ER, разрешено?

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

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

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

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

Приветствия

Ответы

Ответ 1

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

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

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

  • Как только у вас есть определенная уверенность в том, что вы получили права Entities and Relations, вы переходите к Модели данных (которая включает атрибуты). Все еще на уровне Логический отношения n:: n остаются в качестве отношений.

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

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

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

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

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

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

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

Ответ 2

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

Ответ 3

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

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

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