VŠB - Technická univerzita Ostrava Fakulta elektrotechniky a informatiky Katedra informatiky

Transkript

1 VŠB - Technická univerzita Ostrava Fakulta elektrotechniky a informatiky Katedra informatiky Informační systém skautského střediska Loštice Bakalářská práce 2005 Ladislav Rozsíval

2 Prohlašuji, že jsem tuto diplomovou práci vypracoval samostatně. Uvedl jsem všechny literární prameny a publikace, ze kterých jsem čerpal. V Ostravě 9. května

3 Rád bych na tomto místě poděkoval všem, kteří mi s prací pomohli, protože rady a získané informace byly potřebné a při tvorbě jsem je využil.

4 Abstrakt V úvodu se zabývám co je to skautské středisko. Popisuji jeho organizační strukturu a princip fungováni. Dále analyzuji požadavky, které byly od výsledného informačního systému žádány od osob, které jej budou využívat a pracovat s ním. Po získání všech potřebných údajů jsem se zabýval datovou a funkční analýzou. V datové analýze popisuji jednotlivé tabulky databáze, atributy a vztahy mezi nimi. Strukturu databáze popisuji v datových slovnících, vazby mezi tabulkami jsou zobrazeny v E-R diagramu. Ve funkční analýze popisuji akce, které informační systém umožňuje, pomocí seznamu akcí a reakcí. V modelu jednání definuji, kdo má k jednotlivým akcím přístup. V minispecifikacích je popis jednotlivých akcí, které IS vykonává. V závěru funkční analýzy uvádím, jakým způsobem jsem vyřešil práva přístupu v rámci IS. Poté seznamuji jaké technologie jsem při implementaci systému použil. Klíčová slova: informační systém, skautské středisko, oddíl, člen, atribut, tabulka, objekt Abstract In introduction I write what the scout centre is. I describe organizational structure and principle of function. Then I analyze requirements, which persons,which will use and work with final informative system, ask for it. I make data and functional analyse after I have all needed specifications. In data analyse I describe each table of database, attributes and relationships among them. I describe structure of database in data dictionary, relationship among tables are displayed in Entity Relationship diagram. In functional analyse I describe action, which IS provides, in list of action and reaction. In model of act I define, who has access to single action. In is single action description, which IS execute. In the end of function analyse I show how I settle a matter of access right to IS. After it I introduce technology, which I employ in implementation of IS. Keywords: information system, scout centre, division, member attribute, table, object

5 Seznam použitých zkratek a symbolů E-R Entity Relationship HTML Hyper Text Markup Language MySQL My Structured Query Language PHP Profesional Home Pages CSS Cascading Style Sheets int proměnná Integer blob blok binarních dat IS informační systém fg fotogalerie IO integritní omezení PSC poštovní směrovací číslo

6 OBSAH 6 Obsah 1 Úvod 7 2 Specifikace požadavků Skautské středisko Informační systém pro koho? (externí schémata) Podrobné shrnutí částí systému pro jednotlivé skupiny Podrobné zadání evidovaných údajů Evidované vztahy Datová analýza Seznam tabulek a jejich atributů (lineární zápis) Funkční závislosti E-R diagram Datový slovník Funkční analýza Seznam akcí a reakcí Kontextový diagram Model jednání Minispecifikace Systém práv v IS Použité technologie 47 6 Závěr 50 7 Literatura 51 Přílohy 51 A Uživatelská příručka 52 A.1 Požadavky A.2 Přihlášení A.3 Hlavní menu

7 1 ÚVOD 7 1 Úvod V této práci popisuji proces vývoje informačního systému určeného pro skautské středisko. Tento vývoj má několik základních částí. Na začátku tvorby každého informačního systému je třeba nejprve specifikovat požadavky na něj kladené osobami, které jej budou využívat a pracovat s ním. Po specifikaci požadavků bude provedena datová a funkční analýza. Datová analýza bude obsahovat návrh struktury databáze a jednotlivých tabulek. Dále popis vazeb mezi jednotlivými tabulkami a podrobný popis všech atributů tabulek (údajů o objektu, které nás zajímají z hlediska evidence). Při specifikaci požadavků byly určeny akce, na které by IS měl být schopen reagovat a vykonat při nich určenou operaci. Funkční analýza tedy bude obsahovat seznam všech akcí a reakcí, které bude IS při nich muset vykonávat. Jak už jsem uvedl, IS bude využíván více lidmi a proto bude následovat popis, kdo a které funkce bude moci používat. Tvůrce systému by měl vědět, jaký bude princip činnosti jednotlivých funkcí systému. Ty proto budou podrobně popsány v minispecifikacích. Po provedení analýz získáme všechny informace a návrhy, které jsou potřeba pro následnou implementaci daného IS. Před implementací ještě musíme rozhodnout, jaké prostředky k tomu hodláme použít. Všechny tyto technologie, využité v práci, budou popsány v závěrečných částech práce.

8 2 SPECIFIKACE POŽADAVKŮ 8 2 Specifikace požadavků 2.1 Skautské středisko Co je skautské středisko a jak funguje? Základní organizační jednotkou Junáka jsou střediska, která sdružují oddíly a kluby dospělých - oldskautů a zodpovídají za ně. Činnost každého střediska zajišt uje středisková rada volená střediskovým sněmem. Středisko poskytuje oddílům právní a finanční záštitu a také další zázemí potřebné pro dobré působení oddílů. Hlavní výchovná činnost se soustřed uje do oddílů. Oddíl se zpravidla dělí do družin. Během roku se oddíly i družiny scházejí na pravidelných schůzkách. Činnost oddílu se však nesoustřed uje jen do klubovny, v průběhu skautského roku do ní patří jedno i vícedenní výpravy do okolí i do vzdálenějších míst. Vyvrcholením celoroční činnosti oddílu jsou letní tábory trvající nejméně dva až tři týdny. Skautskou družinu vede starší a zkušenější chlapec či dívka, tzv. družinový rádce. Rádcové družin a jejich zástupci, podrádcové, v čele s vedoucím oddílu tvoří oddílovou radu zajišt ující chod oddílu. Každý ze členů má možnost podílet se na tvorbě programu a utvářet život oddílu. Vedení oddílu je svěřeno do rukou dospělým vůdcům. Takže všechny funkce, které se vyskytují ve středisku a jeho částech jsou: Střediskové funkce : Vůdce střediska, Zástupce vůdce střediska, Hospodář, Tiskový zpravodaj, Dívčí výchovný zpravodaj, Chlapecký výchovný zpravodaj Oddílové funkce : Vůdce oddílu, Zástupce vůdce oddílu Družinové funkce : Rádce družiny, Podrádce družiny Nezávislé funkce (nezávisí na typu oddílu) - Kronikář, Nástěnkář, Pokladník, Člen Členové oddílu můžou skládat a plnit různé odborky, odbornosti, stupně, zkoušky nebo se zúčastnit různých kurzů, škol nebo školení. Odbornost je jeden druh lidské činnosti, jehož znalosti se skauti snaží naučit (např. Astronomie, Geologie,Zdravověda, ). Úroveň znalostí v dané oblasti určuje stupeň odbornosti, který člen v dané oblasti dosáhl. Odborka je souhrn několika odborností, které si jsou blízké (např. odborka technik se skládá z odbornosti počítače, rádiové spojení a elektroniky). Zkoušky jsou např. čekatelské nebo vůdcovské, které musí mít každý vůdce oddílu. Stupně v podstatě ukazují stupeň skautských znalosti a dovedností člena a mají tři úrovně stupně znalostí. Každý člen musí během prvních několik měsíců splnit nováčkovskou zkoušku, která je podmínkou jeho členství ve středisku a je první úrovní stupňů. Další dvě jsou I. Stupeň a II. Stupeň. Mezi kurzy a školení patří různé Lesní kurzy, lesní školy, rádcovské školy apod. Záleží vždy na konkrétním středisku a oddíle jakých kurzů se jeho členové zúčastňují a jaké odborky apod. plní. Z popisu struktury a činnosti skautského střediska vyplývají objekty, které bude muset vytvářený IS evidovat. Takovými objekty budou určitě členové střediska, oddíly,akce, jednotlivé funkce a stupně, dokumenty apod. Pojem evidence dat, což je hlavní účel IS,

9 2 SPECIFIKACE POŽADAVKŮ 9 znamená udržovat o skupinách objektů přehled, údaje o nich mít vhodně uspořádány, aby se v nich údaje dobře vyhledávaly, v případě potřeby opravovaly a doplňovaly, někdy počítaly údaje nové, z původních odvozené, vytvářely různé výsledné přehledné tabulky apod. Bližší popis evidovaných dat bude uveden poté, co na základě požadavků všech skupin uživatelů, získáme jejich požadavky na IS. Ideální zadání by mělo být úplné, jednoznačné, přesné, bezesporné. Ovšem zadavatel většinou není profesionální analytik a neumí zadání takto formulovat. Proto jsem během návrhu musel neustále komunikovat se zadavateli práce, aby se případné nejasnosti vyjasnily. 2.2 Informační systém pro koho? (externí schémata) IS je používán obvykle řadou uživatelů, přičemž každý z nich od něj má jiné očekávání a požadavky na jeho služby. Pohledy jednotlivých uživatelů na databázi IS nazýváme externí schémata. Při zadání se obvykle vychází z požadavků jednotlivých uživatelů, tedy z externích schémat. Proto aby výsledný informační systém sloužil svému účelu a byl hojně navštěvován a využíván, musíme si na začátku položit otázku, jakou skupinu lidí zamýšlíme oslovit a kdo bude se systémem pracovat. Tuto odpověd mít pak při tvorbě systému neustále na paměti! Na základě těchto požadavků jednotlivých externích schémat následně specifikujeme konkrétní požadavky na celý systém, které vzniknou jejich sjednocením. Existuje několik skupin potencionálních návštěvníků informačního systému: Nečlenové či rodiče, hledající informace o skautském oddíle nebo středisku - Sem řadíme ty uživatele, kteří k oddílu nemají žádný přímý vztah, ale hledají informace o něm, případně o skautingu obecně. Typickým příkladem může být rodič, který hledá ve svém okolí vhodný oddíl pro své potomky. Skauti z jiných oddílů: Sem řadíme ty uživatele, kteří k oddílu nemají žádný přímý vztah, ale vědí co si pod pojmem skauting a skautské středisko představit. Většinou nenavštěvují stránky pravidelně, ale v případě potřeby jim snadno poslouží ke komunikaci a získaní potřebných informaci Členové představovaného oddílu nebo střediska, případně jejich rodiče. U této skupiny předpokládáme, že má k oddílu nějaký vztah, něco o něm ví a bude se na stránky vracet např. kvůli aktuálním informacím o výpravách, táborech, bodování apod. Vedoucí oddílu nebo střediska, popřípadě členové s nějakou funkcí. U této skupiny uvažujeme že se přímo podílí na tvorbě programu, tudíž budou využívat informační systém jako pomůcku, která jim usnadní informování členů a vůbec veřejnosti o činnostech oddílů. A dále jim pomůže při administraci, spravování oddílů a evidenci potřebných informaci o členech apod. Po rozdělení uživatelů systému do těchto skupin jsem navrhl, jaké informace konkrétně budou zobrazovány v části systému určeného pro tyto čtyři skupiny.

10 2 SPECIFIKACE POŽADAVKŮ 10 Pro první skupinu nečlenů bude vhodné udělat stránky obsahově statické, jejichž obsah budeme aktualizovat jen jednou za pár měsíců, informace budou platné delší časový úsek. Jako jsou například informace o typu oddílu, jeho historie, kontakt na vůdce, termíny schůzek apod. U této skupiny platí základní pravidlo, že je stránky musí upoutat, jelikož do této skupiny patří noví návštěvníci, které když stránky nezaujmou znovu se na ně nevrátí. Na úvodní stránce by mělo být návštěvníkovi jasné, co kde najde, jak to najde, co má dělat, když to nemůže najít apod. Je nutné mít na paměti, že potencionální návštěvník vůbec nemusí tušit, co je to družina, výpravy apod. Informace by měli být jasné hned na první pohled, protože nelze spoléhat na to, že návštěvník bude stránky nějak dlouze zkoumat a prohledávat. Pro druhou skupinu skautů bude potřeba vytvořit stránky obsahově dynamické, které jim umožní snadnou komunikaci se střediskem nebo členy střediska. V informačním systému budou vyhledávat informace o konkrétních osobách, přijdou jim vhod různé nápady a tipy na hry, případně nabídky ke spolupráci mezi středisky, oddíly případně pouze členy (výměně tábořišt apod.). Pro tuto skupinu budou asi nejdůležitější kontakty na členy, informace o konaných akcích pro veřejnost nebo jiné akce střediska, a také samozřejmě komunikační prostředky jako je fórum, umožňující jim snadno a rychle komunikovat se členy střediska. Pro třetí skupinu členů bude potřeba vytvořit obsahově dynamické stránky, jejichž obsah bude záviset na činnosti oddílu. Tato část IS může splňovat vhodně funkci komunikačního nástroje v rámci oddílů a střediska. Měla by členům poskytovat informace o plánovaných akcích, umožnit jim se na ně přihlásit, mít možnost snadno získat aktuální stav oddílového bodovaní apod. Dále členy určitě bude zajímat jak např. byla proběhlá akce nebo i obyčejná schůzka okomentována a zdokumentována. Tudíž do této části stránek je vhodné včlenit možnost členům komentovat akce a vhodným způsobem zobrazovat kroniku nebo fotogalerii v závislosti na materiálu, který byl na akci pořízen a zaznamenán. Pro čtvrtou skupinu vedoucích bude potřeba vytvořit systém, který jim umožní snadno zadávat nové informace o oddílech, zakládat nové akce, přidávat nové členy, mít možnost editovat informace o stávajících členech, vést u členů evidenci o jejich funkcích ve středisku nebo jeho částech a dále vést záznamy o tom, kdo splnil jaké zkoušky, odborky nebo stupně. Samozřejmě musí být umožněno tyto informace jednoduše zadávat a spravovat. Je logické, že výsledný informační systém musí vyhovovat všem skupinám a pro každou ze skupin musí být jimi požadované informace a funkce snadno dostupné. Je však na místě poněkud upřednostnit vedoucí oddílů nebo střediska, nebot jsou zadavateli práce a jim hlavně by měl systém ulehčit práci. Zároveň je nutné kvalitně informovat a upoutat rodiče, zamýšlející přihlásit své dítě do skautského oddílu, a vůdce jiných středisek nebo oddílů oddílu, kteří se snaží navázat kontakt s naším střediskem, jelikož jak nový členové tak nový spolupracovníci a pomoc je potřeba. Takto je již přibližně definováno, co všechno by asi informační systém, pro kterou skupinu měl obsahovat. Takže dále podrobněji popíšu jednotlivé části systému určené daným skupinám, pro které informační systém vzniká. Jak by konkrétně měli vypadat a jaké funkce obsahovat.

11 2 SPECIFIKACE POŽADAVKŮ Podrobné shrnutí částí systému pro jednotlivé skupiny Společné části systému Než se dostaneme k popisu jednotlivých částí pro jednotlivé skupiny, je vhodné napsat pár informací o částech systému, které budou sloužit pro všechny skupiny možných uživatelů systému. Každá skupina samozřejmě využívá dané části systému jinak, proto je zde popíši obecně a později pak v případě nutnosti u jednotlivých skupin podrobněji vysvětlím. Ted už konkrétně k těmto částem. Almanach - zde bude popsána historie střediska a jednotlivých oddílů. Nějaké informace o počátcích skautingu vůbec, začátky skautingu v okrese, v našem městě apod. Dále se zde budou objevovat výroční zprávy, které se od roku 1990 s menšími přestávkami píší. Fórum - Bude sloužit jako komunikační prostředek v rámci střediska, mezi naším střediskem a ostatními středisky, nebo mezi naším střediskem a širokou veřejností. Měla by zde byt možnost anonymního psaní příspěvku tak i psaní příspěvků zaregistrovaným uživatelům nečlenům střediska tak i samozřejmě členům střediska. Fotogalerie - jak již název říká bude se jednat o seznam fotogalerií z jednotlivých akcí a také všechny dochované fotky z celé historie střediska seřazené podle zvoleného kritéria. Fotogalerie umožňuje členům zdokumentovat, jak probíhala akce a fotky případně umístit do kronik nebo nečlenům dává možnost prohlédnout si, jak vypadá atmosféra na akci, v jakých podmínkách akce probíhají a co se na nich děje. Akce - Tato část bude poskytovat informace o plánovaných akcích. Sice se logicky zdá, že by tato část měla být určena pouze pro členy střediska nebo konkrétního oddílu, který akci pořádá, ale akce muže být pro širokou veřejnost, takže je důležité, aby kdokoliv měl možnost přístupu k informacím o akcích, protože se jich např. chce zúčastnit nebo se jen přijít podívat, aby viděl, jak akce střediska probíhá. Měla by zde být možnost se jak přihlásit i odhlásit. Dokumenty - Tato část bude obsahovat různé dokumenty střediska nebo oddílů. Můžou se zde objevit zápisy o proběhlých akcí, výsledky jednotlivých měsíčních bodování nebo nachystané předlohy pro registraci člena apod. Členové střediska zde budou mít k dispozici zápisy ze střediskové rady. Novinky - Tato část bude poskytovat informace o novinkách týkajících se střediska. Můžou se zde objevit odkazy na aktuální akce, informace o náhlé změně termínu schůzek, založení nové diskuze na fóru, přidání nové fotogalerie z proběhlé akce, nové informace pro veřejnost a další aktuální informace. Členové - Tato část bude obsahovat seznam členů oddílů a rozdělených do jednotlivých oddílů a družin. Dále informace o stupních, které splnili.

12 2 SPECIFIKACE POŽADAVKŮ Část pro skupinu nečlenů Ta by měla být co nejstručnější a při tom podávat ucelenou informace o středisku a skautingu obecně. Měla by tedy obsahovat následující části: Informace o Nás - zde bude popsáno, kdo vlastně skautské středisko je, kde se nachází klubovna, popřípadě popis cesty k ní, kdy se konají schůzky jednotlivých oddílů a družin a informace tohoto typu. Jak už jsem uvedl do této skupiny patří převážně rodiče nebo přímo konkrétní zájemci o členství, a proto by měli mít možnost dozvědět se i o pořádaných akcích, aby věděli, jaký mají akce program. Pokud neměli možnost se na akci přijít podívat osobně, můžou zjistit, jak probíhala, v některé části dokumentující proběhlou akci. At už ve fotogalerii, diskuzi na fóru nebo zápisu v dokumentech tykající se dané akce. Kontakty - na vedoucí oddílů nebo vůdce střediska. Pro snadnou komunikaci se střediskem a díky nim možnost případného získání podrobnějších informaci. Ke komunikaci by mělo dopomáhat také fórum, kde díky možnosti psaní příspěvků i anonymním uživatelům se může kdokoliv zeptat na cokoliv. Skauting - Do této části je vhodné dodat i něco málo informací o Skautingu obecně v nepříliš rozsáhlém dokumentu, z kterého by ale zároveň získal návštěvník pokud možno ucelenou představu co skauting nabízí, garantuje a zajišt uje pro své členy nebo pro širokou veřejnost Část pro skupinu skautů Ta by měla logicky využívat část pro nečleny a to konkrétně Informace o Nás a Kontakty. Navíc je ale nejspíš bude i zajímat, kdo konkrétně je členem našeho střediska nebo jeho části. Takže pro tuto skupinu zavedeme také: Členové - kde bude seznam členů oddílů a informace o nich a jejich rozdělení do jednotlivých oddílů. Dále informace o stupních, které splnili. Akce - tato skupina návštěvníků bude v této sekci hledat akce konané pro veřejnost nebo společné akce určené pro více středisek. Z toho vyplývá, že u akcích budeme muset rozdělovat pro koho se dané akce konají. Zda jen pro členy, nebo pro skauty nebo pro širokou veřejnost. Měla by zde být možnost se na akce přihlásit i nečlenům střediska, aby tímto mohli naznačit, že se chtějí účastnit a pořadatelé akce z našeho střediska tak věděli, s kým můžou počítat Část pro skupinu členů Ta bude, jak už jsem výše uvedl poskytovat členům střediska ucelené informace o chodu střediska a o činnostech, které jsou v plánu.

13 2 SPECIFIKACE POŽADAVKŮ 13 Akce - kde bude seznam všech akci pořádaných naším střediskem. Musí udávat informace od a do kdy se akce koná, kde se koná, kdo už je přihlášen, jaký je program akce apod. Dále by členové měli mít možnost pořádat vlastní akci. Dokumenty - tato část by členům měla poskytovat možnost najít zde zápisy z proběhlých akcí, různé informační dokumenty o pořádaných školeních nebo jiných akcích v okolí, kterých by se mohl člen skautského oddílu zúčastnit nebo informace o stavu oddílového bodování atd. Fotogalerie - tato část by členům měla poskytovat možnost prohlédnout si fotografie pořízené na akcích at už jenom z důvodu prohlídky, co se všechno nafotilo, nebo zjistit, jak probíhala akce, které se nemohl zúčastnit apod. Fórum - budou členové moci využívat pro různé návrhy, co by se mohlo v oddílech uskutečnit, nebo pro komentovaní jiných návrhů apod Část pro skupinu vedoucích Ta bude samozřejmě shodná s části pro třetí skupinu, protože i vedoucí je z jistého pohledu vlastně jenom člen, a tak se ho týkají všechny činnosti a informace platné pro členskou část. Vedoucí však navíc budou mít možnost administrace a logicky se očekává, že hlavně oni budou přidávat nové informace. V závislosti na právech (rozeberu později) budou mít možnost spravovat jednotlivé části systému, a proto zde obecně uvedu co všechno se bude dat upravovat. Almanach - musí mít možnost přidávat nový záznam za minuly rok nebo jeho část a mít možnost mazat záznamy, které se například mají nahradí jinými apod. Akce - musí mít možnost přidat novou akci. Popřípadě ji upravit pokud se změní nějak termíny akce apod. Měl by mít možnost mazat akci, které se nikdo nechce účastnit nebo smazat akci založenou jiným členem, kterou nepovažuje za vhodnou. Dokumenty - klasicky by měl mít možnost manipulovat se všemi dokumenty (mazat, přidávat) Fórum - měl by mít možnost zakládat nová a mazat stará témata, a mazat příspěvky, které považuje za nevhodné nebo nepatřící na do diskuze střediska. Je nutno mít na paměti, že jeden z účelů webu střediska, je prezentace střediska před veřejností.to by mělo platit ve všech jeho částech a fórum, jako komunikační nástroj, by toto mělo hlavně splňovat. Proto je jistá forma cenzury potřeba a správcové fóra k tomu musí mít potřebné prostředky. Fotogalerie - měla by být možnost mazat nevhodné fotky, přidávat nové fotogalerie a fotky do nich, upravovat stávající a ručit již nepotřebné fotogalerie. Novinky - přidávat nové zprávy a mazat už neaktuální zprávy.

14 2 SPECIFIKACE POŽADAVKŮ 14 Členové - měl by mít možnost v závislosti na svých právech jmenovat do funkcí jednotlivé členy. Dále bude moci přidávat do databáze nové člen, registrovat jejich karty a přidávat informace o splněných stupních atd. 2.4 Podrobné zadání evidovaných údajů V předchozí kapitolách jsem přibližně odvodil, na základě potřeb skautského střediska a lidí, kteří s ním přicházejí do styku, jaké části by informační systém měl mít. Nyní je potřeba přesně určit jaké informace se v konkrétních částech systému mají evidovat a uchovávat. Z těchto informací pak následně můžeme odvodit tabulky a jejich atributy. ČLENOVÉ Login a Heslo - což je přihlašovací jméno a heslo do systému. Křestní jméno, Příjmení, Pohlaví a Datum narození. Přezdívka člena, jak se členovi v oddíle říká. Číslo mobilního telefonu a číslo na pevnou linku, na kterém je člen k zastižení. ová adresa, ICQ číslo člena a osobní internetové stránky člena, pro případ komunikace přes internet. Adresa skládající se z ulice, čísla domu, města a PSČ trvalého bydliště člena. ODDÍLY Název oddílu nebo družiny je jednoznačný v rámci střediska nebo oddílu. Oficiální název oddílu používaná v oficiálních dokumentech. Nadřazený je oddíl nebo středisko, do kterého nový oddíl patří. Pokřik oddílu není nutné zadat. Znakje obrázek prezentující oddíl. Oddíl dál může mít vlastní fotogalerii, oficiální rok založení, diskusi na fóru o daném oddílu, jeho akcích, činnostech,.programu schůzek apod. FOTOGALERIE Název fotogalerie, jméno dané fotogalerie. Nadřazená fotogalerie je taková, do které daná fotogalerie patří. AKCE Název akce, což je její, pokud možno, jednoznačné pojmenování. Místo konání, které určuje lokalitu, kde se akce koná (klubovna,město, nebo nějaké vetší území v případě nějaké výpravy). Datum začátku a konce akce, u jednodenních akcí čas začátku akce a předpokládaný čas konce akce, u vícedenní akce je to doba srazu před odjezdem a předpokládaný den a čas návratu (pouze orientační doba). Kdo a který oddíl danou akci pořádá. Pro koho se akce koná, akce může být pouze pro členy střediska, družiny nebo oddílu, který akci pořádá nebo může být akce pro kohokoliv, tedy i pro veřejnost.

15 2 SPECIFIKACE POŽADAVKŮ 15 Popis - doplňující informace k akci, informace co je třeba mít sebou, způsob dopravy, program akce a pod. Popřípadě umožnit diskusi na foŕu o akci. ALMANACH Nadpis kapitoly almanachu, který naznačuje o čem v dané kapitole bude řeč. Rok, který říká k jakému roku se daný zápis vztahuje, k jednomu roku může být více zápisů, ale také žádný. Konkrétní text, který popisuje danou kapitolu almanachu. DOKUMENTY Název, jméno daného dokumentu. Popis, určuje o čem dokument je a čeho se tyká. Druh, definuje druh dokumentu(tiskopis, zápis z jednání,...). FUNKCE Název, jméno dané funkce. Ke kterému typu oddílu se funkce vztahuje (středisko, oddíl, družina nebo libovolný). Práva, které jsou od dané funkce odvozeny. STUPEŇ Název, oficiální název stupně. Zkratka, oficiální zkratka stupně. FORUM Zpráva - vzkaz, který má být zaznamenán. Kdo a Kdy - danou zprávu vložil. Příspěvek, do kterého nebo pod který daný příspěvek patří. Kategorie popisuje název skupin fora. 2.5 Evidované vztahy Mezi objekty může v realitě existovat nějaký vztah, který nás zajímá a chceme jej také evidovat. V předchozích kapitolách jsem se již zmínil o některých vztazích, které by měl vytvářený informační systém evidovat a proto je zde všechny vypíši. Vztahy se budou popisovat vždy jménem vztahu, za kterými je v závorce uveden seznam typů objektů, které do daného vztahu vstupují, a slovním popisem. Vztahy, které se budou evidovat tedy jsou : SLOŽIL (STUPEN, CLEN) - kdo má složené jaké stupně ÚČASTNÍ SE (AKCE, CLEN) - účast členů na akcích DĚLÁ (ODDILY,FUNKCE, CLEN) - kdo má jakou funkci v jakém oddíle MÁ (AKCE, FOTOGALERIE) - akce je zobrazena na fotogalerii POPISUJE (FORUM, AKCE) - akce je diskutována na jejím fóru OBSAHUJE (FOTOGALERIE, OBRAZEK) - fotogalerie je složená z obrázků

16 2 SPECIFIKACE POŽADAVKŮ 16 JE NA (CLEN, OBRAZEK) - člen je vyfocen na fotce VLASTNÍ (ODDILY, FOTOGLERIE) - oddíl má svou fotogalerii NAVRHUJE (ODDILY,FORUM) - návrhy jsou podávány na fóru POŘÁDÁ (ODDILY,AKCE) - oddíl je pořadatelem akce ZALOŽIL (CLEN, AKCE) - člen je pořadatelem akce VLOŽIL (CLEN, FORUM) - člen vložil příspěvek do fóra

17 3 DATOVÁ ANALÝZA 17 3 Datová analýza 3.1 Seznam tabulek a jejich atributů (lineární zápis) V této kapitole vyjmenuji seznam všech tabulek a jejich atributů, tak jak jsem je navrhl na základě podrobného zadání. Podrobný popis je deklarován v datovém slovníku. LIDE (id clen, fotka, login, heslo, pohlavi, prezdivka, jmeno, prijmeni, narozen, mobil, telefon, , web, icq, adresa, mesto, psc, zareg, stav) AKCE (id akce, nazev, popis, misto, oddil, od, do, zalozil, druh, forum) FUNKCE (id fun, nazev, prava, ceho, symbol) FOTOGALERIE (id fot, nazev, patri, vlozeno) OBRAZEK (id obr, foto, nazev, typ, velikost) STUPEN (id stup, nazev, zkratka) HISTORIE (id his, nazev, rok, soubor) ODDILY (id od, patri, nazev, oficial, zalozen, fotogalerie, pokrik, znak, forum) FORUM (id for, kdy, patri, autor, zprava, kategorie, master, aktivni) DOKUMENTY (id dok, nazev, popis, druh, soubor, typ, velikost, vlozeno) DELA (id fun, id clen, id od) FOTO (id fot,id obr) UCAST (id akce, id clen) SLOZENO (id clen, is tup) LOG (kde,kdy,ip,co) NOVINKY (id nov, kdo, nazev, text, kdy, grafika) NAVSTEVNOST (kde,kdy,ip) NAVSTEVY (kdo,kdy,ip) 3.2 Funkční závislosti id clen - fotka, login, heslo, pohlavi, prezdivka, jmeno, prijmeni, narozen, mobil, telefon, , web, icq, adresa, mesto, psc, zareg, stav id akce - nazev, popis, misto, oddil, od, do, zalozil, druh, forum id fun - nazev, prava, ceho, symbol id fot - nazev, patri, vlozeno id obr - foto, nazev, typ, velikost id stup - nazev, zkratka id his - nazev, rok, soubor id od - patri, nazev, oficial, zalozen, fotogalerie, pokrik, znak, forum id for - kdy, patri, autor, zprava, kategorie, master, aktivni id dok - nazev, popis, druh, soubor, typ, velikost, vlozeno id nov - kdo,nazev,text, kdy, grafika

18 3 DATOVÁ ANALÝZA E-R diagram Pro popis logické struktury dat se často používá E-R diagram, který popisuje objekty a jejich vazby pomocí jejich grafického zobrazení, což bývá velmi názorné a vede k lepšímu pochopení struktury databáze. Každý obdélník s textem uvnitř značí jednu tabulku v databázi, spojnice mezi nimi značí vztahy, číslo na konci každé spojnice definuje kardinalitu vztahu a kolečka značí povinnosti členství ve vztahu. Atributy jednotlivých tabulek pro přehlednost E-R diagramu zde nepopisuji. Povinnost členství - do některých vztahů musí vstupovat každý objekt, do jiného vztahu ne. 3. Definujeme E-R diagram tedy dva druhy členství ve vztahu: povinné (obligatorní) a nepovinné (fakultativní). Pro popis logické struktury dat se často používá E-R diagram, který popisuje objekty a jejich vazby pomocí jejich grafického zobrazení, Graficky což bývá velmi povinnost názorné a vede členství k lepšímu ve pochopení vztahu struktury v E-R databáze. diagramu zaznamenává kolečkem Každý obdélník plným, s textem nepovinnost uvnitř značí jednu kolečkem tabulku v databázi, prázdným. spojnice mezi nimi značí vztahy, číslo na konci každé spojnice definuje kardinalitu vztahu a kolečka značí povinnosti členství ve vztahu. Atributy jednotlivých Kardinalita tabulek pro přehlednost vztahu E-R je důležitým diagramu zde nepopisuji. IO, protože z něj plyne řada důsledků jak v datové, tak funkční analýze. Základní vztah je 1:1, kdy každý objekt z první množiny objektů je Povinnost členství - do některých vztahů musí vstupovat každá entita množiny entit, do jiného vztahu ne. spojen vztahem Definujeme tedy s nejvýše dva druhy členství jedním ve vztahu: objektem povinné (obligatorní) druhé množiny. a nepovinné (fakultativní). Nejčastějším Graficky se typem vztahu však je 1:N, povinnost kdy členství každý ve vztahu objekt v E-R zdiagramu první zaznamenává množiny kolečkem je spojen plným, vazbou nepovinnost skolečkem žádným prázdným. či více objekty z druhékardinalita množiny, vztahu ale je důležitým každýio, objekt protože z něj druhé plyne řada množiny důsledků jak jev datové, spojena tak funkční vazbou analýze. nejvýše Máme-li s jedním definován binární vztah, má jeden ze tří poměrů: objektem z první množiny. Pokud je vztah M:N, kdy každý objekt z první množiny tedy 1. vztah 1:1, kdy každý objekt z první množiny objektů je spojen vztahem s nejvýše jedním objektem druhé může mít vztah množiny. k N objektům z druhé množiny a naopak každý objekt z druhé množiny 2. vztah 1:N, kdy každý z první množiny je spojen vazbou s žádným či více objekty z druhé množiny, může mít ale každý kobjekt N objektům z druhé množiny je spojena množiny, vazbou nejvýše jes třeba jedním objektem tento vztah z první množiny. rozložit na dva vztahy 1:N pomocí 3. vztah vazební M:N, každý tabulky. objekt z první množiny tedy může mít vztah k N objektům z druhé množiny a naopak každý objekt z druhé množiny může mít vztah k N objektům z první množiny. STUPEN 1 co složil N SLOZENO N kdo složil N 1 se účastní N N je přihlášen AKCE UCAST pořádá založil 1 má vlastní 1 1 kde dělá ODDILY 1 navrhuje 1 popisuje vložil FOTOGALERIE FORUM N 1 obsahuje 1 1 N 1 1 LIDE 1 1 kdo dělá N DELA N co dělá 1 FUNKCE N FOTO N skládá 1 1 OBRAZEK je na

19 3 DATOVÁ ANALÝZA Datový slovník Datový slovník přesně specifikuje strukturu jednotlivých tabulek a důkladně popisuje jednotlivé jejich atributy. U atributů udává jejich název, jakého jsou typu, jakého maximálního rozsahu můžou nabývat, integritní omezení, které jsou na ně kladena, zda daný atribut může být nulový a popřípadě nějakou poznámku k němu. Integritní omezení je obecně každá doplňující informace o objektech, atributech a vazbách, která plyne z reality a kterou je nutno brát v úvahu v IS (uvádí, jak zabezpečit shodu reality a databáze, tedy integritu databáze) Tabulka LIDE Tato tabulka se zabývá evidencí lidí. To znamená členů střediska, současně však i zaregistrovaných uživatelů, kteří systém navštěvují, ale nejsou členy. S ID CLEN číslo 1 je uložen HOST, což je ekvivalent nepřihlazeného uživatele. Název Typ(rozsah) IO null Poznámka ID CLEN int(5) Ne Primární klíč FOTKA int(5) Ano Číslo z tab. OBRAZEK LOGIN varchar(50) min 5 zn. Ne Přihlašovací jméno HESLO varchar(200) min 5 zn. Ne Přihlašovací heslo (MD5) POHLAVI int(1) Ano Pohlaví: 1-žena, 0-muž PREZDIVKA varchar(50) Ano Přezdívka člena JMENO varchar(15) min 3 zn. Ano Křestní jméno PRIJMENI varchar(15) min 3 zn. Ano Příjmení NAROZEN Date Ano Datum narození TELEFON varchar(9) Ano Bez předvolby země MOBIL varchar(9) Ano Bez předvolby země varchar(50) neco@neco Ano ová adresa WEB varchar(50) Ano Osobní webová stránka ICQ varchar(15) Ano ICQ číslo uživatele ADRESA varchar(25) Ano Ulice a číslo domu MESTO varchar(25) Ano Město PSC varchar(5) Ano Směrovací číslo ZAREG int(12) Ne Počet sekund od :00:00 hod STAV char(1) Ne Stav karty (R,A nebo N) primárním klíčem pro tuto tabulku jsem si zvolil ID CLEN, což je kladné celé číslo, které se automaticky generuje na základě již uložených záznamů v tabulce (automaticky se inkrementuje). V této tabulce je dále jednoznačný také LOGIN uživatele, ale ten jsem jako primární klíč nezvolil proto, že jsem chtěl dát uživatelům možnost měnit přihlašovací jméno do informačního systém a toto je právě uložené v atributu LOGIN. V případě, že

20 3 DATOVÁ ANALÝZA 20 by LOGIN byl primární klíč a uživatel by ho měl možnost měnit, ztratila by se nám vazba mezi jinými tabulkami, protože v těch by byl uložen LOGIN předcházející. V případě, že bychom chtěli tuto vazbu zachovat museli bychom projít všechny tabulky databáze a předcházející LOGIN nahradit změněným, což by byla hodně náročná databázová operace a proto jsem jako primární klíč raději upřednostnil ID CLEN. Atribut FOTKA vykonává vztah JE NA a je to klíč tabulky OBRAZEK odkazující na záznam, na kterém je uložena fotka daného člena. Jak už jsem zmínil atribut LOGIN odpovídá přihlašovací jménu uživatele do systému. Je převedeno na velká písmena, aby bylo při registraci snadněji zjistitelné zda je daný login již registrován nebo ne. Pro správné přihlášení musí být zadáno i správné přihlašovací heslo do systému, které je pro každého člena uloženo v atributu HESLO, který je zašifrován pomocí funkce MD5. Atribut POHLAVI určuje zda je člen muž nebo žena. Pokud je muž je tento atribut roven nule, pokud je roven 1 jedná se o ženu. Jiná hodnota tohoto parametru není povolena. Přezdívku člen mít muže, ale taky nemusí, proto je její znění uloženo v atributu PREZDIVKA, který může být nulový. Jméno a příjmení člena je uchováváno v atributech JMENO a PRIJMENI. Atribut NAROZEN značí datum narození člena. Telefonické kontakty na členy jsou zaznamenány v atributech TELEFON a MOBIL, v kterých je evidováno pouze číslo v rámci ČR tzn. že není počítáno s předvolbou +420 apod. Internetové kontakty jsou uloženy v atributech , WEB a ICQ. musí být vyplněn správně, jelikož je prováděna kontrola jeho správného zadání. WEB je zadán v úplné formě tedy včetně Poštovní kontakt na člena uchovávám v atributech ADRESA, MESTO a PSC, které nejsou nijak kontrolovány. Dále jsem do tabulky doplnil dva atributy, které nebyly uvedeny ve specifikacích zadavatelů. Prvním z nich je atribut ZAREG, což je pouze informace o tom, kdy byla daná karta uživatele zaregistrována. Ten nemá žádné vetší opodstatnění, slouží jen k statistice nově zaregistrovaných karet apod. Druhý atribut má větší opodstatnění a je jím atribut STAV. Ten popisuje v jakém stavu karta uživatele je. Může být jen ve třech stavech: R - nově zaregistrovaný, který se může přihlásit, ale nemůže být zvolen do žádné funkce (tzn. nemůže být ani členem!) A - karta uživatele je aktivní, uživatel se může přihlásit a může být volen do funkcí. N - karta je neaktivní, uživatel se nemůže přihlásit ani být volen Tabulka FUNKCE Tato tabulka se zabývá evidencí funkcí, které v středisku nebo jeho částech můžou existovat. Název Typ(rozsah IO null Poznámka ID FUN int(5) Ne Primární klíč NAZEV varchar(30) Ne Název funkce PRAVA varchar(30) Ne Seznam práv, od funkce odvozených SYMBOL int(10) Ano Číslo z tab. OBRAZEK CEHO int(1) Ne Čeho je daná funkce (0,1,2,3)

21 3 DATOVÁ ANALÝZA 21 primárním klíčem pro tuto tabulku jsem si zvolil ID FUN, což je kladné celé číslo, které se automaticky generuje na základě již uložených záznamů v tabulce (automaticky se inkrementuje). Jako primární klíč jsem mohl zvolit také NAZEV, ale ten ve speciálních případech nemusí být jednoznačný, proto jsem pro jistotu zvolil klíčem ID FUN. Přiklad toho co by se mohlo stát. Všechny druhy funkcí, které se v současné době ve středisku, oddílech a družinách vyskytují existují jsou jednoznačné tzn. že daná funkce má jednoznačný název. Ale muže vzniknout případ, kdy vytvářená funkce bude náležet např. jenom oddílu a družině a ne středisku a tak není jiná možnost než vložit dvakrát stejnou funkci jednou pro oddíl a jednou pro družinu. V takovém případě by primárním klíči museli být název funkce ve spojení s druhem funkce. Proto se mi jednodušší zdálo zvolit primárním klíčem id fun. Atribut PRAVA obsahuje řetězec, který se skládá z 30 znaků A nebo N. Znak na každá pozici znamená bud povolení (znakem A) nebo zakázání (znak N) určitého práva. Problematika práv v tomto informačním systému je poněkud složitější budu se jí věnovat ve zvláštní kapitole. Do této tabulky jsem dodal parametr SYMBOL, který obsahuje odkaz na obrázek z tabulky OBRAZEK. Je to nějaký grafický symbol dané funkce, který je zobrazován u člověka, který je do dané funkce zvolen. Atribut CEHO popisuje jakého typu oddílu se daná funkce týká a v kterém tedy může být volena. Je to jednociferné celé číslo a může být jen ve čtyřech hodnotách: 0 - všeobecná, která nezávisí na druhu oddílu a může tedy být volena v jakémkoliv oddílu. Klasickým případem takové funkce je člen. 1 - středisková - funkce ve středisku 2 - oddílová - funkce v oddíle 3 - družinová - funkce v družině Tabulka AKCE Tato tabulka se zabývá evidováním akcí, které středisko nebo jeho části pořádají. Název Typ(rozsah IO null Poznámka ID AKCE int(5) Ne Primární klíč NAZEV varchar(50) Ne Název akce POPIS text Ano Popis akce MISTO varchar(50) Ne Místo konání akce ODDIL int(5) Ano Pořádající oddíl (z tab. ODDIL) OD int(11) Ne Začátek akce - Počet sekund od :00:00 hod DO int(11) Ne Konec akce - Počet sekund od :00:00 hod ZALOZIL int(5) Ne Číslo z tab. LIDE FORUM int(5) Ano Číslo z tab. FORUM GALERIE int(5) Ano Číslo z tab. FOTOGALERIE DRUH varchar(15) Ne Druh akce - pro koho se koná

22 3 DATOVÁ ANALÝZA 22 primárním klíčem pro tuto tabulku jsem si zvolil ID AKCE, což je kladné celé číslo, které se automaticky generuje na základě již uložených záznamů v tabulce (automaticky se inkrementuje). Jiný primární klíč jsem určit nemohl, jelikož všechny ostatní položky tabulky nemusí být jednoznačné v rámci celé tabulky. Každá akce je nějak pojmenována, toto jméno je uloženo v atributu NAZEV. Specifické údaje o akci jako jsou třeba program akce, věci co se na akci mají vzít popřípadě nějaké jiné doplňující informace jsou evidovány v atributu POPIS, který proto může být i nulový, jelikož dané informace jsou nepovinné. Povinné ovšem je definovat prostor nebo budovu, ve které se akce koná. To je uchováváno v atributu MISTO. Atribut ODDIL vykonává vztah POŘÁDÁ a je to klíč tabulky ODDILY odkazující na záznam, na kterém je oddíl, který pořádá danou akci. Každá akce má svůj čas začátku a konce tedy atributy OD a DO. Z důvodu, dle mého názoru, jednoduššího zpracování datumu a času uloženém ve formě počtu sekund od pevně stanoveného času ( :00:00) jsem zvolil tento způsob ukládáni. Oba tyto atributy jsou povinné, musí být smysluplné( nesmí být možnost uložit např ) a konec akce musí logicky následovat až po jejím začátku. Atribut ZALOZIL vykonává vztah ZALOŽIL a je to klíč tabulky LIDE odkazující na záznam, na kterém je člen, který danou akci založil. Atribut FORUM vykonává vztah POPISUJE a je to klíč tabulky FORUM odkazující na záznam, na kterém je fórum týkající se dané akce. Atribut GALERIE vykonává vztah MÁ a je to klíč tabulky FOTOGALERIE odkazující na záznam, na kterém je fotogalerie týkající se dané akce. Jak už jsem se v předchozích kapitolách zmínil každá akce je určena jiným skupinám lidí a tuto skutečnost zaznamenává atribut DRUH. Ten popisuje pro koho je akce určená. Může nabývat 4 hodnot a to těchto : pro veřejnost - akce pro kohokoliv, tím je myšleno jak pro veřejnost tak pro jiná střediska či sdružení. středisková - akce pro členy střediska a jakékoliv jeho části oddílová - akce pro členy oddílu ODDIL, který tuto akci pořádá družinová - akce pro členy družiny ODDIL, který tuto akci pořádá Tabulka UCAST Tato tabulka se zabývá evidencí přihlášených lidí na jednotlivé akce. Název Typ(rozsah IO null Poznámka ID AKCE int(5) Ne Cizí klíč z tabulky AKCE ID CLEN int(5) Ne Cizí klíč z tabulky LIDE rozkládá vztah ÚČASTNÍ SE a obsahuje v sobě vždy primární klíč tabulky AKCE a LIDE Tabulka ODDILY Tato tabulka se zabývá evidencí informací o oddílech a jejich hierarchie v rámci střediska.

23 3 DATOVÁ ANALÝZA 23 Název Typ(rozsah IO null Poznámka ID OD int(11) Ne Primární klíč PATRI int(11) Ne Oddíl, do kterého patří NAZEV varchar(50) Ne Název oddílu OFICIAL varchar(50) Ano Oficiální název POKRIK varchar(250) Ano Pokřik ZALOZEN int(4) Ano Rok založení oddílu ZNAK int(11) Ano Číslo z tab. OBRAZEK FORUM int(5) Ano Číslo z tab. FORUM FOTOGALERIE int(5) Ano Číslo z tab. FOTOGALERIE primárním klíčem pro tuto tabulku jsem si zvolil ID OD, což je kladné celé číslo, které se automaticky generuje na základě již uložených záznamů v tabulce (automaticky se inkrementuje). Atribut NAZEV je sice jednoznačný, ale pouze v rámci jedno oddílu v případě družiny nebo v rámci střediska v případě oddílů. Oficiální název je jednoznačný, ale oficiální název má pouze středisko a jeho oddíly, nikoliv však už části oddílů. Proto jsem jako klíč zvolil ID OD. Atribut PATRI zajišt uje hierarchii a vazbu mezi oddíly. Určuje číslo (ID OD) nadřazeného oddílu tedy oddílu, do kterého patří. Pokuj je hodnota tohoto atributu rovna nule, pak se jedná přímo o středisko. NAZEV popisuje jak se oddílu říká v rámci střediska, ale nemusí to být přímo oficiální název. Ten je uložen v atributu OFICIAL a je používán převážně v oficiálních dokumentech. Atribut FOTOGALERIE vykonává vztah VLASTNÍ a je to klíč tabulky FOTOGALERIE odkazující na záznam, na kterém je fotogalerie daného oddílu. Každý oddíl by měl mít nějaké heslo nebo pokřik, kterým se prezentuje. Ten je uložen v atributu POKRIK, ale je nepovinný. Stejně jako atribut ZALOZEN, který popisuje rok založení oddílu. Ten taky nemusí být přesně znám a proto je nepovinný. Atribut ZNAK je klíč tabulky OBRAZEK odkazující na záznam, na kterém je obrázek, který znázorňuje znak daného oddílu. Atribut FORUM vykonává vztah NAVRHUJE a je to klíč tabulky FORUM odkazující na záznam, na kterém je fórum týkající se dané ho oddílu a jeho činnosti Tabulka DELA Tato tabulka se zabývá evidencí toho, kteří lidé vykonávají jakou funkci v jakém oddíle. Název Typ(rozsah IO null Poznámka id od int(5) Ne Cizí klíč z tabulky ODDILY id fun int(5) Ne Cizí klíč z tabulky FUNKCE id clen int(5) Ne Cizí klíč z tabulky LIDE rozkládá vztah DĚLÁ a obsahuje v sobě vždy primární klíč tabulky FUNKCE, OD- DILU a LIDE.

24 3 DATOVÁ ANALÝZA Tabulka STUPEN Tato tabulka se zabývá evidencí stupňů, odborek a zkoušek, které členové střediska nebo jeho částí můžou plnit. Název Typ(rozsah IO null Poznámka ID STUP int(5) Ne Primární klíč NAZEV varchar(25) Ne Oficiální název ZKRATKA varchar(5) Ne Oficiální zkratka primárním klíčem pro tuto tabulku jsem si zvolil ID STUP, což je kladné celé číslo, které se automaticky generuje na základě již uložených záznamů v tabulce (automaticky se inkrementuje). ID STUP jsem zvolil klíčem z důvodu jednodušší práce než z názvem nebo zkratkou. Tím taky umožníme, že název i zkratka se budou moci měnit, což je výhodnější. NAZEV uchovává oficiální název stupně, zkoušky nebo odborky a ZKRATKA jeho oficiální zkratku Tabulka SLOZENO Tato tabulka se zabývá evidencí toho, kteří členové mají složenou jaký stupeň. Název Typ(rozsah IO null Poznámka ID STUP int(5) Ne Cizí klíč z tabulky STUPEN ID CLEN int(5) Ne Cizí klíč z tabulky LIDE rozkládá vztah SLOŽIL a obsahuje v sobě vždy primární klíč tabulky LIDE a STUPEN Tabulka FOTOGALERIE Tato tabulka se zabývá evidencí fotogalerii a jejich hierarchii. Název Typ(rozsah IO null Poznámka ID FOT int(5) Ne Primární klíč NAZEV varchar(50) Ne Jméno fg PATRI int(5) Ne Číslo fg, pod kterou patří VLOZENO int(11) Ne Čas vložení - počet sekund od :00:00 hod primárním klíčem pro tuto tabulku jsem si zvolil ID FOT, což je kladné celé číslo, které se automaticky generuje na základě již uložených záznamů v tabulce (automaticky se inkrementuje). Jiný primární klíč jsem určit nemohl, jelikož všechny položky tabulky nemusí být jednoznačné v rámci celé tabulky. NAZEV jednoznačný není, jelikož fotogalerie se většinou týká jednotlivých roků a tak názvy jsou většinou stejné, jelikož více oddílu

25 3 DATOVÁ ANALÝZA 25 vlastní své fotogalerie a vkládá do nich fotky k danému roku. Atribut PATRI zajišt uje hierarchii a vazbu mezi fotogaleriemi. Určuje číslo (ID FOT) nadřazené galerie tedy galerie, do které patří. Pokuj je hodnota tohoto atributu rovna nule pak se jedna přímo o jednu z hlavních skupin fotogalerií, které většinou patří jednomu z oddílu nebo středisku. Přidal jsem atribut VLOZENO, což odpovídá času vloženi fotogalerie do databáze. Slouží pro informaci o nově vytvořených fotogaleriích a jako parametr podle nějž se třídí výpis Tabulka OBRAZEK Tato tabulka se zabývá evidencí obrázku, které mohou být použity ve spojení s jinými objekty (FOTOGALERII,ODDILY,LIDE, ). Název Typ(rozsah IO null Poznámka ID OBR int(10) Ne Primární klíč FOTO blob Ne Binární data obrázku NAZEV varchar(50) Ne Jméno obrázkového souboru TYP varchar(20) Ne Typ obrázkového souboru VELIKOST int(10) Ne Velikost obrázku primárním klíčem pro tuto tabulku jsem si zvolil ID OBR, což je kladné celé číslo, které se automaticky generuje na základě již uložených záznamů v tabulce (automaticky se inkrementuje). Atribut FOTO obsahuje přímo binární data daného obrázkového souboru. V atributu NAZEV je uchováván název tohoto souboru, v TYP jeho druh (jpg, gif, ) a v atributu VELIKOST je jeho velikost v Bytech Tabulka FOTO Tato tabulka se zabývá evidencí toho, které obrázky patří do jaké fotogalerie. Název Typ(rozsah IO null Poznámka ID FOT int(5) Ne Cizí klíč z tab. FOTOGALERIE ID OBR int(5) Ne Cizí klíč z tab. OBRAZEK rozkládá vztah OBSAHUJE a obsahuje v sobě vždy primární klíč tabulky FOTOGA- LERIE a OBRAZEK Tabulka HISTORIE Tato tabulka se zabývá evidencí záznamů v almanachu. primárním klíčem pro tuto tabulku jsem si zvolil ID HIS, což je kladné celé číslo, které se automaticky generuje na základě již uložených záznamů v tabulce (automaticky se inkrementuje). Jiný primární klíč jsem určit nemohl, jelikož všechny položky tabulky nemusí být jednoznačné v rámci celé tabulky. Jelikož jako NAZEV záznamu, což je jeho

26 3 DATOVÁ ANALÝZA 26 Název Typ(rozsah IO null Poznámka ID HIS int(3) Ne Primární klíč NAZEV varchar(100) Ne Název zápisu ROK varchar(4) Ne Rok, jehož se zápis týká SOUBOR longblob Ne Binární data souboru pojmenování a zároveň nadpis, může být napsán jakýkoliv řetězec a zároveň za jeden ROK, což odpovídá roku ke kterému se daný zápis vztahuje a jejich a výpis záznamů je podle něj řazen, může být vloženo více zápisů. V atributu SOUBOR jsou uloženy přímo binární data souboru, obsahujícího text vlastního záznamu. Typ souboru musí být HTML a pokud jsou v souboru použity nějaké odkazy na obrázky, tyto obrázky musí být uloženy v adresáři obr v kořenovém adresáři systému Tabulka DOKUMENTY Tato tabulka se zabývá evidencí dokumentů, které středisko používá nebo vytváří. Název Typ(rozsah IO null Poznámka ID DOK int(10) Ne Primární klíč NAZEV varchar(40) Ne Název souboru s dokumentem POPIS varchar(100) Ano Podrobnosti o dokumentu DRUH varchar(20) Ne Druh dokumentu SOUBOR blob Ne Binární data souboru VELIKOST int(10) Ne Velikost souboru VLOZENO int(12) Ne Datum vložení - Počet sekund od :00:00 hod TYP varchar(10) Ne Typ souboru primárním klíčem pro tuto tabulku jsem si zvolil ID DOK, což je kladné celé číslo, které se automaticky generuje na základě již uložených záznamů v tabulce (automaticky se inkrementuje). Jiný primární klíč jsem určit nemohl, jelikož všechny položky tabulky nemusí být jednoznačné v rámci celé tabulky. Atribut SOUBOR obsahuje přímo binární data souboru obsahující daný dokument. V atributu NAZEV je uchováván název tohoto souboru, v TYP jeho druh (pdf, doc, zip ) a v atributu VELIKOST je jeho velikost v Bytech. Atribut POPIS obsahuje popis obsahu daného souboru. Na tento atribut nejsou kladeny žádné omezující požadavky. V atributu VLOZENO je uchováváno datum vložení dokumentu. Jak už jsem se v předchozích kapitolách zmínil každá dokument má jiným význam a je určen pro jinou skupinu lidí a tuto skutečnost zaznamenává atribut DRUH. Může nabývat 3 hodnot a to těchto : Tiskopisy - různé nachystané formuláře, pokyny pro vedoucí apod. Zápisy z jednání - zápisy ze střediskových rad a jiných jednání. Určená pouze pro členy střediska nebo některé jeho části.

27 3 DATOVÁ ANALÝZA 27 Ostatní - ostatní dokumenty Tabulka FORUM Tato tabulka se zabývá evidencí příspěvků uživatelů do fóra. Název Typ(rozsah IO null Poznámka ID FOR int(11) Ne Primární klíč KDY int(12) Ne Čas vložení - Počet sekund od :00:00 hod PATRI int(11) Ne Číslo fóra, kterému příspěvek patří AUTOR int(11) Ne Číslo z tabulky LIDE ZPRAVA text Ne Znění příspěvku KATEGORIE varchar(50) Ano Druh fóra - o akcích, oddílová,.. AKTIVNI int(1) Ne Stav zprávy - 1- aktivní, 0 - neaktivní (jako smazaná) MASTER int(1) Ne Druh zprávy - 1-hlavní zpráva, 0-obyčejná zprava primárním klíčem pro tuto tabulku jsem si zvolil ID FOR, což je kladné celé číslo, které se automaticky generuje na základě již uložených záznamů v tabulce (automaticky se přičítá). Jiný primární klíč být ani zvolen nemohl, jelikož žádný z evidovaných údajů nemusí být jednoznačný v rámci tabulky. Atribut PATRI zajišt uje vazbu mezi jednotlivými příspěvky fóra. Odkazuje se na nadřazený příspěvek, do kterého patří a na který reaguje. Pokud je roven 0 jedná se o jednu z hlavních kategorií. Atribut AUTOR vykonává vztah VLOŽIL a je to klíč tabulky LIDE odkazující na záznam, na kterém je člen, který daný příspěvek vložil. Atribut ZPRAVA obsahuje vlastní znění příspěvku. Atribut KATEGORIE je vyplněn pouze pokud se jedná o příspěvek ve kterém je pouze název nové kategorie. Atribut AKTIVNI značí zda je daný příspěvek platný nebo ne. Příspěvky automaticky nemažu, aby se neztratila vazba mezi příspěvky, které k mazanému příspěvku patří a byla možnost jej případně obnovit. A také proto, aby fóra, která již nejsou aktivní v sekci Fórum, byla dosažitelná z míst, kterých se týká (např. aby fórum tykající se proběhlé akce bylo stalé viditelné ve výpisu této akce). Atribut MASTER určuje zda se jedná o hlavní příspěvek nebo ne. Hlavní příspěvek je zobrazován vždy v úvodu diskuze Tabulka NOVINKY Tato tabulka eviduje novinky zobrazované na úvodní stránce sloužíci k rychlému poskytnutí nových informaci. primárním klíčem pro tuto tabulku jsem si zvolil ID NOV, což je kladné celé číslo, které se automaticky generuje na základě již uložených záznamů v tabulce (automaticky se přičítá). Jiný primární klíč být ani zvolen nemohl, jelikož žádný z evidovaných údajů nemusí být jednoznačný v rámci tabulky. Atribut KDO odpovídá primárnímu klíči tabulky LIDE a určuje autora novinky. Nadpis jednotlivých novinek je uveden v atributu