Bileşik birincil anahtarlarda boş değer atanabilir sütunlarda sorun nedir?

ORACLE, birincil anahtarı içeren sütunların hiçbirinde NULL değerlere izin vermez. Görünüşe göre aynı durum diğer "işletme düzeyindeki" sistemlerin çoğu için de geçerli.

Aynı zamanda, çoğu sistem null yapılabilir sütunlarda benzersiz kısıtlamalara da izin verir .

Neden benzersiz kısıtlamaların NULL'leri olabilir, ancak birincil anahtarlar olamaz? Bunun temel bir mantıksal nedeni var mı, yoksa bu daha çok teknik bir sınırlama mı?

Birincil anahtarlar, satırları benzersiz şekilde tanımlamak içindir. Bu, bir anahtarın tüm parçalarını girişle karşılaştırarak yapılır.

Tanım başına NULL, başarılı bir karşılaştırmanın parçası olamaz. Kendisiyle ( NULL = NULL) bir karşılaştırma bile başarısız olacaktır. Bu, NULL içeren bir anahtarın çalışmayacağı anlamına gelir.

Ek olarak, isteğe bağlı bir ilişkiyi işaretlemek için yabancı anahtarda NULL'a izin verilir. ^(*) PK'de de buna izin vermek bunu bozacaktır.

^(*) Bir uyarı: Null yapılabilir yabancı anahtarlara sahip olmak temiz ilişkisel veritabanı tasarımı değildir.

İki varlık varsa Ave isteğe bağlı olarak ilişkilendirilebilecek Byerler varsa , temiz çözüm bir çözüm tablosu oluşturmaktır (diyelim ). Bu tablo bağlayacak ile : Orada ise olan bir ilişki var ise o zaman, bir kayıt içerecektir değil öyle değil mi o zaman.ABABAB

Birincil anahtar, bir tablodaki her satır için benzersiz bir tanımlayıcı tanımlar : bir tablonun birincil anahtarı olduğunda, ondan herhangi bir satırı seçmek için garantili bir yolunuz olur.

Benzersiz bir kısıtlamanın her satırı tanımlaması gerekmez; sadece bir satırın sütunlarında değerler varsa , o zaman bunların benzersiz olması gerektiğini belirtir . Bu, her satırı benzersiz olarak tanımlamak için yeterli değildir , bu da birincil anahtarın yapması gereken şeydir.

Temel olarak konuşursak, çok sütunlu bir birincil anahtardaki NULL ile hiçbir şey yanlış değildir. Ancak bir tanesine sahip olmak, tasarımcının muhtemelen istemediği sonuçlara sahiptir, bu yüzden bunu denediğinizde birçok sistem hata verir.

Bir dizi alan olarak depolanan modül / paket sürümlerini düşünün:

CREATE TABLE module
  (name        varchar(20) PRIMARY KEY,
   description text DEFAULT '' NOT NULL);

CREATE TABLE version
  (module      varchar(20) REFERENCES module,
   major       integer NOT NULL,
   minor       integer DEFAULT 0 NOT NULL,
   patch       integer DEFAULT 0 NOT NULL,
   release     integer DEFAULT 1 NOT NULL,
   ext         varchar(20),
   notes       text DEFAULT '' NOT NULL,
   PRIMARY KEY (module, major, minor, patch, release, ext));

Birincil anahtarın ilk 5 öğesi, bir yayın sürümünün düzenli olarak tanımlanmış parçalarıdır, ancak bazı paketler genellikle tamsayı olmayan özelleştirilmiş bir uzantıya sahiptir ("rc-foo" veya "vanilya" veya "beta" gibi veya başka biri ne için olursa olsun) kime dört alanları) hayal olabilir yetersizdir. Bir paketin bir uzantısı yoksa yukarıdaki modelde NULL olur ve işleri böyle bırakarak herhangi bir zarar verilmez.

Ama ne olduğunu bir BOŞ? Bilgi eksikliğini , bilinmeyeni temsil etmesi gerekiyordu . Bununla birlikte, belki bu daha mantıklıdır:

CREATE TABLE version
  (module      varchar(20) REFERENCES module,
   major       integer NOT NULL,
   minor       integer DEFAULT 0 NOT NULL,
   patch       integer DEFAULT 0 NOT NULL,
   release     integer DEFAULT 1 NOT NULL,
   ext         varchar(20) DEFAULT '' NOT NULL,
   notes       text DEFAULT '' NOT NULL,
   PRIMARY KEY (module, major, minor, patch, release, ext));

Bu versiyonda, başlığın "ext" kısmı NULL DEĞİLDİR, ancak öntanımlı olarak boş bir dizgedir - anlamsal olarak (ve pratik olarak) NULL'dan farklıdır. NULL bilinmeyen bir dizge iken boş dizge "mevcut olmayan bir şeyin" kasıtlı bir kaydıdır. Diğer bir deyişle, "boş" ve "boş" farklı şeylerdir. "Burada bir değerim yok" ile "Buradaki değerin ne olduğunu bilmiyorum" arasındaki fark bu.

Sürüm uzantısı olmayan bir paketi kaydettiğinizde , bir uzantıdan yoksun olduğunu bilirsiniz , bu nedenle boş bir dize aslında doğru değerdir. Bir NULL, yalnızca bir uzantısı olup olmadığını bilmiyorsanız veya ne olduğunu bildiğiniz halde ne olduğunu bilmiyorsanız doğru olacaktır. Dize değerlerinin norm olduğu sistemlerde bu durumla başa çıkmak daha kolaydır, çünkü 0 veya 1 eklemek dışında "boş bir tamsayıyı" temsil etmenin yolu yoktur, bu daha sonra yapılan herhangi bir karşılaştırmada toplanır (ki kendi sonuçları) *.

Bu arada, Postgres'te her iki yol da geçerlidir ("kurumsal" RDMBS'leri tartıştığımız için), ancak karışıma bir NULL attığınızda karşılaştırma sonuçları biraz değişebilir - çünkü NULL == "bilmiyorum" yani hepsi NULL içeren bir karşılaştırmanın sonuçları, bilinmeyen bir şeyi bilemeyeceğiniz için NULL olur. TEHLİKE! Bunu dikkatlice düşünün: Bu, NULL karşılaştırma sonuçlarının bir dizi karşılaştırma yoluyla yayıldığı anlamına gelir . Bu, sıralarken, karşılaştırırken vb. İnce hataların kaynağı olabilir.

Postgres, yetişkin olduğunuzu varsayar ve bu kararı kendiniz verebilir. Oracle ve DB2, aptalca bir şey yaptığınızın farkında olmadığınızı varsayar ve bir hata verir. Bu genellikle doğru olan şeydir, ancak her zaman değil - aslında bilmiyor olabilirsiniz ve bazı durumlarda bir NULL'a sahip olabilirsiniz ve bu nedenle, anlamlı karşılaştırmaların imkansız olduğu bilinmeyen bir öğeyle bir satır bırakmak doğru davranıştır.

Her durumda, tüm şema boyunca izin verdiğiniz NULL alanların sayısını ortadan kaldırmaya çalışmalısınız ve bir birincil anahtarın parçası olan alanlar söz konusu olduğunda bunu iki katına çıkarmalısınız. Vakaların büyük çoğunluğunda, NULL sütunlarının varlığı, normalize edilmemiş (kasıtlı olarak normalleştirilmesinin aksine) şema tasarımının bir göstergesidir ve kabul edilmeden önce çok düşünülmesi gerekir.

[* NOT: Tamsayıların birleşimi olan özel bir tür ve "bilinmeyen" yerine anlamsal olarak "boş" anlamına gelen "alt" bir tür oluşturmak mümkündür. Ne yazık ki bu, karşılaştırma işlemlerinde biraz karmaşıklık getirir ve genellikle gerçekten doğru tipte olmak pratikte çabaya değmez, NULLçünkü ilk başta birçok değere izin verilmemelidir . Bununla birlikte, RDBMS'lerin "değer yok" anlamını "bilinmeyen değer" ile rasgele bir şekilde karıştırma alışkanlığını önlemek için varsayılan bir BOTTOMtür içermesi harika olurdu NULL. ]

NULL == NULL -> yanlış (en azından DBMS'lerde)

Bu nedenle, gerçek değerlere sahip ek sütunlarla bile NULL değeri kullanarak herhangi bir ilişkiyi alamazsınız.

Tony Andrews'un cevabı makul. Ancak gerçek cevap, bunun ilişkisel veritabanı topluluğu tarafından kullanılan bir kural olduğu ve bir zorunluluk olmadığıdır. Belki bu iyi bir kongredir, belki de değildir.

Herhangi bir şeyi NULL ile karşılaştırmak UNKNOWN (3. gerçek değeri) ile sonuçlanır. Boşluklarla önerildiği gibi, eşitlikle ilgili tüm geleneksel bilgelik pencereden dışarı çıkar. İlk bakışta böyle görünüyor.

Ancak bunun zorunlu olduğunu düşünmüyorum ve SQL veritabanları bile NULL'un karşılaştırma için tüm olasılıkları yok ettiğini düşünmüyor.

Veritabanınızda SELECT * FROM VALUES (NULL) UNION SELECT * FROM VALUES (NULL) sorgusunu çalıştırın

Gördüğünüz şey, NULL değerine sahip bir özniteliğe sahip yalnızca bir demettir. Böylece sendika burada iki NULL değerini eşit olarak kabul etti.

3 bileşeni olan bir bileşik anahtarı 3 öznitelik (1, 3, NULL) = (1, 3, NULL) <=> 1 = 1 VE 3 = 3 VE NULL = NULL olan bir tuple ile karşılaştırırken Bunun sonucu BİLİNMİYOR .

Ancak yeni bir tür karşılaştırma operatörü tanımlayabiliriz, örneğin. ==. X == Y <=> X = Y VEYA (X NULL VE Y NULL)

Bu tür bir eşitlik operatörüne sahip olmak, boş bileşenli bileşik anahtarları veya boş değerli bileşik olmayan anahtarları sorunsuz hale getirir.

Hala bunun teknikliğin getirdiği temel / işlevsel bir kusur olduğuna inanıyorum. Bir müşteriyi tanımlayabileceğiniz isteğe bağlı bir alanınız varsa, şimdi boş bir değeri kırmanız gerekir, çünkü NULL! = NULL, özellikle zarif değil, ancak bu bir "endüstri standardı"