3. Datové struktury a databáze

3.1 Organizace dat, báze dat

Organizace dat je jisté uspořádání dat, které má za účel umožnit efektivní zpracování dat potřebných pro aplikace. Zahrnuje postupy a metody, jak data na médiích ukládat a jak je hledat. Tyto postupy a metody jsou soustředěny v programech, které požadované akce provádí. Programy mají tři úrovně:

• Základní systémová úroveň, kterou realizují komponenty operačního systému pro všechny uživatelské programy jednotně. Záznam a hledání dat podléhá fyzickým charakteristikám jednotlivých médií a proto se tato úroveň nazývá fyzická úroveň (dat, záznamu, organizace apod.).
• Úroveň báze dat. Jde o maximálně obecné, avšak většinou na jediný typ databázové struktury zaměřené programové systémy. Poskytují především možnost definice struktury záznamu (z jakých polí se záznam skládá, označení, zda jde o pole klíčové nebo hodnotové apod.), aktualizace dat (co do množství, kvality i struktury), a získávání informací na základě zadaných specifikací. Základní funkcí bází dat je záznam a čtení takto nadefinovaných struktur na fyzické úrovni (tj. komunikace s programy systémové úrovně). Dále poskytují možnost provádění vazeb mezi jednotlivými soubory a výběr dílčích datových polí z takto provázaných souborů. Tato úroveň se nazývá logická úroveň.
• Uživatelská úroveň. Báze dat jsou zcela postačující systémy pro veškeré požadavky uživatelů na zpracování dat. Pro svou obecnost však kladou na běžné uživatele značné nároky na zvládnutí formalizovaného způsobu jejich ovládání. Proto báze dat poskytují prostředky, jak vytvořit rozhraní mezi obecnou bází dat a specializovanou potřebou toho kterého uživatele. Těmito prostředky jsou většinou programovací jazyky různých syntaxí, ale vždy se zajištěnou možností použít kteroukoliv z funkcí báze dat. Databázoví specialisté ve spolupráci s odborníky různých oblastí pak pomocí daného programovacího nebo dotazovacího jazyka vytváří uživatelské, účelově orientované programy, které sice neposkytují možnost kdykoliv použít jakoukoliv funkci báze dat, ale zato uživatel pracuje v prostředí své odbornosti, ve kterém se dobře orientuje především terminologicky.

3.2 Koncepce báze dat

Výklad je zaměřena na úroveň báze dat a případné vztahy k úrovni systémové tak, aby byly jasně vidět aspekty zvláště bází nejrůznějších geodat v moderních systémech. K vytváření bází dat vedly potřeby nesmírně dynamického rozvoje nových technologií umožňujících koncentraci a zpracování dat kvantity a kvality dříve nevídané (viz např. už jen družicové informace z nejrůznějších oblastí: geografie, geofyzika, strukturní geologie, environmentální inženýrství apod.).

3.2.1 Klasické metody

Klasické metody zpracování dat většinou nelze na data takového rozsahu a provázanosti aplikovat. Především mají principielní nevýhody a s růstem množství dat jsou stále méně efektivní. Jsou založeny na následujících principech:

• Data jsou uložena v souborech. Soubor se skládá ze záznamů.
• Záznam se skládá z jednotlivých datových polí. Často má jedno nebo více polí identifikační význam a tvoří pak klíč záznamu. V takovém případě bývají soubory uspořádány ve vzrůstající posloupnosti hodnot klíčů a při každé změně klíčového pole a přidání nebo vypuštění záznamu je nutno soubor fyzicky přeorganizovat.

Organizace souborů (jejich struktura) je dána potřebou konkrétních programů, které je používají. Programátor takových programů nejprve zjistí, jaká data jsou k disposici, jaká data na jejich základě je nutno odvodit, a podle toho navrhne strukturu souborů, která je z jeho subjektivního hlediska optimální.

V každém takto vytvořeném programu je tedy přesně udáno, které soubory se mají pro zpracování použít, jaká je jejich přesná interní struktura, a jaké informace z nich mají tvořit požadované výsledné informace. Takový klasický způsob zpracování dat má mnoho nevýhod; mezi nejvýraznější patří:

• Během jednotlivých kroků při zpracování dat vzniká množství různých souborů. Je obtížné udržet přehled o jejich jménech, obsahu, formě, době platnosti ap. všech existujících souborů.
• Velké množství souborů vede k tzv. redundanci dat: tatáž data jsou uložena na několika různých místech. Při aktualizaci takového údaje je nutno provést aktualizaci na všech místech jeho výskytu, což je náročné jednak časově a jednak organizačně.
• Velké obtíže nastávají při potřebě použít soubory se strukturou definovanou na míru dané aplikaci v jiných programech, které vyžadují strukturu jinou. Programy pro přeorganizování dat (zvláště pro změnu logické struktury) se svou složitostí mohou blížit samotným zpracovávajícím aplikacím.
• Jestliže je pro nějaký soubor opodstatněné vést dva nebo více nezávislých klíčů, je zapotřebí při přechodu od zpracování podle jednoho ke zpracování podle druhého provést jeho fyzické přeorganizování.

Právě při fyzickém přeorganizovávání objemných souborů může vznikat několik dočasných souborů, které zahltí kapacitu médií.

3.2.2 Báze dat

Koncepce bází dat se snaží tyto nevýhody odstraňovat. Používají přitom následující metody:

1. Sdružují a provazují data souborů.
2. Oddělují popis struktury dat od dat samotných a od zpracovávajících programů.
3. Přistupují k jednotlivým údajům zvláštní programovou vrstvou, nikoliv přímo jednotlivými uživatelskými programy.
4. Dávají možnost vyhodnotit uložená data jakýmkoliv způsobem. K uloženým datům umožňují současný přístup více uživatelů s jejich plnou vzájemnou ochrannou.

ad 1) Sdružování a provazování dat souborů znamená odstranění redundantních dat. Umožňuje spojování logicky navazujících souborů, ve kterých místo násobného přímého výskytu nějaké datové hodnoty udržuje ukazovátka (pointery) na jedinečné místo uložení této hodnoty.

ad 2) Oddělení popisu struktury od vlastních dat znamená, že kromě vlastních uložených dat jsou ukládány také informace o místě a způsobu jejich uložení. Tento popis může být fyzicky přítomen ve stejném souboru jako data, nebo v souboru samostatném. Jestliže se zpracovávající programy opírají o tyto popisy struktury, není zapotřebí programy měnit při reorganizaci vlastních dat.

ad 3) K vlastním datům nepřistupují aplikace přímo, ale žádají o jejich dodání obecně přístupné programové komponenty systému řízení báze dat. Provádí to většinou voláním podprogramů s parametry, kterými jsou popisy požadovaných dat získané z (od dat odděleného) popisu struktury.

ad 4) Zvláště v síťovém prostředí a při práci s citlivými informacemi je zapotřebí zajistit bezpečnost informací. Báze dat k tomu používají na jedné straně prověřování oprávněnosti přístupu pomocí seznamu uživatelů a jejich přístupových hesel a práv, na druhé straně mechanismus zamykání souborů, záznamů a polí dat. Tento aspekt zvláště vyniká v databázích realizovaných jako distribuované (tj. uložené ve více počítačových systémech).

Pro umožnění shora uvedeného musí být zajištěna

• fyzická nezávislost dat: fyzické uložení (např. délka bloku) může být změněno, aniž by bylo nutno přepisovat uživatelské aplikace;
• logická nezávislost dat: může být přidána položka nebo rozšířena logická struktura, aniž by to mělo vliv na existující aplikace;
• programová komunikace: musí být k disposici vhodné programové moduly systémů řízení báze dat pro dodávání dat do aplikací;
• uživatelská komunikace: musí být k disposici vhodný komunikační prostředek pro uživatele - nepočítačové odborníky; tím může být uživatelská aplikace, ale preferuje se obecný dotazovací jazyk nezávislý na použitém systému báze dat.

3.3 Soubor - záznam - pole

Z uživatelského hlediska je základní logickou jednotkou pole. Obsahuje hodnotu některého typu elementární informace (viz příslušná kapitola shora), fyzicky proto bývá uloženo na jednom nebo více bytech. Pole je charakterizováno atributy (typ pole, jeho délka, poloha desetinné tečky nebo čárky atd).

Jestliže více polí tvoří logický celek, tvoří tato pole segment. Segment sám nemusí být tvořen pouze poli, ale libovolnou posloupností polí a segmentů, je-li to potřebné nebo vhodné z hlediska logické struktury.

Segmenty, které k sobě logicky patří, tvoří záznam. Záznamy, které k sobě logicky patří, tvoří soubor. Soubory, které k sobě logicky patří, tvoří bázi dat.

Obr. 3.1: Segmentovaný soubor

Předchozí obrázek znázorňuje soubor s informacemi o podzemních vodách. Záznam je tvořen informacemi o jednom vrtu. Má šest segmentů: Kód vrtu, Poloha, Čerpadlo, ..., Chemismy. První segment je tvořen jediným polem. Segmenty Čerpání a Chemismy mají charakter násobného, opakujícího se segmentu, tj. mohou být přítomny vícekrát. Je samozřejmé, že - až na řídké výjimky - je počet záznamů v souboru vždy proměnný, stejně jako počet násobných segmentů v záznamu. Omezení shora je dáno především kapacitou média.

Některé typy organizace dat na systémové úrovni kladou další omezení na maximální počet záznamů v souboru (např. v systémech s pevným přidělením místa pro soubor) - musí být definován před vytvořením souboru. Některé systémy báze dat kladou další omezení na počet opakování segmentů - rovněž musí být definováno před vytvořením souboru.

3.3.1 Popis a výskyt

Příklad z předchozího odstavce uvádí pohled na "naplněný" soubor. Z tohoto pohledu je zřejmá nejen logická struktura souboru, ale i jeho obsah (kdyby bylo hodně místa na papíře). Pro potřeby vytváření a zpracování bází dat je však zapotřebí od sebe oddělit popis struktury (typy polí, segmentů ...) a výskyt dat (záznamu, segmentu ...).

Popis struktury stanovuje počet polí, jejich typ a pojmenování, komposici segmentů ap. Popis každého segmentu se tedy vyskytuje jen jednou. Avšak segment, který je popsán ve struktuře, se - zvláště u násobných segmentů - nemusí ve skutečném datovém záznamu vyskytnout ani jednou, nebo naopak se může vyskytnout několikrát, přitom u různých záznamů v různém počtu. To se týká např. segmentu Čerpání: po založení záznamu tento segment asi ještě zápis o čerpání mít nebude; ale čas od času přibude další záznam o čerpání tak, jak to stanoví provozní podmínky.

Je zřejmé, že popis struktury je zapotřebí formalizovat, a to jak na úrovni uživatele (=člověka), tak na úrovni aplikace (=programu). Různé systémy báze dat přijímají popisy struktur v různé syntaxi. Např. v hierarchickém modelu bývá používán popis, obdobný popisu souboru v jazyku Cobol.

3.3.2 Vztah mezi logickými a fyzickými záznamy

V předchozím odstavci je podána ukázka logického záznamu. Tak uživatel požaduje, aby se mu záznam jevil. Při klasickém způsobu zpracování (a pohříchu mnohde ještě přetrvávajícímu klasickému myšlení) je od logického k fyzickému záznamu velmi blízko - třebas až na úroveň totožnosti. V bázi dat je ovšem logický záznam budován až na požadavek uživatele.

Takové požadavky mohou být v různých situacích velmi rozmanité a v době vytváření databází ani nemusí být známy. Protože je požadováno jen jedno fyzické uložení jednoho údaje, nemusí být jednotlivá pole logického záznamu dokonce ani v jednom jediném fyzickém souboru: např. shora uvedený logický záznam může být komponován z údajů geologa (vrty a jejich poloha), údajů odběratele (čerpadla a čerpání) a údajů chemika (výsledky chemických analýz).

Obr. 3.2: Koincidence záznamů

Logické záznamy vytváří na přání uživatele aplikační programy (dotazovací jazyky) výběrem a organizací z fyzického záznamu. Logický záznam tedy může obsahovat

• části fyzického záznamu
• celý fyzický záznam
• více fyzických záznamů nebo jejich částí, přičemž tyto fyzické záznamy mohou a nemusí být součástí jednoho nebo více souborů.

Rozlišuje se tedy struktura organizace dat (vnější, uživatelský popis dat sloužící k vytváření logických záznamů), a struktura uložení dat (vnitřní, systémový popis dat fyzických záznamů). Organizace dat v bázi dat musí umožňovat právě spolupráci mezi uložením a organizací.

3.3.3 Lineární a nelineární záznamy

Lineární záznam je takový, jehož pole nejsou vzájemně podřízena. Například záznamy o čerpání vod z vrtů obsahující kód vrtu, datum, hladinu a sekundové množství jsou klasickým příkladem lineárních záznamů. Jednou z jejich charakteristik je např. to, že při návrhu struktury nezáleží na pořadí polí v záznamu.

Nelineární záznam je takový záznam, v němž může existovat vztah nadřazenosti a podřízenosti polím. K nejvýznamnějším a nejpoužívanějším nelineárním strukturám patří shora zmíněná hierarchická struktura. Příklad tamtéž uvedený lze graficky znázornit např. schématem obvyklým v teorii grafů, kde z hlediska této teorie jde o strom.

Obecně lze říci, že u nelineárních záznamů záleží na pořadí polí v záznamu. Konkrétně u hierarchické struktury lze zavést zřejmý pojem úroveň pole jako počet nadřízených polí. Pak při návrhu struktury nezáleží na pořadí polí stejné úrovně podřízené stejnému poli. Všechna ostatní pořadí jsou pak evidentně významná. Možnost vytvářet nelineární záznamy je důležitou vlastností bází dat. Ukazuje se tak opět význam rozlišení fyzických a logických záznamů.

3.4 Uložení dat a přístup k nim

3.4.1 Klíčová pole

Při zpracování záznamů je nutno se v nich orientovat. Základní způsob orientace nabízí úplná množina hodnot všech polí záznamu. Ten je však pro většinu zpracování prakticky nepoužitelný - už jen pro množství hodnot.

Z logiky databází vyplývá, že k orientaci nemusí sloužit hodnoty všech polí, ale jen některých. Např. jednotlivé záznamy o geochemických vlastnostech prvků jsou jednoznačně identifikovatelné názvem prvku. Bývá však zvykem, že při běžné práci se stejně často jako plného názvu prvků používá také jeho chemické značky, která je (dokonce mezinárodně) běžně známa. Z hlediska datových záznamů a jejich identifikace je název prvku a jeho chemická značka zcela ekvivalentní. Navíc chemická značka je podstatně kratší. Proto nic nebrání použít místo názvu prvku jeho chemickou značku.

Taková a podobná pole se nazývají klíčová pole. Klíčová pole mají v souborech jednu nebo více z následujících funkcí:

• identifikační
• klasifikační
• informační
• třídící (řadící)
• kontrolní.

Informační funkce je zřejmá. Třídící funkce umožňuje řadit záznamy při zpracování podle požadovaných kriterií. Kontrolní funkce umožňuje ověřovat správnost dat, zpravidla při vytváření záznamů.

Z uvedených funkcí je pro probíranou problematiku nejdůležitější funkce identifikační. Identifikační klíčové pole obsahuje hodnoty mající přímo informační význam, nebo nějaký jednoznačný kód nahrazující původní informaci (např. ve smyslu číselníků). Takový jednoznačný nahrazující kód vždy existuje - např. pořadové číslo v množině původních informací nějakým způsobem uspořádané.

Klasifikační funkce poskytuje možnost z hodnoty klíčového pole získat i některé vlastnosti záznamu. Je-li klíčovým polem např. státní poznávací značka automobilu, pak z něj lze vyjmout kód okresu, kde je daný automobil registrován. Klasifikační klíče mají některé nevýhody. Především je to potřeba daleko většího počtu znaků, než by bylo teoreticky zapotřebí. Např. rodné číslo jednoznačně identifikující občana naší republiky má 10 cifer, ačkoliv je nás deset milionů a stačilo by tedy cifer pouze 7.

3.4.2 Klíče

Klíčová pole popsaná shora mají velmi často kromě identifikační funkce i funkci informační (a naopak: informační pole mohou být často použita jako pole klíčová). Např. pole obsahující chemickou značku jednak identifikuje záznam, jednak informuje, o jaký prvek jde.

Složitější aplikace však mnohdy identifikují záznam podle několika informačních polí. Např. záznam v souboru čerpání vody z vrtů je identifikován označením vrtu a kalendářním datem měření.

Do takové datové struktury lze přidat klíčové pole, jehož obsah se zkonstruuje připojením obsahu datumového pole za obsah pole s označením vrtu. To je však velmi nepraktické ze dvou důvodů:

• Přidáním dalšího pole nabývá soubor dat na objemu, a to celkem zbytečně, protože toto pole obsahuje údaje, které už jednou v záznamu jsou.
• Nějakým mechanismem se musí zajistit, aby při změně obsahu některého informačního pole, které je částí klíčového pole, byla provedena příslušná změna klíčového pole.

Proto se při práci s daty používá obecnější konstrukce nazývaná klíč. Především je zřejmé, že nic nebrání tomu, aby klíč byl konstruován nejen pouhým spojováním obsahů některých polí "za sebe", ale vytvořen jakýmkoliv (i třeba velmi složitým) výpočtem. Dále: protože záznam sám nese informace (v některých svých polích), které jsou schopny ho identifikovat, lze je vyhodnotit jako klíč až při zpracování záznamu. Obou možností, případně jejich kombinace, se výrazným způsobem využívá v kvalitních moderních databázových systémech.

3.5 Metody uložení dat

Problematika uložení dat je problematikou proto, že se data ukládají na lineárním fyzickém mediu. Paměť počítače je lineární posloupnost paměťových prvků adresovaných od nuly. Magnetická páska je lineárním mediem už z fyzikální podstaty. Disky a diskety s různou technickou konstrukcí jsou jednotným vzorcem linearizovány na shodnou (nanejvýš různě dlouhou) posloupnost paměťových elementů. Data z klávesnice jsou linearizována reálným časem (jak postupně v čase přichází "do počítače") apod. Datové struktury však lineární zdaleka být nemusí. V celé této kapitole se nadále pod pojmem paměť bude rozumět jakékoliv shora naznačené linearizované medium schopné "zapamatovat si" data.

3.5.1 Postupné uložení dat

Toto uložení je charakteristické tím, že při uložení záznamů využívá paměť od počátku (= od adresy nula) a bez mezer. Volná zůstávají paměťová místa s nejvyššími adresami v případě, že objem dat je menší než kapacita paměti.

Další rozlišovací úrovní postupného uložení dat je jejich uspořádání v paměti.

• Sekvenční uložení je takové, při němž se záznamy ukládají v pořadí, jak v čase přicházejí - tvoří vstupní sekvenci. Pokud je zapotřebí nějaký záznam najít, je nutno projít všechny záznamy od počátku.
• Při sériovém uložení řídí pořadí záznamů hodnota nějakého klíče - posloupnost klíčů tvoří uspořádanou sérii. Záznam s nejmenší (největší) hodnotou je prvním záznamem, záznam s největší (nejmenší) hodnotou je poslední. Řazení dat je vzestupné (sestupné). Vyhledávání záznamů se v sériovém uložení velmi zjednoduší. Největší nevýhodou je nutnost fyzicky reorganizovat záznamy, když dojde požadavek na přidání nebo vypuštění záznamů (nebo ke změně hodnoty klíče záznamu).

Z ostatních typů se občas používá řazení podle četnosti vyhledávání. Vyhledávání je pak celkově rychlejší než při sekvenčním uložení. Je však podmíněno jednak znalostí této četnosti (nutnost experimentů), jednak stálosti této četnosti v čase.

3.5.2 Rozptýlené uložení dat

Zásadní rozdíl oproti postupnému uložení je v tom, že mezi jednotlivými záznamy mohou být mezery a že jsou uloženy bez ohledu na nějaké uspořádání.

Při zápisu dat rozptýleného uložení se používají dvě metody:

• Je jedno, kam bude zapisovaný záznam uložen. Proto se uloží do kteréhokoliv volného, délkově vyhovujícího místa v paměti. Tato metoda - má-li být rozumně rychlá a efektivně využívat paměť - používá pomocnou evidenci volného místa v paměti; z této evidence lze kdykoliv zjistit adresy a velikosti volných míst. Při zápisu se pak pomocí této evidence volí optimální strategie ukládání - např. se nejprve hledá přesně stejně veliké volné místo, jako má zapisovaný záznam.
• Místo, kam bude záznam zapsán, se určí na základě obsahu záznamu. V naprosté většině se k tomu používá hodnot klíčů. Existuje tedy zobrazení množiny hodnot klíčů do množiny adres. Toto zobrazení nemusí být prosté. Funkce taková zobrazení definující se nazývají Hash - funkce.

3.5.3 Kombinované uložení

Existuje několik často užívaných kombinovaných uložení:

• Uložení s oblastí přeplnění: Tato metoda kombinuje sériové a rozptýlené uložení. Při primárním vytvoření je soubor vytvářen sériově (tj. ve vzrůstajícím nebo klesajícím pořadí klíčů) s ohledem na Hash - funkci. Nově přidávané záznamy jsou - většinou rozptýleným způsobem - zapisovány do tzv. zóny přeplnění (overflow area).V případě, že v souboru může existovat větší či menší počet záznamů se stejnou hodnotou klíče, modifikuje se metoda tak, že jsou vytvářeny tzv. skupiny záznamů (záznamy se stejným klíčem), přičemž se předpokládá stejnoměrné rozdělení četnosti výskytu. Proto se každé skupině vyhradí stejné místo. Záznamy se stejným klíčem jsou zapisovány sekvenčně v prostoru paměti vyhrazené skupině a jednotlivé skupiny jsou zapisovány sériově v prostoru paměti vyhrazené skupinám. Dojde-li během zápisu záznamu do skupiny k vyčerpání místa určeného skupině, zapisují se tyto záznamy do zóny přeplnění.
• Uložení s indexy: V moderních databázových (zvláště relačních) systémech jde o jedno z nejužívanějších uložení. Zásadně se týká záznamů, pro něž je definován alespoň jeden klíč. Jde v podstatě o tzv. uložení s odkazy. Kromě záznamů jsou ukládány také odkazy na ně. Tyto odkazy však nejsou většinou ukládány přímo v datovém souboru, ale v samostatných souborech.
• Uložení s indexovou tabulkou: Při tomto způsobu uložení jsou data záznamy ukládány sekvenčně do souboru dat. Zároveň je pro každý záznam dat vytvořen záznam indexu. Záznam indexu má dvě pole: prvním je hodnota klíče daného záznamu, druhým je adresa v souboru dat, počínaje kterou byl tento záznam uložen. Takto vytvořený záznam indexu je zapsán do souboru indexů. Záznamy týkající se jednoho klíče jsou souhrnně označovány jako indexová tabulka. Každá indexová tabulka může být uložena v samostatném souboru, nebo mohou být všechny indexové tabulky uloženy v jediném souboru (nebo některé tabulky v jednom, některé v jiném souboru apod). Tyto soubory se nazývají indexové soubory. Zvláště pro velké objemy dat je tento způsob uložení jedním z nejefektivnějších z hlediska využitého paměťového prostoru i (při vhodně zvolené metodě hledání v indexových souborech) při zpracování přímým způsobem. Efektivita při ukládání spočívá jak v časovém hledisku (data jsou ukládána bez jakékoliv další reorganizace souboru vždy přímo na konec souboru), tak v hledisku hospodárnosti (v datovém souboru nejsou nevyužitá místa). Nutnost zpracovat současně i indexové soubory však je daleko menším zatížením, protože jednak jsou záznamy indexového souboru krátké (pouze dvě pole oproti např. desítkám polí vlastního datového souboru), jednak mohou být organizována zcela odlišně od vlastního souboru dat. Navíc, protože jsou poměrně málo objemné, mohou být celé umístěny v operační paměti, čímž se jak vytváření, tak zpracování dále nesmírně urychlí.

3.6 Přístup k datům

Geodata se vyznačují značným množstvím, klíč logického záznamu se může konstruovat z datových polí více souborů apod. Hledání v takových datech je kritickým momentem zpracování. Efektivita zpracování dat přímo závisí na efektivitě hledání v datech.

3.6.1 Hledání v datech

Hledáním rozumíme dodání takového záznamu ze souboru (souborů) dat, který splňuje dané kriterium. Tímto kriteriem může být jakýkoliv logický výraz, vyhodnotitelný pro každý záznam. Záznam, pro nějž po vyhodnocení odevzdá tento logický výraz hodnotu logické 1, dané kriterium splňuje.

Jako kriterium efektivity různých metod hledání se používá průměrný počet vyhodnocení kriteria, jehož splnění je vyžadováno. Toto vyhodnocení vždy pracuje s hodnotami polí záznamu, proto jedno vyhodnocení je přímo spojeno s jedním vyzdvižením dat záznamu (všech nebo jen některých; velmi často jsou rychlosti v obou případech stejné!). Protože vyzdvižení dat záznamu je spojeno s přístupem k mediu - a to je časově velmi náročná operace - potvrzuje to jen tvrzení o hledání v datech jako o kritickém místě procesu zpracování dat.

• Sekvenční hledání: Při sekvenčním hledání se probírají záznamy postupně od začátku jeden za druhým tak dlouho, dokud není nalezen záznam vyhovující vyhledávacímu kriteriu. Při sekvenčním hledání je k nalezení požadovaného záznamu nutno prohlédnout průměrně polovinu souboru.
• Sériové hledání: uplatňuje se v souborech se sériovým způsobem uložení. Záznamy jsou tedy řazeny v uspořádané posloupnosti (sérii) hodnot klíčů. V metodách sériového hledání je vždy vyhledávacím kriteriem hodnota klíče, podle kterého je soubor řazen.
• Sériové hledání s pravidelnými skoky: Tato metoda (myšleně) rozděluje soubor na bloky o shodném počtu záznamů. Nejprve je (sekvenčně) nalezen blok, ve kterém se záznam nachází, a poté (sekvenčně) hledaný záznam.
• Sériové hledání půlením intervalu: Metoda je někdy označována také jako binární hledání, je logicky totožná se stejně označovanou metodou numerické matematiky. Protože jde o sériové hledání, lze aplikovat pouze na soubory se sériovým uložením, tedy seřazené podle hodnot klíče. Metoda je popsána pro vzestupné řazení, pro sestupné postačí zaměnit relace. Princip metody je následující: Existuje záznam, který rozděluje soubor na dvě, co do počtu prvků (až na jeden) stejné části. Všechny záznamy před tímto záznamem mají hodnoty klíče menší nebo rovnu, za tímto záznamem větší nebo rovnu. Vybere se tedy tento "prostřední" záznam a jeho klíč se porovná s hledaným klíčem. Mohou nastat tři případy: (1) Jsou-li klíče totožné, je záznam nalezen. (2) Je-li prostřední klíč větší než hledaný, hledá se stejným způsobem v první polovině souboru. (3) Je-li prostřední klíč menší než hledaný, hledá se stejným způsobem ve druhé polovině souboru. Metoda končí ve dvou případech: hledaný záznam je nalezen, nebo není co půlit - v tom případě hledaný klíč nemá žádný záznam souboru. Tato metoda je ze všech zatím uvedených nejrychlejší.

3.6.2 Přímý přístup k datům

Pod přímým přístupem k datům se rozumí přímé čtení záznamu ze známé adresy. V těchto metodách se každý požadovaný záznam se přečte hned napoprvé. Metody přímého přístupu k datům evidentně vyžadují znalost adresy pro každý záznam. To neznamená, že v každém okamžiku jsou známy adresy všech záznamů najednou. Znamená to, že v okamžiku potřeby daného záznamu existuje možnost adresu zjistit. U těchto metod se obdobně jako u metod sériového hledání předpokládá existence klíče a vzestupné nebo sestupné uspořádání jeho hodnot.

3.6.2.1 Přímé adresování

Při metodě přímého adresování je adresou přímo klíč nebo jeho lineární transformace. Metoda přímého adresování je vhodná v případě, že

• klíč je numerický
• ke každé hodnotě klíče z nějakého uzavřeného intervalu existuje záznam
• délka záznamu je u všech záznamů stejná

3.6.2.2. Nepřímé adresování

Nejčastěji však data v souborech nesplňují ani přibližně požadavky odůvodňující přímé adresování. Je to např. tehdy, když

• posloupnost klíčů ani teoreticky neobsahuje všechny hodnoty jediného uzavřeného intervalu, ale mezi hodnotami jsou "velké mezery".
• klíč je koncipován tak, že teoreticky umožňuje použít všechny hodnoty z nějakého uzavřeného intervalu, ale je známo, že všech skutečných záznamů bude mnohem méně.
• klíčem je výraz jiného typu než numerického a nemůže tedy být přímo použit k adresování.

V uvedených a podobných případech je nutno mít k disposici funkci, která transformuje hodnotu klíče na adresu. Adresa není tedy určena přímo, ale zprostředkovaně klíčem; proto se tyto metody nazývají metody nepřímého adresování, a protože používají (již při výkladu metod zápisu zmíněnou) Hash - funkci, nazývají se také Hash - metodami.

Zpravidla není možno sestrojit funkci A = A (k) tak, aby to bylo prosté zobrazení (celé) množiny klíčů na rovnoměrně rozložené adresy v množině použitelných adres. Na druhé straně by funkce A neměla být (z časových důvodů při jejím vyhodnocování) příliš složitá. Proto se užívají takové funkce, které některé adresy ponechávají neobsazené a jiné adresy jsou obrazem většího počtu klíčů.

3.6.3 Hledání v datech s indexy

Tyto metody hledání mohou být aplikovány pouze na soubory dat, ke kterým byly vytvořeny indexové tabulky (viz odstavec o metodách uložení s indexy). Protože indexové tabulky jsou vytvářeny na základě hodnot klíčů, je možno hledat záznam pouze podle kriteria, kterým je hodnota klíče.

Při této metodě se hledání ve vlastním souboru dat převádí na hledání dané hodnoty klíče v indexové tabulce. Po nalezení záznamu indexové tabulky je z pole adresy získána adresa datového záznamu v souboru dat, a tento záznam se pak přímo získá jediným čtením.

Pro hodnocení metod hledání v datech s indexy platí vše, co bylo uvedeno dříve, ovšem aplikováno na soubor indexů. Organizace uložení v souboru indexů tedy určuje efektivitu používání souborů s indexy. Protože z dosud hodnocených metod hledání je nejméně efektivní sekvenční metoda, téměř nikdy se nepoužívá ani sekvenční organizace uložení, ani sekvenční hledání.

Velmi často se pro indexová tabulky používá uložení s odkazy. Záznam pak má 6 polí: čtyři pole s odkazy (na předchůdce, následovníka, a na levého a pravého souseda), jedno pole pro hodnotu klíče a jedno pro hodnotu adresy záznamu. Indexová tabulka pak má tvar stromu (z teorie grafů). Každý záznam je pak jedním uzlem v tomto grafu, hrany grafu jsou obrazem odkazů. Výhodou je možnost ukládat v každém uzlu ne kompletní hodnoty klíče, ale jen část hodnoty klíče náležející dané úrovni uzlu v grafu.

3.7 Logická organizace báze dat

Historický vývoj směřoval od prvotního zpracování dat na úrovni fyzických záznamů přes datové záznamy bez vzájemných vazeb (na úrovni dat) až po báze dat obsahující v sobě popis dat včetně vazeb. V současné době má smysl rozebírat dva dominantní modely logické organizace bází dat: hierarchický (také hierarchicko - síťový) model a relační model.

3.7.1 Hierarchicko - síťový model

Model vychází z použité hierarchické struktury dat tak, jak byla kdysi zavedena pro potřeby jazyka Cobol pro zobrazení hodnot dat a jejich vzájemných vztahů (nadřízenosti a podřízenosti). Tento model se neopírá o matematickou teorii, i když přejímá část terminologie z teorie grafů. Přesto nalezl v praxi široké uplatnění.

Hierarchická struktura je taková, kde záznamy jsou v hierarchickém vztahu nadřazenosti a podřízenosti. Přitom se používá "rodinná" terminologie rodič a potomek ve zřejmém významu. V hierarchické struktuře má každý potomek jediného rodiče, existuje jediný rodič, který není potomkem a potomek v jednom vztahu může být rodičem v jiném vztahu.

Pokud je zapotřebí popsat, na kterém místě hierarchické struktury se nějaký záznam nalézá, používá se k tomu tzv. přístupová cesta. To je možno díky popsaným vlastnostem hierarchické struktury, které zaručují, že od kořene lze dojít k danému záznamu jediným způsobem. Často se vyžaduje (většinou z ryze praktických důvodů např. sběru dat), aby v každém záznamu existoval klíč. V takovém případě lze přístupovou cestu popsat jednoduše jako posloupnost klíčů počínaje klíčem kořenového záznamu přes klíče všech nadřízených až po klíč daného záznamu včetně.

Zmíněné pojmy z teorie grafů se při popisu hierarchických struktur využívají v tomto smyslu: • záznam = uzel grafu • vztah rodič - potomek = hrana grafu • rodič a potomek = incidenční uzly hrany • hierarchická struktura = souvislý graf, který je stromem • báze dat hierarchického modelu = graf, který je les (tj. množina disjunktních stromů) • přístupová cesta k záznamu = cesta v grafu od kořene k danému uzlu.

Obr. 3.3: Stromová struktura hierarchického modelu

Nevýhodou hierarchických systémů je velmi obtížná implementace odkazů. V takových případech se sice rozšiřují možnosti, snižuje redundance dat, ale současně dochází k nutnosti promíchávat otázky uložení na médiu s otázkami struktury modelu, ke znepřehlednění a zvláště ke snížení abstrakce při práci s daty.

3.7.2 Relační model

Jedním z nejjednodušších zápisů dat je zápis do klasické tabulky. Takto převážně vznikají zápisy dat v terénu, obecně v neautomatizovaných částech systému. Charakteristický pro tento zápis je její členění do sloupců, z nich každý má nadpis. To je velmi podstatné, protože nadpis ve smyslu iden.tifikace údajů automaticky indukuje také typ údajů v daném sloupci. Sloupce jsou tedy "homogenní co do typu". Klasickým příkladem je výňatek z komplexní petrologické databáze Global Data Base in Sedimentary Petrology, Géodiffusion, Paris 1991 (obr. 3.4).

Obr. 3.4: Relační model

Pevným počtem n sloupců tvoří data v řádcích uspořádané n-tice. Každý prvek n-tice, nazývaný pole, je toho typu, jaký odpovídá typu sloupce. Je tedy prvkem (konečné nebo nekonečné) jednoznačně určené množiny Di (např. množiny všech datumů, množiny všech racionálních čísel, množiny {Ano;Ne} apod). Matematický základ relačního modelu je podán v kapitole "Množiny".

3.7.2.1. První normální forma.

Přestože domény mohou být libovolné množiny, používá se z čistě praktických důvodů většinou jen množin, jejichž prvky jsou

• číselné hodnoty (vzhledem ke zpracování v počítačovém prostředí výhradně racionální)
• datumové hodnoty (uspořádané trojice <d, m, r> přirozených čísel s příslušně definovaným oborem a operacemi)
• textové hodnoty (posloupnosti prvků z ze Z, kde Z je konečná neprázdná množina)
• binární hodnoty (prvky dvouprvkové množiny {Ano, Ne})
• relace.

Domény obsahující jen prvky analogické prvním čtyřem vyjmenovaným se nazývají jednoduché. Jestliže relace obsahuje pouze jednoduché domény, nazývá se relace v první normální formě. Proces převedení relace do první normální formy se nazývá normalizace (obr. 3.6). Relace, která není v první normální formě, je dána např. tabulkou na obr. 3.5. Normalizace této relace může vést k jediné relaci, která již v první normální formě je.

Obr. 3.5: Nenormalizovaná relace

Obr. 3.6: Normalizovaná relace

Jde o poměrně jednoduchý příklad; je však nutno upozornit na to, že procesem normalizace zvláště u složitě logicky strukturovaných relací mohou často vznikat redundantní údaje. I v tomto příkladu se redundanci dat nevyhneme: souřadnice jednoho vrtu jsou uloženy na několika různých místech. Pokud např. se posléze zjistí, že souřadnice X vrtu A12 byla zaznamenána chybně, je nutno hodnotu opravit ne na jediném, ale na několika různých místech. To je přesně ta situace, kterých by v reálné praxi mělo být co nejméně.

Některé atributy nebo jejich spojení lze v případě potřeby použít jako klíče. Označme je jako možné klíče. Klíče se používají jednak pro vyhledávání, jednak pro uspořádání. Jestliže se některý možný klíč skutečně pro daný účel použije, stává se po dobu použití primárním klíčem. Je-li klíč tvořen jediným atributem, označuje se jako jednoduchý klíč; je-li tvořen spojením dvou a více atributů, nazývá se spojený klíč. Je-li klíč vytvořen pomocí operací definovaných na hodnotách polí a na konstantách, nazývá se obecný klíč.

Obr. 3.7: Rozklady relace

Pomocí klíčů lze nahradit jednu nenormalizovanou relaci jednoduše více normalizovanými relacemi se stejným datovým obsahem, jak je zřejmé z obr. 3.7. Jednoduchým klíčem je v tomto případě atribut Vrt.

Pro formalizaci zápisu struktury se často používá notace, která je základem některých dotazovacích jazyků. V této notaci se zapíše struktura relací následovně:

Identifikátor relace je uveden před kulatými závorkami; uvnitř nich jsou uvedeny jednotlivé atributy. Je-li před některým z nich uveden znak ^, je tím označen klíč. Nenormalizovaná relace se pak v této notaci zapíše následovně: VRTY (^VRT, X, Y, ČERPÁNÍ (^DATUM, HLADINA, L/SEC), LABORATOŘ) Porovnáním zápisů obou struktur lze odhalit jeden z možných postupů tvorby klíčů při procesu normalizace, kterým vzniká více relací: každá hierarchicky vnořená relace předřadí svému vlastnímu klíči (klíčům) klíč (klíče) relace bezprostředně hierarchicky nadřazené.

3.7.2.2 Operace s relacemi

V relačním modelu je báze dat definována jako n-ární relace; takových bází dat se tedy týkají všechny vlastnosti, které lze odvodit matematickým aparátem pro relace. Tento aparát jako obecný aparát matematický je pro účely počítačového zpracování velmi dobře algoritmicky propracován. S relacemi jako takovými se pracuje poměrně jednoduše; výhoda relačních modelů databází spočívají právě v jednoduchosti práce s relacemi.

Pro relace se zavádí především operace; ze základních operací uveďme projekci a spojení jako nejčastěji vyžadované operace.

Nechť P a Q jsou relace. Operaci x nazýváme projekcí tehdy, je-li P × Q relace, která vznikne z P vynecháním atributů P, které nejsou současně atributy Q, a následným vynecháním shodných řádků. Tato operace se používá pro zbavení se nepodstatných nebo v danou chvíli nedůležitých informací.

Nechť P a Q jsou relace, které mají alespoň jeden shodný atribut. Operaci + nazýváme spojením tehdy, je-li P + Q relací, která vznikne z P přidáním atributů Q, které nejsou současně atributy P, a následným vynecháním shodných řádků. Spojení vytvoří relaci z hodnot atributů obou relací, které odpovídají hodnotám shodného (shodných) atributů.

Tyto a další operace vytváří algebru relací. Kromě operací lze vytvářet další relace také relačním kalkulem. Přitom se využívá symboliky používané obdobně v jiných partiích matematiky (obr. 3.8).

Obr. 3.8: Relační symbolika

Pomocí zavedené symboliky a relačního kalkulu můžeme zavést např. relaci U, která popisuje množinu takových čerpacích měření všech vrtů, kde vydatnost přesahuje 0.5:

3.7.2.3 Normální formy

V předchozích odstavcích byl zaveden termín první normální forma. Příklady osvětlily způsob převodu relace na normalizovaný tvar. Při porovnání výsledků dvou různých normalizací téže relace (do jedné a do dvou relací) a ve smyslu zavedených operací nad relacemi je vidět, že druhý způsob spočívá ve vytvoření dvou projekcí na podmnožiny atributů se stejným informačním významem a ekvivalentním datovým obsahem. Stanovení vhodné (logické) reprezentace dané relace bude cílem následujících odstavců.

Další výklad je dokreslen následujícím příkladem. Nechť je dáno několik vrtů v několika lokalitách; vzorky vod byly podrobeny chemické analýze a výsledky byly shrnuty do relace

Je-li tedy z relace ANALÝZA, pak to znamená, že z vrtu V12, který je v Porubě, byl analyzován vzorek na pH a byla zjištěna jeho hodnota rovna 7.Z příkladu je vidět, že

• kódem vrtu je jednoznačně určeno jeho umístění, jinak řečeno, ze zadaného kódu vrtu lze odvodit jeho umístění: VRT -> LOKALITA
• analyzované množství je jednoznačně určeno kódem vrtu a kódem látky, jinak řečeno, ze zadaných kódů vrtů a látky lze odvodit hodnotu: VRT, LÁTKA -> MNOŽSTVÍ
• naproti tomu ze samotné lokality nelze jednoznačně odvodit žádný jiný údaj, není tedy např. LOKALITA -> MNOŽSTVÍ.

Rozborem dalších možností lze odvodit, že jediným klíčem relace je {VRT, LÁTKA}; pouze tento klíč jednoznačně zpřístupňuje všechny údaje v řádku. Mezi atributy relace se tedy mohou vyskytovat vazby, které jsou dány významem těchto atributů v reálném světě, jejich sémantikou. Formálně jsou tyto vazby označovány jako závislost. Pomocí pojmu závislost resp. úplná závislost lze definovat druhou normální formu:

Relace R [A] je relace ve druhé normální formě, jestliže

1. R [A] je v první normální formě a dále
2. každý atribut a z A, jenž nepatří žádnému klíči R, úplně závisí na každém klíči K v R.

Shora uvedená relace ANALÝZA není ve druhé normální formě, protože má atribut LOKALITA, který nepatří žádnému klíči, funkčně závisí na jediném klíči {VRT, LÁTKA}, ale nezávisí na něm úplně (závisí totiž jen na jeho části VRT).

Nicméně i s relacemi ve druhé normální formě mohou nastat problémy. Uvažujme relaci VRTY (VRT, LOKALITA, SPAD), kde SPAD je jednotkový spad v dané lokalitě: Jediným klíčem je {VRT}. Jestliže se však uzavře poslední vrt v Nové Vsi, ztratí se informace o spadu v dané lokalitě. Problém je zřejmě v existující závislostí LOKALITA → SPAD; žádný z těchto atributů nepatří ke klíči relace. Tyto a obdobné obtíže se je možno odstranit přechodem k projekcím (zde na {VRT, LOKALITA}) a relacím ve třetí normální formě:

Řekneme, že relace R je ve třetí normální formě, jestliže

1. R je ve druhé normální formě a dále
2. množina všech atributů, které nepatří žádnému klíči (tj. množina neprimárních atributů) je nezávislá: žádný neprimární atribut nezávisí na některém z ostatních neprimárních atributů.

Elementy relace, která je ve třetí normální formě, mají následující strukturu: existují pro ně hodnoty klíčů (zpravidla klíče jediného), které tento element plně identifikují, a dále hodnoty atributů, které jistým způsobem elementy popisují. Tyto "popisné" hodnoty neprimárních (= neklíčových) atributů jsou na sobě nezávislé v tom smyslu, že žádná z nich není funkčně určena kombinací některých ostatních.

3.7.3 Návrh logické struktury

Uvedené normální formy mají nesmírný praktický význam zejména při návrhu relační databáze. Především na úrovni řízení báze dat (= úroveň programů) je evidentně zpracování relací ve vyšší normální formě daleko jednodušší a tedy rychlejší než relací v nižší normální formě (popř. zcela nenormalizované). Přestože pro koncového uživatele je to irelevantní, je na místě připomenout, že jednodušší zpracování vyžaduje i jednodušší programování a je známo, že čím jednodušší je program, tím méně potenciálních chyb obsahuje.

Daleko důležitější je však otázka praktického zpracování dat uživatelem počínaje aktualizací a konče čerpáním informací. Údržba koncovým uživatelem dat, která jsou nenormalizovaná, je bez rizika porušení integrity dat nemožná bez obslužných programových nadstaveb, specificky programovaných pouze na tuto datovou strukturu. Toto riziko se - byť v menší míře - vyskytuje i v relacích ve druhé normální formě: přidání dalšího vrtu do relace VRTY předchozího odstavce znamená, že uživatel musí zadat s kódem vrtu a lokality také přesně stejnou hodnotu spadu jako u předchozích řádků téhož vrtu! Teprve relace ve třetí normální formě plně odstraňují (až na zřejmé klíče) redundanci dat.

Protože dnes mají koncoví uživatelé obecných systémů řízení báze dat možnost plně definovat, plnit a aktualizovat své vlastní báze dat, je vhodné závěrem uvést obecný postup normalizace již ve fázi návrhu logické struktury:

• Nenormalizovaný tvar -> první normální forma - rozložení všech datových struktur, které nejsou dvourozměrné, na dvourozměrné
• První normální forma -> druhá normální forma - odstranění neúplných závislostí neprimárních atributů na potenciálních klíčích
• Druhá normální forma -> třetí normální forma - odstranění závislostí neprimárních atributů na sobě

Návrh logické struktury báze dat založené na relačním modelu tedy spočívá v identifikaci všech atributů postihujících existující objekty, a vzájemných vztahů mezi těmito atributy. Na základě této identifikace je třeba - s jistou dávkou opatrnosti - rozhodnout o klíčích relací.

Relační systémy jsou založeny na formalizovaných pojmech používajících matematický aparát. Lze vytvořit analytické nástroje pro automatizaci shora popsaných identifikačních činností a návrhu výsledných relací ve třetí normální formě. Ukázalo se však, že tyto nástroje jsou - zvláště díky moderním propracovaným systémům řízení bází dat - pro koncové uživatele vcelku zbytečné.

3.8 Zpracování báze dat

Detailní popisy postupů, metod a nástrojů podaný v předchozích kapitolách stojí v popředí zájmu těch, kdo své databáze sami budují a udržují. Pro uživatele, které již vytvořené báze dat používají jako zdroj informací, mají význam ilustrační, upřesňující pohled uživatelů na konstrukci bází dat, a významným způsobem ulehčují jejich komunikaci s bází dat při formulaci svých požadavků.

Tato kapitola je úvodní kapitolou do rozsáhlé problematiky práce s bázemi dat "výstupním" směrem. Z hlediska takového způsobu zpracování existujících dat lze uživatele rozdělit na dvě skupiny:

• Programátoři; mají k disposici programovací jazyk umožňující přístup do bází dat. Výsledkem jejich činnosti je program, který - po spuštění - podá požadované informace. Data se tedy zpracovávají na úrovni programu.
• Laici (přesněji ti, kteří nejsou programátoři, kteří pro získání informací neumí, nechtějí nebo nemohou vytvářet programy); mají k disposici dotazovací jazyk, pomocí něhož formulují své požadavky. Výsledkem jsou - po provedení požadovaného dotazu - přímo požadované informace. Data se tedy zpracovávají na úrovni uživatele.

V současné době je zřetelně vidět tendence implementovat dotazovací jazyky (které jsou nutně formalizované, se svou syntaxí a sémantikou) do programovacích jazyků. Tak je tomu např. v novějších systémech s programováním v xBase, které jako rovnocenné syntaktické kategorie používají (alespoň nejdůležitější) příkazy SQL. Podrobněji právě toto rozebírají dvě následující kapitoly.

3.8.1 Zpracování na úrovni programu

Tato práce se nezabývá programováním jako takovým, proto jsou informace k této problematice podány pouze schematicky.

Programovací jazyk obsahuje dvě základní třídy nástrojů: popisy a příkazy. Pomocí popisů (také deklarací) programátor popisuje objekty, nad kterými budou pracovat příkazy. Každá z těchto tříd má relativně samostatný popis syntaxe a sémantiky v daném jazyce. Proto se často vytýká zvlášť jazyk pro popis dat a jazyk pro práci s daty. Za nejjednodušší "jazyk popisu dat" by mohla být považována pouhá tabulka popisu dat, informující tabelární formou o souborech, jejich polích, atributech polí, indexech a vazbách. Komplexní jazyk pro popis (logické struktury) dat musí plnit následující funkce:

• identifikace jmen a typů souborů, záznamů, segmentů a polí
• určení klíče
• popis struktury segmentu resp. záznamu
• pojmenování vztahů mezi segmenty a záznamy
• popis přípustných hodnot polí
• počet opakování položky v poli (matice, ...)
• popis kontrolních algoritmů
• popis přístupových práv a hesel.

Pomocí jazyku pro zpracování dat aplikační programátor nebo koncový uživatel určuje, co se má s daty, popsanými pomocí jazyku pro popis dat, při zpracování stát. Jazyk musí umožňovat

• přímé čtení záznamu podle adresy
• přímé čtení záznamu podle klíče
• čtení záznamu splňujícího zadaná kriteria
• čtení následujícího záznamu
• čtení následujícího záznamu v mezích stejného rodiče
• čtení záznamu následujícího sourozence aktuálního rodiče
• označení záznamu za neplatný
• přidání nového záznamu.

3.8.2 Zpracování na úrovni uživatele

Přestože zvláště ve starších systémech existují dotazovací jazyky na úrovni uživatele s oddělenými částmi popisu dat a popisu zpracování obdobně jako v případě programátorském, v novějších preferovaných dotazovacích jazycích jsou obě části obsaženy v jediné konstrukci.

V současné době je jedním z nejrozšířenějších jazyků pro zpracování na úrovni uživatele jazyk označovaný SQL. Protože se stal poměrně obecným (z hlediska implementace v různých operačních systémech) a kombinuje programátorské i uživatelské možnosti, je mu věnována samostatná publikace.

3.9 Dotazovací jazyk SQL

Problematika zpracování dat - jak je možno vidět z celého předchozího textu - je nesmírně rozsáhlá: od fyzického uložení dat po logické struktury, od sekvenčního přístupu po přístup přímý atd.

U koncového uživatele - nepočítačového odborníka však není možno očekávat, že se nejprve stane odborníkem přes data. Proto je pochopitelná snaha vytvářet pro tyto uživatele jednak formalizované, jednak pokud možno normalizované nástroje pro zpracování dat v počítačovém prostředí jednotným způsobem s tím, že uživatel není zatěžován otázkami uložení, organizace apod.

Pokusů o vytvoření jednotného alespoň dotazovacího prostředí bylo učiněno několik. Faktem zůstává, že – zvláště při velkých objemech dat - jistý stupeň přehledu uživatele o datové problematice je vyžadován u všech. Čím vyšší stupeň přehledu o datech uživatel má, tím optimálněji je schopen zajistit zpracování dat a tím mohutnějším nástrojem se pak takový prostředek pro něj stává.

Obr. 3.9: Části demonstračních relací

V současné době většina implementací SQL pracuje nad relačními databázemi (tj. mající podobu tabulky - viz příslušná kapitola shora). Odtud také zástupná klíčová slova typu "table". Protože však existuje poměrně snadná (protože mechanická) konverze hierarchické (ne síťové) struktury na relační, některé SQL mají možnost pracovat i na hierarchických organizacích datových bází.

V této kapitole je popsána logika a nástin použití základních příkazů SQL. Protože jde o poměrně širokou problematiku, u které je předpoklad plného využití, je nutno odkázat na příslušné referenční manuály. Proto také jsou v této kapitole jednotlivé příkazy uváděny již na konkrétních příkladech a nejsou popisovány ani syntakticky úplně. Všechny příklady jsou předkládány na části datového modelu uvedeného v kapitole Jde o data, jejichž strukturu a počátečními řádky i částečně obsah ukazují schémata na obr.3.9.

Jedním z poměrně zdařilých a v mnoha různých (operačních) systémech implementovaným nástrojem pro zpracování dat je SQL (z plného anglického označení Structured Query Language; toto označení se nepřekládá a používá se jen SQL). Oproti jiným podobným obecným nástrojům má SQL nejen funkce dotazovací (tj. pro čerpání dat z existujících databází), ale i funkce pro plné zpracování dat: vytváření nových databází o definované struktuře, plnění daty, opravy dat ap.

3.9.1 Vymezení dat

Protože uspořádání dat je chápáno "tabulkově", jsou zavedeny ve zřejmém smyslu tyto pojmy: jméno sloupce, šířka sloupce, typ sloupce. Konkrétně typ sloupce je typem každého z jednotlivých údajů, které sloupec tvoří (viz doména a její atributy v kapitole o relačních databázích). SQL pracuje obecně s následujícími typy dat a jejich kódováním:

3.9.1.1 Numerická data - N

Jde o číselná data v běžném pojetí. Charakterizují je celková šířka (v počtu cifer včetně event. desetinné tečky a znaménka), a počet desetinných míst. Celá čísla mají počet desetinných míst nulový a tedy neobsahují ani desetinnou tečku.

3.9.1.2 Znaková (textová) data - C

Jakékoliv texty, obsahující jakékoliv znaky většinou podle kódových tabulek znaků. Charakteristikou je jejich šířka, tj. maximální počet znaků.

3.9.1.3 Datumová data - D

Kalendářní datum bývá zavedeno jako samostatný typ proto, že jsou na něm definovány přirozeným způsobem operace přičítání a odečítání celého čísla, avšak tyto operace nejsou běžné aritmetické operace (např. přechod přes konec měsíce nebo roku). Jejich šířka je vždy konstantní, nejčastěji 8.

3.9.1.4 Logická data - L

Dvouhodnotová data: ANO a NE. Používají se jako indikativní ukazatele apod. Jejich šířka je vždy konstantní, nejčastěji.

Různé implementace mohou zavádět další typy údajů; shora uvedené čtyři typy však postačují pro většinu aplikací běžných aplikací.

3.9.2 Organizační příkazy

3.9.2.1 Vytvoření nové tabulky

Vytvořením nové tabulky se ve většině systémů rozumí založení nového souboru s daným jménem, který obsahuje dvě části: jednak popis jednotlivých sloupců tabulky, jednak vlastní data tabulky organizovaná do řádků. Bezprostředně po vytvoření nové tabulky je druhá část prázdná (zatím nejsou vložena žádná data). Vytvoření tabulky ČERPÁNÍ provede následující příkaz:

Po klíčových slovech CREATE TABLE se tedy uvede jméno tabulky a za ním, uzavřený v kulatých závorkách, seznam popisů jednotlivých sloupců tabulky (=polí řádků). Každý popis obsahuje jméno sloupce následované znakem ve smyslu typu s uvedením celkové šířky event. počtu desetinných míst. Příkaz

provede totéž, ale navíc nadefinuje indexovou tabulku (se jménem stejným jako jméno pole VRT) obsahující přístupový klíč, jehož hodnotami budou kódy vrtů zařazovaných řádků dat.

3.9.2.2 Úprava struktury tabulky

Úpravou struktury se rozumí přidání nebo vypuštění sloupce tabulky. Bez bližších komentářů jsou uvedeny příklady charakteristického tvaru:

přidá do tabulky ČERPÁNÍ nový sloupec VYDADNOST. vypustí sloupec VYDATNOST z tabulky ČERPÁNÍ. vytvoří k tabulce ČERPÁNÍ další indexovou tabulku; klíčem je stonásobek hodnoty MNOŽSTVÍ a indexová tabulka je nazvána KLÍČ

3.9.2.3 Naplnění (doplnění) tabulky daty

Do existující tabulky (např. právě vytvořené) je možno přidávat data. Do shora vytvořené tabulky ČERPÁNÍ se přidají nové řádky příkazem např.

Příkaz přidá na konec tabulky nový řádek dat a naplní ho hodnotami uvedenými jako seznam v kulatých závorkách. Data musí být uvedena v takovém množství, kolik je polí, a musí následovat v tom pořadí, jak byla pole uvedena při vytvoření tabulky.

3.9.2.4 Změna údajů v tabulce

Aktualizaci existujících dat v existující tabulce provádí příkaz UPDATE. Např. zvýšení množství čerpání o 0.1 u všech řádků s hladinou pod 100 provede příkaz

Vynulování hladiny a množství u 4. řádku provede příkaz Výrazem za klíčovým slovem WHERE se určuje množina řádků, pro které se má náhrada (=aktualizace) provést.

3.9.2.5 Vypuštění řádků tabulky

Otázka vypouštění řádků je poněkud složitější. Příkaz

doslova přeložen vypustí z tabulky ČERPÁNÍ řádky, kde je hladina pod 100 a množství nad 1. Problém spočívá v nebezpečnosti akce. Pokud (např. omylem) by byly vypuštěny jiné řádky než uživatel skutečně vypustit chtěl, obtížně by se zajišťovala náprava.

Proto většina SQL provedou nikoliv fyzické vypuštění, ale pouze označení řádků za neplatné. Toto označení lze především příkazem RECALL odstranit, takže se žádné řádky neztratí. Dále: při jakémkoliv dalším zpracování se takto označené řádky nebudou vůbec brát v úvahu. Při výběrech dat, při aktualizaci atd. to bude vypadat tak, jako by tam tyto řádky skutečně nebyly.

Fyzické zrušení (vypuštění, odstranění) řádků z databáze pak provede specielní, k tomu určený příkaz, který většinou závisí na implementaci. Je-li např. SQL implementováno v prostředí xBase, je tímto příkazem PACK.

3.9.3 Čerpání údajů z databází

Tento odstavec je stěžejním odstavcem celé kapitoly. Zatímco organizaci databází (jejich zakládání a aktualizaci) - zvláště informačních systémů větších rozsahů - provádí většinou specializovaní nebo alespoň zvlášť určení pracovníci - správci databází, čerpat z databází by měli mít potřebu všichni.

Ke získávání informací z existujících bází dat slouží v SQL jediný příkaz - SELECT. Jde o velmi silný, poměrně obecný a tedy poněkud složitější příkaz. Proto bude vysvětlen v jednotlivých krocích.

Jako příklad budeme uvažovat uvedenou část modelové databáze geologických souvrství. Konkrétně půjde o tabulky VZORKY, VRSTVY, SOUVRSTVÍ.

Obecně lze říci, že příkaz SELECT vybere určené údaje z určených databází (tabulek) a vytvoří tabulku novou. Může jít o tabulku fyzickou (tj. soubor na médiu), tabulku dočasnou (soubor, který se po ukončení zpracování automaticky z média vymaže) nebo o textový výstup, většinou formou výpisu "ve sloupečcích" ať na obrazovku, nebo na tiskárnu nebo do textového souboru.

3.9.3.1 Údaje z jedné tabulky

Mějme tedy tabulku VZORKY, která má pole SOUVRSTVI, VRSTVY, VRT, HLOUBKA. Následně jsou uvedeny nejjednodušší tvary příkazu SELECT.

vybere všechny sloupce ze všech řádků tabulky VZORKY, a tyto údaje zašle na standardní výstup, kterým je většinou obrazovka terminálu nebo počítače. vybere sloupce VRT a HLOUBKA ze všech řádků tabulky VZORKY, a tyto údaje zašle na standardní výstup, kterým je většinou obrazovka terminálu nebo počítače. vybere sloupce VRT a HLOUBKA z tabulky VZORKY, a tyto údaje zašle na standardní výstup, kterým je většinou obrazovka terminálu nebo počítače. Klíčové slovo DISTINCT zajišťuje, že ve vytvořené tabulce nebudou žádné dva řádky stejné - řádků tedy bude nanejvýš stejný počet jako ve zdrojové tabulce VZORKY. vybere sloupce VRT a HLOUBKA ze všech řádků tabulky VZORKY, a tyto údaje zpracuje pro standardní výstup, kterým je většinou obrazovka terminálu nebo počítače. Na výstupu však druhý sloupec nebude obsahovat původní údaje o hloubce, ale údaje přepočtené podle uvedeného výrazu (přepočet na palce). Tento druhý sloupec výstupu také nebude mít název HLOUBKA, ale PALCE. vybere sloupce VRT a HLOUBKA ze všech řádků tabulky VZORKY, a z těchto údajů vytvoří novou tabulku VÝBĚR. Tabulka VÝBĚR bude mít dva sloupce VRT a HLOUBKA (v tomto pořadí) s atributy i hodnotami dat přejatými z tabulky VZORKY. Počet řádků obou tabulek bude shodný. Vybere sloupce VRT a HLOUBKA ze všech řádků tabulky VZORKY, a z těchto údajů vytvoří novou tabulku VÝBĚR. Tabulka VÝBĚR bude mít dva sloupce VRT a HLOUBKA (v tomto pořadí) s atributy i hodnotami dat přejatými z tabulky VZORKY. V tabulce VÝBĚR však budou zařazeny jen údaje z těch řádků tabulky VZORKY, ve kterých je HLOUBKA větší než 100. vybere sloupce VRT a HLOUBKA ze všech řádků tabulky VZORKY, a z těchto údajů vytvoří novou tabulku VÝBĚR. Tabulka VÝBĚR bude mít dva sloupce VRT a HLOUBKA (v tomto pořadí) s atributy i hodnotami dat přejatými z tabulky VZORKY. Řádky v tabulce VÝBĚR budou seřazeny (ascending - vzestupně) podle kódů vrtů (A18 bude před B11). Pokud dva řádky budou mít shodný kód vrtu, bude rozhodovat hloubka: [V18,140] bude před [V18,120], protože u jména HLOUBKA je uvedeno klíčové slovo descending - sestupně. as NAHORE from VZORKY group by VRT je jednou z velmi silných možností příkazu SELECT. Příkaz v tomto tvaru provádí nejprve myšlené seskupování ("grupování") řádků zdrojové tabulky VZORKY podle údajů ze sloupce VRT - v každé takové skupině jsou ty řádky tabulky VZORKY, které mají stejnou hodnotu ve sloupci VRT. Na výstupu se pak vytvoří tolik řádků, kolik je skupin (tj. kolik různých kódů vrtů je ve vstupní tabulce).

Výstupní tabulka bude mít tři sloupce. První (se jménem VRT) bude obsahovat kód vrtu společný všem řádkům skupiny. Druhý (se jménem DOLE) bude obsahovat nejmenší z hodnot HLOUBKA v této skupině. Analogicky třetí sloupec (se jménem NAHORE) bude obsahovat největší z hodnot HLOUBKA v této skupině.

Je možno použít seskupování podle více kriterií. Například klauzule vytvoří tolik skupin, kolik je ve vstupní tabulce různých dvojic [SOUVRSTVI,VRT].

3.9.3.2 Údaje ze dvou tabulek

Výstupní tabulku lze vytvořit na základě údajů ze dvou a více zdrojových tabulek. Nejjednodušší je případ dvou tabulek.

Tento základní tvar příkazu SELECT obsahující dva zdrojové soubory pracuje následovně: především je vytvořena kombinace všech řádků (se všemi sloupcovými údaji) jedné zdrojové tabulky a všech řádků (se všemi sloupcovými údaji) druhé zdrojové tabulky.

Výstupní tabulka je vytvořena ze všech těchto zkombinovaných řádků s tím, že bude mít tři sloupce; v prvním budou data ze sloupce VRT té části, která vznikla z tabulky VZORKY; ve druhém budou data ze sloupce HLOUBKA té části, která rovněž vznikla z tabulky VZORKY; konečně ve třetím budou data ze sloupce NAZEV té části, která vznikla z tabulky SOUVRSTVI.

Toto je přesný popis vzniku tabulky. Je zřejmé, že právě v uvedeném příkladě se většinou ve výstupní tabulce ocitnou nesmyslné kombinace údajů. Jestliže např. vrt A18 zasahuje jen do ostravského souvrství (tj. logická je jen kombinace [O,A18]), přesto se ve výstupní tabulce objeví i kombinace [K,A18] a případné další.

Je proto zapotřebí vybrat jen ty kombinace, které logicky vyplývají z dat vzorků. To provede tvar příkazu SELECT s již dříve uvedenou klauzulí WHERE:

Nyní jsou do výstupní tabulky ze všech možných kombinací zařazeny jen ty, kde kód SOUVRSTVÍ ve VZORKU je rovno KÓDU v SOUVRSTVÍ. Tento mechanismus je možno považovat za vytvoření "filtru" mezi VZORKY a SOUVRSTVÍmi. "Odfiltrují" se všechny řádky, které nesplňují podmínku uvedenou za WHERE, jinak zde: ke každému řádku ze VZORKŮ se připojí ten řádek ze SOUVRSTVÍ, který má shodný kód s kódem souvrství ve VZORCÍCH. Klauzuli WHERE je možno dále rozšířit o běžné podmínky výběru, např.

Funkce je zcela totožná jako shora až na to, že ve výstupní tabulce budou zahrnuty jen ty řádky, kde je větší hloubka než 100.

3.9.3.3 Údaje z více tabulek

Pro tři a více tabulek platí zřejmá analogie se dvěma tabulkami. Nejprve se vytvoří mezi-tabulka tvořená ze všech možných kombinací všech řádků všech zdrojových tabulek. Výstupní tabulka bude mít tolik sloupců, kolik je určeno výčtem za klíčovým slovem SELECT. Na výstup se dostanou jen ty řádky, které splní podmínku uvedenou za WHERE. Tedy např. pro čtyři tabulky příkaz

ponechá ve výstupní tabulce jen ty řádky, které mají shodné "vazební" prvky uvedené na každé straně rovnítek.

3.9.3.4 Údaje podmíněné údaji v jiných tabulkách

Síla příkazu SELECT se násobí možností použít jeden příkaz SELECT uvnitř jiného příkazu SELECT. Především je možno "na konec" jednoho příkazu SELECT připojit klauzulí UNION další příkaz SELECT, který tabulku vytvořenou prvním příkazem doplňuje o data vytvořená druhým příkazem (a za druhým SELECT lze po UNION psát třetí atd). To zhruba odpovídá postupnému vytvoření dvou a více samostatných tabulek a jejich následným spojením příkazem APPEND.

Zde však popíšeme druhé, daleko důležitější umístění druhého příkazu SELECT: při definování podmínek, za kterých se řádek ve výstupní tabulce vytvoří.

Tento příkaz SELECT obsahuje druhý příkaz SELECT použitý v klauzuli WHERE; "vnitřní" příkaz se provede nejdříve a vytvoří (dočasný) seznam kódů vrtů, kde se čerpalo (alespoň jednou) větší množství než 10. Následuje tvorba výsledné tabulky obsahující sloupce VRT a HLOUBKA z tabulky VZORKY již popsaným způsobem. Do výsledné tabulky se však umístí jen ty řádky, které vyhovují podmínce uvedené v klauzuli WHERE - zde ty, kde se kód VRT vyskytuje v (in) seznamu vytvořeném oním "vnitřním" příkazem SELECT (tedy v seznamu vrtů, v nichž bylo alespoň jednou čerpáno větší množství než 10).

Při vytváření výsledné tabulky obsahující sloupce VRT a HLOUBKA z tabulky VZORKY se pro každý řádek nejprve zjistí, zda je splněna podmínka daná klauzulí WHERE; tj. zda existuje (exists) alespoň jeden řádek tabulky vytvořené "vnitřním" příkazem SELECT. Ten vybere z tabulky ČERPÁNÍ všechny řádky mající kód vrtu shodný s kódem právě zařazovaného řádku z tabulky VZORKY. Pokud existuje, řádek se zařadí; pokud neexistuje, řádek se nezařadí. Výsledná tabulka tedy bude obsahovat údaje jen o těch vrtech, ze kterých bylo čerpáno.

Při vytváření výsledné tabulky obsahující sloupce VRT a HLOUBKA z tabulky VZORKY se pro každý řádek nejprve zjistí, zda je splněna podmínka daná klauzulí WHERE; tj. hloubka vrtu je alespoň o 10 větší než všechny hladiny při čerpáních počínaje rokem 1997.

Při vytváření výsledné tabulky obsahující sloupce VRT a HLOUBKA z tabulky VZORKY se pro každý řádek nejprve zjistí, zda je splněna podmínka daná klauzulí WHERE; tj. hloubka vrtu je alespoň o 10 větší než alespoň jedna hladina při čerpáních počínaje rokem 1997.

3.10 SQL v geostatistice a matematické geologii

3.10.1 Základní statistické charakteristiky

Protože zvláště geologická a jim podobná data jsou převážně nazírána stochasticky, jsou základní statistické charakteristiky prvními informacemi o souboru požadované uživateli.

3.10.1.1 Počet, průměr

Jak počet, tak průměr jsou základními funkcemi dotazovacích jazyků. Tak např. výsledkem dotazu SQL tvaru select count (HLOUBKA), avg (HLOUBKA) from VRTY je počet vrtů a průměrná hloubka všech vrtů. Dotaz může obsahovat všechny další klauzule popsané v kapitole SQL shora, zvláště WHERE pro výběr jen z některých řádků.

3.10.1.2 Minimum, maximum

Minimum a maximum jsou základními funkcemi dotazovacích jazyků. Tak např. výsledkem dotazu SQL tvaru

je nejmenší a největší hloubka všech vrtů. Dotaz může obsahovat všechny další klauzule popsané v kapitole SQL shora, zvláště WHERE pro výběr jen z některých řádků.

3.10.1.3 Rozptyl, směrodatná odchylka

Rozptyl (disperze, variance) a směrodatná odchylka (angl. standard deviation) jsou dalšími základními funkcemi dotazovacích jazyků. Tak např. výsledkem dotazu SQL tvaru

je rozptyl a směrodatná odchylka hloubek všech vrtů. Dotaz může obsahovat všechny další klauzule popsané v kapitole SQL shora, zvláště WHERE pro výběr jen z některých řádků.

3.10.2 Frekvenční tabulka

Základní tabulku např. pro grafické znázornění absolutních a relativních četností vytvoří následující dotaz:

Takto vytvořená tabulka může být přímo otevřena populárními tabulkovými procesory jako Excel, Lotus nebo Quattro pro grafické zpracování četností.

3.10.3 Medián, kvartily

Přímý dotaz na tyto základní neparametrické charakteristiky, tolik potřebné v geo- praxi, není prostředky dotazovacích jazyků možný (neexistuje standardní funkce obdobná např. AVG z SQL). Neelegantní, avšak nejjednodušší je zřejmě dotaz na setříděné pole předmětné veličiny a pak "ruční odpočítání" hodnoty uprostřed resp. v první a třetí čtvrtině: select HLOUBKA from VRTY into cursor DATA order by HLOUBKA Většina systémů tento dotaz umístí do prohlížecího okna opatřeného indikátorem čísla aktuálního řádku a celkového počtu řádků. Proto zjištění požadovaných řádků není příliš obtížné. Pro výpočet mediánu pro lichý počet dat lze použít i následujícího obratu (_tally je identifikátor obsahující počet vybraných řádků příkazem SELECT): select HLOUBKA from VRTY into array DATA order by HLOUBKA s tím, že medián je pak dán hodnou výrazu DATA [ _tally / 2 ] a např. dolní kvartil hodnotou DATA [ _tally / 4 ] ovšem pouze pro _tally/4 skutečně "čtvrtící" soubor dat.

3.10.4 Semivariogram

Hodnoty semivariancí jako základního nástroje pro strukturální analýzu lze získat poměrně jednoduše - rozhodně pracnost při sestavení dotazu je zcela zanedbatelná oproti ručnímu vyhodnocování. Výborně se zde hodí právě vlastnost dotazu SELECT při práci s více tabulkami najednou: do výběru kombinuje ze všech vstupů stylem "každý s každým". Výsledkem dotazu je relační databáze, která může sloužit jako přímý vstup pro zobrazení experimentálního semivariogramu např. programy Excel, Lotus, Quattro apod.

Sestavení dotazu popíšeme nyní podrobněji, protože právě na tomto příkladu lze dokreslit sílu nástrojů pro zpracování databází. Mějme v relační databázi VSTUP přímo připravená data; ve sloupci XX a YY souřadnice v terénu, ve sloupci ZZ hodnoty sledované veličiny. Hodnoty SMVAR semivariancí s krokem označeným HH umístí do relační databáze VÝSTUP následující dotaz:

Dotaz především používá vstupního souboru dvakrát; pro výstup se tedy zpracují všechny kombinace všech bodů vstupu. Podmínka v klauzuli WHERE však zajistí, že se tak nezpracuje kombinace bodu se sebou samým.

První sloupec výstupní databáze obsahuje třídy vzájemných vzdáleností tak, jak to požaduje definice semivariogramu. Pythagorovou větou se zjistí vzájemná vzdálenost dvou bodů, zaokrouhlení podílu této vzdálenosti a zvoleného kroku dá hodnotu, kolikrát je vzdálenost větší než zvolený krok, a konečně vynásobením zvoleným krokem se získá přímá hodnota středu třídy. Semivariance je pak polovina průměrné kvadratické odchylky sledovaných hodnot v jednotlivých třídách. Tvoří druhý sloupec výstupní databáze. Stejné hodnoty středů tříd jsou prvkem, které řídí seskupování (group by) do skupin, ve kterých se průměrování provádí. Výsledná databáze je setříděna (order by) podle hodnot středů tříd.

Obr. 3.10: Semivariogram zinku

Výsledná databáze může pak být přímo zpracována vhodným programem do grafického tvaru -semivariogramu. Uvedeným dotazem byla vytvořena tabulka semivariancí hodnot zinku získaných z vertikálního vrtu s krokem 52 [m], kterou vykreslil program Excel do grafu na obr.3.X. V tomto případě šlo o lineární strukturu, proto hodnoty XX byly hloubkové údaje, hodnoty YY byly všechny rovny nule.

3.10.5 Lokální odhady

V geovědách se běžně používá topografické a prostorové zobrazení lokálních odhadů sledované veličiny v zájmové ploše. Základem jsou obecně známé matematické postupy; z nich ukážeme realizaci metody nazývané metoda inverzních vzdáleností (ID). Metoda zjistí lokální odhad v místě o souřadnicích [x0,y0] jako vážený průměr všech daných hodnot, kde váhami jsou reciproké hodnoty vzdáleností jednotlivých zadaných bodů od místa [x0,y0].

Mějme tabulku (naměřených) hodnot; použijeme tabulku s výsledky geochemických analýz vzorků půd se jménem PŮDY z oblasti Ostravy, kde [x,y] jsou souřadnice místa odběru, (z) je analyzovaná hodnota. Dotaz tvaru

zjistí potřebné součty, takže lokální odhad v [x0,y0] je dán výrazem SM [1] / SM [2]

Základem zobrazovací části zmíněných programů je dopočet lokálních odhadů do uzlů obdélníkové sítě pokrývající zájmový terén, a následné zobrazení hodnot v uzlech prostorově jako známý "drátěný model" nebo topograficky interpolací na úsečkách sítě.

Topografické, ale zvláště prostorové zobrazení hodnot v obdélníkové síti zvládne téměř každý kvalitnější program. Obrázek v této kapitole byl připraven programem Excel. Pokud tedy jde pouze o tuto úlohu, netřeba kupovat náročné a drahé - byť komplexní - programy; lze použít postupu naznačeného dále. V tomto příkladu je modelována plocha lokálních odhadů na kilometrové síti s jihozápadním rohem [470,1190] a severovýchodním rohem [490,1210]. Nejprve se vytvoří tabulka, obsahující souřadnice všech uzlů sítě:

Dále se využije vlastnost dotazu SELECT při práci s více tabulkami najednou: do výběru kombinuje ze všech vstupů stylem "každý s každým". Vytvoří se tabulka kombinací všech uzlů se všemi zadanými daty: Konečně tabulku lokálních odhadů v uzlech sítě vytvoří dotaz s připraveným čitatelem a jmenovatelem zlomku udávající odhad; ten se dopočte jednorázově např. příkazem update TABODH set ODHAD = SumM/SumR Tabulka odhadů TABODH je běžná relační databáze, která svými položkami x₀, y₀ a ODHAD může být vstupem zmíněných obecných programů, např. Excelu ap. Právě tak byl vykreslen následující obrázek (obr. 3.11).

Obr. 3.11: Prostorový model