Как смоделировать отношение ... сущность ... атрибут?
Перед тем, как проектировать базу данных, я хочу смоделировать проблему как диаграмму отношения сущность (используя нотацию Чена).На этой диаграмме я хочу создать отношение между сотрудником и проектом, не обращая внимания на следующие ключи и ограничения.Приложение: Я просто знаю отношения между двумя сущностями, которые расширены атрибутами, но как мне смоделировать это «отношение трех сущностей»?
Это вполне понятно и совершенно правильно.Бумага дешева, объекты в базе данных немного дороже менять.Смоделируйте требование и продолжайте его улучшать, пока вы не будете уверены, затем реализуйте.
Проблема многих сайтов в том, что есть много плотников, которые, хотя и доброжелательно, рассматривают каждую проблему какгвоздь, и поставьте DDL, а не запрашиваемую помощь в моделировании.Чего не хватает, так это контекста и значения, поэтому конечным результатом является быстрая реализация с фиксированными «ключами», но без контекста и значения.Моделирование позволяет нам моделировать различные аспекты, которые имеют отношение к нам, не заботясь о том, как это будет выглядеть в DDL.
Еще один способ сказать, что OMG ответила на один вопрос как мне моделировать "Сотрудник работает над этим проектом как ... "? в изоляции;Я отвечаю на весь ваш вопрос в контексте.
На логическом уровне отношения многие ко многим верны.Такие отношения без других соображений отображаются на физическом уровне в виде ассоциативных таблиц.Но, опять же, еще слишком рано принимать это решение, потому что вы все еще моделируете контекст и значение отношений.
... и это не входит в область нотации уценки SO, чтобы предоставить ее.IME, такие инструменты, как Oracle Designer, генерируют такие диаграммы после того, как вы создали сущности
Ерунда.Вся идея моделирования заключается в том, чтобы разработать и улучшить что-то на бумаге, используя диаграммы, задолго до написания строки кода, или покупки платформы, или необходимости внедрения DDL.Комментарий касается просто реверс-инжиниринга существующей базы данных, после того, что предоставляют многие продукты.
Пример моделирования, прогрессия
Используйте любые символы, которые значат для вас, для моделирования того, что вынеобходимость.Конечно, стандартные символы более понятны.Вот вам
ERD
(я понятия не имею, как «Нотация уценки SO» накладывает ограничение на предоставление рекомендаций по моделированию до факта).Я привел пример прогрессии, которая может произойти .Ничто не является «правильным» или «неправильным», это все кусочки бумаги;пока вы не решите, какие элементы заслуживают подтверждения, и тогда возможна следующая прогрессия.
Отправной точкой, конечно же, являются простые отношения «многие ко многим», о которых вы знаете некоторые вещи , согласно вашему названию,Попытка смоделировать условное трехстороннее отношение неверна, ошибка моделирования: для того, чтобы разрешить любовный треугольник, вам нужно сначала определить дискретные отношения между каждой из сторон, отдельно;это означает, что все отношения только двусторонние.
Проект, сотрудники и ролевые организации ясны, и мы кое-что о них знаем.Здесь я оставил основные сущности неразработанными, потому что они «сильные», и они не являются тем, на что вы фокусируете.
В прогрессии используются примеры атрибутов отношения , вы можете использовать свой собственный.(Наш бельгийский коллега уже обозначил проблему на словах, я просто представляю ее на рисунках.) Многие люди не делают обычной практики, которую они должны делать;Я обеспокоен истинным моделированием сверху вниз, чтобы прогрессировать и прийти к правильной модели данных.Удалите все, что является мусором, и продолжайте прогрессировать.
Я сделал предположение, что атрибуты отношения оправдывают сущность, поэтому я теперь нарисовал их. Здесь я использовал овалы, вы можете использовать алмазы или шевроны для всех Iосторожно, просто используйте некоторый символ, чтобы смоделировать то, что вам нужно.
Здесь наступает момент, когда мы можем ясно видеть: мы не хотим Project :: Employee :: Role, потому что это будетразрешить Сотруднику выполнять любую Роль;мы хотим, чтобы сотрудники выбирались только в том случае, если они были предварительно утверждены на эту роль.Итак, Employee :: Role становится «сильнее».
Следовательно, Employee :: Role является сущностью.И розовая вещь - дитя этой конкретной комбинации или сотрудника + роли, а не всего сотрудника или всей роли.
Точно так же мы не хотим, чтобы какие-либо сотрудники брали какую-либо возможную работув любом возможном проекте мы хотим, чтобы они брали только утвержденные рабочие места в утвержденных проектах.Таким образом, Project :: Role становится сильной личностью и в любом случае имеет атрибуты.
Следовательно, Project :: Role является сущностью.И этот оставшийся овал является потомком этой конкретной комбинации Project + Role, а не всего Project.
Наш розовый ребенок получает статус Entity со своими специфическими атрибутами.Что еще более важно, его ограничения получены из ранее ограниченных сущностей, а не простых.
Данные имеют естественный порядок или иерархию, и диаграмму, составленную с учетом этого, очень легко понять.,Теперь у нас есть возможность взглянуть на атрибуты.Они могут показаться одинаковыми, похожими или запутанными;тогда как теперь они имеют ясное значение, благодаря контексту и иерархии.
Я ввел понятие Идентификаторы , не расширяя его, я оставлю этодля обсуждения, если это необходимо.Я думаю, вы можете видеть, что идентификаторы на самом деле очень, очень важны, и они представлены как обычная часть упражнения по моделированию.
В общих чертах (ваш вопрос, в отличие от моего примера прогрессии)Когда мы добираемся до нормализации, три начальных овала могут закончиться как один или два или остаться как три объекта;простые ассоциативные таблицы без атрибутов;или как истинные сущности с атрибутами ... но мы не заботимся об этом и не должны заботиться об этом прямо сейчас.И снова, это слишком рано для DDL или для нормализации на данном этапе.Мы понятия не имеем, что это за ключи;какие атрибуты связаны с ними;и в каком отношении к ним.Более того, нам все равно.С точки зрения примера, да, сущности понятны и недвусмысленны.
Пожалуйста, оставьте отзыв, чтобы вы могли прогрессировать.
Редактировать: диаграмма обновлена, многостраничная.