Önceki yazıda row level security nedir ‘e giriş yapmış ve statik RLS’ye örnekler vermiştim. Bu yazıda da dinamik row level security ‘den bahsedeceğim.
Yazı İçeriği
Nasıl Kullanılır?
Dinamik row level security, genellikle bir yetkilendirme tablosuyla birlikte USERNAME ve/veya USERPRINCIPALNAME fonksiyonlarıyla kullanılıyor.
Bu iki fonksiyon kullanıcıadı@tenant adresi ve domain adı\kullanıcı adını döndürüyor.
Kullanıcı_USERNAME = USERNAME()
Kullanıcı_USERPRINCIPAL = USERPRINCIPALNAME()
Şöyle bir senaryo düşünelim: Ürün kategorilerinin satış müdürleri olsun, her satış müdürü sadece kendi satışını görsün. Modele aşağıdaki gibi bir yetkilendirme tablosu ekliyorum.
Bu tabloyu modeldeki diğer ilgili tabloyla hem ilişki kurarak ve hem de kurmadan kullanabiliriz!
İlişki Kurmadan Dinamik Row Level Security
Önce ilişki olmaksızın örneklendirelim.
“Ürün Kategorileri” tablosundaki kategori sütunu üzerinden bir rol yaratıp, kullanıcının kim olduğuna göre görmeye yetkisinin olduğu kategorileri döndürebiliriz.
Böyle bir rol filtresini yazmak için kullanabileceğimiz birden fazla fonksiyon var. Önceki yazıda örneklendirdiğim CONTAINSTRING kullanılabilir, LOOKUPVALUE olabilir, vs. Birkaç alternatife bakalım:
'Ürün Kategorileri'[Kategori]
IN
CALCULATETABLE (
VALUES ( 'Satış Müdürleri'[Kategori] ),
'Satış Müdürleri'[Satış Müdürü] = USERPRINCIPALNAME ()
)
* CALCULATETABLE, VALUES, IN operatörü ile ilgili yazılar için buradan.
Bütün espri, ürün kategorileri tablosundaki [Kategori] sütun değerlerinin, ilgili satış müdürünün yetkisinin olduğu kategorilerden gelmesini sağlamak.
Aynı mantığı LOOKUPVALUE ile de kurabiliriz.
'Ürün Kategorileri'[Kategori] =
LOOKUPVALUE (
'Satış Müdürleri'[Kategori],
'Satış Müdürleri'[Satış Müdürü], USERPRINCIPALNAME (),
'Satış Müdürleri'[Kategori], 'Ürün Kategorileri'[Kategori]
)
Bu şekilde bir mantıkla, yani fact tablosuna doğru ilişkisi olan ürün kategorileri tablosu üzerinde filtre yarattığımızda, ilgili filtre satışlar tablosuna kadar akar.
İlişki Kurarak Dinamik Row Level Security
Şimdiyse yetki tablosunu modelle ilişkilendirerek örnekleyelim.
Örnek olarak verdiğim yetki tablosunda her bir kategoriden sadece tek bir satış müdürü sorumlu ama gerçek hayatta aynı kategoriye bakan birden fazla satış sorumlusu olabilir. Bu yüzden ilişkiyi one-to-many şeklinde kurdum. Buradaki anahtar detay, ilişkinin çift yönlü olması ve role verdiğimiz filtrenin her iki yönlü uygulanmasını sağlamak.
Satış müdürleri tablosundaki satış müdürü sütununun kullanıcı adına eşit olması, kategoriler üzerinde filtre yaratacak, bu filtre ok yönünde fact tablosuna kadar akacak!
Yukarıdaki ilişkisiz yöntemle aynı sonucu elde ederiz! Bu örnekteki duruma göre hangisi daha hızlı çalışır derseniz ilişkili olan derim!
Her iki yöntemi de bilmekte fayda var, zira bazen karmaşık RLS senaryolarında, hem USERNAME USERPRINCIPALNAME fonksiyonlarını kullanmak hem de kod örneklerinde olduğu gibi rol filtreleri yaratmak gerekebiliyor.
İlişki kurarak yaptığımız yöntem için bu yazıya da bakmanızı öneririm. Mantık aynı, biraz daha genişletilmiş bir versiyon.
* Bu tür yetkilendirme tablolarını modelde gizlemeyi unutmayın, kullanıcının görmesine gerek yok!
…
Son bir not da zaman zaman karşılaştığım bir durum için: Bazen isteniyor ki, her satış müdürü sadece kendi sorumlu olduğu kategorileri görsün ama diğer tüm satışlara göre % kaçlık oranda olduğunu da görebilsin. Yani kendi kategorilerinin satışları 20TL, tüm satışlar 100 TL, 20% bilgisini de görebilsin. Bunu yapmanın en kolay yolu, kategori bilgisinin olmadığı gruplanmış bir fact tablosunu modele almaktır. Misal, satışlar tablosunu, gün-satış tutarı bazında gruplayarak modele alır ve misal tarih tablosuyla ilişki kurarsanız bu oranı da hesaplayabilirsiniz.
Yazıdaki modelleri -bloga üyeyseniz- indirebilirsiniz.
Sadece üyeler görebilir. Hızlı üyelik için sosyal medya hesabınızla giriş yapabilirsiniz!