Struktura SQL dotazů

V Use Case diagramu vytvářeného systému jsme ještě nerozebrali subsystém, který se stará o převádění požadavků na data do SQL dotazu. V kapitole , jsme rozebírali, že uživatel požaduje atributy týkající se určitých objektů, a že uživatele nezajímá struktura databáze. V kapitole zabývající se bezpečností jsme se zmínili o tom, že bezpečnost omezuje množinu objektů, o kterých můžeme získat určité informace. Převádění požadavků na data do SQL dotazu je pak proces, který transformuje tyto požadavky na informace o objektech a bezpečnostní politiku do SQL dotazu, který už musí pracovat na fyzické úrovni databáze. Funkci převádění požadavků do SQL dotazů jsme zařadili do kompetence tvůrce SQL dotazu. Způsobů, jak takovýto převod provést je velmi mnoho.

V této kapitole podpoříme vývoj tvůrce SQL dotazů dekompozicí SQL dotazu; zanalyzujeme nejběžnější vztahy v rámci jednoho SQL dotazu s ohledem na sestavování tohoto dotazu z výše zmíněných požadavků. Přitom už vezmeme v úvahu silná omezení položená v kapitole „Analýza struktury prezentací“ , a to předně předpoklad, že údaje získané z jednoho dotazu jsou ve vztahu 1:1, a že dotazy na sebe hierarchicky navazují. Důvodem této analýzy je, že dotaz bude muset být sestavován na základě požadavků uživatelů, kteří rozhodně nebudou moci používat přímo SQL.

SQL dotaz se obecně skládá ze třech hlavních částí. Jedná se o části SELECT, FROM a WHERE, které nám postupně říkají „co chceme získat“ , „z kama to chceme získat“ a „jaká omezení mají tyto údaje splňovat“ . V této části nebudou rozebrány ostatní možnosti SQL, jako např. části ORDER BY, GROUP BY, HAVING anebo množinové operace nad celými dotazy jako jsou UNION, INTERSECT a MINUS.

V části SELECT uvádíme požadavky na údaje, které si přejeme z databáze získat. V principu se jedná o dva typy údajů:

1. Údaje přímo se nacházející v některé z tabulek v databázi, tedy zpravidla atributy náležející jedné entitě.
2. Údaje agregované, které mají rovněž vztah k jedné entitě. Jedná se předně o poddotaz v části SELECT a o agregaci provedenou pomocí GROUP BY.

Požadavek na určitý atribut se transformuje do jednoho pole v části SELECT do jednoho nebo více polí v části FROM a do libovolného počtu polí v části WHERE.

Část omezení WHERE má pak vztah předně k části FROM. Omezení se nemusí vázat na údaje získané v části SELECT. Na část SELECT se však váží hlavně v případě údajů, které jsou nějakým způsobem v části SELECT vygenerovány a poté pojmenovány.

Požadavek na určité omezení se tedy transformuje do části WHERE, části FROM a někdy i do části SELECT.

Třída objektů, u nichž chceme zjišťovat určité atributy je v databázi nějak uložena. Zpravidla jsou objekty uloženy v jedné nebo více tabulkách. Tabulky jsou identifikovány částí FROM. Vazby mezi těmito tabulkami jsou vyjádřeny v části WHERE. Požadovaným spojením tabulek získáváme množinu objektů požadované třídy.

Bezpečnostní politika se může vázat na část WHERE anebo na část SELECT. Na bezpečnostní politiku se v silnějším případě můžeme dívat jako na omezení selekce údajů, pak se bude vázat na část WHERE a budou se na ni vztahovat veškeré připomínky k části omezení. Druhým, a to reálnějším způsobem uplatnění bezpečnostní politiky je transformace bezpečnostních pravidel do části SELECT. V této části lze pro každý konkrétní objekt podmínit zobrazení jeho atributu použitím podmíněné hodnoty tohoto atributu. Tím myslíme předně použití funkce podmínky if spojené s poddotazem (ne všechny relační databáze funkci if mají). Na základě vyhodnocení tohoto poddotazu se buď zobrazí atribut, nebo nějaká substituční hodnota informující o nedostatku práv k danému atributu.