Концептуальное моделирование данных: как читать рекурсивные отношения "многие ко многим"
Я понимаю, что простое бинарное отношение, подобное приведенному ниже, будет читаться слева направо: пользователь "может" иметь одну или несколько картинок. Также, если вы читаете его справа налево, это будет... изображение "должно" принадлежать одному и только одному пользователю. 
Тем не менее, я немного запутался, когда увидел следующее. Может кто-нибудь сказать мне, как вы читаете этот тип отношений? Кроме того, на изображении, следующем за одним справа, они говорят одно и то же просто по-разному? 
и наконец, в этих рекурсивных отношениях, где пользователь может быть другом другого пользователя, имеет ли смысл, что оба конца указываются как необязательные многие, или один должен быть обязательным и многими?
Я вижу это так: если у пользователя может быть ноль или много друзей, то на другом конце у него должен быть один или несколько друзей, потому что, если пользователь A дружит с пользователем B, то у пользователя B больше нет возможности иметь ноль друзей. Это предположение правильно или я ошибаюсь?
Любые мысли помогут мне, я просто читаю книгу о концептуальном моделировании данных и действительно хочу понять это, прежде чем я продолжу практиковаться в реальных таблицах.
2 ответа
Да, две диаграммы показывают одно и то же.
Некоторые люди предпочитают оставлять отношения "многие ко многим" нерешенными в концептуальной диаграмме. Некоторый текст, описывающий отношения, может быть полезным (я бы предложил что-то вроде "дружит с"). Я бы тогда прочитал это как что-то вроде "Пользователь может дружить с другими Пользователями".
На второй диаграмме показано, что бы вы нарисовали, если бы вместо этого решили разрешить отношение "многие ко многим". Некоторые люди оставляют это до логического моделирования, и когда вы прочитаете об этом, вы столкнетесь с той же конструкцией (которую я рекомендовал бы в качестве следующего шага после изучения концептуального моделирования). Я бы прочитал отношения между Пользователем и Дружбой как что-то вроде "Пользователь может иметь Дружбу".
Эти отношения всегда необязательны, потому что вы моделируете общую картину, а не один конкретный экземпляр. Показывать его как необязательный с правой стороны означало бы, что у каждого пользователя должна быть хотя бы одна запись во втором столбце таблицы "Дружба" в базе данных, которую вы в конечном итоге сделаете из этой модели - и это не так.
Кстати, я думаю, что очень похвально, что вы читаете об этом (слишком много людей создают базы данных, даже не пытаясь понять концептуальное или логическое моделирование!). Я не буду беспокоиться о том, чтобы подождать, пока вы не почувствуете, что полностью понимаете это, прежде чем испытать то, что изучаете; некоторые идеи могут иметь больше смысла, когда вы применяете их на практике на реальных данных, которые вы уже знаете. Попробуйте набросать концептуальные диаграммы на основе ваших собственных данных, пока вы учитесь, если вы еще этого не сделали.
Здесь есть что распаковать. Ответ от Джо Дуглас покрывает большую часть земли.
Я полагаю, что часть вашего замешательства связана с тем, что люди используют диаграммы ER, чтобы изобразить две совершенно разные модели. Первый - это модели сущности-отношения, более известные как модели ER. Второе - это реляционные модели. На первый взгляд, две модели выглядят практически одинаково. Но у них разные функции, и они созданы для разных целей.
Модель ER может облегчить связь между разработчиком базы данных и экспертом в данной области. Специалист в данной области может иметь глубокое понимание данных: как они выглядят, что они означают, почему это важно и как их следует использовать. Этот же эксперт по предмету может быть мало заинтересован или не заинтересован в технических темах, таких как внешние ключи, ссылочная целостность или нормализация данных.
Реляционная модель - хороший предварительный результат для дизайнера, намеревающегося спроектировать и построить базу данных в одной из популярных баз данных SQL, таких как SQL Server, Oracle или десятки других.
Ваша последняя диаграмма, только с пометкой "Пользователь", очень лаконична и ясна. Это подчеркивает природу отношений "многие ко многим". Это совершенно справедливо в модели ER, но разработчик реляционных моделей скажет вам, что это недопустимо и что требуется распределительная коробка.
Однако в нем нет названия для отношений, а именно дружбы. Называть отношения полезно, если у вас может быть два идентичных отношения. Он также предоставляет имя, на которое вы можете повесить атрибуты. В некоторых случаях вас может заинтересовать дата, когда началась данная дружба.
Является ли связь обязательной или необязательной, может зависеть от того, анализируете ли вы предмет или разрабатываете решение. Если это первый из них, обратитесь к предмету, чтобы узнать, является ли это обязательным или нет. Присутствующие здесь технические специалисты не могут ответить на этот вопрос, потому что мы не знаем вашу тему, даже когда думаем, что знаем.
Если вы разрабатываете решение, вы можете взглянуть на него с другой точки зрения. Вы преувеличиваете данные? Вы недовольны?
Я надеюсь, что это относится к тому, с чем вы боретесь. Дизайн базы данных не сложен. Но это абстрактно.