Mysql
 sql >> Database >  >> RDS >> Mysql

Classe astratta dal diagramma UML al diagramma ER. Possibile? Come?

Ci sono fondamentalmente tre scelte per tradurre la generalizzazione in un modello di database

1. Un tavolo per classe di calcestruzzo

Crea tabelle Admin , Teacher e Student . Ciascuna di queste tabelle contiene colonne per tutti gli attributi e le relazioni di User

  • Pro
    • Tutti i campi di una sottoclasse concreta si trovano nella stessa tabella, quindi non è necessario unire per ottenere tutti i dati degli studenti
    • Restrizioni di convalida dei dati semplici (come i campi obbligatori per Student )
  • Con
    • Tutti i campi di User sono duplicati in ogni tabella di sottoclasse
    • Chiavi straniere per User devono essere suddivisi in tre campi FK. Uno per Admin , uno per Teacher e uno per Student .

2. Sul tavolo per l'intero set di generalizzazioni

In questo caso hai solo una chiamata di tabella User che contiene tutti i campi di User + tutti i campi di tutte le sottoclassi di User

  • Pro
    • Tutti i campi sono nella stessa tabella, quindi non è necessario alcun join per ottenere tutti gli User dati
    • Nessuna suddivisione di FK in User
  • Con
    • Ci sono un sacco di campi che non vengono mai utilizzati. Tutti i campi specifici per Student e Teacher non vengono mai compilati per Admins e viceversa
    • Convalida dei dati come campi obbligatori per una classe concreta come Student diventa piuttosto complesso in quanto non è più un semplice Not Null vincolo.

3. Una tabella per classe concreta e una per la superclasse

In questo caso crei tabelle per ciascuna delle sottoclassi concrete e crei una tabella per la classe User . Ciascuna delle tabelle di sottoclassi concrete ha un FK obbligatorio per User

  • Pro
    • Schema più normalizzato:nessun campo ripetuto per gli attributi dell'utente e nessun campo inutilizzato.
    • Nessuna suddivisione di FK in User
    • Restrizioni di convalida dei dati semplici (come i campi obbligatori per Student )
  • Con
    • Devi interrogare due tabelle se vuoi tutti i dati di uno Student
    • Regole di convalida complesse per assicurarsi che ogni User record ha esattamente un Admin , Teacher o Student registrare.

Quale di queste opzioni scegli dipende da una serie di cose come il numero di sottoclassi, il numero di attributi nella sottoclasse o nella superclasse, il numero di FK nella superclasse e probabilmente alcune altre cose che non ho fatto pensaci.