Исполнителя песня ERD

Question

я видел во время чтения Wikipedia следующего соотношения DB, определенного между художником и песней:

http://en.wikipedia.org/wiki/File:ERD-artist-performs-song.svg

От Источника: http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model

И текст под ней говорится следующее :

Два связанных объекта, показанных с использованием носовой части Ворона. В этом примере между Artist и Song отображается необязательная связь; символы, наиболее близкие к объекту песни, представляют «ноль, один или много», тогда как песня имеет «один и только один» Исполнитель. Таким образом, первое из них читается как Исполнитель (может) исполнять (-ы) «ноль, один или много» (-ых) песен (-ов)

Теперь у меня есть некоторые вопросы об этих отношениях, поскольку определенные отношения мне кажутся нереальными :

1) В реальной жизни песня может иметь от 1 до многих художников, которые могут исполнять или даже писать песню, поэтому, на мой взгляд, правильные отношения должны показать «-IE» от песни к художнику, а не «-II»,

2) Как художник может исполнить 0 песен «-0E» - этот объект больше не должен классифицироваться как художник по определению словаря имени объекта, если это верно, правильно? (пожалуйста, не оставляйте комментарии о том, что видели людей, которые называют себя художниками, и не могут исполнять песни, с которыми я должен согласиться). Согласно показанным отношениям БД, классификация Художника предоставляется субъекту, который не может выполнить песню, поэтому при разработке ERD должно ли определение словаря сущностью также определять отношения сущности? Если это так, то конкретное имя для такого типа планирования в моделировании отношений БД должно принимать во внимание определение имени, данного сущности?

3) В ERD глагол «выполняет» используется для отображения действия отношения, глядя на другие ERD. Я не видел места, где также определяется глагол для отношения, когда диаграмма представлена ​​визуально. Нужно ли определять и показывать этот глагол в ERD? Причина, по которой я спрашиваю, заключается в том, что в вышеупомянутом случае глагол «выполняет», возможно, был плохим выбором, если вместо этого был выбран «созданный» глагол, тогда связь могла быть правильной, чтобы художник мог создавать от 0 до * песен, но из-за глагол, выбранный вместо этого для отношения, как я упоминал выше, он нарушает логическое соединение, которое оператор пытается изобразить и, следовательно, делает его недействительным. Исходя из этого, должны ли глаголы выбраны не обязательно в диаграммах отношений БД?

Answer 1

Вопрос № 1

В реальном мире, мы обычно считают одной песни, чтобы быть performable многими разными артистами. Например, сколько раз песни Beatles исполнялись по-разному разными художниками.

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

Это мое разумное предположение о том, почему диаграмма моделирует отношения таким образом. Технически не было бы ничего плохого в моделировании отношений Artist-Song как многих для многих, как вы предполагали, но это зависит от характера и требований к вашей системе.

Вопрос № 2

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

Вопрос № 3

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

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

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

Сообщите мне, не ясно ли это.