Дизайн базы данных: как ограничить отношение n: m другими отношениями?

Question

Я думаю, что лучше всего спросить на примере: есть люди, клиенты и проекты.

Отношение людей к клиентам - это отношения: m.Люди могут работать на нескольких клиентов.

Проекты для клиентов - это отношения 1: n.Один проект всегда принадлежит определенным клиентам, но, конечно, у клиента может быть несколько активных проектов.

Отношение людей к клиентам - это отношение: m, но оно ограничено проектом для клиента, а люди - для назначения клиентов.

Подробнее: некоторые из наших сотрудников работают на нескольких клиентов, но только на несколько проектов этих клиентов.

Скажем, у клиента А есть проекты 1,2,3, а у клиента Б - проекты 4,5,6.

Теперь Фред работает для клиента A в проекте 1 и для клиента B в проектах 5 и 6. Тим вместо этого работает для клиента A в проекте 2,3 и для клиента B в проекте 6. Наш специальныйпарень Ник работает только для клиента B, но в настоящее время не назначен ни на один проект.Заказчик может назначить его для проекта позже.

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

Поэтому мне нужно спроектировать мои таблицы так, чтобы модель базы данных гарантировала, что невозможно назначить Ника проекту 1, 2 или 3 без предварительного назначения его клиенту A?

Спасибо за любые идеи:)

Answer 1

Вот пример в SQL:

CREATE TABLE Project
 (ProjectID INT NOT NULL PRIMARY KEY, CustomerID INT NOT NULL,
 UNIQUE (ProjectID, CustomerID));

CREATE TABLE EmployeeProject
 (EmployeeID INT NOT NULL, ProjectID INT NOT NULL, CustomerID INT NOT NULL,
  FOREIGN KEY (EmployeeID, CustomerID) REFERENCES EmployeeCustomer (EmployeeID, CustomerID),
  FOREIGN KEY (ProjectID, CustomerID) REFERENCES Project (ProjectID, CustomerID),
  PRIMARY KEY (EmployeeID, ProjectID));

Answer 2

В этой модели Project является подтипом Assignment. Например, назначение может быть типа P = project или O = Open.

• Каждое задание (открытое или проектное) принадлежит только одному клиенту.
• На одном назначении могут работать несколько сотрудников в разные периоды времени.

Ограничение переназначения должно обрабатываться в бизнес-логике (прикладной уровень). Переход от открытого назначения к проекту может быть выполнен путем закрытия периода для этого назначения сотрудника (EndDate) и определения нового назначения type = project для этой комбинации сотрудник-клиент.