Ana içeriğe atla

Üçüncü Normal Form (3NF) Nedir?

Üçüncü normal formun (3NF) yinelenmeyi ortadan kaldırarak ve bağımlılık sorunlarını en aza indirerek veritabanlarınızı daha verimli şekilde düzenlemenize nasıl yardımcı olacağını öğrenin. Tabloları ayrıştırmanın veri yönetimini nasıl basitleştirdiğini görün.
Güncel 22 Nis 2026  · 9 dk. oku

Tekrarlanan, gereksiz bilgilerle dolu, devasa ve yapısız bir veritabanıyla çalıştığınızı hayal edin. Her güncelleme veya silme işlemi potansiyel bir felakete dönüşür, hatalar ve tutarsızlıklar riski artar. Üçüncü normal form (3NF), bu kaostan kaçınmak için kanıtlanmış bir veritabanı normalleştirme yöntemidir. 3NF’yi uygulamak, veri yapınızı düzenleyerek verimli, derli toplu ve gereksiz yinelenmelerden arınmış hale getirir.

Bu yazıda 3NF’nin nasıl çalıştığını, neden değerli olduğunu ve uygulamada nasıl kullanılacağını inceleyeceğiz. Ayrıca 3NF’yi diğer formlarla karşılaştıracak ve her birini ne zaman kullanmanız gerektiğini öğreneceğiz. Bu yapılara dair bilgi herkes için faydalıdır; ancak özellikle bir veritabanı tasarımcısı veya veri bilimciyseniz, çalışmalarınızı önemli ölçüde sadeleştirip veritabanlarınızı güvenilir tutabileceği için daha da kıymetlidir. Veritabanı tasarımına bütünsel olarak ilgi duyuyorsanız, kapsamlı Database Design kursumuza göz atın.

Üçüncü Normal Form (3NF) Tanımı

Üçüncü normal form, istenmeyen bağımlılıkları ortadan kaldıran temel bir veritabanı normalleştirme kavramıdır. 3NF, birinci normal form (1NF) ve ikinci normal form (2NF) üzerine inşa edilir; yani onların kurallarını devralır: 1NF, her hücrede atomik (bölünemez) değerler gerektirir ve 2NF, bileşik bir birincil anahtara olan kısmi bağımlılıkları kaldırır. 3NF ise bir adım daha ileri giderek geçişli bağımlılıkları ortadan kaldırır; bu, anahtar olmayan özniteliklerin birincil anahtara dolaylı olarak bağımlı olduğu durumlardır.

Buna odaklanarak 3NF, bir tablodaki her anahtar olmayan sütunun doğrudan birincil anahtarla ve başka hiçbir şeyle ilişkili olmasını sağlar. Daha pratik bir ifadeyle 3NF, veriyi ekleme, güncelleme veya silme sırasında yinelenmeyi en aza indirmenize ve anormalliklerden kaçınmanıza yardımcı olur.

1970’lerde Edgar F. Codd, tamamen normalleştirilmiş bir veritabanı yapısına ulaşmanın koşullarını resmileştirmek için 3NF’yi tanıttı. Birkaç yıl sonra Carlo Zaniolo’nun yeniden formülasyonu, “klasik” 3NF ile daha kısıtlayıcı olan Boyce-Codd normal formu (BCNF) arasındaki farkın daha net bir açıklamasını sağladı. Şimdilik BCNF konusunda çok endişelenmeyin; aşağıda buna geri döneceğiz.

Üçüncü Normal Form Koşullarını Anlamak

Peki 3NF’ye ulaşmak için tam olarak ne gerekir? Bir tablonun uygun sayılması için şu koşulları karşılaması gerekir:

  • 2NF’de olmak: Yani tablo zaten atomiktir, tekrar eden gruplar yoktur ve herhangi bir bileşik anahtara kısmi bağımlılık bulunmaz.

1NF, 2NF ve 3NF gereksinimleri

3NF, 2NF ve 1NF’yi kapsar. Görsel: Yazar

  • Geçişli bağımlılıkların olmaması: Bu kural kritiktir. 3NF’deki bir tabloda, birincil anahtar olmayan herhangi bir sütun yalnızca birincil anahtara bağlı olmalı, başka bir anahtar olmayan sütun aracılığıyla dolaylı olarak değil.

Bunun pratikte ne anlama geldiğine bakalım.

3NF’ye Ulaşmak İçin Tabloların Ayrıştırılması

3NF’ye ulaşmak için tabloları nasıl ayrıştıracağımızı adım adım inceleyelim. Her adımı göstermek için DataCamp kurslarından bazı örnek verileri kullanacağız.

Adım 1: Geçişli bağımlılıkları belirleyin

Öncelikle, bir tabloda birincil anahtara dolaylı olarak bağlı olan öznitelikleri arayacağız. Genel bir kural olarak, herhangi bir öznitelik birincil anahtar dışında bir şeye bağlıysa bu bir geçişli bağımlılığa işaret eder. Bu da tablonuzu bölmenin zamanı gelmiş olabilir demektir.

Aşağıdaki üç tabloya bakın. Hangisinde geçişli bağımlılık var?

Tablo 1: Course

Course ID Course Name Difficulty
201 SQL Fundamentals Beginner
202 Introduction to Python Beginner
203 Understanding Data Science Intermediate

Tablo 2: Instructor

Instructor ID Instructor Name Expertise
1 Sarah Johnson Data Science
2 Tom Williams Machine Learning
3 Emily Brown Python

Tablo 3: Enrollments

Enrollment ID Student Name Course ID Course Name
1001 Alice Smith 201 SQL Fundamentals
1002 Bob Green 202 Introduction to Python
1003 Charlie Blue 201 SQL Fundamentals

Cevap… Tablo 3!

Bu tabloda, Course Name, Course ID’ye bağlıdır, ancak doğrudan Enrollment ID’ye (birincil anahtar) bağlı değildir. Bu dolaylı bağımlılık, Course Name’i geçişli bir bağımlılık haline getirir.

Adım 2: Veriyi yeni tablolara ayırın

Geçişli bağımlılığı gidermek için Tablo 1’i iki tabloya böleceğiz. Her tablo doğrudan bağımlı verilere odaklanacak.

Gözden geçirilmiş enrollments tablosu

Enrollment ID Student Name Course ID
1001 Alice Smith 201
1002 Bob Green 202
1003 Charlie Blue 201

Courses tablosu

Course ID Course Name
201 SQL Fundamentals
202 Introduction to Python

Artık her tablo yalnızca kendi birincil anahtarına doğrudan bağlı bilgileri içeriyor: Course ID artık Course Name için Courses tablosunda birincil anahtardır ve Enrollment ID ise Enrollments tablosunda birincil anahtardır.

Bu ayrıştırma ile tablolar artık 3NF gereksinimlerini karşılıyor; yinelenmeler ortadan kalkıyor ve her tablo yalnızca doğrudan ilgili bilgileri saklıyor.

Kendi veritabanlarınızı oluşturmak ve uygulamalı çalışmak isterseniz Creating PostgreSQL Databases kursumuza bakın. Biraz daha ileri düzeyseniz, varlık-ilişki ve boyutsal modelleme gibi kavramları ele alan Introduction to Data Modeling in Snowflake kursunu deneyebilirsiniz.

Üçüncü Normal Formu Kullanmanın Faydaları ve Sınırlamaları

Peki 3NF’ye ulaşmak için tüm bu çabaya neden değer? Başlıca avantajlar şunlardır:

  • Gelişmiş Veri Bütünlüğü: Geçişli bağımlılıkları ortadan kaldırarak 3NF, güncellemelerin ve silmelerin tablolar arasında çelişkili veya güncel olmayan verilere yol açmamasını sağlamaya yardımcı olur.
  • Azaltılmış Yinelenme: Daha az yinelenme, veritabanınızın bakımını kolaylaştırır ve depolama kullanımını azaltır.
  • Daha Basit Veri Bakımı: Benzer bilgilerin özel tablolarda tutulması, yinelenen kayıtları aramadan güncellemeyi kolaylaştırır.

Öte yandan, 3NF yapıları veri doğruluğunu desteklerken, veriyi daha çok bölümlere ayırabilir; bu da ek tablo birleştirmeleri nedeniyle karmaşık sorguları bazen yavaşlatabilir. Hız ihtiyacının normalleştirme ihtiyacının önüne geçtiği durumlarda BCNF veya 4NF daha pratik olabilir.

Karşılaştırma: Birinci, İkinci, Üçüncü ve BC Normal Formlar

Formlar arasındaki farklara bakalım.

Karşılaştırma tablosu: birinci, ikinci ve üçüncü normal formlar

1NF, 2NF ve 3NF gereksinimlerini anlamanıza yardımcı olacak bir karşılaştırma tablosu aşağıdadır.

Feature 1NF 2NF 3NF
Atomic data
No partial dependencies
No transitive dependencies

Third normal form vs. Boyce-Codd normal form (BCNF)

BCNF, örtüşen aday anahtarların neden olduğu anormallikleri daha da ortadan kaldıran, 3NF’nin “daha sıkı” bir biçimidir. 3NF’nin tek başına bağımlılıkları tamamen gidermediği karmaşık durumlarda özellikle faydalı olabilir. BCNF, asal olmayan bir özniteliğin, bileşik bir aday anahtarın parçası olan bir özniteliğe bağımlı olduğu durumlarda geçerlidir. Kulağa karmaşık geldiğinin farkındayım; bunu bir örnekle sadeleştirelim.

Mevcut yapı (3NF’de)

3NF’ye ulaşmak için ayrıştırmadan sonra elimizde şu iki tablo vardı:

Enrollments tablosu

Enrollment ID Student Name Course ID
1001 Alice Smith 201
1002 Bob Green 202
1003 Charlie Blue 201

Courses tablosu

Course ID Course Name
201 SQL Fundamentals
202 Introduction to Python

Bu yapıda her tablo 3NF’dedir; geçişli bağımlılık yoktur ve veriler uygun biçimde normalleştirilmiştir.

Yeni bir gereksinim eklemek

Şimdi Courses tablosuna yeni bir öznitelik ekleyelim: her dersin yapıldığı Classroom. Bu yeni öznitelik, BCNF’yi gerektirebilecek bir senaryo doğurabilir.

Güncellenmiş courses tablosu (3NF)

Course ID Course Name Classroom
201 SQL Fundamentals Room 101
202 Introduction to Python Room 102
203 Understanding Data Science Room 101

Burada Course ID hâlâ birincil anahtar ve diğer tüm öznitelikler doğrudan ona bağlı. Ancak her sınıfın aynı anda yalnızca bir konuya ev sahipliği yapabileceğine dair yeni bir kural olduğunu varsayalım. Ayrıca, farklı zamanlarda planlanmaları halinde "SQL Fundamentals" adlı Course Name’in (201, 204 vb. gibi) farklı Course ID’ler altında sunulabildiğini düşünelim. Bu durumda, "SQL Fundamentals" dersi her seferinde, belirli Course ID’den bağımsız olarak "Room 101"'de yapılacaktır. Sonuç olarak Course Name da Classroom’u tekil olarak belirler.

Bu, artık iki aday anahtarımız olduğu anlamına gelir:

  1. Course ID
  2. Course Name

Her iki aday anahtarla birlikte, 3NF’nin ele almadığı bir sorun ortaya çıkıyor: Classroom yalnızca Course ID’ye değil, Course Name’e de bağlıdır.

BCNF uygulamak

Bu bağımlılık sorununu gidermek için Courses tablosunu BCNF’ye daha iyi uyum sağlayacak iki ayrı tabloya daha da ayrıştırmamız gerekir:

  1. Yalnızca Course ID ve Course Name içeren yeni bir Courses tablosu.
  2. Course Name ile Classroom ilişkilendirmesini saklayan bir CourseDetails tablosu.

Bu şöyle görünür:

Gözden geçirilmiş courses tablosu (BCNF)

CourseDetails tablosu (BCNF)

Course Name Classroom
SQL Fundamentals Room 101
Introduction to Python Room 102
Understanding Data Science Room 101

Bu yeni yapıda her tablo BCNF koşullarını karşılar:

  • Courses tablosunda Course ID birincil anahtardır ve tüm öznitelikler yalnızca ona bağlıdır.
  • CourseDetails tablosunda Course Name birincil anahtardır ve Classroom yalnızca Course Name’e bağlıdır.

Bu düzenleme, örtüşen aday anahtarların neden olduğu bağımlılık sorunlarını ortadan kaldırarak sıkı şekilde normalleştirilmiş bir yapı sağlar.

Sonuç

Üçüncü normal form, verilerini temiz, tutarlı ve sorunlu bağımlılıklardan arınmış tutmak isteyen veritabanı tasarımcıları için değerli bir araçtır. 3NF ile veri bütünlüğü artar, yönetim kolaylaşır ve yinelenme azalır. Unutmayın, 3NF çoğu durumda iyi çalışsa da, daha karmaşık veritabanları BCNF veya 4NF gibi ek formlardan fayda görebilir.

Bu makaleyi faydalı bulduysanız, bir sonraki adımı atarak SQL Associate Certification sertifikamızı almayı düşünebilirsiniz. SQL ve veritabanı yönetimi becerilerinizi doğrulamanın ve uzmanlığınızı potansiyel işverenlere göstermenin harika bir yoludur!


Marie Fayard's photo
Author
Marie Fayard

İlk prototipten ürün-pazar uyumuna ve ötesine kadar erken aşama girişimleri büyütme konusunda uzmanlaşmış, ürün odaklı bir teknik liderim. İnsanların teknolojiyi nasıl kullandığına dair bitmeyen bir merakım var ve kurucularla ile disiplinler arası ekiplerle yakın çalışarak cesur fikirleri hayata geçirmeyi seviyorum. Ürün inşa etmediğim zamanlarda ya dünyanın yeni köşelerinde ilham peşinde koşuyor ya da yoga stüdyosunda stres atıyorum.

Üçüncü Normal Form Hakkında Sık Sorulan Sorular

3NF tüm veritabanı türlerine uygulanabilir mi?

3NF ilişkisel veritabanlarında etkili olsa da, esneklik ve ölçeklenebilirliği sıkı normalleştirmenin önüne koyan NoSQL veritabanlarında her zaman gerekli olmayabilir. Bazı durumlarda, özellikle büyük miktarda veriyi hızlıca sorgulamak gerektiğinde, performans nedenleriyle normalleştirilmemiş bir şema tercih edilebilir.

3NF’ye sıkı sıkıya uymanın dezavantajları nelerdir?

3NF’ye sıkı sıkıya bağlı kalmak bazen çok sayıda tablo içeren karmaşık şemalara yol açabilir ve sorgularda birden fazla birleştirme gerektirebilir. Bu, özellikle büyük veritabanlarında veya yüksek işlem hacmine sahip sistemlerde performansı olumsuz etkileyebilir. Bu gibi durumlarda, normalleştirmeme veya BCNF kullanma gibi alternatif yaklaşımlar daha pratik olabilir.

3NF mevcut veritabanlarına uygulanabilir mi, yoksa yeniden tasarlamak mı gerekir?

3NF mevcut veritabanlarına da kesinlikle uygulanabilir; ancak önemli ölçüde yeniden yapılandırma gerektirebilir. Veritabanı yeniden düzenleme (refactoring) olarak adlandırılan bu süreç, yinelenmeleri ve bağımlılıkları ortadan kaldırmak için tabloların ayrıştırılmasını içerir. Veritabanının boyutu ve karmaşıklığına bağlı olarak, veri bütünlüğünü ve sistem performansını korumak için planlama ve test yapılması gerekebilir.

3NF’ye ulaşma sürecini otomatikleştirmeye yardımcı olabilecek araç veya teknikler nelerdir?

MySQL Workbench, Oracle SQL Developer ve ER/Studio gibi çeşitli veritabanı tasarım araçları, veritabanı şemasını görselleştirmenize ve normalleştirme sorunlarını belirlemenize yardımcı olur. Bu araçların bazıları 3NF’ye ulaşmak için adımları önerebilir veya otomatikleştirebilir; ancak veri bütünlüğünü ve tutarlılığı sağlamak için insan denetimi hâlâ önemlidir.

Aday anahtar ile birincil anahtar arasındaki fark nedir?

Bir aday anahtar, bir tablodaki her satırı tekil olarak tanımlayabilen en küçük öznitelik kümesidir. Bir tabloda birden fazla aday anahtar olabilir. Birincil anahtar ise satırları tekil olarak tanımlamak için veritabanı tasarımcısı tarafından seçilen belirli aday anahtardır. Tabloda yalnızca bir birincil anahtar bulunabilir ve NULL değer alamaz.

Bir tablo zaten üçüncü normal formda (3NF) ise neden Boyce-Codd normal formuna (BCNF) ihtiyaç duyarız?

BCNF, 3NF’den daha sıkıdır ve bağımlılıkların aday anahtarlarda bulunduğu durumları ele alır. 3NF geçişli bağımlılıkları ortadan kaldırırken, belirleyenin bir süper anahtar olmadığı fonksiyonel bağımlılıklar varsa yine de yinelenmeye izin verebilir. BCNF, tüm fonksiyonel bağımlılıkların sol tarafında bir süper anahtar olmasını şart koşarak bunu ortadan kaldırır.

Bir tabloda birden fazla aday anahtar olabilir mi?

Evet, bir tabloda birden fazla aday anahtar olabilir. Her aday anahtar, satırları tanımlayabilen tekil ve minimal bir öznitelik kümesidir.

Konular

DataCamp ile Öğrenin

Program

Geliştiriciler için Yardımcı Yapay Zeka Mühendisi

26 sa
API'leri ve açık kaynak kütüphanelerini kullanarak yapay zekayı yazılım uygulamalarına nasıl entegre edeceğinizi öğrenin. Yapay Zeka Mühendisi olma yolculuğunuza bugün başlayın!
Ayrıntıları GörRight Arrow
Kursa Başla
Devamını GörRight Arrow