Veri Ambarı Tasarımı: ERP ve e-Ticaret Analitiği için Yıldız Şeması

ERP veritabanınız sipariş ekleme, envanteri güncelleme, ödemeleri işleme gibi işlemler için optimize edilmiştir. E-Ticaret platformunuz, ürün sayfalarını sunmak ve ödemeleri işlemek için optimize edilmiştir. Her ikisi de iş kararlarını yönlendiren soruları yanıtlamak için optimize edilmemiştir: İadelerden sonra hangi ürün kategorileri en karlıdır? Hangi müşteri segmentleri artan yaşam boyu değere sahip? Tedarik zincirimizdeki darboğazlar nerede?

Bu boşluk veri ambarının doldurduğu boşluktur. Yıldız şeması ise analitik sorguları hızlı, sezgisel ve sürdürülebilir hale getiren tasarım modelidir.

Önemli Çıkarımlar

• Yıldız şeması, iş metriklerini (gerçekleri) açıklayıcı bağlamdan (boyutlar) ayırarak sorguları sezgisel ve hızlı hale getirir
• ERP ve e-Ticaret analitiği, temel iş sorularını karşılamak için genellikle dört ila altı olgu tablosuna ve sekiz ila on iki boyut tablosuna ihtiyaç duyar
• ETL işlem hatları, tüm verileri yeniden işlemeden geçmiş analizleri gerçekleştirmek için yavaş yavaş değişen boyutlara sahip artımlı yükleme kullanmalıdır
• İyi tasarlanmış bir yıldız şeması, normalleştirilmiş operasyonel veritabanlarının doğrudan sorgulanmasına kıyasla sorgu karmaşıklığını yüzde 60 ila 80 oranında azaltır

---

Neden ERP'yi Doğrudan Sorgulamıyorsunuz?

Ayrı bir veri ambarına yatırım yapmadan önce birçok şirket operasyonel veritabanlarında analitik sorgular çalıştırmayı dener. Bu üç nedenden dolayı başarısız olur.

Performans. Analitik sorgular milyonlarca satırı tarar, toplamaları hesaplar ve birçok tabloyu birleştirir. Bunları üretim veritabanında çalıştırmak her kullanıcı için ERP'yi yavaşlatır. Altı aylık sipariş verilerini tarayan bir rapor, tabloları kilitleyebilir ve Shopify mağazanızdaki ödeme performansını düşürebilir.

Karmaşıklık. Operasyonel veritabanları normalleştirilmiştir; veri fazlalığını en aza indirecek şekilde tasarlanmıştır. "Aylara göre ürün kategorisine göre toplam gelir" gibi basit bir soru, Odoo'nun PostgreSQL veritabanındaki sekiz tablonun birleştirilmesini gerektirebilir. Yıldız şemasında aynı sorgu iki tabloyu birleştirir.

Geçmiş. İşletim sistemleri verilerin üzerine yazar. Bir müşteri adresini değiştirdiğinde eski adres kaybolur. Bir ürün yeniden kategorize edildiğinde geçmiş raporlar geriye dönük olarak değişir. Bir veri ambarı, yavaş yavaş değişen boyutlar aracılığıyla geçmişi korur.

Çoklu kaynak. Orta ölçekli şirketler genellikle iş verilerini içeren üç ila yedi sistemi çalıştırır. Veri ambarı bunların hepsini birleştirir. ERP verileri için ETL işlem hatları kılavuzumuz, çıkarma ve yükleme işlemlerini ayrıntılı olarak kapsar.

---

Yıldız Şemasının Temelleri

Yıldız şeması, verileri iki tür tablo halinde düzenler: olgu tabloları ve boyut tabloları. Bilgi tabloları merkezde (yıldızın gövdesi) bulunur ve boyut tabloları onları (yıldızın noktaları) çevreler.

Bilgi Tabloları

Gerçek tabloları ölçülebilir iş olaylarını, yani olup bitenleri saklar. Her satır, en düşük anlamlı grendeki bir olayı temsil eder.

Özellikler:

• Sayısal ölçüler içerir (miktar, miktar, süre, sayım)
• Boyut tablolarına yabancı anahtarlar içerir
• Genellikle depodaki en büyük masalardır
• Yeni olaylar meydana geldikçe sürekli olarak büyüyün
• İşle ilgili soruları destekleyen en iyi düzeyde olmalıdır

Boyut Tabloları

Boyut tabloları açıklayıcı bağlamı (iş olaylarının kim, ne, nerede, ne zaman ve nasıl) depolar.

Özellikler:

• Metinsel nitelikleri ve hiyerarşileri içerir
• Nispeten küçüktürler (milyarlarca değil, binlerce ila milyonlarca satır)
• Zamanla yavaşça değiştirin
• Sorgu basitliği için normalleştirilmemiştir
• Raporlar için etiketleri, filtreleri ve gruplamaları sağlayın

Yıldız Şekli

                    Dim: Customer
                         |
    Dim: Product ---  Fact: Sales  --- Dim: Time
                         |
                    Dim: Location

"Ürün kategorisine göre bölgeye göre çeyreklere göre toplam gelir" gibi bir sorgu, satış verileri tablosunu üç boyutlu tablolarla birleştirir. Alt sorgular yok, karmaşık iç içe birleştirmeler yok; yalnızca basit yıldız birleştirmeler var.

---

ERP ve e-Ticaret için Bilgi Tabloları Tasarlama

Odoo ERP ve Shopify e-Ticaret çalıştıran tipik bir orta ölçekli şirketin, temel analitik kullanım durumlarını kapsayacak dört ila altı olgu tablosuna ihtiyacı vardır.

Gerçek: Satışlar

Satış verileri tablosu temel taşıdır. Her satır, satış siparişindeki bir satır öğesini temsil eder.

Tahıl: Sipariş satırı öğesi başına günde bir satır.

Gerçek: Envanter

Envanter seviyelerini olaylar yerine periyodik anlık görüntüler olarak izler.

Tahıl: Depo başına ürün başına günde bir satır.

Gerçek: Üretim

Üretim şirketleri için üretim olgusu iş emirlerini takip eder.

Tahıl: İş emri başına, ürün başına, günde bir satır.

Ek Bilgi Tabloları

• Gerçek: Satın almalar --- satıcıya, ürüne ve zamana göre satın alma harcaması.
• Gerçek: Destek Bildirimleri --- çağrı hacmi, yanıt süresi, temsilciye, müşteriye ve kategoriye göre çözüm süresi.
• Gerçek: Web Trafiği --- sayfa görüntülemeleri, oturumlar, sayfaya, kaynağa ve kampanyaya göre dönüşümler. Pazarlama ilişkilendirme analizi için kullanışlıdır.

---

Boyut Tablolarını Tasarlama

Boyut tabloları, olgu tablosu sayılarını anlamlı kılan bağlamı sağlar. Temel prensip denormalizasyondur; sorguları basitleştirmek için gereksiz verileri depolamaktır.

Loş: Zaman

Zaman boyutu her yıldız şemasında mevcuttur. Sorgularda karmaşık tarih işlevlerini önlemek için takvim niteliklerini önceden hesaplayın.

Dim: Müşteri

CRM, muhasebe ve e-Ticaret sistemlerinden gelen müşteri özelliklerini tek bir boyutta normalleştirmeyin.

rfm_segment ve lifetime_value_tier sütunları, ETL ardışık düzeni tarafından periyodik olarak güncellenen, RFM analizinden türetilen hesaplanmış alanlardır.

Loş: Ürün

---

Yavaş Yavaş Değişen Boyutlar

Bir müşteri New York'tan Londra'ya taşındığında veri ambarı ne yapmalıdır? Cevap iş sorusuna bağlıdır.

Tip 1: Üzerine Yaz

Eski değeri yeni değerle değiştirin. Müşterinin şehri Londra olur ve tüm geçmiş siparişler artık Londra'yı gösterir. Özelliğin geçmiş doğruluğunun önemli olmadığı durumlarda bunu kullanın.

Tür 2: Yeni Satır Ekle

Müşteri için yeni şehri, geçerlilik tarihini ve son kullanma tarihini içeren yeni bir satır oluşturun. Geçmişteki siparişler hâlâ eski sırayı (New York) işaret ediyor, yeni siparişler ise yeni sırayı (Londra) gösteriyor. Bu, analizi etkileyen nitelikler (müşteri segmenti, çalışan departmanı, ürün kategorisi) için en yaygın yaklaşımdır.

Tip 3: Yeni Sütun Ekle

Hem eski hem de yeni değerleri ayrı sütunlarda saklayın. Öncesini ve sonrasını karşılaştırmanız gerektiğinde ancak tam geçmişe ihtiyacınız olmadığında kullanışlıdır. Uygulamada daha az yaygındır.

Orta ölçekli şirketler için müşteri segmenti, çalışan departmanı, ürün kategorisi ve coğrafi özellikler için Tip 2'yi kullanın. Depoyu basit tutmak için diğer her şey için Tip 1'i kullanın.

---

ETL Tasarım Desenleri

ETL (Çıkarma, Dönüştürme, Yükleme) işlemi, verileri kaynak sistemlerden depoya taşır. ERP ve e-Ticaret verileri için iyi çalışan tasarım modelleri aşağıdakileri içerir.

Artımlı Yükleme

Her çalıştırmada tüm verileri yeniden yüklemek yerine, başarıyla yüklenen son zaman damgasını izleyin ve yalnızca o zamandan bu yana değiştirilen kayıtları işleyin. Odoo'nun write_date alanı ve Shopify'ın updated_at parametresi bunu kolaylaştırır.

1. Query source: SELECT * FROM sale_order_line WHERE write_date > last_load_timestamp
2. Transform: Map source fields to warehouse columns, look up dimension keys
3. Load: INSERT new rows, UPDATE changed rows (upsert)
4. Update: Set last_load_timestamp to current run start time

Vekil Anahtar Yönetimi

Boyut tabloları, doğal anahtarlar (Odoo kimlikleri, Shopify kimlikleri) yerine yedek anahtarlar (otomatik olarak artan tamsayılar) kullanır. Bu, depoyu kaynak sistem anahtar formatlarından ayırır ve farklı sistemlerin çakışan kimlik şemalarına sahip olduğu çoklu kaynak birleştirmeyi yönetir.

Geç Gelen Boyutlar

Bazen ilgili boyut kaydından önce bir olgu kaydı gelir; bir sipariş, henüz senkronize edilmemiş yeni bir müşteriye atıfta bulunur. Bunu, tam boyut kaydı geldiğinde güncellenen yer tutucu boyut satırıyla halledin.

Planlamayı Yenile

Gerçek zamanlı gereksinimler için akış analitiği kılavuzumuza bakın.

---

Sorgu Performansı Optimizasyonu

İyi tasarlanmış bir yıldız şeması, basit birleştirme desenleri nedeniyle zaten iyi performans göstermektedir. Ek optimizasyonlar aşağıdakileri içerir.

Dizinler. Olgu tablolarındaki tüm boyut yabancı anahtarlarında ve yaygın olarak filtrelenen boyut niteliklerinde (tarih aralıkları, müşteri segmentleri, ürün kategorileri) dizinler oluşturun.

Gerçekleştirilmiş görünümler. Yaygın sorguları önceden toplayın: ürün kategorisine göre günlük gelir, depoya göre haftalık envanter seviyeleri, kanala göre aylık müşteri kazanımı. Her ETL yüklemesinden sonra gerçekleştirilmiş görünümleri yenileyin.

Bölümlendirme. Büyük olgu tablolarını tarihe göre (aylık veya üç aylık) bölümlendirin. Tarih aralığına göre filtreleyen sorgular yalnızca ilgili bölümleri tarar.

Sütun istatistikleri. Sorgu planlayıcının en uygun kararları vermesi için PostgreSQL istatistiklerini toplu yüklemelerden sonra ANALYZE ile güncel tutun.

Bu optimizasyonlar, iş kullanıcılarının performans kaygısı olmadan anlık sorgular çalıştırdığı self servis BI deneyimini destekler.

---

Sıkça Sorulan Sorular

Veri ambarını haklı çıkarmak için şirketin ne kadar büyük olması gerekiyor?

Minimum boyut yoktur ancak analiz için birleştirilmesi gereken birden fazla veri kaynağınız olduğunda, operasyonel veritabanı sorguları üretim sistemlerini yavaşlattığında veya manuel veri toplama ve rapor oluşturmaya haftada 10 saatten fazla zaman harcadığınızda yatırım değerli hale gelir. 30 veya daha fazla çalışanı ve en az iki sistemi (ERP artı e-Ticaret) olan çoğu şirket bir depodan yararlanır.

Snowflake veya BigQuery gibi bir bulut veri ambarı kullanmalı mıyız?

Orta ölçekli şirketler için PostgreSQL analitik iş yüklerinin çoğunu iyi bir şekilde yönetir ve maliyeti önemli ölçüde daha düşüktür. Snowflake gibi bulut ambarları, verileriniz 1 TB'yi aştığında, maliyet optimizasyonu için bilgi işlemi depolamadan ayırmanız gerektiğinde veya kuruluşlar arasında karmaşık veri paylaşımı gereksinimleriniz olduğunda cazip hale gelir. PostgreSQL ile başlayın ve büyüyünce geçiş yapın.

Bir veri ambarı oluşturmak ne kadar sürer?

Bir olgu tablosu (satış), dört boyut tablosu ve Odoo ile Shopify'ı birbirine bağlayan bir ETL hattı içeren minimum uygulanabilir bir depo, deneyimli bir ekip için dört ila sekiz hafta sürer. Gerçek tabloların eklenmesi, yavaş yavaş değişen boyutlar ve veri kalitesinin izlenmesi, olgu tablosu başına dört ila sekiz hafta daha sürer. Tüm önemli iş alanlarını kapsayan kapsamlı bir depo için üç ila altı aylık bir plan yapın.

---

Sırada Ne Var

İyi tasarlanmış bir yıldız şeması, self servis kontrol panellerinden tahmin modellerine ve yerleşik analizlere kadar her analiz yeteneğinin temelidir. Şirketinizin karar verme şeklini dönüştüren daha geniş bir BI stratejisinin parçasıdır.

ECOSIRE, Odoo, Shopify ve GoHighLevel çalıştıran şirketler için veri ambarları ve analiz hatları oluşturur. Odoo danışmanlık ekibimiz, iş modelinize göre uyarlanmış depo şemaları tasarlar ve en üstte, OpenClaw AI hizmetlerimiz katman tahmine dayalı analizlerimiz tasarlar.

Veri ambarı mimariniz hakkında görüşmek için bize ulaşın.

---

ECOSIRE tarafından yayınlandı --- işletmelerin Odoo ERP, Shopify eCommerce ve OpenClaw AI genelinde yapay zeka destekli çözümlerle ölçeklenmesine yardımcı oluyor.