Geçişli yabancı anahtarlar eklemeli miyim?

Basit örnek: bir müşteri tablosu var.

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

Veritabanındaki diğer tüm veriler a bağlantılıdır Customer, bu nedenle örneğin Ordersşöyle görünür:

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

Şimdi aşağıdakilere bağlantı veren bir tablo olduğunu varsayalım 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)
)

Ben ayrı bir yabancı anahtar eklemek gerekir Itemsiçin Customers?

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

Bunun yerine bir resim: kesikli çizgi / FK mı eklemeliyim?

Düzenleme: Tablolara birincil anahtar tanımları ekledim. Yukarıda yaptığım noktada tekrarlamak istiyorum: veritabanı, doğruluk / güvenlik önlemi olarak müşteriler tarafından temelde silindi. Bu nedenle, tüm birincil anahtarlar customerkimliği içerir .

Bence bu orijinal bir fikir.

Dikkat edilmesi gereken ilk şey, LineItem tablosundaki PK'nin {CustomerID, CustomerOrderNo, OdrerItemNo}, örneğin iki tanesinin aksine üç özelliğine sahip olmasıdır .

Dikkat edilmesi gereken ikinci şey, idbir öznitelik için genel adın kullanılmasından kaynaklanan karışıklıktır .

CustomerOrderNoİdeal olarak (1,2,3 ..) her müşteri ve için olmalı OrderItemNoher sipariş için (1,2,3 ...).

Bu mümkünse güzeldir, ancak önceki maksimum değeri arayan bir sorgu gerektirir, örneğin

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

yüksek işlem hacmine sahip ortamlarda genellikle tercih edilmediğinden, bunların esasen aynı amaca hizmet eden bir otomatik artışla değiştirildiğini görmek yaygındır. Bu otomatik incremet'in artık benzersiz olduğu doğrudur, bu nedenle bir ANAHTAR olarak kullanılabilir - ancak bunun için gerekli bir uzlaşma olarak bakmayı seçebilirsiniz OrderItemNo.

Yani, bazı yeniden adlandırma CustomerOrderNo -> OrderNove OrderItemNo-> ItemNoile bu modele gelebilirsiniz

Şimdi Orderaşağıdakilere bakarsanız benzersizdir

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

Bir FK olarak hizmet etmek üzere {CustomerID, OrderNo}yayıldığını unutmayın LineItem.

Biraz şaşıyorsanız, bu, örneğinize yakındır, ancak PKs {ItemNo} and {OrderNo}yalnızca - örneğinizdeki iki sütun PK'nin aksine.

Şimdi soru şu, neden böyle bir şeye sadeleştirmiyoruz?

Hangi iyi, ama tanıtır YOLU BAĞIMLILIK - Sen katılamaz LineItemile Customerdoğrudan kullanmalıdır Orderkatılmak içinde.

Mümkün olduğunda ilk vakayı tercih ederim - favorinizi seçersiniz. Ve tabii ki, doğrudan FK gerek yoktur LineItemiçin Customerbu üç durumda da.

"Öğe" doğrudan "müşteri" referans olmamalıdır, çünkü bu öğenin "sipariş" ima. Dolayısıyla, "öğeler" tablosunda "müşteri" sütunlarına ihtiyacınız olmayacak.

Ürünün müşteri ile olan ilişkisi mevcut yabancı anahtar ile sağlanır.

Orders.id bir kimlik sütunuysa, öğeleri kaldırmayı düşünün. Müşteri tamamen.