SQL Multimedia and Application Packages Tomáš Kuchař & Jiří Krůček SQL/MM SQL Multimedia and Application Packages Tomáš Kuchař & Jiří Krůček

Obsah Úvod Část 1: Framework Část 2: Full-Text Část 3: Spatial Část 4: General Purpose Facilities Část 5: Still Image Část 6: Data Mining

Úvod > Motivace Motivace SFQL (1991-1992) Structured Full-text Query Language Rozšíření SQL pro práci s full-textovými daty Vytvořen „Full-textovou“ komunitou Konflikt klíčových slov (CONTAINS) Full-Text vs. Prostorová data Možný konflikt klíčových slov je třeba řešit Na přelomu let 1991-1992, skupina vývojářů textových vyhledávacích nástrojů, pod patronátem IEEE, uvolnila specifikaci jazyka nazvaného SFQL (Structured Full-text Query Language). Cílem SFQL bylo definovat vhodné rozšíření SQL pro práci s full-textovými vyhledáváním v databázích. Návrh byl podán lidmi z full-textové komunity, ale ihned byl kritizován lidmi z komunit zabývajících prací s některými dalšími typy dat, ti tvrdili, že SFQL „vykradlo“ mnoho užitečných klíčových slov, běžně používaných v těchto komunitách. Například klíčové slovo CONTAINS v návrhu SFQL mělo indikovat, že text obsahuje (contains) dané slovo či frázi, ale komunita zabývající prostorovými daty používá stejné klíčové slovo CONTAINS v tom významu, že jeden prostorový objekt obsahuje jiný prostorový objekt. Přestože se na první pohled zdá sémantika klíčového slova CONTAINS v obou případech stejná, jejich implementace se dramaticky liší. Z tohoto příkladu je zřejmé, že by docházelo k tomu, že mnoho rozšíření databázových systémů, rozšíření vytvořených různými komunitami, by nemohlo být spojeno do jednoho produktu, protože by docházelo ke konfliktu klíčových slov.

Úvod > Řešení SQL/MM (1999-2002) Jde o řadu UDT a UDF dle SQL:1999 Okruhy působnosti Full-textová data Prostorová data Obrázky (statické i videa) Tento problém bylo třeba nějak řešit. Úkolem bylo definovat řadu strukturovaných typů s příslušnými metodami. Jde o běžné UDT (uživatelsky definované) typy a metody dle standardu SQL:1999. Navrhovaný standard byl okamžitě znám jako SQL/MM (MM jako MultiMedia). Byla navrhnuta řada okruhů působnosti, kterými by se měl SQL/MM zabývat: full-textová data, prostorová data, obrázky (statické i videa) a další. Úkolem vývoje SQL/MM byl pověřen podvýbor organizace ISO - SQL, s nadějí, že experti z mnoha okruhů působnosti budou schopni vyvinout specifikaci pro každý obor. Informix: Excalibur Text Search DataBlade, Excalibur Image DataBlade, InformixVideo Foundation Data-Blade Module DB2: Image Extender, Audio Extender, Video Extender, Text Extender Oracle: Visual Information Retrieval (VIR) Cartridge, ConText Cartridge, InterMedia

Obsah Úvod Část 1: Framework Část 2: Full-Text Část 3: Spatial Část 4: General Purpose Facilities Část 5: Still Image Část 6: Data Mining

Framework Jednotlivé části SQL/MM jsou na sobě poměrně nezávislé Framework je část společná a závazná „zbytku světa“ Poskytuje: definici společného konceptu užitého v dalších částech SQL/MM hlavní rysy přístupu k definici těchto částí Oproti SQL jsou na sobě jednotlivé části SQL/MM poměrně nezávislé. Nicméně jedna část je společná a závazná „zbytku světa“ - první část - SQL/MM Framework (kostra) - poskytuje definici společného konceptu užitého v dalších částech SQL/MM a hlavní rysy přístupu k definici těchto částí.

Obsah Úvod Část 1: Framework Část 2: Full-Text Část 3: Spatial Část 4: General Purpose Facilities Část 5: Still Image Část 6: Data Mining

Full-Text > Úvod „Full-Text“ ≈ textová data lišící se od běžných znakových řetězců Obvykle delší záznamy Specifické operace Způsob indexování Index slov v dokumentu Index vzájemných vzdáleností slov a frází … Termín „Full-Text“ se užívá pro textová data, která se liší od běžných znakových řetězců. Liší se zejména délkou, ale také specifickými operacemi, které se na ně dají aplikovat. Běžné znakové řetězce (character strings) jsou indexovány celou svou hodnotou, ale na Full-Textová data se používají speciální druhy indexů; jako například index slov, která se vyskytují v dokumentu, nebo index uchovávající informace o vzájemné vzdálenosti slov a frází v textu, apod.

Full-Text > Typ “FullText” Konstruktory Řetězec znaků Řětězec znaků + zadání jazyka Konverzi do běžných SQL znak. řetězců. FullText_to_Character Vyhledávací metody ano/ne (CONTAINS) Rank (RANK) SQL/MM Full-Text standard definuje množství strukturovaných uživatelsky definovaných typů pro podporu ukládání textových dat. Jeden takový typ se jmenuje „FullText“, ten umožňuje konstrukci full-textových záznamů (hodnot) dle řetězce znaků nebo řetězce znaků a jejich výslovnosti, konverzi těchto dat do běžných SQL znakových řetězců (character strings) a testování zda-li tato data obsahují určité vzory (patterns)

Full-Text > vyhledávání Vzorek (+ wildcards) Odvozená slova (STEMMED) Slova s podobným nebo stejným významem (THESAURUS, SYNONYM) Stejně znějící slova (SOUNDS LIKE) Dle pozice v textu (NEAR, …) Dle konceptu textu (IS ABOUT) Vyhledávání vzorků může být docela komplexní, od hledání textu obsahujícího určitá slova, odvozená slova od určitých slov, slova s podobným nebo stejným významem (synonyma), slova, která stejně znějí (homonyma).

Full-Text > Podpora jazyků SQL/MM počítá především s podporou jazyků, kde je snadné výpočetně rozeznat jednotlivé tokeny. SQL/MM počítá především s podporou jazyků, kde je snadné výpočetně rozeznat jednotlivé tokeny (např. slova) v textu. Například „západní“ jazyky používají mezery mezi slovy, interpunkční znaménka pro dělení textu. V japonštině se naopak části textu dají často rozeznat pouze z kontextu.

Full-Text > Příklad > tabulka CREATE TABLE informace ( číslo_dokumentu INTEGER, dokument FULLTEXT ); Uvažujeme následující tabulku. Sloupec “Číslo dokumentu” je identifikátor dokumentu. Sloupec “Dokument” je full-textový dokument. Jak bude vypadat dotaz, který vybere z tabulky „informace“ čísla těch dokumentů, které obsahují slova blízká slovu standard (skloňování, odvozování, …) ve stejném odstavci, kde jsou slova, která se vyslovují podobně jako „sequel“?

Full-Text > Příklad > dotaz SELECT číslo_dokumentu FROM informace WHERE dokument.CONTAINS ( ‘STEMMED FROM OF “standard” IN SAME PARAGRAPH AS SOUNDS LIKE “sequel”’ ) = 1; SELECT vrátí ty řádky, kde metoda CONTAINS vrátí pro sloupec „dokument“ jedničku (1). STEMMED FROM OF najde několik slov odvozených ze slova „standard“ jako např. „standards“ nebo „standardization“. Klauzule IN SAME PARAGRAPH AS vyžaduje aby se následující slovo nebo fráze vyskytovala ve stejném odstavci jako odvozené „STEMMED“ slovo. Klauzule SOUNDS LIKE hledá slova, která se vyslovují (patrně v angličtině) jako slovo „sequel“, tedy např. slovo „SQL“.

Obsah Úvod Část 1: Framework Část 2: Full-Text Část 3: Spatial Část 4: General Purpose Facilities Část 5: Still Image Část 6: Data Mining

Obsah Úvod Geometrický model Příklady Datový katalog Závěr

Úvod

Prostorové databáze Databáze, ve kterých jsou kombinována formátovaná data a prostorová data

Využití prostorových databází Geografické informační systémy (GIS) Plánování výstavby měst Řízení dopravy Mapovaní nalezišť nerostných surovin Distribuční sítě Bankovnictví Pojišťovnictví

Využití prostorových databází CAD/CAM (Computer-aided design and manufacturing) Návrh integrovaných obvodů Návrh mostu Návrh motoru

Co potřebujeme? Vhodný dotazovací jazyk Použití standardních dotazovacích jazyků je nevhodné Neposkytují žádnou podporu pro dotazování nad prostorovými daty Na jedné straně existovaly silné nástroje pro práci s geometrií prostorových objektů reprezentovaných v počítači, na straně druhé interakce či dokonce integrace s neprostorovými daty byly komplikované a neumožňovaly řešit složitější požadavky na kombinaci prostorových a neprostorových dat. Použití standardních dotazovacích jazyků pro zpracování prostorových dat je velice obtížné, protože tyto jazyky neposkytují žádnou podporu právě pro prostorová data. Jsou těsně svázány s vlastnostmi lexikálních dat, pro která byly původně navrženy. I přes tyto těžkosti existuje mnoho pokusů aplikovat existující relační dotazovací jazyky na prostorová data. Vzhledem k tomu, že tyto jazyky pro prostorová data žádný speciální datový typ neposkytovaly, bylo nutné pro jejich uložení používat klasické číselné a řetězcové proměnné. Důsledkem tohoto omezení je skutečnost, že uživatel musí přesně znát strukturu, ve které se prostorová data ukládají. To je samozřejmě velice nepružný a uživatelsky náročný způsob, nicméně, jak ukazují některé komerční produkty hlavních databázových firem, přetrval do jisté míry dodneška. Fundamentální rozdíl je ovšem v tom, že nyní jsou pro dotazování k dispozici potřebné standardizované funkce realizující prostorové operace a predikáty. Ty se v čistě relačním přístupu (např. se staršími standardy SQL) implementovaly ad hoc mimo rámec SQL. Prostorová data mají kromě geometrických vlastností také grafickou prezentaci. I ta by měla být vhodně zakomponována do prostředků dotazovacího jazyka. V některých přístupech jsou prezentační schopnosti chápány jako nedílná součást prostorového dotazovacího jazyka [Eg94].

Řešení Nevyvíjet zcela nový dotazovací jazyk, ale využít jazyka SQL Proč? SQL je databázový standard V praxi se často vyskytují prostorová data společně s lexikálními daty

Co musí jazyk splňovat? Musí umožnit formulování dotazů následujících typů Dotazy výhradně na prostorové vlastnosti (Najdi všechna města rozdělená řekou) Dotazy pouze na neprostorové vlastnosti (Kolik lidí žije v Ostravě?) Kombinace předchozích typů (Vypiš jména všech sousedů parcely číslo 15 v Soukenické ulici) Je důležité, aby dotazovací jazyk poskytoval syntaktické prostředky pro všechny tři typy dotazů. Rozšíření neprostorového jazyka nesmí omezit žádné z jeho původních prostředků.

Historický vývoj GIS databází V první generaci jsou prostorové objekty, jejich atributy a indexy uloženy v souborech. Lze klást prostorové dotazy, nikoliv však dotazy na další, např. podniková, data. Ve druhé generaci jsou neprostorová data včetně dalších aplikačních dat uložena v relační databázi, prostorové objekty a indexy jsou dále uloženy v souborovém systému. Integrace prostorových dat a ostatních dat je nepřímá. Lze již klást dotazy na prostorové objekty a také data, která s těmito objekty nějak souvisí. Přístup je však omezen na požadavky, kde lze jednoduše dekomponovat dotaz na prostorovou a neprostorovou složku. Kromě této omezené funkcionality je hlavním problémem, že dotaz nelze globálně optimalizovat. Systémy třetí generace jsou řízeny spíše ze strany databáze, než ze strany GIS. Prostorové typy dat včetně odpovídajících operací a funkcí jsou integrovány do relačního SŘBD. Toho lze dosáhnout různým způsobem, přičemž zřejmě nejpokročilejším řešením jsou dnes moduly připojené k objektově relačnímu SŘBD (ORSŘBD). Pak lze efektivně realizovat i dotazy typu (iii).

Historie ukládání prostorových dat v relačních databázích Prostorová data jsou uložena v tabulkách v 1NF Prostorová data jsou uložena jako nestrukturované rozsáhlé binární objekty (BLOB) či jako “opaque types” Prostorová data jsou uložena v relační databázi rozšířené o typy prostorových dat Prostorová data jsou implementovaná pomocí uživatelsky definovaných typů V prvním přístupu je nutné prostorové objekty rozložit na primitivní objekty a ty ukládat pomocí souřadnic a čísel. Každá aplikace většinou používá vlastní funkce a integritní omezení. Připomeňme příklad z [Po99], kdy máme pomocí relační databáze implementovat těleso složené z disjunktních čtyřstěnů. Čtyřstěny jsou dány pomocí rovin, hran a bodů. Odpovídající data se uloží ve čtyřech relacích: ČTYŘSTĚNY, ROVINY, HRANY a BODY. Relace ČTYŘSTĚNY obsahuje dvojice (t,f), kde t je identifikátor čtyřstěnu, f je identifikátor jedné z jeho rovin. Relace ROVINY obsahuje dvojice (f,e), kde f je identifikátor roviny a e je jedna z hran v té rovině. Relace HRANY obsahuje trojice (e,p,q), kde e je identifikátor hrany, p a q jsou koncové body hrany. Relace BODY obsahuje čtveřice (p,x,y,z), kde p je identifikátor bodu a x, y, z jeho souřadnice. Je zřejmé, že tato reprezentace geometrie nepodporuje příliš zpracování prostorových dotazů. S prostorovými daty se zachází jako s kterýmikoliv jinými daty, nevyužívá se geometrických vlastností prostoru. Nalézt např. odpověď na dotaz, zdali daná přímka protíná daný čtyřstěn, vyžaduje více vstupů do více relací, které obecně mohou být uloženy na více místech na disku. Jsou-li prostorové objekty uloženy pouze jako bitové mapy, je situace ještě horší. Nelze např. zacházet s částmi prostorového objektu. Lepší možnosti nabízí “opaque type”. Pojem “opaque type” se používá v případech, že pro SŘBD se objekt tváří jako binární objekt, ve skutečnosti je v něm však zakódována struktura, kterou je nutné dešifrovat speciálními programy. Rozšíření relační databáze o prostorové typy dat znamená přidat nové struktury, implementované buď ad hoc nebo opět pomocí tabulek, a odpovídající nové operace. Přínosem je také podpora speciálních indexových struktur. Moduly pro řízení prostorových objektů, jako jsou tzv. cartridges u SŘBD ORACLE, DataBlades u SŘBD Informix a extenders u SŘBD DB2, jdou ještě dále. Funkce modelující chování objektů jsou vnořeny do SŘBD, což umožňuje lepší optimalizaci dotazů. Hovoří se o uživatelem definovaných typech (UDT) a funkcích (UDF). Mechanismus jejich vytváření je součastí konstruktorů jazyka (v daném případě SQL). Implementace takových rozšíření je ovšem velmi různorodá. Např. prostorové moduly v ORACLE 8 a v ORACLE 8i používají různé modely pro reprezentaci geometrických objektů. První je podřízen normalizovaným relacím, druhý je již zasazen do objektově relačního prostředí. Tyto přístupy navíc nejsou mezi jednotlivými relačními SŘBD standardizovány, což představuje pro tvůrce GIS problém. DataBlades Informixu umožňují používat opaque typy. Další řešení pro implementaci UDT a UDF je použito např. v ORSŘBD DB2. Zajímavé řešení nabízí firma MapInfo se sérií produktů SpatialWare, které umožňují ukládat prostorová data do databází ORACLE a Informix a manipulovat je pomocí SQL. Součástí jejich řešení je ovšem i klientský software, který umožňuje správu, vizualizaci a analýzu prostorových dat. Ve původním SQL3 se používá pro UDT a UDF univerzálnější pojem abstraktního datového typu (ADT). ADT zapouzdřuje data a funkce ve stejném smyslu jako u objektově orientovaného přístupu. Relační SŘBD poskytuje jednak nové konstruktory pro tvorbu datových typů (např. ARRAY), jednak konstrukt CREATE TYPE pro vytváření ADT. Pomocí polí lze snadno ukládat souřadnice prostorových objektů. Odkazováním pomocí typu REF lze objekty, a tedy i prostorové objekty, vázat do složitějších prostorových objektů. Mezi další vhodné konstrukty pro implementaci prostorových objektů patří i podtabulky. Hierarchie tabulek může odpovídat hierarchii prostorových objektů (např. silnice ® komunikace).

Vznik SQL/MM (1999) SQL/MM: Part 1: Framework Part 2: Full-text Part 3: Spatial Part 5: Still images Part 6: Data mining

Vlivy na utváření SQL-MM Spatial OpenGIS konsorcium: OpenGIS Simple Features Specification (geometrický model) Standard SQL:1999 (objektová orientace) V tomtéž roce byl také uveden standard SQL:1999 (původně SQL3), který do relačního prostředí vnesl objektovou orientaci. Pro implementaci prostorových objektů se tak otevřely další možnosti. Další oficiální aktivita vznikla ze strany konsorcia OpenGIS (dále OGC), které definovalo standardní SQL schéma [OGC99] pro uložení, výběr, dotazování a aktualizaci jednoduchých geoprostorových kolekcí objektů (features) pomocí ODBC API. Tyto objekty mají prostorové a neprostorové atributy. Prostorové atributy jsou založeny na 2D geometrii s lineární interpolací mezi vrcholy. OGC udržovalo úzký vztah se skupinou WG4 a docílilo tak již ve verzi z r. 1998 kompatibility s jádrem části standardu SQL/MM-Spatial.

Co SQL/MM Spatial definuje? Ukládání, výběr, dotazování a aktualizaci jednoduchých prostorových objektů Reprezentaci prostorových objektů pomocí prostorových datových typů (Spatial types) Funkce pro práci s prostorovými objekty Základní ideou je zapojit geometrické objekty do souborů či relací. Atribut obsahující geometrická data se nazývá prostorový atribut a relace s prostorovým atributem se nazývá prostorová relace. Prostorové relace mají jiné vlastnosti než konvenční relace, neboť odkazují na topologické a metrické vztahy příslušných objektů. Nad prostorovými daty jsou k dispozici speciální operace. Objekty mají prostorové a neprostorové atributy.

Dělení SQL/MM Spatial Standard SQL/MM Spatial je rozdělěn do několika klauzulí Jednotlivé klauzule se zabývají: Prostorovými datovými typy a jejich metodami (Spatial types) Datovým katalogem (Information Schema) …

Datové typy pro reprezentaci prostorových objektů

Prostorové objekty Body: Křivky: Polygony: pouliční lampa, lavička… koryto řeky, hranice pobřeží… Polygony: půdorys budov, území států, pozemky…

SQL geometrický model

SQL geometrický model Hierarchický model, zachycuje vztahy mezi prostorovými datovými typy (dědičnost) Prostorové datové typy reprezentují 0, 1 a 2 dimenzionální geometrické útvary Prostorové datové typy jsou založeny na 2D geometrii s lineární interpolací mezi vrcholy Obsahuje abstraktní typy, od kterých nelze vytvářet instance (ST_Surface…)

SQL geometrický model Vychází z geometrického modelu OGC

0-dimenzionální objekty Bod: ST_Point X a Y souřadnice vzhledem k nějakému systému souřadnic ST_MultiPoint Kolekce bodů Kolekce (Collection) je vždy míněna jako multimnožina, tj. např. v kolekci bodů (Multipoint) mohou být dva body stejné.

1-dimenzionální objekty Křivky: ST_LinearString ST_CircularString ST_CompoundCurve Kombinace ST_LinearString a ST_CircularString ST_MultiLineString Neexistují ST_MultiCircularString a ST_MultiCompoundString Křivka je dána posloupnosti bodů, přičemž podtřídy třídy Curve určují způsob interpolace. V případě LineString (linie, lomená čára) jde o lineární interpolaci. Křivka je jednoduchá, jestliže se sama se sebou nikde neprotíná. Uzavřené křivky mají společní počáteční a koncový bod.

1-dimenzionální objekty Kruhový oblouk je definován třemi body.

2-dimenzionální objekty Povrchy ST_CurvePolygon ST_Polygon (potomek ST_CurvePolygon) ST_MultiPolygon Hranice (boundary) je reprezentována uzavřenou křivkou (resp. křivkami, obsahuje-li povrch díry)

2-dimenzionální objekty

Rozdíly SQL oproti OGC modelu SQL model vypouští typy Line a LinearRing, místo nich zaveden nový typ ST_LineString Zavedeny nové typy pro reprezentaci křivek a povrchů tvořených kruhovými oblouky (ST_CircularString…) Objekty třídy Line (úsečka) jsou dány dvěma body. Třída LinearRing obsahuje pouze jednoduché a uzavřené linie.

Rozdíly SQL oproti OGC modelu U agregovaných typů (kolekcí) není z SQL modelu zřejmé, ze kterých „jednoduchých“ typů jsou složeny Není například zřejmé, zda se typ ST_MultiPoint skládá z objektů typu ST_Point

Prostorové systémy souřadnic Každý prostorový (geometrický) objekt je asociován s nějakým prostorovým systémem souřadnic (Spatial Reference System) Mnoho druhů souřadnicových systémů U některých je třeba brát v úvahu zakřivení zemského povrchu

Prostorové systémy souřadnic Reprezentují se typem ST_SpatialRefSys Všechny hodnoty sloupců reprezentujících prostorová data (prostorové atributy) v SQL dotazu musí být definovány ve stejném souřadnicovém systému

Prázdné prostorové objekty SQL geometrický model nezahrnuje samostatný typ pro reprezentaci prázdného prostorového objektu Instance každého typu může obsahovat prázdný prostorový objekt

Prázdné prostorové objekty Pokud je návratovou hodnotou nějaké metody prázdný prostorový objekt a návratový typ není přesně definován, je vrácen jako prázdný prostorový objekt bod Mezi prázdnými prostorovými objekty lze provádět implicitní i explicitní přetypování Řešení – zavedení typu prázdný objekt

Operace na prostorových objektech Průnik Sjednocení Relace „sousedí“ Objekt A sousedí s objektem B Relace „obsahovat“ Objekt A obsahuje objekt B Vzdálenost dvou objektů …

Typické dotazy Najdi všechna města vzdálená od Londýna nejvíce 50 km Najdi 5 nejbližších měst k Londýnu Najdi všechny dvojice měst, která jsou do sebe vzdálena nejvýše 200 km Najdi mi všechny budovy, které sousedí s vlakovým nádražím

Metody definované na prostorových datových typech Rozděleny do čtyř základních kategorií: Konverze prostorových objektů do/z externích datových formátů Práce s atributy prostorových objektů Porovnávání prostorových objektů Generování nových prostorových objektů Pro jednotlivé třídy jsou specifikovány metody. Na úrovni Geometry to jsou základní metody, např. Dimension, Boundary, a metody pro porovnání objektů Equals, Disjoint, Intersects, Touches, Crosses, Within, Contains, Overlaps, Relate. Výsledkem metody pro porovnání je 1 v případě, že výsledek porovnání je TRUE. Některé metody nejdou přesně zařadit: ST_StartPoint – vrací atribut objektu a zároveň generuje objekt nový

Konverze do/z externích datových formátů SQL/MM standard definuje tři implementačně nezávislé externí datové formáty pro reprezentaci prostorových objektů: Textová reprezentace Well-known text representation (WKT) Binární reprezentace Well-known binary representation (WKB) Geography markup language (GML)

Externí datové formáty Textová reprezentace point (10 10) multipolygon (((1 1, 2 2, 1 2, 1 1)),((10 10, 10 20, 20 20, 20 10, 10 10))) Binární reprezentace 0101000000000001010 GML má možná něco společného s XML.

Externí datové formáty Geography markup language

Konverze z externích datových formátů Pomocí konstruktorů prostorových datových typů Pouze z WKT a WKB reprezentace Z GML pomocí speciálních funkcí ST_LineFromGML, ST_MPointFromGML… Pro zpětnou kompatibilitu s OGC specifikací ST_PointFromText…

Konverze do externích datových formátů Tři metody ST_AsText ST_AsBinary ST_AsGML

Práce s atributy prostorových objektů Všechny prostorové datové typy mají nějaké společné atributy (př. dimenze) Každý podtyp v SQL geometrickém modelu si přidává další, jemu specifické, atributy Př. Polygon – plocha, kterou zabírá

Příklady metod ST_Boundary ST_IsEmpty ST_X ST_Length Vrací hranici prostorového objektu ST_IsEmpty ST_X Vrací X-ovou souřadnici bodu ST_Length Vrací délku křivky Ve třídě např. Curve nalezneme metody pro výpočet délky křivky (Length), počáteční a koncový bod (StartPoint, EndPoint), test na uzavřenost (IsClosed) a na kružnici (IsRing).

Porovnávání prostorových objektů ST_Equals Test na prostorovou rovnost dvou objektů ST_Intersect, ST_Crosses, ST_Overlaps Test na prostorový průnik dvou objektů ST_Touches Test, jestli se objekty dotýkají hranicemi, ale neprotínají se ST_Within, ST_Contains Test, jestli jeden objekt obsahuje jiný

Porovnávání prostorových objektů Metody pro porovnávání objektů jsou založeny na binárních prostorových predikátech Všechny výše uvedené metody vracejí 1 pokud je příslušná relace splněna (TRUE), jinak vrací 0 Další metody ST_Distance

Binární prostorové predikáty

Rozdíl mezi predikáty contains a covers A covers B nabývá TRUE, když interior(B) Ì interior(A) a současně boundary(A) Ç boundary(B) ¹ Æ A contains B nabývá TRUE, když interior(B) È boundary(B) Ì A

Generování nových prostorových objektů Nové objekty mohou být výsledkem provedení nějaké operace na množině stávajících objektů ST_Intersection ST_Union ST_Difference

Generování nových prostorových objektů Mohou být získány pomocí nějakého algoritmu provedeného na jeden objekt ST_Buffer („nárazníková“ zóna) ST_ConvexHull (konvexní obal) ST_Envelope Vrací minimální ohraničující obdélník (MOO) k danému objektu

Přehled metod ST_Geometry ST_Point ST_LineString ST_CircularString ST_CompoundCurve ST_CurvePolygon ST_Polygon ST_GeomCollection ST_MultiPoint ST_MultiLineString ST_MultiPolygon ST_AsText ST_AsBinary ST_AsGML ST_Transform ST_Dimension ST_CoordDim ST_GeometryType ST_SRID ST_IsEmpty ST_IsSimple ST_IsValid ST_Boundary ST_Envelope ST_ConvexHull ST_Buffer ST_Intersection ST_Union ST_Difference ST_SymDifference ST_X ST_Y ST_Length ST_StartPoint ST_EndPoint ST_IsClosed ST_IsRing ST_NumPoints ST_PointN ST_NumCurves ST_CurveN ST_Area ST_Perimeter ST_Centroid ST_PointOnSurface ST_ExteriorRing ST_InteriorRings ST_NumInteriorRing ST_InteriorRingN ST_Distance ST_Equals ST_Relate ST_Disjoint ST_Intersects ST_Touches ST_Crosses ST_Within ST_Contains ST_Overlaps

Rozšiřování SQL geometrického modelu Při rozšiřování geometrického modelu o nový datový typ je třeba vytvořit ještě další typ reprezentující množinu objektů takového typu Viz např. ST_Polygon a ST_MultiPolygon

Nedostatky SQL geometrického modelu Mějme následující dotaz: SELECT ST_Intersection(ST_Polygon( ‘polygon((10 10, 10 20, 20 20, 20 10, 10 10))’, 1), mnozina_bodu) FROM tabulka WHERE … Sloupeček mnozina_body obsahuje hodnoty typu ST_MultiPoint

Nedostatky SQL geometrického modelu Výsledek dotazu může být Prázdný objekt Jeden bod (ST_Point) Množina bodů (ST_MultiPoint) Jeho získání ale není triviální, neboť ST_Point a ST_MultiPoint se nachází v různých větvích geometrického modelu a tudíž můžeme použít pouze obecných metod definovaných v ST_Geometry

Nedostatky SQL geometrického modelu Řešení problému Modifikace geometrického modelu

Modifikovaný geometrický model A similar idea was apparently the bases for the type hierarchy implemented in the SpatialWare DataBlade for IDS product [Map02]. The DB2 Spatial Extender denes a type hierarchy exactly as in the standard, but it omits some of the optional data types [IBM02]. And yet a third approach to handle geometries stems from the Oracle 9 support for strong typing based on the geometries can be enforced in such an environment, but other means have to be used.

Diskuse k metodám Chybí konstruktory využívající GML Řešení: Využití WKT konstruktorů Chybí podpora dalších důležitých externích formátů Př. „shape format“ The standard denes constructor methods that can handle well-known text (WKT) and well-known binary (WKB) representations. It does not allow for a handling of the GML representation in a constructor, however. The existing constructor methods for the wellknown text representation could be reused for that, given that WKT and GML are both a textual representation for geometries and can easily be distinguished be analyzing the very rst non-whitespace character. The functions like ST PolyFromGML could then be removed. They are not dened in the OGC Simple Feature specication, so that compatibility issues do not arise. Another omission can be found in the support for external data formats. The de-facto industry standard to represent geometries is the so-called shape format [ESR97]. The shape format is not supported by the standard, but it should be considered given that existing major products already support it [IBM02, IBM01].

Diskuse k metodám Některé metody poskytují téměř stejnou funkcionalitu ST_Intersects ST_Crosses ST_Overlaps There are several groups of methods that provide (nearly) identical functionality. For example, the methods ST Intersects, ST Crosses, and ST Overlaps all test for intersections of the interiors of the two input geometries. The only difference between the methods is that ST Crosses does not allow to test if a surface intersects some other geometry, or if some other geometry intersects a point. ST Overlaps requires that both geometries to be compared have the same dimension. For example, a line can overlap another line but not a polygon. ST Intersects is the generalized version of the functionality to test for the overlay of geometries. It does not impose any restrictions in its input parameters. The existence of ST Crosses and ST Overlaps is rather questionable.

Příklady

Příklad 1: Pojišťovna

Pojišťovna Pojišťování budov v záplavových oblastech

Pojišťovna CREATE TABLE reky { nazev VARCHAR(30) PRIMARY KEY, mnozstvi_vody DOUBLE PRECISION, koryto ST_LineString, zaplavova_oblast ST_MultiPolygon ) CREATE TABLE budovy { zakaznik VARCHAR(50) PRIMARY KEY, ulice VARCHAR(50), mesto VARCHAR(20), zip VARCHAR(10), pozemek ST_Polygon

Pojišťovna Rozšíření záplavové oblasti řeky FLOOD o 2 km ve všech směrech UPDATE reky SET zaplavova_oblast = zaplavova_oblast.ST_Buffer(2, ‘KILOMETER’) WHERE nazev=‘FLOOD’

Pojišťovna Najdi všechny zákazníky, jejichž budovy se nachází v záplavové oblasti řeky FLOOD SELECT zakaznik, ulice, mesto, zip FROM budovy AS b, reky AS r WHERE b.pozemek.ST_Within( r.zaplavova_oblast) = 1

Příklad 2: Banka

Banka Síť poboček Každý zákazník může mít založen jeden, nebo více účtů Všechny účty jednoho zákazníka jsou spravovány právě jednou pobočkou

Banka CREATE TABLE zakaznici { id INTEGER PRIMARY KEY, jmeno VARCHAR(20), ulice VARCHAR(25), město VARCHAR(10), stat VARCHAR(2), zip VARCHAR(5), typ VARCHAR(10), lokace ST_Point )

Banka CREATE TABLE pobocky { id INTEGER PRIMARY KEY, nazev VARCHAR(12), manager VARCHAR(20), ulice VARCHAR(20), mesto VARCHAR(10), stat VARCHAR(2) zip VARCHAR(5), lokace ST_Point, oblast ST_Polygon )

Banka CREATE TABLE ucty ( id INTEGER PRIMARY KEY, id_vlastnika INTEGER NOT NULL, id_pobocky INTEGER NOT NULL, typ VARCHAR(10) NOT NULL, zustatek DECIMAL(14, 2) NOT NULL, CONSTRAINT fk_zakaznici FOREIGN KEY(id_vlastnika) REFERENCES zakaznici(id), CONSTRAINT fk_pobocky FOREIGN KEY(id_pobocky) REFERENCES pobocky(id) )

Banka Najdi všechny zákazníky se zůstatkem na účtu větším než $10 000, a kteří bydlí dále jak 20 mil od příslušné pobočky, která jim účet spravuje SELECT DISTINCT z.id, z.jmeno FROM zakaznici AS z JOIN ucty AS u ON (z.id=u.id_vlastnika) WHERE u.zustatek > 10000 AND z.lokace.ST_Distance((SELECT p.lokace FROM pobocky AS p WHERE p.id=u.id_pobocky), ‘MILES’) > 20

Banka Najdi všechny dvojice poboček, jejichž oblasti působnosti se překrývají SELECT p1.id, p2.id, p1.oblast.ST_Overlaps(p2.oblast). ST_AsText() FROM pobocky AS p1 JOIN pobocky AS p2 ON (p1.id < p2.id) WHERE p1.oblast.ST_Overlaps(p2.oblast). ST_IsEmpty() = 0

Banka Najdi všechny zákazníky, kteří bydlí v okruhu 10 mil od nějaké pobočky, která nespravuje jejich účty SELECT z.jmeno, p.id FROM pobocky AS p, zakaznici AS z WHERE p.lokace.ST_Buffer(10, ‘MILES’).ST_Contains(z.lokace) = 1 AND NOT EXISTS (SELECT 1 FROM ucty AS u WHERE u.id_vlastnika = z.id AND p.id = u.id_pobocky) Vylepšení dotazu: a zároveň je vzdálenost ke stávající pobočce, která spravuje jejich účty, větší

Datový katalog

Pohledy (VIEWS)

ST_GEOMETRY_COLUMNS Záznamy o všech sloupcích (atributech), které jsou deklarovány jako prostorový datový typ Ke každému sloupci může být přidružen patřičný souřadnicový systém

ST_GEOMETRY_COLUMNS Jeden záznam pohledu se skládá z Identifikátoru sloupce (atributu) Katalog Schéma Tabulka Název sloupce Identifikátoru souřadnicového systému Název souřadnicového systému Numerický identifikátor

ST_SPATIAL_REFERENCE_SYSTEMS Informace o definovaných souřadnicových systémech A spatial reference system has two unique identiers, a name and a numeric identier. The name is used in the same way as for all other SQL objects like schemata, functions, or columns. The numeric identier is used in the methods that require the SRS information as input, for instance to construct a geometry in a specic SRS or to transform a geometry to another SRS.

ST_UNITS_OF_MEASURE Informace o matematických jednotkách využívaných při výpočtech vzdálenosti dvou objektů, délky křivky… Káždá jednotka má Název (KILOMETER, RADIAN..) Typ (úhlová, délková) Konverzní faktor vůči základní jednotce daného typu

ST_SIZINGS Různé meta-proměnné a jejich hodnoty Př. ST_MaxGeometryAsText Maximální délka textové reprezentace (WKT) prostorového objektu

Diskuse k datovému katalogu ST_SPATIAL_REFERENCE_SYSTEMS Celkem primitivní Práce na propracovanější organizaci souřadnicových systému (EPSG - The European Petrol Survey Group) ST_SIZINGS Podobný pohledu SIZING definovanému v SQL99 The view ST SIZINGS has the same intention as the view SIZINGS dened in SQL99 [ISO99], only specialized for the facilities in SQL/MM Spatial. If SQL99 would provide a mechanism for implementations of other standards, including SQL/MM to add new entries to its view, then ST SIZINGS becomes obsolete and could be removed from the SQL/MM standard. Unfortunately, SQL99 does not describe the requested mechanisms, so both views are still necessary.

Závěr

Produkty IBM DB2 Spatial Extender IDS Spatial DataBlade Oracle 9i Spatial Jako příklady implementace alternativ (1) a (3) lze uvést prostorové moduly ORACLE 8 (pomocí SQL92) a ORACLE 8i (pomocí objektově relačního přístupu (Pozn.: Další pionýrskou implementací OGC specifikace byl Spatial Database Engine (SDE) vytvořený pracovištěm ESRI (Environmental Systems Research Institute) a využity pro Spatial Extender v SŘBD DB2.).) Informix využívá pro řízení prostorových objektů technologii DataBlade firmy Illustra. K dispozici jsou moduly pro 2D a 3D. Modul 2D přidává 10 datových typů, popisují společné planární geometrické tvary a polygony, spolu s více než 200 funkcemi, které dovolují vytváření objektů, jejích porovnávání, manipulaci a dotazování. Modul 3D přidává 18 datových typů, jako jsou kruhy, krychle, linie, polygony a plochy spolu s více než 1 000 funkcemi. Illustra využívá možností SQL:1999, tj. funkce a typy jsou plně integrovány do SQL. Co se týče indexace prostorových objektů implementace je založena na R-stromech (viz např. [Po99]), jak ve 2D, tak ve 3D. DB2 extender vznikl společným úsilím IBM a ESRI, jednou z vůdčích organizací pro tvorbu GIS software. Z hlediska architektury umožňuje tento extender zpracovávat jednotným způsobem prostorová data uložená nejen v databázi DB2, ale i v dalších zdrojích. Softwarově těží opět z možností, které nabízí objektově relační přístup.

Shrnutí SQL-MM Spatial Připravuje se druhá verze standardu Standardizuje ukládání, výběr, dotazování a aktualizaci prostorových objektů Definuje množinu typů a metod pro reprezentaci 0, 1 a 2 dimenzionálních prostorových objektů Připravuje se druhá verze standardu This paper described the facilities dened in the standard, and discussed them critically. The implemented type hierarchy is suitable for its purpose, but together with the strong typing and the set-oriented data management imposed be SQL, it inconveniences the spatial data processing. The methods provided for each type cover a wide range of spatial functionality. The multitude of methods lead to the situation where functionality is already duplicated (with very minor differences). Some future directions of the SQL/MM Spatial standard already show in the new working draft that was started recently and will eventually become the third version of the standard. The Japanese standards committee supplied a change proposal that adds a function ST ShortestPath, which calculates the shortest path in a network (or graph) of linestrings between two given points.

Literatura K. Stolze: SQL/MM Spatial:The Standard to Manage Spatial Data in Relational Database Systems http://www.btw2003.de/proceedings/paper/68.pdf J.Pokorný: Prostorové objekty a SQL http://gis.vsb.cz/Publikace/Sborniky/GIS_Ova/gis_ova_2001/sbornik/Referaty/pokorny.htm

Obsah Úvod Část 1: Framework Část 2: Full-Text Část 3: Spatial Část 4: General Purpose Facilities Část 5: Still Image Část 6: Data Mining

General Purpose Facilities Pokus o množinu tříd pro hlavní matematické operace Tato část ze standardu prozatím vypadla Vysoké náklady Málo uživatelů Ze standardu SQL/MM alespoň prozatím vypadla část, která se měla pokusit o množinu tříd pro obecné (hlavní) matematické operace. Je to proto, že by tato část využilo příliš málo uživatelů na úkor velikých nákladů na jeho vývoj. Proto byl vývoj části SQL/MM General Purpose Facilities /*Hlavní účel/smysl vybavení/příslušenství*/ na několik let odložen.

Obsah Úvod Část 1: Framework Část 2: Full-Text Část 3: Spatial Část 4: General Purpose Facilities Část 5: Still Image Část 6: Data Mining

Still Image > Úvod Obrázky = hodnotná data Ukládání obrázků Úprava obrázků Vyhledávání obrázků (dle vizuálních vlastností) Jedno z nejrychleji se vyvíjejících odvětví výpočetních aplikací je ukládání a zpracování obrázků. Mnoho společností vynakládá obrovské množství zdrojů na získávání, ukládání a správu kolekcí obrázků včetně grafiky, maleb a fotografií. Tato data mají často velikou peněžní hodnotu a jejich získání často znamená vynaložit nemalé výdaje. Jedním z podnětných aspektů pro manipulaci s těmito daty je možnost vyhledávání obrázků. SQL/MM Still Image se snaží řešit část této problematiky. Tato část SQL/MM standardu poskytuje strukturované uživatelsky definované typy, které nám umožňují ukládat obrázky do databáze, znovu je získávat, různě je upravovat, ale co je nejdůležitější, vyhledávat obrázky promocí různých popisů visuálních vlastností. Jistě, ne všechny obrázky jsou „still“ – stálé. Dalším oborem jsou „pohybující se“ obrázky, jako například digitální video. Tato data nejsou zachycena ve standardu SQL/MM Still Image, ale pravděpodobně se na ně část SQL/MM v budoucnu bude orientovat.

Still Image > Typy SI_StillImage SI_Feature SI_FeatureList Pro obrazová data SI_Feature Nadtyp pro různé vlastnosti obrázku (dále) SI_FeatureList Seznam pro (všechny) vlastnosti obrázku

Still Image > SI_StillImage (1) Konstruktory BLOB BLOB + Formát (JPEG, TIFF, GIF, …) Metody pro přeformátování (SI_changeFormat) Vytvoření miniatury („Thumbnails“) Změna velikosti Ořezávání Rotace … V SQL/MM Still Image jsou obrázky reprezentovány promocí SQL:1999 strukturovaného typu nazvaného „SI_StillImage“. Tento typ ukládá soubor pixelů reprezentujících dvou-dimenzionální obrázek. Obrázky mohou být uloženy několika formátech (záleží na jednotlivých podporách v implementaci). Například JPEG, TIFF či GIF jsou běžně podporovány jako vstupní i výstupní formáty. Metody pro typ SI_StillImage umožňují změnu velikosti obrázku, ořezávání, rotaci či vytvoření miniatury obrázku.

Still Image > SI_StillImage (2) create type SI_StillImage as ( SI_content binary large object(SI_MaxContLength), SI_contentLength integer, SI_format character varying(8), SI_height integer, SI_width integer, … ) SI_StillImage obsahuje kromě příslušného souboru pixelů navíc informace o formátu obrázku, jeho rozměrech, barevné hloubce atd.

Still Image > SI_Feature (1) Užitečné pro vyhledávání Typ SI_Feature má tyto podtypy SI_AvarageColor SI_ColorHistogram SI_PositionalColor SI_Texture Všechny vlastnosti mají metodu SI_Score, která spočítá podobnost vlastností obrázků a vrátí realnou hodnotu mezi 0 a 1 Další skupina typů umožňuje zachytit další rysy obrázků (Tyto rysy lze potom použít při vyhledání obrázku dle jeho popisu). Typ SI_AvarageColor se používá k reprezentaci „průměrné“ barvy daného obrázku. Typ SI_ColorHistogram poskytuje informaci o všech barvách a jejich množství v obrázku. Typ SI_PositionalColor reprezentuje umístění určité barvy v obrázku. To umožňuje dotazy typu: „Hledám obrázek s oranžovou a červenou barvou nad tmavě modrou barvou“ (Hledám-li obrázky se západem slunce.). Typ SI_Texture umožňuje zaznamenat informace jako: hrubost, kontrast, směrnice granularity. Pomocí kombinování několika rysů hledaného obrázku, lze často z velikého množství obrázků vybrat podstatně menší skupinu obrázků, kde již se snadnější ručně dohledat požadovaný obrázek.

Still Image > SI_Feature (2) create type SI_AverageColor under SI_Feature (SI_AverageColorSpec SI_Color) method SI_AverageColor ( RedValue integer, GreenValue integer, BlueValue integer) returns SI_AverageColor create function SI_AverageColor (image SI_StillImage)

Still Image > Příklad > dotaz SELECT * FROM Registrovaná_loga WHERE SI_findTexture(Naše_logo). SI_Score(Logo) > 0.9; Příklad dotazu: Chceme zjistit, zda naše „nové“ logo firmy nebude v konfliktu s logy, která mají již ochranou známku (copyright). select * from Logos where SI_FeatureList ( SI_Texture (SI_StillImage(:bspLogo)), 0.8 ).SI_Append ( SI_ColorHistogram (SI_StillImage(:bspLogo)), 0.2 ).SI_Score (Logo) > 0.7

Obsah Úvod Část 1: Framework Část 2: Full-Text Část 3: Spatial Část 4: General Purpose Facilities Část 5: Still Image Část 6: Data Mining

Data Mining > Úvod Aplikační balíček Data Mining Analýza (často rozsáhlých) observačních dat s cílem nalézt netušené vztahy a sumarizovat data novými způsoby tak, že jsou srozumitelná a užitečná pro jejich majitele. Do této chvíle jsme se bavili o částech SQL/MM přímo orientovaných na multimediální data (Full-Text, Spatial, Still Image), ale plný název SQL/MM zní „SQL Multimedia and Application Packages“. Již roku 2000 byla započata práce na nové části SQL/MM, která se nezabývá správou multimediálních dat, ale na místo toho definuje aplikační balíček. SQL/MM Data Mining definuje SQL strukturované uživatelské typy, včetně metod na těchto typech, pro využití v důležité součásti moderní správy dat – Data Miningu. David Hand, Heikki Manilla, Padhraic Smyth Principles of Data Mining, MIT 2001: Data Mining je analýza (často rozsáhlých) observačních dat s cílem nalézt netušené vztahy a sumarizovat data novými způsoby tak, že jsou srozumitelná a užitečná pro jejich majitele. Data Mining není nový pojem. Mnoho společností již dlouho chtělo použít nastřádaná data nejenom pro běžné účely, ale také jako zdroj dat pro získání zajímavých informací například o svých zákaznících. Běžné aplikace se dotazují na data splňující daná kritéria. Naproti tomu, dataminingové zařízení se dotazuje na hypotézy, která jsou na daných datech zajímavá. Například lze takto zjistit, takovou hypotézu, že polovina lidí, kteří si kupují dětské plenky a pivo si koupí také osvěžovač vzduchu. V praxi se například můžeme ptát, jaký typ zákazníka je pro naši firmu ten nejdůležitější. Tj. které atributy nejlépe vystihují tohoto zákazníka. (První část dotazu by nebyla neřešitelná bez dataminingu, ale ta druhá část jen těžko.) Mnoho, relativně malých, ale významných, společností v devadesátých letech minulého století vytvořilo dataminingové nástroje, některé založené na relačních databázových systémech, ale většina těchto nástrojů vyžadovala import dat a jejich následnou reorganizaci do struktur specifických pro příslušný dataminingový nástroj. SQL/MM Data Mining přistupuje k této problematice odlišně. Snaží se poskytnout standardizované rozhraní (interface) pro dataminingové algoritmy, které mohou být navrženy nad objektově-relačním DB systémem, dokonce i jako middleware.

Data Mining > Techniky RULE MODEL Hledá pravidla a vztahy v datech. CLUSTERING MODEL Slučuje data do skupin s podobnými charakteristikami. REGRESSION MODEL Předvídá klasifikaci nově pořizovaných dat. CLASSIFICATION MODEL Předvídá klasifikaci (způsob shlukování), která bude nejlépe odpovídat novým datům. Ve standardu SQL/MM Data Mining jsou podporovány čtyři různé dataminingové techniky. RULE MODEL umožňuje hledat pravidla a vztahy mezi částmi dat. CLUSTERING MODEL pomáhá slučovat data, která mají podobné charakteristiky do skupin. REGRESSION MODEL pomáhá předvídat klasifikaci nově pořizovaných dat, dle existujících dat. CLASSIFICATION MODEL je velmi podobný regression modelu, ale je orientovaný na předvídání klasifikace (způsob shlukování) bude nejlépe odpovídat novým datům.

Data Mining > Stupně DM Vytvoření (train) DM modelu Testování modelu (u regression a classifiation technik) Aplikace na primární data Pro všechny tyto techniky existují tři stupně dataminingu, které můžeme využít. Nejdříve se musí dataminingový model natrénovat (TRAIN). To znamená vybrat nejvhodnější metodu pro dosažení cílů, nastavit vhodné parametry této metody a konečně „natrénovat“ model na cvičné množině dat. Potom, používáme-li classification nebo regression techniky, můžeme testovat model jeho aplikací na známa data a porovnávat výsledné „předpovědi“ se známými klasifikacemi našich dat. Konečně, aplikujeme vytvořený model na „primární“ data.

Data Mining > Typy DM_*Model (Definice modelu) * ≈ ‘Rule’, ‘Clus’ , ‘Clas’ nebo ‘Reg’ DM_*Setting (Nastavení modelu) DM_MiningData (Testování modelu) DM_*TestResult (Výsledek testování modelu) DM_*Result (Výsledek aplikace modelu) DM_*Task (Řízení běžícího modelu) Typ DM_*Model se používá pro definování modelu, který chceme použít pro dobývání znalostí z dat (kde * je buď ‘Clas’ pro classification model, ‘Rule’ pro rule model, ‘Clus’ pro clustering model a nebo ‘Reg’ pro regression model). Modely jsou parametrizovány instancemi typu DM_*Setting. Tyto typy dovolují nastavovat řadu parametrů modelu, Jako například hloubku rozhodovacího stromu apod. Modely jsou natrénovány (train) užitím instancí typu DM_ClassificationData. Jakmile byl model vytvořen a natrénován, může být testován užitím instancí typu DM_MiningData. Výsledkem testování modelu na datech je jedna nebo více instancí typu DM_*TestResult (kde * je buď ‘Clas’ nebo ‘Reg’). Při běhu modelu na reálných datech jsou výsledkem instance typu DM_*Result (kde * je buď ‘Clas’ nebo ‘Clus’ nebo ‘Reg’, ale ne ‘Rule’). Ve většině případů lze také vytvořit instance typu DM_*Task k řízení aktuálních, testujících a běžících modelů.

Závěr Budoucnost SQL/MM SQL/MM General Puropose Facilities SQL/MM Moving Images V době sepsání zdrojového článku: Ne všechny části SQL/MM byli komerčně úspěšné, ale z dá se, že roste podpora Full-Text a Spatial u několika důležitých společností (Oracle, … apod). Zdá se, že podpora Still Image roste poněkud pomaleji oproti očekávání. O úspěšnosti balíčku Data Mining se ve zdrojovém článku nehovořilo, protože tato část standardu v době vzniku tohoto článku ještě nebyla uvolněna. Podpora dalších datových typů (například Moving Images) záleží na mnoha faktorech, zejména na zájmu technické komunity o taková data.

Zdroje SQL/MM Spatial: The Standard to Manage Spatial Data in Relational Database Systems http://www.btw2003.de/proceedings/paper/68.pdf SQL Multimedia and Application Packages (SQL/MM) http://dbs.uni-leipzig.de/en/lehre/sql-multimedia-2001-records.pdf Oracle® Spatial User's Guide and Reference: SQL Statements for Indexing Spatial Data https://cwisdb.cc.kuleuven.ac.be/ora10doc/appdev.101/b10826/sdo_objindex.htm http://wwwdvs.informatik.uni-kl.de/courses/MMDB/WS2003/Vorlesungsunterlagen/SQL-MM.half.pdf (nemecky)

Otázky?