SQL'de bir sıfıra veya bir ilişkiye uygulama

Diyelim ki bire bir veya sıfır (1-0..1) bir ilişki olan bir senaryo için bir veritabanı tasarlıyorum. Örneğin:

• Bir dizi Kullanıcı vardır ve bazı Kullanıcılar da Müşteri olabilir .

Böylece, karşılık gelen iki tabloyu yarattım usersve customers...

… Bu durumu belirli bir SQL platformunda temsil etmenin ve uygulamanın en iyi yolu nedir? İki olası çözümü düşündüm:

1. Olarak userstablo eklemek customeriçin bir yabancı anahtar referans olarak mevcut olabilir sütunu customersya da bir NULLişaret.

2. Tabloya, customerstabloya işaret eden bir usersütun ( UNIQUEkısıtlama ile ayarlanmış) ekleyin users.

Bazı forumlarda zaten benzer bir soru sordum, ancak cevap temelde “neye ihtiyacınız varsa”, “neyi uygun buluyorsanız” idi. Bu tür bir cevabı sevmiyorum. Bunun yerine ciddi bir DB teorisi parçası, iyi kurulmuş bir cevap istiyorum. 1-0..1 ilişkilerini nereden okuyabilirim?

DB teorisinin ciddi bir parçasını istiyorum

Modern ilişkisel teori , seçenek 1'inizi hemen geçersiz hale getirecek gibi görünen null'ları reddeder . Ancak, bu strawman varsayılan null'u varsayılan bir değerle değiştirerek ortadan kaldırılabilir, örneğin, yalnızca "müşteri değil" modelini açıkça oluşturmak için oluşturulan bir "kukla" müşteri yazışma.

Seçenek 2'nizin teorik olarak en sağlam olduğunu düşünüyorum, çünkü değiştirilmiş seçenek 1'den farklı olarak, ilişkiler altıncı normal formda (6NF) olabilir, projeksiyon-birleştirme normal formu ve ulaşılabilir en yüksek normal form olabilir.

Ayrıca, bir ilişkinin EITHER bir varlığın VEYA varlıklar arasındaki ilişkiyi modellemesi gerektiğini, ancak her ikisi de benim için mantıklı görünmediğini belirten bir tasarım kuralını duydum. Yine, bu seçenek 2'yi tercih eder. Ancak, bu başparmak kuralını yıllar önce duydum, hatırlamıyorum ve ciddi bir teorik temel sunamazsınız (yukarıda belirtildiği gibi 6NF dışında).

Size kısmen doğru cevap verildi. Gerçek cevap veri modelinizden ve nasıl normalleştirildiğinden gelir. Bir anahtar ilişkiye nasıl ulaşacağınızdır:

• customersTablo için dikkate alanlarda oluşur usersmüşteri kavramına aittir ve Ayrıca, müşteri (kullanıcı alt tipi) olmadıkça boş olan masaya. Bu durumda customerstablo, birincil anahtarı tablodan devralır users. (Çakışabilen veya örtüşmeyen birden çok alt tür mümkündür.)

• customersTablo müşteri kavramına ilişkin alanlarda oluşur, ancak şart kullanıcı kavramı. Müşteri güçlü bir tablodur ve kullanıcı konseptine bağlı değildir. ( usersTablonun kaldırılması, müşteri tablosunun tasarımını önemli ölçüde etkilemez.) Bu durumda, müşteri tablosunun kendi birincil anahtarı olur.

Sahip olduğunuz, üst sınırın 1 olduğu isteğe bağlı bir-çok ilişkisinin özel bir örneğidir. Her iki taraftan da düşünün: Bir kullanıcının birden fazla müşterisi olması veya bir müşterinin birden çok kullanıcısı olması mümkün müdür? Öyleyse, verilerinizi yeniden değiştirmeniz gerekir.

user-idYabancı anahtarın customerstabloya eklenmesi, çok sayıda (üst sınır 1) ilişkiyi doğru şekilde eşleştirdiği ve boş bir alandan kaçındığı için daha iyi bir seçim olarak düşünülebilir. Üst sınırı uygulamak için yabancı anahtar endeksinin benzersiz olması gerekir. Birincil anahtar user-id.

Tabloya customer-idisteğe bağlı bir yabancı anahtar eklemek users, ilişkide 1 üst sınırını zorlar, ancak bağımlılığı tersine çevirir.

Biraz daha karmaşık ama esnek bir yaklaşım düşündünüz mü? Üst tablo "kişi" dir (veya ne kadar karmaşık olmasını istediğinize bağlı olarak "varlık" tır). Daha sonra müşteri masası ve kullanıcı masasının her birinin kişi masasına bir FK'si vardır. Kişi tablosunda kişisel ayrıntılar bulunurken, müşteri ve kullanıcı tablolarında yalnızca bir kullanıcı veya müşteriyle ilişkilendirilmiş özellikler bulunur. Çoğu zaman adresler (e-posta ve salyangoz postaları), telefon numaraları vb., Çoktan çoğa durumlara izin vermek için eşleme tabloları içeren ayrı tablolarda da temsil edilir. Bu, birkaç referans sitesinde bulabileceğiniz nispeten yaygın bir modeldir.