POWER QUERY İLE VERİ TEMİZLEME STANDARDI: TEKRARLANABİLİR DÖNÜŞÜMLER

Power BI projelerinde en çok zaman kaybettiren işlerin başında veri temizleme gelir. Üstelik bu iş, bir kere yapılıp unutulan bir adım değildir: Kaynak dosyalar değişir, kolon isimleri kayar, veri tipleri bozulur, yeni satırlar gelir ve aynı dönüşümler tekrar tekrar gerekir.

İyi haber şu: Power Query ile veri temizleme işini “tek seferlik uğraş” olmaktan çıkarıp, tekrarlanabilir bir standart haline getirebilirsiniz. Böylece aynı veri seti her yenilendiğinde aynı kurallarla dönüştürülür; raporlar daha güvenilir olur, geliştirme süresi kısalır.

Bu makalede Power Query’de kurumsal ölçekte uygulanabilecek bir veri temizleme standardını; isimlendirme, katmanlı sorgu yapısı, M kodu pratikleri, performans ve test yaklaşımıyla birlikte ele alacağız.

Power Query’de Veri Temizleme Standardı Neden Kritik?

Kurumsal raporlama ortamında veri, tek bir kaynaktan gelmez. Excel dosyaları, SQL tabloları, API çıktıları, SharePoint listeleri ve farklı departmanların hazırladığı CSV’ler aynı modelin içinde birleşebilir. Bu ortamda “her seferinde elle düzeltmek” sürdürülebilir değildir.

Bir veri temizleme standardı; ekip içinde ortak bir dil oluşturur, aynı dönüşümlerin farklı raporlarda farklı biçimde uygulanmasını engeller. Ayrıca hataların kök nedenini izlemek kolaylaşır. Özellikle self-service BI ile merkezi BI ekibinin birlikte çalıştığı yapılarda standart, kaliteyi belirgin biçimde artırır.

Tekrarlanabilir dönüşümün somut faydaları

• Veri yenilendiğinde aynı kurallar otomatik uygulanır.
• Rapor yayınlama sürecinde sürpriz hatalar azalır.
• Yeni ekip üyeleri daha hızlı adapte olur.
• Geliştirme maliyeti düşer, bakım kolaylaşır.

Standart Tasarımının Temeli: Katmanlı Sorgu Yapısı

Power Query’de en yaygın hata, tüm dönüşümleri tek bir sorgu içinde biriktirmektir. Bu yaklaşım küçük dosyalarda çalışsa bile kurumsal ölçekte yönetilemez hale gelir. Bunun yerine katmanlı bir yapı kullanmak gerekir.

Pratikte üç katman çok işe yarar: Staging, Transform ve Model. Bu yapı, veri hazırlama sürecini hem okunabilir hem de test edilebilir hale getirir.

1) Staging (Ham veri katmanı)

Bu katmanda amaç sadece veriyi kaynaktan almak ve minimum müdahaleyle bir “ham tablo” üretmektir. Örneğin; dosya yolu, veri kaynağı bağlantısı, tablo seçimi gibi adımlar burada olur. Burada filtreleme ve kolon silme gibi işlemler bile mümkünse minimum tutulur.

2) Transform (Dönüşüm katmanı)

Asıl veri temizleme burada yapılır. Kolon adlandırma, tip dönüşümü, boş değer yönetimi, birleştirme, ayrıştırma, mapping tabloları ile zenginleştirme gibi adımlar bu katmanda yer alır.

3) Model (Modelleme katmanı)

Model katmanında hedef, raporun kullanacağı nihai tabloyu üretmektir. Bu tablo mümkün olduğunca “analize hazır” olmalı; ölçümler DAX ile, veri şekillendirme ise Power Query ile yapılmalıdır. Buradaki sorgular genellikle Enable Load açık olan sorgulardır.

İsimlendirme ve Adım Disiplini: Okunabilirlik Standardı

Power Query projelerinde sürdürülebilirliğin büyük kısmı isimlendirme disiplininden gelir. Bir raporu 6 ay sonra açtığınızda, hangi adımın ne yaptığını 30 saniyede anlamanız gerekir. Bu da hem sorgu adlarında hem de adım isimlerinde standart gerektirir.

Sorgu isimlendirme önerisi

Basit ama etkili bir yaklaşım: her katmanı prefix ile ayırmak.

1. stg_ : Ham veri sorguları
2. trn_ : Dönüşüm sorguları
3. dim_ / fact_ : Model katmanı tabloları
4. ref_ : Referans ve mapping tabloları

Adım isimlendirme standardı

Power Query otomatik olarak “Changed Type”, “Removed Columns” gibi adımlar üretir. Kurumsal projede bu adımlar mutlaka yeniden adlandırılmalıdır. Örneğin:

• Changed Type → Set_Data_Types
• Removed Columns → Keep_Required_Columns
• Filtered Rows → Filter_Valid_Records

Bu yaklaşım, hem ekip içinde ortak bir terminoloji oluşturur hem de M kodunu okurken anlamayı kolaylaştırır.

Veri Tipi ve Null Yönetimi: Kaliteyi Garanti Altına Almak

Veri temizleme standardının en kritik parçası, veri tipi yönetimidir. Özellikle Excel veya CSV gibi kaynaklarda “tarih” kolonunun bir gün metne dönmesi, tüm raporu kırabilir. Bu nedenle veri tiplerini en erken aşamada ve deterministik şekilde set etmek gerekir.

Aynı şekilde null ve boş değerler, hem modelde ilişkileri hem de ölçümleri etkiler. Burada hedef; null’ları rastgele 0 yapmak değil, iş kuralına uygun şekilde yönetmektir.

Örnek: Tip set etme ve null standardizasyonu (M kodu)

let
    Source = Excel.Workbook(File.Contents("C:\Data\Satis.xlsx"), null, true),
    Raw = Source{[Item="Satis",Kind="Table"]}[Data],

    KeepColumns = Table.SelectColumns(Raw, {"SiparisNo", "Tarih", "Musteri", "Tutar", "ParaBirimi"}),

    SetTypes = Table.TransformColumnTypes(
        KeepColumns,
        {
            {"SiparisNo", type text},
            {"Tarih", type date},
            {"Musteri", type text},
            {"Tutar", type number},
            {"ParaBirimi", type text}
        },
        "tr-TR"
    ),

    TrimText = Table.TransformColumns(SetTypes, {{"Musteri", Text.Trim, type text}, {"ParaBirimi", Text.Trim, type text}}),

    NormalizeCurrency = Table.ReplaceValue(TrimText, null, "TRY", Replacer.ReplaceValue, {"ParaBirimi"}),

    RemoveInvalidAmount = Table.SelectRows(NormalizeCurrency, each [Tutar] <> null and [Tutar] >= 0)
in
    RemoveInvalidAmount

Bu örnekte dikkat edilmesi gereken nokta, dönüşümlerin adım adım ve okunabilir biçimde ilerlemesidir. Ayrıca null yönetimi, iş kuralına göre belirlenmiştir: para birimi boşsa varsayılan TRY atanır, tutar boşsa kayıt elenir.

Tekrarlanabilir Dönüşüm İçin Şablon (Template) Yaklaşımı

Kurumsal ekiplerde en büyük verim artışı, aynı dönüşümlerin farklı projelerde tekrar kullanılabilmesiyle gelir. Power Query bu konuda çok güçlüdür: ortak dönüşümleri fonksiyon haline getirip, projeler arasında standartlaştırabilirsiniz.

Örneğin; kolon adlarını normalize eden, veri tiplerini set eden, tarih formatlarını düzenleyen veya referans tablosu ile eşleştirme yapan fonksiyonlar, tüm projelerde aynı şekilde çalışır.

Örnek: Kolon isimlerini standardize eden fonksiyon

// fn_NormalizeColumnName
(colName as text) as text =>
let
    Trimmed = Text.Trim(colName),
    Lowered = Text.Lower(Trimmed, "tr-TR"),
    ReplaceTurkish = Text.Replace(Text.Replace(Text.Replace(Text.Replace(Lowered, "ı", "i"), "ğ", "g"), "ş", "s"), "ö", "o"),
    ReplaceSpaces = Text.Replace(ReplaceTurkish, " ", "_"),
    RemoveDouble = Text.Replace(ReplaceSpaces, "__", "_")
in
    RemoveDouble

Bu fonksiyon, farklı kaynaklardan gelen kolon adlarını daha tutarlı hale getirir. Böylece raporun kırılma riski azalır ve mapping tabloları ile çalışmak kolaylaşır.

Performans Standardı: Query Folding ve Doğru Adım Sırası

Power Query dönüşümlerinin performansı, özellikle büyük veri setlerinde kritik hale gelir. Burada ana kavram query folding’dir. Eğer veri kaynağı SQL Server gibi bir sistemse, Power Query adımlarının bir kısmı kaynağa “itilebilir” ve dönüşümler sunucu tarafında çalışır.

Ancak yanlış adım sırası veya folding’i bozan işlemler, tüm verinin Power BI’a çekilmesine neden olabilir. Bu da hem yenileme süresini uzatır hem de gateway kaynaklarını tüketir.

Folding’i korumak için pratik kurallar

• Filtreleme adımlarını mümkün olduğunca erken yapın.
• Gereksiz kolonları erken aşamada çıkarın.
• Custom Column gibi hesaplamaları minimumda tutun.
• Merge işlemlerini referans tabloları ile kontrollü kullanın.
• Dosya tabanlı kaynaklarda gereksiz “Change Type” tekrarlarından kaçının.

Özellikle SQL tabanlı projelerde, Power Query Editor’de “View Native Query” seçeneği kapanıyorsa folding bozulmuş demektir. Bu kontrol, standardın bir parçası olmalıdır.

Veri Kalite Kontrolü: Hata Yakalama ve İzlenebilirlik

Standart dönüşüm sadece “temizlemek” değildir; aynı zamanda veri kalitesini ölçmek ve hataları erken yakalamaktır. Kurumsal raporlamada en büyük risk, yanlış verinin doğru gibi görünmesidir.

Bu nedenle veri hazırlama sürecinde belirli kontrol kolonları üretmek, tutarsız kayıtları işaretlemek ve gerekirse ayrı bir “quality log” tablosu üretmek iyi bir pratiktir.

Kalite kontrolü için uygulanabilir kontroller

• Zorunlu kolonlarda null var mı?
• Tarih aralığı mantıklı mı (gelecek tarih, çok eski tarih)?
• Negatif tutar veya sıra dışı değerler var mı?
• Referans tablosunda karşılığı olmayan kayıtlar bulunuyor mu?

Bu kontroller, hem raporun güvenilirliğini artırır hem de veri sahibine hızlı geri bildirim vermeyi sağlar. Böylece rapor ekibi “veri temizleme ekibi” rolüne sıkışmaz.

Dokümantasyon Standardı: Power Query Projesini Yaşatmak

Bir Power Query standardının kalıcı olabilmesi için dokümantasyon şarttır. Dokümantasyon, uzun uzun metin yazmak değildir; kritik kararların ve iş kurallarının kaybolmamasıdır.

Minimum dokümantasyon standardı şunları kapsamalıdır:

• Veri kaynağı ve bağlantı bilgisi (kimin sorumluluğunda?)
• Temel dönüşüm kuralları (ör. para birimi boşsa TRY)
• Mapping tabloları ve referans kaynakları
• Performans notları (folding durumu, büyük tablolar)

Ekip içinde standardı yaygınlaştırmak

Bu noktada eğitim ve ortak pratikler devreye girer. Eğer ekip içinde Power Query seviyeleri farklıysa, standart kağıt üzerinde kalır. Bu yüzden dönüşüm şablonlarını, fonksiyon yaklaşımını ve performans prensiplerini ekipçe öğrenmek önemlidir.

Bu konuda daha sistemli ilerlemek isterseniz Power Query & Power Pivot eğitimi içeriği, dönüşüm standardını kurumsal projelere uygulama perspektifiyle ele alır.

Örnek Uygulama Akışı: Bir Raporu Standartla Nasıl Kurarsınız?

Konuyu somutlaştırmak için örnek bir kurulum akışı düşünelim. Amaç; satış verisi, müşteri listesi ve ürün kartını birleştirip modele almak olsun.

Önerilen adım planı

1. stg_Satis, stg_Musteri, stg_Urun sorgularını oluşturun.
2. Her staging sorgusunda sadece kaynaktan okuma yapın.
3. trn_Satis içinde kolon seçimi, tip set etme, null yönetimi uygulayın.
4. trn_Satis içinde müşteri ve ürün eşleştirmelerini yapın.
5. dim_Musteri, dim_Urun ve fact_Satis tablolarını Model katmanında üretin.
6. Kalite kontrolü için ref_KaliteLog gibi bir tablo hazırlayın.

Bu akış, ilk başta daha fazla iş gibi görünür. Fakat 3 ay sonra veri kaynağı değiştiğinde veya yeni bir rapor eklendiğinde, sağladığı hız farkı dramatik olur.

Sonuç: Standart Olmadan Ölçeklenmez

Power Query, tek kullanıcı için harika bir veri hazırlama aracı olduğu kadar, doğru yaklaşımla kurumsal ölçekte de çok güçlü bir ETL katmanı olabilir. Bunun için temel şart; veri temizleme işini kişisel alışkanlıklardan çıkarıp, ekip standardı haline getirmektir.

Katmanlı sorgu yapısı, isimlendirme disiplini, tip ve null yönetimi, M fonksiyon şablonları, query folding odaklı performans kuralları ve kalite kontrolleri bir araya geldiğinde, Power BI projeleriniz daha hızlı, daha güvenilir ve daha sürdürülebilir olur.

Bu standardı bir kez kurduğunuzda, her yeni rapor bir “yeniden icat” süreci olmaktan çıkar; aynı omurganın üstüne eklenen bir yapı haline gelir.