Akcentace a inovace konceptuálního modelu při vývoji databázových aplikací

Akcentace a inovace konceptuálního modelu při vývoji databázových aplikací JanTyrychtr 1, Julie Poláčková 2, Ivana Švarcová 3 Česká zemědělská univerzita, Provozně ekonomická fakulta Katedra informačních technologií 1, 3 Katedra statistiky 2 Abstrakt: V článku je upraven Entity-Relationship model dat tak, aby vyhovoval procesu databázového návrhu s akcentací na kvalitu softwarových aplikací. Schéma diagramů Entity-Relationship modelu (navržený Chenem v roce 1976) je inovováno o množinu upozornění. Možné způsoby použití inovovaného modelu jsou prezentovány. Článek empiricky ověřuje závislost počtu prvků relace (počtu řádků v tabulkách) v systému Wordpress na rychlosti databázového systému MySQL jako hlavního faktoru decelerace aplikací. Článek akcentuje potřebu predikovat budoucí vytížení databáze na příkladu systému Wordpress. Klíčová slova: databáze, databázový systém, konceptuální návrh, ER diagram, Entity-Relationship. Abstract: The paper is modified Entity-Relationship data model so as to meet the database design process with accentuation on the quality of software applications. Schema diagrams Entity-Relationship model (proposed by Chen in 1976) is innovated on the set alerts. Possible uses an innovative model are presented. The paper empirically tested the dependence of elements of the relation (the number of rows in the tables) in the WordPress on the speed of the database system MySQL as the main factor deceleration applications. The paper emphasizes the need to predict the future workload for the database example of Wordpress Keywords: database, database system, conceptual design, ER diagram, Entity- Relationship. 1. Úvod V současnosti je kladen důraz na kvalitu softwaru jako faktoru ekonomického úspěchu organizace. Databáze a databázové systémy jsou používany pro organizaci a manipulaci s daty ve většině organizací. Také většina aplikačního software a webových aplikací je principiálně zaměřena na použití s databázovým systémem. Důvodem řešené problematiky je fakt, že zpracovatel (firma, programátor - analytik atp.) aplikace je postaven před řadu otázek, nejen jak postupovat při vytváření dané aplikace, ale i jaký zvolit programovací jazyk a databázový systém. Některé otázky jsou zodpovězeny samotnými požadavky zadavatele (firma, vedení organizace atp.). Ne vždy ale je problém výběru nejrychlejšího databázového systému tím rozhodujícím faktorem pro běh aplikace. Zadavatel a zpracovatel aplikace (využívající databázový systém) si většinou neuvědomují, že složitost zpracování databázových dotazů není konstantní O(1), tedy nezávislá na rozměru vstupu. Neznalost, nebo i laxnost při vývoji a návrhu celého databázového schématu se bohužel projeví až po nějaké době běhu aplikace, kdy již většinou změna návrhu struktury databázového schématu bývá velmi obtížná. Tato ztráta výkonnosti vede k restrukturalizaci celé aplikace nebo databázového schématu. Důsledkem je pak ekonomická ztráta pro organizaci. SYSTÉMOVÁ INTEGRACE 4/2010 51

JanTyrychtr, Julie Poláčková, Ivana Švarcová Příspěvek ve 2. části využívá metriky pro analýzu kvality relačního databázového schématu v návaznosti na ISO / IEC 9126 (ISO, 1994). Je důležité, aby softwarové produkty, a samozřejmě i databáze, byly hodnoceny pro všechny příslušné charakteristiky pomocí validovaných nebo široce přijímaný metrik [11]. Posouzen je statistický vliv vybraných faktorů (počet řádků v tabulce, doba odezvy zpracování SQL dotazů) na dobu odezvy aplikace WordPress. Statistický vliv je testován prostřednictvím SQL DBMS, databázového systému MySQL. SQL DBMS je systém řízení báze dat založený na jazyku SQL (prvně použitý v Systému R [3]). Důležité při návrhu aplikace je zaměření se na jednotlivé kroky procesu databázového návrhu (obrázek č. 1). Obecným úkolem návrhu databáze je zmapovat daný reálný svět aplikace do formálního datového modelu daného systému pro správu databází. [4] Ve 3. části je akcentován návrh konceptuálního datového modelu. Ve druhém kroku (obrázek č. 1) je vytvořeno konceptuální schéma, které popisuje strukturu databáze nezávislé na databázovém systému. Konceptuální model je používán k popisu konceptuálního schématu. [4] Obrázek č. 1: Proces databázového návrhu [4]. V konceptuální datovém modelu musí být zřejmé jednotlivé požadavky aplikace. Na procesu tvorby databázového návrhu se může a většinou i podílí více lidských 52 SYSTÉMOVÁ INTEGRACE 4/2010

Akcentace a inovace konceptuálního modelu při vývoji databázových aplikací zdrojů. Každá fáze tohoto procesu může být zpracována jiným designérem. To znamená, že při vytváření databáze je potřeba vytvoření vazby dvou nebo více účastníků procesu. S růstem počtu účastníků klesá možnost plně využít komunikační vazby. Komunikační šum roste s narůstajícím počtem prvků komunikačního řetězce geometrickou řadou. Proto je nutné, aby požadavky a specifika aplikace byly přenášeny jednotlivými kroky návrhu, a to stručnou formou, tak aby nedocházelo ke ztrátě informace a ke zvýšení pravděpodobnosti decelerace aplikace v průběhu jejího života. 2. Empirické ověření Tato část je věnována empirickému ověření závislosti počtu prvků relace (počtu řádků v tabulkách) na rychlosti databázového systému jako hlavního faktoru decelerace aplikací. 2.1 Hypotéza Hlavní hypotézou je, že rychlost webové aplikace WordPress je pozitivně korelována s počtem záznamů v databázi databázového systému MySQL. Účinek tohoto vztahu byl zkoumán pomocí korelační analýzy. Test nulové hypotézy říká, že neexistuje žádný vztah mezi prediktorem (počet řádků) a vysvětlovanou proměnnou (doba odezvy aplikace). Nulová hypotéza pro test korelačního koeficientu je H0: ρ = 0, kde ρ je odhad vzorku korelačního koeficientu. H0: ρ 0. 2.2 Experimentální materiály Vybraná množina dat obsahuje informace o počtu řádků a rychlosti aplikace. Datový soubor se skládá z 60 záznamů, které byly naměřeny pomocí náhodně generovaných záznamů (od 0 do 50 tisíc) a uloženy v databázi. Pro testovaní byla použita open source webová aplikace Wordpress. Jedná se o volně šiřitelný publikační systém (v roce 2009 používalo Wordpress přibližně 7000 webových stránek v češtině). Wordpress používá pro ukládání dat databázový systém MySQL. Databázový systém MySQL je založen na SQL DBMS. [12] Výchozí podmínky testování: Aplikace Wordpress 2.9.1 s výchozím nastavením a pluginem WPDB Profiling (pro měření doby odezvy SQL dotazů). Datové úložiště MyISAM v databázovém systému MySQL. Úprava aplikace o funkce (microtime) pro měření celkové rychlosti aplikace. Měřena byla rychlost úvodní stránky webové aplikace. Úvodní stránka obsahovala výpis článků. K tvorbě programových výstupů byl využit statistický software SAS 9.2, převážně možnosti modulu SAS BASE. SYSTÉMOVÁ INTEGRACE 4/2010 53

JanTyrychtr, Julie Poláčková, Ivana Švarcová 2.3 Experimentální výsledky Před realizací regresní a korelační analýzy byla provedena explorační analýza zkoumaného datového souboru. Popisné statistiky pro vysvětlující proměnnou, byly získány z procedury UNIVARIATE. Jednorozměrná analýza potvrdila, že se rozdělení analyzovaných proměnných na hladině významnosti α = 0,05 statisticky významně liší od rozdělení normálního. Korelační analýza byla proto provedena pomocí Spearmanova neparametrického koeficientu korelace. 2.3.1 Posouzení těsnosti závislosti Korelační analýza je použita pro zkoumání a popis vztahu dvou spojitých proměnných. Pro kvantifikaci míry asociace mezi proměnnými prediktoru a odezvy je použito Spearmanova korelačního koeficientu. Spearmanův korelační koeficient získáme pomocí procedury CORR: proc corr data=sasuser.aplikace spearman nosimple; Var pocet_zaznamu; With rychlost_aplikace; Run; Procedura č.1: CORR Vypočítaná p-hodnota, kdy p < 0,05, u Spearmanova koeficientu znamená, že na hladině významnosti α = 0,05 zamítáme nulovou hypotézu o nezávislosti proměnných a přijímáme hypotézu alternativní, která potvrzuje statisticky významnou závislost. Speaman Correlation Coefficients, N = 60 Prob > r under H0: Rho=0 dezva odezva pocet_radku 0.99786 <.0001 Tabulka č. 1: Výstup Corr precedury Hodnota Spearmanova koeficientu rs = 0,998 udává, že mezi proměnnými existuje silná pozitivní korelace. Kladná hodnota tohoto koeficientu naznačuje, že se jedná o pozitivní asociaci, tedy že s růstem počtu záznamů roste také čas rychlosti aplikace. Koeficient determinace (R2) udává, že změnu vysvětlované proměnné (doba odezvy aplikace) lze pomocí vysvětlující proměnné (počet záznamů) vysvětlit z 99,57 %. 2.3.2 Interpretace experimentu Výsledky potvrdily hypotézu - doba odezvy aplikace Wordpress je pozitivně asociována s počtem řádků v databázi databázového systému MySQL. Jedná se o potvrzení toho, že při zvyšování počtu záznamů v databázi databázového systému MySQL, dochází k deceleraci systému Wordpress. 54 SYSTÉMOVÁ INTEGRACE 4/2010

Akcentace a inovace konceptuálního modelu při vývoji databázových aplikací 2.4 Shrnutí experimentu Práce systému Wordpress s databázovým systémem MySQL je velmi neefektivní. Důvodem je, že SQL dotazy provádí plné prohledávání tabulek. Většině času strávené prohledáváním tabulek se lze vyhnout pomocí indexů na pole, která jsou součástí klauzule "WHERE" SQL dotazu. Důvodem neoptimalizovaných SQL dotazů je především to, že všechny části systému Wordpress jsou napsané lidmi (v rámci komunity open source systému Wordpress), kteří neví, jak správně optimalizovat a navrhnout databázové schéma a optimalizovat jej pro různé typy SQL dotazů. Proto je nutné při vývoji databází predikovat budoucí vytížení databáze (kolik bude v navrhované databázi záznamů po dobu její životnosti) a predikci zaznamenat do konceptuálního schématu. Zaznamenání metainformací o entitách umožňuje v dalších fázích optimalizovat návrh databáze. 3. Konceptuální návrh Vytvoření datového modelu je zapotřebí k tvorbě každého databázového systému. Datový model je množina konceptů, které lze použít k popisu struktury a operací na databázi. [10] Představuje výstup datového modelování (nebo konceptuálního návrhu), činnost, která má za cíl vytvořit konceptuální schéma v podobě diagramu a usnadnit komunikaci mezi vývojáři a uživateli. [10]. U většiny databázových řešení je datový model nutné postupně formulovat (obrázek č. 1), to znamená, nejdříve vymezit jeho strukturu obecně. K tomu je nutné využít konceptuální schéma, které využívá abstrakce objektů reálného světa. V současnosti je Entity-Relationship (ER) model nejdůležitějším paradigmatem pro konceptuální návrh databáze. [4] ER model pro konceptuální modelování dat byl představen Chenem [9] v roce 1976. Schéma diagramů bylo formalizováno Bachmanem v roce 1969 [2]. ER model může být použit jako základ pro sjednocení odlišných pohledů na data: síťový model, relační model, a model množin entit. [9] Pro grafickou reprezentaci ER modelu je používán ER diagram. Technika tvorby ER diagramů představuje grafický způsob zobrazování typů entit, typů vztahů a atributů. [6] Formální definice konceptu entit a množin je: SYSTÉMOVÁ INTEGRACE 4/2010 55

JanTyrychtr, Julie Poláčková, Ivana Švarcová Obrázek č. 3 zobrazuje ER diagram dvou entit. Typy entit EMP a PROJ jsou reprezentovány obdélníkem, typy vztahů jako WORK-FOR jsou reprezentovány kosočtvercem. Množina hodnot (doména) jako EMP#, NAME, a PHONE jsou reprezentovány kružnicí, zatímco atributy jsou mapovány z entit a vztahů na množinu hodnot. [6] Kardinalita vztahu mezi relacemi je v diagramu znázorněna u spojovací čáry, například "1" a "N". Obrázek č. 3: ER diagram [6]. 3.1.1 Inovace Entity-Relationship diagramu Vytvořením konceptuálního schématu pomocí ER diagramu a následném převodu na logické schéma, může být realizováno konkrétní fyzické schéma databáze. Tento postup však nepočítá s komunikačním šumem, tak jak bylo uvedeno v úvodu tzn. kdy mezi jednotlivými pracovníky (pracujícími na návrhu databáze a jeho modelu) dochází ke ztrátě popřípadě zkreslení informace. Dalším faktorem ovlivňujícím výslednou aplikaci je neakcentování důležitosti vlivu počtu záznamů uložených v databázi. Toto má za následek, že aplikace (využívající databázový systém), která je vytvořená podle požadavků zadavatele a splňuje stanovenou funkčnost, nemusí nutně splňovat účinnost takové aplikace. Především tehdy je-li měřena atributem dobou odezvy. Mezi další faktory ovlivňující účinnost relačních databází patří počet cizích klíčů. Počet cizích klíčů ve schématu relační databáze je solidním ukazatelem složitosti, délka referenčního stromu není relevantní sama o sobě, ale může modulovat účinek počtu cizích klíčů. [11] Všechny tyto faktory ovlivňují účinnost relační databáze a snižují účinnost celé aplikace. Již v konceptuální fázi je nutné tyto faktory do ER modelu zaznamenat. Obrázek č. 1 ilustruje grafickou reprezentaci ER modelu založenou na frameworku ER modelu [7]. ER diagram je založen na GERM. 56 SYSTÉMOVÁ INTEGRACE 4/2010

Akcentace a inovace konceptuálního modelu při vývoji databázových aplikací Obrázek č. 4: Atributy entit a vztahů [7]. Na základě empiricky ověřené závislosti počtu řádků v relačních tabulkách na době odezvy RDBMS (2. část) a výsledkům experimentu [11] je upraven ER diagram, tak aby vyhovoval procesu databázového návrhu s akcentací na kvalitu softwarových aplikací. Do ER diagramu (inovace ER diagramu je prezentována na příkladu z obrázku č. 4) je přidána množina entit, která se nazývá množinou upozornění (obrázek č. 5). Množina upozornění má dva atributy PROJ a PART. Tyto dva atributy představují v ER diagramu (obrázek č. 4) množinu entit PROJ a PART. V množině upozornění slouží tyto dva atributy pro zaznamenání vlastností typických pravě pro množinu entit PROJ a PART. Text připsaný u šipky, představuje hodnotu v příslušném atributu (tento způsob byl použit Chenem [8]). Obrázek č. 5: Množina upozornění Množina upozornění ESA (Entity Set - Alert) slouží pro zaznamenání předpokládaných charakteristik reálných objektů (entit), přístupem prostupujícím od konceptuálního datového modelu ke schématu databáze. ESA lze transformovat na logický datový model (obrázek č. 6). V ESA je přidán atribut NUMBER A. Tento atribut je nepovinný, slouží jako primární klíč, je však vhodné z důvodu budoucí indexace tabulky atribut do modelu zaznamenat. SYSTÉMOVÁ INTEGRACE 4/2010 57

JanTyrychtr, Julie Poláčková, Ivana Švarcová Obrázek č. 6: Množina upozornění - převod na logický datový model Tabulka č. 2 představuje výsledný převod ESA z logického datového modelu do relačního datového modelu. Sloupce PROJ a PART představují množiny entit z ER diagramu (obrázek č. 4). Sloupec NUMBER A je primárním klíčem tabulky. Při použití projekce v manipulačním jazyku (DML), je možné pro každý atribut zobrazit data, která byla zaznamenána již v konceptuálním návrhu datového modelu. V tomto případě nám například druhý sloupec poskytuje informace o entitě (v konceptuálním modelu), tabulce (v relačním modelu) PROJ. S tabulkou PROJ je předpokládaná větší frekvence práce (čtení, zápis nebo změna záznamů) a predikováno je, že do tabulky bude každý rok přidáno 2000 záznamů. NUMBER A (Primární PROJ PART klíč) 1 'Častý přístup k entitám.' 'Predikce: 10 000 entit za rok.' 2 'Predikce: 2000 entit za rok.' Tabulka č. 2: Množina upozornění po převodu do tabulky Grafická podoba ESA tak jak byla zobrazena na obrázku č. 5 se stává v rozsáhlých konceptuálních modelech nepřehlednou. Proto je ESA možné transformovat na zjednodušený způsob znázornění (obrázek č. 7). Množina upozornění je graficky vyjádřena trojúhelníkem. Hodnoty atributů jsou napsány po stranách trojúhelníku. Názvy atributů jsou vyjádřeny v závorkách, které jsou připsány ke každé hodnotě. Obrázek č. 7: Množina upozornění - zjednodušený způsob znázornění Matematický aparát konceptu entit a vztahů zůstává zachován. Konceptuální datový model vyjádřený pomocí ER diagramu s množinou upozornění se nazývá Entity-Relationship Alert (ERA) model. 58 SYSTÉMOVÁ INTEGRACE 4/2010

Akcentace a inovace konceptuálního modelu při vývoji databázových aplikací 3.2 Přínosy ERA modelu Ověřením použití ERA modelu v praxi byly potvrzeny následující přínosy: 1. ERA model zaznamenává důležité metainformace o entitách, které by jinak pro členy vývojového týmu byly nedostupné nebo podléhaly zkreslení. 2. Model využívá pro svoji grafickou reprezentaci klasické prvky ER diagramu. Možné je použít symbol trojúhelníku pro grafickou reprezentaci množiny upozornění. 3. Model lze použít v odlišných typech databázových projektů. 4. Složitost modelu se zvyšuje minimálně. Model je snadno čitelný pro všechny členy vývojového týmu (za předpokladu, že ovládají modelování pomocí ER diagramů). Hlavním přínosem modelu ERA je efektivnější způsob tvorby databází, tak aby databáze byly optimalizované pro konkrétní typ použití na základě zaznamenání metainformací o entitách. 3.3 Případová studie použití Entity-Relationship Alert modelu 3.3.1 Analýza požadavků Formulace požadavků Vytvořit internetovou aplikaci zabývající se prezentací nabídek práce tak, aby redaktoři mohli vytvářet, upravovat a zobrazovat příspěvky s možností online prezentováním uživatelům na webovém portálu. Smyslem je, aby práce všech uživatelů byla efektivnější. Koncept projektu Jedná se o webový portál, životnost je plánována na 10 let. Předpokládáno je, že denně bude přidáno 80 nabídek práce. Nabídky práce jsou napsány uživatelem v administračním rozhraní. Příspěvek je zařazen do kategorie. Každý příspěvek může mít komentář, který je přidáván registrovaným uživatelem. 3.3.2 Konceptuální schéma Slovník entit CATEGORY - kategorie příspěvku USER - registrovaný uživatel COMMENT - komentář příspěvku POST - příspěvek konkrétní nabídky práce SYSTÉMOVÁ INTEGRACE 4/2010 59

JanTyrychtr, Julie Poláčková, Ivana Švarcová ERA diagram 4. Shrnutí V příspěvku je posouzen statistický vliv vybraných faktorů (počet řádků v tabulce, doba odezvy zpracování SQL dotazů) na dobu odezvy systému Wordpress. Statistický vliv je testován na prostřednictvím SQL DBMS databázového systému MySQL. Hlavní zkoumanou hypotézou je, že rychlost systému Wordpress je pozitivně korelována s počtem řádků v databázi databázového systému MySQL. Účinek tohoto vztahu byl zkoumán pomocí korelační analýzy. Výsledky potvrdily, že rychlost je pozitivně asociována s počtem řádků v databázi. Na základě výsledků byl inovován ER model o množinu upozornění. Množina upozornění ESA (Entity Set - Alert) slouží pro zaznamenání předpokládaných charakteristik reálných objektů (entit), přístupem prostupujícím od konceptuálního datového modelu ke schématu databáze. ESA lze transformovat na logický datový model. Grafickou podobu ESA je možné transformovat na zjednodušený způsob znázornění. Množina upozornění je graficky vyjádřena trojúhelníkem. Hodnoty atributů jsou napsány po stranách trojúhelníku. Názvy atributů jsou vyjádřeny v závorkách, které jsou připsány ke každé hodnotě. Matematický aparát konceptu entit a vztahů zůstává zachován. Konceptuální datový model vyjádřený pomocí ER diagramu s množinou upozornění je nazván Entity-Relationship Alert model. 60 SYSTÉMOVÁ INTEGRACE 4/2010

Akcentace a inovace konceptuálního modelu při vývoji databázových aplikací 5. Náměty pro další výzkum Způsob akcentace neoptimalizovaných databází je ověřen na jediném typu aplikace. Autoři dosud model ERA neporovnávali z hlediska návaznosti mezi jednotlivými artefakty zapojenými do jakékoli fáze procesu vývoje databáze což bude předmětem dalšího výzkumu. Připravuje se porovnání modelu například s MEDEA. [13] Model ERA lze případně řešit z hlediska obohacení o asociační pravidla (AR-EER, [14]), Mesodata [15] apod. Rozšířením modelu ERA o výše uvedené náměty dostává aplikace tohoto modelu nový procesní a ekonomický rozměr, který zvyšuje její použitelnost v reálné praxi podniků. 6. Závěr V současnosti je konceptuální schéma nejčastěji znázorňováno prostřednictvím ER-modelu. Tento model a jeho notace byly publikovány Chenem v roce 1976. Od té doby vznikaly různé alternativní notace (Martinova notace, Bachmanova notace, IDEF1X, UML a další ) a modely - nejznámější je EER model (v současnosti velmi často používán). Smysl samotného konceptuálního návrhu se začal postupně přesouvat do pozadí a novým cílem tvůrců notací a modelů se stala schopnost zaznamenat co nejvíce různých typů vztahů, typů atributů, hierarchií a jejich vzájemnou korelaci (EER model, AER model a další). V článku [5] je navržen soubor metrik pro měření strukturálních vlastností ER diagramů pro předpověď vnější kvality modelu. Článek [1] poukazuje na to, že přítomnost vztahu hierarchie je hlavním zdrojem složitosti modelu. Všechny tyto poznatky jsou důvodem pro používání srozumitelných notací pro tvorbu konceptuálních modelů, bez přídavných prvků, které srozumitelnost modelu snižují. Autory byl představen inovovaný Chenův ER model (nazvaný ERA model). Tento model využívá klasickou "jednoduchou" Chenovu notaci, modifikovanou o množinu upozornění (ESA). ESA přidává do modelu důležitou informaci o entitách, která by jinak pro členy vývojového týmu byla nedostupná nebo podléhala zkreslení (vlastní představy o entitách). Výsledky statistických testů potvrdily, že doba odezvy systému Wordpress je pozitivně asociována s počtem řádků v databázi databázového systému MySQL. Jedná se o důležité potvrzení toho, že při vývoji databází v systému Wordpress je nutné predikovat budoucí vytížení databáze. To je nutné provádět tak, aby každý z členů vývojového týmu mohl provést kroky pro optimalizaci a správný návrh struktury a logiky konceptuálních, logických modelů a databází. Výrazně je proto akcentována potřeba zaznamenávat informace (mající na budoucí aplikaci vliv z hlediska decelerace celkové účinnosti databázového systému) do ER modelu. Navržená inovace konceptuálního modelu dat má za cíl zlepšit kvalitu vytvářených databázových projektů a to tak, aby nedocházelo ke komunikačnímu šumu v rámci přenosu informací mezi jednotlivými členy vývojového týmu. SYSTÉMOVÁ INTEGRACE 4/2010 61

JanTyrychtr, Julie Poláčková, Ivana Švarcová Tento příspěvek byl zpracován v rámci řešení IGA ČZU v Praze (reg. č. 201011150010) Akcentace procesní orientace tvorby databázových struktur jako hlavního faktoru decelerace odezvy webových aplikací. Literatura [1] Artale, A., Calvanese, D., Kontchakov, R., Ryzhikov, V., Zakharyaschev, M.(2007) Reasoning over Extended ER Models, (2007) ER 2007, pp. 277-292. [2] Bachman, C. W. (1969) Data Structure Diagrams, Database 1, 2, pp. 4-10. [3] Chamberlin, D., (1981) A History and Evaluation of System R, Communications of the ACM, vol. 24, No.10, pp. 632-646. [4] Fahrner, C., Vossen, G.(1995) A survey of database design transformations based on the Entity-Relationship model, (1995) Data and Knowledge Engineering, 15 (3), pp. 213-250. [5] Genero, M., Poels, G., Piattini, M.(2007) Defining and validating metrics for assessing the understandability of entity-relationship diagrams, (2007) Elsevier, October 2007. [6] Chen, P. P., (2002) Entity-Relationship Modeling: Historical Events, Future Trends, and Lessons Learned in: Software Pioneers: Contributions to Software Engineering, Broy M. and Denert, E. (eds.), Springer-Verlag, Berlin, Lecturing Notes in Computer Sciences, June 2002, pp. 100-114, ISBN# 3-540-43081-4. [7] Chen, P. P. (1983) A prelimary framework Entity-Relationship models, Entity-Relationship Approach to Systems Analysis and Design (North-Holland, 1983). [8] Chen, P. P.(1980) English sentence structures and Entity-Relationship diagrams, in: Chen, P.P. (ed.), Entity-Relationship Approach to Systems Analysis and Design (North-Holland, Amsterdam, June 1980). [9] Chen, P. P.(1976) The entity relationship model: toward a unified view of data, ACM Transactions on Database Systems, 1, 1 (March 1976),9-37. [10] Navathe, S.B., (1992) Evolution of data modeling for databases. Commun ACM 35(9):112 123. [11] Piattini, M., Calero, C., Genero, M.(2001) Table Oriented Metrics for Relational Databases, (2001) Software Quality Journal, 9 (2), pp. 79-97. [12] MySQL 5.5 Reference Manual [online]. Publikováno 2010 [cit. 2010-12-04]. Dostupné z: <http://dev.mysql.com/doc/refman/5.5/en/index.html>. [13] Dominguez, E., Lloret, J., Rubio, A., Zapata, M. (2008) MeDEA: A database evolution architecture with traceability, Data & Knowledge Engineering 65, pp. 419 441. [14] Chen, G., Ren, M., Yan, P., Guo, X. (2007) Enriching the ER model based on discovered association rules, Information Sciences 177, pp. 1558 1566. [15] La-Ongsri, S., Roddick, J. Vries, D. (2008) Accommodating mesodata into conceptual modelling methodologies, Information and Software Technology, 50, pp. 424 435. 62 SYSTÉMOVÁ INTEGRACE 4/2010