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

Question

Ищите правильный способ моделирования следующих требований.

1. Есть 3 типа «вечеринок», которые нужно обсудить: Фанат, Группа и BandMember.
2. Этот BandMember всегда будет ассоциироваться с группой, а также может быть фанатом любой группы.
3. Есть общие атрибуты между Fan, Band и BandMember, но каждый из этих 3 также будет иметь свои уникальные атрибуты.
4. Фанат может быть поклонником любой группы или вообще ни одного

Это небольшая часть большой мысли, но она создает путаницу в расширении модели. Я полагаю, что это должна быть диаграмма 2 или какой-то другой вариант, поскольку я не понимаю, как BandMember может быть связан с Band в первой модели.

Я ценю любой вклад.

Answer 1

Предостережение

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

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

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

   • Однако, это не встречается в моих ответах на SO, потому что это сайт «вопросов и ответов», у меня естьответить на уровне спрашивающего.(Я отвечаю на вопросы более полно, чем другие, и даже это вызывает негативные комментарии!).Будьте уверены, что я иду через формальную последовательность.
     .

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

   • Я придерживаюсь реляционной модели EF Codd & CJ Date

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

   • Принцип ортогонального проектирования Д. Макговеран и С. Дж. Дата.

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

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

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

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

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

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

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

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

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

   • BandMember и Fan не являются Parties.Они Persons, во-первых (и Person это Party, во-вторых)

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

   • Похоже, у вас есть ERwin (лучший!); это позволяет вам просматривать одну модель на этом уровне очень удобно. Реализуйте идентификаторы в сущностях даже на этом абстрактном уровне.

Препятствие

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

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

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

   • ваша модель не показывает, что Band состоит из один-ко-многим Members. И так далее.
     .
     В то время как программирование может прогрессировать постепенно (когда определение стабильно), моделирование - нет. Например. вы не можете моделировать сущности, но не отношения; Отношения, но не кардинальность. Вот почему они разные науки, программисты не делают хороших модельеров, и наоборот.
     ,

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

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

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

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

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

   • Существами являются Существительные в модели

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

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

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

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

   • A Band состоит из один ко многим People, которые Members

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

   • A 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
   

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

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

Answer 2

Я думаю, что это проще, чем вы думаете. У вас есть два объекта - 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.