Veritabanı normalleştirme temellerinin açıklaması

Bu makalede, yeni başlayanlar için veritabanı normalleştirme terminolojisi açıklanmaktadır. İlişkisel veritabanının tasarımı tartışılırken bu terminoloji hakkında temel bilgiler yararlı olur.

Normalleştirmenin açıklaması

Normalleştirme, veritabanındaki verileri düzenleme 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 tasarlanan kurallara göre tablolar oluşturmayı ve bu tablolar arasında ilişkiler kurmayı içerir.

Yedekli veriler disk alanını boşa harcar ve bakım sorunları oluşturur. Birden fazla yerde bulunan verilerin değiştirilmesi gerekiyorsa, verilerin tüm konumlarda tam olarak aynı şekilde değiştirilmesi gerekir. Bu veriler yalnızca Müşteriler tablosunda depolanıyorsa 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 Müşteriler tablosunda belirli bir müşterinin adresini araması sezgisel olsa da, o müşteriyi arayan çalışanın maaşına bakmak mantıklı olmayabilir. Çalışanın maaşı, çalışanla ilişkili veya buna bağımlıdır ve bu nedenle Çalışanlar tablosuna taşınmalıdır. Tutarsız bağımlılıklar, verileri bulma yolu eksik veya bozuk olabileceğinden verilere erişmeyi zorlaştırabilir.

Veritabanı normalleştirmesi için birkaç kural vardır. Her kurala "normal form" adı verilir. İlk kurala uyulursa, 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 ek tablolar gerektirir ve bazı müşteriler bunu zahmetli bulur. Normalleştirmenin ilk üç kuralından birini ihlal etmeye karar verirseniz, uygulamanızın yedekli veriler ve tutarsız bağımlılıklar gibi oluşabilecek sorunları öngördiğinden emin olun.

Aşağıdaki açıklamalarda örnekler verilmiştir.

İlk normal form

• Tek tek tablolarda yinelenen grupları ortadan kaldırın.
• İlgili her veri kümesi için ayrı bir tablo oluşturun.
• Her ilgili veri kümesini birincil anahtarla tanımlayın.

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

Üçüncü bir satıcı eklediğinizde 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 satıcı bilgilerini Satıcılar adlı ayrı bir tabloya yerleştirin, ardından envanteri madde numarası anahtarıyla satıcılara bağlayın veya satıcı kod anahtarıyla satıcıları envantere bağlayın.

İkinci normal form

• Birden çok kayda uygulanan değer kümeleri için ayrı tablolar oluşturun.
• Bu tabloları yabancı bir anahtarla ilişkilendirin.

Kayıtlar, tablonun birincil anahtarı (gerekirse bileşik anahtar) dışında hiçbir şeye bağımlı olmamalıdır. Örneğin, muhasebe sistemindeki bir müşterinin adresini göz önünde bulundurun. Adres, Müşteriler tablosu tarafından değil, Siparişler, Sevkiyat, Faturalar, Alacak Hesapları ve Koleksiyonlar tabloları tarafından da gereklidir. Müşterinin adresini bu tabloların her birinde ayrı bir giriş olarak depolamak yerine, Müşteriler tablosunda veya ayrı bir Adresler tablosunda tek bir yerde depolayı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 grubunun içeriği tablodaki tek bir kayıttan fazlasına uygulanabilirse, bu alanları ayrı bir tabloya yerleştirmeyi göz önünde bulundurun.

Örneğin, Bir Çalışan İşe Alım tablosunda, bir adayın üniversite adı ve adresi dahil edilebilir. Ancak grup postaları için üniversitelerin tam listesine ihtiyacınız var. Üniversite bilgileri Adaylar tablosunda depolanıyorsa, mevcut adayı olmayan üniversiteleri listelemenin bir yolu yoktur. Ayrı bir Üniversiteler tablosu oluşturun ve bunu bir üniversite kod anahtarıyla Adaylar tablosuna bağlayın.

ÖZEL DURUM: Teorik olarak istenen üçüncü normal forma bağlı olmak her zaman pratik değildir. Müşteriler tablonuz varsa ve tüm olası ara alan bağımlılıklarını ortadan kaldırmak istiyorsanız, şehirler, posta kodları, satış temsilcileri, müşteri sınıfları ve birden çok kayıtta çoğaltılmış olabilecek diğer faktörler için ayrı tablolar oluşturmanız gerekir. Teoride normalleşmenin peşinden koşmaya değer. Ancak, birçok küçük tablo performansı düşürebilir veya açık dosya ve bellek kapasitelerini aşabilir.

Üçüncü normal formun yalnızca sık değişen verilere uygulanması daha uygun olabilir. Bazı bağımlı alanlar kalırsa, herhangi bir alan değiştirildiğinde kullanıcının tüm ilgili alanları doğrulamasını gerektirecek şekilde uygulamanızı tasarlayabilirsiniz.

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ın dikkate alınmaması, mükemmel veritabanı tasarımından daha azı ile sonuçlanabilir, ancak işlevselliği etkilememelidir.

Örnek tabloyu normalleştirme

Bu adımlar kurgusal bir öğrenci tablosunu normalleştirme sürecini gösterir.

1. Normalleştirilmemiş tablo:

   Öğrenci#	Danışman	Adv-Room	Sınıf1	Sınıf2	Sınıf3
   1022	Jones	412	101-07	143-01	159-02
   4123	Etikan	216	101-07	143-01	179-04

2. İlk normalizasyon formu: Tekrarlayan gruplar yok

   Tabloların yalnızca iki boyutu olmalıdır. Bir öğrencinin birkaç sınıfı olduğundan, bu sınıflar ayrı bir tabloda listelenmelidir. Yukarıdaki kayıtlardaki Sınıf1, Sınıf2 ve Sınıf3 alanları tasarım sorunu göstergesidir.

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

   Öğrenci#	Danışman	Adv-Room	Sınıf#
   1022	Jones	412	101-07
   1022	Jones	412	143-01
   1022	Jones	412	159-02
   4123	Etikan	216	101-07
   4123	Etikan	216	143-01
   4123	Etikan	216	179-04

3. İkinci normal form: Yedekli verileri ortadan kaldırma

   Yukarıdaki tablodaki 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 tablolarda ikinci normal form gösterilmektedir:

   Öğrenci:

   Öğrenci#	Danışman	Adv-Room
   1022	Jones	412
   4123	Etikan	216

   Kayıt:

   Öğrenci#	Sınıf#
   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, Adv-Room (danışmanın ofis numarası) işlevsel olarak Advisor özniteliğine bağlıdır. Çözüm, aşağıda gösterildiği gibi bu özniteliği Öğrenciler tablosundan Fakülte tablosuna taşımaktır:

   Öğrenci:

   Öğrenci#	Danışman
   1022	Jones
   4123	Etikan

   Fakülte:

   İsim	Oda	Bölümü
   Jones	412	42
   Etikan	216	42