Нормализация схеме с транзитивным отношением

Question

мне нужно создать три модели, как это:

Company 
* name ... 

Order 
* amount ... 

OrderGroup 
* description ... 

Ордер всегда принадлежит к компании, даже если он не принадлежит ни к одной группе. Группа всегда принадлежит Компании, даже если она не имеет ордеров.

• Приказ принадлежит 0 или 1 группе.
• Группа состоит из от 0 до n ордеров.
• Группа A принадлежит Компании, поэтому все Заказы в ее Группе также должны принадлежать к той же Компании.

Как создать схему для этого?

Если добавить только добавить company_id и group_id заказа, база данных не знает, что они связаны и мое заявление может ввести несоответствие:

Order 1, company1, group1 
Order 2, company2, group1 #should not be possible 

Если добавить company_id в группу, а не на заказ, есть проблема с Приказы, которые не принадлежат к какой-либо группе:

Order 1, Group=null #don't know the company 

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

Answer 1

Ограничения (включая ключи кандидатов, внешние ключи и мощности) не требуются для запросов. Они отражают ограничения на возможные значения базовых таблиц и результатов запроса. Мы сообщаем СУБД об ограничениях, чтобы исключить невозможные ситуации. Внешние ключи не «соединяют» таблицы для запросов; любые две таблицы могут быть сфокусированы.

Если предположить, что каждый заказ и группа имеют компанию и ORDER и GROUP (IDS) являются уникальными, прямолинейным дизайном является:

Company -- company COMPANY has name NAME ... 
    PRIMARY KEY (COMPANY) 
Order -- company COMPANY's order ORDER is for amount AMOUNT ... 
    PRIMARY KEY (ORDER) 
    FOREIGN KEY (COMPANY) REFERENCES Company (COMPANY) 
OrderGroup -- company COMPANY's order group GROUP has description DESCRIPTION ... 
    PRIMARY KEY (GROUP) 
    FOREIGN KEY (COMPANY) REFERENCES Company (COMPANY) 
Contains -- order group GROUP contains order ORDER 
    PRIMARY KEY (GROUP, ORDER) 
    FOREIGN KEY (GROUP) REFERENCES Company (GROUP) 
    FOREIGN KEY (ORDER) REFERENCES Order (ORDER) 

реляционного ограничение внешнего ключа говорит, что список значений в subrow в таблице должно появляться в другом месте как список значений в подземельной таблице, являющейся ключом-кандидатом. (Ограничение SQL FOREIGN KEY ССЫЛКИ: суперкомпьютер: UNIQUE NOT NULL или PRIMARY KEY.)

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

Contains -- for company COMPANY order group GROUP contains order ORDER 
    FOREIGN KEY (COMPANY, GROUP) REFERENCES OrderGroup (COMPANY, GROUP) 
    FOREIGN KEY (COMPANY, ORDER) REFERENCES Order (COMPANY, ORDER) 
-- add to Orders 
    UNIQUE NOT NULL (COMPANY, ORDER) 
-- add to OrderGroup 
    UNIQUE NOT NULL (COMPANY, GROUP) 

(Это причуда SQL, что вы должны объявить ссылки списки столбцов, как UNIQUE/PK даже хотя каждый список включает в себя меньший объявлено UNIQUE/список PK столбцов, что означает, что в том числе списка должен быть также UNIQUE/PK.)

PS выше было написано, прежде чем отредактирована верхней граница одной группы в порядок. Если заказ может отображаться не более чем в одной группе, то есть Содержит PK (ЗАКАЗ). Поскольку порядок может появляться не более одного раза, он может отображаться только в одной группе. (Или у вас может быть дизайн, в котором вы отключаете Contains, и добавьте NULLable GROUP для заказа с FK (КОМПАНИЯ, ГРУППА) в группу.)