Чи слід додати перехідні зовнішні ключі?

Простий приклад: є таблиця клієнтів.

create table Customers (
  id integer,
  constraint CustomersPK primary key (id)
)

Усі інші дані в базі даних повинні посилатись на а Customer, наприклад, Ordersвиглядає так:

create table Orders (
  id integer,
  customer integer,
  constraint OrdersPK primary key (customer, id),
  constraint OrdersFKCustomers foreign key (customer) references Customers (id)
)

Припустимо, зараз існує таблиця, що посилається на Orders:

create table Items (
  id integer,
  customer integer,
  order integer,
  constraint ItemsPK primary key (customer, id),
  constraint ItemsFKOrders foreign key (customer, order) references Orders (customer, id)
)

Чи слід додати окремий зовнішній ключ від Itemsдо Customers?

...
constraint ItemsFKCustomers foreign key (customer) references Customers (id)

Замість цього зображення: чи слід додати пунктирну лінію / FK?

Редагувати: Я додав визначення таблиць первинного ключа до таблиць. Мені хотілося б повторно зазначити пункт, який я зазначив вище: база даних, в основному, є клієнтом, як міра коректності / безпеки. Тому всі первинні ключі містять customerідентифікатор.

Я думаю, що це оригінальна ідея.

Перше, що слід помітити, це те, що ПК у таблиці LineItem має три атрибути {CustomerID, CustomerOrderNo, OdrerItemNo}, на відміну від двох у вашому прикладі.

Друге, що слід зазначити, - плутанина, що виникає внаслідок використання загального idімені для атрибута.

В CustomerOrderNoідеалі вони повинні бути (1,2,3 ..) для кожного клієнта та OrderItemNo(1,2,3 ...) для кожного замовлення.

Ну, це приємно, якщо можливо, але потрібен запит, який шукає попереднє максимальне значення, наприклад

select max(CustomerOrderNo)
from Order 
where CustomerID = specific_customer ; 

що часто не є переважним у середовищах з великим обсягом транзакцій, тому звичайно бачити, що вони замінені автоматичним збільшенням, по суті служать одній і тій же цілі. Це правда, що цей автоматичний приріст тепер унікальний, тому він може використовуватися як КЛЮЧОВИЙ - але ви можете вирішити, щоб на нього розглядати як на необхідний компроміс для OrderItemNo.

Отже, з деяким перейменуванням CustomerOrderNo -> OrderNoта OrderItemNo-> ItemNoви можете прийти до цієї моделі

Отже, якщо ви подивитесь на Orderнаступне, це унікальне

{OrderNo}             -- PK
{CustomerID, OrderNo} -- superkey,  AK on the diagram.

Зауважте, що {CustomerID, OrderNo}він розповсюджується LineItemна службу як ФК.

Якщо ви трохи примружили, це близько до вашого прикладу, але PKs {ItemNo} and {OrderNo}лише - на відміну від двох ПК у стовпці з вашого прикладу.

Тепер питання полягає в тому, чому б не спростити щось подібне?

Що добре, але вводить PATH ЗАЛЕЖНІСТЬ - ви не можете приєднатися LineItemдо Customerбезпосередньо, повинні використовувати Orderв поєднанні.

Я вважаю за краще перший випадок, коли це можливо - ви вибираєте свою улюблену. І очевидно, що немає необхідності в прямому ФК від LineItemдо Customerцих трьох випадків.

"Елемент" не повинен посилатися на "замовника" безпосередньо, оскільки це має на увазі "замовлення" товару. Отже, стовпці "клієнт" у таблиці "позиції" вам взагалі не знадобляться.

Відношення товару до замовника забезпечується наявним зовнішнім ключем.

Якщо order.id - стовпець ідентичності, розгляньте питання про видалення items.customer.