Vaka Çalışması · Perakende
Derimod veri ambarı: AX, Excel ve CRM'den tek analitik veritabanına
Derimod'un her şeyinin üzerine oturduğu katman. AX ERP'nin işlem seviyesindeki verisini, ekiplerin Excel'lerini ve CRM'i SQL Server üzerinde tek bir analitik veritabanında birleştirdik: şema ve adlandırma standardı, prosedür kayıt ve log mekanizması, SSIS ile günlük akış, partition switch ile kesintisiz yükleme, RowHash ile delta tespiti. Dashboard'lar da Optail de bu ambardan besleniyor.
- 3
- Kaynak sistem
- 7
- Şema
- Switch
- Yükleme
- RowHash
- Delta
AX, Excel, CRM — tek modele
Departman bazlı; her projenin yeri belli
Staging'de hazırla, tek hamlede tak; rapor kilitlenmez
Yalnızca değişen kayıt alt süreçlere akar
Problem
Derimod’da veri AX’ın veritabanında, işlem seviyesinde duruyordu: her satış fişi, her stok hareketi, her transfer emri. Üzerine bir karar sistemi kurmak için bu veri önce daha sade bir mimariye taşınmalıydı. Ekiplerin bütçe, plan, kapasite ve kural bilgisi ise Excel’de; müşteri verisi CRM’deydi. Üç kaynağın “satış” dediği şey aynı değildi, aynı ürün üç sistemde üç kodla duruyordu.
Ağustos 2023’te işe bu katmanla başladık; Optail de dashboard’lar da bekledi.
Kurallar önce
İlk doküman bir tablo tasarımı değil, bir düzen dokümanıydı. Analitik ve DevAnalitik diye iki veritabanı — biri canlı, biri Lumtify’ın geliştirme ve test alanı. Projeler ve veri departman şemalarıyla ayrıldı: alokasyon, planlama, mağazacılık, e-ticaret, lojistik merkezi, tedarik zinciri, staging. Bir transfer projesinin tablosu alokasyon şemasında durur; kimin verisi olduğu adından okunur.
| Kural | Karar |
|---|---|
| Tablo adı | Önek yok, alt çizgi yok; her kelimenin ilk harfi büyük: ReplenishmentParametre |
| Kolon | Türkçe karakter yok, boşluk yok; Unicode gerekmiyorsa varchar, gerekiyorsa nvarchar; MAX yerine gereken uzunluk |
| Prosedür / view | sp ve vw öneki; her prosedür spList tablosuna kaydedilir — ne işe yaradığı, ne zaman yazıldığı |
| Log | Her prosedür adımlarını spLog’a yazar: hangi adım, ne zaman — bir gecelik akış yavaşladığında hangi adımda yavaşladığı belli |
Bu kurallar üç yıl sonra da geçerli; Derimod’un kendi ekibinin yazdığı prosedürler de aynı listede.
Akış
SSIS paketleri kaynaklardan veriyi düzenli aralıklarla alır, staging’e yükler, doğrular ve ana tablolara taşır. Veri doğrulaması Derimod’un bilgi işlem, planlama ve iş zekâsı ekipleriyle birlikte yapıldı: ambarın ürettiği satış rakamı, ekiplerin güvendiği rakamla eşleşene kadar tablo “bitmiş” sayılmadı.
İki tasarım kararı zamanla belirleyici oldu.
Partition switch. Satış ve stok gün bazında bölümlenmiş durumda. Yeni gün staging’de hazırlanır, ana tabloya ALTER TABLE … SWITCH ile takılır — metadata işlemi, milisaniyeler. Yükleme sırasında raporlar kilitlenmez, sabah dashboard’lar açıldığında veri hazırdır.
RowHash ile delta. Switch ile ezme yapıldığı için Change Tracking ve CDC devre dışı kalır. Bunun yerine her satırda iş kolonlarından hesaplanan, kalıcı (persisted) bir RowHash kolonu var; hash, bulk yükleme sırasında hesaplanır, ayrıca maliyet açmaz. Staging ile canlı tablo yalnızca (anahtar, RowHash) çifti üzerinden karşılaştırılır — dar bir indeks, geniş satırlara inmeden. Değişen ve yeni kayıtlar delta tablosuna düşer; Optail’in ve dashboard’ların alt süreçleri yalnızca bu deltayı işler. Tarih ve ondalık kolonlar sabit formata çevrilerek hash’lenir; aksi hâlde aynı değer farklı hash üretip sahte değişiklik doğurur.
Excel içeride. Ekiplerin yıllardır Excel’de tuttuğu plan ve kural bilgisini yok saymak yerine tanımlı bir formatla ambara bağladık. Master plan, hariç tutulacak ürün listeleri, mağaza grupları — hepsi Excel’den gelir, tabloya oturur, Optail’in girdisi olur.
Mimarideki kritik kararları Microsoft ile de danışarak doğruladık. Bu tarz yapılarda “çalışıyor” ile “üç yıl sonra da çalışıyor” arasındaki farkı bu kararlar belirliyor.
Üzerine ne kuruldu
Ambar iki şeyi besliyor: 20’den fazla Power BI dashboard’u ve Optail’in senaryo tabloları. Optail’in kendi veritabanı — baz veriler, senaryo, parametre ve sonuç tabloları — ambardan okur; her senaryo benzersiz bir kimlikle girdisini ve çıktısını saklar, geçmiş bir senaryonun hangi parametrelerle çalıştığı yıllar sonra da görülebilir. 2025’te CRM ve kampanya datamart’ı da aynı ambara eklendi.
Neden böyle
- Standart, tablodan önce gelir. Adlandırma ve şema kuralı ilk hafta konmasaydı üçüncü yılda kimin tablosunun ne olduğu bilinmezdi.
- Delta ucuz olmalı. Hash’i yükleme maliyetine gömmek, her gece tüm tabloyu karşılaştırmaktan hem hızlı hem güvenli.
- Kaynak değişince ambar emer. AX’ta bir alan değiştiğinde dashboard’lar ve Optail bunu bilmez; değişikliği ambar katmanı karşılar.