Normalleştirme (veya Normalleştirme) nedir?
Yanıtlar:
Normalleştirme, temelde, yinelenen ve gereksiz verilerin önleneceği bir veritabanı şeması tasarlamaktır. Bazı veri parçalarının veritabanında birkaç yerde kopyalanması durumunda, verilerin bir yerde güncellenip diğerinde güncellenmemesi riski vardır ve bu da veri bozulmasına yol açar.
1. normal formdan 5. normal forma kadar bir dizi normalleştirme seviyesi vardır. Her normal form, genellikle fazlalıkla ilgili belirli bir problemden nasıl kurtulacağınızı açıklar.
Bazı tipik normalleştirme hataları:
(1) Bir hücrede birden fazla değere sahip olmak. Misal:
UserId | Car
---------------------
1 | Toyota
2 | Ford,Cadillac
Burada "Araba" sütunu (bir dizedir) birkaç değere sahiptir. Bu, her hücrenin yalnızca bir değere sahip olması gerektiğini söyleyen ilk normal biçimi rahatsız eder. Araba başına ayrı bir sıra oluşturarak bu sorunu ortadan kaldırabiliriz:
UserId | Car
---------------------
1 | Toyota
2 | Ford
2 | Cadillac
Bir hücrede birkaç değere sahip olmanın sorunu, güncellemenin zor olması, sorgulamanın zor olması ve dizinler, kısıtlamalar vb. Uygulayamamanızdır.
(2) Anahtar olmayan gereksiz verilere sahip olmak (yani veriler gereksiz yere birkaç satırda tekrarlanır). Misal:
UserId | UserName | Car
-----------------------
1 | John | Toyota
2 | Sue | Ford
2 | Sue | Cadillac
Bu tasarım bir sorundur, çünkü ad her zaman KullanıcıKimliği tarafından belirlense de, ad her sütun için tekrarlanır. Bu, teorik olarak Sue adını bir satırda değiştirmeyi ve veri bozulması olan diğerini değiştirmeyi mümkün kılar. Sorun, tabloyu ikiye bölerek ve bir birincil anahtar / yabancı anahtar ilişkisi oluşturarak çözülür:
UserId(FK) | Car UserId(PK) | UserName
--------------------- -----------------
1 | Toyota 1 | John
2 | Ford 2 | Sue
2 | Cadillac
Şimdi, UserId'ler tekrarlandığı için hala fazlalık veriye sahibiz gibi görünebilir; Bununla birlikte, PK / FK kısıtlaması, değerlerin bağımsız olarak güncellenememesini sağlar, böylece bütünlük güvenlidir.
Önemli mi? Evet çok önemli. Normalleştirme hataları olan bir veritabanına sahip olduğunuzda, veritabanına geçersiz veya bozuk verilerin girme riskini açarsınız. Veriler "sonsuza kadar yaşadığından", veri tabanına ilk girdiğinde bozuk verilerden kurtulmak çok zordur.
Normalleşmekten korkmayın . Normalizasyon seviyelerinin resmi teknik tanımları oldukça geniş. Normalleştirme karmaşık bir matematiksel süreçmiş gibi görünmesini sağlıyor. Bununla birlikte, normalleştirme temelde sadece sağduyudur ve sağduyu kullanarak bir veritabanı şeması tasarlarsanız, tipik olarak tamamen normalleştirileceğini göreceksiniz.
Normalleşmeyle ilgili bir dizi yanılgı vardır:
bazıları normalleştirilmiş veri tabanlarının daha yavaş olduğuna ve normalden arındırmanın performansı artırdığına inanıyor. Ancak bu yalnızca çok özel durumlarda geçerlidir. Tipik olarak normalleştirilmiş bir veritabanı da en hızlısıdır.
bazen normalleşme aşamalı bir tasarım süreci olarak tanımlanır ve "ne zaman duracağınıza" karar vermeniz gerekir. Ama aslında normalleştirme seviyeleri sadece farklı belirli sorunları tanımlar. 3. NF'nin üzerindeki normal formlar tarafından çözülen sorun, ilk etapta oldukça nadir görülen sorunlardır, bu nedenle, şemanızın zaten 5NF'de olma ihtimali vardır.
Veritabanları dışındaki herhangi bir şeye uygulanabilir mi? Doğrudan değil, hayır. Normalleştirme ilkeleri ilişkisel veritabanları için oldukça özeldir. Ancak genel temel tema - farklı örnekler senkronize değilse yinelenen verilere sahip olmamalısınız - geniş bir şekilde uygulanabilir. Bu temelde KURU prensibidir .
Normalleştirme kuralları (kaynak: bilinmiyor)
En önemlisi, veri tabanı kayıtlarından çoğaltmanın kaldırılmasına hizmet eder. Örneğin, bir kişinin adının gelebileceği birden fazla yeriniz (tablolarınız) varsa, adı ayrı bir tabloya taşır ve başka her yerde ona referans verirsiniz. Bu şekilde, daha sonra kişi adını değiştirmeniz gerekirse, yalnızca tek bir yerde değiştirmeniz gerekir.
Doğru veritabanı tasarımı için çok önemlidir ve teoride, veri bütünlüğünüzü korumak için mümkün olduğunca onu kullanmalısınız. Ancak birçok tablodan bilgi alırken performansınızı kaybedersiniz ve bu nedenle bazen performans açısından kritik uygulamalarda kullanılan normal olmayan veritabanı tablolarını (düzleştirilmiş olarak da adlandırılır) görebilirsiniz.
Tavsiyem, iyi derecede normalizasyonla başlamak ve sadece gerçekten ihtiyaç duyulduğunda normalizasyondan arındırmak
Not: Konu ve sözde normal formlar hakkında daha fazla bilgi edinmek için http://en.wikipedia.org/wiki/Database_normalization makalesine de bakın.
Normalleştirme, bir tablodaki sütunlar arasındaki fazlalık ve işlevsel bağımlılıkları ortadan kaldırmak için kullanılan bir prosedür.
Genellikle bir sayı ile gösterilen birkaç normal form vardır. Daha yüksek bir sayı, daha az yedeklilik ve bağımlılık anlamına gelir. Herhangi bir SQL tablosu 1NF'dir (ilk normal form, hemen hemen tanım gereği) Normalleştirme, şemayı tersine çevrilebilir bir şekilde değiştirmek (genellikle tabloları bölümlemek), daha az fazlalık ve bağımlılıklar dışında işlevsel olarak aynı olan bir model vermek anlamına gelir.
Verilerin fazlalığı ve bağımlılığı istenmeyen bir durumdur çünkü verileri değiştirirken tutarsızlıklara yol açabilir.
Veri fazlalığını azaltmayı amaçlamaktadır.
Daha resmi bir tartışma için Wikipedia http://en.wikipedia.org/wiki/Database_normalization'a bakın.
Biraz basit bir örnek vereceğim.
Genellikle aile üyelerini içeren bir kuruluşun veritabanını varsayın
id, name, address
214 Mr. Chris 123 Main St.
317 Mrs. Chris 123 Main St.
normalleştirilebilir
id name familyID
214 Mr. Chris 27
317 Mrs. Chris 27
ve bir aile masası
ID, address
27 123 Main St.
Neredeyse Tamamlanmış Normalleştirme (BCNF) genellikle üretimde kullanılmaz, ancak bir ara adımdır. Veritabanını BCNF'ye koyduğunuzda, bir sonraki adım genellikle sorguları hızlandırmak ve belirli ortak eklerin karmaşıklığını azaltmak için mantıksal bir şekilde normalize etmektir. Ancak, bunu önce düzgün bir şekilde normalleştirmeden iyi yapamazsınız.
Gereksiz bilginin tek bir girişe indirgenmesi fikri. Bu, özellikle Bay Chris'in adresini Ünite-7 123 Ana Cadde olarak gönderdiği ve Bayan Chris'in orijinal tabloda iki farklı adres olarak görünecek olan Suite-7 123 Ana Cadde'yi listelediği adresler gibi alanlarda yararlıdır.
Tipik olarak, kullanılan teknik, tekrarlanan öğeleri bulmak ve bu alanları benzersiz kimliklerle başka bir tabloda izole etmek ve tekrarlanan öğeleri yeni tabloya referans veren bir birincil anahtarla değiştirmektir.
CJ Date'den alıntı yapmak: Teori pratiktir.
Normalleştirmeden sapmalar, veritabanınızda belirli anormalliklere neden olacaktır.
İlk Normal Formdan Ayrılma, erişim anormalliklerine neden olur, yani aradığınızı bulmak için ayrı değerleri ayrıştırmanız ve taramanız gerekir. Örneğin, değerlerden biri daha önceki bir yanıtla verilen "Ford, Cadillac" dizesi ise ve "Ford" un tüm tekrarlarını arıyorsanız, dizeyi kırıp açmanız ve şuna bakmanız gerekecektir. alt dizeler. Bu, bir dereceye kadar, verilerin ilişkisel bir veritabanında depolanması amacını ortadan kaldırır.
Birinci Normal Form'un tanımı 1970'ten beri değişti, ancak bu farklılıkların şimdilik sizi ilgilendirmesine gerek yok. İlişkisel veri modelini kullanarak SQL tablolarınızı tasarlarsanız, tablolarınız otomatik olarak 1NF'de olacaktır.
İkinci Normal Biçimden ve daha fazlasından ayrılma, güncelleme anormalliklerine neden olur, çünkü aynı gerçek birden fazla yerde saklanır. Bu sorunlar, var olmayan ve dolayısıyla icat edilmesi gereken diğer gerçekleri saklamadan bazı gerçekleri saklamayı imkansız kılar. Veya gerçekler değiştiğinde, kendisiyle çelişen bir veri tabanına sahip olmamanız için, bir olgunun depolandığı tüm alanları bulmanız ve tüm bu yerleri güncellemeniz gerekebilir. Ve veritabanından bir satırı silmeye gittiğinizde, bunu yaparsanız, hala ihtiyaç duyulan bir gerçeğin depolandığı tek yeri sildiğinizi görebilirsiniz.
Bunlar mantıksal sorunlardır, performans sorunları veya alan sorunları değildir. Bazen dikkatli programlama yaparak bu güncelleme anormalliklerinin üstesinden gelebilirsiniz. Bazen (çoğu zaman) normal formlara bağlı kalarak ilk etapta sorunları önlemek daha iyidir.
Daha önce söylenenlerin değerine bakılmaksızın, normalizasyonun yukarıdan aşağıya bir yaklaşım değil, aşağıdan yukarıya bir yaklaşım olduğu belirtilmelidir. Verilerin analizinde ve ilk tasarımınızda belirli metodolojileri takip ederseniz, tasarımın en azından 3NF'ye uygun olacağı garanti edilebilir. Çoğu durumda tasarım tamamen normalleştirilecektir.
Normalleştirme altında öğretilen kavramları gerçekten uygulamak isteyebileceğiniz yer, size eski bir veri tabanından veya kayıtlardan oluşan dosyalardan eski veriler verildiğinde ve veriler, normal formlar ve ayrılmanın sonuçları tamamen göz ardı edilerek tasarlandığı zamandır. onlardan. Bu durumlarda normalizasyondan sapmaları keşfetmeniz ve tasarımı düzeltmeniz gerekebilir.
Uyarı: Normalleştirme, sanki tam normalleşmeden her ayrılma bir günah, Codd'a karşı bir suçmuş gibi, genellikle dini imalarla öğretilir. (orada küçük kelime oyunu). Bunu satın alma. Veritabanı tasarımını gerçekten, gerçekten öğrendiğinizde, yalnızca kurallara nasıl uyacağınızı değil, aynı zamanda onları çiğnemenin ne zaman güvenli olduğunu da bileceksiniz.
Normalleştirme temel kavramlardan biridir. Bu, iki şeyin birbirini etkilemediği anlamına gelir.
Veritabanlarında özellikle, iki (veya daha fazla) tablonun aynı verileri içermediği, yani herhangi bir fazlalığa sahip olmadığı anlamına gelir.
İlk bakışta bu gerçekten iyi çünkü bazı senkronizasyon problemleri yapma şansınız sıfıra yakın, her zaman verilerinizin nerede olduğunu biliyorsunuz, vb. Ancak, muhtemelen, tablo sayınız artacak ve verileri geçmekte problem yaşayacaksınız. ve bazı özet sonuçlar almak için.
Böylece, sonunda biraz fazlalıkla (bazı olası normalleştirme seviyelerinde olacak) tamamen normalize edilmemiş veritabanı tasarımını bitireceksiniz.
Normalleştirme nedir?
Normalleştirme bize de o şekilde veritabanı tabloları ayrıştırmak sağlayan akıllıca bir adım resmi bir işlemdir veri fazlalığı ve güncelleme anomaliler en aza indirilmiştir.
Normalleştirme Süreci İzniyle
İlk normal biçim, ancak ve ancak her özniteliğin etki alanı yalnızca atomik değerler içeriyorsa (bir atomik değer, bölünemeyen bir değerdir) ve her özniteliğin değeri, o etki alanından yalnızca tek bir değer içeriyorsa (örnek: - için etki alanı cinsiyet sütunu: "M", "F".).
İlk normal biçim şu kriterleri uygular:
- Tek tek tablolarda yinelenen grupları ortadan kaldırın.
- Her bir ilgili veri kümesi için ayrı bir tablo oluşturun.
- Her bir ilgili veri kümesini bir birincil anahtarla tanımlayın
İkinci normal biçim = 1NF + kısmi bağımlılık yok yani, anahtar olmayan tüm özellikler, birincil anahtara tamamen işlevseldir.
Üçüncü normal biçim = 2NF + geçişli bağımlılık yok yani anahtar olmayan tüm öznitelikler, yalnızca birincil anahtara DOĞRUDAN tamamen işlevsel bağımlıdır.
Boyce – Codd normal formu (veya BCNF veya 3.5NF), üçüncü normal formun (3NF) biraz daha güçlü bir versiyonudur.
Not: - İkinci, Üçüncü ve Boyce – Codd normal formları, işlevsel bağımlılıklar ile ilgilidir. Örnekler
Dördüncü normal biçim = 3NF + Birden Çok Değerli bağımlılıkları kaldırın
Beşinci normal biçim = 4NF + birleştirme bağımlılıklarını kaldır
Martin Kleppman'ın Veri Yoğun Uygulamaları Tasarlamak kitabında dediği gibi:
İlişkisel model üzerine literatür, birkaç farklı normal formu birbirinden ayırır, ancak ayrımlar pratik açıdan pek ilgi çekmez. Genel bir kural olarak, tek bir yerde saklanabilecek değerleri kopyalıyorsanız, şema normalize edilmez.
Yinelenen (ve daha kötüsü, çakışan) verilerin önlenmesine yardımcı olur.
Yine de performans üzerinde olumsuz bir etkisi olabilir.