Ligimin dışında bir veritabanı tasarım sorunuyla karşılaştım ve benim DBA gurum yangın tatbikatlarında kapalı.
Özünde, aşağıdaki birincil anahtar (kısaltma için PK) içeren bir tablo var:
child_id integer
parent_id integer
date datetimechild_idve parent_idvarlık tablolarının yabancı anahtarlarıdır. "Alt" tablonun kendisi de "üst" tablonun yabancı bir anahtarını içerir ve her biri, her child_idzaman parent_idyukarıdaki tablonun beklediği ile aynıdır . Aslında, ikisini senkronize tutan bazı ekstra kodlar olduğu ortaya çıkıyor.
Bu da bu aşırı hevesli normalleşme acemisine "Bunun yerine işten çıkarmayı kaldırmalıyım!"
Aşağıdakilere ayrıştım:
Table_1 PK:
child_id integer
date datetime
Table_2 PK:
parent_id integer
date datetime
Table_3: (already exists)
child_id integer PRIMARY KEY
parent_id integer FOREIGN KEYVe bu adamlara doğal yolla katıldığımda orijinal masayı kurtarıyorum. Bunu 5NF yapan benim anlayışım.
Ancak, şimdi gizli bir iş kuralı olduğunun farkındayım.
Normalde, belirli child_idbir tarihle ilişkili tarihler, karşılık gelen tarihlerin bir alt kümesi olmalıdır parent_id. İlk tablonun bu kuralı uyguladığını görebilirsiniz.
Ayrışmam kuralı uygulamıyor, çünkü tarihler çok büyüyene kadar Tablo 1'e özgürce ekleyebilirsiniz.
Bu da beni şu sorulara götürüyor:
Bu ayrışma 5NF mi? Ekleme anormalliklerine izin verdiğini söylesem de, kendisi de bu kılavuzu takip eden Wiki örneğini takip ediyor gibi görünüyor . "Vurgu mayın" ifadesi "tüm gerçek gerçekleri üç ayrı kayıt türünden oluşan normalleştirilmiş bir formdan yeniden oluşturabiliriz" ifadesi bana özel bir duraklama veriyor, çünkü ne kadar çöp
Table_1pompaladığım önemli değil, doğal birleşim hala görmezden geliyor.Diyelim ki bu ayrışmayı sevmiyorum (sevmiyorum). Pratik çözümün tabloyu ve kodu olduğu gibi bırakmak olduğunu serbestçe kabul ediyorum. Fakat teoride, ben ilk tablodan kurtulmak şekilde ve ayrıştırmak / veya kısıtlamaları eklemek için bir yol yoktur ve benim iş kurallarını korumak?