Univerzita Hradec Králové. Filozofická fakulta. Katedra pomocných věd historických a archivnictví

Transkript

1 Univerzita Hradec Králové Filozofická fakulta Katedra pomocných věd historických a archivnictví Databáze soupisu duší s historicko-demografickými výstupy Diplomová práce Autor: Bc. Jiří Kudr Studijní program: N7105 Historické vědy Studijní obor: 7105T005 Archivnictví Vedoucí práce: Ing. Monika Borkovcová Hradec Králové, 2014

2 Univerzita Hradec Králové Filozofická fakulta Zadání diplomové práce Autor: Bc. Jiří Kudr Studijní program: N7105 Historické vědy Studijní obor: Archivnictví Název závěrečné práce: Databáze soupisu duší s historickodemografickými výstupy Název závěrečné práce AJ: The Database of the Register of Souls with Historical-Demographic Output Cíle, metody, literatura, předpoklady: Stručný obsah: Analýza zpracovávaných dat, návrh ERD modelu, specifikace statistických funkcí, implementace databáze s tvorbou číselníků a pomocných tabulek pro statistické výpočty, historicko-vědní zpracování vstupních dat. Metody zpracování: literární rešerše, analýza databázového konceptu a její implementace. Literatura nebo archivní fondy: Sbírka knih soupisu duší SOkA Hradec Králové, zásady historické demografie, knihy UML, database development. Garantující pracoviště: Katedra pomocných věd historických a archivnictví, Filozofická fakulta Vedoucí práce: Ing. Monika Borkovcová Oponent práce: Mgr. Radek Pokorný Datum zadání práce Datum odevzdání práce:

3 Prohlášení Prohlašuji, že jsem tuto diplomovou práci vypracoval (pod vedením vedoucího diplomové práce) samostatně a uvedl jsem všechny použité prameny a literaturu. V Hradci Králové, Bc. Jiří Kudr

4 Poděkování Na tomto místě bych rád poděkoval vedoucí mé diplomové práce Ing. Monice Borkovcové za trpělivost, čas a cenné rady, které věnovala spolupráci na vytvoření této práce. Za trpělivost a ochotu při sestavování databáze děkuji pracovníkům Státního okresního archivu v Hradci Králové.

5 Anotace Kudr, Jiří. Databáze soupisu duší s historicko-demografickými výstupy. Hradec Králové: Filozofická fakulta, Univerzita Hradec Králové, 2014, 87 stran. Diplomová práce. Tématem diplomové práce je návrh a realizace databázového nástroje pro historicko-demografické zpracování knih soupisu duší uložených ve fondech Státního okresního archivu v Hradci Králové. Na základě rozboru archivního pramene soupisu duší je vytvořen konceptuální model relační databáze a následně vytvořen vlastní databázový nástroj. Klíčová slova: soupis duší, databáze, relační model, historická demografie

6 Annotation Kudr, Jiří. The Database of the Register of Souls with Historical- Demographic Output: Hradec Králové, Faculty of Arts, University of Hradec Králové, 87 pp. Master s thesis. Creating of the database of the register of souls with historicaldemographic output is the main goal of this master s thesis. The thesis describes particular register of souls and analyzes its structure. On the basis of this research the conceputal model of relational database and subsequently the own database is created. Keywords: register of souls, database, relational model, historical demography

7 Obsah Úvod Teoretická část technická Teoretická východiska Informace, data, databáze Systém řízení báze dat Relační model dat Návrh databáze s využitím ERD modelu a transformace Jazyk SQL Software SŘBD Analýza zpracovávaných dat Definice databázového systému Definice parametrů Definice pracovních procesů Teoretická část historicko-demografická Demografie Historická demografie Soupis duší Demografická analýza soupisu duší Praktická část technická Vstupní požadavky Přístup k archiváliím... 41

8 3.1.2 Zpracování dat Rozsah použití Cíle projektu Konceptuální model dat E-R model Lineární konceptuální zápis Relační model dat Transformace E-R modelu Fyzický model relační databáze Definice dat Manipulace s daty Grafické rozhraní Praktická část historicko-demografická Soupis duší Analýza pramene Transformace údajů pramene do databáze Tabulka obec Tabulka dum a vlastnictvi_dum Tabulka domacnost Tabulka osoba Tabulky vira a vira_osoba Demografické výstupy... 78

9 Závěr Seznam použitých zdrojů Seznam použitých obrázků a tabulek Přílohy... 87

10 Úvod Soupisy duší jsou cenným historickým pramenem pro demografické studium vývoje obyvatelstva v 18. a první polovině 19. století. Aby však bylo možné pracovat s informacemi, které tento pramen nabízí, je nezbytné tyto data náležitě demograficky zpracovat, neboli provést excerpci dat. Samotná excerpce dat z pramene je časově velmi náročná činnost, proto je nezbytné úkol dopředu dobře promyslet, neboť zjistit na konci zpracování pramene, že nějaký údaj nebo faktor nebyl za začátku práce zohledněn, může být velmi frustrující. Při řešení otázky, jak excerpci provést, je nutné stanovit dva základní faktory. Prvním z nich je faktor historicko-demografický. Na základě kritické analýzy pramene je nutné jasně popsat, jaký rozsah dat a jakou obsahovou hodnotu může pramen poskytnout. Druhým faktorem, který je nutné definovat, je způsob, jakým budou technicky data zpracována. Snahou této práce je vytvořit a aplikovat relační databázový systém pro historicko-demografické zpracování analogového pramene soupisu duší. Analýzou konkrétního soupisu duší bude rozebrána struktura a obsahová podstata pramene, jejichž poznání je nezbytným aspektem pro vytvoření fundovaného návrhu databáze. Následně bude popsána samotná tvorba databázového systému, který by měl budoucím uživatelům umožnit efektivní zpracování pramene pomocí relačního databázového systému. Samotná práce je rozdělena do čtyř hlavních kapitol. První kapitola se zabývá teorií relačních databází. Druhá kapitola je věnována historicko- 10

11 demografickým otázkám a popisuje problematiku soupisu duší. Třetí část dokumentuje postup tvorby databázového systému. Čtvrtá kapitola pak rozebírá vytvořenou databázi z historicko-demografického hlediska. 11

12 1. Teoretická část technická 1.1 Teoretická východiska Technická část práce se opírá o řadu specifických termínů z oblasti informačních technologií a relačních databází, které je nezbytné úvodem definovat a popsat. Teoretická část práce popisuje stěžejní problematiku, jež se v práci objevuje Informace, data, databáze Informace a data V nejobecnějším slova smyslu se informace chápe jako údaj o reálném prostředí, o jeho stavu a procesech v něm probíhajících. V informační vědě se informací rozumí především sdělení, komunikovatelný poznatek, který má význam pro příjemce, nebo údaj usnadňující volbu mezi alternativními rozhodovacími možnostmi. 1 Informace je tedy obsah určitého sdělení. Pokud informaci přiřadíme určitou strukturu, vytvoříme data. Vytvořením struktury kódováním a zaznamenáním na vhodné médium (ať už se jedná o papír nebo o elektronický záznam) jsou získána data, která mohou přetrvat v čase a znovu být dekódována do informace. 2 1 KATUŠČÁN, Dušan. Terminologický a výkladový slovník: odbor knižničná a informačná veda. 1. vyd. Bratislava: SNP, 1998, s ISBN KOCH, Miloš a Bernard NEUWIRTH. Datové a funkční modelování. 1. vyd. Brno: VUT, 2008, s. 5. ISBN

13 Proces přeměny dat v informaci výstižně demonstruje obrázek níže. Obrázek 1: Proces přeměny dat na informace Fyzický záznam Lidský mozek dekódování informace data kódování informace zdroj: KOCH, Miloš a Bernard NEUWIRTH. Datové a funkční modelování. 1. vyd. Brno: VUT, 2008, s. 5. ISBN Databáze V průběhu historie se ukázalo jako nezbytné zajistit způsob, jakým by bylo možné získaná data uchovat, organizovat a zajistit k nim efektivní přístup. Vývoj vedl přes analogové kartotéky, děrnoštítkové automaty až k počítačům. Od 60. let 20. století tak dochází k vývoji prvních softwarových nástrojů pro databázové zpracování dat pomocí počítače. Dnes je pojem databáze nejčastěji definován jako souhrn všech potřebných (uložených) dat dané organizace. 13

14 Databáze jako taková je nezávislá na aplikaci, pomocí které k ní přistupujeme. Zahrnuje čtyři základní komponenty: 3 1. Datové prvky Datové prvky slouží k zachycení elementárních hodnot (například jméno zaměstnance, název pobočky a podobně). 2. Vztahy mezi prvky dat Vztahy mezi prvky dat zachycují vztahy mezi datovými prvky (například fakt, že daný zaměstnanec pracuje na konkrétní pobočce). 3. Integritní omezení Integritní omezení vyjadřuje podmínky, které mají splňovat data obsažená v databázi. 4. Schéma Schéma je popis dat srozumitelné uživateli a odpovídajícímu softwaru Systém řízení báze dat Jak už bylo zmíněno, báze dat stojí nezávisle na aplikacích, pomocí kterých k nim lze přistupovat. Speciálním programem, který tvoří rozhraní mezi samotnou databází a aplikačními programy, je systém řízení báze dat, častěji jen SŘBD. Každý SŘBD musí poskytovat několik základních služeb: 4 definice databáze 3 POKORNÝ, Jaroslav a Ivan HALAŠKA. Databázové systémy. Praha: ČVUT, 2003, s ISBN tamtéž s

15 efektivní manipulace databáze souběžný přístup ochrana dat zotavení z chyb Systém řízení báze dat spolu s databází tvoří databázový systém. Tato syntaxe je dobře patrná z následujícího obrázku: Obrázek 2: Struktura databázového systému zdroj: osobní stránka Ing. Moniky Borkovcové. Edu.uhk.cz [online]. [cit ]. Dostupné z: Relační model dat Model dat, je způsob, jakým jsou data v databázi organizována. V současné době nejpoužívanějším je modelem relační model dat. 5 5 Existují také další modely dat, například objektový, relačně-objektový, hierarchický, síťový nebo relační. 15

16 Myšlenkovým základem relačního modelu dat je matematická teorie množin. Implementací této teorie vznikla základní struktura relačního modelu, která je reprezentována relacemi. Soubor těchto relací je vyjádřen pomocí tabulek. Aby tabulka splňovala pravidla relačního modelu dat, musí mít následující vlastnosti: 6 každá tabulka má jednoznačné jméno každý sloupec v tabulce má jednoznačné jméno všechny hodnoty daného sloupce jsou stejného datového typu každá tabulka musí mít primární klíč 7 nezáleží na pořadí sloupců nezáleží na pořadí řádků tabulka nemůže mít duplicitní řádky všechny hodnoty jsou atomické Relační databázový systém (RDBMS) musí splňovat také několik definovaných pravidel, aby mohl být považován za skutečně relační. Mezi tyto pravidla patří: pravidla o struktuře dat pravidla o integritě dat pravidla o modifikaci dat pravidla o nezávislosti dat 6 HERNANDEZ, Michael. Návrh databází. Praha: Grada Publishng, 2006, s ISBN Primární klíč v tabulce je pole hodnot, které má jedinečnou hodnotu a lze pomocí něj tabulku jednoznačně určit. Pravidla, která primární klíč musí splňovat, jsou vyjádřena pravidly o integritě dat. 16

17 1.1.4 Návrh databáze s využitím ERD modelu a transformace ERD model Mezi záměrem vytvořit databázi a fyzickou tvorbou databáze stojí velmi podstatný krok konceptuálního modelování databáze. Jedná se vlastně o proces zaznamenání myšlenky jak má databáze vypadat strukturovanou formou. Podstatou je převést objekty z reálného světa (zákazník, produkt, výrobce) do světa relačních databází. V souvislosti s relačními databázemi se v konceptuálním modelování využívá entitně-relačního (E-R) modelu. Ten má přesně popsanou strukturu, které je nezbytné se při tvorbě konceptuálního modelu držet. Při tvorbě modelu rozeznáváme tyto konstrukty: 8 Entita Entita je objekt reálného světa, který je schopen nezávislé existence a je jednoznačně odlišitelný od ostatních objektů, například zákazník Josef Novák, produkt Škoda Octavia. Vztah Vztah je vazba mezi dvěma (nebo více) entitami, například zákazník Josef Novák kupuje produkt Škoda Octavia. Atribut Atribut přiřazuje entitám nebo vztahům hodnotu, která určuje jejich podstatnou vlastnost, například červená Škoda Octavia. 8 POKORNÝ, Jaroslav a Ivan HALAŠKA. Databázové systémy. 1. vydání. Praha: ČVUT, 1999, s ISBN

18 ERD diagram Struktura rozeznaných entit, vztahů a jejich atributů je následně zaznamenávána pomocí ERD diagramu (entity-relation diagram). ERD diagram má přesně definována pravidla tvorby schématu, která je nezbytné dodržet. Součástí těchto pravidel jsou mechanismy, ty dále rozvíjejí a zpřesňují entity, atributy a vztahy mezi nimi. V ERD diagramu dále sledujeme: 9 primární klíč kardinalitu vztahu členství ve vztahu Každý použitý konstrukt nebo parametr má přesně definovanou grafickou značku. Existuje několik variant možností grafického zápisu ERD diagramu. Pro účely této práce byl zvolen takzvaný Chenův model, jehož název je odvozen od jména svého vynálezce, Petera Chena. 10 Transformace ERD modelu Transformace ERD modelu do relačního modelu dat je proces, při kterém je konceptuální model dat transformován do opravdového modelu dat, tedy takového modelu, na jehož základě lze přistoupit k samotné tvorbě databáze. 9 KOCH, Miloš a Bernard NEUWIRTH. Datové a funkční modelování. 1. vyd. Brno: VUT, 2008, s. 50. ISBN Za výběrem tohoto modelu nestojí nic hlubšího než autorova vizuální sympatie jeho grafického provedení. V zásadě se funkčně od ostatních modelů neliší. 18

19 Správný převod dat do relačního modelu je klíčová operace, která má zásadní dopad na správné fungování databáze. Výsledně navržený model dat musí odpovídat pravidlům relačního modelu dat popsaných v předchozích kapitolách. Pro navržený model musí také platit pravidla normalizace. Normalizace je proces, který postupnou dekompozicí původní relace vede k vytvoření množiny relací, u kterých platí: 11 jsou eliminovány nežádoucí redundance dat je zjednodušena kontrola integrity dat nedochází k anomáliím při údržbě (aktualizaci) dat Proces normalizace má několik úrovní. Aby relace splňovala kritéria dané úrovně, musí být její struktura přesně v souladu s pravidly pro danou úroveň. 1. normální forma relace (NF) o Relace je v 1. NF, když jsou všechny její hodnoty atomické. 2. normální forma relace o Relace je v 2. NF, když je v 1. NF a každý neklíčový atribut je plně funkčně závislý na primárním klíči. 3. normální forma relace o Relace je v 3. NF, když je v 2. NF a všechny neklíčové atributy jsou vzájemně nezávislé. 11 POKORNÝ, Jaroslav a Ivan HALAŠKA. Databázové systémy. 1. vydání. Praha: ČVUT, 1999, s ISBN

20 1.1.5 Jazyk SQL S relační databází úzce souvisí jazyk SQL (Structured Query Language). Jedná se o neprocedurální jazyk specifikuje, co získat, ne jak to získat. Jedná se o standardizovaný jazyk, který je v současné době reprezentovaný standardem SQL Tento jazyk je spjatý především s relačními databázemi, ale jeho struktura je implementována také do jiných programovacích jazyků. SQL se v relačních SŘBD vyskytuje současně ve dvou verzích interakční a hostitelské. 13 V interakční verzi se dají příkazy SQL používat samostatně, přičemž v hostitelské verzi se příkazy stávají součástí hostitelského jazyka (jazyků vyšší úrovně 3GL, nebo 4GL). Popsat lze několik základních použití SQL: 14 SQL jako dotazovací jazyk pro relační databáze SQL jako dotazovací jazyk pro multimediální databáze SQL jako složka hostitelského jazyka pro programování databázových aplikací SQL jako jazyk komunikace mezi různými zdroji dat Příkazy jazyka SQL lze rozdělit do dvou základních částí: 1. Jazyk pro definování datové struktury 12 Introduction to SQL. W3school.com [online] [cit ]. Dostupné z: 13 POKORNÝ, Jaroslav. Dotazovací jazyky. Praha: Karolinum, 2007, s ISBN tamtéž s

21 Jazyk pro definování datové struktury, který je označován také jako DDL (data definition language), slouží k vytváření a úpravě struktury databáze. Konkrétně se jedná o tyto příkazy: 15 CREATE TABLE o Tento příkaz slouží k vytvoření tabulky. o Jeho přesná syntaxe vypadá takto: CREATE TABLE [nazev_databaze.]nazev_tabulky (<nazev sloupce> <datovy typ> [DEFAULT <konstantni vyraz>] [NULL NOT NULL] [<omezeni pro sloupce>] [<omezeni pro tabulku>] [,...n]; ALTER TABLE, DROP TABLE o Příkaz ALTER TABLE slouží k úpravě struktury již vytvořené CREATE INDEX tabulky, DROP TABLE pak umožňuje odstranit již vytvořenou tabulku. o Pro často používané záznamy v tabulkách je vhodné CREATE VIEW vytvořit indexování, které zrychluje dotazovací procesy v databázi. Obvyklá definice indexu má tento tvar: CREATE [UNIQUE] INDEX jmeno_indexu ON jmeno_tabulky (jmeno_atr1 [usporadani], jmeno_atr2[usporadani] ) 15 SQL tutorial. W3schools.com [online] [cit ]. Dostupné z: 21

22 o Pohled je virtuální tabulka, která umožňuje z praktických nebo bezpečnostních důvodu nastavit uživateli přístup pouze k některým datům obsaženým v tabulce. Syntaxe toho příkazu vypadá takto: CREATE VIEW jmeno_pohledu AS SELECT nazev_sloupce FROM jmeno_tabulky WHERE podminka 2. Jazyk pro manipulaci s daty Jazyk pro manipulaci s daty, označovaný také jako DML (data manipulation language) slouží k výběru, aktualizaci a odstranění dat v databázi. Pro výběr dat je určen příkaz SELECT. Základním konstruktem tohoto příkazu je blok SELECT FROM WHERE. Složka SELECT obsahuje seznam jmen sloupců vytvářející schéma tabulky. Složka FROM určuje tabulky, pro které je dotaz definován. Složka WHERE určuje podmínku, která definuje, co musí splňovat vyhledávaná data. Při definování podmínky se využívají aritmetické a logické operátory a nástroje pro vyhledání textového řetězce nebo data. Pro specifikaci pořadí hodnot ve výsledku slouží funkce ORDER BY. V rámci bloku SELECT se používají také hnízděné dotazy, neboli poddotazy. Poddotaz je zpravidla umístěn do jiného (vnějšího) dotazu, pro nějž vytváří 22

23 hodnotu, která je v tomto dotazu následně použita. Poddotaz je vždy uzavřený v závorkách. 16 Při tvorbě dotazů lze využít agregační funkce, které SQL nabízí: COUNT o Vrací počet hodnot ve specifikovaném sloupci. SUM o Vrací součet hodnot ve specifikovaném sloupci. AVG o Vrací průměr hodnot ve specifikovaném sloupci. MIN, MAX o Tyto funkce vrací nejmenší, nebo největší hodnotu ve specifikovaném sloupci. Agregační funkce lze aplikovat na celou tabulku nebo její podmnožinu. Při použití konstruktu GROUP BY se tabulka konceptuálně rozdělí na skupiny, pro které je hodnota ve zvoleném sloupci konstantní. Spolu s tímto konstruktem lze využít funkci HAVING sloužící k filtrování skupin, které budou do výsledku zahrnuty. Podstatným nástrojem při výběru dat je relační algebra, která slouží při získávání výsledků z více relací. Operátory relační algebry se aplikují na relace a výsledkem vyhodnocení odpovídajících relací jsou opět relace. Mezi tyto množinové operace patří sjednocení, průnik, rozdíl, kartézský součin, projekce, selekce a spojení relací POKORNÝ, Jaroslav. Dotazovací jazyky. Praha: Karolinum, 2007, s ISBN KOCH, Miloš a Bernard NEUWIRTH. Datové a funkční modelování. 1. vyd. Brno: VUT, 2008, s ISBN

24 Sjednocení relací A a B lze provést, pokud jsou relace z hlediska datového typu kompatibilní. Výsledná relace obsahuje prvky relace A nebo B nebo obou relací. Pro sjednocení relací SQL 92 definuje příkaz UNION. Průnik relací A a B lze provést, pokud jsou relace z hlediska datového typu kompatibilní. Výsledná relace obsahuje prvky, které jsou obsaženy současně v A i B. Této operaci je v SQL92 přidělen příkaz INTERSECT. Rozdíl relací A a B lze provést, pokud jsou relace z hlediska datového typu kompatibilní. Výsledkem je relace se stejným záhlavím jako A i B a tělem, které obsahuje pouze prvky relace A. Této operaci je v SQL92 přidělen příkaz EXCEPT. Kartézský součin, nebo také spojení křížem, vyjadřuje kartézský součin tabulek A a B. V jazyce SQL lze použít funkci CROSS JOIN. Rozlišit lze několik způsobů spojení tabulek. Při přirozeném spojení dvou tabulek je spojovací podmínka realizována automaticky dle přítomnosti referenčních vazeb nebo shodnosti názvů sloupců a datových typů ve spojovaných tabulkách. V SQL je definován příkaz NATURAL JOIN. Pokud je spojení tabulek definováno rovností primárního nebo cizího klíče, použito je vnitřní spojení. V SQL je definován příkaz INNER JOIN. Vnější spojení je přirozeným spojením tabulek, které umožňuje zahrnout do výsledné relace i ty řádky, pro které neexistuje v druhé relaci stejná hodnota ve společném sloupci chybějícím hodnotám druhé relace se přiřadí hodnota NULL. V SQL je pro toto spojení definován příkaz OUTER JOIN. V rámci DML jsou definovány také příkazy pro aktualizaci a odstranění dat: 24

25 INSERT INTO umožňuje vkládání řádku do tabulky. Jeho syntaxe vypadá takto: INSERT INTO nazev_tabulky (sloupec1,sloupec2,sloupec3,...) VALUES (hodnota1,hodnota2,hodnota3,...); DELETE slouží k odstraňování řádků z tabulky. Zápis tohoto příkazu vypadá takto: DELETE FROM nazev_tabulky WHERE sloupec=hodnota; Příkaz UPDATE slouží ke změně údajů v řádku, nebo množině řádků. UPDATE nazev_tabulky SET sloupec1=hodnota1,sloupec2=hodnota2,... WHERE sloupec=hodnota; Software SŘBD Většina dnešních databázových systémů je založena na síťové architektuře klient-server. Tato architektura definuje vztah mezi dvěma programy, přičemž jeden program vystupuje jako klient a druhý jako server. Programy klienta a serveru jsou fyzicky odděleny na dvou různých počítačích. Na personálním počítači uživatele je nainstalován klient, pomocí kterého je databázový systém spravován. Je zde vytvořena struktura databáze a prováděny jsou zde také příkazy pro manipulaci s daty. Na serverovém počítači je pak nainstalován databázový server (program), kde je samotná databáze fyzicky uložena. Komunikace mezi oběma programy probíhá pomocí počítačové sítě: klient zadává dotaz 25

26 dotaz je odeslán na databázový server databázový server vykoná dotaz výsledek dotazu je poslán zpět klientovi, kde je zobrazen Obrázek 3: Architektura klient-server zdroj: Architektura databází. Databáze [online] [cit ]. Dostupné z: Na trhu existuje velké množství softwarů poskytujících systém řízení báze dat. Z hlediska jejich podílu na trhu a uživatelské rozšířenosti jsou níže uvedeny nejpoužívanější produkty. 18 Oracle Database Oracle Database, v aktuální verzi Oracle Database 12c, je databázový produkt společnosti Oracle. Produkt je založen na principu klient-server. Nabízí komplexní řešení od malých databází až po velké korporátní systémy. Nástroj standardně podporuje standard jazyka SQL92 a přidává vlastní nadstavbu jazyka SQL/PL. Nástroj podporuje víceuživatelský přístup 18 Pro porovnání podílu jednotlivých produktů na trhu byla použita komparace údajů z několika webových portálů zabývajících se touto problematikou. Nejlépe vystihuje zjištěnou situaci tento portál: DB Engines ranking. DB-Engines [online] [cit ]. Dostupné z: 26

27 a virtualizaci databáze pomocí cloudových služeb. Produkt je komerční a je distribuován pod licencí OLSA (Oracle Licence and Services Agreement). MySQL Oblíbený multiplatformní databázový systém vyvíjený společností Oracle. Produkt je založen na principu klient-server. Současnou aktuální verzí je MySQL 5.6. Jeho hlavní výhodou je distribuce pod bezplatnou licencí GPL (General Public Licence). Z tohoto důvodu je v kombinaci s dalším svobodným softwarem (webový server Apache, operační systém Linux, programovací jazyk PHP) oblíbenou volbou pro tvorbu dynamických webových stránek. Microsoft SQL Server Microsoft SQL Server, v současné verzi SQL Server 2014, je relační databázový systém vyvíjený společností Microsoft. Produkt založený na principu klient-server nabízí komplexní řešení pro malé i korporátní databáze. Podporuje standard jazyka SQL 92 a přidává vlastní rozšíření jazyka Transact-SQL. Nástroj podporuje víceuživatelský přístup a virtualizaci databáze pomocí cloudových služeb. Program je proprietární a je distribuován v komerční i bezplatné verzi. Bezplatná verze SQL Server Express je však funkčně omezena. 27

28 Microsoft Access Produkt Microsoft Access je relačním databázovým systémem určeným především pro desktopové použití. Není zde využit princip klient-server jako u výše uvedených programů, ale aplikační vrstva i databázový systém jsou alokovány na stejném pevném disku bez využití serveru. Práce s databázovým systémem je prováděna pomocí implementovaného grafického rozhraní. V Accessu jsou předem definovány objekty, pomocí kterých lze program obsluhovat: tabulky o Tabulky jsou objekty, do kterých jsou vkládána data v souladu s principy relačních databází. Tabulky mohou být vytvořeny pomocí jazyka SQL, nebo pomocí implementovaného nástroje pro tvorbu tabulek. dotazy o Tvorba struktury databáze a manipulace s daty může být prováděna přímo pomocí jazyka SQL nebo lze využít nadstavbového nástroje, který vytvoří dotaz místo uživatele pomocí stanovených kritérií a s využitím grafického rozhraní. formuláře o Práci s tabulkami a dotazy lze uživatelsky zjednodušit pomocí formulářů, ve kterých lze tabulky a dotazy seskupovat a vytvořit grafickou nadstavbu. sestavy o Sestavy umožňují uživateli vytvářet výstupy z databáze a přímo je odeslat k tisku. 28

29 Práce s jednotlivými objekty probíhá pomocí ovládacích prvků. Využít lze širokou nabídku hotových řešení, nebo lze vytvořit vlastní ovládací prvky pomocí jazyka VBA (Visual Basic for Applications). Technicky je Access postaven na databázovém stroji Microsoft Access Database Engine (ACE engine). Pohled na strukturu databázového systému nabízí níže uvedený obrázek. 19 Obrázek 4: Struktura databázového systému Access zdroj: Data programming with Microsoft Access. MSDN: Microsoft developer network [online] [cit ]. Dostupné z: 19 Data Programming with Microsoft Access. Microsoft Developer Network [online] [cit ]. Dostupné z: 29

30 Z hlediska rozsahu použití je databázový systém Access koncipován pro menší podniková a kancelářská řešení. Maximální použitelný rozsah podle jednotlivých parametrů dokládá následující tabulka. Tabulka 1: Technické parametry DBMS Access Technické parametry MS Access Parametr Maximum Maximální velikost celého databázového objektu 2 GB Maximální počet objektů v databázi Maximální počet tabulek v databázi 34 Maximální počet spojení k jedné tabulce 16 Maximální počet znaků v jednom poli 255 Maximální velikost jedné tabulky 2 GB Zdroj: Databázový systém Access pochopitelně využívá k práci s daty jazyk SQL. Vychází přitom ze standardu ANSI SQL92. Oproti standardu je však zápis některých prvků pozměněn a výrobce používaný jazyk SQL nazývá jako Microsoft Access SQL. 20 Microsoft Access, v aktuální verzi Microsoft Access 2013, je určen pro použití v operačním systému Microsoft Windows. Není však kompatibilní se všemi verzemi tohoto operačního systému, což znázorňuje níže uvedená tabulka. 20 Comparison of Microsoft Access SQL and ANSI SQL. Microsoft developer network [online] [cit ]. Dostupné z: 30

31 Tabulka 2: Požadavky DBMS Access na operační systém operační systém verze architektura Windows XP SP3 32bit Windows Vista všechny 32/64bit Windows 7 všechny 32/64bit Windows 8 všechny 32/64bit Windows 8.1 všechny 32/64bit Zdroj: Microsoft Office. Microsoft developer network [online] [cit ]. Dostupné z: Data jsou na databázovém systému Access nezávislá. Program podporuje mechanismus ODBC (Open Database Connectivity), což umožňuje export dat do jiných databázových systému. Program také podporuje přímou migraci dat do programu Microsoft SQL Server a rovněž propojení s dalšími aplikacemi balíku Microsoft Office. Produkt Microsoft Access není dodáván koncovému uživateli samostatně, ale je součástí balíku aplikací Microsoft Office. Jedná se o proprietární komerční software, který je nutné zakoupit. Jeho používání je definováno licenčním ujednáním EULA (End-User-Licence-Agreement). 21 Pokud uživatel produkt zakoupený nemá, lze využít nástroj Microsoft Access Runtime, který je možné používat zdarma. Je ovšem určen pouze ke čtení. 21 Microsoft Software License Terms for Office. Office products [online]. [cit ]. Dostupné z: 31

32 1.2 Analýza zpracovávaných dat Počátkem tvorby funkčního databázového systému je analýza zpracovávaných dat. Tento často opomíjený krok předchází samotné tvorbě databáze. Cílem analýzy je správné pochopení záměru zadavatele projektu. Při analýze je nezbytné objasnit základní otázky: Proč má být databáze vytvořena? Co od ní zadavatel očekává? Jedině tak lze dosáhnout funkčního návrhu a implementace databáze Definice databázového systému Návrh databáze nelze dělat od stolu. Správné pochopení situace je založeno na komunikaci se zadavatelem projektu. To zahrnuje přímou účast tvůrce databáze v organizaci, pro kterou má být databáze určena. Musí proběhnout série setkání a konzultací s potencionálními uživateli databáze. Nezbytné je také pochopení všech procesů, které v dané organizaci probíhají. V některých případech může být vhodné i užití dotazníků. Výsledkem těchto poznávacích procesů je sestavení definice navrženého databázového systému. Je to jakási dokumentace databáze shrnující vstupní požadavky a cíle, kterých má být dosaženo. Pomocí těchto údajů lze také závěrem zjistit, zda bylo navržených cílů opravdu dosaženo. Při prvotním sestavení definic systému nelze očekávat, že jejich výsledky budou finální. Teprve jejich opakovanou konzultací s uživateli databáze a obecnou kritikou lze dosáhnout uspokojivých výsledků. 32

33 Definici systému lze pro přehlednost rozdělit do dvou skupin: Definice parametrů 1. Stanovení cílů V tomto bodě jsou stanoveny cíle, kterých má být na konci tvorby databáze dosaženo. Vznikají na základě vstupní analýzy dat, které proběhla komunikací se zadavatelem projektu. 2. Sestavení kritérií návrhu Kritéria návrhu jsou vlastně kompromisy mezi stanovenými cíli projektu a možnostmi, které jsou dané reálnou situací, možnostmi dané organizace a navržené technologie. Na základě těchto kritérií lze hodnotit úspěšnost projektu. Při sestavení návrhu sledujeme následující kritéria: 23 Kritéria prostředí Tato část vyjasňuje otázky spojené s prostředím, ve kterém má být databáze nasazena. Sledována je hardwarová a softwarová situace dané organizace. To v praxi znamená zjistit, zda již nějaký databázový software organizace využívá, jaké je morální staří hardwarových a softwarových komponent využívaných organizací a podobně. Důležitým faktorem, který je také brát na zřetel, je počítačová gramotnost cílových uživatelů. 22 RIORDAN, Rebecca. Vytváříme relační databázové aplikace. Praha: Computer Press, 2000, s ISBN tamtéž s

34 přímo měřitelná kritéria Přímo měřitelná kritéria vyjadřují požadavky, které lze nějakým způsobem exaktně vyjádřit. Jejich hodnota je pak často porovnatelná se způsobem, jakým daná organizace konkrétní agendu zpracovávala dříve. Pro názornost uveďme například fiktivní požadavek: Zpracování faktury pomocí toho nástroje by mělo trvat nejdéle deset minut. Obecné strategie Obecné strategie formulují požadavky, které jsou jen obtížně popsatelné nějakou hodnotou. Můžeme sem zařadit například požadavky na grafický vzhled databáze Definice pracovních procesů Definice pracovních procesů jsou uváděny ve většině literatury jako samostatný blok procesů. Jedním dechem je ale upozorňováno, že tato problematika se proplétá všemi aspekty již od prvních kroků návrhu databáze. Jedná se o pochopení a záznam pracovních procesů dané organizace v oblastech, do kterých databázový systém zasahuje. Lze tedy říci, že zatímco definice parametrů sledují data a úlohy, které má databáze obsahovat, definice pracovních postupů sledují mechanismy a posloupnosti, jakými jsou tato data a úlohy zpracovány. Pokud by totiž nebyly tyto přirozené postupy reflektovány, stala by se databáze nepoužitelnou. 34

35 2. Teoretická část historicko-demografická Tato práce je jakýmsi protnutí dvou odlišných světů informačních technologií a historických věd. Samotná tvorba databáze není cílem, ale spíše prostředkem, jakým dosáhnout cíle. Jejím úkolem je napomoci historikům při jejich práci, konkrétně usnadnit zpracování dat soupisů duší. Z tohoto důvodu je nezbytné vymezit a popsat základní historicko-vědní pojmy, o které se tato práce opírá. 2.1 Demografie Demografie je společenskovědní disciplína zabývající se studiem počtu, složení, rozmístění a pohybu obyvatelstva a jejich zákonitostmi, přičemž ve středu pozornosti demografie leží otázky reprodukce lidské populace. 24 Volně přeloženo lze říci, že demografie se zabývá studiem lidské populace a faktory, které její stav a strukturu ovlivňují. Mezi faktory, které jsou při studiu populací brány vzaty na zřetel, jsou faktory přírodní, politické, sociální a ekonomické. Mezi základní jevy, které demografie ve vztahu k populaci studuje, jsou: úmrtnost, porodnost, nemocnost, potratovost, sňatečnost a rozvodovost. Z hlediska oblastí zájmu a metod výzkumu lze demografii rozdělit do několika podkategorií: demografická analýza paleodemografie 24 MAUR, Eduard. Základy historické demografie. Praha: SPN, 1978, s

36 regionální demografie historická demografie ekonomická a sociální demografie geografie obyvatelstva 2.2 Historická demografie Historická demografie se zabývá retrospektivním zkoumáním populačního vývoje, tedy historickými populacemi. 25 Metodologicky vychází z obecné demografie, ovšem vlastní metody zkoumání musí přizpůsobit dochovaným pramenům, ze kterých může vycházet. Prameny, ze kterých může historická demografie čerpat, nevznikaly z demografických důvodů, ale v době vzniku plnily jiný účel. Většinou vznikaly pro účely daňové evidence obyvatel, nebo z důvodu církevních potřeb. Zde se historická demografie velmi úzce propojuje s klasickými historickými vědami. Při demografickém zpracování pramenů je nezbytné detailně znát politické, kulturní, náboženské a ekonomicko-sociální poměry doby, neboť pramen je nezbytné podrobit historicko-vědní kritické analýze. Jedině tak mohou mít datové výstupy, které jsou zkoumáním zjišťovány, určitou vypovídající hodnotu o populaci a době, ve které pramen vznikl. Jeden příklad za všechny - nelze očekávat, že v období násilné rekatolizace v pobělohorském období v soupisech obyvatel podle víry budou obyvatelé pravdivě uvádět jako svoje vyznání jinou než katolickou víru. Je evidentní, že pokud by v demografické studii tento aspekt nebyl zohledněn, pravdivost výstupních dat by byla velmi zkreslená. 25 MAUR, Eduard. Základy historické demografie. Praha: SPN, 1978, s. 6 36

37 Prameny, ze kterých může historická demografie čerpat, se v průběhu historie mění. Nemá smysl na tomto místě popisovat pramenné zdroje pro všechny historické epochy. Omezme se tedy na širší období od konce 16. století do poloviny 19. století, kam soupisy duší z hlediska doby vzniku spadají. 26 Toto období bývá také nazýváno jako období protodemografické. V tomto období začíná postupně docházet k systematické evidenci obyvatel a majetku, i když důvody vzniku stále ještě nejsou demografické. Původce těchto pramenů lze rozdělit do tří základních skupin státní administrativu, patrimonijní správu a církevní administrativu. Státní administrativu vedly k evidenci obyvatel dva hlavní důvody fiskální a vojenské. Jinými slovy, snahou bylo zaevidovat daňové poplatníky a získat údaje o mužích schopných odvodu. V rámci církevní administrativy vznikala evidence obyvatel ze dvou základních potřeb. Hlavním úkolem bylo evidovat obyvatele - duše, které spadaly do jednotlivých farností, pro potřeby církve. Druhým důvodem byla delegace funkcí státní správy na bedra církve. Jinak řečeno, státní správa ukládala tvořit evidenci obyvatel církevním institucím. Je třeba podotknout, že z evidence obyvatel pořízené církví měla užitek jak státní správa, tak i církev jako taková. Mezi prameny, které vzniky působením církevních institucí, jsou nejpodstatnější církevní matriky a seznamy farníků MAUR, Eduard. Základy historické demografie. Praha: SPN, 1978, s tamtéž s

38 2.3 Soupis duší Vedeny jsou dva základní typy seznamů farníků soupisy duší a zpovědní seznamy. Zpovědní seznamy měly být vyhotovovány každoročně o Velikonocích u osob, které absolvovaly povinnou zpověď. 28 Soupis duší, užíván je také výraz status animarum, je soupis, do kterého měli být zahrnuti všichni obyvatelé příslušného církevního obvodu, tedy i děti předzpovědního věku. Soupisy byly sestavovány po výměně 1-2 generací obyvatel, rozlišovány po jednotlivých obcích a strukturovány dle čísel popisných jednotlivých domů. U zde žijících osob měly být zaznamenávány údaje o jménu, příjmení, věku, vyznání, povolání a vztahu k živiteli Demografická analýza soupisu duší Na základě zpracování dat, které status animarum nabízí, lze získat některé socio-demografické poznatky o daném obyvatelstvu. Pochopitelně základním údajem je znalost celkového počtu obyvatel v obci. Na základě této znalosti pak lze populaci dále analyzovat. Podstatným údajem je věková struktura obyvatel. Možností, jak vyjádřit věkovou strukturu obyvatelstva, existuje celá řada. Jako základní pohled na 28 MAUR, Eduard. Dějiny obyvatel českých zemí. Praha: Mladá fronta, 1996, s ISBN PAVLÍK, Jiří a Radek POKORNÝ. Status animarum. Důležitý archivní pramen k vývoji obyvatelstva pevnostního Hradce Králové v první polovině 19. století. Královéhradecko: historický sborník pro poučenou veřejnost. 2011, č. 8. DOI:

39 věkovou strukturu lze uvést kategorizaci populace do věkových skupin, které lze takto diverzifikovat: 30 obyvatelstvo v předprodukčním věku 0 14 let obyvatelstvo v reprodukčním věku let obyvatelstvo v postproduktivním věku 50 let a více Dalším pohledem je věková pyramida, která zobrazuje věkovou strukturu obyvatelstva odděleně pro muže a ženy. Stanoveny jsou nerovnoměrné věkové skupiny obyvatel 0 5 let, 6 11 let, let, let, let a let. Ze soupisů lze také sledovat strukturu domácností a rodin. Zprvu je nezbytné definovat pojem rodina. Z pohledu historické demografie je základním kamenem takzvaná nukleární rodina. Je to svazek muže a ženy s jejich svobodnými dětmi, kteří žijí v jedné domácnosti. Ti dohromady tvoří jádro. Pokud v jedné domácnosti žije více příbuzných, hovoří se o rozšířené rodinné domácnosti, kde je možné pomyslnou rodinu rozdělit do více jader. Strukturu domácností lze výstižně klasifikovat na základě Laslettovy typologie. 31 Domácnosti lze klasifikovat do dvou základních typů rodinné domácnosti a nerodinné domácnosti. 1) Rodinné domácnosti a. manželský pár b. manželský pár s dětmi c. matka s dětmi d. otec s dětmi 30 MAUR, Eduard. Základy historické demografie. Praha: SPN, 1978, s tamtéž s

40 e. rozšířená rodinná domácnost 2) Nerodinné domácnosti a. vdovec nebo vdova b. svobodný, nebo bez určení stavu c. rozšířená nerodinná domácnost Strukturu obyvatelstva a rozmístění obyvatelstva v obci dokreslují informace o počtu obyvatel, které žijí v jednotlivých typech domácností a počet obyvatel na jeden dům. Důležitým pohledem na strukturu obyvatelstva v rámci mikroanalýzy je sociální složení neboli sociální stratifikace obyvatelstva. Soupis bohužel tyto údaje explicitně neuvádí. U některých obyvatel, zejména u živitelů domácnosti, je uvedeno jejich povolání. To ovšem nestačí ke generalizujícímu pohledu na zkoumané obyvatelstvo, a proto ani v práci tato problematika není řešena. 3. Praktická část technická Tato část práce se zaměřuje na popis tvorby databázového systému navrženého pro zpracování soupisu duší. V jednotlivých částech této kapitoly bude kompletně popsán proces vzniku databáze od úvodní analýzy dat, přes vytvoření konceptuálního modelu, relačního modelu, až po implementaci návrhu do samotného aplikačního programu včetně jeho popisu. Úmyslně v této části nebude vysvětlen historicko-vědní význam termínů, které se v popisu databázového systému objeví. Této problematice je vyčleněna samostatná kapitola. 40

41 3.1 Vstupní požadavky Základním úkolem při návrhu databáze pro soupisy duší je pochopení dosavadní přístupu k těmto archiváliím. Jinými slovy je nezbytné odpovědět na otázky, kdo jsou potencionální uživatelé databáze, jakým způsobem získávají přístup k soupisům duší, proč jsou pro ně tyto archiválie atraktivní, jakým způsobem jsou zpracovávány a zisk jakých dat je pro badatele klíčový. Vytvoření uceleného pohledu na tuto problematiku probíhalo pomocí setkání a konzultací s pracovníky SOkA v Hradci Králové jakožto iniciátory projektu a studiem publikací, které se problematice soupisů duší věnují. V dalších odstavcích budou popsány jednotlivé aspekty práce se soupisy duší, které mají přímý dopad na tvorbu návrhu databáze Přístup k archiváliím Danou situaci lze charakterizovat takto: badatelé mohou získat na vyžádání originál archiválie, který lze studovat přímo v badatelně příslušného archivu, ne jinde. Druhou možností je získat digitalizovanou kopii archiválie, se kterou mohou jakkoliv nakládat Zpracování dat Práce s daty, které kniha soupisu duší obsahuje, má v zásadě dva okruhy zájmu. První, jednodušší cíl, je najít v záznamech konkrétní osobu, o kterou se badatel zajímá. Důvod tohoto hledání je prostý: badatele zajímá, zda daná osoba v předpokládaném časovém období a lokalitě žila, tedy jestli je o ní nějaký záznam. Pro splnění těchto požadavků je přepis a zpracování 41

42 dat databázovým systémem určitě výhodné, neboť vyhledání záznamu v databázi je rozhodně rychlejší, než prohledávání archivního materiálu. Často se však jedná o jednorázovou operaci, kdy badatel zjistil, co potřeboval, a vícekrát už soupis nepoužije. V takovém případě je ke zvážení, zda práce vynaložená na přepis pramene do databáze není namáhavější než prostudování analogového pramene. Druhou, z pohledu databáze mnohem zásadnější, službou, kterou soupis duší poskytuje, je hromadné a statistické zpracování dat, které pramen nabízí. Tato data jsou v zájmové oblasti badatelů, kteří například vytvářejí historicko-demografickou studii dané lokality. Zjednodušeně řečeno, představme si, že badatel potřebuje zjistit, kolik bylo v obci, která je středem jeho zájmu, obyvatel. Kolik z nich bylo žen a kolik mužů a podobně. Na základě těchto informací následně badatel vypracovává konkrétní studii. Na tomto jednoduchém příkladu si lze snadno představit, že manuální počítání jednotlivých záznamů, které archiválie obsahuje, je značně vyčerpávající a snadno vede k chybám ve výpočtu. V dřívějších dobách, dnes už opravdu jen vzácně, řešili historičtí demografové excerpci potřebných dat pomocí tištěných formulářů a čárkovací metodou. Většina současných badatelů používá ke zpracování dat služeb tabulkových editorů. Přepisem analogových záznamů do tabulkového editoru s následným využitím matematických funkcí pro práci se záznamy se sice lze dobrat určitých výsledků, na první pohled je ale patrné, že to není zcela ideální řešení. I když použití databázového systému obecně pro účely zpracování dat opravdu není v současnosti přelomovou novinkou, v oblasti historické demografie, soupisů duší a badatelů, kteří se touto problematikou 42

43 zabývají, se nejedná o prozkoumanou oblast. Tato práce je jedním z prvních pokusů aplikovat databázový systém pro zpracování dat pro historicko-demografické účely. Z povahy relačních databází a databází obecně je tedy patrné, že zpracování dat tímto způsobem přináší nesporné výhody. Samotný návrh databáze ztěžuje několik obecných okolností, které je si třeba uvědomit. Studium soupisů duší jako pramene pro historickou demografii je teprve v začátcích, takže existuje jen velmi málo scelujících studií, které by mapovaly excerpci dat z archivního pramene soupisu duší. Jinými slovy, nelze naprosto přesně a priori říci, která data ze soupisu duší lze považovat při návrhu databáze za naprosto klíčová a která označit za okrajová. V mnoha případech je tedy návrh struktury databáze z hlediska obsažených dat založen více na úsudku a znalostech historické demografie autora návrhu databáze než na studiích, které tuto problematiku sledují. Dalším problémem, který komplikuje návrh databáze, je fakt, že forma jednotlivých soupisů duší není unifikovaná. I když v době vzniku soupisů duší existovaly určité metodické pokyny, jak knihy vést a které informace v nich sledovat, forma knih se v průběhu doby měnila a samotné rozhodnutí, jak knihy vést, stejně záviselo na konkrétním autorovi. Nelze tedy vytvořit generalizující pohled, jak soupis duší vypadal, ale je při návrhu databáze nutné mít na paměti, že mezi jednotlivými knihami jsou, mnohdy značné, rozdíly. Výsledná struktura databáze je tedy jakýsi použitelný kompromis zohledňující rozdílnost jednotlivých soupisů. 43

44 3.1.3 Rozsah použití Důležitým aspektem, který je třeba objasnit, je jak velký objem dat bude databáze zpracovávat. Jedná o údaj, který je těžké vyjádřit nějakou přesnou hodnotou, cílem je tedy spíše vytvořit rámcovou představu. Jedná se ovšem o podstatný údaj, neboť na jeho základě lze hodnotit, zda uvažovaný databázový systém bude výkonově vyhovovat jeho navrhovanému účelu. Tento údaj lze získat protnutím dvou stanovitelných aspektů tedy jaké množství záznamů obsahuje jeden soupis duší a kolik soupisů bude databáze zpracovávat. Očekává se, že databáze bude sloužit badatelům SOkA Hradec Králové pro individuální použití, při tvorbě historickodemografických studií, které se budou vztahovat ke konkrétní lokalitě, v níž soupis duší vznikl. Představou tedy není zpracovat celý fond soupisů duší a vytvořit nějakou ucelenou databázi všech knih. Ze znalosti historické demografie, analýzy již existujících studií zabývajících se populacemi obcí a analýzou knih uložených v příslušném fondu vyplývá, že k vytvoření konkrétní studie používají badatelé řádově jednotky knih. 32 Pokud bychom přijali velmi zjednodušující fakt, že jedna osoba v soupisu duší se rovná jednomu záznamu v databázi, vyplývá, že z pohledu objemu dat se jedná o databázi spíše menšího rozsahu. 32 Zohledněny byly tyto studie: ČÁP, Jaroslav. Broumov a jeho obyvatelé ve světle soupisu věřících z roku 1785: články a studie. Stopami dějin Náchodska. Náchod: Státní okresní archiv, 1997, č. 3, s PAVLÍK, Jiří a Radek POKORNÝ. Status Animarum: Důležitý archivní pramen k vývoji obyvatelstva pevnostního Hradce Králové v první polovině 19. století. Královéhradecko: historický sborník pro poučenou veřejnost. 2011, č. 8 44

45 3.2 Cíle projektu Na základě rozboru výše uvedených vstupních požadavků lze stanovit cíle projektu: Tvorba databázového systému pro účely zpracování dat v rámci historicko-demografické studie nebo edice. Umožnit vkládání dat pomocí grafického rozhraní. Umožnit vyhledávání dat pomocí grafického rozhraní. Vytvořit nástroje pro komparaci dat s ohledem na zásady historické demografie. Vytvořit nástroje pro export dat z databázového nástroje a tvorbu rejstříku. Vytvořit databázový systém, který je přenosný tedy není závislý síti nebo lokálním úložišti. Pro tvorbu databázového systému byl použit program Microsoft Access ve verzi Microsoft Access Tento produkt splňuje požadavky, které jsou na databázový systém kladeny. Výhodou je všeobecná rozšířenost produktu Microsoft Office, jehož je součástí. 3.3 Konceptuální model dat Na základě zmapování vstupních požadavků a stanovení cílů lze přejít k samotné tvorbě konceptuálního modelu databáze. V tomto kroku jsou vytvořeny entity, jejich atributy a vztahy mezi entitami. Stanoveny jsou také primární klíče, sledována je kardinalita mezi vztahy entit a jejich členství v daném vztahu. Koncept je znázorněn E-R diagramem a veškeré aspekty jsou také zobrazeny pomocí lineárního zápisu. 45

46 3.3.1 E-R model E-R model popisuje navržené entity, vztahy mezi entitami a základní integritní omezení, které zahrnuje stanovení primárního klíče, kardinality, vztahu mezi entitami a členství ve vztahu. Obrázek 5: Schéma E-R diagramu zdroj: autor Lineární konceptuální zápis OSOBA (id_osoba:int, jmeno_transk_cj:char, prijmeni_transk_cj:char, jmeno_transk_nj:char, prijmeni_transk_nj:char, jmeno_transk_lt:char, prijmeni_transk_lt:char, jmeno_translit:char, prijmeni_translit:char, predikat:char, udavane_datum_nar:date, udavany_vek:int, misto_nar:char, umrti:char, datum_umrti:date, pohlavi:int, prednosta:char, pastorek:char, prislusnost:char, povolani:char, funkce:char, pozn_povolani:varchar) 46

47 DOMACNOST (id_domacnost:int, pozn_domacnost:varchar) DUM (id_dum:int, cislo_popisne:int, popis_domu:char, pozn_dum:varchar) MESTO (id_mesto:int, nazev_mesto:char, interpi:char, město_pozn:varchar) VIRA (id_vira:char, nazev_vira:char) CISELNIK_ROLE (id_role:char, popis_role:char) CISELNIK_SOC_STRATIFIKACE (id_soc_stratifikace:char, popis_soc_stratifikace:char) CISELNIK_TYP_DOMACNOST (id_typ_domacnost:char, popis_typ_domacnost:char) VERI (svate_prijimani:char, velikonocni_zpoved:char, obdrzeni_birmovani:char, schopnost_zpovedi:char, schopnost_svateho_prijimani:char) 3.4 Relační model dat Podstata relační databáze a relačního modelu dat byla vysvětlena v teoretické části. Z praktického hlediska lze říci, že navržený relační model databáze odpovídá struktuře dat následně aplikované v databázovém nástroji. 47

48 3.4.1 Transformace E-R modelu Proces transformace E-R modelu do relačního modelu dat je založen na dekompozici vztahů mezi uvažovanými relacemi, analýzy funkčních závislostí atributů a stanovení integritního omezení tak, aby navrhovaná struktura odpovídala pravidlům relační databáze. Ověření správnosti struktury probíhá pomocí procesu normalizace, tak aby datová struktura splňovala normalizační pravidla. Cílem navrhované struktury je, aby odpovídala pravidlům třetí normální formy Fyzický model relační databáze Fyzický model relační databáze lze zobrazit několika způsoby. Základní metodou je lineární zápis relací. Ten však není ve svém důsledku příliš přehledný, neboť nevyjadřuje vazby mezi relacemi. Z hlediska přehlednosti je mnohem výhodnější použití schématu, které mnohem lépe vyjadřuje vazby mezi relacemi. 48

49 Schéma fyzického modelu relační databáze Obrázek 6: Schéma fyzického modelu databáze zdroj: autor 3.5 Definice dat Tvorba struktury databáze tabulek, je provedena pomocí jazyka SQL, respektive pomocí jeho příkazů pro definici dat (DDL). Pro tvorbu tabulek je stanoven příkaz CREATE TABLE. Jeho celá syntaxe vypadá takto: CREATE TABLE [nazev_databaze.]nazev_tabulky (<nazev sloupce> <datovy typ> 49

50 [DEFAULT <konstantni vyraz>] [NULL NOT NULL] [<omezeni pro sloupce>] [<omezeni pro tabulku>] [,...n]; 33 Na následujících stránkách je popsána tvorba konkrétních tabulek pomocí jazyka SQL včetně obrázku vyobrazující vytvořenou tabulku v návrhovém zobrazení. Tabulka obec Obrázek 7: Tabulka obec Zápis pomocí SQL: CREATE TABLE obec ( id_obec int NOT NULL PRIMARY KEY, nazev_obec char(30) NOT NULL, interpi char(30), obec_pozn char(255) ) zdroj: autor 33 POKORNÝ, Jaroslav a Ivan HALAŠKA. Databázové systémy. 1. vydání. Praha: ČVUT, 1999, s. 87, ISBN

51 Tabulka dum Obrázek 8: tabulka dum zdroj: autor Zápis pomocí SQL: CREATE TABLE dum ( id_dum int NOT NULL, cislo_popisne char(10) NOT NULL, popis_dum char(30), dum_pozn varchar(255), id_obec int, PRIMARY KEY (id_dum), CONSTRAINT id_obec FOREIGN KEY (id_obec) REFERENCES obec(id_obec) ) Tabulka ciselnik_typ_domacnosti Obrázek 9: Tabulka ciselnik_typ_domacnosti zdroj: autor 51

52 Zápis pomocí SQL CREATE TABLE ciselni_typ_domacnosti ( id_typ_domacnost char(5) NOT NULL UNIQUE PRIMARY KEY, popis_typ_domacnosti char(30) ) Tabulka domacnost Obrázek 10: Tabulka domacnost Zápis pomocí SQL: zdroj: autor CREATE TABLE domacnost ( id_domacnost int NOT NULL, id_typ_domacnost char(5) NOT NULL, id_obec int, id_dum int, domacnost_pozn varchar(255), PRIMARY KEY (id_domacnost), CONSTRAINT fk_d_id_obec FOREIGN KEY (id_obec) REFERENCES obec(id_obec), CONSTRAINT fk_d_id_dum FOREIGN KEY (id_dum) REFERENCES dum(id_dum), CONSTRAINT fk_d_id_typ_domacnost FOREIGN KEY (id_typ_domacnost) REFERENCES ciselnik_typ_domacnosti(id_typ_domacnost) ) 52

53 Tabulka ciselnik_role Obrázek 11: Tabulka ciselnik_role Zápis pomocí SQL: zdroj: autor CREATE TABLE ciselnik_role ( id_role char(5) NOT NULL UNIQUE PRIMARY KEY, popis_role char(30) role_pozn varchar(255) ) Tabulka ciselnik_soc_stratifikace Obrázek 12: Tabulka ciselnik_soc_stratifikace zdroj: autor Zápis pomocí SQL: CREATE TABLE ciselnik_soc_stratifikace ( id_soc_stratifikace char(5) NOT NULL UNIQUE PRIMARY KEY, popis_soc_stratifikace char(30), soc_stratifikace_pozn varchar(255) ) 53

54 Tabulka osoba Obrázek 13: Tabulka osoba Zdroj: autor Zápis pomocí SQL: CREATE TABLE osoba ( id_osoba int UNIQUE NOT NULL, id_domacnost int NOT NULL, id_dum int NOT NULL, jmeno_transk_cj char(20) NULL, prijmeni_transk_cj char(20) NULL, jmeno_transk_nj char(20) NULL, prijmeni_transk_nj char(20) NULL, jmeno_transk_lt char(20) NULL, prijmeni_transk_lt char(20) NULL, predikat char(10) NULL, udavane_dat_nar date NULL, udavany_vek int NULL, misto_nar char(30) NULL, pohlavi int NOT NULL, prednosta bit NULL, prislusnost int NOT NULL, pastorek bit NULL, id_soc_stratifikace char(5) NULL, id_role char(5) NOT NULL, povolani char(20) NULL, funkce char(20) NULL, umrti bit NULL, 54

55 datum_umrti date NULL, navstevovani_skoly bit NULL, osoba_pozn varchar(255), PRIMARY KEY (id_osoba), CONSTRAINT fk_o_id_dum FOREIGN KEY (id_dum) REFERENCES dum(id_dum), CONSTRAINT fk_o_id_domacnost FOREIGN KEY (id_domacnost) REFERENCES domacnost(id_domacnost), CONSTRAINT fk_o_id_role FOREIGN KEY (id_role) REFERENCES ciselnik_role(id_role), CONSTRAINT fk_o_id_soc_stratifikace FOREIGN KEY (id_soc_stratifikace) REFERENCES ciselnik_soc_stratifikace(id_soc_stratifikace) ) Tabulka vira Obrázek 14: Tabulka vira Zdroj: autor Zápis pomocí SQL: CREATE TABLE vira ( id_vira int NOT NULL, nazev_vira char(50) NULL, PRIMARY KEY (id_vira) ) 55

56 Tabulka vira_osoba Obrázek 15: Tabulka vira_osoba Zápis pomocí SQL: zdroj: autor CREATE TABLE vira_osoba ( id_vira int NOT NULL, id_osoba int NOT NULL, svate_prijimani bit NULL, velikonocni_zpoved bit NULL, obdrzeni_birmovani bit NULL, schopnost_zpovedi bit NULL, schopnost_svateho_prijimani bit NULL, PRIMARY KEY (id_osoba, id_vira), CONSTRAINT fk_vo_id_osoba FOREIGN KEY (id_osoba) REFERENCES osoba(id_osoba), CONSTRAINT fk_vo_id_vira FOREIGN KEY (id_vira) REFERENCES vira(id_vira) ) Tabulka vlastnictví_dum Obrázek 16: Tabulka vlastnictvi_dum zdroj: autor 56

57 Zápis pomocí SQL: CREATE TABLE vlastnictvi_dum ( id_osoba int NOT NULL, id_dum int NOT NULL, PRIMARY KEY (id_osoba, id_dum), CONSTRAINT fk_odm_id_osoba FOREIGN KEY (id_osoba) REFERENCES osoba(id_osoba), CONSTRAINT fk_odm_id_dum FOREIGN KEY (id_dum) REFERENCES dum(id_dum) ) 3.6 Manipulace s daty Příkazy pro manipulaci dat v SQL zahrnují výběrový příkaz SELECT a aktualizační příkazy INSERT, DELETE, UPDATE. Tyto příkazy jsou zapisovány a spouštěny pomocí dotazů. Dotazy jsou následně implementovány do grafického rozhraní. Uživatel k nim může přistupovat pomocí vytvořených formulářů, nebo pomocí vlastních dotazových objektů. Vzhledem k množství použitých dotazů je jejich kompletní výčet včetně popisu konstrukce přiložen jako vlastní dokumentace v příloze práce. Z hlediska historicko-vědního jsou tyto dotazy rozebrány v následující kapitole. 3.7 Grafické rozhraní Tvorbu grafického uživatelského rozhraní (GUI) databáze v MS Access lze realizovat pomocí již hotových objektů a ovládacích prvků, které program nabízí. Výhodné je, že uživatel databáze tak může sám snadno přizpůsobovat uživatelské rozhraní podle vlastní potřeby. Databázový 57

58 systém je na prvcích grafického rozhraní nezávislý, takže změny v GUI neovlivní strukturu dat. Grafické uživatelské rozhraní použité v práci je vytvořeno pomocí soustavy formulářů. Pro každou relaci a skupinu dotazů je vytvořen vlastní formulář. Podle oblasti použití jsou formuláře seskupeny do tří hlavních kategorií. Pro každou tuto kategorii je vytvořen jeden centrální formulář navigační formulář, který umožňuje pomocí pásu přepínacích karet jejich ovládání. Vytvořen je navigační formulář vkládání údajů, který slouží k vkládání dat do databáze. Navigační formulář dotazy seskupuje formuláře s vytvořenými dotazy. Navigační formulář rejstřík a vyhledávání slouží k vyhledávání konkrétních záznamů v databázi podle parametru a také k tvorbě sestav. Obrázek 17: Formulář vkládání údajů zdroj: autor 58

59 Obrázek 18: Formulář dotazy zdroj: autor Obrázek 19: Formulář rejstřík a vyhledávání zdroj: autor 59