SQL s objekty hledá v multimediálních datech

Společně s tím, jak se v tradičních systémech relačních databází vytvářejí stále komplexnější typy dat, musí...


Společně s tím, jak se v tradičních systémech relačních databází vytvářejí
stále komplexnější typy dat, musí se také standardní databázový dotazovací
jazyk SQL přizpůsobovat rozmanitému obsahu. Např. společnost IBM, kde byl jazyk
SQL vyvinut, se však k různým objektově-orientovaným metodám staví poměrně
skepticky.
Jen malá část všech dat je uložena v tabulkách relačních databází, většina
elektronických informací se nachází v jiných strukturách jako text, obraz, tón,
jako časová řada a jiné typy. Internet a multimédia tento nerelač-ní "objektově-
orientovaný" podíl uložených informací v příštích letech ještě podstatně zvýší.
Dosavadní relační model má ovšem tu výhodu, že je založen na matematicky čistě
formulovatelné teorii. Proto je velmi bezpečný a pro určité účely v podnikové
administrativě snadno intuitivně pochopitelný. Metodicky je relační koncepce
jen zvláštním případem objektově-orientovaného systému mimo jiné
optimalizovaného z hlediska bezpečnosti.
K objektům
Objektová metoda popisu databáze najde jistě uplatnění v plné šíři při
zobrazování reálného světa. Vynutí si ji především aplikace typu prezentace na
Internetu a zejména webově orientované integrované obchodní transakce. O tom,
jaký je současný stav v této oblasti i o výhledech do budoucna se dočtete na
str. 4.
Volkhard Wolf
Kombinace relačních a nerelačních dat se bude vyskytovat stále hojněji. A
databázový jazyk si s nimi musí poradit.
Vezměme si jako příklad tře-ba spojení pojistek s fotografiemi a textovým
popisem nehody u pojištění povinného ručení motorových vozidel. Anebo spojení
parametrů výroby a geografických dat při plánování marketingové kampaně.
Jednou věcí je ovšem uložení relačních a nerelačních dat do paměti, jinou pak
rekonstrukce nebo pracné dolování vzájemných informačních vztahů. Není totiž
samozřejmé, že se z uložených dat dají určitým konečným vynaložením technických
prostředků a s rozumnými náklady získat také užitečné informace. V podobě
strukturovaného dotazovacího jazyku SQL se v 80. letech prosadil deklarativní,
množinově orientovaný databázový dotazovací jazyk, který umožňuje poměrně
účinně vyhledávat mnoho informací z relačních tabulek, zhušťovat je a dávat je
dohromady.
Standardizací SQL, která probíhá od konce 80. let, vzniklo dotazovací rozhraní,
které zaručuje vzájemnou kompatibilitu různých databázových produktů aspoň
pokud nebudeme používat specifické zvláštnosti některých výrobců. V nerelačních
systémech však neexistuje nástroj, který by se dal stejným způsobem aplikovat
na celé spektrum produktů a dodavatelů a byl přitom stejně efektivní jako je
SQL.
Snahou o změnu je standardizační záměr v oblasti objektově-orientovaných
databází pod názvem Object Query Language (OQL), který se orientuje podle SQL,
ale dosud nedosahuje jeho technické zralosti a není u odběratelů přijímán tak
jako SQL.
OQL zatím neuspěl
Vzhledem ke zmíněné situaci byla nasnadě snaha udržet při integraci nových
datových struktur přednosti SQL a navíc je ještě rozšířit. Konkrétně to znamená
zachovat koncept relačních databázových systémů a s nimi související dotazovací
techniky a začlenit modelování dotčených objektů do staré koncepce.
Realizace v rámci tabulkových struktur, ačkoliv by teoreticky byla možná,
nepřicházela v úvahu, protože přímý přístup k objektům jako jsou texty, obrazy,
geografická data nebo časové řady, pomocí SQL by vyžadoval těžko zvládnutelné
programy a dlouhé doby provádění. Je proto mnohem účelnější neusilovat o
komplexnost dotazů typu SQL, nýbrž vytvořit nové komplexní datové typy, resp.
připustit datové typy, které by si uživatel definoval sám podle své potřeby.
Současně je přitom možno stanovit metody, tedy programový kód, který by
umožňoval přístup k těmto novým datovým typům.
Přichází SQL3
Výsledkem tohoto postupu byl koncept objektově-relačních databází, který
všichni velcí dodavatelé implementovali v minulých letech s klasickým relačním
modelem v různých technických formách. Metoda byla použita v konceptech jazyka
SQL3, který je nyní diskutován v příslušných normalizačních grémiích.
Např. IBM implementovala objektově-relační techniku ve své vlastní databázi DB2
Universal Database (UDB). Současně IBM nabízí tzv. realační extendery,
předkonfigurované balíky umožňující "dolování" obrazu a textu (nebo
picture/text mining, chcete-li), ukládání audio a videosekvencí, geografických
mapových systémů a analýzu časových řad.
Tato rozšíření DB2 jsou sbírkou uživatelsky definovaných datových typů a
funkcí, jakož i procedurálních rozšíření databází. Spojují se přímo a bez
nároku na další programové vybavení s jádrem DB2 a nabízejí obsáhlé algoritmy
hledání a dotazování pro konkrétní oblast.
Pomocí extenderů je možno ukládat obvyklá databázová data vedle textových
dokumentů, video a audiosekvencí, zeměpisných map a časových řad v tabulkách
DB2 pod daným speciálním datovým typem a dotazovat se na ně pomocí instrukcí
SQL. Pro vyšší výkon a vzhledem k existujícím programovacím infrastrukturám se
vytváří také komplexní datové typy, k nimž je přístup nikoliv přes SQL, ale
např. přes C, C++ nebo Javu. Tyto datové typy se někdy označují jako
"neprůhledné" (opaque). Nepodporují žádné podtypy a tudíž žádné inherentní
mechanismy.
Programovací jazyky zpřístupňují nové datové typy
V porovnání s datovými typy tradičních relačních bází nejsou u těchto
zvláštních typů kladeny další požadavky na jejich strukturu, např. na sloupcové
primární klíče. Popis atributů, formát a kódová stránka tak popisují textový
dokument v textovém extenderu.
Uživatelsky definované metody, dodávané s textovým extenderem, provádějí své
funkce ukládání a dotazování na těchto atributech. Existují tu např. atributy
rozložení barev a textury, které mimo jiné charakterizují strukturu uživatelsky
definovaných obrazových datových typů. Při použití obrazového extenderu se v
DB2 UDB můžeme instrukcemi SQL dotazovat, nejen zda obraz odpovídá nebo se
podobá předloze, ale také na určité rozložení barev a texturu.
Některé indexy pro nové datové typy
Pro interaktivní hledání v katalozích je např. možno zadat skupiny zmíněných
parametrů, které umožní identifikovat hledaný objekt nebo se mu alespoň
přiblížit. Speciální indexové techniky, zaměřené na obrazové datové typy a
překračující tradiční relační struktury obvyklých B-stromů, usnadňují hledání v
databázi.
Uživatel však s vlastními indexovými technikami nepřijde do styku. Zadá
příslušnou instrukci SQL spolu s extenderovými funkcemi a dostane výsledek.
Jednou z vlastností extenderového modelu DB2 UDB je to, že je možno provádět
dotaz SQL v několika komplexních datových strukturách a u tradičních relačních
datových typů současně. Tak může např. pojišťovna formulovat dotazy, které
jednak zpřístupní obsahy obrazů a textů (obrazový extender a textový extender),
jednak i obvyklé tabulky zákazníků.
Složitější texty
Textový extender integruje v DB2 na standardním rozhraní SQL fulltextovou
vyhledávací rutinu. Tím odpadají přídavná rozhraní aplikačních programů pro
vyhledávání v textových dokumentech. Uvedený textový extender "rozumí" textovým
dokumentům na základě slov, vět nebo částí textu. Je možno hledat speciální
slova nebo sled slov, event. tzv. "přibližná funkce" vybírá dokumenty, které
obsahují určitá slova nebo množinu slov bez ohledu na jejich pořadí.
Takový dotaz poskytne např. jména všech pojištěnců, v jejichž nehodových
protokolech se vyskytují věty jako "...při nehodě vznikla velká škoda na levých
předních dveřích..." nebo "... pravé dveře na přední straně vozidla vykazují
těžké škody...". Textový extender si přitom sám poradí s transformací plurálu
"škody" na singulár "škoda", protože obsahuje algoritmy k rozpoznání
skloňovaných tvarů (ško-da = škody) a synonym (velká = = těžká).
Vazby jsou nutné
"Najdi všechny zákazníky, kteří vydělávají ročně více než 500 000 korun a bydlí
nejdále 20 km od obratově silné filiálky X v místě Y." Pro takové úlohy se hodí
"prostorový" extender (Spatial Extender); ovšem jen ve spojení s DB2 UDB.
Předpokladem je totiž úplná integrace geografického informačního systému do
objektově-relační databáze.
Takto formulované úlohy dokládají význam rozšíření obvyklých databázových
informací o kartografické znázornění v GISech (geografických informačních
systémech). V podstatě se strategie optimalizace tradičních relačních systémů
rozšíří o "geografické tabulky". Výsledkem bude podstatné zjednodušení a
urychlení precizního plánování marketingových kampaní nebo databází podporovaný
výběr vhodného stanoviště pro obchodní filiálky.
Po dostatečně efektivní integraci nástrojů tak budou zájemci moci pracovat s
jednotnou sadou systémových manažérských nástrojů.
9 0073 / pen

Databázová inteligence v praxi
Níže uvedená instrukce SQL znázorňuje spojitost mezi obrazově-textovým hledáním
a tradičním vyhledáváním v tabulkách relačních databází a představuje
následující situaci:
Představme si, že v databázi existuje tabulka "nehody", která obsahuje také
sloupec označený "zpráva". V tomto sloupci je podrobný textový popis nehody. Ve
sloupci označeném "obraz" je pak znázorněno poškozené vozidlo. Mimo to jsou v
tabulce sloupce s označením "jméno", "věk" a "číslo pojistky".
Níže definovaná instrukce SQL má nyní vyhledat všechny nehody zákazníků
mladších 25 let, k nimž došlo na vozech červené barvy a při nichž byly těžce
poškozeny přední dveře.
SELECT jméno, číslo pojistky
FROM nehody
WHERE obsahuje (zpráva, "škoda" IN SAME SENTENCE AS
"velký" AND "přední strana" AND "dveře")
= 1 AND vyhodnocení (obraz, "červený") > 0,5
AND stáří < 25.
Ke každému obrazu poškozeného vozidla dodá databáze (např. v hlavním textu
zmíněná DB2) vyhodnocení shody barev. Budou vybrány jen obrazy, u nichž bude
koeficient shody větší než 0,5. Potom začne výše popsané vyhledávání podle
popisu poškození a porovná se s obrazovou množinou. Zbývající množství se
podrobí selekci podle věku zákazníků (mladší 25 let), takže nakonec zbudou jen
soubory, které splňují všechna kritéria. Optimizátor DB2 sám určí pořadí
jednotlivých dílčích kroků při vyhledávání, které může ve skutečnosti být jiné,
než jak jsme zde popsali.
Databázová inteligence v praxi
Níže uvedená instrukce SQL znázorňuje spojitost mezi obrazově-textovým hledáním
a tradičním vyhledáváním v tabulkách relačních databází a představuje
následující situaci:
Představme si, že v databázi existuje tabulka "nehody", která obsahuje také
sloupec označený "zpráva". V tomto sloupci je podrobný textový popis nehody. Ve
sloupci označeném "obraz" je pak znázorněno poškozené vozidlo. Mimo to jsou v
tabulce sloupce s označením "jméno", "věk" a "číslo pojistky".
Níže definovaná instrukce SQL má nyní vyhledat všechny nehody zákazníků
mladších 25 let, k nimž došlo na vozech červené barvy a při nichž byly těžce
poškozeny přední dveře.
SELECT jméno, číslo pojistky
FROM nehody
WHERE obsahuje (zpráva, "škoda" IN SAME SENTENCE AS
"velký" AND "přední strana" AND "dveře")
= 1 AND vyhodnocení (obraz, "červený") > 0,5
AND stáří < 25.
Ke každému obrazu poškozeného vozidla dodá databáze (např. v hlavním textu
zmíněná DB2) vyhodnocení shody barev. Budou vybrány jen obrazy, u nichž bude
koeficient shody větší než 0,5. Potom začne výše popsané vyhledávání podle
popisu poškození a porovná se s obrazovou množinou. Zbývající množství se
podrobí selekci podle věku zákazníků (mladší 25 let), takže nakonec zbudou jen
soubory, které splňují všechna kritéria. Optimizátor DB2 sám určí pořadí
jednotlivých dílčích kroků při vyhledávání, které může ve skutečnosti být jiné,
než jak jsme zde popsali.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.