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

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

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

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

http://img149.imageshack.us/i/84754821.png

ура

Источник

3 ответа

Решение

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

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

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

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

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

  3. Когда вы переходите на физический уровень, модель данных имеет таблицы; Колонны; Типы данных.

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

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

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

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

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

Источник

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

Источник

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

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

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

Источник
Другие вопросы по тегам