Raporu kim çizer, veriyi kim hazırlar?
Power BI, Tableau, Looker Studio gibi araçlar grafiği çizer; ama doğru, temiz ve tutarlı veriyi hazırlamak çoğu zaman SQL'in işidir. İyi bir BI veri hazırlığının adımları:
- Tanecik (grain) seç: Bir satır neyi temsil edecek? Sipariş mi, sipariş satırı mı, gün mü? Her şey buna göre şekillenir.
- Olgu (fact) görünümü: Ölçülebilir değerler (adet, tutar) ve boyutlara bağlanan anahtarlar.
- Boyutlar (dimension): Müşteri, ürün, tarih. Okunur adlar, NULL yerine “Bilinmiyor”.
- İş kuralları tek yerde: “Net ciro” tanımı her raporda ayrı formülle değil, görünümde bir kez yazılır.
CREATE VIEW v_satis AS
SELECT oi.item_id,
o.order_id,
o.order_date,
o.channel,
o.status,
o.customer_id,
oi.product_id,
oi.quantity,
ROUND(oi.quantity * oi.unit_price * (1 - oi.discount), 2) AS net_tutar
FROM order_items oi
JOIN orders o ON o.order_id = oi.order_id;
SELECT channel, ROUND(SUM(net_tutar), 0) AS ciro
FROM v_satis
WHERE status = 'delivered'
GROUP BY channel;
Import mu, DirectQuery mi?Power BI veriyi kendi belleğine alırsa (import) raporlar hızlıdır ama veri yenileme zamanına kadar eskidir. DirectQuery her tıklamada veritabanına sorgu gönderir; bu durumda görünümlerin ve indekslerin performansı doğrudan kullanıcı deneyimidir.
Yıldız şema
BI modelinin ortasında olgu tablosu, çevresinde boyutlar durur (yıldız şema). Ayrıntılar Veri Modelleme dersinde; burada SQL tarafında yapılacakları gördük.
| Kural | Neden? |
|---|---|
| Boyut anahtarları tekil olsun | Yoksa BI aracı ilişkide satırları çoğaltır. |
| Tarih için ayrı takvim tablosu | Zaman zekâsı (YTD, geçen yıl) hesapları bunu ister. |
| Hesaplanmış oranları olgu tablosuna yazma | Oranlar toplanamaz; pay ve paydayı ayrı ver, oranı araç hesaplasın. |
| Sütun adlarını işin diliyle ver | Raporu kullanan kişi col_17 değil “Net Tutar” görmeli. |