No title

Originál zadání!!!!

Anotace Bakalářská práce je zaměřena na komplexní řešení problematiky informačního systému skladového hospodářství externího skladu logistické společnosti. Hlavním cílem je zejména možnost nasazení daného řešení na mnohdy jednorázové akce dočasných pronájmů skladových prostor mimo logistické centrum, a to za cenu minimálních investic. První část se zabývá uvedením do problematiky informačních systémů a dále konkretizací zadání externího skladu logistické společnosti. Následuje teoretický rozbor návrhu datových struktur a implementace řešení ve vybraném software. Praktickou část tvoří databázová aplikace splňující základní požadavky na evidenci pohybů, tisk dokumentů, pomocné výpočty, podklady k vyúčtování a v neposlední řadě na uživatelsky přívětivou obsluhu.

Annotation The bachelor’s thesis is focused on complex solution of problems of information system of stock holding used in an external store of a logistic company. The main aim is especially to enable the usage of the given solution in one-shot temporary leases of store areas out of the logistic centre, in particular at minimal expenses. The first part deals with introduction to problems of information systems and further with concretization of assignments of the external store of the logistic company. Theoretical analysis of a proposal of data structures and of implementation of the solution in the chosen software follows. Practical part includes database aplications which meet the basic requirements on records of flows, document printing, subsidiary calculations, bases for final accounts and, last but not least, on user friendly operation.

Poděkování Poděkování za pomoc a podnětné připomínky patří vedoucímu bakalářské práce panu doc. RNDr. Ing. Miloši Šedovi, Ph.D., a v neposlední řadě také všem blízkým a přátelům, kteří mi svou trpělivostí a tolerancí vytvořili podmínky k vypracování této závěrečné bakalářské práce.

Prohlášení Čestně prohlašuji, že tuto bakalářskou práci jsem vypracoval samostatně dle rad a pokynů vedoucího a že jsem veškerou použitou literaturu uvedl v seznamu použité literatury.

…………………….. podpis

Strana 1

OBSAH 1. Úvod.............................................................................................................................. 3 2. Stručný pohled do historie IS........................................................................................ 7 2.1 Přehled vývoje informačních technologií ............................................................... 7 2.2 Úvod do databázových systémů ........................................................................... 14 2.3 Dotazovací jazyky................................................................................................ 16 3. Popis externího skladu logistické společnosti ............................................................ 17 3.1 Zadání projektu meziskladu.................................................................................. 17 3.2 Cíl zadání tvorby informačního systému .............................................................. 18 3.3 Očekávané přínosy................................................................................................ 18 3.4 Kritéria návrhu ...................................................................................................... 20 4. Rozbor zadání ............................................................................................................. 21 4.1 Volba softwarové platformy ................................................................................. 21 4.2 Metodika zpracování datových struktur ............................................................... 23 4.3 Konceptuální datový model .................................................................................. 24 4.4 CASE Studio 2 – nástroj pro návrh databází ........................................................ 25 5. Praktická tvorba báze dat ............................................................................................ 27 5.1 Modelování CASE studio 2.3 CZ ......................................................................... 27 5.2 Fyzické databázové schéma.................................................................................. 29 5.3 Integrita dat ........................................................................................................... 33 6. Praktická tvorba SŘBD............................................................................................... 35 6.1 Formuláře.............................................................................................................. 35 6.2 Sestavy .................................................................................................................. 42 6.3 Hlavní panel uživatelského rozhraní..................................................................... 48 6.4 Souhrny, výpočty a Visual Basic for Application ................................................ 49 6.5 Dotazovací jazyk SQL .......................................................................................... 53 6.6 Bezpečnost ............................................................................................................ 54 6.7 Podmínky provozu................................................................................................ 56 7. Závěr ........................................................................................................................... 57 Seznam použité literatury ............................................................................................... 59

Stana 2

Strana 3

1. Úvod Logistika je odvětvím, bez kterého se neobejde žádné společenské a ekonomické odvětví. Každý předmět, který si koupíme, ať je to rohlík, snídaně nebo auto, kterým jezdíme do práce, byl vždy součástí nějakého logistického řetězce. Na počátku musel někdo přepravit suroviny k výrobě do zpracujících podniků a dále již jako polotovary do montážních nebo výrobních firem, kde z nich teprve vznikl finální výrobek, který, než se dostal na náš stůl či do garáže, prošel dlouhým přepravním a skladovým řetězcem. Žijeme ve společnosti s vyspělou tržní ekonomikou, kde vládne tvrdá ruka trhu, která velí výrobním a obchodním společnostem, pakliže chtějí na poli volné soutěže uspět se svým výrobním či obchodním programem, minimalizovat fixní náklady mezi které patří i náklady na logistiku a které obecně tvoří až 30 % ceny výrobku, než se dostane do rukou koncovému spotřebiteli. Každý úspěšný podnikatel, ředitel, vedoucí či obchodník mi dá za pravdu, když prohlásím, že jednou z nejcennějších deviz v procesu rozhodování, řízení, plánování a obchodování je mít kvalitní a rychlé informace. Informace a jejich kvalita má zásadní vliv na dějinný vývoj člověka již od pradávna. Vůdcové a vládcové všech společenstev ji využívali i zneužívali napříč dějinami a ne jinak je tomu i dnes. „Z historie víme, že vynález písma a papíru rozšířil ústní předávání informací o předávání informace pomocí textu. Efektivnost předávání informace v podobě textu byla podstatně zvýšena v 15. století Guttenbergovým vynálezem knihtisku, který nenákladnou reprodukcí tiskem umožnil na svou dobu nebývalé šíření informací, mající v té době velkou zásluhu na šíření vzdělanosti. Vedle knih se koncem 17. století začínají objevovat i časopisy jako zdroje nových informací. Jejich počet s rozvojem vědy a techniky neustále narůstal. Jestliže počátkem 19. století vycházelo 100 titulů vědeckých časopisů, dosáhl jejich počet za 100 let počtu přes 10 000. Dnes na celém světě vycházejí ročně desetitisíce vědeckých knih a téměř již 200 000 titulů odborných časopisů. Uvádí se, že každý rok se objem informací zvětšuje o více než 7 milionů stran tištěného textu. Není tedy divu, že v 70. letech minulého století se začíná hovořit o „informační explozi“.“ [5] Zásadní zlom co do kvality a rychlosti získané informace nastává na počátku a zejména přelomu minulého století s nástupem moderních technologií v oboru sdělovacích technik. Nemalou zásluhu, i když politováníhodnou, na tom mají dvě světové války z první poloviny minulého století, kdy vlády všech zemí a zejména zúčastněných velmocí vynakládaly nemalé prostředky ze svých rozpočtů na vědu a výzkum. Motivace byla jasná, být o krok vpředu v množství, kvalitě a možnostech vyrobeného zbrojního arzenálu. Jedním z nejdůležitějších úkolů v oblasti informačních technologií bylo definovat a z matematického hlediska vymezit kvantitativní hodnotu informace. Završením úsilí mnoha vědců a inženýrů byla Shannonova (obr. 1.1) definice informace z roku 1948 informační entropie H, jako záporně vzatý logaritmus pravděpodobnosti nějakého jevu. Matematicky zapsáno Hi = −log pi. „Pro nejmenší možnou informaci, tj. odpověď „ano/ne“ pak byla odvozena jednotka informace 1 bit Hi = −log pi = −log2 1/2.“ [6] Tato definice je dnes většinou vědců a inženýrů vnímána jako konečná, ale zpřesňování definice informace pokračuje stále.

Strana 4

1. Úvod

Obr. 1.1. Claude Elwood Shannon 1916–2001 Volba logaritmického základu odpovídá volbě jednotky pro míru informace. Když je použit základ 2, výsledné jednotky mohou být zvány binárními číslicemi nebo zkráceně bity. Slovem, které navrhl J. W. Tukey. Zařízení se dvěma stabilními stavy, jako je relé nebo klopný obvod, může uchovat jeden bit informace. N takových zařízení může uchovat N bitů… [The Bell System Technical Journal, Vol. 27, p. 379, (July 1948).] „Všechny informace, které člověk doposud nashromáždil, je možné vyjádřit číslem 1016 bitů. Lidský mozek si osvojuje informace rychlostí 0,2 až 1 bit za sekundu, přičemž proud informací jen nových vědecko-technických poznatků dosahuje podle různých odhadů od 3 do 20 bitů za sekundu. Tedy ani člověk, který by četl celý den a celou noc bez odpočinku a bez spánku a jen četl nové publikace, by nemohl být informován o všech událostech vědy.“ [5] Z této skutečnosti plyne nutnost, motivace k vytváření systémů, které dokáží informace specifikovat, uchovávat a poskytovat vždy v požadovaném a konkretizovaném množství v závislosti na požadavcích. Takovýmto systémům říkáme informační systémy (IS). Život moderního člověka si bez nich již ani nedokážeme představit. Ať už jde o ty nejjednodušší formy, jako například různá ovládací menu spotřební elektroniky, palubní desky automobilů (obr. 1.2) až k vysoce sofistikovaným, jakými jsou systémy podnikových agend, kontrol nebo například systém řízení jaderné elektrárny. Nejrozšířenější a pravděpodobně také nejpopulárnější informační systémem současnosti je zajisté Internet. Jeho šíře je celosvětová a množství informací nepředstavitelné. Cesta k Internetu, jednomu z nynějších vrcholů informačních systémů, byla ovšem trnitá, lemována miliony hodin práce tisíců vědců a pracovníků výzkumných center na mnoha zejména amerických univerzitách. Shrneme-li výše uvedené poznatky, je samozřejmostí, že žádný z pracovníků účastnících se logistických procesů nemůže mít v paměti uchovány veškeré informace a data, tak aby mohl kvalitně řídit, účetně uzavírat a kontrolovat práci na svém pracovišti. Tato bakalářská práce má napomoci k vedení jednoho z konkrétních projektů meziskladu popsaného v následujících kapitolách.

1. Úvod

Obr. 1.2. Uživatelské rozhraní informačního systému automobilu

Obr. 1.4. Internet je celosvětovou informační sítí

Strana 5

Strana 6

1. Úvod

Strana 7

2. Stručný pohled do historie IS Dříve než bude pozornost zaměřena na zadané téma, rád bych ve zkratce prošel dějinný vývoj, který musel nutně předcházet dnešnímu modelu i principu zpracování dat a výpočtů. 2.1 Přehled vývoje informačních technologií „Historii lze rozdělit na čtyři základní periody charakterizující technické metody využité k řešení vstupu, zpracování, výstupu a přenosu dat: 1. 2. 3. 4.

předmechanickou; mechanickou; elektromechanickou; elektronickou.

1. Předmechanická doba 3000 př. n. l.–1450 n. l. – přenos informací První lidé využívali k přenosu informací pouze řeč a malbu obrazců. Féničané vynalezli symboly a Řekové k nim přidali samohlásky. Římané dali základ dodnes používané latinské abecedě. První metody vložení informací na médium bylo Sumeřany vynalezené rytí jehlou do vlhkého jílu. Egypťané přišli se záznamem na papyrus. Posléze Číňané vynalezli papír, který je v inovované formě využíván doposud. První metody archivace dat byly objeveny v Mezopotámii, kde duchovní vůdcové uchovávali první knihy. Egypťané schraňovali svitky papyrů a o systematickém uchovávání lze hovořit ve starém Řecku, kde započali s rolováním sešitů a jejich svazováním. První číselný systém byl sestrojen Hindy ve staré Indii, kde byl sestaven početní devítičíslicový systém (obr. 2.1).

Obr. 2.1. První kalkulátor

Strana 8

2. Stručný pohled do historie IS

2. Mechanická doba 1450–1840 První informační exploze se datuje ke vzniku knihtisku Johannem Guttenbergem (Mainz, Německo) roku 1450. Vývoj knih, číslování stránek a indexování. Vývoj početních metod vyústil vznikem posuvného měřítka (obr. 2.2) Paskalova a Leibnizova početního stroje (obr. 2.3 a 2.4).

Obr. 2.2. Posuvné měřítko

Obr. 2.3. Model Paskalova stroje


Strana 9

Obr. 2.4. Leibnizův početní stroj

V průběhu roku 1830 byl navržen Josephem Marie Jacquardem tkalcovský stav (obr. 2.5), který až pozoruhodně připomíná architekturu počítače dnešních dnů. Jacquard obnovil myšlenku Charlese Babbage a využil metodu děrných štítků k vytvoření vzoru na látce. Představena roku 1801. Zavedení pojmu binární logika. Pevný program schopný pracovat v reálném čase.

Obr. 2.5. Tkalcovský stav navržený Josephem Marie Jacquardem

Strana 10


3. Elektromechanická doba 1840–1940 V průběhu této periody byl objeven způsob, jak využít elektrickou energii, což byla klíčová cesta dalšího postupu. Znalosti a informace mohou být nyní konvertovány na elektrický impulz. Nastal rozvoj telekomunikací. Vynález voltické baterie, telegrafu, Morseovy abecedy a telefonu. S objevem elektromagnetického vlnění, které se šíří prostorem a dokáže vyvolat efekt daleko od místa vzniku, byl jen krůček k vynálezu rádia (Guglielmo Marconi).“ [10] Jedním z prvních využití elektromechanického zpracování dat byl vynález Hermana Holleritha (obr. 2.6), německého přistěhovalce do USA. Jeho stroj (obr. 2.7) dokázal zpracovat data ze sčítání lidu ve Spojených státech roku 1890 za neuvěřitelně krátkou dobu, a to šest týdnů oproti ručnímu zpracováni z roku 1880, které trvalo celých sedm let.

Obr. 2.6. Herman Hollerith

Obr. 2.7. Hollerithův stroj

„Herman Hollerith vyhrál roku 1890 konkurz u Amerického statistického úřadu se svým rok starým návrhem na využití děrnoštítkového stroje. Výsledky byly při nárůstu nákladů pouhých 100 procent impozantní. Na první pohled se nyní zdá, že nešlo o žádné databáze. Opak je pravdou, genialita tohoto vědce spočívala v myšlence použít již existující děrné štítky nikoli jako prostředek pro předpis programu, ale jako nosiče dat. Tedy dat obsahujících informace, které statistický úřad zajímaly. V děrném štítku o velikosti tehdy platné jednodolarové bankovky představovala jedna vyražená dírka číslici, dvě pak jedno písmeno. Z databázového pohledu přitom nebyla důležitá ani tak samotná rychlost zpracování, jako možnosti plynoucí z dlouhodobého uložení dat“. [7]


Strana 11

„Roku 1890 došlo k založení jednoho z nejdůležitější hráčů na poli informačních technologií – společnosti IBM (The International Business Machines Corporation).

Obr. 2.8. První logo společnosti IBM

4. Elektronický věk 1940–doposud Elektronický věk se dá rozdělit do čtyř generačních částí. První generace elektronkových počítačů, jejichž hlavním logickým členem byla právě elektronka (obr. 2.8). Děrné štítky se využívaly k vložení a externímu uložení dat i programu. Rotační magnetické válce k internímu uložení dat a programu. Programy byly psány ve strojovém kódu.

Obr. 2.8. Elektronkový segment počítače první generace

Strana 12


V druhé generaci počítačových systémů nahradily elektronky tranzistory jako hlavní logický člen (obr. 2.9). Magnetické pásky a disky nahradily děrné štítky jako hlavní médium uložení dat. Magnetické jádro (miniaturní magnety, které mohou být zmagnetovány jedním ze dvou nasměrování reprezentujících binární hodnotu) interních pamětí fungovalo jako úložiště dat a programu. Nastoupila vyšší úroveň programovacích jazyků Fortran a Cobol.

Obr. 2.9. Tranzistorový segment počítače druhé generace Třetí generace znamenala integraci jednotlivých tranzistorů do integrovaných obvodů a jednotlivých částí do samostatných jednotek (obr. 2.10). Magnetické pásky a disky vytlačily děrné štítky z pozice média externího uložení dat. Nastává doba operačních systémů. Vylepšené programovací jazyky, jako Basic. Počátek éry Microsoftu v roce 1975.

Obr. 2.10. Hlavní rámec výpočetního střediska třetí generace


Strana 13

Čtvrtá generace přináší nové technologie integrací tranzistorů na křemíkové destičky v počtech statisíců. Vznikl mikroprocesor, který jako jedna součástka obsahuje paměť, logické obvody a ovládací okruh – CPU = Central Processing Unit. Tento zlom přináší zmenšení celého počítače na stolní verze PC a jeho hektické rozšíření do všech oblastí života. Následuje nová generace programovacích jazyků a softwarových produktů, jako například Lotus, Microsoft Word, dBase a mnoho dalších. GUI – Graphical User Interfaces, tedy grafické uživatelské rozhraní. Tento zlom v myšlení návrhu operačních systémů a uživatelských programů obecně přinesla firma Microsoft, čímž udala nový směr.“ [10]

Obr. 2.11. OS Windows XP

Obr. 2.13. OS Linux

Obr. 2.12. MAC OSX

Obr. 2.14. OS Amiga TOS

Strana 14


2.2 Úvod do databázových systémů Databáze jako pojem je slovo poměrně lehce zavádějící, ale v rámci této práce se jím rozumí skupina informací uspořádaných podle určitých pravidel tak, aby následná práce s nimi byla co nejefektivnější. Za databázi je považováno pouze ono skladiště dat, ve kterých jsou data uložena a zpracovávána nezávisle na aplikačních programech. Pro samotný přístup k datům uloženým v databázi je používán speciální software. Nazývá se anglicky Database Management Systém (DBMS), česky Systém řízení báze dat (SŘBD). Fyzická struktura uložených údajů potom nemusí být aplikačnímu programu, a tím pádem ani uživateli, vůbec známa. Databázový systém je pojmem, který zastřešuje samotné údaje spravované v databázi společně se softwarem pro přístup k těmto údajům. Historicky se vyvinuly tři hlavní databázové modely: - hierarchický; - síťový; - relační. Nejstarší z uvedených je hierarchické modelování databází. Toto pojetí pochází z reálného uspořádání světa. Základem hierarchického modelu je stromová struktura, kde výchozím prvkem je kořen (kořenový uzel, v každém systému existuje právě jeden) a na větvích jsou pak umístěny uzly, respektive listy, pokud již tyto neobsahují žádnou další větev. Právě větve obsahují vlastní datové struktury. „Důležité je, že uzly mohou být propojeny nejen v klasickém hierarchickém vztahu rodič–syn, ale také v rámci jedné úrovně. Tato skutečnost se podílí i na usnadnění vyhledávání – není nutno prohledávat celý objem dat, ale pomocí „přesné“ navigace po větvích a listech nelézt požadovanou informaci. Pochopitelně v propojení zůstává i nadále omezení na jednosměrnost vazeb 1:N (jeden potomek má jen jednoho rodiče). Jednou z hlavních výhod tohoto databázového modelu je vedle zefektivnění vyhledávání také odklonění se od fyzického modelu – autory aplikací nemusí vůbec zajímat, jak jsou data fyzicky uložena. Pro realizaci hierarchického modelu se obvykle využívají zřetězené seznamy. Mezi hlavní omezení hierarchického modelu patří v případě změny požadavků nutnost přepracování celé struktury databáze, jinými slovy nestačí pouze ubrat či přidat jednu položku. Značným omezením je také již zmíněná komplikovanost při realizaci vazeb N:M, která je sice řešitelná, ovšem pomocí redundantních přístupů a cyklických vztahů. Tento databázový model je vhodný především pro aplikace, které zpracovávají data založená na hierarchické struktuře, ke kterým patří například organizační či skladové systémy (pochopitelně je možné je realizovat výhodněji i pomocí novějších modelů).“ [8]

„Podstatou síťového modelu je použití ukazatelů vyjadřujících vztahy mezi jednotlivými databázovými položkami. Vzhledem k tomu, že tyto ukazatele mohou být lineární i cyklické a svým způsobem mohou vyjadřovat skutečné vztahy mezi objekty v databázi (tedy objekty reprezentujícími reálné objekty skutečného světa), lze poměrně snadno pomocí síťového modelu realizovat vztahy N:M, i když ve složitějších případech to znamená vysokou režii. Vyhledávání konkrétního údaje není v rámci síťového modelu nijak složité, stejně jako v případě vyhledávání odvozených hodnot – začít je možno prakticky kdekoli v rámci daného modelu. Na druhou stranu i síťový


Strana 15

model trpí podobnou nevýhodou jako model hierarchický. Tímto handicapem jsou omezení ve změnách struktury databáze. V mnoha případech musí autor aplikace znovu vytvořit celý databázový model, i když oproti hierarchickému modelu je toto omezení méně restriktivní. Přestože se síťový databázový model dočkal v letech následujících po své první specifikaci (1971) celé řady rozšíření a standardů (poslední byl přijat roku 1984), neexistuje prakticky žádná větší komerčně dostupná implementace. Důvod je prostý, velkého zájmu se od poloviny sedmdesátých let začal těšit relační databázový model.“ [8]

„Relační model je v současné době jednoznačně nejrozšířenějším způsobem uložení dat v databázi (stejně jako v případě předchozích modelů ve smyslu logického uložení). Jeho kořeny spadají již do konce šedesátých let, kdy v roce 1969 seznámil doktor E. F. Codd veřejnost se svou představou o databázi založené na matematickém aparátu relačních množin. Ve své podstatě šlo o to, že stačí vzít množinu například osob, množinu rodných čísel a množinu dat narození a z nich vytvořit kartézský součin reprezentující možné vazby mezi jednotlivými množinami. Zjednodušeně řečeno je pak tedy možno za relaci považovat podmnožinu tohoto kartézského součinu odpovídajícího skutečnosti, případně kartézský součin celý (formálně je totiž relací libovolná podmnožina tohoto kartézského součinu). Relační model přináší celou řadu výhod, zejména mnohdy přirozenou reprezentaci zpracovávaných dat, možnost snadného definování a zpracování vazeb apod. V souvislosti s relačním modelem se nejčastěji setkáváme s pojmem tabulka, který se mnohdy chybně považuje za synonymum relace. Ale není tomu tak – tabulka je vlastně konkrétní reprezentací dané relace, například právě ve formě výstupu na monitor. Velkým přínosem relačního modelu je fakt, že klade velký důraz na zachování integrity zpracovávaných dat a zavádí pojmy, jako jsou referenční integrita, cizí klíče, primární klíče apod. Je dlužno poznamenat, že ne vždy musí platit, že relační model je nejrychlejším možným způsobem uložení dat – například v datových skladech tomu bývá mnohdy jinak (využívají se tzv. multidimenzionální databáze). Pro úplnost dodejme, že v současnosti je dále využíván objektový a objektově-relační přístup k databázím.“ [8]

Strana 16


2.3 Dotazovací jazyky

S relačními databázovými systémy se samozřejmě začaly vyvíjet a postupně zdokonalovat dotazovací jazyky. V praxi se můžeme setkat se dvěma koncepty dotazovacích jazyků: - koncept QBE (Query By Example); - koncept SQL (Structured Query Language). Při práci s QBE jde spíše o jednoduchý zápis dotazu do navrženého schématu (formuláře) než o „programování“. Koncept QBE tak umožňuje rychle vytvářet dotazy i běžným uživatelům, nejen odborníkům. Původní vznik konceptu QBE byl spojen s firmou IBM už v 70. letech, později jej uplatnila velmi kvalitně firma Borland v produktu Paradox. V letech 1974 až 1975 probíhal ve firmě IBM výzkum týkající se možnosti využití relačních databází. Pro tento projekt vznikl jazyk SEQUEL (Structured English Query Language), který měl co nejvíce napodobovat běžný jazyk (angličtinu). IBM svůj jazyk dále vylepšoval a začaly vznikat i databázové platformy dalších firem. V těchto systémech se používaly různé verze jazyka SEQUEL, který se později přejmenoval na SQL. Jazyk SQL byl postupně přijat jako standard různými výrobci databázových aplikací a stal se tak spojovacím článkem mezi různými systémy. V koncepci klient–server se dotazy specifikují na straně klienta, odesílají na stranu serveru, který dotaz v jazyce SQL realizuje a výsledek pošle zpět uživateli na straně klienta. Většina významných databázových platforem dnes jazyk SQL podporuje. Vzrůstající význam relačních databází si vyžádal nutnost standardizace. A tak byl v roce 1986 Americkým standardizačním institutem (ANSI) přijat nový standard SQL-86, který měl však některé nedostatky a tak byl v roce 1992 přijat standard SQL92 (nebo také SQL2). V současnosti je v platnosti norma SQL3, která reaguje na poslední trendy vývoje v databázových technologiích (např. využívání objektů apod.). Jazyk SQL můžeme částečně využít pro samotný vývoj databázových aplikací, ale jinak slouží především jako dotazovací jazyk pro práci s údaji v relační databázi. Jazyk SQL se totiž skládá ze dvou základních částí. První je DDL, tedy Data Definition Language, druhá pak DML, tedy Data Manipulation Language. Příkazy DDL slouží pro definici databázových struktur, jako jsou tabulky, indexy, pohledy, snímky atd. Jedním z DDL příkazů je např. CREATE TABLE. V tomto případě tedy nejde o pokládání dotazů v pravém slova smyslu. Příkazy druhé skupiny již opravdu slouží pro „manipulaci“ s daty, jejich výběr, modifikaci, mazání apod. Nejznámějším DML příkazem je příkaz SELECT sloužící k selekci.

Strana 17

3. Popis externího skladu logistické společnosti V zadání bakalářské práce se hovoří o návrhu a realizaci informačního systému pro externí sklad logistické společnosti. Aby bylo možno tuto problematiku názorněji popsat z hlediska dalšího rozboru, je třeba vysvětlit některé pojmy, které se budou dále vyskytovat.

Logistická společnost – firma zabývající se organizací a fyzickým prováděním skladových a dopravních služeb pro svoji klientelu. Zpravidla vlastní skladové plochy, technologie, manipulační prostředky popřípadě i vlastní dopravní systém.

Externí sklad (dále jen sklad) – sklad obvykle zřízený mimo vlastní logistické centrum, a to zejména na pokrytí okamžitých potřeb konkrétního obchodního případu. Mnohdy se může jednat o mezisklad zřízený přímo u klienta ve výrobním podniku nebo o jednorázovou sezonní záležitost (sklad vybavení větších stavebních projektů atp.). Časem může dojít po sjednání dlouhodobějšího kontraktu nebo úspěchem daného obchodního případu k sjednocení a trvalému zavedení oddělení skladu tzv. pod jednu střechu a systém v logistickém centru.

3.1 Zadání projektu meziskladu Výrobní podnik firmy Electrolux v Maďarsku dodává na základě hromadných předsezonních objednávek zboží do centrálního skladu Electroworld Česká Republika, Brno, a to vždy v období od srpna do ledna následujícího roku. Jednotlivé objednávky jsou vyskladňovány hromadně dle možností výroby. Přeprava je organizována po železnici nejmodernějšími vagonovými vozy o objemu více než 120 m3. Úkolem logistické společnosti je zřídit mezisklad, který bude schopen zboží přijímat z železnice a dále na základě konkrétních rezervací dodávat po jednotlivých silničních přepravních jednotkách na rampu centrálního skladu Electroworld tzv. just in time. Grafické zpracování nabízí obr. 3.1. Smluvní podmínky účtování: - skladné bude účtováno na základě aktuálně zabrané plochy v m2/den; - manipulace bude účtována na základě aktuálně zmanipulovaných m3 /den; - náklady za přistavení železničních vozů budou přeúčtovány dle skutečné výše za sjednané účetní období;

Strana 18

3. Popis externího skladu logistické společnosti

- náklady na přepravu budou účtovány dle sjednané ceny za přepravní jednotku, kterou je standardní návěs 13,5 m nebo sólo 6,2 m; - doplňkové služby, jako přebalování, vkládání návodů a záručních listů do výrobků, se účtuje dle smluvní ceny za kus, a to vždy za jedno účetní období; - účetním obdobím je v tomto případě jeden měsíc.

3.2 Cíl zadání tvorby informačního systému

Cílem zadání tvorby informačního systému meziskladu zboží firmy Electrolux určeného pro centrální sklad Electroworld Brno jsou zejména následující požadavky: -

evidence příjmů a výdejů z meziskladu; tisk dokladu k příjmu a výdeji; tisk inventurních sestav; evidence příjmů i výdejů jednotlivých přepravních jednotek včetně identifikace typu a druhu dopravy; automatické dělení přijaté dávky na vhodné silniční přepravní jednotky; evidence doplňkových služeb; výpočty skladného, manipulací a doplňkových služeb; tisk podkladu pro vyúčtování za zúčtovací období (přílohy k faktuře).

3.3 Očekávané přínosy Zavedením informačního systému dojde ke zrychlení práce obsluhy skladu, zprůhlednění toku zboží a v neposlední řadě k rychlému, efektivnímu a přesnému vyúčtování za poskytované služby. Hlavní úspory budou v lidských zdrojích a kancelářských potřebách na administrativní činnosti. Nedílnou součástí je zvýšení pružnosti při komunikaci s klientem a zejména rychlosti zpracovávání jeho požadavků. Pro vedoucí pracovníky přinese nasazení informačního systému jednoduchou formu kontroly a přehledu vykonaných prací včetně možnosti provádění bleskových inventur v případě změny obsluhy skladu nebo standardní inventury po daném období. Z obchodně-strategického hlediska přinese systém jednoduchou možnost přehledu výkonu a fakturace. Z dopravně-organizačního hlediska přinese systém automatizaci rozložení a tedy plánování silničních dopravních jednotek.


Strana 19

Hromadná objednávka

Obchodní oddělení Electrolux CZ, Praha

Centrální nákup řetězce Electroworld Harmonogram plánu expedice

Výrobní podnik Maďarsko Vyexpedovaná dávka (železnice)

Potvrzení přijetí dávky a sdělení počtu silničních jednotek na dávku

Mezisklad Brno (externí sklad)

Provozní oddělení Electrolux CZ, Praha Zadání termínu expedice

Dílčí dávky (silnice)

Centrální sklad Electroworld Brno Objednávka přijetí dílčích dávek

Zadání času přijetí dílčích dávek

Obr. 3.1. Grafické znázornění funkce meziskladu

Strana 20


3.4 Kritéria návrhu Dříve než přejdu k rozboru zadání, rád bych ještě stanovil kritéria návrhu. Je to nedílnou součástí celého projektu, neboť není nic „důležitějšího“ než vědět, kdy jsme vlastně s prací hotovi. Je běžným nešvarem na všech úrovních lidského konání, že při zabřednutí do problematiky se mnohdy ztratí pojem o včasném ukončení a požadované funkčnosti zpracovávaného projektu. Příklad z vlastní zkušenosti. Při zpracovávání podpůrné aplikace operačního řízení dispečinku vnitrostátní sběrné služby jsem v jisté fázi neustále zdokonaloval vzhled a ovládací prvky formulářů SŘBD a přitom zapomněl, že systém byl již funkční, mohl pracovat a splňoval cíl, tedy rychlé a přesné sjednocení dat o zásilkách k plánování. Poučení z toho plynoucí je, abychom nedělali nad rámec cíle a měřitelného kritéria – stejně nám to nikdo nezaplatí. V rámci projektu této bakalářské práce bych definoval jako hlavní kritéria následující: - čas potřebný k vyúčtování, měsíční uzávěrce zkrátit na max. 10 minut; - veškeré sestavy požadované v cílech lze tisknout.

Splněním těchto požadavků lze projekt považovat za ukončený v rámci rozsahu této práce. Neznamená to však, že nebude dále vyvíjen a vylepšován, protože se nejedná jen o pouhou teoretickou demonstraci, ale pravděpodobně je jedním z mála bakalářských projektů, který bude opravdu fyzicky nasazen k praktickému využití.

Strana 21

4. Rozbor zadání Jedna věc je od začátku jasná: „srdcem“ systému bude databáze. Účelem systému bude uchovávat, zpracovávat a zpřístupňovat data, o jiném řešení se zde neuvažuje. Základem systému tedy bude databáze. Hovořím-li takto rozhodně o databázi, vycházím z prapodstaty databáze, což je vlastně virtuální sklad. Sklad dat, ze kterých je možno skládat cenné informace. Úkolem zadaní je vytvořit informační systém pro sklad elektrospotřebičů, tedy asociace mezi fyzickým skladem a bází dát je nasnadě. Databáze bude virtuálním odrazem fyzického skladu. Jako příklad analogie lze uvést inventuru skladových položek. Tu lze provést fyzicky spočtením všech položek skladu, nebo popřípadě vhodným algoritmem vytáhnout z databáze. Pominu-li zde hodnotu těchto dvou odlišně získaných informací a tedy porovnám jen metodu provedení, tak každému je zajisté ihned zřejmé, jak dlouho budeme počítat stovky kusů výrobků, pokud se nám to vůbec povede, oproti získání přesného údaje z databáze. Z předchozích kapitol této bakalářské práce, kde jsem ve zkratce představil základní struktury databází, v podstatě vyplývá, že pro implementaci využiji dnes nejpoužívanější a nejpodporovanější model, tedy databázi relační. Další úvaha se bude týkat umístění této databáze. V první chvíli každého možná napadne zachovat se v souladu s módou a umístit databázi (a vlastně celou aplikaci) na internet. Tímto řešením bych asi nic zásadního nepokazil, ale na druhou stranu bych příliš celé věci neprospěl. Proč? Vzhledem k tomu, že databáze poběží buďto celá na lokálním počítači v případě, že sklad bude otevřen v prostorách bez přístupu na firemní síť, popřípadě bude realizována varianta klient–server, a to v případě dostupnosti firemní sítě, nač tedy vytvářet krkolomný model, který si žádá v obou případech instalaci databázového i webového serveru a příslušného skriptovacího interpreta. Umístnění na internet by bylo vhodné pouze v případě, že by sklad měl být nastálo provozován mimo dosah firemní sítě, šlo by zajistit spolehlivé připojení k síti internet a on-line přístup k datům by byl vyžadován na mnoha různých místech země. Shrnuto: jádrem informačního systému bude relační databáze, která nebude provozována webovou technologií.

4.1 Volba softwarové platformy Již v předešlé kapitole jsem naznačil, kterým směrem se bude ubírat návrh informačního systému výše popsaného sklad. Volba softwarové platformy je v tomto případě relativně jednoduchou záležitostí, a to s ohledem na zavedený softwarový systém logistické společnosti, pro kterou je systém určen. V této společnosti jsou zakoupeny multilicence MS Office a operační systém Windows 2000 Professional. Na firmě rovněž funguje informační systém v rámci oddělení dopravy a zasilatelství. V omezené míře také logistické projekty. Provozovaný databázový server je MS server 2003. SŘBD (systém řízení báze dat) je naprogramován a funguje v obou případech v Access 2000. Mnou navrhovaný systém bude provozován v odštěpném závodě Brno, kde je v provozu připojení k zmíněnému dopravnímu systému a ve dvou případech také

Strana 22

4. Rozbor zadání

logistické projekty. Navrhovaný systém musí vyhovovat podmínce minimálních nákladů, tedy provoz na stávající platformě a s případnou možností převodu databáze na MS server 2003. Proč vyvíjet nový SŘBD, když ve firmě již logistický projekt existuje? Odpověď je jednoduchá. Logistický projekt je zaměřen na komplexní distribuční služby pro obchodní společnosti a nevyhovuje výše specifikovaným požadavkům na mezisklad pro firmu Electrolux. Je to řešení příliš „robustní“ a přitom úzce zaměřené. Na jaké platformě pracoval mezisklad doposud? Celé skladové hospodářství se provozovalo na tabulkovém procesoru Excel 2000 (obr. 4.1). Nevýhod tohoto řešení je mnoho, vyjmenuji tedy jen ty zásadní: - příliš mnoho dat v souborech. Data je obtížné zpracovat, navíc mohou zaplnit a tím omezit systémovou paměť; - více pohledů na data. V případě, že potřebuji získat jiný pohled na data, jako jsou například analýzy výkonu, dotazy typu „co kdyby“, je toto velmi obtížné nebo mnohdy nemožné; - sdílení dat. Potřebuji, aby s daty mohlo pracovat zároveň více lidí, a to každý z jiného pohledu. Obsluha skladu zadávání údajů. Vedoucí skladu reporty pro zákazníka či vedoucího logistiky. Dopravní oddělení přehled dílčích dávek k odvozu atp.; - nedůvěryhodnost dat. Vzhledem k tomu, že s daty pracuje každý uživatel přímo na fyzické úrovni. Stačí, aby třeba omylem přepsal či smazal jakoukoliv hodnotu a výsledky výpočtů jsou nepravdivé. V zakládání nových listů pro nové měsíce dochází ke kopírování polí včetně vzorců, což mnohdy způsobuje nesprávné odkazy na buňky ve vzorcích; - nutnost kontroly datové konzistence.

Obr 4.1. Současné skladové hospodářství

4. Rozbor zadání

Strana 23

Přestože má stávající systém většinou samé nevýhody, pokusím se najít nějakou výhodu. Myslím, že jedinou je relativní jednoduchost, kdy i pouhý středně znalý uživatel dokáže v případě náhlé potřeby změnit rámec zadávání dat. Závěrem bych shrnul podstatné údaje z této kapitoly. Databáze i SŘBD budou navrženy a naprogramovány v ACCESS 2002, ovšem uloženy jako aplikace verze 2000. V současnosti bude systém provozován jako klient–server, kdy databáze bude uložena na files serveru odštěpného závodu Brno a jednotliví klienti, tedy obsluha skladu, vedoucí skladu, vedoucí logistiky, dispečer vozových přeprav a obchodník, k ní budou připojeni přes firemní síť Ethernet Base 10T. Nebude problém celý systém kdykoliv přenést na jeden počítač v případě nasazení na sklad mimo dosah firemní sítě a synchronizaci dat zajistit vhodným přenosem. Výstupy v podobě fakturačních podkladů, příloh k fakturám se v tištěné podobě předávají do účtárny odštěpného závodu Brno k zaevidování, předfakturaci a odeslání do centrální účtárny Praha, kde jsou data ručně vložena do účetního systému Nvision a teprve z něj tištěny faktury.

4.2 Metodika zpracování datových struktur V první fázi je třeba shromáždit veškeré dostupné údaje tak, abychom mohli začít s identifikací entit, atributů a vztahů. Tato první fáze se sestává z podrobného seznámení se s prostředím skladu, pracovními procesy, řídicí strukturou firmy a potřebami všech spolupracujících oddělení. V neposlední řadě je třeba znát potřeby a možnosti uživatelů. Vzhledem k tomu, že ve firmě pracuji na postu vedoucího logistiky, jsem v tomto případě zároveň nejpovolanější osobou, která může výše uvedené informace prezentovat. Je to samozřejmě velká výhoda být zadavatel, uživatel, tvůrce pracovních procesů v oddělení skladu a tvůrce informačního systému v jedné osobě. Tímto si mohu dovolit přeskočit fázi rozhovorů, exkurzí a mapování prostředí, pro které je systém navrhován, a rovnou přejít k další části. Následujícím úkolem bude sestrojit konceptuální model. Konceptuální či sémantické modely jsou pokusem umožnit vytvoření popisu dat v databázi nezávisle na jejich uložení. Konceptuální model představuje formální popis modelované reality. Hlavními úkoly je nalezení entit, vztahů a atributů. Sémantické modely slouží obvykle k vytvoření schémat s následnou transformací na databázové schéma. Spojíme-li sémantickou a databázovou úroveň, dostáváme se k tzv. objektově-orientovaným SŘBD. Posledním krokem bude vytvoření E-R diagramu (entity relationship diagram). Kvalitně a správně vytvořený digram je zárukou dobrého základu pro konstrukci databáze a samozřejmě je i úzce spjat s návrhem systémemu řízení báze dat. Přeskočení nebo nedostatečná péče tomuto zásadnímu modelu datové struktury by nás mohla později stát hodiny a hodiny práce nad změnou struktury relačního schématu nebo SŘBD jen proto, že jsme zapomněli implementovat některou důležitou entitu, proces či parametr. Po ukončení těchto fází zpracování datových struktur můžeme přistoupit k fyzické tvorbě databáze v prostředí ACCESS 2002.

Strana 24

4. Rozbor zadání

4.3 Konceptuální datový model

Myšlenkový neboli konceptuální datový model obsahuje popis jednotlivých entit, jejich atributů a vztahů mezi nimi. Není to totéž, co databázové schéma, které popisuje fyzické rozvržení tabulek. K vytvoření databázového schématu zatím není dostatek informací. Nejprve musím pochopit strukturu uživatelského rozhraní a architekturu, v níž budu systém implementovat, a pak se pustím do jeho návrhu. Prvně vypíši veškeré známe objekty, procesy a dokumenty, které mají co do činění s chodem skladu. Neznamená to, že veškeré objekty budou do systému implementovány jako entity. Použiji jen ty, které mají z hlediska cíle návrhu nějaký smysl. Například objekt manipulační technika nemá v tomto případě žádný význam včleňovat do systému, neboť nemá žádnou vazbu na činnost ani výstupní dokumenty. V případě, že bych do systému implementoval také evidenci inventáře skladu, přehled údržby majetku nebo jeho amortizaci, měl by tento objekt význam. Každopádně do níže uvedené množiny všech objektů patří: množina objekty:

sklad, skladová položka, skladník, manipulační technika, klient, dispečer, přepravní jednotka, řidič, zákazník;

množina procesy:

příjem, výdej, inventura, rozdělení na dílčí dávky, vychystání, kontrola, potvrzení, měřit, vážit, balit, etiketovat, vkládat, třídit, manipulovat, zadávat nové položky, tisknout výstupy, přihlašovat se, umistňovat;

množina dokumenty: příjemka, výdejka, inventurní seznam, plán rozložení na dílčí dávky, potvrzení přijetí, měsíční vyúčtování.

Nyní je třeba ze seznamu separovat jednotlivé entity jejich atributy a vztahy mezi nimi. Jak jsem již výše naznačil, ne všechny objekty jsou vhodné entity. V tomto stadiu návrhu je nejlepším nástrojem tužka a papír, kdy lze škrtat, gumovat a kreslit vazby. Z uvedeného procesu jsem separoval následující entity a jejich atributy (záměrně již v názvech nepoužívám diakritická znaménka).

Sklad (id_skladu, id_jednotky, nazev_firma, nazev_oddeleni, typ) Skladova polozka (id_polozky, id_umistneni, nazev_polozky, pocet_v_baleni, hmotnost_baleni, vyska, sirka, delka) Osoba ( id_osoby, id_prijemky, pozice, jmeno, prijmeni, telefon, heslo) Subjekt (id_subjektu, jméno, ulice, mesto, psc, telefon, dic) Prepravni jednotka (id_jednotky, id_provedeni registracni_znacka, typ, max_nosnost, vyska, sirka, delka) Umistneni (id_umistneni, id_skladu ) Prijemka (id_prijemky, id_polozky, id_subjektu, datum_provedeni, datum_vystaveni, cislo_faktury, cislo_dl, pocet_ks, poznamka)

4. Rozbor zadání

Strana 25

Vydejka

(id_vydejky, id_polozky, id_subjektu, datum_provedeni, datum_vystaveni, cislo_bookingu, cislo_dl, pocet_ks, poznamka ) Sluzby (id_sluzby, nazev_sluzby, jednotkova_cena, jednotka) Provedeni sluzby (id_provedeni, id_sluzby, datum, mnozstvi)

Výše uvedené relační schéma vzniklo na základě čistě myšlenkové konstrukce a je výsledkem úvahy nad nezbytně nutným množstvím entit a jejich atributů. Stavěno je na analýze, množině procesů, objektů a dokumentů. Prozatím nemá nic společného s fyzickým uložením dat. V následujícím kroku přistoupím k tvorbě E-R diagramu, k čemuž použiji ryze český softwarový produkt CASE Studio 2.23. Tento program je v demoverzi volně ke stažení na internetu. Nevýhodou demoverze je, že umožňuje uložení návrhu maximálně o šesti entitách. Jednorázově lze vytvořit složitější schéma s využitím všech funkcí. Vývojoví technici tohoto produktu jsou z Ostravy a celý je tvořen v prostředí Delphi. Jeho hlavní předností je zejména podpora dvaceti databázových platforem, možnost zpětné tvorby modelu ze starší funkční databáze a generování SQL kódu k pohodlnému a rychlému vytvoření báze dat ve zvolené platformě. Samozřejmostí jsou funkce podporující zajištění integrity dat, identifikace primárních a cizích klíčů, verifikace návrhu atp. Program umožňuje také tvorbu D-F diagramu Data Flow Diagram).

4.4 CASE Studio 2 – nástroj pro návrh databází „CASE Studio 2 CZ je profesionální software pro vizuální navrhování databázových struktur – jinak a jednoduše řečeno „Database modeler“ či „Database designer“. Klíčové vlastnosti zahrnují: -

E-R diagramy (Entity relationship diagrams); podporu pro různé databáze; generování SQL (DDL) scriptů; reverse engineering (zpětné načtení struktury); generování velice detailní HTML a RTF dokumentace; export do XML formátu apod.

Entitně relační diagramy (ERD) Pomocí graficky velmi přehledných entitně relačních diagramů můžete zcela snadno vytvořit strukturu databází. Ve svých modelech tak budete mít přehledně zobrazeny veškeré entity, atributy, domény, primární klíče, foreign klíče, constrainty, relace, ale také poznámky a další fyzická a logická data. Při vytváření modelů budete mít dokonalý přehled o veškerých prvcích databáze. Jednoduše si můžete stanovit hodnoty všech atributů, typy relací a další kritéria, jako např. indexy apod. CASE Studio 2 CZ je komplexním produktem, který plně podporuje většinu specifik jednotlivých databází.

Strana 26

Jaký je přínos takového nástroje?

-

profesionální a rychlý vývoj; zvýšení produktivity; menší procento chyb při vývoji; velice efektivní údržba; práce s již existujícími databázovými strukturami; testování konzistence a platnosti modelu; tvorba důkladné dokumentace; triggery, procedury, pohledy aj.

CASE Studio 2 podporuje také Funkce, Procedury, Triggery, Pohledy, Packages, Package bodies, Object type bodies, Sekvence a Synonyma jako Textové objekty (v závislosti na vybrané databázi). CASE Studio 2 umožňuje vytvořit šablony/vzorky pro triggery, pohledy a procedury. Veškeré Textové objekty jsou také načítány během reverse engineeringu.

Podporované databáze Access 2000, Access 97, Advantage 7, Advantage 8, Clipper 5.0, DB2 UDB v.7, DB2, UDB v.8, DBIsam 3, Firebird, Informix 10, Informix 9, Informix, Ingres, Interbase 4, Interbase 5, Interbase 6 SQL 1, Interbase 6 SQL 3, Interbase 7, MaxDB 7.5, MaxDB 7.6, MS SQL 2000, MS SQL 2005, MS SQL 6.5, MS SQL 7, mySQL 3.23, mySQL 4.0, mySQL 4.1, mySQL 5, Oracle 10g, Oracle 8, Oracle 9i, Paradox, Pervasive V8, Pervasive v9, PostgreSQL 7.3, PostgreSQL 7.4, PostgreSQL 7, PostgreSQL 8.0, PostgreSQL 8.1, Sybase Anywhere 9, Sybase Anywhere, Sybase ASE 12.5.3, Sybase, ASE 12.5, Sybase ASE 15.“ [9]

Strana 27

5. Praktická tvorba báze dat

Praktickou tvorbu báze dat jsem rozčlenil do třech částí. Modelování ERD diagramu ve výše popsaném programu, fyzická implementace relační báze dat a ošetření integrity dat.

5.1 Modelování CASE studio 2.3 CZ

Modelování jsem začal vytvořením entit jejich atributů a definováním primárních klíčů. Následoval jeden z nejdůležitějších kroků, a to tvorba relací. Relace jsem vytvořil opět na základě konceptuálního modelu. Před započetím modelování jsem definoval jako výchozí databázovou platformu Access 2000. Program automaticky při tvorbě relace M:N nadefinoval nutnou propojovací entitu. Výsledkem mého snažení je E-R diagram znázorněný na obr. 5.1.

Obr. 5.1. Entity Relationship Diagram zpracovávaného meziskladu

Strana 28


Po vytvoření diagramu následoval další krok, a to verifikace modelu. Verifikace je jedna z chytrých pomůcek CASE Studia a pomůže odstranit případné zásadní chyby modelu. Upozornění, že návrh není zcela v pořádku, se dělí do tří hlavních skupin: - errors – zásadní chyby relačního návrhu; - warnings – upozornění na nesprávný návrh; - hints – rada, co není zcela v pořádku. Výsledek verifikace výše zobrazeného návrhu meziskladu je patrný z obr. 5.2. Tato pomucká se při návrhu relačního schématu velmi dobře osvědčila, protože mě upozornila na opomenutí definování primárního klíče u několika entit.

Obr. 5.2. Verifikace návrhu


Strana 29

5.2 Fyzické databázové schéma

V průběhu modelování došlo ke změně či doplnění některých atributů, rozdělení některých entit, přidání některých entit, které jsou nezbytně nutné k vytvoření M:N vazeb a zejména definici primárních i cizích klíčů zajišťujících propojení a integritu dat mezi jednotlivými entitami. Po kontrole a verifikaci modelu jsem přistoupil k vygenerování stavebního SQL kódu, který stačilo přenést do modulu prázdné databáze Accessu a spustit jej. Výsledkem je vytvoření báze dat (obr. 5.3). Vytvořeny jsou tabulky, relace, definovány klíče i datové tipy jednotlivých atributů. Ukázka části vygenerovaného kódů je uvedena níže.

Obr. 5.3 Relační schéma vygenerované z modelu Case a uložené v Access databázi.

Zápis definované relační struktury uvádím níže pro případné porovnání s konceptuálním modelem. Sklad (id_skladu, nazev) Skladova polozka (id_polozky, nazev_polozky, pocet_v_baleni, hmotnost_baleni, vyska, sirka, delka) Osoba (id_osoby, pozice, jmeno, prijmeni, telefon, heslo) Subjekt (id_subjektu, jméno, ulice, mesto, psc, telefon, kontakt, dic)

Strana 30


Prijezd_jednotky (id_prijezdu, id_prijemky, id_prepravni_jednotky, reg._znacka, ridic) Odjezd_jednotky (id_odjezd_jednotky, id_vydejky, id_prepravni_jednotky, reg._znacka, ridic) Umistneni (id_umistneni, adresa_umistneni) Sklad_oddeleni (id_skladu_oddeleni, nazev_oddeleni) Prijemka (id_prijemky, id_subjektu, id_osoby, datum_provedeni, datum_vystaveni, cislo_faktury, cislo_dl, poznamka) Vydejka (id_vydejky, id_subjektu, datum_provedeni, datum_vystaveni, cislo_bookingu, cislo_dl, poznamka) Sluzba (id_sluzby, nazev_sluzby, jednotkova_cena, jednotka, popis_jednotky, popis) Provedeni sluzby (id_provedeni, id_sluzby, datum, mnozstvi) Prijem (id_prijemky, id_prijmu, id_skladu, id_polozky, id_umisteni, mnozstvi_ks, id_skladu_oddeleni) Vydej (id_vydejky, id_vydeje, id_skladu, id_polozky, id_umisteni, mnozstvi_ks, id_skladu_oddeleni) Prepravni_jednotka (id_prepravni_jednotky, typ, nosnost, vyska, sirka, delka)

Část SQL vygenerovaného kódu z modulu VBA :

Public dbs As DAO.Database Public tdf As DAO.TableDef Public idx As DAO.Index Public rel As DAO.Relation Sub Main() Set dbs = CurrentDb() On Error GoTo ErrorHandler Call CreateTables Call CreatePrimaryKeys Call CreateIndexes Call CreateRelations MsgBox "Script successfully processed.", vbInformation Exit Sub ErrorHandler: Select Case Err.Number Case 3010 MsgBox "Table " & tdf.Name & " already exist!", vbInformation Err.Clear Case 3284 MsgBox "Index " & idx.Name & " for table " & tdf.Name & " already exist!", vbInformation Err.Clear


Strana 31

Case Else MsgBox Err.Description, vbCritical End Select End Sub ' Create tables '=============== Sub CreateTables() Call CreateTable3 'tab_Odjezd_jednotky Call CreateTable4 'tab_Osoba Call CreateTable5 'tab_Prepravni_jednotka Call CreateTable6 'tab_Prijem Call CreateTable7 'tab_Prijemka Call CreateTable8 'tab_Prijezd_jednotky Call CreateTable9 'tab_Provedeni_sluzby Call CreateTable10 'tab_Sklad Call CreateTable11 'tab_Sklad_oddeleni Call CreateTable14 'tab_Skladova_polozka Call CreateTable15 'tab_Sluzba Call CreateTable16 'tab_Subjekt Call CreateTable17 'tab_Umistneni Call CreateTable18 'tab_Vydej Call CreateTable19 'tab_Vydejka End Sub '=== Create table tab_Odjezd_jednotky ====== Sub CreateTable3() Set tdf = dbs.CreateTableDef( "tab_Odjezd_jednotky" ) Call AddFieldToTable("id_Odjezd_jednotky", dbLong, 0, dbAutoIncrField, "", "", "", FALSE, FALSE ) Call AddFieldToTable("id_vydejky", dbLong, 0, 0, "0", "", "", FALSE, FALSE ) Call AddFieldToTable("id_prepravni_jednotky", dbLong, 0, 0, "0", "", "", FALSE, FALSE ) Call AddFieldToTable("reg_znacka", dbText, 50, 0, "", "", "", FALSE, TRUE ) Call AddFieldToTable("ridic", dbText, 50, 0, "", "", "", FALSE, TRUE ) dbs.TableDefs.Append tdf Call AddPropertyToField( "reg_znacka","UnicodeCompression",true,dbBoolean) Call AddPropertyToField( "ridic","UnicodeCompression",true,dbBoolean) End Sub '=== Create table tab_Osoba ====== Sub CreateTable4() Set tdf = dbs.CreateTableDef( "tab_Osoba" ) Call AddFieldToTable("id_osoby", dbLong, 0, dbAutoIncrField, "", "", "", FALSE, FALSE ) Call AddFieldToTable("pozice", dbText, 50, 0, "", "", "", FALSE, TRUE ) Call AddFieldToTable("jmeno", dbText, 50, 0, "", "", "", FALSE, TRUE ) Call AddFieldToTable("prijmeni", dbText, 50, 0, "", "", "", FALSE, TRUE ) Call AddFieldToTable("telefon", dbText, 50, 0, "", "", "", FALSE, TRUE ) Call AddFieldToTable("heslo", dbText, 50, 0, "", "", "", FALSE, TRUE ) dbs.TableDefs.Append tdf

Strana 32


Call AddPropertyToField( "pozice","UnicodeCompression",true,dbBoolean) Call AddPropertyToField( "jmeno","UnicodeCompression",true,dbBoolean) Call AddPropertyToField( "prijmeni","UnicodeCompression",true,dbBoolean) Call AddPropertyToField( "telefon","UnicodeCompression",true,dbBoolean) Call AddPropertyToField( "heslo","InputMask","Password",dbText) Call AddPropertyToField( "heslo","UnicodeCompression",true,dbBoolean) End Sub '=== Create table tab_Prepravni_jednotka ====== Sub CreateTable5() Set tdf = dbs.CreateTableDef( "tab_Prepravni_jednotka" ) Call AddFieldToTable("id_prepravni_jednotky", dbLong, 0, dbAutoIncrField, "", "", "", FALSE, FALSE ) Call AddFieldToTable("typ", dbText, 50, 0, "", "", "", FALSE, TRUE ) Call AddFieldToTable("nosnost", dbSingle, 0, 0, "0", "", ">0", FALSE, FALSE ) Call AddFieldToTable("vyska", dbSingle, 0, 0, "0", "", ">0", TRUE, FALSE ) Call AddFieldToTable("sirka", dbSingle, 0, 0, "0", "", ">0", TRUE, FALSE ) Call AddFieldToTable("delka", dbSingle, 0, 0, "0", "", ">0", TRUE, FALSE ) dbs.TableDefs.Append tdf Call AddPropertyToField( "typ","UnicodeCompression",true,dbBoolean) End Sub '=== Create table tab_Prijem ====== Sub CreateTable6() Set tdf = dbs.CreateTableDef( "tab_Prijem" ) Call AddFieldToTable("id_prijemky", dbLong, 0, 0, "", "", "", TRUE, FALSE ) Call AddFieldToTable("id_prijmu", dbLong, 0, dbAutoIncrField, "", "", "", FALSE, FALSE ) Call AddFieldToTable("id_skladu", dbLong, 0, 0, "", "", "", FALSE, FALSE ) Call AddFieldToTable("id_polozky", dbLong, 0, 0, "", "", "", FALSE, FALSE ) Call AddFieldToTable("id_umistneni", dbLong, 0, 0, "0", "", "", TRUE, FALSE ) Call AddFieldToTable("id_skladu_oddeleni", dbLong, 0, 0, "0", "", "", TRUE, FALSE ) Call AddFieldToTable("mnoztvi_ks", dbLong, 0, 0, "", "Nelze přijmout nulové nebo záporné množstí.", ">0", TRUE, FALSE ) dbs.TableDefs.Append tdf

End Sub . . .

Kód samozřejmě pokračuje do vytvoření všech tabulek, relací, nastavení klíčů atd. Velkou výhodou je jeho uložení v modulu a případné nové vygenerování báze dat, kdykoliv je potřeba.


Strana 33

5.3 Integrita dat

Zachování integrity dat v databázi je jedním z velkých úkolů každého návrháře a programátora databázových systémů. Zajištění dokonalé věrohodnosti všech uložených dat je opravdu úkol mnohdy nad veškeré možnosti, ovšem každý dobrý návrhář by měl udělat maximum možného integritními omezeními a zachovat tak úroveň věrohodnosti na maximální úrovni. Datová integrita se implementuje na několika různých úrovních. Doménová, přechodová a entitová omezení definují pravidla pro údržbu integrity jednotlivých relací. Omezení referenční integrity zajišťují zachování potřebných vztahů mezi relacemi. Dalším typem jsou omezení databázové integrity, která kontrolují databázi jako celek, a omezení transakční integrity, která řídí způsob manipulace s daty buď v jedné databázi, nebo i mezi několika databázemi. Nejprve je třeba zaměřit se na nejnižší úroveň navrhovaného systému a tou je fyzické uložení dat. Na úrovni tabulek lze vhodnou volbou datového typu, vstupní masky, ověřovacích pravidel a uvážlivě zvolenou výchozí hodnotou dosáhnout omezení chybovosti a nepřesnosti uchovávaných dat. V prostředí Accessu lze výše jmenované nastavit příjemnou formou ve vlastnostech pole (obr. 5.4). Na tomto obrázku je vidět, že pole jednotková_cena v entitě služba je upraveno tak, aby nemohlo obsahovat zápornou hodnotu (dobropis) a musí to být číslo ve formátu měny s nutností vždy zadat hodnotu při definici nové služby. Důvod nutnosti zadání vyplývá z povinnosti, že každá služba musí být zpoplatněna, ovšem s připuštěním nulové hodnoty, neboť ne každý klient musí za každou službu platit => univerzálnost nasazení. Podrobnou analýzou dat a oborů hodnot, která jednotlivá pole mohou nabývat, lze dosáhnout přesnosti v zadávání hodnot a tím kvalitní manipulaci a výběr informací. Příkladem může být PNC kód položky, který musí obsluha vždy přesně zadat. Abychom dosáhli věrohodnosti tohoto údaje, bude pro zadání navrhnuto pole se seznamem, které bude nabízet pouze čísla PNC, která existují v seznamu položek. V opačném případě bude obsluha nejdříve nucena zadat novou položku včetně všech atributů a teprve poté ji lze přijmout na sklad. Každá položka má vlastnost „stohovatelnost“, která udává, kolik výrobků na sebe lze naskládat. S tímto číslem je třeba strategicky obchodně opatrně zacházet, neboť čím více kusů na sebe naskládáme, tím méně bude zabrané plochy a samozřejmě se méně vybere na skladném a naopak klient může platit neúměrné skladné. Jedná se vždy o kompromis, neboť to, že logistická společnost disponuje vyspělou skladovací technikou, neznamená, že na skladném bude prodělávat. Důvodem stohování při skladování je úspora místa ve skladu a možnost uspokojení více klientů. Na druhou stranu klientovi nelze účtovat plochu dle skutečných m2 jednotlivých položek, protože by to bylo neúměrné vůči ploše přepravního prostředku, kterým bylo zboží dodáno na sklad. Podobných příkladů, kdy je třeba omezit rozsah hodnot, je mnoho. Příjem musí být pouze celé kladné číslo, délkové údaje musí být kladná čísla, data musí mít shodný formát, číselné hodnoty musí být definovány jako číselné datové typy, aby s nimi mohlo být dále manipulováno jako s čísly atp.

Strana 34


Referenční integrita Access nabízí velmi dobrou pomůcku k zachování referenční integrity, což znamená, že nám například nedovolí vytvořit příjem pro neexistující položku, umístit položku na neexistující umístění, popřípadě přijmout zboží do skladu, který neexistuje. Hned při definici relací nabídne, zda chceme zajistit referenční integritu a pokud toto požadujeme, sám doplní indexy, které slouží k rychlejšímu vyhledávání dat. Indexy urychlují zpracování dotazů na indexovaná pole, stejně jako operace řazení a seskupení. Dalším úkolem při zachování věrohodnosti báze dat navrhovaného meziskladu bude zajištění, aby nešla vydat položka, která bude mít nulový stav, tedy do minusu. Toto již nelze ošetřit na nejnižší úrovni uložení dat, ale bude nutno zadat proceduru připojenou k formuláři výdej, pole množství ks, která před aktualizací ověří počet ks na skladě a v případě, že požadovaný výdej bude větší než momentální lokace, tak tento výdej nepovolí a zobrazí varovnou zprávu.

Obr. 5.4. Omezení rozsahu hodnot jednotkové ceny v entitě Služba

Strana 35

6. Praktická tvorba SŘBD

První část tvorby informačního systému meziskladu dle zadání je zdárně za mnou. Data jsou uložena v tabulkách a navzájem propojena relacemi. Nyní je třeba zajistit spolehlivý a bezpečný přístup k těmto datům, tak abychom je mohli aktualizovat, třídit, řadit, editovat a na jejich základě provádět výpočty nových žádaných hodnot nebo informací. Systém, který popsané zajišťuje, se nazývá SŘBD (systém řízení báze dat). Je oddělen od fyzického uložení dat, je tedy možno jej aktualizovat, vylepšovat nebo zcela přepracovat, aniž bychom jakkoliv ovlivnili fyzicky uložená data. Tvorbu SŘBD rozdělím do několika základních částí. Tvorbu uživatelského rozhraní, což budou představovat formuláře a jejich podklady. Definice sestav, které budou splňovat cíl návrhu a jejich podklady. Automatizační prvky VBA (Visual Basic for aplication). Bezpečnost a praxe. Pro ujasnění pojmů bych rád vysvětlil, že tvořený informační systém dostal pracovní název „EXSLOS“, což je akronym utvořený ze slov EXterní Sklad LOgistické Společnosti, a v dalším textu jej tak budu nazývat.

6.1 Formuláře Formuláře tvoří prvotní rozhraní mezi uživateli a aplikací. Mohou sloužit k mnoha různým účelům. Nejběžnějším využitím formulářů je zobrazení a úprava dat. Nabízí způsob, jak uživatelsky prezentovat data z databáze. Je možno je také využít ke vkládání a odstraňování dat z databáze. Lze nastavit různé možnosti, jako je zobrazování některých dat jen pro čtení, automatické doplňování souvisejících údajů, dopočítávání hodnot, zvýrazňování určitých hodnot atd. Dalším běžným použitím je řízení toku aplikace. Ve formuláři lze vytvořit různé ovládací prvky, které mohou reagovat na události a na jejich základě spouštět makro nebo proceduru VBA. Pomocí těchto procedur nebo maker můžeme otevírat jiné formuláře, spouštět dotazy, omezovat zobrazená data, nastavovat hodnoty, provádět příkazy z nabídek, zobrazovat nabídky, tisknout sestavy atp.

Veškeré formuláře které tvoří Exslos by šlo shrnout do tří skupin: - aktualizační; - informační; - speciální. Jednotlivé skupiny dále popíši podrobněji.

Strana 36


Aktualizační Stěžejním formulářem Exslosu jsou bezesporu formuláře „Příjem“ a „Výdej“ (obr. 6.1 a 6.2). Formuláře jsou optimalizovány pro rozlišení 1 280 × 1 024 pixelů a jsou děleny středovým křížem na čtyři základní části. Jejich kostra se skládá z vrstvení podformulářů na základní, a to i do více úrovní v případě výdeje. V záhlaví obou formulářů je číslo pohybu, které se skládá z následujících údajů:

X-BM/17/2006/2 Pořadové číslo Zkratka pohybu

Zkratka terminál

Zkratka týdne

Rok

Hned vedle je stejné číslo, ovšem kódováno v čárovém kódu (code 39). Je to standardizovaný formát a jeho použití předurčuje budoucí možné využití k tisku etiket pro signování položek, skenování dokumentů atp. V první části (vlevo nahoře) jsou základní údaje žádané od uživatele k doplnění. Obecně jsou vždy údaje povinné k doplnění podbarveny žlutě pro lepší orientaci. V pravé části se automaticky doplňují informace o vybraném klientovi či osobě. Opět je takto ošetřena chybovost při zadávání dat ručním vypisováním. V případě požadavku na doplnění nového údaje je třeba přejít do číselníků v hlavním menu viz dále. V dolní levé části je umístěn podformulář pro vkládání položek daného pohybu. Opět je ošetřeno zadávání PNC kódu a názvu položky, a to vybráním PNC ze seznamu, který je napojen na uložené skladové položky v tabulce skladových položek. V případě příjmu nové položky je vyžadován nový záznam přes číselníky, který si žádá doplnění všech atributů dané položky, jako jsou rozměry, hmotnost, počet v balení, stohovatelnost, což jsou stěžejní údaje pro výpočty skladného a manipulací. Pravá dolní část je posledním prvkem, který si žádá vyplnění. Jde o doplnění přepravní jednotky, samozřejmě opět výběr ze seznamu a případné doplnění přes číselníky včetně všech atributů, které jsou v tomto případě důležité pro výpočty nakládek konkrétních položek, s čímž se v dalším využití tohoto informačního systému počítá. Pod položkou přepravní jednotky jsou tři jednoduché ovladače. Prvním tlačítkem „Uložit“ dojde ke kontrole zadaných údajů a případnému varovnému hlášení o vynechaných hodnotách nebo nesprávné hodnotě. Druhé tlačítko „Tisk xxxxx“ zobrazí sestavu formuláře před tiskem a nabídne tisk nebo storno. Třetí tlačítko „Zavřít“ hovoří o své funkci výmluvně.


Obr. 6.1. Formulář příjemky

Obr. 6.2. Formulář výdejky

Strana 37

Strana 38


Zásadním rozdílem mezi formulářem příjemky a výdejky je sekce „Položky výdejky“ ve formuláři výdejka. Zde je navíc automaticky nastavované pole „Lokace“, které zobrazí počet momentálně uložených kusů položky na skladě, oddělení a umístění, ze kterého se má vydávat. V případě, že obsluha bude chtít vydat více kusů, než je přijato, bude spuštěno varování. Podobným případem jako dva předešlé formuláře, tedy interface pro vkládání dat o procesech, které se na skladě udály a které mají zásadní vliv na ekonomické výsledky, je evidence doplňkových služeb (obr. 6.3).

Obr. 6.3. Evidence doplňkových služeb

Dalším typem formuláře často využívaného řadovým uživatelem jsou číselníky. Jsou to formuláře entit, které jsou uloženy jako samostatné skupiny a nad jejichž množinami záznamů se odehrávají jednotlivé procesy. Tyto formuláře mají nejčastěji vzhled prostého datového listu s tím, že uživateli není dovoleno jakékoliv uložené položky měnit, protože by to mohlo závažně poškodit integritu dat. Kdyby si např. někdo po roce užívání Exslosu chtěl ušetřit práci s vypisováním klienta a jen tak přepsal již existujícího se stejnou ulicí a městem, ztratily by se veškeré záznamy s přepsaným klientem a nový by měl připsány historicky mylné případy pohybu zboží původního. Příkladem tohoto formuláře je obr. 6.4. Číselníky jako takové si zasluhují bližší pozornost, neboť zde se vždy v bázi dat ukrývá nejvíce redundantních hodnot. Již mnohokrát jsem viděl existující vnitropodnikové číselníky klientů, dodavatelů atp., které za roky, kdy do nich bylo pumpováno množství adres a názvů firem uživateli informačního systému, svým objemem několikanásobně překročili skutečnost a obsahují více adres, než je fyzicky v celé zemi, a více názvů firem, než kolik kdy v naší zemi bylo. Tímto se stávají pomalými a nevěrohodnými. V Exslosu toto nehrozí, protože je úzce profilován vždy na jednoho či několik málo klientů, ale přesto stojí za zamyšlení, jak lze zabránit


Strana 39

nekvalitnímu vkládání informací o názvech firem a jejich adresách. Určitě je cesta ve vstupní masce směrovacího čísla, nebo lépe porovnání se souborem existujících. Názvy firem vyhledávat pokud možno přes IČ, města mít přiřazena k okresům, ty k intervalu směrovacího čísla a tak podobně testovat věrohodnost. Samozřejmostí je pravidelná údržba a filtrování chyb. Jakmile číselník nemá věrohodnost (uživatel nemůže za rozumný čas najít správný kontakt), tak uživatelé místo aby kontakt vyhledávali, jej znovu a znovu zadávají.

Obr. 6.4. Formuláře číselníku „Subjekt“ Shrnuto podtrženo, aktualizační formuláře v Exslosu nemají jiný úkol než přidávat nové záznamy do relační báze dat pokud možno s minimální chybovostí.

Informační Následující formulář na obr. 6.5 je svým vzhledem velmi podobný formuláři aktualizačnímu z předcházejícího odstavce, ovšem svým účelem je zcela jiného ražení. Je to tzv. informační formulář, který pouze sděluje informace – v tomto případě o množství položek na daném skladě, oddělení a umístnění. Je to velmi cenná informace pro obsluhu skladu, která takto rychle získá přehled o uloženém zboží, například v případě telefonického dotazu klienta nebo před výdejem či příjmem si dokáže zjistit, kam je nejlepší danou položku umístit z důvodu konsolidace, nebo odkud je nejlepší ji vzít. Dalším velice důležitým informačním formulářem je formulář vyhledávání příjemky nebo výdejky (obr. 6.6). Tento formulář je určen k rychlému přístupu k uloženým dokladům, a to velice přehlednou formou. Touto cestou lze znovu tisknout příjemku či výdejku, nebo dodatečně opravit některý údaj. Navrhnut je jako překrývané okno, uživatele tedy nutí k jeho případnému zavření v případě, že najde správný doklad.

Strana 40


Obr. 6.5. Informační formulář lokace Je do jisté míry věcí názoru, zda je dobré ponechat možnost obsluze zasahovat do uložených dokladů o pohybu, ale v konečném efektu odpovědnostní hodnotu mají vždy jen doklady, které jsou tištěny v čase provedení pohybu a které jsou parafovány osobou přebírající. Žádný soud doposud nevznesl rozsudek a ani nepřiřkl vinu za zpronevěru na základě dat v informačním systému, což je zajisté dobře. Speciálním případem informačního formuláře je také formulář hlavního přepínacího menu nebo pozadí, o němž pojednává kapitola 6.3.

Speciální Speciální formuláře jsou v Exslosu v podstatě dva, a to manipulace a skladné. Jsou to formuláře určené pro vedoucího logistiky, příp. pověřené osoby, které budou účetně uzavírat hospodaření skladu. První zmíněný formulář, tedy formulář manipulace, který je znázorněn na obr. 6.7, je velmi jednoduchý a přehledný, ochráněn hlášeními uživateli proti chybě. Výpočet probíhá v obou formulářích ve více krocích a formuláře poskytují přehled o datech použitých k výpočtu. Více bude o způsobu výpočtů řečeno v následující samostatné kapitole.


Obr. 6.6. Informační formulář příjemky

Obr. 6.7. Speciální formulář pro výpočet manipulací

Strana 41

Strana 42


Závěrem bych k formulářům ještě podotkl, že u všech v zobrazení datového listu fungují místní nabídky a tak jdou poměrně dobře řadit nebo vyhledávat skládáním filtrů dle libovolných kritérií konkrétní záznamy, resp. data.

6.2 Sestavy Sestavy jsou svým založením tím nejhmatatelnějším výsledkem celé práce tvorby Exslosu. Těžko budete někoho přesvědčovat, že jste trávili desítky hodin prací nad něčím, co není vidět a když tak jen nějaká okénka a knoflíky. Ovšem každý i sebevětší laik uzná, že když vezme do rukou papír s hodnotami, které by v lepší případě ručně dával dohromady několik dní a v horším by vůbec nepřišel na to jak, tak je vskutku jedinečné mít možnost jedním kliknutím takovéto informace získat. Hlavními výstupními sestavami, které jsou v první fázi tvorby Exslosu hotovy a které tímto vyhovují kritériím zadání této bakalářské práce, jsou příjemka, výdejka, blesková inventura, podrobná inventura, manipulace, skladné a doplňkové služby. Prozatím není systém naplněn větším množstvím pohybů, ale i tak lze výpočty provést a sestavy demonstrovat. Samozřejmostí je promítnutí čárového kódu čísla pohybu na tištěný doklad a souhrny včetně celkové částky za služby. Na několika dalších stranách uvádím přehled hlavních výstupních dokladů, které předpokládám nepotřebují další komentář, protože v podstatě hovoří samy za sebe.


Obr. 6.8. Výdejka ze skladu

Strana 43

Strana 44


Obr. 6.9. Inventura podrobná


Obr. 6.10. Vyúčtování doplňkových služeb

Strana 45

Strana 46


Obr. 6.11. Vyúčtování manipulací


Obr. 6.12. Vyúčtování skladného

Strana 47

Strana 48


6.3 Hlavní panel uživatelského rozhraní Hlavní panel uživatelského prostředí je proveden jako vlastní nabídková lišta (obr. 6.13). Uživatel může pohodlně, tak jak je zvyklý z jiných programů, pomocí rolety příkazů z řádku provádět veškeré úkony nad aplikací. Hlavní rozbalovací menu se skládá z nabídky příjemky, výdejky, přehledy, číselníky a funkce. Příjemky – zde je možnost nahlédnout do uložených příjemek a nebo zadat novou. Výdejky – totožné s volbou příjemky, pouze v modifikaci pro výdejky. Přehledy – nabízí informační náhled na lokace, bleskovou inventuru a podrobnou inventuru. Číselníky – nabízí možnost doplnění záznamů do množin prvků, jako jsou například skladové položky nebo přepravní jednotka, nad kterými se odehrávají veškeré události v procesu chodu skladu. Funkce – je to odkaz pro osobu, která bude vypočítávat účetní uzávěrky za skladné, manipulace a doplňkové služby. Soubor, úpravy a okno – tyto nabídky jsou převzaty ze standardního řádku nabídek Accessu a nabízí běžné funkce, jako je například přepínání mezi jednotlivými spuštěnými okny, vyjmout data, kopírovat data, tisk atp.

Obr. 6.13. Hlavní panel uživatelského prostředí


Strana 49

6.4 Souhrny, výpočty a Visual Basic for Application

Pominu-li vysvětlování, jak jsem došel k souhrnům cen a množství v sestavách vyúčtování za jednotlivé služby, což by bylo zbytečné, přejdu hned ke čtyřem základní a složitějším výpočtům. Blesková inventura Tento výpočet je založen na souhrnu všech příjmů všech skladových položek a od tohoto souboru je odečten souhrn všech výdejů skladových položek. Při výpočtu vycházím z toho, že nemůže být vydáno více, než bylo přijato, tedy výpočet jde zleva do prava, od příjmu k výdeji. Podrobná inventura U tohoto výpočtu bylo třeba vzít v úvahu parametr sklad, oddělení a umístění. Nejprve se tedy sečtou všechny příjmy na výše uvedené možnosti a od nich se odečtou výdeje ze všech těchto možností. Opět vycházím z úvahy, že množina výdejů je podmnožinou příjmů, tedy výpočet jde od příjmu k výdeji. Výpočet manipulací Zde bylo třeba vzít v úvahu nové parametry času a rozměru položky. Čas je konstanta a objem se jednoduše vypočítá z údajů v číselníku skladové položky. Účetní uzávěrka je dle zadání měsíc. Účtuje se za zmanipulovaný m3. Výpočet probíhá obdobně jako blesková inventura, ale provede se jen za zvolené období jednoho měsíce. Pohyby ve smyslu příjem, výdej mají v tomto případě stejnou hodnotu, takže se od sebe neodečítají, ale naopak. Pro přehlednost je na sestavě agregován typ pohybu na typu položky ke dni provedení a k tomu celkový objem. Zbývá jen sečíst a vynásobit sjednanou částkou. Výpočet skladného Vypočet skladného je v tuto chvíli nejsložitějším úkolem, který Exslos plní. Výpočet zahrnuje parametr času, aktuálně zabrané plochy a sazbu. Čas je konstanta a plocha je vypočítána z číselníku skladové položky, a to tak, že základna je násobena stohovatelností. Jak se určuje stohovatelnost, je popsáno v kapitole 5.3. Aktuálně zabraná plocha na den se určí tak, že se vypočítá aktuálně zabraná plocha do dne účtování a od ní se odečte aktuální plocha za účtovaný měsíc. Dostaneme výchozí stav k poslednímu dni měsíce předcházejícího. Dále se vypočítají aktuální pohyby plochy ke každému dni účtovaného měsíce, a to agregováním plochy na den a odečtením plochy výdejů od příjmů. Můžeme samozřejmě dostat zápornou hodnotu, protože je možné, že v určitý den je výdej plochy vyšší než příjem. Nyní následuje poslední krok, kterým je zjištění, zda první den v účtovaném měsíci došlo k nějaké změně plochy. Pokud ne, načte se do tohoto dne hodnota dne předcházejícího, pokud ano, přičte se hodnota dne předcházejícího. Analogicky se testuje další den, tedy zjištění, zda došlo ke změně; pokud ano, přičte se hodnota dne předešlého, pokud ne, dosadí se hodnota dne

Strana 50


předešlého. Takto se výpočet provede za celý účtovaný měsíc. Vynásobit aktuální plochu sazbou za m2 je již triviální samozřejmostí. Pozorný čtenář si jistě všimne, že celý algoritmus má jednu nevýhodu, a sice, že vyúčtovat je třeba nejpozději před zadáním jakéhokoliv pohybu do měsíce následujícího. V opačném případě by došlo k chybnému výpočtu počátečního stavu měsíce předešlého. Osobně si nemyslím, že by to bylo překážkou, naopak to vyvine tlak na včasnou fakturaci. V budoucnu bude možno výpočet upravit dle potřeb praxe. Výpočty jak manipulací, tak skladného se provádí přes připravené formuláře, tak aby měl uživatel kontrolu nad daty, která jsou pro výpočet využívána, a aby byl instruován o průběhu výpočtu. Na obr. 6.14 je interface pro výpočet skladného.

Obr. 6.14. Výpočet skladného

Visual Basic for Application Tento mocný pomocník pro automatizace procesů v aplikaci a bdělý hlídač správnosti postupu práce s ní povyšuje práci v prostředím Access na plnohodnotné vývojové prostředí pro databáze, kde programováním kódu je možno dosáhnout prakticky všeho, nač si uživatel nebo klient vzpomene.


Strana 51

Nyní bych rád předvedl několik ukázek využití VBA (Visual Basic for aplication) v Exslosu. Procedura tlačítka uložit výdej: Private Sub tlUloz_Click() On Error GoTo Err_tlUloz_Click 'Zobrazí zprávu, není-li korektně vyplněna výdejka Dim strZprava As String, strTitulek As String Dim intOvladac As Integer Dim s As Form_frm_Vydej_zadani_podformular Dim k As Form_frm_Prepravni_jednotka_vydej_podformular Set s = frm_Vydej_zadani_podformular.Form Set k = [Form_frm_Prepravni_jednotka_vydej_podformular].Form If IsNull(s.id_polozky) Or s.id_polozky = " " Then strZprava = "Musíte zadat položku vydejky." strTitulek = "Zadaní položky" intOvladac = vbOKOnly MsgBox strZprava, intOvladac, strTitulek s.id_polozky.SetFocus Else If IsNull(k.id_prepravni_jednotky) Or IsNull(k.reg_znacka) Or k.id_prepravni_jednotky = " " Or k.reg_znacka = "" Then strZprava = "Musíte zadat korektně přepravní jednotku." strTitulek = "Zadaní přepravní jednotky" intOvladac = vbOKOnly MsgBox strZprava, intOvladac, strTitulek k.VyberJednotku.SetFocus Else strZprava = "Výdejka je korektně vyplněna, můžete tisknout." strTitulek = "Hotovo" intOvladac = vbOKOnly MsgBox strZprava, intOvladac, strTitulek End If End If Exit_tlUloz_Click: Exit Sub Err_tlUloz_Click: MsgBox Err.Description Resume Exit_tlUloz_Click End Sub

Strana 52


Procedura kontroly množství výdeje položky ze skladu, oddělení, umístnění: Private Sub mnoztvi_ks_AfterUpdate()

Dim strMsg As String, strTitle As String Dim intStyle As Integer Dim k As Form_frm_Vydej_lokace_podformular Set k = [Form_frm_Vydej_lokace_podformular] If IsNull(k.lokace) Or Me!mnoztvi_ks > k.lokace Then Me.mnoztvi_ks.SetFocus strMsg = "Není dostatek kusů k výdeji z aktuální lokace." strTitle = "Lokace" intStyle = vbOKOnly MsgBox strMsg, intStyle, strTitle Me.mnoztvi_ks.SetFocus End If End Sub

Procedura tlačítka tisk výdejky: Private Sub tlTisk_Click() On Error GoTo Err_Tisk_Click Dim stDocName As String Dim stCisloVydejky As String Dim strZprava As String, strTitulek As String Dim intVybral As Integer

stDocName = "rpt_Vydejka" stCisloVydejky = Me!id_vydejky strZprava = "Opravdu chcete tisknout aktuální výdejku." strTitulek = "Tisk" DoCmd.OpenReport stDocName, acViewPreview, , stCisloVydejky intVybral = MsgBox(strZprava, vbOKCancel, strTitulek) If intVybral = 1 Then DoCmd.PrintOut acPages, 1, 1, , 2 DoCmd.Close Else DoCmd.Close End If

Exit_Tisk_Click: Exit Sub Err_Tisk_Click: MsgBox Err.Description Resume Exit_Tisk_Click End Sub


Strana 53

6.5 Dotazovací jazyk SQL

Dotazovací jazyk SQL představený v kapitole 2.3 je použit jako základní stavební kámen pro většinu formulářů a sestav aplikace Exslos a proto bych zde rád demonstroval alespoň jeden příklad jeho použití. Aplikace Access nabízí interaktivní prostředí pro tvorbu i velmi složitých dotazů, ale dle mojí zkušenosti je mnohdy lepší napsat dotaz přímo v SQL kódu, což je samozřejmě také možné. Na obrázku 6.14 je vidět dotaz pro výpočet všech příjmů dle skladových položek na sklad, oddělení a umístnění.

Obr. 6.14 dotaz pro výpočet všech příjmů dle skladových položek na sklad, oddělení a umístnění v návrhovém zobrazení interaktivního prostředí Access.

Kód v SQL jazyku tohoto dotazu zní: SELECT tab_Prijem.id_skladu, tab_Sklad.nazev, tab_Prijem.id_skladu_oddeleni, tab_Sklad_oddeleni.nazev_oddeleni, tab_Prijem.id_umistneni, tab_Umistneni.adresa_umistneni, tab_Skladova_polozka.id_polozky, tab_Skladova_polozka.nazev_polozky, Sum(tab_Prijem.mnoztvi_ks) AS Stav_prijem FROM tab_Umistneni INNER JOIN (tab_Sklad INNER JOIN (tab_Skladova_polozka INNER JOIN (tab_Sklad_oddeleni INNER JOIN tab_Prijem ON tab_Sklad_oddeleni.id_skladu_oddeleni = tab_Prijem.id_skladu_oddeleni) ON tab_Skladova_polozka.id_polozky = tab_Prijem.id_polozky) ON tab_Sklad.id_skladu = tab_Prijem.id_skladu) ON tab_Umistneni.id_umistneni = tab_Prijem.id_umistneni GROUP BY tab_Prijem.id_skladu, tab_Sklad.nazev, tab_Prijem.id_skladu_oddeleni, tab_Sklad_oddeleni.nazev_oddeleni, tab_Prijem.id_umistneni,

Strana 54


tab_Umistneni.adresa_umistneni, tab_Skladova_polozka.nazev_polozky;

tab_Skladova_polozka.id_polozky,

6.6 Bezpečnost Zabezpečení souboru databáze aplikace Microsoft Access Nejjednodušší metodou zabezpečení je nastavení hesla pro otevření aplikace (.mdb). Jakmile je nastaveno heslo, zobrazí se při otevření databáze dialogové okno, které požaduje zadání hesla. Otevření databáze bude dovoleno pouze uživatelům, kteří napíší správné heslo. Tato metoda je bezpečná (aplikace Microsoft Access heslo zakóduje, takže není přístupné přímým načtením databázového souboru), ale vztahuje se pouze na otevření databáze. Jakmile je databáze otevřena, všechny její objekty jsou uživateli přístupné (pokud již nebyly definovány jiné druhy zabezpečení, které jsou popsány dále). Je-li databáze sdílena pouze malou skupinou uživatelů nebo na jediném počítači, nastavení hesla obvykle postačí a v první fázi provozu Exslosu bude toto použito. Nevýhodou tohoto zabezpečení je, že zaheslovanou databázi nelze replikovat a poté sinchronizovat. Zabezpečení objektů databáze na uživatelské úrovni zabezpečení Nejpružnější a nejrozsáhlejší metoda zabezpečení databáze se nazývá uživatelská úroveň zabezpečení. Tento typ zabezpečení je podobný metodám používaným ve většině síťových systémů. Dva hlavní důvody pro použití uživatelské úrovně zabezpečení jsou následující: −

prevence neúmyslného poškození aplikace změnou tabulek, dotazů, formulářů, sestav nebo maker, na nichž aplikace závisí,

−

ochrana citlivých dat v databázi.

Na uživatelské úrovni zabezpečení se vyžaduje, aby se uživatelé po spuštění aplikace Microsoft Access identifikovali pomocí kódu a zadali heslo. V informačním souboru pracovní skupiny jsou identifikováni jako členové pracovních skupin. Aplikace Microsoft Access poskytuje dvě výchozí skupiny: administrátoři (nazvaná skupina Administrátoři) a uživatelé (nazvaná skupina Uživatelé), ale lze definovat i další vlastní skupiny. Toto nastavení lze provést pomocí průvodce zabezpečením nebo definovat přímo použitím příkazu Zabezpečení v nabídce Nástroje. Skupinám a uživatelům jsou přidělena oprávnění, která určují, jak smějí pracovat s jednotlivými tabulkami, dotazy, formuláři, sestavami a makry databáze. Členům skupiny Uživatelé může být například povoleno zobrazit, vložit nebo upravit data v tabulce Subjekty, ale nikoli měnit návrh této tabulky. Skupině Uživatelé může být povoleno pouze zobrazit data týkající se výdejek a příjemek, ale zároveň jí může být zcela odepřen přístup k vyúčtování za služby nebo k datům z tabulky Služby kde jsou


Strana 55

jednotlivé ceny. Členové skupiny Administrátoři mají plná oprávnění ke všem tabulkám, dotazům, formulářům, sestavám a makrům databáze. Zabezpečení kódu jazyka Visual Basic for Applications (VBA) Kód jazyka Microsoft Visual Basic for Applications (VBA) v modulech, včetně modulů ve formulářích a sestavách, lze chránit heslem, které se zadává na začátku každé relace. Heslo zabraňuje neoprávněným uživatelům v úpravě, vyjímání, kopírování, exportování nebo odstraňování kódu jazyka VBA. K ochraně duševního vlastnictví lze odstranit zdrojový kód jazyka VBA z databáze a zabránit úpravám formulářů, sestav a modulů uložením databáze jako souboru MDE. Této možnosti je v Exslosu využito. Zabezpečení aplikace Nakonec ještě lze zabránit zvědavým nebo zlomyslným koncovým uživatelům v náhodném či záměrném poškození aplikace skrytím objektů databáze v okně Databáze a nastavením některých možností spouštění (automatické otevření výchozího formuláře a panelu nástrojů), čímž budeme řídit vzhled a chování aplikace a zabezpečíme panely nabídek a příkazů. Taktéž použito v Exslosu. Zabezpečení v prostředí s více uživateli V mnoha situacích je žádoucí zabránit uživatelům v replikaci databáze. Replikace databáze umožňuje uživateli vytvořit kopii sdílené databáze a také přidávat pole a provádět další změny aktuální databáze. Dále můžeme chtít zabránit uživatelům v nastavení hesla databáze. Nastaví-li uživatel heslo sdílené databáze, žádný jiný uživatel nebude moci databázi bez hesla otevřít. Dále může být vhodné nedovolit uživatelům měnit vlastnosti spuštění, které určují funkce jako vlastní nabídky, vlastní panely nástrojů nebo úvodní formulář. Nemá-li sdílená databáze definovanou uživatelskou úroveň zabezpečení viz. výše, nemůžeme uživatelům v těchto změnách zabránit. Je-li uživatelská úroveň zabezpečení definována a uživatel nebo skupina již oprávnění Správa má, odebrání tohoto oprávnění zabrání uživateli nebo skupině v provádění změn. Je-li zapotřebí umožnit uživateli nebo skupině provádět kteroukoli z těchto úloh, můžeme jim přiřadit oprávnění Správa.

Shrnuto: v první fázi projektu Exslos je zabezpečení databázového souboru provedeno heslem a aplikačního souboru (SŘBD) převodem na příponu MDE. Další případná zabezpečení budou nastavena dle aktuálních potřeb praxe.

Strana 56


6.7 Podmínky provozu Aplikaci lze provozovat a plně funkčně spustit za těchto podmínek: − − − − − − − − − −

počítač s procesorem o taktovací frekvencí alespoň 1,5 GHz; RAM alespoň 128 MB; operační systém MS Windows XP SP 1; nainstalovaný MS Office XP včetně programu Access 2002; textová tiskárna jako výchozí pro tisk sestav; volné místo na disku doporučeno alespoň 100MB; v případě síťového provozu doporučen alespoň Ethernet Base 10T a nebo platforma s obdobnými parametry; dodržení platných licenčních ujednání softwarových produktů; nainstalován font písma code39 ; monitor s rozlišením minimálně 1280 x 1024 pixelů.

Doporučení: Pro hladký chod aplikace doporučuji v záložce Nástroje, Možnosti, Úpravy či hledání odstranit zaškrtnutí potvrzovat akční dotazy. V opačném případě budou při výpočtech skladného a manipulací generovány informační zprávy, které jsou nepodstatné.

Strana 57

7. Závěr Tématem této bakalářské práce je návrh a realizace informačního systému externího skladu logistické společnosti. Podíváme-li se ještě do nedávné historie, bylo zcela běžné, že skladové hospodářství bylo vedeno ručně. Skladové karty byly uloženy v kovových registrech a skladník, to byl ten vševědoucí a svým způsobem nepostradatelný člověk pro každého zaměstnavatele. Inventura trvala týdny (ukázkově zpracováno ve filmu „Holky z porcelánu“) a její věrohodnost byla nízká. Trendem moderních logistických projektů a s nimi nerozlučně spjatých informačních systémů je anulovat nenahraditelnost konkrétního lidského prvku v řetězci procesů spojených s chodem skladového hospodářství. Člověk jako zdroj informace o pozici, zařazení, šarži, typu, rozměru, času příjmu nebo výdeje atp. je notně nespolehlivý. Abychom hovořili v rovině konkrétna, nasazením systému Exslos na skladové hospodářství popsaného meziskladu vymezíme roli člověka pouze jako zadavatele hodnot, čímž jej zcela vymažeme z roviny poskytování informací. Toto je hlavním zlepšením v rychlosti a věrohodnosti získaných dat. Efekt bude rychlý a viditelný na první pohled. Jestliže ještě před pěti měsíci trvala měsíční účetní uzávěrka několik dní, tak Exslos ji zvládne pod stanovených 10 minut. Okamžitá úspora zdrojů řádově v tisíci korunách za měsíc. Nutností bude zajistit vkládání přesných dat, a to jak školením, tak zdokonalením integritních omezení. Rád bych podotknul, že Exslos není jednoúčelový projekt pro školní potřebu, ale systém, který se po nezbytném doladění a eliminaci chyb stane systémem plnohodnotně pracujícím v jedné logistické společnosti v Brně. Toto praktické nasazení s sebou nese další vývoj a zdokonalování jak v oblasti základních funkcí, tak v nástavbových prvcích, kterými bezesporu může být a bude export a import dat, datové výstupy v různých formátech, jako například SMS, e-mail, pdf atp. Plnohodnotné začlenění systému čárového kódu bude také nezbytné v případě vyššího obratu a drobné distribuce. Podpůrné prvky pro plánování ložení na auta a optimalizaci rozložení zboží na skladě a mnoho dalších funkcí lze časem implementovat dle aktuální poptávky. Z hlediska ekonomicko-analytických informací bude systém schopen po určitém čase z nastřádaných dat vyhodnotit informace vedoucí k optimalizaci rozložení pracovníků obsluhy jednotlivých skladů, výši přímých nákladů na zmanipulovanou jednotku, např. m3, a hlavně cenovou politiku pro jednání s klienty ohledně způsobu výpočtu skladného a typu měrných jednotek. Nejzásadnějším ukazatelem v tomto smyslu je stohovatelnost v kartě skladová položka. V kapitole o formulářích je zmíněna tato hodnota vlastnosti skladové položky, která má zásadní vliv na výpočet plochy skladného a která se jen velmi obtížně spravedlivě stanovuje. Bude dobrou zprávou pro všechny, kteří se přímo podílí na provozu skladu nebo jsou jen zpracovateli informací, že Exslos vznikl, aby jim ulehčil práci a zvýšil efekt z jejich práce, což by se mělo odrazit na jejich ohodnocení. Bakalářská práce jako završení tříletého úsilí o načerpání nových znalostí a poznatků plní pomyslnou roli měřidla, které má ukázat, zda čas strávený nad stovkami stran učebních textů a hodiny strávené v lavicích učeben přinesly kýžený výsledek, kterým je posun znalostí a schopnosti samostatného analytického myšlení. Již v úvodu této práce je doloženo, že žádný člověk není schopen pojmout veškeré znalosti a poznatky byť jen

Strana 58

7. Závěr

z jedné oblasti, například přírodních věd. Dokonalosti vědění se lze pouze limitně blížit. Zásadní na cestě za poznáním je ovšem vůle a motivace. Motivací je lidská přirozenost vycházející z odvěkého zákona výběru, tedy boje o přežití, kde v moderních dějinách je stále platnější, že kdo víc zná, ten přežije. Zákon síly fyzické přechází na zákon síly myšlenky. Vůli, tu v sobě musí najít každý sám.

Strana 59

Seznam použité literatury

[1]

POLIŠČUK, R.: Titulní strana závěrečné práce

[2]

RIORDAN, R. M.: Vytváříme relační databázové aplikace. CP Books, a. s., 2000, 294 s. ISBN 80-722-6360-9.

[3]

VIESCAS, J. L.: Mistrovství v Microsoft Office ACCESS 2003. CP Books, a. s. 2005, 960 s. ISBN 80-251-0537-7.

[4]

POKORNÝ, J.: Visual Basic pro aplikace ACCESSU 2000. Kopp 1999, 267 s. ISBN 80-7232-091-2.

[5]

OŠMERA, P.: Informační systémy, část 1, Teorie informace. Sylab VUT Brno 2002.

[6]

LACKO, B.: Projektování řídicích systémů. Sylab VUT Brno, říjen 2002.

[7]

KOCAN, M. Jedna z prvních databází [online]. 2002, srpen [cit. 10. května 2006]. Dostupné na www: http://www.dbsvet.cz/view.php?cisloclanku=2002082604

[8]

KOCAN, M. Databáze nejsou jen relační, díl druhý, třetí, čtvrtý [online]. 2001, prosinec [cit. 10. května 2006]. Dostupné na www: http://www.dbsvet.cz/view.php?cisloclanku=2001120303

[9]

CHARONWARE, s,r,o,. CASE Studio 2, [online]. 2006 [cit. 15.května 2006]. Dostupné na www: http://www.casestudio.com

[10] BUTLER, Jeremy. A History of Information Technology and Systems [online]. 1997, summer [cit. 10.5.2006]. Dostupné na www: http://www.tcf.ua.edu/AZ/ITHistoryOutline.htm

No title

Recommend Documents