Kvalifikátory

Petr Dadák

dadak@pef.mendelu.cz

Co to je kvalifikátor

kvalifikátor (Q) - mechanizmus pro výběr podmnožiny objektů daného typu splňující určité vlastnosti

kvalifikované objekty: uživatelé (nejen!)

vlastnosti: typ uživatele (student, zaměstnanec, externista), status uživatele (aktivní, vyřazený, přerušený), příslušnost uživatele (ústav, fakulta, studijní program), ...

Q umožňují omezovat velice specifické skupiny (př.: interní doktorandi ústavu 110 s úvazkem alespoň 0.5, zaměstnanci PEF – učitelé předmětů na AF v aktuálním období)

Co to je kvalifikátor

z DB pohledu je jeden kvalifikátor ekvivalentní záznamu v tabulce - číselníku

má tedy své ID, lze se na něj odkazovat cizími klíči v jiných tabulkách

pomocí PL/SQL kódu jsou ještě na DB úrovni definovány základní operace:

rozhodnutí o příslušnosti daného objektu do kvalifikátoru (objekt vyhovuje/nevyhovuje kvalifikátoru)

výběr všech objektů vyhovujících danému Q

vlastní struktura a implementace kvalifikátorů je zcela odstíněna

Co to je kvalifikátor

v konečné implementaci v aplikaci UISu je kvalifikátor ekvivalentní např. uživatelské skupině (výběr uživatelů však probíhá automaticky při definici kvalifikátoru a je neustále aktualizován)

lze použít např. místo „běžného“ omezení na pracoviště nebo fakultu (jemnější dělení)

uživatel používající Q se nemusí starat, jakým způsobem funguje výběr vyhovujících objektů, správnost a kompletnost je vždy zaručena

případná změna datového modelu vyžaduje pouze úpravu definice kvalifikátoru, nikoliv aplikací, které ho využívají

Jak fungují

Q je ‘jednoduchý’ SQL dotaz (SELECT – FROM – WHERE)

SELECT - vybírá pouze ID vyhovujících objektů

část FROM obsahuje všechny tabulky obsahující hodnoty nezbytné pro vyhodnocení podmínek kvalifikátoru

tabulky jsou připojeny (INNER JOIN) k tabulce kvalifikovaných objektů (číselník uživatelů)

v části WHERE jsou dva typy podmínek

joinovací – zajišťují propojení tabulek

omezovací – obsahují konkrétní hodnoty podmínek definovaných v kvalifikátoru

SQL příkaz SELECT je uložen v datových strukturách pro definici Q a jeho provedení – vrácení vybraných objektů je zajišťováno tabulkovou funkcí

tab. funkce – vlastnost RDBMS Oracle umožňující funkcím vracet sady záznamů a operovat s nimi jako s tabulkami

Správa kvalifikátorů

požadavky při návrhu způsobu definice a ukládání kvalifikátorů:

jednoduché a flexibilní ovládání přes aplikace UIS („klikání, ne psaní SELECTů”)

automatické generování stromu kvalifikátorů (viz dále)

kvalifikátory skládány z podmínek

podmínka – atomická, definuje tabulku a sloupec, dále typ parametru, jehož hodnota se dosazuje při zařazení podmínky do kvalifikátoru

dále podmínka obsahuje typ relačního operátoru (=, !=, IS NULL, ...)

podmínky mohou být i bezparametrické

správu zajišťuje PL/SQL balík PKG_KVALIFIKATOR

Správa kvalifikátorů

při definici Q jsou přidávány jednotlivé podmínky a spojovány logickým operátorem ‘AND’

zároveň je generována část FROM výsledného SELECTu včetně spojovacích podmínek pro propojení tabulek

toto se děje automaticky díky evidenci tabulek do kvalifikátorů, jedné z částí jádra systému, kde u každé tabulky je definována ‘připojovací cesta’ ke kořenové tabulce, tj. všechny tabulky a jejich podmínky

pokud více podmínek potřebuje stejnou tabulku, je tato připojována pouze jednou

lze přidat více podmínek stejného typu (student programu) s různými hodnotami parametru

takové podmínky jsou pak spojeny operátorem ‘OR’

Strom kvalifikátorů

mezi jednotlivými kvalifikátory vznikají vztahy nadřízenosti a podřízenosti

speciální Q s více podmínkami omezuje skupinu objektů, která je podmnožinou množiny objektů kvalifikovaných jiným, obecnějším Q (např. Q všichni studenti a Q studenti prezenční formy)

z hlediska přehlednosti evidence a především budoucího použití kvalifikátorů jako ‘zobecněných subjektů’ je žádoucí tyto vztahy mezi Q evidovat

Díky výše popsanému mechanizmu evidence podmínek Q, je možno vytvářet strom kvalifikátorů automaticky, přímo při definování nových Q

zjednodušené pravidlo: Q1 je podřízeným Q2 pokud všechny podmínky Q2 má i Q1

Unionované kvalifikátory

jak bylo řečeno, jednotlivé podmínky kvalifikátoru jsou spojovány vždy operátorem ‘AND’

kombinace operátorů ‘OR’ a ‘AND’ v rámci podmínek jednoho Q nebyla možná (nutnost závorek)

jako řešení byl navrhnut UNION kvalifikátor, který obsahuje dva a více klasických kvalifikátorů, jejichž SELECTy jednoduše sjednocuje klauzulí UNION

strom kvalifikátorů je korektně generován i pro unionované Q, je také možné přidávat jako dílčí Q unionovaného Q jiný unionovaný Q

první zkušenosti s používáním Q ukázaly, že unionované Q jsou potřeba jen zřídka

Obecnost kvalifikátorů

dosavadní výklad a příklady se týkal výhradně ‘uživatelských’ kvalifikátorů, které kvalifikují objekty třídy uživatele

uživatelské kvalifikátory jsou v současné době jedinými prakticky používanými kvalifikátory

je důležité poznamenat, že celý systém jádra Q a jejich správy je navržen zcela obecně a používá pojmu třída kvalifikátorů

třída kvalifikátorů odpovídá kořenové tabulce (KC_UZIVATELE), ke které se joinují ostatní tabulky při vytváření Q

kvalifikátory a podmínky jsou různých tříd jsou zcela disjunktní, mají také jiné ‘joinovací cesty’ pro tabulky

kvalifikátorů jiných tříd bude plně využito především v novém právním systému (viz dále)

Použití Q – dnes

oblastí, kde byly kvalifikátory nasazeny v ostrém provozu je automatické přidělování nároků (implicitní nároky) a práva v dokumentovém serveru

nutnost automatického přidělování ‘čehokoliv’ stála u zrodu Q

na DB úrovni řeší PKG_IMPLICITNI, který úzce spolupracuje s PKG_KVALIFIKATOR

rozlišujeme:

implicitní nároky – uživatel má nárok na 0 – n ‘věcí’ (účty na serverech, přístupové body, uživatelské skupiny)

implicitní kategorie – uživateli je přidělována právě jedna kategorie, může-li mít kategorií víc, vybírá se na základě definovaných preferencí ta nejlepší (dotační kategorie stravování, formát loginu, druh karty)

implicitní kvóty – podobné jako kategorie, avšak bez preferencí, uživateli je z kvót na které má nárok přidělena ta nejvýhodnější (nejvyšší – preferencí vlastně je velikost quoty)

Použití Q – dnes

při implementaci implicitních nároků do nějakého subsystému máme většinou ve výchozím stavu:

číselník nárokovatelných ‘věcí’ (např. seznam serverů)

evidenci nároků (spojovací tabulka mezi uživatelem a ‘věcí’)

pro implicitní nároky potřebujeme:

definiční tabulku – pomocí kvalifikátoru specifikujeme, kteří uživatelé mají jaký nárok

v evidenci nároků nutno přidat údaj o tom, kdo nárok přidělil (pokud byl přidělen uživatelem – správcem, nepodléhá implicitním updatům)

definiční tabulku implementujeme jako:

spojovací tabulku mezi číselníkem kvalifikátorů a ‘věcí’

mnohonásobný atribut typy kvalifikátor v šabloně k číselníku ‘věcí’ (lze použít jen u impl. nároků)

Použití Q – dnes

po spuštění garantuje implicitní přidělování automatický a transparentní refresh (odebrání/přidání nároků) při:

změně statusu uživatele (vyřazení studenta, nástup zam-ce)

změně definice přidělování

změně definice kvalifikátoru

v současnosti je implicitní přidělování nasazeno v:

stravovací subsystém (kompletně včetně definičních aplikací)

CPS, pošta (přidělování funguje, aplikace ve vývoji)

vydávání karet (chybí aplikace na správu)

přístupové body (chybí aplikace na správu)

plánované nasazení:

právní systém – automatická práva a skupiny

Použití Q – zítra

Kvalifikátory ve zobecněné podobě (parametrické používáme už dnes v DS, dynamické až zítra)

jedná se především o:

nový nový právní systém

lepší výběry osob

Slabé stránky

Jak bylo řečeno, základem kvalifikátorů je jednoduchý SQL join SELECT. Kvalifikátory (alespoň v současné podobě) tedy neumožňují použití složitějších konstrukcí jako sumačních funkcí, zanořených selectů a podobně

Jsou požadavky, které nejsou schopny kvalifikátory postihnout. Takové situace vznikají často porušením některé normální formy při návrhu databáze. Další potíž je se šablonami.

Netransparentnost. Při implicitním přidělování vyžadují ošetření všech DML operací měnících status uživatele PL/SQL procedurami.

Závěrem

Kvalifikátory, ač ve své podstatě jednoduché zdají se být velmi mocným a elegantním nástrojem jádra systému použitelným k celému spektru účelů.

Dosavadní provoz v UIS ověřil jejich použitelnost a efektivnost, plného využití lze však patrně dosáhnout jen v systému projektovaného od počátku s jejich podporou.

Děkuji za pozornost.
Dotazy ?

Zvláštnosti chovu angoráků

Jméno uživatele

2003-10-08T01:12:23

Petr Dadák