Semantic layer; fiziksel veri modellerinin üzerinde iş kavramlarını, metrik formüllerini, boyutları, varlıkları, zaman kurallarını, ilişki yollarını ve erişim politikalarını tanımlar. BI aracı veya dashboard değildir; farklı rapor, uygulama ve AI istemcilerinin aynı onaylı iş anlamını kullanmasını sağlar. Başarısı araç kurulumundan çok metrik sahipliği, grain, join, zaman, para birimi, sürüm ve performans kurallarının açık yönetilmesine bağlıdır.
Semantic layer ortak iş anlamını veri tüketim araçlarından ayırır
Aynı gelir metriği bir dashboard’da fatura tarihine, başka bir raporda sipariş tarihine; birinde KDV dahil, diğerinde hariç hesaplanabilir. Sorun yalnız SQL farklılığı değildir; iş tanımı, zaman, grain ve ilişki kuralları ortak yönetilmemektedir. Semantic layer bu kuralları merkezi ve makine tarafından sorgulanabilir bir modelde tutar.
İş terimleri
Müşteri, sipariş, gelir ve ürün gibi varlıkları ortak dilde tanımlar.
Metrik formülleri
Ölçü, filtre, zaman ve para birimi kurallarını merkezileştirir.
Join ve grain
Tabloların hangi anahtar ve ayrıntı düzeyinde birleştirileceğini sınırlar.
BI, uygulama ve AI
Onaylı metrikleri farklı istemcilere ortak arayüzle sunar.
Katman metrik, boyut, entity ve zaman modelini birlikte taşır
| Bileşen | Örnek | Kritik karar |
|---|---|---|
| Entity | Müşteri, sipariş, ürün, kampanya | Tekil kimlik ve ilişki |
| Measure | Brüt satış, maliyet, adet | Grain ve agregasyon |
| Metric | Net gelir, dönüşüm, churn | Formül, filtre ve iş tanımı |
| Dimension | Tarih, ülke, kanal, segment | Geçerlilik ve hiyerarşi |
| Time spine | Gün, hafta, mali dönem | Zaman bölgesi ve dönem kuralı |
| Policy | Satır/alan erişimi | Rol, amaç ve hassasiyet |
Bir metriğin yalnız formülü değil; sahibi, açıklaması, grain’i, izin verilen boyutları, para birimi, varsayılan zaman penceresi, veri gecikmesi ve kalite durumu görünür olmalıdır.
Semantic layer veri ambarı veya dashboard yerine geçmez
Veri ambarı fiziksel ve mantıksal veri depolama/modelleme katmanıdır. BI semantic model belirli raporlama ekosistemi içinde ilişkiler, ölçüler ve güvenlik sağlar. Kurumsal semantic layer ise aynı metrik anlamını birden fazla BI aracı, notebook, uygulama veya AI istemcisine sunmayı hedefleyebilir. Kurumun mimarisine göre bu katmanlar aynı ürün içinde veya ayrı bileşenlerde bulunabilir.
| Katman | Temel görev | Tipik tüketici |
|---|---|---|
| Warehouse/lakehouse | Veriyi depolamak ve dönüştürmek | Data engineer ve analist |
| Semantic model | Belirli analitik modelde ilişki ve ölçü | BI raporu ve dashboard |
| Semantic layer | Ortak metrik ve iş anlamını servis etmek | BI, uygulama, API ve AI |
| Dashboard | Görsel karar yüzeyi | İş kullanıcısı ve yönetim |
Metrik tanımı formülden önce karar amacını açıklamalıdır
- Metrik hangi iş sorusunu cevaplıyor?
- Hangi entity ve grain üzerinde hesaplanıyor?
- Pay, payda, filtre ve dışlama kuralları neler?
- Olay tarihi mi, işlem tarihi mi, muhasebe tarihi mi kullanılıyor?
- İptal, iade, eksik kayıt ve geç gelen veri nasıl ele alınıyor?
- Para birimi ve kur dönüşümü hangi kaynaktan geliyor?
- Hangi boyutlarla güvenli biçimde dilimlenebilir?
- Veri ne kadar gecikmeli ve hangi kalite eşiğinde?
- Metrik sahibi ve değişiklik onaylayanı kim?
“Aktif müşteri” gibi kavramlar farklı amaçlarda farklı tanım gerektirebilir. Tek bir tanımı zorlamak yerine adlandırılmış ve açık amaçlı metrikler kullanılabilir: aylık işlem yapan müşteri, sözleşmesi aktif müşteri veya ürünü kullanan müşteri gibi.
Mimari hesaplama, yönetişim ve tüketim sınırlarını açıklaştırmalıdır
- Onaylı dönüşüm modellerini ve veri ürünlerini belirleyin.
- Entity, grain, primary key ve ilişki yollarını tanımlayın.
- Measure ve metric tanımlarını kod ve metadata ile yönetin.
- Zaman, para birimi ve yavaş değişen boyut kurallarını ekleyin.
- Erişim ve hassasiyet politikalarını uygulayın.
- Query engine, cache ve maliyet sınırlarını tasarlayın.
- BI, spreadsheet, notebook, API ve AI tüketicilerini bağlayın.
- Lineage, test, sözleşme ve sürüm bilgilerini yayımlayın.
Canlı sorgu ile önceden hesaplama arasında performans ve güncellik dengesi kurulmalıdır. Ortak metrik tanımı her sorgunun aynı fiziksel planla çalışması gerektiği anlamına gelmez.
Metrik değişikliği kod değişikliği kadar kontrollü olmalıdır
Bir metrik formülünün değiştirilmesi yönetim raporlarını, primleri, bütçeyi ve AI kararlarını etkileyebilir. Bu nedenle sahip, teknik uygulayıcı, onaylayıcı, versiyon, geçerlilik tarihi ve tüketici etkisi kaydedilmelidir.
| Değişiklik | Risk | Kontrol |
|---|---|---|
| Kolon veya veri tipi | Sorgu kırılması | Model/data contract ve test |
| Formül | Tarihsel karşılaştırma bozulması | Yeni metrik sürümü ve geçerlilik tarihi |
| Join yolu | Çift sayım | Grain ve cardinality testi |
| Boyut | Yanlış segment | Hiyerarşi ve referans veri onayı |
| Erişim | Hassas veri sızıntısı | Rol ve satır/alan politikası |
Senaryo: Net gelir üç farklı ekipte üç farklı hesaplanıyor
Finans faturayı, satış siparişi, büyüme ekibi tahsilatı esas alır. Semantic layer’da üç kullanım amacı ayrılır: muhasebe net geliri, ticari sipariş geliri ve tahsil edilmiş gelir. Her metrik kendi zaman alanı, iade kuralı, para birimi, sahibi ve gecikme bilgisini taşır. Yönetim dashboard’u hangi metriği neden kullandığını açıkça gösterir; AI asistanı da sorgu bağlamına uygun metriği seçmek için bu metadata’yı kullanır.
Semantic layer AI için kontrollü kurumsal bağlam sağlayabilir
Doğal dil sorgulama veya AI ajanı ham şema üzerinde çalıştığında benzer kolonları yanlış bağlayabilir, grain’i bozabilir veya onaysız metriği kullanabilir. Semantic layer onaylı entity, metric, dimension ve ilişki bilgisini sunarak sorgu alanını sınırlar. Yine de modelin doğru metriği seçtiği, filtreyi uyguladığı ve sonucu açıklayabildiği test edilmelidir.
- AI istemcisine yalnız onaylı ve yetkili metriklerin sunulması
- Metrik açıklaması ve kullanım örneklerinin makinece erişilebilir olması
- Sorgu planı ve kullanılan metrik sürümünün loglanması
- Hassas boyutların rol bazlı kapatılması
- Sonuçla kaynak metrik arasında izlenebilirlik
- Yanlış join ve çift sayım için test setleri
Başarı dashboard sayısıyla değil ortak anlamın kullanımıyla ölçülmelidir
| KPI | Sağlıklı gösterge | Yanlış yorum |
|---|---|---|
| Metrik yeniden kullanım | Onaylı metriği kullanan tüketici oranı | Tanımlı metrik sayısı |
| Tutarlılık | Aynı sorguda araçlar arası sonuç uyumu | Dashboardların benzer görünmesi |
| Değişiklik güveni | Etki analizi ve regresyon başarısı | Az değişiklik yapmak |
| Performans | P95 sorgu süresi ve birim maliyet | Yalnız cache hit oranı |
| Self-service | Uzman desteği olmadan doğru cevap oranı | Sorgu sayısı artışı |
Kaynaklar ve gözden geçirme notu
Bu rehberde değişebilir veya teknik iddialar için öncelikle resmî kurum, ürün geliştiricisi ve birincil araştırma kaynakları kullanılmıştır. Bağlantılar 27 Temmuz 2026 tarihinde gözden geçirilmiştir.
- 01dbt Developer Hub — dbt Semantic Layer
Metriklerin merkezi tanımlanması ve farklı veri tüketim araçlarında tutarlı kullanımı yaklaşımını açıklar.
- 02dbt Developer Hub — About MetricFlow
Metrik, boyut ve entity mantığının modellenmesi ve sorgulanmasını açıklar.
- 03Microsoft Learn — Power BI Semantic Models
Semantic modelin analitik alan, metrik, iş terimi, fact ve dimension ilişkilerini nasıl temsil ettiğini açıklar.
- 04Microsoft Learn — Semantic Models Across Workspaces
Onaylı semantic modellerin paylaşılması, sertifikasyonu ve erişim yönetişimini açıklar.
- 05dbt Developer Hub — Semantic Layer Integrations
Ortak metrik katmanının BI ve diğer tüketim araçlarına API/entegrasyonlarla sunulmasını açıklar.