Часть сценария, с которой вы путаетесь, может быть смоделирована с помощью классической конструкции, называемой структурой supertype-subtype 1 .
Я (1) представлю некоторые соответствующие предварительные идеи, (2) подробно опишу, как я бы очертил - на концептуальном уровне - рассматриваемый бизнес-контекст, и (3) предоставлю дополнительный связанный материал - например, соответствующее представление логического уровня через SQL -DDL декларации - следующим образом.
Вступление
Структура такого рода имеет место, когда в данной бизнес-среде существует кластер типов сущностей, внутри которого супертип имеет одно или несколько свойств (или атрибутов), которые совместно используются остальными типами сущностей в кластере, т.е. , то подтипы . Каждый подтип , в свою очередь, имеет определенный набор свойств, которые применимы только к нему.
Кластеры супертип-подтип могут быть двух видов:
Exclusive . Происходит, когда экземпляр типа superrentity должен всегда иметь один и только один аналог подтипа; следовательно, потенциальные вхождения подтипа, о которых идет речь, являются взаимоисключающими . Это тот тип, который относится к вашему сценарию.
Типичным случаем, когда возникает исключительный подтип супертипа, является бизнес-сфера, в которой и Организация, и Лицо считаются Юридическими сторонами , как в ситуации, рассмотренной в этой серии публикаций .
Неисключительный . Представляется, когда экземпляр супертипа может быть дополнен множеством вхождений подтипа , каждый из которых вынужден относиться к другой категории .
Пример такого типа супертипа-подтипа рассматривается в этих постах .
Примечания : Стоит отметить, что структуры подтипов супертипов, являющиеся элементами концептуального характера, не относятся к конкретной теоретической структуре управления данными, будь то реляционная, сетевая или иерархическая, каждая из которых предлагает конкретные структуры для представления концептуальных элементов.
Также уместно указать, что хотя кластеры супертип-подтип имеют определенное сходство с наследованием и полиморфизмом объектно-ориентированного прикладного программирования (ООП) , они на самом деле являются различными устройствами, поскольку они служат различным целям. В концептуальной модели базы данных, которая должна представлять аспекты реального мира, каждый имеет дело со структурными особенностями для описания информационных требований, тогда как в ООП-полиморфизме и наследовании, среди прочего, один (а) делает наброски и (б) реализует вычислительные и поведенческие характеристики аспекты, которые, безусловно, относятся к разработке и программированию прикладных программ.
Кроме того, отдельный класс ООП, являющийся компонентом прикладной программы, не обязательно должен «отражать» структуру отдельного типа сущности, который принадлежит концептуальному уровню имеющейся базы данных. В этом отношении программист приложения может, как правило, создавать, например, один единственный класс, который «объединяет» все свойства двух (или более) разных типов сущностей концептуального уровня, и такой класс также может включать в себя вычисляемые свойства.
Использование конструкций отношения сущностей для представления концептуальной модели со структурами супертип-подтип
Вы запросили диаграмму сущности-отношения (ERD для краткости), но, несмотря на то, что, будучи экстраординарной платформой моделирования, оригинальный метод, представленный доктором Питером Пин-Шаном Ченом 2 , не предоставил достаточно конструкций для представления сценариев подобного рода. обсуждается с точностью, необходимой для концептуальной модели базы данных.
Следовательно, необходимо было сделать некоторые расширения для указанного метода, что привело к разработке подхода, который помогает в создании улучшенных диаграмм отношений сущностей (EERD), которые, естественно, обогатили первоначальный метод построения диаграмм новыми выразительными характеристиками. , Одной из таких характеристик является, в частности, возможность изображения структур подтипа супертипа.
Моделирование вашего контекста интересов
Иллюстрация, показанная на рисунке 1, представляет собой EERD (с использованием символов, аналогичных символам, предложенным Рамезом А. Эльмасри и Шамкантом Б. Навате 3 , которые называют такие структуры как суперкласс / подкласс ), где я смоделировал бизнес-область, которую вы описываете, учитывая все технические характеристики. Он также доступен в формате PDF, который можно загрузить с Dropbox .
Как вы можете видеть на вышеупомянутой диаграмме, оба Groupи SoloPerformerотображаются как эксклюзивные подтипы типа Artistsuperrentity:
Описание схемы
Чтобы начать описание EERD, важно указать, что ваше предложение
- «Исполнитель должен быть либо группой, либо SoloPerformer (но не обоими)»
связан с аспектами дизъюнктности и полноты рассматриваемого кластера супертип-подтип.
Дизъюнктность
Особенность дизъюнктивности особенно важна, потому что именно здесь «или часть», которую вы упомянули, вступает в игру, потому что an Artistдолжен быть либо одним экземпляром подтипа, либо другим, который я указал в EERD через маленький круг, содержащий букву «d», конструкцию, которая получает имя непересекающегося правила .
Когда супертип может быть дополнен одним или несколькими из его возможных подтипов, эта точка должна быть выражена маленьким кружком с меткой с буквой «о», символом, называемым правилом перекрытия .
Свойство дискриминатора
Также в рамках фактора дизъюнктности этой ассоциации супертип-подтип стоит обратить пристальное внимание на это Artist.Typeсвойство, так как оно выполняет очень важную задачу в этой схеме: оно функционирует как дискриминатор подтипа . Он назван таким образом, поскольку это свойство указывает на исключительный вид подтипа, с которым Artistсвязан конкретный экземпляр объекта .
В случаях неэксклюзивных кластеров использование свойства дискриминатора излишне, поскольку определенный супертип может иметь несколько подтипов в качестве дополнений (как было сказано выше).
Общее правило специализации и полнота
Требование, которое предусматривает, что каждый Artistдолжен всегда иметь дополнительный экземпляр подтипа, связано с характеристикой полноты этого кластера. Это очерчивается с помощью правила полной специализации , демонстрируемого через символ двойной линии, соединяющий (a) 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свойства, в то же время, изображенном в качестве внешних ключей (ФКС) , которые делают ссылку Artist.ArtistNumber, свойство супертипом PK.
Итак, поскольку каждое SoloPerformerи Groupвхождение зависит от существования конкретного Artistэкземпляра, эти типы сущностей участвуют в идентифицирующей ассоциации, которая вступает в силу посредством процесса миграции свойства PK, описанного в предыдущих абзацах.
Внешние ключи и типы ассоциативных объектов
Диаграмма IDEF1X также служит для иллюстрации FK, которые составляют PK двух типов релевантных ассоциативных объектов, т. Е. GroupMemberИ SoloPerformerInstrument; первый соединяет два подтипа, а второй один связывает подтип с независимым типом объекта, то есть Instrument.
2. Описательное SQL-DDL логическое объявление
Как объяснялось ранее, структура подтипа супертипа - это средство выражения определенных видов концептуализаций, специфичных для бизнес-предметной области, касающихся информационных требований, которые, в свою очередь, могут быть представлены в базе данных с помощью различных конструкций, которые должны соответствовать тем, которые предлагаются конкретным теоретическая парадигма (будь то реляционная, сетевая или иерархическая), за которой следует система управления базой данных, используемая разработчиком.
Одним из многочисленных преимуществ реляционной парадигмы является то, что она позволяет представлять информацию в ее естественной структуре, и наиболее популярными приближениями к системам, предлагаемым в теории отношений, являются различные системы управления базами данных SQL.
Итак, наконец, вот несколько примеров операторов DDL, включая (а) схемы базовых таблиц и (б) некоторые соответствующие ограничения, которые представляют на логическом уровне абстракции концептуальное моделирование, рассмотренное выше:
--
--
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 не предоставила подходящих механизмов для этого (насколько я знаю). Следовательно, очень удобно использовать ACID TRANSACTIONS, чтобы эти условия всегда выполнялись в базе данных (другой вариант - использовать TRIGGERS, но они, как правило, делают вещи неопрятными).
Вопросы получения данных
Одним из основных аспектов реляционной модели является то, что она рассматривает получение данных как первостепенный фактор в управлении данными. В соответствии с этим он облегчает создание (а) базовых отношений - или базовых таблиц в SQL, как показано в приведенных выше инструкциях DDL, - и (b) производных отношений - производных таблиц в SQL, т. Е. Тех, которые объявлены с помощью операций 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 Кодд, EF (декабрь 1979). Расширение реляционной модели базы данных для получения большего значения , транзакции ACM в системах баз данных , том 4, выпуск 4 (стр. 397-434). Нью-Йорк, штат Нью-Йорк, США.
2 Чен П.П. (март 1976 г.). Модель сущности-отношения - на пути к унифицированному представлению данных , транзакции ACM в системах баз данных - Специальный выпуск: документы Международной конференции по базам данных очень больших размеров: 22–24 сентября 1975 г., Фрамингем, штат Массачусетс , том 1, выпуск 1 (стр. 9-36). Нью-Йорк, штат Нью-Йорк, США.
3 Elmasri, R & Navathe, SB (2003). Основы систем баз данных , четвертое издание. Addison-Wesley Longman Publishing Co., Inc. Бостон, Массачусетс, США.
4 Национальный институт стандартов и технологий (США) [NIST] (декабрь 1993 г.). Определение интеграции для информационного моделирования (IDEF1X), Публикация федеральных стандартов обработки информации , том 184. США.
5 Кодд, EF (июнь 1970). Реляционная модель данных для крупных совместно используемых банков данных , сообщения ACM , том 13, выпуск 6 (стр. 377-387). Нью-Йорк, штат Нью-Йорк, США.
6 См. Ссылку 4
