Część scenariusza, z którą się mylisz, można modelować za pomocą klasycznej konstrukcji o nazwie struktura typu podtyp 1 .
Przedstawię (1) kilka istotnych wstępnych pomysłów, (2) wyszczególnię, w jaki sposób nakreślę - na poziomie pojęciowym - rozważany kontekst biznesowy, oraz (3) przedstawię dodatkowe powiązane materiały - np. Odpowiednią reprezentację na poziomie logicznym za pośrednictwem SQL -Deklaracje DDL - w następujący sposób.
Wprowadzenie
Struktura tego rodzaju ma miejsce, gdy w danym środowisku biznesowym istnieje klaster typów jednostek, w ramach którego nadtyp ma jedną lub więcej właściwości (lub atrybutów), które są wspólne dla pozostałych typów jednostek w klastrze, tj. , podtypy . Każdy podtyp ma z kolei określony zestaw właściwości, które dotyczą tylko siebie.
Klastry podtypów mogą być dwojakiego rodzaju:
Exclusive . Zdarza się, gdy instancja typu nadrzędność musi zawsze mieć jeden i tylko jeden odpowiednik podtypu; w związku z tym potencjalne występujące podtypy wykluczają się wzajemnie . Ten rodzaj dotyczy twojego scenariusza.
Typowym przypadkiem, w którym powstaje wyłączny podtyp, jest domena biznesowa, w której zarówno Organizacja, jak i Osoba są uważane za strony prawne , tak jak w sytuacji omawianej w tej serii postów .
Niewyłączne . Występuje, gdy instancja nadtypu może być uzupełniona wieloma wystąpieniami podtypu , z których każdy musi być innej kategorii .
Przykład tego rodzaju podtypu omówiono w tych postach .
Uwagi : Warto wspomnieć, że struktury podtypu - będące elementami o charakterze koncepcyjnym - nie należą do określonych ram teoretycznych zarządzania danymi, czy to relacyjnych, sieciowych czy hierarchicznych - z których każda oferuje określone struktury reprezentujące elementy koncepcyjne -.
Warto również zauważyć, że chociaż klastry podtypów są w pewnym stopniu podobne do dziedziczenia obiektowego i polimorfizmu programowania obiektowego (OOP) , to w rzeczywistości są odrębnymi urządzeniami, ponieważ służą różnym celom. W modelu koncepcyjnym bazy danych - który musi odzwierciedlać aspekty świata rzeczywistego - jeden dotyczy cech strukturalnych w celu opisania wymagań informacyjnych , podczas gdy w OOP polimorfizm i dziedziczenie, między innymi, jeden (a) szkice i (b) implementuje cechy obliczeniowe i behawioralne , aspekty, które zdecydowanie należą do projektowania i programowania aplikacji.
Oprócz tego, osoba OOP klasy -being program element tak aplikacji, czy nie koniecznie „lustro” struktury indywidualnego typu jednostki, która należy do pojęciowego poziomie bazy danych pod ręką. W związku z tym programista aplikacji może zazwyczaj tworzyć, np. Jedną pojedynczą klasę, która „łączy” wszystkie właściwości dwóch (lub więcej) różnych typów jednostek na poziomie koncepcyjnym, a taka klasa może również zawierać obliczone właściwości.
Używanie konstrukcji relacja-byt do reprezentowania modelu koncepcyjnego ze strukturami podtyp-podtyp
Poprosiłeś o schemat relacji między bytami (ERD dla zwięzłości), ale chociaż jest niezwykłą platformą modelowania, oryginalna metoda - wprowadzona przez dr. Petera Pin-Shana Chena 2 - nie dostarczyła wystarczającej liczby konstrukcji do przedstawienia scenariuszy tego rodzaju omówione z precyzją wymaganą przez odpowiedni model koncepcyjny bazy danych.
W związku z tym konieczne było wprowadzenie pewnych rozszerzeń tej metody, co zaowocowało opracowaniem podejścia, które pomaga w tworzeniu ulepszonych diagramów relacji między bytami (EERD), które naturalnie wzbogaciły początkową technikę tworzenia diagramów o nowe cechy ekspresyjne . Jedną z tych cech jest właśnie możliwość przedstawienia struktur podtypu.
Modelowanie kontekstu zainteresowania
Ilustracja pokazana na rycinie 1 to EERD (wykorzystująca symbole podobne do tych zaproponowanych przez Rameza A. Elmasri i Shamkanta B. Navathe 3 , którzy określają takie struktury jak nadklasa / podklasa ), w których modelowałem domenę biznesową, którą opisujesz , biorąc pod uwagę wszystkie specyfikacje. Jest również dostępny w formacie PDF, który można pobrać z Dropbox .
Jak widać we wspomnianym schemacie, zarówno Groupi SoloPerformersą wyświetlane jako wyłącznych podtypów Artisttypu superentity:
Opis schematu
Aby rozpocząć opis EERD, ważne jest, aby zaznaczyć, że zdanie
- „An wykonawców muszą być albo Grupę lub SoloPerformer (ale nie obydwa)”
jest związany z aspektami rozłączności i kompletności dostępnego klastra podtypu.
Rozłączność
Funkcja rozłączności jest szczególnie ważne, ponieważ to właśnie tu, gdzie „lub część” które wspomniano wchodzi w grę, ze względu na fakt, że Artistmusi być albo jedno wystąpienie podtypu lub druga, którą określono w EERd przez małe okrąg zawierający literę „d”, konstrukcja, która otrzymuje nazwę reguły rozłącznej .
Gdy nadtyp można uzupełnić o jeden lub więcej jego możliwych podtypów, punkt ten musi być wyrażony małym kółkiem z etykietą z literą „o”, symbolem zwanym regułą nakładania się .
Właściwość dyskryminatora
Również w zakresie współczynnika rozłączności tego skojarzenia nadtyp-podtyp warto zwrócić szczególną uwagę na Artist.Typewłaściwość, ponieważ wykonuje ona bardzo istotne zadanie w tym układzie: działa ona jako dyskryminator podtypu . Nazwano go w ten sposób, ponieważ jest to właściwość wskazująca na wyłączny rodzaj podtypu, z którym Artistodnosi się określone wystąpienie elementu .
W przypadkach niewyłącznych klastrów użycie właściwości dyskryminującej jest niepotrzebne, ponieważ pewien nadtyp może mieć wiele podtypów jako uzupełnień (jak wspomniano powyżej).
Zasada całkowitej specjalizacji i kompletność
Wymóg, zgodnie z którym każdy Artistmusi zawsze mieć dodatkową instancję podtypu, dotyczy właściwości kompletności tego klastra. Wyznacza się to za pomocą reguły całkowitej specjalizacji , wykazanej przez symbol podwójnej linii łączący (a) Artistnadtyp z (b) konstrukcją reguły rozłącznej.
Powiązanie grup z wykonawcami solo
Ocena zdań
- „ Grupa składa się z jednego lub więcej SoloPerformers ”
i
- „ SoloPerformer może być członkiem wielu grup lub nie należeć do żadnej grupy ”,
można rozpoznać, że oba podtypy są zaangażowane w skojarzenie (lub relację) wiele do wielu (M: N), które reprezentowałem za pomocą pudełka w kształcie rombu oznaczonego jako Group-SoloPerformer.
Jeśli realizowane w relacyjnej bazie danych jako podstawy stołu, składnik ten będzie bardzo przydatny do Derive (tj przeprowadzić obliczenia) łącznie Numberz SoloPerformerstym uzupełnić betonem Group(jeden z wymogów, które określić).
Związek między wykonawcami solo a instrumentami
Zastrzeżenie
- „SoloPerformer […] może grać na jednym lub kilku instrumentach”
pozwala nam wnioskować, że jednocześnie
- „Na instrumencie gra zero, jeden lub więcej SoloPerformers”.
Jest to zatem kolejny przykład skojarzenia M: N, a ja użyłem figury w kształcie rombu, SoloPerformer-Instrumentaby go odsłonić.
Dodatkowy materiał
Aby objaśnić zakres struktur typu podtypowego, zamierzam uwzględnić jeszcze dwa zasoby, tj.
schemat IDEF1X 4 przedstawiony na rysunku 2 ( można go również pobrać z Dropbox jako plik PDF ), który ilustruje ekspresyjne możliwości tego rodzaju diagramów dotyczących danej domeny biznesowej; i
odpowiednia struktura logiczna DDL ekspozytora, która ilustruje sposób zarządzania całym omawianym scenariuszem za pomocą systemu zarządzania bazą danych SQL.
1. Reprezentacja IDEF1X
Technika modelowania informacji IDEF1X z pewnością oferuje możliwość przedstawiania struktur podtypu, jednak z ograniczeniem: nie zapewnia wizualnego mechanizmu wskazującego, czy precyzyjny klaster jest wyłącznym, czy też niejednoznacznym (jego „rodzime” symbole mogą się komunikować kompletny lub niekompletny identyfikacja wszystkich możliwych typów subentity istotności). Na szczęście można zastosować notację inżynierii informatycznej (IE), aby dokładniej pokazać ten najważniejszy aspekt, korzystając jednocześnie z mocy opisowej standardu IDEF1X.
W tej technice główną cechą twojego pytania jest „relacja kategoryzacji”, w której nadtyp jest nazywany „bytem ogólnym”, a podtyp otrzymuje nazwę „bytu kategorii”. Będę jednak nadal stosować termin „ podtyp” w tym poście, ponieważ (1) użył go dr Edgar Frank Codd, twórca modelu relacyjnego, (2) jest bardziej znany i (3) notacja IE to używane zamiast „rodzimego”.
Klucze obce i klastry podtypów
Jak wykazano, IDEF1X zapewnia dodatkową korzyść: środki do wyświetlania definicji KLUCZA OBCEGO (FK), elementów o pierwszorzędnym znaczeniu, jeśli osoba ćwicząca będzie reprezentować skojarzenie typu podtypu w relacyjnej bazie danych.
W celu sportretowania takiego rodzaju stowarzyszenia, klucz podstawowy (PK) własność supertypem, to znaczy Artist.ArtistNumber, musi przenieść się Groupi SoloPerformer, mimo że został przydzielony dwóch różnych nazw ról 5, 6 , GroupNumberi SoloPerformerNumberodpowiednio, w celu podkreślenia znaczenie przekazywane przez właściwość w kontekście każdego rodzaju subentity.
Oprócz scharakteryzowania jako PK, właściwości Group.GroupNumberi SoloPerformer.SoloPerformerNumbersą jednocześnie przedstawione jako KLUCZY ZAGRANICZNE (FK), które odnoszą się do Artist.ArtistNumberwłaściwości PK nadtypu.
Tak więc, ponieważ każda SoloPerformeri Groupwystępowanie jest istnienie zależne od dokładnego Artistprzykład, tego rodzaju jednostka zaangażowany w identyfikującego związku , które ma wpływ na zasadzie procesu migracji właściwości PK zakreślonym w poprzednich akapitach.
Klucze obce i typy jednostek stowarzyszonych
Diagram IDEF1X służy również do zilustrowania FK, które składają się z PK dwóch typów istotnej jednostki stowarzyszonej , tj. GroupMemberI SoloPerformerInstrument; pierwszy łączy dwa podtypy, a drugi łączy podtyp z niezależnym typem jednostki, tj Instrument.
2. Deklaracyjne logiczne deklaracje SQL-DDL
Jak wyjaśniono wcześniej, struktura podtypu jest sposobem wyrażenia pewnych rodzajów specyficznych dla domeny biznesowej koncepcji dotyczących wymagań informacyjnych, które z kolei mogą być reprezentowane w bazie danych za pomocą odrębnych konstrukcji, które muszą odpowiadać tym, które oferuje konkretna teoretyczny paradygmat (relacyjny, sieciowy lub hierarchiczny), a następnie projektant korzysta z systemu zarządzania bazą danych.
Jedną z wielu zalet paradygmatu relacyjnego jest to, że pozwala on reprezentować informacje w jego naturalnej strukturze, a najbardziej popularnymi przybliżeniami systemów zaproponowanych w teorii relacyjnej są różne systemy zarządzania bazami danych SQL.
Na koniec oto kilka przykładowych instrukcji DDL - w tym (a) schematy tabel podstawowych wraz z (b) niektórymi istotnymi ograniczeniami - które reprezentują, na logicznym poziomie abstrakcji, modelowanie koncepcyjne potraktowane powyżej:
--
--
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)
);
--
--
Uwagi dotyczące integralności i spójności danych
W zgodzie ze wszystkim, co zostało wcześniej wyjaśnione, projektant musi zagwarantować, że każdy wiersz „nadtypu” jest zawsze uzupełniany przez towarzyszący mu odpowiednik „podtypu”, a z kolei upewnić się, że wspomniany wiersz „podtypu” jest zgodny z wartością zawarty w kolumnie „dyskryminator” nadtypu.
Byłoby to bardzo praktyczny i elegancki egzekwować stwierdzono okoliczności deklaratywnie (jak proponuje ramy relacyjny), ale, niestety, żaden z głównych platform SQL dostarczył odpowiednie mechanizmy, aby to zrobić (o ile wiem). Dlatego bardzo wygodne jest stosowanie TRANSAKCJI KWASOWYCH , aby te warunki były zawsze spełnione w bazie danych (inną opcją byłoby użycie WYZWALACZE, ale zwykle powodują one nieporządek).
Uwagi dotyczące wyprowadzania danych
Jednym z głównych aspektów modelu relacyjnego jest to, że bierze pod uwagę wyprowadzanie danych za najważniejszy czynnik w zarządzaniu danymi. Zgodnie, ułatwia tworzenie (a) bazowych stosunki -or bazowe tabele w SQL, jak pokazano na DDL stwierdzenia wyżej, oraz (b) wywodzące się stosunki - pochodzące tabel w SQL, to znaczy te, które są dzięki czynności SELECT, który może być naprawione jako widoki do dalszego wykorzystania—.
Można więc zadeklarować widok, który gromadzi „pełne” punkty danych grupy :
CREATE VIEW FullGroup AS
SELECT G.GroupNumber,
A.Name,
A.CreatedDateTime,
G.FormationDate
FROM Artist A
JOIN MyGroup G
ON G.GroupNumber = A.ArtistNumber;
Oraz inny widok łączący „pełne” informacje SoloPerformer :
CREATE VIEW FullSoloPerformer AS
SELECT SP.SoloPerformerNumber,
A.Name,
A.CreatedDateTime,
SP.BirthDate
FROM Artist A
JOIN SoloPerformer SP
ON SP.SoloPerformerNumber = A.ArtistNumber;
W ten sposób bardzo łatwo można manipulować - deklaratywnie - wszystkimi znaczącymi danymi za pomocą tego samego urządzenia na poziomie logicznym, tj. Relacji lub tabeli (bazowej lub pochodnej). Oczywiście użycie widoków jest bardziej skuteczne, gdy typy jednostek pojęciowych reprezentowane w relacyjnej bazie danych mają więcej interesujących właściwości, ale jest to możliwość, którą warto zilustrować za pomocą obecnego scenariusza.
Bibliografia
1 Codd, EF (grudzień 1979). Rozszerzenie modelu relacyjnego bazy danych, aby uchwycić więcej znaczenia , transakcje ACM w systemach baz danych , tom 4, wydanie 4 (str. 397-434). Nowy Jork, NY, USA.
2 Chen, PP (marzec 1976). Model relacji jednostka - w kierunku ujednoliconego widoku danych , transakcje ACM w systemach baz danych - wydanie specjalne: Artykuły z międzynarodowej konferencji na temat bardzo dużych baz danych: 22–24 września 1975 r., Framingham, MA , tom 1, wydanie 1 (str. 9–36). Nowy Jork, NY, USA.
3 Elmasri, R & Navathe, SB (2003).Podstawy systemów baz danych , wydanie czwarte. Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA.
4 National Institute of Standards and Technology (US) [NIST] (grudzień 1993). Definicja integracji dla modelowania informacji (IDEF1X), Federalna publikacja standardów przetwarzania informacji , tom 184. USA.
5 Codd, EF (czerwiec 1970). Relacyjny model danych dla dużych wspólnych banków danych , komunikacja z ACM , tom 13, wydanie 6 (str. 377-387). Nowy Jork, NY, USA.
6 Patrz odnośnik 4
Odpowiedź MDCCL jest doskonałym streszczeniem koncepcji nadklasy / podklasy lub uogólnienia / specjalizacji przedstawionych na poziomie EERD.
Ta odpowiedź ma na celu wskazanie trzech wzorców projektowych lub technik, które warto poznać, kiedy przyjdzie czas na przekształcenie EERD w projekt relacyjny, oparty na zdefiniowanych tabelach ze zdefiniowanymi kolumnami.
Oto trzy:
Dwie pierwsze są alternatywami, jedna jest dobra dla prostych przypadków, w których prawie wszystkie dane dotyczą nadklasy. Drugi jest bardziej skomplikowany, ale może działać lepiej, gdy wiele danych dotyczy kilku podklas. Słowo „Dziedziczenie” jest używane, aby wskazać, że projekt zapewnia taką samą moc ekspresji, jaką dziedzictwo zapewniłoby w modelu obiektowym.
Wspólny klucz podstawowy to technika, dzięki której wpisy w tabelach podklasy mogą uzyskać tożsamość poprzez „dziedziczenie” tożsamości odpowiedniego wpisu w tabeli nadklasy.
Powyżej w SO są trzy tagi o tych nazwach. Karta Informacje pod każdym tagiem zawiera opis, a pod tagami znajduje się wiele pytań.
Istnieje również wiele stron internetowych prezentujących te techniki. Polecam te z Martina Fowlera. Podoba mi się sposób, w jaki to przedstawia. Oto kilka stron internetowych:
Dziedziczenie tabeli pojedynczej klasy
źródło