ZÁPADOESKÁ UNIVERZITA V PLZNI. Úvod do projektu disertaní práce

Transkript

1 ZÁPADOESKÁ UNIVERZITA V PLZNI Akademický rok 2008/2009 Ing. Jaroslav HALVA

2 1 ChronData - databázové ešení provedení a vyhodnocení chronometráže ešení mé diplomové práce v roce 2006 ukázalo, že poteba softwarové podpory v oblasti normování spoteby asu je stále aktuálním tématem. Ukázalo se, že pedevším nástroj pro podporu provedení a hlavn statistické vyhodnocení chronometráže zcela chybí. I proto jsem svou diplomovou práci orientoval na koncepci softwarového nástroje pro podporu stanovení asové náronosti manuálních pracovních inností v polygrafickém závod. Následn došlo k pepracování a drobným zmnám ve struktue dat tak, aby bylo možné databázovou aplikaci využít také v oblasti strojírenství. S odstupem asu je možné odhalit postupn nkteré nedostatky systému zvlášt pak pi uvedení do praxe, takže vzniká poteba inovace. Dá se íci, že je toto tématem disertace: Vyvinout systém normování manuálních pracovních inností a rozšíit jeho funkce krom provedení a statistického vyhodnocení chronometráže také na další metody stanovení asové náronosti vybrané operace. Je nasnad implementovat nkteré zásady REFA a zamit se také na další asové studie jako je snímkování i multimomentková pozorování. Vzniká otázka, zda má taková práce smysl? Praxe ukazuje, že existuje mnoho nástroj, které dokáží racionalizovat pípravné fáze výroby jako je technologická píprava, obsahují mnohdy i nkteré moduly pro normová, ale z vtší ásti je to MTM, nebo prost nástroj pro využití tabulkových normativ, který definuje skladbu asu a ze zadaných hodnot normativ sestavuje vlastní normu spoteby. Jak ovšem získat hodnoty platných normativ? V souasné dob se jedná o problém, jehož ešení zaspávalo celkem nkolik desetiletí, takže normativy stanovené v sedmdesátých letech (nkde dodnes používané) již nevyhovují moderním trendm technologie obrábní a prmyslové innosti vbec. Vyvstává myšlenka koncipovat relaní databázový systém s možností efektivního sbru dat mením a centrálním zpsobem vyhodnocení. Zvýšit tak produktivitu získávání dat napíklad chronometráží, jejíž výsledky mže management spolenosti sledovat, zatímco normovai, pracovníci v terénu, sestavují pomrn rychle (díky databázovému pístupu) široký okruh dat relevantních pro jejich statistické posouzení. Dílí ešení existují, i když zamená vtšinou na jinou oblast získávání asových údaj a pokud ano, vždy se jedná pouze o jednu metodu zpracování. Disertaní práce si klade za cíl nabídnout takových metod hned nkolik základních. O možné ešení projevuje zájem spolenost TPVGroup autoi databázového systému TPV2000 se zámrem implementovat takové ešení do vlastního systému za úelem možného dalšího využití v technologické píprav výroby. Tím získává ešení disertaní práce zcela jiný rozmr a hlavn další fázi vývoje. Pedpokladem je, aby byl systém schopen samostatného fungování. Tato úloha je prioritní. Plánované zalenní ásti systému jako modulu TPV2000 je plánované jako druhá fáze projektu. 2 Co by ml systém ChronData splovat? Jak již bylo nastínno, systém ChronData by ml vyplnit chybjící lánek v systémech technologické pípravy výroby pedevším v ásti stanovování asové náronosti technologických operací metodami odmování. Vtšina systém podporujících 2

3 technologickou pípravu výroby podporuje pevážn metody pedem stanovených as jako je MTM, protože tyto metody vykazují nejvtší pesnost a jejich použití zažívá jistý boom Metody pedem stanovených as nelze bez odborného zaškolení zvládnout ani s podprným programem. Jejich použití je tedy závislé na schopnosti uživatele a pedevším na zvládnutí techniky lenní operací nejen na jednotlivé úkony, ale pedevším také na dílí pohyby v úkonu, což je úkol pro laika velmi obtížný by i s podporou softwarového nástroje. Proti tomu se staví systém ChronData, který sám o sob disponuje s potebnými znalostmi tak, že uživatel mže podle pokyn provádt mení a získávat požadované hodnoty bez hlubší znalosti zásad provádní chronometráže. Je tak možné rozšíit pole možných mitel i na osoby, které jsou pouze seznámeni s programem. Díky databázovému zpracování by bylo možné penést odpovdnost za pípravu chronometráže na osobu znalou, vlastní mení pak mže provést osoba pouze zaškolená. (Týká se jen obsluhy programu.) Tuto skutenost ukazuje praxe. Jaká by tedy nová verze mla být? Pokud opomineme již zmiované funkce, které doplují systém o další metody asových studií, chceme též pizpsobit a koncipovat systém ve standardní relaní databázi tak, aby jej bylo možné modulárn zalenit do stávajícího TPV2000. Systém by ml pesto zstat sobstaný s podporou technologické pípravy výroby pro stanovení asových nároností strojních operací, dostaten variabilní i ve smyslu nastavení struktury jednotlivých druh as, nebo i tato je v dnešní dob variabilní a standard, který je používán v eské republice, je pouze jakýsi dodržovaný pedpis, nikoli norma, která by byla zásadní. Jako ešitel jsem omezen prostedky ke zvládnutí jednak návrhu databáze, ale pedevším ve zvládnutí koncipování aplikaní úrovn. Volím systém Delphi 7.0 spolen s databázovým serverem INTERBASE 6.0 (volná licence). Programovací jazyk Delphi disponuje praxí proveným nástrojem k tvorb databázových aplikací pomocí VCL (Visual Component Library) komponent, které byly spoleností Borland vyvinuty pímo pro server INTERBASE. Nebudeme proto používat ani struktury DBF soubor, dokonce opustíme i dlouho používaný databázový nástroje BDE (Borland Databáze Engine) a využijeme práv nových komponent k optimálnímu propojení aplikace s databázovým serverem. Výsledkem by mla být dvouvrstvá struktura Klient/Server, kde na stran klienta stojí aplikaní úrove vytvoená v Delphi, na stran serveru potom databázový server INTERBASE. Tato kombinace není jediná možná. (Volím ji jako optimální pro mé ešitelské schopnosti.) Delphi umjí kombinovat aplikaci i s dalšími druhy databází v podob pipojovacích etzc. Pak ovšem není možné využít širokou paletu pipravených komponent pro INTERBASE. Pro jiné databáze existují též hotová ešení pro ovládání databáze ze strany klienta. Jedná se o komponenty oznaované jako DAC (Direct Access Components). Tyto komponenty je ovšem nutné dokupovat dodaten. Obr. 2-1 Paleta komponent pro práci s INTERBASE Otázkou zstává, jakým zpsobem využít i dalších možných komunikaních nástroj, napíklad pro nkteré manažerské a vyhodnocovací funkce by bylo možné vytvoit webovou aplikaci pro internetový prohlíže a zpístupnit tak nkterá data (zejména výsledky mení a jejich statistické vyhodnocení) bez nutnosti instalace klientské aplikace. Tato možnost by byla pedmtem dalšího vývoje jako nadstavba celého systému. 3

4 Jaké by bylo využití? V souasné dob prosperují spolenosti zabývající se poradenstvím, v oblasti racionalizace práce. Nedílnou inností, které tyto spolenosti vykonávají, je práv stanovování asových nároností, obnova podnikových normativ atp. Využití ChronData by bylo pínosné, databázové zpracování by umožnilo ídit výsledky v míst sídla spolenosti, pitom by se asové údaje sbíraly v terénu. Odpadá tím pepis hodnot a asová prodleva vlivem dodatené pípravy dat pro jejich statistické posouzení. 3 Nástroje pro ešení Následující kapitola a pedevším její stat popisují nástroje pro ešení navrhovaného projektu. Bude zapotebí pipravit analytickou ást a navrhnout vhodný datový model. Pitom mžeme použít nkteré stat z již stávající verze systému ChronData a upravit je vhodn tak, aby vyhovly inovované verzi. Chceme souasn, aby systém sploval nkteré základní požadavky na technologickou pípravu výroby, bude nutné vhodn navrhnout strukturu pracoviš, závod, stroj a zaízení, nástroj a pípravk a dalších entit. Mžeme si v tomto ohledu njakým zpsobem pomoci? Opomineme-li databázový skript pro vytvoení SQL databáze a zamíme-li se pouze na myšlenku modelu, mžeme vyjít z nkterých již ešených projekt informaních systém, které vtšinou dávají k dispozici popis jednotlivých entit v rámci uživatelské píruky. Tak mžeme navrhnout entity pro stroje, zaízení, nástroje, abychom do nich zalenili všechny potebné atributy. Zpracování takového modelu pak provedeme pomocí njakého CASE nástroje. Dále se zamíme na vlastní zpracování klientské aplikace. I tato ást vyžaduje nejen uritou pípravu v návrhu ešení (jestli volit MDI aplikaci nebo modální otevíraná okna popípad jinak ) ale pedevším volbu vhodného jazyka. (s ohledem na schopnosti ešitele a na zvolený databázový server) Jak již bylo v pedcházející kapitole uvedeno, cílem je kombinovat možnosti Delphi a INTERBASE. 3.1 Navrhujeme datový model V návrhu datového modelu nám výrazn pomže CASE Studio. Jednak úeln vizualizuje navrhované struktury jak ERA diagramu (Entita Relace - Atribut) tak DFD (Data Flow Diagram) diagramu. Navíc nám umožní snadno a rychle generovat SQL skript pro vytvoení databáze vetn definovaných struktur a dokonce i vytvoí databázový report s popisem jednotlivých deklarovaných tabulek, atribut a vazeb. Následující text by mohl být struným návodem, jak s takovým systémem pracovat. V první ásti užívání programu s cílem vytvoení datového modelu musíme zvolit cílovou databázi. Vybíráme INTERBASE. Systém pak bude generovat skript pro založení databáze v syntaxi pro INTERBASE. I pesto, že je SQL (Structured Query Language) v jisté form standardizovaný, nkteré databáze se mohou mírn odlišovat v syntaxi tohoto jazyka. I zde titíž dochází k trvalému vývoji a pedevším také verzování, takže mžeme najít odlišnosti v jazyce SQL1 a SQL3. 4

5 Obr. 3-1 Výbr cílové databáze V analytické ásti realizace projektu je dležitá pedevším dekompozice a vytvoení seznamu atribut, které jsou následn pevádny z 1.NF do vyšší, minimáln však do 3.NF. (Protože tento dokument zatím nepopisuje vlastní realizaci, ale je jakýmsi reportem o budoucím prbhu projektu, nezabývám se zatím vlastním provedením této dekompozice Pedstavme si, že tato ást byla provedena a je nyní implementována do datové struktury pomocí CASE nástroje.) Jednotlivé entity se v CASE Studiu zakládají na pracovní ploše pomocí vizuálních komponent. Tyto se tažením myši umisují na pracovní plochu, kde se zárove zpracovávají nkteré jejich další vlastnosti. Obr. 3-2 Vizuální komponenty pro sestavení ERA diagramu Mezi základní vlastnosti tabulky (entity) patí definice jednotlivých atribut (sloupc tabulky). Systém eviduje jednak jejich název, tak fyzické názvy sloupc jak se budou objevovat ve struktue SQL databáze. Navíc i každý sloupec (atribut entity) obsahuje další vlastnosti, které po zadání do systému ovlivují cílovou databázi v její definici. 5

6 Obr. 3-3 Definované atributy tabulky souástí Pi ešení je dodrženo nkolik zásad ve volb názv sloupc. 1 Vlastnosti každého z atribut se definují ve zvláštním formulái. Zde je možné urit, zda se jedná o primární klí, zda je pole povinné nebo pípadn unikátní (unique). Souasn je zadáván název atributu a fyzický název sloupce. Název atributu je volen v eštin 2, fyzický název sloupce potom v anglitin pekladem. Z dležitých vlastností bych poznamenal dále datový typ a možnosti nastavení omezení zadání hodnoty tzv. CONTRAINTY. Je možné zadat limitující podmínku, poátení hodnotu pi založení záznamu a další možnosti. 1 Tyto zásady jsou pomckou autora/ešitele tak, aby bylo možné se v definované struktue lépe orientovat. Napíklad všechny fyzické názvy jsou v anglitin a zaínají písmenkem X, aby nedocházelo ke kolizím klíových slov SQL a názv atribut, entit a relací. Stejn tak i v definici cizích klí lze vysledovat jistá pravidla v názvech 2 Opt se jedná o zabhlou konvenci autora/ešitele. 6

7 Obr. 3-4 Vlastnosti atributu (sloupce) Pedpokládá se, že v analytické ásti je již navrženo, jaké datové typy se použijí v jednotlivých atributech. Cílem práce s CASE Studiem je získat pehlednou strukturu datového modelu a pedevším spíše dílích submodel, nebo rozsah databáze mnohdy neumožuje sledovat model v jeho celistvosti. Prakticky se tak více pracuje s jeho ástmi, napíklad se rozdlují jednotlivé moduly, aby struktura zstala pehledná. Je úelné, aby zakládané položky byly souasn dokumentovány poznámkou, kterou je možné zapisovat do píslušné záložky ve formulái vlastností. Tato poznámka mže obsahovat další informace o definovaném prvku (a je to tabulka nebo sloupec), která se zobrazuje v databázovém reportu. Toto je smysluplné a výrazn pomáhá pi ešení aplikaní úrovn. Stejným zpsobem jsou ešeny i jednotlivé relace mezi databázovými tabulkami. Jedná se o prvek, který má své vlastnosti a v závislosti na jejich nastavení se výsledná databáze také bude chovat. U relace je dležité volit její kardinalitu a pedevším chování vztahu rodi potomek. Co to znamená? Je možné nastavit tzv. restrikci v pípad, že existuje výše zmínný vztah. Ukažme si tento problém na klasickém píklad: Mjme definovanou tabulku spoleností a adres k dané spolenosti ve vzájemném propojení relací s kardinalitou 1:N. To znamená, že každé spolenosti mžeme definovat N adres. Založení adresy spoívá v piazení cizího klíe spolenosti tak, aby bylo zejmé, ke které spolenosti se adresa váže. Pokud bude tato vazba 7

8 restrikní, v pípad, že budeme chtít záznam o spolenosti smazat a tato bude mít definované adresy (minimáln jednu), databáze provedení operace mazání zablokuje. Jiným pípadem by bylo nastavení vazby na kaskádní, což by zapíinilo s výmazem spolenosti také výmaz všech jejích potomk tedy vazeb na definované adresy. V jistém slova smyslu je restrikce jistým prvkem ochrany. Existuje mnoho dalších možností, které bychom mohli využít. Zmíním se o tzv. textových objektech. K modelu je možné pidružit SQL skripty pedevším k tvorb generátor pro primární klíe databázových tabulek, ale i dalších. Napíklad pokud chceme pímo s generováním databáze založit njaké implicitní výbrové záznamy tabulky. Obr. 3-5 Textové objekty modelu databáze Výsledkem práce s CASE nástrojem (nyní bez ohledu na popisované CASE Studio) je pehledná struktura modelu, který tvoí základnu naší databáze. To samo o sob by pro analytika a programátora nebylo až takovým pínosem, protože stejné diagramy je možné pomrn rychle nartnout run. Co je ovšem výhodou je skutenost, že zpracováním takového modelu (v naší ukázce se jedná o submodel) máme k dispozici data pro automatické generování SQL skriptu, který vytvoí požadovanou strukturu databáze. Navíc mžeme generovat databázový report jako dokumentaci k vytvoené struktue a pedložit ji k posouzení. Ta mže zárove sloužit jako píruka pro ešitele aplikaní úrovn. 8

9 Obr. 3-6 Píklad vizuálního provedení navržené datové struktury (výrobní postup) Je sice pravda, že sestavení datového modelu je asov nároné a pokud chceme využít maximum možností CASE nástroje také pracné, pínos pro naši práci to bezesporu má: Minimáln v tom, že generovaný skript bude bez chyb a peklep, které by mohly zapíinit jeho nezdárný probh v generování vlastní databáze. 3.2 Programujeme v Delphi Co se vývoje aplikaní úrovn týe, je teba si pedem ujasnit nkolik zásad, které budeme ve fázi programování dodržovat. Nkteré hlavní z nich budou podrobn popsány v programové dokumentaci, která souasn obsáhne popis veškerých stžejních metod a objekt. Zamme se nyní spíše na obecné pojetí realizace klient-server aplikace pomocí Delphi. Základem tvorby databází pro INTERBASE v Delphi je knihovna komponent pro práci s daty. Jedná se o vizuální i nevizuální komponenty, které umožují pímé spojení s databází INTERBASE. (viz. Obr. 2-1 Paleta komponent pro práci s INTERBASE) Tyto komponenty vkládáme vtšinou do tzv. datového modulu. Vlastnosti komponenty se tak stávají zddnými metodami modulu a je možné je použít kdekoli v programu deklarováním názvu modulu v klauzuli USES. Pro vlastní databázi slouží komponenta IBDatabase. Její vlastnosti, pedevším pak cílový databázový soubor, který mže být koncipován jednak jako lokální databáze, jednak jako vzdálená databáze s pipojením pomocí TCP-IP protokolu, lze mnit za bhu programu. Jaké to mže mít výhody? Lze využít inicializaního souboru (FileName.ini) k definici umístní 9

10 databáze a tuto zmnu tedy provádt bez nutnosti zásahu do zdrojového kódu programu. (To je jist žádoucí 3 ) Komponenta IBDatabase Série komponent pro realizaci spojení databázové tabulky s klientskou aplikací: IBQuery, IBUpDateSQL, DataSource Obr. 3-7 Datový modul s komponentami datových tabulek S komponentou IBDatabase se váže také další komponenta: IBTransaction. Pro správné fungování pipojení databáze je teba, aby datový modul obsahoval alespo jednu komponentu IBTransaction a tato byla s pedchozí propojena pomocí vlastností. Krom jiného je možné zadat pístupové heslo a uživatelské jméno pro prvotní pipojení databáze než dojde k pihlášení uživatele. Je možné také nechat ízení pihlášení na databázi samotné (komponenta toto umožuje vlastností LoginPrompt) ale ukazuje se, že je lepší ídit pístup do databáze aplikaní úrovní, nebo tak máme znalost pihlášeného uživatele. Zpsob realizace tohoto problému je popsán v programové dokumentaci. Bez komponent IBDatabase a IBTransaction a jejich vzájemného propojení nelze navázat vazbu mezi databází a aplikaním úrovní. Následující struktury, o kterých se zmíním, jsou již reprezentanty jednotlivých tabulek, které jsme definovali v modelu. Dá se tvrdit, že základem vývoje databázové aplikace v Delphi je komponenta IBQuery nebo IBTable. Ve vtšin pípad používám IBQuery, protože umožuje využití jazyka SQL v operaci vyhledávání metodou selekce dat a stejn tak dobe i azení. Abychom byli schopni svázat existující tabulku v databázi s aplikaní úrovní, musíme použít sérii komponent, jak ukazuje: Obr. 3-7 Datový modul s komponentami datových tabulek. Jedná se o IBQuery, IBUpDateSQL a DataSource. Každá z uvedených komponent plní uritou funkci a jsou vzájemn provázané. Tak napíklad IBQuery musí mít definovanou 3 Poznámka autora. 10

11 vlastnost Database, kde vtšinou vybereme výše popsanou komponentu z výtu možností. To také znamená, že v klientské aplikaci mžete ídit pístup i do více databází. Otázkou zstává, jak moc je toto žádoucí, pinejmenším v pípad nkterých systémových funkcí, napíklad pímý pístup do jiné databáze za úelem synchronizace nkterých kmenových dat. To se vtšinou moc nepoužívá, protože si tvrci databází své zdroje samozejm chrání a synchronizaci tak realizují radji dávkovou výmnou dat. Obr. 3-8 Vlastnosti IBQuery spojení s komponentou IBDatabase Krom jiného je dležitou vlastností komponenty IBQuery také vlastnost urující zpsob generování identifikaního ísla. Je možné ve vlastnosti GeneratorField vybrat deklarovaného generátoru v databázi a zvolit, jak se má hodnota zvyšovat a kdy generovat. (Napíklad pi založení nového záznamu nebo až ped uložením nového záznamu.) Popis výtu všech vlastností by vydal na celou uebnici Delphi. V této stati si vybíráme jen nkteré z nich. Provázanost mezi IBQuery a IBUpDateSQL je realizována opt pes vlastnost IBQuery: UpdateObject, kde je možné vybrat z komponent IBUpDateSQL. Tyto ti uvedené vlastnosti jednoznan udávají: K jaké databázi se tabulka pipojuje Jaký generátor pebírá funkci generování identifikaního ísla tzv. ID Jaký objekt realizuje základní operace INSERT, DELETE, UPDATE a REFRESH v podob píkazu SELECT Aby komponenta byla skuten funkní, musíme zadat také vlastnost SQL, kde vypisujeme SQL píkaz pro zobrazení dat v okamžiku její aktivace. Vtšinou obsahuje prostý píkaz: SELECT * FROM TableName ORDER BY ColumnName. Je možné také realizovat vazby. V takovém pípad musíme ješt do vlastnosti IBQuery: DataSource vybrat zdroj rodiovské tabulky. Jedná se o vytvoení tzv. struktury Master 11

12 Detail Connection (MDC). V podstat se jedná o to, že dceiná tabulka bude zobrazovat jen záznamy podle aktuální pozice kurzoru v tabulce rodie. To lze interpretovat také takto: Jestliže bude v databázi aktivní záznam urité spolenosti A, bude tabulka adres zobrazovat jen adresy píslušné ke spolenosti A, pestože jinak obsahuje de facto všechny adresy z definovaných spoleností. Je zejmé, že takové zobrazení je též jedním ze základ strukturování dat v aplikaní úrovni. Zmínili jsme ješt tetí komponentu: DataSource. Jedná se o objekt, který realizuje vizualizaci dat databázové tabulky pomocí píslušných komponent palety DataControls. Tato paleta je mocným nástrojem pro zobrazování dat. Umožuje programátorovi data strukturovat do formuláe, tabulky, ale také do grafu. Obr. 3-9 Paleta komponent datacontrols Tím se již dostáváme do vlastního zpracování celého vzhledu programu. Každá komponenta z uvedené palety (jedná se nyní o tzv. VCL vizuální komponenty) obsahuje vlastnosti, kterými je pipojena k urité jednak tabulce databáze, ale také k píslušnému sloupci. V podstat jsou tyto dv vlastnosti (DataField a DataSource) základním prvkem nastavení každé z uvedených komponent, které se od sebe dále liší složitostí další instalace ve struktue pipravované aplikace. Podrobnjší popis takovýchto úkon je opt obsahem programové dokumentace. Obr Nastavení vlastností vizuální komponenty DBEdit 12