Karmaşık JOIN yoğunluğunu azaltmak için view kullanırsınız – performans roketler! Sürekli hesaplanan metrikleri önceden kolon olarak ekleyebilirsiniz (quarterlyRevenue, inventoryValue)–soru-cevap sürecini hızlandırırsınız. Lakin dikkat edin; fazla abartırsanız yönetilmez bir veri modeliyle uğraşırsınız sonra...

Veritabanına Akıllı Soru Sorabilen AI: Data API Builder MCP ile Güvenli Analiz Dönemi -

⏱️ 5 dk okuma📅 25 Mart 2026

Şu Soru: “Verime Nasıl Soru Sorarım?”

Bak şimdi, Doğruya doğru, SQL bilmek hâlâ neredeyse her IT işinin jokeri. Ama kabul edelim; herkes için pek parlak gelmiyor bu dünya. Hele son yıllarda yapay zekâ ajanları (AI agents) piyasaya daldı ya… işler tam arapsaçı olabiliyor. Ufak bir hata, veritabanının canına okur – misal SQL injection patladı mı geçmiş olsun! Neyse ki Microsoft’un Data API Builder’ı (DAB) ve MCP (Managed Control Plane) desteği devreye girdi de azıcık içimiz rahatladı. Şimdi rahatça “Geçen yıl en çok ciro yapan müşterim kim?” diye sorabiliyoruz, hem de arka planda çıplak SQL kodlarıyla boğuşmadan.

Geçen ay Logosoft’ta bulut geçişinde koca finans firmasının başında aynısını yaşadık: Bir yerde deli gibi pivotlar lazım, öbür tarafta düz topla çıkar işleri… Eskiden bunların her biri için ayrı endpointler açmak gerekirdi; stored procedure manyağı olurduk resmen! Şimdi ise doğal dilde sormak ve cevabını almak gerçekten başka bir seviye konfor getirdi diyebilirim.

DAB MCP Ne Yapar? Bildiğiniz API, Ama Çift Katman Güvenlikle

Peki bu MCP ne işe yarıyor derseniz… DAB’in 1.7 ile beraber gelen MCP desteği sayesinde hayalini kurduğumuz “Ajanlar veriye erişsin. Ben patron olayım” senaryosu gerçek oldu diyebilirim. Ajanınıza beş ana işlem tanımlıyorsunuz: Create, Read, Update, Delete (yani klasik CRUD), üstüne Aggregate eklenmiş (toplama vs.). Tüm işlemler MCP ile soyutlanıyor — token penceresi dolup taşmadan işinizi görebiliyorsunuz.

Artık AI ajanlarının veritabanına ulaşırken denetimli ve güvenli hareket etmesi masal değil; NL2SQL dönemi bitiyor gibi—rastgele yazılmış SQL injection’lara da veda.

2019’da ufak sunucularımda aynı kafayla GraphQL denemiştim mesela ama şu anki DAB’in güvenlik yaklaşımı oradan fersah fersah ötede duruyor. Rol tabanlı yetkilendirme (RBAC), özel politika tanımlarını istediğin kadar detaylandır… Siz izin vermedikçe bırak sorguyu çalıştırmayı – tabloyu uzaktan koklatamazsın bile ajana!

Neden Ham SQL Yerine Soyut Sorgu?

Bunu özellikle vurgulamak istiyorum çünkü NLP’den çıkan NL2SQL mantığı hep içimi gıcıklamıştır açıkçası! Arada garip prompt girilirse… hani birazcık şanssızsanız ortalık karışır.

💡 Bilgi: DAB’in sorgu motoru istekleri tamamen soyut biçimde alıyor; yani entity, function, field, filter parametreleriyle oynanıyor sadece—kimsenin gelip random string manipülasyonu yapıp veri tabanınızı yakma ihtimali kalmıyor.

Aklıma geçen yıl Azure OpenAI’de yaptığımız testlerden biri geldi — GPT-4o öyle acayip bir NL2SQL prompt’u çıkardı ki canlıya verseydik muhtemelen felaket yaşardık! Tam zamanında fark ettik… İşte DAB’in soyut sorgu yaklaşımı sayesinde bu tarz facialar büyük oranda önleniyor.

Soruları Kolaylaştıran Özellikler

Kontekst Penceresi Ekonomisi: Büyük dil modellerinde hep başımızın belasıdır şu token sınırı mevzusu… DAB burada işi küçücük komut setine indiriyor — daha fazla fonksiyonelliği aynı limitte barındırabiliyorsunuz yani.
Açık Yetki Tanımı: Hangi ajan hangi tabloya bakacak—tamamen sizin elinizde kontrol butonu var!
Tam Deterministik Sonuçlar: Aynı input giriyorsunuz, aynı output geliyor – sürpriz yok!

Karmaşık Agregasyonlarda Denormalizasyon Şart mı?

Burası baya önemli! Kaç yıldır DBA’lık yapıyorum—kesinlikle her durumda denormalizasyon zorunlu demek saçmalığın daniskası olur. Bazen performans için mecbur kalıyoruz tabii… Bazen parçalara bölmektense tek tabloda bırakmak kolaylık oluyor ama abartınca da yönetilmeyecek hale gelebiliyor şema yapısı. Bu konuyla ilgili VS Code ile SQL Şema Yönetimi Artık Akıcı: Yayı… yazımıza da göz atmanızı tavsiye ederim. ABD Devletine Açılan Sır Kapısı: Azure Top Secr… yazımızda bu konuya da değinmiştik.

Birkaç ay evvel AskınKilic.com.tr’ye mini bir demo hazırlarken yüzde yüz normalize şema kullandım. Aggregate fonksiyonlarını rahatça yürüttüm. Lakin işler büyüyüp JOIN çorbasına sarınca örneğin aylık cirolar hesabında view eklemek hayat kurtardı diyebilirim… Bu konuyla ilgili VS Code’da MSSQL Eklentisinde Neler Değişti? Ya… yazımıza da göz atmanızı tavsiye ederim.

Peki Ne İşe Yarar?

Karmaşık JOIN yoğunluğunu azaltmak için view kullanırsınız – performans roketler!
Sürekli hesaplanan metrikleri önceden kolon olarak ekleyebilirsiniz (quarterlyRevenue, inventoryValue)–soru-cevap sürecini hızlandırırsınız.
Lakin dikkat edin; fazla abartırsanız yönetilmez bir veri modeliyle uğraşırsınız sonra…

Küçük Bir Taktik Notu:

Eğer peşi sıra benzer rapor ihtiyaçları doğuyorsa mutlaka ilgili view veya materialized view hazırlayın derim—model daha sadeleşir ve sistem gereksiz yere kasılmaz. Logosoft’taki e-ticaret projelerinde böyle uygulattığımızda gözle görülür şekilde hız aldığımız oldu mesela.

“En Değerli Müşterim Kim?” — Gerçek Bir Sorgu Hikayesi

Dürüst olmak gerekirse, Sade konuşacağım—herkesin kulağına gelmiştir bu soru kesinlikle:“Geçtiğimiz yıl boyunca en çok gelir bırakan aktif müşteri hangisi?” Bunu direkt cevaplamak zordur. Filtre gruplama vs., normalde upuzun query yazar durursunuz… VS Code’da SQL Kod Analizi Artık Daha Kolay: Ku… yazımızda bu konuya da değinmiştik.

{
"entity": "CustomerSales",
"function": "sum",
"field": "totalRevenue",
"filter": "isActive eq true and orderDate ge 2025-01-01",
"groupby": ["customerId", "customerName"],
"orderby": "desc",
"first": 1
}

DAB buradan yürüyüp size deterministic olarak şöyle pırıl pırıl sonuç çıkarıyor:

SELECT customerId, customerName, SUM(totalRevenue) AS sum_totalRevenue
FROM CustomerSales
WHERE isActive = 1 AND orderDate >= '2025-01-01'
GROUP BY customerId, customerName
ORDER BY SUM(totalRevenue) DESC
LIMIT 1;

Böylesi aggregate sorular için eskiden iki hafta geliştirme döngüsü isterdik—şimdi ise birkaç saniye bekleyince sonuç geliyor!

Eh, Bunu atlamayın — ekstra analizlere gerek duyarsanız dinamik filtreyi çat diye ekleyebilirsiniz (“Sadece İstanbul’daki müşteriler” tipi şeyler). Böyle esnekliği klasik REST API endpointlerinde görmek çoğu zaman imkânsız olurdu doğrusu.

“Devreden Ürün Hangisi Olsun?” — Pratik Bir Karar Sorusu Daha!

Şöyle ki, Açık konuşmam gerekirse beni en şaşırtanlardan biri de şu tarz otomasyon senaryoları oldu; “Hangi aktif ürünümüz neredeyse hiç satmamış? Belki kataloğa elveda desek mi…” Yukarıdaki formatla buna direkt ulaşabiliyorsun bakın:

{
"entity": "ProductSales",
"function": "sum",
"field": "totalRevenue",
"filter": "isActive eq true and inStock gt 0 and orderDate ge 2025-01-01",
"groupby": ["productId", "productName"],
"orderby": "asc",
"first": 1
}

Bunu işletmelerde canlı ortamda ilk kez gösterdiğim an insanlarda oluşan şaşkınlığı tarif etmem zor… Çünkü vaktiyle haftalarca excel dosyası kovalamaca oynuyorduk bunun için! Şimdi model kendi buluyor iki dakika sonra öneriyi önüme koyuyor resmen…

💡 Bilgi: Benzer kontrolü Azure SQL DiskANN vektör indekslerinde gördüm (Azure SQL’de DiskANN Vektör İndeksleri üzerine notum burada). Orada da sistem dışarıya sadece izin verilen kadarını açıp geri kalan kısmı modelden gizliyordu.

Peki Dezavantaj Hiç Yok mu?

Soyut sorgulama bazen fazlaca sınırlandırıcı olabiliyor; bazı ekstrem durumlarda normalde tek satırlık çözümler MCP tarafında biraz dolambaçlı yol istiyor insandan … moral bozabilir başta!
MCP tool syntax öğrenmesi ilk etapta yorucu olabilir; junior arkadaşlar yeni başlamışsa kafalar karışabiliyor kısa süreyle de olsa… Zamanla alışılıyor yalnız onu söyleyeyim :)
Anlık değişen yetki ihtiyaçlarında RBAC güncellemek vakit alabilir; eğer ekip içinde sık rol değiştirmek gerekiyorsa süreç eski usule göre biraz hantallaşıyor ne yazık ki…

Kendimiz bizzat geçen Mart ayında telekom sektöründe bunu tecrübe ettik; yeni dashboard talebi çıktı ve REST+SQL yönteminde RBAC değişimini yapmak saatimizi aldı! O esnada politikayı elle açıp kapatarak workaround yaptık ama yine de aksadı süreç–bunu unutmayın derim.

Nihai Değerlendirme & Küçük İpuçları

DAB + MCP kombinasyonu risk almadan AI entegrasyonu sağlıyor – hele hassas kurum projelerinde veri korkusu yaşatmıyor artık desem yeridir!
Eğer bol bol analitik agent soruları üretiyorsanız tablo yapılarına extra view/precomputed field tanımlayın–performans uçacaktır emin olun.
Production’a atmadan önce mutlaka demo/test ortamında ajanlarla bolca oynayın – sonradan ağlamayın :)
MCP syntax’ının limitlerini iyice görünceye dek örnek datalar üzerinde çalışın–beklediğiniz kadar esnek çıkmayabilir bazen.

Bir göz atmak isteyenler için:
SQL Server’da JSON Depolama Yeniliklerine dair yazımı okuyabilirsiniz!

Kaynak: What questions will you ask your data agent?

Sıkça Sorulan Sorular

Data API Builder (DAB) nedir ve ne işe yarar?

DAB, veritabanlarına doğal dil veya API üzerinden güvenli ve soyut bir şekilde sorgu yapmanızı sağlayan bir Microsoft aracıdır. SQL yazmak zorunda kalmadan CRUD işlemlerini ve toplama fonksiyonlarını güvenle gerçekleştirebilirsiniz.

MCP desteği neden önemli?

MCP, yani Managed Control Plane, DAB’in güvenlik katmanını güçlendiriyor. AI ajanlarının veriye kontrollü erişmesini sağlıyor, yetkisiz sorguları engelliyor. Kendi deneyimime göre, özellikle büyük projelerde MCP sayesinde veri sızıntısı riskini büyük ölçüde azalttık.

Rol tabanlı yetkilendirme (RBAC) nasıl çalışıyor?

RBAC sayesinde her kullanıcı ya da AI ajanı için ayrı izinler tanımlayabiliyorsunuz. İsterseniz sadece veri okuma, isterseniz sadece belirli tablolara erişim verebilirsiniz. Bu, veritabanı güvenliğini sağlamada çok pratik bir yöntem.

NL2SQL neden yeterli değil?

NL2SQL bazen karmaşık veya hatalı sorgular üretebiliyor; bu da veritabanında risk oluşturuyor. DAB ise sorguları tamamen soyut katmanda işleyerek bu tür sorunları önlüyor. Kendi testlerimde de GPT tabanlı NL2SQL çözümlerinin bazen beklenmedik sonuçlar verdiğini gördüm.

DAB ile büyük dil modellerinin token sınırı nasıl aşılır?

DAB, sorguları küçük ve öz parametrelerle alarak token kullanımını minimize ediyor. Böylece daha karmaşık işlemleri bile token sınırı içinde rahatça yapabiliyorsunuz, bu da performans ve maliyet açısından büyük avantaj sağlıyor.