Boyce–Codd normal formu

Boyce – Codd normal formu (veya BCNF veya 3.5NF), veritabanı normalleştirmesinde kullanılan normal bir formdur . Üçüncü normal formun (3NF) biraz daha güçlü bir versiyonudur. BCNF, 1974 yılında Raymond F. Boyce ve Edgar F. Codd tarafından, başlangıçta tanımlandığı şekliyle 3NF tarafından ele alınmayan belirli anormallik türlerini ele almak için geliştirilmiştir.[1]

Bir ilişkisel şema BCNF'de ise, diğer tür artıklık hala mevcut olsa da, işlevsel bağımlılığa dayalı tüm artıklık kaldırılmıştır. İlişkisel bir şema R, ancak ve ancak X → Y bağımlılıklarının her biri için aşağıdaki koşullardan en az biri geçerliyse Boyce – Codd normal biçimindedir:[2]

  • XY önemsiz bir işlevsel bağımlılıktır (Y ⊆ X),
  • X, R şeması için bir süperanahtardır.

Yalnızca nadir durumlarda, 3NF tablosu BCNF gerekliliklerini karşılamaz. Birden çok örtüşen aday anahtarı olmayan bir 3NF tablosunun BCNF'de olması garanti edilir.[3] İşlevsel bağımlılıklarının ne olduğuna bağlı olarak, iki veya daha fazla örtüşen aday anahtarı olan bir 3NF tablosu BCNF'de olabilir veya olmayabilir.

BCNF'yi karşılamayan bir 3NF tablosu örneği:

Bugünün kort kayıtları
Kort Başlangıç saati Bitiş saati Ücret türü
1 09:30 10:30 İndirimli
1 11:00 12:00 İndirimli
1 14:00 15:30 Standart
2 10:00 11:30 Özel-B
2 11:30 13:30 Özel-B
2 15:00 16:30 Özel-A
  • Tablodaki her sıra, bir tenis kulübündeki bir kort rezervasyonunu temsil eder. Bu kulübün 1 ve 2 numaralı 2 kortu vardır.
  • Bir rezervasyon kaydı, bir kortun hangi saatler arasında rezerve edildiğini belirtir.
  • Ek olarak, her rezervasyonun kendisiyle ilişkilendirilmiş bir Ücret Türü vardır. Dört farklı ücret türü vardır: İndirimli, Standart, Özel-A ve Özel-B.

Tablonun süperanahtarları şunlardır:

  • S 1 = {Kort, Başlangıç zamanı}
  • S 2 = {Kort, Bitiş zamanı}
  • S 3 = {Ücret türü, Başlangıç zamanı}
  • S 4 = {Ücret türü, Bitiş zamanı}
  • S 5 = {Kort, Başlangıç zamanı, Bitiş zamanı}
  • S 6 = {Ücret türü, Başlangıç zamanı, Bitiş zamanı}
  • S 7 = {Kort, Ücret türü, Başlangıç zamanı}
  • S 8 = {Kort, Ücret türü, Bitiş zamanı}
  • S T = {Kort, Ücret türü, Başlangıç zamanı, Bitiş zamanı}, önemsiz süperanahtar

Yukarıdaki tabloda Başlangıç zamanı ve Bitiş zamanı özelliklerinin her biri için yinelenen değerleri olmasa da, bazı günlerde 1. ve 2. kortta iki farklı rezervasyonun aynı anda başlayabileceğini veya sona erebileceğini kabul etmemiz gerektiği unutulmamalıdır. Bu, {Başlangıç zamanı} ve {Bitiş zamanı} nın tablonun süperanahtarları olarak kabul edilememesinin nedenidir.

Bununla birlikte, sadece, 1 S 2S, 3 S 4 olan S aday anahtarlar için, örneğin (bu ilişki için, en az superkeys olduğu) S 1 ⊂ S 5, dolayısıyla S 5 bir aday anahtar olamaz.

2NF'nin asal olmayan özniteliklerin kısmi işlevsel bağımlılıklarını yasakladığı göz önüne alındığında, 3NF, aday anahtarlar üzerindeki asal olmayan özniteliklerin geçişli işlevsel bağımlılıklarını yasaklar.

Bugünün kort kayıtları tablosunda asal olmayan nitelikler yoktur: yani, tüm özellikler bazı aday anahtarlarına aittir. Bu nedenle tablo hem 2NF hem de 3NF'ye bağlıdır.

BCNF'ye uymayan tasarım, BCNF'yi karşılamak üzere şu şekilde değiştirilebilir:

Ücret türleri
Ücret türü Kort Üye mi
İndirimli 1 Evet
Standart 1 Hayır
Özel-A 2 Evet
Özel-B 2 Hayır
Bugünün rezervasyonları
Üye mi Kort Başlangıç saati Bitiş zamanı
Evet 1 09:30 10:30
Evet 1 11:00 12:00
Hayır 1 14:00 15:30
Hayır 2 10:00 11:30
Hayır 2 11:30 13:30
Evet 2 15:00 16:30

Ücret türleri tablosunun aday anahtarları şunlardır: {Ücret türü} ve {Kort, Üye mi}; Bugünün rezervasyonları tablosu için aday anahtarlar {Kort, Başlangıç zamanı} ve {Kort, Bitiş zamanı}'dır. Her iki tablo da BCNF'tir. {Ücret türü}, Ücret türleri tablosunda bir anahtar olduğunda, iki farklı kortla ilişkilendirilmiş bir ücret türüne sahip olmak imkansızdır, bu nedenle, Ücret türleri tablosunda anahtar olarak {Ücret türü} kullanılarak, orijinal tabloyu etkileyen anormallik elenmiş olur.

BCNF'nin elde edilebilirliği

değiştir

Bazı durumlarda, BCNF olmayan bir tablo, BCNF'yi karşılayan ve orijinal tabloda tutulan bağımlılıkları koruyan tablolara ayrıştırılamaz. Beeri ve Bernstein, 1979'da, örneğin, bir dizi işlevsel bağımlılığın {AB → C, C → B} bir BCNF şeması ile temsil edilemeyeceğini gösterdi.[4]

İşlevsel bağımlılıkları {AB → C, C → B} modelini takip eden aşağıdaki BCNF olmayan tabloda:

En yakın mağazalar
Kişi Mağaza türü En yakın mağaza
Davidson Gözlükçü Eagle Eye
Davidson Kuaför Snippets
Wright Kitapçı Merlin Books
Fuller Fırın Doughy's
Fuller Kuaför Sweeney Todd's
Fuller Gözlükçü Eagle Eye

Her Kişi / Mağaza türü kombinasyonu için, tablo bize bu türden hangi mağazanın coğrafi olarak o kişinin evine en yakın olduğunu gösterir. Basit olması için tek bir mağazanın birden fazla türde olamayacağını varsayıyoruz.

Tablonun aday anahtarları:

  • {Kişi, Mağaza türü},
  • {Kişi, En yakın mağaza}.

Üç özniteliğin tümü asal öznitelikler olduğundan (yani aday anahtarlara ait), tablo 3NF içindedir. Tablo BCNF'de değildir, Mağaza türü özelliği işlevsel olarak süperanahtar olmayan bir mağazaya bağlıdır: En yakın mağaza.

BCNF'nin ihlali, tablonun anormalliklere tabi olduğu anlamına gelir. Örneğin, Eagle Eye, "Davidson" kaydında Mağaza türü "Gözlükçü" olarak kalırken "Fuller" kaydında Mağaza türünü "Optikçi" olarak değiştirilmiş olabilir. Bu, "Eagle Eye"ın mağaza türü nedir?" sorusuna çelişkili cevaplar olacağı anlamına gelir. Her mağazanın Mağaza türünü yalnızca bir kez tutmak, bu tür anormalliklerin ortaya çıkmasını önleyeceği için tercih edilebilir görünür:

Kişiye yakın mağaza
Kişi Mağaza
Davidson Eagle Eye
Davidson Snippets
Wright Merlin Books
Fuller Doughy's
Fuller Sweeney Todd's
Fuller Eagle Eye
Mağaza
Mağaza Mağaza tipi
Eagle Eye Gözlükçü
Snippets Kuaför
Merlin Books Kitapçı
Doughy's Fırın
Sweeney Todd's Kuaför

Bu gözden geçirilmiş tasarımda, "Kişiye yakın mağaza" tablosunda {Kişi, Mağaza} aday anahtarı ve "Mağaza" tablosu {Mağaza} aday anahtarına sahiptir. Ne yazık ki, bu tasarım BCNF'ye bağlı olsa da, farklı gerekçelerle kabul edilemez: aynı kişiye karşı aynı türden birden fazla mağazayı kaydetmemize izin veriyor. Diğer bir deyişle, aday anahtarları, {Kişi, Mağaza türü} → {Mağaza} işlevsel bağımlılığına saygı duyulacağını garanti etmez.

Tüm bu anormallikleri ortadan kaldıran (ancak BCNF'ye uymayan) bir tasarım mümkündür. Bu tasarım, Temel Anahtar Normal Form olarak bilinen yeni bir normal formu sunar.[5] Bu tasarım, yukarıda açıklanan "Mağaza" tablosu ile tamamlanan orijinal "En yakın mağazalar" tablosundan oluşur. Bernstein'ın şema oluşturma algoritması[6] tarafından oluşturulan tablo yapısı aslında EKNF'dir, ancak algoritma tasarlandığı sırada, 3NF'ye yapılan bu iyileştirme henüz tanınmamıştı:

En yakın mağazalar
Kişi Mağaza tipi En yakın mağaza
Davidson Gözlükçü Eagle Eye
Davidson Kuaför Snippets
Wright Kitapçı Merlin Books
Fuller Fırın Doughy's
Fuller Kuaför Sweeney Todd's
Fuller Gözlükçü Eagle Eye
Mağaza
Mağaza Mağaza tipi
Eagle Eye Gözlükçü
Snippets Kuaför
Merlin Books Kitapçı
Doughy's Fırın
Sweeney Todd's Kuaför

İlk tablodaki {Mağaza türü, En yakın mağaza}'nın ikinci tablodan bir {Mağaza türü, Mağaza}' ya referans vermesi gerektiği etkisine yönelik bir referans bütünlük kısıtlaması tanımlanırsa, daha önce açıklanan veri anormallikleri önlenir.

Ayrıca bakınız

değiştir

Kaynakça

değiştir
  1. ^ Codd, E. F. "Recent Investigations into Relational Data Base" in Proc. 1974 Congress (Stockholm, Sweden, 1974). New York, N.Y.: North-Holland (1974).
  2. ^ Database System Concepts. 6th. McGraw-Hill. 2006. ss. 333. ISBN 978-0-07-352332-3. 
  3. ^ Vincent, M. W. and B. Srinivasan. "A Note on Randi Schemes Which Are in 3NF But Not in BCNF". Information Processing Letters 48(6), 1993, pp. 281–283.
  4. ^ Beeri, Catriel and Bernstein, Philip A. "Computational problems related to the design of normal form relational schemas". ACM Transactions on Database Systems 4(1), March 1979, p. 50.
  5. ^ Zaniolo, Carlo. "A New Normal Form for the Design of Relational Database Schemata". ACM Transactions on Database Systems 7(3), September 1982, p. 493.
  6. ^ Bernstein, P. A. "Synthesizing Third Normal Form relations from functional dependencies". ACM Transactions on Database Systems 1(4), December 1976 pp. 277–298.

Dış bağlantılar

değiştir