Моделирование сценария, в котором каждый музыкальный исполнитель является либо группой, либо сольным исполнителем

Мне нужно разработать диаграмму сущностных отношений (ERD) для бизнес-контекста, которая включает в себя разметку исполнителей музыки , как я подробнее расскажу ниже.

Описание сценария

  • Исполнитель имеет Имя и должен быть или a Группа или a Solo Performer (но не оба).

  • A Группа состоит из одного или нескольких Solo Performers и имеет Число участников (которые должны быть рассчитаны из количество Solo Performers , составляющее Группа ).

  • A Solo Performer может быть Member для многих групп или no Group и может воспроизведите один или несколько инструментов .

Вопрос

Как создать ERD для представления такого сценария? Я путаюсь с «или» частью этого.

10 голосов | спросил Boshir 16 FebruaryEurope/MoscowbMon, 16 Feb 2015 18:03:18 +0300000000pmMon, 16 Feb 2015 18:03:18 +030015 2015, 18:03:18

1 ответ


14

Часть сценария, с которым вы смешиваетесь, может быть смоделирована с помощью классической конструкции, называемой структурой supertype-subtype 1 .

Я (1) представлю некоторые соответствующие предварительные идеи, (2) подробно расскажу, как бы я определил - на концептуальном уровне - рассматриваемый бизнес-контекст и (3) предоставить дополнительные связанные материалы -eg, соответствующий логический уровень представление через объявления SQL-DDL - следующим образом.

Введение

Структура такого рода имеет место, когда в данной бизнес-среде существует кластер типов , в которых супертип имеет одно или несколько свойств (или атрибуты), которые являются shared остальными типами сущностей в кластере, т. е. подтипами . Каждый подтип имеет, в свою очередь, определенный набор свойств, которые применимы только к себе.

Классы супертипов-подтипов могут быть двух видов:

  • Эксклюзив . Приходит, когда экземпляр экземпляра типа сущности имеет всегда один и только один подтип; поэтому потенциальные вложенные подтипы являются взаимоисключающими . Это относится к вашему сценарию.

    Типичным случаем, в котором возникает подтип эксклюзивного супертипа, является бизнес-домен, в котором рассматриваются как Организация , так и Лицо Юридические стороны , как в ситуации, обсуждаемой в этой серии сообщений .

  • Неэксклюзивным . Представляет собой, когда супертип экземпляр может быть дополнен несколькими подтипами вхождения , каждый из которых вынужден иметь другую категорию .

    Пример такого типа подтипа супертипа рассматривается в этих сообщениях .

Примечания : Следует отметить, что структуры супертипов-подтипов, которые являются элементами концептуального характера, not относятся к конкретной теоретической структуре управления данными, будь то реляционный, сетевой или иерархический, каждый из которых предлагает определенные структуры для представления концептуальных элементов -.

Также полезно отметить, что хотя кластеры супертипа-подтипа имеют некоторое сходство с объектно-ориентированным прикладным программированием (OOP) наследование и полиморфизмом , они на самом деле являются разными устройствами, потому что они служат различным целям. В базе данных концептуальной модели, которая должна представлять аспекты реального мира, речь идет о функциях структурных для описания требований информационных , тогда как в полиморфизме ООП и наследование, среди прочего, один (а) эскизы и (б) реализует характеристики вычислительные и поведенческие , аспекты, которые явно принадлежат к разработке и программированию программ приложений.

Кроме того, отдельный класс OOP , имеющий компонент прикладной программы, not обязательно должен «зеркалировать» структуру отдельного объекта тип, который относится к концептуальному уровню базы данных. В этом отношении программист приложения обычно может создавать, например, один класс, который «объединяет» все свойства двух (или более) разных типов объектов на уровне концептуального уровня, и такой класс может также включать вычисленные свойства.

Использование конструкций сущности-отношения для представления концептуальной модели с структурами супертипа-подтипа

Вы запросили диаграмму сущностей-связей (ERD для краткости), но, будучи необычной платформой моделирования, оригинальный метод - представлен Д-р Питер Пин-Шань Чен 2 - не поставлял достаточное количество конструкций для представления сценариев рассматриваемого вида с той точностью, что правильная базовая концептуальная модель базы данныхтребуется.

Следовательно, необходимо было сделать некоторые расширения для упомянутого метода, что дало результаты в разработке подхода, который помогает в создании улучшенных диаграмм сущностных отношений (EERD), которые, естественно, , обогатил первоначальный метод диаграмм с новыми выразительными характеристиками. Одной из этих характеристик является, в частности, возможность отображения структур супертипа-подтипа.

Моделирование вашего контекста интереса

Иллюстрация, показанная в Рисунок 1 - это EERD (с использованием символов, похожих на предложенные Рамезом А. Эльмасри и Шамкантом Б. Навате 3 , которые относятся к таким структурам как суперкласс /подкласс ), где я смоделировал бизнес-домен, который вы описываете, учитывая все спецификации , Он также доступен как PDF, который может быть загружен из Dropbox .

Как вы можете видеть на вышеупомянутой диаграмме, оба Group и SoloPerformer отображаются как эксклюзивные подтипы типа Artist:

Музыкальная картинка с улучшенной структурой сущностей

Описание схемы

Чтобы начать описание EERD, важно указать, что ваше предложение

  • "Исполнитель должен быть или группой или для SoloPerformer (но не для обоих)"

связан с непересекающимися и полнотой аспектами кластера подтипов супертипа.

Дизъюнктность

Особенность дизъюнкции особенно важна, потому что она здесь, где упоминается «или часть», которую вы упомянули, из-за того, что Artist должен быть или один экземпляр подтипа или другой, который я указал в EERD через маленький круг, содержащий букву «d», конструкцию, которая получает имя непересекающееся правило .

Если супертип может быть дополнен одним или несколькими его возможными подтипами, эта точка должна быть выражена небольшим кругом, удерживающим метку с буквой «o», символом, который называется правило перекрытия .

Свойство дискриминатора

Также в рамках фактора disjointness этой ассоциации супертипа-подтипа стоит обратить пристальное внимание на Artist.Type, поскольку он выполняет очень важную задачу в этой компоновке: он функционирует как подтип дискриминатор . Он назван таким образом, поскольку он является свойством, указывающим на исключительный вид подтипа, с которым конкретный экземпляр Artist.

В случае кластеров nonexclusive использование свойства дискриминатора бесполезно, поскольку определенный супертип может иметь несколько подтипов в качестве дополнений (как описано выше).

Общее правило специализации и завершение

Требование, согласно которому каждый Artist должен всегда иметь дополнительный экземпляр подтипа, который должен соответствовать характеристике завершения этого кластера. Это определяется с помощью правила общего специализации , демонстрируемого с помощью символа двойной линии, соединяющего (a) Artist supertype с (b) конструкцией непересекающегося правила.

Связанные группы с исполнителями соло

Оценка предложений

  • "a Группа состоит из одного или нескольких SoloPerformers "

и

  • "a SoloPerformer может быть членом многих групп или no Group ",

можно признать, что оба подтипаучаствуя в ассоциации many-to-many (M: N) (или взаимосвязи), которую я представлял в виде ромбовидного прямоугольника, обозначенного как Group-SoloPerformer.

Если он реализован в реляционной базе данных в качестве таблицы base , этот компонент будет очень полезен для получения (т. е. для выполнения вычисление) общий Number of SoloPerformers которые составляют конкретный Group (одно из требований, которое вы указали).

Связь между исполнителями и инструментами Solo

Оговорка

  • "SoloPerformer [...] может воспроизводить один или несколько инструментов"

позволяет сделать вывод, что в то же время

  • «Инструмент играет нуль, один или несколько SoloPerformers».

Таким образом, это еще один пример ассоциации M: N, и я использовал ромбовидную фигуру, обозначенную SoloPerformer-Instrument, чтобы разоблачить ее .

Дополнительный материал

Чтобы изложить объем структур подтипа супертипа, я собираюсь включить еще два ресурса, т. е.

  1. диаграмма IDEF1X 4 , представленная в Рисунок 2 ( и вы можете скачать его из Dropbox как PDF ), который иллюстрирует выразительные возможности такого рода диаграмм, касающихся бизнес-области; и

  2. соответствующая текстовая логическая структура DDL, которая иллюстрирует, как управлять полным сценарием, обсуждаемым на основе системы управления базами данных SQL.

1. Представление IDEF1X

Технология моделирования IDEF1X, безусловно, предлагает возможность изображать структуры супертипа-подтипа, хотя и с ограничением: он не предоставляет визуальный механизм, чтобы указать, является ли точный кластер исключительным или небезопасным (его «родные» символы может передавать только complete или неполную идентификацию всех возможных типов сущностей значимости). К счастью, можно использовать нотацию Information Engineering (IE), чтобы более точно показать этот первостепенный аспект, используя при этом преимущества описательной мощности стандарта IDEF1X.

В этом методе основной особенностью вашего вопроса является деноминированное «отношение категоризации», где супертип называется «общий объект», а подтип получает имя «субъект категории». Тем не менее, я буду продолжать применять термин supertype-subtype в этом сообщении, потому что (1) он использовался доктором Эдгаром Фрэнком Коддом, создателем реляционной модели, (2) он более широко известен и (3) вместо обозначения «native» используется IE-нотация.

Музыкальные дизайнеры IDEF1X Diagram

Внешние ключи и кластеры супертипа-подтипа

Как показано, IDEF1X дает дополнительное преимущество: средство для определения FOREIGN KEY (FK), элементов первостепенной важности , если , практик будет представлять ассоциацию супертипов-подтипов в реляционная .

Чтобы изобразить такую ​​ассоциацию, свойство PRIMARY KEY (PK) супертипа, то есть Artist.ArtistNumber, должно перейти в Group и SoloPerformer, хотя ему были назначены два разных имени ролей 5, 6 , GroupNumber и SoloPerformerNumber соответственно, с целью подчеркнуть значение , переданное свойством в контексте каждого типа сущности.

Помимо того, что они характеризуются как PK, Group.GroupNumber и SoloPerformer.SoloPerformerNumber, в то же время изображаются как FOREIGN KEYs(FK), которые ссылаются на Artist.ArtistNumber, свойство Pty супертипа.

Итак, поскольку каждый SoloPerformer и Group зависимый от существования для точного экземпляра Artist, эти типы сущностей участвуют в идентификация ассоциации , которая вступает в силу посредством процесса миграции свойств PK, очерченного в предыдущих параграфах.

Внешние ключи и типы ассоциативных сущностей

Диаграмма IDEF1X служит также для иллюстрации FK, которые составляют PK двух ассоциативных типов сущностей , т.е. GroupMember и SoloPerformerInstrument; первый соединяет два подтипа, а второй связывает подтип с независимым типом сущности, то есть Instrument.

2. Логические объявления Expository SQL-DDL

Как объяснялось ранее, структура супертипа-подтипа является средством выражения определенных видов концепций бизнес-домена, касающихся информационных требований, которые, в свою очередь, могут быть представлены в базе данных с помощью различных конструкций, которые должны соответствовать тем, которые предлагаются по конкретной теоретической парадигме (будь то реляционной, сетевой или иерархической), за которой следует система управления базами данных, используемая дизайнером.

Одним из многочисленных преимуществ реляционной парадигмы является то, что она позволяет представлять информацию в ее естественной структуре, а наиболее популярными приближениями к системам, предлагаемым в теории реляционных отношений, являются различные системы управления базами данных SQL.

Итак, наконец, вот несколько примеров DDL-операторов, включая (a) base схемы таблиц, а также (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)  
);
--
--

Целостность данных и согласованность

В соответствии со всем, что было ранее объяснено, разработчик должен гарантировать, что строка each супертипа всегда дополняется сопровождающим ее «подтипом» и , в свою очередь, убедитесь, что указанная строка подтипа совместима со значением, содержащимся в столбце «дискриминатор» супертипа.

Было бы очень практично и элегантно применять указанные обстоятельства декларативно (как предлагает реляционная структура), но, увы, ни одна из основных платформ SQL не предоставила подходящих механизмов для этого (пока как я знаю). Поэтому очень удобно использовать ACID TRANSACTIONS , чтобы эти условия всегда были встретились в базе данных (другим вариантом было бы использовать TRIGGERS, но они, как правило, делают вещи неопрятными).

соображения о деривации данных

Одним из основных аспектов реляционной модели является то, что он считает вывод первостепенным фактором в управлении данными. В соответствии с этим он облегчает создание (a) базовых отношений -или базовых таблиц в 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 Codd, EF ( Декабрь 1979 г.). Расширение реляционной модели базы данных для получения более значимого значения , ACM Transactions on Системы баз данных , том 4, выпуск 4 (стр. 397-434). Нью-Йорк, Нью-Йорк, США.

2 Chen, PP ( Март 1976 г.). Модель отношения сущностей - к единому представлению данных , ACM Transactions on Database Systems - Специальный выпуск: Документы Международной конференции по очень крупным базам данных: 22-24 сентября 1975 г., Фремингем, Массачусетс , том 1, выпуск 1 (стр. 9-36). Нью-Йорк, Нью-Йорк, США.

3 Elmasri, R & Navathe, S. B. (2003). Основы систем баз данных , четвертое издание. Addison-Wesley Longman Publishing Co., Inc. Бостон, Массачусетс, США.

4 Национальный институт стандартов и технологий (США) [NIST] (декабрь 1993 года). Определение интеграции для информационного моделирования (IDEF1X), Публикация федеральных стандартов обработки информации , том 184. США.

5 Кодд, Э. Ф. (июнь 1970 г.). Реляционная модель данных для крупных общих банков данных , Связь ACM , том 13, выпуск 6 (стр. 377-387). Нью-Йорк, Нью-Йорк, США.

6 См. ссылку 4

ответил MDCCL 20 Maypm15 2015, 20:48:15

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132