Zgodnie z moją interpretacją twoich specyfikacji chcesz znaleźć metodę implementacji dwóch różnych (ale połączonych ) struktur podtypów .
Aby objaśnić podejście do realizacji wspomnianego zadania, dodam do omawianego scenariusza dwa klasyczne typy hipotetycznych typów , które nazywamy Fooi Bar, które szczegółowo omówię poniżej.
Zasady biznesowe
Oto kilka stwierdzeń, które pomogą mi stworzyć model logiczny:
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
Model logiczny
Następnie wynikowy model logiczny IDEF1X [1] pokazano na rysunku 1 (można go również pobrać z Dropbox jako plik PDF ):
Dodatek Foo and Bar
Nie dodałem Foo i Barżeby model wyglądał lepiej, ale żeby był bardziej wyrazisty. Uważam, że są one ważne z następujących powodów:
Ponieważ Ai Bdzielę się nazwanym atrybutem E, ta funkcja sugeruje , że są to typy podobieństwa odrębnego (ale pokrewnego) rodzaju pojęcia , zdarzenia , osoby , miary itp., Które przedstawiłem za pomocą Bartypu podrzędności, który z kolei jest rodzaj podobieństwa Foo, który posiadaD atrybut na górze hierarchii.
Ponieważ Cdzieli tylko jeden atrybut z pozostałymi omawianymi typami bytu, tj. DAspekt ten sugeruje , że jest to rodzaj podobieństwa innego rodzaju koncepcji , zdarzenia , osoby , pomiaru itp., Dlatego przedstawiłem tę okoliczność na podstawieFoo Super typu jednostki.
Są to jednak tylko założenia, a ponieważ relacyjna baza danych ma dokładnie odzwierciedlać semantykę określonego kontekstu biznesowego , musisz zidentyfikować i sklasyfikować wszystkie interesujące rzeczy w Twojej konkretnej domenie, abyś mógł dokładnie uchwycić więcej znaczenia .
Ważne czynniki na etapie projektowania
Warto wiedzieć, że odkładając na bok całą terminologię, wyłączny klaster typu podtyp jest zwykłym związkiem. Opiszmy sytuację w następujący sposób:
- Każde wystąpienie wyłącznego rodzaju podrzędności jest powiązane tylko z jednym dopełnieniem typu podległości .
Tak więc w tych przypadkach istnieje zgodność (lub liczność) jeden do jednego (1: 1).
Jak wiadomo z poprzednich postów, atrybut dyskryminujący (kolumna, gdy jest zaimplementowany) odgrywa nadrzędną rolę podczas tworzenia powiązania tego rodzaju, ponieważ wskazuje on poprawną instancję podtypu, z którą połączony jest nadtyp . migracja z klucz podstawowy z (i) supertypem do (ii) podtypy również pierwszorzędne znaczenie.
Betonowa struktura DDL
A potem napisałem strukturę DDL opartą na modelu logicznym przedstawionym powyżej:
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)
);
Dzięki tej strukturze unikasz przechowywania znaków NULL w tabelach podstawowych (lub relacjach ), co wprowadziłoby niejednoznaczność do bazy danych.
Uczciwość, spójność i inne względy
Po wdrożeniu bazy danych należy upewnić się, że (a) każdy wyłączny wiersz nadtypu jest zawsze uzupełniany przez odpowiedni odpowiednik podtypu, a z kolei gwarantuje, że (b) taki wiersz podtypu jest zgodny z wartością zawartą w kolumnie dyskryminatora nadtypu . Dlatego bardzo wygodnie jest stosować ACID TRANSACTIONS, aby upewnić się, że warunki te są spełnione w bazie danych.
Nie należy rezygnować z logicznej solidności, samoekspresji i dokładności bazy danych, są to aspekty, które zdecydowanie sprawiają, że baza danych jest bardziej solidna.
Dwie wcześniej opublikowane odpowiedzi już zawierają istotne punkty, które z pewnością warto wziąć pod uwagę przy projektowaniu, tworzeniu i zarządzaniu bazą danych i jej aplikacjami.
Pobieranie danych za pomocą definicji VIEW
Można skonfigurować niektóre widoki, które łączą kolumny różnych grup podtypów i typów , dzięki czemu można pobrać dostępne dane bez, np. Pisania za każdym razem niezbędnych klauzul JOIN. W ten sposób możesz z łatwością WYBIERAĆ bezpośrednio Z WIDOKU ( zależność pochodna lub tabela ).
Jak widać, „Ted” Codd był niewątpliwie genialny. Narzędzia, które zapisał, są dość mocne i eleganckie, i oczywiście są dobrze zintegrowane ze sobą.
Powiązane zasoby
Jeśli chcesz przeanalizować obszerną bazę danych, która obejmuje relacje nadtyp-podtyp, możesz znaleźć niezwykłe odpowiedzi zaproponowane przez @PerformanceDBA na następujące pytania dotyczące przepełnienia stosu:
Uwaga
1. Definicja integracji dla modelowania informacji ( IDEF1X ) jest wysoce zalecaną techniką modelowania danych, która została ustanowiona jako standard w grudniu 1993 r. Przez Narodowy Instytut Norm i Technologii Stanów Zjednoczonych ( NIST ). Jest solidnie oparty na (a) wczesnym materiale teoretycznym autorstwa dr EF Codda; od (b) do związków encji świetle danych, opracowanych przez dr PP Chen ; a także w (c) Logical Database Design Technique, stworzonej przez Roberta G. Browna. Warto zauważyć, że IDEF1X został sformalizowany za pomocą logiki pierwszego rzędu.