SQL Server утроить отношения многие ко многим - PullRequest
Новая
       35

SQL Server утроить отношения многие ко многим

0 голосов
/ 11 апреля 2019

Я пытаюсь наметить базу данных для учебного веб-сайта для сотрудников.

Он работает следующим образом:

  1. Каждому сотруднику будут назначены модули, один или несколько.

  2. Каждый модуль будетназначенные курсы, опять же один или несколько.

Один и тот же модуль может быть назначен нескольким сотрудникам, и один и тот же курс может быть назначен нескольким модулям.

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

Итак, будет ли это третичным отношением?Или тройное отношение многих ко многим?Как будет установлена ​​БД?

Вот что я думаю до сих пор.

Сотрудник 

 EmployeeID 
 Name

Модуль 

 ModuleID
 ModuleName
 Status

Курс 

 CourseID
 CourseName
 Status

EmployeesModules 

 EmployeeID
 ModuleID

ModulesCourses 

 ModuleID
 CourseID

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

Как мне улучшить этот дизайн?

1 Ответ

1 голос
/ 12 апреля 2019

Рассмотрим следующее ERD:

ERD

Сначала приведем некоторые пояснения к диаграмме ...

В этом ERD синие типы сущностей похожи на основные таблицы.Зеленые типы объектов похожи на таблицы транзакций.Для атрибутов подчеркнутые являются ключом-кандидатом.Вы можете быть тем, кому нравятся суррогатные ключи для каждой таблицы - если это так - идите вперёд, или вы можете использовать (иногда составные) ключи, показанные на схеме.Пока ключи на диаграмме уникальны, все готово.

Теперь, о чем я говорю и как это вам поможет? ...

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

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

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

Теперь вы можете отслеживать прогресс сотрудника по каждому курсу вEmployee_Course_Status таблица.Единственная потенциальная проблема в вашем коде - это значение Module_Enrolment.EmployeeModuleStatus.В зависимости от ваших бизнес-правил это может быть рассчитано на основе множества значений статуса на уровне курса.Это создает небольшую избыточность и возможность для аномалии обновления (при которой значения состояния вашего курса и значения состояния вашего модуля выходят из строя).

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

...