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

ZÁPADO ESKÁ UNIVERZITA V PLZNI

Úvod do projektu diserta ní práce

Akademický rok 2008/2009

Ing. Jaroslav HALVA

ChronData ´08 Úvod do projektu diserta ní práce

1 ChronData - databázové chronometráže

Západo eská univerzita v Plzni Fakulta strojní

ešení provedení a vyhodnocení

ešení mé diplomové práce v roce 2006 ukázalo, že pot eba softwarové podpory v oblasti normování spot eby asu je stále aktuálním tématem. Ukázalo se, že p edevší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áro nosti manuálních pracovních inností v polygrafickém závod . Následn došlo k p epracování a drobným zm nám ve struktu e dat tak, aby bylo možné databázovou aplikaci využít také v oblasti strojírenství. S odstupem asu je možné odhalit postupn n které nedostatky systému zvlášt pak p i uvedení do praxe, takže vzniká pot eba 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áro nosti vybrané operace. Je nasnad implementovat n které zásady REFA a zam it 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 n které moduly pro normová, ale z v tší á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 spot eby. Jak ovšem získat hodnoty platných normativ ? V sou asné dob se jedná o problém, jehož ešení „zaspávalo“ celkem n kolik desetiletí, takže normativy stanovené v sedmdesátých letech (n kde dodnes používané) již nevyhovují moderním trend m technologie obráb ní a pr myslové innosti v bec. Vyvstává myšlenka koncipovat rela ní databázový systém s možností efektivního sb ru dat m ením a centrálním zp sobem vyhodnocení. Zvýšit tak produktivitu získávání dat nap íklad chronometráží, jejíž výsledky m že management spole nosti sledovat, zatímco normova i, pracovníci v terénu, sestavují pom rn rychle (díky databázovému p ístupu) široký okruh dat relevantních pro jejich statistické posouzení. Díl í ešení existují, i když zam ená v tšinou na jinou oblast získávání asových údaj a pokud ano, vždy se jedná pouze o jednu metodu zpracování. Diserta ní práce si klade za cíl nabídnout takových metod hned n kolik základních. O možné ešení projevuje zájem spole nost TPVGroup auto i databázového systému TPV2000 se zám rem 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í diserta ní práce zcela jiný rozm r a hlavn další fázi vývoje. P edpokladem je, aby byl systém schopen samostatného fungování. Tato úloha je prioritní. Plánované za len ní ásti systému jako modulu TPV2000 je plánované jako druhá fáze projektu.

2 Co by m l systém ChronData spl ovat? Jak již bylo nastín no, systém ChronData by m l vyplnit chyb jící lánek v systémech technologické p ípravy výroby p edevším v ásti stanovování asové náro nosti technologických operací metodami odm ování. V tšina systém podporujících

2



technologickou p ípravu výroby podporuje p evážn metody p edem stanovených as jako je MTM, protože tyto metody vykazují nejv tší p esnost a jejich použití zažívá jistý boom… Metody p edem stanovených as nelze bez odborného zaškolení zvládnout ani s podp rným programem. Jejich použití je tedy závislé na schopnosti uživatele a p edevším na zvládnutí techniky len ní operací nejen na jednotlivé úkony, ale p edevší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 pot ebnými znalostmi tak, že uživatel m že podle pokyn provád t m ení a získávat požadované hodnoty bez hlubší znalosti zásad provád ní chronometráže. Je tak možné rozší it pole možných „m itel “ i na osoby, které jsou pouze seznámeni s programem. Díky databázovému zpracování by bylo možné p enést odpov dnost za p ípravu chronometráže na osobu znalou, vlastní m ení pak m že provést osoba pouze zaškolená. (Týká se jen obsluhy programu.) Tuto skute nost ukazuje praxe. Jaká by tedy nová verze m la být? Pokud opomineme již zmi ované funkce, které dopl ují systém o další metody asových studií, chceme též p izp sobit a koncipovat systém ve standardní rela ní databázi tak, aby jej bylo možné modulárn za lenit do stávajícího TPV2000. Systém by m l p esto z stat sob sta ný s podporou technologické p ípravy výroby pro stanovení asových náro ností strojních operací, dostate n 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ý p edpis, nikoli norma, která by byla zásadní. Jako ešitel jsem omezen prost edky ke zvládnutí jednak návrhu databáze, ale p edevším ve zvládnutí koncipování aplika ní úrovn . Volím systém Delphi 7.0 spole n s databázovým serverem INTERBASE 6.0 (volná licence). Programovací jazyk Delphi disponuje praxí prov eným nástrojem k tvorb databázových aplikací pomocí VCL (Visual Component Library) komponent, které byly spole ností 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 m la být dvouvrstvá struktura Klient/Server, kde na stran klienta stojí aplika ní úrove vytvo ená 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 um jí kombinovat aplikaci i s dalšími druhy databází v podob p ipojovacích et zc . Pak ovšem není možné využít širokou paletu p ipravený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 ozna ované jako DAC (Direct Access Components). Tyto komponenty je ovšem nutné dokupovat dodate n .

Obr. 2-1 Paleta komponent pro práci s INTERBASE

Otázkou z stává, jakým zp sobem využít i dalších možných komunika ních nástroj , nap íklad pro n které manažerské a vyhodnocovací funkce by bylo možné vytvo it webovou aplikaci pro internetový prohlíže a zp ístupnit tak n která data (zejména výsledky m ení a jejich statistické vyhodnocení) bez nutnosti instalace klientské aplikace. Tato možnost by byla p edm tem dalšího vývoje jako nadstavba celého systému. 3



Jaké by bylo využití? V sou asné dob prosperují spole nosti zabývající se poradenstvím, v oblasti racionalizace práce. Nedílnou inností, které tyto spole nosti vykonávají, je práv stanovování asových náro ností, 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 spole nosti, p itom by se asové údaje sbíraly v terénu. Odpadá tím p epis hodnot a asová prodleva vlivem dodate né p ípravy dat pro jejich statistické posouzení.

3 Nástroje pro ešení Následující kapitola a p edevším její stat popisují nástroje pro ešení navrhovaného projektu. Bude zapot ebí p ipravit analytickou ást a navrhnout vhodný datový model. P itom m žeme použít n které stat z již stávající verze systému ChronData a upravit je vhodn tak, aby vyhov ly inovované verzi. Chceme sou asn , aby systém spl oval n které 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 n jakým zp sobem pomoci? Opomineme-li databázový skript pro vytvo ení SQL databáze a zam íme-li se pouze na myšlenku modelu, m žeme vyjít z n kterých již ešených projekt informa ních systém , které v tšinou dávají k dispozici popis jednotlivých entit v rámci uživatelské p íru ky. Tak m žeme navrhnout entity pro stroje, za ízení, nástroje, abychom do nich za lenili všechny pot ebné atributy. Zpracování takového modelu pak provedeme pomocí n jakého CASE nástroje. Dále se zam íme na vlastní zpracování klientské aplikace. I tato ást vyžaduje nejen ur itou p ípravu v návrhu ešení (jestli volit MDI aplikaci nebo modální otevíraná okna pop ípad jinak…) ale p edevším volbu vhodného jazyka. (s ohledem na schopnosti ešitele a na zvolený databázový server) Jak již bylo v p edchá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 vytvo ení databáze v etn 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 stru ným návodem, jak s takovým systémem pracovat. V první ásti užívání programu s cílem vytvo ení 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 p esto, že je SQL (Structured Query Language) v jisté form standardizovaný, n které databáze se mohou mírn odlišovat v syntaxi tohoto jazyka. I zde titíž dochází k trvalému vývoji a p edevším také verzování, takže m žeme najít odlišnosti v jazyce SQL1 a SQL3.

4



Obr. 3-1 Výb r cílové databáze

V analytické ásti realizace projektu je d ležitá p edevším dekompozice a vytvo ení seznamu atribut , které jsou následn p evád ny 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 pr b hu projektu, nezabývám se zatím vlastním provedením této dekompozice…P edstavme 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 umis ují na pracovní plochu, kde se zárove zpracovávají n které 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 struktu e SQL databáze. Navíc i každý sloupec (atribut entity) obsahuje další vlastnosti, které po zadání do systému ovliv ují cílovou databázi v její definici.

5



Obr. 3-3 Definované atributy tabulky sou ástí

P i ešení je dodrženo n kolik 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é ur it, zda se jedná o primární klí , zda je pole povinné nebo p ípadn unikátní (unique). Sou asn 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 angli tin p ekladem. Z d lež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 áte ní hodnotu p i založení záznamu a další možnosti.

1

Tyto zásady jsou pom ckou autora/ ešitele tak, aby bylo možné se v definované struktu e lépe orientovat. Nap íklad všechny fyzické názvy jsou v angli tin 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

Op t se jedná o zab hlou konvenci autora/ ešitele.

6



Obr. 3-4 Vlastnosti atributu (sloupce)

P edpoklá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 p ehlednou strukturu datového modelu a p edevší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 rozd lují jednotlivé moduly, aby struktura z stala p ehledná. Je ú elné, aby zakládané položky byly sou asn 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á p i ešení aplika ní úrovn . Stejným zp sobem 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 d ležité volit její kardinalitu a p edevším chování vztahu rodi – potomek. Co to znamená? Je možné nastavit tzv. restrikci v p ípad , že existuje výše zmín ný vztah. Ukažme si tento problém na klasickém p íklad : M jme definovanou tabulku spole ností a adres k dané spole nosti ve vzájemném propojení relací s kardinalitou 1:N. To znamená, že každé spole nosti m žeme definovat N adres. Založení adresy spo ívá v p i azení cizího klí e spole nosti tak, aby bylo z ejmé, ke které spole nosti se adresa váže. Pokud bude tato vazba 7



restrik ní, v p ípad , že budeme chtít záznam o spole nosti 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 spole nosti 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é p idružit SQL skripty p edevší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 n jaké implicitní výb rové 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 p ehledná 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é pom rn rychle na rtnout ru n . Co je ovšem výhodou je skute nost, ž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 vytvo ené struktu e a p edložit ji k posouzení. Ta m že zárove sloužit jako p íru ka pro ešitele aplika ní úrovn .

8



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áro né 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 p eklep , které by mohly zap í init jeho nezdárný prob h v generování vlastní databáze.

3.2 Programujeme v Delphi Co se vývoje aplika ní úrovn tý e, je t eba si p edem ujasnit n kolik zásad, které budeme ve fázi programování dodržovat. N které hlavní z nich budou podrobn popsány v programové dokumentaci, která sou asn obsáhne popis veškerých st žejních metod a objekt . Zam me 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 v tšinou do tzv. datového modulu. Vlastnosti komponenty se tak stávají zd d ný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, p edevší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 p ipojením pomocí TCP-IP protokolu, lze m nit za b hu programu. Jaké to m že mít výhody? Lze využít inicializa ního souboru (FileName.ini) k definici umíst ní

9



databáze a tuto zm nu tedy provád t 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í p ipojení databáze je t eba, aby datový modul obsahoval alespo jednu komponentu IBTransaction a tato byla s p edchozí propojena pomocí vlastností. Krom jiného je možné zadat p ístupové heslo a uživatelské jméno pro prvotní p ipojení databáze než dojde k p ihlášení uživatele. Je možné také nechat ízení p ihlášení na databázi samotné (komponenta toto umož uje vlastností LoginPrompt) ale ukazuje se, že je lepší ídit p ístup do databáze aplika ní úrovní, nebo tak máme znalost p ihlášeného uživatele. Zp sob 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 aplika ní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 v tš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 dob e i azení. Abychom byli schopni svázat existující tabulku v databázi s aplika ní ú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í ur itou funkci a jsou vzájemn provázané. Tak nap íklad IBQuery musí mít definovanou

3

Poznámka autora.

10



vlastnost Database, kde v tš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 z stává, jak moc je toto žádoucí, p inejmenším v p ípad n kterých systémových funkcí, nap íklad p ímý p ístup do jiné databáze za ú elem synchronizace n kterých kmenových dat. To se v tšinou moc nepoužívá, protože si tv rci databází své zdroje samoz ejm chrání a synchronizaci tak realizují rad ji dávkovou vým nou dat.

Obr. 3-8 Vlastnosti IBQuery – spojení s komponentou IBDatabase

Krom jiného je d ležitou vlastností komponenty IBQuery také vlastnost ur ující zp sob generování identifika ní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 p i založení nového záznamu nebo až p ed uložením nového záznamu.) Popis vý tu všech vlastností by vydal na celou u ebnici Delphi. V této stati si vybíráme jen n které z nich. Provázanost mezi IBQuery a IBUpDateSQL je realizována op t p es vlastnost IBQuery: UpdateObject, kde je možné vybrat z komponent IBUpDateSQL. Tyto t i uvedené vlastnosti jednozna n udávají: • K jaké databázi se tabulka p ipojuje • Jaký generátor p ebírá funkci generování identifika ního ísla tzv. ID • Jaký objekt realizuje základní operace INSERT, DELETE, UPDATE a REFRESH v podob p íkazu SELECT Aby komponenta byla skute n funk ní, musíme zadat také vlastnost SQL, kde vypisujeme SQL p íkaz pro zobrazení dat v okamžiku její aktivace. V tš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 rodi ovské tabulky. Jedná se o vytvo ení tzv. struktury Master 11



Detail Connection (MDC). V podstat se jedná o to, že dce iná tabulka bude zobrazovat jen záznamy podle aktuální pozice kurzoru v tabulce rodi e. To lze interpretovat také takto: Jestliže bude v databázi aktivní záznam ur ité spole nosti A, bude tabulka adres zobrazovat jen adresy p íslušné ke spole nosti A, p estože jinak obsahuje de facto všechny adresy z definovaných spole ností. Je z ejmé, že takové zobrazení je též jedním ze základ strukturování dat v aplika ní úrovni. Zmínili jsme ješt t etí 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 p ipojena k ur ité 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 struktu e p ipravované aplikace. Podrobn jší popis takovýchto úkon je op t obsahem programové dokumentace.

Obr. 3-10 Nastavení vlastností vizuální komponenty DBEdit

12

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

Recommend Documents