TEHNOLOGII DE INTEGRARE A

SISTEMELOR INFORMATICE

Conectarea aplicaiilor prin stocurile de date este relativ simpl,

apelnd la: FTP, utiliti oferite de SGBD-uri, instrumente ETL (Extract,
Transform and Load), servere de integrare. Multitudinea de instrumente
suport pentru integrare la acest nivel uureaz 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 fr a mai fi nevoie de
extragerea, transportul, transformarea, validarea i curarea datelor din
sistemele surs i ncrcarea lor n sistemele destinaie. Migrarea datelor se
poate face ctre un sistem operaional (n general ctre o baz de date) sau
ctre un sistem suport decizie (adic ctre un depozit de date). Principalul
standard folosit pentru interschimbul de informaii este eXtensible Markup
Language (XML), iar cel mai important protocol de comunicaii 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 aplicaiilor trebuie ca
schimbul de informaii s apar ntre bazele de date (sau proprietari API,
care produc informaie), ceea ce nseamn c bazele de date trebuie vzute
76

ca puncte principale de integrare. Soluiile de integrare orientat pe date pot

fi grupate n trei categorii:

copii multiple ale bazei de date ;

federalizarea datelor;

procesarea interfeei.

Figura 2.1 Schimb de informaie ntre dou aplicaii

2.1.1. Meninerea unor copii ale datelor

Prin realizarea unor copii ale bazei de date si distribuirea lor la
nivelul aplicatiilor fiecare aplicaie poate s aib propriul stoc dedicat de
date. n orice moment, o parte din surse sunt puin desincronizate, datorit
ntrzierilor inerente n propagarea schimbrilor 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 tranzaciilor

replicare incremental a tranzaciilor master-slave;

implementarea sincronizrii la nivel de linie master-master

utiliznd SQL Server;

implementarea replicrii snapshot master-slave utiliznd 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 proveniene diferite (Figura 2.2)

i pot avea modele

diferite. Cerina 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.

Aplicaie

Aplicaie

Replicarea datelor

Aplicaie

Replicarea datelor

Baza de
date 1

Baza de
date 2
Replicarea datelor

Figura 2.2 Replicarea unei baze de date

78

Baza de
date 3

Multe baze de date, care includ soluii 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 soluii ofer servicii de transformare precum i abilitatea de a
modifica schema i coninutul astfel nct acestea s aib sens pentru baza
de date int.
Avantajele replicrii bazelor de date sunt simplitatea i costurile
sczute. Replicarea este uor de implementat, iar tehnologia este ieftin.
Din pcate, aceste avantaje sunt eliminate dac sunt necesare metode ataate
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, federaiile bazei de date reprezint bazele de date
virtuale.
Instrumentele pentru federalizarea datelor plaseaz un nivel
software (middleware) ntre bazele de date distribuite fizic i aplicaiile
care vizualizeaz datele. Acest nivel conecteaz bazele de date folosind
interfee i mapeaz bazele de date fizice ntr-o baz de date virtual.
Aplicaia folosete aceast baz de date virtual pentru a accesa informaiile
necesare. Instrumentele pentru federalizarea bazei de date gestioneaz

79

colectarea i distribuirea datelor, pe msur ce acestea sunt necesare, ctre

bazele de date fizice.
Avantajul folosirii acestui software este c poate lega tipuri
diferite de date ntr-un model unificat care suport schimbul de informaie.

Figura 2.3 Federalizarea datelor

Aceasta este cea mai elegant soluie 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 modificri ale aplicaiilor int. Totui, schimbri sunt necesare
la nivelul aplicaiei care susine software-ul bazei de date coninut n
federaie. Acest fapt este datorat interfeelor 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 interfeelor

Soluiile de procesare a interfeei folosesc interfee ale unor aplicaii
bine definite pentru a se axa att pe integrarea aplicaiilor pachet, ct i pe a
celor obinuite (Figura 2.4). Interesul curent n integrarea de tip Enterprise
Resource Planning (ERP) manifestat de ctre SAP, PeopleSoft - Oracle a
fcut acest sector cel mai atractiv n ceea ce privete integrarea de aplicaii.

Figura 2.4 Procesarea interfeei

Productorii de soluii ERP susin soluiile bazate pe procesarea

interfeei prin oferirea de adaptori, care s conecteze ct mai multe aplicaii
obinuite sau aplicaii pachet, externaliznd informaia. Aceti adaptori se
conecteaz la soluiile 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 nelege
mai bine interfaa grafic. Ecranele mai noi prezint informaia n format
HTML, pentru a putea fi accesat dintr-un browser.
81

O integrare eficient a mai multor tipuri de aplicaie definete

avantajul principal al utilizrii produselor de integrare a aplicaiilor. n doar
cteva zile, este posibil conectarea unei aplicaii SAP R/3 la o aplicaie
Oracle, prin intermediul unei soluii de procesare a interfeei care s
gestioneze diferenele de schem, coninut i semantica aplicaiei, prin
interpretarea informaiei interschimbat ntre sisteme.
Dezavantajul folosirii produselor de integrare bazat pe procesarea
interfeei este c se acord atenie limitat logicii procesului de afaceri, ct
i metodelor aparinnd sursei sau sistemelor int. n aceste situaii, se
recomand folosirea unei abordri orientate pe servicii. Se prognozeaz c
pe viitor, tehnologia de procesare a interfeei 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 informaie pe Internet. Ca
urmare, aplicabilitatea la integrarea aplicaiilor este natural, deoarece XML
ofer un standard robust, uor de neles pentru schimbul de informaie.
XML poate susine interschimbul de semantici ale aplicaiilor i de
informaie. Tot acest proces se realizeaz fr ca aplicaiile destinaie s aib
nevoie de informaii despre aplicaiile surs.
XML ofer un format comun de schimb de informaie, ncapsulnd
att datele ct i metadatele. Acest format permite aplicaiilor i bazelor de
date s comunice fr a avea informaii una despre cealalt. Pentru a
82

comunica, sistemul surs reformateaz un mesaj, o informaie sau o

nregistrare ca un XML-text i mut acea informaie ntr-ul alt sistem, care
tie s citeasc XML.
Valoarea XML-ului rezid din simplitatea lui. Se pot lua cantiti
mari de informaie i se pot consolida ntr-un document XML ca piese
semnificative, care dau structura i organizarea informaiei. (Figura 2.5)

Figura 2.5 XML, reprezentare text simpl a unor date de complexiti 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 coninute de un element
rdcin XML, care suport elemente rdcin sau elemente n alte
elemente, de unde rezult c poate susine o structur ierarhic. Numele
83

elementelor descriu coninutul elementului, iar structura descrie relaiile

dintre elemente. Un document XML este considerat bine format, dac poate
fi citit de un parser XML i dac formatul su se potrivete cu specificaiile
XML. Se pot defini atribute ale elementelor i descrie caracteristici ale
elementelor n tagul de nceput. Un parser XML citete 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 aplicaiile ce folosesc XML s poat fi integrate, ele
trebuie s externalizeze informaia sub form de XML. Tehnologia
middleware-XML gestioneaz extragerea informaiei din sistemul surs,
conversia ei n XML i plasarea informaiei n sistemul destinaie, tot
procesul fiind automat i transparent pentru utilizator. Aa cum s-a mai
specificat, XML este bazat pe text i, astfel, o informaie care n mod normal
poate fi stocat pe 512 KB, se poate mapa ntr-un fiier XML de 20 ori mai
mare, acest fapt reprezentnd unul din dezavantajele utilizrii XML.

Figura 2.6 Extragerea informaiei prin parser XML

Legtura 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 nelese de sistemele

destinaie. Middleware-ul gestioneaz i interfeele cu aplicaiile surs i
destinaie i mut informaia.
XML nu juca pn mai recent un rol prea important n domeniul
integrrii aplicaiilor n cadrul aceleai companii. Practic, n aceste cazuri
erau alese alte standarde i metode de integrare din motive de eficien.
Totui, datorit descentralizrii controlului asupra informaiei, XML devine
din ce n ce mai important. Multe companii, ca Oracle-PeopleSoft i SAP
folosesc acum XML ca interfa nativ pentru sistemele lor. OraclePeopleSoft deja a definit un produs, Open Integration Framework, care
folosete XML. Mai mult dect att, productorii 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 integrrii aplicaiilor ntre mai
multe companii. Standardele XML ofer valoare suplimentar prin
includerea nivelurilor de metadate comune, care pot exista ntre unul sau
mai muli parteneri membri ai tranzaciei i chiar prin includerea
mecanismelor de transformare standard ca XSLT.
Cele mai relevante standarde XML folosite pentru integrarea
aplicaiilor sunt: RosettaNet, XEDI, BizTalk, Extensible Financial Reporting
Markup Language (XFRML), XML-Schema, XML Query i XSLT (tabelul
2.1.).
RosettaNet
XEDI
BizTalk
XFRML

un cadru pentru interschimb de date i procese cu e-business.

se refer la o specificaie, care descrie cum trebuie mapat un
EDI tradiional la un XML i invers
este fondat de Microsoft i definete un standard XML pentru
XML-uri bazate pe mesaje i metadate. Microsoft ofer i un
server BizTalk pentru a susine acest standard.
este un standard definit de American Institute of Certified
85

XMLSchema
XML
Query

Public Accountants pentru a defini standarde XML pentru

informaii financiare.
este un grup de lucru al W3C, care descrie un mecanism
pentru determinarea structurii unui document XML
Este un alt grup W3C, care creeaz un set de operaii comune
i sintax pentru a accesa date stocate XML
Tabelul 2.1. Standarde XML pentru integrarea aplicaiilor

XSLT este un limbaj proiectat s transforme un document XML

ntr-un altul, modificnd att schema, ct i coninutul procesului.
Documentele XML sunt ca nite mesaje. Fiecare aplicaie are un set unic de
semantici, iar documentele care circul ntre aplicaii trebuie s poat fi
transformate (Figura 2.7). Att structurile de date, ct i coninutul sunt
necesar s fie corecte din punct de vedere semantic pentru a fi ncrcate n
aplicaia int. Dac datele nu au formatul necesar, atunci operaia de
actualizare nu va reui.

Figura 2.7 Transformarea documentelor XML prin XSLT

86

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

operaii 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
pai. Primul pas const ntr-o transformare structural, unde datele sunt
transformate, de la o structur de intrare la o structur de ieire. Acest pas
implic selectarea datelor, gruparea lor, sortarea lor sau agregarea lor n
funcie de necesitile transformrii. 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 colaborrii dintre UN/CEFACT i OASIS. Acest

standard a fost construit pe baza XML, ca i alte standarde Internet i
servicii Web. Scopul su este crearea unei infrastructuri pentru comerul
electronic bazat pe informaie i procese. ebXML este considerat un
standard bun, fiind folosit de cei care automatizeaz B2B.
Unicitatea ebXML-ului este dat de completitudinea acestuia,
adresnd probleme ca: procese, managementul tranzaciilor, semantici,
notaii, securitate, acorduri, standarde legate de transferul de informaie i
standarde legate de structurarea informaiei.
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 comerul electronic. Acesta este un sistem bazat pe
mesaje XML pentru schimbul de informaie i poate conine un depozit
pentru a permite accesul simultan la informaie. Sistemul de mesaje suport
orice tip de date, tranzacii EDI i informaie binar. Mai mult dect att,
ebXML suport acorduri de tranzacionare ntre parteneri o funcie
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 productorilor de aplicaii i integrare de aplicaii s-si
proiecteze produsele pentru a susine acest standard.
2.2.2. SOAP, WSDL, UDDI
Simple Object Access Protocol (SOAP) definete un format XML
bazat pe mesaje, care este folosit de aplicaiile 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 funcii n
alte aplicaii. Este analog cu Remote Procedure Calls (RPC) folosit de
tehnologii ca DCOM sau CORBA, dar elimin o parte din complexitatea
utilizrii acestor interfee. SOAP permite aplicaiilor s apeleze funcii din
alte aplicaii, 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 colecie 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 informaiei
tehnice i funcionale despre serviciile Web pe Internet.
Un document WSDL este descris de un numr de elemente:

definiii tip, pentru elementele de date (n mod normal, utiliznd

XML Schema);

definiii de mesaje, care comprim unul sau mai multe elemente

de date;

definiii ale operaiilor, care reprezint descrieri abstracte ale

aciunilor care pot fi suportate de serviciu, i care definesc tipul
mesajului: de intrare sau de ieire;
89

definiii PortType;

definiii de conectare, care descriu conexiunea ntre PortType i

protocoale (SOAP, HTTP, GET/POST);

definiii 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
gsete att n COM ct i n CORBA. Cu alte cuvinte, este un simplu
contract ntre client i server.
WSDL definete o gramatic XML pentru descrierea serviciilor de
reea ca o colecie de puncte finale de comunicaie, care pot face transfer de
informaie. Definirea serviciilor WSDL ofer o modalitate pentru
automatizarea comunicrii ntre aplicaii (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 asemntor
cutrii informaiei n Pagini Aurii sistemele de comer pot cuta n registrul
UDDL serviciile Web, apoi pot prelua parametrii de interaciune i pot
interaciona efectiv cu serviciile Web gsite folosind SOAP.
Specificaiile UDDI intesc s defineasc un mecanism comun
pentru publicarea i cutarea informaiei prin servicii Web. Creatorii UDDI
(IBM, Microsoft, Ariba) ncearc s creeze un echivalent pe Internet pentru
Pagini Aurii. Acum este disponibil pe pia prima generaie de specificaii.

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 colecii de date n memoria
extern, cu urmtoarele caracteristici:

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

este structurat, conform unui model de date;

este coerent, prin restriciile de integritate i protecia 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 rspndit model de
baze de date este cel relaional, n care datele sunt memorate n tabele. Pe
lng tabele, o baz de date relaional mai poate conine: indeci, proceduri
stocate, declanatori, utilizatori i grupuri de utilizatori, tipuri de date,
mecanisme de securitate i de gestiune a tranzaciilor etc. Alte modele de
baze de date sunt: modelul ierarhic, modelul reea, modelul obiectualrelaional, modelul orient obiect.
O baz de date poate fi folosit pentru integrarea diverselor aplicaii.
n aceasta pot fi ncrcate 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 locaie fizic, ci este dispersat ntr-o reea de
calculatoare interconectate, putnd fi accesat de mai muli utilizatori
92

concureni. Sistemul de baze de date distribuite trebuie gestionat astfel nct

distribuirea, concurena i eventualele eecuri s fie transparente,
asigurndu-se c operaiile de citire (cererile) i operaiile de scriere
(actualizrile) se execut astfel nct s nu apar nici o diferen fa de
situaia unei baze de date cu un singur utilizator [TRAI82]. Transparena din
toate aceste puncte de vedere poate fi destul de scump, iar n practic ea
este realizat doar n msura n care permite obinerea unor performane
acceptabile.
Coleciile de date pot fi distribuite pe mai multe calculatoare, care se
pot afla n aceeai locaie fizic sau n locaii fizice diferite. O baz de date
este distribuit sub form de partiii/fragmente distincte, care pot fi replicate
pe mai multe noduri din reea. Pe lng fragmentare i replicare, exist i
alte tehnici de proiectare a bazelor de date distribuite, alegerea uneia dintre
acestea

realizndu-se

funcie

de

nevoile

afacerii

de

sensibilitatea/confidenialitatea datelor care vor fi stocate n baza de date.

Sistemele distribuite se folosesc n mai multe domenii ale
informaticii (sisteme de baze de date, reele de calculatoare, sisteme de
operare etc.). Totui, toate sistemele distribuite, indiferent de tipul lor, au
cteva caracteristici i obiective de realizare comune. Aceste aspecte
comune le prezentm n paragraful de fa.
Caracteristicile principale ale sistemelor distribuite
1. Suport pentru partajarea resurselor: aceleai resurse sunt folosite de
mai muli 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 clieni. 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 rspunsul.

modelul bazat pe obiecte, n care, ntr-o execuie de program, fiecare

entitate este vzut ca un obiect cu interfa public de acces. De
asemenea, fiecare resurs partajat este vzut ca un obiect.

2. Deschiderea: Sistemul poate fi extins, n orice moment, pe diferite ci.

n acest sens, sistemul deine: mecanisme de comunicare interprocese,
interfee publice pentru acces la resurse partajate i resurse, care sunt
eterogene.
3.

Concurena i paralelismul: n acelai timp, mai muli utilizatori,

folosesc n mod eficient aceleai resurse. Aspectele care trebuie
implementate de sistem sunt: simultaneitate privind mai muli utilizatori
i mai multe procese, s separe activitile de utilizatori, s asigure
independena proceselor fa de resurse i de activiti.

4. Scalabilitate: Sistemul acioneaz efectiv i eficient pe diferite scale

(datorit eterogenitii resurselor).
5. Toleran la accidente: Sistemul se bazeaz pe redundana hardware i
pe acoperirea software.
6. Transparena: Se refer la gradul de independen ntre componentele
sistemului (resurse, operaii, utilizatori etc.), la funcionare. n asigurarea
transparenei se ine cont de: separarea componentelor sistemului,
necesitatea comunicaiei i de tehnici de integrare i management.
Regulile lui Date
94

C.J. Date a ntocmit 12 reguli conform crora 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 funciilor de baz:
securitate, controlul concurenei, backup i recuperare.
R2. Independena fa serverul central: fiecare nod trebuie s acioneze
independent, fr s depind de un server central sau un alt nod.
R3. Continuitatea: activitatea ntr-un sistem distribuit se desfoar fr
ntreruperi pentru ntreineri sau reparaii.;
R4. Transparena localizrii: nici un utilizator/program are nevoie s tie
unde i cum sunt amplasate datele folosite.
R5. Independena fragmentrii: SGBDD va trebui s poat reconstrui
automat, n orice moment, o colecie de date din fragmentele sale.
R6. Independena replicrii: utilizatorii/programele nu trebuie s tie dac
datele au fost replicate i cum anume.
R7. Interogri distribuite: o interogare poate fi executat pe orice nod din
reea care conine date utile execuiei cererii. La rspunsul interogrii pot s
participe mai multe noduri, fr ca beneficiarul s fie contient de acest
lucru.
R8. Tranzacii distribuite: o tranzacie poate s acceseze i s modifice date
din mai multe noduri, fr ca beneficiarul s fie contient de acest lucru.
R9. Independena fa de hardware: nodurile pe care se gsesc datele pot fi
calculatoare de diferite tipuri i puteri.
R10. Independena fa de software: nu trebuie s aib importan
sistemele de operare care exist pe noduri (eterogene).
95

R11. Independena fa de reea: BDD i SGBDD trebuie s poat fi

implementate pe orice platform de reea corespunztoare, iar diferitele
protocoale utilizate n reea, nu trebuie s afecteze funcionarea BDD.
R12. Independena 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, ncrcarea..

Figura 2.11 Tehnici de distribuire

a) Distribuirea prin fragmentare este operaia de descompunere logic a
coleciilor globale n pri disjuncte numite fragmente, utiliznd
operatori speciali.
96

Pentru a realiza fragmentarea SGBDD respect anumite reguli i

metode.
REGULILE ce trebuie respectate la fragmentare:

completitudinea semnific faptul c ntreaga colecie global trebuie

descompus n fragmente. Rezult c orice nregistrare dintr-o
colecie global trebuie s se regseasc ntr-un fragment;

reconstrucia semnific faptul c orice colecie global trebuie s

poat fi recompus, oricnd, din fragmentele sale;

disjuncia semnific faptul c fragmentele n care se descompune o

colecie global trebuie s fie exclusive. Rezult c o nregistrare din
colecia global nu poate s se regseasc n dou sau mai multe
fragmente ale sale.
METODELE ce pot fi utilizate la fragmentare:

orizontal, conform creia

descompunerea coleciei globale n

fragmente se face prin extragerea unui set de nregistrri, pstrnduse toate cmpurile coleciei iniiale. Rezult c fiecare fragment are
un numr de nregistrri mai mic dect al coleciei globale din care
provine, dar aceeai structur de date;

vertical, conform creia descompunerea coleciei globale n

fragmente se face prin extragerea unui set de cmpuri, pstrndu-se
toate nregistrrile coleciei iniiale. Rezult c fiecare fragment are
o structur de date subset din cea a coleciei globale din care
provine, dar acelai numr de nregistrri;

mixt, conform creia descompunerea coleciei globale n fragmente

se face prin aplicarea succesiv a metodelor orizontal i vertical.
97

b) Distribuirea prin replicare este operaia de stocare a unor poriuni

dintr-o baz de date, sub form de copii, pe mai multe calculatoare
(noduri) dintr-o reea.
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 parial, date
replicate total.
METODELE ce pot fi utilizate la replicare:

date nereplicate nseamn c SGBDD aloc spaiu pentru anumite

date, pe o singur copie, pe un anumit calculator din reea.
Caracteristicile acestei metode sunt: redundana este minim,
concurena accesului la date este maxim, timpul de actualizare este
mic i timpul de regsire este mare;

date replicate parial 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 reea. Caracteristicile
acestei metode sunt: redundana crete, concurena accesului la date
scade, timpul de actualizare este mediu i timpul de regsire este
mediu;

date replicate total, nseamn faptul c SGBDD aloc pentru

ntreaga BD mai multe copii pe diversele calculatoare din reea.
Caracteristicile acestei metode sunt: redundana este maxim,

98

concurena accesului la date este minim, timpul de actualizare este

mare i timpul de regsire este mic.
c) Distribuirea mixt este operaia de aplicare succesiv a
fragmentrii i replicrii pentru aceeai colecie global de date. Aceast
tehnic preia avantajele celorlalte dou, dar este mai greu de implementat.
d) Distribuirea prin ncrcare este operaia de copiere periodic a
ntregii baze de date centralizate sau a unei poriuni din ea pe noduri locale.
Este cea mai simpl tehnic i se folosete atunci cnd datele sunt stabile
sau atunci cnd nu toi 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 tranzacional, care conine datele eseniale
despre activitatea companiei din multitudinea de surse de date existente.
Rapoartele obinute pe baza acestor date sunt utilizate ca un instrument de
analiz strategic i competitiv. Analizele rapide i corecte pot influena
deciziile privind evoluia organizaiei pe termen mediu i lung.
O definiie a depozitelor de date formulat de ctre Consiliul OLAP
este urmtoarea [OLAP95]:
Un depozit de date reprezint o stocare centralizat a datelor
detaliate provenite din toate sursele relevante din cadrul unei

99

organizaii i permite interogarea dinamic i analiza detaliat a

tuturor informaiilor.
Spre deosebire de sistemele operaionale, structurile de date ntr-un
depozit de date sunt optimizate pentru o regsire i o analiz rapid. Datele
sunt istorice i sunt actualizate la intervale regulate de timp, n funcie de
cerinele de raportare.
Definiia lui William Inmon, cunoscut drept printele acestui concept
(de altfel deine i trademark-ul pentru datawarehouse) este extrem de
concis: un depozit de date este o colecie de date orientat pe subiecte,
integrat, avnd 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 organizaionale, datele obinute sunt consistente i pot fi
separate sau combinate n funcie de fiecare dimensiune sau aspect al
afacerii. Depozitul de date include, de asemenea un set de instrumente
pentru interogare, analiz i prezentare a informaiilor; reprezint locul n
care sunt publicate datele folosite. Calitatea datelor coninute 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, obinut dintr-o varietate
de surse, disponibil utilizatorilor finali ntr-un mod uor perceptibil i
utilizabil n contextul afacerii.
Sam Anahory [ANDE97] subliniaz finalitatea depozitelor de date,
preciznd c un depozit de date include datele i procesele manageriale care
100

fac informaiile disponibile, permind managerilor s ia decizii corect

fundamentate.
Exist o serie de firme binecunoscute care i-au adus contribuia n
definirea, dezvoltarea i popularizarea tehnologiilor de data warehouse
precum: IBM, Software AG, Oracle, Microsoft, Prism Solution etc.
Creterea volumului de informaii, precum i perfecionarea
software-ului de exploatare a acestuia, au condus la o nou calitate a
folosirii datelor prin analize care pot releva conducerii organizaiei
informaii greu sau chiar imposibil de obinut pe alte ci. Se pot obine astfel
informaii privind preferinele clienilor, profilul lor, distribuia 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 preferinele
unui anumit segment de pia etc.
Este evident c astfel de informaii nu se pot obine dect folosind
anumite prelucrri, 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 cptat denumirea de data mining
(minerit al datelor). Din volumul foarte mare de date se extrag numai datele
relevante, celelalte fiind ignorate. Pentru astfel de aplicaii datele trebuie
bine organizate i indexate pentru o uoar regsire si utilizare.
Pentru a ne da seama de dimensiunile fenomenului voi oferi cteva
cifre semnificative [VILA97]. Un depozit de date este alctuit din baze de
date coninnd intre 1 i peste 10 terrabyte, aceste cifre neavnd dect un
caracter orientativ. Exist astfel i depozite de date coninnd 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

cheltuiete pentru software-ul necesar extragerii, prelucrrii, depozitrii i
analizrii datelor, iar ultima treime este destinat sistemelor hardware
necesare i stocrii datelor. De obicei, depozitele de date i dubleaz
dimensiunile n primele 12 pn la 18 luni. Aceast cretere exponenial
poate fi pe de o parte semnul sigur al succesului implementrii depozitelor
dar, pe de alta parte, poate deveni o problem, dac sistemele nu sunt
construite de la nceput suficient de elastice i de deschise.

Figura 2.12. Structura cheltuielilor pentru crearea unui depozit de date

Din cele de mai sus rezult importana deosebit a flexibilitii
impuse sistemelor care adpostesc asemenea depozite de date. n acest caz,
flexibilitate nseamn o conectivitate la nivelul ntregii organizaii, astfel
nct servere provenind de la furnizori diferii s se poat conecta simultan
la depozitul deja existent. Este, de asemenea, deosebit de important s se
aleag o arhitectur care s se adapteze uor la modificrile de performane,
capacitate i conectivitate. Procesele de configurare, optimizare si
administrare a sistemului, inclusiv procedurile de salvare - restaurare,
precum si pstrarea n tot acest timp a funcionalitii sistemului pot deveni
102

operaii extrem de dificile dac trebuie repetate la fiecare adugare 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 conin numai datele relevante pentru
analiza necesar. Astfel de sub-depozite sunt numite data marts i pot fi
fcute s funcioneze pe configuraii mai modeste dect depozitele de date.
Un astfel de data mart este un depozit de date specific unui anumit
subset de cerine sau unui anumit departament din cadrul organizaiei. n
timp ce un depozit de date conine datele care pot fi utilizate pentru a
rspunde oricrei ntrebri privind afacerile unei companii, un data mart
conine datele pertinente unui anumit compartiment al companiei.
Departamentele pot folosi n comun datele lor, conectnd mpreun data
mart-urile aferente diferitelor compartimente ale companiei i formnd
astfel o infrastructur specific pe baza creia se poate crea un sistem de
suport al deciziei mai uor de construit i mai elastic.
Un data mart care poate utiliza serverele existente, structura
informaional existent (un LAN sau un Intranet) cu mai puin de 500 GB,
cost ai puin 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 organizaii i a contextului n care acesta
acioneaz. Utilizarea acestei colecii poate consta din extragerea unor
rapoarte (la cerere sau cu o anumit periodicitate), extragerea unor date
pentru a fi utilizate de aplicaiile de birotic (programe de calcul tabelar,
procesoare de text, programe de prezentare etc.), dar mai ales pentru a fi
103

utilizate de ctre aplicaii specializate de analiz. Acestea ar putea fi

mprite n dou categorii:

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

Processing - aplicaii axate pe analiz multidimensional);

instrumente pentru "minerit" n date (data mining - aplicaii

axate pe descoperirea unor abloane semnificative n colecii
de date).

2.3.2.1. Caracteristici ale depozitelor de date

Datorit obiectivelor impuse de utilizarea depozitelor de date n
analiz, se desprind cteva caracteristici mai importante pe care acestea le
dein:

depozitul de date asigur accesul la datele organizaiei. 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 existena unor
utilitare care s fie foarte uor de folosit;

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

Consistena presupune faptul c atunci cnd dou persoane
solicit acelai set de informaii s primeasc aceleai date, chiar
dac ele au fost cerute la momente de timp diferite. Dac datele
nu au fost complet ncrcate atunci utilizatorul va fi avertizat cu

104

privire la acest lucru i este sftuit s atepte pn ce vor fi

complet ncrcate;

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

a oferi un acces ct mai rapid i un timp de rspuns ct mai mic
sistemului;

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

utilitare pentru a interoga, analiza, prezenta informaiile;

datele din depozite sunt utilizate direct n analize, fr alte

prelucrri suplimentare. Datele nu sunt doar acumulate la un loc
i pstrate 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 ntlnete
frecvent situaia n care datele sunt de bun calitate, dar nu sunt
colectate n ntregime sau au un caracter opional.

Pentru obinerea acestor caracteristici este necesar redundana

datelor. Dac n sistemul operaional redundana este eliminat (prin
procesul de normalizare) pentru a evita anomaliile de actualizare, n
depozitul de date redundana este creat n mod intenionat (prin
denormalizare i sumarizare) pentru a permite un acces mai rapid la date.
Raiunea pentru care este creat depozitul de date este, n cele din
urm, integrarea datelor. Datele sunt adunate pentru a rspunde nevoilor
informaionale ale ntregii organizaii, asigurnd faptul c rapoartele
generate pentru diversele compartimente vor conine aceleai rezultate.
Sistemul operaional 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:

modaliti unice de codificare, sistem de uniti de msur

consistente,

sistem stabil de reprezentare fizic a datelor,

convenii clare privind modul de reprezentare a datelor

calendaristice,

convenii unice privind denumirile datelor.

2.3.2.2. Arhitectura depozitelor de date

Arhitecturi de baz aunui depozit de date presupune ncrcarea
datelor din una sau mai multe surse, utilizatorii acceseaz n mod direct
depozitul de date. Dar arhitectura depozitelor de date poate varia n funcie
de situaia specific a fiecrei organizaii.
O arhitectur complex presupune existena unui sistem de
purificare i integrare a datelor precum i a mai multor sisteme de tipul
data mart proiectate pentru compartimente ale ntreprinderii. Figura
urmtoare prezint un sistem complex de datawarehouse:

106

Surse de date

Depozitul de date

Instrumente BI

Interogari
Interogari
Stocare
Stocare
centralizata
centralizata

ET
ET
L
L

Data
Data
Warehouse
Warehouse

OLAP
OLAP
Data
Data Mining
Mining

Fisiere
Baze de date
Surse externe

Rapoarte
Rapoarte
Data Marts

Figura 2.13 Depozit de date cu arhitectur complex

Din punct de vedere funcional, n cadrul unui depozit de date pot
fi identificate trei niveluri distincte de realizare:
1) Modulul operaional este reprezentat de datele instituiei care
sunt, de obicei, pstrate n diverse forme, n fiiere sau baze de
date i prelucrate de SGBD-uri diferite. Aceste date pot proveni
de la aplicaii 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, condiionare, curare, fuziune, validare i
ncrcare Acest proces de transformare a datelor reprezint

107

baza pe care se construiete 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 pstrate n uniti independente (Independent
Data Marts), fiecare coninnd datele relevante pentru un
anumit aspect al operaiilor unei instituii;
b. implementarea unei surse de date unice, centralizate i
integrate la care au acces utilizatorii din toate
departamentele unei instituii.
3) Modulul strategic, de afaceri este nivelul la care datele sunt
prezentate analistului pentru interpretare.

Prin folosirea

diferitelor unelte de acces la informaie i a tehnologiilor data

mining disponibile, utilizatorii pot obine informaii care i vor
ajuta n procesele de stabilire a strategiei firmei. Instrumentele de
cereri grafice, prezentrile, rapoarte scrise, browser-ele Web,
instrumente de vizualizare a datelor, toate aparin 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. Aplicaiile suport de decizie ale
clienilor, care ne dau noi informaii despre bugete, prognoze,
recomandri cu privire la alocarea resurselor i multe altele se
afl n modulele data marts la acest nivel al arhitecturii.
108

Utilizatori IT
Modulul Operational

Secventiale

Date operationale
Ne-relationale Relationale
Transformarea datelor
Filtrare

Incarcare

Externe
Conditionare

Depozitul de date
Modulul Central

Replicare si distribuire
Data Marts
Cunoastere/Data Mining

Modulul Strategic

Utilitare pentru accesarea informatiilor

Utilizatori finali

Figura 2.14 Modulele funcionale ale unui depozit de date

Din punct de vedere al ariei de cuprindere, se ntlnesc trei modele
de depozite de date:
1. Depozitul central al organizaiei (Enterprise Warehouse)
colecteaz toate informaiile despre subiectele care privesc
ntreaga organizaie, integrnd date din surse eterogene,
provenite din sisteme tranzacionale diferite. El furnizeaz un
volum extins de date. De regul, conine date detaliate, dar i
date agregate, iar ca ordin de mrime pornete de la civa
gigabytes pn 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 conine un subset al volumului de date din
organizaie, specific unui grup de utilizatori sau departament.
Domeniul este limitat la subiecte specifice. Datele coninute n
data mart sunt, de obicei, agregate. n mod curent, data marturile 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
uor

de

construit

ntreinut

mai

puin

scump

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

curnd msurat n sptmni dect n luni sau ani.
3. Depozitul virtual (Virtual warehouse) este un set de viziuni
(views) asupra bazelor de date relaionale. Pentru eficiena
procesrilor interogrilor, unele din viziunile de agregare pot fi
materializate. Un depozit virtual este uor de construit, dar
problema extragerii i prelucrrii datelor revine n mod exclusiv
serverului de baze de date, ceea ce poate conduce la un timp de
prelucrare mare, ns se elimin necesitatea stocrii datelor ntrun depozit real [HOLL00].

2.3.3. Migrarea datelor

"Migrare sau reproiectare?" este una din primele ntrebri cnd se ia
n considerare migrarea ctre o nou baz de date. Uneori, simpla migrare a
bazei de date nu este suficient, ci este necesar reproiectarea ntregului
110

sistem informatic. Aceast situaie apare cnd procesele interne ale firmei sau schimbat n aa msur nct 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 slbiciunile

structurale;

adoptarea de noi tehnologii;

crearea unei fundaii 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 investiie important. De cele mai multe ori,
departamentul de IT nsrcinat cu realizarea noului sistem nu poate
s ntrein i vechiul sistem n acelai timp;

este posibil ca noul sistem s fie mai puin funcional dect vechiul,
anumite funcii putnd fi uitate.
Nu exist un rspuns 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 parial sau reproiectarea sistemului dup ncheierea migrrii 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 (definiii de tabele,
viziuni, restricii de integritate etc.), ct i a funciilor, procedurilor i

111

pachetelor stocate n baza de date. Principalii factorii ce trebuie luai n

considerare cnd se migreaz la o alt baz de date:
1. Diferenele de sintax SQL ntre principalele SGBD-uri;
2. SGBD-urile de top precum Oracle, SQL Server i DB2 pun la
dispoziie dezvoltatorilor posibilitatea de integra n baza de date
diferite restricii de integritate ct i algoritmi. Toate aceste elemente
i obiecte sunt foarte importante pentru funcionarea corect a
aplicaiilor i dac baza de date surs le conine trebuie s ne
asigurm c i baza de date destinaie le suport i le putem converti;
3. Bazele de date pot conine 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 rmn doar corecii
minore i de finee. O alt problem este i interdependena dintre
obiectele bazei de date. Aproape orice procedur face referiri la
tabele, viziuni sau la alte proceduri, iar aceast interdependen
trebuie meninut 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 fcut
modificarea n toate viziunile, funciile/ procedurile/pachetele
stocate, cheile externe care fac apel sau refer tabela respectiv. Un
astfel de exemplu este LIMIT, care nu este cuvnt rezervat n
Oracle, dar este n MySQL;
4. Volumul mare de date face ca transferul s dureze i zeci de ore n
funcie de metoda de export-import folosit.
Etapele Migrrii datelor
112

Migrarea datelor se realizeaz n trei etape: export i conversie, transfer

i procesare i import.

Figura 2.20 Etapele migrrii datelor

Etapa 1: Export i conversie
n aceast etap se export i se convertete ntreaga baz de date
iniial sau doar anumite obiecte, caz n care se pot alege urmtoarele tipuri
de obiecte:

tabele;

viziuni;

proceduri / funcii / pachete stocate;

declanatori.
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). Operaia poate fi la nivel
113

global, pentru toate obiectele sau doar pentru o parte dintre acestea. Etapa se
finalizeaz prin crearea fiierelor cu comenzi SQL, folosite pentru crearea
structurii bazei de date. Aceste fiiere ASCII conin att datele exportate ct
i scripturile necesare derulrii importului i depind de baza de date
destinaie.
Etapa 2: Transfer i procesare
Aceast etap este una opional i este folosit n cazul proiectelor
n care fiierele de export trebuie dintr-un motiv sau altul s fie transferate.
Acest lucru este frecvent n cazul migrrii bazelor de date distribuite
geografic sau cnd nu se poate stabili o conexiune direct ntre baza de date
surs i cea destinaie. 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 destinaie. Structura bazei de date este
creat cu ajutorul utilitarelor specifice fiecrei baze de date care permit
execuia 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 ncrcarea datelor din fiierele 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 migrrii este necesar mai puin timp i efort,

procesul fiind n general sigur, cu o probabilitate sczut de eec. n plus,
investiia fcut n vechiul sistem nu este pierdut, dar este evident c
slbiciunile 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.................................................................76
2.1.1. Meninerea unor copii ale datelor...............................................77
2.1.2 Federalizarea datelor....................................................................79
2.1.3 Integrarea datelor prin intermediul interfeelor...........................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