Ne zaman denormalize etmelisin?

Bence hepimiz veritabanı normalleştirmeye aşinayız .

Sorum şu: Tabloları denormalize etmek istediğinizde kullandığınız bazı kurallar nelerdir?

OLAP işlemleri olduğunda denormalize et, OLTP olduğunda normalize et (Denormalizasyon bölümü altındaki bağlantılı makaleden)

Çevrimiçi işlem gerçekleştirmeye yönelik veritabanları (OLTP), çevrimiçi analitik işlemeye (OLAP) yönelik veritabanlarından genellikle normalize edilir. OLTP uygulamaları, bir süpermarket kasa sayacında bir satış kaydının güncellenmesi gibi yüksek miktarda küçük işlemle karakterize edilir. Beklenti, her işlemin veritabanını tutarlı bir durumda bırakmasıdır. Buna karşılık, OLAP işlemlerine yönelik veritabanları öncelikle “çoğunlukla okunur” veritabanlarıdır. OLAP uygulamaları, uzun bir süre boyunca biriken geçmiş verileri çıkarma eğilimindedir. Bu tür veritabanları için fazlalık veya "denormalize" veriler iş zekası uygulamalarını kolaylaştırabilir. Spesifik olarak, bir yıldız şemasındaki boyutsal tablolar genellikle denormalize veri içerir. Denormalize veya gereksiz veriler, alma, dönüştürme, yükleme (ETL) işleme sırasında dikkatlice kontrol edilmeli ve kullanıcıların tutarlı bir duruma gelinceye kadar verileri görmelerine izin verilmemelidir. Yıldız şemalarına normalize edilmiş alternatif, kar tanesi şemasıdır. Çoğu durumda, bilgisayarlar ve RDBMS yazılımı daha güçlü hale geldikçe denormalizasyon ihtiyacı azalmıştır, ancak veri hacimleri genellikle donanım ve yazılım performansı ile birlikte arttığından, OLAP veritabanları genellikle denormalize şemalar kullanmaktadır.

Denormalizasyon, bilgisayarlı yazarkasalarda ve mobil cihazlarda olduğu gibi daha küçük bilgisayarlarda da performansı artırmak için kullanılır, çünkü bunlar yalnızca arama için verileri kullanabilir (örn. Fiyat aramaları). Denormalizasyon, bir platform için (Palm gibi) herhangi bir RDBMS olmadığında veya verilerde herhangi bir değişiklik yapılmaması durumunda ve hızlı bir yanıt için çok önemli olduğunda da kullanılabilir.

Acıyana kadar normalleştirin, çalışana kadar normalleştirin (yani: performans kabul edilebilir hale gelir) :)

Kontrollü denormalizasyon uygulamak için potansiyel olarak mantıklı bir sebep, aksi takdirde mümkün olmayacak olan verilere bazı bütünlük kısıtlamaları uygulamanıza olanak sağlamasıdır. Çoğu SQL DBMS'nin çoklu tablo kısıtlamaları için son derece sınırlı desteği vardır. SQL'de bazen belirli kısıtlamaları uygulamak için tek etkili yol, kısıtlamaya dahil olan özelliklerin aynı tabloda mevcut olmasını sağlamaktır - normalizasyon ayrı ayrı tablolara ait olduklarını belirlese bile.

Kontrollü denormalizasyon, gereksiz verilerden kaynaklanan tutarsızlıkların ortaya çıkmamasını sağlamak için mekanizmaların uygulanması anlamına gelir. Bu ekstra kontrollerin maliyeti ve tutarsız veri riski, denormalizasyonun faydalı olup olmadığına karar verirken göz önünde bulundurulmalıdır.

Denormalizasyonun diğer bir yaygın nedeni, depolama yapılarında bazı değişikliklere izin vermek veya DBMS'nin başka şekilde izin vermeyeceği başka fiziksel optimizasyonlara izin vermektir. Fiziksel Veri Bağımsızlığı ilkesine göre bir DBMS, veritabanındaki verilerin mantıksal gösterimini gereksiz yere değiştirmeden iç depolama yapılarını yapılandırma araçlarına sahip olmalıdır. Ne yazık ki, çoğu DBMS belirli bir veritabanı şeması için mevcut fiziksel uygulama seçeneklerinde çok kısıtlayıcıdır. İstenen mantıksal modelin yalnızca optimal alt bir uygulamasını destekleyerek fiziksel veri tabanının bağımsızlığını tehlikeye atma eğilimindedirler.

Açık olması gerekir, ancak yine de söylenmesi gerekir: Her durumda, yalnızca performansı belirleyebilecek fiziksel uygulama özelliklerinde yapılan değişiklikler - iç veri yapıları, dosyalar, indeksleme, donanım vb. Normalleştirme ve denormalizasyonun performans veya depolama optimizasyonu ile ilgisi yoktur.

Bu sorunun cevaplarında önerildiği gibi, hesaplanan verilere sıklıkla erişiyorsanız denormalize edin . Hesaplanan verilerin saklanması ve muhafaza edilmesinin maliyeti, yük profiliniz okuma ağır ise, genellikle tekrar tekrar hesaplamanın maliyetinden daha az olacaktır.

Veri bütünlüğünü kısıtlamalarla zorlayabilmem için rutin olarak normalleştiriyorum. Bir örnek, bu sitedeki son bir soru - Başka bir tablodaki bir sütunu çoğalttım, böylece başka bir sütuna karşılaştırmak için CHECK kısıtlaması kullanabilirim. Bu tekniğin bir başka örneği blog yazım .

Bu gibi işlevselliği skaler UDF'lere çağırdıysanız, bir CHECK kısıtlaması oluşturmadan farklı satırlardaki veya farklı tablolardaki sütunları karşılaştırmak için CHECK kısıtlamalarını kullanamazsınız. Bir iş kuralını uygulamak için gerçekte farklı satırlardaki veya farklı tablolardaki sütunları karşılaştırmanız gerekirse? Örneğin, bir doktorun çalışma saatlerini bildiğinizi ve tüm randevuların çalışma saatlerine uygun olduğundan emin olmak istediğinizi varsayalım. Elbette, bu işletme kuralını uygulamak için bir tetikleyici veya saklı yordam kullanabilirsiniz, ancak ne tetikleyici ne de saklı yordam, tüm verilerinizin temiz olduğu konusunda% 100 garanti veremez - birisi tetikleyicinizi devre dışı bırakabilir veya bırakabilir, kirli verileri kullanın ve tetikleyicinizi yeniden etkinleştirin veya yeniden oluşturun. Ayrıca birisi saklı yordamları atlayarak doğrudan tablonuzu değiştirebilir.

Bu iş kuralının yalnızca FK ve CHECK kısıtlamaları kullanılarak nasıl uygulanacağını göstereyim - bu, tüm kısıtlamalara güvenildiği sürece tüm verilerin iş kuralını yerine getirdiğini garanti eder.

Yine bir başka örnek, zaman aralıklarının boşluk ve örtüşme olmadığını zorlamanın bir yoludur .