Veritabanı normalleştirme esaslarının açıklaması

Bu makalede, yeni başlayanlar için veritabanı normalleştirme terminolojisi açıklanmaktadır. İlişkisel veritabanının tasarımı üzerine bir tartışmada bu terminolojinin temel olarak anlaşılmış olması işinizi kolaylaştıracaktır.

Normalleştirmenin Açıklaması

Normalleştirme, bir veritabanındaki verileri düzene koyma işlemidir. Hem verileri korumak hem de yedekliliği ve tutarsız bağımlılığı ortadan kaldırarak veritabanını daha esnek hale getirmek için tasarlanmış kurallara göre tablolar oluşturmayı ve bu tablolar arasında ilişkiler kurmayı içerir.

Artık veriler disk alanını boşa kullanır ve bakım sorunları oluşturur. Birden çok konumda bulunan verilerin değiştirilmesi gerekirse, bu veriler tüm konumlarda tam olarak aynı şekilde değiştirilmelidir. Bu veriler yalnızca Müşteriler tablosunda ve veritabanında başka hiçbir yerde depolanmadıysa, müşteri adresi değişikliğinin uygulanması daha kolaydır.

"Tutarsız bağımlılık" nedir? Bir kullanıcının belirli bir müşterinin adresi için Müşteriler tablosuna bakması sezgisel olsa da, o müşteriyi arayan çalışanın maaşına bakmak mantıklı olmayabilir. Çalışanın maaşı, çalışanın kendisiyle ilişkili ya da buna bağımlıdır ve bu nedenle de Çalışanlar tablosuna taşınmalıdır. Tutarsız bağımlılıklar verilere erişimi zorlaştırabilir, çünkü verileri bulma yolu eksik veya bozuk olabilir.

Veritabanı normalleştirmesi için birkaç kural bulunmaktadır. Her kural "normal form" olarak adlandırılır. İlk kural gözlemlenirse veritabanının "ilk normal biçimde" olduğu söylenir. İlk üç kurala uyulursa, veritabanı "üçüncü normal biçimde" kabul edilir. Diğer normalleştirme düzeyleri mümkün olsa da, üçüncü normal form çoğu uygulama için gereken en yüksek düzey olarak kabul edilir.

Birçok resmi kural ve belirtimde olduğu gibi, gerçek dünya senaryoları her zaman mükemmel uyumluluk sağlamaz. Genel olarak, normalleştirme için ek tablolar gerekir ve bazı müşteriler bunun ek yük getirdiğini düşünmektedir. Normalleştirmenin ilk üç kuralından birini ihlal etmeye karar verirseniz, uygulamanızın artık veriler ve tutarsız bağımlılıklar gibi oluşabilecek sorunlara karşı hazır olmasını sağlayın.

Aşağıdaki açıklamalarda örnekler yer almaktadır.

İlk normal form

  • Aynı tablodaki yinelenen grupları kaldırın.
  • Her bir ilgili veri kümesi için ayrı bir tablo oluşturun.
  • Her bir ilgili veri kümesini bir birincil anahtarla tanımlayın.

Benzer verileri depolamak için tek bir tabloda birden çok alan kullanmayın. Örneğin, iki olası kaynaktan alınabilecek bir stok öğesini izlemek için, stok kaydı, Satıcı Kodu 1 ve Satıcı Kodu 2 alanlarını içerebilir.

Üçüncü bir satıcı eklerseniz ne olur? Alan eklemek yanıt değildir; program ve tablo değişiklikleri gerektirir ve dinamik sayıda satıcıyı sorunsuz bir şekilde barındırmaz. Bunun yerine, tüm sayıcı bilgilerini Satıcılar adlı ayrı bir tabloya yerleştirin, sonra da stoğu bir öğe numarası anahtarıyla satıcılara veya satıcıları bir satıcı kodu anahtarıyla stoğa bağlayın.

İkinci normal form

  • Birden çok kayıt için geçerli olan değer kümeleri için ayrı tablolar oluşturun.
  • Bu tabloları bir yabancı anahtarla ilişkilendirin.

Kayıtlar, tablonun birincil anahtarı (gerekirse bileşik anahtar) dışında hiçbir şeye bağımlı olmamalıdır. Örneğin bir muhasebe sistemindeki müşteri adresini ele alalım. Adresin Müşteriler tablosunun yanı sıra Siparişler, Nakliye, Faturalar, Alacak Hesapları ve Topluluklar tablolarında da kullanılması gerekir. Müşterinin adresini bu tabloların her birinde ayrı bir girdi olarak saklamak yerine, Müşteriler tablosunda veya ayrı bir Adresler tablosunda olmak üzere tek bir konumda saklayın.

Üçüncü normal form

  • Anahtara bağımlı olmayan alanları ortadan kaldırın.

Bu kaydın anahtarının parçası olmayan bir kayıttaki değerler tabloya ait değildir. Genel olarak, bir alan grubu içeriğinin tabloda birden çok kayda uygulanabileceği durumlarda, bu alanları ayrı bir tabloya yerleştirebilirsiniz.

Örneğin bir Çalışan İşe Alma tablosunda, bir adayın bitirdiği üniversitenin adı ve adresi bulunabilir. Ancak grup postaları için tüm üniversitelerin listesi gerekir. Üniversite bilgileri Adaylar tablosunda saklanıyorsa, geçerli adaylar olmayan üniversiteler listelenemez. Ayrı bir Üniversiteler tablosu oluşturup bu tabloyu bir üniversite kodu anahtarıyla Adaylar tablosuna bağlayın.

ÖZEL DURUM: Teorik olarak istenen üçüncü normal forma bağlı olmak her zaman pratik değildir. Bir Müşteriler tablonuz varsa ve tüm olası alanlar arası bağımlılıkları kaldırmak isterseniz şehirler, posta kodları, satış temsilcileri, müşteri sınıfları ve birden çok kayıtta yinelenebilecek tüm diğer öğeler için ayrı tablolar oluşturmalısınız. Teoride, normalleştirme devam etmeye değer. Ancak çok sayıda küçük tablo nedeniyle performans düşebilir veya açık dosya ve bellek özellikleri yetersiz kalabilir.

Üçüncü normal formun yalnızca sık sık değişen verilere uygulanması daha uygun olabilir. Bazı bağımlı alanlar kalacaksa, uygulamanızı kullanıcıdan herhangi bir alan değiştiğinde tüm ilgili alanları doğrulamasını isteyecek biçimde tasarlayın.

Diğer normalleştirme formları

Boyce-Codd Normal Form (BCNF) olarak da adlandırılan dördüncü normal form ve beşinci normal form vardır, ancak pratik tasarımda nadiren kabul edilir. Bu kuralları göz ardı etme, mükemmel veritabanı tasarımından daha azı ile sonuçlanabilir, ancak işlevselliği etkilememelidir.

Örnek bir tabloyu normalleştirme

Aşağıdaki adımlarda, kurgusal bir öğrenci tablosunu normalleştirme işlemi gösterilmektedir.

  1. Normalleştirilmemiş tablo:

    Öğrenci# Danışman Oda No Ders1 Ders2 Ders3
    1022 Güneş 412 101-07 143-01 159-02
    4123 Etikan 216 101-07 143-01 179-04
  2. İlk normal form: Yinelenen grup yok

    Tablolar yalnızca iki boyutlu olmalıdır. Aynı öğrenci birden çok ders alacağı için, bu dersler ayrı bir tabloda listelenmelidir. Yukarıdaki kayıtlardaki Ders1, Ders2 ve Ders3 alanları bir tasarım sorununun göstergesidir.

    Elektronik tablolar genellikle üçüncü boyutu kullanır, ancak tablolar kullanmamalıdır. Bu soruna bakmanın başka bir yolu da bire çok ilişkisidir; tek tarafı ve çok tarafını aynı tabloya yerleştirmeyin. Bunun yerine, aşağıdaki örnekte gösterildiği gibi yinelenen grubu (Class#) ortadan kaldırarak ilk normal biçimde başka bir tablo oluşturun:

    Öğrenci# Danışman Oda No Ders#
    1022 Güneş 412 101-07
    1022 Güneş 412 143-01
    1022 Güneş 412 159-02
    4123 Etikan 216 101-07
    4123 Etikan 216 143-01
    4123 Etikan 216 179-04
  3. İkinci normal form: Fazlalık verileri ortadan kaldırma

    Yukarıdaki tabloda yer alan her Student# değeri için birden çok Class# değerini not edin. Sınıf# işlevsel olarak Student# (birincil anahtar) öğesine bağımlı olmadığından, bu ilişki ikinci normal biçimde değildir.

    Aşağıdaki tablolar, ikinci normal formu göstermektedir:

    Öğrenciler:

    Öğrenci# Danışman Oda No
    1022 Güneş 412
    4123 Etikan 216

    Kayıt:

    Öğrenci# Ders#
    1022 101-07
    1022 143-01
    1022 159-02
    4123 101-07
    4123 143-01
    4123 179-04
  4. Üçüncü normal form: Anahtara bağımlı olmayan verileri ortadan kaldırma

    Son örnekte, Oda No öğesi (danışmanın oda numarası) Danışman özniteliğine işlevsel olarak bağımlıdır. Çözüm, bu özniteliği aşağıda gösterildiği gibi Öğrenciler tablosundan Fakülte tablosuna taşımaktır:

    Öğrenciler:

    Öğrenci# Danışman
    1022 Güneş
    4123 Etikan

    Fakülte:

    Name Oda Bölüm
    Güneş 412 42
    Etikan 216 42