SPECIALIZAREA CALCUL ATOARE ȘI TEHNOLOGIA INFORMA ȚIEI [610006]

UNIVERSITATEA DIN BUCUREȘTI
FACULTATEA DE MATEMA TICĂ ȘI INFORMATIC Ă
SPECIALIZAREA CALCUL ATOARE ȘI TEHNOLOGIA INFORMA ȚIEI

LUCRARE DE LICENȚĂ

COORDONATOR ȘTIINȚIF IC
CONF.DR. KEVORCHIAN CRISTIAN

ABSOLVENT: [anonimizat]
2018

UNIVERSITATE A DIN BUCUREȘTI
FACULTATEA DE MATEMA TICĂ ȘI INFORMATICĂ
SPECIALIZAREA CALCUL ATOARE ȘI TEHNOLOGIA INFORMAȚIEI

SOLUȚIE DE VIZUALIZA RE A DATELOR
FURNIZATE DE PLATFOR ME NEOMOGENE CU
APLICAȚIE IN HR

COORDONATOR ȘTIINȚIF IC
CONF.DR. KEVORCHIAN CRISTIAN

ABSOLVENT: [anonimizat]
2018

Cuprins

1 INTRODUCERE – Scurt istoric ………………………….. ………………………….. ……….. 4
2 Bazele teoretice ale conceptului de Business Int elligence ………………………….. .. 9
3 Sisteme neomogene de date ………………………….. ………………………….. ………… 16
4 Integrarea datelor ………………………….. ………………………….. ……………………….. 19
4.1 Generalități ………………………….. ………………………….. ………………………….. . 19
4.2 Tehnologii de integrare ………………………….. ………………………….. ………….. 20
4.2.1 Integrarea orientată pe date ………………………….. ………………………….. 21
4.2.1.1 Menținerea de copii ale datelor ………………………….. ………………………….. ….. 21
4.2.1.2 Federalizarea datelor ………………………….. ………………………….. ………………….. 24
4.2.1.3 Integrarea datelor prin intermediul interfețelor ………………………….. ………. 25
4.3 Standarde utilizate la integrarea datelor ………………………….. ………………… 27
4.3.1 XML, XSLT, ebXML ………………………….. ………………………….. …………. 27
4.3.2 SOAP, WSDL, UDDI ………………………….. ………………………….. ………… 31
4.4 Tehnologii de integrare – Baze de date centralizate și distribuite ………….. 32
5 Raportare / Instrumente de raportare ………………………….. …………………………. 37
6 Sisteme complexe de BI ………………………….. ………………………….. ………………. 41
7 Aplicație ………………………….. ………………………….. ………………………….. ………… 46
7.1 Motivare.Soluții.Utilitate ………………………….. ………………………….. ………….. 46

4
1 INTRODUCERE – Scurt istoric
Utilizarea sporadică a termenului Business Intelligence datează din anii 1860 , mai
precis, acest termen apare pentru prima dată menționat în lucrar ea lui Richard Miller
Devens: ” Cyclopaedia of Commercial and Business Anecdote”(1865) .
În 1958, omul de știință Hans Peter Luhn, publică articolul “A Business Intelligence
System”, care descrie "un sistem automat … dezvoltat pent ru a disemina informații
diferitelor secțiuni ale oricărei organizații industriale, științifice sau guvernamentale",
în urma exploziei postbelice, astfel de sectoare au necesitat o modalitate de
organizare și simplificare a masei în creștere rapidă a datel or tehnologice și științifice.
Folosind ș i definiția inteligenței din Dicționarul Webster, Luhn, recunoscut în termeni
populari ca ”Tatăl BI”, creionează nucleul BI -ului : ”o modalitate de a înțelege rapid și
ușor cantități uriașe de informații, astfel înc ât să poată fi luate cele mai bune decizii
posibile”.
Odată cu apariția computerelor în lumea afacerilor, companiile au avut în final o
alternativă la stocarea datelor pe hârtie. Inventarea de către IBM a hard disk -ului în
1956 a revoluționat stocarea date lor. Floppy -urile, discurile laser și alte tehnologii de
stocare au însemnat că, odată cu generarea de cantități în creștere de date, găsirea
și folosirea de mijloace de stocare trebuia să crească în proporție directă.
Acest lucru a dat naștere la crearea primelor sisteme de gestionare a bazelor de date,
denumite colectiv sisteme de suport decizional (DSS). Până în anii '70, câțiva furnizori
de BI -uri au apărut cu instrumente care au făcut posibilă accesarea și organizarea
acestor date. Dar era o tehnologie nouă și stângace și cel mai important, a fost foarte
dificil de utilizat.
Consultantul Howard Dresner este considerat primul care folosește termen ul de BI în
1989, cu referi re la utilizarea tehnicilor de analiză a datelor pentru luarea deciziilor în
aface ri.
Concurența din partea mai multor furnizori din domeniu a dus la progrese, inclusiv la
apariția și evoluția DW (data warehouses) – depozitele de date. Acest nou instrument
a îmbunătățit fluxul de date în timp ce acesta a trecut de la sistemele operațio nale la
suportul decizional.

5
Stocarea datelor a redus drastic timpul necesar accesării datelor. Datele care în mod
tradițional au fost stocate în mai multe locuri au fost acum într -o singură locație.
Împreună cu această dezvoltare au apărut și aspecte supl imentare ale depozitării de
date, care sunt astăzi capabile de BI. Acestea includ instrumentele Extract,
Transformare și Încărcare (ETL) și software -ul Procesare analitică online (OLAP). În
anii următori, această fază de dezvoltare a devenit cunoscută sub numele de Business
Intelligence 1.0 .
Pe măsură ce BI a devenit o sintagmă cunoscută la sfârșitul anilor 1990 și începutul
anilor 2000, zeci de vânzători noi au intrat pe piață. În această perioadă, au existat
două funcții de bază ale BI: producerea de date și rapoarte, organizarea acestora și
vizualizarea într -un mod prezentabil.
Cu toate acestea, au rămas două aspecte semnificative care stau la baza acestei faze
în curs de dezvoltare a tehnologiei: complexitatea și timpul.
Prea multe proiecte au fost dețin ute de departamentul IT, ceea ce înseamnă că
majoritatea utilizatorilor încă nu au capacitatea de a executa sarcini BI pe cont propriu.
Instrumentele BI existente fuseseră dezvoltate numai pentru experți, iar pentru
folosirea lor era necesară o instruirea amplă. Și pentru că datele au fost sparte, a fost
nevoie de mai mult timp pentru a formula și furniza rapoarte factorilor de decizie. Doar
experții tehnici au reușit să utilizeze software -ul BI de analiză a datelor. Totuși
instrumentele au început foarte l ent să evolueze pentru a putea fi utilizate și de
personal non -tehnic.
Începutul secolului al XXI -lea a marca t un punct de cotitură distinct – Business
Intelligence 2.0 – tehnologii dezvoltate pentru a aborda atât probleme de complexitate,
cât și de viteză . De asemenea, acestea au fost susținute de apariția și dezvoltarea
conceptului ”Cloud ”, ceea ce a extins și simplificat acoperirea platformelor BI.
BI 2.0 a inclus o serie de tehnologii diferite, cum ar fi procesarea în timp real, care a
încorporat inform ații din evenimente, așa cum sa întâmplat în depozitele de date,
permițând companiilor să ia decizii pe baza celor mai recente informații disponibile.
Alte tehnologii care au intrat în joc au inclus accesul auto -service pentru utilizatorii
non-experți, cee a ce înseamnă că angajații ar putea acum să realizeze proiecte fără
a apela la departamentul IT.

6
Creșterea exponențială a internetului a susținut și a avansat aceste evoluții, parțial
prin generarea de instrumente de rețele sociale. Facebook, Twitter și bl ogurile au oferit
utilizatorilor modalități foarte simple și foarte rapide de a împărtăși idei și opinii.
De asemenea, a oferit utilizatorilor posibilitatea de a revizui metodele și software -ul și,
în general, să difuzeze o înțelegere de bază a diferitelor utilizări ale serviciilor BI.
Comunicarea a facilitat rapid înțelegerea noilor tehnologii.
Până în 2005, interconectivitatea tot mai mare a mediului de afaceri a însemnat că
organizațiile au nevoie de informații în timp real, din diverse motive. Acestea f iind
nevoite să țină pasul cu concurența și să înțeleagă ce voiau consumatorii și ce credeau
despre compania lor.
BI nu mai era un utilitar suplimentar sau un simplu avantaj. A devenit o cerință pentru
întreprinderile care doresc să rămână competitive și c hiar să rămână pe linia de plutire
într-un mediu complet nou, bazat pe date. Agilitatea și viteza platformei de business
intelligence de la mijlocul anilor 2000 au suferit un proces intens de rafinare.
Specificarea instrumentului, extinderea opțiunilor de auto-service și îmbunătățirea
vizualizării sunt trei dintre cele mai importante trăsături ale următoarei frontiere a
evoluției BI.
Instrumentele BI în prezent sunt deseori concepute cu o industrie foarte specifică, fie
că este vorba de asistență medicală, de aplicare a legii sau chiar de sporturi
profesionale. Cunoscută ca "verticalizarea software -ului", această creștere a
instrumentelor specifice industriei a contribuit în mod semnificativ la adoptarea sporită
a inteligenței de afaceri.
Marea revoluție a d atelor și explozia internetului au condus organizațiile la generarea
de date în continuă creștere. Fiecare persoană creează cantități tot mai mari de
informații. Peste 204 de milioane de e -mail-uri sunt trimise pe minut.
Instrumentele de vizualizare au înc eput să evolueze pentru a implica din ce în ce mai
mult utilizatorul final , ceea ce presupune că ace sta poate să exploreze și să utilizeze
datele din propriul cont fără instruire.
BI-ul în cloud, care găzduiește software -ul pe internet, reduc e costurile de stocare și
asigură accesul la date și informații organizaționale mai rapid și mai convenabil.

7
Furnizorii de hardware și software au experimentat, inovat și apoi au scos pe piață
intrumente din ce în ce mai rapide și mai accesibile.
Direct proporțională cu creșterea tehnologiei ”Cloud” este creșterea platformelor
mobile, care permite utilizatorilor să lucreze cu BI în mișcare pe smartphone -uri,
tablete și alte dispozitive.
Pe măsură ce instrumentele sunt perfecționate și îmbunătățite, acestea sunt, de
aseme nea, simplificate și mai convenabile, încurajând o adaptare mai largă.
Aplicațiile Business Intelligence ajută la accelerarea și îmbunătățirea procesului de
luare a deciziilor, optimizarea proceselor interne, creșterea eficienței operaționale,
generarea de noi venituri și exploatarea concurenței. Sistemele BI ajută companiile să
identifice tendințele pieței și să identifice problemele care trebuie abordate.
Datele BI pot include informații istorice, dar și date noi din sistemele sursă, colectate
imediat dup ă generare. În plus față de managerii BI, echipele de business intelligence
includ de obicei arhitecți BI, dezvoltatori BI, analiști de afaceri și profesioniști în
managementul datelor. Utilizatorii de afaceri se alăture, de asemenea, echipelor
pentru a re prezenta partea de afaceri și pentru a se asigura că nevoile organizației se
regăsesc în procesul de dezvoltare BI. Ca rezultat, un număr din ce în ce mai mare
de companii înlocuiesc dezvoltarea tradițională cu o abordare Agile BI și de stocare a
datelor u tilizând tehnicile de dezvoltare a software -ului Agile pentru a diviza proiectele
BI în părți mici și pentru a oferi noi funcțion alități utilizatorilor finali. Această abordare
permite organizațiilor să implementeze mai rapid funcționalitatea BI pentru a r afina
sau a modifica planurile de dezvoltare pe măsură ce schimbările de afaceri sau nevoile
noi apar și devin priorități.
În calea adoptării Business Intelligence există și bariere, una dintre ele fiind rezistența
culturală a angajaților companiei. În mod similar, calitatea slabă a datelor sau
cantitatea mare de date inutile pot fi problematice. Soluția de obținere a datelor
relevante din sistemele de business intelligence se bazează pe date standard. Într –
adevăr, datele sunt principala componentă a oricăr ei soluții BI. Acestea sunt blocuri
de cunoștințe. Companiile trebuie să se asigure că depozitele lor de date sunt
ordonate înainte de a începe să extragă informații. În caz contrar, vor funcționa pe
informații eronate .

8
De asemenea, instrumentele BI pot fi obstacole. Instrumentele sunt mai intuitive decât
înainte, dar nu sunt încă pe deplin accesibile. În cele din urmă, multe companii nu
înțeleg suficient procesele lor de afaceri pentru a determina cum să le
îmbunătățească. În plus, companiile trebuie să ră mână prudente în privința proceselor
pe care le aleg. Dacă procesul nu are un impact direct asupra veniturilor companiei
sau dacă nu este standardizat în întreaga companie, toate eforturile pot fi în zadar.
Întreprinderile trebuie să înțeleagă toate activi tățile legate de proces, modul în care
informațiile și fluxurile de date prin intermediul întreprinderii, modul în care datele sunt
transmise utilizatorilor de afaceri diferiți și modul în care aceștia sunt utilizați de toată
lumea pentru a -și îndeplini pa rtea din proces.

9
2 Bazele teoretice ale conceptului de Business Intelligence
Business Intelligence (BI) reprezintă un sistem d e tehnologii , bazate pe sisteme
informatice – hardware și software, care sunt utilizate în colectarea, analiza precum ș i
în transf orma rea datelor în informație inteligibilă, folosită ulterior pentru a determina și
influența deciziile strategice și tactice ale unei organizații.
BI este implementat printr -o varietate de instrumente, software și metodologii care
accesează , colectează și analizează seturi de date din surse diverse – atât sisteme
interne cât și alte surse externe. Asupra acestor pachete de date se dezvolt ă si se
execută interogari , prelucrări , apo i se prezintă rezultatele analitice în rapoarte,
rezumate, tablouri, grafice, diagrame și hărți , pentru a oferi atât utilizatorilor factori de
decizie, cât și lucrătorilor operaționali , informații detaliate despre starea
afacerii /proiectului .
Arhitectura BI poate fi privită ca un lanț de furnizare a informațiilor (figura 1) . Datele
din surse distribuite, adesea eterogene, precum sistemele de procesare online a
tranzacțiilor (OLTP), sunt periodic extrase, curățate, integrate, transformate și
încărcate într -un Data Warehouse (DW), care, la rândul său, este interogat de aplicații
anali ticei. Back -end-ul lanțului de aprovizionare a informațiilor este un proces continuu
(un flux de date), de obicei implementat prin s cripturi sau coduri originale, dezvoltate
in organizație sau prin aplicații ETL ( extra ct-transform -load), cum ar fi PowerCen ter,
DataStage, Ab Initio, Warehouse Builder, QlickView și așa mai departe.
Figura 1
Proiectele BI sunt consumatoare mari de timp si resurse, suferind de cele mai multe
ori ș i de o comunicare necorespunzătoare între partea de ges tionare a

10
afacerii /proiectului si departamentul/ providerul IT. Totodată sunt, de obicei, inflexibile
și, odată cu demararea procesului de dezvoltare, foarte greu sau deloc mai pot fi
aduse modificări de structură sau de funcționalitate.
Complexitatea unei soluții BI este determinată de complexitatea fiecăreia dintre cele
trei mari componente din care este constituită, respectiv consolidare , integrare și
raportare . De menționat că ultima componentă (raportarea), fiind cea care pune în
evidență direct utilita tea soluției BI, prin rezultatele generate, va fi de cele mai multe
ori asimilată soluției înseși.
Consolidarea datelor se referă la colectarea și integrarea datelor dintr -o serie de surse
într-o singură destinație. În timpul acestui proces, diferite surse de date sunt
consolidate (conectate sau puse împreună) într -un singur Data Warehouse.
Informațiile, datele, care vor sta la baza sistemului BI, provin adesea din mai multe
sisteme de informații ale companiei , consolidarea permite explicitarea datelor,
facilitând, de asemenea, o analiză eficientă a datelor. Tehnicile de consolidare a
datelor reduc ineficiențele, cum ar fi duplicarea datelor, costurile legate de dependența
de mai multe baze de date și punctele multiple de gestionare a datelor.
Consolidarea a re la bază următoarele motive:
Centralizarea : dificultatea și chiar uneori imposibil itatea de a accesa datele în timp
real, date puse la dispoziție de diferite sisteme , cauzate de probleme de interconectări
ale rețelelor, de viteza de comunicare precum și de incompatibilități ale protocoalelor
și interfețelor.
Unificare : DW-ul colectează datele într -un singur sistem unic, cu o refer ință și o
terminologie comună, cu o modelare unificată și interfețe de acces identice. Aceasta
permite crearea de legături într e date eterogene.
Resurse IT : aplicațiile BI pot fi consumatoare extreme de resurse (CPU, disc,
memorie ) iar sisteme le aflate la dispoziție nu sunt dimensionate corespunzător pentru
nevoi.
Specializare : aplicațiile BI au nevoi specifice care nu pot fi sat isfăcute de sistemele
existente în organizație .

11
Data Warehouse este o bază de date de consolidare , adesea o bază de date
relațională relativ standard, dar care trebuie să găzduiască și să gestion eze volume
mari de informații. Aceasta poate fi o bază date o pen source (MySQL,
PostgreSQL, s.a.) sau o bază de date proprietară (Oracle, SQL -Server).

DataWareH ouse concentrează informațiile de luare a deciziilor de la diferite sisteme
informatice de întreprindere. Această nouă bază de date în cadrul companiei nu e ste
creată pentru beneficiile unei aplicații operaționale direct legate de activitatea
companiei (ex: sistemul contabil, baza de date HR, baza de date de vânzări, etc.).
DataWarehouse -ul va stoca doar informațiile cheie ale companiei și va fi dedicat doar
cererilor de analiză și raportare.
Compania va putea analiza aceste date fără a reduce performanțele instrumentelor
actuale de producție.
Baza de decizie va fi modelată pentru a facilita "interogările". Vorbim despre
modelarea decizională în format ”fulg de zăpadă ” sau ”stea”.Tabelele vor fi legate
printr -un singur câmp cheie pentru a ajuta la interogarea performanței.
Ca orice modelare de baze de date, acest pas este crucial pentru succesul unui proiect
BI. Modelarea trebuie să fie scalabilă, pentru a prim i cu ușurinț ă zone funcționale noi
DataWareHouse
Subseturi de
date
(DATA MARTS)
CONTABILITATE
COMERCIAL
MARKETING
HR
ALTE DB
ETL

12
(„subseturi“) în viitor și pentru a asigura durabilitatea reală în arhivarea / stocarea unei
cantități importante de informații.
DW-ul trebuie să aibă o durată de viață mai mare decât instrumentele de producție,
acestea p ot evolua sau chiar pot fi înlocuite. În acest caz, DataWarehouse -ul asigură
memoria organizației și vor fi actualizate numai interfețele de încărcare ale acestuia.
Integrarea datelor este un proces în care date eterogene sunt preluate și combinate
ca form ă și structură, datele fiind stocate în DataWarehouse utilizând diferite tehnologii
și ofer ind o vizualizare unificată a datelor . Integrarea datelor permite ca diferite tipuri
de date (cum ar fi seturi de date, documente și tabele) să fie fuzionate de util izatori,
organizații și aplicații, pentru a fi utilizate ca procese și / sau funcții personale sau de
afaceri.
De exemplu, integrarea datelor despre clienți implică extragerea informațiilor despre
fiecare client individual din sisteme de afaceri disparate, cum ar fi vânzările, conturile
și marketing -ul, care apoi sunt combinate într -o singură viziune a clientului putând fi
utilizate de departamente precum comercial, raportare și analiză.
Integrarea datelor sprijină în primul rând prelucrarea analitică a set urilor mari de date
prin alinierea, combinarea și prezentarea fiecărui set de date de la departamentele
organizaționale și sursele externe de la distanță pentru a îndeplini obiectivele
integratorului.
Raportarea presupune generarea si apoi prezentarea date lor prin intermediul
rapoartelor, graficelor, tabele, astfel încât acestea să poată fi analizate.
Raportarea în business intelligence (BI) prezintă două aspecte: un tip de raportare
strict definit ă și o "raportare" luată într -un sens mai general. În primul caz, raportarea
este arta colectării datelor din diverse surse de date și prezentarea lor către utilizatorii
finali într -un mod care este ușor de înțeles și pregătit pentru a fi analizat. În al doilea
sens, raportarea înseamnă prezentarea datelor și a inf ormațiilor, deci include și
analiza – cu alte cuvinte, permițând utilizatorilor finali să vizualizeze și să înțeleagă
datele, precum și să acționeze asupra acestora.
Raportarea poate fi clasificată în mai multe moduri diferite. Raportările pot fi tehnice
sau non -tehnice, funcție de cine le generează. Un alt mod în care raportarea poate fi

13
clasificată este identificarea celor mai importante caracteristici ale unui raport, cum ar
fi tabelele de date, rapoartele tab -urilor, caracteristicile de vizualizare etc.
În cazul în care schema de inteligență a afacerilor urmărește să vadă, să înțeleagă și
să acționeze asupra datelor, obiectivul rapoartelor este să permit ă utilizatorilor finali
să vadă datele, astfel încât să le poată analiza și să le facă inteligibile prin analiză.
Raportarea se referă la date, în timp ce analiza este ceea ce transformă datele în
informații.
Raportarea este condiția prealabilă necesară pentru analiză; ca atare, ar trebui să fie
privită în lumina obiectivului de a face datele ușor de înțel es și gata pentru o analiză
simplă, eficientă și precisă.
Ciclul de viață al unei soluții BI cuprinde 6 etape, fiecare fiind împarțită în mai mulți
pași. Fiecare etapă și fiecare pas cuprinde o verificare pe puncte, documente de
testare și rapoarte.
Etape le ciclului de viață ale unei soluții BI sunt:
1
Etapa 1: Justificare a nevoii soluției BI, plecând de la o e valuare complexă a afacerii /
proiectului în care nevoile și o portunitățile sunt identificate, rezultând propune rea unei

1 Informatica Economică vol. 13, no. 4/2009 – Adela BARA, Iuliana BOTHA, Vlad DIACONIȚA, Ion
LUNGU, Anda VELICANU, Manole VELICANU – Academia de Studii Economice, Bucuresti, Romania,
pag.102

14
soluți i inițial e justifica tă prin optimizări de timp, costuri precum și alte beneficii, toate
acestea fiind cuprinse într -un raport preliminar .
Etapa a 2-a: Planificare a, va cuprinde estimarea și valorizarea capabilităților existente
în organizație pentru susținerea și realizarea proiectului BI , respectiv infrastructura,
componentele, dispozitive le, rețea ua, precum și necesitatea de echipamente , acolo
unde este cazul . Totodată, această etapă implică o dinamică ce va putea genera
schimbări de tehnologie, organizare și nevoile afaceri i/proiectului, resursele umane și
echipa de implementare.
Etapa a 3-a: Analiza afacerii / proiectului, va porni prin colectarea datelor generate de
business prin interviuri și întâlniri cu persoanele de decizie din organizație,
propunându -se o soluție ini țială care apoi este analizață. Tot la această etapă se va
identifica și proiecta atât sursele de date , cât și metodele de extragere/interogare.
Rezultatul acestei etape este elaborarea unui prototip inițial care are la bază modelul
logic rezultat, prototi p ce este testat în vederea validarii. Pe baza rezultatelor testelor
se va trece la analiza metadatelor , acestea sunt proiectate , iar sursele de date sunt
mapate pe structura metadatelor .
Etapa a 4 -a: Proiectarea sistemului , care debuteaza cu proiectarea m odelului fizic prin
rafinarea și detalierea modelului logic. Se va alege unul dintre modelele de date pentru
procesare și stocare (poate fi model relațional, orientat pe obiecte și multidimensional)
si se va trece la proiectarea procesului ETL (extract / t ransform / load). Dificultatea
acestui proces va depinde de calitatea surselor de date, de aceea este recomandabil
ca procesul să fie construit într -un mediu care să integreze toate modulele organizației
și nu separat, pe fiecare departament. Dacă se utili zează o soluție predefinită pentru
depozitul de metadate, atunci aici este ajustată pentru cerințele proiectului, în caz
contrar un depozit de metadate este proiectat în termeni de model logic de metadate ,
în funcție de modelul de date: orientate sau multi dimensionale.
Etapa a 5 -a: Execuție si d ezvoltare : dezvoltarea ETL (instrumente de filtrare,
proceduri, operatori sunt utilizați pentru cons truirea procesului ETL; f iltrarea și
transformările de date depind de calitatea surselor de date , ce pot fi : fișier e, baze de
date, e -mail, internet, surse neconvenționale), dezvoltarea aplicațiilor , exploatarea
datelor (sistemele executive trebuie să implementeze funcțiile de extragere a datelor
pentru a realiza cerințele proiectului, aceasta presupune testarea algori tmilor,

15
tehnicilor de extragere a datelor , cum ar fi gruparea datelor – clustering , algoritmi de
predicție și analiză Bayes ) și dezvoltarea familiei de metadate asociate (dacă trebuie
să fie construit, atunci dicționarul metadatelor și interfețele de acces la date sunt
dezvoltate ).
Etapa a 6 -a: Implementarea sistemului reprezintă procesul de livrare în care echipa
de dezvoltare organizează sesiuni de instruire pentru manageri, se pregătesc
documentații finale și suport tehnic, se realizează procesul de încă rcare a datelor și
se realizează instalarea aplicațiilor , urmate de punerea în aplicare a concluziilor
preliminare, evaluarea costurilor și elaborarea de către echipa de dezvoltare a unui
raport final în care sunt descrise performanțele sistemului , dar și unele părți care
trebuie îmbunătățite sau reconstruite.

16
3 Sisteme neomogene de date
Un DDBMS (distributed database management system) poate fi clasificat ca omogen
sau eterogen (neomogen). Într -un sistem omogen, toate aplicațiile utilizează același
DBMS (database management system) . Într -un sistem eterogen, aplicațiile pot rula
diferite DBMS, care nu trebuie să se bazeze pe același model de baze de date, astfel
încât sistemul poate fi compus din DBMS -uri relaționale, distribuite ierarhic și orientate
pe obi ect.
Sistemele omogene sunt mult mai ușor de proiectat și gestionat. Această abordare
oferă o creștere incrementală, ceea ce face ca adăugarea unei noi aplicații DDBMS
să fie ușoară și permite creșterea performanței prin exploatarea capacității de
procesar e paralelă a mai multor aplicații sau site -uri.
Sistemul neomogen este, de obicei, rezultatul când sursele de date individuale au
implementat o bază de date proprie și integrarea este luată în considerare ulterior.
Într-un sistem eterogen, traducerile sunt necesare pentru a permite comunicarea între
diferite DBMS -uri. Pentru a asigura transparența în DBMS, utilizatorii trebuie să poată
face interogări în limba jul aferent DBMS. Sistemul are apoi sarcina de a localiza datele
și de a efectua translatările nece sare (CLR – Common Language Runtime) .
Când datele trebuie solicitate de la o altă aplicație, dacă hardware -ul este diferit, dar
produsele DBMS sunt aceleași, traducerea este simplă, implicând schimbarea
codurilor și a lungimilor cuvintelor, dar dacă produs ele DBMS sunt diferite, traducerea
este complicată, implicând cartografierea structurii de date într -un model de date cu
structurile de date echivalente dintr -un alt model de date.
Soluția tipică utilizată de unele sisteme relaționale care fac parte dintr -o DDBMS
eterogenă este de a utiliza gateway -uri care convertesc limba jul și modelul fiecărui
SGBD diferit în limbajul și modelul sistemului relațional.
Sistemele care încearcă să integreze și analizeze date din mai multe surse de date
sunt susținute prin a dăugarea de contexte semantice și metadate specifice care
descriu în mod explicit ce înseamnă o valoare a datelor.

17
Pentru fiecare sursă de date, un dezvoltator creează un model personalizat,
completând șablonul cu atribute și valoare predefinite. Această a bordare facilitează
construirea modelului și oferă sintaxă și semantică consecventă între modelele create
cu șablon. Sistemele care pot procesa structura șablonului și valorile atributelor pot
explica orice model astfel descris.
Pentru a realiza un sistem coerent este necesară capacitatea de a integra date diverse
din punct de vedere conceptual și de a raționa în mod consecvent cu privire la aceste
date. Aceste probleme se pot rezolva printr -o abordare foarte generală a integrării
datelor din sursele de dat e multiple și diverse.
Compararea automată și raționamentul cu privire la diverse date din diferite surse
rămâne o problemă deschisă. Principalul obstacol în calea integrării acestor date este
faptul că, în diferite surse de date, aceleași concepte pot fi reprezentate în mod diferit,
iar concepte diferite pot fi reprezentate într -o manieră superficială.
O abordare comună în abordarea acestui obstacol este plasarea datelor în context
pentru a oferi metadate detaliate sistemelor de integrare sau de mediere. iiContextul
unei date include semantica sa ("La ce concept specific se referă această
informație?"), sintaxa sa ("Cum este structurată această structură a datelor?") precum
și alte metadate asociate, cum ar fi informații despre calitatea datelor. Fără context, o
bucată de date este aproape lipsită de sens. De exemplu, pentru a înțelege fragmentul
unui mesaj HL7 "| 234 -7120 ~ |, trebuie să știm atât sintaxa, cât și semantica. Sintaxa
indică faptul că un "~" indică faptul că intra rea precedentă trebuie repetată;
semni ficația semantică este necesară pentru a ști că în acest domeniu specific, "234 –
7120" este un număr de telefon care poate fi folosi t pentru a contacta o persoană;
modelul informațiilor de referință HL7 încearcă să facă acest tip de informații
semantice ex plicite . În mod tradițional, însă, designul unei baze de date și al unui
sistem de informații client definește implicit semantica și, într -o oarecare măsură,
sintaxa unui set de date.
O astfel de abordare ad -hoc nu este posibilă pentru sistemele care înce arcă să
integreze surse de date arbitrare sau să motiveze date integrate. Un astfel de sistem
are nevoie ca contextul datelor să fie specificat explicit pentru a determina dacă două
fragmente de date pot fi combinate, cum ar putea fi combinate și ce ar put ea însemna

18
această combinație. Două abordări majore ale problemelor legate de definirea
contextului datelor într -o singură sursă de date și de contextele conexe din mai multe
surse au fost urmărite în domeniul integrării informației și al medierii.
Prima a bordare este crearea unui model local explicit pentru fiecare sursă de date,
care descrie contextul datelor din acea sursă. Modelele locale variază de la schema
de bază de date care fixează relațiile și constrângerile dintre valorile datelor la ontologii
mai expresive care descriu o bază de cunoștințe de domeniu iii a structurii și atributelor
datelor dintr -o singură sursă. Odată ce astfel de modele sunt create, există mai multe
tehnici pentru a reuni mai multe modele locale, inclusiv potrivirea schemei, fuziunea și
integrarea ontologicăiv, și abordările combinatev. Din păcate, construirea modelelor
locale pentru mai multe surse diferite de date solicită forță de muncă foarte mare, iar
metodele de integrare adesea nu ajustează bine în tratarea multor modele.
O a doua abordare a integrării surselor de date multiple este aceea de a elabora
manual un model global care să specifice contextul unui întreg domeniu al cunoașterii.
Sursele de date specifice sunt apoi descrise cu referire explicită la această ontologie
sau schemă globală. Această abordare sa întâlnit cu un mare succes: SIMS (security
information management system) , un experiment timpuriu în integrarea semantic
bogată a bazelor de date, a folosit un model de domeniu central pentru a lega
împreună mai multe baze de date și a facilita construirea complexă a interogărilor în
baza acestor baze de date.
Un model global strict nu este totuși un panaceu. Dacă o ontologie globală nu este
destul de detaliată, unele date vor fi în mod necesar pierdute la abstractizare : De
exemplu, dacă o sursă de date furnizează înregistrări pentru "oraș" și "țară", dar un
model global are doar "țară" din modelul global implică pierderea informațiilor despre
"oraș". Astfel, un model global trebuie să fie atât amplu, cât și detaliat, pe ntru a adapta
surse de date eterogene fără a "abstracționa" informațiile potențial relevante. Mai mult,
menținerea unei ontologii detaliate și detaliate este o sarcină non -trivială.

19
4 Integrarea datelor
4.1 Generalități
Din ce în ce mai mult, pe măsură ce orga nizațiile devin mai automatizate, și nevoia de
lucru cu date în timp real se amplifică, arhitectura BI evoluează pentru a sprijini luarea
deciziilor operaționale. Acest lucru impune cerințe suplimentare precum și
compromisuri, ducând la o din ce în ce mai mare complexitate în proiectarea fluxurilor
de integrare a datelor .
Acestea includ:
– reducerea latenț ei, astfel încât datele să poată fi livrate aproape în timp real
către depozit ul de date (DW);
– extragerea de informații dintr -o varietate din ce în ce mai m are de surse de date
(conținut nestructurat și semistructurat, fluxuri de date externe, senzori și alte
forme de fluxuri de date ;
– extinderea fluxului ETL – caracterizat prin rigiditate ridicată, către fluxuri de date
mai generale
– luarea în considerare a im plementărilor fizice alternative.
În arhitectura evolutivă pentru BI operațional, procesele ETL nu mai sunt un flux
unidirecțional , ele devin fluxuri de date mai generale, unde, de exemplu, evenimentele
din surse sunt transmise prin operații de transformar e spre depozitul de date, iar datele
curățate pot curge înapoi la bazele de date operaționale (figura 2)
Figura 2

20
Din punct de vedere istoric, proiectarea și implementarea ETL a fost considerată o
sarcină adiacentă în proiectarea și crearea depozitul ui de date (DW) și a fost în mare
parte tratată cu ușurință deoare ce, conceptual, aceasta părea a un simpl u proces de
transfer și integrare de datevi. Cu toate acestea, rămâne o sarcină scumpă, cu forță
de muncă, în mar e măsură manuală. De fapt, într -un tipic proiect de depozit de date,
ETL poate consuma o mare parte din efort (70% din unele estimări). Focusul pentru
ETL a fost pe o funcționalitate corectă și o performanță adecvată; adică mapările
funcționale de la sursele de date la depo zit trebuie să fie corecte, fiind condiționate să
se finalizeze într -un anumit ă durată de timp.
Integrarea reală a datelor sau integrarea bazelor de date implică posibilitatea de a
accesa orice sursă de date în cadrul sau din afara organizației și de a fol osi aceste
informații în aproape orice aplicație sau sistem critic. Datele pot fi stocate în formate
de baze de date relaționale sau non -relaționale / ierarhice, cum ar fi Oracle, DB2,
SQLServer, My SQL, Essbase, FOCUS db și VSAM, dar și in foi de calcul, f ișiere text
sau csv. Informațiile pot fi de asemenea stocate în sisteme ERP, cum ar fi SAP.
Accesul la date este de obicei sub forma unei interogări, a unui sistem de raportare
sau a unui tablou de bord, dar poate include și capacități de actualizare și po ate avea
loc în timp real .
4.2 Tehnologii de integrare
Dacă se realizează prin intermediul stocuri lor de date (DW), conectarea aplicațiilor
este relativ simplă, apelând la utilități oferi te de SGBD -uri, la instrumente ETL sau/și
la servere de integrare. Efortu l de integrare este relativ mic la acest nivel datorită
existenței unei m ultitudin i de instrumente suport pentru integrare la acest nivel .
Integrarea orientată pe date prin migrarea datelor dintr -un sistem în altul sau prin
intermediul unor aplicații care facilitează accesul la date fără extragere, transport,
adaptare și validare, se poate face ori către un sistem operațional, o bază de date, ori
către un sistem suport, respectiv un DW. Pentru schimbul de date se folose ște în
principal standardul XML (Exten sible Markup Language), protocolul de comunica ții
fiind SOAP (Simple Object Access Protocol).

21
4.2.1 Integrarea orientată pe date
In integrarea orientată pe date schimbul de informații apare între bazele de date,
acestea reprezentând puncte principale de integrar e. Soluțiile de integrare orientată
pe date pot fi grupate în trei categorii:
 realizarea de copii multiple ale bazei de date ;
 federalizarea datelor;
 procesarea interfeței.
4.2.1.1 Menținerea de copii ale datelor
Într-un scenariu în care mai multe aplicații sunt c onectate la aceeași bază de date,
efectuarea de copii ale bazei de date, copii ce sunt distribuite la nivelul aplicațiilor,
acestea ajungând să dețină propriul stoc de date fiecare în parte, reprezintă o soluție
care, din cauza inerentelor întârzieri în pr opagarea schimbărilor între sursele de date,
se dovedește a avea neajunsul că o parte din surse sunt mai mult sau mai puțin
desincronizate.
Operația de mutare/copiere a datelor se poate face dup ă 12 modele, astfel:
• mutarea unei copii a datelor;
• replica rea datelor;
• replicare master -master;
• replicare master -slave;
• sincronizare la nivel de linie master -master;
• replicare snapshot master -slave;
• capturarea detaliilor tranzacțiilor ;
• replicare incrementală a tranzacțiilor master -slave;
• implementar ea sincronizării la nivel de linie master -master utilizând SQL
Server;
• implementarea replicării snapshot master -slave utilizând SQL Server;

22
• replicare master -slave în cascadă.
Replicarea datelor reprezintă simpla mutare a datelor între două sau mai mult e baze
de date, care pot avea diferite modele și proveniențe (Figura 3), cu condiția ca baza
de date sa ofere o infrastructură pentru schimbul de date.

Figura 3
Replicarea bazelor de date se poate realiza în cel puțin 3 metode:
 ”SNAPSHOT ” – datele sunt copiate în întregime fie într -o altă bază de date de
pe același server fie pe un alt server. Replicarea snapshot presupune un
consum mare de resurse și de timp, de aceea nu se folosește des ci numai în
anumite cazuri, cum ar fi pentru baze de date care nu suferă schimbări
frecvente sau atunci când este nevoie de stabilirea unui punct de plecare în
replicarea dintre mai multe sisteme, pentru care actualizările ulterioare sunt
propagate folosind replicarea tranzacțională sau replicarea merge.
 ”MERGE ” – replicarea tip merge este cel mai complex tip de replicare,
deoarece permite modificarea atât a bazei de date principale cât și a celei
abonate, sau dacă sunt mai multe baze de date, a tuturor. Modificările sunt apoi
sincronizat e de către agentul sau agenții de replicare . Această metodă permite
astfel, executare de opera țiuni asupra bazelor de date și în situațiile în care nu
există conexiuni active între bazele de date, agentul de replicare activându -se
la restabilirea conexiuni i. Intră în discuție și implicit în acțiune aici și un
mecanism/algoritm de tratare a conflictelor în cazul în care modific ările aduse
diverselor baze de date abonate intră în conflict între ele. Acest tip de replicare
Aplicație
Aplicație
Aplicație
Baza de
date 1
Baza de
date 2
Baza de
date 3
Replicarea
datelor
Replicarea
datelor
Replicarea d atelor

23
este folosit frecvent de utilizatorii de laptop sau alți utilizatori care nu pot rămâne
permanent conectați la o bază de date de pe un server, dar care poate
transporta o bază de date abonat pe care să lucreze.
 TRANZACȚIONALĂ – replicarea tranzacțională reprezintă distribuția automată
și periodică a schimbărilor între baze de date. Datele sunt copiate în (sau
aproape) în timp real de pe serverul principal ( SURSA ) la baza de date
receptoare ( ABONAT ). Astfel, replicarea tranzacțională oferă o copie de
rezervă excelentă pentru modificările frecve nte, zilnice ale bazelor de date. În
majoritatea cazurilor, replicarea tranzacți onală începe prin preluarea unei copii
complete a SURSEI , care este apoi scrisă la ABONAT . Apoi, orice modificări
ale SURSEI sunt înregistrate în timp real și reproduse la ABON AT. Replicarea
tranzacțională nu copiază pur și simplu efectul net al schimbărilor de date, ci
replică în mod consecvent și exact fiecare schimbare. Datorită naturii sale
aproape în timp real, replicarea tranzacțională este frecvent utilizată de doi sau
mai mulți administratori de baze de date (DBA) ca mecanism de remediere a
erorilor în cazurile în care nu se acceptă mai mult de câteva minute de
deconectare, cum ar fi rețelele ATM și centralele nucleare. În acest sens,
replicarea tranzacțională s -a dovedit a fi un mecanism sigur pentru bazele de
date de rezervă.
Serviciile de replicare sunt incluse in soluțiile “middleware”(termen care definește un
software ce interconectează aplicații și/sau baze de date ) care însoțesc bazele de
date. Replicarea prin inter mediul serviciilor este realizată prin plasarea unui strat
software între două sau mai multe baze de date. 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 ofe ră 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ă.
Costurile reduse (tehnologie destul de ieftină) și simplitatea (fiind ușor de implementat)
prin care se realiz ează sunt atuurile replicării bazelor de date. Totuși, dacă apare
necesitatea metodelo r atașate date lor, trebuie luată în considerare orientarea bazată
pe servicii, replicarea nefiind utilizabilă.

24
4.2.1.2 Federalizarea datelor
Un sistem de baze de date federalizat e este un tip de sistem de gestionare a bazelor
de date bazate pe metadate (DBMS), care cartografiază în mod transparent mai multe
sisteme autonome de baze de date într -o singură bază de date federalizată. Bazele
de date constitutive sunt interconectate pr intr-o rețea de calculatoare și pot fi
descentralizate din punct de vedere geografic. Deoarece sistemele de baze de date
constitutive rămân autonome, un sistem federalizat de baze de date este o alternativă
demnă de a fi luată în seamă și de a fi utilizată față de sarcina (uneori descurajantă)
de a uni mai multe baze de date diferite. O bază de date federalizată sau o bază de
date virtuală este o compoziție a tuturor bazelor de date constitutive dintr -un sistem
de baze de date federalizate , cu un view unifi cat (Figura 4) . Nu există o integrare reală
a datelor în bazele de date disparate ale constituenților ca urmare a federalizării
datelor.
Figura 4
Prin intermediul abstractizării datelor, sistemele de baze de date federalizate pot oferi
o interfață de utilizator uniformă, permițând utilizatorilor și clienților să stocheze și să
recupereze date din mai multe baze de date discontinue, nelegate cu o singură
interogare – chiar dacă bazele de date constitutive sunt eterogene. În acest sc op, un
sistem de baze de date federalizate trebuie să fie capabil să descompună interogarea

25
în mai multe interogări (”sub-cereri ”) pentru a fi transmise DBMS -urilor constitutive
relevante, după care sistemul trebuie să compună seturile de rezultate ale
subinterogărilor. Deoarece sistemele de gestionare a bazelor de date diferite folosesc
limbaje de interogare diferite, sistemele de baze de date federalizate traduc în
limbajele de interogare corespunzătoare subinterogările .
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 nece sare 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ă).
4.2.1.3 Integrarea datelor prin in termediul interfețelor
O interfață software – API (application programming interface) este o punte care
permite ca două sau mai multe programe să schimbe informații între ele, chiar dacă
s-ar putea să fi fost dezvoltate de diferite surse sau să utilizeze limbaje de programare
diferite, putându -se realiza astfel integrare atât de aplicații complexe dar și integrare
de aplicații obișnuite (Figura ?).
O interfață va folosi adesea un format de fișier standard, cum ar fi XML pentru a muta
informațiile dintr -un sistem în altul. Unele interfețe sunt programe separate care pot fi
configurate și implementate cu o serie de sisteme, cum ar fi Microsoft BizTalk , în timp
ce altele sunt integrate într -un produs de sine stătător.
Solicitare de date sau servicii

Răspuns
Aplicație cu
baza de date
SQL
Aplicație cu
baza de date
ORACLE

26
De exemplu, soluția de programare Personal Right Omni are două module integrate
pentru a interconecta cu alte soluții software HR, astfel încât să poată fi utilizat cu
software -ul HRIS existent și de salarizare. Un alt exemplu este StaffRefresh care
conectează un sistem HR la StaffRight Omni, astfel încât da tele demografice ale
angajaților, locurile de muncă și informațiile de contact pot fi transmise între cele două
sisteme. StaffPay este puntea între StaffRight Omni și soluția de salarizare, care
folosește și sistem de pontaj.
Sistemele interfațate nu au ac eeași bază de date, astfel încât o interfață necesită
adesea menținerea "mapărilor" între sisteme. Acesta este procesul de potrivire a
codurilor dintr -un sistem cu coduri de la celălalt sistem, cum ar fi codurile de lucru în
HR cu codurile de locuri de mun că în soluția de planificare. "Mapările" acționează ca
director pentru locația în care informațiile dintr -un sistem intră în celălalt.
Cu o interfață, dacă se fac modificări în oricare dintre sisteme, este posibil ca tabelul
de mapări să fie actualizat. Î n caz contrar, software -ul ar putea să tragă informații din
locurile greșite. Folosind același exemplu, dacă s-ar adăuga un nou cod de salarizare
în sistemul de salarizare, trebuie schimba te, de asemenea, mapările din interfaț ă dacă
se dorește ca acest cod să fie utilizat de alte sisteme.
Deoarece soluțiile integrate partajează aceeași bază de date, nu există niciun proces
de codare de cartografiere între sisteme, care poate reduce erorile. Toate modificările
se aplică automat în fiecare parte a sistemului.
Integrarea de tip ERP (Enterprise Resource Planning) reprezintă în preze nt o parte
foarte importantă în integrarea aplicațiilor. Soluțiile ERP se folosesc de adaptori pentru
a realiza conexiuni la cât mai multe aplicații (pachet sau simple). Informația pr eluată
de adaptori este apoi externalizată prin interfețele lor sau prin alte interfețe puse la
dispoziție de alți producători, putându -se folosi și interfețe deschise (open source).
Adaptorii se pot conecta atât prin folosirea de tehnologii middleware cât și cu
instrumente “screen scraper” (acestea permit interceptarea de date dintr -un
mainframe și sunt utilizate pentru a extrage datele relevante din interfața vizuală a
unei aplicații).
Principalul avantaj în utilizarea produselor de integrare a aplicațiil or este generat prin
integra rea a cât mai mult or tipuri de aplicații.

27
4.3 Standarde utilizate la integrarea datelor
4.3.1 XML, XSLT, ebXML
Complexitatea integrării datelor provenind din surse de date eterogene implică
reconcilierea la diferite niveluri – modele de date, schemă de date și instanțe de date.
Astfel, apare o nevoie puternică pentru un instrument viabil de automatizare care să
organizeze datele într -o sintaxă comună. XML (eXtensible Markup Language) este
cel mai bun în îndeplinirea acestei foarte importa nte cerințe.
Modele de date – Sursele de date utilizează structuri diferite, cum ar fi fișiere, tabele
și obiecte, pentru a reprezenta sau pentru a stoca date. Această natură de
eterogenitate a structurilor sau modelelor de date indică necesitatea unui mod el
comun de date pentru a cartografia informații provenite din diferite surse de date.
Schema de date – Există diferite reprezentări ale aceleiași entități sau proprietăți. De
exemplu, două surse de date pot folosi nume diferite pentru a reprezenta aceeași
entitate (preț și cost) sau același nume pentru a reprezenta două concepte diferite sau
două moduri diferite de transmitere a acelorași informații (vârsta și data nașterii). În
plus, sursele de date pot reprezenta aceleași informații utilizând diferite st ructuri de
date. De exemplu, luați în considerare două surse de date care reprezintă date
conform modelului relațional, unde ambele surse modelează entitatea "Angajat", dar
prima utilizează doar un singur tabel, în timp ce al doilea ia două tabele pentru a
reprezenta aceeași entitate. Astfel, instrumentul de automatizare trebuie să ia în
considerare toate aceste diferențe pentru atingerea obiectivului de integrare a datelor.
Instanțe de date – La nivel de instanță, problemele de integrare includ determinare a
faptului că diferite obiecte provenind din surse diferite reprezintă aceeași entitate din
lumea reală și selectând o sursă atunci când se găsesc informații contradictorii în
diferite surse de date, de exemplu date diferite de naștere pentru aceeași perso ană .
Capabilități XML
1. XML oferă un model de date simplu, standard și bine acceptat. XML poate structura
date bazate pe reprezentări ierarhice, bazate pe grafic. Acest lucru facilitează o
reprezentare puternică a informațiilor structurate, semi -structur ate și nestructurate.
Astfel, tehnologia XML este capabilă să furnizeze un model comun de date foarte

28
solid, flexibil și ușor de administrat pe Web. Există o serie de instrumente software
inovatoare care facilitează publicarea conținutului bazei de date în XML.
2. Deoarece XML acceptă extensibilitatea, numele și semnificațiile etichetelor XML
sunt arbitrare. Astfel, a apărut nevoia unui set de etichete și scheme specifice pentru
domenii standardizate, deoarece s -a considerat că standardizarea etichetelor și
schemelor este setată pentru a simplifica sarcina de integrare a datelor. Există mai
multe încercări în această direcție, cum ar fi OASIS și Biztalk. De asemenea, există
XSLT care poate defini mapări între etichete eterogene.
Dar, în același timp, apare n ecesitatea unui mecanism de descriere a semanticii
elementelor și a atributelor. De exemplu, presupunând că două surse de date folosesc
același element de "preț" pentru a descrie suma de bani necesară pentru a cumpăra
un anumit element, atunci apar întrebă ri precum ce monedă specifică prețul, dacă
prețul include taxe și alte cheltuieli. Astfel, este nevoie de înțelegerea semanticii
informațiilor care trebuie integrate. Prin urmare, conceptul de metadate a luat ființă și
toate metadatele pot fi exprimate fol osind XML în sine.
De asemenea, procesul de reconciliere la nivel de schemă poate, de asemenea, să
confere informații despre context, cum ar fi semnificațiile unui anumit nume sau ale
unei valori specifice care depind de contextul în care se produce inform ația. De
exemplu, numărul de identificare al unui angajat poate transmite informații relevante
cititorilor care cunosc convențiile de numerotare urmărite în acea companie. Aceasta
este informația și subiectul împărtășește același context. Astfel devine cri tică pentru
elaborarea unor tehnici și instrumente eficiente pentru schimbul și integrarea
informațiilor contextului.
3. Conceptul de metadate ocupă o poziție foarte importantă în reconcilierea instanțelor
de date. Ajută la rezolvarea unor informații simil are sau contradictorii în sursa de date.
De exemplu, metadatele ajută la atașarea unui timbru de timp sau a unui nivel de
calitate la datele integrate și astfel de informații sunt utilizate în rezolvarea conflictelor
dintre informațiile stocate în diferite surse de date.
Citirea corecta de către un parser XML precum și încadrarea lui în specificațiile XML
sunt condițiile ce trebuie îndeplinite de un document . Atributele elementelor precum și
descrierea caracteristicilor elementelor se face în tag -ul de înce put al documentului

29
XML. Parserul XML, care este și parte a middleware -ului, extrage date din documente
XML, pe care le pune la dispoziție pentru a fi accesate de un alt program . (Figura)

XML, o tehnologie Web în evoluție, chiar dacă dezavantajoasă din punct de vedere al
mărimii fișierelor text (o informație ce solic ită 512KB se mapează într -un fiș ier de 20
de ori mai mare) contribuie la sarcina de integrare a datelor și reduc e efortul de
reconciliere a surselor de date eterogene , tot procesul fiind auto mat și transparent
pentru utilizator . Există eforturi în desfășurarea unei limbi care poate specifica
semantica asociată conținutului de date. De asemenea, dezvoltarea unor instrumente
adecvate pentru integrarea în XML a surselor eterogene se desfășoară în mod
constant.
XSLT (Extensible Stylesheet Language Transformations) oferă posibilitatea de a
transforma automat datele XML dintr -un format în altul. XSL reprezintă un limbaj de
tip extensibil care este pentru XML ceea ce este CSS pentru HTML.
În cazul unu i document HTML, etichetele sunt predefinite, cum ar fi table, div și span;
iar browser -ul știe cum să le adauge stilul și să le afișeze pe cele care utilizează
stilurile CSS. Dar în cazul documentelor XML, etichetele nu sunt predefinite. Pentru a
înțelege și a schița un document XML, World Wide Web Consortium (W3C) a dezvoltat
XSL, care poate acționa ca limbaj Stylesheet bazat pe XML. Un document XSL
specifică modul în care un browser ar trebui să afișeze un document XML.
Părțile principale ale XSL sunt: XSLT – folosit pentru a transforma documentul XML în
diverse alte tipuri de documente, XPath – folosit pen tru navigarea în documentul XML
și XSL-FO – folosit pentru a formata un document XML.
O foaie de stil XSLT este utilizată pentru a defini regulile de t ransformare care trebuie
aplicate pe documentul țintă XML. Șablonul de stil XSLT este scris în format XML.

30
Procesorul XSLT preia foaia de stil XSLT și aplică regulile de transformare pe
documentul țintă XML și apoi generează un document formatat ca XML, HT ML sau
text. Acest document formatat este apoi utilizat de formatatorul XSLT pentru a genera
ieșirea reală care urmează să fie afișată utilizatorului final.

XSLT prezintă importantul avantaj de a fi i ndependent de programare. Transformările
sunt scrise într -un fișier separat xsl, care este din nou un document XML. Totodată
ieșirea poate fi modificată prin simpla modificare a transformărilor în fișierul XSL.
ebXML (Electronic Business XML) este un proiect care utilizează limbajul extensibil
de ma rcare (XML) pentru a standardiza schimbul securizat de date de afaceri. Printre
alte scopuri, ebXML ar cuprinde și poate înlocui un standard familiar denumit
Electronic Data Interchange (EDI). ebXML este conceput pentru a permite o piață
electronică global ă în care întreprinderile de orice dimensiune și în orice locație ar
putea tranzacționa în condiții de siguranță și în siguranță prin schimbul de mesaje
bazate pe XML. Organismul Organizației Națiunilor Unite pentru facilitarea comerțului
și standardele el ectronice de informare în afaceri (UN / CEFACT) și Organizația pentru
Promovarea Standardelor de Informații Structurate (OASIS) au lansat proiectul ca o
inițiativă comună.
Deoarece ebXML se bazează pe standardele existente ale Internetului, cum ar fi
HTTP , TCP / IP, MIME, SMTP, FTP, UML și XML, acesta poate fi implementat și
implementat pe orice platformă de calcul. Utilizarea standardelor existente oferă
ebXML avantajul de a fi relativ ieftin și ușor de utilizat.
O lucrare albă pe site -ul web oficial ebXM L explică faptul că inițiativa este construită
pe trei concepte de bază: (1) asigură o infrastructură care asigură interoperabilitatea

31
comunicațiilor de date; (2) să ofere un cadru de semantică care să asigure
interoperabilitatea comercială; și (3) să ofer e un mecanism care să permită
întreprinderilor să se găsească reciproc, să fie de acord să devină parteneri comerciali
și să își desfășoare activitatea între ele.
4.3.2 SOAP, WSDL, UDDI
SOAP (Simple Object Access Protocol) este un protocol de mesagerie care per mite
aplicațiilor să apeleze funcții din alte aplicații , acestea putând rula pe sisteme de
operare disparate (cum ar fi Windows și Linux) , comunicarea se realizează utilizând
Hypertext Transfer Protocol (HTTP) și limbajul Extensible Markup Language (XML) ,
fiind totodată standard pentru codificarea mesajelor în XML .
WSDL (Web Language Description Language) este o notație XML pentru
descrierea unui serviciu web. O definiție WSDL îi spune unei aplicații client cum să
compună o solicitare de serviciu web și des crie interfața furnizată de furnizorul de
servicii web. WSDL a fost dezvoltat în comun de Microsoft și IBM.
WSDL este un protocol bazat pe XML pentru schimbul de informații în medii
descentralizate și distribuite.
WSDL este o parte integrantă a UDDI (Univ ersal Description, Discovery, and
Integration) , un registru pentru servicii Web și pentru alte servicii electronice și non –
electronice mondial bazat pe XML și folosit cu preponderență de mediul de afaceri .
WSDL este adesea folosit în combinație cu SOAP și XML Schema pentru a furniza
servicii web prin Internet. Un program client care se conectează la un serviciu web
poate citi WSDL pentru a determina ce funcții sunt disponibile pe server. Toate tipurile
de date speciale utilizate sunt încorporate în fișierul WSDL sub forma Schemei XML.
Clientul poate apoi să utilizeze SOAP pentru a apela efectiv una dintre funcțiile listate
în WSDL.
UDDI este echivalentul Internet al unei agende telefonice, unde se înregistrează
întreprinderile și alte întreprinderi sau consu matori le caută. Un registru UDDI
funcționează în modul următor: un furnizor de servicii își înregistrează afacerea în
registrul UDDI, separat fiecare serviciu oferit; consumatorul de servicii caută afacerea
și serviciile din registrul UDDI și se leagă de furnizorul de servicii și utilizează serviciul.

32

Când UDDI a fost introdus în 2000, rolul său de pilon central al industriei de servicii
web a fost foarte promițător. Actorii majori precum IBM, Microsoft și SAP au investit în
UDDI și au lansat registrele UDDI de afaceri publice (UBDI). La începutul anului 2006,
cele trei companii au anunțat închiderea UBR -urilor publice. În timp ce conceptul de
tehnologie a fost dovedit și versiunile UDDI 2.0 și 3.0 au fost acceptate ca standarde
de către OASIS, motivul pr incipal al închiderii era lipsa suportului de afaceri. Conduita
în afaceri necesită încă o interacțiune umană în faza de contractare. Standardul UDDI
este încă utilizat, în principal în operațiunile interne ale organizațiilor. Au fost introduse
și alte sta ndarde care reglementează interacțiunea cu registrele. Cele mai răspândite
sunt ebXML și Java API pentru registrele XML.
4.4 Tehnologii de integrare – Baze de date centralizate și distribuite
Conform Wikipedia, ”o bază de date , uneori numită și bancă de date ( abreviat BD),
reprezintă o modalitate de stocare a unor informații și date pe un suport extern (un
dispozitiv de stocare), cu posibilitatea extinderii ușoare și a regăsirii rapide a acestora ”.
La prima vedere sarcina poate părea banală. Totuși, în condiții le în care este vorba
de a lucra cu milioane de elemente, fiecare putând consta din cantități de date care
trebuie accesate simultan prin Internet de către mii de utilizatori răspândiți pe întreg
globul; și în condițiile când disponibilitatea aplicației și datelor trebuie să fie
permanentă (de ex. pentru a nu pierde ocazia de a încheia afaceri), soluțiile bune nu
sunt de loc simple.

33
De obicei o bază de date este memorată într -unul sau mai multe fișiere. Bazele de
date sunt manipulate cu ajutorul sistemelor de gestiune a bazelor de date.
Cel mai răspândit tip de baze de date este cel relațional, în care datele sunt memorate
în tabele. Pe lânga tabele, o bază de date relațională mai poate conține: indecși,
proceduri stocate, declanșatori, utilizatori și grupur i de utilizatori, tipuri de date,
mecanisme de securitate și de gestiune a tranzacțiilor etc.
Alte tipuri de baze de date sunt modelul ierarhic, modelul orientat pe obiecte și, mai
nou, modelul XML.”
Un sistem centralizat de baze de date este un sistem car e păstrează datele într -o
singură bază de date într -o singură locație. Într -un sistem de baze de date centralizate,
o singură mașină numită un server de bază de date găzduiește DBMS și baza de date.
Utilizatorii multipli sau stațiile de lucru client pot lu cra simultan într -un sistem
centralizat de baze de date folosind configurația Client / Server sau configurația
Intranet dacă este disponibilă o rețea locală (LAN -urile pot include una sau mai multe
clădiri adiacente), care poate face parte sau nu dintr-o rețea WAN (Wide Area
Network).
Arhitectura client / server este una foarte reușită și populară, deoarece echilibrează
încărcarea de procesar e între mașina client și server .
Creșterea continuă a aplicațiilor Internet și intranet a reorientat atenția asupra b azelor
de date centralizate. Într -o astfel de configurație, cea mai mare parte a prelucrării nu
se află pe mașina client, ci mai degrabă pe mașina ce găzduiește Serverul de aplicații
și mașina serverului de bază de date.
Principalul dezavantaj al sistemelo r de baze de date centralizate este cel al unui singur
punct de eșec. Când baza de date cedează, nu mai este accesabilă sau are erori de
funcționare din diverse motive , munca tuturor utilizatorilor este întreruptă. Cu toate
acestea, atunci când sunt necesa re operațiuni 24×7, există soluții pentru a minimiza
riscul de eșec al serverului bazei de date, cum ar fi utilizarea unui server de cluster.
De asemenea, în cazul în care se utilizează WAN -uri, eșecul unei părți a rețelei
înseamnă întreruperea activității în locația de la distanță.

34
Prin urmare, bazele de date centralizate sunt mai ușor de gestionat, menținute și
controlate în scopuri de securitate. Ar trebui să fie alegerea aleasă dacă nu este
nevoie de o arhitectură mai complexă.
O bază de date distribuit ă este o colecție de baze de date interconectate multiple,
care sunt răspândite fizic în diferite locații care comunică prin intermediul unei rețele
de calculatoare.
Caracteristicile bazelor de date distribuite sunt:
 bazele de date din colecție sunt logic interconectate între ele. Adesea ele
reprezintă o singură bază de date logică.
 datele sunt stocate fizic pe mai multe servere/site -uri. Datele din fiecare site pot
fi gestionate de un DBMS independent de celelalte site -uri.
 procesoarele din site -uri sunt c onectate printr -o rețea. Nu au configurație
multiprocesor.
 bază de date distribuită nu este un sistem de fișiere slab conectat.
 bază de date distribuită include procesarea tranzacțiilor, dar nu este sinonimă
cu un sistem de procesare a tranzacțiilor.
Gesti onarea bazelor de date distribuite este realizată cu un DDBMS (Distributed
Database Management System) – un sistem software centralizat care gestionează o
bază de date distribuită ca și cum ar fi fost stocate într -o singură locație.
Caracteristicile unui D DBMS sunt:
 este folosit pentru a crea, prelua, actualiza și șterge baze de date distribuite.
 sincronizează periodic baza de date și oferă mecanisme de acces în virtutea
cărora distribuția devine transparentă pentru utilizatori.
 se asigură că datele modific ate la orice site sunt actualizate universal.
 este folosit în domenii de aplicații în care volume mari de date sunt procesate
și accesate simultan de numeroși utilizatori.
 este conceput pentru platforme de baze de date eterogene.
 menține confidențialitatea și integritatea datelor bazelor de date.
Următoarele sunt avantajele bazelor de date distribuite asup ra bazelor de date
centralizate:

35
 Dezvoltarea modulară – dacă sistemul trebuie extins la noi locații sau noi unități,
în sisteme de baze de date centraliza te, acțiunea necesită eforturi substanțiale
și perturbarea funcționării existente. Cu toate acestea, în bazele de date
distribuite, lucrarea necesită pur și simplu adăugarea de noi computere și date
locale către noul site și, în final, conectarea acestora la sistemul distribuit, fără
întreruperi în funcțiile curente.
 Mai multă fiabilitate – în caz de eșec al bazei de date, sistemul total al bazelor
de date centralizate se oprește. Cu toate acestea, în cazul sistemelor
distribuite, atunci când o componentă e șuează, funcționarea sistemului
continuă să aibă o performanță redusă. Prin urmare, DDBMS este mai fiabil.
 Răspuns mai bun – dacă datele sunt distribuite într -o manieră eficientă, atunci
cererile utilizatorilor pot fi întâlnite chiar din datele locale, ofe rind astfel un
răspuns mai rapid. Pe de altă parte, în sistemele centralizate, toate interogările
trebuie să treacă prin serverul central pentru prelucrare, ceea ce sporește
timpul de răspuns.
 Cost redus de comunicare – în sistemele de baze de date distrib uite, în cazul
în care datele sunt localizate la nivel local unde sunt utilizate în cea mai mare
parte, atunci costurile de comunicare pentru manipularea datelor pot fi reduse
la minimum. Acest lucru nu este fezabil în sistemele centralizate.
Dezavantaje a le bazelor de date distribuite pot fi următoarele:
 Nevoia de software complex și costisitor – DDBMS cere software complex și
adesea costisitor pentru a asigura transparența și coordonarea datelor în cadrul
mai multor site -uri.
 Durata procesării foarte mar e – chiar și operațiunile simple pot necesita un
număr mare de comunicații și calcule suplimentare pentru a asigura
uniformitatea datelor pe toate site -urile.
 Integritatea datelor – necesitatea actualizării datelor în mai multe site -uri
prezintă probleme d e integritate a datelor.
 Timp mare de răspuns în cazul distribuir ii necorespunzătoare a datelor –
reactivitatea interogărilor depinde în mare măsură de distribuirea corectă a
datelor. Distribuția necorespunzătoare a datelor duce adesea la un răspuns
foarte lent la solicitările utilizatorilor.

36
Apărută în 2008, odată cu lansarea lucrării „Bitcoin: un sistem electronic de numerar
de tip peer -to-peer” ( Satoshi Nakamoto), t ehnologia Blockchain (BCT) este de fapt o
bază de date :
 publică (to ți membrii re țelei resp ective au acces la ea);
 distribuită (datel e nu sunt stocate pe un server);
 actualizată continuu;
 securizată criptografic.
BCT utilizează o combinație de tehnologii care au o istorie considerabilă în domeniul
informaticii și al aplicațiilor comerciale. Aces te tehnologii componente includ
criptografia cheilor publice / private, funcțiile hash criptografice, tehnologii aferente
baze lor de date, în special bazele de date distribuite, algoritmii de consens și
prelucrarea descentralizată. Scopul fundamental este de a realiza coerența și
integritatea bazelor de date într -un context al unei baze de date descentralizate
distribuite.

37
5 Raportare / Instrumente de raportare
Un raport generat de o bază de date este rezultatul coerent al interogărilor bazei de
date și co nține date utile pentru analiză și, ulterior , pentru luarea deciziilor.
O caracteristică importantă a unui sistem de BI este reprezentată de componenta de
raportare . Pentru utilizatorul final (organizație sau individ), eficiența și performa nța
unui sistem B I sunt date de rapoartele pe care le generează. Abilitatea de a produce
informații care să contribuie la procesul de luare a deciziilor este un atribut cheie
pentru acest tip de sistem. Majoritatea soluțiilor oferă șabloane de rapoarte multiple,
în timp ce altele oferă posibilitatea de a crea rapoarte specifice și salva aceste rapoarte
ca șabloane de la care să se poat ă genera rapoarte specifice.
În faza de alegere/proiectare a unei soluții BI, configurarea componentei de raportare
se baze ază pe cerințe, ple cându -se de la acestea vor fi elaborate a tât strategia de
raportare cât ș i modelele de rapoarte. Strategia de implementare a acestei
componente presupune alegerea includerii rapoartelor într -o aplicație separată sau
includerea lor în aplicația operațională . Logica impleme ntării raportării se bazează atât
pe tehnologia folosită cât și pe regulile de selecție a informațiilor ce apar în rapoarte.
Microsoft Power BI este o suită de instrumente de analiză a afacerilor pentru a prelucra
date și a partaja informați i. Power BI poate unifica toate datele unei organizații, în
cloud sau local. Utilizând gateway -urile Power BI, se pot conecta baze de date SQL
Server, modele Analysis Services (Microsoft OLAP) și multe alte surse de date la
aceleași tablouri de bord în Pow er BI. Power BI pentru Office 365 este un serviciu
bazat pe cloud care permite utilizatorilor să creeze și să partajeze rapoarte foarte bine
realizate tehnic și vizual precum și interogările de date pe baza cărora rapoartele au
fost generate. Integrat cu M icrosoft Excel, Power BI face posibilă consolidarea
informațiilor dintr -o gamă largă de surse și combinarea acestora în conținut pe care
utilizatorii îl pot accesa, colaborarea fiind asigurată prin accesarea rapoartelor într -un
portal central din cloud. În centrul Power BI se află datele care generează conținutul.
Platforma SQL Server Reporting Services (SSRS) , este o tehnologie Microsoft SQL
Server folosită pentru crearea, implementarea și gestionarea rapoartelor la nivelul
întregii organizații și care per mite utilizarea unei mari variet ăți de surse de date . Cu

38
acest element fundamental, dezvoltatorii pot crea rapoarte interacționale, tabulare,
grafice sau libere din surse de date relaționale, multidimensionale sau bazate pe XML.
SSRS poate rula pe o mașină server de rapoarte. Un server de raportare stochează
intern elemente cum ar fi rapoartele paginate precum și în variantă accesibilă la citirea
de pe mijloace mobile, articolele legate de raport și resursele. Un server de rapoarte
poate fi configurat ca un singur server autonom sau ca o fermă de tip scale out sau
poate fi integrat cu SharePoint Server. Interacțiunea cu elementele serverului de
rapoarte se poate face prin intermediul Reporting Services Web service, WMI
(Windows Management Instrumentation) , acces URL sau prin intermediul scripturilor.
Modul de interacți une cu un server de rapoarte depinde de configurația sistemului și
de topologia implementării .
Rapoartele sunt create folosind Report Builder (constructor de rapoarte ) sau Report
Designe r. Repo rt Builder asigură proiectarea și construcția completă a rapoartelor.
Dispune de o interfață de utilizator similară cu cea a Microsoft Word sau Microsoft
Excel, ceea ce constituie un avantaj pentru utilizatorii familiarizați cu aceste produse.
Report Desig ner, face parte din SQL Ser ver Data Tools și Visual Studio și acceptă, de
asemenea, toate caracteristicile serviciului de raportare. În plus, furnizează
instrumente de organizare a proiectelor și de gestionare a codurilor sursă pentru cei
care raportează p roiecte care au un ciclu de viață similar celui al unui proiect de
dezvoltare software (controlul versiunii, check -in / check -out etc.) . Cele două medii
menționate conțin tot ceea ce este necesar pentru a crea o gamă largă de rapoarte .
Fiecare raport Repor ting Services conține două seturi distincte de instrucțiuni care
determină ce va conține raportul :
 primul set de instrucțiuni este data definition (definiția datelor ), care control ează
sursa de unde provin datele din raport și ce informații vor fi selectat e din acele
date;
 cel de-al doilea este report layout (structura raportului ), care controlează modul
în care informațiile vor fi prezentate pe ecran sau pe hârtie.
Ambele seturi de instrucțiuni sunt stocate utilizând limbajul de definire a raportului
(RDL ).

39

Data definition conține două părți: sursa de date și setul de date . Sursa de date este
serverul de date sau fișierul de date care furnizează informațiile pentru raport, aceasta
nu este inclusă în raport. Ceea ce este inclus este setul de instrucțiuni prin care
raportul trebuie să aibă acces la sursa de date respectivă. Aceste instrucțiuni includ
următoarele:
 tipul sursei utiliza te, care poate fi de exemplu, Microsoft SQL Server, Oracle,
DB2, Informix sau Microsoft Access , etc. . SSRS utilizează aceste informații
pentru a determina modul de comunic are cu sursa de date ;
 numele serverului bazei de date sau calea către fișierul de date ;
 numele bazei de date ;
 autentificarea pentru conectarea la această sursă de date, dacă este necesară
o autentificare.
Când raportul este executat, acesta utilizează instrucțiunile sursei de date conținute
în raport pentru a obține acces la sursa de date. Extrage apoi informațiile din sursa de
date într -un format nou care poate fi utilizat de raport. Acest nou format este num it set
de date.
Conținutul setului de date este definit utilizând un instrument denumit Query Designer
(designer de interogări ). Query Designer facilitează crearea unei interog ări a bazei de
date. Interogarea bazei de date poate fi în limbajul de interoga re Transact -Structured
Query Language (T -SQL), pentru interogarea datelor relaționale, limbajul

40
Multidimensional Expression (MDX) pentru interogarea datelor multidimensionale sau
limbajului Expression Mining Data (DMX) pentru interogări de extragere a date lor.
Interogarea furnizează instrucțiuni sursei de date, indicând datele de selecta t pentru
generarea raportul ui. Interogarea este stocată în raport ca parte a Data Definition .
Datele selectate de interogare în setul de date constau în rânduri și coloane. Rândurile
corespund înregistrărilor selectate de interogare din sursa de date. Coloanele
corespund câmpurilor selectate de interogare din sursa de date. Interogările din MDX
sunt aplatizate într -un tabel cu rânduri și coloane . Informațiile despre câmpur ile care
urmează să fie selectate pentru setul de date sunt stocate în raport ca parte a Data
Definition . Numai informațiile despre cum vor fi denumite câmpurile și tipul de date pe
care acestea le vor păstra sunt stocate în Report Layout . Datele reale nu sunt stocate
în Report Layout , ci sunt selectate din sursa de date atunci când raportul este rulat.
Report Layout (structura raportului ) reprezintă setul de instrucțiuni care se ocupă de
aspectul raportului. Datele pe care raportul le -a extras într -un set de date nu sunt de
mare folos decât dacă se prezintă într -o modalitate accesibilă utilizatorului. Report
Layout conține instrucțiuni care stabilesc unde se vor amplasa câmpurile pe ecran
sau pe hârtie. De asemenea, prin intermediul acestuia se vor adăuga elemente
precum titluri, subtitluri , etichete și numere de pagini. Toate acestea formează
structura raportului. În majoritatea cazurilor, aspectul raportului include o zonă
specială care interacționează cu setul de date. Această zonă specială este cunoscu tă
ca regiune de date . O regiune de date afișează toate rândurile din setul de date prin
repetarea unei secțiuni a Report Layout pentru fiecare rând.
Instrucțiunile din data definition și report layout sunt stocate utilizând limbajul Report
Definition Lan guage (RDL), care este o adaptare a limbajului XML proiectată de
Microsoft special pentru stocarea definițiilor raportului . Aceste definiții includ
instrucțiunile sursei de date, informațiile de interogare care definesc setul de date și
aspectul raportului (report layout).

41
6 Sisteme complexe de BI
Organizațiile de astăzi pot alege dintr -o listă robustă de furnizori care oferă
instrumente BI. Platforma Gartnervii identifică aproape două duzini de furnizori de BI
și de analiză în raportul său din 201 7 Magic Quadrant, care menționează Microsoft,
Qlik și Tableau ca lideri. Alți furnizori de instrumente BI includ constructorii de
informații, Sisense și Zoomdata.
O enumerare succinta a soluțiilor BI la care organizațiile pot recurge ar putea cuprinde
Domo, Tabl eau Desktop, Looker, SAP, Microsoft Power BI, Qlik Sense Enterprise,
Zoho s.a.m.d.
Tableau este adesea privit ca marele maestru al software -ului de vizualizare a datelor
și aceasta foarte bine motivat. Tableau are o bază de clienți foarte mare de aproximat iv
57.000 de conturi în multe industrii datorită simplității sale în utilizare și a capacității
de a produce vizualizări interactive mult mai optime decât cele oferite de soluțiile
generale BI. Totodată este potrivit pentru manipularea seturilor de date ur iașe și care
se schimbă / înnoiesc foarte rapid, care sunt utilizate în operațiunile Big Data, inclusiv
aplicațiile de inteligență artificială și de învățare automată, datorită integrării cu un
număr mare de soluții avansate de baze de date, inclusiv Hadoo p, Amazon AWS, My
SQL , SAP și Teradata. Cercetarea extensivă și testarea intensivă permit Tableau să
creeze grafice și vizualizări cât mai eficient și cât mai user -friendly posibil.
Qlik cu instrumentul Qlikview este celălalt jucător important în acest sp ațiu și cel mai
mare concurent al lui Tableau. Furnizorul are peste 40.000 de conturi de client în peste
100 de țări, iar cei care o utilizează citează în mod frecvent configurația foarte
personalizabilă și gama largă de funcții ca un avantaj cheie. În plu s față de
capabilitățile de vizualizare a datelor, Qlikview oferă o puternică abilitate în BI, în
analiza de afaceri precum și capabilități foarte bine optimizate de raportare , toate
acestea beneficiind de o interfață curată și bine structurată. Qlikview este folosit în
mod obișnuit alături de Qliksense, care gestionează explorarea și gestionarea datelor.
Există, de asemenea, o comunitate puternică și există o mulțime de resurse terțe
disponibile online pentru a ajuta noii utilizatori să înțeleagă cum să i ntegreze proiectele
lor.

42
FusionCharts este un pachet de elaborare de grafice și vizualizare bazat pe
JavaScript, foarte utilizat pe scară largă. Acesta poate produce 90 de tipuri diferite de
diagrame și se integrează cu un număr mare de platforme și aplica ții care oferă o mare
flexibilitate.
Highcharts , la fel ca și FusionCharts, necesită și o licență pentru uz comercial, deși
poate fi folosit în mod liber ca trial ori în versiune non -comercială sau pentru uz
personal. Producătorul susține că este utilizat de 72 dintre cele mai mari 100 de
companii din lume și este adesea ales atunci când trebuie să fie lansată o soluție
rapidă și flexibilă, cu o nevoie minimă de formare și specializare a utilizatorilor .
Datawrapper devine din ce în ce mai populară, în speci al printre organizațiile media
care o folosesc frecvent pentru a crea grafice și a prezenta statistici. Are o interfață
simplă și clară, care face foarte ușor încărcarea datelor csv și crearea de diagrame
simple și, de asemenea, hărți, care pot fi rapid în corporate în rapoarte.
Plotly permite vizualizări mai complexe și sofisticate, datorită integrării sale cu limbaje
de programare orientate spre analiză, cum ar fi Python, R și Matlab. Este construit pe
baza bibliotecilor de vizualizare d3.js open source pe ntru JavaScript, dar beneficiază
de layere user friendly, precum și suport integrat pentru API -uri cum ar fi Salesforce.
Sisense oferă o platformă de analiză full stack, dar capabilitățile sale de vizualizare
oferă o interfață drag and drop, care permite d iagrame și grafică mai complexă,
precum și vizualizări interactive, care pot fi create cu un minim de cunoștințe. Permite
conectarea la mai multe surse de date într -un depozit ușor accesibil, care poate fi
interogat instantaneu prin tablouri de bord (dashb oard), chiar și în seturi de dimensiuni
mari. Tablourile de bord pot fi apoi împărțite între organizații, asigurând acces facil în
utilizare chiar și personalului nespecializat.
Organizațiile aleg în general platforma BI bazâdu -se pe diverși factori, inclu siv
mărimea și complexitatea activității lor, precum și ce tip de tehnologie dețin deja (IBM,
Oracle, SAS, SAP – toate oferă instrumente BI). Totodată, pot alege dintre soluțiile
existente pe piață, sau pot recurge la un producător pentru a obține o soluți e total
customizată nevoilor lor.

43
Instrumentele de „business intelligence ” simplifică efortul depus in procesele de
căutare, interpretare, concatenare și interog are a datel or pentru a obține diverse
informații necesare. Plecând de la această utilitate majo ră, posibilitățile de utilizare
pentru BI se pot extinde dincolo de domeniul afacerilor (unde le putem regăsi, de
exemplu cu rol de îmbunătățire a vânzărilor și de optimizare a costuri lor), având
aplicabil itate și în alte domenii. De exemplu , sistemul școl ar din Columbus – Ohio
(SUA) are implementat cu succes un sistem de instrumente BI pentru a examina
numeroase pachete de date – de la rata de participare la cursuri și până la
performanțe le studenților – pentru a îmbunătăți cursurile de învățare a studenți lor și a
absolvenților de liceu2.
Un alt exemplu de aplicare cu succes a unui sistem BI complet sau par țial este în
domeniul administrației locale. În 2014, oficialii orașului Fayetteville – Statul Carolina
de Nord (SUA) au început proiectarea unui sistem de management al performanței,
denumit TRACStat, Rapoarte transparente și Analytics pentru cetățeni, pentru a
urmări eficiența și calitatea programelor sale , ca mijloc de a oferi cele mai bune servicii
municipale posibile cetățenilor și vizitatorilor săi, precum și de a face transparente
toate operațiunilor sale. TRACStat a făcut parte din tranziția orașului la un proces de
programare bazat pe buget cu managementul performanței.
Fayetteville a lansat TRACStat folosind platforma de BI – BOARD pentru a colect a,
analiza și raporta datele de performanță ale orașului. Orașul încarcă, de asemenea,
date privind bugetul în sistem care se îmbină cu datele de performanță , datele
combinate rezultate fiind folosite pentru a crea automat prezentarea bugetului anual
al orașului. Orașul a dezvoltat o echipă de analiză a datelor la nivel de oraș pentru a
furniza suport și elaborarea de îndrumări specifice.
Pe plan intern, TRACStat permite administrației Fayetteville să colecteze datele
efective de perf ormanță din toate depar tamentel e. Se mențin date istorice, permițând
directorilor departamentelor să identifice tendințele și să ia măsurile corespunzătoare
pe baza acestora și să optimizeze performanța operațională.

2 Cindi Howson, vicepreședinte Gartner Group – termenul de “business int elligence” a fost introdus de
către Gartner Group la mijlocul anilor '90

44
Pe plan extern, portalul TRACStat oferă rezidenților și aleși lor oficiali diferite nivele de
detaliu privind performanța organizațională a orașului. Cetățenii au acces la
instantanee la nivel înalt privind modul în care Fayetteville îndeplinește obiectivele
strategice și bugetul orașului și poate analiza datele deta liate privind măsurile
specifice, toate printr -un portal web ușor de navigat, care extrage date din aplicațiile
TRACStat dezvoltate și care rulează pe Platforma BOARD (portalul poate fi accesat
la adresa: http://board.fayettevillenc.gov/#/screen/Public%5CTRACStat.cpsx –
figura ).

Pentru viitor specialiștii de la Gartner prevăd un al treilea val de modificări și adaptări ,
ceea ce firma de cercetare numește "analiză augmenta tă", în care procesul de
învățare a mașinilor este cuprins în software și va ghida utilizatorii asupra interogărilor
lor în date: "Va fi BI și analiză, și va fi inteligent".
Combinațiile incluse în aceste platforme software vor face fiecare funcție mai put ernică
individual și mai valoros pentru oamenii de afaceri care le utilizează. "Cineva se va
uita la rapoarte, de exemplu, din vânzările de anul trecut – asta este BI – dar vor obține
și previziuni despre vânzările de anul viitor – analiză previzionară de afaceri – și apoi
vor adăuga la această capacitate ce -ar fi: Ce s -ar întâmpla dacă se va acționa în
direcția X în loc de Y? "(Michael Gorman – Gartner) , explicând u-se faptul că

45
producătorii de software se deplasează pentru a dezvolta aplicații care vor ofer i aceste
funcții într -o singură aplicație, mai degrabă decât să le livreze pe mai multe platforme,
așa cum este acum.
Raportul Magic Quadrant al companiei Gartner prevede că, până în 2020, organizațiile
care oferă utilizatorilor accesul la un catalog cuant ificat de date interne și externe își
vor dubla cifra de afaceri din investițiile de analiză decât cele care nu au această ofertă
de servicii în portofoliu .
Pornind de la faptul ca un sistem BI po ate fi folosit integral sau parțial î n diverse
domenii de ac tivitate, așa cum am arătat mai sus, pe lângă domeniile de business se
pot regăsi implementate și funcționând cu succes și în domenii precum educația,
administrația publică, sănătate, ONG -uri – activități caritabile, etc.
Prezenta lucrare prezintă un model de folosire parțială a unui sistem BI, mai precis
utilizarea instrumentelor de raportare aferente BI ca SOLUȚIE DE VIZUALIZARE A
DATELOR FURNIZATE DE PLATFORME NEOMOGENE CU APLICAȚIE IN HR.

46
7 Aplicație
7.1 Motivare.Soluții.Utilitate
Angajații sunt cel mai imp ortant activ în cadrul unei companii, privată sau de interes
public. Abilitatea unei organizații de a analiza datele privind capitalul uman îi permite
acesteia să mențină o forță de muncă diversă și echilibrată, în timp ce se străduiește
să-și păstreze ang ajații.
Această analiză trebuie sa pornească încă de la debutul angajatului în activitatea din
acea organizație, ba chiar și mai devreme, încă din timpul procesului de recrutare.
Thomas Siebel, fondatorul Siebel (acum Oracle) a fost citat într -un intervi u:
"Organizațiile pot economisi o mulțime de bani atunci când date valoroase stocate în
întreaga organizație în silozuri separate pot fi integrate și combinate".
Totodată, prin accesul la soluții BI în domeniul resurselor umane, se asigură
acuratețea infor mațiilor cu privire la viitorii angajați și în plus, se eficientizează timpii
în colectarea și prelucrarea datelor, atât de către persoanele care au nevoie de aceste
date (manageri, responsabili recrutare, salarizare și administrare personal ), dar și de
către angajaț ii care trebuie să pună la dispoziția organizației informațiile respective .
După intrarea într -o organizație noul angajat trebuie să prezinte o serie de documente,
ceea ce generează consum de timp și resurse financiare. Lipsa acestor docum ente
poate crea o breșă în fișa angajatului. Uneori companiile sunt nevoite să acopere
poziții diverse determinând candidatul sau angajatul să procedeze la demersuri
cronofage. În cel mai negativ scenariu angajatul nu poate prezenta documentele
solicitate în timp util, iar organizația este nevoită să își asume riscul încadrării fără a
avea siguranța că persoana este potrivită, de exemplu lipsa unui cazier judiciar ar
putea să constituie o problemă extrem de delicată pentru anumiți angajatori.

47

i S. Chaudhuri, U. Dayal, V. Ganti. Database Technology for Decision Support Systems. I n IEEE
Computer 34(12), pp. 48 -55, December 2001.
ii Sciore E, Siegel M, Rosenthal A. Using semantic values to facilitate interoperability among
heterogeneous information systems. ACM Transactions on Database Systems. 1994;19(2):254 –90.
iii Gruber TR. Toward principles for the design of ontologies used for knowledge sharing. International
Journal of Human -Computer Studies. 1995;43(5 –6):907 –28
iv Rahm E, Bernstein PA. A survey of approaches to automatic schema matching. VLDB Journal.
2001;10(4):334 –50.
v Noy NF, Musen MA. PromptDiff: A fixed -point agorithm for comparing ontology versions. The
Eighteenth National Conference on Artificial Intelligence (AAA I -02); August, 2002; Edmonton,
Canada.
vi P. Vassiliadis, A. Simitsis. Near Real Time ETL. In Springer Annals o f Information Systems, Vol. 3,
pp. 19 -29, 2008.
vii Magic Quadrant for Business. Intelligence and Analytics Platforms. Published: 16 February 2017.
Analyst(s): Rita L. Sallam, Cindi Howson, Carlie J. Idoine, Thomas W. Oestreich, James Laurence
Richardson, Jo ao Tapadinhas