Využijeme-li pro ukládání dat nějakého DBMS, získáváme možnost data ukládat v nějakém datovém modelu, zde je jejich přehled.
Tento model organizuje data ve stromové struktuře, tj. jeden rodič má hodně dětí (
),
jsou tedy možné vztahy 1:1 a 1:N.
Jeho výhodou je,že umožňuje velice rychlé vyhledávání.
Jeho nevýhodou je to, že je vhodný pouze pro aplikace se stabilní strukturou, tam kde se primární vztahy mezi daty mění jen velice málo. Proto se v GIS příliš nepoužívá. Pokud například do modelu, který je zobrazen na (
),
budeme chtít přidat organizace, které sdružují více států, např: EU, OSN, NATO (
),
dostáváme se v tomto datovém modelu do problémů hned ze dvou důvodů. Za prvé třeba pro světadíl Antarktida žádná takováto organizace neexistuje, protože tam nejsou žádné státy. Druhý problém je, že výše jmenované organizace mohou působit na více světadílech a dostáváme se k otázce, zda má být ve vyšší hierarchické úrovni typ entity světadíl, či organizace.
Podobně jako hierarchický model, se tento model příliš neosvědčil, proto se jím nebudeme dále zaobírat.
Organizuje data do tabulek. Každá tabulka má položku primární klíč, která je unikátní tj. jednoznačně identifikuje položku (entitu). Díky klíčům je možné logicky spojovat více tabulek - vytvářet relační vztah (relaci) 1:1, 1:N, M:N. Pro odstranění redundance (duplicity dat) se při návrhu struktury používá tzv. normalizace - ale o tom více v předmětu KIV/DB1.
Výhody:
Protože stručný a přehledný popis relačních databází lze nalézt např. v diplomové práci Ing. Lucie Vokounové (kap. 2 - Úvod do databází), která je dostupná na našem WWW serveru v adresáři
http://gis.zcu.cz/studium/dp/2003/
a protože relační model je v GIS velmi používaný, doporučuji vám, abyste tuto kapitolu prostudovali. Z téhož důvodu je zde uveden jen stručný přehled.
Vychází z objektově orientovaného programování, kde jsou data spravována jako objekty, což více přibližuje model reálnému světu.
Pro každý objekt, jsou popisovány nejen jeho vlastnosti (atributy), ale i způsob jeho chování (metody).
Příklad: meteorologická stanice má atribut teplotu a rekordní teploty (tmin, tmax). Když teplota překročí nějaký rekord - mezní hodnotu, jsou automaticky aktualizovány i atributy rekordních teplot - informace o chování objektu (metoda).
Je možné vytvářet složitější objekty z jednodušších, říkáme, že potomek dědí vlastnosti a chování po rodiči + přidává svoje vlastní.
Příklad: z meteorologické stanice pro teploty můžeme vytvořit (děděním) meteorologickou stanici pro srážky a teploty. V relačním modelu je tohle obtížné a časově náročné.
Jednotlivé objekty mezi sebou komunikují pomocí zpráv.
Příklad: meteorologická stanice v Plzni zjistí rekordní teplotu pro Plzeň (a nastaví podle toho své atributy). Zároveň zašle zprávu centrální meteorologické stanici pro ČR o této události. Centrální stanice vyhodnotí, jestli jde o rekordní teplotu v celé republice a podle toho nastaví své vlastní atributy.
Objekty stejných vlastností (např. meteorologické stanice v Krkonoších, na Šumavě) jsou popsány jako třída objektů (class). Konkrétní meteorologická stanice - individuální objekt se pak nazývá instancí této třídy.
Výhody:
Nevýhody:
Po vyhodnocení všech výhod a nevýhod objektového a relačního modelu nakonec vznikl objektově-relační model, který zachovává všechny výhody relačního modelu a přidává výhody objektového modelu. Dnes je objektově-relační model používán u většiny velkých databází (Oracle 8i, Informix, …).