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

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:

Praha

Ing. Vladimír Beneš

Duben, 2009

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

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.

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.

Obsah ÚVOD ............................................................................................................................................................... 6  1 

DATABÁZOVÉ MODELY .................................................................................................................. 7  1.1  UVEDENÍ DO PROBLEMATIKY A VÝKLAD DŮLEŽITÝCH POJMŮ ................................................................... 8  1.2  HISTORIE POČÍTAČOVÉ SPRÁVY DAT ........................................................................................................ 11  1.2.1  Počátky databází............................................................................................................................ 11  1.2.2  Síťový databázový model ............................................................................................................... 12  1.2.3  Hierarchický databázový model .................................................................................................... 13  1.2.4  Relační databázový model ............................................................................................................. 14  1.2.5  Objektový databázový model ......................................................................................................... 14  1.2.6  Objektově - relační databázový model........................................................................................... 16  1.2.7  Nativní XML databázový model..................................................................................................... 16  1.2.8  Textové a hypertextové databázové modely ................................................................................... 17 

2 

RELAČNÍ MODEL DATABÁZE ...................................................................................................... 21  2.1  2.2  2.3  2.4  2.5 

3 

RELACE.................................................................................................................................................... 23  ENTITA, ATRIBUT, DOMÉNA .................................................................................................................... 24  RELAČNÍ VAZBY ...................................................................................................................................... 25  INTEGRITNÍ PRAVIDLA A OMEZENÍ ........................................................................................................... 25  NORMÁLNÍ FORMY ................................................................................................................................... 26 

VYUŽITÍ DATABÁZÍ V KNIHOVNICTVÍ..................................................................................... 29  3.1  KATALOGIZACE ....................................................................................................................................... 30  3.2  POČÁTKY MEZINÁRODNÍ INTEGRACE ....................................................................................................... 32  3.3  TRADIČNÍ KNIHOVNICKÉ SYSTÉMY .......................................................................................................... 41 

4 

IMPLEMENTACE SYSTÉMU CLAVIUS ....................................................................................... 45  4.1  OBECNÝ POPIS SYSTÉMU .......................................................................................................................... 45  4.1.1  Akvizice .......................................................................................................................................... 45  4.1.2  Katalogizace .................................................................................................................................. 46  4.1.3  Vyhledávání ................................................................................................................................... 46  4.1.4  Výpůjční protokol .......................................................................................................................... 48  4.1.5  Komunikační standardy ................................................................................................................. 48  4.2  IMPLEMENTACE CLAVIUS PRO BIVŠ..................................................................................................... 50 

5 

BUDOUCNOST INFORMATIKY V KNIHOVNICTVÍ ................................................................. 57  5.1  DIGITALIZACE .......................................................................................................................................... 57  5.1.1  Dublin Core ................................................................................................................................... 58  5.1.2  RDF ............................................................................................................................................... 59  5.1.3  OAI-PMH ...................................................................................................................................... 61  5.2  DIGITÁLNÍ KNIHOVNY .............................................................................................................................. 62 

6 

ZÁVĚREČNÉ SHRNUTÍ A VYHODNOCENÍ ................................................................................ 67 

SEZNAM POUŽITÉ LITERATURY ......................................................................................................... 68 

Ú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

1 Databá D ázové modely m y Dataabáze, jejichh vznik a postupný výývoj v rozdíílných modelech správvy dat je neeodlučitelněě spojeen s postupnným vývojeem počítačůů. V roce r 1959 vzniklo seskupení Data Sysstems Langguages (C CODASYL), ustavenéé ministerstvem obrany o USA A pro standaardizaci prog gramových aplikací. krokem byl přechod k magnetický ým diskům,, Výslledným prodduktem byl COBOL1. Dalším pok namíísto dříve používanýcch magnetiických páseek, které umožňovaly u y jen sério ový přístupp k dattům, což užž z principu značně sttěžovalo vy yhledávání dat a možnnost definicce nějakéhoo efekttivnějšího modelu m dataabáze.2 Tabbulka 1: Záásadní milnííky vývoje datových d m modelů na čaasové ose. • založžení konsorccia CODAS SYL • úkol - vytvořit koncepci k daatabázovýchh systémů 19559 • výsleedek - COB BOL (COmm mon Busineess Orientedd Languagee)

19661

• prvníí integrovanný datový skklad s náznaakem datového manageementu a podoobnými vlasttnostmi • tvůrcce Charles Bachman B z General G Eleectric

19665

• Vytvořen Hiearcchický modeel správy daat • Systéém IMS vyttvořen v IBM M pro progrram Apollo

19669

• Databbase Task Group G prezeentuje první síťový moddel správy dat d

• publiikování relaačního modeelu správy dat d z c IBM 19770 • tvůrcce Dr. Edgarr F. Codd, zaměstnanec • počáttky objektovvého modellování správ vy dat • Enco ore-Ob/Serv ver (Brown U University) , EXODUS S (Universityy of Wiscon nsin) 19880 • Dimeenzionální modely m m indexace teextů, metadaata, Dublin Core 19990 • Nativvní XML modelování,

p zmínněných techhnologií a jeejich postuppného vývojje se věnují následujícíí Podrrobnějšímu popisu podkkapitoly. 1 2

COm mmon Businesss Oriented Laanguage. Zdrooj: ALLAN, R. R A. A History ry of the Persoonal Computerr: The Peoplee and the Techhnology. Lond don, Ont.: Allann Pub., 2001. ISBN: 09689910807 : 9780968910801.

7

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.

1.1.1 GUI Pojem GUI3 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

1.1.2 SŘBD Databáze v dnešním pojetí je počítačový systém řízení báze dat (SŘBD4). 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).

1.1.3 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 SQL5. 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 5

SŘBD – Systém řízení správy dat. Z anglického originálu Data Base Management System, DBMS. Z anglického originálu Structure Query Language.

9

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-R6 a ERA7 diagramy entit a vztahů. Tento model byl zaveden a poprvé použit v roce 1976. Brzy se rozšířil a stal se obecně uznávaným standardem8. 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.

AUTOR

KNIHA KNIHA

autor

AUTOR

kniha Zdroj: Vlastní.

6

Z anglického originálu Entity Relationship Diagrams. Z anglického originálu Entity Relationship Atributs. 8 POKORNÝ, J.: Databazová abeceda. Science, Veletiny, 1998, str. 145 – 148. 7

10

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í.

1.2.1 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 Company9. 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: http://www-03.ibm.com/ibm/history/history/decade_1890.html, 20.2.2009. Social Security Act – Původní zákon o sociálním zabezpečení.

10

11

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.

1.2.2 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ých12 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 5-7.

12

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ý.

1.2.3 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, 2005.

13

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.

1.2.4 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 1949. 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.

1.2.5 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

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 013899725X.

15

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ší.

1.2.6 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.

1.2.7 Nativní XML databázový model Nativní XML databáze je úplně novým typem databáze, která byla vyvinuta na Berkeley University16. Existence relativně nového směru vývoje dokumentů XML17, 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 17

Jedním z hlavních tvůrců této databáze je Ronald Bourret. 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

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 NXD18, 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 XPath19, který se již hojně využívá při XSL20 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, DB21 API22, standardní HTTP23. 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.

1.2.8 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. 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ů. 19

17

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 2.

24

Zdroj: ECONOMIA a.s., dostupné na http://ov.ihned.cz/index.php?p=305700, 20.2.2009.

18

Obrázek 2: Ukázka dotazu v programu OVEL.

Zdroj: ECONOMIA a.s., dostupné na http://ov.ihned.cz/index.php?p=305700, 20.2.2009.

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 1.

25

Zdroj: http://quotes.nasdaq.com/asp/SummaryQuote.asp?selected=GOOG&symbol=GOOG, 20.2.2009.

19

Obrázek 3: Výsledek indexace v aplikaci Google desktop search.

Zdroj: Vlastní.

20

2 Relační model databáze Relační model26 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 1970. 28 POKORNÝ, J.: Dotazovaci jazyky. Science, Veletiny, 1994, str. 21 – 46.

21

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 Ellison29 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: http://www.oracle.com/corporate/history.html, 20.2.2009.

22

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

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 8888. 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

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

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 NULL30. 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. , 20.2.2009.

26

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

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: http://www.rydval.cz/phprs/view.php?cisloclanku=2005123127, 20.2.2009.

28

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 138 313 427 položek32. 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: http://www.loc.gov/about/generalinfo.html#2007_at_a_glance, 28.2.2009.

32

http://www.loc.gov/about/generalinfo.html#2007_at_a_glance, 20.2.2009.

29

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.

3.1.1 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ů.

3.1.2 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

velkou rychlostí data uložená v mnoha zdrojích, tím že si sami vytvoří výsledek hledání vlastním výpočtem a výsledek zobrazí ve formě seznamu nalezených položek. Moderní objektové datové modely používají pro vyhledávání takzvaná „metadata“. Metadata jsou pomocné soubory, které obsahují zkrácené informace o uložených datech v systému a vyhledávací stroj prohledává jen tyto metadatové soubory, které následně odkazují na uložené informace. Takže položky nemusí být zatříděné do kategorií, dle kterých se omezují výsledky vyhledávání. Ukázka vyhledávácího formuláře a základního dělení položek knihovnické databáze SOULS z University of Oxford je na obrázku 7. Obrázek 7: Základní dělení a ukázka klíčových slov databáze SOULS.

Zdroj: http://www.ouls.ox.ac.uk/sers/support_ouls/ouls_database_search_help, 20.2.2009.

3.1.3 Výpůjčka Poslední klíčová funkce každého knihovnického systému. Půjčování položek je základní smysl existence každé knihovny bez ohledu na to, jestli je vědecká či nikoli. Každý informační systém pro knihovnu musí tuto funkcionalitu obsahovat. Čím kvalitnější a rychlejší je proces výpůjčky, tím efektivnější je každodenní provoz knihovny. Začínalo to tiskem výpůjčního protokolu s informacemi o podmínkách výpůjčky, v dnešní době si lze představit datové, automatizované řešení tohoto procesu. Transakčním zpracováním pomocí bezdrátových technologií. Potvrzovací e-mail, SMS nebo „klik“ myší, uživatele přihlášeného pod svým identifikátorem a heslem do informačního systému knihovny.

31

3.2 Počátky mezinárodní integrace Časový nesoulad v historickém vývoji knihovnictví a informačních technologií vytvořil samotný základ technických problémů. Jen pro ilustraci pár časových údajů. První knihovny se začaly objevovat ve starověku, Asýrii, Babylóně, Egyptě, Číně. Období jejich zakládání jde na časové ose paralelně s obdobím vývoje písemnictví.33 Zmínky o prvních počítačích se objevují až v druhé polovině 19. století našeho letopočtu. Knihovnictví je dnes vědecká disciplína, která se kromě ochrany kulturního dědictví, zabývá volným šířením myšlenek a idejí. Proto není myslitelné, aby se toto šíření zastavilo na hranicích států či kontinentů. Pro mezinárodní spolupráci a integraci knihoven muselo a stále musí být vyřešeno mnoho problémů, které zapříčinily právě odlišnosti jazykové, technické, vývojové a mnoho dalších. Zdaleka není vše dokončeno a mnoho problémů stále čeká na své řešení. Začalo to snahami sjednocovat a standardizovat metody katalogizace. První teoretické práce na téma katalogizace se objevují již v 16. století. Byl popsán jmenný a systematický katalog a metodika tvorby záznamů. Od tohoto období se začínají objevovat teoretické spisy na téma katalogizace34.

3.2.1 Písemnictví a jazyky Aplikace informačních technologií v oboru knihovnictví naráží na významnou komplikaci, která je dána úplnou podstatou a historickým vývojem písemnictví a jazyků. Základem písemnictví jsou symboly ručně napsané na pergamenové a později papírové listy. Základem informačních technologií je matematika a práce s čísly, tedy s něčím logicky absolutně odlišným než písemnictví. Budování integrovaných databází pro knihovny, které pracují s textovými záznamy musí tento problém nějak uspokojivě vyřešit. Když si představíme, že ještě v druhé polovině dvacátého století byl v počítačích problém se zobrazováním češtiny a na našem území se používaly tři navzájem nekompatibilní metodiky pro zobrazování grafických miniatur, jako jsou naše háčky a čárky, jeví se tento problém jako neřešitelný. Pro ilustraci problému písem je na obrázku 8 ukázka klasické čínštiny a arabštiny.

33 34

Zdroj: GEORGES J. Písmo, paměť lidstva, přel. H.Tomková. Zdroj: KNOLL, A. Předpoklady možného technického řešení virtuálního zpřístupnění kulturního dědictví.

32

Obrázek 8: Ukáázka tradičn ní čínštiny a arabštiny.

Zdroj čínština: č http:///www.profesiionalni-preklaady.cz/img/znaaky-cinstina.bbmp, 25.2.2009. Z Zdroj arabštinna: http://www w.cestomaniakk.cz/cestopisy//fotky_detail.pphp?id=5470& &poradi=1, 25 5.2.2009.

Z obbrázku je naa první pohhled zřejméé, že relačn ní model daatabáze se s takovým problémem m nemoohl vypořáddat bez překkladu textu do d jazyka daatabázového prostředí. Modderní objektoové a ještě novější inddexové meto odiky na báázích digitallizovaných dokumentůů jsou schopné řeešit i tento problém. Metadatové M é indexačníí soubory ssi může kažždý systém m m prostředíí a ty pak pomocí číselných inddexů najdou u správnouu vytvoořit ve svéém národním položžku, konkréétní záznam m. Význnamnou událostí v dalším vývoji v kataalogizace bylo vydáání dvou národníchh katallogizačních instrukcí, které na dllouhou dobu u ovlivnily katalogizaační praxi. Na N sklonkuu 19. století, v rocce 1899, bylla vydána pruská kata alogizační in nstrukce prro jmenný katalog. k Uplaatňovala se především p v vědeckýcch knihovnáách. ve V rooce 1908 byyla vydána anglo-ameri a ická instruk kce pro jmennnou kataloggizaci. Obě instrukce se poměrněě rychle roozšířily i na n území dalších d státůů a na dlo ouhou dobuu ovlivvnily kataloggizační praxxi v knihovnnictví.35 Opraavdové mezinárodní sjeednocovaní a spoluprácce v knihovvnictví začallo v roce 19 927. Ve skotském s hllavním měsstě Edinburrgh byla zaaložena Mezzinárodní fe federace pro o spojováníí knihooven a insstitucí (IFL LA). Hlavnním cílem organizace je tvořit jednotné, univerzálníí standdardy a metodiky pro mezinárodní m í výměnu in nformací v knihovnictv k ví.36 Něktteré milníkyy a základní výsledky činnosti tétto organizacce jsou přibblíženy v náásledujícíchh podkkapitolách.

3.2.22 IFLA Meziinárodní feederace kniihovnickýchh spolků je j nepoliticcká organizzace, kteráá ovlivňujee a pom máhá usměrrňovat rozvoj knihovniictví na celéém světě.

35

Zdrroj: MAXWEL LL, Margaret F. Příručka k AACR2, reviize 1988 : výkklad a příkladyy k Anglo-am merickým kataalogizačním pravidlům. p 36 Thee Internationall Federation of o Library Asssociations and Institutions, zdroj: z http://w www.ifla.org/, 15.2.2009.

33

V současné době má přes 1800 členů, knihovnických spolků, knihoven a institucí z více než 150 zemí celého světa. Od roku 1971 je registrována v Nizozemsku. Vedení IFLA sídlí v Haagu, v Královské knihovně, která je také nizozemskou národní knihovnou. Má pět takzvaných klíčových programů37. − Rozvoj knihovnictví ve třetím světě (ALP).38 − Výbor pro autorská práva a legislativní záležitosti (CLM).39 − Výbor pro svobodný přístup k informacím a pro svobodu projevu (FAIFE).40 − Aliance pro knihovnické standardy (ICABS).41 − Kontrola a mezinárodní koordinace užívání (UNIMARC).42 Bývalé Československo, zastoupené panem Zdeňkem Václavem Tobolkou, bylo jednou ze sedmi zakladatelských zemí IFLA. V roce 1926 byl v Praze zorganizován mezinárodní kongres knihovníků. Pražská rezoluce se stala podkladem pro další kroky vedoucí k ustavení mezinárodní knihovnické organizace.43 Dnešní IFLA rozvíjí svou činnost ve 46 sekcích soustředěných do 8 divizí. − Všeobecné vědecké knihovny (General Research Lib-raries). − Odborné knihovny (Special Libraries). − Knihovny pro širokou veřejnost (Libraries Serving the General Public). − Bibliografická kontrola (Bibliographic Control). − Fondy a služby (Collection and Services). − Řízení a technologie (Management and Technology). − Vzdělání a výzkum (Education and Research). − Regionální aktivity (Regional Activities). Výsledky činností se prezentují na mezinárodních výročních konferencích, kde se zároveň definují nové cíle a problémy k řešení44. 37

CORE ACTIVITIES, zdroj: http://www.ifla.org/act-serv.htm, 15.2.2009. Advanced of Librarianship in the Third World, zdroj: http://www.ifla.org/VI/1/alp.htm, 20.2.2009. 39 Committee on Copyright and other Legal Matters zdroj: http://www.ifla.org/III/clm/copyr.htm, 15.2.2009. 40 Committee on Free Access to Information and Freedom of Expression zdroj: http://www.ifla.org/faife/index.htm, 15.2.2009. 41 IFLA-CDNL Alliance for Bibliographic Standards zdroj: http://www.ifla.org/VI/7/icabs.htm, 20.2.2009. 42 UNIMARC zdroj: http://www.ifla.org/VI/8/up.htm, 20.2.2009. 43 Zdroj: BURGETOVÁ, Jarmila. IFLA a české knihovnictví. Národní knihovna. 2002, roč. 13, č. 4, s. 288. 38

34

3.2.3 Mezinárodní norma ISO 2709 Systémový analytik Henriette Avram Davidson z Kongresové knihovny Spojených států vytvořil v roce 1960 formát pro výměnu knihovnických informací. Tento formát se později stal prvním ANSI standardem Z39.2, který byl jednou z prvních norem pro mezinárodní elektronickou výměnu dat v knihovnictví.45 Poslední vydání této normy bylo v roce 1994 (ISSN: 1041-5653). Nakonec byla norma upravena a standardizována do ISO 2709 pro uspořádání bibliografických údajů na magnetické pásce (původně Format for Bibliographic Interchange on Magnetic Tape), nyní ISO 2709:1996 Information and documentation - Format for Information Exchange).46 Norma specifikuje potřebné prvky obecného výměnného formátu, který je určen pro přenos strojem čitelných záznamů, jež popisují dokumenty jakéhokoliv typu. Jde o záznamy, které jsou vhodné pro budování knihovnických bází dat a rovněž bází souvisejících, jako jsou např. soubory normalizovaných jmenných nebo předmětových hesel – tzv. autorit.

3.2.4 Anglo-americká katalogizační pravidla Paralelně, mimo aktivity IFLA byly v roce vydány 1967 takzvaná anglo-americká katalogizační pravidla, která navazují na ISO 2709 a upřesňují univerzální metodiku popisků v knihovnictví pro mezinárodní výměnu informací.47 Původní vydavatelé těchto pravidel jsou Americké sdružení knihovníků48, Kanadské sdružení knihovníků49 a Zmocněný institut knihovníků a informačních profesionálů50. Pravidla byla několikrát revidována a upravována. Poslední platná aktuální revize z roku 1988 a má přesný název AACR2R, Anglo-American Cataloguing Rules, 2nd. ed. 1988 Revision. Nicméně v běžném jazyce se obecně nazývá jako norma AACR2.51 Po nějaké době byl vytvořen takzvaný řídící a poradní výbor, který je odpovědný za přezkoumávání nových potřeb po revizích a úprav pravidel. Má také na starosti konkrétní

44

Zdroj: http://www.ifla.org/IV/index.htm, 15.2.2009. Zdroj: http://www.sfgate.com/cgibin/article.cgi?f=/c/a/2006/05/04/BAG5HIKG5B1.DTL&hw=marc&sn=001&sc=1000, 20.2.2009. 46 Zdroj: 2709: 1996 Information and Documentation–Format for Information Exchange, 1996, ISO. 47 Zdroj: MAXWELL, Margaret F. Příručka k AACR2, revize 1988 : výklad a příklady k Anglo-americkým katalogizačním pravidlům. 48 American Library Association. 49 Canadian Library Association. 50 Chartered Institute of Library and Information Professionals. 51 MAXWELL, M. F. Příručka k AACR2, revize 1988 : výklad a příklady k Anglo-americkým katalogizačním pravidlům. 45

35

přípravu textu každé takové revize a poradenství. Tvoří ji šest členů a ti jsou jmenováni šesti organizacemi.52 Například The American Library Association, The British Library. Tato norma je uznávána vzhledem k velkému počtu dokumentů vydaných v angličtině. Navíc, v angličtině se odehrává největší procento vývoje a tvorby informačních technologií. Národní knihovna České republiky stanovila v roce 1996 AACR2 jako normu pro záznamy do souborného katalogu budovaného pro Českou Republiku.53

3.2.5 Mezinárodní standard pro knihovnický popis Mezinárodní standard pro knihovnický popis byl vydán v roce 1971 z iniciativy a společné činnosti orgánů IFLA. Základním cílem bylo vytvořit unifikovaný a jednotný mezinárodní standard komunikace mezi knihovníky.54 V technické rovině se především jedná o sjednocení struktury záznamu a pořadí popisných údajů. S nastupující elektronickou automatizací katalogizace bylo třeba také vyřešit jednotnou metodiku ukládání záznamů pro počítačové zpracování. Výsledky této činnosti lze shrnout do těchto konkrétních norem. − ISBD(G)55 - Všeobecný mezinárodní standardní bibliografický popis. − ISBD(M)56 - Mezinárodní standardní bibliografický popis pro monografie. − ISBD(S)57 - Mezinárodní standardní bibliografický popis pro seriálové dokumenty. − ISBD(A)58 - Mezinárodní standardní bibliografický popis pro staré tisky a prvotisky. − ISBD(CM)59 - Mezinárodní standardní popis pro kartografické dokumenty. − ISBD(NBM)60 - Mezinárodní standardní bibliografický popis pro neknižní dokumenty. − ISBD(ER)61 - Mezinárodní standardní bibliografický popis pro elektronické zdroje. − ISBD(PM)62 - Mezinárodní standardní bibliografický popis pro tištěné hudebniny. Doporučení

pro

popis

částí

dokumentu

na

základě

mezinárodního

standardního

bibliografického popisu (ISBD).63 52

Zdroj: http://www.aacr2.org/governance.html, 15.2.2009. Zdroj: http://www.nkp.cz/pages/page.php3?page=fond_zaznpo1.htm, 20.2.2009. 54 INTERNATIONAL STANDARD BIBLIOGRAPHIC DESCRIPTION (ISBD), zdroj: http://www.ifla.org/VII/s13/pubs/cat-isbd.htm, 15.2.2009. 55 General International Standard Bibliographic Description. 56 International standard bibliographic description for monographic publications. 57 International Standard Bibliographic Description for Serials. 58 International Standard Bibliographic Description for Older Monographic Publications (Antiquarian). 59 International Standard Bibliographic Description for Cartographic Materials. 60 International Standard Bibliographic Description for Non-Book Materials. 61 International Standard Bibliographic Description for Electronic Resources. 62 International Standard Bibliographic Description for Printed Music. 63 ISBD(M) : mezinárodní standardní bibliografický popis pro monografie. - 1. vyd. - Praha : Národní knihovna ČR 53

36

Vše je j přeloženno do českéhho jazyka a aplikován no v našem národním kknihovnictv ví. Aplikacee do čeeského prosstředí probíhhala v těchtoo etapách. −

1993--1998 českéé překlady ISBD I

−

1994 český překlad AACR2 2R

−

1996 stanovení národních n sttandardů IS SBD(G) a A AACR264

Ukázzka převoduu formátu z původní české normy y ČSN 0101195 (1964) do norem ISBD I je naa obrázzcích 9 a 100. Obrázek 9: 9 Záznam dle d ČSN 0100195 (1964) a Pravidell jmenného katalogu (1969).

Z Zdroj: http://w www.ics.muni..cz/hanan/KIC C05/KIC05_A AACR2.pdf, 155.2.2009.

Obrázekk 10: Stejnýý záznam přřevedený doo norem ISB BD.

Z Zdroj: http://w www.ics.muni..cz/hanan/KIC C05/KIC05_A AACR2.pdf, 155.2.2009.

3.2.66 Mezináárodní výýměnný foormát UN NIMARC UNIM MARC65 je obecný, mezinároddní rámec formátu zaapisování ddat dle no orem ISBD D a AA ACR2, ale taak aby byly čitelné pro počítačovéé programy. 64

Knnihovní řád Náárodní knihovvny ČR. - Prahha : Národní knihovna k ČR, 1999.

37

Vychází z původního MARC, což je zkratka pro „Strojem čitelná data“. Vznikl z pilotního projektu MARC1 vedeného v letech 1965–66 Knihovnou Kongresu Spojených států. Hlavním cílem projektu bylo zjistit možnost výroby formátu dat pro katalogizaci, který by byl čitelný pro počítače. Podobný projekt probíhal v Národní knihovně Spojeného Království. Nakonec vznikla společná práce na projektu MARCII. Cíl již byl poněkud ambicióznější, vytvořit univerzální mezinárodní komunikační formát pro světové knihovnictví. Výsledným produktem této aktivity byl mezinárodně přijatý standard UNIMARC, nicméně přes veškerou snahu o mezinárodní kompatibilitu byly vytvořeny různé národní varianty tohoto rámce.66 Například, USMARC pro Spojené státy, CAN/MARC pro Kanadu, AUSMARC pro Austrálii a mnoho dalších národních upravených verzí. Což v podstatě znamená, že problém mezinárodního formátu komunikace mezi knihovnickými systémy nebyl uspokojivě vyřešen. Obrázek 11: Ukázka formátu UNIMARC se zápisem konkrétní položky.

Zdroj: http://knihovny.cvut.cz/akp2003/sbornik/13_bartl.pdf, 15.2.2009.

Nicméně pro opravdovou integraci informačních technologií bylo nutné mít opravdu jednotný, kompatibilní a univerzální formát pro výměnu dat. 65 66

Universal Machine Readable Cataloguing. Zdroj: UNIMARC manuál : bibliografický formát. Překlad Národní knihovna České republiky.

38

Dá se říct, že zatím konečná fáze je spojení USMARC a CAN/MARC ke kterému se následně připojila Britská národní knihovna a byl vytvořen jednotný formát, takzvaně pro dvacáté první století, pojmenovaný MARC2167. Tento formát je kompromisem pro řešením mezinárodní komunikace při akceptování národních odlišností. Navíc a to je velmi podstatné, obsahuje komunikační platformy pro používání znakových sad v počítačových systémech MARC868 dle normy ISO 2022 a UNICODE69 dle znakové sady UTF8, takže formát podporuje mimo jiné arabštinu, azbuku, řečtinu, hebrejštinu a konečně tradiční východoasijské abecedy jako je korejština, čínština a další.70 Nevýhodou je, že MARC21 šel cestou zjednodušení a omezení počtu povinných položek, takže systémy, které konvertují z původního UNIMARC mají jisté těžkosti a ne všechno se přenáší úplně korektně. Česká národní knihovna v současnosti přešla na MARC21, ale zároveň paralelně podporuje i původní UNIMARC.71

3.2.7 Síťový komunikační protokol Z39.50 Nástup a neobyčejné rozšíření síťových technologií a internetu si vynutil hledání rychlé cesty komunikace katalogizačních systémů prostřednictvím IP72 protokolu. Již v roce 1970 se organizace Library of Congress, Online Computer Library Center (OCLC) a Research Libraries Information Network začaly hledat cestu k vytvoření standardizovaných prostředků pro vyhledávání informací ve sdílených databázích, které obsahují katalogizovaná data používaná v knihovnictví. Původní projekt se nazýval Linked systems project73. Po letech vývoje byl zahájen program Z39.50 Interoperability Testbed74, jehož cílem bylo zjistit možnosti implementací Z39.50 na internetové technologie. Většina zúčastněných v projektu se zabývala tvorbou a vývojem automatizovaných knihovnických systémů a navíc mnoho z nich byli poskytovatelé universitních knihovnických databází.

67

Zdroj: http://www.loc.gov/marc/bibliographic/, 15.2.2009. Zdroj: http://www.loc.gov/marc/specifications/speccharmarc8.html, 15.2.2009. 69 Zdroj: http://unicode.org/, 20.2.2009. 70 Zdroj: BALÍKOVÁ, M, KUBALOVÁ, H. Katalogizace ve formátu MARC 21 : stručná instrukce a příklady pro knihy a některé typy pokračujících zdrojů. 71 Zdroj: Knihovní řád Národní knihovny ČR. - Praha : Národní knihovna ČR. 72 IP (Internet Protocol) je datový protokol na síťové vrstvě používaný pro přenos dat přes paketové sítě. Tvoří základní protokol dnešního Internetu. 73 Zdroj: http://www.oclc.org/research/projects/rdf_interop/default.htm , 15.2.2009. 74 Zdroj: http://www.oclc.org/research/projects/rdf_interop/default.htm , 15.2.2009. 68

39

Projekt byl úspěšný a výsledný produkt byl schválen v roce 1995. Nese oficiální označení Z39.50 - 1995 nebo verze 3. V březnu 1997 byla tato verze protokolu uznána jako standard ISO 23950.75 Tento protokol mají implementovány snad všechny knihovnické katalogizační systémy. Jakákoli univerzitní knihovna ho nemůže vynechat už jen z prestižních důvodů. Protokol je na aplikační vrstvě a zpřístupňuje katalogizaci položek z databáze mimo jiné všem na internetu a při tom nezáleží, na jaké bázi dat pracuje ten, který knihovnický systém. Pracuje na komunikační architektuře klient–server. Názorná ukázka vyhledané položky pomocí protokolu Z39.50 přes webové rozhraní je na obrázku 12. Obrázek 12: Výsledek hledání pomocí protokolu Z39.50 v internetovém prohlížeči.

Zdroj:http://www.loc.gov/cgibin/zgate?ACTION=INIT&FORM_HOST_PORT=/prod/www/data/z3950/locils2. html,z3950.loc.gov,7090, 15.2.2009.

V hlavičce HTML stránky s výsledkem hledání je navíc informace o konkrétním knihovnickém systému zdroje zobrazené položky. Protokol rozlišuje dva druhy záznamů, které se mohou vyskytnout v odpovědi serveru. Záznamy databázové a diagnostické. 75

Zdroj: http://www.iso.org/iso/catalogue_detail?csnumber=27446, 15.2.2009.

40

Databázové záznamy musí vyhovovat registrovaným formátům. Z39.50 – verze 1995 podporují formáty Unimarc, Intermarc, CCF, USmarc, UKmarc, Normarc, Librismarc, Danmarc, Finmarc, MAB, Canmarc, SBN, Picamarc, Ausmarc a Ibermarc.76 Přenosová syntaxe záznamu podporuje strukturu záznamu pro výměnu dat dle standardu ISO 2709. Tento komunikační protokol byl další mezník pro mezinárodní spolupráci v oblasti knihovnické katalogizace.

3.3 Tradiční knihovnické systémy Označení tradiční je trochu nadsázkou pro označení informačních systémů postavených na relačních databázích. Dnešní situace postupně ukazuje, že katalogizace v tomto databázovém modelu má omezení, daná samotnou datovou strukturou a je pravděpodobné že bude postupně nahrazována jinými, vývojově dokonalejšími metodami. Nicméně, jak je již zmíněno v předchozí kapitole, relační model se tak rozšířil, že nové metody správy dat s ním ještě nadlouho musí počítat. V dalších podkapitolách je představeno pár systémů a výrobců, kteří ve světě knihovnictví něco dokázali a stále mají co říci. Vzhledem k tomu, že systémů pro elektronické vedení knihoven je opravdu mnoho a vzhledem k zaměření této práce na univerzitní knihovnictví budou přiblíženy produkty zejména s tímto zaměřením.

3.3.1 Dynix Dynix je jeden z nejstarších počítačových katalogizačních systémů pro knihovnictví. Společnost byla založena v roce 1979 v Utahu a po několika málo letech byla implementována první verze knihovnického systému. Dávno před masovým rozšířením internetových rozhraní již nabízel svou verzi vzdáleného síťového připojení ke katalogizaci. Dnešní aktuální produkty pro knihovnictví jsou Symphony a Unicorn. Zdrojová databáze je Oracle a operační systémy na straně klientů mohou být Unix, Linux a Microsoft Windows.77 Názorná ukázka architektury systému je na obrázku 13.

76 77

Zdroj: http://www.loc.gov/z3950/agency/Z39-50-2003.pdf, 20.2.2009. Zdroj: http://www.sirsidynix.com/Company/technology_cite.php, 15.2.2009.

41

Obrázek 13: Ukázka architektury systému Symphony.

Zdroj: http://www.sirsidynix.com/Solutions/Products/integratedsystems.php, 20.2.2009.

3.3.2 ALEPH ALEPH78 je velmi významný, rozšířený a výkonný knihovnický systém. Původně vyvinutý programátory, analytiky a knihovníky Hebrejské univerzity v Jeruzalémě. Dnešní výrobce a zároveň implementátor je izraelská společnost Ex Libris Group79. Je to přední světový výrobce pokročilých informačních systémů pro knihovny a informační centra. Nadnárodní společnost Ex Libris má pobočky po celém světě. Systém ALEPH byl instalován ve více než 1500 knihovnách v mnoha zemích. ALEPH je modulární systém. Obsahuje tyto základní moduly, Katalog, OPAC, Výpůjční protokol, Akvizice, Seriály, Konsorcia a přídavné moduly DAM - Aleph Digital Asset Module a ARC-Aleph Reporting Center. Moduly pracují nezávisle na sobě, zájemce se může rozhodnout, které potřebuje a nemusí platit za nevyužívané části systému. Dnešní verze ALEPH 500 je uživatelsky otevřený systém. Sadou konfiguračních tabulek je umožněno ovládat a nastavovat v prostředí systému téměř cokoliv. Lze si nastavit, podle čeho

78 79

Automated Library Expandable Program Zdroj: http://www.exlibris.co.il/category/Aleph, 15.2.2009. Zdroj: http://www.exlibrisgroup.com/, 15.2.2009.

42

a jakým způsobem se má vyhledávat, definují se přístupové soubory, rejstříky, indexy, slova. Uživatelské rozhraní je přeloženo do více než dvaceti jazyků. Systém řízení správy dat je Oracle. Univerzální konektivitu s ostatními systémy zajišťuje XML rozhraní. ALEPH 500 může být instalován v operačních systémech UNIX, AIX, Red Hat Enterprise Linux, Solaris a Tru64.80 Grafická ukázka vícevrstvé architektury je na obrázku 14. Obrázek 14: Grafické znázornění architektury systému ALEPH.

Zdroj: http://aleph.cuni.cz/ALEPH-13.html, 15. 2. 2009.

Systém ALEPH u nás užívá Národní knihovna České republiky. Ústav výpočetní techniky, Univerzity Karlovy v Praze (ÚVT UK) je od 19. 7. 2002 dokonce výlučným distributorem systému, pro Českou Republiku a Slovensko81. Některé z nových produktů tohoto výrobce jsou:

80 81

−

MetaLib, informační portál pro knihovny.

−

DigiTool, řešení pro budování digitálních knihoven.

−

Verde, nejnovější systém pro správu elektronických zdrojů.

−

Rosetta, výkonný systém pro správu digitalizovaného materiálu.

Zdroj: http://aleph.cuni.cz/ALEPH-13.html, 15.2.2009. Zdroj: http://aleph.cuni.cz/ALEPH-2.html, 15.2.2009.

43

3.3.3 Voyager Opět tradiční a velmi rozšířený systém. Používá ho přes 1300 knihoven na světě, včetně Knihovny kongresu Spojených států. Původní americký výrobce Endeavor Information System Inc. implementoval první verzi systému již v roce 1994. V roce 2006 firmu akvizičně fúzoval izraelský, výše zmíněný producent Ex Libris Group a systém VOYAGER přidal do svého portfolia produktů ihned vedle neméně oblíbeného systému ALEPH.82 Systém je opět modulární a obsahuje všechny moduly potřebné pro jakoukoli knihovnu, bez ohledu na velikost či zaměření. Systém je vystavěn na databázi Oracle. Operační systém Solaris 883, aplikační rozhraní klient pracuje pod operačním systémem Microsoft Windows. Obsahuje všechna potřebná komunikační rozhraní k přístupu do katalogu přes internetové prohlížeče, komunikační protokol Z39.50, jazykové standardy UNIMAC.

3.3.4 CLAVIUS Knihovnický systém CLAVIUS je nástupcem původního produktu LAVIUS, který je na trhu od roku 1993. Výrobcem a implementátorem je česká firma LANius s.r.o. Původní vývoj a první instalace byla realizována v Městské knihovně Tábor a první funkční modul byl výpůjční protokol. Dnešní verze CLAVIUS je od roku 2001 obohacena o SQL klienta, takže uživatel může mít data ve své výkonné relační databázi. Zájemce může volit mezi moduly pro databáze Oracle verze 9i, Microsoft SQL server 2000/2005 a bezplatnou MySQL 5.x. Poslední zmíněná databáze je bezplatná varianta pro operační systém serveru LINUX.84 Dalším podrobnostem o systému a popisem konkrétní implementace systému CLAVIUS se věnuje celý následující oddíl.

82

Zdroj: http://investing.businessweek.com/research/stocks/private/snapshot.asp?privcapId=696247, 15.2.2009 Verze UNIX pro počítače firmy Sun Microsystems, Inc. 84 Zdroj: http://www.clavius.cz/frcla.htm?info.htm&informace, 20.2.2009. 83

44

4 Implementace systému CLAVIUS CLAVIUS je modulární systém, každý modul pracuje soběstačně a nezávisle na sobě. Uživatel si objedná a implementuje pouze moduly, které potřebuje. Popis systému včetně komunikačních standardů je v následujících podkapitolách.

4.1 Obecný popis systému Systém má architekturu server-klient, na straně klienta je podporovaný operační systém Microsoft Windows od verze 2000. Na straně serveru může být Microsoft server 2003 nebo LINUX. Je nutné zmínit, že varianta se serverem Microsoft je na pořizovacích nákladech výrazně dražší a na spolehlivosti ani kvalitě nijak nepřidá. Zájemci, kteří nemají vlastní databázi, menší univerzitní nebo městské knihovny se mohou spolehnout na vnitřní integrovanou relační databázi Microsoft Visual FoxPro 9.0. Pro knihovny s více než sto padesáti tisíci svazky výrobce doporučuje přejít na variantu SQL připojení k výkonné databázi Oracle nebo Microsoft SQL. V následujících podkapitolách budou popsány základní moduly a standardy.

4.1.1 Akvizice Modul akvizice je volitelný, ale jeden ze základních částí systému. V režimu akvizice jsou definováni jednotliví odběratelé, včetně jejich rozpočtu, a dodavatelé. Požadované objednávky a další dokumenty jsou vkládány do hlavní databáze a jsou volně přístupné pomocí OPAC85. Pro objednávky je možné vybrat pouze určité tituly podle vlastních zadaných kriterií. Následně je systém sám tiskne nebo zasílá elektronickou poštou. Modul zároveň sleduje lhůty plnění dodávek, automaticky vytváří urgence. Realizované dodávky jsou sledovány také z pohledu čerpání rozpočtů a evidence nákladů. K dispozici je celá historie objednaného titulu včetně čísel dokladů a finančních částek. Součástí režimu je hlídání rozpočtů odběratelů a statistika. Při následné katalogizaci jsou automaticky použity informace z objednávek.

85

Online public access katalog, technologie, která zpřístupní data v databázi pomocí internetových protokolů, takže je lze prohlížet v internetových prohlížečích.

45

4.1.2 Katalogizace Katalogizace je základní část celého integrovaného systému. Standardně jsou k dispozici režimy pro katalogizaci monografií, AV médií, hudebnin, periodik, analytického popisu článků periodik a další Mezi jednotlivými záznamy lze vytvářet vazby. Pro jednotlivé dokumenty jsou připraveny vstupní formuláře, které jsou plně modifikovatelné myší metodou uchop a vlož. Jednotliví pracovníci katalogizace mohou mít své vlastní upravené vstupní formuláře. Vlastní katalogizace je v souladu s mezinárodními pravidly UNIMARC a katalogizační normou AACR2. Kdykoli během katalogizace lze zobrazit bibliografický zápis dle pravidel ISBD, ve formě katalogizačního lístku. Každé pole obsahuje odbornou nápovědu včetně příkladů. Pro usnadnění vkládání údajů je systém vybaven technologií slovníků a tvůrců kódů. Nová verze obsahuje definice souborů takzvaného multimediálního typu, obrázek, zvuk, video. Může mít i formu internetového odkazu na webovou stránku. Při ukládání nové položky systém automaticky kontroluje vyplnění povinných polí tak, jak jsou definována v konfigurační databázi. Dále systém ukládá svazkové údaje, které lze pro větší množství exemplářů snadno kopírovat. Každá položka může být označena čárovým kódem pro automatizovaný výpůjční protokol a ostatní manipulace s dokumentem. Klasickou variantou tištěného výstupu je přírůstkový seznam, popř. katalogizační lístek. Ve všech režimech lze definovat výstupní sestavy dle zadání uživatele. Jednotlivé položky lze vyřadit pomocí režimu úbytky. Práci s modulem akvizice a katalogizace zastřešuje režim nastavení a definice uživatelů. Každému uživateli lze přiřadit nastavení práv, šablon, druhů dokumentů a další. Systém podporuje katalogizaci z více klientských stanic v síti současně.

4.1.3 Vyhledávání Další naprosto klíčový modul systému. Vyhledávání je základním účelem a smyslem existence databází. Modul obsahuje kombinované vyhledávání podle všech ukládaných údajů. Základní formulář pro zadání dotazu může pro zjednodušení obsahovat pouze základní údaje. Vyhledávat lze také pomocí síťových protokolů prostřednictvím webového rozhraní. Pro takové vyhledávání je nutné mít aktivní OPAC modul a vyhledávací formulář se zobrazuje ve

46

webovém prohlížeči. V případě, že server není připojený k internetu, musí být na straně klienta nainstalovaný a správně nastavený serverový program, například APACHE86. Ukázka GUI vyhledávání v aplikaci je na obrázku 15 a prostředí OPAC na obrázku 16. Obrázek 15: Základní vyhledávácí formulář uvnitř aplikace.

Zdroj: Aplikace CLAVIUS.

Obrázek 16: GUI vyhledávání pomocí OPAC ve webovém prohlížeči.

Zdroj: http://knihovna.bivs.cz/, 15.2.2009.

86

Softwarový webový server s otevřeným kódem pro Linux, Windows a další OS. V současné době dodává prohlížečům na celém světě absolutní většinu internetových stránek. Zdroj: http://apache.org/, 20.2.2009.

47

4.1.4 Výpůjční protokol Standardní modul pro knihovnu nepostradatelný. Řeší evidenci čtenářů, výpůjček, poplatků včetně upomínek. Samozřejmostí je plné využití technologie čárového kódu. Součástí modulu je správa databáze uživatelů s možností zadání osobního finančního kreditu, pouze ve verzi SQL připojení k databázi. Rozsáhlé možnosti nastavení konfigurace výpočtů částek za registrace a další poplatky čtenářů. Dále lze využít kategorizace čtenářů, dokumentů a závislostí jejich kombinací pro výpočet prolongací a upomínek. Vlastní režim výpůjčního protokolu provádí evidenci absenčních i prezenčních výpůjček, prodloužení, rezervace na položku. Tisk upomínek a oznámenek rezervací s možností automatického odesílání elektronickou poštou. Součástí modulu je i komplexní statistický pohled na evidenci výpůjček, který mimo jiné zahrnuje statistický výkaz, deník a žebříček nejžádanějších položek. Tiskové výstupy ve formě sestav lze kromě tisku exportovat například do textového editoru, případně posílat elektronickou poštou.

4.1.5 Komunikační standardy Systém ukládá data přímo ve formátu UNIMARC, podporuje uložení „tagů“ s možností definice vlastních polí a podpolí nad rámec UNIMARC. Systém podporuje používání anglo-amerických katalogizačních pravidel AACR2, včetně zobrazení bibliografických výstupů podle norem ISBD. Autoritní záznamy včetně věcných hesel jsou ukládány v mezinárodním výměnném formátu UNIMARC/Autority. Možnost připojení národních autorit z katalogu Národní knihovny České Republiky. Do systému může být připojen libovolný externí tezaurus, např. EUROVOC, který je převeden do formátu UNIMARC/Autority a program Clavius je připraven s ním pracovat. Export a import položek ve formátu UNIMARC splňuje minimální záznam pro souborný katalog ČR. Systém obsahuje síťové protokoly TCP/IP, IPX/SPX, NETBEUI. Internetové protokoly IP, HTTP, HTML, Z39.50 server verzi 2 a integrovaný klient verzi 3. Exportní formáty souborů dle ISO 2709, HTML, XML.

48

Implementovaný síťový protokol Z39.50 umožňuje automatickou výměnu informací mezi jinými knihovnickými systémy. Varianta „klient“ je pro vyhledávání informací ve vzdálených Z39.50 serverech, tuzemských i zahraničních knihoven. Klient je integrovaný do modulu katalogizace. Obsahuje možnost automatizovaného přebírání bibliografických a autoritních záznamů katalogizace z těchto knihoven. Varianta „server“ zajišťuje vystavení fondu vlastní knihovny pomocí celosvětově používaného komunikačního protokolu. Knihovnické systémy jiných knihoven mající klienta protokolu Z39.50 mohou stahovat katalogizační údaje pro své účely. Server je provozován výhradně v prostředí Win32 serverů, Windows 2000/2003/200887. Ukázka nastavení protokolu je na obrázku 17. Obrázek 17: Nastavení Z39.50 v aplikaci CLAVIUS.

Zdroj: Aplikace CLAVIUS. 87

Zdroj: http://www.clavius.cz/frcla.htm?l, 15.2.2009.

49

4.2 Implementace CLAVIUS pro BIVŠ Bankovní institut vysoká škola a.s. je v současnosti univerzita s knihovnou do dvaceti tisíc svazků. Knihovna nakupuje, katalogizuje, prodává a půjčuje knihy a skripta zejména svým studentům. Momentálně se půjčování a prodej knih realizuje pouze osobními návštěvami klientů, kteří jsou obsluhováni zaměstnanci knihovny. Jedná se o klasickou metodu přepážkové obsluhy, která prodeje a výpůjčky ručně zaznamenává do informačního systému. Do budoucna se plánuje rozšíření činností zejména v oblasti automatizace výpůjček, prodejů včetně získávání analytických dat pro objednávání nedostatkových položek. Implementace modulu ověření identity konkrétního studenta z čipové karty. Dále se počítá s integrací modulů výpůjčky a prodeje do centrálního školního informačního systému https://is.bivs.cz/auth/. Rozšíření implementace webové brány protokolu Z39.50 o možnost přímé objednávky nebo rezervace konkrétního nalezeného titulu ihned v reálném čase. Rozšíření systému knihovny o přímou komunikaci mezi vedením knihovny a akademickou obcí za účelem systematického sběru požadavků na nová díla, zejména ze strany přednášejících. Ti budou mít své uživatelské rozhraní, kde mohou vkládat své požadavky na nové knihy přímo do modulu systému knihovny.

4.2.1 Zadání a požadované parametry implementace Knihovnický systém musí mít architekturu server-klient. Integrovaná relační databáze Microsoft Visual FoxPro 9.0 doporučená výrobcem pro knihovnu s počtem položek do dvaceti tisíc je momentálně dostačující. Aktuální počet katalogizovaných položek nepřesahuje dva tisíce. Katalog knihovny musí být na přístupný on-line na internetu, musí obsahovat webový modul pro prezentaci dat pomocí internetových prohlížečů a přístupný na školním intranetu. Podmínkou je implementovaný komunikační protokol Z39.50. Šablony katalogizace musí mít formát UNIMARC, MARK21. Formát dat musí splňovat normu AACR2 verze 2, 1990. Požadované je využití technologie čárových kódů ve všech modulech. Automatické zasílání oznámení pomocí elektronické pošty přímo ze systému.

50

Automatická replikace několika oddělených databází přes síťové protokoly. Požadovaná je spolupráce s aplikacemi kancelářského balíku programů Microsoft Office. Moduly základní implementace jsou: −

Katalogizace knih, map a hudebnin.

−

Vyhledávání a rešerše pro knihovníky.

−

Výpůjční protokol.

−

www katalog pro dokumenty.

−

ISHARE – sdílená katalogizace.

−

CKPrint – tisk čárového kódu.

Velikost licence do 20 000 záznamů.

4.2.2 Hardware a operační systémy Počítačové vybavení: − 2 ks LENOVO Intel Pentium DualCore 2 GHz, HDD 500 GB, 2GB RAM. Studovna – čítárna: − 6 ks LENOVO Intel Pentium DualCore 2 GHz, HDD 250 GB, 2GB RAM Počítačové učebny: − 70 ks LENOVO Intel Pentium DualCore 2 GHz, HDD 250 GB, 2GB RAM Serverová místnost: − Webový server IBM x3350, 4193-K1G, P Xeon D 2,66G, 2GB, 2x160GB SATA RAID1 − Souborový server IBM x3650, 7979-KPG, 2x P Xeon D 2,00G, 8GB, 4x750GB SATA RAID5, W2K3 STD R2 EN 64bit − W2K3 STD R2 EN 32bit 2ks IBM Service Pac® k IBM System x3250M2 Express Operační systém serveru je Microsoft server 2003. Webový server je Internet Information Services (IIS)88, integrovaná součást operačního systému serveru. Síť LAN 100/1000 Mbps. Wi-Fi standard 802.11g, vstup na internet je omezen na 4 Mbps. Požadavky výrobce na hardware a programové vybavení jsou násobně překročeny.

88

Zdroj: http://www.iis.net/, 15.2.2009, nový webový server z dílny Microsoft corp.

51

4.2.3 Automatická akvizice Modul integrovaný do statistik objednávek, výpůjček a stále nedostatkových položek, který automaticky generuje sestavu, report pro management knihovny s informacemi o které tituly je největší zájem a navíc jich není dostatečné množství. Ten pak rozhodne, jestli se nakoupí. Modul sám vytváří dle předem definovaných kriterií objednávky potřebných titulů a zasílá je dodavatelům elektronickou poštou nebo je zasílá jako objednávkovou datovou transakci přímo do informačního systému dodavatele. Podmínkou této datové integrace je kvalitní technické zázemí na obou stranách, dobrá spolupráce při řešení problémů a kvalitní smluvní ujednání s dodavatelem. Další funkcionalita modulu je on-line vkládání požadavků na nové položky v knihovně ze strany přednášejících. Systém automaticky jednou týdně generuje datový výstup ve formě seznamu položek k odsouhlasení, která se automaticky zobrazí nebo přijde elektronickou poštou osobě, která má pravomoc schvalovat a objednávat nové tituly do knihovny. Další vývojový stupeň modulu je automatické schválení a objednání nových položek dle předem nastavených parametrů. Ukázka části procesu automatizované objednávky v grafické podobě je na obrázku 18. Obrázek 18: Grafické vyjádření části modulu automatizace akvizice. Požadavek na novou položku (generovaný systémem)

Ověření požadavku

Ne

Odeslání požadavku ke schválení

Ano

Odeslání objednávky dodavateli Zdroj: Vlastní.

52

4.2.4 Integrace čipové karty Implementace nového modulu, který načítá údaje z čipu průkazu studenta, upravená data vloží do pomocného modulu, který ověří správnost údajů a provede schválení nebo zamítnutí požadované transakce. Ukázka načtení dat čipové čtečky je na obrázku 19. Obrázek 19: Rozhraní čipové čtečky OMNIKEY CardMan 21x.

Zdroj: http://software.intel.com/file/14272, 15.2.2009.

Modul pracuje s externím databázovým modulem, který eviduje registrované zájemce včetně různých práv a omezení. Každý registrovaný uživatel si může pomocí čipové karty kreditovat finanční prostředky ve prospěch svého čipového účtu a pomocí tohoto kreditu může realizovat výpůjčky nebo nákupy v knihovně bezhotovostně. Po dohodě se studentem může vedení školy na tento účet automaticky kreditovat prospěchovou slevu na školné, takže student získá kredit automaticky. Správa tohoto čipového účtu je implementována do „osobní administrativy“ v aktuálním školním systému SIS. V tomto rozhraní po zadání identifikačních a ověřovacích údajů může

53

student kontrolovat aktuální stav svého čipového účtu. Ukázka integrace účtu do školního systému je na obrázku 20. Obrázek 20: Ukázka integrace čipového účtu do školního systému SIS.

Zdroj: Vlastní.

V budoucnosti je možné tento modul integrovat do dalších služeb poskytované univerzitou, například bezhotovostní platby v jídelně, za kopírku a podobně.

4.2.5 Elektronická objednávka Nová síťová funkcionalita integrovaná do katalogu knihovny, on-line připojená k modulům výpůjčka a katalog. Student, který je přihlášený pod svým čipovým účtem si pomocí webového rozhraní vyhledá a po úspěšném vyhledání přímo objedná vybranou položku. Systém automaticky prověří aktuální informace o dostupnosti a tuto informaci obratem sdělí přihlášenému uživateli. Zájemce si může zvolit metodu komunikace, elektronickou poštu nebo krátkou textovou zprávu na mobilní telefon. Telefonní číslo musí mít uživatel uložené v databázi ve svém profilu založeného čipového účtu. V případě, že je položka nedostupná z důvodu půjčení, systém automaticky odešle informaci o budoucí dostupnosti. Funkce dále poskytuje průběžný monitoring stavu aktuální dostupnosti a průběžné informace si student může objednat ve formě pravidelného zasílání informací o změně stavu a v případě vrácení se požadovaný titul okamžitě rezervuje pro zájemce, který si rezervaci vytvořil. Modul eviduje objednávky a rezervace titulů, které jsou nevrácené v termínu. Sám automaticky generuje a zasílá upomínky studentům, kteří nevrátili vypůjčený titul včas. Celá komunikace může probíhat kromě elektronické pošty také textovými zprávami přes GSM bránu na celulární mobilní telefony. Ukázka integrace modulu ve webovém rozhraní elektronického katalogu je na obrázku 21.

54

Obrázek 21: Ukázka integrace funkcionality „elektronická objednávka“.

Zdroj: Vlastní.

4.2.6 Shrnutí Správce knihovny CLAVIUS splňuje všechna funkční očekávání i přesto, že implementace je na databázi Microsoft Visual FoxPro 9.0. Neomezená délka vstupních polí všech údajů. Ukládání všech druhů dokumentů do jedné společné báze dat. Celková délka záznamu stejně jako počet záznamů v databázi nejsou systémem omezeny. Aplikace podporuje standard MDI (Multi document interface). Intuitivní forma ovládání dle zvyklostí Windows a Microsoft Office. Spolupráce s aplikacemi kancelářského balíku programů Microsoft Office.

55

Desítky předdefinovaných šablon vstupních a výstupních formulářů s možnostmi úprav. Tvorba vlastních vstupních a výstupních formulářů metodou uchop a vlož. Široké možnosti vyhledávání všech druhů dokumentů a tvorby rešerší. Uživatelské vymezení kategorií dokumentů, které budou vyhledávány. Odezva programu je svěží a díky graficky nenáročnému GUI funkčních a pracovních formulářů pracuje program rychleji, než je u podobných systémů obvyklé. Až každodenní praxe ukáže, jak se na rychlosti projeví extrémní zatížení databáze. Vytknout se dá pouze barevné a grafické provedení některých formulářů systému. Neodpovídají dnešním nárokům uživatelů na vizuální kvalitu programů. Některé použité barvy jsou tak výrazné, že po několikahodinovém používání mohou být až nepříjemné. Závěrem se dá prohlásit, že při hodnocení parametrů cena/kvalita/výkon je knihovnický systém CLAVIUS velmi dobrou volbou pro menší univerzitní knihovnu. Po testovací fázi a uvedení do provozu všech prezentovaných a popsaných modulů lze dosáhnout opravdu výkonného systému, který bude naprosto automaticky provádět mnoho rutinních činností a lidská obsluha se může věnovat jen řešení výjimečných a nečekaných situací. Zejména implementace čtečky čipových karet studentů se výrazně projeví při konkrétních činnostech obsluhy, která místo opisování údajů a vkládání do databáze bude jen kontrolovat a potvrzovat načtená data. Po následném zprovoznění a rozšíření modulu o čerpání plateb z čipových účtů studentů navíc odpadne práce s hotovostí, což ještě zvýší efektivitu a pohodlí práce v knihovně. Modul elektronická objednávka navíc přesune mnoho činností z prostor knihovny k uživatelům u počítače. Zde prezentovanou základní implementaci výrobce prodává za patnáct tisíc korun bez DPH89. Cena je dosažena díky speciálním cenám pro školy, které mají slevu ve výši 25 % z ceny základního programového balíku90. Vývoj, úprava a implementace nových výše popsaných modulů a funkcionalit by neměl překročit částku padesáti tisíc korun.

89 90

Daň z přidané hodnoty v ČR na programové vybavení je v základní sazbě 19 %. Zdroj: http://www.lanius.cz/frcla.htm?skola.htm&skola, 15.2.2009.

56

5 Budoucnost informatiky v knihovnictví Informační technologie, sítě, internet, globalizace, mobilní technologie a další technické novinky dvacátého století a počátky následujícího se pomalu a nezadržitelně integrují do našich každodenních životů. Předchozí část práce se převážně zabývala elektronickou katalogizací, ale novými fenomény dneška jsou digitalizace, indexace a metadata. Knihovnictví opět nemohlo zůstat stranou. První projekty digitalizace knihoven a uměleckých děl začaly již v osmdesátých letech minulého století. Bližší seznámení je v následujících podkapitolách.

5.1 Digitalizace Digitalizace je v podstatě neustálý vývoj a zdokonalování původní technologie OCR (Optical character recognition)91, jedná se o počítačové algoritmy, které převádějí obrázky nebo tištěný text do jedniček a nul v uložitelném formátu na datová média. Do této podoby se dnes převádí úplně vše, co je jen trochu možné. Obrazy, knihy, filmy, hudba, povrh planety země92, dna oceánů93 atd. Hudbě a filmům se říká multimédia, délka záznamů není podstatná, ale zabýváme se velikostí souborů v kilobytech a datový tok v kilobitech za sekundu (kbps). Tyto veličiny dnes určují kvalitu záznamů, naštěstí pouze technologickou a ne uměleckou. Nové technologie správy dat jsou post relační, objektové, hypertextové a hledání v těchto nových databázových modelech je takzvaně indexové a indexy jsou uložené v metadatových souborech. Dnešní metadatová indexace konkrétních digitalizovaných částí knih, vět a dokonce jednotlivých slov je doslova revolucí v současných systémech katalogizovaného vyhledávání. Vznikl nový pojem, hypertextové databáze, které pracují na principu číselného indexování jednotlivých částí vět nebo digitalizovaných objektů, dokonce naskenovaných částí textů. Mezníkem metadatového indexování je vyvinutí a zdokonalení formátu Dublin Core. Pro rychlou a efektivní mezinárodní síťovou komunikaci je průlomem vyvinutí nového komunikačního protokolu OAI-PMH. 91

Původní vynálezce technologie OCR je rakouský vědec Gustav Tauschek. Program Google Earth od společnosti Google inc. Zdroj: http://earth.google.com/intl/cs/tour.html, 20.2.2009. 93 Program Google Earth Ocean od společnosti Google inc. Zdroj: http://earth.google.com/intl/cs/ocean/. 92

57

5.1.1 Dublin Core Dublin Core je výsledek semináře původní nezávislé iniciativy odborníků, kteří se pojmenovali Dublin Core. První seminář se uskutečnil v březnu 1995. Jeho hlavním výsledkem byl základní soubor prvků, které byly po dohodě celé pracovní skupiny vybrány jako vhodný základ pro popis elektronických zdrojů. Úvodní seminář se zaměřil na popis sémantiky určené přímo problematice vyhledávání elektronických dokumentů. V dubnu 1996 se uskutečnil druhý seminář ve Warwicku v Anglii, který řešil problém syntaxe a začal s určováním sémantiky v syntaxi pro webovské aplikace. Na tomto setkání byl položen konceptuální základ architektury metadat, takzvaný Warwick Framework. Tento rámec se stal spolu s Meta Content Framework jádrem pro vytvoření Resource Description Framework (RDF). RDF slibuje poskytovat flexibilní syntaktický základ pro webovská metadata včetně různých k metadatům přidružených modelů, které sahají mimo rámec zavedených popisných metadat. Třetí seminář v září 1996 v Dublinu, kterého se účastnili zejména experti na grafické formáty, rozšířil cílovou řadu zdrojů o grafické formáty. Specialisté se shodli, že ačkoli zdroje grafických dat a textových jsou v mnoha směrech rozdílné, kategorie podle kterých se seskupují a popisují se až tak lišit nemusí. Několik prvků popisu Dublin Core prošlo v tomto období revizí a k původním třinácti byly přidány další dva. V říjnu 1997 se v Helsinkách ve Finsku uskutečnil pátý seminář Dublin Core, který byl sponzorován OCLC94 a Národní knihovnou ve Finsku. Šestý seminář v roce 1998 se uskutečnil v Kongresové knihovně Spojených Států. Hlavním cílem bylo sjednotit vývoj v jednotlivých pracovních skupinách iniciativy Dublin Core. Poskytnout informace o zkušenostech s implementací a strategiemi existujících pilotních

projektů

a

určit

klíčové

momenty

k

prosazení

ineroperability

mezi

implementacemi.95 Na iniciativě je zapojena i Čína, ukázka překladu Dublin Core je na stránkách Shanghai Library a na obrázku 22.

94 95

Ohio College Library Center http://www.oclc.org/us/en/about/history/default.htm , 20.2.2009. Zdroj: http://www.dublincore.org/about/, 15.2.2009.

58

Obrázek 22: Část překladu Dublin Core do čínštiny.

Zdroj: Vlastní úprava http://dc.library.sh.cn/dcmi-terms.htm, 15.2.2009.

Dublin Core je základním mezníkem pro hledání částí děl v digitalizovaném formátu na internetu.96 Oficiální definice všech prvků je vytvořena podle normy ISO/IEC 11179, pro popis datových údajů. Všechny prvky jsou volitelné, neomezeně opakovatelné a jsou definovány jako textové řetězce.97 Pro zápis Dublin Core v jazyce XML pro webové aplikace potřebujeme RDF.

5.1.2 RDF RDF (Resource Description Framework) je v podstatě hypertextový datový model, který se používá pro zápis metadat pomocí normy Dublin Core. Byl vytvořen konsorciem W3C

96

Zdroj: M. Bartošek. Vyhledávání v Internetu a DUBLIN CORE. Zpravodaj ÚVT MU. ISSN 1212-0901, 1999, roč. IX, č. 4, s. 1-4. 97 Zdroj: http://metadata-stds.org/11179/, 20.2.2009.

59

(World Wide Web Consortium) v roce 1999, původně pouze pro XML syntaxe ve formě doporučení. V roce 2004 byl revidován a vydán jako obecný datový formát pro strukturovaný zápis metadat, nejen pro Dublin Core a XML. Podporuje i jiné metadatové standardy.98 Názorná ukázka sémantiky zápisu konkrétní položky Dublin Core v XML/RDF je na obr. 23. Obrázek 23: Zápis konkrétní položky Dublin Core v XML/RDF.

Zdroj: http://en.webarchiv.cz/files/dokumenty/konference/datasem2000.pdf, 20.2.2009.

98

KOOHANG, HARMAN, A. K. Learning Objects and Instructional Design. Published by Informing Science, 2007.

60

5.1.3 OAI-PMH OAI-PMH99 je jednoduchý komunikační protokol pro automatický sběr poskytovaných dat v metadatové normě Dublin Core bez kvalifikace. Je to nejnovější komunikační protokol. Jedná se v podstatě o jazyk, kterým by mohli vzájemně komunikovat všechny knihovnické informační systémy, bez ohledu na to jestli mají data uložená v relačních databázích nebo jiných novějších modelech správy dat. Vývoj začal v roce 1999 a po první verzi se již implementuje verze 2.0, která byla oficiálně vydána v červnu 2002 a je považována za stabilní. Protokol využívá tyto základní vlastnosti: −

Jednoznačné adresné identifikátory URI.100

−

Metadatový standard Dublin Core.

−

Komunikuje prostřednictvím protokolu http.

−

Důsledné využití XML.

Je to protokol pro automatickou komunikaci informačních systémů mezi zdrojem dat poskytovatele a takzvaným sklízečem dat, na druhé straně. Architektura server – klient.101 Standard definuje základní pojmy metadatového nekvalifikovanéh Dublin Core: −

Ressource, zdroj definován daným metadatovým objektem.

−

Repository, server poskytující záznamy ve formátu OAI-PMH.

−

Harvester, klientský program, který získává metadatové záznamy.

−

Item, metadatový objekt uložený v repozitáři.

−

Record, metadatový záznam v konkrétním formátu získaný z metadat.

Ukázka konkrétního metadatového záznamu je na obrázku 24. V současnosti je protokol implementován většinou v digitalizovaných knihovnách, ale jeho univerzálnost a možnosti jednoduché aplikace mu dávají velkou šanci na masové používání ve světovém měřítku.

99

Open Archives Initiative Protocol for Metadata Harvesting, zdroj: http://www.openarchives.org/OAI/openarchivesprotocol.html, 20.2.2009. 100 URI (Uniform Resource Identifier), zdroj: http://www.openarchives.org/OAI/openarchivesprotocol.html. 101 Zdroj: BARTOŠEK, M. Vyhledávání v Internetu a DUBLIN CORE. Zpravodaj ÚVT MU.

61

Obrázek 24: Položka metadatového záznamu pro protokol OAI-PMH.

Zdroj: http://knihovny.cvut.cz/akp2003/sbornik/05_zabicka.pdf, 20. 2. 2009.

5.2 Digitální knihovny V následujících podkapitolách jsou přiblíženy první projekty digitalizace knihoven. První projekt započal již v sedmdesátých letech minulého století a dodnes je funkční. Když se píše o digitalizaci nelze vynechat doslova impozantní projekty, které realizuje mladá a dynamická společnost Google inc. V následujících podkapitolách jsou blíže popsány některé známé projekty digitalizace knihoven.

5.2.1 Projekt Gutenberg Projekt Gutenberg je zřejmě nejstarším pokusem o digitalizaci knihovny. Projekt byl zahájen v roce 1971 na University of Illinois. Student informatiky Michael Hart dostal neomezený přístup k zařízení Xerox Sigma V. a k dispozici volný účet s prakticky neomezeným množstvím strojového času.102 Prvním digitalizovaným textem údajně byla Deklarace nezávislosti Spojených Států. 102

Zdroj: HART, Michael. Gutenberg:The History and Philosophy of Project Gutenberg, dostupný z WWW http://www.gutenberg.org/wiki/Gutenberg:The_History_and_Philosophy_of_Project_Gutenberg_by_Michael _Hart, 25.2.2009.

62

K projektu se postupně přidávaly další subjekty a v polovině devadesátých let se začala používat technologie pro optické rozpoznávání textu (OCR). Většina děl jsou úplné texty knih s právním statusem volného díla, ve smyslu autorského práva USA. Provozovatelé projektu se snaží o maximální otevřenost formátu, aby byla zachována maximální možná přístupnost k dílům v jakémkoli počítači s jakýmkoli operačním systémem. Takže většina děl jsou digitalizována do otevřených textových formátů souborů (TXT, RTF, HTML). V březnu 2006 projekt obsahoval ve své sbírce víc než 18 000 titulů, přičemž průměrně přibývá více než 50 nových titulů měsíčně. Jsou to většinou literární díla takzvané západní kulturní tradice. Mimo literárních forem jako romány, poezie, povídky a drama projekt obsahuje i referenční díla a vydání periodik. Sbírka má také několik netextových děl, jako zvukové soubory a soubory s hudebním zápisem. Většina děl je v anglickém jazyce, ale významné množství je také v němčině, francouzštině, italštině a dalších jazycích.103 Projekt bývá kritizován za nedostatek bibliografických informací ve svých elektronických textech. Nedostatečné údaje o vydání, včetně nezveřejnění původně publikovaných předmluv. Provozovatel to řeší a okruh informací se neustále rozšiřuje. Ukázka webového rozhraní vyhledané položky je v příloze 2.

5.2.2 Manuscriptorium Manuscriptorium je systém digitalizace uměleckých děl na českém území. Provozuje ho berounská obchodní společnost AiP Beroun s.r.o. za finanční podpory Národní knihovny ČR. Manuscriptorium je výsledkem činností, které započaly společně s iniciativou UNESCO „Memory of the World“ v roce 1992. V Manuscriptoriu jsou digitálně uchovávány informace poskytnuté spolupracujícími partnery, přispěvateli z knihoven, archivů a muzeí. Dalším cílem je budování virtuálního badatelského prostředí pro oblast historických fondů.104 Přístup je zajištěn komunikačním protokolem Z39.50 a OAI-MPH od března roku 2007. 103

Zdroj: http://www.gutenberg.org/wiki/Gutenberg:The_History_and_Philosophy_of_Project_Gutenberg_by_Michael _Hart, 20.2.2009. 104 http://www.manuscriptorium.com/Site/CZE/o_projektu.asp, 20.2.2009.

63

Obrázek 25: Náhled na položku v systému Manuscriptorium.

Zdroj: http://www.manuscriptorium.com/Manuscriptorium/rep_normal_160/msDisplay.asp?folderID=M/NKCR__XII_ E_17_______2KOM&aRep=http://www.manuscriptorium.com/Manuscriptorium/rep_normal_160&lang=CZ&e nvLang=cze, 20.2.2009.

5.2.3 Google book search Ambiciózní, obsáhlý a snad i nejvíce kontroverzní projekt digitalizace knihoven na internetu vytvořený společností Google inc. Původní projekt s názvem Google Print, pak přejmenován, byl zahájen v roce 2004 na University of Michigan. Doslova v tichosti se začaly skenovat, indexovat a umísťovat na webové servery díla univerzitní knihovny.

64

Po půl roce byl prezentován webový portál a k projektu se okamžitě připojily další knihovny. Stanford, Harvard, Oxford's Bodleian a The New York Public Library.105 Postupně se připojují další knihovny už nejen ze Spojených států. V roce 2005 Google Inc. poskytl grand ve výši 3 miliony dolarů Kongresové knihovně Spojených států a stal se spoluzakladatelem nového projektu s názvem Světová digitální knihovna (WDL).106 Projekt přímo navazuje na původní aktivitu Kongresové knihovny, započatou již v roce 1990 s názvem Paměť národa107. Cílem bylo digitalizovat a zpřístupnit široké veřejnosti významné památky Spojených Států.108 Jako všechny aktivity této společnosti je i projekt Google Book Search technologickým průlomem na poli indexace a vyhledávání. Metadatové indexové soubory zároveň obsahují indexy i na části textu uvnitř skenovaných dokumentů. Takže vyhledávaný výraz je nalezen i uvnitř díla a ne jen v katalogizovaných polích, jako u dosud používaných katalogizačních metodik. Jen pro názornost, ukázka porovnání hledání textového řetězce „objective database model“: −

Knihovna Kongresu USA: 4 výsledky za cca 1 sekundu.

−

Webová brána protokolu Z39.50: 20 výsledků za cca 1 sekundu.

−

Google Book Search: 3 280 výsledků za 0,07 sekundy.

Digitalizované knihy jsou na webovém portálu zobrazovány ve třech variantách: −

náhled,

−

bližší náhled,

−

úplný náhled.

Je to ústupek autorům, který si vynutili, pod hrozbou hromadných žalob pro porušování autorských práv. Ukázka indexace položek uvnitř textu knihy je na obrázku 26.

105

http://books.google.com/googlebooks/library.html, 20.2.2009. World Digital Library (WDL) zdroj: http://newsbreaks.infotoday.com/nbreader.asp?ArticleID=16060. 107 the American Memory zdroj. http://newsbreaks.infotoday.com/nbreader.asp?ArticleID=16060, 20.2.2009. 108 BARTOŠEK, M. Nástroje Google. 3. Google Book Search. 106

65

Obrázek 26: Indexace digitalizované knihy v Google Book Search.

Zdroj: http://books.google.com/books?id=FLabRYnGrOcC&pg=RA1PR18&dq=apple+computer&as_brr=1#PRA1-PR18,M1, 20.2.2009.

Úplný digitální náhled je u knih, které jsou ve smyslu autorského práva, v režimu volné. Což znamená 75 let po smrti autora nebo se souhlasem vydavatelství a autora. U každé nalezené položky nemohou chybět odkazy na internetové obchody, kde si lze prohlíženou knihu objednat, včetně informací o cenách. Manažeři a obchodníci Google inc. netají, že jsou úspěšnou internetovou obchodní společností se zájmem o výnosy. Navíc u každé nalezené knihy jsou k dispozici grafické ukázky na mapě, kde se dotyčné dílo nachází ve fyzické podobě. Zobrazené jak jinak než v internetové aplikaci Google maps. Ukázka úplného zobrazení položky je v příloze 3.

66

6 Závěrečné shrnutí a vyhodnocení Knihovnictví v roli ochránce a poskytovatele kulturního dědictví široké veřejnosti je opět další lidskou činností, která se bez informačních technologií neobejde, bude-li chtít poskytovat své služby na úrovni hodné dvacátého prvního století a budoucnosti. Dá se s určitostí prohlásit, že od osmdesátých let, počátku vývoje počítačů a prvních databází, knihovníci urazili kus cesty. Dnešní úroveň klasické katalogizace je opravdu na skvělé úrovni. Světové standardy a mezinárodní normy splňují i poměrně levné a dostupné programy. Mezi ně patří i Clavius, jehož implementace je popsána v této práci. Jediné co by se dalo významně zdokonalit je vizuální a grafický výraz aplikace. Některé barevné a stylistické provedení formulářů, včetně dalších ovládacích prvků již neodpovídá dnešním nárokům na design. Co se týká rychlosti operací a užitných vlastností programu, neobjevil jsem významnější problém a vše odpovídá programu postaveném na malé relační databázi. Internet, vývoj síťových protokolů Z39.50 a OAI-MPH řádně rozproudily mezinárodní komunikaci. Katalogizační zápisy, indexy, metadata a další informace doslova lítají takzvaně „po síti“ mezi knihovnami a uživateli na celém světě. Digitalizace je další nový impuls, fenomén, který otevřel nové obzory a dostal umělecká díla do každé domácnosti, která disponuje jakýmkoli počítačem připojeným k internetu. Dá se říci, že dnešní digitalizace knih, časopisů a uměleckých děl je absolutní průlom do stávajícího systému informačních technologií v knihovnictví. Vývoj relačních databází byl začátek dlouhé cesty, která se nyní začíná měnit v poměrně komplikované rozcestí a je velmi těžké odhadovat kam nás tento rychlý a překotný vývoj zavede. Velmi těžké je také rozhodnutí, která cesta vede k nejlepšímu cíli. Digitalizace a indexace od Google inc. se momentálně jeví jako jasný vítěz, ale až zkouška časem prověří, jestli je to správná cesta do vzdálené budoucnosti knihovnictví. Velká otázka závěrem je: „Jak dlouho přežijí magnetické zápisy jedniček a nul“. Knihy nám zůstaly v knihovnách a muzeích po staletí.

67

Seznam použité literatury [1]

ALLAN, R. A. A History of the Personal Computer: The People and the Technology. London, Ont. : Allan Pub., 2001. ISBN: 0968910807 : 9780968910801

[2]

ARLOW, J., NEUSTADT, I. UML a unifikovaný proces vývoje aplikací: Průvodce analýzou a návrhem objektově orientovaného softwaru. Brno: Computer Press, 2003. 387 s. ISBN 80-7226-947-X

[3]

BALÍKOVÁ, M., KUBALOVÁ, H. Katalogizace ve formátu MARC 21 : stručná instrukce a příklady pro knihy a některé typy pokračujících zdrojů. 1. vyd. Praha : Národní knihovna ČR, 2004. 155 s. ; 30 cm. ISBN 80-7050-438-2

[4]

BARRETT, R. Management, labour process and software development : reality bytes, New York : Routledge, 2005. str. 22-25

[5]

BARTOŠEK, M. Vyhledávání v Internetu a DUBLIN CORE. Zpravodaj ÚVT MU. ISSN 1212-0901, 1999, roč. IX, č. 4, s. 1-4.

[6]

BARTOŠEK, M. Nástroje Google. 3. Google Book Search. Zpravodaj ÚVT MU. ISSN 1212-0901, 2009

[7]

BARTOŠEK, M. Nástroje Google. 2. Google Scholar. Zpravodaj ÚVT MU. ISSN 1212-0901, 2008

[8]

BARTOŠEK, M. Vyhledávání v Internetu a DUBLIN CORE. Zpravodaj ÚVT MU. ISSN 1212-0901, 1999, roč. IX, č. 4, s. 1-4.

[9]

BURGETOVÁ, J. IFLA a české knihovnictví. Národní knihovna. 2002, roč. 13, č. 4, s. 288-294.

[10] BURGETOVÁ, J. Zpráva o účasti na 68. výroční konferenci Mezinárodní federace knihovnických spolků a institucí (IFLA) v Glasgow. Praha : SKIP, říjen 2002. [11] CODD, E. F. A Relational Model for Large Shared Data Banks. In CACM, 13, 6, June 1970. [12] HÁJKOVÁ, Z. VOCHOZKOVÁ, H. Pravidla AACR2. Čtenář, 2000, roč. 52, č. 211. [13] HART, M. Gutenberg:The History and Philosophy of Project Gutenberg. Dostupný z WWW: http://www.gutenberg.org/wiki/Gutenberg:The_History_and_Philosophy_of_Project _Gutenberg_by_Michael_Hart [14] CHAMBERLIN at al. IBM Journal of Research and Development, by International Business Machines Corporation, Published 1957, Original from Stanford University [15] DATE C. J.: An Introduction to Database Systems. Sixth edition. Addison-Wesley, 1995, str. 79 – 218. [16] DAVIS, C. G. Entity-relationship approach to software engineering : proceedings of the Third International Conference on Entity-Relationship Approach, Anaheim, California, U.S.A., October 5-7, 1983 ISBN: 0444867775 9780444867773

68

[17] FOX, M. HENRIETTE A. Revolutionized library catalogs. San Francisco chronicle [online]. May 4, 2006 [cit. 2007-03-11]. Dostupný z WWW: [18] GEORGES J. Písmo, paměť lidstva, přel. H.Tomková, Slovart, 1994. ISBN: 807145-115-0 [19] KNOLL, A. Předpoklady možného technického řešení virtuálního zpřístupnění kulturního dědictví. In : Národní knihovna. Knihovnická revue, roč. 13, 2002, č. 2, s. 79-80 [20] KOOHANG, A. HARMAN, K. Learning Objects and Instructional Design. Published by Informing Science, 2007 [21] LOOMIS, M. CHAUNDRI, A. Object Databases in Practice, Prentice Hall 1994, ISBN 013899725X [22] MAXWELL, M. F. Příručka k AACR2, revize 1988 : výklad a příklady k Angloamerickým katalogizačním pravidlům. 1. české vyd. Praha : Národní knihovna České republiky, 1995.ISBN 80-7050-228-2 [23] http://www-03.ibm.com/ibm/history/history/decade_1890.html [24] O'NEILL, Ed. Conference Chairman.Authority Control in the 21st Century : An Invitational Conference, March 31 - April 1, 1996 [online]. Dublin (OH) : OCLC, [1996] [cit. 2003-02-05].Dostupný z WWW: < http://www.oclc.org/oclc/man/authconf/confhome.htm> . [25] PATTERSON, D. A. HENNESSY, L., GOLDBERG, D. Computer Architecture: A Quantitative Approach. Burlington. Morgan Kaufmann, 2003. ISBN 0123704901, 9780123704900 [26] POKORNÝ, J.: Databazová abeceda. Science, Veletiny, 1998, str. 145 – 148. [27] POKORNÝ, J.: Dotazovaci jazyky. Science, Veletiny, 1994, str. 21 – 46. [28] POKORNÝ, M. Vyvíjíme databázový a informační system, 26. 05. 2004. Dostupný z www: < http://www.dbsvet.cz/view.php?cisloclanku=2004052601> [29] PUGH, E. W. Building IBM: Shaping an Industry and Its Technology, Published 1995, MIT Press [30] RYDVAL, S. Normální formy, 07. 08. 2005, Dostupný z www: [31] SILBERSCHATZ, A. and Korth, H. Database System Concepts, published by McGraw-Hill, was released on July 27, 2001. [32] SKLENÁK, V. Data, informace, znalosti a Internet. Praha : C.H. Beck, 2001. ISBN: 80-7179-409-0 [33] SIMON, A. R. Melton J. SQL: Understanding Relational Language Components, str. 16, Published 2002 Morgan Kaufmann, ISBN 1558604561

69

[34] Timeline Firsts. Oracle's History: Innovation, Leadership, Results Dostupný z ://www.oracle.com/corporate/history.html [35] ISBD(M) : mezinárodní standardní bibliografický popis pro monografie. - 1. vyd. Praha : Národní knihovna ČR, 1993. - 62 s. Dotisk 1999 ISBN 80-7050-166-9 [36] Knihovní řád Národní knihovny ČR. - Praha : Národní knihovna ČR, 1999. - 21 s.ISBN 80-7050-345-9 [37] UNIMARC manuál : bibliografický formát. Překlad Národní knihovna České republiky. 1. české vyd. Praha : NK ČR, 1996. ISBN 80-7050-252-5.

70