Birinci normal form

Birinci normal form veya Birinci normal biçim (1NF), ilişkisel bir veritabanındaki bir ilişkinin özelliğidir. Bir ilişki, ancak ve ancak her bir öznitelik yalnızca atomik (bölünemez) değerler içeriyorsa ve her özniteliğin değeri, bu etki alanından yalnızca tek bir değer içeriyorsa birinci normal biçimdedir (1NF).[1] Terimin ilk tanımı, Edgar Codd'un 1971 tarihli bir konferans makalesinde yapılmıştır.[2]

Birinci normal form, ilişkisel bir veritabanındaki bir ilişkinin temel bir özelliğidir. Veritabanı normalizasyonu, bir veritabanını ilişkiler açısından standart normal formlarda temsil etme sürecidir, burada birinci normal form minimum gereksinimdir.

Birinci normal formda şu kriterler uygulanır:[3]

  • Bir tablo içinde tekrar eden grupları ortadan kaldırmak
  • Her bir ilgili veri kümesi için ayrı bir tablo oluşturmak
  • Her bir ilgili veri kümesini bir birincil anahtarla tanımlamak

Örnekler

değiştir

Aşağıdaki senaryolar ilk olarak bir veritabanı tasarımında birinci normal formun nasıl ihlal edildiğini ve ardından birinci normal forma uygun örnekleri gösterir.[4][5]

1NF'yi ihlal eden tasarımlar

değiştir

Aşağıda müşterilerin isimlerini ve telefon numaralarını saklayan bir tablo bulunmaktadır. Bazı müşteriler için birden fazla telefon numarasını saklamak gerekmektedir. Bu gereksinimi karşılamanın en basit yolu, herhangi bir satırdaki "Telefon Numarası" sütununun birden fazla değer içermesine izin vermektir:

Musteri
Musteri ID Ad Soyad Telefon
123 Pooja Singh 555-861-2025, 192-122-1111
456 San Zhang (555) 403-1659 Dahili. 53; 182-929-2929
789 John Doe 555-808-9633

Telefon numarası sütunu, tek bir değerde birden çok telefon numarası içerir. Örneğin, ilk satırda virgülle ayrılmış iki telefon numarası vardır. Sütun değerleri atomik değildir: iki sayıya bölünebilir. Bu durum, birinci normal formu ihlal etmektedir.

Akla gelen bir çözüm, daha fazla sütun sunmaktır:

Musteri
Musteri ID Ad Soyad Telefon1 Telefon2
123 Pooja Singh 555-861-2025 192-122-1111
456 San Zhang (555) 403-1659 Dahili. 53 182-929-2929
789 John Doe 555-808-9633

Teknik olarak bu tablo, değerlerin atomik olması gerekliliğini ihlal etmemektedir. Ancak, iki telefon numarası sütunu hala bir "tekrar eden grup" oluşturur: kavramsal olarak aynı özniteliği, yani bir telefon numarasını tekrarlar. Keyfi bir sıralama getirilmiş olur: 555-861-2025 bilgisinin neden Telefon2 sütunu yerine Telefon1 sütununa yerleştirildiğine ilişkin somut bir neden yoktur. Müşterilerin ikiden fazla telefon numarasına sahip olmaması için hiçbir neden olmadığına göre, bu durumda kaç tane TelefonN sütunu olacağı da belirsizdir. Böyle bir yapıda, rastgele sayıda sütunda arama yapmadan bir telefon numarasını aramak mümkün olmaz. Fazladan bir telefon numarası eklemek, tabloya sadece yeni bir satır eklenmesi yerine yeni bir sütun eklenerek yeniden düzenlenmesini gerektirebilir. (789 numaralı müşteri için Telefon2'nin boş (null) değeri de bir sorundur.)

1NF ile uyumlu tasarım

değiştir

Modeli birinci normal forma getirmek için, telefon numarası bilgilerini tutmak için kullanılan satırlar "atomik" (yani bölünemez) varlıklara bölünür: her varlık tek bir telefon numarası içerir. Ve hiçbir satırın birden fazla telefon numarası içermediğinden emin olunur.

Müşteri
MusteriID Ad Soyad Telefon
123 Pooja Singh 555-861-2025
123 Pooja Singh 192-122-1111
456 San Zhang 182-929-2929
456 San Zhang (555) 403-1659 Dahili. 53
789 John Doe 555-808-9633

Bu çözümde yinelenen müşteriler için "ID" nin artık tekil olmadığı unutulmamalıdır. Bçyle bir yapıda, bir satırı tekil (benzersiz) şekilde tanımlamak için (ID, Telefon) kombinasyonunu kullanmak gerekir. Her bir sütun ayrı ayrı tekrarlanan değerler içermesine rağmen, kombinasyonun değeri tekildir. Bir satırı tekil şekilde tanımlayabilmek, 1NF'nin bir gereksinimidir.

Alternatif bir tasarımda ise iki tablo kullanılır:

Musteri
MusteriID Ad Soyad
123 Pooja Singh
456 San Zhang
789 John Doe
Müşteri Telefon Numarası
TelefonID MüşteriID Telefon
1 123 555-861-2025
2 123 192-122-1111
3 456 (555) 403-1659 Dahili. 53
4 456 182-929-2929
5 789 555-808-9633

Bu tasarımda kolonlar birden fazla telefon numarası içermemektedir. Bunun yerine, her Müşteri-Telefon Numarası bağlantısı kendi satırında görünür. MüşteriID anahtar olarak kullanıldığında, müşteri ve müşteri telefonu tabloları arasında bire çok ilişkisi vardır. "Üst" tablodaki bir satır olan Müşteri Adı, "alt" tablodaki birçok telefon numarası satırıyla, Müşteri Telefon Numarasıyla ilişkilendirilebilir, ancak her telefon numarası yalnızca bir müşteriye aittir.[6] Bu tasarımın ikinci ve üçüncü normal form için ek gereksinimleri de karşıladığını belirtmekte fayda var.

Atomiklik

değiştir

Edgar F. Codd'un 1NF tanımı, 'atomiklik' kavramına gönderme yapar.[7] Codd, atomik bir değeri "daha küçük parçalara ayrıştırılamayan (belirli özel işlevler hariç)"[8] şeklinde tanımlar Bu, bir sütunun içinde birden fazla veri türü olan parçalara bölünmemesi gerektiği anlamına gelir.

Hugh Darwen ve Chris Date, Codd'un "atomik değer" kavramının belirsiz olduğunu ve bu belirsizliğin 1NF'nin nasıl anlaşılması gerektiği konusunda yaygın bir kafa karışıklığına yol açtığını öne sürdüler.[9][10] Özellikle, "ayrıştırılamayan bir değer" kavramı sorunludur, çünkü çok az veri türünün atomik olduğunu ima ediyor gibi görünmektedir:

  • Bir karakter dizisi tipik olarak alt karakter dizilerine bölünebildiğinden, atomik görünmeyebilir.
  • Ondalıklı bir sayı, tam sayı ve kesirli bileşen olarak bölünebildiğinden, atomik görünmeyebilir.
  • Dil ve yayıncı tanımlayıcısı içerdiğinden, ISBN bilgisi atomik görünmeyebilir.

Chris Date, "atomiklik kavramının mutlak bir anlamı olmadığını" öne sürer:[11][12] Bir değer bazı amaçlar için atomik olarak kabul edilebilirken, başka amaçlar için daha temel elementlerin bir araya gelmesi olarak düşünülebilir. Bu kabule göre, 1NF tanımında atomikliğe referans verilemez.

İlişkilerin temsili olarak 1NF tabloları

değiştir

Date'in tanımına göre, bir tablo, ancak ve ancak "bir ilişkiye izomorf" ise, yani özellikle aşağıdaki beş koşulu karşıladığında birinci normal formdadır:[13]

  1. Satırlar için yukarıdan aşağıya sıralama yoksa
  2. Sütunlarda soldan sağa sıralama yoksa
  3. Yinelenen satır yoksa
  4. Her satır ve sütun kesişimi, geçerli etki alanından tam olarak bir değer içerirse (ve başka hiçbir şey içermezse)
  5. Tüm sütunlar düzenliyse (ör. satırların satır IDleri, nesne IDleri veya gizli zaman damgaları gibi gizli bileşenleri yoksa).

Bu koşullardan herhangi birinin ihlali, tablonun ilişkisel olmadığı ve bu nedenle de birinci normal formda olmadığı anlamına gelir.

Bu birinci normal biçim tanımına uymayan tabloların (veya görünümlerin) örnekleri şunlardır:

  • Benzersiz bir anahtar kısıtlaması olmayan bir tablo. Böyle bir tablo, koşul 3'ü ihlal edecek şekilde yinelenen satırları barındırabilir.
  • Tanımı, sonuçların belirli bir sırayla döndürülmesini zorunlu kılan bir görünüm, böylece sıra sıralaması, görünümün içsel ve anlamlı bir yönüdür.[14] Bu durum ilk kuralı ihlal eder. Gerçek ilişkilerdeki demetler birbirine göre sıralanmamıştır.
  • En az bir "null" atanabilir özelliğe sahip bir tablo. Null yapılabilir bir öznitelik, her sütunun kendi sütun etki alanından tam olarak bir değer içermesini gerektiren 4 koşulunu ihlal eder. Durum 4'ün bu yönü tartışmalıdır. Bu, Codd'un daha sonraki ilişkisel model vizyonundan[15] önemli bir ayrılışı işaret eder, bu da "null" değerler için açık hükümler getirir.[16]

Chris Date tarafından tanımlanan birinci normal form, ilişki değerli özniteliklere (tablolar içindeki tablolar) izin verir. Date, bir tablodaki bir sütunun bir tablo içerebildiği, ilişki değerli özniteliklerin nadir durumlarda yararlı olduğunu savunur.[17]

Ayrıca bakınız

değiştir

Kaynakça

değiştir
  1. ^ Fundamentals of Database Systems, Fourth Edition. Pearson. Temmuz 2003. s. 315. ISBN 0321204484. It states that the domain of an attribute must include only atomic (simple, indivisible) values and that the value of any attribute in a tuple must be a single value from the domain of that attribute. 
  2. ^ E. F. Codd (Oct 1972), Further normalization of the database relational model, Courant Institute: Prentice-Hall, ISBN 013196741X, A relation is in first normal form if it has the property that none of its domains has elements which are themselves sets. 
  3. ^ Database Design - 2nd Edition. Victoria, B.C: BCcampus. 2014. 19 Ekim 2020 tarihinde kaynağından arşivlendi. Erişim tarihi: 21 Ağustos 2020. 
  4. ^ "studytonight.com". 11 Ağustos 2020 tarihinde kaynağından arşivlendi. Erişim tarihi: 21 Ağustos 2020. 
  5. ^ "stackoverflow.com". 26 Ekim 2013 tarihinde kaynağından arşivlendi. Erişim tarihi: 21 Ağustos 2020. 
  6. ^ In the "real" world, that would not be a good assumption.
  7. ^ Codd, E. F. The Relational Model for Database Management Version 2 (Addison-Wesley, 1990).
  8. ^ Codd, E. F. The Relational Model for Database Management Version 2 (Addison-Wesley, 1990), p. 6.
  9. ^ Darwen, Hugh. "Relation-Valued Attributes; or, Will the Real First Normal Form Please Stand Up?", in C. J. Date and Hugh Darwen, Relational Database Writings 1989-1991 (Addison-Wesley, 1992).
  10. ^ "[F]or many years," writes Date, "I was as confused as anyone else. What's worse, I did my best (worst?) to spread that confusion through my writings, seminars, and other presentations." Date, C. J. ["What First Normal Form Really Means"] in Date on Database: Writings 2000-2006 (Springer-Verlag, 2006), p. 108
  11. ^ Date, C. J. ["What First Normal Form Really Means"] p. 112.
  12. ^ SQL and Relational Theory: How to Write Accurate SQL Code. "O'Reilly Media, Inc.". 6 Kasım 2015. ss. 50-. ISBN 978-1-4919-4115-7. 25 Haziran 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 31 Ekim 2018. 
  13. ^ Date, C. J. ["What First Normal Form Really Means"] pp. 127–128.
  14. ^ Such views cannot be created using SQL that conforms to the SQL:2003 standard.
  15. ^ "Codd first defined the relational model in 1969 and didn't introduce nulls until 1979" Date, C. J. SQL and Relational Theory (O'Reilly, 2009), Appendix A.2.
  16. ^ The third of Codd's 12 rules states that "Null values ... [must be] supported in a fully relational DBMS for representing missing information and inapplicable information in a systematic way, independent of data type." Codd, E. F. "Is Your DBMS Really Relational?" Computerworld, October 14, 1985.
  17. ^ Date, C. J. ["What First Normal Form Really Means"] pp. 121–126.