#database #database-design #loops #data-modeling #entity-relationship-model
#База данных #база данных-проектирование #циклы #моделирование данных #сущность-связь
Вопрос:
Кто-то сказал мне, что наличие циклов в datamodel — плохой дизайн. Я слышал это раньше пару раз, но не обращал особого внимания. Например, у вас есть объекты User, Project, Activity. Проект принадлежит пользователю, поэтому у нас есть отношение «один ко многим» от пользователя к проекту. Действие может быть назначено одному пользователю, другое отношение «один ко многим» — от пользователя к действию. Конечно, проект определяется набором действий, еще одним отношением «один ко многим» от проекта к действию. Таким образом, формируется цикл.
Я спросил этого парня, почему это плохой дизайн, но он сказал мне, что тоже не знает, ему тоже так сказали, обезьянье обучение в лучшем виде.
Я пытался выполнить поиск, но, полагаю, я не использовал правильные слова, однако мне кажется, это должно быть фундаментальным для того, кто пытается спроектировать БД.
Итак, может кто-нибудь указать мне на некоторую полезную информацию о циклах в диаграммах er / db, следует ли их избегать?
Ответ №1:
В главе 3 этой статьи есть действительно хорошая трактовка циклов связей (archive.org).
Однако, как правило, наиболее распространенной проблемой циклов является согласованность избыточной информации.
Рассмотрим случай (из статьи), когда у родителя много детей; каждый ребенок посещает школу. Существует третья связь между родителем и школой (‘у родителя есть ребенок в школе’). Однако: вы не хотите явно моделировать третьи связи; это полностью выводимо из двух других. Если бы вы фиксировали это явно, вам нужно было бы убедиться, что цикл всегда был согласованным.
Итак, в этом случае вы хотели бы избежать цикла. Однако: циклы не всегда плохи. Снова взяв приведенный выше пример, рассмотрим моделирование случая, когда родитель является управляющим в школе. Это также создало бы цикл. Хотя в этом случае это допустимо: невозможно вывести отношение «родитель является управляющим в школе» из двух других отношений.
Итак, вкратце: не моделируйте циклы, когда одна связь полностью выводима из других вместе взятых. Но это нормально создавать циклы, когда они не выводимы.
Тем не менее, я бы порекомендовал статью; в ней дается гораздо лучшее описание, чем я могу привести здесь.
Комментарии:
1. Это хороший вопрос, и ваш ответ имеет большой смысл. Итак, если бы я экстраполировал на пример OP, вы могли бы сказать, что вам обычно не нужно привязывать пользователя к проекту, поскольку эта связь может быть выведена на основе того факта, что они назначены задачам, которые, в свою очередь, назначены проекту, следовательно, вы можете вывести эту связь. Однако, если бы у вашего объекта project был менеджер проекта, это было бы допустимым отношением для сопоставления пользователям, поскольку вы не могли бы вывести это отношение.
2. @Stephen: да, именно так. В статье также есть несколько других сценариев, но по сути это сводится либо к управлению согласованностью избыточной информации, либо к ее удалению с помощью деривации.
3. Статья выглядит как много шума из ничего. Нет, «циклов» (такого рода) не «лучше избегать». Чего лучше избегать, так это избыточности (в общем, не только применительно к связям). Информация, которая может быть получена из другой информации, которая уже присутствует, которой следует избегать, если у вас нет очень веских причин не делать этого. Зачем им нужны x-ty страницы, чтобы сказать это?
4. @Erwin: если вы уже знаете, чего вам следует опасаться в циклах — а вы явно это делаете, — то статья не сообщит вам ничего нового. Однако OP конкретно сказал (а), что ему сказали «циклы плохие», и не знал почему. В документе приводятся конкретные примеры, объясняющие ситуацию с точки зрения первых принципов. Поэтому целесообразно, если вы начинаете оттуда. Если вы этого не делаете, то это не так.
5. К сожалению, ссылка мертва.