Yakın zamanda veri dünyasının tanınan isimlerinden SeattleDataGuy, şirketlerin modern veri ambarlarını incelerken dehşet verici bir tabloyla karşılaştığını yazdı: Veri modelleme konsepti unutulmaya yüz tutmuştu.​Bulut teknolojilerinin sunduğu "Sonsuz Depolama" ve "Devasa İşlem Gücü", mimari disiplini zayıflattı. ORM araçlarının otomatik oluşturduğu "Spagetti Veri" yığınları, temel tasarım prensiplerini unutturmuş durumda.​Peki, sistem çöktüğünde veya analitik sorgular saatler sürmeye başladığında o kaçtığımız temellere dönmek zorunda kalmıyor muyuz? Gelin, veri mühendisliğinin sarsılmaz iki kalesini; Normalizasyon ve Denormalizasyonu, yüksek teknolojili devasa bir Lojistik Merkezi üzerinden inceleyelim.<img src="https://ezycourse.b-cdn.net/6009/cmobtpzdacb49v3qsd315cpgt.png" alt="image" containerstyle="width: 100%; height: auto; cursor: pointer; " wrapperstyle="display: flex"><h3 id="0b5ee0a4-8f13-4b5d-bb1d-a91970c0536a" data-toc-id="0b5ee0a4-8f13-4b5d-bb1d-a91970c0536a" style="font-size: 20px; line-height: 1.2;">​1. Normalizasyon: "Sıfır Hata" Deposu ve Mimari Savunma Hattı (OLTP)</h3>​Fütüristik bir e-ticaret deposu hayal edin. Bu depoda her bir vidanın, pilin veya kablonun milimetrik bir koordinatı vardır. Hiçbir parça iki farklı yerde bulunmaz.​İşte Normalizasyon (Normalization), veriyi tablolar arasında tekrar etmeyecek şekilde parçalara bölme ve Veri Anomalilerini (Data Anomalies) engelleme sanatıdır. Veritabanının bu "Sıfır Hata" deposunda kurallar kesindir:<ul><li>​1NF (First Normal Form) - Atomik Düzen: Her raf hücresinde tek bir ürün durur. Veri dünyasında bir project_id sütununa "101, 105, 108" gibi virgülle ayrılmış (array) veriler yazamazsınız. Yazarsanız, ileride o veriyi parse etmeden hiçbir rapor çekemezsiniz. Her hücre tek ve net bir gerçekliği yansıtmalıdır.</li><li>​2NF &amp; 3NF - Bağımlılıkların Reddi: Bir ürünün fiyat etiketi sadece "Fiyatlar" rafında değişir. Eğer Kullanici_Kurs tablosuna Kullanici_Adi bilgisini eklerseniz, kullanıcı adını değiştirdiğinde binlerce satırı güncellemek zorunda kalırsınız (Update Anomaly). Altın kural basittir: Anahtar olmayan her özellik, sadece ve sadece birincil anahtara (Primary Key) tam bağımlı olmalıdır.</li></ul>​Sonuç: Bu depo mükemmel bir tutarlılığa sahiptir. Bir kullanıcı silindiğinde, referans bütünlüğü (Referential Integrity) sayesinde açıkta kalan (orphan) veri olmaz. Ancak müşteri "Laptop, Çanta ve Mouse" seti sipariş ettiğinde, robotların 3 farklı koridora gidip veriyi birleştirmesi (JOIN işlemi) gerekir. Günlük operasyon sistemlerinde (OLTP) bu durum kabul edilebilirdir, çünkü yazma hızı ve veri doğruluğu her şeydir.<h3 id="f66c1aec-13be-4734-88c7-abfb7555ee0d" data-toc-id="f66c1aec-13be-4734-88c7-abfb7555ee0d" style="font-size: 20px; line-height: 1.2;">2. Denormalizasyon: "Hazır Paketler" ve Analitik Otoyolu (OLAP)</h3>​Eğer depo mükemmel kurgulandıysa, neden modeli bozalım? Çünkü yöneticiniz sizden "Son 5 yılın en çok satan 3'lü kombinasyonlarının bölgesel dağılımını" 2 saniye içinde getirmenizi istediğinde, 15 farklı rafı birbirine bağlayan SQL JOIN'leri veritabanınızı felç edecektir.​İşte burada deponun "Kampanya - Hızlı Gönderim" bandına geçiyoruz. Burada Denormalizasyon devreye girer. Bu bir mimari hata değil, stratejik bir hız tavizidir:<ul><li>​Boyutsal Modelleme (Dimensional Modeling) &amp; Kimball: Yöneticilerin hızla rapor alabilmesi için veriyi önceden birleştiririz. Ortada devasa bir Fact (Olay) tablosu dururken, etrafını Dimension (Boyut) tablolarıyla sararız (Star Schema). Müşteri bilgisi bilerek tekrar edilir, çünkü amaç o anki siparişi saniyeler içinde okumaktır (Read-Heavy).</li><li>​One Big Table (OBT): Modern dünyada (BigQuery, Snowflake gibi), JOIN maliyetini tamamen sıfırlamak için bazen her şeyi "Tek Bir Devasa Kutuya" doldururuz.</li></ul>​Risk: Eğer o "Hazır Paketlerin" içindeki pillerden biri hatalı üretildiyse, binlerce kutuyu açıp güncellemek tam bir kabustur. Bu yüzden Denormalizasyon yaptığımız Veri Ambarlarında (Data Warehouse), dönüşüm (dbt vs.) yaparken sıkı Veri Kalitesi Testleri (Data Quality Checks) kurgulamak zorundayız.<h3 id="2d2401f3-f370-4430-815f-947b61b71294" data-toc-id="2d2401f3-f370-4430-815f-947b61b71294" style="font-size: 20px; line-height: 1.2;">TVT Perspektifi: İki Dünyanın Dengesi</h3>​"Sınırsız sunucu gücümüz var, tasarıma gerek yok" demek bir mühendislik vizyonu değildir.​İyi bir Veri Mühendisi; operasyonel veritabanını (OLTP) tasarlarken anomalilerden kaçınmak için bir cerrah titizliğiyle Normalize eder. Ancak aynı mühendis, analitik tarafa (OLAP) veri taşırken şirket zekasının akıcı çalışması için stratejik olarak veriyi Denormalize eder.​👇 Söz Sırası Sizde!Kendi projelerinizde ağırlıklı olarak Kimball (Star Schema) yaklaşımını mı kullanıyorsunuz, yoksa One Big Table (OBT) yaklaşımı mı hızınızı daha çok artırıyor? Yorumlarda mimarileri çarpıştıralım!​#DataEngineering #DataModeling #ModernDataStack #DataArchitecture #StarSchema #OLAP #OLTPKaynak: https://seattledataguy.substack.com/p/normalization-vs-denormalization

Yakın zamanda veri dünyasının tanınan isimlerinden SeattleDataGuy, şirketlerin modern veri ambarlarını incelerken dehşet verici bir tabloyla karşılaştığını yazdı.

Veri Modelleme Öldü Mü? Sonsuz İşlem Gücü Çağında Normalizasyon ve Denormalizasyon İkilemi

​1. Normalizasyon: "Sıfır Hata" Deposu ve Mimari Savunma Hattı (OLTP)

2. Denormalizasyon: "Hazır Paketler" ve Analitik Otoyolu (OLAP)

Read articles, tips, and resources to help you learn, grow, and succeed. Explore our latest posts covering education, community, and personal growth

Blog – Insights, Tips & Resources for Learning and Growth

Explore articles, tips, and insights to help you succeed in learning, community building, and personal development.

Veri Modelleme Öldü Mü? Sonsuz İşlem Gücü Çağında Normalizasyon ve Denormalizasyon İkilemi

Veri Modelleme Öldü Mü? Sonsuz İşlem Gücü Çağında Normalizasyon ve Denormalizasyon İkilemi

Related Posts

Fabrication #11 : REST API'lar ile Fabric Yönetimi

Fabrication #10 : Fabric App Nedir?

Fabrication #9 : Notebook Yasak, Dataflow Serbest

H-Azure Bilgi #1 : Shared Responsibility Model Nedir?