Databáze obcí včetně importu dat z databáze matrik

Databáze obcí včetně importu dat z databáze matrik DOKUMENT SPECIFIKACE POŽADAVKŮ pro Historical Document Viewer Verze 1.1

Historie dokumentu Datum Verze Popis Autor 26.03.2012 1.0 První verze Pavel Cihlář 03.04.2012 1.1 Úprava slovníku a některých požadavků Pavel Cihlář Stránka 2 z 20

Obsah 1. Úvod... 4 1.1 Předmět specifikace... 4 1.2 Cílové publikum, návod ke čtení... 4 1.3 Rozsah projektu... 5 1.4 Odkazy... 5 2. Obecný popis... 5 2.1 Kontext systému... 5 2.2 Funkce produktu... 7 2.3 Třídy uživatelů... 7 2.3.1 Uživatel typu badatel... 8 2.3.2 Uživatel typu archivář... 8 2.4 2.5 Provozní prostředí... 8 Omezení návrhu a implementace... 8 2.6 Uživatelská dokumentace... 8 2.7 Předpoklady a závislosti... 8 3. Funkce systému... 9 3.1 Import obcí do nové databázové struktury... 9 3.1.1 Popis a priorita... 9 3.1.2 Události a odpovědi... 9 3.1.3 Funkční požadavky... 9 3.2 Import ostatních dat do nové databáze... 9 3.2.1 Popis a priorita... 9 3.2.2 Události a odpovědi... 10 3.2.3 Funkční požadavky... 10 3.3 Import dat z databáze Acta Publica do nové databáze... 10 3.3.1 Popis a priorita... 10 3.3.2 Události a odpovědi... 10 3.3.3 Funkční požadavky... 10 3.4 Webové rozhraní... 11 3.4.1 Popis a priorita... 11 3.4.2 Události a odpovědi... 11 3.4.3 Funkční požadavky... 11 4. Požadavky na vnější rozhraní... 11 4.1 Uživatelská rozhraní... 11 4.2 4.3 Hardwarová rozhraní... 11 Softwarová rozhraní... 12 4.4 Komunikační rozhraní... 12 5. Další parametrické (mimofunkční) požadavky... 12 5.1 Výkonnostní požadavky... 12 5.2 Bezpečnostní požadavky... 12 5.3 Kvalitativní parametry... 13 6. Ostatní požadavky... 13 7. Dodatek A: Slovníček... 14 7.1 Obecný... 14 7.2 Technický... 15 8. Dodatek B: Analytické modely... 16 8.1 Popis tabulek databáze Acta Publica:... 16 8.2 Use-Case: Drupal HDV... 17 8.3 ERA Diagram: Struktury Drupalu 7... 18 8.4 ERA Diagram: Redukovaná struktura tabulek databáze Acta Publica... 19 9. Dodatek C: Seznam úkolů... 20 Stránka 3 z 20

1. Úvod 1.1 Předmět specifikace Účel tohoto dokumentu je definovat potřeby a požadavky od našich zadavatelů, které postihují problematiku převodu databází obcí a matrik do nové podoby. Dále pak popsat projekt, který významným způsobem vylepší současný informační systém Státního oblastního archivu v Plzni. Tento dokument slouží jako základ komunikace mezi vývojáři i mezi všemi zainteresovanými stranami. Představuje smluvní ujednání, kterého se budou všechny strany držet. 1.2 Cílové publikum, návod ke čtení Dokument specifikace požadavků je určen především celému týmu CK Lokomotiva, to jest autorům projektu a dále pak zadavatelům, kterými jsou zaměstnanci Státního oblastního archivu v Plzni. Nejdůležitější kapitolou tohoto dokumentu je kapitola číslo čtyři, kde se specifikují nejdůležitější požadavky našich zadavatelů. Složení týmu CK Lokomotiva: Jméno Studijní číslo Kontakt Pavel Cihlář A11N0020P CihlaP@seznam.cz Jaroslav Kvapil A11N0117P begbang@gmail.com Martin Štulc A11N0131P martin.stulc@gmail.com Jan Šváb (team leader) A080061P jansvab10@gmail.com Zadavatelé: Jméno Funkce Kontakt Bc. Petr Kocourek Správce ICT kocourek@soaplzen.cz Bc. Jan Římovský Správce ICT rimovsky@soaplzen.cz Stránka 4 z 20

1.3 Rozsah projektu Rozsah a účel projektu Databáze obcí včetně importu dat z databáze matrik je podrobně popsán v dokumentu Vize projektu, který je k dispozici na následujícím odkazu: http://students.kiv.zcu.cz/wiki/uploads/aswi2012ckl/vize.doc 1.4 Odkazy Vize projektu: http://students.kiv.zcu.cz/wiki/uploads/aswi2012ckl/vize.doc Školní web projektu: http://students.kiv.zcu.cz/wiki/aswi2012ckl/homepage Stránky projektu: http://www.assembla.com/spaces/nrap_hdv/wiki Úložiště projektu: http://www.assembla.com/code/nrap_hdv/subversion/nodes/trunk/new?rev=221 Státní oblastní archiv v Plzni: http://www.soaplzen.cz/cs Akta publica: http://actapublica.eu/ 2. Obecný popis 2.1 Kontext systému 2002 - Státní oblastní archiv se stává samostatnou organizační složkou státu. Devět státních okresních archivů se stává součástí Státního oblastního archivu (předtím součástí okresních úřadů). Vznikem hospodářsko-správního oddělení SOA v Plzni vznikla nutnost zvládnout skokový nárůst administrativy 2003-2004 - Počátek snahy o postupné sjednocení úrovně informačních a komunikačních technologií v okresních archivech a v SOA, vytváření počítačových sítí, zřizování připojení k Internetu, zřizování serverů, nákup a obměna PC a telefonních ústředen, počátky zajišťování správy PC ve spolupráci s místními firmami nebo soukromníky. Ve všech archivech je používán jednotný software pro evidenci archiválií (ARS, PEvA - FoxPro). Zavádí se jednotný SW pro archivní knihovny (Clavius), včetně převodu dat ze stávajících systémů. 2004-2008 - Navázáno úzké obchodní partnerství se společností NetPro systems. Obměna všech serverů, propojení lokálních počítačových sítí prostřednictvím VPN, vznik jednotné intranetové aplikace SOANET, náhrada všech dosavadních webových prezentací jednotnými webovými stránkami, zavádění programu pro tvorbu archivních pomůcek inventárních seznamů JANUS 2000, počátek zpřístupňování archivních pomůcek na webu, příprava zpřístupňování matrik a kronik na webu, významný podíl SOA na vývoji SW pro NetPro (analýzy, testování, dokumentace, školení a podpora uživatelů, propagace). Počátek digitalizace matrik a kronik. Stránka 5 z 20

2009 - Končí smlouva se společností NetPro systems, z důvodu nevýhodnosti pro archiv a různým problémům při spolupráci rozhodnuto stávající smlouvu ani obchodní partnerství neprodlužovat. Zajišťování náhrady všech komponent informačního systému, který byl ve spolupráci se společností NetPro vytvářen čtyři roky, protože kvůli podmínkám končící smlouvy je nebylo možné bez jejího prodloužení dále používat. Obměna lokálních serverů. 2010 - Zprovozněny nové webové stránky a intranetové aplikace vytvořené informatiky SOA v Plzni (včetně převodu dat z původních aplikací). Dále zprovozněn nový podací deník vytvořený ve spolupráci se Západočeskou univerzitou v Plzni (ZČU), převedena data z minulých let z intranetového modulu Spisová služba. S koncem roku vypršela platnost poslední smlouvy SOA v Plzni se společností NetPro systems, na vývoj a správu programu (Janus 2000) pro tvorbu archivních pomůcek a jejich zveřejňování. Program již není vyvíjen archiváři je využíván čím dál méně, hlavně kvůli relativní náročnosti na uživatele a uživatelskou podporu (relativně nízká úroveň textového editoru, problémy především s tiskovými sestavami), i na správu (jednouživatelský systém, problémy s instalací na nové operační systémy). Opětovné zpřístupnění archivních pomůcek na Internetu je naplánováno na další rok pomocí vlastního nového SW, který bude muset dříve či později program Janus 2000 plně nahradit. Zahájení zpřístupňování matrik veřejnosti pomocí webové aplikace Acta Publica ve spolupráci s Moravským zemským archivem (MZA), včetně převodu dat z původní intranetové aplikace. Příprava nové aplikace pro popis a prezentaci digitalizovaných archiválií včetně komplexních metadat a pokročilého vyhledávání. Sjednocení databází regionálních knihoven archivů - zavedení systému Clavius REKS. Spolupráce se Západočeskou univerzitou v Plzni na projektu Prohlížeč historických dokumentů (HDV, opensource). Tento projekt měl zajistit integritu dat a jejich zprostředkování prostřednictvím webového rozhraní. 2011 - Další spolupráce se ZČU - Program na převod formátů a obohacování obrázků metadaty. Projekt vyřešil především způsob uložení obrazových dat a k nim odpovídajících popisných informací (metadat). Převod obrázků z několika formátů do formátu JPEG2000 a zajistil sjednocení dat ze vstupních souborů s metadaty a jejich uložení ve formátu XML přímo do souboru s obrázkem. Takto uložená metadata byly zpřístupněny prostřednictvím jednoduchého rozhraní v PHP, které umožňovalo základní integraci se systémem pro prohlížení archivních dat přes webový prohlížeč. Vzhledem k tomu, kolik zásahů bylo do informačního systému SOA v Plzni provedeno a to různými vývojáři, je naše práce podstatně ztížena. Naší primární starostí je jen část celkového problému a to import dat ze současných struktur do struktury nové. Stránka 6 z 20

2.2 Funkce produktu Požadavek na aplikaci vznikl v souvislosti s potřebou Státního oblastního archivu v Plzni digitalizovat archivní sbírky tak, aby byl v budoucnu umožněn přístup běžných uživatelů internetu a archivářů (zaměstnanců Státního oblastního archivu v Plzni) k archivu prostřednictvím webového rozhraní. To by mělo Státnímu oblastnímu archivu ušetřit čas i peníze. Výhody tohoto přístupu: ochrana národního dědictví rychlejší prozkoumávání lepší dostupnost prezentace archivu veřejnosti Jednotná databáze Webové rozhraní Badatel Archivář MySQL PHP, Drupal 7 2.3 Třídy uživatelů Uživatel Definice Činnost Badatel Každý uživatel internetu Prohledávání archivu webové rozhraní Archivář Zaměstnanec Státního oblastního archivu v Plzni Prohledávání a veškerá správa (editace) dat Stránka 7 z 20

2.3.1 Uživatel typu badatel Reprezentuje každého uživatele internetu, který se rozhodne navštívit vyvíjený web a který si bude pomocí webového rozhraní moci vyhledat historické souvislosti např. o svém původu, o své obci atd. 2.3.2 Uživatel typu archivář Archiváři jsou zaměstnanci Státního oblastního archivu v Plzni, kteří aplikaci budou využívat nejen k vyhledávání informací, ale i k její editaci a to zejména k přidávání nového obsahu. Ti budou také zodpovídat za správnost dat. 2.4 Provozní prostředí Požadavky na hardwarové nároky, odezvu systému, zabezpečení ani na uživatelské prostředí nebyly nijak stanoveny. Není naším úkolem řešit platformu, na které aplikace poběží. 2.5 Omezení návrhu a implementace Jsme omezeni na následující technologie: MySQL PHP Drupal 7 2.6 Uživatelská dokumentace Žádné požadavky na uživatelskou dokumentaci na nás nebyly kladeny. 2.7 Předpoklady a závislosti Zadavatel musí provozovat vlastní server, kde poběží webový server Apache, systém Drupal a dále pak musí vlastnit doménu. K dispozici je již hotová databázová struktura, kterou lze po domluvě upravit. Je nutné užít technologie PHP (Drupal 7) s MySQL. Tyto technologie již použili při vývoji naši předchůdci. Posledním faktorem je webové rozhraní, k jeho případné implementaci nemusí být dostatek času. Toto rozhraní nebylo zadavatelem nijak specifikováno. Jeho složitost je na nás. Stránka 8 z 20

3. Funkce systému 3.1 Import obcí do nové databázové struktury 3.1.1 Popis a priorita Importem obcí do nové databázové struktury se rozumí jednorázový přesun dat, která obsahuje dokument tabulkového procesoru (.xls). Nová databázová struktura nám byla předem dána (vytvořena zadavateli a externí firmou. Tato databázová struktura je založena na systému Drupal 7. Tato část projektu má nejvyšší možnou prioritu, protože data, která budou importována do nové databázové struktury, se již nebudou měnit. Jedná se o jednorázový import. Výsledek může sloužit jako pevný bod pro případné další pokračovatele (vývojáře). 3.1.2 Události a odpovědi Událostí se rozumí vyhledávání archiváře, či badatele v archivu (v databázi). Po zadání hledaného výrazu se zobrazí odpovídající data. Veškeré události a odpovědi mají probíhat mezi uživatelským prostředím (webovým rozhraním) a vlastní databází. 3.1.3 Funkční požadavky POŽADAVEK-1: Import veškerých dat z.xls dokumentu. POŽADAVEK-2: Data nesmí být duplicitní či nekonzistentní. POŽADAVEK-3: Nová databáze a data v ní obsažena musí být propojena s webovým rozhraním. 3.2 Import ostatních dat do nové databáze 3.2.1 Popis a priorita Po úspěšném importu obcí do nové databázové struktury je na řadě i import kronik, které jsou rovněž uloženy v dokumentech tabulkového procesoru (.xls). Jedná se taktéž o jednorázový import. Tato část projektu má vysokou prioritu. Zadavatel se zavázal, že tato ostrá data dodá nejpozději do 20.04.2012. Stránka 9 z 20

3.2.2 Události a odpovědi Událostí se rozumí vyhledávání archivářem, či badatelem v archivu (v databázi). Po zadání hledaného výrazu se zobrazí odpovídající data. Veškeré události a odpovědi mají probíhat mezi uživatelským prostředím (webovým rozhraním) a vlastní databází. 3.2.3 Funkční požadavky POŽADAVEK-1: Import veškerých použitelných dat z dokumentů.xls do nové databázové struktury. POŽADAVEK-2: Data nesmí být duplicitní či nekonzistentní. POŽADAVEK-3: Nová databáze a data v ní obsažena musí být propojena s webovým rozhraním. 3.3 Import dat z databáze Acta Publica do nové databáze 3.3.1 Popis a priorita Vedle úspěšného importu dat (obcí, kronik) je třeba zajistit import základních dat (obce, matriky) z databáze Acta Publica do nové databázové struktury. Následně zajistit aby tato data byla konzistentní a zamezit jejich duplicitě. Po dokončení této části, bude následovat import ostatních dat z databáze Acta Publica a opět jejich následná kontrola. Tato část importu bude mít zásadní vliv na posouzení kvality provedení celého projektu, a proto má vysokou prioritu Testování řešení tohoto bodu bude probíhat na neúplné databázi AP. Ostrá verze databáze bude k dispozici nejdříve až v úplném závěru projektu. 3.3.2 Události a odpovědi Událostí se rozumí vyhledávání archivářem, či badatelem v archivu (v databázi). Po zadání hledaného výrazu se zobrazí odpovídající data. Veškeré události a odpovědi mají probíhat mezi uživatelským prostředím (webovým rozhraním) a vlastní databází. 3.3.3 Funkční požadavky POŽADAVEK-1: Import matrik a obcí z databáze Acta Publica do nové databázové struktury. POŽADAVEK-2: Import ostatních dat z databáze Acta Publica do nové databázové struktury. POŽADAVEK-3: Data nesmí být duplicitní či nekonzistentní. POŽADAVEK-4: Nová databáze a data v ní obsažena musí být propojena s webovým rozhraním. Stránka 10 z 20

3.4 Webové rozhraní 3.4.1 Popis a priorita Webové rozhraní musí umožňovat vyhledávat data v nové databázové struktuře. Toto vyhledávání musí korektně fungovat a veškerá data musí být skrze toto rozhraní editovatelná. Vše musí být napsáno v PHP a běžet pod systémem Drupal 7. 3.4.2 Události a odpovědi Událostí se rozumí dotaz na databázi, který se vyšle z webového rozhraní v momentě, kdy se uživatel (badatel, archivář) pokusí vyhledat nějaká data. Odpovědí je výpis určených dat prostřednictvím webového rozhraní. 3.4.3 Funkční požadavky POŽADAVEK-1: Webové rozhraní musí být správně propojeno s novou databázovou strukturou. POŽADAVEK-2: Data musí být editovatelná. POŽADAVEK-3: V případě časové rezervy je možné pustit se do grafické úpravy tohoto prvku. 4. Požadavky na vnější rozhraní 4.1 Uživatelská rozhraní Uživatelským rozhraním je webové rozhraní napsané v PHP, fungující pod systémem Drupal 7. Toto webové rozhraní jsme netvořili my, ale naši předchůdci. Nepředpokládáme téměř žádné podstatné úpravy, protože by to ani kvůli časovému omezení nebylo možné. Řešit uživatelské rozhraní není předmětem projektu, tj. neřešíme např. rozlišení obrazovky, tlačítka, klávesové zkratky, pravidla ohledně lokalizace softwaru, pravidla pro zobrazení zpráv apod. Jediným požadavkem je, aby výsledná aplikace byla funkční, tj. aby bylo možné vyhledávat v databázi, kterou naplníme daty, prostřednictvím webového rozhraní. 4.2 Hardwarová rozhraní Hardwarové rozhraní nebylo nijak specifikováno. Neohlížíme se na platformu, ani na nic jiného. V tomto ohledu nejsme omezeni. Omezeni jsme pouze po softwarové stránce. Stránka 11 z 20

4.3 Softwarová rozhraní Jsme omezeni následujícími technologiemi: MySQL PHP Drupal 7 Viz use-case diagram v kapitole 8.2. Databáze je vytvořena v MySQL, je nad ní vystavěno webové rozhraní v PHP a to vše běží na serveru, na kterém je nainstalovaný systém Drupal 7. Přes webové rozhraní se vyšle dotaz na databázi, kde se vyberou požadovaná data, která se následně přes webové prostředí zobrazí uživateli. Důvodem tohoto omezení je fakt, že se nejedná o první aplikaci tohoto typu. 4.4 Komunikační rozhraní Ke komunikaci slouží webové rozhraní napsané našimi předchůdci v PHP. Není naším úkolem ho jakkoliv modifikovat, a proto neřešíme např. formát pro výměnu zpráv, zabezpečení komunikačních kanálů, šifrování, přenosové rychlosti, synchronizační mechanismy ani nic podobného. V případě potřeby můžeme toto komunikační rozhraní modifikovat, ale není to předmětem projektu. 5. Další parametrické (mimofunkční) požadavky 5.1 Výkonnostní požadavky Požadavky na výkon jednotlivých funkcí výsledné aplikace nebyly zadavatelem specifikovány. Neřešíme proto věci jako typ CPU či jeho taktovací frekvence, minimální velikost operační paměti nebo operační systém. 5.2 Bezpečnostní požadavky Nebyly žádným způsobem specifikovány. Není předmětem řešeného projektu. Samotné zabezpečení komunikace s databází zajišťuje Drupal. Stránka 12 z 20

5.3 Kvalitativní parametry Požadavky na snadnost používání, spolehlivost, robustnost či udržovatelnost nebyly žádným způsobem specifikovány. Kvalitativní požadavky a jejich priorita, podle kterých se bude hodnotit výsledná aplikace, jsou následující: import základních dat do nové databáze (1) odstranění duplicity dat (1) konzistence dat (1) funkčnost webového rozhraní (1) import veškerých dat do nové databáze (2) přizpůsobení databáze (2) ostatní činnosti (3) 6. Ostatní požadavky Žádné další požadavky jako jsou např. právní požadavky, požadavky na lokalizaci, provoz, správu a údržbu výsledné aplikace apod. nebyly žádným způsobem specifikovány. Stránka 13 z 20

7. Dodatek A: Slovníček 7.1 Obecný Archivář - Zaměstnanec Státního oblastního archivu v Plzni Matrika - Jde o seznam narození, sňatků a úmrtí. Agenda matrik patří do kompetence Ministerstva vnitra. Okres - Okres je označení typu územně-správní jednotky menší než kraj a větší než obec, české a slovenské okresy vznikly postupným vývojem z okresů Československa a Rakousko-Uherska. Samota - Samota, venkovská samota nebo na Moravě laz obvykle označuje osamocené venkovské lidské obydlí tvořené jediným domem, výjimečně až dvěma nebo třemi obydlenými domky. Samota může být také charakterizována nepřítomností dalšího stavení na doslech" ani na dohled" (podle terénu krajiny). Samoty obvykle administrativně patří do obce, na jejímž území se nacházejí. Polohu samoty mohou mít i solitérní venkovská sídla jako zámečky, hospodářské dvory a usedlosti, hájovny, myslivny, mlýny, hamry. Osamocená poloha těchto objektů byla volena pro účelovou činnost vázanou na zemědělskou kulturu (hájovny a myslivny na okraji lesů a obor), na zdroj energie (vodní a větrné mlýny, hamry), na zdroj příjmů (hospody u křižovatek) nebo z důvodu zvláštního společenského postavení vlastníka či obyvatele (reprezentativní sídlo). Panství - Panství je historický termín, který označuje soubor soukromého (zejm. rodinného) majetku (reprezentačních či hospodářských staveb, měst, vesnic, polností, lesů, vodohospodářských staveb apod., včetně jeho poddaných a služebnictva) spadajícího pod patrimoniální správu jednoho vlastníka nebo rodiny (pána) šlechtického původu. Zároveň se jednalo o správní jednotky. V českých zemích existovala panství do roku 1848, kdy byla patrimoniální správa nahrazena státní správou vykonávanou okresy a samosprávou vykonávanou obcemi. Období spravování - Časová jednotka, po kterou byla daná oblast spravována. Statutární město - Statutární město je město, jehož správa je organizována (nebo může být organizována) podle základní městské vyhlášky nebo zemského zákona, přičemž se oba typy těchto právních norem označují jako statut města. Status statutárního města může znamenat buď právo města vydat statut města, nebo povinnost města vydat statut města. Politická správa - Politická správa je název pro ten úsek veřejné správy, kterou vykonává ministerstvo vnitra a politické úřady jemu podřízené". Vznikla na základě císařského nařízení z 31. Července 1849. První instancí byl politický okres (Okresní hejtmanství nebo též Podkrajský úřad), jehož území tvořily většinou obvody dvou nebo tří soudních okresů. Druhou instancí politické správy byly krajské vlády podřízené ministerstvu vnitra. Na základě zákona č. 10 ř. z. z 25. ledna 1853 došlo s účinností od 12. května 1855 k první reorganizaci státní správy. Dosavadní soudní okresy se změnily v tzv. smíšené politicko-soudní okresy. Krajské vlády byly nahrazeny krajskými úřady, které však byly pouze prostředníky mezi okresními a zemskými úřady a jako takové byly v Čechách nařízením z 23. Října 1862 k 1. listopadu 1862 zrušeny. Stránka 14 z 20

Soudní správa - V Čechách vznikla císařským nařízením z 26. června 1849. Základními články se staly okresní soudy s působností pro soudní okresy, které byly podřízeny krajským (do r. 1855 krajinským) nebo zemským (týká se zemských hlavních měst - Brna, Prahy) soudům. Obvod krajského soudu tvořilo 15 až 25 soudních okresů a zhruba se shodoval s územím politického kraje. Obec - Obce jako samosprávné jednotky vznikly v rámci reforem v roce 1850, kdy byla zákonem ze 17. března 1849 zrušena dosavadní panství a vrchnostenské zřízení a nejnižší jednotkou správy se staly obce.*1+ Po druhé světové válce a za komunistického režimu v souvislosti se zřízením národních výborů obce ztratily faktickou právní subjektivitu, třebaže i nadále existovaly formálně volené obecní orgány. Postavení obcí definoval československý ústavní zákon o národních výborech (12/1954 Sb.) a zákon o národních výborech, 13/1954 Sb., později 65/1960 Sb. a 69/1967 Sb. Zákonem České národní rady č. 367/1990 Sb., o obcích (obecní zřízení), byla ke dni voleb obnovena právní subjektivita obcí a byla rozlišena samostatná a přenesená působnost obcí. Obcemi jsou podle tohoto zákona územní celky, které byly obcemi ke dni nabytí jeho účinnosti, a obce nově vzniklé podle tohoto zákona. Práva a povinnosti místních a městských národních výborů přešly ke dni nabytí účinnosti zákona na obce, v nichž měly tyto národní výbory sídlo. Obcemi přidruženými pod společný MNV se sídlem v jiné obci se zákon č. 367/1990 Sb. speciálně nezabývá a nezmiňuje je. Další změny přinesl nový zákon o obcích, 128/2000 Sb. Zatímco zákon z roku 1990 definoval obec jako územní celek, zákon z roku 2000 jako územní samosprávné společenství občanů, tvořící územní celek. Postavení Prahy jako obce je upraveno samostatným zákonem. Fara - Fara je obydlí a zároveň úřadovna faráře, úřední sídlo farnosti a případně i místo jejích dalších, zejména neliturgických aktivit. Do roku 1950 zde byly vedeny církevní farní matriky, do kterých se zapisovaly sňatky, narození a křty i úmrtí. Křestní matriky vedou církve pro vlastní potřebu zpravidla dodnes. Digitalizovaný materiál - V současnosti se vztahuje k matričním knihám a zápisům, kronikám, vedutám a soupisům poddaných, výhledově jsou připravovány sčítací operáty a pozemkové knihy. SOA - Státní Oblastní Archiv 7.2 Technický PHP - ( PHP: Hypertextový preprocesor, původně Personal Home Page) je skriptovací programovací jazyk. Je určený především pro programování dynamických internetových stránek a webových aplikací například ve formátu HTML, XHTML či WML. Drupal - Drupal je softwarový systém pro správu obsahu, který původně napsal Dries Buytaert. Umožňuje tvorbu internetových časopisů, blogů, internetových obchodů a jiných komplexních systémů. Je naprogramován v jazyce PHP. Oficiálně podporovanými databázemi v Drupalu jsou relační databáze MySQL a PostgreSQL. MySQL - MySQL je multiplatformní databáze. Komunikace s ní probíhá jak už název napovídá pomocí jazyka SQL. Podobně jako u ostatních SQL databází se jedná o dialekt tohoto jazyka s některými rozšířeními. Janus 2000 - Program, který je určen pro tvorbu archivních pomůcek a jejich zveřejňování. Webové rozhraní - V podstatě internetová stránka sloužící ke komunikaci s uživatelem. Stránka 15 z 20

8. Dodatek B: Analytické modely 8.1 Popis tabulek databáze Acta Publica: Tabulka new_cfg Jedná se o tabulku, která obsahuje více různých typů záznamů: jednotlivé okresy jednotlivé státy číselníky (například pro vyjádření zachovalosti vazby matriky) Tabulka new_obce Obsahuje obce a jejich části v historickém vývoji (například část obce vznikla v určitém roce a zanikla v jiném roce). Dále zachycuje historické změny názvů jednotlivých obcí a jejich částí. Tabulka new_comunity_district Zachycuje správní vývoj lokalit z tabulky new_obce, tedy k jakému okresu, panství nebo státu patřila v daném období. Tabulka new_source Vznik a správu matriky má na starosti vždy nějaký správní útvar a v něm určitá osoba. Tito tvůrci a správci (původci)jsou zaznamenány v této tabulce. Tabulka new_source_comm Jedná se o relační tabulku, která má dva významy: Definuje, pro které obce z tabulky new_obce zaznamenává události původce z tabulky new_source. Definuje, kterých obcí z tabulky new_obce se daná matrika z tabulky new_registry týká. Tabulka new_registry Obsahuje jednotlivé matriky. Z tabulky new_source je jí přiřazen její původce. Prostřednictví tabulky new_source_comm je určeno, kterých obcí se týká. Stránka 16 z 20

8.2 Use-Case: Drupal HDV DRUPAL HDV Zobrazení databáze Údržba databáze Badatel Údržba systému Archivář Administrátor Stránka 17 z 20

8.3 ERA Diagram: Struktury Drupalu 7 Stránka 18 z 20

8.4 ERA Diagram: Redukovaná struktura tabulek databáze Acta Publica Stránka 19 z 20

9. Dodatek C: Seznam úkolů 1) Jednorázový import obcí ze zdroje, který je ve formátu.xls 2) Jednorázový import kronik ze zdrojů, které jsou ve formátu.xls 3) Import základních dat (obce, matriky) z databáze Acta Publica 4) Redukce, chyb, kontrola konzistence, odstranění duplicity 5) Import veškerých dat z databáze Acta Publica 6) Celkové odladění, kontrola chyb, konzistence, odstranění duplicity Třetí iterace Čtvrtá iterace Pátá iterace Šestá iterace Sedmá iterace Import kronik z xls dokumentů Import obcí a matrik z dat. Acta publica Import dat z databáze Acta publica Dokončení importu dat Import obcí z xls dokumentu Import obcí z databáze Acta publica Kontrola a odstranění chyb, duplicity Kontrola a odstranění chyb, duplicity Kontrola a odstranění chyb, duplicity 03.04.2012 10.04.2012 24.04.2012 02.05.2012 09.05.2012 15.05.2012 Čas LEGENDA: VELMI VYSOKÁ PRIORITA VYSOKÁ PRIORITA STŘEDNÍ PRIORITA Stránka 20 z 20