Modellierung eines Szenarios, in dem jeder Musikkünstler entweder eine Gruppe oder ein Solist ist

12

Ich muss ein Entity-Relationship-Diagramm (ERD) für einen Geschäftskontext entwerfen, in dem Musikkünstler beschrieben werden , wie ich weiter unten ausführlich erläutere.

Szenariobeschreibung

  • Ein Künstler hat einen Namen und muss entweder eine Gruppe oder ein Solist sein (aber nicht beide).

  • Eine Gruppe besteht aus einem oder mehreren Solo-Performern und hat eine Anzahl von Mitgliedern (die aus der Anzahl der Solo-Performer berechnet werden sollte, aus denen die Gruppe besteht ).

  • Ein Solist kann Mitglied vieler Gruppen oder keiner Gruppe sein und ein oder mehrere Instrumente spielen .

Frage

Wie erstelle ich eine ERD, um ein solches Szenario darzustellen? Ich bin verwirrt mit dem 'oder' Teil davon.

Boshir
quelle

Antworten:

15

Der Teil des Szenarios, mit dem Sie verwechselt werden, kann mit einem klassischen Konstrukt namens Supertyp-Subtyp- 1- Struktur modelliert werden.

Ich werde (1) einige relevante vorläufige Ideen einführen, (2) detailliert beschreiben, wie ich - auf konzeptioneller Ebene - den betrachteten Geschäftskontext abgrenzen würde, und (3) zusätzliches verwandtes Material bereitstellen - z. B. die entsprechende Darstellung auf logischer Ebene über SQL -DDL-Deklarationen - wie folgt.

Einführung

Eine Struktur dieser Art findet statt, wenn es in einer bestimmten Geschäftsumgebung einen Cluster von Entitätstypen gibt, in dem der Supertyp eine oder mehrere Eigenschaften (oder Attribute) aufweist, die von den übrigen Entitätstypen im Cluster gemeinsam genutzt werden, d. H. , die Untertypen . Jeder Subtyp verfügt wiederum über einen bestimmten Satz von Eigenschaften, die nur für sich selbst gelten.

Es gibt zwei Arten von Supertyp-Subtyp-Clustern:

  • Exklusiv . Kommt zustande, wenn eine Instanz des Superentitätstyps immer nur ein Subtyp-Gegenstück haben muss; Daher schließen sich die potenziellen Subtypvorkommen gegenseitig aus . Dies ist die Art, die Ihr Szenario betrifft.

    Ein typischer Fall, in dem ein exklusiver Supertyp-Subtyp entsteht, ist eine Geschäftsdomäne, in der sowohl eine Organisation als auch eine Person als rechtliche Parteien gelten , wie in der in dieser Reihe von Beiträgen beschriebenen Situation .

  • Nicht exklusiv . Stellt sich , wenn ein übergeordneter Typ - Instanz kann durch mehrere Subtyp ergänzt werden Vorkommen , von denen jede dazu gezwungen wird von einer anderen zu sein Kategorie .

    Ein Beispiel für diese Art von Supertyp-Subtyp wird in diesen Beiträgen behandelt .

Anmerkungen : Es ist erwähnenswert, dass Supertyp-Subtyp-Strukturen - Elemente eines konzeptuellen Charakters - nicht zu einem bestimmten theoretischen Rahmen für die Datenverwaltung gehören, sei es relational, netzwerk- oder hierarchisch - von denen jede bestimmte Strukturen zur Darstellung konzeptioneller Elemente bietet -.

Es ist auch angebracht darauf hinzuweisen, dass Supertyp-Subtyp-Cluster zwar eine gewisse Ähnlichkeit mit der Vererbung und dem Polymorphismus der objektorientierten Anwendungsprogrammierung (OOP) aufweisen , jedoch tatsächlich unterschiedliche Geräte sind, da sie unterschiedlichen Zwecken dienen. In einer Datenbank konzeptionellen Modell -Das reale Welt aspects- man sich mit repräsentieren muß strukturelle Merkmale zu beschreiben , um Informationsanforderungen, während in OOP Polymorphismus und Vererbung, unter anderem ein (a) Skizzen und (b) Arbeitsgeräte Rechen und Verhaltensmerkmale , Aspekte, die eindeutig zum Design und zur Programmierung von Anwendungsprogrammen gehören.

Abgesehen davon muss eine einzelne OOP- Klasse, die eine Anwendungsprogrammkomponente ist, nicht unbedingt die Struktur eines einzelnen Entitätstyps „spiegeln“, der zur konzeptionellen Ebene der vorliegenden Datenbank gehört. In dieser Hinsicht kann ein Anwendungsprogrammierer typischerweise beispielsweise eine einzelne Klasse erstellen, die alle Eigenschaften von zwei (oder mehr) verschiedenen Entitätstypen auf konzeptioneller Ebene "kombiniert", und eine solche Klasse kann auch berechnete Eigenschaften enthalten.

Verwenden von Entity-Relationship-Konstrukten zur Darstellung eines konzeptionellen Modells mit Supertyp-Subtyp-Strukturen

Sie haben nach einem Entity-Relationship-Diagramm (ERD der Kürze halber) gefragt, aber obwohl es sich um eine außergewöhnliche Modellierungsplattform handelt, lieferte die ursprüngliche Methode - wie sie von Dr. Peter Pin-Shan Chen 2 eingeführt wurde - nicht genügend Konstrukte, um Szenarien dieser Art darzustellen mit der Genauigkeit diskutiert, die ein geeignetes konzeptionelles Datenbankmodell erfordert.

Infolgedessen war es notwendig, einige Erweiterungen dieser Methode vorzunehmen. Diese Situation führte zur Entwicklung eines Ansatzes, der die Erstellung erweiterter Entity-Relationship-Diagramme (EERDs) unterstützt, die natürlich die anfängliche Diagrammtechnik mit neuen Ausdrucksmerkmalen bereicherten . Eine dieser Eigenschaften ist genau die Möglichkeit, Supertyp-Subtyp-Strukturen darzustellen.

Modellierung Ihres Interessenkontexts

Die in Abbildung 1 gezeigte Abbildung ist eine EERD (unter Verwendung von Symbolen ähnlich den von Ramez A. Elmasri und Shamkant B. Navathe 3 vorgeschlagenen , die sich auf Strukturen wie Superklasse / Unterklasse beziehen ), in denen ich die von Ihnen beschriebene Geschäftsdomäne unter Berücksichtigung aller Faktoren modelliert habe Spezifikationen. Es ist auch als PDF verfügbar, das von Dropbox heruntergeladen werden kann .

Wie Sie in dem oben genannten Diagramm sehen können, werden beide Groupund SoloPerformerals exklusive Untertypen des ArtistSuperentitätstyps angezeigt :

Verbessertes Entity-Relationship-Diagramm für Musikkünstler

Diagrammbeschreibung

Um mit der Beschreibung des EERD zu beginnen, ist es wichtig, darauf hinzuweisen, dass Ihr Satz

  • "Ein Künstler muss entweder eine Gruppe oder ein SoloPerformer sein (aber nicht beide)"

hängt mit der Disjunktheit und den Vollständigkeitsaspekten des vorliegenden Supertyp-Subtyp-Clusters zusammen.

Disjunktheit

Die Disjunktheitsfunktion ist besonders wichtig, da genau hier das von Ihnen erwähnte „oder Teil“ ins Spiel kommt, da Artistes sich entweder um eine Subtypinstanz oder die andere handeln muss, die ich in der EERD durch die kleine angegeben habe Kreis mit dem Buchstaben "d", einem Konstrukt, das den Namen der disjunkten Regel erhält .

Wenn ein Supertyp durch einen oder mehrere seiner möglichen Subtypen ergänzt werden kann, muss dieser Punkt durch einen kleinen Kreis ausgedrückt werden, der eine Beschriftung mit dem Buchstaben „o“ enthält, einem Symbol, das als Überlappungsregel bezeichnet wird .

Diskriminator-Eigenschaft

Auch im Rahmen des Disjunktheitsfaktors dieser Supertyp-Subtyp-Assoziation lohnt es sich, der Artist.TypeEigenschaft besondere Aufmerksamkeit zu schenken , da sie in dieser Anordnung eine sehr relevante Aufgabe erfüllt: Sie fungiert als Subtyp- Diskriminator . Es wird auf diese Weise benannt, da es die Eigenschaft ist, die auf die exklusive Art von Subtyp hinweist, auf die sich eine bestimmte Instanz von Artistbezieht.

In Fällen von nicht exklusiven Clustern ist die Verwendung einer Diskriminatoreigenschaft unnötig, da ein bestimmter Supertyp mehrere Subtypen als Komplemente haben kann (wie oben erwähnt).

Totale Spezialisierungsregel und Vollständigkeit

Die Anforderung, dass jeder Artistimmer eine zusätzliche Subtypinstanz haben muss, hat mit der Vollständigkeitscharakteristik dieses Clusters zu tun. Dies wird durch eine totale Spezialisierungsregel beschrieben , die durch das zweizeilige Symbol demonstriert wird, das (a) den ArtistSupertyp mit (b) dem disjunkten Regelkonstrukt verbindet.

Gruppen mit Solisten verbinden

Auswertung der Sätze

  • "Eine Gruppe besteht aus einem oder mehreren SoloPerformern "

und

  • „Ein SoloPerformer kann Mitglied vieler Gruppen oder keiner Gruppe sein “,

man kann erkennen, dass beide Subtypen an einer Viele-zu-Viele- Assoziation (oder Beziehung) beteiligt sind (M: N), die ich mit dem rautenförmigen Kästchen mit der Bezeichnung dargestellt habe Group-SoloPerformer.

Wenn diese Komponente in einer relationalen Datenbank als Basistabelle implementiert wird, ist sie sehr nützlich, um die Summe Numberder SoloPerformerskonkreten Elemente Group(eine der von Ihnen angegebenen Anforderungen) abzuleiten (dh die Berechnung durchzuführen ).

Die Assoziation zwischen Solisten und Instrumenten

Die Bestimmung

  • „Ein SoloPerformer […] kann ein oder mehrere Instrumente spielen.“

erlaubt uns zu schließen, dass gleichzeitig

  • "Ein Instrument wird von null, einem oder mehreren SoloPerformern gespielt".

Dies ist also ein weiteres Beispiel für eine M: N-Assoziation, und ich habe die rautenförmige Figur verwendet SoloPerformer-Instrument, um sie freizulegen.

Zusätzliches Material

Um den Umfang der Supertyp-Subtyp-Strukturen zu erläutern, werde ich zwei weitere Ressourcen einbeziehen, d. H.

  1. ein in Abbildung 2 dargestelltes IDEF1X 4- Diagramm ( und Sie können es auch als PDF von Dropbox herunterladen ), das die Ausdrucksmöglichkeiten dieser Art von Diagrammen in Bezug auf die betreffende Geschäftsdomäne veranschaulicht; und

  2. Die jeweilige logische DDL-Struktur des Expositorys, die beispielhaft zeigt, wie das gesamte diskutierte Szenario mithilfe eines SQL-Datenbankverwaltungssystems verwaltet wird.

1. IDEF1X-Darstellung

Die IDEF1X-Informationsmodellierungstechnik bietet sicherlich die Möglichkeit, Supertyp-Subtyp-Strukturen darzustellen, allerdings mit einer Einschränkung: Sie bietet keinen visuellen Mechanismus, um anzuzeigen, ob ein präziser Cluster exklusiver oder nicht exklusiver Art ist (seine „nativen“ Symbole können nur kommunizieren die vollständige oder unvollständige Identifizierung aller möglichen Subentitätstypen von Bedeutung). Glücklicherweise kann man die Information Engineering (IE) -Notation verwenden, um diesen überragenden Aspekt genauer darzustellen und gleichzeitig die Beschreibungskraft des IDEF1X-Standards zu nutzen.

Bei dieser Technik wird das Hauptmerkmal Ihrer Frage als "Kategorisierungsbeziehung" bezeichnet, wobei ein Supertyp als "generische Entität" bezeichnet wird und ein Subtyp den Namen "Kategorieentität" erhält. Ich werde den Begriff Supertyp-Subtyp jedoch in diesem Beitrag weiter anwenden, da (1) er von Dr. Edgar Frank Codd, dem Urheber des relationalen Modells, verwendet wurde, (2) er bekannter ist und (3) die IE-Notation ist wird anstelle des "nativen" verwendet.

Musikkünstler IDEF1X Diagramm

Fremdschlüssel und Supertyp-Subtyp-Cluster

Wie gezeigt, bietet IDEF1X einen weiteren Vorteil: die Möglichkeit, FOREIGN KEY (FK) -Definitionen anzuzeigen, Elemente von größter Bedeutung, wenn ein Praktiker eine Supertyp-Subtyp-Assoziation in einer relationalen Datenbank darstellen soll.

Um eine solche Art von Assoziation darzustellen, der primäre Schlüssel (PK) Eigenschaft des Supertyp, das heißt Artist.ArtistNumber, hat zu migrieren , zu Groupund SoloPerformer, obwohl es zwei verschiedene zugewiesen wurde Rollennamen 5, 6 , GroupNumberund die SoloPerformerNumberjeweils zum Zwecke der Betonung die Bedeutung, die die Eigenschaft im Kontext jedes Subentitätstyps vermittelt.

Abgesehen davon, dass sie als PKs charakterisiert sind, werden die Eigenschaften Group.GroupNumberund SoloPerformer.SoloPerformerNumbergleichzeitig als FOREIGN KEYs (FKs) dargestellt, die auf Artist.ArtistNumberdie Supertyp-PK-Eigenschaft verweisen .

Also, da jeder SoloPerformerund GroupAuftreten Existenz abhängig von einer genauen ArtistInstanz werden diese Entitätstypen in einer beteiligt identifiziert Assoziation , die in den vorstehenden Absätzen abgegrenzten Effekt durch den PK Eigenschaft Migrationsprozess dauert.

Fremdschlüssel und assoziative Entitätstypen

Das IDEF1X-Diagramm dient auch zur Veranschaulichung der FKs, aus denen die PKs der beiden relevanten assoziativen Entitätstypen bestehen , dh GroupMemberund SoloPerformerInstrument; Der erste verbindet die beiden Untertypen, und der zweite verbindet einen Untertyp mit einem unabhängigen Entitätstyp, d Instrument. h .

2. Logische Expository SQL-DDL-Deklarationen

Wie bereits erläutert, ist eine Supertyp-Subtyp-Struktur ein Mittel, um bestimmte Arten von geschäftsdomänenspezifischen Konzeptualisierungen in Bezug auf Informationsanforderungen auszudrücken, die wiederum in einer Datenbank durch unterschiedliche Konstrukte dargestellt werden können, die denen entsprechen müssen, die von dem jeweiligen angeboten werden theoretisches Paradigma (sei es relational, netzwerk- oder hierarchisch), gefolgt vom Datenbankverwaltungssystem, das vom Designer verwendet wird.

Einer der vielfältigen Vorteile des relationalen Paradigmas besteht darin, dass es die Darstellung der Informationen in ihrer natürlichen Struktur ermöglicht. Die beliebtesten Annäherungen an die in der relationalen Theorie vorgeschlagenen Systeme sind die verschiedenen SQL-Datenbankverwaltungssysteme.

So, endlich, hier sind einige Beispiele für DDL - Anweisungen -einschließlich (a) Basistabellen Schemata zusammen mit (b) einige der betreffenden constraints-, die auf der logischen Ebene der Abstraktion dar, die konzeptuelle Modellierung Übung oben behandelt:

--
--
CREATE TABLE Artist ( -- Stands for the supertype.
    ArtistNumber    INT      NOT NULL,
    Name            CHAR(30) NOT NULL,
    Type            CHAR(1)  NOT NULL, -- Holds the discriminator values.
    CreatedDateTime DATETIME NOT NULL,
    --
    CONSTRAINT Artist_PK      PRIMARY KEY (ArtistNumber),
    CONSTRAINT Artist_AK      UNIQUE      (Name), -- ALTERNATE KEY.
    CONSTRAINT Artist_Type_CK CHECK       (Type IN ('G', 'S')) -- Enforces retaining either ‘G’, for ‘Group’, or ‘S’, for ‘SoloPerformer’, only.
);

CREATE TABLE MyGroup ( -- Represents one subtype.
    GroupNumber   INT  NOT NULL, -- To be constrained as PK and FK simultaneously.
    FormationDate DATE NOT NULL,
    --
    CONSTRAINT MyGroup_PK         PRIMARY KEY (GroupNumber),
    CONSTRAINT MyGroupToArtist_FK FOREIGN KEY (GroupNumber)
        REFERENCES Artist (ArtistNumber)  
);

CREATE TABLE SoloPerformer ( -- Denotes the other subtype.
    SoloPerformerNumber INT  NOT NULL, -- To be constrained as PK and FK simultaneously.
    BirthDate           DATE NOT NULL,
    --
    CONSTRAINT SoloPerformer_PK               PRIMARY KEY (SoloPerformerNumber),
    CONSTRAINT SoloPerformerNumberToArtist_FK FOREIGN KEY (SoloPerformerNumber)
        REFERENCES Artist (ArtistNumber)  
);

CREATE TABLE GroupMember ( -- Stands for a M:N association involving the two subtypes.
    MemberNumber INT  NOT NULL,
    GroupNumber  INT  NOT NULL,
    JoinedDate   DATE NOT NULL,
    --
    CONSTRAINT GroupMember_PK                PRIMARY KEY (MemberNumber, GroupNumber), -- Composite PK.
    CONSTRAINT GroupMemberToSoloPerformer_FK FOREIGN KEY (MemberNumber)
        REFERENCES SoloPerformer (SoloPerformerNumber),
    CONSTRAINT GroupMemberToMyGroup_FK       FOREIGN KEY (GroupNumber)
        REFERENCES MyGroup       (GroupNumber)  
);

CREATE TABLE Instrument ( -- Represents an independent entity type.
    InstrumentNumber INT      NOT NULL,
    Name             CHAR(30) NOT NULL,
    --
    CONSTRAINT Instrument_PK PRIMARY KEY (InstrumentNumber),
    CONSTRAINT Instrument_AK UNIQUE      (Name) -- ALTERNATE KEY.  
);

CREATE TABLE SoloPerformerInstrument ( -- Denotes another M:N association, in this case between a subtype and an independent entity type.
    SoloPerformerNumber INT  NOT NULL,
    InstrumentNumber    INT  NOT NULL,
    CreatedDate         DATE NOT NULL,
    --
    CONSTRAINT SoloPerformerInstrument_PK                PRIMARY KEY (SoloPerformerNumber, InstrumentNumber), -- Composite PK.
    CONSTRAINT SoloPerformerInstrumentToSoloPerformer_FK FOREIGN KEY (SoloPerformerNumber)
        REFERENCES SoloPerformer (SoloPerformerNumber),
    CONSTRAINT SoloPerformerInstrumentToInstrument_FK    FOREIGN KEY (InstrumentNumber)
        REFERENCES Instrument    (InstrumentNumber)  
);
--
--

Überlegungen zur Datenintegrität und -konsistenz

In Übereinstimmung mit all dem, was zuvor erläutert wurde, muss der Designer sicherstellen, dass jede Zeile „Supertyp“ jederzeit durch das zugehörige Gegenstück „Untertyp“ ergänzt wird, und im Gegenzug sicherstellen, dass diese Zeile „Untertyp“ mit dem Wert kompatibel ist in der Spalte "Diskriminator" des Supertyps enthalten.

Es wäre sehr praktisch und elegant, diese Umstände deklarativ durchzusetzen (wie es das relationale Framework vorschlägt), aber leider hat keine der großen SQL-Plattformen die geeigneten Mechanismen dafür bereitgestellt (soweit ich weiß). Daher ist es sehr bequem, ACID TRANSACTIONS zu verwenden, damit diese Bedingungen immer in einer Datenbank erfüllt sind (eine andere Option wäre die Verwendung von TRIGGERS, aber sie neigen dazu, die Dinge unordentlich zu machen).

Überlegungen zur Datenableitung

Einer der Hauptaspekte des relationalen Modells besteht darin, dass es die Datenableitung als einen entscheidenden Faktor bei der Datenverwaltung betrachtet. Entsprechend erleichtert sie (a) die Schaffung Basis Beziehungen -oder Basistabellen in SQL, wie in der DDL - Anweisungen dargestellt ober- und (b) abgeleiteten Relationen - abgeleitete Tabellen in SQL, dh diejenigen , erklärt vermöge SELECT - Operationen , die sein kann , als Ansichten für die weitere Ausbeutung festgelegt -.

So kann man eine Ansicht deklarieren, die die "vollständigen" Gruppendatenpunkte sammelt :

CREATE VIEW FullGroup AS
    SELECT G.GroupNumber,
           A.Name,
           A.CreatedDateTime,
           G.FormationDate
         FROM Artist A
         JOIN MyGroup G 
           ON G.GroupNumber = A.ArtistNumber;

Und eine andere Ansicht, die die „vollständigen“ SoloPerformer- Informationen kombiniert :

CREATE VIEW FullSoloPerformer AS
    SELECT SP.SoloPerformerNumber,
            A.Name,
            A.CreatedDateTime,
           SP.BirthDate
         FROM Artist A
         JOIN SoloPerformer SP 
           ON SP.SoloPerformerNumber = A.ArtistNumber;

Auf diese Weise ist es sehr einfach, - deklarativ - alle signifikanten Daten über dasselbe Gerät auf logischer Ebene zu manipulieren, dh über die Beziehung oder Tabelle (sei es Basis oder abgeleitet). Offensichtlich ist die Verwendung von Ansichten effektiver, wenn die in einer relationalen Datenbank dargestellten konzeptuellen Entitätstypen mehr interessante Eigenschaften besitzen, aber es ist eine Möglichkeit, die mit dem vorliegenden Szenario veranschaulicht werden sollte.


Verweise

1 Codd, EF (Dezember 1979). Erweiterung des relationalen Datenbankmodells, um mehr Bedeutung zu erfassen , ACM-Transaktionen auf Datenbanksystemen , Band 4, Ausgabe 4 (S. 397-434). New York, NY, USA.

2 Chen, PP (März 1976). Das Entity-Relationship-Modell - Auf dem Weg zu einer einheitlichen Sicht auf Daten , ACM-Transaktionen auf Datenbanksystemen - Sonderausgabe: Beiträge der Internationalen Konferenz über sehr große Datenbanken: 22. bis 24. September 1975, Framingham, MA , Band 1, Ausgabe 1 (S. 9-36). New York, NY, USA.

3 Elmasri, R & Navathe, SB (2003). Grundlagen von Datenbanksystemen , 4. Auflage. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

4 Nationales Institut für Standards und Technologie (USA) [NIST] (Dezember 1993). Integrationsdefinition für Informationsmodellierung (IDEF1X), Federal Information Processing Standards Publication , Band 184. USA.

5 Codd, EF (Juni 1970). Ein relationales Datenmodell für große gemeinsam genutzte Datenbanken , Mitteilungen des ACM , Band 13, Ausgabe 6 (S. 377-387). New York, NY, USA.

6 Siehe Referenz 4

MDCCL
quelle
4

Die Antwort von MDCCL ist faszinierend, lehrreich und vermutlich richtig (obwohl über meiner Gehaltsstufe).

Im Gegensatz dazu habe ich die Frage neu interpretiert und bin zu den Grundlagen zurückgekehrt, um eine möglichst einfache Lösung zu finden. Vielleicht betrüge ich und beantworte die Frage nicht wirklich ... aber hier geht es trotzdem.

Ich war verwirrt, als ich die Frage las und wieder las. Als ich den Begriff "Künstler" sah, dachte ich immer an einzelne Menschen. Aber nein, es ist im Sinne von "Artistic Brand Labeling" gemeint, wie ein Musikalbum einen Titel und einen "Künstler" hat, ob der Künstler eine Einzelperson wie Johnny Cash oder eine Gruppe wie The Cure ist .

Nehmen wir als Beispiel den Künstler, der jetzt als Prinz bekannt ist . Er hat Alben veröffentlicht als:

Alle vier wären Beispiele für "Künstler". Insbesondere gab es zwei Frauen, Wendy Melvoin und Lisa Coleman, in seiner Band The Revolution, aber nicht in New Power Generation , die abgereist waren, um ihre Karriere unter der Marke Wendy & Lisa fortzusetzen .

Wir hätten also noch eine weitere Instanz von "Artist" mit Wendy & Lisa, während die Individuen Melvoin und Coleman jeweils Darsteller wären, aber nicht "Artist". Diese einzelnen Frauen würden als Darsteller zwei "Künstlerinnen" ((1) Prince & The Revolution , (2) Wendy & Lisa ) zugewiesen .

Das folgende Diagramm ist ein ungeschickter Versuch, diese Beispieldaten kompakt darzustellen. Wir zeigen die beiden unterstrichenen Frauen (Darsteller), die zwei verschiedenen Bands (Künstler) angehören. Und wir zeigen den kursiv geschriebenen Mann Prince, der zu vier Bands (Künstlern) gehört, aber nicht zur letzten Band (Künstler).

Geben Sie hier die Bildbeschreibung ein

Wenn dies die Geschäftsdomäne beschreibt, würde ich das folgende Tabellendesign (und ERD) vorschlagen.

Tabellenentwurfsdiagramm von Künstler, Mitgliedschaft, Darsteller, Spieler, Instrument

Grundsätzlich haben wir zwei Viele-zu-Viele-Beziehungen:

  • Einem Künstler (ob Solo oder Band) sind ein oder mehrere Darsteller zugeordnet. Und ein Performer kann Mitglied eines oder mehrerer "Artist" / Bands sein.
  • Ein Performer kann ein oder mehrere Instrumente spielen. Und auf jedem Instrument können viele Interpreten aufgeführt sein, die es spielen können.

Wie für "Group" und "SoloPerformer":

  • Ein "Solo" ist lediglich ein "Künstler", dem nur ein einziger "Performer" zugewiesen ist.
    (Nur einem untergeordneten Datensatz in der Mitgliedschaftstabelle ist die Künstler-ID als Fremdschlüssel zugewiesen.)
  • Eine "Gruppe" ist ein "Künstler", dem mehr als ein "Darsteller" zugewiesen ist.
    (Bei zwei oder mehr untergeordneten Datensätzen in der Mitgliedschaftstabelle ist die Künstler-ID als Fremdschlüssel zugewiesen.)

Wenn ein Teil der Geschäftslogik darin besteht, zwischen Artist-Elementen zu unterscheiden, die Solo oder Group sind, können wir in SQL Abfragen für Künstlerzeilen mit nur einer Zeile durchführen. Mitgliedschaftstabelle gegenüber solchen mit mehreren. In der Praxis ist es jedoch wahrscheinlich sinnvoll, diese Informationen zu denormalisieren, indem:

  • Hinzufügen eines "Solo / Group" -Booleschen Werts zum Künstlertisch und…
  • Erzwingen Sie diese Einzel- / Mehrfachmitgliedschaft in den Apps.

Wenn das Ziel der Frage darin bestand, diese Unterscheidung zwischen Solo und Gruppe innerhalb der Datenbankstruktur (oder ERD) durchzusetzen, bin ich gescheitert. Ich hoffe jedoch, dass sich diese Antwort als interessant und nützlich erweist.

Basil Bourque
quelle
Sehr gute Perspektive
Pmpr
2

Die Antwort von MDCCL ist eine hervorragende Zusammenfassung der Konzepte hinter Superklasse / Unterklasse oder Generalisierung / Spezialisierung, wie sie auf EERD-Ebene dargestellt werden.

Diese Antwort soll auf drei Entwurfsmuster oder -techniken hinweisen, die es wert sind, zu wissen, wann es an der Zeit ist, die EERD in einen relationalen Entwurf umzuwandeln, der auf definierten Tabellen mit definierten Spalten basiert.

Hier sind die drei:

  • Einzelklassenvererbung
  • Vererbung der Klassentabelle
  • Gemeinsamer Primärschlüssel

Die ersten beiden sind Alternativen, eine ist gut für einfache Fälle, in denen fast alle Daten zur Oberklasse gehören. Die zweite ist komplizierter, funktioniert jedoch möglicherweise besser, wenn sich viele Daten auf die verschiedenen Unterklassen beziehen. Das Wort "Vererbung" wird verwendet, um anzuzeigen, dass das Design einen Teil der Ausdruckskraft bietet, die die Vererbung in einem Objektmodell bieten würde.

Der gemeinsam genutzte Primärschlüssel ist eine Technik, mit der die Einträge in den Unterklassentabellen eine Identität erhalten können, indem sie die Identität des entsprechenden Eintrags in der Oberklassentabelle "erben".

In SO gibt es drei Tags mit diesen Namen. Die Registerkarte "Info" unter jedem Tag enthält eine Beschreibung, und unter den Tags sind viele Fragen zusammengefasst.

Es gibt auch viele Websites, auf denen diese Techniken vorgestellt werden. Ich empfehle die von Martin Fowler. Ich mag die Art, wie er es präsentiert. Hier sind einige Webseiten:

Single Table Inheritance Class Tabellenvererbung

Walter Mitty
quelle