Моделирование иерархической структуры данных

Question

20120304 - Оптимизированный вопрос

Предположим, что мы имеем сущности R, D и Е, и эта реляционные кардинальностей

• R < п: т> Д
• D < 1 : n> E

Отображение этой спецификации является прямым, но у нас есть еще один r equirement:

• R < п: т> E

Side Состояние: E1 может получить только 'назначен' на R1, если E1 связан с некоторым D1 и это D1 связано R1.

К сожалению, даже если E2 связано с D2, связанным с R2 - E2, возможно, не связано с R2.

• Я ищу реляционную модель БД.
• Модель, которая не требует многократных обновлений, если D отсоединяется от Ra и повторно подключается к другому Rb. В этом случае все Es of D должны быть отделены от Ra и прикреплены к Rb тоже.

20120305 - Обход проблемы?

Друг предлагает создать сущность DxR, которая связывает ее D и ее R с помощью кортежа (D, R). Затем создайте отношение

• Dxr < п: т> E

Hm ...

20120302 - Оригинальный вопрос

Система состоит из зон верхнего уровня (Z). Зона может иметь несколько регионов (R).

Так называемые отделы (D) могут быть отнесены к регионам. Один отдел может быть назначен более чем одному региону, только если каждый регион принадлежит к другой зоне.

И, наконец, сотрудников (E) принадлежат к одному и только одному отделу.

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

Важно: Сотрудник не должен принадлежать всем регионам, к которым принадлежит его отдел.

Предположим, что в следующих графиках E1 принадлежит D1. Е1 также должен принадлежать к R1, но не принадлежит к R2 - хотя D1 принадлежит R1 и R2:

-  Z   Z 
- __|___  ___|___ 
- R1 R  R2 R 
- \_________/ 
-  D1   

Q: Пожалуйста предложить отношения структуру таблицы БД, которая моделирует выше спецификации?

Answer 1

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

Действительно интересная часть этих бизнес-правил это одна: (мой курсив)

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

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

create table ZONE 
(ID int not null 
, NAME varchar(50) not null 
, constraint PK_ZONE primary key clustered (ID) 
) 

create table REGION 
(ZONE_ID int not null 
, REGION_ID int not null 
, NAME varchar(50) not null 
, constraint PK_REGION primary key clustered (ZONE_ID, REGION_ID) 
, conttraint FK_REGION__ZONE foreign key (ZONE_ID) 
    references ZONE (ID) 
) 

create table DEPARTMENT 
(ID int not null 
, NAME varchar(50) not null 
, constraint PK_DEPARTMENT primary key clustered (ID) 
) 

create table EMPLOYEE 
(ID int not null 
, NAME varchar(50) not null 
, DEPT_ID int not null 
, constraint PK_EMPLOYEE primary key clustered (ID) 
, constraint FK_EMPLOYEE__DEPARTMENT foreign key (DEPT_ID) 
    references DEPARTMENT (ID) 
) 

Указанные таблицы являются довольно очевидными. Однако есть одна особенность: таблица REGION имеет составной первичный ключ, который включает FK в ZONE. Это полезно для распространения ограничения на то, что отделы должны быть разными внутри зоны.

Assigninging департаментов регионов требует пересечения таблицы:

create table DEPT_ASGT -- Department Assignment 
(REGION_ID int not null 
, DEPT_ID int not null 
, ZONE_ID int not null 
, constraint PK_DEPT_ASGT (REGION_ID, DEPT_ID) 
, constraint FK_DEPT_ASGT__REGION foreign key (ZONE_ID, REGION_ID) 
    references REGION (ZONE_ID, ID) 
, constraint FK_DEPT_ASGT__DEPARTMENT foreign key (DEPT_ID) 
    references DEPARTMENT (ID) 
, constraint UN_DEPT_ASGT__ZONES unique nonclustered (ZONE_ID, DEPT_ID) 
) 

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

Наконец, нам необходимо отобразить сотрудников на департаменты и в регионы. Это требует другого пересечения таблицы:

create table EMP_ASGT -- Employee Assignment 
(REGION_ID int not null 
, DEPT_ID int not null 
, EMPLOYEE_ID int not null 
, constraint PK_EMP_ASGT (REGION_ID, DEPT_ID, EMPLOYEE_ID) 
, constraint FK_EMP_ASGT__DEPT_ASGT (REGION_ID, DEPT_ID) 
    references DEPT_ASGT (REGION_ID, DEPT_ID) 
, constraint FK_EMP_ASGT__EMPLOYEE (EMPLOYEE_ID) refernces EMPLOYEE (ID) 
) 

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

Вот одно место, где требуется триггер или какая-либо другая процедурная логика. Вы должны убедиться, что EMPLOYEE.department_id остается совместимым с записями в EMP_ASGT. Вы можете попытаться подтолкнуть это к декларативной ссылочной целостности, сделав PK EMPLOYEE составным идентификатором и DEPT_ID, но это заставит вас решить, хотите ли вы нарушить 3NF или сделать изменения в вашем рабочем отделе процедурно уродливым. В конце концов, небольшой триггер, чтобы убедиться, что EMP_ASGT не противоречит EMPLOYEE.DEPT_ID, будет гораздо меньше проблем.