DB / Entity Design: tabella relativa a una qualsiasi di più tabelle

Question

Un Rapporto può avere più grafici. La tabella Grafico ha il seguente aspetto:

• Grafico - ID , ChartId , ReportId , ...

Il ChartId sopra può essere mappato sul ChartId su uno dei seguenti tipi di grafici:

• Linea : ChartId , Spessore , YAxis , XAxis , Colore , ...
• Torta : ChartId , Raggio , Colore , ...
• Barra : ChartId , Larghezza , Colore , Bordo , .. .

Sto usando SQL Server e sfortunatamente soluzioni alternative come l'utilizzo di CouchDB ecc. non sono opzioni praticabili. Intendo anche mappare queste tabelle alle entità usando Entity Framework.

Questo disegno è il mio primo colpo e vedo molti problemi con questo disegno:

1. Grafico . ReportId non può essere una chiave esterna su più tabelle, quindi applicare un FK è un problema.
2. Quando eseguo una query SQL (o Linq), dovrò eseguire due query per ottenere il tipo di grafico e quindi interrogare quella tabella. Oppure, dovrò eseguire un join su tutte le tabelle per ottenere i dati del grafico.
3. Quando si effettua un'unione con i tipi di grafico, ChartId su queste tabelle deve essere unico, pertanto Chart . ChartId viene mappato a un solo di Riga . ChartId o Barra . ChartId o Torta . ChartId .
4. Mappare questo con EF sarà complicato.

Immagino che questo sia un problema abbastanza comune che ci sono soluzioni prescritte e modi stabiliti per gestirlo.

Sono sulla buona strada con il design? E in tal caso, come superare i problemi di cui sopra (FK, join, ID univoco su più tabelle e mapping).

Soluzione

Questa rispondi è abbastanza completo sulle strategie. E l'articolo del team SQL su implementazione dell'ereditarietà delle tabelle in SQL Server mi ha portato dove volevo.

Answer 1

Hai considerato di inserire i grafici nella stessa tabella e di utilizzare una Tabella per eredità dell'erarchia modello? Il link lì mostra come implementarlo in Entity Framework. Il fatto che sia praticabile dipende da quanto saranno diversi tutti quei tipi di grafici e da quanti campi ciascuno avrà bisogno.

Esiste anche Tabella per tipo che è più simile a quello che stai già descrivendo.

Answer 2

Lo affronterei con uno schema di ereditarietà delle tabelle:

Chart (ChartId, ChartTypeId)
   PK (ChartId, ChartTypeId)
   CHECK ChartTypeId IN ('Line', 'Bar', 'Pie')

LineChart (ChartId, ChartTypeId)
   PK (ChartId, ChartTypeId)
   FK (ChartId, ChartTypeId) -> Chart
   CHECK ChartTypeId IN ('Line')

Per aggiungere un grafico, devi prima aggiungere a " base " Tabella dei grafici e quindi al sottotipo "quot" appropriato tavolo da carteggio. I vincoli di controllo mantengono tutto in linea.

Answer 3

Grafici a linee. grafici a torta e grafici a barre sono forme specializzate di grafici.

Ricerca " modellazione relazionale di specializzazione di generalizzazione " per buoni articoli su questo modello.

Answer 4

  

O dovrò eseguire un join contro   tutte le tabelle per ottenere i dati del grafico.

Sì, e va bene.