İlk Normal Form'un kesin bir sürümünü almaya çalışıyorum. Okuduğum her şeyin biraz farklı bir dönüşü var.

Date gibi birçok otorite, tanım gereği, bir ilişkinin her zaman İlk Normal Formda olduğunu söylerken, diğerleri gereksinimlerin bir listesini verir. Bu, 1NF için sıfır ila birçok gereksinim olduğu anlamına gelir.

Bir fark belirli kısıtlamalar takip ederken, tablolar ve ilişkiler arasındaki fark: tablolar tam bir karışıklık olabilir varsayalım. Bir ilişkinin SQL'de bir tablo olarak temsil edilmesi bazı karışıklıklar yaratır.

SQL veritabanları ile ilgili olarak özellikle 1NF üzerinde duruyorum. Soru şudur: Bir tablonun ilk normal formda olmasını sağlamak için hangi özellikler gereklidir?

Birçok makam, bir tablo bir ilişkiyi temsil ediyorsa , o zaman zaten 1NF'de olduğunu ileri sürmektedir . Bu, 1NF tanımını bir ilişkinin tanımına geri iter.

İşte 1NF'de bir tablonun bazı özellikleri:

• Sütun Düzeni önemsizdir [1]
• Satır Sırası önemsiz
• Tüm satırlar aynı uzunluktadır (yani, satır verileri sütun başlıklarıyla eşleşir)
• Yinelenen satır yoktur (yedek birincil anahtar kullanılarak garanti edilebilir, ancak PK'nin kendisi gerekli değildir)
• Yinelenen sütun yok
• Her sütun tek bir değer içerir (atomik)

[1] Teknik olarak nitelikler sıralanmamıştır, ancak bir tabloda satır verilerinin sütun başlıklarıyla aynı sırada olması gerekir. Ancak, gerçek sipariş önemsizdir.

Açık birden veriler :

Atomik veri kavramı, bir maddenin daha fazla parçalanamayacağıdır. Bu kavram, teknik olarak her şey reklam müzesinde parçalanabilse de, söz konusu verilerin, verilerin nasıl kullanılacağına bağlı olarak, pratik olarak daha fazla parçalanamayacağı konusunda nitelikli olmuştur .

Örneğin, bir tam adres veya bir tam ad normalde daha fazla parçalanmalıdır, ancak verilen ad veya şehir adı gibi bileşenler, dizeler olabilmelerine rağmen muhtemelen daha fazla bozulmamalıdır.

Yinelenen sütunlarla ilgili olarak , vb. Gibi neredeyse yinelenen sütunlara sahip olmak zayıf bir tasarım sütunudur . Genel olarak, tekrarlanan veriler ek bir ilişkili tabloya ihtiyaç olduğunu gösterir.phone1phone2

Bağımlılık

Satırlar arasında aynı başlıklara uymaları dışında herhangi bir ilişki olmamalıdır.

Sütunlar arasında da bir ilişki olmamalı, ancak bunun daha yüksek normal formların konusu olduğuna inanıyorum.

Soru şudur: 1NF'nin tanımında yukarıdakilerin ne kadarı? Bağımsız sıralar da buna girer mi?

Ön hazırlık

Tanımı normal formda (1971 bir “veri tabanı ilişkisel model başka Normalizasyon” sunumundan olarak bilinen birinci normal formu ) ve güçlü bir koşulla ki kendisi bilimsel yazıda defa 1970 yılında, ilişkisel paradigma tanımı veritabanı yönetimi, yani uygulamasına temel, “Büyük Paylaşılan Veri Bankaları için Veri A ilişkisel Modeli” yarattığı (kısalık için RM) Dr EF Codd bir Turing Ödülü alıcı ve olduğunu ilişkisel çerçeve konusunda otorite.

Evet, Dr. Codd'un metni hakkında birçok açıklama, yorum, açıklama, sapma ve görüş var, ancak kişisel olarak orijinal kaynağa bağlı kalmayı tercih ediyorum ve kendi sonuçlarınızı çizebilmeniz için bunu kendiniz analiz etmenizi şiddetle tavsiye ediyorum.

RM'yi kesinlikle tam olarak anlamıyorum, ancak anladığım şey mükemmelliğini, vizyonunu, niyetini ve kapsamını takdir etmeme izin veriyor ve on yıllar sonra insanın birkaç küçük belirsizliği olduğunu not etse de, herhangi bir şekilde dehası ve zarafeti. Kendi alanında RM, zamanın testini benzersiz bir şekilde sürdürdü ve eşsiz kaldı.

Bahsedilen yanlışlıkları vurgulama eylemi - hayırsever bir terim kullanarak - haksızlık olurdu , çünkü bunu önemli bir mesafeden görmek, bu seminal malzeme birkaç iyileştirme ve uzatma gerektirdi, evet, ancak işin ana gövdesi, çok anlayışlı (ve aslında Dr. Codd, bu ayrıntılandırmaların ve uzantıların kendisinin hepsinden olmasa da - en iyisini yaptı).

Bu istisnai bilgi kaynağını anlamamı güçlendirmek için RM'yi sürekli olarak yeniden okumaya devam ediyorum (ve saygım her tekrarda büyümeye devam ediyor); amaç devlerin omuzlarında durmaktır.

İlişkiler ve tablolar

İlişkilerin soyut kaynaklar olduğu için, Dr. Codd'un bunları tablo şeklinde göstermenin faydasını öngördüğünü belirtmek önemlidir (başlangıçta “dizi gösterimi” terimini kullanmıştır, ancak daha sonra “tablo” veya “r-tablo” kullanmıştır). ilişkisel bir veritabanının (RDB) kullanıcıları, tasarımcıları ve yöneticileri onlara daha tanıdık veya somut bir şekilde yaklaşabilir . Bu nedenle, RDB uygulaması bağlamında, ilişki için bir kısayol olarak tabloyu kullanmak geçerlidirsöz konusu tablo gerçek bir ilişkiyi temsil ettiği sürece. Bu özellik - açık olsa da - oldukça önemlidir, çünkü bir tablonun ilk normal forma (1NF) uygun bir ilişki olup olmadığını değerlendirmeden önce, tam olarak bir ilişkiyi temsil etmesi gerekir.

RM doğal olarak bir tablonun aslında bir ilişkiyi gösterip göstermediğini belirlemek zorunda olması gereken nitelikleri içerir, ancak burada onlar hakkında gayri resmi ve iddiasız bir yorum sunacağım (başka bir tane, evet!):

• Bir adı olmalıdır (bir veritabanı yapısındaki her özel ilişki diğerlerinden ayrılmalıdır).
• Satırlarının her biri , ilgili ilişkinin tam olarak bir demetini tasvir etmelidir .
• Emir onun satırların hiç önemli değildir.
• Sütunlarının her birinin , ilgili ilişkinin tam bir alanının anlamını temsil eden bir adı olmalıdır ve adı geçen ad, tablonun diğer sütunlarının adlarından farklı olmalıdır (bir sütun benzersiz bir şekilde farklılaştırılmalı ve belirgin bir anlam ve evet, bir veritabanı modelleyici ve iş uzmanlarının her bir önem alanını doğru bir şekilde tanımlamak için oynadığı rol çok önemlidir)
• Emir onun sütun hiçbir önemi vardır.
• Tüm satırları aynı sayıda sütuna sahip olmalıdır.
• Satırlarla tasvir edilen tuple'ların her birini benzersiz şekilde tanımlayan en az bir sütuna veya bir sütun kombinasyonuna sahip olmalıdır ; bu şekilde, tüm satırlar farklı olmalıdır (evet, bu en az bir KEY'in bildirilmesinin önemini vurgular ve iki veya daha fazla KEY olduğunda pragmatik nedenlerle birincisi PRIMARY olarak tanımlanır, gerisi ALTERNATİF olarak kabul edilir; ancak evet, karar vermeden önce her ANAHTAR PRİMER olarak tanım için “aday” dı).

Gerçekte bir ilişkiyi temsil eden bir tabloya sahip olmak kritik bir öneme sahiptir, çünkü ilişkisel türde bir manipülasyon işlemine maruz kaldığında sonuç yine bir ilişkiyi temsil eden bir tablodur. Bu şekilde, söz konusu tablonun davranışı tahmin edilebilir .

Atomik alanlar (sütunlar)

RM'nin ilk bölümlerinde, Dr. Codd bazı kavramları tanıtmak için çeşitli ilişkiler örnekleri sunar; atomik alanın anlamını anlamak için , RM'den bazı ilgili noktaları ayrıntılandıran aşağıdaki alıntıdan başlayalım:

Şimdiye kadar, elementleri atomik (birleştirilemez) değerler olan alanlar gibi basit alanlarda tanımlanan ilişkilerin örneklerini tartıştık. Nontomik değerler ilişkisel çerçevede ele alınabilir. Bu nedenle, bazı alanların öğeler olarak ilişkileri olabilir. Bu ilişkiler, basit olmayan alanlarda tanımlanabilir.

Bu yolla, yukarıda zikredilen açıklayıcı ilişkilerin her birinin iki türden birine uyduğunu söyleyebiliriz, ya A tipi ya da B tipi :

• Tür A yalnızca gruplarının (satırlarının) her birinde yalnızca basit değerler içeren alanlarla (sütunlar) yapılandırılmış ilişkileri (tablolar) , yani bu alanların (sütunların) değerler olarak ilişki (tablolar) içermediğini, bu bağlam, değerlerin atomik olduğu anlamına gelir, çünkü art arda yeni ilişkilere ayrılamazlar (tablolar). Bu nedenle, bu sınıfın ilişkileri normalleştirilmiş olanlardır , yani 1NF'ye uygundurlar, formları arzu edilir.

• B Tipi, her bir ilişkide (satır) ilişkileri ilişki olarak tutan bir veya daha fazla etki alanına (sütun) sahip olan ve bahsedilen değerlerin daha sonra yeni ilişkilere ayrılabildikleri için anatomik olmadığını ifade eden ilişkiler (tablolar) ile bütünleştirilir. (tablolar), yani ayrıştırılabilirler . Bu nedenle, bu tür ilişkiler normalleşmez, yani 1NF'yi ihlal ederler, istenmeyen bir formdadırlar.

normalleştirme

Dr. Codd, RM'de normalleşme ile ilgili bölümü aşağıdaki paragrafla tanıtıyor:

Etki alanları tamamen basit olan bir ilişki, depolamada yukarıda tartışılan türden iki boyutlu kolon homojen bir dizi ile temsil edilebilir. Bir veya daha fazla basit olmayan alanla ilişki için biraz daha karmaşık veri yapısı gereklidir. Bu nedenle (ve diğer alıntılar aşağıda belirtilmiştir) basit olmayan alan adlarını ortadan kaldırma olasılığı araştırmaya değer görünmektedir! Aslında, normalleştirme diyeceğimiz çok basit bir eleme prosedürü vardır.

Sonra göstermeye devam ediyor:

1. Birinin normalleştirilmemiş olduğu bir grup ilişki (değer olarak ilişki içeren etki alanlarına sahiptir, yani bunlar anatomik değildir; yani basit değildir)

2. Normalize edilmiş bir grup ilişki (yani ayrıştırılmış olan bir ilişki; yani değerli alanlarla ilişkisinin atomik olduklarını gösteren basit olanlara ayrıldığı)

Ve sonra normalleştirilmemiş ilişkilerden normalleştirilmiş ilişkiler elde etme prosedürünü açıklar.

Bu bağlamda, normalleştirme alıştırması ve alıştırma tanımının kendisini göstermek için kullandığı ilişkiler oldukça açıktır ve bunları kendiniz analiz etmenizi tekrar öneririm (ve umarım bu bazı okuyucuları metinle etkileşime teşvik eder).

Başarıyla şöyle diyor:

Normalleştirici türde başka işlemler de mümkündür. Bunlar bu yazıda tartışılmamıştır.

Ve adı geçen işlemler, yani ikinci ve üçüncü normal form (2NF ve 3NF) aslında "Veri Tabanı İlişkisel Modelinin Daha da Normalleştirilmesi" ve yukarıda belirtildiği gibi, bu makalenin sunumundan (ve daha sonra basılması ve yayınlanmasından sonra) ayrıntılı olarak açıklanmaktadır. , orijinal normal biçimi ilk normal form olarak tanındı.

Bir uygulayıcının gözlemleyebileceği gibi, normalleşmemiş ilişkilere (tablolara) sahip olmak RDB uygulamalarına (neredeyse her zaman gereksiz) evrişim getirir.

1NF'yi karşılayan bir ilişki, Dr. Codd'un aşağıdaki satırlarda belirttiği gibi, normal olmayan ilişkiler (tablolar) için gerekenden daha az karmaşık bir veri alt dili vasıtasıyla uygulanabilecek kısıtlamaların ve veri işleme işlemlerinin tanımını kolaylaştırır:

Yukarıda tarif edildiği gibi ilişkisel bir veri modelinin benimsenmesi, uygulanan bir yüklem hesaplamasına dayanan evrensel bir veri alt dilinin geliştirilmesine izin verir. İlişkilerin toplanması normal formda ise birinci dereceden yüklem hesabı yeterlidir. Böyle bir dil, önerilen diğer tüm veri dilleri için bir dilsel güç göstergesi sağlayacak ve kendisi çeşitli ana bilgisayar dillerine (programlama, komut veya probleme yönelik) gömülmesi (uygun sözdizimsel modifikasyonla) için güçlü bir aday olacaktır. [...]

[...]

Veri alt dilinin evrenselliği, açıklayıcı yeteneğinde (hesaplama yeteneğinde değil) yatmaktadır.

Şaşkınlık

Benim bakış kaynaktan, şaşkınlık bağlı 1NF ve yaklaşık vb yorumlardan açıklamalar, (a) yukarıda sözü edilen aşırı, ortaya çıkmıştır daha fazla girişimi RM kendisi, çünkü (b) 'nin yeniden tanımlanması 1nF bu durum bu ilişkileri olan ilişkileri tutan değerleri olan etki alanlarında, karşılık olarak, her karşılık gelen demet için tek bir değer olduğu sürece ilişkiler 1NF'ye uygundur .

Diğer puanları almam

Satırlar arasında aynı başlıklara uymaları dışında herhangi bir ilişki olmamalıdır.

Bu ifadenin niyetini doğru anladığımdan emin değilim, ancak aynı başlıklara uymanın yanı sıra, bir ilişkinin (tablolar) satırları arasında bir bağlantı olması gerekir, çünkü her biri bir ilişkinin (tablonun) temsil etmesi gereken belirli varlık türünün (ilgili ticari bağlam bağlamında tanımlanan) belirli bir oluşumu.

Sütunlar arasında da bir ilişki olmamalı, ancak bunun daha yüksek normal formların konusu olduğuna inanıyorum.

Bu ifadenin anlamını da doğru bir şekilde yorumlayıp yorumlamadığımı bilmiyorum, ama aslında ve önceki yönüne verdiğim yanıta göre , bir ilişkinin (tablo) alan adları (sütunları) arasında da bir ilişki olmalı bu tam olarak bir ilişkidir ( ilişkisel modelin ve somut bir RDB uygulamasının temel yapısı ).

Varsayımsal ilişki ile ilgili örnek vermek (tablo)

• Salary (PersonNumber, EffectiveDate, Amount)

demet (sıra)

• Salary (x, y, z)

anlamı iletir

• The Salary payed to the Person identified by PersonNumber x, on EffectiveDate y corresponds to the Amount of z

Bu nedenle, Salaryilişkinin (tablonun) her bir tupu (satırı) yukarıda gösterilen iddianın yapısına uymalıdır ve fark ilgili etki alanı (sütun) değerlerinin değiştirilmesi olacaktır, ancak (a) arasında bir ilişki olmalıdır. tüm Salaryalan (sütunlar) ve ayrıca (b) arasında her bir tuple (sıra) ile ilgili karşılık gelen değerleri; böyle bir ilişki vazgeçilmezdir.

Daha yüksek normal formlar (2NF ve 3NF), bir ilişkinin (tablo) etki alanları (sütunları) arasındaki işlevsel bağımlılıklardan kurtulmak için yararlıdır , söz konusu istenmeyen bağlantılar güncelleme anormalliklerinin eklenmesine izin verdiğinden , alanlar (sütunlar) arasında istenmeyen bağlantılardan kaçınmaya yardımcı olurlar. . Hem 2NF hem de 3NF, belirli bir RDB uygulamasında ilişkilerin (tabloların) yapısının sağlamlığını test etmeye yardımcı olur.

Bir örnek. Tipik bir ABD adresi içeren bir metin dizesi alın:

"123 Cornhusk Rd., South Succotash, NY 12345"

Tüm Cornhusk Yolu sakinlerini veya Güney Succotash kasabasının veya New York eyaletinin belirli bir sakinini bulmak için bir sorgu yazmak korkutucu bir iş olacaktır. Özellikle verilerde aşağıdaki dizeler bulunduğunda:

"123 Cornhusk Road, South Succotash, NY 12345"
"123 Cornhusk Rd., South Succotash, New York 12345"
"123 Cornhusk, South Succotash, NY 12345"
"123 Cornhusk Rd., SOUTH SUCCOTASH, NY 12345"

Bunların her biri aynı gerçek adresi belirtir (ve bu, "Succatash" gibi olası yanlış yazımları bile dikkate almaz), ancak bunları başarılı bir şekilde karşılaştırmak için algoritmayı yazmak, bu Dünya'da kalan son yıllarımı yapmak istemeyeceğim bir şeydir.

İlk normal formu girin. Nasıl yapıldığının ayrıntılarına girmeyeceğim, sadece çoğu veritabanında görüldüğü gibi ortak bir form düşünün:

create table Addresses(
  ...
  Street  varchar,
  City    int        references Cities( ID ),
  State   char( 2 )  references States( ID ),
  Zip     int
  ...
);

Bu tam bir normalleşme değildir. Örneğin, Street'i StreetNum ve StreetName'e daha fazla bölebilirsiniz, ancak bu basit bir örnek için yeterince yeterlidir ve gerçekten normalleştirme sürecinin gerçek hayatta olduğu kadarıyla ilgilidir. Hala Cornhusk Road sakinleri bulmak için küçük bir sorun var ama eğer sokak "Cornhusk" alt dizesi için arama ve bir yerde Cornhusk adlı bir kasaba oldu, en azından bu karışıklık neden olmaz.

Date ve arkadaşlarının tanımındaki problem, bir veri parçasının içine bakıp o verilerin anlamını dikkate almamalarıdır. Onları özellikle suçladığım için değil, oldukça zor olabilir.

Bu yüzden bir "karakter dizesi" alıp bir "adres" e dönüştürmeliyiz. Ancak her şey dahil bir adres tanımı bulmak, göründüğü kadar basit değildir. Özellikle birden fazla ülkedeki adreslerle çalışırken.

İlk olarak, içeriği düzeltiriz. Hiçbir şeyin bağlam olmadan anlamı yoktur. Buradaki bağlamımız adres . Bu bağlamda, verilerin Sokak , Şehir vb. Gibi belirli anlamları olan kısımlarını görebiliriz . Her bir anlamı ayrı bir alan atarız.

Zor olan nokta, verilerin, kelimeler gibi, farklı insanlar için farklı anlamlara sahip olabilmesidir veya bazı insanlar başkalarının anlamadığı yerlerde anlam görebilirler. Kendi başına bir proje olabilir ve çok fazla işbirliği çabası gerektirir. Ancak, iyi veritabanı tasarımında kritik bir unsurdur.

Normalleştirme noktası, anormal verileri ortadan kaldırmak veya en azından en aza indirmektir . Yukarıdaki tabloda, seçilen durumda bulunmayan bir Kasaba veya Posta kodu girilebileceğini düşünün. Ya da seçilen kasabada gerçekte olmayan bir sokağa girildi. Ah, ama şimdi ikinci ve üçüncü normal forma giriyoruz ve bu başka bir konu.

1NF'yi belirli bir veri yapısı veya sabit kurallar kümesi yerine matematiksel ilişkiler kavramına giriş olarak düşünün. İlişkiler gibi matematiksel yapılar farklı şekillerde temsil edilebilir - tablolar en uygun yollardan sadece biridir. Tabloları kullanırken, amaçlanan ilişkilerini açıkça temsil etmelerini ve tablolardaki işlemlerin temsil edilen ilişkilere göre mantıklı olmasını sağlamak için kısıtlamalar vardır.

Sütun ve satır sırası ve çoğaltmanın önemsiz olduğunu söylediğimizde, bu, tüm önemli bilgilerin tabloda değerler olarak kaydedilmesini ve sorgularımız tarafından erişilebilir olmasını ve tablonun sunumuna kodlanmamasını sağlamak içindir. Az sayıda yazar varsa, tablolarda renk kullanımını açıkça yasaklamış olsa da, yukarıdaki kısıtlamaların amacının anlaşılması, anlamlı renk değerlerinin açıkça kaydedilmesi için anlamlı sunum renklerinin kullanımını benzer şekilde dışlamamıza neden olacaktır. Tarih ve diğer yazarlar da aynı nedenden dolayı gizli satır tanımlayıcılarını kullanımdan kaldırmıştır.

Atomisite kavramı, tüm önemli yapıların ilişkiler olarak ifade edilmesini sağlamakla ilgilidir, böylece tüm verilerimizdeki bağımlılıkları analiz edebilir ve anomalileri önleyebiliriz, böylece tüm anlamlı yapıların ilişkisel operasyonlar için eşit olarak erişilebilir olmasını sağlayabiliriz. Bileşik değerler geçersiz değildir, ancak açmak için etki alanına özgü işleçler gerektirir ve bu da karmaşıklığı artırır ve fazlalık getirebilir. Tabii ki, pratikte bazı basit kompozit türler ve ilgili operatörler uygundur ve sorguların kompaktlığını ve ifadesini artırmaya yardımcı olur, ancak bu teoriyle çelişmez.

Çok değerli bağımlılıklar gibi satır bağımlılıkları 1NF'yi ihlal etmez, ancak sütunlar arasındaki bağımlılıklar gibi daha yüksek normal formların konusudur. Neredeyse yinelenen sütunlar phone1, phone2vb.Gibi zayıf tasarım olsalar bile 1NF'yi ihlal etmeyin.

Tanımı ve açıklama 1NF hakkında Wikipedia'dan, oldukça iyi olduğunu düşünüyorum. - joanolo

Wikipedia makalesinde bir cümle üzerinde genişleme:

Telefon numaraları olarak görülen metin atomik değildir

Bu, neden bu kadar karışıklık olduğu konusunda size yardımcı olabilir. Bu sadece metnin bir parçasıysa, o zaman atomiktir. Ama telefon numarası olarak görülüyorsa atomik değildir. Tarih ve diğerleri bu sorunu ortadan kaldırıyor. Verilerin anlamı ile ilgilidir. Konuyu analiz ederken, verilerin ne anlama geldiğini kavramanız gerekir.

Daha fazla parçalamak için herhangi bir nokta olup olmadığı, ilk normal formun karşılanıp karşılanmadığı sorusuyla ilgilidir. 1NF'nin arkasındaki nokta, tüm verilere anahtarlı erişim sağlamaktır. Ancak, anahtarlı erişim yoluyla aldığınız şeyin alt yapısı varsa, alt yapıya anahtarlı erişiminiz olmaz. - Walter Mitty

"1NF", çoğu eşzamanlı olarak saçma ve yaygın olan bir grup farklı şeyi ifade etmek için kullanılır . Bağlantıları da dahil olmak üzere "Veritabanı yönetim sisteminde normalleştirme" yanıtıma bakın . Bunlardan biri olan "nedir bölünmezlik DBMS" cevabım . (Her ikisi de Stack Overflow'da.) - philipxy

_{Soru üzerine kalan yorumlardan oluşturulan Topluluk Wiki yanıtı}