İkinci normal formda (2NF) bir sorunum var ve Google'ı kullanarak çözemedim. Beni çıldırtıyor çünkü ben öğretmenim ve öğrencilerime yanlış şeyler öğretmek istemiyorum.

5 alanlı bir masa alalım.

Notlar = {StudentName, SubjectCode, SubjectName, #Exam, Grade}

Bağımlılıklar şu şekilde:

StudentName, SubjectCode, #Exam -> Not

SubjectCode -> Konu Adı

SubjectName -> SubjectCode

Bu nedenle, aday anahtar 1 {StudentName, SubjectCode, #Exam} ve aday anahtar 2 {StudentName, SubjectName, #Exam} 'dir .

Başbakan nitelikleridir {StudentName, SubjectCode, konuadı, #Exam} -asal niteliklerini edilir Sınıf

İkinci normal formun tanımına göre, asal olmayan bir özellik, aday anahtarın bir kısmına bağlı olamaz. Yalnızca asal olmayan özellik (Derece) bir aday anahtarın bir bölümüne bağlı değildir, bu nedenle bu tablo 2NF'de görünür.

Sorun şu ki bir şeylerin yanlış olduğunu düşünüyorum (ve yanlış olabilir). Bence deneklerin kendi masaları olmalı.

Notlar = {ÖğrenciAdı, Konu Kodu, # Sınav, Not}

Konular = {Konu Kodu, Konu Adı}

Ancak 2NF bunu üretmez. 3NF, asal olmayan öznitelikler arasındaki bağımlılıklarla ilgilidir, bu yüzden bunu da üretmez. Ama bana öyle geliyor ki, bu doğru sonuç, çünkü artıklığı yok.

Asal olmayan öznitelik "aday anahtar olmayan öznitelik" olarak tanımlanmışsa, 2NF istenen sonucu üretir. Ama bunu tekrar tekrar kontrol ettim ve asal olmayan öznitelik "bir aday anahtara AİTMEYEN öznitelik" olarak tanımlandı.

Neyi yanlış yapıyorum?

Kişisel ilişki (ve sadece 2NF), 3NF, sen sadece sigara asal niteliktir söylediği gibi bu yana Sınıf yalnızca FDS sağ tarafında görünür.

İlişki BCNF'de değildir, çünkü iki küçük FD'nin sol tarafı superkey değildir.

Bununla birlikte, az kayıplı (ilişki için ayrıştırmak SubjectCode , konuadı ) ve ya ( StudentName, SubjectCode, #Exam, Derece ) veya ( StudentName, konuadı, #Exam, Derece )

Bu ayrışma size iki BCNF ilişkisi verir ve tüm işlevsel bağımlılıkları korur. Bu her zaman mümkün değildir (her zaman 3NF ile bir ilişkiyi ayrıştırabilirsiniz, ancak mutlaka BCNF ile ilişkilendiremezsiniz).

2NF

2NF örneği (3NF değil) istiyorsanız, ilişkinizin geçişli bağımlılıklar içermesi gerekir.

Örneğin, bir Puan sütununuz olduğunu varsayalım. Sezgisel olarak Puan -> Notu, aynı puanı alan tüm sınavların aynı notu alması gerekir (aksi halde oldukça haksız olurdu), ancak birkaç puanın aynı sınıfa (% 11 ve% 12) sahip olabileceğinden Not -> Puan diyemeyiz. örneğin "Başarısız" olabilir).

Şimdi ilişkiniz:

Notlar ( ÖğrenciAdı, KonuKodu, KonuAdı, # Sınav, Puan, Not )

ve yeni bir yedekli formunuz var, çünkü başka bir Gradings kaydıyla aynı puana sahip bir sonuca her girdiğinizde aynı notu tekrarlamanız gerekir. 3NF'ye ulaşmak için,

ScoreGrades ( Puan, Not )

ile Score anahtarı olarak ve

Puanlar ( ÖğrenciAdı, KonuKodu, KonuAdı, # Sınav, Puan )

Söylediğin her şeyde haklısın. Konu Kodu, KonuAdı, istenen bağımlılıkları uygulamak için kendi tablolarına gitmelidir. Bu, 2NF ve 3NF'nin neden iyi veritabanı tasarımları üretmek için yeterli olmadığının iyi bir örneğidir - bunun yerine Boyce Codd Normal Formuna (BCNF) ihtiyacınız vardır.

2NF ve 3NF'nin yerini, pratik olarak konuşan bu küçük NF'leri geçersiz kılan BCNF alır. BCNF açıklanması ve uygulanması daha önemli ve tartışmasız daha basittir. Bir öğretmen olarak BCNF'ye daha fazla, 2NF ve 3NF'ye daha az zaman ayırmanızı öneririm. Bir tablo BCNF gereksinimlerini karşılarsa, aynı zamanda 2NF ve 3NF'yi de karşılar.

* 3NF, bağımlılığı koruyan en yüksek Normal Form değildir. Temel Anahtar Normal Formudur (EKNF). Kesinlikle söylemek gerekirse, 3NF'yi eski yapan BCNF değil EKNF'dir, ancak EKNF haksız bir şekilde ihmal edilir ve çoğu ders kitabı ve ders bundan bile bahsetmez. Aynı şey BCNF'ye tasarlamak ve daha sonra istenen tüm bağımlılıkların ve diğer bütünlük kurallarının düzgün bir şekilde uygulanıp uygulanamayacağını kontrol etmektir - eğer değilse, tasarımı değiştirin. UF'lerin hiçbiri veri bütünlüğü için tam bir çözüm değildir, ancak BCNF genel olarak en yakına gelir ve açıklaması ve kullanımı en kolay olanıdır.

Tüm bunları ilk öğrendiğimden bu yana ne kadar zaman geçtiğini söylemeyeceğim. Ama hatırlıyorum, bize "işlevsel bağımlılık" ve "asal olmayan özellik" ve diğer tüm buzzwords doğru anlamını öğrettikten sonra, bize belirli bir normal olup olmadığını görmek için bir dizi basit soru verdi forma ulaşıldı. Bakalım bunu hatırlayabiliyor muyum ...

Aday anahtar (lar) ını belirledik, bu nedenle kalan asal olmayan niteliklerle ilgili bu soruyu soruyoruz. Bu durumda, sadece bir tane vardır: not.

Notu benzersiz bir şekilde tanımlamak için ihtiyacımız olan mutlak minimum bilgi nedir? Öğrenciyi, konuyu ve girilen sınavı bilmemiz gerekiyor. Güzel, bu aday anahtarlarından biri.

DÜZENLEME: VVV

Ancak cevap aynı zamanda öğrenci adı, konu adı ve sınav olabilir. Bu ikinci aday anahtarıyla eşleşir.

SubjectCode ve SubjectName öğelerinin, Subject varlık için aday anahtarlar olduğu varsayıldığında, bu alanların her ikisinin de burada olması için bir neden yoktur. Konular tablosundaki bir satıra benzersiz bir referans oldukça yeterlidir. Bu nedenle, Modelin bütünlüğünden ödün vermeden SubjectName alanından güvenle kurtulabiliriz.

Ancak, orijinal cevabımda, başka bir normalizasyon seviyesi gösterme arzumda, SubjectName'in bir aday anahtarda kullanıldığını görmezden geldim ve bunu sadece başka bir asal olmayan özellik olarak kabul ettim. Sanırım o kadar açıktı ki, bunun herkes için olduğu kadar açık olacağını düşündüğüm işe yaramaz bir alandı ve her iki şekilde de alandan kurtulduğumuzdan beri, ne fark etti?

Ama cevabın bu kısmını kaldırmak yerine, karşılaştırma için saklayacağım.

SON DÜZENLEME: ^ ^ ^

Konu adını benzersiz bir şekilde tanımlamak için ihtiyacımız olan mutlak minimum bilgi nedir?

SubjectName yalnızca aday anahtarın bir alt kümesi olan SubjectCode öğesine bağımlıdır. Yani bu demet 2nf'de değil. SubjectCode, SubjectName'i yerleştirmek için doğru konum olacak şekilde bir Subject tablosunun birincil anahtarı olmalıdır. Bu demetten çıkarın ve şimdi 2nf'de.

Bir öznitelik sorusunu sorarsak ve cevap aday anahtarın tamamı ya da bir parçası değilse, grup 3nf'de değildir. Ama bu grup da 3nf ve ötesinde, çünkü soru sormak için alanlarımız tükendi. ;)

Not: "normalleştir" dediğimizde, mantıksal bir varlığa uygulanan bir işleme atıfta bulunuyoruz. Verilen tuple "grade" adı verilen bir varlığın tanımı gibi göründüğü için normalleştirebiliriz. Ancak, bir noktada "bu grup 2nf'de değil" dedim, ki bu daha doğru bir şekilde olmalı, "bu varlık 2nf'de değil." Bu karışıklığa neden olduysa özür dilerim.

Yalnızca asal olmayan özellik (Derece) bir aday anahtarın bir bölümüne bağlı değildir, bu nedenle bu tablo 2NF'de görünür.

2NF cinsindendir.

Sorun şu ki bir şeylerin yanlış olduğunu düşünüyorum (ve yanlış olabilir). Bence deneklerin kendi masaları olmalı.

Deneklerin orijinal tablonun 2NF'ye ayrıştırılması için kendi tabloları olmasını beklemek için bir neden yoktur . Belli bir normal formun aslında size verdiği şeyle ilgili bazı “zorunluluk” kavramını karıştırıyorsunuz.

3NF, asal olmayan öznitelikler arasındaki bağımlılıklarla ilgilidir, bu yüzden bunu da üretmez.

"3NF, asal olmayan nitelikler arasındaki bağımlılıklarla ilgilidir" 3NF'nin doğru bir tanımı değildir, bu yüzden "bu yüzden de üretmez" sağlam bir sonuç değildir. Her ne kadar gerçek bir tanım uygulamak tablonun 3NF'de olduğunu göstermesine rağmen, öğrenci tablosu gerekmez. Ama yine de olmasını beklemek için hiçbir neden yok.

Ama bana öyle geliyor ki, bu doğru sonuç, çünkü artıklığı yok.

Yine, "işten çıkarılma" yararsız bir şekilde belirsizdir, bu yüzden "çünkü" ve öğrenci tablosu beklentiniz sağlam değildir. Farklı normal formlar serbesttir ve belirli tür anormalliklere ve ilişkili "fazlalıklara" tabidir . Ancak normalleştirme ile ele alınmayan diğer "artıklık" kalabilir.

Bu tablo BCNF'de değildir, çünkü CK'larda olmayan FD'lere sahiptir. BCNF'ye göre ayrıştırılması, öğrenci masasına sahip olmasına yol açar. BCNF, FD'lere eşlik eden JD'lerle (birleştirme bağımlılıkları) başa çıkmak için en yüksek normal formdur. Bununla birlikte, diğer JD'ler problemli olabilir (yani "CK'lar tarafından ima edilmez") ve 5NF'ye normalleştirilerek çıkarılmalıdır.

Not Orijinal tablo FD {StudentName, SubjectName, #Exam} -> Notunu da karşılar.

Bağımlılıklar şu şekilde:

Bunun anlamı ne? Net değil.

"Bunların hepsi önemsiz olmayan FD'ler" mi demek istiyorsun? Hayır, çünkü dördüncü ima ediyorlar. "İşte bazı FD'ler var"? Hayır, araçlar Geçişli kapatma ambarındaki FDS, ancak diğerleri demek olmadığını o değil tutun, henüz ÇKS tespit etmeyi başardı. "Tutan FD'ler tam olarak bunların geçişli kapanışında olanlardır"? Eğer varsa demek ki sadece olurdu biliyorum sen olsaydı bunu gösterildiği bunu daha sonra (minimal / kanonik kapak aracılığıyla tipik) kapatılması ve başka hiçbir FDS olduğunu göstermiştir bulduk olurdu yani; yaptın mı Ne olursa olsun, yazdıklarınız bunun anlamına gelmez. Bu yüzden FD & CK durumu hakkında mantıklı düşünmemenizi bekliyorum.

Haklısınız, konular kendi tablosunu gerektiriyor. Aday anahtarlarınızdan birini seçerseniz subject_codeveya subject_namebirincil olmayan bir aday anahtar olur. Daha sonra birincil olmayan konular alanını dereceler tablosundan kaldırın.

İki benzersiz tanımlayıcıya sahip olduğunuz konuya işlevsel bir bağımlılığınız var. Bu, subject_codeve arasındaki geçişli bağımlılık ile gösterilmiştir subject_name. Bu, bu iki alanı içeren bir tablo oluşturma ve bu alanlardan birini diğer tüm tablolardan kaldırma gereksinimini gösterir. Bu tabloda ek bağımlı sütunlar olabilir, ancak bu örnekte hiçbirini göremiyorum. 3. normal formda seçtiniz.

not, yeni mezuniyet tablosundaki diğer üç alana (aday anahtarı) bağlıdır. Yukarıda belirtildiği gibi, konular tablosu için aday alanlarından birini seçmeniz gerekir. Normalde, daha kararlı olma eğiliminde oldukları için bu bir kod değeri olacaktır. Tüm anahtar olmayan alanlar birincil anahtardaki alanlara tamamen bağımlı olduğundan sonuçtaki model 3nf biçimindedir.

Sorunun daha ayrıntılı analiz edilmesi (gereksinimler), işaretlerin uygulandığı bir oturum tablosu verecektir. Mevcut modelin bir kursu tekrar eden bir öğrenciyi kapsaması olası değildir. Bu daha sonraki bir derste ele alınacaktır.

Aynı ada sahip birden fazla öğrencinin olması mümkün olduğundan öğrenciler muhtemelen ayrı bir tablo haline gelir. Bu muhtemelen bir sentetik birincil anahtar (öğrenci numarası?) Eklenerek çözülebilir.

subjects --->  sessions ---+--> grades
students  -----------------+

Yanlış kabul edildiği için bunu silmeye hazırlanıyorum

Konu Adı aynı zamanda asal olmayan bir özelliktir ve birincil anahtarın Konu Kodunun bir bölümüne bağlıdır (kural kırılır - birincil anahtarda herhangi bir sütunun kısmi bağımlılığı olmamalıdır).

Bu, 2. Normal Formda yasaklanmıştır ve bundan şüphelendiğiniz gibi kendi masasına yerleştirilmelidir.

Bence nerede çözüldüğünüz iki aday anahtar kümesi tanımlamak olduğunu, tablo oluştururken birincil anahtar yapmak için bir aday anahtar kümesi seçmelisiniz. Kalan sütunlar asal olmayan nitelikler haline gelir; örneğin, ikinci aday anahtarınızı seçtiyseniz, Konu Kodu birincil anahtarın (Konu Adı) bir kısmına bağlı olan asal olmayan bir nitelik haline gelir ve kendi tablosuna yerleştirilmelidir.

1., 2. ve 3. normal formları birbirleri üzerine kurdukları sırada öğretmek önemlidir. BCNF de esasen 3. normal formata bir uzantısıdır, bu nedenle daha düşük seviyelerde güçlü bir kavrama gereklidir.

Daha ileri; deneyimli bir geliştirici, birçok kural sezgisel hale geldiğinden bağımsız normalleştirme seviyelerini dikkate almayacaktır.

Ayrıca belirli tasarım ve optimizasyon problemlerini çözmek için normalleştirme kurallarını ne zaman kıracaklarını da bilirler. Normalizasyon, sıkı bir kural değil, iyi bir tasarım kılavuzu olarak ele alınmalıdır, bunun da iyi bir öğretim noktası olacağına inanıyorum.