VÝVOJ APLIKACÍ S VYUŽITÍM NATIVNÍHO DATABÁZOVÉHO SYSTÉMU VEMA Ing. Bc. Jaroslav Šmarda Vema, a. s.
[email protected] Abstrakt Společnost Vema, a. s., která patří již 15 let mezi přední dodavatele aplikací pro oblasti řízení lidských zdrojů, ekonomiky a logistiky v České a Slovenské republice, používá ve všech svých aplikacích nativní databázový systém a generátor aplikací DBV. Datový model databáze DBV je odvozen od relačního tak, aby co nejvíce odrážel potřeby ekonomických aplikací, takže obsahuje tabulky s variantními řádky nebo formuláři a několik možností pro vyjádření vazeb mezi tabulkami. Základem systému ukládání dat jsou indexsekvenční a kmenový (rozšířený ISAM) soubor, které umožňují sdílený přístup uživatelů. Ukládání dat je optimalizováno pro spojování mnoha (desítky nebo stovka) tabulek (například s personálními údaji zaměstnanců). Použití databázového systému DBV je svázáno s vytvořením aplikace generátorem. Takto vygenerované aplikace mají společné systémové jádro s řadou standardních vlastností, mezi které patří použití datového procesoru pro přístup k veškerým údajům a rozsáhlé možnosti uživatelského přizpůsobení aplikací. Aplikace jsou primárně určeny pro provoz v režimu s aplikačním serverem a tenkými klienty na stanicích. Mohou samozřejmě také fungovat v běžném síťovém provozu.
1. Vlastnosti aplikací Vema Společnost Vema, a. s. patří mezi největší dodavatele personálních informačních systémů v České a Slovenské republice. O tom svědčí počet zákazníků, kterých je v současnosti více než 4 200. Aplikací pro zpracování mezd Vema jsou zpracovávány mzdy pro téměř 600 000 zaměstnanců v ČR a SR. To je číslo, kterým se nemůže žádný jiný dodavatel personálních informačních systémů. Jednou z příčin úspěchu aplikací Vema u zákazníků je také využití nativního databázového systému DBV (zkratka z databáze Vema) spojeného s generátorem aplikací a sestav, který tvoří jádro všech aplikací Vema. Nativní databáze DBV umožňuje vytvářet robustní aplikace s efektivním přístupem k datům přesně podle potřeb klientů se širokým možnostmi přizpůsobení aplikací individuálním požadavkům uživatelů. Výhody použití nativního databáze DBV se ještě zvýrazní v případě řešení aplikací ve variantě s aplikačním serverem a tenkými klienty, které je vhodné pro všechny typy sítí včetně internetu. Na využití nativního databázového systému DBV se musíme podívat z širšího pohledu, protože se nejedná o izolovanou část, ale o provázaný systém zahrnující také společné systémové jádro aplikací. Proto se nejprve zastavíme u základních systémových vlastností aplikací Vema. Mezi základní patří:
Jednotný vzhled a systém ovládání všech aplikací Na obrázku č. 1 můžete vidět typické uživatelské rozhraní aplikace Vema. Rozhraní je úplně shodné v případě použití tenkého klienta i v standardní síťové verze. V levé části vidíme stromovou nabídku všech souborů a funkcí aplikace. V pravém okně je v tomto případě v datovém editoru otevřen jeden ze základních souborů aplikace pro zpracování mezd s údaji o pracovněprávním vztahu zaměstnance.
Obrázek č. 1 Typické uživatelské rozhraní aplikace
Přístup k datům prostřednictvím univerzálního datového procesoru Datový editor je obecný datový procesor pro práci se všemi soubory všech aplikací. Výhodou pro uživatele je, že práce se všemi soubory je naprosto shodná a uživatel má k dispozici širokou škálu funkcí, které mu umožňují efektivní zpracování dat. Datový editor nepotřebuje programátory pracně navrhované a uživatelem těžko modifikovatelné formuláře pro jednotlivé soubory. Návrh obrazovek je zcela automatický. Vidíme, že údaje jsou rozmístěny do dvou sloupců. V horní části obrazovky oddělené od ostatních vidíme klíčové položky (Osobní číslo) a tzv. identifikační položky (například Příjmení). Identifikační údaje nemají charakter klíče věty, ale uživatelé je vyžadují pro přehlednost. Uživatelské modifikace aplikací Uživatel má k dispozici řadu funkcí, které mu umožňují přizpůsobit aplikací svým potřebám. Například při práci se souborem v datovém editoru může kdykoliv skrýt nepotřebné údaje a okamžitě dojde k překreslení obrazovky. Jednoduchým způsobem je možno modifikovat nabídky funkcí a souborů, vytvářet jednoduché sestavy nebo měnit funkčnost aplikace nastavením uživatelských událostí. Řešení aplikační server/tenký klient Pro širokou škálu sítí je k dispozici řešení ve variantě aplikační server/tenký klient. Na jednom počítači v síti běží aplikační server, který řeší datovou a zpracovatelskou vrstvu aplikace. Uživatelé z počítačových stanic přistupují k aplikaci prostřednictvím univerzálních (z hlediska aplikací Vema) tenkých klientů, který řeší prezentační vrstvu aplikace. Na rozdíl od obvyklého řešení, kdy je využíván
univerzální webový prohlížeč jako tenký klient, poskytuje toto řešení uživateli plnou funkčnost aplikace. Uživatel prakticky nepozná, zda pracuje s aplikací v síťovém řešení nebo s tenkým klientem. Tenký klient využívá obecný síťový protokol a samozřejmě funguje v internetu nebo intranetu. Portálové řešení aplikací Pro přístup širšího okruhu uživatelů (například všech zaměstnanců v podniku ke svým personálním údajům) je k dispozici řešení využívající universální webový prohlížeč (MS IE) jako tenkého klienta. Prostřednictvím portálového řešení mají uživatelé přístup k vybraným údajům včetně možnosti aktualizace.
2. Nativní databáze DBV 2.1. Datový model Při popisu datového modelu se budu zabývat především odlišnostmi datového modelu DBV oproti běžným databázím. Nejprve se podíváme na základní požadavky kladené na datový model DBV. 2.1.1.
Základní požadavek na datový model DBV
Primárním účelem databáze DBV je ukládání dat z oblasti lidských zdrojů, ekonomiky a logistiky. Aplikace pro řízení lidských zdrojů pracují především s údaji o zaměstnancích. Zaměstnance charakterizují desítky typů formulářů a navíc v jednom typu formuláře může být několik variant údajů (např. formulář srážek zaměstnance může obsahovat jednu z asi deseti druhů srážky). Základním požadavkem je tedy efektivního přístupu k množině formulářů o zaměstnanci. Klasické spojení několika desítek typů tabulek by bylo hodně neefektivní. 2.1.2.
Základní vlastnosti datového modelu
Nejzákladnějším objektem modelu je soubor, obdobou v klasickém relačním modelu je tabulka. Datový model DBV je odvozený od relačního a navíc obsahuje: •
soubory s variantní částí řádku (bez klíčových položek ve variantní části)
•
kmenový soubor s variantními formuláři (i klíčové položky)
Kromě standardních primárního a sekundárních indexů je v DBV využíván také formulářový index, který optimalizuje přístup k jednotlivým typům formulářů v kmenovém souboru. 2.1.3.
Požadavky na vazby mezi soubory
V personálních a ekonomických aplikacích jsou často používány údaje, které mohou obsahovat jen hodnoty z oboru hodnot určeného obsahem jiného souboru, který se pak nazývá číselník (například položka s číslem dodavatelské firmy obsahuje jen hodnoty ze seznamu firem). Další obvyklou vazbou v aplikacích je taková, kdy k větě souboru jednoho typu logicky patří množina vět souboru dalšího typu (k záhlaví faktury patří množina řádků faktury). 2.1.4.
Číselníky
V DBV při definici položky je možno specifikovat, který soubor je číselníkem pro tuto položku. Systém pak sám zajišťuje integritní kontrolu, nabídku povolených hodnot i otevření číselníkového souboru pro případné doplnění číselníkových hodnot. DBV rozlišuje dva druhy číselníků: pevné a variabilní.
Pevné jsou tvořeny seznamem dvojic číslo a vysvětlující text. Pevné číselníky nemůže uživatel měnit, ale ani k tomu nemá důvod. Variabilní číselníky je běžným souborem, ve kterém je při definici určeno, která textová položka tvoří vysvětlující text pro číselníkové hodnoty. Na obrázku č. 2 můžete vidět v datovém editoru otevřený soubor se začátky a konci pracovněprávního vztahu zaměstnanců s nabídkou číselníkových hodnot s důvody vzniku pracovněprávního vztahu, nabídku uživatel vyvolá stiskem klávesy F2 nad položkou Důvod vzniku PPV. Dvojicí kláves Ctrl+F2 je možno číselník (pouze variabilní) otevřít jako soubor a případně pořizovat nové hodnoty do číselníku.
Obrázek č. 2 Nabídka hodnot z číselníku důvodů vzniku pracovněprávního vztahu
2.1.5.
Podsoubory
Pro vyjádření logické vazby věty jednoho souboru k množině vět jiného souboru se v DBV používá mechanismus tzv. podsouboru. V personální databázi existuje soubor základních údajů o zaměstnancích, ve kterém je jedna věta o každém zaměstnanci. K větě se základními údaji o zaměstnanci patří množina vět s údaji o dětech zaměstance, ale také například jedna věta s údaji o partnerovi, množina vět s údaji o plánované dovolené a mnoho dalších. Na obrázku č. 3 vidíme větu se základními údaji o zaměstnanci. Všechny položky, které obsahují znaky šipku => představují podsoubory. Takovou je i položka Děti v levém sloupci.
Obrázek č. 3 Personální soubor údajů o zaměstnanci s odkazy na podsoubory
Obrázek č. 4 Datový editor po vstupu do podsouboru s údaji o dětech zaměstnance
Dvojitým kliknutím myší na položku Děti se otevře podsoubor vět s údaji o dětech zaměstnance, který vidíme na obrázku č. 4. Podsoubor je možno editovat stejným způsobem jako základní soubor jenom v menším okně.
2.1.6.
Požadavek na časovou platnost záznamů
Většina údajů v personálních a ekonomických aplikacích má časovou platnost, tzn. platí v určitém období (dovolená zaměstnance od – do) nebo od určitého data (zvýšení platu zaměstnance od). Stejně tak příslušná legislativa má novely zákonů (zvýšení minimální mzdy od) a vyhlášek. 2.1.7.
Řešení časové platnosti
Soubor s časovou platností obsahuje systémovou položku typu datum a systém zajišťuje, aby uživatelé pracovali s platnými větami. V případě měsíčního zpracování (například zpracování mezd) se systém chová tak, že uživatele pracuje s větami právě aktuálního měsíce zpracování (soubor s dovolenými zaměstnanců apod.). V případě zobrazení vět z minulých měsíců uživatel vyvolá dialog, který vidíme na obrázku č. 5 a zadá interval, který ho zajímá.
Obrázek č. 5 Nastavení intervalu časové platnosti
2.2. Systém ukládání dat Ukládání dat v souborech je optimalizováno z hlediska použití. Systém rozlišuje několik typů fyzických souborů pro ukládání dat. Data jsou ukládána v binární formě. Pro práci se systémem ukládání dat je vytvořeno programátorské rozhraní, které zakrývá rozdílné způsoby ukládání dat. V rozhraní se rozlišují dvě vrstvy: •
fyzická
•
logická
Fyzická vrstva řeší uložení údajů do souborů OS, logická vrstva je obdobou trigerů v běžných databázových systémech. Z hlediska přístupu pro zápis lze rozlišit fyzické soubory na ty, které umožňují sdílený zápis a na ty, které jsou jen výjimečně používány pro zápis a umožňují tedy pouze výlučný zápis. 2.2.1.
Fyzické soubory s výlučným přístupem pro zápis
Fyzické soubory s výlučným přístupem pro zápis: •
soubor s jednou větou (nepotřebuje klíčové položky)
•
tabulka (jednoduchá tabulka, věty mají klíčové položky a jsou ukládány seřazeny podle klíčů, není budován indexový soubor)
•
časová tabulka (až 12 jednoduchých tabulek po měsících v roce, obvykle přístupná poslední tabulka aktuálního období zpracování, možnost vytisknout sestavy za celý rok)
2.2.2.
Fyzické soubory se sdíleným přístupem pro zápis
Podstatné pro řešení nativního databázového systému DBV jsou fyzické soubory se sdíleným přístupem: •
indexsekvenční soubor
•
kmenový indexsekvenční soubor
2.2.3.
Základní vlastnosti obou typů indexsekvenčních souborů
Pro oba typy indexsekvenčních souborů platí řada společných vlastností. Datové věty a indexy jsou ukládány do samostatných souborů po stránkách pevné délky. Všechny indexy (primární a libovolný počet sekundárních) jsou uloženy v jediném indexovém souborů, který může být kdykoliv znovu vytvořen funkcí reindexace. Indexy jsou organizovány jako B-stromy. Nové a aktualizované datové věty jsou ukládány na konec datového souboru, ve kterém jsou všechny verze věty. To umožňuje návrat k minulým verzím věty. Funkce reorganizace komprimuje datový soubor tak, že v něm ponechá jen poslední aktuální verze vět. 2.2.4.
Vlastnosti kmenového indexsekvenčního souboru
V kmenovém indexsekvenčním souboru je ukládáno více (i více než 100) typů záznamů, které označujeme jako formulářů. Všechny formuláře mají společnou část klíče (osobní číslo, číslo formuláře) a každý typ formuláře má další klíčové položky. Formuláře tvoří skupiny (všechny formuláře pro jednoho zaměstnance), jeden z formulářů je systémový a jsou v něm vytknuty základní identifikační a indikační údaje o skupině formulářů jako je příjmení a jméno zaměstnance nebo indikační údaj, zda zaměstnanec má již vypočítanou mzdu.
2.3. Systém uživatelů a sdílený přístup Sdílený přístup v databázovém systému DBV je založen na systému uživatelů a rolí. Pod pojmem uživatel se rozumí skutečný fyzický uživatel identifikovaný jménem, pod pojmem role se rozumí například administrátor aplikace, mzdová účetní nebo fakturantka. Podle uživatelů a rolí se nastavují: •
oprávnění pro přístup nebo pro aktualizace k jednotlivým souborům a položkám souborů,
•
oprávnění pro přístup k aplikačním funkcím,
•
uživatelské kontroly a parametrizace spuštěných sestav (například sestavy jen za určitý organizační celek) a
•
technické nastavení (například obrazovky, klávesnice a myši).
Sdílený přístup byl řešen na základě zadání, kdy byl vyžadován sdílený přístup bez centrálního databázového stroje. Řešení umožňuje provoz aplikací Vema ve variantě se sdílením souborů v síti, kdy server je využíván pouze jako souborový server. Tato varianta, která je stále velmi využívána, ale už není nejvíce preferovanou variantou. Nejmodernějším a nejefektivnějším řešením je dnes provoz aplikací Vema ve variantě s aplikačním serverem a tenkými klienty. Z hlediska sdíleného přístupu aplikační server zajišťuje paralelní provoz aplikací na serveru, ale nenahrazuje centrální databázový stroj. To se ukázalo jako velmi výhodné řešení z hlediska robustnosti zpracování. Aplikační procesy jsou tak téměř nezávislé. Sdílený přístup je založen na mechanismu zamykání abstraktních prostředků. Takový abstraktním prostředkem může být například datový soubor, textová tzv. memo položka, celé datové prostředí aplikace a prostředek ALL (vše). Mechanismus zamykání využívá těchto 5 typů zámků prostředků: exclusive, write, prevent write, read.
3. Vývojové prostředí Vema Použití nativního databázového systému DBV je neoddělitelně spojeno s vývojovým prostředím DBV, které je kromě překladače MS Visual C++ tvořeno především generátorem aplikací DBV a generátorem sestav GES.
3.1. Generátor aplikací Generátor je běžná aplikace Vema. Na obrázku č. 6 vidíme stromovou nabídku souborů a funkcí, kterou nabízí generátor aplikací.
V horní části nabídky v podnabídce Aplikace se definují základní parametry aplikace jako celku. V podnabídce Nabídky autor aplikace specifikuje stromovou nabídku aplikačních funkcí. V podnabídce Soubory se definují soubory, položky souborů, klíče a indexy souborů. V podnabídce číselníky jsou specifikovány pevné číselníky aplikace. V dolní části nabídky v podnabídce Funkce vidíme základní funkci celé aplikace Generování aplikace. Součástí aplikace jsou kromě souborů vytvořených generátorem aplikace také spustitelné soubory s aplikačními a systémovými funkcemi vytvořenými v C++.
3.2. Generátor sestav Do aplikace zpravidla patří řada sestav. Pro popis sestavy slouží v DBV neprocedurální textový jazyk. Základem jazyka jsou konstrukce pro výběr údajů z databáze a tisk údajů. Stejný jazyk se používá také pro dynamické dokumenty, tj. soubory, do kterých se v okamžiku otevření doplní údaje z databáze. Dynamické dokumenty mohou být ve formátech: xml, html a xls.
Obrázek č. 6 Generátor DBV aplikací
4. Silné a slabé stránky řešení Na závěr článku se budeme věnovat silným a slabým stránkám řešení. Mezi silné stránky řešení patří: •
Použití nativního databázového systému umožňuje vytvářet aplikace předevevším pro oblasti řízení lidských zdrojů, ekonomiky a logistiky v souladu s požadavky uživatelů, protože systém je možno kdykoliv přizpůsobit požadavkům aplikací.
•
Řešení je robustní a efektivní, nemáme prakticky žádné problémy se ztrátou dat v databázích a s výkonností aplikací.
•
Řešení aplikací s nativním databázovým systémem DBV je vhodné pro malé i velké organizace. V jednouživatelské verzi (například aplikace pro zpracování mezd pro malou školu), v řešení pro malou síť i v náročném zpracování s využitím aplikačního serveru (například zpracování mezd pro nemocnice s několika tisíci zaměstnanci) je většina funkcí úplně shodných.
•
Řešení s aplikačním serverem a tenkými klienty na stanicích je velmi výkonné, protože je optimalizované. Řešení minimálně zatěžuje síť a pracovní stanice a spolehlivě funguje i v internetu.
•
Řešení umožňuje dodavateli aplikací být nezávislý na dodavateli databázového systému (nezávislost na chybách a zpoždění některých užitečných funkcích).
•
Pro uživatele je příjemné, že řešení nevyžaduje nákup licencí databáze.
•
Řešení odlišuje aplikace společnosti Vema založené na nativním databázovém systému DBV od konkurence.
Slabé stránky: •
Hlavní a jedinou podstatnou nevýhodou je to, že některá výběrová řízení na výběr softwaru vyžadují SQL řešení. Nevýhoda se ale může stát i výhodou, pokud řešení konkurentů nabízejí sice SQL řešení, ale založené na jiném dodavateli databáze než který preferuje zadavatel výběrového řízení. Pak použití aplikací založených na nativním databázovém systému DBV je mnohem jednodušší než implementace databáze od jiného dodavatele.
•
Za určitou nevýhodu je možno považovat vyšší náklady spojené s vývojem databázového systému.
Další informace o řešení informačních systémů, které poskytuje zákazníkům společnost Vema, a. s., naleznete na www.vema.cz.
