0NF (un-normalized - flat table) - Ogrenci_Ders
Ogrenci_No | Ogrenci | Aldigi_Ders_ve_Egitmenler |
|---|---|---|
| 101 | Salih Girgin | VIBECODE101 (Wojak Developer), MOBDEV101 (Fatih Kadir Akın ) |
| 102 | Arif Çıkkın | TWITTER101 (Prompt Mühendisi) |
| 103 | Onur Özcan | CHATGPT101 (Sam Altman), VIBECODE101 (Wojak Developer) |
Tablodaki Sorunlar
- Atomik Değil:
Aldigi_Ders_ve_Egitmenlersütunu birden fazla değer içermekte. - Veri Tekrarı (Redundancy):
VIBECODE101 (Wojak Developer)verisi hemSalih Girginiçin hem deOnur Özcaniçin tekrar ediyor. - Anomaliler
- Güncelleme Anomalisi:
VIBECODE101dersinin eğitmeni “onandagpt babandapt” olursa Salih’in ve Onur’un satırları ayrı ayrı bulunup düzeltilmesi gerekir. Sadece birisi düzeltilirse sistemde aynı dersin iki farklı hocası varmış gibi gözükür ki, bu veri tutarsızlığıdır. - Silme Anomalisi:
Arif Çıkkınokulu bırakırsa ve bu satırı silersekTWITTER101diye bir dersin var olduğu ve eğitmeninPrompt Mühendisiolduğu bilgisi de sistemden tamamen silinir ki, bu istenmeyen bir veri kaybıdır. - Ekleme Anomalisi: Yeni bir ders açıldı diyelim, adı ‘
AIETHICS202’. Ancak bu dersi alan hiçbir öğrenci yok henüz. Bu tabloya bu durumda bu dersi ekleyemeyiz, çünküOgrenci_Nokısmı boş kalamaz (boş kalamayacağını varsayıyoruz). Yani bir dersi sisteme eklemek için illa bir öğrencinin o dersi almasını beklemek zorundayız.
- Güncelleme Anomalisi:
1NF
- Birleşik verileri ayıracağız ve atomikliği sağlayacağız.
- Teknik Nüans: Esasında
Ogrencisütununu “Salih Girgin” olarak birleşik bırakmak 1NF’yi ihlal etmeyebilir. Atomiklik verinin kullanım amacına bağlıdır. Biz burada sorgulama esnekliği sağlamak ve genel kabul görmüş en iyi tasarım pratiğini uygulamak amacıyla ad ve soyadı ayrı sütunlara bölmeyi tercih ediyoruz.
Ogrenci_No | Ad | Soyad | Ders_Kod | Egt_Ad | Egt_Soyad |
|---|---|---|---|---|---|
| 101 | Salih | Girgin | VIBECODE101 | Wojak | Developer |
| 101 | Salih | Girgin | MOBDEV101 | Fatih Kadir | Akın |
| 102 | Arif | Çıkkın | TWITTER101 | Prompt | Mühendisi |
| 103 | Onur | Özcan | CHATGPT101 | Sam | Altman |
| 103 | Onur | Özcan | VIBECODE101 | Wojak | Developer |
Tablodaki Sorunlar
- Bileşik Birincil Anahtar (Composite PK): Bu tabloda bir satırı benzersiz yapan tek bir sütun yoktur. Bir kaydı benzersiz yapan şey (
Ogrenci_No,Ders_Kod) ikilisidir. Buna bileşik anahtar (composite key) denir.
- Veri Tekrarı Sorunu: En büyük sorun budur.
Salih GirginbilgisiSalih’in aldığı her ders için tekrar tekrar yazılmaktadır. Bu durum aşağıdaki güncelleme anomalisine yol açar. - Anomaliler
- Güncelleme Anomalisi:
Girgin’iGirişkenile değiştirmek istersem, 101 numaralı öğrencinin geçtiği tüm satırları bulup tek tek güncellemem gerekir. Birini atlarsam aynı öğrencinin iki farklı soyadı olur ve veri tutarsızlaşır. - Ekleme Anomalisi: Hiç ders almayan yeni bir öğrenciyi bu tabloya ekleyemeyiz.
- Silme Anomalisi Arif Çıkkın’ın kaydını silersek, TWITTER101 dersi de sistemden silinir.
- Güncelleme Anomalisi:
2NF
-
Amaç: 1NF tablosundaki veri tekrarını ve buna bağlı anomalileri çözmek.
-
Kural: Eğer bir tablo bileşik birincil anahtara sahipse, anahtar olmayan her sütun bu bileşik anahtarın tamamına bağlı olmalıdır. Sadece bir parçasına bağlıysa (kısmî bağımlılık) bu durum veri tekrarına yol açar ve 2NF ihlalidir.
-
Bizim 1NF tablomuzda
AdveSoyadsütunları bileşik anahtarın (Ogrenci_No,Ders_Kod) tamamına bağlı değildir. Bir öğrencinin adı, hangi dersi aldığına bağlı olarak değişmez.AdveSoyadanahtarın sadeceOgrenci_Nokısmına bağlıdır.** İşte bu duruma kısmî bağımlılık denir. -
Kısmî olarak bağımlı olan sütunları (
Ad,Soyad), tamamen bağlı oldukları anahtar parçası (Ogrenci_No) ile birlikte alıp kendi mantıksal tablolarına, yaniOgrencilertablosuna taşıyacağız. Bu sayedeSalih Girginbilgisi sadece bir kez yazılacak.
Ogrenciler Tablosu
🔑 Ogrenci_No (PK) | Ad | Soyad |
|---|---|---|
| 101 | Salih | Girgin |
| 102 | Arif | Çıkkın |
| 103 | Onur | Özcan |
Ders_Kayitlari Tablosu
🔑 Ogrenci_No (PK, FK) | 🔑 Ders_Kod (PK) | Egt_Ad | Egt_Soyad |
|---|---|---|---|
| 101 | VIBECODE101 | Wojak | Developer |
| 101 | MOBDEV101 | Fatih Kadir | Akın |
| 102 | TWITTER101 | Prompt | Mühendisi |
| 103 | CHATGPT101 | Sam | Altman |
| 103 | VIBECODE101 | Wojak | Developer |
2NF Sonrası Durum ve Kalan Sorunlar
- Çözülen Sorun: Öğrenci bilgilerinin tekrar etmesi sorunu (kısmî bağımlılık) çözüldü.
- Kalan Sorun (Geçişli Bağımlılık):
Ders_Kayitlaritablosunda hâlâ bir veri tekrarı var:Wojak Developerbilgisi iki kez yazıyor. Bunun sebebiEgt_AdveEgt_Soyad’ın anahtar olmayan bir sütun olanDers_Kod’a bağlı olmasıdır. Zincirleme bir ilişki vardır:- PK (
Ogrenci_No,Ders_Kod) →Ders_Kod→ (Egt_Ad,Egt_Soyad) - İşte bu “yanlış yerde duran bilgi” ve buna bağlı veri tekrarı sorununa teknik olarak geçişli fonksiyonel bağımlılık denir.
- PK (
- Anomaliler
- Güncelleme Anomalisi:
Wojak Developer’ın soyadı değişirse, bu bilginin tekrar ettiği tüm satırları ( ve nolu öğrencilerin kayıtları) tek tek bulup güncellemek gerekir. - Silme Anomalisi: Eğer
Arif ÇıkkınTWITTER101dersini alan tek öğrenciyse ve bu kaydı silersek,TWITTER101dersinin varlığına ve eğitmenine dair tüm bilgileri de sistemden kaybederiz. - Ekleme Anomalisi: Henüz hiçbir öğrencinin almadığı yeni bir dersi (ve eğitmenini) sisteme eklemek istesek,
Ogrenci_Noalanı boş kalacağı için bu tabloya ekleyemeyiz.
- Güncelleme Anomalisi:
3NF
- Amaç: 2NF’de kalan geçişli bağımlılığı ve buna bağlı veri tekrarı ile anomalileri ortadan kaldırmak.
- Çözüm: Her tablonun tek bir işi olması ilkesini uygulayacağız. “Dersi kim veriyor?” bilgisini, ait olduğu yere, yani Dersler aedında yeni bir tabloya taşıyacağız. Ders_Kayitlari tablosu ise sadece asıl işi olan öğrenci-ders eşleşmesini yapan bir ilişki tablosuna dönüşecek.
Ogrenciler Tablosu
🔑 Ogrenci_No (PK) | Ad | Soyad |
|---|---|---|
| 101 | Salih | Girgin |
| 102 | Arif | Çıkkın |
| 103 | Onur | Özcan |
Dersler Tablosu
🔑 Ders_Kod (*PK *) | Egt_Ad | Egt_Soyad |
|---|---|---|
| VIBECODE101 | Wojak | Developer |
| MOBDEV101 | Fatih Kadir | Akın |
| TWITTER101 | Prompt | Mühendisi |
| CHATGPT101 | Sam | Altman |
Kayıtlar Tablosu
🔑 Kayit_ID (PK) | Ogrenci_No (FK) | Ders_Kod (FK) |
|---|---|---|
| 1 | 101 | VIBECODE101 |
| 2 | 101 | MOBDEV101 |
| 3 | 102 | TWITTER101 |
| 4 | 103 | CHATGPT101 |
| 5 | 103 | VIBECODE101 |
Sonuç
- Pratikte karşılaşılan en yaygın anomaliler ve veri tekrarı sorunları çözülmüştür.
- Bu yapı çoğu uygulama için yeterince sağlam ve tutarlıdır.
- Ancak BCNF, 4NF gibi daha ileri normalizasyon seviyeleri hâlâ vardır. Bu yüzden tüm anomalilerin çözüldüğünü söylemek teknik olarak yanlış olur.