Nasazení Object Relation Mapping nástrojů nad legacy datovým modelem

Nasazení Object Relation Mapping nástrojů nad legacy datovým modelem 1 Ondřej Berger, Pavel Janečka, 2 Lukáš Černovský 1 Univerzita Hradec Králové Fakulta informatiky a managementu KIKM Hradecká 1249/6, Hradec Králové 2 ORTEX spol. s r.o., Resslova 935/3, 500 02 Hradec Králové (ondrej.berger@uhk.cz), (pavel.janecka@uhk.cz), (lukas.cernovsky@ortex.cz) Abstrakt: Modernizace informačního systému s sebou přináší otázky a problémy, kdy je nutné na jedné straně modernizovat současný systém prostřednictvím nových přístupů a technologií a zároveň zachovat kontinuitu dat spravovaných systémem. Často není možné realizovat odstavení starého systému a přejít v jednom kroku na systém nový. Je tedy nutné zajistit sdílení datové základny mezi různými systémy a na nový systém přecházet postupně a řešit tak souběh aplikací a sdílení datové základny. Následující text se proto zaměřuje na realizaci transakčního přístupu k datům pomocí objektově relačního nástroje. Podmínkou ovšem je zachování současného netransakčního procedurálního přístupu a to nad společnou datovou základnou. Jedním z požadavků je i provedení co nejmenšího počtu změn datového modelu. Klíčová slova: ORM, databázové systémy, COBOL, MyBatis, uložené procedury Abstract: When modernizing an information system it is necesssary to deal with problems and questions modernization brings. The new system is inovated by new technologies and must preserve data which controls. It happends very often that old system cannot be shutdown and replaced by new system in single step. Then it s necessary to share one database among various systems and transfer responsibilities to the new system continually. This solution brings problematic situations which are discussed in this paper. Transactional access using object relation mapping is presented together with non-transactional relation/procedural access with shared database objects. Other presented restriction is that number of database changes should be as small as possible. Keywords: ORM, database systems, COBOL, MyBatis, stored procedures 1. Úvod Vývoj software nekončí jeho nasazením první verze na produkčním prostředí, ale musí být dále opravován, postupně přibývají nové vlastnosti a funkcionality a často bývá dále intergrován s dalším existujícím či nově vytvářeným software. Neustále se měnící požadavky ze strany uživatelů a vývoj stále modernějších frameworků a technologií zapříčiňuje stárnutí vývojové platformy i samotného softwarového produktu. Pokud má být zachována stejná funkčnost při vývoji nového - modernějšího - software bez možnosti dlouhodobějšího odstavení je nutné podniknout kroky postupné transformace legacy datového modelu. Článek popisuje možný přístup k problematice transformace legacy datového modelu pro modernější nástroje ORM (Object Relation SYSTÉMOVÁ INTEGRACE 4/2012 157

Ondřej Berger, Pavel Janečka, Lukáš Černovský Mapping) objektově relační mapování, umožňující snažší převod mezi relační databází a objektovým prostředím. 2. Motivace Transformace datového modelu software starého několik let nebývá ve většině případů přiliš složitá, pokud byl však původní legacy systém naprogramován ještě ve strukturovaném paradigmatu a nově vznikající software využívá objektový přístup, naráží se na značnou zastaralost původních technologií a objevují se problémy, jejichž řešení není triviální. Referenční integrita není zajišťována primárními a cizími klíči, ale je obsažena v aplikační logice legacy systému, kterou z důvodu jiného paradigmatu nelze využít. Nekteré programovací jazyky neumí využívat hodnotu null a proto bývá nahrazována v legacy datových modelech prázdným řetězcem. Z důvodu nedostatečných systémových prostředků se v legacy systémech často obchází první normální forma a data jsou úmyslně duplikována pro vyšší rychlost přístupu. Konzistence je pak zajišťována v aplikační vrstvě. Chyby v aplikaci pak mohou zapříčiňovat vysokou nekonzistenci dat se kterou je nutné počítat.v legacy systémech se často vytváří dynamické názvy datových zdrojů v závislosti na jejich časovém zařazení. To však znesnadňuje využití ORM nástrojů pro mapování na objekty. Pokud není možné stará data a celý datový model zahodit a začít od úplného začátku, je nutné dodržet správný postup postupné transformace a migrace dat do nového datového modelu. Ideálním řešením by v případě nového systému bylo vytvoření úplně nové databázové vrstvy navržené s ohledem na použití ORM nástroje. To by umožnilo odstranit existující problémy, jako například referenční integrita a chybějící vazby a obecně vylepšit a zefektivnit databázový model. Mezi základní požadavky často patří běh legacy systému souběžně s novým systémem navrženým ve programovacím jazyce vyšší úrovně než systém předchozí. Proto je třeba aplikovat jiné přístupy, které umožní nejprve souběžný provoz starého i nového systému a poté umožní přemigrovat na systém nový. Článek se zaměřuje na použitelné přístupy a řešení z hlediska databázové vrstvy, která je pro většinu aplikací klíčová. Bude nastíněno i pozdější migrování a odstavení starého systému a návrh vhodné architektury vznikající aplikace. 3. Zachování DB Často není možné novou aplikaci realizovat jako separátní od původního řešení. Nelze tedy vytvořit novou databázovou vrstvu s novým modelem, a je třeba navrhnout integraci nového řešení se starým datovým modelem. S využitím uvedených databázových technik je možné nad existující nevyhovující databázovou vrstvou pomocí pohledů a triggerů emulovat korektní relační databázové schéma využitelné pro ORM nástroje. Vrstva přístupu k datům (tzv. Data Access Object - DAO) v nové aplikaci tak může využívat kupříkladu nástroje Hibernate, či MyBatis. Z hlediska nestandardnosti řešení bude vhodnější využít nástroj MyBatis oproti Hibernate. Hlavní důvodem je konstrukce některých databázových dotazů vyžadují 158 SYSTÉMOVÁ INTEGRACE 4/2012

Nasazení Object Relation Mapping nástrojů nad legacy datovým modelem konkrétní a specificky upravené SQL dotazy, které lze lépe definovat v MyBatis mapovacích souborech. 3.1 Vydefinování nových entit Legacy databázové modely obsahují obvykle velké množství problémů či nedostatků pro ORM nástroje, jako jsou špatná referenční integrita, chybějící vazby, nenormalita modelu a další. Je tedy nutné vydefinování nového modelu. Ten by měl zachovávat vazby a logiku modelu původního a dodržovat alespoň základní požadavky na normalitu a kvalitu návrhu. Zároveň je nezbytné model navrhnout tak, aby byl realizovatelný pomocí dále uvedených technik. 3.2 View entity nad stávajícím modelem Při tvorbě nových entit je nezbytné redefinovat některé staré aplikační entity tak, aby lépe vyhovovaly požadavkům na objektový přístup. 3.2.1 Čtení z databáze Vzhledem k problémům, které má stávající databázové schéma, není možné definovat nové entity jako stávající databázové tabulky, ale je nutné provést transformaci tak aby jednak zachovala původní funkcionalitu staré aplikace, a zároveň umožnila vytvořit objektovou aplikaci novou. Je nutné se zaměřit na následující oblasti. 3.2.2 Datové typy a relace Legacy systémy často obsahují omezení, jako například absence podpory hodnoty null v databázi, které však mohou být zásadní pro datový model, zejména pak v oblasti relací, nově vznikající aplikace a využití vybraných frameworků. Použití ORM nástrojů (ať už MyBatis či Hibernate, JPA atd.) umožňuje tuto chybějící vlastnost překlenout pomocí vlastních datových typů a jejich obsluhy při překladu mezi databázovou a aplikační vrstvou. Pro potřeby nové aplikace pracující se starou databází je nutné vytvořit dvě základní transformace primárních a zejména cizích klíčů pro podporu prázdných (null) hodnot. Pro číselné sloupce hodnota 0 znamená null, pro textové sloupce pak řetězec složený pouze z mezer. Pro tyto účely MyBatis definuje rozhraní [1], které umožnuje definovat vlastní datové typy v aplikaci a zajistit jejich mapování na databázové datové typy. Pro nově vznikající aplikaci lze tento handler využít pro transformaci databázových hodnot 0 a prázdných řetězců na hodnotu null. Tento datový handler se poté registruje na příslušné sloupce tabulky, buď v tzv. Result map, případně přímo v definici SQL příkazu : <resultmap id="accountresultmap" type="account"> <id property="id" column="id" typehandler= cz.account.handler.emptytonullhandler /> <result property="title" column="account_title"/>... </resultmap> SYSTÉMOVÁ INTEGRACE 4/2012 159

Ondřej Berger, Pavel Janečka, Lukáš Černovský Následuje zjednodušená ukázka části kódu handleru, mapujícího prázdný řetězec z aplikace, na null hodnotu a opačně: public class EmptyToNullTypeHandler implements TypeHandler<String> { @Override public void setparameter(preparedstatement ps, int i, String parameter, JdbcType jdbctype) throws SQLException { if (parameter == null)) { ps.setstring(i, ); } else { ps.setstring(i, parameter); } } @Override public String getresult(resultset rs, String columnname) throws SQLException { String dbvalue = rs.getstring(columnname); if (.equals(dbvalue)) return null; return dbvalue; }.. } V legacy aplikacích je často problematické použití primárních klíčů v podobě řetězců. To přináší výkonnostní problémy a obtížné definování relací. Zejména v případě, že databáze obsahuje tisíce záznamů, dochází ke zpomalení při vyhledávání a práci s primárním klíčem. Není dost dobře možné nahradit primární klíče ve staré aplikaci číselnými, pro účely provozování hybridního řešení (tedy nové aplikace nad stávající databázovou základnou) je třeba novou aplikaci navrhnout s využitím číselných primárních a cizích klíčů. Do stávající databázové základny se tak doplní nové sloupce, které nebudou databázovými PK a FK, ale budou vyjadřovat stejnou relaci pro nový systém. O nových sloupcích nebude mít stará aplikace žádné informace, nebude je tedy využívat. 160 SYSTÉMOVÁ INTEGRACE 4/2012

Nasazení Object Relation Mapping nástrojů nad legacy datovým modelem View entity Pro účely čtení dat z databáze ve formě entit, které jsou vydefinovány pro novou aplikaci, je možné v legacy databázovém schématu definovat tzv. pohledy. Pohledy (views) jsou ve své podstatě definované SELECT dotazy, které se databázovému klientu tváří jako tabulka, nad kterou lze provádět klasické SQL dotazy. Jediným omezením v tomto případě, je skutečnost, že v případě složitějších pohledů, které kupříkladu obsahují agregační či join funkce, není možné tyto pohledy použít pro vkládání ani editaci dat. Ovšem pro účely čtení dat je možné snadno v nové aplikaci vydefinovat entity, které budou databázově napojené na view, nikoliv skutečné tabulky. Problematiku relací entit je v některých případech možné řešit také pomocí relací view pohledů, eventuálně na vrstvě aplikační logiky přímo v DAO objektech do hybridní aplikace doplnit kód pro korekci relací. 3.2.3 Zápis do databáze Čtení dat je realizováno pomocí entit, které jsou mapovány na databázové pohledy. Protože databázové pohledy, které jsou složitější (spojují více tabulek, obsahují agregační funkce apod.) nefungují pro zápis, je nutné zápis do správných tabulek / sloupců realizovat buď na úrovni DAO vrstvy aplikace, případně až na úrovni databáze. DAO realizace zápisu V případě požití zápisu realizovaného na úrovni aplikační logiky, je nutné v aplikaci provést inserty / updaty sloupců příslušných tabulek, ze kterých se skládá daná entita. Nástroj MyBatis je opět ve výhodě proti ostatním ORM frameworkům, jelikož umožňuje definovat vlastní SQL dotazy, které lze přímo optimalizovat pro vybranou databázi. Použití Hibernate je poněkud obtížnější, i když ne nemožné, je také možné definovat vlastní pojmenované dotazy. Provedení uvedených db operací v rámci jedné transakce dále zajistí integritu dat v databázi. Primární a cizí klíče Primární a cizí klíče jsou v legacy systémech realizovány pomocí řetězcových hodnot. Z výkonnostních důvodů [2] je nutné novou aplikaci navrhnout s využitím číselných primárních a cizích klíčů. Do stávající databázové základny se tak doplní nové sloupce, které nebudou databázovými PK a FK, ale budou vyjadřovat stejnou relaci pro nový systém. O nových sloupcích nebude mít stará aplikace žádné informace, nebude je tedy využívat. Toto řešení umožní v některých případech eliminovat i potřebu vlastních datový typů pro podporu null hodnot. V případě nové aplikace je pak nutné na úrovni databáze zajistit správné vyplnění existujících řetězcových primárních klíčů, tedy aby relace vyjádřená pomocí číselných falešných klíčů byla pro potřeby staré aplikace vyjádřena i pomocí řetězcových. Vzhledem k tomu, že db after_insert triggery na nově vložených záznamech jsou problematické z hlediska nekonečných rekurzí je nutné tuto relaci vyjádřit již do dat vkládaných/editovaných v nové aplikaci. V případě editace dat není tento přístup nevhodný, jelikož příslušné hodnoty klíčů budou součástí editovaných dat. Pro vkládání nových dat je tedy vyžadován navíc jeden nebo více dotazů do databáze, které příslušné hodnoty zjistí. Z hlediska výkonu tento přístup nepředstavuje problém, SYSTÉMOVÁ INTEGRACE 4/2012 161

Ondřej Berger, Pavel Janečka, Lukáš Černovský protože operace vkládání a editací jsou v drtivé většině případů méně časté než čtení, zpomalení vložení tak nebude znatelné z hlediska uživatele. INSTEAD OF trigger Pro lépe přenositelný kód, který zajistí lepší migraci na nový systém je vhodnější zápisy realizovat co nejvíce v databázové vrstvě. Je-li to možné je vhodné realizovat tento přístup místo transakce v aplikační logice popsané v předchozí části. K realizaci tohoto přístupu je nutné využívat tzv. instead-of trigger, který je podporován všemi moderními databázemi [3-6]. Tento zvláštní druh uložené procedury umožňuje vykonat definované SQL příkazy místo zvolené operace nad danou tabulkou nebo pohledem. Z toho vyplývá i možnost, definovat tento druh triggeru na insert/update operace nad pohledem, který odpovídá aplikačním entitám. Aplikace tak zavolá běžný insert či update SQL dotaz, a ten je interně realizován pomocí instead-of triggeru. Tento trigger tak rozloží operaci nad pohledem do operací nad jednotlivými tabulkami, ze kterých se daný pohled skládá. 3.2.4 Dynamické názvy tabulek Legacy systémy mohou obsahovat neefektivní strukturu ukládání určitých například měsíčních dat do separátních tabulek, které mají jednotnou strukturu sloupců, ovšem liší se se svým názvem. V tomto názvu tabulky je zakódován měsíc a rok, ke kterému se vztahují uložená data. Celkově není toto řešení zdaleka ideální, z hlediska DB návrhu nového systému je efektivnější tato data sloučit do jedné tabulky, které bude přidán jeden či dva sloupce identifikující rok a měsíc, ke kterému se data vztahují. Nicméně vzhledem k nutnosti minimalizovat úpravy stávajícího systému je nutné tento model návrhu se separátními tabulkami zachovat a přístup nového systému vyřešit tak, aby byl později možný přechod na lepší strukturu. Databázová funkce Jedním z možných řešení je využití databázových funkcí. V databázovém serveru je tak možné definovat funkci, které se předá rok a měsíc a tato funkce na základě parametrů zvolí příslušnou tabulku, ze které se budou zpracovávat data. Tuto funkci je poté možné používat v dotazech z DAO vrstvy a předávat pouze parametr identifikující danou tabulku. Následuje ukázka funkce pro výběr dat z tabulek měsíce fixního roku (zjednodušeno) jak je možné ji definovat v PostgreSQL. Tabulky jsou pojmenovány: month_2012_1, month_2012_2 atd. A všechny mají sloupec value, který je stejného typu varchar a bude vrácen z funkce jako month_value. CREATE OR REPLACE FUNCTION select_month(int) RETURNS TABLE (month_value VARCHAR) AS $$ BEGIN RETURN QUERY EXECUTE 'SELECT value FROM month_2012_' $1 ; END; 162 SYSTÉMOVÁ INTEGRACE 4/2012

Nasazení Object Relation Mapping nástrojů nad legacy datovým modelem $$ LANGUAGE plpgsql STRICT SECURITY DEFINER; Výběr měsíce ledna je pak možné určit přímo v SQL pomocí parametru výše vytvořené funkce: SELECT * FROM select_month(1); Takto lze sjednotit přístup k dynamickým názvům tabulek, které mají jednotnou strukuturu a určité schématické pojmenování. Klienta databáze odstíníme pomocí funkce od schématu jež neplní požadavky na normalitu. Dynamický SQL dotaz V případě, že není možné definovat databázové funkce, které budou na základě parametrů vracet tabulku, je nutné dynamicky skládat dotaz již na úrovni aplikace, tedy v DAO vrstvě. V tomto případě je výhodnější použití frameworku MyBatis, jelikož umožňuje přímou manipulaci s SQL dotazem během provádění, a pomocí parametrů tak lze definovat nejen hodnoty upravující výsledek dotazu (např. filtry ve WHERE klauzulích apod.), ale i dynamicky definovat jména tabulek. Oproti tomu Hibernate je v tomto ohledu problematický, neboť mapuje jednu tabulku na jednu entitu. Není tak možné dynamicky měnit název tabulky mapovaný na entitu. Je sice možné pomocí NamingStrategies [7] toto chování měnit, ale změna této strategie vyžaduje mj. i vytvoření uplně nové session factory, potažmo Hibernate session. Je to proto problematické realizovat v aplikaci, která dynamicky pracuje s různými entitami z různých zdrojových tabulek. 3.3 Přepsání DAO vrstvy Vícevrstvý návrh nově vznikající aplikace umožňuje využití legacy datového modelu o nově navrženého datového modelu najednou, za pomocí dvou různých DAO vrstev představujících přístup k jednotlivým datovým modelům. Data ze starého modelu získává jedna implementace DAO vrstvy a při jejich změně jsou data již zapisována pomocí druhé DAO implementace do nového datového modelu. Při použítí tohoto přístupu je možné kompletně projít legacy datový model a zmigrovat data do nového datového modelu pomocí pomocí sjednocující datové vrstvy. SYSTÉMOVÁ INTEGRACE 4/2012 163

Ondřej Berger, Pavel Janečka, Lukáš Černovský Obrázek č.1 - využití dvou DAO vrstev k souběžnému běhu obou datových modelů a postupné migraci dat 3.3.1 Replikace databázové vrstvy Provedení migrace dat mezi starou datovou základnou a novým systémem je vhodné provádět průběžně během souběžného fungování obou aplikací. Pro menší systémy, nebo systémy, kde je zaručeno, že během souběžné práce systémů dojde k aktualizaci všech záznamů ve všech tabulkách, je možné na úrovni databáze data replikovat. Nelze ovšem využít replikaci pomocí nástrojů databáze, protože je třeba měnit i strukturu dat mezi starým a novým systémem. Proto je nutné využít triggery (after-inster, after-update, after-delete) na starém db modelu, které budou provádět příslušné operace do nové datové základy nového systému. V případě, že bude zapisovat nová aplikace, je nutné podobné triggery přidat i do nové databáze, kde budou měnit data ve starém systému. Tento postup je ale možný pouze pro situace, kdy lze garantovat, že všechny záznamy projdou aktualizacemi, jinak by v novém datovém modelu některé záznamy chyběly, protože by se pro ně neprovedly příslušné triggery. 3.4 Návrh nové aplikace Novou aplikaci, která poběží souběžně s existujícím systémem je nutné navrhnout s ohledem na následující skutečnosti a omezení: Datový model, jež bude vydefinován pro samostatný běh, musí být v maximální možné míře realizovatelný pomocí uvedených postupů. Vrstva přístupu k datům (DAO) musí být uplně odstíněna od zbývající aplikační logiky z důvodu pozdější migrace na novou databázovou strukturu. 164 SYSTÉMOVÁ INTEGRACE 4/2012

Nasazení Object Relation Mapping nástrojů nad legacy datovým modelem Není-li možné některé databázové relace a struktury vyjádřit pomocí view a triggerů, musí být aplikační logika týkající se těchto vazeb implementována pouze v DAO vrstvě. V ideálním případě by do vrstev využívajících DAO neměly přijít přímo entity, ale již transformované DTO objekty pro přenos dat. Je tak možné odstínit databázové relace od objektových. 3.5 Migrace po odstavení původního systému Přechod od legacy systému ke kompletně nové implementaci s postupnou transformací dat prochází třemi hlavními stavy. Legacy systém je posupně nahrazován hybridním přístupem, kdy s výše uvedenými postupy nad stejnou databází pracují legacy systém i nově implementovaná aplikace využívající ORM mapování. Postupně pak data migrují do nové databáze a starý legacy systém je kompletně odstaven. Obrázek č.2 - postupná migrace a odstavení legacy datového modelu 4. Závěr Tvorba nového systému při zachování funkčnosti starého a sdílení datové základny je netriviální postup, s nutností kreativního přístupu k řešení. Výše uvedené postupy a návrhy řeší požadavky, které vznikly v průběhu reálné migrace existujícího systému. Některé myšlenky se v průběhu implementace ukázaly jako nevhodné v konkrétní situaci, ovšem testy na vzorcích dat ukázaly, že jsou realizovatelné v praxi. Zdroje [1] TypeHandler interface. MyBatis documentation [online]. 2012 [cit. 2012-07-22]. Dostupné z: http://www.mybatis.org/core/apidocs/reference/org/apache/ibatis/type/typeha ndler.html SYSTÉMOVÁ INTEGRACE 4/2012 165

Ondřej Berger, Pavel Janečka, Lukáš Černovský [2] InformIT. Natural or Surrogate Keys: The Cost of GUIDs as Primary Keys [online]. 2002 [cit. 2012-08-03]. Dostupné z: http://www.informit.com/articles/article.aspx?p=25862 [3] MICROSOFT. MSDN Library: Designing INSTEAD OF Triggers [online]. 2012 [cit. 2012-08-07]. Dostupné z: http://msdn.microsoft.com/enus/library/aa175158(v=sql.80).aspx [4] ORACLE. Oracle Database Application Developer's Guide - Fundamentals: Coding Triggers [online]. 2005 [cit. 2012-08-07]. Dostupné z: http://docs.oracle.com/cd/b19306_01/appdev.102/b14251/adfns_triggers.htm#babcibbj [5] POSTGRESQL GLOBAL DEVELOPMENT GROUP. PostgreSQL: Documentation: 9.1: Create trigger [online]. 2012 [cit. 2012-08-07]. Dostupné z: http://www.postgresql.org/docs/9.1/static/sql-createtrigger.html [6] IBM. INSTEAD OF Triggers: All Views are Updatable [online]. 2002 [cit. 2012-08- 07]. Dostupné z: http://www.ibm.com/developerworks/data/library/techarticle/0210rielau/02 10rielau.html [7] Naming Strategy in Hibernate [online]. 2010 [cit. 2012-08-09]. Dostupné z: http://java.dzone.com/articles/naming-strategy-hibernate JEL: C80, M15 166 SYSTÉMOVÁ INTEGRACE 4/2012