Nach meiner Interpretation Ihrer Spezifikationen möchten Sie eine Methode finden, um zwei verschiedene (aber zusammenhängende ) Supertyp-Subtyp- Strukturen zu implementieren .
Um einen Ansatz zur Erreichung der oben genannten Aufgabe aufzuzeigen, füge ich dem fraglichen Szenario die beiden klassischen hypothetischen Entitätstypen hinzu, die als Foound bezeichnet werden und auf Bardie ich unten näher eingehen werde.
Geschäftsregeln
Hier sind einige Anweisungen, die mir beim Erstellen eines logischen Modells helfen:
A Foo is either one Bar or one CA Foo is categorized by one FooTypeA Bar is either one A or one CA Bar is classified by one BarType
Logisches Modell
Das resultierende logische IDEF1X [1] -Modell ist in Abbildung 1 dargestellt (und Sie können es auch als PDF von Dropbox herunterladen ):
Der Foo and Bar Zusatz
Ich habe nicht hinzufügen Foound Bardas Modell besser aussehen zu machen, aber es ausdrucksvoller zu machen. Ich halte sie aus folgenden Gründen für wichtig:
Wie Aund Bdas Attribut mit dem Namen teilt E, ist diese Funktion legt nahe , dass sie Sub - Entität Arten eines deutlichen (aber verwandte) Art sind Konzept , Event , Person , Messung usw., die ich mit Hilfe des dargestellten Barsuperentity Typ das wiederum ist Ein Subentity-Typ von Foo, der das DAttribut oben in der Hierarchie enthält.
Da Cnur ein Attribut mit den übrigen diskutierten Entitätstypen gemeinsam ist, dh Ddieser Aspekt unterstellt, dass es sich um einen Subentitätstyp einer anderen Art von Konzept , Ereignis , Person , Messung usw. handelt, habe ich diesen Umstand anhand von dargestellt der Foosuper Entitätstyp.
Dies sind jedoch nur Annahmen, und da eine relationale Datenbank die Semantik eines bestimmten Geschäftskontexts genau widerspiegeln soll , müssen Sie alle interessanten Dinge in Ihrer spezifischen Domäne identifizieren und klassifizieren , damit Sie genau die Bedeutung erfassen können .
Wichtige Faktoren in der Entwurfsphase
Es ist sehr nützlich, sich der Tatsache bewusst zu sein, dass, abgesehen von der Terminologie, ein exklusiver Supertyp-Subtyp-Cluster eine gewöhnliche Beziehung ist. Beschreiben wir die Situation folgendermaßen:
- Jedes Auftreten eines exklusiven Superentitätstyps bezieht sich nur auf ein Subentitätstyp- Komplement.
Somit besteht in diesen Fällen eine Übereinstimmung (oder Kardinalität) von eins zu eins (1: 1).
Wie Sie aus Ihren vorangegangenen Beiträgen wissen, spielt das Diskriminatorattribut (Spalte, sofern implementiert) beim Erstellen einer Assoziation dieser Art eine übergeordnete Rolle , da es die richtige Subtypinstanz angibt, mit der der Supertyp verbunden ist . Die Migration des PRIMARY KEY von (i) dem Supertyp zu (ii) den Subtypen ist ebenfalls von vorrangiger Bedeutung.
Konkrete DDL-Struktur
Und dann habe ich eine DDL-Struktur geschrieben, die auf dem oben dargestellten logischen Modell basiert:
CREATE TABLE FooType -- Look-up table.
(
FooTypeCode CHAR(2) NOT NULL,
Description CHAR(90) NOT NULL,
CreatedDateTime DATETIME NOT NULL,
CONSTRAINT PK_FooType PRIMARY KEY (FooTypeCode),
CONSTRAINT AK_FooType_Description UNIQUE (Description)
);
CREATE TABLE Foo -- Supertype
(
FooId INT NOT NULL, -- This PK migrates (1) to ‘Bar’ as ‘BarId’, (2) to ‘A’ as ‘AId’, (3) to ‘B’ as ‘BId’, and (4) to ‘C’ as ‘CId’.
FooTypeCode CHAR(2) NOT NULL, -- Discriminator column.
D INT NOT NULL, -- Column that applies to ‘Bar’ (and therefore to ‘A’ and ‘B’) and ‘C’.
CreatedDateTime DATETIME NOT NULL,
CONSTRAINT PK_Foo PRIMARY KEY (FooId),
CONSTRAINT FK_from_Foo_to_FooType FOREIGN KEY (FooTypeCode)
REFERENCES FooType (FooTypeCode)
);
CREATE TABLE BarType -- Look-up table.
(
BarTypeCode CHAR(1) NOT NULL,
Description CHAR(90) NOT NULL,
CONSTRAINT PK_BarType PRIMARY KEY (BarTypeCode),
CONSTRAINT AK_BarType_Description UNIQUE (Description)
);
CREATE TABLE Bar -- Subtype of ‘Foo’.
(
BarId INT NOT NULL, -- PK and FK.
BarTypeCode CHAR(1) NOT NULL, -- Discriminator column.
E INT NOT NULL, -- Column that applies to ‘A’ and ‘B’.
CONSTRAINT PK_Bar PRIMARY KEY (BarId),
CONSTRAINT FK_from_Bar_to_Foo FOREIGN KEY (BarId)
REFERENCES Foo (FooId),
CONSTRAINT FK_from_Bar_to_BarType FOREIGN KEY (BarTypeCode)
REFERENCES BarType (BarTypeCode)
);
CREATE TABLE A -- Subtype of ‘Bar’.
(
AId INT NOT NULL, -- PK and FK.
X INT NOT NULL, -- Particular column.
CONSTRAINT PK_A PRIMARY KEY (AId),
CONSTRAINT FK_from_A_to_Bar FOREIGN KEY (AId)
REFERENCES Bar (BarId)
);
CREATE TABLE B -- (1) Subtype of ‘Bar’ and (2) supertype of ‘A’ and ‘B’.
(
BId INT NOT NULL, -- PK and FK.
Y INT NOT NULL, -- Particular column.
CONSTRAINT PK_B PRIMARY KEY (BId),
CONSTRAINT FK_from_B_to_Bar FOREIGN KEY (BId)
REFERENCES Bar (BarId)
);
CREATE TABLE C -- Subtype of ‘Foo’.
(
CId INT NOT NULL, -- PK and FK.
Z INT NOT NULL, -- Particular column.
CONSTRAINT PK_C PRIMARY KEY (CId),
CONSTRAINT FK_from_C_to_Foo FOREIGN KEY (FooId)
REFERENCES Foo (FooId)
);
Mit dieser Struktur vermeiden Sie das Speichern von NULL-Marken in Ihren Basistabellen (oder -relationen ), was zu Mehrdeutigkeiten in Ihrer Datenbank führen würde.
Integrität, Konsistenz und andere Überlegungen
Wenn Sie Ihre Datenbank implementiert haben, müssen Sie sicherstellen, dass (a) jede exklusive Supertyp- Zeile immer durch das entsprechende Subtyp- Gegenstück ergänzt wird und dass (b) diese Subtyp- Zeile mit dem in der Supertyp- Diskriminator- Spalte enthaltenen Wert kompatibel ist . Daher ist es sehr praktisch, ACID TRANSACTIONSzu verwenden, um sicherzustellen, dass diese Bedingungen in Ihrer Datenbank erfüllt sind.
Sie sollten nicht auf die logische Solidität, Selbstausdruckskraft und Genauigkeit Ihrer Datenbank verzichten. Dies sind Aspekte, die Ihre Datenbank entscheidend solider machen.
Die beiden zuvor veröffentlichten Antworten enthalten bereits relevante Punkte, die beim Entwerfen, Erstellen und Verwalten Ihrer Datenbank und ihrer Anwendungsprogramme unbedingt berücksichtigt werden sollten.
Abrufen von Daten über VIEW-Definitionen
Sie können einige Sichten einrichten, die Spalten der verschiedenen Supertype-Subtype- Gruppen kombinieren , damit Sie die vorliegenden Daten abrufen können, ohne z. B. jedes Mal die erforderlichen JOIN-Klauseln zu schreiben. Auf diese Weise können Sie problemlos direkt AUS DER ANSICHT (eine abgeleitete Beziehung oder Tabelle ) von Interesse AUSWÄHLEN.
Wie Sie sehen, war „Ted“ Codd zweifellos ein Genie. Die Werkzeuge, die er hinterlassen hat, sind ziemlich stark und elegant und natürlich gut miteinander integriert.
Ähnliche Resourcen
Wenn Sie eine umfangreiche Datenbank analysieren möchten, die Supertyp-Subtyp-Beziehungen enthält, sind die von @PerformanceDBA vorgeschlagenen außergewöhnlichen Antworten auf die folgenden Stapelüberlauf- Fragen von Nutzen :
Hinweis
1. Integration Definition für Informationsmodellierung ( IDEF1X ) ist eine sehr empfehlenswerte Datenmodellierungstechnik, die als etabliert wurde Standard im Dezember 1993 von den Vereinigten Staaten National Institute of Standards and Technology ( NIST ). Es basiert auf (a) dem frühen theoretischen Material von Dr. EF Codd; zu (b) der Entity-Relationship- Sicht auf Daten, entwickelt von Dr. PP Chen ; und auch auf (c) der Logical Database Design Technique, erstellt von Robert G. Brown. Es ist erwähnenswert, dass IDEF1X mit Hilfe von Logik erster Ordnung formalisiert wurde.