Veritabanı normalleştirme - Database normalization

Bu makale Veritabanları konusunda bir uzmanın ilgilenmesi gerekiyor. Bakın konuşma sayfası detaylar için. WikiProject Veritabanları bir uzmanın işe alınmasına yardımcı olabilir. (Mart 2018)

Veritabanı normalleştirme yapılandırma sürecidir ilişkisel veritabanı^{[açıklama gerekli ]} bir dizi sözde uyarınca normal formlar azaltmak için veri yedekleme Ve geliştirmek veri bütünlüğü. İlk önce tarafından önerildi Edgar F. Codd onun bir parçası olarak ilişkisel model.

Normalleştirme, sütunlar (özellikler) ve tablolar bir veritabanının (ilişkiler) bağımlılıklar veritabanı bütünlüğü kısıtlamaları tarafından uygun şekilde uygulanır. Ya bir işlemle bazı resmi kuralları uygulayarak gerçekleştirilir. sentez (yeni bir veritabanı tasarımı oluşturmak) veya ayrışma (mevcut bir veritabanı tasarımını iyileştirmek).

Hedefler

1970 yılında Codd tarafından tanımlanan ilk normal formun temel amacı, verilerin, temel alan "evrensel veri alt dili" kullanılarak sorgulanmasına ve manipüle edilmesine izin vermekti. birinci dereceden mantık.^[1] (SQL bu tür bir veri alt dilinin bir örneğidir, ancak Codd'un ciddi şekilde kusurlu bulduğu bir dildir.^[2])

1NF'nin (ilk normal form) ötesinde normalizasyon hedefleri Codd tarafından şu şekilde belirtilmiştir:

1. İlişki koleksiyonunu istenmeyen ekleme, güncelleme ve silme bağımlılıklarından kurtarmak için.
2. Yeni veri türleri ortaya çıktıkça, ilişki koleksiyonunu yeniden yapılandırma ihtiyacını azaltmak ve böylece uygulama programlarının ömrünü uzatmak.
3. İlişkisel modeli kullanıcılar için daha bilgilendirici hale getirmek.
4. İlişkilerin koleksiyonunu, bu istatistiklerin zaman geçtikçe değişme eğiliminde olduğu sorgu istatistiklerine karşı tarafsız kılmak.

— E.F. Codd, "Veri Tabanı İlişkisel Modelinin Daha Fazla Normalleştirilmesi"^[3]

Bir anormalliği güncelle. Çalışan 519, farklı kayıtlarda farklı adreslere sahip olarak gösterilir.

Bir ekleme anormalliği. Yeni öğretim üyesi Dr. Newsome en az bir ders vermekle görevlendirilene kadar detayları kaydedilemez.

Bir silme anormalliği. Dr. Giddens ile ilgili tüm bilgiler, herhangi bir kursa atanmayı geçici olarak durdurursa kaybolur.

Bir ilişkiyi değiştirme (güncelleme, ekleme veya silme) girişiminde bulunulduğunda, yeterince normalize edilmemiş ilişkilerde aşağıdaki istenmeyen yan etkiler ortaya çıkabilir:

• Anormalliği güncelleyin. Aynı bilgiler birden çok satırda ifade edilebilir; bu nedenle ilişkideki güncellemeler mantıksal tutarsızlıklara neden olabilir. Örneğin, bir "Çalışanların Becerileri" ilişkisindeki her kayıt bir Çalışan Kimliği, Çalışan Adresi ve Beceri içerebilir; bu nedenle, belirli bir çalışanın adres değişikliğinin birden fazla kayda (her beceri için bir tane) uygulanması gerekebilir. Güncelleme yalnızca kısmen başarılı olursa - çalışanın adresi bazı kayıtlarda güncellenir, ancak diğerlerinde güncellenmez - bu durumda ilişki tutarsız bir durumda kalır. Özellikle, ilişki, bu belirli çalışanın adresinin ne olduğu sorusuna çelişkili yanıtlar sağlar. Bu fenomen, güncelleme anomalisi olarak bilinir.
• Ekleme anormalliği. Bazı gerçeklerin kaydedilemediği durumlar vardır. Örneğin, "Fakülte ve Dersleri" ilişkisindeki her kayıt bir Fakülte Kimliği, Fakülte Adı, Fakülte İşe Alma Tarihi ve Ders Kodu içerebilir. Bu nedenle, en az bir ders veren herhangi bir öğretim üyesinin ayrıntılarını kaydedebiliriz, ancak Ders Kodu'nu null olarak ayarlamak dışında, henüz herhangi bir ders vermek üzere atanmamış yeni işe alınmış bir öğretim üyesini kaydedemiyoruz. Bu fenomen, ekleme anomalisi olarak bilinir.
• Silme anormalliği. Belirli koşullar altında, belirli gerçekleri temsil eden verilerin silinmesi, tamamen farklı gerçekleri temsil eden verilerin silinmesini gerektirir. Önceki örnekte açıklanan "Fakülte ve Dersleri" ilişkisi bu tür bir anormallikten muzdariptir, çünkü bir öğretim üyesi herhangi bir derse atanmayı geçici olarak durdurursa, o öğretim üyesinin göründüğü son kayıtları etkili bir şekilde silmeliyiz. Ders Kodu null olarak ayarlanmadıkça, öğretim üyesini de silmek. Bu fenomen, silme anormalliği olarak bilinir.

Veritabanı yapısını genişletirken yeniden tasarımı en aza indirin

Tamamen normalleştirilmiş bir veritabanı, yapısının mevcut yapıyı çok fazla değiştirmeden yeni veri türlerini barındıracak şekilde genişletilmesine izin verir. Sonuç olarak, veritabanıyla etkileşime giren uygulamalar minimum düzeyde etkilenir.

Normalleştirilmiş ilişkiler ve bir normalleştirilmiş ilişki ile diğeri arasındaki ilişki, gerçek dünya kavramlarını ve bunların karşılıklı ilişkilerini yansıtır.

Misal

Müşterilerin kredi kartı işlemlerinin aşağıdaki 1NF olmayan temsili gibi normalize edilmemiş bir veri yapısı içindeki verileri sorgulamak ve değiştirmek, gerçekten gerekenden daha fazla karmaşıklık içerir:

Her müşteri için bir 'tekrar eden işlem grubuna' karşılık gelir. Bu nedenle, müşterilerin işlemleriyle ilgili herhangi bir sorgunun otomatik olarak değerlendirilmesi, genel olarak iki aşamayı içerir:

1. Bir gruptaki münferit işlemlerin incelenmesine olanak tanıyan bir veya daha fazla müşteri işlem grubunun paketinden çıkarılması ve
2. İlk aşamanın sonuçlarına göre bir sorgu sonucu türetme

Örneğin, tüm müşteriler için Ekim 2003'te gerçekleşen tüm işlemlerin parasal toplamını bulmak için, sistemin önce paketini açması gerektiğini bilmesi gerekir. İşlemler her müşterinin grubu, ardından Miktarlar bu şekilde elde edilen tüm işlemlerin Tarih işlemin% 50'si Ekim 2003'e düştü.

Codd'un önemli anlayışlarından biri, yapısal karmaşıklığın azaltılabileceğiydi. Azaltılmış yapısal karmaşıklık, kullanıcılara, uygulamalara ve DBMS'lere sorguları formüle etmek ve değerlendirmek için daha fazla güç ve esneklik sağlar. Yukarıdaki yapının daha normalleştirilmiş bir eşdeğeri şöyle görünebilir:

Değiştirilmiş yapıda, birincil anahtar {Cust. ID} ilk ilişkide, {Cust. ID, Tr. İkinci ilişkide ID}.

Artık her satır ayrı bir kredi kartı işlemini temsil ediyor ve DBMS, sadece Ekim ayında bir Tarihe sahip tüm satırları bularak ve Tutarlarını toplayarak ilgilendiğiniz yanıtı elde edebilir. Veri yapısı, tüm değerleri eşit bir zemine yerleştirir ve her birini doğrudan DBMS'ye maruz bırakır, böylece her biri potansiyel olarak sorgulara doğrudan katılabilir; oysa önceki durumda bazı değerler, özel olarak ele alınması gereken alt düzey yapıların içine gömülmüştü. Buna göre, normalleştirilmiş tasarım genel amaçlı sorgu işlemeye uygunken, normalleştirilmemiş tasarım bunu yapmaz. Normalleştirilmiş sürüm ayrıca kullanıcının müşteri adını tek bir yerde değiştirmesine izin verir ve müşteri adının bazı kayıtlarda yanlış yazılması durumunda ortaya çıkabilecek hatalara karşı koruma sağlar.

Normal formlar

Codd, normalleştirme kavramını tanıttı ve şimdi Birincil normal form (1NF) 1970 yılında.^[4] Codd, ikinci normal biçim (2NF) ve üçüncü normal biçim (3NF) 1971'de,^[5] ve Codd ve Raymond F. Boyce tanımlanmış Boyce-Codd normal formu (BCNF) 1974'te.^[6]

Gayri resmi olarak, ilişkisel bir veritabanı ilişkisi, üçüncü normal formu karşılıyorsa "normalleştirilmiş" olarak tanımlanır.^[7] Çoğu 3NF ilişkisinde ekleme, güncelleme ve silme anormallikleri yoktur.

Normal formlar (en az normalleştirilmişten en çok normalleştirilmişe) şunlardır:

	UNF (1970)	1NF (1970)	2NF (1971)	3NF (1971)	EKNF (1982)	BCNF (1974)	4NF (1977)	ETNF (2012)	5NF (1979)	DKNF (1981)	6NF (2003)
Birincil anahtar (kopya yok demetler )
Tekrar eden grup yok
Atomik sütunlar (hücrelerin tek değeri vardır)[8]
Her önemsiz olmayan işlevsel bağımlılık ya uygun bir a alt kümesiyle başlamaz aday anahtar veya ile biter asal nitelik (aday anahtarlara birincil olmayan özniteliklerin kısmi işlevsel bağımlılıkları yoktur)[8]
Önemsiz olmayan her işlevsel bağımlılık bir süper veya bir asal öznitelikle biter (hayır geçişli işlevsel bağımlılıklar aday anahtarlarda asal olmayan özniteliklerin sayısı)[8]
Önemsiz olmayan her işlevsel bağımlılık ya bir süper anahtarla başlar ya da bir temel asal nitelik[8]											Yok
Önemsiz olmayan her işlevsel bağımlılık bir süper anahtarla başlar[8]											Yok
Her önemsiz olmayan çok değerli bağımlılık bir süper ile başlar[8]											Yok
Her bağımlılığa katıl süper bir bileşeni var[9]											Yok
Her birleştirme bağımlılığının yalnızca süper bileşen bileşenleri vardır[8]											Yok
Her kısıtlama, etki alanı kısıtlamalarının ve anahtar kısıtlamaların bir sonucudur[8]											Yok
Her katılma bağımlılığı önemsizdir[8]

Adım adım normalleştirme örneği

Normalleştirme, bir veri tabanı tasarım tekniğidir. ilişkisel veritabanı daha yüksek normal forma kadar tablo.^[10] Süreç aşamalıdır ve önceki seviyeler karşılanmadıkça daha yüksek bir veritabanı normalizasyonu seviyesine ulaşılamaz.^[11]

Bu, verilerin normalleştirilmemiş form (en az normalleştirilmiş) ve en yüksek normalleşme düzeyine ulaşmayı hedefleyen ilk adım, aşağıdakilere uyumu sağlamak olacaktır. Birincil normal form ikinci adım, ikinci normal biçim yukarıda belirtilen sırayla karşılanır ve veriler uygun olana kadar altıncı normal form.

Ancak, normal formların ötesinde olduğunu belirtmekte fayda var. 4NF Çözülmesi gereken problemler pratikte nadiren ortaya çıktığı için esas olarak akademik ilgi çekmektedir.^[12]

Lütfen aşağıdaki örnekteki verilerin kasıtlı olarak normal formların çoğuyla çelişecek şekilde tasarlandığını unutmayın. Gerçek hayatta, bazı normalleştirme adımlarını atlamak oldukça mümkündür çünkü tablo verilen normal formla çelişen hiçbir şey içermemektedir. Ayrıca, bir normal formun ihlalini düzeltmenin, süreçteki daha yüksek normal bir formun ihlalini de düzelttiği yaygın olarak görülür. Ayrıca her adımda normalleştirme için bir tablo seçilmiştir, bu da bu örnek işlemin sonunda, en yüksek normal formu karşılamayan bazı tablolar olabileceği anlamına gelir.

İlk veri

Aşağıdaki yapıya sahip bir veritabanı tablosuna izin verin:^[11]

Bu örnekte her kitabın yalnızca bir yazarı olduğunu varsayıyoruz.

1NF'yi tatmin etmek

1NF'yi sağlamak için, bir tablonun her sütunundaki değerler atomik olmalıdır. İlk tabloda, Konu uygun olmadığı anlamına gelen bir dizi konu değeri içerir.

1NF'ye ulaşmanın bir yolu, tekrar eden grupları kullanarak kopyaları birden çok sütuna ayırmaktır. Konu:

Şimdi tablo resmi olarak 1NF'ye uygun olsa da (atomiktir), bu çözümle ilgili problem açıktır - eğer bir kitabın üçten fazla konusu varsa, yapısını değiştirmeden veritabanına eklenemez.

Sorunu daha zarif bir şekilde çözmek için, tabloda gösterilen varlıkları belirlemek ve bunları kendi tablolarına ayırmak gerekir. Bu durumda, sonuçta Kitap, Konu ve Yayımcı tablolar:^[11]

İlk verileri birden çok tabloya ayırmak, veriler arasındaki bağlantıyı keser. Bu, yeni tanıtılan tablolar arasındaki ilişkilerin belirlenmesi gerektiği anlamına gelir. Dikkat edin Yayıncı kimliği Kitabın tablosundaki sütun bir yabancı anahtar farkına varma çoktan bire bir kitap ve bir yayıncı arasındaki ilişki.

Bir kitap birçok konuya uyabileceği gibi, bir konu birçok kitaba karşılık gelebilir. Bu aynı zamanda bir çoktan çoğa ilişkinin tanımlanması gerekiyor, bir bağlantı tablosu:^[11]

Bir tablo yerine normalleştirilmemiş form 1NF'ye uygun 4 tablo var.

2NF'yi tatmin edici

Kitap masada bir tane var aday anahtar (bu nedenle birincil anahtar ), bileşik anahtar {Başlık, Biçim}.^[13] Aşağıdaki tablo parçasını düşünün:

Aday anahtarın parçası olmayan tüm öznitelikler aşağıdakilere bağlıdır: Başlık, ama sadece Fiyat ayrıca bağlıdır Biçim. Uymak 2NF ve yinelemeleri ortadan kaldırırsanız, her aday-anahtar olmayan öznitelik, yalnızca bir kısmına değil, tüm aday anahtarına bağlı olmalıdır.

Bu tabloyu normalleştirmek için {Başlık} bir (basit) aday anahtar (birincil anahtar), böylece her aday anahtar olmayan özellik tüm aday anahtara bağlıdır ve Fiyat ayrı bir tabloya böylelikle bağımlılığı Biçim korunabilir:

Şimdi Kitap tablo uygundur 2NF.

3NF'yi tatmin etmek

Kitap tablo hala geçişli bir işlevsel bağımlılığa sahiptir ({Yazar Uyruğu}, {Başlık} 'a bağlı olan {Yazar}' a bağlıdır). Tür için benzer bir ihlal var ({Tür Adı}, {Başlık} türüne bağlı olan {Tür Kimliği} 'ne bağlıdır). Bu nedenle, Kitap tablo 3NF'de değil. Bunu 3NF'de yapmak için, aşağıdaki tablo yapısını kullanalım, böylece kendi ilgili tablolarına {Author Nationality} ve {Genre Name} yerleştirerek geçişli işlevsel bağımlılıkları ortadan kaldıralım:

EKNF'yi tatmin etmek

Temel anahtar normal formu (EKNF) kesinlikle 3NF ve BCNF arasındadır ve literatürde pek tartışılmamaktadır. O istendi "Hem 3NF hem de BCNF'nin göze çarpan özelliklerini yakalamak için" her ikisinin de sorunlarından kaçınırken (yani, 3NF'nin "çok bağışlayıcı" ve BCNF'nin "hesaplama karmaşıklığına eğilimli" olması). Literatürde nadiren bahsedildiği için bu örneğe dahil edilmemiştir.^[14]

4NF'yi tatmin etmek

Veritabanının, farklı lokasyonlarda dükkanları olan birkaç franchise sahibi olan bir kitap perakendecisi franchise'a ait olduğunu varsayalım. Bu nedenle perakendeci, kitapların farklı konumlarda bulunup bulunmadığına ilişkin verileri içeren bir tablo eklemeye karar verdi:

Bu tablo yapısı bir bileşik birincil anahtar, anahtar olmayan nitelikler içermez ve zaten BCNF (ve bu nedenle önceki tüm normal formlar ). Ancak, mevcut tüm kitapların her alanda sunulduğunu varsayarsak, Başlık kesin bir şekilde belirli bir yer ve bu nedenle tablo tatmin etmiyor 4NF.

Bu, tatmin etmek için dördüncü normal biçim, bu tablonun da ayrıştırılması gerekiyor:

Şimdi, her kayıt net bir şekilde bir süper bu nedenle 4NF memnun.^[15]

ETNF'yi karşılama

Franchise alanların farklı tedarikçilerden kitap sipariş edebileceğini varsayalım. İlişki ayrıca aşağıdaki kısıtlamaya tabi olsun:

• Belli ise Tedarikçi belli bir şey sağlar Başlık
• ve Başlık tedarik edilir imtiyaz sahibi
• ve imtiyaz sahibi tarafından tedarik ediliyor Tedarikçi,
• sonra Tedarikçi sağlar Başlık için imtiyaz sahibi.^[16]

Bu tablo 4NF, ancak Tedarikçi Kimliği, projeksiyonlarının birleşimine eşittir: {{Tedarikçi Kimliği, Kitap}, {Kitap, Franchise Kimliği}, {Franchise Sahibi Kimliği, Tedarikçi Kimliği}}. Bu birleşme bağımlılığının hiçbir bileşeni bir süper (tek süper başlığın tamamı olduğundan), bu nedenle tablo, ETNF ve daha da ayrıştırılabilir:^[16]

Ayrışma üretir ETNF uyma.

5NF'yi tatmin etmek

Tatmin edici olmayan bir tablo bulmak için 5NF genellikle verileri kapsamlı bir şekilde incelemek gerekir. Varsayalım ki tablo 4NF örneği verilerde küçük bir değişiklikle ve tatmin edip etmediğini inceleyelim 5NF:

Bu tabloyu ayrıştırırsak fazlalıkları azaltır ve aşağıdaki iki tabloyu alırız:

Bu masalara katılmaya çalışırsak ne olur? Sorgu aşağıdaki verileri döndürür:

Görünüşe göre, JOIN olması gerekenden üç satır daha döndürüyor - ilişkiyi netleştirmek için başka bir tablo eklemeye çalışalım. Üç ayrı tablo ile sonlandırıyoruz:

JOIN şimdi ne döndürecek? Aslında bu üç masayı birleştirmek mümkün değil. Bu, ayrıştırmanın mümkün olmadığı anlamına gelir. Franchise Sahibi - Rezervasyon Yeri veri kaybı olmadan, bu nedenle tablo zaten tatmin ediyor 5NF.^[15]

C.J. Date, sadece 5NF'deki bir veritabanının gerçekten "normalleştirilmiş" olduğunu savundu.^[17]

DKNF'yi tatmin etmek

Bir göz atalım Kitap Önceki örneklerden alınan tabloya bakın ve aşağıdaki koşulları karşılayıp karşılamadığına bakın: Etki alanı anahtarı normal biçimi:

Mantıksal olarak, Kalınlık sayfa sayısına göre belirlenir. Bu bağlı olduğu anlamına gelir Sayfalar bu bir anahtar değildir. 350 sayfaya kadar olan bir kitabın "ince" ve 350 sayfadan fazla bir kitabın "kalın" kabul edildiğini söyleyen bir örnek kongre oluşturalım.

Bu kural teknik olarak bir kısıtlamadır ancak ne bir alan kısıtlaması ne de bir anahtar kısıtlamasıdır; bu nedenle, veri bütünlüğünü korumak için etki alanı kısıtlamalarına ve anahtar kısıtlamalarına güvenemeyiz.

Başka bir deyişle - hiçbir şey, örneğin sadece 50 sayfalık bir kitap için "Kalın" koymamızı engellemez - ve bu, tablonun ihlal etmesine neden olur DKNF.

Bunu çözmek için, tanımlayan bir tablo tutan numaralandırma oluşturabiliriz. Kalınlık ve bu sütunu orijinal tablodan kaldırın:

Bu şekilde, alan bütünlüğü ihlali ortadan kaldırılmış ve tablo DKNF.

6NF'yi tatmin etmek

Basit ve sezgisel bir tanım altıncı normal form bu mu "bir masa var 6NF ne zaman satır Birincil Anahtarı ve en fazla başka bir özniteliği içerir ".^[18]

Bu, örneğin, Yayımcı tablo iken tasarlanmış 1NF'nin oluşturulması

ayrıca iki tabloya ayrıştırılması gerekir:

6NF'nin bariz dezavantajı, tek bir varlık üzerindeki bilgileri temsil etmek için gereken tabloların çoğalmasıdır. 5NF'deki bir tablonun bir birincil anahtar sütunu ve N özniteliği varsa, 6NF'de aynı bilgiyi temsil etmek için N tablo gerekir; tek bir kavramsal kayda yapılan çok alanlı güncellemeler, birden çok tabloda güncellemeler gerektirecektir; ve eklemeler ve silmeler, benzer şekilde birden çok tabloda işlemler gerektirecektir. Bu nedenle hizmet vermesi amaçlanan veri tabanlarında Çevrimiçi İşlem İşleme ihtiyaç, 6NF kullanılmamalıdır.

Ancak veri depoları Etkileşimli güncellemelere izin vermeyen ve büyük veri hacimlerinde hızlı sorgulama için özelleştirilmiş olan bazı DBMS'ler dahili 6NF gösterimi kullanır - Sütunlu veri deposu. Bir sütunun benzersiz değerlerinin sayısının tablodaki satır sayısından çok daha az olduğu durumlarda, sütun yönelimli depolama, veri sıkıştırma yoluyla önemli ölçüde alan tasarrufu sağlar. Sütunlu depolama, aralık sorgularının hızlı yürütülmesine de olanak tanır (örneğin, belirli bir sütunun X ile Y arasında veya X'ten küçük olduğu tüm kayıtları gösterin.)

Ancak tüm bu durumlarda, veritabanı tasarımcısının ayrı tablolar oluşturarak 6NF normalleştirmesini manuel olarak gerçekleştirmesi gerekmez. Ambarlama için uzmanlaşmış bazı DBMS'ler, örneğin Sybase IQ, varsayılan olarak sütunlu depolamayı kullanın, ancak tasarımcı yine de yalnızca tek bir çok sütunlu tablo görür. Microsoft SQL Server 2012 ve sonrası gibi diğer DBMS'ler, belirli bir tablo için bir "sütun deposu indeksi" belirlemenize izin verir.^[19]

Ayrıca bakınız

• Denormalizasyon
• Veritabanı yeniden düzenleme

• Kayıpsız birleşim ayrışması

Notlar ve referanslar

daha fazla okuma

• Tarih, C.J. (1999), Veritabanı Sistemlerine Giriş (8. baskı). Addison-Wesley Longman. ISBN  0-321-19784-4.
• Kent, W. (1983) İlişkisel Veritabanı Teorisinde Beş Normal Form İçin Basit Bir Kılavuz, ACM İletişimleri, cilt. 26, s. 120–125
• H.-J. Schek, P. Pistor Entegre Bir Veri Tabanı Yönetimi ve Bilgi Erişim Sistemi için Veri Yapıları

Dış bağlantılar

• Kent, William (Şubat 1983). "İlişkisel Veritabanı Teorisinde Beş Normal Form İçin Basit Bir Kılavuz". ACM'nin iletişimi. 26 (2): 120–125. doi:10.1145/358024.358054. S2CID  9195704.
• Veritabanı Normalleştirme Temelleri Yazan: Mike Chapple (About.com)
• Veritabanı Normalleştirme Giriş, Bölüm 2
• Veritabanı Normalleştirmesine Giriş Mike Hillyer tarafından.
• İlk 3 normal form hakkında bir eğitim Fred Coulson tarafından
• Veritabanı normalleştirme temellerinin açıklaması Microsoft tarafından
• Chaitanya tarafından DBMS'de normalleştirme (beginnersbook.com)
• Veritabanı Normalleştirme için Adım Adım Kılavuz
• ETNF - Temel demet normal formu