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;

77
 • replicare snapshot master-slave;
• 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.

Aplicaţie Aplicaţie Aplicaţie

Replicarea datelor Replicarea datelor

Baza de Baza de Baza de
date 1 date 2 date 3

Replicarea datelor

Figura 2.2 Replicarea unei baze de date

78
 Multe baze de date, care includ soluţii “middleware” oferă servicii
pentru replicarea datelor. Replicarea prin intermediul serviciilor este
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ă

79
colectarea şi distribuirea datelor, pe măsură ce acestea sunt necesare, către
bazele de date fizice.
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 invers
BizTalk 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- este un grup de lucru al W3C, care descrie un mecanism
Schema pentru determinarea structurii unui document XML
XML Este un alt grup W3C, care creează un set de operaţii comune
Query ş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

92
concurenţi. Sistemul de baze de date distribuite trebuie gestionat astfel încât
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:

93
 o procesele client, care execută sarcini care solicită de la server
resurse partajate;
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

94
 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ă
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ă,

98
 concurenţa accesului la date este minimă, timpul de actualizare este
mare şi timpul de regăsire este mic.

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

99
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
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

100
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.
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
101
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ă
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
Cheltuieli cu serviciile
software-ul pentru profesionale
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

102
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
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

103
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ă);
 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

104
 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;
• 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

105
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,
 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
 Surse de date Depozitul de date Instrumente BI

Interogari
Interogari

Stocare Data
ET
centralizata Warehouse OLAP
OLAP
L

Data
Data Mining
Mining
Fisiere
Baze de date Rapoarte
Rapoarte
Surse externe

Data Marts

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ă

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
 U tilizatori IT

D ate operationale
M od ulul O perational
S ecventiale N e-relationaleR elationale Externe

Transform area datelor

Incarcare Filtrare C onditionare

D epozitul de date
M od ulul C en tral
R eplic are si distribuire

D ata M arts

C unoastere/D ata M ining

M od ulul Strategic
U tilitare pentru accesarea inform atiilor

U tilizatori finali

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

111
pachetelor stocate în baza de date. Principalii factorii ce trebuie luaţi în
considerare când se migrează la o altă bază de date:
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

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

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
113
global, pentru toate obiectele sau doar pentru o parte dintre acestea. Etapa se
finalizează prin crearea fişierelor cu comenzi SQL, folosite pentru crearea
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:

114
 • SQL Loader pentru Oracle;
• LOAD/IMPORT pentru IBM DB2;
• BCP pentru SQL Server şi Sybase;
• 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....76
2.1.Integrarea orientată pe date................................................................76
2.1.1. Menţinerea unor copii ale datelor...............................................77
2.1.2 Federalizarea datelor....................................................................79
2.1.3 Integrarea datelor prin intermediul interfeţelor...........................81
2.2. Standarde utilizate la integrarea datelor............................................82
2.2.1. XML, XSLT, ebXML.................................................................82
2.2.2. SOAP, WSDL, UDDI.................................................................88
2.3. Tehnologii informatice de integrare a datelor...................................91
2.3.1. Baze de date centralizate şi distribuite........................................92
2.3.2. Depozite de Date ........................................................................99
2.3.2.1. Caracteristici ale depozitelor de date.................................104
2.3.2.2. Arhitectura depozitelor de date..........................................106
2.3.3. Migrarea datelor........................................................................110

116