Моделирование данных: супертип/подтип

Осторожно

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

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

2. Это действительно здорово, что вы понимаете необходимость (а) моделирования данных и (б) изучения науки (задокументированной более 30 лет) концептуального, логического, а затем физического. Это именно то, что я делаю. Вы не можете себе представить, сколько времени и усилий экономит формальный процесс.

   • However, that does not come across in my answers at SO, because it is a "question and answer" site, I have to answer at the level of the questioner. (I answer questions more fully than others, and even that, causes negative commentary !). Be assured that I go through the formal sequence.
     .

3. Следует отметить, что моделирование отношений сущностей — это работа гигантов отрасли, Э. Ф. Кодда и П. Чена. Методология основана на их работе и была завершена Р. Брауном в 1980-х годах. IDEF1X стал стандартом NIST в 1993 году. Когда я отвечаю на вопросы о моделировании данных, я не предлагаю какой-то личный метод, о котором написал книгу, я стою на плечах гигантов.

   • Я придерживаюсь реляционной модели Э. Ф. Кодда и К. Дж. Дейта.

   • Принцип полной нормализации (?) C J Date & F Pascal

   • Принцип ортогонального дизайна, Д. Макговеран и К. Дж. Дейт.

Данные моделирования

1. Да, здесь правильная структура супертип-подтип. К сожалению, это не распространено и, следовательно, не всегда понятно.

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

3. Дело в том, что это может выглядеть «сложно», но на самом деле это очень просто.

   Именно здесь Кен Даунс и Крис Беренс путают смоделированную простоту (с высокой расширяемостью) с немоделированной реализацией (неправильной и нерасширяемой) из-за упрощенного подхода, рекомендованного дварфами, такими как Мартин Фаулер. Без обид, я понимаю, что люди привязаны к тому, что знают, и будут защищать то, что они знают, как бы ограниченно это ни было.

   • обратите внимание, что каждый Подтип также является вполне допустимой Сущностью (Таблица в Физическом, когда мы дойдем до этой стадии) сам по себе и может существовать сам по себе.

   • для более низких уровней или таблиц транзакций или функций, которые имеют отношения к этим подтипам, хитрость заключается в использовании правильного подтипа (роли). Распространенная ошибка заключается в том, что они используют Party, а затем теряется значение подтипа или роли и правильная ссылочная целостность.

   • по отдельности все имена ролей производны от Party, но это не является веской причиной для использованияParty вместо правильной роли.

   • Здесь вы действительно хорошо разбираетесь в данных, но (вас никто этому и не учил) вы перепутали Роли и Подтипы.

   • BandMember и Fan не Parties. Они Persons, первый (а Person это Party, второй)

4. Чтобы прояснить эти моменты, на этом концептуальном уровне нам нужно работать с сущностями и идентификаторами (а не с атрибутами), а не только с сущностями. Поэтому я предусмотрел и это.

   • It appears you have ERwin (the best!); it allows you to view the single model at that level very conveniently. Do implement the Identifiers in the Entities, even at this abstract level.

Препятствие

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

1. В модели (1) Band не может быть независимым (квадратные углы): поскольку он идентифицируется как зависимый от Party; это подтип Party; и он имеет тот же идентификатор.

2. Отсутствующая Кардинальность имеет решающее значение. Ввод его на самом деле поможет в разрешении модели. Меня не смущает IDEF1X (кружки) и IEEE (гусиные лапки), но я всегда добавляю их по ходу дела и продолжаю менять по мере развития модели.

   • your model does not show that a Band is made up of one-to-many Members. Et cetera.
     .
     While programming can progress incrementally (once the definition is stable)), modelling does not. Eg. you can't model the Entities but not the Relations; the Relations but not the Cardinality. That is why they are different sciences, programmers do not make good modellers, and vice versa.
     .

3. На этом этапе также очень важны Правила. Моделирование — это, по сути, моделирование Правил. Поэтому исправление или изменение Правил является частью процесса Моделирования.

   • Фанат может быть фанатом любой группы или не быть фанатом вообще, это неразумно. Если Person никакой, то он является представителем широкой публики и не имеет никакого отношения ни к какому Band. Обычный Person.

   • Fan имеет отношение как минимум к одному Band. На самом деле наличие Отношения с Band — это то, что выводит Person из этой области и приводит к хранению Fan подробностей или специфических подробностей поклонников группы.

   • Если есть такая Сущность, как Fan with no Band (т.е. вы храните детали этого, отдельно от Fan по моей модели), сообщите, и я изменю модель (бумага дешевая!).

4. Глагольные фразы также важны на этом этапе; не менее, чем мое замечание о правилах и кардинальности выше, это часть процесса моделирования, и она нуждается в изменении/модуляции по мере развития модели. Вы не поверите, как важно правильно произносить глагольные фразы. Включение их вполне могло помочь вам в прояснении подтипов и ролей. Вот определение, которое каждый специалист по моделированию данных знает наизусть.

   • Сущности — это существительные в модели.

   • Отношения — это глаголы, действия, происходящие между существительными.

   • Глагольные фразы определяют эти действия (поэтому они и называются Глагольными фразами, это не смешное название).

   Как описано в документе Нотация IDEF1X, для ассоциативных таблиц считывайте глагольную фразу «сквозь» их к родительскому элементу на другой стороне ассоциации.

   • Person делает один ко многим Bands и, таким образом, является Member

   • Band состоит из People "один ко многим", которые являются Members

   • Person покровительствует Band, что делает их Fan (а не просто Person, у которого есть строка в таблице Fan)

   • Band зависит от People, которые Fans

   Придумать самую короткую и содержательную глагольную фразу; не использовать упрощенные слова ("содержит" следует избегать"), является проблемой для моделистов. Не стесняйтесь улучшать предложенные мною Глагольные фразы.

▶Отношения сторон◀< /а>

Читатели, незнакомые со Стандартом моделирования реляционных баз данных, могут найти ▶Нотация IDEF1X◀ полезно.

Примечание

Все, что я сделал, это разрешил подтипы; Роли; Мощность отношений, как определено выше.

1. Актуальность подтипов и ролей станет для вас более ясной, когда вы оцените свой второй транш или свои транзакционные сущности (как вы сказали, здесь у нас есть только идентифицирующие сущности).

2. Идентификаторы. Это стоит пояснить не только для того, чтобы прояснить модель, но и потому, что это хороший пример использования идентификаторов IDEF1X и возможностей, которые они задействуют. Вы уже указали в своей модели, что понимаете это (сплошные линии), я просто даю ей полную трактовку.

   • Person и Band являются подтипами Party. Они также являются ролями Party. Поэтому мы используем PersonId и BandId от этой точки вниз, а не PartyId (хотя это PartyId).

   • Когда Person играет роль Member, мы используем MemberId (то есть PersonId, то есть PartyId).

   • Когда Person играет роль Fan, мы используем FanId (то есть PersonId, то есть PartyId).

   Допустим, вы перечисляли Fans из Band, ваш запрос сосредоточен на Fan. Если бы у вас были эти Id суррогатные ключи на каждом столе, вы были бы вынуждены присоединиться к Person, а затем присоединиться к Party. Но с имеющимися у вас реляционными идентификаторами вы можете перейти прямо к Party:

   SELECT Name FROM Party WHERE PartyId = FanId
   

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

Пожалуйста, оцените и задайте конкретные вопросы.

Я думаю, это проще, чем вы думаете. У вас есть два объекта — Band и Person, и они могут быть связаны двумя разными способами, либо как поклонник, либо как участник. Вот быстрый скрипт базы данных без внешних ключей или чего-то еще:

CREATE TABLE [dbo].[XREFBandMembers](
    [MemberID] [int] NOT NULL,
    [BandId] [int] NOT NULL,
 CONSTRAINT [PK_XREFBandMembers] PRIMARY KEY CLUSTERED 
(
    [MemberID] ASC,
    [BandId] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

CREATE TABLE [dbo].[XREFBandFans](
    [FanId] [int] NOT NULL,
    [BandId] [int] NOT NULL,
 CONSTRAINT [PK_XREFBandFans] PRIMARY KEY CLUSTERED 
(
    [FanId] ASC,
    [BandId] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

CREATE TABLE [dbo].[People](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [Name] [nvarchar](100) NOT NULL,
 CONSTRAINT [PK_People] PRIMARY KEY CLUSTERED 
(
    [Id] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

CREATE TABLE [dbo].[Bands](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [Name] [nvarchar](50) NOT NULL,
 CONSTRAINT [PK_Bands] PRIMARY KEY CLUSTERED 
(
    [Id] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

Что касается конкретных атрибутов отношений, вы можете поместить их в таблицы XREF, например, FanClubMembershipNumber входит в XREFBandFans.