Riportoló rendszerekkel szembeni követelmény az adatok védelme illetéktelen hozzáféréssel szemben, aminek fontos része hogy adott felhasználók vagy felhasználói csoportok az adatok meghatározott részéhez férjenek csak hozzá. Adott dolgozó csak azokat az adatokat lássa amire a munkájához szüksége van, azaz például másik részlegét, más területi egységét ne. A sales-es láthassa a saját ügyfeleinek adatait, a többiekét ne, a csoportvezető láthassa a beosztottakét, a marketing a teljes sales csapat adatait, de annak csak a marketing feladatokhoz szükséges részét, bizonyos adatokat ne, stb.  A Tableau többféle megközelítésben támogatja e probléma kezelését.

Készíthető felhasználóhoz illetőleg felhasználói csoportokhoz rendelt szűrő, (user filter) amit a Tableau kezel és a belépett felhasználóra automatikusan vonatkozik. Komoly hátránya hogy nagy munkába kerül a karbantartása, hiszen a többi rendszeren túl a Tableau-n is át kell vezetni minden egyes szervezeti változást.

http://onlinehelp.tableau.com/current/pro/desktop/en-us/help.htm#publish_userfilters_create.html#create-user-filter

Készíthető adatbázis szinten biztonsági leíró tábla vagy táblastruktúra, melynek sorai meghatározzák hogy adott felhasználó mire jogosult (vagy akár a forrástáblák speciális oszlopa is tartalmazhatja a jogosult felhasználó adatait) , a  a szűrés az egyes adatforrások viszonylatában történik, akár segédtáblákon keresztül. Ezeket a segédtáblákat (vagyis a szabályrendszert) általában szintén az adatforrás tartalmazza, de természetesen ezeket az adatok jöhetnek egy másik rendszerből is, pl. generálható a HR rendszerből, így szervezeti változás esetén a Tableau-n nem szükséges semmit módosítani. A Tableau beépített függvényein keresztül - elsősorban a USERNAME() vagyis a bejelentkezett felhasználó neve -  történik a szűrés a security táblán vagy táblákon, melyek össze vannak joinolva az adattáblákkal, így kiszűrődnek a nem elérhető sorok.

Ezzel a megközelítéssel több probléma van. A security sorok esetleges duplikációja az eredményhalmazt is duplikálhatja, illetőleg másik, nagyobb gond, hogy a Tableau elkészíti a joinolt táblát a memóriában és ebben fog szűrni, és ha a security táblának sok sora van nagyon nagyra nőhet az eredménytábla, vagyis ha egy sorhoz 100 felhasználó férhet hozzá az azt jelenti hogy 100-szor fog szerepelni a sor a memóriában, még ha tömörítve is, és ebből lekérdezéskor 99 biztosan kiszűrődik, aminek komoly teljesítményvonzata van. Ez részben megkerülhető csoportok illetve ISMEMBEROF(‘Group Name’) használatával. Sajnos a csoporttagság karbantartása szintén a Tableauban történik.

Másik lehetőség fenti problémakör megkerülésére, ha a security table az azonos jogosultsággal rendelkező felhasználók felsorolását tartalmazza (vagy egyenesen a ténytáblába kerül egy ilyen felhasználó felsorolás oszlop), majd valamilyen CONTAINS([Security Field], USERNAME()) -hez hasonló feltétellel szűrünk, érdemes a felhasználónevet valamilyen elválasztóval körül venni és ezt is beletenni a szűrésbe, hogy ne találjon meg másik hasonló, de rövidebb nevű felhasználót.

Tehát Tableau-ban az adatforráson a security table inner join-nal kapcsolódik az adattáblára (illetve ha az adattábla tartalmazza a jogosult felhasználót erre nincs is szükség) és bekerül a joinba egy számított mező USERNAME() ahol „security” a security table, és minden sor automatikusan kiszűrődik amire a feltétel hamis. A sample superstore mintaadatbázist város szerint szűrtem, a joinba került bele a feltétel, a name mező a felhasználónév kell legyen, és a felhasználóhoz rendelt városok jelennek csak meg az adatok között, ha sales1 jelentkezne be Detroit és Seattle adatai jelennének meg, St Petersburgé nem.

Megadható ugyanez szűrésként is, a két táblát továbbra is joinolni kell:

További lehetőségek

Harmadrészt lehetőség van a hozzáférés korlátozására adatbázis oldalról is, akár az előző pontban körvonalazott security táblák és szűrések adatbázis oldalra költöztetésével illetőleg a különféle adatbáziskezelők „row level security” funkcionalitásán keresztül. Beállítható a Tableau úgy hogy az egyes felhasználóknak külön session-t nyit, bejelentkezéskor átadja a felhasználói adatokat, és ilyenkor az adott sessionon keresztül kérdez le. Ilyenkor az adott felhasználó által elérhető adatok érkeznek csak meg a Tableau-hoz, így csökken az átadott adatmennyiség és megoldódik a security table join által duplikált sorok problémája, viszont több session lesz párhuzamosan nyitva, felhasználónként egy, és a bejelentkezett felhasználók hiába dolgoznak ugyanazokkal az adatokkal, felhasználónként külön lekérdezésre kerül a teljes dataset. A paraméterek átadására a Tableau-ban megadható adatbáziskapcsolat-létesítéskor egyszer lefutó „Initial SQL” ahol megtörténhet a session testreszabása a Tableau user alapján. E funkcionalitásról későbbi blogposztban írok részletesen.

Amennyiben pedig továbblépnél és szeretnéd ezekből a lehetőségekből a mindennapi munkában minél többet hasznosítani, keress fel minket az elérhetőségeink valamelyikén, és mi segítünk megtalálni azokat a területeket, ahol a legnagyobb üzleti hasznot realizálhatod egy ilyen eszköz használatával, természetesen szakmai támogatást nyújtunk a bevezetéshez