Seznam obrázků

6

Chtěl bych poděkovat vedoucí své bakalářské práce paní RNDr. Kláře Císařové PhD.za její ochotnou a obětavou péči. Za její motivační schopnosti a za její intervenci do mé práce, která byla jistě přínosem. Dále bych chtěl poděkovat společnosti IBR Consultings.r.o, konkrétně divizi ASPE®za odborná školení a osobnostní i profesní růst.

7 Abstrakt:

Zadáním této práce je vytvořit systém pro správu obsahu disků, tzv. DMS nebo CMS specificky pro potřeby původního zadavatele, kterým byla fyzikálně-chemická laboratoř.

Vznikl systém, který umí zmapovat soubory na discích připojených k počítači, mapování je možné filtrovat, je možné vybrat jen některé disky, popřípadě jen soubory obsahující určitý text, např. příponu nebo celý název souboru. Celý software je pojat jako klient-server aplikace. Na klientské straně se získávají informace o jednotlivých souborech a jejich umístění na discích. Tato část je vyhotovena jako aplikace Windows Forms. Na serverové straně se tyto informace ukládají do databáze. Na klientské straně se rovněž zjišťuje velikost souborů v bytech, čas jejích vzniku a čas poslední změny a jejich hash. Software je kompletně vyvíjen v Microsoft Visual Studiu 2012. K programování klientské části aplikace je použit programovací jazyk C#. Databáze je postavena na MS SQL. Software umožňuje vybrat z databáze pouze soubory uložené na konkrétním úložišti. Umožňuje odebírat a přidávat údaje o souborech do databáze. Pomocí informací uložených v SQL databázi je možné vyhledávat míru duplicity souborů. Systém je navržen pro Microsoft Windows.

Klíčová slova:

DMS (Document Management System), klient-server aplikace, Windows Forms aplikace, hash, MS SQL, CMS (Content Management System)

8 Abstract:

Thetaskis to create a content management systemcalled DMS or CMS.

Thissystemisable to map files on disksattached to thecomputermappingcanbefiltered, itispossible to selectonlysomediscs, oronlyfilescontainingcertain text, such as the extensit orwholefilename. Theentire software isdesigned as a client-server application.

Theclientsidegetsinformationaboutindividualfiles and theirlocation on the disk.

Thissectionisdesigned as a Windows Formsapplication. On the server sideisinformationaboutfilesstored in a database. On

theclientsidealsodeterminesthesizeofthefile in bytes, thetimeofitsorigin and timeofthe last change and itshash. These informationsare used to findduplicitiesoffiles. Software

isfullydeveloped in Microsoft Visual Studio 2012. To

theprogrammingoftheclientapplicationisusedprogramminglanguage C# . The database isbuild on MS SQL language . Software allowschoosingfile on theselectedstorage.

Aplicationalsoallowsinsertig and deletingrowsfrom database. Usingtheinformationstored in the SQL database canbesearchedforfilesofduplication. Thesystemisdesignedfor Microsoft Windows.

Keywords:

DMS (Document Management System), client-server application, Windows formsapplication, hash, MS SQL, CMS (Content Management System)

9

Obsah

Seznam obrázků ... 11

Seznam tabulek ... 11

1 Úvod ... 12

1.1 Databázové systémy ... 13

1.1.1 Historie ... 13

1.1.2 Implementační databázové modely ... 15

1.1.3 Databázové systémy ... 20

1.1.4 Jazyk SQL a jeho podmnožiny ... 21

1.1.5 Databázové objekty ... 22

1.2 Organizace dat na disku ... 24

1.2.1 Diskové jednotky ... 24

1.2.2 Souborové systémy ... 25

1.3 Existující systémy pro správu obsahu ... 26

1.3.1 DMS v softwaru ASPE® ... 26

1.3.2 Microsoft Team Foundation Server® ... 28

1.3.3 Document management system společnosti CCA group a.s. ... 31

2 Návrh implementace monitorování disků ... 33

2.1 Analýza ... 33

2.2 Požadavky na systém pro správu obsahu ... 33

2.3 Návrh serverové části aplikaci ... 35

2.3.1 Návrh klientské části aplikace ... 36

3 Implementační část ... 38

3.1 Architektura aplikace ... 38

3.2 Serverová strana aplikace ... 38

3.3 Klientská aplikace ... 39

3.3.1 Záložka monitoring disků ... 39

10

3.3.2 Záložka databáze ... 44

3.3.3 Okna filtrů ... 47

3.3.4 Záložka parametry ... 49

4 Závěr ... 50

Seznam použité literatury ... 52

Obsah přiloženého CD ... 53

11

Seznam obrázků

Obrázek 1: Seznam souborů ASPE ... 27

Obrázek 2: Detail souboru ASPE ... 28

Obrázek 3: TFS - anotovaný kód ... 29

Obrázek 4: TFS - větve vývoje, historie vývojové větve ... 30

Obrázek 5: porovnání zdrojových kódů ... 31

Obrázek 6: Datový model aplikace ... 35

Obrázek 7: vyhledávání souborů ... 40

Obrázek 8: získávání údajů o souborech ... 41

Obrázek 9: vyhledané soubory ... 42

Obrázek 10: výsledky porovnání ... 43

Obrázek 11: databáze souborů ... 45

Obrázek 12: hromadné mazání záznamů... 46

Obrázek 13: Detail o souboru v databázi ... 46

Obrázek 14: seznam přípon ... 47

Obrázek 15: filtr období, komponenta pro výběr ... 48

Obrázek 16: záložka parametry ... 49

Seznam tabulek

12

1 Úvod

Úvodem mojí bakalářské práce je nutné říci, že hlavní motivací vzniku této práce byla žádost z praxe. Laboratoř fyzikálně-chemických měření, která je zadavatelem, měla přání, aby pro ni byl vyvinut software, pomocí kterého bude moci monitorovat obsah svých disků.

Z měření prováděných v laboratoři vzniká velké množství podobných souborů, které nejsou nikterak uspořádány. Proto se zadavatel rozhodl, že by soubory chtěl filtrovat, popřípadě upozornit, na soubory, které jsou duplicitní, ať se již vyskytují na jednom úložišti, nebo na několika různých.

Program je pojat jako aplikace server-klient, kdy klientská část této aplikace bude

umožňovat komunikaci s uživatelem, zjišťovat obsah úložišť (logických diskových jednotek) aktuálně připojených ke klientskému PC. Dále klient zajišťuje porovnávání souborů

s databází, pro zjištění případných duplicit. Serverová část tato data uchovává, umožňuje jejich filtrování. Systém bude navržen a implementován pro OS Microsoft Windows, jelikož právě tento systém používá laboratoř fyzikálního měření, která je zadavatelem práce.

Klientská část by měla umožnit vybrat jedno nebo více úložišť, které chceme mapovat.

Nadále by měla umožnit nalézt ty názvy souborů, které obsahují pouze nějaký konkrétní text, například příponu souboru, či libovolnou sekvenci znaků v názvu. O těchto souborech by měl klient získat takové množství atributů, aby bylo možné porovnávat jejich případné

duplicity.Serverová část aplikace bude tato data shromažďovat v databázi.

Na dnešním trhu pochopitelně existuje spousta podobných programů zastávajících tyto požadované funkce, ať už se jedná o souborové manažery nebo o systémy na správu

dokumentů, jimž se budu věnovat v následující kapitole. Existující programy jsou však velmi komplexní a na požadavky zadavatele zbytečně rozsáhlé. U systému na správu dokumentů také navíc velmi drahé. Proto si zadavatel přál software, který bude plnit jeho konkrétní přání, na rozdíl od softwaru, který je již nabízen softwarovými společnostmi na dnešním trhu.

13 1.1 Databázové systémy

Pojem databáze se používá pro množinu strukturovaných dat definovaných pro realizaci konkrétního databázového informačního systému. Příkladem mohou být data pro řízení skladu, data studentech a jejich studijní cestě pro studentskou agendu, data pro správu

knihovnu či jiný účel. V tomto smyslu je databáze účelově definovaná množina. Tyto data se dále zpracovávají speciální databázovou technologií některého z databázových systémů.

Manipulace s daty umožňuje část databázových systémů, která se nazývá SŘBD, tedy systém řízení báze dat. Typickými aktuálně používanými představiteli databázových systémů jsou například Oracle, MS SQL, MySQL a řada dalších.

1.1.1 Historie

Databáze vznikly jako potřeba lidí uchovávat velké objemy dat jednotně,

centralizovaně a elektronicky. Předchůdcem databází byly papírové kartotéky pro různé agendy. Informace se získávaly manuálním zpracováváním. Běžné jednoduché úkony jako je vložení, či editace je často potřebné doplnit o složitější hledání informací pro následné rozhodování a to je v papírových agendách obtížné. Pro rozhodování je často nutná znalost odpovědi spojené se zkoumáním mnoha dat za delší období , hledáním závislostí, či řešením komplikovanějších úloh, a tyto informace nelze získat v manuálních systémech dostatečně rychle. Práce s papírovými daty je zdlouhavá, únavná, stereotypní a zákonitě zatížená chybami. Dalším krokem ve vývoji zpracování dat bylo mechanické, strojové zpracovaní štítků s dírami. U tohoto zpracovávání docházelo ale k velkým duplicitám dat, například při sčítání lidu v USA v roce 1890, kde byly poprvé tyto štítky nasazeny, byl pro každého pana Smitha (nejběžnější příjmení v USA) vyděrován speciální štítek. Metoda uchovávání dat pomocí děrovaných štítků byla používána dalších 50 let.

Dalším impulsem pro rozvoj databází byl rozvoj počítačů. Ukázalo se, že není vhodné data ukládat tak jako v předchozím případě, a to nejen kvůli velkým objemům na papírových mediích, kterými byly děrné štítky a děrné pásky, ale i dalším problémovým situacím. Papír neměl potřebnou mechanickou odolnost, ve snímačích se často zasekával a s rostoucími objemy dat rostly i problémy s jejich archivací. V té době už byla možnost ukládání dat na magnetických mediích a to discích a páskách. Papírová média postupně ztrácela význam a podoba vstupních dat se zcela „elektronizovala.“ První aplikace byly psané v jazycích jako Assembler, Algol nebo Fortran. Tyto vycházely z potřeb řešení hardwarových problémů,

14

případně řešení logických a matematických problémů. Práce s velkými daty byla pro tyto jazyky možná, ale komplikovaná. Z toho důvodu se v roce 1959 objevil požadavek na vyšší programovací jazyk pro zpracování dat. Následující rok byl publikován jazyk COBOL, který byl několik dalších let hlavním jazykem, spolu s jazykem PL1, pro zpracování dat

v elektronických agendových systémech. Agendové aplikace, tenkrát označované slovem program, vznikaly zprvu nekoordinovaně podle potřeby. Co problém to program, nezávislý na jiných programech napsaných v dané organizaci. Problémy menšího podniku mohou být například: řízení dopravy, výpočet mezd, řízení skladu, evidence faktur a objednávek a další.

Každý problém měl svůj program, svého autora, své datové vstupy – soubory na sadách štítků či magnetických páskách, které obsahovaly data podle logiky programu a návrhu autora, nekoordinovaně s ostatními vstupy do jiných programů. Důsledkem tohoto přístupu k prvním programům pro zpracování dat, byla velká redundance a nekompabilita dat. Výskyt jedné datové položky (jméno a adresa zaměstnance) v různých aplikacích a v různých datových formátech způsoboval komplikace při zpracování i údržbě datových souborů. Tento přístup měl dva zásadní následky.

 V rovině ekonomické to byly zvýšené náklady na údržbu, pořizování dat a odstraňování případných nekonzistencí.

 V posouzení kvality nasazených programů – často se stávalo, že „změnová řízení“

neproběhla na všech místech výskytu dat a tím byla porušena integrita dat a hlavně důvěryhodnost informací poskytovaných programem.

Naléhavost řešit popsané problémy vedla k prvnímu užití pojmu jednotná báze dat. Tedy snaha i nutnost organizovat data v jednom místě koordinovaně a pokud možno bez zbytečné redundance. V roce 1965 vznikl výbor DBTG – database taskgroup. V tomto výboru se začala rodit koncepce databázových systémů tak, jak ji známe dnes. Začaly vznikat první síťové systémy řízení báze dat na obrovských sálových počítačích.“Obrovských“ je měřítko

historické. Nevztahuje se k hardwaru a výkonu počítače, ale k prostoru, který sálové počítače té doby zabíraly. Tehdejší výkon sálového počítače dnes zvládne osobní počítač střední třídy.

Později se začaly objevovat síťové a hierarchické databázové modely. Jejichž zevrubný popis bude uveden dále.

V roce 1970 pan Edgar Frank Codd zveřejnil článek o relačních databázích, ve kterých jsou data implementovaná v relačním datovém modelu. Relační datový model postavil na relační algebře a předem matematicky podložil všechny manipulace s daty, které tvoří

15

podstatu funkčnosti SŘBD. Tento krok se považuje za počátek relačních databází. Zhruba kolem roku 1974 se objevuje na světle světa první verze SQL jazyka pro dotazy do relačních databází.

V pozdější době se ještě začaly objevovat snahy o objektově orientované databáze, to zhruba kolem roku 1990. Hlavním principem je přiblížit databáze k objektově orientovaným programovacím jazykům. Vzhledem k vývoji hardwaru se dá očekávat, že objektové databáze časem relační nahradí. Zatím, mimo jiné, vznikla objektově relační technologie, kterou

najdeme v publikacích pod názvem postrelační databáze. Příkladem takové databáze je Cache.

Velmi často je dnes používán i objektový návrh a analýza, vlastní model je pak „namapován“

– transformován do relačních tabulek. Databáze Caché umí oboje.

1.1.2 Implementační databázové modely

Data a jejich vzájemné vazby mohou být fyzicky uloženy v databázi různým způsobem.

V průběhu historie DBS se vyprofilovalo několik datových modelů. První databázové modely byly síťové a hierarchické databázové modely. Síťové a hierarchické přístupy modelování databází jsou dnes již překonanou záležitostí a jsou zde uvedeny, aby bylo možné získat lepší představu o vývoji databázových modelů.

Hierarchický implementační model:

V hierarchickém databázovém modelu jsou data zorganizována do stromové struktury.

Každý záznam je uzlem tohoto stromu. Vztah mezi uzly stromu je tedy rodič/potomek.

Hledání dat v hierarchické databázi vyžaduje průchod přes záznamy, které jsou cestou z rodiče na potomka nebo naopak. Využívají se tedy algoritmy pro průchod stromů.

Největšími zápory hierarchického modelu je složitá operace vkládání a mazání záznamů.

V některých případech se dá za nevýhodu tohoto uspořádání považovat i nepřirozenou organizaci dat. Data jsou uchovávána v souborech, jejichž základní jednotkou je záznam (segment). Záznam je tvořen daty - poli, která obsahují sledované údaje o příslušném prvku (objektu, entitě) databáze a vazby jsou realizované obvyklými dynamickými datovými strukturami. Největší nevýhodou hierarchického modelu je obtížné vyjádření a udržování vztahů s kardinalitou m:n. Modelovaná realita, jako zájmová oblast reálného světa, pro kterou navrhujeme databázi, má vztah m:n mezi daty velmi často a nelze jej ignorovat nebo se tomuto problému vyhnout. Při zachování pravidel pro hierarchický databázový model vede

16

implementace vztahu m:n k redundanci dat. To je problémový prvek takto navržené struktury [7].

Síťový model dat:

Síťový model je možné pojmout jako zobecnění modelu hierarchického. Tento model doplňuje datové struktury o tzv. „sety“, které představují mnohonásobné vztahy. Tyto vztahy vytvářejí možnost propojení záznamů na principu „každý s kýmkoliv.“ Data jsou uložena bez zbytečné redundance, ale počet vazeb realizovaných dynamickými datovými strukturami prudce roste s růstem funkcionality. Velkým záporem takto uložené databáze je její nízká flexibilita co znamená, že i malé změny struktury databáze jsou náročnými operacemi.

Předností je, že vytvářet vztahy lze takřka bez omezení, ale v praxi toto vedlo k realizaci komplikovaných a obtížně udržovatelných databázových systémů.[7].

Relační model dat:

Relační datový model byl navržen panem Codem už v roce 1970, ale k jeho prosazení vedla ještě dlouhá cesta. Návrh vyplynul z dlouhé zkušenosti se síťovým IDMS.

Komplikovanost práce analytické a programátorské a její nedocenění v praxi, vedlo Coda k hledání datových struktur, které by optimalizovaly práci s daty, eliminovaly vznik chyb a problémů známých z hierarchických a síťových databází. Jeho návrh organizuje data na základě pojmu matematické relace a manipulace s datovými strukturami odvozuje od teorie relační algebry. Je to první SŘBD, který vznikl na základě promyšlené matematické teorie aplikované do programátorského života. U předcházejících systému existovalo nejprve programátorské řešení a až potom se hledaly teoretické základy realizovaných algoritmických principů.

Definice relační struktury je pro relační databáze zásadní, proto nejprve potřebné definice podle [8].

Def. 1 Kartézský součin

Nechť je dán systém {Di | 1=i<=n } neprázdných množin. Potom kartézským součinem R = D1xD2 x ....Dn nad D1,D2, ....Dnnazýváme množinu všech uspořádaných n-tic (d1,d2 ....dn) takových, že di Dipro 1=i<=n. Z této definice vyplývá, že obecně množiny Di

mohou být různé a tedy n-tice budou typově heterogenní. V n-tici je možné mít čísla, stringy, kódy, datumy atd.

17 Def. 2 Relace

Nechť je dán systém {Di | 1=i<=n } neprázdných množin. Potom podmnožinu kartézského součinu R D1xD2 x ....Dn nazýváme relací stupně n (n-ární relace) nad D1,D2,

....Dn . Prvky relace jsou uspořádané n-tice (d1,d2 ....dn) takové, že di Dipro1=i<=n.

Relaci můžeme chápat jako matici nebo také tabulku o m – řádcích a n sloupcích.Každý řádek je jedním prvkem množiny R. Definiční množiny Di nazývámedoménami. V teorii relačních databází pojmenování Di nazýváme atributem. Pojmenování relace významově popisuje soubor atributů soustředěných v jedné relaci relační databáze.

Strukturu relace zapisujeme obvykle takto:

STUDENT (RODNÉ ČÍSLO, JMÉNO, PŘIJMENÍ, ČÍSLO INDEXU, FAKULTA, DATUM ZÁPISU, ADRESA, ABSOLVOVANÁ STŘEDNÍ ŠKOLA, STUDOVANÝ OBOR, ZAPSANÉ PŘEDMĚTY)

Def. 3 Báze dat

je konečná množina v čase proměnných konečných relací, které jsou definovány nad doménami ze systému množin {Di | 1=i<=n }. Změna v čase spočívá v možnosti přidání, vynechání jednoho nebo více řádků v některých relacích, nebo ve změně některých hodnot v již existujících řádcích některých relací.

Def. 4 Populace

Relaci R(t) v čase t_i nazýváme populace.

Z definice relace vyplývá, že doménou, nad kterou je relace definovaná, může být opět relace. V tomto slova smyslu rozlišujeme atributy jednoduché – dále nedělitelné a atributy složené, které jsou kombinací několika jednoduchých atributů. Prvky domény složeného atributu jsou pak uspořádané n-tice. Rozlišení co je atribut a co je entita je relativní a může se lišit podle úhlu pohledu analytika. Algoritmy pro práci s daty uloženými v relačních datových strukturách jsou založené například na těchto operacích s relacemi – průnik relací, kartézský součin, projekce, restrikce, spojení, přirozené spojení a další. Pro návrh databáze je

rozhodující jaké relace budou tvořit databázi. To závisí na zkušenosti návrháře analytika, který musí návrh v několika diskusích konzultovat se zadavatelem. Cíle a funkce, které zadavatel očekává, může systém splnit pouze, když bude mít relevantní data. Návrh datových struktur, funkcí a datových toků se dnes obvykle tvoří v case nástrojích a to strukturovaně

18

nebo objektově. Kvalita konečné aplikace je podstatně ovlivněna kvalitou datového modelu.

Pro relační databáze byl poprvé v historii předepsán exaktně popsaný proces hledání dobrého modelu dat. Tento proces se nazývá normalizace a vychází z matematicky přesně popsaných kroků. Návrhář – analytik dostává do rukou pravidla, které pokud je dodrží, pomohou model vytvořit. Jednotlivým krokům se říká normální formy. Na počátku všechna potřebná data pro naplnění informačních cílů jsou v jedné relaci. Postupně, aplikací předepsaných postupů, se tato rozpadá na menší relace. Odstraní se složené atributy, funkční závislosti poslouží k dalšímu pochopení dat a jejich dekompozice. Dekompozice je účelová, odstraňuje možné duplicity a přispívá tím k udržení konzistence dat. Normálních forem je více, aplikují se podle subjektivní zkušenosti analytika. Rozpad na příliš mnoho relací totiž znamená také

komplikaci při některých databázových operacích. Pro některá hledání v datech je nutné relace spojovat pomocí klíčových položek a to může znamenat zpomalení systému. To, kdy - při jaké normální formě, návrh analytik ukončí, je nutné podrobit hluboké úvaze.

0NF

uvažuje všechny atributy, které z analýzy vyplynuly v jedné relaci Nevylučují se složené atributy. V příkladu podbarvené atributy mohou být složenými atributy.

STUDENT (RODNÉ ČÍSLO, JMÉNO, PŘIJMENÍ, ADRESA, ČÍSLO INDEXU, MAIL, FAKULTA, SÍDLO FAKULTY, DĚKAN, DATUM ZÁPISU, ABSOLVOVANÁ STŘEDNÍ ŠKOLA, STUDOVANÝ OBOR,ZAPSANÉ PŘEDMĚTY)

1NF

Relace R je v 1-normální formě, pokud všechny atributy relace jsou jednoduché, říkáme, že jsou atomické tj. totéž jako nedělitelné, v níže uvedeném příkladu zůstává atribut ZAPSANÉ PŘEDMĚTY neatomizován z důvodu přehlednosti

STUDENT (RODNÉ ČÍSLO, JMÉNO, PŘIJMENÍ, ULICE, MĚSTO, PSC, ČÍSLO INDEXU, MAIL, FAKULTA, F-ULICE,F-MĚSTO, F-PSC, DĚKAN, DATUM ZÁPISU, ABSOLVOVANÁ STŘEDNÍ ŠKOLA, NÁZEV OBORU, KÓD OBORU, POPIS, TYP STUDIA, STANDARDNÍ DÉLKA, JAZYK, GARANT OBORU, ZAPSANÉ PŘEDMĚTY)

Def.5 Silná funkční závislost atributů

19

Nechť A,B jsou atributy relace R. B je silně funkčně závislý na A, pokud v každé populaci každé hodnotě A odpovídá jediná hodnota atributu B. tj. existuje fce f: A B a zároveň neexistuje podmnožina AA taková, že atribut B je závislý na A.

2NF

Relace R je v 2NF pokud je v 1NF a každý atribut, který nepatří ke klíči R je silně funkčně závislý od klíče relace R. Klíč je definovaný jako podmnožina atributů relace,

nezávislá na čase a jednoznačně určující každou n-tici a je vzhledem k identifikaci minimální.

Klíčů lze najít v relaci víc, ten, který je analytikem vybrán se nazývá primárním. Klíčovou položkou pro příklad ať je RODNÉ ČÍSLO. Některé budoucí možné duplicity lze odstranit převodem relace do 2NF a to pomocí projekce.

Relace STUDENT se aplikací projekce rozpadá na relace STUDENT, FAKULTA, ZAPSANÉ PŘEDMĚTY, STUDIJNÍ OBOR

STUDENT (RODNÉ ČÍSLO, JMÉNO, PŘIJMENÍ, ULICE, MĚSTO, PSC, ČÍSLO INDEXU, MAIL, DATUM ZÁPISU, ABSOLVOVANÁ STŘEDNÍ ŠKOLA, )

FAKULTA (FAKULTA, F-ULICE, F-MĚSTO, F-PSC, DĚKAN, TELEFON. FAX, WEB) STUDIJNÍ OBOR (NÁZEV, KÓD OBORU, POPIS, TYP STUDIA, STANDARDNÍ DÉLKA, JAZYK, GARANT)

ZAPSANÉ PŘEDMĚTY (ZKRATKA PŘEDMĚTU, NÁZEV, ZPŮSOB ZAKONČENÍ, GARANT PŘEDMĚTU, JAZYK, ZAPSÁNO V AR)

3NF

Relace je ve třetí normální formě, pokud je v druhé normální formě a neexistuje neklíčový atribut, který by byl tranzitivně závislý na kterémkoliv klíči relace R. Transitivní závislost mezi dvěma neklíčovými atributy a klíči v příkladu ukážeme na relaci STUDENT, student bydlí ve MĚSTĚ, MĚSTO má PSC, proto provedeme dekompozici projekcí na relace novou relaci STUDENT a MĚSTO

STUDENT (RODNÉ ČÍSLO, JMÉNO, PŘIJMENÍ, ULICE, MĚSTO, ČÍSLO INDEXU, MAIL, DATUM ZÁPISU, ABSOLVOVANÁ STŘEDNÍ ŠKOLA)

MĚSTO (MĚSTO, PSČ) v tomto případě vznikne „číselník“

20

Popsaný proces je jen výkladový, rozhodně nepředstavuje úplnou a uzavřenou formu návrhu, má pouze ilustrovat proces normalizace. Hledání funkčních závislostí mezi atributy by mělo pokračovat, jsou známé další normální formy. To jak hluboko se původní relace rozpadnou na nové menší relace je závislé na databázovém analytikovi, jeho zkušenosti a dovednosti a tak stejný problém může mít různá řešení. Obvykle se tento fakt označuje jako sémantický relativizmus. Důležité je, že rozkladem na další relace se nesmí ztratit informace, že spojením pomocí klíčových atributů lze původní relace obnovit. Spojování

dekomponovaných tabulek je náročné na čas a proto je důležité dělat rozklad uvážlivě.

Výhody a nevýhody normalizace, případná denormalizace z důvodu zvýšení výkonu databáze lze najít podrobněji diskutované v [5],[9],[10].

1.1.3 Databázové systémy

Databázový systém je softwarové vybavení serverového typu, které umožňuje práci s databází, vývoj serverové aplikační části a její provoz. Musí umožnit vytvoření databáze definováním databázových objektů, jako jsou například tabulky, indexy, pohledy, uživatelské funkce, triggery, či uložené procedury. Dále musí umožňovat vkládání dat a jejich změny, výběr dat podle potřeby. Definování uživatelů a jejich práv, případně rolí. Databázový systém musí být schopen efektivně pracovat s velkým množstvím data to tak, aby uživatel dostal požadovanou informaci z velkých dat dostatečně rychle.

Dnes na serverové straně obvykle pracuje SQL server, který stejně pojmenovaným neprocedurálním jazykem SQL dovoluje pracovat s daty. Patří do skupiny dotazovacích jazyků.

Objektové databáze nejsou předmětem této práce, proto nebudou v textu prezentované, více lze nalézt v literatuře a jsou podtypem databází označovanýchNoSQL databáze, tedy databáze, které nejsou relační. Relační databáze mají mnoho užitečných vlastností (proto jsou stále nejrozšířenější), ale občas se hodí i jiný způsob práce se strukturovanými daty. Zastánci NoSQL databází vyzdvihují například jejich škálovatelnost. Pro obrovské objemy dat tzv.

„big data“ je využívají společnosti jako Google nebo NFAmazon, apod.

Dnes mezi nejpoužívanější databázové systémy stále ještě patří Oracle, MS SQL, Sybase, Informix a další. Tyto programy nejsou levné, ale uživatelům dávají záruky v poskytované podpoře a budoucím vývoji s respektem k změnám na trhu s informačními

21

technologiemi. Konkurují jim systémy šířené zdarma jako freeware nebo opensourcové nástroje - např. MySQL, mSQL a PostgreSQL.

Příklady některých databázových systémů pro vývoj databázových informačních systémů:

 Oracle

 DB2

 SybaseAdaptive Server Enterprise

 FileMaker

 Firebird

 Ingres

 Informix

 Microsoft Access

 Microsoft SQL Server

 Microsoft Visual FoxPro

 MySQL

 PostgreSQL

 Progress

 SQLite

 Teradata

 CSQL

 OpenLinkVirtuoso

 Caché

 NexusDB

1.1.4 Jazyk SQL a jeho podmnožiny

SQL – StructuredQueryLanguage je strukturovaný, neprocedurální, deklarativní dotazovací jazyk. Je jazykem pro definici a manipulaci s daty relačních databází.

Neprocedurální znamená, že jeho příkazy se říká jaké informace chceme získat, nikoli jak je získat. Jinak řečeno SQL nevyžaduje přístupové metody k datům. Má relativně volný formát a založený je na několika jednoduchých anglických slovech. Základy se tak relativně snadno může naučit i manager, který není informatik a získat tak informace, které rychle potřebuje. Je ale pravda, že pro sofistikovaný, komplexní systém je potřeba databázového specialisty. Ten musí stavět na znalostech a zkušenostech a také na spolupráci se zadavatelem, který zná modelovanou realitu a potřebu, kterou má databázový informační systém naplnit.

Práci s databázovými systémy umožňují tři podmnožiny příkazů jazyka SQL První podmnožinou SQL je DDL Data DefinitionLanguage – příkazy pro definici dat, který se používá pro definování databázové struktury, používá např. příkazy:

 CREATE – prvotní vytvoření databázové instance, pohledů, indexů, domén

 ALTER – mění strukturu databázové tabulky, pohledů, funkce, procedury

22

 DROP – smaže objekt z databáze

 TRUNCATE – smaže všechny záznamy z tabulky

Další podmnožinou příkazů pro manipulaci s databází je DML – Data ManipulationLanguage jazyk pro manipulaci s daty:

 SELECT – získává data z databáze

 INSERT – vkládá data do tabulky

 UPDATE - upraví existující data v tabulce

 DELETE – maže data z tabulek

Další podmnožinou je DCL Data ControlLanguage – jazyk pro kontrolu přístupů, používá následující příkazy:

 GRANT – dává uživateli přístupová práva do databáze, lze definovat pro jaké akce

 REVOKE – obere práva, která byla přidělena příkazem GRANT

Jazyk SQL má mnoho klonů lišících se v detailech, tak jak historicky vznikaly. Je pozitivně přijímán dodavateli i uživateli a tím má široké použití. Téměř všichni významní dodavatelé poskytují databázové produkty založené na SQL nebo s rozhraním SQL. Většina z nich se aktivně zúčastňuje procesu standardizace. SQL je první a prozatím jediný standardizovaný databázový jazyk. [11]

1.1.5 Databázové objekty

Tabulky v databázi jsou jen jednou z mnoha databázových entit, objektů. Databázové systémy pokročilejšího typu obsahují například:

Pohled/View:

Tento databázový objekt není ničím jiným než příkazem SELECT, který je označem názvem a uložen do databáze. Hlavní výhodou tohoto objektu je to, že se chová úplně jako tabulka a proto je možné jej použít i v jiných příkazech SELECT. Pohled nemůže obsahovat například klauzuli COMPUTE, používat klíčové slovo INTO. Navíc pohled nemůže

odkazovat na dočasnou tabulku či proměnnou jakéhokoli typu. Pohled umožňuje data před použitím "učesat". Úprava dat pomocí pohledu je možná, pokud se tato úprava týká právě jedné tabulky, sloupce odkazují přímo na sloupce v tabulce atd. Pohledy je možné

indexovat.[1]

23 Index:

Index obsahuje informace o indexovaném objektu, zjednodušeně řečeno, se jedná o přístupový klíč v daném řazení podle jednotlivých sloupců tabulky. Primárním účelem indexů je zvýšení rychlosti dotazů na data. Nevýhodou indexů je to, že snižují rychlost vkládání dat.

V ideálním případě by bylo možné vytvořit velké množství různých indexů, aby byla zajištěna rychlá odezva všech možných kombinací dotazů, které by uživatel mohl zadat. Indexy je však nutné udržovat. Při vkládání, úpravě a mazání dat je proto nutné indexy aktualizovat. Díky indexům nemusíme sekvenčně procházet relací – tabulkou nebo pohledem, pokaždé když hledáme nějakou položku. Pro samotnou implementaci indexů se používají např. vyvážené b- stromy.

Trigger:

Spouště neboli triggery umožňují automaticky spouštět kód na základě určité akce – databázové události. Na rozdíl od funkce nebo procedury nemůže být triggerpušťen přímo, k aktivaci kódu uvnitř spouště dochází pouze v souvislosti s událostí, pro kterou je definován.

Obecně existují dva typy spouští – DDL Triggery a DML Triggery. Spouště definované na základě jazyka pro manipulaci s daty se definují pro konkrétní události INSERT, UPDATE nebo DELETE a jejích stav Trigger se aktivuje před nebo po události pro kterou je vytvořen.

Například BEFORE INSERT, AFTER DELETE. DDL spouště se aktivují buď pokud je spuštěn příkaz DDL nebo se k instanci přihlásí uživatel.

Uživatelem definovaná uložená funkce:

Je to funkce v databázi, v které programátor definuje (pojmenuje a uloží) konkrétní posloupnost instrukcí. Vstupem funkce může být libovolný počet parametrů, jejím výstupem může být pouze jedna databázová tabulka nebo skalární hodnota. Funkce nemohou provést akce, které mění stav databáze. Měnit data v tabulce. Volat funkce, které mají externí efekt, například funkce RAND(). Vytvářet dočasné tabulky nebo k nim jakýmkoli způsobem přistupovat. A v neposlední řadě nemohou dynamicky spouštět kód.

Uživatelem definovaná uložená procedura:

Nejuniverzálnějším programovatelným objektem ze čtveřice pohled, funkce, trigger, uložená procedura, je právě procedura. Tyto procedury jsou základem každého reálného databázového informačního systému. Každý příkaz spouštěný v databázovém serveru je

24

možné zapouzdřit do uložené procedury. Zjednodušeně řečeno je tedy procedura dávka příkazů, která je označená názvem a uložena do databáze. Od bazální dávky příkazů se liší tím, že je možné uplatnit všechny struktury kódu – řídící příkazy, podmíněné příkazy, cykly.

Uložené procedury mohou vracet více hodnot.

Reporty:

Umožní definovat strukturu pro výstup tabulky, do které se při použití daného reportu doplní aktuální hodnoty z databáze. Používají se pro náhled a tisk dat v čitelném formátu.

Uživatelská oprávnění:

Moderní databázové systémy umožňují na straně serveru hlídat uživatelská oprávnění.

Mohou hlídat přístup různých uživatelů k datům, popřípadě k akcím. Například vkládat zaměstnance může pouze personalista, získávat informace o platech jen účetní a ředitel a k mazání dat z databáze má právo pouze správce.

1.2 Organizace dat na disku 1.2.1 Diskové jednotky

Slouží pro ukládání dat v PC. Diskovou jednotkou může být fyzický pevný disk, logický pevný (část fyzického disku) nebo jím může být jakékoli vyměnitelné médium (DVD, Flash, BD, etc.)

V operačních systémech společnosti Microsoft se diskové jednotky označují velkými písmeny abecedy A-Z. Některá písmena jsou privilegována:

 A:, B: – disketové mechaniky

 C: – systémová část pevného disku

 D: až Z: – další fyzické pevné disky, logické pevné disky, a vyměnitelná úložiště Tato funkce diskových jednotek platí pouze u OS společnosti Microsoft, v Unixových systémech GNU/Linux nebo MAC OS je souborový systém diametrálně jiný. Je tvořen hlavním kořenovým adresářem (označen „/“) v adresáři jsou složky, které mohou označovat složky na systémovém disku nebo i jinou diskovou jednotku.

25 1.2.2 Souborové systémy

Souborové systémy se skládají ze dvou základních částí, v první části jsou uložena samotná data a programy a v druhé části je uložena struktura adresářů, která obsahuje informace o souborech.

 FAT (FileAllocation Table) – Souborový systém FAT byl vytvořen s první verzí QDOSu, což byl předchůdce MS-DOSu. Výhodou FAT systému je použitelnost ve většině operačních systémů (Windows, MAC OS, Linux), nevýhodou je omezení maximální velikosti souborů. Jelikož cluster může být tvoření jedním nebo více sektory (mocniny dvou). Maximální počet sektorů v clusteru je 64 (což odpovídá velikosti 32 KB). V případě jednosektorového clusteru je maximální možná velikost logické jednotky 32 MB, při maximální velikosti clusteru 2 GB.

Systém FAT má následující strukturu:

1. Boot sektor – hlavní spouštěcí záznam 2. Spouštěcí záznam svazku

3. Alokační tabulka souborů 4. Kořenový adresář

5. Clustery (Alokační jednotky v dané oblasti) 6. Diagnostické cylindry pro zápis/čtení

 NTFS (New Technology FileSystem) – Souborový systém vytvořen společností Microsoft pro operační systémy nové generace tzv. Windows NT. Je to rozšiřitelný souborový systém. Hlavní vlastností je tzv. žurnálování – všechny zápisy se zároveň zaznamenávají do speciálního souboru, tzv. žurnálu. Pokud dojde při zápisu k havárii, je možné uvést souborový systém, díky záznamům v žurnálu, uvést opět do

konzistentního stavu. Umožňuje komprimování na úrovni systému souborů. Přiděluje práva k souborům pomocí tzv. „Access Control List.“ Podporuje dlouhá jména souborů. NTFS využívá 64-bitovou adresaci clusterů. Z této vlastnosti plyne to, že může být diskový oddíl větší než u FAT. U FAT je maximální velikost diskového oddílu 2 TB a u NTFS je to až 16 EB (exabytů). Celý systém je v podstatě obří databáze, jejíž záznamem je soubor.

26

 Ext (Extendedfilesystem) – Souborový systém vyvinutý pro OS Linux. Tento systém vychází z tradičního Unixového systému UFS. Jeho nástupci jsou ext2, ext3 a ext4.

 ExFAT (Extendedfileallocation table) – Je to nástupce souborového systému FAT.

Odstraňuje hlavní nevýhody tohoto souborového systému, kterými jsou – omezení velikosti diskového oddílu a omezení velikosti souboru. Velikost souboru je

maximálně 16 exabytů a velikost diskového oddílu 128 exabytů. Je cílen na ukládání dat v přenosných zařízeních (flashdisky, paměťové karty).

1.3 Existující systémy pro správu obsahu 1.3.1 DMS v softwaru ASPE®

ASPE je softwarový nástroj, který je určen k přípravě a realizaci stavebních projektů.

Jelikož jsem součástí vývojového týmu tohoto softwaru, bylo po dohodě s vedoucí práce rozhodnuto, že bude popsán tento systém.

Program ASPE umožňuje jak investorům, tak dodavatelům kontrolovat projekty, jež realizují. Software je modulární, umožňuje rozpočtovat stavby, kontrolovat a zadávat jejich realizaci, čerpání, fakturaci a změny během výstavby, popřípadě rozpad velkých stavebních celků na dílčí části. Ke každé z těchto částí se dají přiřadit dokumenty, které souvisí

s jednotlivými částmi stavby, či se stavbou jako celkem.

27

Obrázek 1: Seznam souborů ASPE

DMS softwaru ASPE umožňuje několik operací s dokumenty:

 Přidávat dokumenty k jednotlivým útvarům (reprezentovaných položkami ve stromu) – dojde k přidání dokumentu do číselníku dokumentů se záznamem o tom k jaké úrovni je přidán a s kódem konkrétní položky

 Odebírat dokumenty z číselníku dokumentů

 Ukládat do databáze záznamy o dokumentech

 Vyhledávat v dokumentech podle části názvu nebo jeho celku

 Otevřít dokument v příslušné aplikaci (pokud je pro daný typ souborů vytvořena asociace)

 Rozvazovat vazby dokumentů k jednotlivým položkám stromu – poté nejsou přiřazeny ke konkrétnímu uzlu stromu, nýbrž jsou pouze uloženy v databázi, je možné je opět k některému uzlu přidat

Tento systém dále umožňuje zobrazit detail jednotlivých dokumentů

28

Obrázek 2: Detail souboru ASPE

Systém dále umožňuje filtrovat soubory v seznamu podle:

 Názvu souboru ve formátu *.*

 Podle velikosti – využívá 3 Windows.Formskompenty, dva comboBoxy, jeden na výběr druhu porovnání a druhý na výběr řádů. Třetí komponentou je textBox kam uživatel zadává konkrétní hodnotu velikosti.

 Zdroj souboru

 Datum vytvoření záznamu

 Části obsahu dokumentu

 Podle popisu

1.3.2 Microsoft Team Foundation Server®

Jako další systém pro správu obsahu byl zvolen produkt Team Foundation Server (dále jen TFS), společnosti Microsoft. Tento systém se používá pro správu zdrojových kódů.

Systém je primárně určen pro správu verzí zdrojových kódů při programování v teamu. Díky

29

uživatelským účtům umožňuje zjišťovat, kdo v daném zdrojovém kódu udělal v jakém datu jakou konkrétní změnu.

Obrázek 3: TFS - anotovaný kód

Umožňuje sledovat historii celé vývojové větve nebo jen konkrétního souboru. Na (Obrázek 4: TFS - větve vývoje, historie vývojové větve) je vidět historie celé vývojové větve, v seznamu jsou poté jednotlivé tzv. „changesety“ – úpravy zdrojových souborů shrnuté

30 do skupiny a pojmenované podle významu změny.

Obrázek 4: TFS - větve vývoje, historie vývojové větve

TFS dále například umožňuje:

 Ukládat soubory, popřípadě změny do databáze na serveru o Kontrolovat kdo pracuje na jakých souborech

 Při vložení nové změny spustit na serveru kompletní build

 Získávat reporty o buildech

31

 Porovnávat jednotlivé verze zdrojových kódů a hledat v nich rozdíly (Obrázek 5:

porovnání zdrojových kódů)

Obrázek 5: porovnání zdrojových kódů

1.3.3 Document management system společnosti CCA group a.s.

Pro popis existujícího komerčního systému pouze pro správu dokumentů byl zvolen produkt české společnosti CCA group a.s. Tato společnost je jedním z předních poskytovatelů IT služeb v České republice, kteří se zaměřují na správu dokumentů.

Jejich software se jmenuje jednoduše „Document management system“. Produkt používá pro správu dokumentů Microsoft SharePoint, což je platforma nástrojů pro spolupráci mezi spolupracovníky uvnitř společností, která umožňuje práci s dokumenty, řízení

souvisejících procesů a sdílení informací mezi uživateli.

OracleWebCenterContent je technologická platforma pro správu podnikového obsahu, zajišťuje správu celého spektra nestrukturovaného obsahu – od běžných dokumentů (faktury, objednávky, dodací listy, smlouvy a další), grafiky a webových stránek až po naskenované

32

obrázky a e-maily. Součástí řešení je integrace se skenovacími zařízeními, rozpoznávání dat na formulářích, integrace s nástroji MS Office a další. [2]

Systém společnosti CCA group a.s. řeší také přístupová práva. Zabezpečení obsahu dokumentů je jednou z nejdůležitějších vlastností DMS systému. Zabezpečení je daleko důkladnější, než jaké je možné zajistit u papírových dokumentů. U papírového dokumentu totiž nelze absolutně zaručit, že se k němu nedostane neautorizovaná osoba. Avšak systém pro správu obsahu tento problém řeší, tím, že neautorizovaného uživatele do dokumentu nevpustí.

Navíc se vedou záznamy o všech vstupech do dokumentu, takže je vždy zpětně možné zjistit, kdo do dokumentu přistupoval.

Tento produkt také přináší podporu elektronických formulářů, které jsou v dnešní době velmi efektivním nástrojem ke zrychlení procesů s dokumenty. Navíc jsou ekonomické, šetří čas i peníze, jelikož není nutné vytisknout papírový formulář a poté údaje přepsat do

elektronické formy.

Aplikace od CCA group a.s. zajišťuje dále verzování a zamykání souboru, má velmi propracované vyhledávací nástroje, dokáže komunikovat s mobilními zařízeními a v

neposlední řadě řeší způsoby komunikace s externími systémy.

Shrnutí k testovaným DMS a CMS systémům:

Systémy ASPE DMS a TFS jsem otestoval a závěrem lze říct, že každý z nich má své specifické použití a uplatnění na trhu. Nabídka funkcí je závislá na správě očekávaných dokumentů a také cílové množině uživatelů. Jiné funkce nabízí správa dokumentů ASPE spojená s realizací stavebních projektů, jinak vypadá DMS zdrojových kódů v TFS.

Relativně obecně postavený systém DMS společnosti CCA grou a.s. je komplexní ve správě uživatelů.

Závěrem se dá říct, že pro potřebu relativně malé laboratoře – 5 zaměstnanců, která si původně monitoring disků zadala, jsou tyto komplexní systémy z mnoha různých důvodu stěží použitelné a zbytečně drahé.

33

2 Návrh implementace monitorování disků

2.1 Analýza

Hlavním úkolem práce bylo vytvoření funkčního řešení databázového informačního systému pro správu disků. Proto bylo nutné nejprve zjistit, jaké jsou požadavky na tento systém. Po shrnutí požadavků na tento systém byla po dohodě s vedoucím práce stanovena kompletní architektura databázového informačního systému a zvoleny technologie pro její implementaci. Klientská část aplikace by měla být co nejvíce uživatelsky přívětivá a intuitivní aby v ní mohli snadno pracovat i lidé, kteří mají nízké IT znalosti.

Tento informační systém by měl umožnit:

 Načíst adresářovou strukturu a soubory, které jsou uloženy na discích připojených k počítači na kterém je provozována klientská část aplikace.

 Aplikace musí umožnit filtrovat vyhledávání. Prohledávat jen některé logické disky připojené ke klientskému počítači.

 Musí být možné získat o souborech potřebné množství informací (atributů) k jejich porovnávání.

 Ukládání a mazání záznamů o souborech na databázovém serveru, editace těchto záznamů není potřebná, jelikož záznam je pořízen o konkrétním stavu souboru v konkrétním čase

 Porovnávat takto získané záznamy s nově nalezenými soubory.

 Zobrazit detail o uloženém souboru.

 Zobrazit obsahy jednotlivých disků a údaje o souborech na nich uložených

2.2 Požadavky na systém pro správu obsahu

DMS jsou systémy pro správu dokumentů, jak elektronických, tak digitalizovaných tzn. například naskenovaných, vyfocených, nahraných apod. Hlavním důvodem vzniku systémů pro správu obsahu byla potřeba zajistit přístupová práva k jednotlivým dokumentům, či jen jejich k některým částem.

Komerční systémy pro správu dokumentů by měli umožnit následující operace:

34

 Přidávat dokumenty – a současně je uchováván metapopis (meta data) dokumentů, jenž typicky obsahuje dodatečné informace o dokumentu, které bývají využity například pro rychlejší vyhledávání

 Spravovat verze dokumentů – má umožnit automatické párování identifikátorů a dokumentů, nebo jejich verzí, které slouží k tomu, aby byl identifikátor v rámci systému unikátní

 Zajistit dostupnost dokumentů a dokumentace díky centralizaci

 Spravovat verze dokumentů – ukládají se informace o tom, v jakých bitových stavech se dokument nacházel. Ideálně je ukládat bitovou změnu, aby bylo možné soubor v jakémkoli stavu zpětně obnovit

 Přístupová práva – hlídá se, aby se do dokumentu nedostal uživatel, který k němu nemá oprávnění

 Umožnit kategorizaci – slouží k zobrazení dokumentů podle jednotlivých kategorií

35 2.3 Návrh serverové části aplikaci

Návrh serverové strany aplikace vycházel z analýzy systému. V prvním kroku byl vytvořen datový model, postupnou normalizací. Data po dekompozici získala následující relační strukturu (Obrázek 6: Datový model aplikace)

Obrázek 6: Datový model aplikace

Po datovém modelu byly definovány operace, které jsou od databáze požadovány.

Z analýzy vyplývá, že soubory, které jsou uživatelem vyhledány je třeba do databáze uložit se všemi zjištěnými atributy.

Jelikož tento proces bude potřebovat využít SQL příkazu INSERT je pro jeho realizaci zvolena uživatelsky definovaná uložená procedura.

Dalším požadavkem na systém bylo možnost soubory najít podle přípony. Proto, aby bylo možné vyhledávat podle přípony, kterou jsme ještě nikdy nenalezli, se dají využít dvě

36

varianty. První z nich je možnost naplnit číselník přípon všemi příponami z nějakého seznamu. Je však možné, že programy mají přípony, které nejsou nikde uvedeny. Proto byla zvolena možnost uživatelského vložení přípony. Přípona může mít maximálně 6 znaků. O tento krok se opět stará uložená procedura.

Jedním z hlavních požadavků na vyvíjený systém je možnost porovnat obsahy více disků, tento požadavek jsem rozšířil tak, že je možné vyfiltrovat soubory podle dalších kritérií jako je například přípona souboru, soubory které vložil jaký uživatel pod Windows ověřením nebo období v kterém byly soubory vytvořeny. Tyto filtry je možné libovolně

kombinovat. O zobrazení takto filtrovaných dat z databáze se bude starat další uložená procedura.

2.3.1 Návrh klientské části aplikace

Návrh klientské části informačního systému pro taktéž vycházel z analýzy požadavků.

Klientská část musí umět projít adresářovou strukturu disku a najít soubory podle zadaných kritérií – část názvu, umístění na logické diskové jednotce. Popřípadě vyhledávat podle přípony, kterou předtím bude možné přidat. Výsledky takto provedeného vyhledávání musí umět uživateli zobrazit. Dále musí uživateli umožnit vybrat výsledky vyhledávání, s kterými poté chce učinit nějakou akci.

Klient bude připraven na ukládání dat z databáze a jejich zobrazování. Zobrazování by měl mít uživatel možnost filtrovat, primárně podle disku, z kterého byla data získána.

Vyhledané soubory musí být možné porovnat a zobrazit procentuální míru shody těchto souborů.

Aplikace by měla umožnit nastavit, jaké atributy o souborech bude možné zjišťovat.

Parametry jako například velikost nebo název nelze zjišťovat volitelně.

Uživatel musí mít možnost smazat záznamy z databáze a to jak jednotlivě, tak

hromadně. Mělo by být možné komfortně zvolit jaké soubory smazat, popř. jednoduše vyčistit databázi.

Musí být možné zobrazit detaily o souboru uloženém v databázi.

Aplikace by měla být přehledná i pro méně zkušené uživatele PC. Proto bylo

rozhodnuto, že bude aplikace přehledně rozčleněna, většina ovládacích prvků se nachází tam, kde je uživatelé obvykle najdou u jiných systémů. Program bude obsahovat komponentu,

37

která bude umožňovat skrytí a zobrazení komponent do ní vnořených (jejího obsahu). Velká pozornost byla věnována nejen návrhu ergonomie programu ale i jeho designové stránce.

Bylo stanoveno několik jednoduchých grafických pravidel, které budou popsány v realizační části tak, aby celkový design aplikace působil na pohled co nejlépe.

Komunikace s uživatelem bude probíhat pomocí systémových dialogů, kde vždy bude nastavená taková hodnota, aby bylo ovládání co nejrychlejší, tj. u informačních dialogů přímo na potvrzení, u mazání na odmítnutí, aby nedošlo k nežádoucímu vymazání záznamů.

38

3 Implementační část

3.1 Architektura aplikace

Pro realizaci klientské části aplikace byl zvolen .NET Framework vyvíjený společností Microsoft, který je téměř nativní technologií pro operační systém MS Windows, pro který je aplikace určena. Jako programovací jazyk byl zvolen C#. Metodiku práce by nejlépe popsal tzv. „scrum“. Kde je na začátku pouze krátká fáze programování, poté je produkt předveden zadavateli a vždy se předvádí každá další konkrétní změna tak, aby bylo možné rozhodnout, zda je změna žádoucí nebo nikoli. S ohledem na to, že aplikace je určena pouze pro PC není v ní přítomna žádná vektorová grafika, ani animované efekty a je možné že aplikace poběží na málo výkonném hardwarubyla pro vývoj zvolena technologie MS Windows.Forms, nikoli Windows PresentationFoundation.

Pro programování serverové části byl na přání zadavatele zvolen MS SQL Server 2008 R2. Zadavatel měl tento systém zakoupený již před tím, než padl návrh implementovat tento databázový informační systém pro správu obsahu disků.

Program je rozdělen do několika záložek, každá záložka se bude inicializovat

programově až na enter, tento krok zajistí krátkou odezvu zapnutí programu. Je plně dodržen objektový princip programování, z důvodu snadné pozdější rozšiřitelnosti programu a

testování. Změny budou mít vždy vliv na jeden konkrétní soubor.

3.2 Serverová strana aplikace

Podle datového modelu vytvořeného v rámci analýzy řešení databázového informačního systému pro správu obsahu disků, byly sestaveny skripty na vytvoření tabulek. Při vývoji byly vytvořeny i skripty na drop tabulek v databázi.

Databáze dále obsahuje 3 uložené procedury, které administrují:

 Vkládání přípony souboru – pokud se uživatel rozhodne vyhledávat soubory na discích podle přípony, kterou ještě databáze neobsahuje, je mu umožněno příponu přidat. Tento krok poté realizuje velmi jednoduchá procedura, která vloží uživatelem zadaná data do číselníku přípon. Procedura vrací příznak, který nabývá hodnoty TRUE/FALSE podle toho, jestli bylo uložení úspěšné.

39

 Ukládání údajů o vyhledaných souborech – jak je zřejmé z datového modelu, pokud se rozhodneme zapsat data o souborech, které si uživatel přeje, je nutné ovlivnit několik databázových tabulek .Všechny tyto potřebné kroky v transakci zajišťuje procedura na vložení souboru. To, že se vkládání děje v transakci řeší problémy spojené se síťovým provozem (např. záznam, který se snažím vybrat příkazem SELECT už někdo editoval nebo smazal). Procedura vrací index nově vytvořeného prvku a chybový kód, popř. 0 pokud k chybě na straně serveru nedojde. Navíc, pokud dojde během vykonávání procedury k chybě, celá transakce bude vrácena a data budou v původním stavu jako před jejím začátkem.

 Filtrování údajů o souborech – procedura, která jako vstupní parametry filtry které může uživatel vybrat. Například rozmezí vytvoření souborů, jejich příponu nebo to, na jakém se nachází disku. Bez ohledu na to, jaké filtry jsou aktivní, procedura vždy vrátí výsledky odpovídající přesně všem kritériím filtrů.

Databáze dále umožňuje záznamy o souborech mazat jednotlivě či hromadně. Tento krok není řešen v uložené proceduře proto, že je v aplikaci použito pouze na jednom místě.

3.3 Klientská aplikace

Klientská aplikace je postavena jako formulářová aplikace, která je zaměřena především na rychlé odezvy pro uživatelské akce, uživatelský komfort a přehlednost. Její dynamičnost umožňuje velmi snadnou další rozšiřitelnost.

3.3.1 Záložka monitoring disků

Klient je rozdělen na tři záložky, na první záložce se obsluhuje získávání informací o souborech, jejich porovnávání s existujícími záznamy, ukládání záznamů o těchto souborech do databáze.

40

Po startu aplikace, pokud si uživatel přeje zjišťovat informace o nových souborech, vybere logickou jednotku, na které chce vyhledávat. V dalším kroku zadá název souboru, jeho část nebo vybere příponu z číselníku, popř. onu příponu přidá. Poté uživatel klepne na tlačítko

„Vyhledávej“. V tzv. backthreadu(při ukončení nebo pádu se toto vlákno zabije, na rozdíl od tzv. „frontthreadu“) se spustí vyhledávání, zobrazí se progressbar, který vizualizuje uživateli průběh vyhledávání.(Obrázek 7: vyhledávání souborů)

Obrázek 7: vyhledávání souborů

41

Pro vyhledávání se používá funkce Directory.EnumerateFiles. Tato funkce jako své vstupní parametry přijímá tři vstupní parametry, prvním z nich je relativní nebo absolutní cesta k adresáři, který má být prohledáván. Druhým je vyhledávaný řetězec, může obsahovat

* a ?, regulární výrazy však nepodporuje. Třetím parametrem je jedna z hodnot výčtu, který určuje zda by operace vyhledávání měla projít pouze aktuální adresář, nebo i všechny

podadresáře. Funkce vrátí kolekci, která implementuje rozhraní IEnumerable (je vyčíslitelná), názvů souborů i s cestou podle zadaných parametrů[4].

Obrázek 8: získávání údajů o souborech

Velké množství komponent je umístěno ve vlastních uživatelských kontrolech, které se jmenují „DropDownPanel“ a byli vytvořeny v rámci vývoje tohoto systému. Jedná se o jednoduché expandery, které umožňují skrýt/zobrazit jejich obsah.

42

Po prvotním vyhledávání (Obrázek 9: vyhledané soubory) se objeví uživateli další komponenty pro ovládání programu ve spodní části záložky „Monitor Disků“. První tři tlačítka vlevo slouží k označování řádku v tabulce vyhledaných souborů. Tlačítko „Ulož výsledky“ ukládá označené řádky do databáze.

Obrázek 9: vyhledané soubory

Po vyhledání souborů je také možné je porovnat s obsahem databáze. Kvůli

přehlednosti výsledného okna bylo rozhodnuto, že najednou bude možné porovnávat pouze

43

pět souborů. Tlačítko „porovnávat“ vyvolá další okno (Obrázek 10: výsledky porovnání).

Obrázek 10: výsledky porovnání

V tomto okně se nachází tabulka, jež zobrazuje porovnání vybraných souborů se všemi soubory v databázi majícími stejný prostý název. Shoda souborů je vyjádřena procenty.

Každému atributu, jenž by mohl vypovídat o případné duplicitě souboru,byla na základě testování na různých souborech s různými diferencemipřiřazena procentní váha (Tabulka 1:

procentuální váhy atributů), pokud nebyly zjištěny všechny atributy (zjišťování bylo vypnuto), tak nelze soubory prohlásit za 100% shodné. V tabulce jsou popsány váhy jednotlivých atributů a možnosti jejich změn, jež mohou nastat změnou uživatelského nastavení na záložce parametry. Uživatel si může vybrat, jaký kontrolní součet souboru chce počítat – tento kontrolní součet má váhu 40 procentních bodů, pokud se uživatel rozhodne počítat oba, procentní body se mezi ně rozdělí. Tabulka předpokládá, že pokud jsou atributy zjištěny, musí se shodovat, aby bylo možné přičíst procentuální váhu.

44

Tabulka 1: procentuální váhy atributů

Atribut Zjišťovat Váha

SHA ano 20

MD5 ano 20

SHA ne 0

MD5 ano 40

SHA ano 40

MD5 ne 0

Datum vytvoření ano 10

Datum změny ano 10

Název souboru ano 10

Velikost (shodná) ano 20

velikost ± 10% ano 10

Atribut skrytý ano 2,5

Atribut skrytý ne 0

Atribut systémový ano 2,5

Atribut systémový ne 0

Atribut archivovat ano 2,5

Atribut archivovat ne 0

Atribut jen pro čtení ano 2,5

Atribut jen pro čtení ne 0

3.3.2 Záložka databáze

Záložka databáze zobrazuje uživateli záznamy o souborech, které jsou uloženy

v databázi na serveru. Po prvním vstupu na tuto záložku (Obrázek 11: databáze souborů) jsou zobrazeny 4 filtry, které umožňují filtrovat zobrazené soubory podle: přípony, disku z kterého

45

pocházejí, data vytvoření nebo podle rozmezí a podle uživatele.

Obrázek 11: databáze souborů

Záložka dále obsahuje tabulku, v které uživatel vidí soubory uložené v databázi, buď všechny, nebo pouze vyfiltrované. Vedle každého filtru je také tlačítko, které ho zruší. Dále záložka obsahuje tlačítko, které smaže všechny záznamy, nad tlačítkem je umístěn text, který indikuje, kolik souborů odpovídá filtrům.

Na záložce databáze je dále možné soubory mazat, komponenta pro zobrazování v tabulce umožňuje označovat řádky stejně jako v průzkumníku Windows, tj. pomocí

modifikačních kláves. Toto označení mu umožňuje vybrat více souborů ke smazání(Obrázek 12: hromadné mazání záznamů).

46

Obrázek 12: hromadné mazání záznamů

Záložka databáze je dále rozdělena na dvě další podzáložky, kde na jedné je seznam souborů a filtry. Na druhé záložce je poté zobrazen detail souboru vybraného

v tabulce(Obrázek 13: Detail o souboru v databázi).

Obrázek 13: Detail o souboru v databázi

Z ilustrace je patrná další vlastnost třídy DropDownPanel, pokud je do ní umístěn pouze jeden textbox a uvede se do zavřeného stavu začátek textu v textboxu bude zobrazen v horní liště pro popis a ovládání komponenty.

47

Podzáložka údaje na záložce databáze slouží pouze pro lepší přehlednost údajů zobrazených v tabulce. V tabulce je možné se posouvat na další/předchozí záznam spodními tlačítky, bez nutnosti překliku na druhou podzáložku seznam.

3.3.3 Okna filtrů

V aplikaci jsou k filtrování zobrazených souborů z databáze použity dva typy filtrů.

 Obecný filtr – pomocí tohoto filtru zobrazujeme uživateli všechny záznamy, které jsou v jednotlivých tabulkách v databázi a podle kterých lze vyfiltrovat soubory. Po kliku na lupu filtrovacího textboxu se zobrazí modální dialogové okno (není možné pracovat v původním okně bez jeho ukončení), v kterém první sloupec odpovídá identifikátoru a druhý sloupec konkrétní hodnotě podle které chceme filtrovat. Tento druh je použit u všech filtrů krom datumového.

Obrázek 14: seznam přípon

 Filtr podle data a času vytvoření souboru – Tento filtr určuje buďto jeden konkrétní den/měsíc data vytvoření souboru který má být zobrazen. Nebo rozmezí dat vytvoření,

48

mezi kterým chceme záznamy zobrazit. Pro získávání těchto informací jsou vytvořeny vlastní třídy zděděné od třídy UserControl.

Obrázek 15: filtr období, komponenta pro výběr

1. Třída RokKalendar – tato třída byla vytvořena kvůli absenci komponenty pro výběr pouze měsíců (bez nutnosti vybrat den) ve Windows Forms. Vzhledem k tomu, že aplikace cílí na maximální uživatelský komfort, bylo rozhodnuto, že nahradit tuto komponentu např. kombinací numericUpDownu (pro výběr let) a ComboBoxu (pro výběr měsíců), není ideální varianta.

2. Třída DvojKalendar – sdružuje dvě komponenty kalendáře, v jednom režimu obsahuje klasický Windows.Forms.MonthCalendar a v druhém režimu kalendáře vytvořené v rámci vývoje aplikace, které jsou popsány výše. Tyto režimy řídí proměnná typu bool. Mezi režimy je možné přepínat i v designeru Microsoft Visual Studia. Tato komponenta navíc řeší správnost datumů od a do, která v případě výběru dat ve špatném pořadí sama prohodí.

3. Třída KalendarTextBox – v rámci designu aplikace bylo rozhodnuto, že klasický design komponenty, kterou poskytuje windows.forms není dostatečný, proto od této komponenty byla zděděna vlastní, která lépe odpovídá designu aplikace.

4. TridaDvojKalendarPanel – sdružuje instanci třídy DvojKalendar a dvě instance třídy KalendarTextBox. Řeší přepínání režimů (buď je možné vybrat pouze měsíc a rok

49

nebo lze vybírat i dny). Dále komponenta řeší také přepínání režimů

KalendarTextBoxu z formátu dd.mm.rrrr na dlouhý formát měsíc slovem a rok číslem.

3.3.4 Záložka parametry

Záložka parametry je relativně jednoduchá třída odvozená od třídy UserControl. Tato třída obsahuje radiobuttony a checkboxy pro přednastavení parametrů vyhledávání. Některé volby není možné změnit. V rámci korektního zapouzdření reprezentuje každý konkrétní checkBox a radioButton hodnotu bool, která je pomocí „property“ jazyka C# vyvedena pro ostatní controly pouze pro čtení.

Obrázek 16: záložka parametry

50

4 Závěr

Hlavním úkolem bakalářské práce bylo vyvinout software, který dokáže monitorovat obsah disků. Měl jsem aplikaci naprogramovat tak, aby klientská část aplikace umožnila získávat data o souborech na klientském počítači a tyto data ukládat a dále zpracovávat v databázi, která je uložena na serveru. Hlavní motivací vzniku tohoto programu byla žádost z laboratoře, která provádí fyzikálně-chemická měření. Tato laboratoř má na svých discích velké množství souborů s podobnými daty, které je potřeba monitorovat, nikoli verzovat, ani porovnávat.

Software, který byl náplní mé bakalářské práce, je ve své podstatě systémem pro správu obsahu. V první části práce se věnuji rozboru databázových systémů a databází obecně, jelikož můj systém je celý postaven nad databází a bez znalosti této problematiky by nebylo možné aplikaci implementovat. Dále se věnuji řešerši podobných existujících

produktů, aby se předešlo tomu, že se bude programovat software, které je možné získat např.

jako freeware. Pro popis jsem zvolil několik produktů, jednak software ASPE, na jehož vývoji se ve své praxi podílím, součástí tohoto je právě document management system, pro správu dokumentů staveb. Dále pak systém od společnosti Microsoft, Team Foundation Server, pro vývoj projektů v týmech. Tento software sám nejvíce využívám, a proto jsem se rozhodl popsat právě jej. Dále pak shrnuji informace o existujícím produktu české společnost CCA group a.s. Při zjišťování informací o softwaru této společnosti jsem vycházel z informací, které uvádějí na svých webových stránkách. Tuto společnost mi pro popis jejího produktu doporučila vedoucí bakalářské práce.

Program po dohodě s vedoucí vznikl v programovacím jazyce C#. Pro vývoj jsem použil MS Visual Studio 2012. Databáze je vyvinuta pro MS SQL Serveru verze 2008 R2.

Návrh programu byl poměrně složitý, jelikož požadavky zadavatele nebyly úplně jasné. Byla jasná zevrubná představa o systému, ale konkrétní způsoby, jak získávat

informace o souborech, podle jakých atributů zjišťovat shodu, jak duplicitu monitorovat jasné nebylo. Proto byli konzultace ohledně architektury softwaru poměrně časté a pro

programování byl použit „scrum“. Práce je poměrně rozsáhlá. Bylo dbáno na design a uživatelskou přívětivost. Samozřejmě jsem během vývoje práce narazil na nemalé množství problémů, avšak při programování je neustále nutné řešit problémy. Implementace bakalářské práce rozšířila mé znalosti o relačních databázích, tím že jsem chtěl část logiky přenést na server.

51

Největší problém, na který jsem narazil, byla diference mezi datovými typy jazyka C#

a dotazovacího jazyka SQL. Konkrétně u pokusu přetypovat tzv. „varchar“ na pole bytů.

Soubory z disků je možné porovnávat se soubory uložené v databázi, aplikace umožňuje zjistit procentuální míru shody souborů. Tuto akci lze provést i hromadně.

Program umožňuje pomocí filtrů porovnat obsah více disků.

Pro spuštění aplikace je nutné modifikovat konfigurační soubor v adresáři „release“, do kterého je nutné napsat jako datový zdroj server, na kterém se databáze nachází a její název.

Při návrhu a implementaci aplikace jsem vycházel z praktické zkušenosti s vývojem softwaru ASPE, kde pracuji jako programátor.