SQL’de Normalizasyon: 1NF’ten 5NF’e Eksiksiz Kılavuz

Özet

• Normalizasyon, fazlalıkları ortadan kaldırmak ve veri bütünlüğünü korumak için ilişkisel veritabanı tablolarını düzenler
• 1NF: Her hücre tek bir atomik değer tutar; her satır benzersiz olarak tanımlanabilir
• 2NF: Kısmi bağımlılıkları kaldırın—anahtar olmayan sütunlar tüm birincil anahtara bağlı olmalıdır
• 3NF: Geçişli bağımlılıkları kaldırın—anahtar olmayan sütunlar diğer anahtar olmayan sütunlara değil yalnızca birincil anahtara bağlı olmalıdır
• BCNF, 4NF, 5NF: Karmaşık şemalar için fonksiyonel, çok değerli ve birleşim bağımlılıklarını ele alır
• Üretimdeki çoğu veritabanı 3NF’e kadar normalizasyona ihtiyaç duyar; daha üst formlar özel kullanım durumlarına uygulanır

SQL’de Normalizasyon Nedir?

Bu bağlamda normalizasyon, bir veritabanındaki (ilişkisel veritabanı) verileri, fazlalık gibi veri anomalilerini ortadan kaldıracak şekilde düzenleme sürecidir.

Basitçe söylemek gerekirse, büyük ve karmaşık bir tabloyu, veri ilişkilerini koruyarak daha küçük ve basit tablolara ayırmayı içerir.

Normalizasyon, genellikle büyük veri kümeleriyle çalışırken kullanılır.

Normalizasyonun sıkça kullanıldığı bazı senaryolara kısaca göz atalım.

Veri bütünlüğü

Müşteri bilgileri içeren bir veritabanı hayal edin. Normalizasyon olmadan, bir müşteri yaşını değiştirdiğinde bunu birden çok yerde güncellememiz gerekir; bu da tutarsızlık riskini artırır. Verileri normalize ederek, verinin doğru ve tutarlı kalmasını sağlayan benzersiz bir tanımlayıcıyla birbirine bağlanan ayrı tablolar oluşturabiliriz.

Verimli sorgulama

Yinelenen bilgiler saklayan, birbiriyle ilişkili birden fazla tablodan oluşan karmaşık bir veritabanını düşünelim. Bu durumda, join içeren sorgular daha karmaşık ve kaynak tüketimi yüksek hale gelir. Normalizasyon, verileri daha küçük tablolara bölerek ve her tabloda yalnızca ilgili bilgileri tutarak sorgulamayı basitleştirir, böylece karmaşık join’lere duyulan ihtiyacı azaltır.

Depolama optimizasyonu

Yinelenen verilerin büyük bir sorunu, gereksiz depolama alanı kaplamasıdır. Örneğin, aynı ürün ayrıntılarını her sipariş kaydında saklarsak, kopyalamaya yol açar. Normalizasyonla, verileri ayrı tablolara bölerek fazlalıkları ortadan kaldırabilirsiniz.

SQL’de Normalizasyon Neden Önemlidir?

Normalizasyon, veritabanı tasarımında kritik bir rol oynar. İşte neden vazgeçilmez olduğuna dair birkaç neden:

• Fazlalığı azaltır:Fazlalık, aynı bilginin birden fazla kez saklanmasıdır; bunu önlemenin iyi bir yolu verileri daha küçük tablolara ayırmaktır.
• Sorgu performansını artırır: Normalizasyon uygulanmış daha küçük tablolarda sorgular daha hızlı çalıştırılabilir.
• Güncelleme anomalilerini en aza indirir: Normalize edilmiş tablolarda, diğer kayıtları etkilemeden verileri kolayca güncelleyebilirsiniz.
• Veri bütünlüğünü güçlendirir: Verinin tutarlı ve doğru kalmasını sağlar.

Normalizasyon İhtiyacını Ne Doğurur?

Bir tablo düzgün normalize edilmemişse ve veri fazlalığı içeriyorsa, yalnızca fazladan depolama alanı tüketmekle kalmaz; veritabanını yönetmeyi ve güncellemeyi de zorlaştırır.

Normalizasyon ihtiyacını doğuran çeşitli etkenler vardır; yukarıda değinildiği gibi veri fazlalığından ilişkileri yönetme zorluğuna kadar uzanır. Hemen bakalım:

• Ekleme, silme ve güncelleme anomalileri: Bir tabloda yapılan her tür değişiklik, dikkatli ele alınmazsa diğer tablolarda hatalara veya tutarsızlıklara yol açabilir. Bu değişiklikler veritabanına yeni veri ekleme, veriyi güncelleme veya kayıtları silme olabilir ve istenmeyen veri kaybına neden olabilir.
• İlişkileri yönetme zorluğu: Normalize edilmemiş bir yapıda karmaşık ilişkileri sürdürmek daha zor hale gelir.
• Normalizasyon ihtiyacını doğuran diğer etkenler kısmi bağımlılıklar ve geçişli bağımlılıklardır. Kısmi bağımlılıklar veri fazlalığına ve güncelleme anomalilerine, geçişli bağımlılıklar ise veri anomalilerine yol açabilir. İlerleyen bölümlerde, veritabanı normalizasyonunu sağlamak için bu bağımlılıkların nasıl ele alınabileceğine bakacağız.

Farklı Veritabanı Normalizasyon Türleri

Şimdiye kadar SQL’de normalizasyonun ne olduğunu, neden önemli olduğunu ve normalizasyon ihtiyacını neyin doğurduğunu gördük. Veritabanı normalizasyonu, her biri giderek artan düzeyde veri organizasyonu sunan farklı formlarda gelir.

Bu bölümde, farklı normalizasyon seviyelerini kısaca ele alacak, ardından bir sonraki bölümde daha derine ineceğiz.

Görsel: Yazar

Normal formların hızlı karşılaştırması

Birinci Normal Form (1NF)

Bu normalizasyon seviyesi, verilerinizdeki her sütunun yalnızca atomik değerler içermesini sağlar. Bu bağlamda atomik değer, bir sütundaki her kaydın bölünemez olduğu anlamına gelir. Bir e-tablo hücresinin sadece tek bir bilgi tutması gerektiğini söylemek gibidir.1NF, her sütun hücresinin yalnızca tek bir değer içermesini ve her sütunun benzersiz adlara sahip olmasını sağlayarak verinin atomikliğini güvence altına alır.

İkinci Normal Form (2NF)

Kısmi bağımlılıkları ortadan kaldırır; anahtar olmayan özniteliklerin yalnızca birincil anahtara bağlı olmasını sağlar. Özünde bu, her sütun ile birincil anahtar arasında doğrudan bir ilişki olması ve sütunların birbirine bağlı olmaması gerektiği anlamına gelir.

Üçüncü Normal Form (3NF)

Geçişli bağımlılıkları ortadan kaldırır; anahtar olmayan özniteliklerin yalnızca birincil anahtara bağlı olmasını sağlar. Bu normalizasyon seviyesi 2NF üzerine inşa edilir.

Boyce-Codd Normal Formu (BCNF)

Bu, ek anomalileri ele alan 3NF’in daha katı bir sürümüdür. Bu normalizasyon seviyesinde her belirleyici bir aday anahtardır.

Dördüncü Normal Form (4NF)

Bu, çok değerli bağımlılıkları ele alarak BCNF üzerine inşa edilen bir normalizasyon seviyesidir.

Beşinci Normal Form (5NF)

5NF, birleşim bağımlılıklarını ele alan en yüksek normalizasyon seviyesidir. Fazlalığı daha da azaltmak için bir tabloyu daha küçük tablolara bölme yoluna gidilen özel senaryolarda kullanılır.

Gerçek Dünya Örnekleriyle Veritabanı Normalizasyonu

Tüm veri normalizasyon seviyelerini özetledik. Şimdi her birini örnekler ve açıklamalarla daha derinlemesine inceleyelim.

Birinci Normal Form (1NF) Normalizasyonu

1NF, her sütun hücresinin yalnızca atomik değerler içermesini sağlar. Kitap bilgilerini (başlık, yazar, tür ve borrowed_by) saklayan bir tabloya sahip bir kütüphane veritabanını düşünün. Tablo normalize edilmemişse, borrowed_by alanı virgülle ayrılmış borçlu adlarının bir listesini içerebilir. Bu, tek bir hücrede birden çok değer tutulduğu için 1NF’i ihlal eder. Aşağıdaki tablo, yukarıda açıklandığı gibi 1NF’i ihlal eden bir tabloya iyi bir örnektir.

Çözüm?

1NF’te borçlular için ayrı bir tablo oluşturur ve bunları kitap tablosuna bağlarız. Bu tablolar, borçlular tablosundaki yabancı anahtar kullanılarak veya ayrı bir ilişki tablosuyla bağlanabilir. Borçlular tablosundaki yabancı anahtar yaklaşımı, borçlular tablosuna, kitaplar tablosunun birincil anahtarına referans veren bir yabancı anahtar sütunu eklemeyi içerir. Bu, tablolar arasında bir ilişki uygular ve veri tutarlılığını sağlar.

Bunun bir gösterimini aşağıda bulabilirsiniz:

Bu normalize edilmiş tabloları oluşturmak için SQL şöyledir:

CREATE TABLE books (
    book_id INT PRIMARY KEY,
    title VARCHAR(255),
    author VARCHAR(100),
    genre VARCHAR(50)
);

CREATE TABLE borrowers (
    borrower_id INT PRIMARY KEY,
    name VARCHAR(100),
    book_id INT,
    FOREIGN KEY (book_id) REFERENCES books(book_id)
);

Books tablosu

Borrowers tablosu

İkinci Normal Form (2NF)

Daha önce açıklandığı gibi bu normalizasyon seviyesi, birincil anahtarda kısmi bağımlılıkların olmamasını sağlayarak 1NF üzerine inşa edilir. Basitçe söylemek gerekirse, anahtar olmayan tüm öznitelikler yalnızca birincil anahtarın tamamına bağlı olmalı, bir kısmına değil.

Uygulanan 1NF’ten itibaren hâlihazırda iki ayrı tablomuz var (1NF bölümüne bakabilirsiniz).

Şimdi, bu tabloları ödünç alma kayıtlarını tutmak için bağlamak istediğimizi varsayalım. İlk yaklaşım, aşağıda gösterildiği gibi books tablosuna basitçe bir borrower_id sütunu eklemek olabilir:

Bu bir çözüm gibi görünse de, 2NF’i ihlal eder; çünkü borrower_id yalnızca book_id’ye kısmen bağlıdır. Bir kitabın birden çok borçlusu olabilir, ancak bu yapıda tek bir borrower_id yalnızca bir kitaba bağlanabilir. Bu da kısmi bağımlılık oluşturur.

Çözüm?

2NF’i sağlamak için kitaplar ve borçlular arasında çoktan çoğa ilişki kurmamız gerekir. Bu, ayrı bir tablo eklenerek yapılabilir:

Book_borrowings tablosu

Bu tablo, kitaplar ve borçlular arasında net bir ilişki kurar. book_id ve borrower_id, ilgili tablolarındaki birincil anahtarlara referans veren yabancı anahtarlar olarak görev yapar. Bu yaklaşım, borrower_id’nin books tablosunun birincil anahtarının (book_id) tamamına bağlı olmasını sağlayarak 2NF ile uyumludur.

Üçüncü Normal Form (3NF)

3NF, geçişli bağımlılıkları ortadan kaldırarak 2NF üzerine inşa edilir. Geçişli bağımlılık, anahtar olmayan bir özniteliğin, yine anahtar olmayan başka bir özniteliğe bağlı olduğu; onun da birincil anahtara bağlı olduğu durumda ortaya çıkar. Temelde geçişme yasasından anlamını alır.

Uyguladığımız 2NF’ten itibaren, kütüphane veritabanımızda üç tablo vardır:

Books tablosu

Borrowers tablosu

Book_borrowings tablosu

2NF yapısı verimli görünse de gizli bir bağımlılık olabilir. Books tablosuna due_date sütunu eklediğimizi hayal edin. İlk bakışta mantıklı görünse de bu, şu durumu yaratarak geçişli bir bağımlılık oluşturacaktır:

• due_date sütunu, book_borrowings tablosundaki anahtar olmayan bir öznitelik olan borrowing_id’ye bağlı olur.
• Borrowing_id ise books tablosunun birincil anahtarı olan book_id’ye bağlıdır.

Bunun sonucu, due_date’in doğrudan birincil anahtara (book_id) bağlı olmak yerine, aradaki anahtar olmayan bir özniteliğe (borrowing_id) bağlı hale gelmesidir. Bu, 3NF’i ihlal eder.

Çözüm?

due_date sütununu en uygun tabloya taşıyabilir; book_borrowings tablosunu due_date ve returned_date sütunlarını içerecek şekilde güncelleyebiliriz.

Güncellenmiş tablo aşağıdadır:

due_date sütununu book_borrowings tablosuna koyarak geçişli bağımlılığı başarıyla ortadan kaldırdık.

Bunun anlamı, due_date’in artık doğrudan book_id ve borrower_id arasındaki birleşik ilişkiye bağlı olmasıdır. Bu bağlamda book_id ve borrower_id, birlikte book_borrowings tablosunun birincil anahtarını oluşturan bileşik bir yabancı anahtar gibi davranmaktadır.

Boyce-Codd Normal Formu (BCNF)

BCNF, bir ilişkideki tüm aday anahtarları dikkate alan fonksiyonel bağımlılıklara dayanır.

Fonksiyonel bağımlılıklar (FD), bir ilişkisel veritabanındaki öznitelikler arasındaki ilişkileri tanımlar. Bir FD, bir sütunun değerinin ilgili başka bir sütunun değerini belirlediğini ifade eder. FD’ler, bağımlılıkları belirleyip verinin tablolara uygun şekilde dağıtılmasını sağlayarak normalizasyon sürecine rehberlik ettikleri için çok önemlidir.

BCNF, 3NF’in daha katı bir sürümüdür. Bir tablodaki her belirleyicinin (bir satırı benzersiz olarak tanımlayan öznitelik kümesi) bir aday anahtar (bir satırı benzersiz tanımlayan minimal öznitelik kümesi) olmasını garanti eder. Özünde, tüm belirleyicilerin birincil anahtar olarak hizmet edebilmesi gerekir.

Her fonksiyonel bağımlılığın (FD) belirleyicisinin bir süper anahtar olmasını güvence altına alır. Başka bir deyişle, X —> Y (X, Y’yi belirler) geçerliyse, X ilişkinin bir aday anahtarı (süper anahtarı) olmalıdır. Lütfen X ve Y’nin bir veri tablosundaki sütunlar olduğunu not edin.

3NF’ten devamla üç tablomuz var:

Books tablosu

Borrowers tablosu

Book_borrowings tablosu

3NF yapısı iyi olsa da book_borrowings tablosunda gizli bir belirleyici olabilir. Bir borçlunun aynı kitabı eşzamanlı olarak iki kez ödünç alamadığını varsayarsak, book_id ve borrower_id birleşimi bir ödünç alma kaydını benzersiz olarak tanımlar.

Bu yapı BCNF’i ihlal eder; çünkü birleşik küme (book_id ve borrower_id) tablonun birincil anahtarı değildir (yalnızca borrowing_id birincil anahtardır).

Çözüm?

BCNF’i sağlamak için book_borrowings tablosunu iki ayrı tabloya ayrıştırabilir veya birleşik öznitelik kümesini birincil anahtar yapabiliriz.

1. Yaklaşım 1 (tabloyu ayrıştırma): Bu yaklaşımda, book_borrowings tablosunu ayrı tablolara ayıracağız:

• • borrowing_id’nin birincil anahtar olduğu; borrowed_date, due_date ve returned_date sütunlarını içeren bir tablo.
  • Kitaplar ve borçluları bağlamak için; book_id ve borrower_id’nin yabancı anahtar olduğu ve olası ek olay-özel öznitelikler içeren başka bir ayrı tablo.

2. Yaklaşım 2 (birleşik öznitelik kümesini birincil anahtar yapma): Ödünç alma kayıtlarını benzersiz tanımlamak için book_id ve borrower_id’yi bileşik birincil anahtar yapmayı düşünebiliriz. Bu yaklaşımın sorunu, bir borçlu aynı kitabı birden çok kez ödünç alabiliyorsa amacına hizmet etmeyecek olmasıdır.

Sonuçta bu seçenekler arasındaki tercih, spesifik veri ihtiyaçlarınıza ve ödünç alma ilişkilerini nasıl modellemek istediğinize bağlıdır.

Dördüncü Normal Form (4NF)

4NF, çok değerli bağımlılıkları ele alır. Bir özniteliğin birden çok bağımlı özniteliğe sahip olabildiği ve bu bağımlı özniteliklerin birincil anahtardan bağımsız olduğu durumlarda çok değerli bağımlılık vardır. Oldukça karmaşıktır; ancak bir örnek üzerinden daha derinlemesine inceleyeceğiz.

Bu açıklamalar boyunca kullandığımız kütüphane örneği bu normalizasyon seviyesi için uygun değildir. 4NF genellikle tek bir özniteliğin, birincil anahtarla doğrudan ilişkisi olmayan birden çok bağımlı özniteliğe sahip olabildiği durumlara uygulanır.

Başka bir senaryo kullanalım. Yayınlarla ilgili bilgileri saklayan bir veritabanı hayal edin. “Publications” tablosunda title, author, publication_year ve keywords sütunlarını ele alacağız.

Yukarıdaki tablo yapısı 4NF’i ihlal etmektedir; çünkü:

• keywords sütunu, birincil anahtar publication_id üzerinde çok değerli bir bağımlılığa sahiptir. Bu, bir yayının birden çok anahtar sözcüğe sahip olabileceği ve bu anahtar sözcüklerin yayının benzersiz tanımlayıcısından bağımsız olduğu anlamına gelir.

Çözüm?

Ayrı bir tablo oluşturabiliriz.

Publication_keywords tablosu

Yeni oluşturulan tablo (Publication_keywords), yayınlar ve anahtar sözcükler arasında çoktan çoğa bir ilişki kurar. Her yayın, publication_id (yabancı anahtar) üzerinden birden çok anahtar sözcükle ilişkilendirilebilir ve her anahtar sözcük birden çok yayınla ilişkili olabilir.

Böylece çok değerli bağımlılığı başarıyla ortadan kaldırdık ve 4NF’e ulaştık.

Beşinci Normal Form (5NF)

5NF, birleşim bağımlılıklarını ortadan kaldıran en karmaşık normalizasyon biçimidir. Bu, tablolar 4NF’te bile olsa belirli bir sorguyu yanıtlamak için verilerin birden çok tablodan birleştirilmesini gerektiren bir durumdur.

Daha basit bir ifadeyle, 5NF, tablolar bir araya getirildiğinde, ayrı tablolarda zaten bulunmayan ek hiçbir bilginin türetilememesini sağlar.

Tablolar zaten normalize edildiğinde (3NF veya 4NF’te) birleşim bağımlılıkları daha az olasıdır; bu nedenle 5NF için net ve doğrudan bir örnek oluşturmak zordur.

Yine de, 5NF’in ilgili olabileceği şu senaryoya bakalım:

“Courses” ve “Enrollments” için normalize edilmiş tablolara sahip bir üniversite veritabanını hayal edin.

Courses tablosu

Enrollments tablosu

Bu tabloların zaten 3NF veya 4NF’te olduğunu varsayarsak, verilerin nasıl saklandığına bağlı olarak bir birleşim bağımlılığı mevcut olabilir. Örneğin, bir dersin ön koşulu, “Courses” tablosunda “prerequisite_course_id” sütunu olarak saklanmaktadır.

Bu ilk bakışta verimli görünebilir. Ancak, bir öğrencinin kayıtlı olduğu dersleri ve bunların ilgili ön koşullarını getirmesi gereken bir sorguyu düşünün. Bu senaryoda, “Courses” ve “Enrollments” tablolarını birleştirmeniz, ardından ön koşul bilgilerini almak için muhtemelen “Courses” tablosunu yeniden birleştirmeniz gerekir.

Çözüm?

Birleşim bağımlılığını potansiyel olarak ortadan kaldırmak ve 5NF’e ulaşmak için ayrı bir “Course Prerequisites” tablosu ekleyebiliriz:

Course_prerequisite tablosu

Bu yaklaşım, ön koşul bilgisini ayırır ve “Enrollments” ile “Course_prerequisites” tabloları arasında tek bir join ile kayıtlı dersler ve bunların ön koşullarının verimli şekilde alınmasına olanak tanır.

Not: Bir öğrencinin ders başına yalnızca bir ön koşulu olabildiğini varsayıyoruz.

5NF çok karmaşık ve nadir bir normalizasyon türüdür; bu nedenle veri alanındaki öğrenme yolculuğunuza yeni başlıyorsanız uygulamasını pek görmeyebilirsiniz. Yine de ek bir bilgi sağlar ve karmaşık veritabanlarıyla karşılaştığınızda hazırlıklı olmanızı sağlar.

Normalizasyon ve Denormalizasyon

Normalizasyon fazlalığı azaltır ve veri bütünlüğünü artırır; ancak bazı durumlarda denormalizasyon daha iyi bir seçimdir. Denormalizasyon, belirli iş yüklerinde okuma performansını artırmak için kasıtlı olarak fazlalık ekler.

Uygulamada, üretimdeki çoğu veritabanı her iki yaklaşımı da birlikte kullanır. Tamamen normalize bir şemayla başlayın, ardından sorgu performansının gerektirdiği yerlerde seçici olarak denormalize edin.

SQL Becerilerinizi Geliştirin

Bunu okuyorsanız, sonuna kadar bizimle kaldığınız için tebrikler. SQL’de normalizasyonun ne olduğu, neden önemli olduğu, normalizasyon ihtiyacını neyin doğurduğu ve farklı veritabanı normalizasyon türlerini keşfetmek harika bir yolculuk oldu. Farklı normalizasyon türlerini açıklarken kullanılan senaryolar, bu bilgiyi tam olarak anlamanız ve öğrenme yolculuğunuzda uygulayabilmeniz içindir.

Normalizasyon, veriyle ilgili herhangi bir kariyer yoluna başlayan herkes için temel bir beceridir. Bu ilkeleri anlayarak artık verimli ve iyi organize edilmiş veritabanları kurmaya hazırsınız.

Öğrenme, veri alanında çok önemlidir ve SQL becerilerinizi geliştirmek için bazı kaynaklarımız var.

• Creating PostgreSQL Databases Kursu
• DBMS’de Normalizasyon: SQL Örnekleriyle Eksiksiz Kılavuz
• Veri Modellemesi Açıklaması: Teknikler, Örnekler ve En İyi Uygulamalar
• SQL Sorgu Örnekleri ve Kılavuzu
• Veritabanlarında Denormalizasyon: Ne Zaman ve Nasıl Kullanılır