Диаграмма ER, это разрешено?

Question

Мне нужно создать диаграмму ER на основе реляционной схемы.

Есть таблица игроков и таблица зон.Игрок может «жить» во многих зонах, и каждая зона принадлежит одному или нескольким игрокам.

Я придумал эту простую диаграмму ER, но я не уверен, что отношения, проходящие в каждую сторону, разрешены?

Приветствия

Answer 1

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

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

1. На этой ранней стадии нормально моделировать сущности и отношения (не атрибуты), поэтому она называется диаграммой ER; мы не приблизились к моделированию данных. Отношения актуальны, и именно поэтому вы детализируете и оцениваете их характер в алмазах и кардинальности. Цель состоит в том, чтобы уточнить истинные сущности и их отношения друг к другу. Отношения многие ко многим остаются отношениями. ERD является чисто логическим, физического нет.

2. Как только у вас появится уверенность в том, что вы правильно поняли сущности и отношения, вы переходите на Модель данных (которая включает в себя атрибуты). На уровне Logical отношения n :: n остаются отношениями.

   • По мере продвижения вы можете показывать дополнительную информацию, например, «Домен» для каждого атрибута. Это DataType, но на логическом уровне, так же как термины Entity = Table и Attribute = Column, Domain = DataType.
     .

3. При достижении Физического уровня модель данных имеет таблицы; Колонны; Datatypes.

   • И n :: n Отношения проявляются как Ассоциативные Таблицы.
     .
4. Идея состоит в том, что, пока вы работаете по предписанным шагам, в (1) содержание в алмазах будет определять (раскрывать), нужно ли их хранить, и таким образом алмаз повышается до Сущности; в противном случае это остается отношением.

В реляционной схеме, которую мне дали, есть соединительная таблица с именем live-in. Тем не менее, я думал, что при отображении реляционной схемы [назад] на диаграмму ER таблица соединений становится отношением?

• Реляционный термин - Ассоциативная таблица.

• Да. Если это чистая таблица n :: n (не содержащая ничего, кроме двух FK для PK родительских таблиц), на уровне ERD, который является только логическим, это отношение.

• Если у него есть столбцы , отличные от двух FK, то это сущность.

Answer 2

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

PLAYER (playerid, <other fields>)
ZONE (zoneid, <other fields>
PLAYER_ZONE(playerid, lives_in_zoneid)
ZONE_OWNER (zoneid, owner_playerid)

В противном случае достаточно трех столов.

Answer 3

Поскольку между [Players] и [Zones] существует отношение «многие ко многим», необходимо добавить соединительную таблицу (называемую, например, [PlayersZones]).Само обозначение правильное (обозначение Чена), хотя я предпочитаю обозначение вороньей лапки.