Knihovnický informační systém pro vysokou školu

Transkript

1 Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování Knihovnický informační systém pro vysokou školu Implementace aplikace CLAVIUS pro BIVŠ Diplomová práce Autor: Jiří Šimeček Informační technologie, manažer projektů IS Vedoucí práce: Ing. Vladimír Beneš Praha Duben, 2009

2 Prohlášení: Prohlašuji, že jsem diplomovou práci zpracoval samostatně s použitím uvedené literatury. V Praze dne Jiří Šimeček

3 Poděkování: Chtěl bych tímto poděkovat Ing. Vladimírovi Benešovi Petrovickému za vstřícný a profesionální přístup. Dále za korekturu práce a její správné nasměrování. Chtěl bych také poděkovat za ochotu mým kolegům a blízkým, kteří mne podpořili, umožnili načerpat znalosti a ověřit je v praxi.

4 Anotace: Tato práce předkládá obecné informace o některých databázích. Vrací se do historie a popisuje počátky databázových systémů. Přibližuje některé technické a programovací přístupy k vývoji databází. Popisuje vybrané zásadní rozdíly mezi těmito přístupy z úhlu pohledu programátora a koncového uživatele. Blíže se věnuje relačnímu modelu správy dat a představuje významné, světově proslulé produkty této kategorie. Seznamuje čtenáře s uplatněním databází v oboru knihovnictví. Prezentuje konkrétní ukázku implementace řešení informačního systému pro správu univerzitní knihovny. Představuje některá novátorská řešení v oblasti digitalizace knihoven. Klíčová slova: Databáze, Relační databáze, Relace, SQL, Knihovna, AACR2, UNIMARK, MARK21, ISBD, Z39.50, Dublin Core, OPAC, OAI-MPH, INDEX. Annotation: This work presents general information about certain databases. It goes back into history and describes the beginnings of database systems. It introduces some technical and programming approaches to database development. It describes selected important differences between those approaches from the viewpoint of the programmer and end user. It covers in more detail the relational model of data administration and it presents important, world famous products of that category. It familiarizes the reader with the application of databases in the field of librarianship. It presents a concrete demonstration of implementation of an information system solution for the administration of a university library. It introduces some innovative solutions in the area of library digitalization. Keywords: Database, Relational of database, Relation, SQL, Library, AACR2, UNIMARK, MARK21, ISBD, Z39.50, Dublin Core, OPAC, OAI-MPH, INDEX.

5 Obsah ÚVOD DATABÁZOVÉ MODELY UVEDENÍ DO PROBLEMATIKY A VÝKLAD DŮLEŽITÝCH POJMŮ HISTORIE POČÍTAČOVÉ SPRÁVY DAT Počátky databází Síťový databázový model Hierarchický databázový model Relační databázový model Objektový databázový model Objektově - relační databázový model Nativní XML databázový model Textové a hypertextové databázové modely RELAČNÍ MODEL DATABÁZE RELACE ENTITA, ATRIBUT, DOMÉNA RELAČNÍ VAZBY INTEGRITNÍ PRAVIDLA A OMEZENÍ NORMÁLNÍ FORMY VYUŽITÍ DATABÁZÍ V KNIHOVNICTVÍ KATALOGIZACE POČÁTKY MEZINÁRODNÍ INTEGRACE TRADIČNÍ KNIHOVNICKÉ SYSTÉMY IMPLEMENTACE SYSTÉMU CLAVIUS OBECNÝ POPIS SYSTÉMU Akvizice Katalogizace Vyhledávání Výpůjční protokol Komunikační standardy IMPLEMENTACE CLAVIUS PRO BIVŠ BUDOUCNOST INFORMATIKY V KNIHOVNICTVÍ DIGITALIZACE Dublin Core RDF OAI-PMH DIGITÁLNÍ KNIHOVNY ZÁVĚREČNÉ SHRNUTÍ A VYHODNOCENÍ SEZNAM POUŽITÉ LITERATURY... 68

6 Úvod Cílem této práce je předložit čtenářům souhrnné informace o praktickém využití databázových systémů a informačních technologií v oboru knihovnictví, který se stal doslova vědeckou disciplínou. Překotný vývoj v oblasti informačních technologií způsobil, že různí výrobci se ubírali každý jiným směrem, což mimo jiné způsobilo, že v různých etapách vývoje vznikaly odlišné databázové modely. Snažím se je v této práci popsat a definovat jejich základní rozdíly. Detailně se věnuji relačnímu modelu správy dat, jelikož většina dnes využívaných knihovnických katalogizačních systémů pracuje právě v tomto datovém modelu. Předkládám popis, implementaci a přizpůsobení konkrétního softwarového řešení Clavius, který je postaven na relační databázi Microsoft Visual FoxPro a poskytuje elektronickou správu a organizaci knihovny. Řešení Clavius má architekturu server klient, komunikace v systému probíhá přes síťové protokoly a obsahuje běžné internetové standardy, protože v dnešním globalizovaném a elektronicky komunikujícím světě se přenos informací jiným způsobem jeví příliš pomalý, tudíž neefektivní. Obsahem mé práce je návrh rozšíření konkrétního, stávajícího funkčního řešení o další možné moduly a funkcionality, které přináší automatizaci některých činností, v současnosti nevykonávaných anebo vykonávaných manuálně, což zvýší efektivitu činností v knihovně. V obecné rovinně řešení stávajících databázových systémů se v práci zaměřuji na některé těžkosti, které do úspěšného aplikování informačních technologií v knihovnictví vnáší jazyky a písemnictví, zejména v oblasti mezinárodní integrace systémů. Přes veškerou rozšířenost relačních databází vidím budoucnost knihovnictví ve využití nejmodernějších nástrojů informačních technologií, která spočívá v digitalizaci a inovativní indexaci skenovaných dokumentů. 6

7 1 Databázové modely Databáze, jejich vznik a postupný vývoj v rozdílných modelech správy dat je neodlučitelněě spojen s postupným vývojem počítačů. V roce 1959 vzniklo seskupení Data Systems Languages (CODASYL), ustavené ministerstvem obrany USA pro standardizaci programových aplikací. Výsledným produktem byl COBOL 1. Dalším pokrokem byl přechod k magnetickým diskům, namísto dříve používaných magnetických pásek, které umožňovaly jen sériový přístupp k datům, což už z principu značně stěžovalo vyhledávání dat a možnost definice nějakého efektivnějšího modelu databáze. 2 Tabulka 1: Zásadní milníky vývoje datových modelů na časové ose založení konsorcia CODASYL úkol - vytvořit koncepci databázových systémů výsledek - COBOL (COmmon Business Orientedd Language) první integrovaný datový sklad s náznakem datového managementu a podobnými vlastnostmi tvůrce Charles Bachman z General Electric Vytvořen Hiearchický model správy dat Systém IMS vytvořen v IBM pro program Apollo Database Task Group prezentuje první síťový model správy dat publikování relačního modelu správy dat tvůrce Dr. Edgar F. Codd, zaměstnanec IBM počátky objektového modelování správy dat Encore-Ob/Server (Brown University), EXODUS (University of Wisconsin) Dimenzionální modely Nativní XML modelování, indexace textů, metadata, Dublin Core Podrobnějšímu popisu zmíněných technologií a jejich postupného vývoje se věnují následujícíí podkapitoly. 1 COmmon Business Oriented Language. 2 Zdroj: ALLAN, R. A. A History of the Personal Computer: The Peoplee and the Technology. London, Ont.: Allan Pub., ISBN: :

8 1.1 Uvedení do problematiky a výklad důležitých pojmů Databázi ve velmi obecné rovině lze chápat jako určitou uspořádanou množinu uložených informací (dat) společně s informacemi o metodě, logice a struktuře tohoto uložení. Není to hromada dokumentů naházená ve skříni. Kartotéka s popisem metodologie a způsobu jejich uložení by se za jistou formu mechanické databáze již považovat dala. Základním účelem správy dat je strukturovaná a metodická práce s informacemi, které se určitým a popsaným způsobem ukládají tak, aby byly strukturovaně řazené dle různých typů, kategorií a oblastí, dle kterých je jednou budeme chtít vyhledávat a třídit. Základním důvodem této metodické práce s informacemi je jejich efektivní a hlavně rychlé ukládání, řazení a následné vyhledávání dle různých předem definovaných kriterií. Pro účely této práce považuji za důležité vyložit a upřesnit několik velmi důležitých pojmů, které souvisí s popisovanými technologiemi. GUI, SŘBD, SQL, Konceptuální a logický model databáze. Výklad těchto pojmů předkládám v následujících podkapitolách GUI Pojem GUI 3 nesouvisí pouze s databázemi. Je to obecné pojmenování pro soubor grafických prvků, které slouží pro komunikaci a práci uživatele s počítačem. V současnosti to jsou interaktivní ikony, tlačítka, okna a další ovládací prvky každého programu, tak jak je vidí uživatel na obrazovce, display či monitoru jakéhokoli počítače. GUI prvních programů bylo velmi strohé, vše začínalo jednobarevným pozadím a textovou příkazovou řádkou. Uživatel musel znát přesné názvosloví příkazů a parametrů, které vkládal prostřednictvím klávesnice do textového příkazového řádku. Absolutní světové vedení ve vývoji grafického prostředí na počítačích nelze upřít vývojářům ze společnosti XEROX corp. a APPLE inc. V dobách kdy většina uživatelů jiných platforem ještě psala příkazy z klávesnice ve formě textových příkazových řádků, majitelé JABLEK už klikali myší na ikony umístěné na ploše v přehledném systému složek, podsložek a souborů. 3 Anglická zkratka Graphical User Interface. 8

9 1.1.2 SŘBD Databáze v dnešním pojetí je počítačový systém řízení báze dat (SŘBD 4 ). Je to program nebo několik integrovaných programových celků fungujících jako rozhraní mezi daty v databázi a uživatelem, případně aplikačním programem. Slouží k definici a konstrukci popisu metody ukládání dat a poté k další manipulaci s nimi. SŘBD umožňuje oddělit samotná data od jádra zdrojového kódu aplikace. Takže databáze umožňuje pohodlně měnit strukturu dat bez nutnosti změn přeprogramování zdrojového kódu programu databáze. Základní složky databáze tvoří: Programovací jazyk pro vytváření, definování a změny datových struktur. Dotazovací jazyk pro manipulaci s daty. Programové rozhraní pro tvorbu formulářů, prezentaci dat a tiskových sestav. Program pro řízení přístupu uživatelů k datům. Jmenované části společně s datovou základnou tvoří databázi (databázový systém) SQL Pro práci s konkrétními informacemi (daty) bylo nutné vytvořit takzvaný dotazovací jazyk, který bude realizovat dotazování na konkrétní položky nebo vybrané množiny položek v databázi. Pro relační model databáze je dnes standardem jazyk SQL 5. Jedná se o neprocedurální dotazovací jazyk, založený na teorii množin a relační algebře, optimalizovaný pro práci s relačními databázemi. Používá se pro všechny typy operací s konkrétními daty. Vytvoření množiny nových dat, definování tabulek, indexů, nastavení integritních omezení, změny dat a samozřejmě výběr dat z databáze. Slovník je odvozen z angličtiny, jednoduchá syntaxe připomíná věty přirozeného jazyka. Např. příkaz "SELECT Autor FROM Knihy WHERE Cena>100" lze přeložit českou větou "Vyber autory knih, s cenou přesahující 100 Kč". V současné době se tento jazyk používá ve většině dostupných relačních databázových systémů, buď k interaktivní práci s daty, nebo jako komunikační nástroj v databázích souborové architektury server klient. 4 SŘBD Systém řízení správy dat. Z anglického originálu Data Base Management System, DBMS. 5 Z anglického originálu Structure Query Language. 9

10 1.1.4 Konceptuální model databáze Pro vývoj a tvorbu nové databáze je nutné znát pojem konceptuální model databáze (conceptual database model). Jedná se o obecnou metodu umožňující zobrazit a popsat objekty v databázi a vztahy mezi nimi z hlediska jejich významu a chování. Výsledkem konceptuálního modelování je grafické schéma, které je obecné a nezávislé na aplikacích ve kterých se později může databáze programovat nebo implementovat. Konceptuální model je prvním krokem ve vývoji konkrétního databázového řešení. V praxi obvykle vzniká ručními náčrty a definicemi úplně základních entit a vztahů mezi nimi. Výsledkem konceptuálního modelování jsou E-R 6 a ERA 7 diagramy entit a vztahů. Tento model byl zaveden a poprvé použit v roce Brzy se rozšířil a stal se obecně uznávaným standardem 8. Entity se v těchto diagramech popisují pomocí obdélníků, vztahy se znázorňují pomocí kosočtverců. Atributy se mohou znázorňovat pomocí elips (oválů), v takových případech už se jedná takzvané ERA diagramy. Ukázka konkrétního jednoduchého ERA diagramu je na obrázku 1. Obrázek 1: Ukázka ERA diagramu v konceptuálním modelování databáze. KNIHA AUTOR KNIHA autor AUTOR kniha Zdroj: Vlastní. 6 Z anglického originálu Entity Relationship Diagrams. 7 Z anglického originálu Entity Relationship Atributs. 8 POKORNÝ, J.: Databazová abeceda. Science, Veletiny, 1998, str

11 1.1.5 Logický model databáze Bližší rozpracování konceptuálního modelu databáze pro konkrétní programovací prostředí vyúsťuje v logický model databáze (logical database model). Tento model již umožňuje zobrazit, popsat objekty v databázi a vztahy mezi nimi s ohledem na implementaci v konkrétním programovacím prostředí, daném strukturou (organizací) datové základny a konkrétním typem systému řízení báze dat. Logický model je rozšířením konceptuálního modelu o podrobnosti specifické pro dané prostředí, například datové typy, realizaci vazeb mezi daty, integritní pravidla a omezení. Model neobsahuje popis konkrétní fyzické organizace a uložení dat na záznamovém médiu. 1.2 Historie počítačové správy dat Pravděpodobně se nelze přesně dopátrat kdo a kdy byl úplně první tvůrce nějaké databáze. Pokud se někdo zabýval systematickým, cíleným sběrem a ukládáním informací, zejména pak jejich strukturovaném řazení pro účely rychlého a operativního vyhledávání, začal vytvářet první databázi. Kartotéky se strukturovaně ukládanými dokumenty umožňovaly uspořádání informací dle různých kategorií, zatřiďování nových položek a rychlejší vyhledávání. Veškeré operace s nimi prováděl přímo člověk. Správa takových kartoték byla v mnohém podobná správě dnešních databází. Pro obecné účely pojmu není podstatné, jak a kam byly informace ukládány. Ať už to byly zápisy v knihách a ty pak v kartotékách. Důležitá je popsaná struktura a metoda ukládání Počátky databází Počátky strojem zpracovávaných informací začínají v USA, v roce 1890 při sčítání lidu. Statistický úřad Spojených států prohlásil své výpočetní metody za zastaralé a vyhlásil soutěž, která měla najít výkonnější metody pro sčítání velkých objemů dat. Vítězem se stal Hermann Hollerith, německý imigrant a zaměstnanec úřadu, jehož stroj ke čtení dat z děrovacích štítků používal elektrický proud. Na tomto úspěchu v roce 1896 Hollerith vybudoval podnik Tabulating Machine Company 9. Když byla v roce 1935 v USA uzákoněna nutnost vedení informací o cca 26 milionech zaměstnanců 10, vytvořila IBM pro zpracování podobných úloh nové zařízení. Byl to první digitální počítač pro komerční využití s názvem UNIVAC I., založený na státem 9 Zdroj: Social Security Act Původní zákon o sociálním zabezpečení. 11

12 podporovaném projektu Electronic Discrete Variable Automatic Computer (EDVAC) z University of Pennsylvania. 11 Vývoj probíhal na mnoha univerzitách a v různých časových obdobích, takže nezávisle na sobě vznikalo několik platforem a myšlenkových proudů, které nakonec vyústily ke vzniku několika odlišných modelů správy dat. V následujících podkapitolách jsou popsány ty základní. Síťový, hierarchický, relační, objektový a zároveň jsou zmíněny nové technologie. XML a nativní přístupy k datům Síťový databázový model V síťovém modelu databáze (network database), jsou data logicky i fyzicky uspořádána jako uzly rovinného grafu, v němž může být každý záznam spojený s libovolným počtem dalších záznamů. Vztahy mezi záznamy jsou vyjádřeny obvykle prostřednictvím ukazatelů (pointerů), speciálních položek obsahujících odkaz na identifikátor souvisejícího záznamu. Manipulace s daty se děje procedurálně, procházením grafu cestou definovanou ukazateli, takzvanou navigací. V praktických implementacích jsou síťové modely zpravidla omezeny, například standard CODASYL připouští pouze vztahy 1:N ( 1 záznam k libovolnému počtu záznamů). Model naprosto převládal v komerčních databázových systémech 80 tých let. Nejznámější produkt byl IDMS od firmy Culliname Corp. Síťová struktura se modeluje pomocí takzvaných Bachmanových 12 diagramů. 13 Základní konstruktory síťového modelu jsou věta a set. VĚTA je souhrn vzájemně souvisejících datových položek. Ta na straně 1 se jmenuje věta vlastnická a na straně N věta členská. SET je vztah mezi dvěma větami vazby 1:N. Set je definován jménem, vlastnickou a členskou větou. Set má své výskyty. Výskyt setu je dán výskytem konkrétního vlastníka a výskytem jeho členů. Rozlišujeme níže uvedené typy setů. Singulární set je takový, ve kterém je virtuální vlastník systém a tento set má pouze jeden výskyt členských vět (kompromisní prostředek, který umožňuje vložit do databáze plochou strukturu). 11 Zdroj: PATTERSON, David A. HENNESSY, L., GOLDBERG, David. Computer Architecture: A Quantitative Approach. 12 Charles Bachman z General Electric Company v roce 1961 představil integrovaný datový sklad s prvním náznakem Data Base managementu a jinými vlastnostmi. Je považován za tvůrce síťové koncepce. 13 Entity-relationship approach to software engineering : proceedings of the Third International Conference on Entity-Relationship Approach, Anaheim, California, U.S.A., October

13 Vícečlenský set může mít více vět (nikoliv výskytu vět) za své členy. Rekurzivní set speciální set pro řešení takzvané konceptuální smyčky, tzn. že daná věta je současně vlastníkem i členem. Dále se rozlišují tyto, níže uvedené typy členství v setu: Automatické výskyt členské věty nově vstupující do databáze je automaticky připojen k odpovídajícímu výskytu v setu. Povinné výskyt členské věty nemůže existovat v databázi, aniž je přiřazen k výskytu určité vlastnické věty. Volitelné výskyt členské věty může existovat v databází aniž je přiřazen k výskytu určité vlastnické věty. Manuální manuálně můžeme volně přesouvat výskyt věty do příslušného výskytu setu. Na našem území se síťový model moc nerozšířil. Systém IDMS pro počítače IBM, DBMS pro SMEP a VAX. IMAGE na počítačích Hewlett-Packard, ADT. Tento model databáze lze dnes označit za překonaný a zastaralý Hierarchický databázový model Databáze založená na hierarchickém modelu je vylepšeným speciálním typem síťového modelu, omezující logické uspořádání dat na stromovou strukturu, jež umožňuje vyjádřit ve směru shora dolů jednosměrné vazby typu 1:N. Pravděpodobně nejznámější implementací tohoto modelu byl systém IMS vyvinutý v šedesátých letech společnostmi IBM a NASA, pro realizaci skladového hospodářství v rámci projektu APOLLO. 14 Základem hierarchického modelu je stromová struktura, kde výchozím prvkem je kořen. Takzvaný kořenový uzel v každém systému existuje pouze jeden a na větvích jsou pak umístěny další uzly, respektive listy, pokud již tyto neobsahují žádnou další větev. Právě větve obsahují vlastní datové struktury. Vztahy mezi záznamy jsou vyjádřeny obvykle prostřednictvím ukazatelů (pointerů), tj. speciálních položek obsahující odkazy na identifikátor souvisejícího záznamu. Manipulace s daty se děje procedurálně, sekvenčním procházením stromem nebo jeho částí (větví). Důležitým faktorem je, že uzly mohou být propojeny nejen v klasickém hierarchickém vztahu rodič syn, ale také v rámci jedné úrovně. Tato skutečnost se podílí i na usnadnění vyhledávání. Není nutné prohledávat celý objem dat, ale pomocí "přesné" navigace po větvích 14 Zdroj: Management, labour process and software development : reality bytes, by Rowena Barrett, New York : Routledge,

14 a listech lze nelézt požadovanou informaci. Pochopitelně i nadále v propojení zůstává omezení na jednosměrnost vazeb 1:N. Jednou z hlavních výhod tohoto databázového modelu je vedle zefektivnění vyhledávání také odklonění se od fyzického modelu uložení dat. Autory aplikací vůbec nemusí zajímat, jak jsou data fyzicky uložena. Pro realizaci hierarchického modelu se obvykle využívá zřetězených seznamů. Jedním z hlavních omezení hierarchického modelu je nutnost přepracování celé struktury databáze v případě změny požadavků na systém správy dat. Jinými slovy, nestačí pouze ubrat či přidat jednu položku s novým požadavkem. Dalším značným omezením je také již zmíněná komplikovanost při realizaci vazeb N:M (například vazba STUDENT KURZ, kdy jeden student může mít více kurzů a jeden kurz může mít více studentů). Právě tento typ vazby je nejběžnější v reálném světě. Úloha je sice řešitelná, ovšem pomocí redundantních přístupů a cyklických vztahů. Tento databázový model je vhodný především pro aplikace, které zpracovávají data založená na hierarchické struktuře, ke kterým patří například organizační či skladové systémy. Pochopitelně i tento model lze v současnosti považovat za poněkud zastaralý a málo používaný. Data ve skladových systémech lze lépe a efektivněji organizovat v relačním modelu databáze Relační databázový model Zakladatel a tvůrce relačního modelu správy dat byl zaměstnanec IBM Dr. Edgar F. Codd, absolvent Oxfordu, který vstoupil do IBM roku Codd v roce 1970 publikoval článek "A Relational Model of Data for Large Shared Data Banks"[2], což byl návrh na implementaci nového datového modelu, který byl nazván "relačním". Codd načrtl možnost, jak použít relační kalkul a algebru i pro netechnické uživatele při ukládání a manipulaci s daty. Relačnímu modelu správy dat se věnuje převážná část této práce, proto bude popsán podrobněji ve třetí kapitole Objektový databázový model Objektová databáze je v podstatě nový datový model, který není postaven jako rozšíření relačního datového modelu. Do jisté míry jde o renesanci původního síťového datového modelu, který je doplněn o možnost práce s objekty tak, jak je známe z objektového programování. Oproti dnes nejrozšířenějšímu relačnímu modelu má nerelační objektově orientovaný datový model následující přednosti. 14

15 Lépe podporuje datové struktury, které známe z objektově orientovaných programovacích jazyků. Není třeba datové struktury tolik transformovat, aby byly uložitelné do databáze. Protože navazuje na síťový datový model, tak má předpoklady pro efektivnější způsoby zpracování velmi složitých dotazů ve srovnání s relačním datovým modelem. Tato vlastnost se projevuje hlavně u složitých datových struktur, které by se v relačním datovém modelu musely rozkládat do mnoha vzájemně provázaných relačních tabulek. Umožňují skladování dat s libovolnou strukturou. Programátor či kdokoliv jiný se při použití objektové databáze nemusí vůbec starat o mapování objektových struktur do dvourozměrných tabulek. Každý persistentní objekt v objektové databázi má svoji vlastní identitu, je tedy jednoznačně odlišitelný od libovolného jiného objektu nezávisle na hodnotách svých vlastností. Odpadají tedy problémy s tvorbou primárních klíčů. Kvalitní objektová databáze podporuje všechny vlastnosti nutné pro práci s objekty, tedy: zapouzdření každý objekt se skládá z množiny atributů definujících stav objektu a dále z množiny metod, které specifikují chování systému. jednoznačná identifikace objektu každému objektu je přiřazen při jeho vzniku jednoznačný identifikátor, který se v průběhu životního cyklu nemění. Není tedy závislý na hodnotách atributů a nemusí mít primární klíč jako jedinečný identifikátor. Každý objekt je jedinečný sám o sobě, což je dáno základním principem objektově orientovaného přístupu. reference mezi objekty hodnoty atributů jednotlivých objektů mohou být samostatné objekty nebo množiny objektů. Hodnota atributu tedy nemusí být atomická, ale může být dále strukturována (množina, seznam). První objektově orientované databáze se objevily již ve druhé polovině 80. let. Vznikly na základě potřeby uchovávat a databázově zpracovávat v pokud možno nezměněné podobě data z programů napsaných v tehdy se rozvíjejících objektově orientovaných programovacích jazycích. Ve srovnání s relačními databázemi, které v té době byly na vrcholu vývoje, to byly systémy velmi neefektivní a málo výkonné. Bylo to dáno tím, že se jednalo čistě o experimentální programy psané jako aplikace v objektovém programovacím jazyce. Přesto existují prakticky použitelné systémy (např. Gemstone, ObjectStore, O2, Versant), 15 které dovolují v databázi zpracovávat objekty ve stejném tvaru, jak se s nimi nakládá v objektových programovacích jazycích. 15 Zdroj: LOOMIS M., CHAUNDRI, A.: Object Databases in Practice, Prentice Hall 1994, ISBN X. 15

16 Po více než deseti letech vývoje je však situace v objektovém přístupu úplně jiná. V praxi již existují případy, kdy nasazení objektové databáze vyřešilo problémy, které relační systém nedokázal zvládnout. Objektové databázové aplikace se objevují již i v ČR. Dnešní objektové databáze jsou poměrně výkonné. Zvládají stovky transakcí za sekundu a tisíce současně připojených uživatelů, ale oproti relačnímu přístupu mají výrazně menší rychlost zpracování dat. Všeobecně je známo, že s objektovými databázovými aplikacemi se můžeme setkat například v informačních systémech letového provozu (např. Finair, Air France), rezervačních systémech osobní letecké dopravy. Informačních systémech pro řízení dopravy zboží, například v Orient Overseas Container Line, jeden ze 3 největších dopravců mezi USA a Evropou. Informačních systémech dodavatelů elektřiny (např. Floria Power & Light), rezervačních hotelových služeb (např. Navigant International Northwest Travel), systémů pro pojištění a další. Objektové databáze, v kombinaci s relačními, také používá pro speciální aplikace mnoho firem. Jsou to například Texas Instruments, BMW, Opel, Ford, JP Morgan, IBM, Hewlett Packard, AT&T a další Objektově - relační databázový model Objektově relační model databáze představuje evoluční trend vývoje. Jde o doplnění relačního datového modelu o možnost práce s některými datovými strukturami, které známe z oblasti objektově orientovaných programovacích jazyků. Většina výrobců velkých relačních databázových systémů (např. Oracle) zvolila tuto variantu. Objektově relační datový model ale ve svých základních principech zůstává původním relačním datovým modelem Nativní XML databázový model Nativní XML databáze je úplně novým typem databáze, která byla vyvinuta na Berkeley University 16. Existence relativně nového směru vývoje dokumentů XML 17, zapříčinil vznik nových typů databázových serverů (Native XML databases). Hlavním úkolem nativních XML databází (dále jen NXD) je uložit XML dokument včetně jeho logické struktury a podoby. Dokument obdržíme zpět přesně v takové podobě, v jaké jsme jej předali databázi, včetně všech poznámek a dalších příloh. 16 Jedním z hlavních tvůrců této databáze je Ronald Bourret. 17 extensible Markup Language je rozšiřitelný značkovací jazyk, který byl vyvinut a standardizován konsorciem W3C. Umožňuje snadné vytváření konkrétních značkovacích jazyků pro různé účely a široké spektrum různých typů dat. 16

17 Princip fyzického ukládání dat je různý. Nativní XML databáze může využívat buď své proprietární řešení nebo využít služeb relační databáze. V současné době lze objevit NXD 18, která bude existovat pouze jako přístupová vrstva, umístěná nad relační databázi. Způsob fyzického ukládání dat, ale není pro tento model podstatný. Mnohem podstatnější jsou funkce, které NXD přináší. Patří mezi ně například možnost indexování uložených dokumentů pro výrazné zvýšení výkonu a možnost provádění dotazů napříč sadou dokumentů umístěných v takzvané kolekci. Pro lepší představu si můžeme přirovnat jeden XML dokument k jedné řádce v relační databázi a kolekci k jedné tabulce v relační databázi. Není ani nutné jít příliš daleko, aby byl vidět zřejmý rozdíl. V NXD lze umístit dokumenty založené na různých XML schématech do jedné kolekce. Pro dotazování v této databázi je často využívaným společným jazykem XPath 19, který se již hojně využívá při XSL 20 transformacích, ale bohužel neimplementuje takové funkce, které by se lépe hodily na skupiny XML dokumentů (agregace a další). S vědomím tohoto nedostatku se vyvíjí několik lepších variant dotazovacích XML jazyků (XQuery, XQL, nebo XML-QL). Momentálně je situace taková, že dotazovací jazyk je silně závislý na použité NXD, dokonce některé NXD mohou implementovat vlastní verze dotazovacích jazyků. Obecně lze ale tvrdit, že pokud je programátor nebo uživatel zvyklý pracovat s XML dokumentem, nebude pro něj velkým problémem zvyknout si na práci s jakoukoli NXD. V praxi známe například nativní XML databázi exist. Ukládá XML dokumenty do své nebo externí databáze. Podporuje standardy XML, DB 21 API 22, standardní HTTP 23. Dále standard umožňující číst a měnit datové elementy databáze podobně jako složky a soubory v klasickém souborovém systému. Nástroj pro administraci je aplikace XMl dbgui Textové a hypertextové databázové modely V podstatě se nejedná o databáze, tak jak jsou obecně databáze chápány (definice objektů, struktury apod.). Jedná se o databáze, jejíž datovou základnu tvoří digitálně reprezentované textové údaje. Základním strukturním elementem je dokument, jehož vnitřní struktura je na 18 Zkratka Nativní XML Databáze. 19 XML Path Language je počítačový jazyk, pomocí kterého lze adresovat části XML dokumentu, lze z dokumentu vybírat jednotlivé elementy a pracovat s jejich hodnotami a atributy. 20 extensible Stylesheet Language je rodina jazyků umožňujících popsat jak se mají XML soubory formátovat a převádět. Obsahuje 3 jazyky: XSL Transformace, XSL-FO a XMLPath. 21 Původní databáze vyvinutá na University of California at Berkeley rozšířená o API rozhraní. 22 Application Programming Interface je sbírka procedur, funkcí či tříd nějaké knihovny i jiného programu nebo jádra operačního systému. Určuje, jakým způsobem se funkce knihovny mají volat ze zdrojového kódu programu. 23 Hyper Text Transfer Protocol je internetový protokol určený pro přenos hypertextových dokumentů. 17

18 rozdíl od záznamů v tradičních databázových systémech (např. relačních) nepravidelná nebo vůbec neexistuje (takzvané nehomogenní, nestrukturované či semistrukturované dokumenty). Například úplná znění textů zákonů, časopisů, knih a podobně. Vyhledávání informací se realizuje buď listováním v databázi nebo formulací dotazu. Přístupovými body k obsaženým informacím mohou být textové řetězce obsažené v textech dokumentů, takzvaná metadata (profily dokumentů s bibliografickými údaji) nebo hypertextové odkazy. Tyto metody jsou však pomalé a nesplňují dnešní nároky na strukturovanou práci s daty. Proto byly vytvořeny programové nástroje, které indexují (označují) obsah textových souborů a následně vytvářejí pomocné indexační soubory se segmenty těchto záznamů. Pomocí těchto souborů se následně urychluje prohledávání dat uložených v souborech s obsáhlými textovými záznamy. Textové databáze pracují s těmito pojmy. Dokument deskriptor, vlastní dokument. Term jedno slovo nebo fráze uvnitř dokumentu. Datové struktury dále obsahuj následující typy souborů: sekvenční, invertovaný, se signaturou. Jeden z uvedených, konkrétně, invertovaný soubor je abecedně setříděný seznam termů. Takzvaný index, jedná se o obdobu indexů v relační databázi. Každý term má přiřazeny ukazatele na dokumenty, které ho obsahují. Deskriptorem dokumentu je seznam jeho termů. Pro zdokonalování invertovaného souboru se ještě pracuje s termínem TF: (term frequency), DF: (document frequency), IDF: (inverse document frequency). Tyto upřesňující specifikace umožňují rozlišení a seřazení výsledků dotazů na dokumenty s prostým výskytem termu a uspořádání výsledku dle vah, počtu zobrazení termů. V současné praxi je známá technologie FULCRUM od společnosti FULCRUM Technologies. Tuto technologii využívá například program OVEL, elektronická verze Obchodního věstníku. 24 Ukázka základního dotazovacího formuláře v programu OVEL je na obrázku Zdroj: ECONOMIA a.s., dostupné na

19 Obrázek 2: Ukázka dotazu v programu OVEL. Zdroj: ECONOMIA a.s., dostupné na Další konkrétní příklady aplikovaných hypertextových databází jsou takzvaní vyhledávácí roboti na internetu. Jeden z nejznámějších a nejvýkonnějších je Google od společnosti Google, inc. Zajímavým, poměrně novým produktem, kterým je také aplikovaná malá hypertextová databáze je program Google Desktop Search. Je to robot, který neustále prohledává lokální úložiště dat v počítači a vytváří metadatové indexy, které následně využívá pro vyhledávání textových informací uložených v souborech. Kvalitu a významný úspěch této, stále ještě docela mladé firmy, lze také dokumentovat tím, že emitovala akcie na americkém trhu technologických akcií NASDAQ. 25 Na obrázku 3 je ukázka stavu indexace v programu Google desktop search. Rozsáhlá a také známá hypertextová databáze je program ASPI od společnosti ASPI Publishing, spol. s r. o. Jedná se o komplexní řešení prohledávání textů zákonů a judikátů. Ukázka vyhledávacího prostředí programu ASPI je v příloze Zdroj:

20 Obrázek 3: Výsledek indexace v aplikaci Google desktop search. Zdroj: Vlastní. 20

21 2 Relační model databáze Relační model 26 databáze, jak již bylo uvedeno, vytvořil a poprvé publikoval zaměstnanec IBM Dr. Edgar F. Codd, absolvent Oxfordu, který v roce 1970 publikoval článek "A Relational Model of Data for Large Shared Data Banks" 27. Relační model správy dat je založený na pevných matematických základech, teorii množin, matematické relace a kartézského součinu. Základní konstrukt tohoto modelu je databázová relace, vypočítaná pomocí vzorců z původní relační algebry. Výpočet vychází z klasické matematické relace, ale oproti ní je výsledkem databázové relace množina kartézských součinů nad množinami jiných kartézských součinů, výsledek lze většinou zobrazit ve formě tabulky se záznamy. Korektním výsledkem relačního výpočtu je množina (seznam) neduplicitních položek záznamů. Všechny matematické operace v relačním uspořádání databáze jsou realizovány dotazovacími jazyky. Definují se tyto kategorie jazyků: Procedurální uživatel specifikuje jaké operace má systém provést pro získání výsledku, uživatel určí posloupnost kroků k výpočtu výsledku. Neprocedurální uživatel určí jak má vypadat výsledek, ale neříká jak výsledek vytvořit Dále jsou definovány takzvané čisté jazyky procedurální a neprocedurální. Relační algebra (procedurální). N-ticový relační kalkul (neprocedurální). Doménový relační kalkul (neprocedurální). Čisté jazyky jsou stručné, formální, bez jakéhokoli takzvaného syntaktického cukru. Čisté jazyky jsou základem dotazovacích jazyků, které se běžně používají. 28 Jedním z čistých dotazovacích jazyků je Relační algebra. Nepracuje s jednotlivými záznamy relací, ale s celými relacemi. Operátory relační algebry se aplikují na relace a výsledkem jsou opět relace. Protože relace jsou množiny, přirozenými prostředky pro manipulaci s relacemi budou množinové operace. Relační algebra v této podobě není vždy implementována v jazycích SŘBD, přesto je její zvládnutí nutnou podmínkou pro správnost manipulací s relacemi. Složitější dotazy jazyka 26 Název relační model a relační databáze je odvozen od faktu, že relace je základním abstraktním pojmem modelu a jedinou strukturální jednotkou databáze na logické úrovni. 27 Zdroj: CODD, E. F. A Relational Model for Large Shared Data Banks. In CACM, 13, 6, June POKORNÝ, J.: Dotazovaci jazyky. Science, Veletiny, 1994, str

22 SQL, který je deskriptivním dotazovacím jazykem, mohou být bez zkušeností s relační algebrou problematické. Základní operace relační algebry jsou: sjednocení relací téhož stupně, průnik relací, rozdíl relací, kartézský součin relace R stupně m a relace S stupně n. Další relační operace jsou: projekce, výběr sloupců relace R na komponenty, selekce, výběr řádků z relace R podle podmínky P, spojení relací R s atributy A a S s atributy B dle relačního operátoru. Výsledkem všech těchto matematických úkonů je vždy nová relace, se kterou systém dále pracuje a je možné si jí představit jako množinu záznamů, kterou lze zobrazit ve formě tabulky. Zásadní výhody relačního modelu databáze jsou: Transparentnost přístupových metod při manipulacích s daty. Poskytnutí matematické podpory pro manipulaci s daty. Poskytnutí matematické podpory k omezení redundance. Velká rychlost zpracování obrovských objemů dat. První skutečnou relační databází na trhu byla v roce 1979 Oracle pro počítače VAX. Výrobce, společnost Oracle Corporation, kterou založil pan Lawrence Ellison 29 se dodnes svými databázovými systémy řadí mezi tři nejprodávanější a nejlepší na světě. Po nějakém čase, po určitých pochybnostech managementu přišla na trh i IBM se svým produktem DB2 (pro počítače MVS). Mezi velké hráče se samozřejmě připojila společnost Microsoft corporation, se svým produktem MS SQL Server. Relační model je velmi rozšířený a vývoj nových technologií správy dat s ním musí stále více či méně počítat. Nový produkt musí obsahovat alespoň SQL dotazovaní a rozhraní pro přístup k datům v databázi. Klíčové pojmy, relace, entita, atribut, doména, relační vazba, integritní pravidla, integritní omezení jsou blíže specifikovány v následujících podkapitolách. 29 Zdroj:

23 2.1 Relace Relace je základní konstrukt tohoto datového modelování, je vypočítaná pomocí vzorců původní relační algebry. Výpočet vychází z klasické matematické relace, ale oproti ní je výsledkem databázové relace množina kartézských součinů nad množinami jiných kartézských součinů, výsledek lze většinou zobrazit ve formě tabulky se záznamy. Korektním výsledkem relačního výpočtu je množina (seznam) neduplicitních položek záznamů. Konkrétní takzvaná zdrojová data jsou uložena v tabulkách. Pro správný výsledek relačního výpočtu není podstatné, v kolika tabulkách jsou uložena zdrojová data, ale podstatná je struktura, identifikace a definice uložených dat. Ta musí splňovat přesné parametry označení vazeb a další podmínky nutné pro realizaci správných výpočtů databázových relací. Na obrázku 4 je velmi zjednodušené grafické znázornění výsledku konkrétní relace. Obrázek 4: Jednoduché grafické znázornění struktury dat v relačním modelu databáze. Zdroj: Vlastní. Dr. Codd definoval jazyk jehož pomocí se vyhledávají informace a manipuluje s daty v databázi. Představil matematické definice pojmů ENTITA a její typ, ATRIBUT a jeho hodnoty a VAZBA a její typ. 23

24 2.2 Entita, Atribut, Doména ENTITA je libovolná existující osoba, věc či jev (objekt) reálného světa. Schopná samostatné existence v abstraktním datovém pojetí. Je to cokoli o čem je potřeba ukládat nějaké informace a nadále s nimi pracovat. Konkrétní entita může být fyzicky existující objekt, jeden určitý výrobek, osoba, dům nebo událost například prodej domu, servis automobilu. Může jít také o zákaznickou transakci, obchod, objednávka. Entita může být jeden určitý zápis z jednání, záznam telefonního hovoru a podobně. Abstraktní entita může být jeden určitý, popsaný vztah mezi jinými entitami. Entita v databázi musí být jednoznačně identifikovatelná a rozlišitelná od ostatních entit. Názorná ukázka jedné entity. Klient banky: Jméno, Příjmení, Identifikační číslo 77, číslo smlouvy 9999, číslo účtu ATRIBUT je charakteristika, určitá vlastnost entity, údaj o entitě (objektu). Atribut přiřadí každé entitě z množiny entit hodnotu z nějaké neprázdné množiny hodnot, nazvané též doména atributu (obor hodnot atributu). Je zadán svým názvem (identifikátorem) a datovým typem. Zjednodušeně se dá uvést, že v tabulkovém zobrazení relace atribut vypadá jako sloupec tabulky, který je označen názvem. Pro názornost příklad konkrétního atributu. U entit VÝROBKY budeme evidovat atribut JMÉNO VÝROBKU. DOMÉNA se dá obecně definovat jako pojmenovaná množina skalárních neprázdných hodnot téhož typu, která popisuje typ dat, které daný atribut reprezentuje. Konkrétní doména je seznam předem daných a přípustných hodnot, které smí atribut obsahovat. Musí to být logický pojem, například věk, vzdělání a podobně. Dá se také říct, že se jedná o spojení datového typu a ověřovacího (validačního) pravidla, které ověří správnost či platnost hodnoty. Pomocí domén se uplatňují doménová integritní pravidla a omezení a databáze se tím udržuje v takzvaném konzistentním stavu. Bude blíže popsáno v následujících kapitolách., 24

25 2.3 Relační vazby Relační vazby jsou definované vztahy asociace mezi relacemi. Jsou naprosto zásadním prvkem relačního modelu správy dat. Typ vazby (kardinalita) významně ovlivňuje výpočty relací. Typy vazeb jsou 1:1, 1:N a M:N, níže jsou názorně popsány rozdíly mezi nimi. Vazba 1:1 se dá na příkladu popsat takto. Každá jednotlivá osoba může mít pouze jednu složku s údaji na matrice. Vazba 1:N odpovídá příkladu skutečnosti, že jedna osoba může vlastnit více kreditních karet, ale jedna kreditní karta může být vlastněna pouze jednou osobou. Vazba M:N nemá žádné omezení, příkladem by mohla být situace, že student na vysoké škole si může zapsat několik různých předmětů, ale jeden předmět může být zároveň zapsán více studenty. V relačním modelu databáze se dále definuje skalární datová hodnota a doména. Skalární datová hodnota je takzvaně atomická a je to nejmenší sémantická jednotka dat, nedá se již dále rozdělit (vnitřně nestrukturovatelná). Doména je pojmenovaná množina skalárních hodnot téhož typu. Nutno zmínit, že některé učebnice a dokonce manuály databázových programů používají pojem relace pro označení vazby mezi entitami, ne pro relaci, výsledek relačního výpočtu zobrazeného ve formě tabulky. Zřejmě se jedná o chybný překlad původního slova Relationship odpovídajícího relační vazbě. Například poměrně rozšířený produkt Microsoft Access je jedním z nich. V anglickém manuálu je vše v pořádku, ale v češtině je termín relace pro relační vazby místo relačních výpočtů, které jsou pojmenované jako dotazy a tabulky. 2.4 Integritní pravidla a omezení Tyto pojmy definují pravidla pro zajištění správnosti a konzistence ukládaných dat v tabulkách databáze. Zároveň hlídají vzájemná propojení mezi tabulkami. Například, pokud se odstraní z jedné tabulky záznam, tak jsou rovněž smazány integritně spojené záznamy z dalších tabulek, včetně informací nastaveného integritního omezení. Integritní pravidla a omezení pro jednu ze svých základních činností musí mít schopnost definovat naprostou jedinečnost konkrétního záznamu v relaci nebo v celé databázi. Tuto schopnost umožňuje takzvaný primární klíč. Primární klíč je atribut (pole) nebo kombinace 25

26 atributů, které jednoznačně identifikují každý jednotlivý záznam v relaci, tabulce nebo celé databázi a pro svou správnou funkci musí splňovat přísná kriteria. Atribut definován jako primární klíč nesmí obsahovat hodnotu NULL 30. Každá tabulka může mít definován pouze jeden primární klíč. Primární klíč musí splňovat tři základní kriteria: Jedinečnost. Neměnnost. Nenulovou hodnotu. Typickým příkladem správného primárního klíče je rodné číslo (bez lomítka) v seznamu osob nebo identifikační číslo v seznamu firem. Pokud u záznamu neexistuje žádný přirozený primární klíč, nebo je takový primární klíč nevhodný (například textový údaj), používá se jako primární klíč číslo, které záznamu automaticky přidělí systém správy databáze. Takové číslo může být např. pořadové číslo záznamu nebo generované náhodné číslo. Jestliže relace tabulka pracuje s primárním klíčem jiné tabulky a užívá ho, jako svůj jedinečný identifikátor záznamů jedná se o užití takzvaného cizího primárního klíče. Integritní omezení definujeme zpravidla na třech úrovních, entitní, doménové a referenční. Entitní integrita zajišťuje jednoznačné určení každého řádku v rámci tabulky pomocí primárního klíče Doménová integrita zajišťuje, aby každá hodnota atributu byla vybrána z množiny přípustných hodnot. Například systém zabrání vložení neexistujícího data. Referenční integrita sleduje a kontroluje cizí klíče. Atribut nebo skupina atributů tvořící v jiné tabulce (relaci) primární klíč nemůže nabývat nepřípustných hodnot. Integritní pravidla odstraňují zásadní problémy, které mohou vznikat při práci s daty v konkrétních tabulkách. Správně nastavená doménová integrita zabrání vložení špatných dat (např. neexistující datum, neexistující měrná jednotka apod.) do zdrojové tabulky a uživatel je o takovém pokusu informován. 2.5 Normální formy Pro správné navržení tabulek a relačních vazeb, nutné pro efektivní a rychlé zpracování relačních výpočtů se při vývoji databáze aplikují takzvané Normální formy (normalizace) tabulek v databázi. Jsou to normy, které určují jak ukládat a definovat zdrojová data. 30 Hodnota: NULL v relační algebře znamená prázdné pole. Hodnota: číslo 0 není NULL.,

27 Základním smyslem těchto norem je co nejvíce omezit případné redundance položek ve zdrojových tabulkách a co nejvíce zefektivnit, zrychlit a zpřesnit výsledky relačních výpočtů. Normální formy jsou v podstatě souhrnem postupně se zpřísňujících pravidel. Normální formy se dají rozdělit do dvou skupin. První skupinu tvoří první tři normální formy, které byly součástí Coddovy formulace relační teorie. Ve většině případů jsou tyto tři formy dostačující. Druhou skupinu pak tvoří normální forma Boyce/Coddova, čtvrtá a pátá forma. Slouží pro speciální případy, ale někdy je také pokládána za variaci třetí normální formy. Normální formy tabulek se používají pro správné návrhy databázových systémů. Obecně platí, že čím je tabulka ve vyšší normální formě, tím kvalitněji je tabulka navržena. Seznam normálních forem a stručný popis jejich významu: 0NF (nultá normální forma): Tabulka je v nulté normální formě právě tehdy, existuje-li alespoň jedno pole, které obsahuje více než jednu hodnotu. 1NF (první normální forma): Relace (tabulka) je v první normální formě, pokud každý její atribut (sloupec) obsahuje jen atomické hodnoty. Tedy hodnoty z pohledu databáze již dále nedělitelné. Tato podmínka není splněna například u tabulky, kde je jméno a příjmení v jednom sloupci a aplikace pracuje s těmito položkami jako samostatnými. Na níže uvedeném obrázku 5 je konkrétní ukázka úpravy dat pro splnění 1NF. Obrázek 5: Oprava tabulky na základě splnění pravidel první normální formy (1NF). Zdroj: Vlastní. 2NF (druhá normální forma): Relace se nachází v druhé normální formě, pokud splňuje podmínky první normální formy a každý neklíčový atribut je plně závislý na primárním klíči, a to na celém klíči a nejen na nějaké jeho podmnožině. 3NF (třetí normální forma): Pro splnění 3NF musí být relace v 2NF. Dále nesmí být žádný neklíčový atribut tranzitivně závislý na žádném klíči schématu. Tedy například existence atributů PSČ a města uvnitř relace uživatel s primárním klíčem rodné číslo odporuje 3NF, protože město funkčně závisí na PSČ. Pro zavedení 3NF je třeba vyrobit číselníky. 27

28 BCNF (Boyce-Coddova normální forma): Tabulka je v Boyce-Coddově normální formě, jestliže pro každou netriviální závislost X-->Y platí, že X je nadmnožinou nějakého klíče schématu. Což znamená, že každý prvek na kterém je jiný prvek funkčně závislý, musí být součástí klíče. Pro splnění BCNF je nutné splnit 3NF (implicitně). Vyžaduje jednoduché a přímočaré relační vazby. 4NF (čtvrtá normální forma): Tabulka je ve čtvrté normální formě, je-li ve třetí, BCNF a popisuje pouze příčinnou souvislost (jeden fakt). V jedné relaci se nesmí spojovat nezávislé, opakované skupiny. 5NF (pátá normální forma): Tabulka je v páté normální formě, pokud je ve čtvrté a není možné do ní přidat nový sloupec (skupinu sloupců) tak, aby se vlivem skrytých závislostí rozpadla na několik dílčích tabulek. 31 Obecně platí, že čím vyšší normální forma tím je jednodušší rozložení dat v tabulkách a rychlejší výpočty relací. Teorie říká, že tabulky by měly být alespoň ve třetí normální formě. V praxi se ukazuje jako nejlepší rozložit vše do co nejvyšší normy a pak dávat zpět na takovou úroveň, kterou je schopen unést databázový stroj. 31 Zdroj:

29 3 Využití databází v knihovnictví Knihovnictví je obor, který naskýtá velkou výzvu pro aplikaci nových vědeckých postupů, které přináší vývoj informačních technologií. Kromě statistiky a ekonomie je snad jediný, který spravuje, organizuje a třídí takové množství informací. Proto poptávka po využití vysokých výpočetních výkonů, které informační technologie poskytují, je v knihovnictví opodstatněná. Pro ilustraci, knihovna Kongresu Spojených Států Amerických (The Library of Congress) má ve sbírkách položek 32. Rozložení základního roztřídění dokumentuji na obrázku 6. Obrázek 6: Základní zatřídění položek knihovny Kongresu Spojených Států Amerických. Zdroj:

30 3.1 Katalogizace Se vznikem prvních databázových systémů se začaly v knihovnictví objevovat první projekty takzvané elektronické katalogizace knihoven. Elektronická katalogizace se dá obecně a zjednodušeně rozdělit do tří základních částí. Akvizice, vyhledávání a výpůjčka. V následujících podkapitolách jsou popsány základní funkce těchto částí. Další činnosti knihovnických systémů jsou podpůrné. Evidence půjčovatelů, klientů, vydavatelů a dalších činností. Knihovnictví je disciplína, která je svou podstatou multikulturní a překračuje hranice národů, států a kontinentů. Pro úspěšnou mezinárodní katalogizaci v tomto vědeckém oboru bylo potřeba vyřešit mnohá technická úskalí. Věnují se jim další podkapitoly Akvizice Akvizice je získání, založení, zatřídění nové položky, nového díla do informačního systému, databáze. Původně prováděna ručně, lidskou činností, dnes je tato činnost plně automatizována a většina sofistikovaných knihovnických systémů si data o nových položkách importuje z jiných již existujících databází, většinou centrálních národních knihoven. Metoda takových automatizovaných importů je krom rychlosti také odolná vůči chybám na straně lidského faktoru. Dnes je již nepředstavitelné, že by si každá větší knihovna zatřiďovala nové položky ručně, prostřednictvím zaměstnanců či brigádníků Vyhledávání Každá databáze, která má plnit svou každodenní činnost musí obsahovat metody vyhledávání uložených položek, dle kritérií, která byla definována při zatřiďování nových údajů. Tato funkcionalita je v podstatě nejdůležitější pro každý databázový systém a také je na ní upřena mimořádná pozornost při vývoji nových modelů správy dat. Z tohoto důvodu jsou funkce prohledávání záznamů v dnešních systémech velmi propracované a dosahují obdivuhodných rychlostí. Počáteční manuální procházení souborových stromových systémů dle definovaných oborových oblastí a dalších kritérií bylo v relačních systémech nahrazeno profesionálními dotazovacími jazyky, které dle takzvaných datových indexových záznamů prohledávají 30