3NF ve BCNF arasındaki fark basit terimlerle (8 yaşında bir çocuğa açıklayabilmelidir)

Alıntı okudum: veri anahtar [1NF], tüm anahtar [2NF] ve hiçbir şey [3NF] anahtarına bağlıdır .

Ancak, 3.5NF veya BCNF'yi çağırdığı gibi anlamakta zorlanıyorum. İşte anladıklarım:

• BCNF 3NF'den daha sıkı
• tablodaki herhangi bir FD'nin sol tarafı superkey (veya en azından bir aday anahtar) olmalıdır

Öyleyse neden bazı 3NF tabloları BCNF'de değil? Yani, 3NF alıntısı açıkça "anahtardan başka bir şey" diyor, yani tüm niteliklerin sadece birincil anahtara bağlı olduğu anlamına geliyor. Her şeyden önce birincil anahtar, birincil anahtarımız olarak seçilene kadar bir aday anahtardır.

Şimdiye kadar anlayışımla ilgili bir şey varsa, lütfen beni düzeltin ve verebileceğiniz herhangi bir yardım için teşekkürler.

Pizzanızın tam olarak üç tane tepesi türü olabilir:

• bir tür peynir
• bir tür et
• bir tür sebze

Bu yüzden iki pizza sipariş ediyoruz ve aşağıdaki sosları seçiyoruz:

Pizza    Topping     Topping Type
-------- ----------  -------------
1        mozzarella  cheese
1        pepperoni   meat
1        olives      vegetable
2        mozzarella  meat
2        sausage     cheese
2        peppers     vegetable

Bir saniye, mozzarella hem peynir hem de et olamaz! Ve sosis peynir değil!

Mozzarella'yı her zaman peynir haline getirmek için bu tür hataları önlemeliyiz . Bunun için ayrı bir tablo kullanmalıyız, bu yüzden bu gerçeği sadece bir yere yazıyoruz.

Pizza    Topping
-------- ----------
1        mozzarella
1        pepperoni
1        olives
2        mozzarella 
2        sausage
2        peppers

Topping     Topping Type
----------  -------------
mozzarella  cheese
pepperoni   meat
olives      vegetable
sausage     meat
peppers     vegetable

8 yaşındaki bir çocuğun anlayabileceği açıklama buydu. İşte daha teknik sürüm.

BCNF, yalnızca birden çok çakışan aday anahtarı olduğunda 3NF'den farklı davranır.

Bunun nedeni fonksiyonel bağımlılığın X -> Yelbette Ybir alt kümesi olması durumunda doğrudur X. Bu nedenle, yalnızca bir aday anahtarı olan ve 3NF'de olan herhangi bir tabloda zaten BCNF'de bulunur, çünkü o anahtarın dışında herhangi bir şeye işlevsel olarak bağımlı olan bir sütun (anahtar veya anahtar olmayan) yoktur.

Her pizzanın her bir tepeleme türünden tam olarak birine sahip olması gerektiğinden, (Pizza, Topping Type) bir aday anahtar olduğunu biliyoruz. Ayrıca sezgisel olarak, belirli bir tepenin aynı anda farklı türlere ait olamayacağını da biliyoruz. Bu yüzden (Pizza, Topping) benzersiz olmalı ve bu nedenle bir aday anahtardır. Yani birbiriyle örtüşen iki aday anahtarımız var.

Mozarella'yı yanlış tepesi türü olarak işaretlediğimiz bir anomali gösterdim. Bunun yanlış olduğunu biliyoruz, ancak yanlış yapan kural, Topping -> Topping Typebu tablo için BCNF için geçerli bir bağımlılık olmayan bir bağımlılıktır. Aday anahtarın dışında bir şeye bağımlılık.

Bunu çözmek için Topping Type'ı Pizzas tablosundan çıkarırız ve Topingler tablosunda anahtar olmayan bir özellik haline getiririz.

İnce fark, 3NF'nin anahtar ve anahtar olmayan özellikler ( asal olmayan özellikler olarak da adlandırılır) arasında bir ayrım yapması, BCNF'nin ise bunu yapmamasıdır.

Bu en iyi Zaniolo'nun Codd'lara eşdeğer olan 3NF tanımı kullanılarak açıklanmaktadır :

R'nin bir ilişkisi, aşağıdaki koşullardan en az biri R tarafından tatmin edilen her önemsiz FD (X-> A) için 3NF iff'de geçerlidir:

(a) X, R için bir süperkeydir veya

(b) A, R için anahtar bir özelliktir

BCNF (a) 'yı gerektirir ancak (b)' yi kendine özgü bir durum olarak ele almaz. Başka bir deyişle BCNF, bağımlı niteliklerinin bir anahtarın parçası olmasına rağmen önemsiz olmayan her determinantın superkey olmasını gerektirir.

R'den memnun olan her önemsiz FD (X-> A) için bir ilişki, R, BCNF iff'de bulunur: Aşağıdaki koşul doğrudur:

(a) X, R'nin bir süperkeyidir

BCNF bu nedenle daha katıdır.

Fark o kadar incedir ki, birçok insanın gayri resmi olarak 3NF olarak tanımladığı şey aslında BCNF'dir. Örneğin, burada 3NF'nin "verilerin anahtar [lar] a ve anahtar [lar] dan başka bir şeye bağlı olmadığını" ifade ettiğini, ancak bu gerçekten de 3NF'nin değil, BCNF'nin gayri resmi bir tanımı olduğunu ifade ettiniz. 3NF " anahtar olmayan veriler anahtarlara bağlıdır ... ve anahtarlardan başka bir şey değildir " olarak daha doğru bir şekilde tanımlanabilir .

Ayrıca:

3NF alıntısı açıkça "anahtardan başka bir şey" der, yani tüm öznitelikler yalnızca birincil anahtara bağlıdır.

Bu aşırı basitleştirme. 3NF ve BCNF ve tüm Normal Formlar, yalnızca bir "birincil" anahtarla değil, tüm aday anahtarlar ve / veya süper anahtarlarla ilgilidir .

BCNF ve 3NF arasındaki fark

BCNF tanımını kullanma

Yalnızca ve bağımlılıklarının her biri için X → Y ise, aşağıdaki koşullardan en az biri geçerliyse :

• X → Y önemsiz bir işlevsel bağımlılıktır (Y ⊆ X) veya
• X, R şeması için bir süper anahtardır

ve 3NF tanımı

Yalnızca ve fonksiyonel bağımlılıklarının her biri için X → A için, aşağıdaki koşullardan en az biri geçerliyse:

• X, A içerir (yani X → A önemsiz fonksiyonel bağımlılıktır) veya
• X bir süperkeydir veya
• AX'in her unsuru, A ve X arasındaki ayarlanmış fark, asal bir özelliktir (yani, AX'taki her özellik bazı aday anahtarlarda bulunur)

Aşağıdaki farkı basit terimlerle görüyoruz:

• BCNF'de : Her kısmi anahtar (ana özellik) yalnızca bir superkey'e bağlı olabilir ,

buna karşılık

• 3NF'de : Kısmi bir anahtar (asal öznitelik), superkey olmayan bir özniteliğe de bağlı olabilir (başka bir kısmi anahtar / asal öznitelik veya hatta asal olmayan bir öznitelik).

Nerede

1. Bir asal nitelik aday anahtarında bulunan bir özelliktir ve
2. Bir aday anahtar o ilişki için asgari SuperKey olduğunu ve
3. Bir süperkey , bir değişkenin atanmış tüm ilişkilerinde, bu kümedeki öznitelikler için aynı değerlere sahip iki ayrı tuple (satır) bulunmadığı bir ilişki değişkeninin nitelikler kümesidir. şemanın tüm özniteliklerinin işlevsel olarak bağımlı olduğu bir ilişki şemasının öznitelikler kümesi olarak tanımlanabilir. (Bir superkey her zaman bir aday anahtar içerir / bir aday anahtar her zaman bir superkey'in alt kümesidir. Superkeylerden birini elde etmek için bir ilişkide herhangi bir nitelik ekleyebilirsiniz.)

Yani, bir aday anahtarın hiçbir kısmi altkümesi (tam küme dışında önemsiz olmayan bir altküme) bir superkey dışındaki herhangi bir şeye işlevsel olarak bağımlı olamaz.

BCNF'de olmayan bir tablo / ilişki, başka bir kullanıcı tarafından pizza örneğinde belirtilen güncelleme anomalileri gibi anormalliklere tabidir. Ne yazık ki,

• BNCF olamaz daima elde edilebilir iken,
• 3NF her zaman elde edilebilir .

3NF ve BCNF Örneği

Farkın bir örneği şu anda Wikipedia'da " 3NF tablosunu karşılamayan (Boyce-Codd normal formu) " adresinde bulunabilir , burada aşağıdaki tablo 3NF ile karşılaşır, ancak BCNF ile karşılaşmaz, çünkü "Tenis Kortu" (kısmi bir anahtar / ana özellik) "Ücret Türü" (bir superkey olmayan kısmi bir anahtar / ana özellik ) üzerinde, bu da veritabanının müşterilerine, tenis kulübüne sorarak belirleyebileceğimiz bir bağımlılıktır:

Bugünün Tenis Kortu Rezervasyonları ( 3NF, BCNF değil )

Court   Start Time  End Time    Rate Type
------- ----------  --------    ---------
1       09:30       10:30       SAVER
1       11:00       12:00       SAVER
1       14:00       15:30       STANDARD
2       10:00       11:30       PREMIUM-B
2       11:30       13:30       PREMIUM-B
2       15:00       16:30       PREMIUM-A

Masanın süperkeyleri:

S1 = {Court, Start Time}
S2 = {Court, End Time}
S3 = {Rate Type, Start Time}
S4 = {Rate Type, End Time}
S5 = {Court, Start Time, End Time}
S6 = {Rate Type, Start Time, End Time}
S7 = {Court, Rate Type, Start Time}
S8 = {Court, Rate Type, End Time}
ST = {Court, Rate Type, Start Time, End Time}, the trivial superkey

3NF problemi : Kısmi anahtar / ana nitelik "Mahkeme", superkey dışında bir şeye bağlıdır. Bunun yerine, "Ücret Türü" kısmi anahtar / ana özelliğine bağlıdır. Bu, bir mahkemeyi yükseltirsek kullanıcının ücret türünü manuel olarak değiştirmesi veya ücret değişikliği uygulamak isterse mahkemeyi manuel olarak değiştirmesi gerektiği anlamına gelir.

• Ancak, kullanıcı mahkemeyi yükseltir, ancak oranı artırmayı hatırlamazsa ne olur? Ya da bir mahkemeye yanlış ücret türü uygulanırsa?

(Teknik açıdan, "Ücret Türü" -> "Mahkeme" işlevsel bağımlılığının ihlal edilmeyeceğini garanti edemeyiz.)

BCNF çözümü : Yukarıdaki tabloyu BCNF'ye yerleştirmek istiyorsak, verilen ilişki / tabloyu aşağıdaki iki ilişki / tabloya ayırabiliriz (ücret türünün yalnızca mahkemeye ve üyelik durumuna bağlı olduğunu varsayarsak, veritabanımızın müşterilerine, tenis kulübünün sahiplerine sorarak keşfedin):

Hız Türleri ( BCNF ve BCNF tarafından ima edilen daha zayıf 3NF)

Rate Type   Court   Member Flag
---------   -----   -----------
SAVER       1       Yes
STANDARD    1       No
PREMIUM-A   2       Yes
PREMIUM-B   2       No

Bugünün Tenis Kortu Rezervasyonları ( BCNF ve BCNF tarafından ima edilen daha zayıf 3NF)

Member Flag     Court     Start Time   End Time
-----------     -----     ----------   --------
Yes             1         09:30        10:30
Yes             1         11:00        12:00
No              1         14:00        15:30
No              2         10:00        11:30
No              2         11:30        13:30
Yes             2         15:00        16:30

Sorun Çözüldü : Şimdi mahkemeyi yükseltirsek, ücret türünün bu değişikliği yansıtacağını garanti edebiliriz ve mahkeme için yanlış fiyat talep edemeyiz.

(Teknik açıdan, "Ücret Türü" -> "Mahkeme" işlevsel bağımlılığının ihlal edilmeyeceğini garanti edebiliriz.)

Tüm iyi cevaplar. Basit dilde söylemek gerekirse [BCNF] Hiçbir kısmi anahtar bir anahtara bağlı olamaz.

yani bir aday anahtarın hiçbir kısmi alt kümesi (yani tam set dışında önemsiz olmayan bir alt küme) işlevsel olarak bazı aday anahtarlara bağlı olabilir.

' Smartnut007 ', ' Bill Karwin ' ve ' sqlvogel ' yanıtları mükemmel. Yine de ilginç bir bakış açısı getireyim.

Asal ve asal olmayan anahtarlarımız var.

Primer olmayanların primere nasıl bağlı olduğuna odaklandığımızda iki durum görüyoruz:

Primer olmayanlar bağımlı olabilir veya olmayabilir .

• Bağımlı olduğunda: tam bir aday anahtara bağlı olmaları gerektiğini görüyoruz. Bu 2NF .

• Bağımlı olmadığında: bağımlılık veya geçişli bağımlılık olabilir

  • Geçişli bağımlılık bile değil: Normalizasyon teorisinin buna hitap ettiğinden emin değilim.
  • Geçişe bağımlı olduğunda: İstenmeyen kabul edilir. Bu 3NF .

Asallar arasındaki bağımlılıklar ne olacak?

Şimdi görüyorsunuz, 2. veya 3. UF ile asal sayılar arasındaki bağımlılık ilişkisini ele almıyoruz . Dahası, eğer böyle bir bağımlılık arzu edilmez ve bu nedenle bunu ele almak için tek bir kuralımız vardır. Bu BCNF .

Buradaki Bill Karwin'in gönderisinden gelen örneğe bakarak , hem ' Topping ' hem de ' Topping Type ' öğelerinin ana anahtarlar olduğunu ve bir bağımlılığa sahip olduğunuzu göreceksiniz . Bağımlılığı olan asal olmayanlar olsaydı, 3NF devreye girerdi.

Not:

BCNF'nin tanımı çok geneldir ve asal olan ile asal olmayan arasındaki farklılıkları ayırt etmeden. Yine de, yukarıdaki düşünme şekli, 2. ve 3. UF'den sonra bile bazı anomalilerin nasıl süzüldüğünü anlamaya yardımcı olur.

Gelişmiş Konu: Genel BCNF'yi 2NF ve 3NF ile eşleme

Artık BCNF'nin herhangi bir asal / asal olmayan özniteliğe başvurmadan genel bir tanım sağladığını bildiğimize göre, BCNF ve 2/3 NF'lerin nasıl ilişkili olduğunu görelim.

İlk olarak, BCNF (önemsiz durum dışında) her işlevsel bağımlılık X -> Y(FD) için X'in süper anahtar olmasını gerektirir. Sadece herhangi bir FD'yi göz önünde bulundurursanız, üç vakamız var - (1) Hem X hem de Y, asal olmayan, (2) Hem asal hem de (3) X asal ve Y asal olmayan, (saçma) X vakasını atarak - asal ve Y asal.

Durum (1) için 3NF ilgilenir.

Durum (3) için 2NF ilgilenir.

Durum (2) için BCNF kullanımını buluyoruz

Bu, değerli cevapları olan eski bir soru, ancak 3NF ile ilgili sorunu gösteren gerçek bir yaşam örneği bulana kadar biraz kafam karıştı. Belki 8 yaşında bir çocuk için uygun değil ama umarım yardımcı olur.

Yarın üç aylık ebeveyn / öğretmen toplantılarından birinde en büyük kızımın öğretmenleriyle buluşacağım. Günlüğüm şöyle görünüyor (isimler ve odalar değiştirildi):

Teacher   | Date             | Room
----------|------------------|-----
Mr Smith  | 2018-12-18 18:15 | A12 
Mr Jones  | 2018-12-18 18:30 | B10 
Ms Doe    | 2018-12-18 18:45 | C21 
Ms Rogers | 2018-12-18 19:00 | A08 

Oda başına sadece bir öğretmen var ve asla hareket etmiyorlar. Eğer bir göz varsa, göreceksiniz: (1) her özellik için Teacher, Date, Room, biz satır başına yalnızca bir değere sahip. (2) süper tuşları şunlardır: (Teacher, Date, Room), (Teacher, Date)ve (Date, Room)ve aday tuşları belli ki (Teacher, Date)ve (Date, Room).

_{(Teacher, Room) bir superkey değil çünkü önümüzdeki çeyrek masayı tamamlayacağım ve bunun gibi bir satırım olabilir (Bay Smith hareket etmedi!):}

Teacher  | Date             | Room
---------|------------------| ----
Mr Smith | 2019-03-19 18:15 | A12

Neyi sonuçlandırabiliriz? (1) 1NF'nin gayri resmi fakat doğru bir formülasyonudur. (2) 'den hiçbir "asal olmayan özellik" olmadığını görüyoruz: 2NF ve 3NF ücretsiz olarak verilmektedir.

Günlüğüm 3NF. İyi! Hayır. Aslında bir veri düzenleyicisi bunu bir DB şemasında kabul edemeyeceği için değil. RoomNitelik bağlıdır Teacher(yine!: Öğretmenler hareket etmiyor) özniteliği ama şema bu gerçeği yansıtmaz. Aklı başında bir veri düzenleyici ne yapardı? Tabloyu ikiye bölün:

Teacher   | Date
----------|-----------------
Mr Smith  | 2018-12-18 18:15
Mr Jones  | 2018-12-18 18:30
Ms Doe    | 2018-12-18 18:45
Ms Rogers | 2018-12-18 19:00

Ve

Teacher   | Room
----------|-----
Mr Smith  | A12
Mr Jones  | B10
Ms Doe    | C21
Ms Rogers | A08

Ancak 3NF, birincil öznitelik bağımlılıklarıyla ilgilenmez. Sorun şu: 3NF uyumluluğu, bazı durumlarda sağlam bir tablo şeması tasarımı sağlamak için yeterli değildir .

BCNF ile, özelliğin 2NF ve 3NF kurallarında asal bir özellik olup olmadığı önemli değildir. Her önemsiz bağımlılık için (altkümeler açıkça üst kümeleri tarafından belirlenir), belirleyici tam bir süper anahtardır. Başka bir deyişle, hiçbir şey tam bir süper anahtardan başka bir şey tarafından belirlenmez (önemsiz FD'ler hariç). (Resmi tanım için diğer cevaplara bakınız).

En kısa sürede Roombağlıdır Teacher, Roombir alt kümesi olmalıdır Teacher(vaka olmadığını) ya da Teacherbir süper anahtarı olmalıdır (günlüğüme böyle değil ama tablo bölünmüş durumda şu).

Özetlemek gerekirse: BNCF daha katıdır, ancak bence 3NF'den daha kolay anlaşılır:

• çoğu durumda, BCNF 3NF ile aynıdır;
• diğer durumlarda, BCNF düşündüğünüz / umudunuz 3NF'dir.