ÜÇÜNCÜ NORMAL BIÇIM NEDIR? (VERITABANLARI) - TEKNOLOJI - 2025

Üçüncü normal form (veritabanları) değil sadece ikinci normal forma uygun oluşturan farklı tablolar, ancak tüm nitelikleri veya alanları birincil anahtar doğrudan bağlı bir ilişkisel veritabanı tasarımı tekniğidir.

Bir veritabanı tasarlarken ana amaç, verilerin, aralarındaki ilişkilerin ve ilgili veriler üzerindeki kısıtlamaların doğru bir temsilini oluşturmaktır.

Kaynak: Pixabay.com

Bu amaca ulaşmak için, aralarında normalleştirme de bulunan bazı veritabanı tasarım teknikleri kullanılabilir.

Bu, kavramsal modelin basit ve kararlı bir tasarımını oluşturarak verilerin eklenmesi, güncellenmesi veya ortadan kaldırılmasındaki fazlalıkları ve olası anormallikleri önlemek için verileri bir veritabanında düzenleme işlemidir.

Nitelikler arasındaki işlevsel ilişkiyi veya bağımlılığı inceleyerek başlar. Bunlar, verilerin bazı özelliklerini veya aralarındaki ilişkiyi açıklar.

Normal şekiller

Normalleştirme, bu özniteliklerin en iyi şekilde gruplandırılmasına yardımcı olmak ve nihayetinde bir şirketin veri gereksinimlerini destekleyen uygun ilişki kümesini oluşturmak için normal formlar adı verilen bir dizi test kullanır.

Yani normalleştirme tekniği, bir kısıtlama sistemini tanımlayan normal form kavramı etrafında inşa edilmiştir. Bir ilişki belirli bir normal formun kısıtlamalarını karşılıyorsa, ilişkinin bu normal formda olduğu söylenir.

İlk normal form (1FN)

Bir tablonun içindeki tüm öznitelikler veya alanlar yalnızca benzersiz değerler içeriyorsa 1FN'de olduğu söylenir. Yani, her öznitelik için her değer bölünemez olmalıdır.

Tanım olarak, bir ilişkisel veritabanı her zaman ilk normal forma normalleştirilecektir, çünkü öznitelik değerleri her zaman atomiktir. Bir veritabanındaki tüm ilişkiler 1FN içindedir.

Ancak, veri tabanını bu şekilde bırakmak, fazlalık ve olası yükseltme hataları gibi bir dizi sorunu tetikler. Bu sorunları düzeltmek için daha yüksek normal formlar geliştirilmiştir.

İkinci normal form (2FN)

Bir tablodan döngüsel bağımlılıkları kaldırmakla ilgilenir. Bir ilişkinin 1FN'de olması ve ayrıca her bir anahtar olmayan alan veya öznitelik tamamen birincil anahtara bağlı olması veya daha spesifik olarak tablonun tek bir amaca sahip olmasını sağlaması durumunda 2FN'de olduğu söylenir.

Anahtar olmayan bir öznitelik, bir ilişkinin birincil anahtarının parçası olmayan herhangi bir özniteliktir.

Üçüncü normal form (3FN)

Bir tablodan geçişli bağımlılıkları ortadan kaldırmakla ilgilenir. Diğer bir deyişle, birincil anahtara değil, başka bir özelliğe bağlı olan anahtar olmayan öznitelikleri kaldırın.

Geçişli bağımlılık, anahtar olmayan bir alanın veya özniteliğin değerinin, anahtar olmayan başka bir alanın değeriyle belirlendiği bir tür işlevsel bağımlılıktır.

Bu anahtar olmayan özniteliklerin birincil anahtardan başka hiçbir şeye bağlı olmadığından emin olmak için anahtar olmayan özniteliklerde yinelenen değerleri aramalısınız.

Hiçbiri işlevsel olarak diğerlerinin kombinasyonuna bağlı değilse, niteliklerin karşılıklı olarak bağımsız olduğu söylenir. Bu karşılıklı bağımsızlık, başka bir özniteliği etkileme tehlikesi olmadan özniteliklerin ayrı ayrı güncellenmesini sağlar.

Bu nedenle, bir veritabanındaki bir ilişkinin üçüncü normal biçimde olması için aşağıdakilere uyması gerekir:

- 2FN'nin tüm gereksinimleri.

- Birincil anahtarla ilgili olmayan öznitelikler varsa, bunlar kaldırılmalı ve her iki tabloyu bir yabancı anahtar aracılığıyla ilişkilendiren ayrı bir tabloya yerleştirilmelidir. Yani geçişli bağımlılıklar olmamalıdır.

Üçüncü normal form örnekleri

örnek 1

Birincil anahtarı öğrencinin kimliği (STUDENT_ID) olan ve aşağıdaki özelliklerden oluşan tablo ÖĞRENCİ olsun: STUDENT_NAME, STREET, CITY ve POST_CODE, 2FN olma koşullarını yerine getiriyor.

Bu durumda, STREET ve CITY'nin STUDENT_ID birincil anahtarıyla doğrudan bir ilişkisi yoktur, çünkü bunlar doğrudan öğrenciyle ilişkili değildir, ancak tamamen posta koduna bağlıdır.

Öğrenci, CODE_POSTAL tarafından belirlenen sitede bulunduğundan, STREET ve CITY bu öznitelikle ilişkilidir. Bu ikinci derece bağımlılık nedeniyle, bu nitelikleri ÖĞRENCİ tablosunda saklamak gerekli değildir.

Yeni tablo oluştur

ÖĞRENCİ tablosunun muazzam miktarda kayda sahip olduğu aynı posta kodunda birden fazla öğrenci olduğunu ve cadde veya şehrin adını değiştirmek gerektiğini ve bu cadde veya şehrin tüm tabloda aranması ve güncellenmesi gerektiğini varsayalım. ÖĞRENCİ.

Örneğin, “El Limón” sokağını “El Limón II” olarak değiştirmeniz gerekirse, ÖĞRENCİ tablosunun tamamında “El Limón” u aramanız ve ardından bunu “El Limón II” olarak güncellemeniz gerekecektir.

Büyük bir tabloda arama yapmak ve tekli veya çoklu kayıtları güncellemek uzun zaman alacaktır ve bu nedenle veritabanının performansını etkileyecektir.

Bunun yerine, bu ayrıntılar, POST_CODE özniteliği kullanılarak ÖĞRENCİ tablosu ile ilişkili ayrı bir tabloda (POSTCARD) tutulabilir.

POST tablosunda nispeten daha az kayıt olacak ve bu POST tablosunun yalnızca bir kez güncellenmesi gerekecek. Bu, veri tabanını ve sorguları basitleştirerek ÖĞRENCİ tablosuna otomatik olarak yansıtılacaktır. Yani tablolar 3FN'de olacak:

Örnek 2

Aşağıdaki tablonun Project_Num alanı birincil anahtar olarak ve anahtar olmayan özniteliklerde yinelenen değerlerle kullanılmasına izin verin.

Telefon değeri, bir yöneticinin adı her tekrarlandığında tekrarlanır. Bunun nedeni, telefon numarasının proje numarasına yalnızca ikinci derece bağımlılığı olmasıdır. Bu gerçekten önce yöneticiye bağlıdır ve bu da, geçişli bir bağımlılık oluşturan proje numarasına bağlıdır.

Aynı yönetici birden fazla projeyi yönettiği için Project_Manager özniteliği Projeler tablosunda olası bir anahtar olamaz. Bunun çözümü, özniteliği tekrarlanan verilerle (Telefon) kaldırarak ayrı bir tablo oluşturmaktır.

İlgili öznitelikler birlikte gruplanmalı ve onları kaydetmek için yeni bir tablo oluşturulmalıdır. Veriler girilir ve tekrarlanan değerlerin birincil anahtarın parçası olmadığı doğrulanır. Her tablo için birincil anahtar ayarlanır ve gerekirse yabancı anahtarlar eklenir.

Üçüncü normal forma uymak için, sorunu çözmek için yeni bir tablo (Yöneticiler) oluşturulur. Her iki tablo da Project_Manager alanıyla ilişkilidir:

Referanslar

1. Teradata (2019). Birinci, İkinci ve Üçüncü Normal Formlar. Alınan: docs.teradata.com.
2. Eğitim Kupası (2019). Üçüncü Normal Form (3NF). Alınan: tutorialcup.com.
3. Veritabanı Geliştirme (2015). Üçüncü Normal Form (3NF) - Veritabanınızı Normalleştirme. Alınan: databasedev.co.uk.
4. İlişkisel DB Tasarımı (2019). Üçüncü Normal Biçime Giriş. Alındığı: relationaldbdesign.com.
5. Aptallar (2019). SQL Birinci, İkinci ve Üçüncü Normal Formlar. Alınan: dummies.com.