Частина сценарію, з якою вас плутають, може бути змодельована класичною конструкцією під назвою структура супертипу-підтипу 1 .
Я (1) введу кілька відповідних попередніх ідей, (2) докладно розповім, як я б окреслив - на концептуальному рівні - бізнес-контекст, що розглядається, і (3) надати додатковий пов'язаний матеріал - наприклад, відповідне представлення логічного рівня через SQL -DDL-декларації - наступним чином.
Вступ
Така структура має місце тоді, коли в заданому бізнес-середовищі існує кластер типів сутностей, в межах якого супертип має одне або більше властивостей (або атрибутів), які поділяються рештою типів сутності в кластері, тобто , підтипи . Кожен підтип має, у свою чергу, певний набір властивостей, застосовний лише до себе.
Супертипні підтипи кластерів можуть бути двох видів:
Ексклюзивний . Приходить тоді, коли екземпляр типу надхідності завжди повинен мати один і лише один підтип підтипу; отже, потенційні підтипи, про які йдеться, взаємовиключні . Це такий, який стосується вашого сценарію.
Типовий випадок, коли виникає ексклюзивний підтип підтипу - це бізнес-сфера, де і Організація, і Людина вважаються юридичними сторонами , як, наприклад, у ситуації, розглянутий у цій серії повідомлень .
Невиключний . Уявляє себе , коли супертіп екземпляр може бути доповнені кілька підтипом входжень , кожен з яких змушений бути різної категорії .
Приклад подібного типу підтипу-супертипу розглядається в цих публікаціях .
Примітки : Варто зазначити, що структури підтипу підтипу - як елементи концептуального характеру - не належать до конкретних теоретичних рамок управління даними, будь то реляційні, мережеві або ієрархічні, кожна з яких пропонує окремим структурам представляти концептуальні елементи.
Також доречно зазначити, що хоч кластери підтипів підтипу мають певну схожість з успадкуванням об'єктно-орієнтованого прикладного програмування (OOP) та поліморфізмом , вони насправді є різними пристроями, оскільки вони служать різним цілям. У концептуальній моделі бази даних - яка повинна представляти аспекти реального світу - йдеться про структурні особливості з метою опису інформаційних потреб, тоді як у поліморфізмі та успадкуванні OOP, серед іншого, є одна (а) ескізи та (б) реалізація обчислювальних та поведінкових характеристик. , аспекти, які, безумовно, належать до проектування та програмування програми.
Крім того, окремий клас OOP - який є компонентом програми програми - не обов'язково повинен "відображати" структуру окремого типу об'єкта, що належить до концептуального рівня бази даних. У цьому відношенні прикладний програміст може, як правило, створювати, наприклад, один єдиний клас, який "поєднує" всі властивості двох (або більше) різних типів суті понятійного рівня, і такий клас може також включати обчислювані властивості.
Використання конструкцій взаємозв'язку сутності для представлення концептуальної моделі із структурами супертипу та підтипу
Ви попросили створити діаграму взаємозв'язків між сутністю (ERD для стислості), але, незважаючи на те, що це надзвичайна платформа для моделювання, оригінальний метод - запроваджений доктором Пітером Пін-Шаном Чен 2 - не забезпечив достатньо конструкцій для представлення сценаріїв подібного типу обговорювали з точністю, якої потрібна концептуальна модель належної бази даних.
Отже, необхідно було зробити деякі розширення до зазначеного методу, ситуація, яка дала б результат у розробці підходу, який сприяє створенню вдосконалених діаграм взаємозв'язків із сутністю (EERD), які, природно, збагатили початкову техніку діаграмування новими виразними характеристиками . Однією з таких характеристик є саме можливість зображення супертипових структур.
Моделювання вашого контексту, що цікавить
Ілюстрація, показана на рисунку 1, - це EERD (використовуючи символи, подібні символам, запропонованим Рамесом А. Ельмасрі та Шамкант Б. Наватхе 3 , які називають такі структури як суперклас / підклас ), де я моделював бізнес-домен, який ви описуєте, враховуючи всі технічні характеристики. Він також доступний у вигляді PDF, який можна завантажити з Dropbox .
Як ви бачите на вищезгаданій діаграмі, обидва Groupі SoloPerformerвідображаються як ексклюзивні підтипи типу Artistнадхідності:
Опис схеми
Щоб розпочати опис ЗНО, важливо вказати, що ваше речення
- "Виконавець повинен бути або групою, або SoloPerformer (але не обидва)"
пов'язане з непересічністю та повнотою аспектів кластеру супертипу та підтипу.
Неуважність
Особливість нерозбірливості особливо важлива, оскільки саме тут вступає в дію «або частина», яку ви згадали, через те, що анк Artistповинен бути або одним екземпляром підтипу, або іншим, який я вказав у EERD через малий коло, що містить літеру "d", конструкцію, яка отримує ім'я правила, що не перетинається .
Коли супертип може бути доповнений одним або декількома можливими підтипами, ця точка повинна бути виражена невеликим колом, що містить етикетку з літерою “o”, символом, що називається правилом перекриття .
Властивість дискримінанта
Також в межах коефіцієнта нерозбірливості цієї асоціації супертипів-підтипів варто приділити пильну увагу Artist.Typeвластивості, оскільки вона виконує в цій структурі дуже важливе завдання: вона функціонує як дискримінатор підтипу . Його називають таким чином, оскільки саме властивість вказує на винятковий вид підтипу, з яким пов'язаний конкретний екземпляр Artist.
У випадках неексклюзивних кластерів використання властивості дискримінатора є непотрібним, оскільки певний супертип може мати кілька підтипів як доповнення (як викладено вище).
Загальне правило спеціалізації та повнота
Вимога, яка передбачає, що кожен Artistзавжди повинен мати додатковий екземпляр підтипу, пов'язана з повнотою, характерною для цього кластера. Це окреслено за допомогою правила загальної спеціалізації , продемонстрованого символом подвійної лінії, що з'єднує (а) Artistсупертип з (b) конструкцією правила, що перебуває у суперечці.
Зв'язок груп з сольними виконавцями
Оцінювання речень
- " Група складається з одного або декількох SoloPerformers "
і
- " SoloPerformer може бути членом багатьох груп або немає групи ",
можна визнати, що обидва підтипи беруть участь у об'єднанні (або відношенні) багато-багато-багато (M: N), яке я представляв із діамантоподібної коробки, позначеної як Group-SoloPerformer.
Якщо він буде реалізований у реляційній базі даних як базова таблиця, цей компонент був би дуже корисним для отримання (тобто для проведення обчислення) загальної Numberсуми, SoloPerformersщо складається з конкрету Group(одна з вимог, яку ви вказали).
Асоціація між сольними виконавцями та інструментами
Положення
- "SoloPerformer […] може грати на одному або декількох інструментах"
дозволяє нам зробити висновок, що в той же час,
- "Інструмент грає нуль, один або кілька SoloPerformers".
Таким чином, це ще один приклад асоціації M: N, і я використав фігуру у формі ромба, призначену SoloPerformer-Instrumentдля викриття.
Додатковий матеріал
Для розширення сфери структур підтипових підтипів я збираюся включити ще два ресурси, тобто
діаграма IDEF1X 4, представлена на рисунку 2 ( і ви також можете завантажити її з Dropbox як PDF ), що ілюструє виразні можливості подібного роду діаграм щодо бізнес-домену, про який йдеться; і
відповідна логічна структура DDL-сховища, що ілюструє, як керувати повним обговорюваним сценарієм завдяки системі управління базами даних SQL.
1. Представлення IDEF1X
Техніка інформаційного моделювання IDEF1X, безумовно, пропонує можливість зображувати структури підтипу підтипу, хоча і з обмеженням: він не надає візуального механізму для визначення того, чи точний кластер має винятковий чи невиключний вид (його "рідні" символи можуть спілкуватися лише повне або неповне визначення всіх можливих типів subentity значущості). На щастя, можна використовувати позначення Інформаційна інженерія (IE) для більш точного відображення цього найважливішого аспекту, користуючись перевагою описової сили стандарту IDEF1X.
У цій техніці головною особливістю вашого питання називається "відносини категоризації", де супертип називається "загальною сутністю", а підтип отримує назву "категорія сутності". Однак я продовжуватиму застосовувати термін супертип-підтип у цій посаді, оскільки (1) його використовував доктор Едгар Френк Кодд, засновник реляційної моделі, (2) він більш відомий і (3) позначення IE є використовується замість "рідного".
Іноземні ключі та кластери підтип-підтипу
Як було продемонстровано, IDEF1X надає ще одну перевагу: засоби для демонстрації визначень FOREIGN KEY (FK), елементів найважливішого значення, якщо практик буде представляти асоціацію підтипу підтипу в реляційній базі даних.
Для того , щоб зобразити такий вид асоціації, властивість PRIMARY KEY (PK) з супертіпа, тобто Artist.ArtistNumber, повинен мігрувати до Groupі SoloPerformer, хоча були виділені два різних ролей імен 5, 6 , GroupNumberі , SoloPerformerNumberвідповідно, з метою підкреслити значення передається у власність в контексті кожного типу subentity.
Окрім того, що вони характеризуються як ПК, властивості Group.GroupNumberта SoloPerformer.SoloPerformerNumberвластивості водночас зображуються як ІНТЕРНЕТНІ КЛЮЧІ (FK), які посилаються на Artist.ArtistNumberвластивість супер-типу PK.
Отже, оскільки кожне SoloPerformerі Groupвиникнення залежать від існування від конкретного Artistекземпляра, ці типи об'єктів беруть участь у ідентифікаційній асоціації, яка набуває чинності шляхом міграції властивостей PK, визначеного у попередніх пунктах.
Іноземні ключі та асоціативні типи сутностей
Діаграма IDEF1X служить також для ілюстрації ФК, які складають ПК, що стосуються двох типів релевантної сутності , тобто, GroupMemberі SoloPerformerInstrument; перший з'єднує два підтипи, а другий пов'язує підтип із незалежним типом сутності, тобто Instrument.
2. Експозиція логічних декларацій SQL-DDL
Як було пояснено раніше, структура підтипу підтипу - це засіб вираження певних видів концептуалізацій, що стосуються бізнес-домену щодо інформаційних вимог, які, в свою чергу, можуть бути представлені в базі даних за допомогою чітких конструкцій, які повинні відповідати структурам, запропонованим конкретним теоретична парадигма (будь то реляційна, мережева чи ієрархічна) з наступною системою управління базами даних, що використовується дизайнером.
Однією з безлічі переваг реляційної парадигми є те, що вона дозволяє представляти інформацію в її природній структурі, а найпопулярнішими наближеннями до систем, запропонованих в реляційній теорії, є різні системи управління базами даних SQL.
Отже, ось нарешті, ось декілька зразкових висловлювань DDL - включаючи (а) схеми базових таблиць разом з (b) деякі відповідні обмеження - які на логічному рівні абстрагування представляють вищезазначене поняття концептуального моделювання:
--
--
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)
);
--
--
Міркування щодо цілісності та послідовності даних
Відповідно до всього, що було раніше роз'яснено, дизайнер повинен гарантувати, що кожен рядок "супертипу" постійно доповнюється його супровідним "підтипом" аналога і, у свою чергу, переконатися, що зазначений рядок "підтипу" сумісний зі значенням міститься у колонці «дискримінатор» супертипу.
Було б дуже практично та елегантно застосовувати зазначені обставини декларативно (як це пропонує реляційна рамка), але, на жаль, жодна з основних платформ SQL не забезпечила відповідних механізмів для цього (наскільки я знаю). Тому дуже зручно застосовувати КИСЛОТНІ ПЕРЕВАГИ, щоб ці умови завжди виконувалися в базі даних (інший варіант - використовувати ТРІГЕРИ, але вони, як правило, роблять речі неохайними).
Міркування щодо отримання даних
Одним з головних аспектів реляційної моделі є те, що вона розглядає отримання даних як найважливіший фактор управління даними. Відповідно, це полегшує створення (a) базових відносин - або базових таблиць у SQL, як показано в операторах DDL вище - і (b) похідних відносин - похідних таблиць у SQL, тобто тих, що оголошуються за допомогою dint операцій SELECT, які можуть бути зафіксовано як погляди на подальшу експлуатацію—.
Таким чином, можна оголосити вигляд, який збирає "повні" точки даних групи :
CREATE VIEW FullGroup AS
SELECT G.GroupNumber,
A.Name,
A.CreatedDateTime,
G.FormationDate
FROM Artist A
JOIN MyGroup G
ON G.GroupNumber = A.ArtistNumber;
І інший погляд, який поєднує "повний" фрагмент інформації 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;
Таким чином, дуже легко маніпулювати (декларативно) усіма істотними даними через той самий пристрій логічного рівня, тобто відношення чи таблицю (будь то базовою чи похідною). Очевидно, що використання поглядів є більш ефективним, коли типи концептуальних сутностей, представлені у реляційній базі даних, мають більше цікавих властивостей, але це можливо проілюструвати цим сценарієм.
Список літератури
1 Codd, EF (грудень 1979). Розширення реляційної моделі бази даних для отримання більш значущого значення , трансакцій ACM в системах баз даних , том 4, випуск 4 (с. 397-434). Нью-Йорк, штат Нью-Йорк, США.
2 Чень, ПП (березень 1976 р.). Модель відносин між особами - до єдиного перегляду даних , транзакцій ACM на системах баз даних - Спеціальний випуск: Доповіді Міжнародної конференції з дуже великих баз даних: 22–24 вересня 1975 р., Фреймінгем, МА , Том 1, випуск 1 (с. . 9-36). Нью-Йорк, штат Нью-Йорк, США.
3 Elmasri, R & Navathe, SB (2003). Основи систем баз даних , четверте видання. Аддісон-Уеслі Longman Publishing Co., Inc. Бостон, Массачусетс, США.
4 Національний інститут стандартів і технологій (США) [NIST] (грудень 1993). Визначення інтеграції для інформаційного моделювання (IDEF1X), Публікація Федеральних стандартів обробки інформації , Том 184. США.
5 Codd, EF (червень 1970). Реляційна модель даних для великих спільних банків даних , комунікації ОСБ, Том 13, випуск 6 (стор. 377-387). Нью-Йорк, штат Нью-Йорк, США.
6 Див. Посилання 4
