Tvorba a aktualizace datových číselníků

podplukovník Ing. František RUŽIČKA, VÚ 8860 Belgie

Úvod

Informace, data. Na kvalitě, aktuálnosti a dostupnosti informací jsou v současnosti závislé veškeré oblasti naší činnosti.  Řazení v logické struktuře od obecných skupin ke konkrétní a podrobné informaci je požadavek, vycházející z potřeby rychlého nalezení požadované informace. Příkladem může být program kin na Internetu, kdy lze lístky do kina rezervovat přes zvolené město, kino a čas nebo přes žánr a název hledaného filmu. Funkčnost informačních systémů, které jsou založeny na sběru, aktualizaci a uživatelských výstupech informací (v tomto případě raději dat), je závislá na kvalitě jejich řazení. Všechna taková data jsou řazena více či méně pomocí číselníků dat.

Typickým představitelem číselníku je telefonní seznam, kde je každý účastník telefonní sítě identifikován jménem, bydlištěm a jedinečným, neopakovatelným telefonním číslem. Dalším praktickým příkladem je seznam měst a obcí s jejich názvy a poštovními směrovacími čísly (PSČ). V rezortu obrany by jako příklad číselníku mohl sloužit seznam vojenských útvarů a zařízení (VÚZ).

Terminologie

Úvodem je nutné vysvětlit základní(1) terminologii a její obsah. Samozřejmě vychází z obecně platných a zažitých konvencí, např. v [1], [2].
Uspořádanou kolekci dat s určitou strukturou a za určitým účelem lze nazvat databází. Součástí databáze bývá i software, který umožňuje manipulaci s daty a přístup k nim, nazývaný systém řízení báze dat. Existuje celá řada typů databází, ten nejrozšířenější a nejmodernější typ je relační databáze.

Tabulka

 Základní část databáze, s nejméně jedním sloupcem a dvěma řádky shromažďuje logicky související údaje. Pokud se rozhodneme použít úvodního příkladu s vojenskými útvary a zařízeními, budou v tabulce údaje o jednom typu objektu - VÚZ. Pro lehčí orientaci je nutné tabulku pojmenovat, např. ,,VUZ".
Řádek (záznam) V řádcích tabulky jsou jednotlivé VÚZ a údaje k nim vztažené. Každý řádek je v celém rozsahu jedinečný, neopakuje se.
Sloupec (položka, atribut) V záhlaví tabulky (první řádek tabulky) je jednoznačně uvedeno, jaký atribut vyjadřuje (popisuje) - na příkladu VÚZ jsou to: ,,název VÚZ", ,,číslo VÚZ", ,,posádka VÚZ" a další, např. ,,nezbytná" ,,poznámka".

Vše se pokusí přiblížit tabulka č. 1.


Tabulka č. 1

Obsah jednotlivých položek (atributů) by měl splňovat nějaká, předem stanovená kritéria. Tam, kde je očekávaná číselná hodnota, měla by se číselná hodnota také nacházet. Tam, kde je očekáván název útvaru a vojenského zařízení, nemají místo zkratky, zkomoleniny a ani dodatečné, neočekávané informace, např. o posádce, čísle VÚZ a další. Nejvhodnější varianta je uvádět hodnoty v jednotlivých položkách a v záznamech výběrem z uzavřeného množství informací, vhodně řazených v jiné tabulce - datovém číselníku.

Definice datového číselníku by mohla znít tak, že se ,,jedná o množinu věcně souvisejících a standardizovaných jedné a více položek, formálně vyjádřených pomocí textu nebo řady číslic, s jednoznačnou identifikací každého záznamu, sestavených v tabulce". Slouží ke sjednocení zpracovávaných podkladů, zpravidla formulářů (písemných nebo elektronických) a umožňuje hromadné elektronické zpracování dat. Standardnost položek spočívá v jednotnosti (struktury, formy atd.).

Je nutné nějaký číselník vytvářet?

Prvním předpokladem pro vznik jakéhokoli datového číselníku (dále jen číselník) je nutnost jeho vzniku. Jinými slovy, číselník dat je nástrojem k vytvoření takové struktury dat, která slouží požadovanému (předpokládanému) účelu, tj. např. evidence, vyhodnocení, plánování a jiné podklady k rozhodování nebo jiné činnosti.

Dejme tomu, že je nutné sledovat počty personálu po vojenských útvarech a zařízeních.  Nutností je tedy vytvořit seznam vojenských útvarů a zařízení, kterým bude přiřazován počet jejich příslušníků.


Tabulka č. 2

Zjednodušená tabulka s evidencí počtu personálu může mít podobu podle tabulky č. 2:

Tento příklad je možné použít jako základ pro sběr dat pro různé účely. Je nutné si ovšem uvědomit, že byl konstruován za jistým účelem a dodatečné požadavky snižují použitelnost příkladu číselníku. Chybí např. další informace o vojenském útvaru (posádka, uvedení místa v organizační struktuře rezortu MO atd.) a také pouhý součet personálu nemusí být dostatečný (pravděpodobně by bylo vhodné počty personálu uvádět po skupinách - vojáci a občanští zaměstnanci nebo ještě podrobnější, po hodnostech nebo hodnostních sborech).

Dodatečně vznášené požadavky jsou pro posouzení věrohodnosti a využitelnosti zpracovaných dat naprosto kritické. Účelnost a objektivnost takových požadavků je běžně těžké posoudit, v praxi často záleží jen na umístění tvůrce a posuzovatele dodatečných požadavků v organizační struktuře organizace.

Řešit dodatečně vznášené požadavky opakovaným sběrem doplněných dat je nejen časově náročné opatření, ale hlavně zpochybňuje celý proces, pro který byla data zpracovávána.

Platí tedy, že jedním z hlavních předpokladů pro vytvoření kvalitního (tj. relevantního a stabilního) číselníku dat je předběžná podrobná systémová analýza vazeb a struktury používaných dat nejen v průběhu daného procesu, ale také včasné definování potřebné struktury dat na vstupu a výstupu procesu použitelné pro další, navazující procesy.

Úroveň podrobnosti číselníku

Při tvorbě číselníku je potřebné zohlednit potřebnou úroveň detailu (kolik informací a jak podrobné informace je nutné zpracovat). Je nutné si uvědomit jednoduchou skutečnost, že podrobnost detailu na vstupu (sběru, zahájení procesu) se NEMUSÍ nutně rovnat úrovni detailu na výstupu (vyhodnocení, ukončení procesu). Dochází zpravidla k určitému stupni zobecnění agregace dat podle obsahu jednotlivých datových položek. Optimální je disponovat několikastupňovou agregací, ve výše uváděném příkladu by to mohly být počty personálu od jednotlivých útvarů a zařízení, brigád, velitelství a celkově za rezort MO.

Již v počátku tvorby číselníku je nutné promyslet důsledně úroveň detailu číselníku a nalezení optimální míry mezi podrobností informace, která je požadovaná a přitom zbytečně nezatěžuje zpracovatele.

Identifikace jednotlivých záznamů číselníků

Každý záznam v číselníku je možné označit identifikátorem, který ulehčuje uživatelům orientaci v číselníku a slouží pro jednodušší identifikaci např. dlouhé textové položky. Tento identifikátor není povinný, ale lze ho výhodně použít při seskupování jednotlivých záznamů do logických skupin. Je možné označit položku jakoukoli alfanumerickou kombinací znaků. Prioritním předpokladem, limitujícím funkčnost celého číselníku, je JEDINEČNOST každého záznamu v číselníku (resp. identifikátoru, pokud je použitý). Jako fatální selhání je možné označit některé publikované číselníky v rezortu MO ČR, které obsahují více stejných identifikátorů záznamů při odlišném věcném obsahu.

Bylo již zdůrazněno, že identifikátor není povinný, prioritně má sloužit k jednodušší orientaci v položkách číselníku. Paradoxně je možné nalézt číselník (fiktivní příklad) číselných velikostí výstroje s identifikátory, které jsou odlišné od čísel velikostí. Takže personál porovnáním s inventurní sestavou a převodníky ověřuje, kolik mají výstroje 23505 ve velikosti XsW. Srozumitelnější by jistě bylo položku 23505 přejmenovat na ,,košili s krátkým rukávem" a velikost XsW na velikost ,,43". Jednoduše, materiálové, finanční a personální sestavy dat lze tvořit čitelné, či srozumitelné pro všechny uživatele. Není přece nutné vytvářet nový, tajuplně zašifrovaný jazyk ...

Délka identifikátoru závisí na platformě, kde je užíván (Windows, Linux apod.) a na použitém obslužném software. Na platformě Windows(2) je k dispozici textový identifikátor v délce 2 miliardy znaků, v případě číselného identifikátoru(3) je maximální hodnota 18 446 744 073 709 551 615 (více než 18 trilionů).
Navzdory tomu je opakovaně uváděn požadavek na omezení délky položky např. v [3] a [4], kdy se nejčastěji stanovuje délka položky do 32 znaků nebo v případě textové položky do 255 znaků. Tento požadavek je technicky zastaralý, věcně neopodstatněný a vychází z historického vývoje databází.

Historické ohlédnutí


Obrázek č. 1

V první polovině 80. let byl uveden na trh program nazvaný dBASE. Byl vyvinut pro osmibitové počítače a na dlouhou dobu byl ve své kategorii jediným produktem. Pravděpodobně nejpovedenější a nejrozšířenější byla verze dBASE III Plus, pro kterou také existovala česká nadstavba (podobná jako na obr. č. 1).

Úspěch dBASE III Plus asi spočíval v tom, že při své prokazatelné jednoduchosti poskytovala rozumné možnosti přístupu k datům (pro zrychlení přístupu se používalo indexů), dostatečně bohatou škálu tiskových sestav a pro programování i jednoduché možnosti ladění.

Jedním z nedostatků dBASE III Plus byla její pomalost. Bylo to hlavně způsobeno tím, že program v programovacím jazyce byl interpretován přímo ze zdrojového textu (převzato z [5]).

Navíc měl mnoho omezení, např. názvy položek mohou být dlouhé maximálně 32 znaků, položka dlouhá maximálně 255 znaků a přesnost desetinných čísel byla omezena na 20 míst. Jedním z nejvážnějších omezení je to, že všechny položky mají pevnou délku(s využitím [6]).
Na svou dobu (1978-1988) byly ovšem produkty dBASE revolučním krokem pro management databázi.

Aktualizace číselníku


Schéma č. 1

Dalším faktorem, který ovlivňuje kvalitu a tedy použití číselníku, je jeho aktualizace. Aktualizaci číselníku lze obecně chápat tak, že se všechny záznamy a položky číselníku porovnají s nějakým stavem (např. stavem k nějakému datu apod.), vyhodnotí se odchylky a po posouzení příčiny a závažnosti odchylky se číselník upraví.

Existuje určité, ovšem naprosto kritické omezení. Spočívá v dodržení časové souslednosti procesů, které číselník používají, nelze ho tedy bez negativních důsledků měnit v průběhu procesu ani mezi navazujícími procesy, ale aktualizace by měla být prováděna mimo procesy, nejlépe tedy před a po jeho použití, tedy pokud lze nalézt nějakou ucelenou etapu souslednosti procesů.

Jako příklad lze uvést dva závislé procesy, které sdílejí stejný číselník (schéma č. 1). V rezortu obrany ČR může jít například o proces plánování a rozpočtování, investiční a akviziční procesy nebo výstavbu sil a evidenci personálu. Pokud na časové ose je proces č. 1 ohraničen mezi body A-B a proces č. 2 mezi body C-D, v období B-C dochází k předávání, verifikaci (možná i restrukturace) a přípravě k použití dalšího, navazujícího procesu.

Pokud dojde k úpravě číselníku mezi body:

Není až tolik podstatné, z jakých důvodů dochází k úpravě číselníků (změna zákona, vyhlášky, rozhodnutí politické reprezentace), téměř vždy dochází k negativním jevům.

V této souvislosti je třeba říci, že správce číselníku (to je pověřená složka rezortu obrany, která daný číselník spravuje, tj. může ho vytvořit, aktualizovat, užívat a poskytovat jiným složkám) nemusí odpovídat za všechny procesy, které číselník užívají. Pokud není nastavena vhodná úroveň komunikace, dochází zpravidla k jevům, kdy se navzájem všechny procesy se sdíleným číselníkem negativně ovlivňují.

Z dalších variací možných stavů lze vybrat ten, pokud oba procesy č. 1 a č. 2 používají vlastní číselníky, ovšem logicky propojené. Pokud tedy správce procesu č. 1 a příslušného číselníku ho nějakým způsobem upraví, správce procesu č. 2 a příslušného číselníku má na výběr možné varianty:

Lze tedy odvodit, že správce číselníků by měl provádět aktualizaci s ohledem nejen na proces, za který zodpovídá, ale také s ohledem na všechny procesy, které číselník užívají se zřetelem na možné další dopady. Protože zpravidla platí, že každý proces pracuje s nějakými vstupy a měl by tvořit použitelné výstupy.

U jednotlivých položek číselníku může dojít k několika změnám:

Důsledky jednotlivých změn mohou být různé. Jako součást datové věty (což je logická posloupnost položek různých číselníků s určením množství zdrojů - finančních, věcných, lidských) má zrušení položky číselníku za následek definitivní ztrátu alokovaných zdrojů.

Pří sloučení více položek nevzniká v období použití závažný problém. Dokonce ho lze použít kdykoli i v průběhu procesu.

Při rozložení položek na několik položek by mělo dojít k rozložení zdrojů na tyto položky, původně přiřazených jedné položce číselníku.  Bez informace, jak zacházet se zdroji alokovanými k původní položce, dochází ke ztrátě zdrojů nebo jejich chybné alokaci.

Nová položka číselníku nemá alokované zdroje, a jsou na ní alokované zdroje, které byly v předešlých procesech nebo cyklu alokovány jinde.

Před každou změnou číselníku je nutné si ovšem také uvědomit, že dochází ke ztrátě kontinuity historické báze dat. Tzn., že již nepůjde bez určitého zkreslení porovnat vývoj alokace zdrojů v jednotlivých řadách dat v několika obdobích na stejných položkách a každá změna číselníku způsobí nějakou odchylku. Nelze tedy zcela souhlasit s častými, nepravidelnými úpravami číselníků užívaných v rezortu MO bez dostatečného ujasnění negativních dopadů.

Ponechání již neplatné položky v číselníku, např. z důvodu zachování datové řady, není vhodné řešení. V roce 2006 bylo možné v číselníku vojenských útvarů jednoho z klíčových dokumentů rezortu MO nalézt vojenský útvar, který byl při rozdělení republiky (1993) redislokován na Slovensko a tam v roce 1995 zrušen. Protože byl v číselníku nadále, alokovaly se na něj nadále příslušné zdroje (reálný případ).

Jakýkoli zásah do již užívaného číselníku má negativní dopady, proto je nutné každou úpravu číselníku provést po vyhodnocení těchto dopadů.
Pokud dojde ke změně číselníku dat, je nutné takovou změnu vhodně evidovat.

Kontinuita historické báze dat


Schéma č. 2

Vhodným řešením, jak udržet kontinuitu historické báze dat (např. číselník dat), je sledování postupných změn. V jednotlivých generacích úprav se k novým záznamům přidá odkaz na předchozí stav (rodiče) a rodičovskému záznamu se přidá odkaz na nový záznam (potomka). Celý algoritmus je přehledněji znázorněn na schématu č. 2.

Zabezpečení vazby mezi jednotlivými ,,generacemi" jednotlivých stavů (řazených chronologicky) je úkolem obslužného software podle uvedeného algoritmu.

Datové rozhraní

Dosud jsou v rezortu MO ČR (a jistě se nejedná o nějaký výjimečný případ ve státní správě ČR) budovány podpůrné informační systémy (IS), které nezohledňují navzájem požadavky na datové vstupy (včetně již zmíněného příkladu s výměnou číselníků). Dochází pak někdy k paradoxu, že vstupy se do IS přepisují RUČNĚ z tištěných sestav jiného IS.  Vzájemná propojitelnost informačních systémů v mnohých případech závisí jen na interpersonálních vztazích zástupců jednotlivých složek, řídících ,,své", na podporu své činnosti vybudované, podpůrné IS - v pozitivních i negativních dopadech. Příkladem z praxe může být předávání souboru s výstupními sestavami v ,,elektronické podobě" ve formátu PDF(4).
Při výměně dat (viz část ,,Aktualizace číselníku") je důležité dodržet ,,pouze" dvě základní podmínky:

  1. validita dat - pod tímto souhrnným označením lze chápat
    • věcnou správnost informací;
    • aktuálnost.
  2. formální podoba dat, která zahrnuje dodržení dohodnuté struktury dat, jejich formátu ve správných metrických jednotkách(5), v případě potřeby doplněné textovým popisem. Důležitým aspektem je včasnost (dodržení termínu) předání dat.

Mělo by být zřejmé, že po předání dat by předaná data NEMĚLA být dodatečně poskytovatelem dat měněna.
Na formátu souboru dat již tolik nezáleží a není podstatné, jestli půjde o prostý text, soubor MS Access, MS Excel nebo rozšířený XML formát [7]. Podstatné je, aby poskytovatel a příjemce dat disponovali vhodným softwarovým nástrojem pro export/import dat z/do IS.

Relační databáze

Poměrně často jsou v rezortu MO distribuovány a užívány číselníky, které obsahují více věcně nesouvisejících atributů.

Takovým je např. číselník cílů a úkolů, které jsou dále přiřazeny jednotlivým VÚZ. U takového provedení číselníku je zvýšená pravděpodobnost nutnosti aktualizace, jelikož při změně jednoho atributu (cíl, úkol nebo VÚZ) se musí aktualizovat celý tento kombinovaný číselník.

Již při tvorbě číselníku by se mělo přihlížet k jeho snadné údržbě (aktualizaci). Na myšlence umístění informace v několika samostatných tabulkách, propojených vzájemně vztahy (relacemi) - relační databáze [8]. Změnu číselníku lze tak provádět jen na jednom místě. Minimalizuje se tím čas potřebný k aktualizaci a možnost vzniku chyb.

Nejdříve je nutné doplnit některé pojmy a jejich význam:

Primární klíč

Primární klíč je atribut, jehož hodnota je pro každý záznam jedinečná. Může to být např. rodné číslo, u kterého je zaručeno, že je má každý občan České republiky jedinečné. U čísla VÚZ není zřejmé, jestli je jedinečné, a proto lze primární klíč i automaticky generovat. Často se tento identifikátor (zaužívaný název) ,,logicky" konstruuje jako další atribut tabulky. Např. všechny útvary podřízené Velitelství XY musí začínat číslicí 1 a tvoří se tak další ,,šifrovaný" jazyk. Řazení jednotlivých záznamů do skupin je možné tvořit dalšími atributy.
Primární klíč je v každé tabulce vždy jen jeden.

Cizí klíč

Cizí klíč je atribut, který slouží jako odkaz na jinou tabulku a obsahuje tedy primární klíče jiné tabulky. Pokud se tabulka účastní více vztahů s ostatními tabulkami, může obsahovat více cizích klíčů.


Schéma č. 3

Mezi tabulkami mohou existovat různé typy vztahů. Nejčastější vztah je 1:N, kdy jednomu záznamu jedné tabulky je přiřazeno několik záznamů druhé tabulky.  Z důvodu kompatibility jsou upravené názvy atributů a tabulek tak, aby neobsahovaly diakritická znamínka a mezery, mezery mezi slovy jsou nahrazeny podtržítkem (,,_"). Lze tak bez problémů v databázi procházet data podle jména tabulky a jejího atributu.

Na schématu č. 3 je zřejmá vazba 1:N mezi jednotlivými záznamy v tabulkách podle jednotlivých klíčů (primárních a cizích).  Jeden útvar má tak přidělen pomocí vazby mezi tabulkami jeden a více cílů.


Schéma č. 4

Jiným typem vazby mezi tabulkami relační databáze je vazba M:N (schéma č. 4). S úpravou výše uvedeného příkladu se jedná o vztah, kterým je vyjádřeno, že jeden útvar může mít přidělených jeden a více cílů a naopak, jeden cíl může být realizován jedním a více útvary.

Vložením převodní tabulky ,,Tabulka_VUZ_Cil" se všechny vztahy zjednoduší na vztahy 1:N. Primární klíč je v této tabulce tvořen jedinečnou kombinací cizích klíčů z tabulek ,,Tabulka_VUZ" a ,,Tabulka_Cile". Lze tak identifikovat, které útvary se podílejí na realizaci cílů a jaké cíle jsou přidělené vojenskými útvary a zařízeními.

V praxi se běžný uživatel s relačními tabulkami setká jen ve formě generovaného výstupu. Pro řízení procesu je ovšem nezbytné si uvědomit, že softwarová podpora může být vytvořena až po systémových principech tvorby, řízení a vyhodnocení procesu, přičemž každá změna znamená dodatečné úpravy podpory procesu(6). Většinou jde o přirozený a žádoucí vývoj (progres, evoluce), někdy se naopak jedná o zřejmé pochybení již v samotném procesu s veškerými věcnými, finančními a časovými následky.

V tomto příkladu jsou jednotlivé identifikátory (primární a cizí klíče) použity pouze za účelem vysvětlení vazby (relace) mezi tabulkami. Standardní uživatel (či spíše spotřebitel) se s nimi za normálních okolností nesetká.

SQL

Jeden z nástrojů, kterým lze manipulovat s relační databází, je programovací jazyk SQL (Structured Query Language). Jazyk SQL je programovací jazyk připomínající angličtinu, který je srozumitelný pro databázové programy. Je definován normou ISO/IEC 9075. Jazyk SQL je programovací jazyk, který pracuje se sadami údajů a relacemi mezi nimi. Na rozdíl od jiných programovacích jazyků není ani pro začínajícího uživatele obtížné jazyk SQL číst a porozumět mu.

Jednoduchý příklad příkazu SQL využívající výše uvedených relačních tabulek, který načte seznam vojenských útvarů a zařízení, jejichž jméno obsahuje řetězec ,,mech" (mechanizovaný), může vypadat například takto:
SELECT nazev_utvaru
FROM tabulka_VUZ
WHERE nazev_utvaru LIKE "*mech*";

Podrobný popis jazyka SQL je mimo předmět tohoto článku a k dalšímu studiu lze doporučit odbornou literaturu, např. [9], [10], [11].

Grafické rozhraní

Na základě praxe lze předpokládat, že při vyšším počtu zpracovatelů podkladů jich celá řada (a zajisté v dobrém úmyslu) využije možnost zpracování podkladů k vložení dalších, zpřesňujících údajů - resp. poznámek. Vysoce pravděpodobné je také poskytování podkladů v odlišné formě, zejména u výše postavených zpracovatelů v hierarchii organizace. Negativním důsledkem je, že takové vstupy nelze bez dodatečné opravy využít při hromadném zpracování dat a snižují jejich věrohodnost.


Obrázek č. 2

Chyby způsobené ručně vkládanými vstupy (nejedná se jen o překlepy, ale také o použití zkrácených slov, nesprávného názvu atd.) mohou být eliminovány použitím vizuálních grafických prvků naplněných předdefinovanými hodnotami z číselníku dat. Takových prvků existuje celá řada, mezi nejčastěji používané vizuální prvky patří ,,rozevírací seznam", známý také pod anglickým názvem - ,,ComboBox" [12] - obrázek č. 2.

Na druhou stranu, jedinečnost některých potřeb, působností nebo úkolů vyžaduje dodatečné upřesnění, prováděné často v různé kvalitě a rozsahu. V případě jedinečných vstupů od uživatelů vzniká potřeba tyto vstupy dodatečně vyhodnocovat, seskupovat nebo jinak standardizovat. Je výhodnější již před sběrem potřeb od uživatelů umožnit svou potřebu zařadit do vhodné kategorie (skupiny) v logickém řazení od obecného ke konkrétnímu zařazení potřeby - což zase klade vyšší nároky na tvůrce číselníku dat.

Číselník dat by měl obsahovat všechny možnosti a umožnit tak po jeho použití automatizované zpracování dat. Musí ale, v případě neurčitého počtu záznamů nebo položek, obsahovat záznam nebo položku pro případný nový vstup od uživatele (nová položka, poznámka, další, nový apod.).

Původní stručný seznam vojenských útvarů a zařízení může být také rozšířen o další logické doplňující informace. Předně, uvedený seznam by po vyplnění reálných informací a jen málo rozšířený podléhal zvláštnímu režimu utajovaných informací podle nařízení vlády č. 522/2005 Sb., kterým se stanoví seznam utajovaných informací v působnosti jednotlivých ministerstev a musel by být utajován na stupeň ,,V".

Takto rozšířený číselník po propojení na data již otvírá další možnosti tvorby výstupů pro analýzy, verifikace, rozhodnutí atd. (záleží na účelu tvorby číselníku dat).

Závěr

Příspěvek se zabývá dosud obecně nepopsanou oblastí v softwarové podpoře procesů - tvorbě a aktualizaci číselníku dat - ve všech možných aspektech. Vychází z několikaleté praxe tvorby číselníků v procesu střednědobého plánování a z prostudování několika veřejně přístupných ,,číselníků dat" jiných procesů. Některé z těchto číselníků obsahovaly podle autora článku řadu kritických, až diletantských chyb, které způsobily, že takové číselníky dat byly nepoužitelné v jiných procesech, neumožňovaly aktualizaci a přiměřenou stabilitu (kontinuitu historické báze dat) souvisejících procesů.

Základním východiskem a s využitím odborné literatury je sladěna a použita vhodná terminologie.

Za číselník dat se považuje množina věcně souvisejících a standardizovaných jedné a více položek, formálně vyjádřených pomocí textu nebo řady číslic, s jednoznačnou identifikací každého záznamu, sestavených v tabulce, sloužících ke standardizování podkladů.

Dále, vzniku číselníku dat by měla předcházet analýza se zaměřením na účel a strukturu číselníku dat. Je nutné identifikovat vzájemné vazby na vstupech a výstupech mezi jednotlivými procesy, které číselník dat využívají přímo nebo v odvozené podobě.

Již při tvorbě číselníku dat je nutné pamatovat na pozdější nezbytné úpravy s minimalizací pozdějších nevyhnutelných negativních dopadů. Aktualizaci číselníku dat je věnována značná pozornost se závěrem, že nezbytnou aktualizaci číselníku dat je nutné vhodně věcně a časově sladit s navazujícími procesy.

Značná část článku je věnována technické části provedení číselníku. Nemá se jednat o návod, ale o poskytnutí teoretických základů pro příslušné manažery a snad i pokus o částečné odstranění ,,pověstí" o technické složitosti a z toho vyplývající finanční náročnosti softwarového provedení, vydatně živené na jedné straně specializovanými firmami poskytujícími outsourcingové řešení a elementární neznalostí některých manažerů, ovlivňující vývoj informačních systémů v rezortu MO ČR.

Informace obsažené v článku by měly být zohledněny při tvorbě a řízení jakéhokoli procesu, u kterého se předpokládá softwarová podpora. Lze tak předejít řadě možných problémů s dopady na personální, časovou a finanční náročnost při hledání jejich dodatečných řešení.

Literatura:
[1] HERNANDEZ, Michael J., VIESCAS, John L. Myslíme v jazyku SQL - Tvorba dotazů. 1. vydání. Grada Publishing 2004. ISBN: 80-247-0899-X.
[2] http://www.kosek.cz
[3] příloha č. 4 Odborné nařízení pro zpracování návrhu státního rozpočtu a střednědobého rozpočtového výhledu v rezortu Ministerstva obrany, čj. 80-34/2010-8201, ze dne 30. dubna 2010.
[4] http://adisepo.mfcr.cz/adistc/adis/idpr_pub/epo2_info/popis_struktury_seznam.faces (popis struktury souborů daňové správy - MF ČR).
[5] http://www.ics.muni.cz/zpravodaj/articles/369.html.
[6] http://www.dbase.com/dBase_Knowledgebase.asp.
[7] http://www.w3.org/XML/.
[8] VIESCAS, John, CONRAD Heft. Mistrovství v Microsoft Office Access 2007. Computer Press 2008. ISBN: 978-80-251-2162-7.
[9] SHELDON, Robert. SQL - začínáme programovat. Grada 2005. ISBN:80-247-0999-6.
[10] GROFF, James R., WEINBERG, Paul N. SQL - Kompletní průvodce. Computer Press 2005. ISBN: 80-251-0369-2.
[11] OPPEL, Andy. SQL bez předchozích znalostí - Průvodce pro samouky. Computer Press 2008.  ISBN: 978-80-251-1707-1.
[12] http://msdn.microsoft.com/cs-cz/library/ms754288.aspx.

(1) Ostatní termíny jsou vysvětleny při prvním použití (zpět)
(2) Obchodní značka firmy Microsoft pro několik typů operačních systémů (zpět)
(3) Pro programátory: jedná se o typ označený UInt64 (zpět)
(4) (Portable Document Format - PDF) - formát souborů vyvinutý firmou Adobe k uložení a tisku dokumentů v identickém formátu nezávisle na použitém software a hardware. Pro účely předání dat v souboru obsažených k importu do IS naprosto nevhodné (zpět)
(5) Operace se správnými hodnotami, uváděnými v jedné části např. v Kč a v jiné části v mil. Kč vede zpravidla k fatálním výsledkům (zpět)
(6) Jedná se o teoreticky jednoduchou a logickou konstrukci. Praxe bývá bohužel odlišná. Autor tohoto článku negativním oponentním posudkem zamezil realizaci dvouletého výzkumného projektu, ve kterém se v první části nakupoval software a v další části se posuzovala jeho vhodnost k podpoře procesu, který do té doby nebyl a ani dosud není nastaven a popsán - vše za několik milionů Kč (zpět)


Close