Bir veritabanını modellerken zayıf varlıkları ne zaman kullanmalıyız?

12

Bu temel olarak zayıf varlıklar hakkında bir soru mu? Ne zaman kullanmalıyız? Nasıl modellenmelidirler?

Normal varlıklar ile zayıf varlıklar arasındaki temel fark nedir? Zayıf varlıklar Etki Alanına Dayalı Tasarım yaparken değer nesnelerine karşılık geliyor mu?

Konu ile ilgili soruyu burada tutmaya yardımcı olmak için Wikipedia'dan alınan ve bu soruyu cevaplamak için kullanabileceğiniz bir örnek : resim açıklamasını buraya girin

Bu örnekte OrderItemzayıf bir varlık olarak modellenmiştir, ancak bunun neden normal bir varlık olarak modellenemediğini anlayamıyorum.
Başka bir soru, normal veya zayıf bir varlık olan sipariş geçmişini (yani durumundaki değişiklikleri) izlemek istersem ne olur?

— Songo
kaynak

10

Resmi olarak "zayıf" bir varlık aşağıdaki özelliklere sahiptir.

1.  It is existence-dependent on another entity, i.e., 
    it cannot exist without the entity with which it has a relationship.

2.  It inherits at least part of it's primary key from the entity to which 
    it is related. 


    i.e. -> A weak entity's primary key must be a composite key that includes 
       the primary key of the entity on which it is existence-dependent.

Pratikte açık bir şekilde kendi başına "zayıf" bir varlık yapmaya karar vermeyeceğinizi söyleyebilirim ; bunun yerine verileri modellemeye çalıştığınız şeyi temsil edecek şekilde yapılandırırsınız. Bunu yaptıktan sonra, belirli bir varlığa bakarsanız ve "zayıf" bir varlığın özelliklerine sahipse, bir nedenden dolayı bunu açıkça veya uğruna çağırmanız gerektiğini düşünüyorsanız, bunu uygun şekilde belgeleyebilir veya diyagram haline getirebilirsiniz. formalitenin.

— Ed Hastings
kaynak

hmmm peki ya örneğim? burada bir OrderItema ait olmadan Orderhayır orderItemsolamaz çünkü bağlıdır order, ama neden ItemLineNumbersadece bir öğeyi tanımlamak için kullanamıyorum ?! Aslında, tekliği sağlamak ve iki varlığı birbirine bağlamak için yabancı bir anahtar kullanmak ItemLineNumberiçin otomatik olarak üretilmiş olabilir mi ?! intorderID

— Songo

2

OrderItem öğenizi benzersiz bir şekilde tanımlayan sıralı bir kimliğe sahip olarak tanımlarsanız ve OrderId anahtarın bir parçası değilse, OrderItems'i birinci derece vatandaşlar olarak görürsünüz ve gerçekten zayıf bir varlığınız yoktur. İsterseniz OrderItems için ayrı ayrı FK tablolar olabilir; zaten OrderItems almak için bir OrderId olması gereksizdir. Öte yandan OrderItem'i OrderId ve Order ile ilgili bir sequId (veya benzeri) ile anahtarladıysanız, zayıf bir varlığınız olur ve tek tek satır öğeleri yalnızca OrderId ve sequIId kullanılarak referanslanabilir olur. Kullanım amacına uygun olarak model kullanımı.

— Ed Hastings

2

Ayrıca, teğetsel bir yorum, her tabloya kendi sıralı birincil anahtarını vermek ve tek alanlı PK-> FK ilişkileriyle ilişkileri olabildiğince basit tutmak çok cazip olabilir. Özellikle basit veritabanları için harikadır ve akıl yürütmesi kolaydır. Bununla birlikte, daha karmaşık ve / veya karmaşık ilişkileri modellerken kompozit anahtarlar çok kullanışlı hale gelir ve nüansları modellemek için size daha fazla seçenek sunar.

— Ed Hastings

1

Bir OrderItemsipariş veya ürün olmadan var olamaz. Dolayısıyla bağımlılıkları kontrol ettiği için zayıftır.

Örneğin siparişi kaldırırsanız, öğenin nereye gönderileceğini bilmenin bir yolu yoktur. Ya da ürünü kaldırırsanız ne göndereceğinizi bilmiyorsunuz.

— jgauffin
kaynak

-1

Yukarıdaki şemadaki anlayışım gereği, iki varlık / tabloyu bir yani sipariş ve sipariş öğesi yerine eklediler, böylece iki varlık tasarlandığında bilgiye erişim kolaylaşır. Ve sipariş kalemi sipariş varlığına bağımlı olduğundan zayıf bir varlık olarak kabul edilir. çünkü zayıf varlığın özelliği başka bir varlığa bağlı olmasıdır. Sipariş kalemi varlığını dahil etmiyorsanız, sipariş öğesinin fiyatını, indirimini nasıl bileceğinizi varsayalım. ve jgauffin'in söylediği gibi Siparişi kaldırırsanız, öğenin nereye gönderileceğini bilmenin bir yolu yoktur. Ya da ürünü kaldırırsanız ne göndereceğinizi bilmiyorsunuz.

ER diyagramı iş gereksinimlerine göre tasarlanmalıdır.

— Sam
kaynak

-1

Bakın, bir siparişin birçok sipariş öğesi vardır (çok değerli öznitelik). Böylece kurala göre ayrı bir tablo oluştururuz.

Şimdi, 2 müşterinin aynı siparişe sahip olduğunu varsayalım. Her ikisi de iPhone'u aynı fiyat, indirim, aynı tarihte vb. Bu yüzden ideal olarak, sipariş ilişkisinde iPhone sırası için iki tam tuples olmalıdır. Ancak bir ilişkinin kısıtlamasına göre, tüm tupeller benzersiz olmalıdır. Şimdi iki siparişi şu ana kadar aynı item_line_number.no problemiyle ilişkilendirelim. Şimdi müşteri iptallerinden birini düşünün. İPhone order. Ayrıca item_line_number tuple silinecek. Şimdi iPhone satın alan diğer müşteriler de M: 1 yazışmaları nedeniyle siliniyor. Sonuç olarak veritabanı tutarsız. Bu yüzden orderid olacak bir tanımlayıcı anahtar kullanıyoruz. Bu nedenle bir iPhone siparişi silmek veritabanı bozulmasına neden olmaz.

— VIVEK barbeküsü
kaynak