Az Oracle adatbáziskezelő 8-as verziójától kezdve rendelkezik Virtual Private Database funkcionalitással mely az egyre újabb verziókban fokozatosan fejlődött, a 11g már lehetővé teszi a sor és az oszlop szintű szűrést, a tábla bizonyos oszlopainak elrejtését a bejelentkezett felhasználó jogosultságai alapján, sőt úgy is beállítható hogy csak akkor tűnjön el az adott sor ha annak bizonyos védett oszlopa is megjelenne.

Közvetlenül az adatbázisobjektumokhoz rendelhetőek biztonsági szabályrendszerek (lényegében egy újabb, akár dinamikusan előállított where feltétel), így ezek bármilyen elérése védett lesz, az adatbázisra épülő alkalmazások nem tudják megkerülni. Külön szabály(rendszer) rendelhető a SELECT, INSERT, UPDATE, DELETE parancshoz, Tableau viszonylatában a SELECT lényeges egyedül, hiszen a Tableau nem írja az adatbázist.

A Tableau oldaláról semmilyen változtatásra nincs szükség a kapcsolat felépítését leszámítva, az adatbázis kapcsolat létesítésekor állítja be a sessiont a Tableau „initial SQL” parancson keresztül, mely felhasználó nevében fog lekérdezni. Több felhasználó esetén mindenkinek külön, párhuzamosan futó session-ja lesz, melyek egymástól függetlenek, így adatot sem osztanak meg egymással. A kérdéses Initial SQL valami ilyesmi lesz:

begin

 DBMS_SESSION.SET_IDENTIFIER([TableauServerUser]);

end;

A [TableauServerUser] automatikusan behelyettesítődik a bejelentkezett felhasználó azonosítójával, természetesen ennek léteznie kell Oracle oldalon is.

Oracle oldalon minimálisan szükség lesz egy függvényre, mely visszaad egy VARCHAR2 típusú stringet, ez lesz a where feltétel ami a sorszintű szűrésért felelős, illetve kell egy policy, ami használja azt. A függvény fixen a séma és az objektum nevét kapja meg paraméterként. Szintaktikailag hibás feltétel illetve hibára futó függvény esetén a táblából egyáltalán nem lehet lekérdezni, hibaüzenet érkezik. További korlátozás, hogy a policy által korlátozott táblákból nem kérdezhet le a függvény.

CREATE OR REPLACE FUNCTION hide_rows(v_schema  IN VARCHAR2 ,v_objname IN VARCHAR2) RETURN VARCHAR2
AS
  con       VARCHAR2 (200);
  count_reg NUMBER;
  CURSOR region_cur
  IS
    SELECT region
    FROM global_superstore_people
    WHERE Person = SYS_CONTEXT('userenv', 'client_identifier');
BEGIN
  count_reg := 0;
  FOR reg IN region_cur
  LOOP
    IF count_reg = 0 THEN
      con := '(region=''' || reg.region || '''';
    ELSE
      con := con || ' OR region=''' || reg.region || '''';
    END IF;
    count_reg := count_reg + 1;
  END LOOP;
  if count_reg>0 then con := con || ')'; end if;
  if count_reg=0 then con := '1=0'; end if;
  RETURN (con);
END hide_rows;


BEGIN
  sys.dbms_rls.add_policy ( object_schema => 'SCHEMA1'
                            ,object_name => 'GLOBAL_SUPERSTORE_ORDERS'
                            ,policy_name => 'HIDE_ROWS_POLICY'
                            ,policy_function => 'HIDE_ROWS'
                            ,function_schema => ' SCHEMA1'
                            ,statement_types => 'SELECT');
END;

A global_superstore_people tábla tartalmazza hogy mely felhasználó mely régiókhoz férhet hozzá, a global_superstore_orders a célobjektum, melyen szűrni fogunk, kizárólag a SELECT parancsoknál fog élni a szűrés. Miután ezt a kódot az adatbázison futtattuk, global_superstore_people táblát feltöltöttük, aktív a szűrés az orders-en, vagyis az átküldött felhasználóhoz rendelt régiók adatait fogja csak visszaadni a SELECT. Mint a képen látható, a Tableau-n nem lett beállítva szűrés, más-más user-rel kérdeztem le ugyanazt az adatcsoportot.

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