Действительность следующей модели отношений сущностей?

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

Я особенно не уверен в своей кардинальности отношений между Клиентом и VIP. Кроме того, отношения поставщика и компакт-диска. start_date сущности VIP — должен ли это быть слабый ключ? Существуют ли какие-либо другие потенциальные слабые ключи, помимо атрибута name объекта Song?

Модель E/R

Легенда

  • Объект введите здесь описание изображения
  • Атрибут введите здесь описание изображения
  • Слабая сущность введите здесь описание изображения
  • Связь введите здесь описание изображения
  • Определение отношения введите здесь описание изображения
  • Отношение мощности введите здесь описание изображения

Я использовал следующие веб-сайты в качестве ссылок для построения моей диаграммы:

  1. http://en.wikipedia.org/wiki/File:ERD_Representation.svg
  2. http://en.wikipedia.org/wiki/Entity-relationship_model
  3. http://www.cse.ohio-state.edu/~gurari/course/cse670/cse670Ch2.xht

Программное обеспечение, использованное для создания схемы: Dia (Linux)


sql database-design entity-relationship er-diagrams
person Sahat Yalkabov    schedule 18.04.2012    source источник
comment
Случайным образом - могут ли два компакт-диска содержать одну и ту же песню? Например, сборник хитов или что-то в этом роде? Будет ли это еще одна запись песни? или вам, возможно, нужно разорвать связь с другой таблицей (cd, song, songtoCD { songid, cdid, track# }) или что-то в этом роде?   -  person Prescott    schedule 18.04.2012
comment
мой UML слаб - так что, если эта диаграмма уже говорит об этом, не обращайте внимания на мой комментарий!   -  person Prescott    schedule 18.04.2012
comment
@Prescott Каждый компакт-диск может содержать только одно уникальное название песни. Довольно упрощенная модель.   -  person Sahat Yalkabov    schedule 18.04.2012
comment
Ах, хорошо, так что не нужно знать, что, может быть, у исполнителя есть песня X на двух дисках? у вас просто есть две записи, в которых говорится, что песня X - Cd1, песня X - cd2, и вы предполагаете, что песня X - это одна и та же песня X? или вас вообще не волнуют эти конкретные отношения? я думаю ты понял, просто интересно   -  person Prescott    schedule 18.04.2012
comment
Отношения is между Customer и VIP являются экземпляром шаблона gen-spec. Есть лучшие способы моделирования gen-spec в диаграммах ER. Когда вы приступите к преобразованию в SQL, вам нужно знать, как проектировать таблицы SQL, которые моделируют gen-spec.   -  person Walter Mitty    schedule 18.04.2012
comment
Я бы посчитал имя в сущности производителя слабым ключом. Даже у музыкальных продюсеров могут быть общие (дублирующиеся) имена.   -  person Kerbocat    schedule 15.06.2012

Ответы (1)


arrow_upward
1
arrow_downward

Извините, это поздний ответ, но на случай, если он будет полезен, вы можете сделать два улучшения.

1) Связь «является» между «VIP» и «CUSTOMER» указывает на наличие надкласса (клиент) и подкласса (vip). Вы можете смоделировать VIP как подкласс.

2) Поскольку вы отслеживаете даты отношения «арендная плата», кардинальность должна быть взята «с течением времени». Следовательно, количество элементов с обеих сторон равно «N» (т. е. не «1» на стороне клиентов).

Небольшое улучшение: в «Песне» (класс слабых сущностей) в качестве частичного идентификатора задайте «трек», а не «имя»; это позволит сделать несколько записей одной и той же песни на компакт-диске (например, 2 версии). Номер дорожки всегда будет уникальным на компакт-диске.

person F C    schedule 26.08.2012