Реляционная база данных Дизайн - проблема отношений

Question

Мне нужно создать таблицы базы данных для хранения заметок. в предложении «Кому» пользователь может выбрать отдельного сотрудника или группу сотрудников (различные группы уже доступны в базе данных, имеющие отношения «многие ко многим» с сотрудником). мне интересно, какой должна быть структура таблиц. Для простой заметки, в которой нет групп, у меня будут «MemoMasters» и «Memodetails» с заметкой «EmployeeID» в качестве внешнего ключа. как я могу встраивать группы в эту структуру

Привет

Answer 1

Пока вы подходите к ней как к задаче реляционного моделирования, я не вижу сложности.Предполагая, что вам нужно чисто реляционное решение, попробуйте эту модель Memo Data Model .Если вы не знакомы со Стандартом моделирования реляционных баз данных, может быть полезна нотация IDEF1X .

1. Используется обычный супертип-подтипСостав.

   • В данном случае это Exclusive: MemoAddress, т.е. либо и EmployeeAddress или , GroupAddress.

   • Эксклюзивным подтипам нужен Дискриминатор в Супертипе: я использовал логическое значение IsEmployee, также встречается код CHAR или аналогичный.

2. Эточистый 5NF;нет аномалий обновления;полная декларативная ссылочная целостность.

3. Ack находится в нужном месте (я использовал DateTime, но логическое тоже хорошо).

4. Прогноз заполнения структуры Supertype-Subtype может выглядеть некрасиво, если вы к ней не привыкли;просто спросите, нужна ли вам помощь.

5. Не относитесь к «простым заметкам с одним сотрудником» иначе, вы столкнетесь с проблемами, дублирующим кодом и т. д.

6. Отдельная проблема в том, что вам может понадобиться EmployeeId из Employee, который написал Memo, что совсем другое, и для этого вам нужен FK для Employee in Memo.

Answer 2

Кажется, что вам нужна наследственная наследственность, чтобы достичь того, что вы описываете.Рассмотрим диаграмму ниже:

На этой диаграмме вы создаете родительскую таблицу (я называю ее «Плакат»), а таблицы сотрудников и групп являются дочерними.Вы должны присвоить таблице сотрудников и таблице групп один и тот же первичный ключ, то есть существует одно-однозначные ссылки от группы к постеру и от сотрудника к постеру.

Таким образом, поле памятки poster_id указываетв супер класс.Вы можете выполнить объединение между плакатом, группой и сотрудником, чтобы определить, ссылаетесь ли вы на сотрудника или группу.

Я упустил связь между сотрудником и группой на диаграмме, как вы сказали, что у вас это уже есть.

Обратите внимание, что это просто иллюстрация того, что возможно, ваше решение может отличаться.

Answer 3

В этой структуре вы не могли.

Это отношение многие ко многим , смоделируйте его как таковое.

РЕДАКТИРОВАТЬ (пересматривая сценарий): Приведенных выше требований недостаточно для определения «точного решения»

С риском чрезмерного упрощения вы должны:

1) проверьте, можете ли вы вставить новую информацию в любые существующие таблицы / сущности
2) если нет, то проверьте, добавлены ли атрибуты / столбцы к какой-либо из существующих таблиц / записей
3) если нет, то добавьте новую таблицу

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

Так, например, когда вы заявляете, что у вас уже есть таблица «многие ко многим» для групп, сейчас главный вопрос - погода, чтобы повторно использовать эту таблицу или создать новую.

Это зависит от других атрибутов в этой таблице. Может быть, для вашей бизнес-модели / варианта использования это имеет смысл, а может и нет.

Может быть, вам нужно смоделировать таблицу, называемую «MemoRecipients», в которой будет храниться информация о получателях (доставка, подтверждение и т. Д.). Тогда вы должны спросить себя, нужно ли вам время для всех этих статусов и т. Д., И т. Д ...

Только вы можете определить, что является правильным решением для вашей проблемной области.