Veritabanı tasarımı: Aynı tablo ile iki 1'den birçok ilişkiye

Ben her ikisi de 0, 1 veya birçok chequing hesabı olabilir iki farklı tablo Kişi ve Corporation ile ilgili olması gereken bir tablo Chequing_Account (bütçe, iban numarası ve hesabın diğer ayrıntılarını içeren) bir durum modellemek zorunda.

Başka bir deyişle, aynı tablo ile iki 1-çok ilişkim var Chequing hesabı

Bu sorun için normalleştirme gerekliliklerine uygun çözümler duymak istiyorum. Etrafımda duyduğum çoğu çözüm:

1) hem Person'in hem de Corporation'ın ait olduğu ortak bir varlık bulun ve bu ve Chequing_Account tablosu arasında bir bağlantı tablosu oluşturun, bu benim durumumda mümkün değildir ve bu sorunu değil, genel sorunu çözmek istesem bile.

2) İki varlığı Chequing Hesaplarıyla ilişkilendiren PersonToChequingAccount ve CorporationToChequingAccount olmak üzere iki bağlantı tablosu oluşturun. Ancak iki kişinin aynı chequing hesabına sahip olmasını istemiyorum ve bir chequing hesabını paylaşmak için gerçek bir kişi ve bir şirkete sahip olmak istemiyorum! bu resme bak

3) Chequing Hesabında, Corporation ve Gerçek Kişiye işaret eden iki yabancı anahtar oluşturun, ancak bu nedenle bir Kişinin ve Şirketin birçok chequing hesabına sahip olabileceğini zorunlu kılmakla birlikte, her ChequingAccount satırı için her iki ilişkinin de Şirket ve gerçek kişi, çünkü bir çek hesabı ya bir şirket ya da gerçek bir kişidir. bu resme bak

Bu sorunun daha temiz bir çözümü var mı?

İlişkisel veritabanları bu durumu mükemmel bir şekilde ele almak için inşa edilmemiştir. Sizin için neyin en önemli olduğuna karar vermeli, sonra da takaslarınızı yapmalısınız. Birkaç hedefiniz var:

• Üçüncü normal formu koru
• Referans bütünlüğünü koruyun
• Her hesabın bir şirkete veya gerçek bir kişiye ait olduğu kısıtlamasını koruyun.
• Verileri basit ve doğrudan alma yeteneğini koruyun

Sorun şu ki, bu hedeflerin bazıları birbiriyle rekabet ediyor.

Alt Yazma Çözümü
Hem şirketleri hem de kişileri içeren bir süper tür oluşturduğunuz bir alt yazma çözümü seçebilirsiniz. Bu süper-tip muhtemelen alt-tipin doğal anahtarının bir bileşik anahtarına ve bir bölümleme özelliğine (örneğin customer_type) sahip olacaktır. Bu normalleşmeye kadar iyidir ve referans bütünlüğünü ve kurumların ve kişilerin birbirini dışlayan kısıtlarını uygulamanızı sağlar. Sorun, customer_typehesabın hesabına ne zaman katıldığınıza bağlı olarak her zaman şube açmanız gerektiğinden, bu durum veri alımını zorlaştırır . Bu muhtemelen UNIONsorgunuzda çok sayıda tekrarlanan SQL kullanmak ve kullanmak demektir .

İki Yabancı Anahtar Çözümü
Hesap tablonuzda, biri şirkete diğeri de kişi olmak üzere iki yabancı anahtarı saklayabileceğiniz bir çözüm seçebilirsiniz. Bu çözüm aynı zamanda referans bütünlüğünü, normalleştirmeyi ve karşılıklı münhasırlığı korumanızı sağlar. Ayrıca, alt yazma çözümüyle aynı veri alma dezavantajına sahiptir. Aslında, bu çözüm, birleştirme mantığınızı "daha erken" dallandırma problemine girmeniz dışında, alt-yazma çözümü gibidir.

Bununla birlikte, birçok veri modelcisi, karşılıklı münhasırlık kısıtlamasının uygulanması nedeniyle bu çözümü alt yazma çözümünden daha düşük olarak değerlendirecektir. Alt yazma çözümünde, karşılıklı münhasırlığı uygulamak için anahtarları kullanırsınız. İki yabancı anahtar çözümünde bir CHECKkısıtlama kullanırsınız . Çek kısıtlamalarına karşı haksız önyargısı olan bazı insanlar tanıyorum. Bu insanlar, kısıtlamaları anahtarlarda tutan çözümü tercih ederler.

"Denormalized" Bölümleme Öznitelik Çözümü
Chequing hesap tablosunda tek bir yabancı anahtar sütunu tuttuğunuz ve yabancı anahtar sütununu nasıl yorumlayacağınızı söylemek için başka bir sütun kullandığınız başka bir seçenek daha var (RoKaOwnerTypeIDkolonu). Bu esas olarak alt tablolamadaki süper tip tabloyu, alt tabloya bölümleme niteliğini denormalize ederek ortadan kaldırır. (Bölümleme özniteliği birincil anahtarın bir parçası olduğu için bunun biçimsel tanıma göre kesinlikle "denormalizasyon" olmadığını unutmayın.) Bu çözüm, aynı şeyi yapmak için fazladan bir tabloya sahip olmaktan kaçındığı için oldukça basit görünüyor ve yabancı anahtar sütunlarının sayısını bire indirir. Bu çözüm ile sorunu alma mantığın dallanma önlemek etmez ve dahası, bu sürdürmek için izin olmamasıdır deklaratif bilgi tutarlılığı. SQL veritabanları, birden çok üst tablodan biri için olan tek bir yabancı anahtar sütununu yönetme yeteneğine sahip değildir.

Paylaşılan Birincil Anahtar Alan Adı Çözümü
İnsanların bazen bu sorunla ilgilenmesinin bir yolu, bir alt türe veya diğerine ait olsun, herhangi bir kimlik için karışıklık olmaması için tek bir kimlik havuzu kullanmaktır. Bu, bir banka senaryosunda doğal olarak işe yarayacaktır, çünkü hem bir şirkete hem de gerçek bir kişiye aynı banka hesap numarasını vermeyeceksiniz. Bunun avantajı, bir bölümleme özelliğine ihtiyaç duyulmamasıdır. Bunu süper tip bir tabloyla veya tablo olmadan yapabilirsiniz. Süper tür bir tablo kullanmak, benzersizliği zorunlu kılmak için bildirici kısıtlamalar kullanmanızı sağlar. Aksi takdirde, bunun usule uygun olarak uygulanması gerekir. Bu çözüm normalleştirilmiştir, ancak süper tür tablosunu tutmadığınız sürece bildirici başvuru bütünlüğünü korumanıza izin vermez. Hala karmaşık geri alma mantığından kaçınmak için hiçbir şey yapmıyor.

Bu nedenle, tüm kurallara uyan temiz bir tasarıma sahip olmanın ve aynı zamanda veri alımınızı basit tutmanın gerçekten mümkün olmadığını görebilirsiniz. Ödüllerinizin nerede olacağına karar vermelisiniz.