Denormalizasyon Nedir?

Denormalizasyon Nedir?

Denormalizasyon, istikrarlı, tamamen normalleştirilmiş bir veri yapısı tanımladıktan sonra, belirli performans gereksinimlerini kolaylaştırmak için seçici olarak yinelenen verileri tanıttığınız süreçtir.” Denormalizasyon, farklı varlıklardan veri öğelerini birleştirme işlemidir.

Bunu yaparak, normalleştirmenin faydalarını kaybederiz ve bu nedenle, fazlalığı tasarıma yeniden dahil ederiz. Bu ekstra fazlalık, geri alma süresi performansını iyileştirmeye yardımcı olabilir. Alma süresinin azaltılması, denormalizasyonun birincil nedenidir. Diyelim ki müşteri adını Satınalma varlığına normalleştirdik. Bu varlıktan bazı değerler listelenir.

Satın alan müşterinin adını almamız gerekirse, bunu bu ürünün bahsedildiği kayıtta çok hızlı bir şekilde yapabiliriz. Ad bilgisini bulmak için ayrı bir Müşteri tablosuna katılmamız ve bir müşteri tanımlayıcısı aramamız gerekmez. Veri öğelerini tekrar ederek, verilerimize daha hızlı erişim sağlayabiliriz.

Von Halle’nin tanımındaki en sevdiğim kelime seçici olarak. Denormalizasyonu uyguladığımız yerde çok dikkatli ve seçici olmalıyız çünkü geri alma süresini azaltabilse de çok büyük bir bedeli olabilir.

Denormalize etmenin bedeli şu kasvetli durumlar şeklinde olabilir:

Güncelleme, silme ve ekleme performansı düşebilir. Bir veri öğesini iki veya daha fazla tabloda tekrarladığımızda, genellikle bu veri öğesi içindeki değerleri çok daha hızlı bir şekilde geri getirebiliriz. Ancak, bu veri elemanındaki değeri değiştirmemiz gerekiyorsa, bulunduğu her tabloda değiştirmemiz gerekir.

Bu nedenle, Robert Jones olarak adlandırılmayı tercih edeceğimiz değerler listesinde, tüm satın alma kayıtlarını bu değişiklikle güncellememiz gerekiyor. Bu durumda, MÜŞTERİNİN İLK ADI veri öğesini üç kez güncellememiz gerekir; burada Bob değerini Robert olarak değiştiririz. Bu, bu değişiklikleri yapmak, yalnızca müşteri varlığı içinde müşteri adına sahip olmaktan ve Bob’dan Robert’a değişikliği yalnızca bir kez yapmaktan daha fazla zaman alır.

Bazen okuma performansı bile zarar görebilir. Okuma veya alma performansını artırmak için denormalize ediyoruz. Yine de, çok fazla veri elemanı tek bir varlığa denormalize edilirse, her bir kayıt uzunluğu çok büyüyebilir ve tek bir kaydın, veritabanı içinde tanımlanan bitişik belleğin uzunluğu olan bir veritabanı bloğu boyutunu kapsayabilme potansiyeli vardır.

Denormalizasyon nedir
Normalizasyon ve Denormalizasyon Nedir

Bir kayıt bir blok boyutundan daha uzunsa, bu alma süresinin çok daha uzun süreceği anlamına gelebilir çünkü artık kullanıcının istediği bilgilerin bir kısmı bir blokta, geri kalanı ise farklı bir blokta olabilir. diski geri almak önemli ölçüde daha fazla zaman alır. Yakın zamanda üzerinde çalıştığım bir Sevkiyat varlığı bu sorundan muzdaripti. Çok fazla sayıda veri öğesi içeriyordu ve bu nedenle çapraz veritabanı blokları çok verimsiz bir tasarıma neden oluyordu.

Çok fazla gereksiz veriyle karşılaşabilirsiniz. MÜŞTERİ SOYADI veri öğesinin 30 karakter olduğunu varsayalım. Bu veri öğesini üç kez tekrarlamak, artık 30 karakter yerine 90 karakter kullandığımız anlamına gelir. Az sayıda kayda sahip bir tabloda veya oldukça kısa uzunlukta yinelenen veri öğelerine sahip bir tabloda, bu fazladan depolama alanı önemli olmayacaktır.

Ancak milyonlarca satır içeren tablolarda her karakter megabaytlarca ek alan gerektirebilir. Örneğin, müşteri gibi veri ambarı olgu tablolarımızda ve büyük boyut tablolarımızda, normalleştirmeyi önemli ölçüde boşa harcayabiliriz. Alan nispeten ucuz olabilse de ve giderek daha ucuz hale geliyor olsa da, ucuz olan pek çok şey birdenbire oldukça pahalı hale gelebilir.

Anlayış eksikliğini maskeleyebilir. Denormalizasyonun performans ve depolama etkileri veritabanına ve teknolojiye çok özeldir. Bununla birlikte, bir tasarımdaki veri öğelerini tam olarak anlamamak, potansiyel olarak çok daha kötü sonuçları olan, daha çok işlevsel ve işle ilgili bir sorundur. Önce normalleşmeden asla normalleşmemeliyiz.

Bu yazı dizimizin önceki kısımlarında bahsedildiği gibi normalleştirdiğimizde, veri öğeleri arasındaki ilişkileri daha iyi anlarız. Nerede denormalize olacağımızı bilmek için bu anlayışa ihtiyacımız var.

Normalleştirmenin zirvesine ulaşmadan doğrudan denormalize edilmiş bir tasarıma gidersek, üretime geçtikten hemen sonra sistemin tamamen yeniden yazılmasını gerektirebilecek çok kötü tasarım kararları verebiliriz. Bir keresinde, tüm tasarım için tüm veri öğelerinin tek bir tabloya denormalize edildiği bir çevrimiçi telefon rehberi tasarımını inceledim. Yüzeyde, tablo oldukça doğru bir birincil anahtar gibi görünüyordu.

Ancak, çevrimiçi telefon rehberi tasarımıyla ilgili belirli sorularla tasarımcıyı sorgulamaya başladık:

■■ Ya bir çalışanın iki ev telefonu numarası varsa?
■■ Aynı çalışan için birden fazla e-posta adresini nasıl saklayabiliriz?
■■ İki çalışan aynı iş telefon numarasını paylaşabilir mi?

Tasarımcıdan boş bir bakış aldıktan sonra, Normalleştirme Yürüyüşü çabasına girmeden önce denormalizasyonun uygulandığını ve bu nedenle veri öğeleri arasındaki ilişkilerde önemli bir anlayış eksikliği olduğunu fark ettik. Veri kalitesi sorunlarına neden olabilir.

Uygulamalarımız içindeki verileri karıştırmak için her zaman fırsatlar vardır. Tasarım sırasında, “Mantıksal Veri Analizi” olarak adlandırılan Veri Kalitesi Yakalama Şablonu ve Veri Kalitesi Doğrulama Şablonu ile belirli veri kalitesi sorunlarının önüne geçebiliriz. Ancak tasarımımızda aynı veri öğesini birden çok kez kullanarak, veri kalitesi sorunlarına yönelik fırsatları önemli ölçüde artırıyoruz.

Bob’un ilk adını güncellersek, ilk adını MÜŞTERİNİN İLK ADI veri öğesinin her üç oluşumunda da güncellememiz gerekir. Bu üç MÜŞTERİNİN İLK ADI değerinden ikisinde adını Robert olarak güncellersek, bir veri kalitesi sorunu yaratmış oluruz.

Bu üç MÜŞTERİNİN İLK ADI değeri arasındaki değerlerde tutarsızlıklara yol açabilecek, bazen ortaya çıkan donanım, ağ ve yazılım durumları her zaman vardır.

Uygulamanın büyümesini engelleyebilir. Denormalize ettiğimizde, yeni gereksinimleri karşılamak için yapıları geliştirmek zorlaşabilir. Müşteri varlığına yeni bir müşteri verisi öğesi eklersek, muhtemelen bunu nispeten zahmetsizce ekleyebilir ve kısa süre sonra onu bilgilerle doldurmaya başlayabiliriz.

Bununla birlikte, Müşteri, gördüğümüz gibi, Satınalma varlığına denormalize edildiyse, yeni bir müşteri verisi öğesi eklemek çok daha karmaşık hale gelir. MÜŞTERİ AYAKKABI BEDENİ veri öğesini Satınalma varlığına eklediğimizi varsayalım.

Bu veri öğesini her bir müşteri adı için doğru şekilde doldurduğumuzdan emin olmalıyız, böylece veri kalitesi sorunları risklerini ve geçerli bir yapı elde etmek için manuel müdahale ihtiyacını artırmalıyız. Yeni gereksinimler eklemek için önemli miktarda fazladan çaba harcayan denormalize yapılar, insanları bir uygulamayı genişletmekten alıkoyabilir ve böylece potansiyelini sınırlayabilir.

Düşük performans, çok fazla artıklık, anlayış eksikliği, daha fazla veri kalitesi sorunu ve gelecekteki büyüme üzerinde getirilen sınırlamalar gibi bu çok büyük risklerle, denormalizasyon kararlarını çok “seçici bir şekilde” almamız gerekiyor. Denormalize etmemiz gereken her fırsatın artılarını ve eksilerini tam olarak anlamamız gerekiyor.

Denormalization çok önemli bir araç haline geldiği yer burasıdır. Denormalizasyon Hayatta Kalma Kılavuzu, doğru denormalizasyon kararlarını vermemize yardımcı olacak, böylece tasarımlarımız zamana karşı dayanıklı olacak ve bu kasvetli durumların ortaya çıkma ihtimalini en aza indirecektir.