Normalize mi Denormalize mi? Tablo Tasarımında Tutarlılık ile Okuma Hızı Dengesi

Ortak zemin: aynı veri, iki farklı yerleşim

Normalizasyon ve denormalizasyon aynı soruya verilen iki yanıttır: bir bilgi veritabanında kaç yerde durmalı? Microsoft'un normalizasyon açıklaması, normalizasyonu verileri koruyacak ve veritabanını daha esnek kılacak kurallara göre tablolar oluşturup aralarında ilişki kurmak olarak tanımlar; amaç tekrarı ve tutarsız bağımlılığı ortadan kaldırmaktır. Tekrarlanan veri disk alanı harcar ve bakım sorunu yaratır: birden fazla yerde duran bir bilgi değiştiğinde, her yerde tam olarak aynı biçimde değiştirilmesi gerekir.

Denormalizasyon bu ilkenin bilinçli bir istisnasıdır. Power BI'ın yıldız şema rehberi farkı somut bir örnekle anlatır: satış tablosu ürünü yalnız ürün anahtarıyla tutuyorsa normalizedir; ürün anahtarının yanında kategori, renk ve beden gibi ürün bilgilerini de tutuyorsa denormalizedir.

İkisi arasında seçim yapmak, bir ödünleşimi yönetmektir. Normalize tasarım yazmayı ve tutarlılığı kolaylaştırır, ama okurken tabloları birleştirmeyi gerektirir. Denormalize tasarım okumayı kolaylaştırır, ama aynı bilginin her kopyasını güncel tutma yükünü getirir.

Ölçüt ölçüt iki yaklaşım

• Ölçüt: Tekrar. Normalizasyon: her bilgi tek yerde; tekrar en aza indirilir. / Denormalizasyon: seçilen bilgiler birden fazla yerde ya da önceden hesaplanmış olarak tutulur.
• Ölçüt: Yazma. Normalizasyon: güncelleme tek yerde yapılır, basittir. / Denormalizasyon: güncelleme tüm kopyalara yayılmalıdır; tetikleyici, uygulama kodu ya da yenileme işi gerekir.
• Ölçüt: Okuma. Normalizasyon: ilişkili bilgiyi görmek için tablolar birleştirilir. / Denormalizasyon: sık kullanılan bilgi tek tablodan okunur.
• Ölçüt: Tutarlılık riski. Normalizasyon: düşük; aynı bilginin çelişen iki kopyası olmaz. / Denormalizasyon: kopyalar senkron tutulmazsa güncelleme anomalisi doğar.
• Ölçüt: Depolama. Normalizasyon: daha az alan. / Denormalizasyon: tekrar nedeniyle daha fazla alan.
• Ölçüt: Tipik yer. Normalizasyon: işlem sistemleri, sık ve dağınık yazılan veriler. / Denormalizasyon: raporlama tabloları, analitik modeller, çok sık okunan ekranlar.
• Ölçüt: Değişime uyum. Normalizasyon: yeni bir ilişki ya da alan eklemek kolaydır. / Denormalizasyon: her yapısal değişiklik kopyaları da etkiler.

Microsoft'un notu, gerçek hayatın her zaman tam uyuma izin vermediğini de kabul eder: tüm alan bağımlılıklarını ortadan kaldırmak için çok sayıda küçük tablo oluşturmak teoride doğrudur, ama performansı düşürebilir. Notun önerisi, ilk üç kuraldan birini çiğnemeye karar verirseniz uygulamanın tekrar ve tutarsız bağımlılık gibi sorunları önceden hesaba katmasıdır.

Denormalizasyonun yaygın biçimleri

Denormalizasyon tek bir teknik değil, birkaç farklı karardır. Tablo tasarımında en sık karşılaşılanlar şunlardır:

• Tekrarlanan sütun: sık birlikte okunan bir bilgiyi ilişkili tablodan kopyalamak; örneğin sipariş listesinde gösterilen müşteri adını sipariş tablosunda da tutmak.
• Türetilmiş ya da hesaplanmış alan: her okumada yeniden hesaplanan bir değeri saklamak; örneğin bir ürünün yorum sayısını ürün tablosunda tutmak.
• Özet tablo: ayrıntılı kayıtlardan önceden hesaplanmış toplamları ayrı bir tabloda tutmak; örneğin günlük satış özeti.
• Tabloları birleştirmek: hiyerarşik olarak ayrılmış tabloları tek tabloda toplamak; örneğin kategori, alt kategori ve ürünü tek bir ürün tablosunda tutmak. Power BI rehberi bunu, kar tanesi boyutunu tek bir model tablosunda birleştirmek olarak anlatır ve faydasının genellikle daha ağır bastığını, bedelinin ise büyük boyut tablolarında artan depolama olduğunu belirtir.
• Veritabanı motorunun sunduğu materyalize görünüm ve benzeri yapılar: tutarlılık işini motora bırakarak sorgu sonucunu saklamak.

Son madde önemlidir: aynı okuma kazancını, kopyaları elle yönetmeden sağlayan bir araç varsa, çoğu zaman önce o denenmelidir.

Karar akışı: önce normalize et, sonra ölç

Denormalizasyon kararı, tasarımın başında değil, kanıt oluştuğunda verilmelidir. Sağlıklı akış birbirinin üzerine kurulan adımlardan oluşur.

İlk adımda tasarım normalize edilir. Varlıklar, anahtarlar ve ilişkiler netleşir; Microsoft notunun ifadesiyle çoğu uygulama için üçüncü normal form gereken en yüksek düzey sayılır.

Ardından gerçek sorgular ölçülür. Hangi ekran ya da rapor yavaş, sorgu planında zaman nereye gidiyor? Çoğu yavaşlık eksik indeks ya da kötü yazılmış sorgudan kaynaklanır; bunlar tasarımı bozmadan çözülebilir.

Sonra, ancak indeks ve sorgu iyileştirmesi yetmiyorsa, darboğazı oluşturan noktaya özel ve seçici bir denormalizasyon yapılır. Tüm şemayı değil, ölçülmüş sorunu hedefler.

Son adımda kopyaların tutarlılığı güvenceye alınır: hangi kaynağın asıl olduğu yazılır, kopyayı güncelleyen mekanizma belirlenir ve kopya ile kaynak arasındaki farkı yakalayan bir kontrol kurulur.

Örnek: bir e-ticaret yönetim panelinde sipariş listesi her açılışta müşteri, adres ve kargo tablolarını birleştiriyor ve yoğun saatlerde yavaşlıyor. Ekip önce eksik indeksleri ekler, sorguyu sadeleştirir. Liste hâlâ yavaşsa, yalnız listede gösterilen müşteri adını sipariş tablosuna kopyalar ve müşteri adı değiştiğinde bu kopyayı güncelleyen mekanizmayı aynı değişiklikte kurar.

Hangi durumda hangisi?

Tek bir doğru yanıt yoktur; tablonun nasıl kullanıldığı belirler.

• Veri sık ve farklı kaynaklardan yazılıyorsa, tutarlılık kritikse normalizasyon ağır basar. Müşteri, stok ve hesap kayıtları gibi verilerde tek doğru kaynak vazgeçilmezdir.
• Veri az değişiyor ama çok sık okunuyorsa, denormalizasyon makul bir adaydır. Kategori adları, il listeleri ya da nadiren değişen ürün özellikleri buna örnektir.
• Tablo raporlama ya da analiz içinse, denormalize boyut tabloları yaygın ve önerilen bir yoldur. Microsoft'un çevrim içi analitik işleme belgesi, analitik sistemlerin geleneksel normalizasyon yerine genellikle yıldız ya da kar tanesi şeması kullandığını belirtir.
• Bilgi zamana bağlıysa, kopya değil tarihsel kayıt söz konusudur. Siparişteki o anki fiyat ya da teslimat adresi, kaynakla senkron tutulmamalıdır; aksine kaynak değiştiğinde de değişmemelidir.

Sık yapılan hatalar

• Ölçmeden denormalize etmek. "Birleştirme yavaştır" varsayımıyla baştan kopya alanlar eklemek, ileride hiç ihtiyaç duyulmayacak bir tutarlılık yükü yaratır.
• Güncelleme mekanizmasını sonraya bırakmak. Kopya alan eklenip onu güncel tutan tetikleyici, uygulama kodu ya da yenileme işi kurulmazsa ilk değişiklikte veri çelişir.
• Asıl kaynağı belirsiz bırakmak. İki yerde duran bilginin hangisinin doğru kabul edileceği yazılmazsa, çelişki çıktığında karar verilemez.
• Tarihsel kaydı senkron tutmaya çalışmak. Siparişteki fiyatı ürün fiyatı değişince güncellemek, geçmiş siparişlerin tutarını bozar.
• Analitik modeli işlem tablosunun kopyası gibi tasarlamak. Rapor için kurulan model, işlem sisteminin normalize yapısını aynen taşırsa raporlar gereksiz karmaşıklaşır; Power BI rehberi bu durumda boyut ve olgu tablolarına ayrılmış bir yıldız şemayı önerir.

Mindset programlarında nerede çalışılır?

Veritabanı tasarımcıları, yazılım geliştiriciler ve veri modelleme uzmanları için bu karar, şema tasarımının ve performans çalışmasının kesiştiği yerdedir. Veritabanı Tasarımı ve Normalizasyon eğitimi normalizasyon formlarını, bütünlük kısıtlarını ve denormalizasyonun performans ödünleşimini ayrı modüllerde ele alır. Analitik model tarafında Boyutsal Modelleme ve Kimball Metodolojisi eğitimi olgu ve boyut tablolarının tasarımını işler.