Neler yeni

Yazılım Forum

Tüm özelliklerimize erişmek için şimdi bize katılın. Kayıt olduktan ve giriş yaptıktan sonra konu oluşturabilecek, mevcut konulara yanıt gönderebilecek, itibar kazanabilecek, özel mesajlaşmaya erişebilecek ve çok daha fazlasını yapabileceksiniz! Bu hizmetlerimiz ise tamamen ücretsiz ve kurallara uyulduğu sürece sınırsızdır, o zaman ne bekliyorsunuz? Hadi, sizde aramıza katılın!

Veritabanı Normalizasyon Prensipleri: Kapsamlı Bir Rehber

Veritabanı Normalizasyonu Nedir?
Veritabanı normalizasyonu, bir veritabanının tasarımını optimize etmek için kullanılan sistematik bir süreçtir. Temel amacı, veri yedekliliğini (redundancy) azaltmak ve veri tutarlılığını (consistency) artırmaktır. Normalizasyon, veritabanı şemasını daha küçük, daha yönetilebilir ve daha az sorunlu ilişkilere (tablolara) ayırarak veri bütünlüğü sorunlarını, yani ekleme, güncelleme ve silme anomalilerini ortadan kaldırmayı veya minimize etmeyi hedefler. Bu süreç, veritabanının daha verimli çalışmasını, daha az disk alanı kullanmasını ve daha güvenilir olmasını sağlar. Veritabanı yönetim sistemlerinin (VTYS) etkinliğini artıran temel prensiplerden biridir.

Veri yedekliliği, aynı verinin veritabanının farklı yerlerinde birden fazla kez saklanması durumudur. Bu durum, depolama alanını israf etmekle kalmaz, aynı zamanda veri anormalliklerine yol açar. Örneğin, bir müşteri adresini değiştirdiğinde, bu adresin saklandığı her yerde güncellenmesi gerekir. Eğer bir yerde unutulursa, veritabanında çelişkili bilgiler ortaya çıkar. Normalizasyon bu tür sorunları önlemek için kritik bir araçtır.

Normalizasyonun temel faydaları şunlardır:
  • Veri Bütünlüğü: Verilerin tutarlı ve doğru kalmasını sağlar.
  • Yedekliliğin Azaltılması: Gereksiz veri tekrarını ortadan kaldırır, depolama alanından tasarruf sağlar.
  • Anormalliklerin Giderilmesi: Ekleme, güncelleme ve silme işlemlerinde ortaya çıkabilecek problemleri önler.
  • Veritabanı Yapısının İyileştirilmesi: Daha mantıksal, esnek ve sürdürülebilir bir şema oluşturur.
  • Daha Hızlı Sorgular: Bazı durumlarda, daha küçük ve odaklanmış tablolar daha hızlı sorgu yanıtları sağlayabilir.
  • Daha Kolay Bakım: İyi normalize edilmiş bir veritabanının bakımı ve yönetimi daha kolaydır.

Normalizasyon süreci, artan katı kurallar dizisi olan "Normal Formlar" (Normal Forms - NF) aracılığıyla ilerler. Her normal form, bir önceki formun gerekliliklerini karşılamanın yanı sıra ek kurallar da getirir. Yaygın olarak kullanılan normal formlar Birinci Normal Form (1NF), İkinci Normal Form (2NF), Üçüncü Normal Form (3NF) ve Boyce-Codd Normal Form (BCNF) şeklindedir. Daha ileri formlar olan Dördüncü Normal Form (4NF) ve Beşinci Normal Form (5NF) da bulunmaktadır.

1. Birinci Normal Form (1NF)
Bir tablonun 1NF'de olabilmesi için aşağıdaki koşulları sağlaması gerekir:
  • Her hücrede yalnızca bir atomik (bölünemez) değer bulunmalıdır. Yani, bir sütun birden fazla değer veya karmaşık bir yapı (örneğin, virgülle ayrılmış bir listeler dizisi) içermemelidir.
  • Her sütunun belirli bir veri tipi olmalı ve bu tipte değerler içermelidir.
  • Her satır benzersiz olmalıdır (yani, her satır için bir birincil anahtar olmalıdır, ancak bu genellikle daha sonraki aşamalarda tanımlanır).
  • Tekrarlayan gruplar olmamalıdır. Yani, bir satır içinde aynı türden birden fazla bilgi tekrar etmemeli; bunun yerine ayrı satırlara veya ayrı tablolara taşınmalıdır.
Örnek olarak, bir ÖğrenciDersler tablonuz olduğunu varsayalım ve bir öğrencinin aldığı dersleri bir sütunda virgülle ayırarak saklıyorsunuz:
Kod:
ÖğrenciID | ÖğrenciAdı | Dersler
-----------|-------------|------------------
101        | Ayşe Yılmaz | Matematik, Fizik
102        | Can Demir   | Kimya
Bu tablo 1NF'de değildir çünkü "Dersler" sütunu atomik değildir. 1NF'e dönüştürmek için her dersi ayrı bir satıra taşımamız veya ayrı bir tabloya ayırmamız gerekir:
Kod:
ÖğrenciID | ÖğrenciAdı | Ders
-----------|-------------|-------------
101        | Ayşe Yılmaz | Matematik
101        | Ayşe Yılmaz | Fizik
102        | Can Demir   | Kimya
Bu yapı, "Dersler" sütunundaki çoklu değer sorununu çözer. Ancak, bu örnek hala potansiyel yedeklilik içerebilir.

2. İkinci Normal Form (2NF)
Bir tablonun 2NF'de olabilmesi için aşağıdaki koşulları sağlaması gerekir:
  • 1NF'de olmalıdır.
  • Birincil anahtarın (Primary Key) tüm kısımlarına tam bağımlı olmayan hiçbir kısmi bağımlılık (partial dependency) olmamalıdır. Kısmi bağımlılık, bir anahtar dışı sütunun, birleşik bir birincil anahtarın sadece bir kısmına bağlı olması durumudur.
Örnek olarak, önceki 1NF örneğimizden devam edelim, ancak şimdi birleşik bir anahtar kullanalım:
Kod:
Tablo: ÖğrenciDersleri
Birincil Anahtar: (ÖğrenciID, DersKodu)

ÖğrenciID | DersKodu | ÖğrenciAdı | DersAdı   | DersKredi
-----------|----------|-------------|-----------|-----------
101        | MAT101   | Ayşe Yılmaz | Matematik | 3
101        | FIZ101   | Ayşe Yılmaz | Fizik     | 4
102        | KIM201   | Can Demir   | Kimya     | 3
Bu tabloda birleşik bir birincil anahtar `(ÖğrenciID, DersKodu)` vardır.
* `ÖğrenciAdı`, `ÖğrenciID`'ye kısmi bağımlıdır (tüm birincil anahtara değil).
* `DersAdı` ve `DersKredi`, `DersKodu`'na kısmi bağımlıdır.
Bu, bir güncelleme anormalliğine yol açabilir: Ayşe Yılmaz'ın adını değiştirmek için her satırda güncelleme yapmanız gerekir. Veya bir öğrenci dersi bıraktığında, öğrenci ad bilgisi de silinebilir (silme anormalliği).
2NF'ye getirmek için bu kısmi bağımlılıkları gidermemiz gerekir:
Kod:
Tablo: Öğrenciler
Birincil Anahtar: ÖğrenciID

ÖğrenciID | ÖğrenciAdı
-----------|-------------
101        | Ayşe Yılmaz
102        | Can Demir

Tablo: Dersler
Birincil Anahtar: DersKodu

DersKodu | DersAdı   | DersKredi
----------|-----------|-----------
MAT101   | Matematik | 3
FIZ101   | Fizik     | 4
KIM201   | Kimya     | 3

Tablo: ÖğrenciDersKaydı
Birincil Anahtar: (ÖğrenciID, DersKodu)
Yabancı Anahtar: ÖğrenciID (Öğrenciler tablosundan), DersKodu (Dersler tablosundan)

ÖğrenciID | DersKodu
-----------|----------
101        | MAT101
101        | FIZ101
102        | KIM201
Şimdi her şey birincil anahtara tam bağımlıdır.

3. Üçüncü Normal Form (3NF)
Bir tablonun 3NF'de olabilmesi için aşağıdaki koşulları sağlaması gerekir:
  • 2NF'de olmalıdır.
  • Birincil anahtar dışındaki sütunlar arasında hiçbir geçişli bağımlılık (transitive dependency) olmamalıdır. Geçişli bağımlılık, bir anahtar dışı sütunun başka bir anahtar dışı sütuna bağlı olması durumudur. Yani, `A -> B` ve `B -> C` ise, `A -> C` (geçişli) bir bağımlılıktır. 3NF bunu engeller.
Örnek olarak, bir Personel tablosu düşünelim:
Kod:
Tablo: Personel
Birincil Anahtar: PersonelID

PersonelID | PersonelAdı | DepartmanKodu | DepartmanAdı     | DepartmanLokasyonu
-----------|-------------|---------------|------------------|-------------------
1          | Ali Veli    | DPT001        | İnsan Kaynakları | Merkez Bina
2          | Zeynep Ataş | DPT002        | Pazarlama        | Kuzey Ofis
3          | Cem Kara    | DPT001        | İnsan Kaynakları | Merkez Bina
Bu tabloda:
* `PersonelID` -> `DepartmanKodu`
* `DepartmanKodu` -> `DepartmanAdı`
* `DepartmanKodu` -> `DepartmanLokasyonu`
Burada `DepartmanAdı` ve `DepartmanLokasyonu` sütunları `PersonelID`'ye doğrudan değil, `DepartmanKodu` aracılığıyla bağlıdır. Bu bir geçişli bağımlılıktır. Eğer bir departmanın adını veya lokasyonunu değiştirmek isterseniz, bu departmanda çalışan her personel için güncelleme yapmanız gerekir. Yeni bir departman eklemek isterseniz, ilgili personeli eklemeden sadece departman bilgisi ekleyemezsiniz.
3NF'ye getirmek için bu geçişli bağımlılıkları ortadan kaldırmamız gerekir:
Kod:
Tablo: Personel
Birincil Anahtar: PersonelID

PersonelID | PersonelAdı | DepartmanKodu
-----------|-------------|---------------
1          | Ali Veli    | DPT001
2          | Zeynep Ataş | DPT002
3          | Cem Kara    | DPT001

Tablo: Departmanlar
Birincil Anahtar: DepartmanKodu

DepartmanKodu | DepartmanAdı     | DepartmanLokasyonu
---------------|------------------|-------------------
DPT001         | İnsan Kaynakları | Merkez Bina
DPT002         | Pazarlama        | Kuzey Ofis
Bu sayede veri yedekliliği azalmış ve anormallikler giderilmiştir. Bu genellikle çoğu uygulama için yeterli normalizasyon seviyesidir.

Normalizasyonun temel felsefesi, her bilgi parçasının veritabanında sadece bir yerde saklanması gerektiğidir.

4. Boyce-Codd Normal Form (BCNF)
BCNF, 3NF'nin daha katı bir versiyonudur. Bir tablonun BCNF'de olabilmesi için aşağıdaki koşulları sağlaması gerekir:
  • 3NF'de olmalıdır.
  • Her determinant (yani, başka bir sütunu veya sütun kümesini belirleyen her sütun veya sütun kümesi) bir aday anahtar (candidate key) olmalıdır.
3NF, anahtar dışı öznitelikler arasında geçişli bağımlılık olmamasını gerektirirken, BCNF hem anahtar dışı öznitelikler hem de anahtar öznitelikleri (yani birincil anahtarın parçası olan öznitelikler) arasındaki tüm geçişli bağımlılıkları ele alır. BCNF, birden fazla çakışan veya üst üste binen aday anahtar olduğunda 3NF'den farklılık gösterebilir. Nadiren görülür, ancak veritabanı tasarımcıları için önemli bir detaydır.

Örnek (basitleştirilmiş): Bir DersUzmanlığı tablosu düşünün.
Kod:
Tablo: DersUzmanlığı
Birincil Anahtar: (ÖğrenciID, DersAdı)

ÖğrenciID | DersAdı | UzmanÖğretmen
-----------|---------|---------------
101        | Fizik   | Prof. A
101        | Kimya   | Prof. B
102        | Fizik   | Prof. A
Burada:
* `ÖğrenciID` + `DersAdı` -> `UzmanÖğretmen` (Bir öğrenci belirli bir dersi bir uzman öğretmenden alır.)
* Aynı zamanda, `UzmanÖğretmen` -> `DersAdı` olabilir (Bir öğretmen yalnızca belirli bir dersi öğretmekte uzmandır).
Bu senaryoda, `UzmanÖğretmen` bir determinanttır (`DersAdı`'nı belirler) ancak bir aday anahtar değildir. Bu durum, 3NF'yi geçebilir ancak BCNF'yi ihlal eder. Çözüm, bu bağımlılığı ayrı bir tabloya taşımaktır.

Kod:
Tablo: ÖğrenciDers
Birincil Anahtar: (ÖğrenciID, DersAdı)

ÖğrenciID | DersAdı
-----------|---------
101        | Fizik
101        | Kimya
102        | Fizik

Tablo: UzmanÖğretmenDersleri
Birincil Anahtar: (DersAdı, UzmanÖğretmen)

DersAdı | UzmanÖğretmen
---------|---------------
Fizik   | Prof. A
Kimya   | Prof. B
Bu ayrım, BCNF'yi sağlar ve veri bütünlüğünü daha da artırır.

5. Dördüncü Normal Form (4NF)
Bir tablonun 4NF'de olabilmesi için aşağıdaki koşulları sağlaması gerekir:
  • BCNF'de olmalıdır.
  • Çok değerli bağımlılık (Multi-valued dependency - MVD) içermemelidir. Bir tabloda, bir öznitelik A, diğer öznitelikler B ve C'ye çok değerli bağımlıysa, bu, A'nın her bir değeri için B'nin birden çok değerinin ve C'nin birden çok değerinin bağımsız olarak var olduğu anlamına gelir. 4NF, gereksiz MVD'leri ortadan kaldırmayı hedefler.
Örnek: Bir ÖğrenciYetenekKursları tablosu düşünün. Bir öğrenci birden fazla yeteneğe ve birden fazla kursa kayıtlı olabilir, ancak yetenekler ve kurslar birbirinden bağımsızdır.
Kod:
Tablo: ÖğrenciYetenekKursları
Birincil Anahtar: (ÖğrenciID, Yetenek, Kurs)

ÖğrenciID | Yetenek     | Kurs
-----------|-------------|--------------
1          | Programlama | Veritabanları
1          | Programlama | Algoritmalar
1          | Resim       | Desen
1          | Resim       | Renk Teorisi
Bu tabloda:
* `ÖğrenciID` ->> `Yetenek` (Çok değerli bağımlılık)
* `ÖğrenciID` ->> `Kurs` (Çok değerli bağımlılık)
Yani, bir öğrenciye birden fazla yetenek ve birden fazla kurs atanabilir ve bu iki bağımlılık birbirinden bağımsızdır. Bu durum, anlamsız veri tekrarlarına yol açar.
4NF'ye getirmek için iki ayrı tabloya bölmek gerekir:
Kod:
Tablo: ÖğrenciYetenekleri
Birincil Anahtar: (ÖğrenciID, Yetenek)

ÖğrenciID | Yetenek
-----------|-------------
1          | Programlama
1          | Resim

Tablo: ÖğrenciKursları
Birincil Anahtar: (ÖğrenciID, Kurs)

ÖğrenciID | Kurs
-----------|--------------
1          | Veritabanları
1          | Algoritmalar
1          | Desen
1          | Renk Teorisi
Bu, 4NF'yi sağlar ve gereksiz veri tekrarlarını önler.

6. Beşinci Normal Form (5NF)
5NF, aynı zamanda Projeksiyon-Birleştirme Normal Formu (Project-Join Normal Form - PJNF) olarak da bilinir.
Bir tablonun 5NF'de olabilmesi için aşağıdaki koşulları sağlaması gerekir:
  • 4NF'de olmalıdır.
  • Hiçbir birleştirme bağımlılığı (join dependency) olmamalıdır. Yani, bir tablo, daha küçük (projeksiyon) tablolara bölündüğünde ve bu küçük tablolar tekrar birleştirildiğinde (join), orijinal tabloyla aynı sonuç elde edilmelidir.
5NF çok nadiren uygulanır çünkü çok karmaşık ve pratikte çok az fayda sağlayan durumları ele alır. Genellikle, 4NF'ye kadar normalizasyon çoğu veritabanı tasarımı için yeterlidir. Birleştirme bağımlılıkları, genellikle bir tabloyu üç veya daha fazla tabloya ayrıştırmanın daha fazla bilgi kaybına neden olmadığı durumlarda ortaya çıkar.

Normalizasyon ve Denormalizasyon
Normalizasyonun birincil amacı veri bütünlüğünü sağlamak ve yedekliliği azaltmak olsa da, aşırı normalizasyonun dezavantajları da olabilir. Aşırı normalizasyon, sorgu performansını düşürebilir çünkü bir sorgunun tamamlanması için çok sayıda tablonun birleştirilmesi (JOIN) gerekebilir. Bu, özellikle yüksek okuma yoğunluklu (read-heavy) sistemlerde önemli bir performans darboğazı yaratabilir.

Bu tür durumlarda, denormalizasyon adı verilen bir teknik devreye girebilir. Denormalizasyon, performansı artırmak amacıyla kontrollü bir şekilde veri yedekliliğini yeniden tanıtmaktır. Bu genellikle, sık kullanılan birleştirme işlemlerinden kaçınmak veya raporlama için özel olarak optimize edilmiş tablolar oluşturmak için yapılır. Ancak denormalizasyon, veri tutarlılığı riskini artırdığı için dikkatli ve bilinçli bir şekilde yapılmalıdır. Hangi seviyede normalizasyonun uygun olduğu, uygulamanın özel gereksinimlerine, veri hacmine ve performans beklentilerine bağlıdır. Genellikle 3NF, çoğu ticari uygulama için iyi bir denge noktası olarak kabul edilir. BCNF ve daha yüksek normal formlar, özellikle kritik veri bütünlüğü gereksinimleri olan veya çok karmaşık ilişkilerin bulunduğu durumlarda düşünülmelidir.

Kod:
-- Örnek bir normalizasyon adımı:
-- Müşteri ve Sipariş Bilgileri
CREATE TABLE Musteriler (
    MusteriID INT PRIMARY KEY,
    MusteriAdi VARCHAR(100),
    Adres VARCHAR(255),
    Telefon VARCHAR(20)
);

CREATE TABLE Siparisler (
    SiparisID INT PRIMARY KEY,
    MusteriID INT,
    SiparisTarihi DATE,
    ToplamTutar DECIMAL(10, 2),
    FOREIGN KEY (MusteriID) REFERENCES Musteriler(MusteriID)
);

-- Denormalizasyon örneği (performans için):
-- Sık kullanılan raporlar için müşteri adını sipariş tablosuna ekleyebiliriz
CREATE TABLE Siparisler_Denormalize (
    SiparisID INT PRIMARY KEY,
    MusteriID INT,
    MusteriAdi VARCHAR(100), -- Denormalize edilmiş veri
    SiparisTarihi DATE,
    ToplamTutar DECIMAL(10, 2)
);

Sonuç
Normalizasyon prensipleri, iyi tasarlanmış, esnek, tutarlı ve sürdürülebilir bir veritabanı yapısının temelini oluşturur. Veri yedekliliğini ve anormallikleri azaltarak, veritabanının uzun vadeli sağlığını ve güvenilirliğini sağlar. Her normal form, belirli bir tür veri bağımlılığını veya anormalliğini ele alarak veritabanını daha yüksek bir bütünlük seviyesine taşır. Uygulamaların çoğu için 3NF genellikle yeterli bir seviye olsa da, BCNF ve üzeri formlar daha spesifik ve karmaşık veri bütünlüğü senaryolarında değerlidir. Veritabanı tasarımında doğru normalizasyon seviyesini seçmek, sistem performansı ve veri bütünlüğü arasında hassas bir denge gerektirir. Bu denge, veritabanı tasarımcısının en kritik kararlarından biridir. Unutmayın ki, iyi bir veritabanı tasarımı sadece bugünkü ihtiyaçları değil, gelecekteki olası değişimleri de hesaba katmalıdır.

Daha fazla bilgi için şu kaynağı ziyaret edebilirsiniz: Veritabanı Normalizasyonu - Wikipedia
 
shape1
shape2
shape3
shape4
shape5
shape6
Üst

Bu web sitenin performansı Hazal Host tarafından sağlanmaktadır.

YazilimForum.com.tr internet sitesi, 5651 sayılı Kanun’un 2. maddesinin 1. fıkrasının (m) bendi ve aynı Kanun’un 5. maddesi kapsamında Yer Sağlayıcı konumundadır. Sitede yer alan içerikler ön onay olmaksızın tamamen kullanıcılar tarafından oluşturulmaktadır.

YazilimForum.com.tr, kullanıcılar tarafından paylaşılan içeriklerin doğruluğunu, güncelliğini veya hukuka uygunluğunu garanti etmez ve içeriklerin kontrolü veya araştırılması ile yükümlü değildir. Kullanıcılar, paylaştıkları içeriklerden tamamen kendileri sorumludur.

Hukuka aykırı içerikleri fark ettiğinizde lütfen bize bildirin: lydexcoding@gmail.com

Sitemiz, kullanıcıların paylaştığı içerik ve bilgileri 6698 sayılı KVKK kapsamında işlemektedir. Kullanıcılar, kişisel verileriyle ilgili haklarını KVKK Politikası sayfasından inceleyebilir.

Sitede yer alan reklamlar veya üçüncü taraf bağlantılar için YazilimForum.com.tr herhangi bir sorumluluk kabul etmez.

Sitemizi kullanarak Forum Kuralları’nı kabul etmiş sayılırsınız.

DMCA.com Protection Status Copyrighted.com Registered & Protected