TEHNOLOGII DE INTEGRARE A SISTEMELOR INFORMATICE

Conectarea aplicaţiilor prin stocurile de date este relativ simplă,

apelând la: FTP, utilităţi oferite de SGBD-uri, instrumente ETL (Extract,

Transform and Load), servere de integrare. Multitudinea de instrumente

suport pentru integrare la acest nivel uşurează mult efortul de integrare.

Integrarea orientată pe date se poate realiza prin migrarea datelor

dintr-un sistem informatic în altul sau prin folosirea unor produse software,

care permit accesul la diferite surse de date fără a mai fi nevoie de

extragerea, transportul, transformarea, validarea şi curăţarea datelor din

sistemele sursă şi încărcarea lor în sistemele destinaţie. Migrarea datelor se

poate face către un sistem operaţional (în general către o bază de date) sau

către un sistem suport decizie (adică către un depozit de date). Principalul

standard folosit pentru interschimbul de informaţii este eXtensible Markup

Language (XML), iar cel mai important protocol de comunicaţii bazat pe

acesta şi care stă la baza serviciilor Web este Simple Object Access

Protocol (SOAP).

2.1.Integrarea orientată pe date

In abordarea orientată pe date pentru integrarea aplicaţiilor trebuie ca

schimbul de informaţii să apară între bazele de date (sau proprietari API,

care produc informaţie), ceea ce înseamnă că bazele de date trebuie văzute

76

ca puncte principale de integrare. Soluţiile de integrare orientată pe date pot

fi grupate în trei categorii:

copii multiple ale bazei de date ;

federalizarea datelor;

procesarea interfeţei.

Figura 2.1 Schimb de informaţie între două aplicaţii

2.1.1. Menţinerea unor copii ale datelor

Prin realizarea unor copii ale bazei de date si distribuirea lor la

nivelul aplicatiilor  fiecare aplicaţie poate să aibă propriul stoc dedicat de

date. În orice moment, o parte din surse sunt puţin desincronizate, datorită

întârzierilor inerente în propagarea schimbărilor între sursele de date.

Există 12 modele de mutare a datelor [Teal03]:

mutarea unei copii a datelor;

replicarea datelor;

replicare master-master;

replicare master-slave;

sincronizare la nivel de linie master-master;

replicare snapshot master-slave;

77

capturarea detaliilor tranzacţiilor

replicare incrementală a tranzacţiilor master-slave;

implementarea sincronizării la nivel de linie master-master

utilizând SQL Server;

implementarea replicării snapshot master-slave utilizând SQL

Server;

replicare master-slave în cascadă.

Replicarea datelor este o variantă a copierii datelor, referindu-se la

simpla mutare a datelor între două sau mai multe baze de date. Aceste baze

de date pot avea provenienţe diferite (Figura 2.2) şi pot avea modele

diferite. Cerinţa fundamentală pe care trebuie să o îndeplinească o bază de

date pentru a i se putea replica datele este să ofere o infrastructură pentru

schimbul de date.

Figura 2.2 Replicarea unei baze de date

Multe baze de date, care includ soluţii “middleware” oferă servicii

pentru replicarea datelor. Replicarea prin intermediul serviciilor este

Aplicaţie Aplicaţie Aplicaţie

Baza de date 1

Replicarea datelor

Replicarea datelor Replicarea datelor

Baza de date 2

Baza de date 3

78

realizată prin plasarea unui strat software între două sau mai multe baze de

date. Pe de o parte, datele sunt extrase dintr-o bază de date sau din mai

multe baze de date şi sunt apoi plasate în bazele de date ţintă. Multe dintre

aceste soluţii oferă servicii de transformare precum şi abilitatea de a

modifica schema şi conţinutul astfel încât acestea să aibă sens pentru baza

de date ţintă.

Avantajele replicării bazelor de date sunt simplitatea şi costurile

scăzute. Replicarea este uşor de implementat, iar tehnologia este ieftină.

Din păcate, aceste avantaje sunt eliminate dacă sunt necesare metode ataşate

datelor. În acest caz, trebuie luată în considerare orientarea bazată pe

servicii.

2.1.2 Federalizarea datelor

Federalizarea datelor se referă la integrarea mai multor baze de date

şi a modelelor asociate într-o singură bază de date, cu un view unificat

(Figura 2.3). Practic, federaţiile bazei de date reprezintă bazele de date

virtuale.

Instrumentele pentru federalizarea datelor plasează un nivel

software (middleware) între bazele de date distribuite fizic şi aplicaţiile

care vizualizează datele. Acest nivel conectează bazele de date folosind

interfeţe şi mapează bazele de date fizice într-o bază de date virtuală.

Aplicaţia foloseşte această bază de date virtuală pentru a accesa informaţiile

necesare. Instrumentele pentru federalizarea bazei de date gestionează

colectarea şi distribuirea datelor, pe măsură ce acestea sunt necesare, către

bazele de date fizice.

79

Avantajul folosirii acestui software este că poate lega tipuri

diferite de date într-un model unificat care suportă schimbul de informaţie.

Figura 2.3 Federalizarea datelor

Aceasta este cea mai elegantă soluţie pentru integrarea datelor

deoarece permite accesul la orice bază de date conectată la sistem printr-o

singură interfaţă bine definită. Spre deosebire de replicare, federalizarea

nu necesită modificări ale aplicaţiilor ţintă. Totuşi, schimbări sunt necesare

la nivelul aplicaţiei care susţine software-ul bazei de date conţinută în

federaţie. Acest fapt este datorat interfeţelor diferite care sunt folosite pentru

a accesa un model al bazei de date diferit (baza de date virtuală).

80

2.1.3 Integrarea datelor prin intermediul interfeţelor

Soluţiile de procesare a interfeţei folosesc interfeţe ale unor aplicaţii

bine definite pentru a se axa atât pe integrarea aplicaţiilor pachet, cât şi pe a

celor obişnuite (Figura 2.4). Interesul curent în integrarea de tip Enterprise

Resource Planning (ERP) manifestat de către SAP, PeopleSoft - Oracle a

făcut acest sector cel mai atractiv în ceea ce priveşte integrarea de aplicaţii.

Figura 2.4 Procesarea interfeţei

Producătorii de soluţii ERP susţin soluţiile bazate pe procesarea

interfeţei prin oferirea de adaptori, care să conecteze cât mai multe aplicaţii

obişnuite sau aplicaţii pachet, externalizând informaţia. Aceşti adaptori se

conectează la soluţiile tehnologice care includ tehnologii middleware, dar şi

“screen scrapere”, ca puncte de integrare. Un “screen scaper” este un

instrument care permite PC-urilor să intercepteze datele dintr-un mainframe

(fiind adesea prezentat ca un ecran verde) şi este utilizat pentru a înţelege

mai bine interfaţa grafică. Ecranele mai noi prezintă informaţia în format

HTML, pentru a putea fi accesată dintr-un browser.

81

O integrare eficientă a mai multor tipuri de aplicaţie defineşte

avantajul principal al utilizării produselor de integrare a aplicaţiilor. În doar

câteva zile, este posibilă conectarea unei aplicaţii SAP R/3 la o aplicaţie

Oracle, prin intermediul unei soluţii de procesare a interfeţei care să

gestioneze diferenţele de schemă, conţinut şi semantica aplicaţiei, prin

interpretarea informaţiei interschimbată între sisteme.

Dezavantajul folosirii produselor de integrare bazată pe procesarea

interfeţei este că se acordă atenţie limitată logicii procesului de afaceri, cât

şi metodelor aparţinând sursei sau sistemelor ţintă. În aceste situaţii, se

recomandă folosirea unei abordări orientate pe servicii. Se prognozează că

pe viitor, tehnologia de procesare a interfeţei va fi capabilă să includă şi

metode.

2.2. Standarde utilizate la integrarea datelor

2.2.1. XML, XSLT, ebXML

De la crearea sa, eXtensible Markup Language (XML) a fost

proiectat ca standard pentru interschimbul de informaţie pe Internet. Ca

urmare, aplicabilitatea la integrarea aplicaţiilor este naturală, deoarece XML

oferă un standard robust, uşor de înţeles pentru schimbul de informaţie.

XML poate susţine interschimbul de semantici ale aplicaţiilor şi de

informaţie. Tot acest proces se realizează fără ca aplicaţiile destinaţie să aibă

nevoie de informaţii despre aplicaţiile sursă.

XML oferă un format comun de schimb de informaţie, încapsulând

atât datele cât şi metadatele. Acest format permite aplicaţiilor şi bazelor de

date să comunice fără a avea informaţii una despre cealaltă. Pentru a

82

comunica, sistemul sursă reformatează un mesaj, o informaţie sau o

înregistrare ca un XML-text şi mută acea informaţie într-ul alt sistem, care

ştie să citească XML.

Valoarea XML-ului rezidă din simplitatea lui. Se pot lua cantităţi

mari de informaţie şi se pot consolida într-un document XML ca piese

semnificative, care dau structura şi organizarea informaţiei. (Figura 2.5)

Figura 2.5 XML, reprezentare text simplă a unor date de complexităţi diferite

Blocul de bază al unui document XML este un elementul definit prin

marcatori (tag-uri). Un element are un tag de început şi un tag de final.

Toate elementele dintr-un document XML sunt conţinute de un element

rădăcină XML, care suportă elemente rădăcină sau elemente în alte

elemente, de unde rezultă că poate susţine o structură ierarhică. Numele

83

elementelor descriu conţinutul elementului, iar structura descrie relaţiile

dintre elemente. Un document XML este considerat bine format, dacă poate

fi citit de un parser XML şi dacă formatul său se potriveşte cu specificaţiile

XML. Se pot defini atribute ale elementelor şi descrie caracteristici ale

elementelor în tagul de început. Un parser XML citeşte documente XML şi

extrage datele ce urmează a fi accesate de alt program. Parserul este parte

componentă a nivelului middleware. (Figura 2.6)

Pentru ca aplicaţiile ce folosesc XML să poată fi integrate, ele

trebuie să externalizeze informaţia sub formă de XML. Tehnologia

middleware-XML gestionează extragerea informaţiei din sistemul sursă,

conversia ei în XML şi plasarea informaţiei în sistemul destinaţie, tot

procesul fiind automat şi transparent pentru utilizator. Aşa cum s-a mai

specificat, XML este bazat pe text şi, astfel, o informaţie care în mod

normal poate fi stocată pe 512 KB, se poate mapa într-un fişier XML de 20

ori mai mare, acest fapt reprezentând unul din dezavantajele utilizării XML.

Figura 2.6 Extragerea informaţiei prin parser XML

Legătura între XML şi middleware este clară deoarece tehnologia

middleware realizează partea de transfer efectiv de mesaje, care

84

încapsulează XML şi se asigură că acele mesaje pot fi înţelese de sistemele

destinaţie. Middleware-ul gestionează şi interfeţele cu aplicaţiile sursă şi

destinaţie şi mută informaţia.

XML nu juca până mai recent un rol prea important în domeniul

integrării aplicaţiilor în cadrul aceleaşi companii. Practic, în aceste cazuri

erau alese alte standarde şi metode de integrare din motive de eficienţă.

Totuşi, datorită descentralizării controlului asupra informaţiei, XML devine

din ce în ce mai important. Multe companii, ca Oracle-PeopleSoft şi SAP

folosesc acum XML ca interfaţă nativă pentru sistemele lor. Oracle-

PeopleSoft deja a definit un produs, Open Integration Framework, care

foloseşte XML. Mai mult decât atât, producătorii de sisteme de gestiune a

bazelor de date precum Oracle, Sybase şi Informix, oferă mecanisme, care

permit XML-urilor să citească şi să scrie direct în baza de date.

Rolul major al XML este în domeniul integrării aplicaţiilor între mai

multe companii. Standardele XML oferă valoare suplimentară prin

includerea nivelurilor de metadate comune, care pot exista între unul sau

mai mulţi parteneri membri ai tranzacţiei şi chiar prin includerea

mecanismelor de transformare standard ca XSLT.

Cele mai relevante standarde XML folosite pentru integrarea

aplicaţiilor sunt: RosettaNet, XEDI, BizTalk, Extensible Financial

Reporting Markup Language (XFRML), XML-Schema, XML Query şi XSLT

(tabelul 2.1.).

RosettaNet un cadru pentru interschimb de date şi procese cu e-business.XEDI se referă la o specificaţie, care descrie cum trebuie mapat un

EDI tradiţional la un XML şi inversBizTalk este fondat de Microsoft şi defineşte un standard XML pentru

XML-uri bazate pe mesaje şi metadate. Microsoft oferă şi un server BizTalk pentru a susţine acest standard.

XFRML este un standard definit de American Institute of Certified 85

Public Accountants pentru a defini standarde XML pentru informaţii financiare.

XML-Schema

este un grup de lucru al W3C, care descrie un mecanism pentru determinarea structurii unui document XML

XML Query

Este un alt grup W3C, care creează un set de operaţii comune şi sintaxă pentru a accesa date stocate XML

Tabelul 2.1. Standarde XML pentru integrarea aplicaţiilor

XSLT este un limbaj proiectat să transforme un document XML

într-un altul, modificând atât schema, cât şi conţinutul procesului.

Documentele XML sunt ca nişte mesaje. Fiecare aplicaţie are un set unic de

semantici, iar documentele care circulă între aplicaţii trebuie să poată fi

transformate (Figura 2.7). Atât structurile de date, cât şi conţinutul sunt

necesar să fie corecte din punct de vedere semantic pentru a fi încărcate în

aplicaţia ţintă. Dacă datele nu au formatul necesar, atunci operaţia de

actualizare nu va reuşi.

Figura 2.7 Transformarea documentelor XML prin XSLT

86

În plus, XSLT poate realiza şi alte tipuri de procesare de text şi

operaţii de transformare, care includ crearea formatelor de date standard

bazate pe text ca PDF-uri sau alte formate.

Transformarea unui document XML folosind XSLT necesită doi

paşi. Primul pas constă într-o transformare structurală, unde datele sunt

transformate, de la o structură de intrare la o structură de ieşire. Acest pas

implică selectarea datelor, gruparea lor, sortarea lor sau agregarea lor în

funcţie de necesităţile transformării. De exemplu, în cadrul unui document

XML se poate face conversia de la dolari americani la franci francezi.

Această transformare este bazată pe o rată de conversie valutară, fie pe o

valoarea statistică fie pe o valoare citită dintr-o bază de date aflată la

distanţă.

Electronic Business using eXtensible Markup Language

(ebXML) este un produs al colaborării dintre UN/CEFACT şi OASIS.

Acest standard a fost construit pe baza XML, ca şi alte standarde Internet şi

servicii Web. Scopul său este crearea unei infrastructuri pentru comerţul

electronic bazat pe informaţie şi procese. ebXML este considerat un

standard bun, fiind folosit de cei care automatizează B2B.

Unicitatea ebXML-ului este dată de completitudinea acestuia,

adresând probleme ca: procese, managementul tranzacţiilor, semantici,

notaţii, securitate, acorduri, standarde legate de transferul de informaţie şi

standarde legate de structurarea informaţiei.

Cu toate acestea, completitudinea ebXML-ului poate fi considerată

un factor ce limitează, din cauza duratei pe care o necesită pentru a se plia

pe un domeniu.

87

Standardul ebXML a fost creat pentru a înlocui EDI sau alte

standarde folosite în comerţul electronic. Acesta este un sistem bazat pe

mesaje XML pentru schimbul de informaţie şi poate conţine un depozit

pentru a permite accesul simultan la informaţie. Sistemul de mesaje suportă

orice tip de date, tranzacţii EDI şi informaţie binară. Mai mult decât atât,

ebXML suportă acorduri de tranzacţionare între parteneri – o funcţie

fundamentală a subsistemelor partener EDI-ebXML poate fi folosit astfel

pentru a reprezenta acordurile de servicii de afaceri.

Ca şi alte standarde (ebXML-ul nu este un produs) vine cu un set de

reguli, care permit producătorilor de aplicaţii şi integrare de aplicaţii să-si

proiecteze produsele pentru a susţine acest standard.

2.2.2. SOAP, WSDL, UDDI

Simple Object Access Protocol (SOAP) defineşte un format XML

bazat pe mesaje, care este folosit de aplicaţiile bazate pe servicii Web pentru

a comunica şi interopera între ele pe Web (figura 2.8.). SOAP este un

standard pentru codificarea mesajelor în XML şi care poate apela funcţii în

alte aplicaţii. Este analog cu Remote Procedure Calls (RPC) folosit de

tehnologii ca DCOM sau CORBA, dar elimină o parte din complexitatea

utilizării acestor interfeţe. SOAP permite aplicaţiilor să apeleze funcţii din

alte aplicaţii, care rulează pe altă platformă hardware, indiferent de sistemul

de operare şi limbajul de programare.

88

Figura 2.8 SOAP oferă mecanisme de comunicare între client şi server

Web Service Description Language (WSDL) este o colecţie de

metadate despre XML bazat pe servicii, folosită pentru descrierea scopului

unei afaceri şi a modului de accesare electronică a serviciilor acestora. Bazat

pe SOAP, WSDL specifică procedurile pentru descoperirea informaţiei

tehnice şi funcţionale despre serviciile Web pe Internet.

Un document WSDL este descris de un număr de elemente:

definiţii tip, pentru elementele de date (în mod normal, utilizând

XML Schema);

definiţii de mesaje, care comprimă unul sau mai multe elemente

de date;

definiţii ale operaţiilor, care reprezintă descrieri abstracte ale

acţiunilor care pot fi suportate de serviciu, şi care definesc tipul

mesajului: de intrare sau de ieşire;

89

definiţii PortType;

definiţii de conectare, care descriu conexiunea între PortType şi

protocoale (SOAP, HTTP, GET/POST);

definiţii de servicii.

Ca urmare, se poate spune că WSDL oferă o abordare standard

serviciilor Web. De asemenea, WSDL oferă un mecanism automat de

generare a proxy-urilor pentru serviciile Web folosind un limbaj standard.

Acest standard este analog IDL (Interface Definition Languages) şi se

găseşte atât în COM cât şi în CORBA. Cu alte cuvinte, este un simplu

contract între client şi server.

WSDL defineşte o gramatică XML pentru descrierea serviciilor de

reţea ca o colecţie de puncte finale de comunicaţie, care pot face transfer de

informaţie. Definirea serviciilor WSDL oferă o modalitate pentru

automatizarea comunicării între aplicaţii (Figura 2.9).

90

Figura 2.9 Definirea serviciilor prin WSDL

Universal Description, Discovery and Integration (UDDI) este un

standard pentru catalogarea şi publicarea descrierilor WSDL asociate

serviciilor Web, care sunt disponibile pe Internet. Într-un mod asemănător

căutării informaţiei în Pagini Aurii sistemele de comerţ pot căuta în registrul

UDDL serviciile Web, apoi pot prelua parametrii de interacţiune şi pot

interacţiona efectiv cu serviciile Web găsite folosind SOAP.

Specificaţiile UDDI ţintesc să definească un mecanism comun

pentru publicarea şi căutarea informaţiei prin servicii Web. Creatorii UDDI

(IBM, Microsoft, Ariba) încearcă să creeze un echivalent pe Internet pentru

Pagini Aurii. Acum este disponibilă pe piaţă prima generaţie de specificaţii.

Figura 2.10 UDDI

2.3. Tehnologii informatice de integrare a datelor

91

2.3.1. Baze de date centralizate şi distribuite

Baza de date este un ansamblu de colecţii de date în memoria

externă, cu următoarele caracteristici:

este organizat, pe trei niveluri (conceptual, logic, fizic);

este structurat, conform unui model de date;

este coerent, prin restricţiile de integritate şi protecţia datelor;

are o redundanţă minimă şi controlată, prin implementarea unui

model de date şi prin aplicarea unei tehnici de proiectare;

este accesibil mai multor utilizatori în timp util. [VELI01]

Bazele de date sunt manipulate cu ajutorul sistemelor de gestiune a

bazelor de date, care constituie ansamblul de programe prin care se asigură

gestionarea şi prelucrarea complexă a datelor. Cel mai răspândit model de

baze de date este cel relaţional, în care datele sunt memorate în tabele. Pe

lângă tabele, o bază de date relaţională mai poate conţine: indecşi, proceduri

stocate, declanşatori, utilizatori şi grupuri de utilizatori, tipuri de date,

mecanisme de securitate şi de gestiune a tranzacţiilor etc. Alte modele de

baze de date sunt: modelul ierarhic, modelul reţea, modelul obiectual-

relaţional, modelul orient obiect.

O bază de date poate fi folosită pentru integrarea diverselor aplicaţii.

În aceasta pot fi încărcate date diverse provenite din diverse surse (ASCII,

EXCEL, XML, FOX, ACCESS etc.).

O bază de date distribuită este o bază de date care nu este

localizată într-o singură locaţie fizică, ci este dispersată într-o reţea de

calculatoare interconectate, putând fi accesată de mai mulţi utilizatori

concurenţi. Sistemul de baze de date distribuite trebuie gestionat astfel încât 92

distribuirea, concurenţa şi eventualele eşecuri să fie transparente,

asigurându-se că operaţiile de citire (cererile) şi operaţiile de scriere

(actualizările) se execută astfel încât să nu apară nici o diferenţă faţă de

situaţia unei baze de date cu un singur utilizator [TRAI82]. Transparenţa din

toate aceste puncte de vedere poate fi destul de scumpă, iar în practică ea

este realizată doar în măsura în care permite obţinerea unor performanţe

acceptabile.

Colecţiile de date pot fi distribuite pe mai multe calculatoare, care se

pot afla în aceeaşi locaţie fizică sau în locaţii fizice diferite. O bază de date

este distribuită sub formă de partiţii/fragmente distincte, care pot fi replicate

pe mai multe noduri din reţea. Pe lângă fragmentare şi replicare, există şi

alte tehnici de proiectare a bazelor de date distribuite, alegerea uneia dintre

acestea realizându-se în funcţie de nevoile afacerii şi de

sensibilitatea/confidenţialitatea datelor care vor fi stocate în baza de date.

Sistemele distribuite se folosesc în mai multe domenii ale

informaticii (sisteme de baze de date, reţele de calculatoare, sisteme de

operare etc.). Totuşi, toate sistemele distribuite, indiferent de tipul lor, au

câteva caracteristici şi obiective de realizare comune. Aceste aspecte

comune le prezentăm în paragraful de faţă.

Caracteristicile principale ale sistemelor distribuite

1. Suport pentru partajarea resurselor: aceleaşi resurse sunt folosite de

mai mulţi utilizatori. Acest lucru se realizează prin două modele:

modelul client – server, în care unul sau mai multe servere

gestionează baza de date şi rezolvă cererile transmise de clienţi. În

acest model există două tipuri de procese:

o procesele client, care execută sarcini care solicită de la server

resurse partajate;93

o procesele server, care activează resursele de un anumit tip şi

întoarc răspunsul.

modelul bazat pe obiecte, în care, într-o execuţie de program, fiecare

entitate este văzută ca un obiect cu interfaţă publică de acces. De

asemenea, fiecare resursă partajată este văzută ca un obiect.

2. Deschiderea: Sistemul poate fi extins, în orice moment, pe diferite căi.

În acest sens, sistemul deţine: mecanisme de comunicare interprocese,

interfeţe publice pentru acces la resurse partajate şi resurse, care sunt

eterogene.

3. Concurenţa şi paralelismul: În acelaşi timp, mai mulţi utilizatori,

folosesc în mod eficient aceleaşi resurse. Aspectele care trebuie

implementate de sistem sunt: simultaneitate privind mai mulţi utilizatori

şi mai multe procese, să separe activităţile de utilizatori, să asigure

independenţa proceselor faţă de resurse şi de activităţi.

4. Scalabilitate: Sistemul acţionează efectiv şi eficient pe diferite scale

(datorită eterogenităţii resurselor).

5. Toleranţă la accidente: Sistemul se bazează pe redundanţa hardware şi

pe acoperirea software.

6. Transparenţa: Se referă la gradul de independenţă între componentele

sistemului (resurse, operaţii, utilizatori etc.), la funcţionare. În asigurarea

transparenţei se ţine cont de: separarea componentelor sistemului,

necesitatea comunicaţiei şi de tehnici de integrare şi management.

Regulile lui Date

C.J. Date a întocmit 12 reguli conform cărora se poate stabili dacă un

SGBD este distribuit sau nu. Ca o sinteză a regulilor, se poate afirma că

94

distribuirea datelor nu trebuie să afecteze în nici un fel utilizatorii (SGBD-ul

va asigura o transparenţă totală a distribuirii datelor).

R1. Autonomia locală: fiecare nod are control local asupra datelor şi este

independent de celelalte noduri din punct de vedere al funcţiilor de bază:

securitate, controlul concurenţei, backup şi recuperare.

R2. Independenţa faţă serverul central: fiecare nod trebuie să acţioneze

independent, fără să depindă de un server central sau un alt nod.

R3. Continuitatea: activitatea într-un sistem distribuit se desfăşoară fără

întreruperi pentru întreţineri sau reparaţii.;

R4. Transparenţa localizării: nici un utilizator/program are nevoie să ştie

unde şi cum sunt amplasate datele folosite.

R5. Independenţa fragmentării: SGBDD va trebui să poată reconstrui

automat, în orice moment, o colecţie de date din fragmentele sale.

R6. Independenţa replicării: utilizatorii/programele nu trebuie să ştie dacă

datele au fost replicate şi cum anume.

R7. Interogări distribuite: o interogare poate fi executat pe orice nod din

reţea care conţine date utile execuţiei cererii. La răspunsul interogării pot să

participe mai multe noduri, fără ca beneficiarul să fie conştient de acest

lucru.

R8. Tranzacţii distribuite: o tranzacţie poate să acceseze şi să modifice date

din mai multe noduri, fără ca beneficiarul să fie conştient de acest lucru.

R9. Independenţa faţă de hardware: nodurile pe care se găsesc datele pot fi

calculatoare de diferite tipuri şi puteri.

R10. Independenţa faţă de software: nu trebuie să aibă importanţă

sistemele de operare care există pe noduri (eterogene).

95

R11. Independenţa faţă de reţea: BDD şi SGBDD trebuie să poată fi

implementate pe orice platformă de reţea corespunzătoare, iar diferitele

protocoale utilizate în reţea, nu trebuie să afecteze funcţionarea BDD.

R12. Independenţa faţă de SGBD: la nivel de nod local pot “rula” diferite

SGBD-uri.

Tehnicile prin care un SGBDD, asigură distribuirea datelor de bază

sunt: fragmentarea, replicarea, mixtă, încărcarea..

Figura 2.11 Tehnici de distribuire

a) Distribuirea prin fragmentare este operaţia de descompunere logică a

colecţiilor globale în părţi disjuncte numite fragmente, utilizând

operatori speciali.

96

Pentru a realiza fragmentarea SGBDD respectă anumite reguli şi

metode.

REGULILE ce trebuie respectate la fragmentare:

completitudinea semnifică faptul că întreaga colecţie globală trebuie

descompusă în fragmente. Rezultă că orice înregistrare dintr-o

colecţie globală trebuie să se regăsească într-un fragment;

reconstrucţia semnifică faptul că orice colecţie globală trebuie să

poată fi recompusă, oricând, din fragmentele sale;

disjuncţia semnifică faptul că fragmentele în care se descompune o

colecţie globală trebuie să fie exclusive. Rezultă că o înregistrare din

colecţia globală nu poate să se regăsească în două sau mai multe

fragmente ale sale.

METODELE ce pot fi utilizate la fragmentare:

orizontală, conform căreia descompunerea colecţiei globale în

fragmente se face prin extragerea unui set de înregistrări, păstrându-

se toate câmpurile colecţiei iniţiale. Rezultă că fiecare fragment are

un număr de înregistrări mai mic decât al colecţiei globale din care

provine, dar aceeaşi structură de date;

verticală, conform căreia descompunerea colecţiei globale în

fragmente se face prin extragerea unui set de câmpuri, păstrându-se

toate înregistrările colecţiei iniţiale. Rezultă că fiecare fragment are

o structură de date subset din cea a colecţiei globale din care

provine, dar acelaşi număr de înregistrări;

mixtă, conform căreia descompunerea colecţiei globale în fragmente

se face prin aplicarea succesivă a metodelor orizontală şi verticală.

97

b) Distribuirea prin replicare este operaţia de stocare a unor porţiuni

dintr-o bază de date, sub formă de copii, pe mai multe calculatoare

(noduri) dintr-o reţea.

Dacă un utilizator actualizează o copie locală atunci SGBDD

actualizează automat toate copiile acelor date.

Pentru a putea realiza distribuirea prin replicare un SGBDD

utilizează anumite metode: date nereplicate, date replicate parţial, date

replicate total.

METODELE ce pot fi utilizate la replicare:

date nereplicate înseamnă că SGBDD alocă spaţiu pentru anumite

date, pe o singură copie, pe un anumit calculator din reţea.

Caracteristicile acestei metode sunt: redundanţa este minimă,

concurenţa accesului la date este maximă, timpul de actualizare este

mic şi timpul de regăsire este mare;

date replicate parţial înseamnă că SGBDD alocă pentru o parte din

date o singură copie pe un calculator, iar pentru o altă parte din date

mai multe copii pe mai multe calculatoare din reţea. Caracteristicile

acestei metode sunt: redundanţa creşte, concurenţa accesului la date

scade, timpul de actualizare este mediu şi timpul de regăsire este

mediu;

date replicate total, înseamnă faptul că SGBDD alocă pentru

întreaga BD mai multe copii pe diversele calculatoare din reţea.

Caracteristicile acestei metode sunt: redundanţa este maximă,

concurenţa accesului la date este minimă, timpul de actualizare este

mare şi timpul de regăsire este mic.

98

c) Distribuirea mixtă este operaţia de aplicare succesivă a

fragmentării şi replicării pentru aceeaşi colecţie globală de date. Această

tehnică preia avantajele celorlalte două, dar este mai greu de implementat.

d) Distribuirea prin încărcare este operaţia de copiere periodică a

întregii baze de date centralizate sau a unei porţiuni din ea pe noduri locale.

Este cea mai simplă tehnică şi se foloseşte atunci când datele sunt stabile

sau atunci când nu toţi utilizatorii trebuie să aibă acces la datele de ultimă

oră.

2.3.2. Depozite de Date

Un depozit de date furnizează o sursă integrată şi centralizată de

date, aparte faţă de sistemul tranzacţional, care conţine datele esenţiale

despre activitatea companiei din multitudinea de surse de date existente.

Rapoartele obţinute pe baza acestor date sunt utilizate ca un instrument de

analiză strategic şi competitiv. Analizele rapide şi corecte pot influenţa

deciziile privind evoluţia organizaţiei pe termen mediu şi lung.

O definiţie a depozitelor de date formulată de către Consiliul OLAP

este următoarea [OLAP95]:

“Un depozit de date reprezintă o stocare centralizată a datelor

detaliate provenite din toate sursele relevante din cadrul unei

organizaţii şi permite interogarea dinamică şi analiza detaliată a

tuturor informaţiilor.”

Spre deosebire de sistemele operaţionale, structurile de date într-un

depozit de date sunt optimizate pentru o regăsire şi o analiză rapidă. Datele

99

sunt istorice şi sunt actualizate la intervale regulate de timp, în funcţie de

cerinţele de raportare.

Definiţia lui William Inmon, cunoscut drept părintele acestui

concept (de altfel deţine şi trademark-ul pentru datawarehouse) este extrem

de concisă: “un depozit de date este o colecţie de date orientată pe subiecte,

integrată, având istorice şi nevolatile destinată sprijinirii procesului de luare

a deciziilor manageriale” (“A data warehouse is a subject-oriented,

integrated, time-variant and nonvolatile collection of data in support of

management's decision making process”) [INMO96]

În viziunea lui Ralph Kimball [KIMB96] depozitul de date oferă

acces la datele organizaţionale, datele obţinute sunt consistente şi pot fi

separate sau combinate în funcţie de fiecare dimensiune sau aspect al

afacerii. Depozitul de date include, de asemenea un set de instrumente

pentru interogare, analiză şi prezentare a informaţiilor; reprezintă locul în

care sunt publicate datele folosite. Calitatea datelor conţinute în depozit

reprezintă o premiză pentru reingineria afacerii.

După Barry Devlin [DEVL97], un depozit de date înseamnă o

stocare a datelor, unitară, completă şi consistentă, obţinută dintr-o varietate

de surse, disponibilă utilizatorilor finali într-un mod uşor perceptibil şi

utilizabil în contextul afacerii.

Sam Anahory [ANDE97] subliniază finalitatea depozitelor de date,

precizând că un depozit de date include datele şi procesele manageriale care

fac informaţiile disponibile, permiţând managerilor să ia decizii corect

fundamentate.

Există o serie de firme binecunoscute care şi-au adus contribuţia în

definirea, dezvoltarea şi popularizarea tehnologiilor de data warehouse

precum: IBM, Software AG, Oracle, Microsoft, Prism Solution etc.100

Creşterea volumului de informaţii, precum şi perfecţionarea

software-ului de exploatare a acestuia, au condus la o nouă calitate a

folosirii datelor prin analize care pot releva conducerii organizaţiei

informaţii greu sau chiar imposibil de obţinut pe alte căi. Se pot obţine astfel

informaţii privind preferinţele clienţilor, profilul lor, distribuţia etc.

Astfel se pot furniza conducerii date, cum ar fi de exemplu: în ce

regiune a ţării se vinde mai bine un anumit produs, care sunt preferinţele

unui anumit segment de piaţă etc.

Este evident că astfel de informaţii nu se pot obţine decât folosind

anumite prelucrări, cum ar fi analiza multidimensională, anumite metode

statistice de prognoză sau alte metode matematice aplicate unui volum

foarte mare de date. Aceste metode matematice reclamă folosirea unui

software specializat deosebit de complex. Analiza matematică a datelor

aflate în astfel de depozite de date a căpătat denumirea de data mining

(minerit al datelor). Din volumul foarte mare de date se extrag numai datele

relevante, celelalte fiind ignorate. Pentru astfel de aplicaţii datele trebuie

bine organizate şi indexate pentru o uşoară regăsire si utilizare.

Pentru a ne da seama de dimensiunile fenomenului voi oferi câteva

cifre semnificative [VILA97]. Un depozit de date este alcătuit din baze de

date conţinând intre 1 şi peste 10 terrabyte, aceste cifre neavând decât un

caracter orientativ. Există astfel şi depozite de date conţinând zeci de

terrabyte. Crearea unui astfel de depozit costă în jur de 3 milioane $. Din

acest cost, o treime o reprezintă serviciile profesionale. O altă treime se

cheltuieşte pentru software-ul necesar extragerii, prelucrării, depozitării şi

analizării datelor, iar ultima treime este destinată sistemelor hardware

necesare şi stocării datelor. De obicei, depozitele de date îşi dublează

dimensiunile în primele 12 până la 18 luni. Această creştere exponenţială 101

poate fi pe de o parte semnul sigur al succesului implementării depozitelor

dar, pe de alta parte, poate deveni o problemă, dacă sistemele nu sunt

construite de la început suficient de elastice şi de deschise.

Cheltuieli cu serviciile

profesionaleCheltuieli cu

software-ul pentru extragerea, prelucrarea,

depozitarea şi analiza datelor Cheltuieli cu

sistemele hardware şi

stocarea datelor

Figura 2.12. Structura cheltuielilor pentru crearea unui depozit de date

Din cele de mai sus rezultă importanţa deosebită a flexibilităţii

impuse sistemelor care adăpostesc asemenea depozite de date. În acest caz,

flexibilitate înseamnă o conectivitate la nivelul întregii organizaţii, astfel

încât servere provenind de la furnizori diferiţi să se poată conecta simultan

la depozitul deja existent. Este, de asemenea, deosebit de important să se

aleagă o arhitectură care să se adapteze uşor la modificările de performanţe,

capacitate şi conectivitate. Procesele de configurare, optimizare si

administrare a sistemului, inclusiv procedurile de salvare - restaurare,

precum si păstrarea în tot acest timp a funcţionalităţii sistemului pot deveni

operaţii extrem de dificile dacă trebuie repetate la fiecare adăugare a unor

noi servere în sistem.

Pentru a evita aceste probleme, se poate alege o cale de mijloc şi se

poate crea un sub-depozit care să conţină numai datele relevante pentru

102

analiza necesară. Astfel de sub-depozite sunt numite data marts şi pot fi

făcute să funcţioneze pe configuraţii mai modeste decât depozitele de date.

Un astfel de data mart este un depozit de date specific unui anumit

subset de cerinţe sau unui anumit departament din cadrul organizaţiei. În

timp ce un depozit de date conţine datele care pot fi utilizate pentru a

răspunde oricărei întrebări privind afacerile unei companii, un data mart

conţine datele pertinente unui anumit compartiment al companiei.

Departamentele pot folosi în comun datele lor, conectând împreună data

mart-urile aferente diferitelor compartimente ale companiei şi formând

astfel o infrastructură specifică pe baza căreia se poate crea un sistem de

suport al deciziei mai uşor de construit şi mai elastic.

Un data mart care poate utiliza serverele existente, structura

informaţională existentă (un LAN sau un Intranet) cu mai puţin de 500 GB,

costă ai puţin de 1 milion de dolari şi se implementează,de obicei, în 90 de

zile. Companiile de software au început deja să ofere pe piaţă produsele

necesare pentru a construi aceste data marts.

Rolul unui depozit de date este de a oferi o imagine coerentă asupra

datelor relative la activitatea unei organizaţii şi a contextului în care acesta

acţionează. Utilizarea acestei colecţii poate consta din extragerea unor

rapoarte (la cerere sau cu o anumită periodicitate), extragerea unor date

pentru a fi utilizate de aplicaţiile de birotică (programe de calcul tabelar,

procesoare de text, programe de prezentare etc.), dar mai ales pentru a fi

utilizate de către aplicaţii specializate de analiză. Acestea ar putea fi

împărţite în două categorii:

instrumente de analiză on-line (OLAP - On Line Analytical

Processing - aplicaţii axate pe analiză multidimensională);

103

instrumente pentru "minerit" în date (data mining - aplicaţii

axate pe descoperirea unor şabloane semnificative în colecţii

de date).

2.3.2.1. Caracteristici ale depozitelor de date

Datorită obiectivelor impuse de utilizarea depozitelor de date în

analiză, se desprind câteva caracteristici mai importante pe care acestea le

deţin:

depozitul de date asigură accesul la datele organizaţiei. Accesul

trebuie să fie imediat, la cerere şi să fie performant. Nu este

acceptabil ca acest acces să fie realizat prin intermediari sau să

fie prea lent. De asemenea, accesul presupune existenţa unor

utilitare care să fie foarte uşor de folosit;

datele dintr-un depozit de date trebuie să fie consistente.

Consistenţa presupune faptul că atunci când două persoane

solicită acelaşi set de informaţii să primească aceleaşi date, chiar

dacă ele au fost cerute la momente de timp diferite. Dacă datele

nu au fost complet încărcate atunci utilizatorul va fi avertizat cu

privire la acest lucru şi este sfătuit să aştepte până ce vor fi

complet încărcate;

datele într-un depozit de date pot fi separate şi combinate pentru

a oferi un acces cât mai rapid şi un timp de răspuns cât mai mic

sistemului;

104

depozitele de date nu reprezintă doar datele, ci şi un set de

utilitare pentru a interoga, analiza, prezenta informaţiile;

datele din depozite sunt utilizate direct în analize, fără alte

prelucrări suplimentare. Datele nu sunt doar acumulate la un loc

şi păstrate ci sunt asamblate dintr-o varietate de surse, sunt

corectate de erori, li se asigură calitatea necesară şi abia apoi

devin utilizabile;

calitatea datelor din depozitele de date este un factor

determinant pentru procesul de reculegere a datelor. Se întâlneşte

frecvent situaţia în care datele sunt de bună calitate, dar nu sunt

colectate în întregime sau au un caracter opţional.

Pentru obţinerea acestor caracteristici este necesară redundanţa

datelor. Dacă în sistemul operaţional redundanţa este eliminată (prin

procesul de normalizare) pentru a evita anomaliile de actualizare, în

depozitul de date redundanţa este creată în mod intenţionat (prin

denormalizare şi sumarizare) pentru a permite un acces mai rapid la date.

Raţiunea pentru care este creat depozitul de date este, în cele din

urmă, integrarea datelor. Datele sunt adunate pentru a răspunde nevoilor

informaţionale ale întregii organizaţii, asigurând faptul că rapoartele

generate pentru diversele compartimente vor conţine aceleaşi rezultate.

Sistemul operaţional este adesea imposibil de folosit pentru analiză, fiind de

cele mai multe ori format din subsisteme semi-independente, create la

momente diferite, de echipe diferite, în maniere diferite.

Integrarea datelor în cadrul depozitului de date se referă la diferite

aspecte:

modalităţi unice de codificare, sistem de unităţi de măsură

consistente, 105

sistem stabil de reprezentare fizică a datelor,

convenţii clare privind modul de reprezentare a datelor

calendaristice,

convenţii unice privind denumirile datelor.

2.3.2.2. Arhitectura depozitelor de date

Arhitecturi de bază aunui depozit de date presupune încărcarea

datelor din una sau mai multe surse, utilizatorii acceseazâ în mod direct

depozitul de date. Dar arhitectura depozitelor de date poate varia în funcţie

de situaţia specifică a fiecărei organizaţii.

O arhitectură complexă presupune existenţa unui sistem de

purificare şi integrare a datelor precum şi a mai multor sisteme de tipul data

mart proiectate pentru compartimente ale întreprinderii. Figura următoare

prezintă un sistem complex de datawarehouse:

106

Figura 2.13 Depozit de date cu arhitectură complexă

Din punct de vedere funcţional, în cadrul unui depozit de date pot

fi identificate trei niveluri distincte de realizare:

1) Modulul operaţional este reprezentat de datele instituţiei care

sunt, de obicei, păstrate în diverse forme, în fişiere sau baze de

date şi prelucrate de SGBD-uri diferite. Aceste date pot proveni

de la aplicaţii sau de la sisteme distribuite din cadrul companiilor

cum ar fi sisteme de gestiune a comenzilor, de eliberare a

facturilor, de contabilitate financiară. Indiferent de originea lor,

datele trebuie să fie colectate şi aduse într-o formă consistentă

pentru a putea fi folosite. Transformarea datelor presupune un

proces de extragere, condiţionare, curăţare, fuziune, validare şi

încărcare Acest proces de transformare a datelor reprezintă

Interogari Interogari

DataWarehouse

DataWarehouse OLAP OLAP

Data MiningData Mining

RapoarteRapoarte

Surse de date

ETLETL

Instrumente BI

Stocare centralizata

Stocare centralizata

Data Marts

Depozitul de date

FisiereBaze de dateSurse externe

107

baza pe care se construieşte un depozit de date consistent, de

înaltă calitate..

2) Modulul central al depozitului de date este reprezentat de

SGBD şi de serverul pe care acesta rulează şi de modul în care

este implementat depozitul. Există în acest moment două modele

de implementare:

a. implementarea unui sistem distribuit, descentralizat unde

datele sunt păstrate în unităţi independente (Independent

Data Marts), fiecare conţinând datele relevante pentru un

anumit aspect al operaţiilor unei instituţii;

b. implementarea unei surse de date unice, centralizate şi

integrate la care au acces utilizatorii din toate

departamentele unei instituţii.

3) Modulul strategic, de afaceri este nivelul la care datele sunt

prezentate analistului pentru interpretare. Prin folosirea

diferitelor unelte de acces la informaţie şi a tehnologiilor data

mining disponibile, utilizatorii pot obţine informaţii care îi vor

ajuta în procesele de stabilire a strategiei firmei. Instrumentele de

cereri grafice, prezentările, rapoarte scrise, browser-ele Web,

instrumente de vizualizare a datelor, toate aparţin acestui nivel.

Interpretarea uzuală constă în reprezentarea tabelară sau grafică a

datelor. Valoarea finală a unui depozit de date este determinată

de avantajele pe care le oferă utilizatorului în diferite procese de

luare a deciziilor şi analiză. Aplicaţiile suport de decizie ale

clienţilor, care ne dau noi informaţii despre bugete, prognoze,

recomandări cu privire la alocarea resurselor şi multe altele se

află în modulele data marts la acest nivel al arhitecturii. 108

Utilizatori IT

Date operationale

Secventiale Ne-relationale Relationale Externe

Transformarea datelor Incarcare Filtrare Conditionare

Depozitul de date

Replicare si distribuire

Data Marts

Cunoastere/Data Mining

Utilitare pentru accesarea informatiilor

Utilizatori finali

Modulul Operational

Modulul Central

Modulul Strategic

Figura 2.14 Modulele funcţionale ale unui depozit de date

Din punct de vedere al ariei de cuprindere, se întâlnesc trei modele

de depozite de date:

1. Depozitul central al organizaţiei (Enterprise Warehouse)

colectează toate informaţiile despre subiectele care privesc

întreaga organizaţie, integrând date din surse eterogene,

provenite din sisteme tranzacţionale diferite. El furnizează un

volum extins de date. De regulă, conţine date detaliate, dar şi

date agregate, iar ca ordin de mărime porneşte de la câţiva

gigabytes până la sute de gigabytes, terrabytes sau mai mult. Un

depozit de date de întreprindere poate fi implementat pe servere

puternice UNIX sau pe platforme cu arhitecturi paralele. În acest

109

caz, cheltuielile pentru modelare sunt mai mari şi sunt necesari

ani de zile pentru proiectare şi realizare [RYAN99].

2. Data mart-ul conţine un subset al volumului de date din

organizaţie, specific unui grup de utilizatori sau departament.

Domeniul este limitat la subiecte specifice. Datele conţinute în

data mart sunt, de obicei, agregate. În mod curent, data mart-

urile sunt implementate pe servere departamentale mai ieftine

care se bazează pe UNIX sau Windows 2000/2003. Un data mart

poate fi considerat un subansamblu al unui depozit de date mai

uşor de construit şi întreţinut şi mai puţin scump

[INMO99].Ciclul de implementare al unui data mart este mai

curând măsurat în săptămâni decât în luni sau ani.

3. Depozitul virtual (Virtual warehouse) este un set de viziuni

(views) asupra bazelor de date relaţionale. Pentru eficienţa

procesărilor interogărilor, unele din viziunile de agregare pot fi

materializate. Un depozit virtual este uşor de construit, dar

problema extragerii şi prelucrării datelor revine în mod exclusiv

serverului de baze de date, ceea ce poate conduce la un timp de

prelucrare mare, însă se elimină necesitatea stocării datelor într-

un depozit real [HOLL00].

2.3.3. Migrarea datelor

"Migrare sau reproiectare?" este una din primele întrebări când se ia

în considerare migrarea către o nouă bază de date. Uneori, simpla migrare a

bazei de date nu este suficientă, ci este necesară reproiectarea întregului

110

sistem informatic. Această situaţie apare când procesele interne ale firmei s-

au schimbat în aşa măsură încât nu mai pot fi acoperite de sistemul existent,

iar efortul de adaptare a acestuia nu se justifică economic.

Avantajele pe care le conferă reproiectarea sistemului informatic

sunt:

posibilitatea de a începe de la zero şi a elimina slăbiciunile

structurale;

adoptarea de noi tehnologii;

crearea unei fundaţii proaspete pentru noul sistem

Reproiectarea sistemului informatic crează însă şi o serie de

neajunsuri:

analiza, proiectarea şi implementarea unui nou sistem solicită mult

timp şi resurse fiind o investiţie importantă. De cele mai multe ori,

departamentul de IT însărcinat cu realizarea noului sistem nu poate

să întreţină şi vechiul sistem în acelaşi timp;

este posibil ca noul sistem să fie mai puţin funcţional decât vechiul,

anumite funcţii putând fi uitate.

Nu există un răspuns facil la întrebarea "Migrare sau reproiectare?".

Fiecare caz trebuie analizat individual prin prisma avantajelor şi

dezavantajelor. Alegerea poate fi însă şi una combinată: reproiectare şi

migrare parţială sau reproiectarea sistemului după încheierea migrării pe

noile echipamente.

Schimbarea bazei de date nu este doar un simplu proces de transfer

de date, ci implică şi conversia schemei bazei de date (definiţii de tabele,

viziuni, restricţii de integritate etc.), cât şi a funcţiilor, procedurilor şi

pachetelor stocate în baza de date. Principalii factorii ce trebuie luaţi în

considerare când se migrează la o altă bază de date:111

1. Diferenţele de sintaxă SQL între principalele SGBD-uri;

2. SGBD-urile de top precum Oracle, SQL Server şi DB2 pun la

dispoziţie dezvoltatorilor posibilitatea de integra în baza de date

diferite restricţii de integritate cât şi algoritmi. Toate aceste elemente

şi obiecte sunt foarte importante pentru funcţionarea corectă a

aplicaţiilor şi dacă baza de date sursă le conţine trebuie să ne

asigurăm că şi baza de date destinaţie le suportă şi le putem converti;

3. Bazele de date pot conţine sute sau chiar mii de obiecte (tabele,

viziuni, proceduri). Din această cauză se recomandă folosirea unui

asistent de migrare, care să automatizeze cele mai multe sarcini, iar

în sarcina administratorului bazei de date, să rămână doar corecţii

minore şi de fineţe. O altă problemă este şi interdependenţa dintre

obiectele bazei de date. Aproape orice procedură face referiri la

tabele, viziuni sau la alte proceduri, iar această interdependenţă

trebuie menţinută şi după migrare. Din această cauză, dacă spre

exemplu numele unei tabele din Oracle este un nume rezervat în

MySQL acesta va trebui schimbat, sau pus între ghilimele şi făcută

modificarea în toate viziunile, funcţiile/ procedurile/pachetele

stocate, cheile externe care fac apel sau referă tabela respectivă. Un

astfel de exemplu este „LIMIT”, care nu este cuvânt rezervat în

Oracle, dar este în MySQL;

4. Volumul mare de date face ca transferul să dureze şi zeci de ore în

funcţie de metoda de export-import folosită.

Etapele Migrării datelor

Migrarea datelor se realizează în trei etape: export şi conversie, transfer şi procesare şi import.

112

Figura 2.20 Etapele migrării datelor

Etapa 1: Export şi conversie

În această etapă se exportă şi se converteşte întreaga bază de date

iniţială sau doar anumite obiecte, caz în care se pot alege următoarele tipuri

de obiecte:

tabele;

viziuni;

proceduri / funcţii / pachete stocate;

declanşatori.

După ce s-au ales obiectele, acestea se pot redenumi sau se pot

schimba tipurile de reprezentare a datelor (de exemplu se pot converti toate

datele de tip numeric întreg în tipul caracter). Operaţia poate fi la nivel

global, pentru toate obiectele sau doar pentru o parte dintre acestea. Etapa se

finalizează prin crearea fişierelor cu comenzi SQL, folosite pentru crearea

113

structurii bazei de date. Aceste fişiere ASCII conţin atât datele exportate cât

şi scripturile necesare derulării importului şi depind de baza de date

destinaţie.

Etapa 2: Transfer şi procesare

Această etapă este una opţională şi este folosită în cazul proiectelor

în care fişierele de export trebuie dintr-un motiv sau altul să fie transferate.

Acest lucru este frecvent în cazul migrării bazelor de date distribuite

geografic sau când nu se poate stabili o conexiune directă între baza de date

sursă şi cea destinaţie. În faza de procesare, scripturile rezultate din transfer

pot fi modificate pentru anumite nevoi particulare neacoperite de asistentul

de migrare folosit.

Etapa 3: Import

Scriptul rezultat după prima etapă şi eventual prelucrat în cea de a

doua este executat pe baza de date destinaţie. Structura bazei de date este

creată cu ajutorul utilitarelor specifice fiecărei baze de date care permit

execuţia de scripturi SQL. Cele mai importante sunt:

SQL Plus pentru Oracle;

CLP (Command Line Processor) pentru IBM DB2;

ISQL pentru Ms SQL Server şi SyBase;

linia de comandă MySQL.

Utilitarele pentru încărcarea datelor din fişierele ASCII sunt de

asemenea specifice bazei de date. Cele mai importante sunt:

SQL Loader pentru Oracle;

LOAD/IMPORT pentru IBM DB2;

BCP pentru SQL Server şi Sybase;114

LOAD DATA INFILE pentru MySQL;

BUTIL pentru Persasive SQL.

În general, în cazul migrării este necesar mai puţin timp şi efort,

procesul fiind în general sigur, cu o probabilitate scăzută de eşec. În plus,

investiţia făcută în vechiul sistem nu este pierdută, dar este evident că

slăbiciunile acestuia nu vor fi eliminate în totalitate de migrarea la un nou

sistem de gestiune a bazelor de date.

115

TEHNOLOGII DE INTEGRARE A SISTEMELOR INFORMATICE

2.1.Integrarea orientată pe date.................................................................762.1.1. Menţinerea unor copii ale datelor...............................................772.1.2 Federalizarea datelor....................................................................792.1.3 Integrarea datelor prin intermediul interfeţelor...........................81

2.2. Standarde utilizate la integrarea datelor............................................822.2.1. XML, XSLT, ebXML.................................................................822.2.2. SOAP, WSDL, UDDI.................................................................88

2.3. Tehnologii informatice de integrare a datelor...................................912.3.1. Baze de date centralizate şi distribuite.......................................922.3.2. Depozite de Date........................................................................99

2.3.2.1. Caracteristici ale depozitelor de date.................................1042.3.2.2. Arhitectura depozitelor de date..........................................106

2.3.3. Migrarea datelor.......................................................................110

116