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.Codd, E. F. "Recent Investigations into Relational Data Base" in Proc. 1974 Congress (Stockholm, Sweden, 1974). New York, N.Y.: North-Holland (1974). 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: * X → Y ö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.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. İş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: {| class="wikitable" Ücret türü Kort Üye mi İndirimli 1 Evet Standart 1 Hayır Özel-A 2 Evet Özel-B 2 Hayır Ü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 == 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.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. İş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: {| class="wikitable" Kişi Mağaza Davidson Eagle Eye Davidson Snippets Wright Merlin Books Fuller Doughy's Fuller Sweeney Todd's Fuller Eagle Eye 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.Zaniolo, Carlo. "A New Normal Form for the Design of Relational Database Schemata". ACM Transactions on Database Systems 7(3), September 1982, p. 493. 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ıBernstein, P. A. "Synthesizing Third Normal Form relations from functional dependencies". ACM Transactions on Database Systems 1(4), December 1976 pp. 277–298. 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ı: {| class="wikitable" 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 İ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 == * Birinci normal form * İkinci normal form * Üçüncü normal form == Kaynakça == == Dış bağlantılar == * Veri Normalleştirme Kuralları * ITS, Texas Üniversitesi tarafından Gelişmiş Normalleştirme . Kategori:Veritabanları Kategori:Veri modelleme