Haruskah saya menambahkan kunci asing transitif?

Contoh sederhana: ada meja pelanggan.

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

Semua data lain dalam database harus terhubung ke Customer, jadi misal Ordersterlihat seperti ini:

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

Misalkan sekarang ada tabel yang menghubungkan ke 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)
)

Haruskah saya menambahkan kunci asing terpisah dari Itemske Customers?

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

Sebagai gantinya gambar: haruskah saya menambahkan garis putus-putus / FK?

Sunting: Saya telah menambahkan definisi kunci utama ke tabel. Saya ingin mengulang kembali pada poin yang saya buat di atas: basis data pada dasarnya dibungkam oleh pelanggan, sebagai ukuran kebenaran / keamanan. Oleh karena itu, semua kunci utama berisi customerID.

Saya pikir ini adalah ide asli.

Hal pertama yang perlu diperhatikan adalah bahwa PK pada tabel LineItem memiliki tiga atribut {CustomerID, CustomerOrderNo, OdrerItemNo}, bukan hanya dua dalam contoh Anda.

Hal kedua yang perlu diperhatikan adalah kebingungan yang dihasilkan dari penggunaan idnama generik untuk atribut.

The CustomerOrderNoidealnya harus (1,2,3 ..) untuk setiap pelanggan dan OrderItemNo(1,2,3 ...) untuk setiap pesanan.

Yah, ini bagus jika memungkinkan, tetapi membutuhkan kueri yang mencari nilai maks sebelumnya, seperti

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

yang sering tidak disukai di lingkungan volume transaksi tinggi, jadi itu umum untuk melihat ini digantikan oleh kenaikan otomatis, pada dasarnya melayani tujuan yang sama. Memang benar bahwa incremet otomatis ini sekarang unik, sehingga dapat digunakan sebagai KUNCI - tetapi Anda dapat memilih untuk melihatnya sebagai kompromi yang diperlukan untuk OrderItemNo.

Jadi, dengan beberapa penggantian nama CustomerOrderNo -> OrderNodan OrderItemNo-> ItemNoAnda dapat tiba di model ini

Jadi sekarang jika Anda melihat Orderyang berikut ini adalah unik

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

Catatan yang {CustomerID, OrderNo}disebarkan ke LineItemuntuk melayani sebagai FK.

Jika Anda sedikit menyipit, ini dekat dengan contoh Anda, tetapi dengan PKs {ItemNo} and {OrderNo}hanya - yang bertentangan dengan dua PK kolom dari contoh Anda.

Sekarang pertanyaannya adalah, mengapa tidak menyederhanakan sesuatu seperti ini?

Yang baik-baik saja, tetapi memperkenalkan PATH DEPENDENCE - Anda tidak dapat bergabung LineItemdengan Customerlangsung, harus menggunakan Orderdalam bergabung.

Saya lebih suka case pertama jika memungkinkan - Anda memilih favorit Anda. Dan jelas, tidak ada kebutuhan untuk FK langsung dari LineItemke Customertiga kasus ini.

"Item" tidak boleh merujuk "pelanggan" secara langsung, karena ini tersirat oleh "pesanan" item. Jadi, Anda tidak memerlukan kolom "pelanggan" pada tabel "item" sama sekali.

Hubungan barang dengan pelanggan dipastikan dengan kunci asing yang ada.

Jika orders.id adalah kolom identitas, pertimbangkan untuk menghapus item.customer semuanya.