Wie werden super - und Subtyp-Beziehungen in ER-Diagrammen dargestellt, die als Tabellen?

Ich versuche es zu lernen, wie zu interpretieren, Entity-Relationship-Diagramme in SQL-DDL-Anweisungen, und ich bin verwirrt durch die Unterschiede in der notation. Betrachten Sie eine disjunkte Beziehung, wie im folgenden Diagramm:

Wie werden super - und Subtyp-Beziehungen in ER-Diagrammen dargestellt, die als Tabellen?

Würde dies wie folgt dargestellt werden:

  1. Fahrzeug, 2WD und 4WD-Tabellen (2WD und 4WD würde, zeigen Sie auf der PK des Fahrzeugs); oder
  2. NUR die 2WD-und 4WD-Tabellen (und KEINE Fahrzeug-Tabelle), beide würde die doppelte alle Attribute Fahrzeug hätte?

Ich denke, dies sind die anderen Arten des Schreibens die Beziehung:

Wie werden super - und Subtyp-Beziehungen in ER-Diagrammen dargestellt, die als Tabellen?
Wie werden super - und Subtyp-Beziehungen in ER-Diagrammen dargestellt, die als Tabellen?

Ich bin auf der Suche nach einer eindeutigen Erklärung der Differenz in Bezug auf das, was Tabellen, die Sie würde am Ende mit für jedes Diagramm.

  • In Relationale Datenbank-Terminologie, ist dies eine einfache, straight-forward - Exklusive Subtyp Anforderung. UML kann sein verwendet, um zu definieren, RDbs, der es einfach nicht über die Schreibweise oder den Reichtum der IDEF1X. Leider ist die OO/ORM-Menge sind ratlos über RDbs und IDEF1X. Generalisierung-Spezialisierung deckt nicht ausreichend, keine Modelle oder Methoden gegeben ist. Alle Einschränkungen notwendig werden, kann implementiert werden in SQL,ohne den Wahnsinn des kreisförmigen [duplizieren] Referenzen oder Verzögerte Einschränkungsüberprüfung oder "superkeys* duplizieren oder die Indizes.
InformationsquelleAutor xingyu | 2012-08-20
  1. 22

    ER-Notation

    Gibt es mehrere ER-Notationen. Ich bin nicht vertraut mit, die Sie verwenden, aber es ist klar genug, Sie versuchen, stellen einen Subtyp (aka. Vererbung, Kategorie, Unterklasse Generalisierung Hierarchie...). Dies ist die relationale cousin der OOP-Vererbung.

    Wenn dabei subtypisierung, Sie sind in der Regel befasst sich mit den folgenden design-Entscheidungen:

    • Abstrakt vs. konkret: das übergeordnete Element instanziiert werden? In deinem Beispiel: kann ein Vehicle existieren ohne auch 2WD oder 4WD?1
    • Inclusive vs. exclusive: Können mehr als ein Kind instanziiert werden für die gleichen Eltern? In deinem Beispiel kann Vehicle werden beide 2WD und 4WD?2
    • Vollständige vs. unvollständige: erwarten Sie, dass mehr Kinder in Zukunft Hinzugefügt werden? In deinem Beispiel, erwarten Sie, dass ein Bike oder eine Plane (etc...) könnte später Hinzugefügt, um die Datenbank-Modell?

    Des Information Engineering notation unterscheidet Sie zwischen inklusiven und exklusiven Subtyp-Beziehung. IDEF1X-notation, auf der anderen Seite, nicht (direkt) zu erkennen, dieser Unterschied, aber es hat die Unterscheidung zwischen vollständigen und unvollständigen Subtyp (der IE nicht).

    Das folgende Diagramm aus dem ERwin-Methoden-Guide (Kapitel 5, Subtyp-Beziehungen) illustriert den Unterschied:

    Wie werden super - und Subtyp-Beziehungen in ER-Diagrammen dargestellt, die als Tabellen?

    Weder IE noch IDEF1X direkt erlauben die Angabe von abstrakten vs. konkreten übergeordneten.

    Physische Darstellung

    Leider, praktische Datenbanken nicht direkt unterstützt Vererbung, so müssen Sie verwandeln dieses Diagramm, um zu echten Tabellen. Grundsätzlich gibt es 3 Ansätze dafür:

    1. Stellen alle Klassen in der gleichen Tabelle, und lassen Sie Kinder Felder, die NULL-Lage. Sie können dann ÜBERPRÜFEN, um sicherzustellen, dass die richtige Teilmenge der Felder in den nicht-NULL.
      • Vorteile: Kein Eintritt, also einige Abfragen profitieren können. Erzwingen können Eltern-level-Tasten (wenn Sie z.B. vermeiden wollen anders 2WD und 4WD Fahrzeuge mit der gleichen ID). Auf einfache Weise erzwingen können inklusive vs. exklusive Kindermode und abstrakte vs. konkrete Elternteil (nur durch Variation der PRÜFUNG).
      • Nachteile: Einige Abfragen werden langsamer, da müssen Sie filter-out "uninteressant" Kinder. Je nach DBMS werden die Kind-spezifischen constraints problematisch sein können. Eine Menge von Null-Werten kann die Lagerung der Abfälle. Weniger geeignet für unvollständige subtypisierung - hinzufügen von neuen Kindes erfordert eine änderung der bestehenden Tabelle, was problematisch sein kann, in einer Produktionsumgebung.
    2. Setzen alle Kinder in separaten Tabellen, aber nicht über eine Tabelle für den übergeordneten (stattdessen wiederholen Sie die übergeordneten Felder und constraints in der alle Kinder). Hat die meisten der Merkmale (3) während die Vermeidung von JOINs, um den Preis der geringeren Wartbarkeit (durch all diese Feld-und constraint-Wiederholungen) und der Unfähigkeit zur Durchsetzung der übergeordneten Schlüssel oder stellen einen konkreten Eltern.
    3. Setzen sich Eltern und Kinder in separaten Tabellen.
      • Vorteile: Sauber. Keine Felder/Einschränkungen müssen künstlich wiederholt. Erzwingt übergeordneten Schlüssel und einfach zu addieren, Kind-spezifische Einschränkungen. Geeignet für unvollständige subtypisierung (relativ leicht hinzufügen mehr den child-Tabellen). Bestimmte Abfragen können profitieren, indem Sie nur auf der Suche auf "interessante" Kind-Tabelle(s).
      • Nachteile: Einige Abfragen JOIN-schwer. Kann sein, schwer zu durchzusetzen, inklusive vs. exklusive Kindermode und abstrakten vs. konkreten übergeordneten (diese durchgesetzt werden kann, deklarativ, wenn das DBMS unterstützt kreisförmigen und latente foreign keys, aber die Durchsetzung auf der Anwendungsebene wird in der Regel als das kleinere übel).

    Wie Sie sehen können, die situation ist weniger als ideal ist, müssen Sie Kompromisse machen, was auch immer Ansatz Sie wählen. Der Ansatz (3) sollten wahrscheinlich Ihren Ausgangspunkt, und nur eine der alternativen zu wählen, wenn es einen zwingenden Grund, dies zu tun.

    1 ich vermute, dies ist, was die Stärke der Linie steht für die in Ihren Diagrammen.

    2 ich vermute, dies ist, was das Vorhandensein oder die Abwesenheit von "disjunkt" steht für die in Ihren Diagrammen.

    InformationsquelleAutor Branko Dimitrijevic
  2. 3

    In der Regel, wenn Sie ein Super-Typ/Sub-Typ-Beziehung in Ihrer Datenbank design, erstellen Sie eine separate Tabelle für Ihre Allgemeinen Entity-Typ (Super Typ) und separate Tabellen für Ihre speziellen Entität version/s (Sub-Typ) disjunkt oder nicht. In Ihrem Fall, Sie brauchen, um eine Tabelle zu erstellen für FAHRZEUG und einem primären Schlüssel und einige Attribute, die auf gemeinsamen oder als gemeinsam von allen Sub-Typen. Dann müssen Sie erstellen Sie separate Tabellen für die 2WD und 4WD zusammen mit spezifischen Attributen nur auf diese Tabellen. Zum Beispiel

    Wie werden super - und Subtyp-Beziehungen in ER-Diagrammen dargestellt, die als Tabellen?

    dann könnte man die Abfrage von Tabellen mithilfe von SQL-Joins

    InformationsquelleAutor curzedpirate
  3. 2

    Was andere-Responder sagte, plus das folgende, das geht in primär-Schlüssel für die Unterklasse Tabellen.

    Ihrem Fall sieht aus wie eine Instanz des design-Muster, bekannt als "Generalisierung-Spezialisierung" , oder Gen-Spec für kurze. Die Frage, wie das Modell gen-spec die Verwendung von Datenbank-Tabellen kommt die ganze Zeit SO.

    Wenn du Modellierung von gen-spec in einer OOPL wie Java verwenden Sie die Unterklasse, Vererbung, Anlage, Pflege der details für Sie. Sie würde einfach eine Klasse definieren, kümmern sich um die generalisierte Objekte, und definieren Sie dann eine Sammlung von Unterklassen, eine für jede Art von spezialisierten Objekt. Jede Unterklasse erweitert die Allgemeine Klasse. Es ist einfach und unkompliziert.

    Leider ist das relationale Datenmodell nicht-Unterklasse, Vererbung eingebaut, und die SQL-Datenbank-Systeme bieten keine solche Anlage, meines Wissens. Aber Sie sind nicht das Glück. Sie können Ihre design-Tabellen-Modell gen-spec in einer Weise, dass parallels die Klassenstruktur der OOP. Sie haben dann zu arrangieren, um Ihre eigenen Vererbungsmechanismus, wenn neue Elemente Hinzugefügt werden, die generalisierte Klasse. Details Folgen.

    Klasse Struktur ist ziemlich einfach, mit einer Tabelle für die Klasse gen und eine Tabelle für jede Skillung Unterklasse. Hier ist eine schöne Abbildung, von Martin Fowler ' s website. Class Table Inheritance. Beachten Sie, dass in diesem Diagramm, Cricket-Spieler, ist sowohl eine Unterklasse und eine Oberklasse. Sie haben zu wählen, welche Attribute gehen in die Tabellen ein. Die Abbildung zeigt eine Beispiel-Attribut in jeder Tabelle.

    Kniffligen detail ist, wie definieren Sie Primärschlüssel für diese Tabellen. Die Klasse gen Tabelle bekommt einen Primärschlüssel in der üblichen Weise (es sei denn, diese Tabelle ist eine Spezialisierung noch eine Verallgemeinerung, wie Kricketspieler). Die meisten Designer geben, die den primären Schlüssel einer standard-Namen, wie z.B. "Id". Verwenden Sie die AutoWert-Funktion, um füllen Sie das Id-Feld. Die spec-Klasse-Tabellen bekommen Sie einen primär-Schlüssel, die mit dem Namen "Id", aber die AutoWert-Funktion wird nicht verwendet. Anstelle der Primärschlüssel jeder Unterklasse Tabelle gebunden ist, der zum verweisen auf die Primärschlüssel der verallgemeinerten Tabelle. Dies macht jedes einzelne der spezialisierten Primärschlüssel einen Fremdschlüssel als auch ein Primärschlüssel. Beachten Sie, dass im Falle der Kricketspieler, das Id-Feld referenziert das Feld " Id " in die Spieler, aber das Id-Feld in der Kegler-Verweis auf das Feld Id in der Kricketspieler.

    Nun, wenn Sie neue Elemente hinzufügen, die Sie haben, um die referenzielle Integrität zu erhalten, Hier ist, wie.

    Sie legen Sie zuerst eine neue Zeile in die gen-Tabelle, die Daten für alle Attribute außer dem Primärschlüssel. Das AutoWert-Mechanismus generiert einen eindeutigen Primärschlüssel. Als Nächstes fügen Sie eine neue Zeile in die entsprechenden spec-Tabelle, einschließlich der Daten für alle Ihre Attribute, einschließlich primärer Schlüssel. Der primäre Schlüssel, den Sie verwenden, ist eine Kopie der Marke neue primäre Schlüssel, den Sie gerade generiert. Diese Vermehrung der Primärschlüssel kann als "poor man ' s Erbe".

    Nun, wenn Sie wollen, dass alle Allgemeinen Daten zusammen mit den Daten spezialisiert ist, nur aus einer Unterklasse, alles, was Sie tun müssen, ist verbinden Sie die beiden Tabellen über den gemeinsamen Schlüssel. Alle Daten, die nicht beziehen sich auf die Unterklasse drop aus dem join. Es ist glatt, einfach und schnell.

    InformationsquelleAutor Walter Mitty
  4. 1

    Es ist nicht immer nur eine Möglichkeit zur Implementierung von bestimmten Daten-Modell. Oft ist es eine transformation, die Auftritt, wenn Sie ein logisches Modell physikalisches Modell.

    Standard-SQL nicht über eine saubere Art und Weise zu erzwingen disjunkte Subtyp Einschränkungen.

    Wenn Ihr Ziel ist es, durchzusetzen, als viele Ihrer model-Regeln wie möglich mit dem schema, dann wird der standard-Ansatz für die Umsetzung Ihres Modells ist die Verwendung einer Tabelle für den obertyp und eine für jede der Unterarten. Dadurch wird sichergestellt, dass nur die gültigen Attribute für jede Entität.

    Gibt es eine mehr oder weniger standard-SQL-trick für die Durchsetzung der disjunkten constraint. Es bringt einige Leute ab, da Sie gegen normalisierungsregeln in eine unwichtige Weg. Noch immer, einige Leute finden, die Technik ästhetisch anstößig, da es eine technische Verletzung der 2NF.

    Diese Technik beinhaltet das hinzufügen eines Partitionierung Attribut an den obertyp und darunter diese Partitionierung-Attribut in jedem Subtyp, indem es auf den Primärschlüssel der Subtyp. Zusammen mit check-Einschränkungen, die vorschreiben, die bestimmte Werte für die Aufteilung von Attributen, dies stellt sicher, dass jede Entität kann maximal einen Subtyp. Die Technik ist ausführlich dokumentiert in vielen Orten, wie dieser blog.

    • Es ist fair genug, dass Sie Sie gelesen haben, etwas in einem blog irgendwo, und Sie wiederholte es, aber echtes wissen & Erfahrungen fehlen. Der trick ist, nicht ein "standard" (nur Normen, Organisationen, Normen). Es ist ein Greuel, verursacht doppelte Spalten und zusätzliche Indizes. Wenn Sie wie massive Vervielfältigung und der reduzierten Leistung, das ist in Ordnung, aber zu verhängen, um es auf andere, und das Etikett "standard" ai ai ai. Die Abscheulichkeit war offenbar geschrieben von Joe Celko vor vielen Jahren, als seine eigenen. Wenn ich nahm es mit ihm auf c.d....t, und wies darauf hin, seine Absurdität,
    • gegeben, dass es getan werden kann in reinen SQL "sauber", ohne die zusätzliche massive Vervielfältigung, wich er aus und sagte, er habe ihn nicht erfunden. Gegen die Normalisierung ist "unwichtig" nur, wenn die Relevanz von db-design und den Wert der Normalisierung ist nicht bekannt; nichts "ästhetischen" über es. Die richtige Methode (ich will nicht hin, es ist "standard", und wir wissen bereits, es ist nicht bekannt, um die Massen) ist die Antwort. Eine Exklusive Subtyp umgesetzt deklarativ & garantiert durch den server (nicht app-code). Keine Vervielfältigung, kein zusätzlicher index pro Subtyp.
    • Ich werde nicht streiten mit Ihnen über die potenziellen legitimen Nutzungen des Wortes der standard da das DBA.SE nicht EL&U. SE. Ich werde vorschlagen, dass nach 25 Jahren gezahlt, um die Entwicklung von business-Anwendungen, die ich denke, ich habe viel von "echtes wissen & erleben". Wie zu Greuel, ich werde sagen, dass anstelle der Blick auf die Welt, in der extremistische Bezug auf meine Erfahrung sagt mir, dass Faustregeln sind schön und gut, aber es ist besser zu verstehen, die Logik dahinter und anwenden, Begründung, statt nach der Regel, ohne darüber nachzudenken, warum.
    InformationsquelleAutor Joel Brown
Schreibe einen Kommentar