Abstrakte Klasse von UML zu ER-Diagramm. Möglich ? Wie?

Grundsätzlich gibt es drei Möglichkeiten, die Generalisierung in ein Datenbankmodell zu übersetzen

1. Eine Tabelle pro Betonklasse

Erstellen Sie Tabellen Admin , Teacher und Student . Jede dieser Tabellen enthält Spalten für alle Attribute und Beziehungen von User

• Pro
  • Alle Felder einer konkreten Unterklasse befinden sich in derselben Tabelle, sodass kein Join erforderlich ist, um alle Schülerdaten zu erhalten
  • Einfache Datenvalidierungseinschränkungen (z. B. Pflichtfelder für Student )
• Con
  • Alle Felder von User werden in jeder Unterklassentabelle dupliziert
  • Fremdschlüssel für User müssen in drei FK-Felder aufgeteilt werden. Eine für Admin , eine für Teacher und eine für Student .

2. Auf dem Tisch für den gesamten Generalisierungssatz

In diesem Fall haben Sie nur eine Tabelle namens User die alle Felder von User enthält + alle Felder aller Unterklassen von User

• Pro
  • Alle Felder befinden sich in derselben Tabelle, daher ist kein Join erforderlich, um alle User zu erhalten Daten
  • Kein Aufteilen von FK's auf User
• Con
  • Es gibt eine Reihe von Feldern, die nie verwendet werden. Alle Felder spezifisch für Student und Teacher werden für Admins nie ausgefüllt und umgekehrt
  • Datenvalidierung wie Pflichtfelder für eine konkrete Klasse wie Student ziemlich komplex werden, da es kein einfacher Not Null mehr ist Einschränkung.

3. Eine Tabelle pro konkreter Klasse und eine für die Oberklasse

In diesem Fall erstellen Sie Tabellen für jede der konkreten Unterklassen und erstellen eine Tabelle für die Klasse User . Jede der konkreten Unterklassentabellen hat einen obligatorischen FK zu User

• Pro
  • Am meisten normalisiertes Schema:Keine wiederholten Felder für die Attribute des Benutzers und keine ungenutzten Felder.
  • Kein Aufteilen von FK's auf User
  • Einfache Datenvalidierungseinschränkungen (z. B. Pflichtfelder für Student )
• Con
  • Sie müssen zwei Tabellen abfragen, wenn Sie alle Daten eines Student wollen
  • Komplexe Validierungsregeln, um sicherzustellen, dass jeder User Datensatz hat genau einen Admin , Teacher oder Student aufnehmen.

Welche dieser Optionen Sie wählen, hängt von einer Reihe von Dingen ab, wie der Anzahl der Unterklassen, der Anzahl der Attribute in entweder der Unterklasse oder der Oberklasse, der Anzahl der FKs für die Oberklasse und wahrscheinlich ein paar anderen Dingen, die ich nicht getan habe überlegen.