🔐 Row-Level Security w Power BI bez spadku wydajności

Kiedy Row-Level Security w Power BI najbardziej psuje wydajność modelu?

Row-Level Security najbardziej obniża wydajność wtedy, gdy filtr bezpieczeństwa musi być wyliczany dynamicznie dla każdego użytkownika i jednocześnie przechodzi przez dużą część modelu. Problem pojawia się szczególnie wtedy, gdy reguły RLS nie są prostym filtrem na dobrze zoptymalizowanym wymiarze, tylko opierają się na złożonych wyrażeniach DAX, relacjach wiele-do-wielu, długich ścieżkach filtrowania albo tabelach mapujących użytkowników do wielu elementów organizacyjnych. W takiej sytuacji silnik ma mniej możliwości optymalizacji i częściej wykonuje kosztowne przeliczenia przy każdym zapytaniu.

Najgorzej jest wtedy, gdy RLS ogranicza duże tabele faktów pośrednio, przez kilka relacji lub przez tabele o wysokiej kardynalności. Jeśli użytkownik ma dostęp do wielu regionów, klientów, oddziałów lub produktów, filtr bezpieczeństwa nie jest wąski, tylko rozlewa się na dużą liczbę wierszy. To zwiększa koszt propagacji filtra i może pogarszać zarówno czas wykonania zapytań, jak i skuteczność cache, ponieważ wyniki stają się bardziej zależne od konkretnego użytkownika.

Wydajność wyraźnie spada też wtedy, gdy reguły RLS używają funkcji takich jak USERPRINCIPALNAME() w połączeniu z logiką wyszukującą uprawnienia w rozbudowanych tabelach dostępowych. Samo użycie tożsamości użytkownika nie jest problemem, ale jeśli prowadzi do złożonych filtrów i częstych przekształceń kontekstu, każde zapytanie staje się cięższe. W praktyce najbardziej kosztowne są więc nie same role, ale dynamiczne, szeroko propagowane i słabo uproszczalne filtry bezpieczeństwa działające na dużym modelu.

Jeżeli reguła RLS jest prosta, oparta na małej tabeli wymiaru i filtr przechodzi krótką, jednoznaczną ścieżką do faktów, wpływ na wydajność zwykle jest umiarkowany. Gdy jednak bezpieczeństwo staje się dodatkową warstwą logiki biznesowej w modelu, RLS zaczyna być jednym z głównych źródeł spowolnień.

Jak zaprojektować tabelę uprawnień, żeby filtry RLS były tanie obliczeniowo?

Tabela uprawnień powinna być zaprojektowana tak, aby filtr RLS dało się wyrazić jako proste dopasowanie klucza, a nie jako obliczenie wykonywane dla każdej ewaluacji zapytania. Najtańszy wariant to model, w którym użytkownik jest powiązany z konkretnymi wartościami kluczy używanymi w relacjach, na przykład identyfikatorem regionu, działu albo klienta, a sam filtr opiera się na bezpośrednim porównaniu tych wartości. Im mniej logiki tekstowej, wyszukiwań warunkowych i pośrednich transformacji w regule bezpieczeństwa, tym mniejszy koszt obliczeniowy.

W praktyce oznacza to, że tabela uprawnień powinna zawierać znormalizowane, techniczne klucze, a nie opisy biznesowe. Jeśli filtrujesz dane sprzedaży po regionie, to w tabeli uprawnień powinien znaleźć się identyfikator regionu, a nie jego nazwa. Porównania po liczbach lub krótkich kluczach są tańsze niż operacje na tekstach i zmniejszają ryzyko niejednoznaczności. Dobrą praktyką jest też utrzymanie jednej wartości na wiersz, czyli modelu typu użytkownik–klucz dostępu, zamiast przechowywania wielu uprawnień w jednym polu w postaci listy lub ciągu znaków.

Istotne jest również ograniczenie liczby poziomów, przez które musi przejść filtr. Najlepiej, gdy tabela uprawnień filtruje bezpośrednio wymiar, a wymiar dalej filtruje fakty przez standardową relację. Jeśli dostęp wymaga przechodzenia przez wiele tabel pośrednich, mapowań i warunków specjalnych, koszt rośnie, a zachowanie modelu staje się trudniejsze do przewidzenia. Tabela uprawnień powinna więc być możliwie wąska, jednoznaczna i relacyjnie prosta.

Żeby filtry były tanie, warto też zadbać o małą kardynalność i brak zbędnych duplikatów. Jeżeli użytkownik ma dostęp do 500 pozycji, tabela powinna zawierać dokładnie te 500 powiązań, ale bez powielania tych samych kombinacji. Nie należy przechowywać w niej kolumn, które nie uczestniczą w filtrowaniu, ponieważ zwiększają rozmiar modelu bez korzyści dla RLS. Kluczowe jest, aby tabela odpowiadała na jedno pytanie: który użytkownik ma dostęp do którego klucza filtrowania.

Najgorszy wzorzec to tabela uprawnień wymagająca interpretacji w czasie zapytania, na przykład z wartościami typu zakres, tekstowymi regułami, flagami warunkowymi albo zależnościami typu „jeśli dział A, to też region B”. Takie wyjątki lepiej rozstrzygać wcześniej, na etapie przygotowania danych, tak aby do modelu trafiała już gotowa, jawna mapa dostępów. Dzięki temu reguła RLS pozostaje prosta, a silnik wykonuje głównie filtrowanie po relacjach i kluczach, zamiast kosztownych obliczeń.

💡 Projektuj tabelę uprawnień jako prostą mapę użytkownik→klucz techniczny, tak by RLS sprowadzał się do bezpośredniego porównania po relacji, a nie do logiki tekstowej czy warunków liczonych w locie. Każdy wyjątek i interpretację reguł rozstrzygaj wcześniej w ETL, bo najtańszy filtr to jawny, znormalizowany klucz bez duplikatów i bez list w jednym polu.

Czy lepiej filtrować po kluczach (ID) czy po nazwach i dlaczego?

W kontekście Row-Level Security w Power BI lepiej filtrować po kluczach technicznych (ID), a nie po nazwach. Powód jest prosty: ID są jednoznaczne, stabilne i zwykle lepiej wspierają wydajne porównania w modelu. Nazwy mogą się powtarzać, zmieniać w czasie, zawierać różnice w zapisie, spacje, wielkość liter lub znaki specjalne, co zwiększa ryzyko błędów w definicji RLS i utrudnia utrzymanie reguł.

Od strony wydajności filtrowanie po ID jest korzystniejsze, ponieważ model analityczny opiera relacje i propagację filtrów właśnie na kluczach. Jeśli reguła RLS działa na kolumnie kluczowej, silnik ma prostszą i bardziej przewidywalną ścieżkę filtrowania niż w przypadku porównań tekstowych. Kolumny tekstowe, zwłaszcza o wysokiej liczbie unikalnych wartości lub niespójnej jakości danych, są cięższe w przetwarzaniu i częściej prowadzą do mniej efektywnych warunków.

Jest też aspekt poprawności. Jeśli zabezpieczenie opiera się na nazwie, to zmiana nazwy jednostki, klienta czy regionu może nagle zmienić wynik działania RLS albo wymagać ręcznej aktualizacji mapowania. Przy ID logika dostępu pozostaje spójna nawet wtedy, gdy etykieta biznesowa zostanie zmieniona. Nazwę należy traktować jako atrybut do prezentacji użytkownikowi, a nie jako podstawę kontroli dostępu.

Wyjątek ma sens tylko wtedy, gdy w źródle danych faktycznie nie istnieje stabilny klucz i nazwa jest jedynym identyfikatorem. Nawet wtedy lepszą praktyką jest najpierw wytworzyć jednoznaczny klucz w warstwie danych lub modelu, a dopiero potem oprzeć na nim RLS.

Jak użyć USERPRINCIPALNAME() bez tworzenia wolnych, niejednoznacznych reguł?

USERPRINCIPALNAME() zwraca login aktualnego użytkownika i samo w sobie nie jest problemem. Problem zaczyna się wtedy, gdy ta wartość jest używana bezpośrednio w złożonych filtrach RLS, zwłaszcza z przeszukiwaniem dużych tabel faktów, wieloma warunkami OR albo niejednoznacznymi relacjami. Najbezpieczniejszy wzorzec to użycie USERPRINCIPALNAME() wyłącznie do odfiltrowania małej tabeli uprawnień lub wymiaru użytkowników, a następnie przeniesienie filtra do modelu przez jednoznaczne relacje.

W praktyce oznacza to, że tworzysz tabelę mapującą użytkownika na dozwolony zakres danych, na przykład: UPN → Region, UPN → Dział albo UPN → Klucz klienta. Reguła RLS powinna być zdefiniowana na tej tabeli w najprostszej możliwej postaci, np. [UPN] = USERPRINCIPALNAME(). Dzięki temu silnik najpierw ogranicza niewielki zbiór uprawnień, a nie wykonuje kosztownego filtrowania na dużych danych transakcyjnych.

Nie warto pisać reguł typu: „pokaż wiersz, jeśli e-mail handlowca, opiekuna lub kierownika jest równy USERPRINCIPALNAME()”. Taka logika bywa wolna i niejednoznaczna, bo łączy kilka ścieżek dostępu w jednym wyrażeniu. Lepsze podejście to spłaszczenie uprawnień do osobnej tabeli, gdzie każdy dozwolony dostęp jest osobnym rekordem. Wtedy model rozstrzyga uprawnienia przez relacje, a nie przez rozbudowane warunki DAX.

Używaj USERPRINCIPALNAME() tylko w tabeli użytkowników/uprawnień, nie w tabeli faktów.
Porównuj do jednej, znormalizowanej kolumny z loginem, najlepiej w jednolitym formacie.
Opieraj RLS na jednoznacznej ścieżce filtrowania przez relacje 1:* zamiast na wielu alternatywnych warunkach.
Unikaj logiki „użytkownik pasuje do kilku kolumn naraz”; zamień ją na tabelę mapowań z osobnymi wierszami uprawnień.

Jeśli jeden użytkownik ma dostęp do wielu elementów, nie rozbudowuj reguły o kolejne porównania. Dodaj kolejne rekordy w tabeli uprawnień. To usuwa niejednoznaczność, upraszcza utrzymanie i zwykle daje lepszą wydajność, bo filtr jest mały, przewidywalny i zgodny z modelem relacyjnym.

Kluczowa zasada jest prosta: USERPRINCIPALNAME() powinien identyfikować użytkownika, a nie zastępować całej logiki autoryzacji w DAX. Im mniej logiki w samej regule RLS, a im więcej w dobrze zaprojektowanej tabeli uprawnień i relacjach, tym mniejsze ryzyko wolnych i niejednoznacznych reguł.

Kiedy warto zastosować TREATAS w RLS, a kiedy pogorszy to sytuację?

TREATAS w RLS warto rozważyć wtedy, gdy trzeba przenieść filtr bezpieczeństwa między tabelami, które nie mają bezpośredniej relacji albo nie da się jej bezpiecznie aktywować w modelu. Typowy przypadek to model z tabelą uprawnień użytkowników, która mapuje użytkownika do kluczy biznesowych, a filtrowana tabela faktów lub wymiarów nie jest z nią połączona w sposób pozwalający na poprawną propagację filtra. W takiej sytuacji TREATAS może działać jak wirtualne przypisanie wartości z jednej tabeli do kolumny w innej tabeli i dzięki temu wymusić właściwy zakres danych.

To rozwiązanie ma sens tylko wtedy, gdy jest naprawdę potrzebne i gdy zbiór wartości przekazywanych przez TREATAS jest relatywnie mały oraz dobrze kontrolowany. Im mniej kluczy musi zostać przeniesionych do filtra, tym większa szansa, że koszt obliczeniowy pozostanie akceptowalny. Dobrze sprawdza się też w modelach, w których alternatywa wymagałaby niejednoznacznych relacji, dwukierunkowego filtrowania albo przebudowy modelu w sposób pogarszający czytelność i przewidywalność RLS.

TREATAS pogarsza sytuację wtedy, gdy staje się zamiennikiem poprawnego modelowania danych. Jeżeli ten sam efekt da się osiągnąć przez prostą, jednoznaczną relację i filtrację po wymiarach, to relacja prawie zawsze będzie wydajniejsza i łatwiejsza do utrzymania. Problem nasila się szczególnie wtedy, gdy reguła RLS z TREATAS operuje na dużej tabeli uprawnień, wielu kolumnach albo generuje szeroki zestaw dozwolonych wartości dla każdego użytkownika. Wtedy silnik musi przetworzyć więcej logiki dynamicznej przy każdym zapytaniu, co może zwiększać czas odpowiedzi i obciążenie pamięci.

Ryzykowne jest też używanie TREATAS warstwowo, na przykład w zagnieżdżonych wyrażeniach lub równolegle w kilku częściach modelu bezpieczeństwa. Taki zapis bywa trudniejszy do diagnostyki, a przy rozbudowanym RLS może powodować nieoczywiste skutki filtracji. Jeżeli reguła bezpieczeństwa staje się przez to bardziej skomplikowana niż sam model, zwykle jest to sygnał, że rozwiązanie idzie w złą stronę.

Praktyczna zasada jest prosta: TREATAS stosuj jako narzędzie specjalne, gdy musisz przenieść filtr bezpieczeństwa tam, gdzie relacja modelu nie rozwiązuje problemu bez skutków ubocznych. Nie używaj go jako domyślnego mechanizmu RLS ani jako obejścia dla źle zaprojektowanych relacji. Jeśli można osiągnąć ten sam efekt przez prostszy model i naturalną propagację filtrów, TREATAS najczęściej tylko zwiększy koszt wykonania i utrudni utrzymanie rozwiązania.

Jak sprawdzić, czy problemem jest DAX w roli, relacje czy sam model danych?

Najpewniejsza metoda to izolowanie warstw problemu i testowanie ich osobno. W Power BI błędy RLS zwykle wynikają z jednej z trzech przyczyn: filtr w definicji roli zwraca inny zestaw wierszy niż oczekiwano, relacje nie przenoszą filtru tak jak zakładano albo model danych ma taką strukturę, że nawet poprawna rola nie może działać stabilnie i wydajnie.

Najpierw sprawdź sam filtr DAX w roli. Uruchom widok testowy roli i oceń, czy tabela, do której przypisano warunek, zawiera dokładnie te rekordy, które powinny być widoczne dla użytkownika. Jeśli już na tym etapie wynik jest błędny, problem leży w logice DAX: warunek zwraca za dużo, za mało albo nie uwzględnia wartości pustych, wielokrotnych dopasowań czy niezgodnych typów danych.

Jeżeli filtr na tabeli źródłowej działa poprawnie, a mimo to wizualizacje nadal pokazują nieprawidłowe dane, sprawdź relacje. Kluczowe jest to, czy filtr z tabeli objętej RLS rzeczywiście propaguje się do tabel faktów i wymiarów, które zasilają raport. Problemem są najczęściej nieaktywne relacje, błędny kierunek filtrowania, relacje wiele-do-wielu albo brak jednoznacznej ścieżki propagacji filtra. W takiej sytuacji rola może być poprawna, ale model nie przenosi ograniczenia tam, gdzie powinien.

Jeśli zarówno warunek DAX, jak i ścieżki relacji są poprawne, wtedy trzeba ocenić sam model danych. Sygnałami problemu modelowego są: duplikaty kluczy po stronie wymiaru, brak tabeli bezpieczeństwa o jednoznacznych mapowaniach, mieszanie logiki uprawnień z tabelami faktów albo konieczność stosowania złożonych filtrów zamiast prostego filtrowania po kluczu. W takim przypadku RLS może działać pozornie, ale dawać niespójne wyniki lub wyraźnie obniżać wydajność.

Objaw	Najbardziej prawdopodobna przyczyna
Błędne wyniki już po przetestowaniu roli	DAX w definicji roli
Rola działa na jednej tabeli, ale nie ogranicza danych w raportach	Relacje i propagacja filtra
Poprawność zależy od obejść, wyjątków lub złożonych warunków	Struktura modelu danych
RLS działa, ale po wdrożeniu mocno spowalnia raport	Najczęściej model danych, czasem zbyt kosztowny filtr DAX

Praktycznie: najpierw potwierdź wynik filtra na tabeli objętej rolą, potem prześledź relacje od tej tabeli do danych używanych w wizualizacjach, a dopiero na końcu oceniaj architekturę modelu. Taka kolejność pozwala szybko ustalić, czy naprawy wymaga formuła roli, relacje czy przebudowa modelu.

Co zmienić w modelu (gwiazda, kierunek filtrowania, kardynalność), aby RLS nie dławił raportu?

Najczęściej trzeba uprościć model tak, aby filtr bezpieczeństwa przechodził krótką, przewidywalną ścieżką: z tabeli uprawnień lub wymiaru do tabel faktów. W praktyce oznacza to model gwiazdy, relacje 1:* z wymiarów do faktów oraz unikanie sytuacji, w których RLS musi propagować filtr przez wiele tabel pośrednich, relacje wiele-do-wielu albo dwukierunkowe zależności.

Model gwiazdy jest najbezpieczniejszy wydajnościowo, bo ogranicza liczbę ścieżek filtrowania. Wymiary powinny zawierać atrybuty opisowe i klucze biznesowe, a fakty miary i zdarzenia. Jeśli zabezpieczenia dotyczą np. regionu, działu lub klienta, to filtr RLS powinien opierać się na odpowiednim wymiarze albo na osobnej tabeli mapującej użytkownika do klucza wymiaru, a nie na tabeli faktów.

Kierunek filtrowania powinien być domyślnie jednokierunkowy. Najlepszy układ to taki, w którym filtr przechodzi z wymiaru do faktu. Dwukierunkowe filtrowanie zwiększa koszt obliczeń, komplikuje plan zapytania i może powodować, że RLS rozlewa się na większą część modelu, niż jest to potrzebne. Jeśli relacja działa poprawnie tylko po ustawieniu both, zwykle oznacza to problem projektowy, a nie brak „opcji” w modelu.

Kardynalność powinna być możliwie jednoznaczna: jeden unikalny klucz po stronie wymiaru i wiele rekordów po stronie faktu. Relacje wiele-do-wielu są szczególnie kosztowne przy RLS, bo silnik musi rozwiązywać filtr przez mniej selektywny zbiór i częściej tworzy droższe operacje pośrednie. Jeśli taka relacja wynika z danych, zwykle lepiej wprowadzić tabelę pomostową z poprawnym ziarnem niż zostawić bezpośrednie M:M.

Element modelu	Zmiana zalecana przy RLS	Dlaczego pomaga
Układ tabel	Model gwiazdy zamiast łańcuchów i „pajęczyny” relacji	Krótsza i bardziej przewidywalna propagacja filtra
Kierunek filtrowania	Single zamiast Both, jeśli tylko logika raportu na to pozwala	Mniej kosztownych ścieżek i mniejsze ryzyko nadmiarowego filtrowania
Kardynalność	1:* zamiast wiele-do-wielu	Lepsza selektywność i prostszy plan wykonania
Mapowanie uprawnień	Osobna tabela uprawnień powiązana po kluczu z wymiarem	RLS działa na małym zbiorze kluczy, a nie na dużym fakcie

Warto też usunąć relacje nieużywane przez raport lub bezpieczeństwo. Każda dodatkowa ścieżka filtrowania zwiększa złożoność modelu, a przy RLS ta złożoność jest odczuwalna przy każdym zapytaniu użytkownika. Celem nie jest „więcej relacji”, tylko mniej relacji, ale jednoznacznych.

Jeżeli po włączeniu RLS raport wyraźnie zwalnia, to najczęściej poprawa przychodzi właśnie po tych trzech zmianach: uproszczeniu do gwiazdy, cofnięciu dwukierunkowego filtrowania do jednokierunkowego i zastąpieniu relacji wiele-do-wielu układem z poprawnym kluczem oraz tabelą pomostową lub wymiarem bezpieczeństwa.

💡 Jeśli RLS spowalnia raport, najpierw skróć drogę propagacji filtra: model gwiazdy, relacje 1:* i jednokierunkowe filtrowanie z wymiaru do faktu zwykle dają największy zysk. Unikaj both i wiele-do-wielu tam, gdzie da się je zastąpić tabelą pomostową lub osobnym wymiarem bezpieczeństwa, bo to upraszcza plan zapytania i ogranicza koszt każdej ewaluacji RLS.

Jak testować role w Power BI Service, żeby wyniki i wydajność nie zaskoczyły po publikacji?

Testowanie ról trzeba wykonywać przede wszystkim w Power BI Service, a nie kończyć na Power BI Desktop. Desktop pozwala sprawdzić logikę filtrowania przez funkcję podglądu roli, ale dopiero w usłudze widać rzeczywiste zachowanie po publikacji: sposób działania modelu po odświeżeniu, wpływ przypisania użytkowników lub grup do ról oraz realny czas wykonywania zapytań dla różnych odbiorców.

Najbezpieczniejszy sposób to opublikować raport do środowiska testowego, przypisać role dokładnie tak, jak będą przypisane produkcyjnie, a następnie sprawdzić raport jako konkretny użytkownik. W praktyce trzeba potwierdzić dwie rzeczy: czy użytkownik widzi dokładnie te dane, które powinien, oraz czy otwieranie stron, filtrowanie i interakcje z wizualizacjami nie są istotnie wolniejsze niż dla administratora lub konta bez ograniczeń. Jeśli test wykonuje tylko autor raportu z szerokimi uprawnieniami, bardzo łatwo przeoczyć różnice wynikające z rzeczywistego kontekstu zabezpieczeń.

Wyniki należy porównywać na reprezentatywnych przypadkach, a nie na jednym koncie testowym. Dobrą praktyką jest sprawdzenie co najmniej użytkownika z małym zakresem danych, użytkownika z typowym zakresem oraz użytkownika z szerokim dostępem w ramach dozwolonej roli. To ważne, bo wydajność RLS zależy nie tylko od samej definicji roli, ale też od tego, jak duży fragment modelu musi zostać przefiltrowany dla danego odbiorcy. Ta sama rola może działać szybko dla jednego użytkownika i zauważalnie wolniej dla innego.

Podczas testu nie wystarczy potwierdzić, że tabele pokazują poprawne rekordy. Trzeba przejść przez najcięższe strony raportu, użyć najczęstszych filtrów i otworzyć wizualizacje, które generują złożone miary. Jeśli po włączeniu roli czas reakcji wyraźnie rośnie, to sygnał, że zabezpieczenia wpływają na plan zapytania albo zwiększają zakres skanowanych danych. Właśnie takie różnice najczęściej wychodzą dopiero po publikacji.

Warto też pamiętać, że test w usłudze powinien odbywać się po pełnym odświeżeniu opublikowanego modelu. Tylko wtedy sprawdzasz faktyczny stan danych, relacji i mapowań użytkowników, z jakiego będą korzystać odbiorcy. Jeżeli RLS jest dynamiczny, test musi obejmować realne adresy użytkowników lub grup, bo poprawna formuła nie gwarantuje jeszcze poprawnego działania po stronie Service, jeśli mapowanie tożsamości jest niezgodne z założeniem modelu.

Krótko mówiąc: role trzeba testować w Service na opublikowanym i odświeżonym modelu, jako rzeczywisty użytkownik lub jego dokładny odpowiednik, sprawdzając jednocześnie poprawność widoku danych i czas reakcji raportu na typowych scenariuszach użycia. Dopiero taki test daje wiarygodną ocenę, czy po publikacji nie pojawią się niespodzianki.

Majczęściej zadawane pytania i odpowiedzi odnośnie Row-Level Security w Power BI bez spadku wydajności: błędy, które kosztują najwięcej

Czy RLS w Power BI zawsze spowalnia raport?

Nie, RLS nie zawsze powoduje zauważalny spadek wydajności. Problemy pojawiają się głównie wtedy, gdy reguły są dynamiczne, złożone i filtrują duże obszary modelu przez długie ścieżki relacji. Jeśli RLS opiera się na prostym filtrze po małym wymiarze lub tabeli uprawnień i przechodzi krótką relacją do faktów, wpływ na czas odpowiedzi zwykle pozostaje umiarkowany.

Jak rozpoznać, że to właśnie RLS odpowiada za wolne działanie raportu?

Najłatwiej rozpoznać problem po wyraźnej różnicy między działaniem raportu bez roli i po włączeniu roli. Jeśli raport działa sprawnie dla administratora, a zwalnia po zastosowaniu RLS, trzeba sprawdzić trzy obszary:

logikę DAX w definicji roli,
ścieżki relacji i propagację filtra,
strukturę modelu, zwłaszcza relacje wiele-do-wielu i dwukierunkowe filtrowanie.

Czy dynamiczny RLS jest gorszy od statycznego pod względem wydajności?

Tak, dynamiczny RLS częściej bywa cięższy obliczeniowo niż statyczny. Dzieje się tak dlatego, że filtr bezpieczeństwa jest wyliczany w kontekście konkretnego użytkownika i może ograniczać skuteczność cache. Sam mechanizm identyfikacji użytkownika nie jest problemem, ale jeśli prowadzi do złożonych mapowań, wielu wyjątków i szerokiej propagacji filtra, koszt zapytań rośnie.

Jakie błędy w tabeli uprawnień najczęściej psują wydajność RLS?

Najbardziej szkodzą tabele uprawnień, które wymagają interpretacji zamiast prostego filtrowania po kluczu. Typowe błędy to przechowywanie nazw zamiast ID, list wielu uprawnień w jednym polu oraz nadmiar zbędnych kolumn. Problemem są też duplikaty i reguły warunkowe rozstrzygane dopiero w czasie zapytania, zamiast wcześniej przygotowanej, jawnej mapy użytkownik–klucz.

Czy można budować RLS bezpośrednio na tabeli faktów?

Zwykle nie jest to najlepsze rozwiązanie. RLS oparty bezpośrednio na tabeli faktów bywa trudniejszy do utrzymania i częściej kosztuje więcej wydajnościowo, bo filtr działa na dużym zbiorze danych. Lepszy wzorzec to ograniczanie małej tabeli uprawnień lub wymiaru, a następnie przeniesienie filtra do faktów przez prostą, jednoznaczną relację.

Kiedy relacja wiele-do-wielu staje się szczególnie ryzykowna przy RLS?

Relacja wiele-do-wielu jest szczególnie ryzykowna wtedy, gdy przez nią przechodzi filtr bezpieczeństwa do dużych tabel. W takiej sytuacji model ma mniej przewidywalną ścieżkę filtrowania i częściej wykonuje droższe operacje pośrednie. Jeśli M:M wynika z danych, bezpieczniej jest rozważyć tabelę pomostową z poprawnym ziarnem albo osobny wymiar bezpieczeństwa.

Po czym poznać, że model danych trzeba przebudować zamiast poprawiać sam DAX w roli?

Sygnałem do przebudowy modelu jest sytuacja, w której poprawna rola nadal wymaga obejść i wyjątków. Jeśli filtr działa tylko przy złożonych warunkach, relacjach both albo wielu tabelach pośrednich, problem zwykle leży w architekturze. Najczęstsze objawy to:

brak jednoznacznej ścieżki filtra,
duplikaty kluczy po stronie wymiaru,
mieszanie logiki bezpieczeństwa z danymi faktowymi.

Jak przygotować test RLS po publikacji, żeby uniknąć niespodzianek w Power BI Service?

Najbezpieczniej testować role na opublikowanym i odświeżonym modelu w Power BI Service. Trzeba sprawdzić raport jako rzeczywisty użytkownik lub jego dokładny odpowiednik, a nie tylko w podglądzie Desktop. Dobrze porównać konta z małym, typowym i szerokim zakresem dostępu oraz przejść przez najcięższe strony i wizualizacje, bo tam najczęściej ujawnia się koszt RLS.