SQL'de Normalleştirme: 1NF, 2NF, 3NF & BCNF

Normalleştirme, ilişkisel bir veritabanı modelinin verimli olmasını, genel amaçlı sorgulamaya uygun olmasını ve verilerin bütünlüğünü kaybetmesine neden olan ekleme, güncelleme ve silme anormallikleri gibi istenmeyen özelliklerden arınmış olmasını sağlamaya yönelik sistematik bir süreçtir. Bu normalleştirme işlemi ayrıca veri fazlalığını ortadan kaldırmaya yardımcı olur ve herhangi bir ekleme, güncelleme veya silme işleminden sonra tutarsızlık olasılığını azaltır.

Daha iyi anlamak için aşağıdaki şemayı göz önünde bulundurun: Öğrenci (Ad, Adres, Konu, Not)

Bu şemada birkaç sorun veya verimsizlik var.

1) Fazlalık : Öğrencinin kayıtlı olduğu her ders için Adresi tekrarlanır.

2) Güncelleme anomalisi : Bir demette (satırda) Adresi güncellerken diğer satırlarda değiştirmemiş olabiliriz. Böylece her öğrenci için tutarlı bir şekilde benzersiz bir adresimiz olmayacaktı.

3) Ekleme Anomalisi : En az bir Ders kaydı yapmadan öğrencinin Adresini kaydetmeyeceğiz. Benzer şekilde, bir öğrenci yeni bir Konuya kaydolmak istediğinde, farklı bir Adresin girilmesi mümkündür.

4) Silme Anomalisi : Öğrenci, kayıtlı olduğu derslerin tamamına devam etmemeye karar verirse, silme işlemi sırasında öğrencinin adresi de kaybolur.

Bu nedenle, kullanıcı verilerini, grup ekleme, silme veya güncelleme işlemlerini takiben anormallikler oluşturmayan ilişkilerle temsil etmek önemlidir. Bu, yalnızca bütünlük kısıtlamalarının, özellikle de veri tabanının veri bağımlılıklarının dikkatli bir analiziyle başarılabilir.

İlişkiler, yalnızca doğal olarak birlikte var olan nitelikler gruplanacak şekilde tasarlanmalıdır. Bu, çoğunlukla tüm veri niteliklerinin anlamının temel olarak anlaşılmasıyla yapılabilir. Bununla birlikte, tasarım hedefimizi sağlamak için hala bazı resmi önlemlere ihtiyacımız var.

Normalleştirme bu resmi önlemdir. Belirli bir özellik grubunun neden diğerlerinden daha iyi olacağı sorusunu yanıtlar.

Bugün itibariyle yedi normal form mevcuttur:

• İlk Normal Form (1NF)
• İkinci Normal Form (2NF)
• Üçüncü Normal Form (3NF)
• Boyce-Codd Normal Formu (BCNF)
• Dördüncü Normal Form (4NF)
• Beşinci Normal Form (5NF)
• Altıncı veya Etki Alanı Anahtarı Normal form (6NF)

Okuyun: SQL'deki Görünüm Türleri

İlk Normal Form (1NF veya Minimal Form)

• Satırlarda yukarıdan aşağıya ve sütunlarda soldan sağa sıralama yoktur.
• Yinelenen satır yok.
• Her satır ve sütun kesişimi, geçerli etki alanından veya boş değerden tam olarak bir değer içerir. Bu koşul, tüm sütun değerlerinin atomik, skaler olması veya yalnızca tek bir değeri tutması gerektiğini belirtir. Burada birden çok sütunda bilgi veya değer tekrarına izin verilmez.
• Tüm sütunlar düzenlidir (yani, satırların satır kimlikleri, nesne kimlikleri veya gizli zaman damgaları gibi gizli bileşenleri yoktur).

Normalleştirilmemiş bir şema örneğini ele alalım. Bir tasarımcının müşterilerin isimlerini ve telefon numaralarını kaydetmek istediğini varsayalım. Gösterildiği gibi bir müşteri tablosu tanımlarlar:

Burada, 1 NF'de değil. Telefon Numaraları sütunu atomik değil veya skaler bir değere sahip değil, yani 1 NF'de izin verilmeyen birden fazla değere sahip.

1 NF yapmak için

• Önce tekli masamızı ikiye böleceğiz (ayrıştıracağız).
• Her tablo yalnızca bir varlık hakkında bilgi içermelidir.

Bu tasarımda tekrar eden telefon numaraları grupları oluşmaz. Bunun yerine, her Müşteri-Telefon Numarası bağlantısı kendi kaydında görünür.

Ödeme: En Yaygın SQL Mülakat Soruları ve Cevapları

İkinci Normal Form

Her normal form, öncekinden daha fazla kısıtlayıcı kritere sahiptir. Bu nedenle, ikinci normal formda (2NF) veya daha yüksek olan herhangi bir tablo, tanımı gereği 1NF'dedir. Öte yandan, 1NF'de olan bir tablo 2NF'de olabilir veya olmayabilir; 2NF'deyse, 3NF'de olabilir veya olmayabilir, vb.

Bir 1NF tablosunun, ancak ve ancak asal olmayan özniteliklerinden hiçbiri bir aday anahtarın bir parçasına (uygun altküme) işlevsel olarak bağımlı olmaması durumunda 2NF'de olduğu söylenir. (Bir asal olmayan nitelik, herhangi bir aday anahtara ait değildir.)

Bir 1NF tablosunda bileşik aday anahtarlar olmadığında (birden fazla öznitelikten oluşan aday anahtarlar), tablonun otomatik olarak 2NF'de olduğunu unutmayın.

FD ile R (A, B, C, D, E) İlişkisinin { BC ? D, AC? OL, B? E } 2NF'de mi?

• Görüldüğü gibi üyelik algoritması uygulanarak AC'nin kapanması (AC)+ = {A, C, B, E, D} olur. Ancak hiçbir alt kümesi, ilişkinin tüm özniteliğini kendi başına belirleyemez, bu nedenle AC, bu ilişkinin aday anahtarıdır. Ayrıca, ne A ne de C, ilişkinin başka herhangi bir özniteliğinden türetilemez, bu nedenle {AC} olan yalnızca 1 aday anahtar olacaktır.
• Burada {A, C} asal niteliklerdir ve {B, D, E} asal olmayan niteliklerdir.
• 1NF'deki ilişkisel bir VTYS, çoklu değerli veya bileşik özniteliğe izin vermediğinden, R ilişkisi zaten 1. normal formdadır.

M.Ö ? D, 2. normal formdadır çünkü BC, AC aday anahtarının uygun bir alt kümesi değildir,

AC ? AC'nin kendisi aday anahtar olduğundan BE 2. normal formdadır ve

B ? E 2. normal formdadır B, AC aday anahtarının uygun bir alt kümesi değildir.

Böylece verilen R bağıntısı 2. Normal Formdadır.

Üçüncü Normal Form

Bir tablonun, ancak ve ancak işlevsel bağımlılıklarının her biri için olması durumunda 3NF'de olduğu söylenir.

X → A , aşağıdaki koşullardan en az biri geçerlidir:

• X, A'yı içerir (yani, X → A önemsiz bir işlevsel bağımlılıktır) veya
• X bir süper anahtardır veya
• A bir asal niteliktir (yani, A aday anahtarda bulunur)

3NF'nin başka bir tanımı, R'nin her anahtar olmayan özniteliğinin, R'nin birincil anahtarına geçişsiz olarak bağımlı (yani doğrudan bağımlı) olduğunu belirtir. Bu, hiçbir asal olmayan özniteliğin (aday anahtarın parçası olmayan) işlevsel olarak diğer asal olmayan özniteliklere bağlı olmadığı anlamına gelir. A gibi iki bağımlılık varsa? B ve BC, o zaman bu FD'lerden A ? C. Bu bağımlılık AC geçişlidir.

3NF örneği:

Verilen FD'ler seti ile aşağıdaki Sipariş (Sipariş#, Parça, Tedarikçi, BirimFiyat, Adet Sipariş) ilişkisini göz önünde bulundurun:

Sipariş# ? Parça, Tedarikçi, QtyOrdered ve Tedarikçi, Bölüm ? Birim fiyat)

Burada Sıra#, ilişkinin anahtarıdır.

Amstrong aksiyomlarını kullanarak şunu elde ederiz:

Sipariş# ? Parça, Sipariş? Tedarikçi ve Sipariş ? AdetSipariş edildi.

Sipariş# ? Parça, Tedarikçi ve Tedarikçi, Bölüm ? Birim Fiyat, her ikisi de Sipariş# veriyor mu? Birim fiyat.

Böylece, tüm asal olmayan niteliklerin anahtara (Sipariş#) bağlı olduğunu görüyoruz. Ancak, Order# ile UnitPrice arasında geçişli bir bağımlılık vardır. Yani bu ilişki 3NF'de değil. 3NF'de nasıl yaparız?

Birisi o Parça için sipariş vermedikçe, herhangi bir Tedarikçi tarafından sağlanan herhangi bir Parçanın Birim Fiyatını saklayamayız. Bu yüzden 3NF'yi aşağıdaki gibi takip etmesi için tabloyu ayrıştırmamız gerekecek.

Sipariş (Sipariş#, Parça, Tedarikçi, Sipariş Miktarı) ve Ana Fiyat (Parça, Tedarikçi, BirimFiyat).

Şimdi geçişli bağımlılıklar mevcut değil. İlişki 3NF'de.

Ayrıca Okuyun: Veri Bilimi için SQL

Dünyanın En İyi Üniversitelerinden Online Yazılım Kursları Öğrenin . Kariyerinizi hızlandırmak için Yönetici PG Programları, Gelişmiş Sertifika Programları veya Yüksek Lisans Programları kazanın.

Çözüm

BCNF, 4NF, 5NF ve 6NF gibi normalleştirmeye daha çok şey var. Kısacası, BCNF, 3NF'nin bir uzantısından başka bir şey değildir, çünkü 3NF'nin son kuralı burada geçerli değildir. Tüm işlevsel bağımlılıkların, sol tarafta anahtar niteliklere sahip olması ve sağ tarafta hiçbirinin olmaması gerekir. (BCNF, 3.5NF olarak da adlandırılır). Bununla birlikte, 4NF ve ötesinden gelen normal formlar, düzenli uygulamada nadiren uygulanmaktadır.

Full-stack geliştirme hakkında daha fazla bilgi edinmek istiyorsanız, upGrad & IIIT-B'nin çalışan profesyoneller için tasarlanmış ve 500+ saatlik zorlu eğitim, 9+ proje sunan Full-stack Yazılım Geliştirmede Yönetici PG Programına göz atın. ve görevler, IIIT-B Mezunları durumu, pratik uygulamalı bitirme projeleri ve en iyi firmalarla iş yardımı.