Veritabanına Akıllı Soru Sorabilen AI: Data API Builder MCP ile Güvenli Analiz Dönemi
Ş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 işe 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 öldü diyebilirim. Ajanınıza beş ana işlem tanımlıyorsunuz: Create, Read, Update, Delete (yanı 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 dürüyor. Rol tabanlı yetkilendirme (RBAC), özel politika tanımlarını istediğin kadar detaylandır… Sız izin vermedikçe bırak sorguyu çalıştırmayı – tabloyu uzaktan koklatamazsın bile ajana!
Data API Builder (DAB) ve MCP desteğiyle, yapay zekâ ajanlarının veritabanına doğal dille güvenli şekilde erişmesini sağlayan “ham SQL’den soyut sorguya” geçişi karşılaştırır.
| Özellik | Konu: DAB + MCP yaklaşımı |
|---|---|
| Giriş yöntemi | Doğal dil ile soru; arka planda soyut sorgu yönetimi |
| Güvenlik | RBAC + politika kontrolleri; izin yoksa sorgu çalıştırılmaz |
| Sorgu riski | Random SQL string manipülasyonu azalır; SQL injection yüzeyi düşer |
| İşlem modeli | CRUD + Aggregate; ajan için denetimli “5 ana işlem” akışı |
Not: Amaç, ajanların “veriye erişmesini” kontrol altına alıp denetimli analiz deneyimini otomatikleştirmek.
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.
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 yanı.
- 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 tabiî… Bazen parçalara bölmektense tek tabloda bırakmak kolaylık oluyor ama abartınca da yönetilmeyecek hâle gelebiliyor şema yapısı.
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…
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 öldü mesela.
“En Değerli Müşterim Kim?” — Gerçek Bir Sorgu Hikâyesi
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…
{
"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 işe 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ı öldü; “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…
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 önü 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 böl böl 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.
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, yanı 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 işe 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.
Kaynaklar ve İleri Okuma
Microsoft Data API Builder Resmî Dokümantasyonu
Azure Blog: Data API Builder Genel Kullanıma Sunuldu
Data API Builder GitHub Deposu
Azure Managed Control Plane (MCP) Hakkında Bilgi
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
