Revista Informatica Economică nr.2 (38)/2006 5 History and Point in Time in Enterprise Applications Prof.dr. Constantin-Gelu APOSTOL, Catedra de Informatică Economică, A.S.E. Bucureşti ec. Daniel BĂLĂCEANU, TotalSoft S.A., Bucureşti First part points out the main differences between temporal and non-temporal databases. In the second part, based on identification of the three main categories of time involved in database applications: user-defined time, valid time and transaction time, some relevant solutions for their implementation are discussed, mainly from the point of view of database organization and data access level of enterprise applications. The final part is dedicated to the influences of historical data in the business logic and presentation levels of enterprise applications and in application services, as security, workflow, reporting. Keywords: temporal databases, non-temporal databases, user-define time, valid time, transaction time, enterprise application architecture, application services P entru proiectarea bazelor de date şi a aplicaţiilor de întreprindere o anumită viziune asupra dimensiunii temporale a datelor este obligatorie. Baze de date temporale şi non-temporale După modul cum tratează atributul timp, bazele de date pot fi împărţite în două mari categorii: temporale, respectiv nontemporale. Majoritatea sistemelor de gestiune a bazelor de date (SGBD) comerciale sunt în esenţă non-temporale, adică nu tratează distinct dimensiunea temporală a datelor. Ca urmare, într-o abordare simplistă, se poate ajunge ca toate datele memorate să fie considerate ca valide numai la timpul prezent. Datele trecute au fost suprascrise sau şterse, iar cele viitoare sunt considerate ca valide la un timp viitor, dar nu în prezent. Această caracteristică este valabilă atât pentru SGBD relaţionale (SGBDR), cât şi pentru SGBD orientate obiect (SGBD-OO). În consecinţă, considerând exemplul tabelei Persoana (figura 1), dintr-o bază de date relaţională, absenţa oricăror atribute (coloane) de timp conduce implicit la o abordare nontemporală. Eventualele schimbări de nume, prenume sau salariu se fac prin suprascriere, devenind imposibil răspunsul la întrebări de tipul: Câte persoane şi-au schimbat numele în ultimul an? sau De când are Ionescu Mihai salariul actual? sau Cine avea cel mai mare salariu acum două luni? etc. IDPersoana Nume Prenume Salariu 1000 Popescu Ioana 250 1001 Ionescu Mihai 125 1000 Mihnea Ioana 250 Fig.1. Exemplu de tabelă relaţională non-temporală În cazul unui SGBD-OO, persoanele vor deveni obiecte de un anumit tip, grupate în colecţii, caracterizate prin proprietăţi ca Nume, Prenume, Salariu etc. În absenţa unor proprietăţi temporale ale obiectelor de diverse tipuri se ajunge însă, ca şi pentru SGBDR, în situaţia în care multe cerinţe de analiză a datelor nu pot fi satisfăcute. Pentru modelarea atributului de timp pot fi identificate trei tipuri de date temporale fundamentale (Snodgrass, 2000): Moment: un moment sau punct în timp, când se întâmplă ceva (de exemplu, 20 iulie 1969, 20:17:40 GMT, când astronautul Neil Armstrong a pus piciorul pe Lună); Interval: o durată nelocalizată în timp (de exemplu, 12 luni, 15 minute, 30 secunde etc.); Perioadă: o durată localizată în timp (de exemplu, 1 decembrie 2005 la 31 ianuarie 2006).
6 Revista Informatica Economică nr.2 (38)/2006 În acord cu terminologia folosită în (Goralwalla et al., 2001), perioadele corespund unor date temporale ancorate, în timp ce intervalele sunt date temporale neancorate. Din perspectiva aplicaţiilor cu baze de date, este importantă distincţia între trei categorii fundamentale de timp: Timpul utilizator (user-defined time), reprezentând uzual un moment de timp (point in time) a cărui semnificaţie este determinată de utilizator (de exemplu, momentul când se execută o aplicaţie). Perioada de validitate (valid time), desemnând perioada de timp pe parcursul căreia un fapt este adevărat în raport cu situaţia din lumea reală. Perioada de tranzacţionare (transaction time), desemnând perioada de timp pe parcursul căreia un fapt este reflectat informaţional în baza de date. Aşa cum evidenţiază abordarea propusă de TimeConsult (1998), un prim pas spre trecerea la baze de date temporale îl reprezintă asocierea unor mărci de timp (timestamp) datelor, ceea ce permite realizarea distincţiei între diferitele stări ale bazei de date. Între soluţiile posibile se remarcă marcarea temporală a entităţilor, respectiv marcarea temporală a valorilor proprietăţilor acestor entităţi. În modelul de date relaţional sunt marcate tuplurile, iar în modelele de date orientate obiect sunt marcate obiectele şi/sau valorile proprietăţilor. În funcţie de modul de folosire a perioadelor de timp pentru marcare se distinge între mai multe forme de baze de date temporale: Baze de date istorice (historical database), care memorează datele în raport cu perioada de validitate. Baze de date tranzacţionale (rollback database), care memorează datele în raport cu perioada de tranzacţionare. Baze de date bitemporale (bitemporal database), care memorează datele în raport cu ambele perioade de timp. În raport cu această clasificare, bazele de date non-temporale pot fi considerate ca fiind doar instantanee (snapshot databases), având capacitatea să reflecte o singură stare a lumii reale, uzual pe cea mai recentă. Fără a ne propune să analizăm în ce măsură diversele SGBD comerciale actuale oferă soluţii pentru implementarea caracteristicilor bazelor de date temporale, remarcăm că discuţiile pe această temă sunt în continuare actuale, aşa cum evidenţiază, între altele, o recentă abordare a acestui subiect (Haughey et al., 2006). Din perspectiva reflectării atributului timp în aplicaţii, se remarcă faptul că majoritatea arhitecturilor structurează aplicaţiile pe mai multe niveluri (figura 2). Prezentare Logica afacerii Acces date Date Actor Fig.2. Arhitectura generală a aplicaţiilor de întreprindere Aspectele legate de istoric apar pe ultimele două niveluri, de acces la date şi de stocare a datelor. Nivelurile de logica afacerii şi de prezentare, plus alte posibile niveluri superioare, folosesc (sau ar trebui să folosească) nivelul de acces la date pentru orice probleme legate de istoric, mecanismul fiind transparent pentru ele. Înţelegerea corectă a celor trei categorii de timp evidenţiate anterior este esenţială pentru dezvoltatori, având în vedere că în bazele de date şi în aplicaţii pot interveni - succesiv sau simultan - una, două sau chiar toate cele trei categorii de timp. Exemplificările folosite în continuare în acest scop se bazează atât pe diagrame UML, cât şi pe valori concrete din tuplurile unor tabele ale bazei de date pentru gestiunea angajaţilor. Utilizarea perioadei de validitate Pentru aplicaţia de gestiune a angajaţilor este necesară înregistrarea datelor personale şi a
Revista Informatica Economică nr.2 (38)/2006 7 celor legate de angajare. Fiecare angajat este unic identificat prin marca sa, iar între atributele asociate uzual clasei Angajat se regăsesc (figura 3): Nume, Prenume, Adresa, tipul de contract, perioada de angajare, salariul net lei, salariul brut lei, salariul net USD, salariul brut USD. Angajat +Nume +Prenume +Adresa +Tip contract +Perioada Angajare +NetLei +NetUSD +BrutLei +BrutUSD Fig.3. Diagrama clasei Angajat Un angajat poate avea una sau mai multe adrese: de bază, flotantă, temporară etc. Angajatul îşi poate schimba numele; aceste schimbări trebuie înregistrate. Tipul de contract şi perioada de angajare sunt relativ stabile, putându-se modifica doar în cazuri excepţionale. Salariul angajatului se poate modifica în timp. Angajatul poate opta pentru o negociere a salariului în lei sau în valută, la nivel brut sau net. Funcţie de opţiunea sa, toate celelalte sume (NetLei, NetUSD, BrutLei, BrutUSD) se calculează în fiecare lună. În baza acestor cerinţe, modelul de mai sus se rafinează (figura 4), introducerea dimensiunii temporale determinând separarea într-o clasă distinctă a atributelor asupra cărora se aplică. În exemplul considerat, atributele Nume şi Prenume evoluează diferit de datele de angajare, fapt ce a determinat izolarea lor în clasa Persoana. Similar, datele de salariu au propria lor evoluţie, lunară, şi au fost izolate în clasa Salariu. O altă rafinare o reprezintă apariţia celor două atribute, DataStart şi DataFinal, cu ajutorul cărora este înregistrată perioada de validitate a înregistrărilor. Un Angajat poate avea unul sau mai multe salarii de-a lungul timpului. Dacă se adaugă însă calificatorii temporali, atunci un angajat are un singur Salariu la un anumit moment de timp. Persoana +Nume +Prenume +DataStart +DataFinal Angajat +Marca +Tip contract +Durata contract +DataStart +DataFinal +Are 1 +Apartine 1..* Salariu +NetLei +NetUSD +BrutLei +BrutUSD +Luna +DataStart +DataFinal Fig.4. Rafinarea modelului prin includerea dimensiunii temporale Transpunerea acestui model obiectual într-un model relaţional ridică unele probleme. De regulă, introducerea dimensiunii temporale adaugă un grad de multiplicitate, în sensul că acolo unde există o singură înregistrare pe obiect, odată cu istoricul vor exista mai multe. Există mai multe abordări posibile pentru transpunerea dimensiunii temporale în termenii modelului relaţional. De exemplu, considerând clasele Persoana şi Angajat, în plus faţă de modelul obiectual vor apare cheile primare (PK- Primary Key), cheile externe (FK Foreign Key), relaţiile dintre tabele. Necesitatea cheilor explică prezenţa atributelor de tip ID (IDPersoana, IDAngajat, IDSalariu etc.). În literatura de specialitate sunt propuse di-
8 Revista Informatica Economică nr.2 (38)/2006 verse tehnici de transpunere a modelelor obiect în structuri relaţionale (Blaha & Rumbaugh, 2004) precum şi pattern-uri temporale (Fowler, 2005) asociate modelelor de istoric al datelor. În funcţie de modelul de istoric ales, modelul relaţional poate arăta diferit. În cazul unui sistem simplu bazat pe înregistrarea modificărilor (audit log), cea mai bună soluţie este adăugarea unei noi tabele în care sunt păstrate înregistrările istorice (figura 5). În acest scenariu, în tblpersoana sunt păstrate datele curente, iar în tblpersoanalog datele istorice. Modelul este bun atunci când aplicaţia foloseşte uzual doar datele valide la momentul curent (sau un alt moment ales de aplicaţie); datele istorice sunt folosite doar izolat, pentru consultări de genul cum au evoluat datele personale? Fig.5. Model relaţional cu tabelă pentru date istorice Într-un alt scenariu posibil (figura 6), toate datele sunt păstrate într-o singură tabelă. Fig.6. Model relaţional cu o singură tabelă Fără cele două atribute (coloane) temporale, IDPersoana (vrzi figura 5) poate forma singură cheia primară, cu consecinţa că fiecărei persoane îi corespunde un singur tuplu. Prin adăugarea coloanelor temporale, DataStart şi DataFinal, care împreună cu IDPersoana formează cheia primară, fiecărei persoane îi pot corespunde mai multe înregistrări, dar, într-un moment de timp dat, îi corespunde una singură, indiferent de scenariu. Fără a ne propune, în acest cadru, ilustrarea diverselor interogări posibile prin implementarea acestor modele, recomandăm una din cele mai complete lucrări de specialitate dedicată tratării istoricului în baze de date (Snodgrass, 2000). Utilizarea perioadei de tranzacţionare Tabelele analizate surprind doar una din dimensiunile temporale: durata de validitate, dar nu conţin date despre istoricul tranzacţiilor. Dacă, spre exemplu, datele personale sunt folosite pentru a tipări fluturaşii de salarii, este important de ştiut care erau datele valide cunoscute de aplicaţie la momentul tipăririi lor. În acest scop sunt adăugate două noi coloane temporale, DeLa şi PanaLa, care specifică perioada în care sistemul a cunoscut şi folosit acea înregistrare (figura 7), corespunzând perioadei de tranzacţionare. În exemplul din figura 7, în tabel sunt surprinse ambele dimensiuni temporare, perioada de validitate şi perioada de tranzacţionare. O mulţime de informaţii pot fi extrase dintr-o astfel de structură, dacă este analizată cu atenţie. 1000 Popescu Ioana 15.03.1976 10.10.2005 05.06.2004 20.10.2005 1001 Ionescu Mihai 20.10.1976 31.12.9999 06.06.2004 31.12.9999 1000 Mihnea Ioana 10.10.2005 31.12.9999 20.10.2005 31.12.9999 Fig.7. Includerea de atribute pentru perioada de tranzacţionare În cele ce urmează este descrisă evoluţia înregistrărilor din acest tabel. Pasul 1: Pe 5.06.2004 s-a înregistrat Popescu Ioana, înregistrare validă din 15.03.1976. (Asupra coloanelor DataFinal şi PanaLa se revine la pasul 3). 1000 Popescu Ioana 15.03.1976 31.12.9999 05.06.2004 31.12.9999
Revista Informatica Economică nr.2 (38)/2006 9 Pasul 2: Pe 6.06.2004 s-a înregistrat Ionescu Mihai, înregistrare validă din 15.03.1976 pâna la infinit (corespunzând, în standardul SQL, datei de 31.12.9999). 1000 Popescu Ioana 15.03.1976 31.12.9999 05.06.2004 31.12.9999 1001 Ionescu Mihai 20.10.1976 31.12.9999 06.06.2004 31.12.9999 Pasul 3: Pe 20.10.2005 sistemul înregistrează modificarea numelui persoanei 1000, din Popescu în Mihnea, începând cu 10.10.2005. 1000 Popescu Ioana 15.03.1976 10.10.2005 05.06.2004 20.10.2005 1001 Ionescu Mihai 20.10.1976 31.12.9999 06.06.2004 31.12.9999 1000 Mihnea Ioana 10.10.2005 31.12.9999 20.10.2005 31.12.9999 Odată cu apariţia noilor informaţii, primul rând a fost modificat şi el. DataFinal s-a modificat din 31.12.9999 în 10.10.2005, data pâna la care este validă înregistrarea, iar PanaLa s-a modificat în 20.10.2005, data la care sistemul a fost conştient de această modificare. Utilizarea timpului definit de utilizator Aşa cum reflectă soluţiile analizate, folosirea istoricului poate merge de la o simplă înregistrare a datelor istorice şi pâna la consultări ale întregii evoluţii a unui obiect. Ele acoperă partea de înregistrare şi consultare, dar procesele de afaceri pot necesita răspunsuri la întrebări de tipul: Care a fost starea întregului sistem cu două luni în urmă? sau Care va fi aceasta peste 3 luni?. Asemenea întrebări cer mai mult decât înregistrarea şi consultarea datelor istorice şi se bazează pe conceptul de timp definit de utilizator (point in time), care desemnează capacitatea unei aplicaţii de a funcţiona în mod nativ la orice moment de timp ales. Pentru a ilustra implicaţiile implementării în aplicaţii a acestui concept se consideră o tabelă Persoana, cu înregistrările din figura 8. RecordId EntityId Nume Marca DataStart DataFinal Salariu 1 1 Mihai 10000 01.01.2005 01.03.2005 100 2 2 Dan 10001 01.05.2005 150 3 1 Mihai 10000 01.03.2005 125 4 3 Vasile 10002 01.01.2005 01.03.2005 100 5 3 Vasile 10002 01.03.2005 130 Fig.8. Exemplu de tupluri dintr-o tabelă de personal Pot fi imaginate mai multe scenarii de utilizare a acestei tabele în aplicaţia de gestiune a personalului. Scenariul 1: Lista angajaţilor. La data de 01.02.2005 utilizatorul deschide aplicaţia şi solicită lista angajaţilor din companie. Apar Mihai şi Vasile reprezentând mulţimea înregistrărilor valide la data curentă. Scenariul 2: Detalii angajat. Este selectat angajatul Mihai. Salariul său este de 100, reprezentând salariul valid la 01.02.2005. Scenariul 3: Istoric angajat. Se apelează opţiunea Istoric, obţinându-se cele două înregistrări ale angajatului, cu salariul de 100, respectiv 125. De remarcat data de 01.02.2005, care este un element foarte important, ea dând momentul definit de utilizator pentru care sunt furnizate toate informaţiile. Modul de tratare a acestei date, numită uzual data curentă a aplicaţiei, poate fi diferit, cu următoarele variante de abordare: Data curentă. Există aplicaţii la care se consideră întotdeauna data curentă, aşa cum este ea furnizată de serverul de aplicaţii sau de staţia client. De regulă, aceste aplicaţii au nevoie de date istorice cel mult pentru operaţii de audit. Mulţime de valori. Există aplicaţii în care această dată poate lua valori dintr-o mulţime strictă de valori. Pentru o aplicaţie de salarii,
10 Revista Informatica Economică nr.2 (38)/2006 de exemplu, sau de contabilitate, luna de calcul este foarte importantă. Din acest motiv, de regulă, utilizatorii au posibilitatea să aleagă luna pentru care vor să lucreze, aplicaţia furnizându-le datele valide în acea lună. Orice dată. Există aplicaţii în care utilizatorul poate alege orice dată doreşte, aplicaţia furnizându-i datele valide la acel moment de timp. Toate interogările sunt făcute la data aleasă de utilizator. Implicaţii ale utilizării datelor istorice pe alte niveluri ale aplicaţiilor Modelele şi soluţiile evidenţiate au analizat implicaţiile dimensiunii temporale pentru nivelurile de acces la date şi de stocare a datelor (conform figurii 1). Cerinţe de considerare a evoluţiei în timp pot apare însă şi în celelalte niveluri ale aplicaţiei: Nivelul de logică a afacerii. Dacă se consideră, de exemplu, o aplicaţie de salarizare, trebuie avut în vedere că legislaţia din domeniu, cel puţin în România, este destul de dinamică. Regulile după care s-au calculat salariile anul trecut pot fi diferite de cele de astăzi. Dacă vrem să ne întoarcem la acel moment de timp şi să refacem calculul de salarii, vom avea nevoie de componenta de logică a afacerii de la acel moment. Nivelul de prezentare. Există aplicaţii dinamice în care interfaţa client este construită la momentul interogării: meniurile disponibile se afişează în funcţie de drepturi, acţiunile pe care le poate face utilizatorul sunt funcţie de starea sistemului etc. Toate aceste elemente pot fi şi ele afectate de istoric. Implicaţiile dimensiunii temporale asupra serviciilor din aplicaţii De regulă, diferitele servicii în cadrul unei aplicaţii folosesc şi ele structuri proprii de date. Problema istoricului în cadrul acestor servicii înseamnă de fapt semnificaţia şi modul cum folosesc ele datele istorice. Câteva dintre tipurile de servicii afectate de atributul timp sunt: Sistemul de securitate. De regulă, în orice model de securitate apar elemente ca utilizatori, roluri, acţiuni, obiecte. Modelul de securitate poate merge de la unul simplu, bazat pe roluri, până la unul complex, cu acţiuni şi obiecte care trebuie securizate. Şi aici pot apare întrebări legate de istoric: Ce permisiuni avea George la 1 iulie 2005? ; Exista utilizatorul George la 1 iulie 2005? ; Cum a putut George extrage acest raport, pentru că acum nu are aceste permisiuni? etc. Dacă se reia exemplul aplicaţiei de personal, în cadrul ei există rolul de manager, care oferă utilizatorului dreptul de a vizualiza angajaţii din cadrul departamentului său. Dacă utilizatorul se întoarce în timp, modificând data aplicaţiei, ce angajaţi va vedea el? Cei existenţi la acel moment? Era el manager la momentul de timp pe care şi l-a ales? Mecanisme de flux de lucru. Există aplicaţii care oferă facilităţi de flux de lucru (workflow), date de posibilitatea ca un obiect să treacă printr-o succesiune de stări ca urmare a unei acţiuni a utilizatorului sau a unor evenimente în cadrul aplicaţiei. În acest caz, succesiunea de stări prin care a trecut un document reprezintă istoricul acelui document în raport cu fluxul de lucru. Mai mult, se paote face distincţie între istoricul stărilor în flux şi istoricul conţinutului documentului, care pot fi diferite. Istoricul în sistemul de raportare. Scenariile analizate anterior au evidenţiat câteva tipuri de interogări legate de istoric. O problemă care poate apare aici este combinarea istoricului mai multor obiecte. Bibliografie 1. Blaha, M.R., Rumbaugh, J.R. (2004). Object- Oriented Modeling and Design with UML (2 nd Edition), Prentice Hall 2. Martin, F. (2005). Temporal Patterns, http://martinfowler.com/eaadev/timenarrative.html 3. Goralwalla, I.A., Leontiev, I., Özsu, M.T., Szafron, D., Combi, C. (2001). Temporal Granularity: Completing the Puzzle, Journal of Intelligent Information Systems, Vol.16, Nr.1, pag. 41-63 4. Haughey, T., Kelley, C., Oates, J. (Ianuarie, 2006). Is there any database management system which supports temporal databases? www.dmreview.com/ editorial/dmreview/articleid=1045306 5. Snodgrass, R.T. (2000). Developing Time-Oriented Database Applications in SQL, Morgan Kaufmann Publishers, Inc., San Francisco 6. TimeConsult (1998). What are temporal Databases? www.timeconsult.com/temporaldata/ TemporalDB.html