Ministerul Educatiei și Cercetării al Republicii Moldova

Universitatea Tehnica a Moldovei

Facultatea Calculatoare, Informatica și Microelectronica
Departament Informatică şi Ingineria Sistemelor

LABORATOR NR.2

RAPORT
La disciplina: MBDC

PRIVIND EFECTUAREA LUCRĂRII DE LABORATOR

BD STRUCTURATE
PROIECTAREA BDO SI DWH PENTRU SARCINA:

Elaborarea design-ului BD Operaționale (BDO), aplicației WEB/Desktop, iar în

baza ei și DWH/DD pentru subiectul ce urmează: “Managementul companiei
internaționale de transport de mărfuri” și elaborarea pentru DWH/DD o aplicație Desktop
sau o aplicație Web de suport a procesului decizional, utilizând: pentru BDO, unul din
SGBD-uri MySQL, platformele integrate, XAMPP, aplicației-web PhpMyAdmin, precum și
HTML, CSS, PHP, JavaScript, utilizînd abordarea MVC, framework-ul: Code Igniter
(Laravel sau altul după caz) și MS SQL Server 2017, 2019 pentru DWH, si limbajele de
programare PHP, C#, Python, mediile integrate Visual Studio, Deductor ș.a., pentru
realizarea instrumentelor Business Intelegense sau Data Mining, pentru entitățile abilitate cu
dreptul de decizie in procesul de management a domeniului economic menționat.

A realizat: st. gr. MAI-211M

ECHIPA NR. 5

A verificat: conf. univ., dr. Perebinos Mihail

Chișinău 2021
Cuprins:

Capitolul 2. Proiectarea și crearea unui Depozit de Date...........................................................3

2.1. Formularea sarcinii si scopului Proiectului pentru crearea unui SI a sarcinii abordate.
Formularea cerințelor de bază...................................................................................................3

2.2. Elaborarea proiectului BDO pentru sarcina abordată. Schema ER a BDO....................4

2.2.1. Descrierea succintă a etapelor procesului de modelare si creare a BDO pentru
sarcina abordată..................................................................................................................4
2.2.2. Modelul conceptual. Diagrama MC.......................................................................7
2.2.3. Modelul logic al BDO prin abordarea „DE SUS IN JOS”/”OUTPUT – INPUT”.
Diagramele modelelor logice si fizice ale BDO. Schema ER............................................9

2.3. Elaborarea Proiectului DWH pentru sarcina abordată...................................................10

2.3.1. Descrierea succintă a etapelor procesului de modelare si creare a unui DWH
pentru sarcina abordată....................................................................................................11
2.3.2. Despre schema de prezentare a DWH de tip “stea”.............................................12
2.3.3. Modelarea multidimensională a DWH. Tabele de dimensiuni.............................13
2.3.4. Crearea tabelului de fapte pentru DWH...............................................................13
2.3.5. Prezentarea diagramei ER a schemei modelului DWH........................................14

2.4. Procesul ETL în cadrul unui DWH.................................................................................15

2.5. Concluzii...........................................................................................................................16

Bibliografie..............................................................................................................................17
 Capitolul 2. Proiectarea și crearea unui Depozit de Date
În acest capitol vor fi descrise etapele de conceptualizare, creare și modelarea a unei
baze de date operaționale, care, în continuare, va simplifica procesul de creare a unui depozit
de date. Astfel încât având drept punct de pornire o bază de date, poate constitui un bun start
pentru creare unui depozit. De asemenea această metamorfoză va permite înțelegerea mai
bună a unor diferențe dintre aceste două formate de stocare a datelor.
Tema proiectului fiind compania internațională de transport de mărfuri, scopul și
sarcina acestuia vor fi concepute în corespondență cu necesitățile acestui domeniu. Pașii
principali pentru proiectare sunt modelarea conceptuală, logică și fizică. Aceștia definesc
cursul viitor al proiectului.

2.1. Formularea sarcinii si scopului Proiectului pentru crearea unui SI a

sarcinii abordate. Formularea cerințelor de bază
Sarcina și scopul proiectului sunt vectorii care definesc traiectoria pentru dezvoltarea
unui sistem informațional. Aceștia sunt pilonii care sprijinesc întregul proiect și care definesc
lucrul care urmează să fie îndeplinit.
Aria de dezvoltare a proiectului este Managementul companiei internaționale de
transport a mărfurilor, un domeniu foarte vast care oferă un potențial mare, în special în ceea
ce ține veniturile.
Astfel, sarcina proiectului constă în dezvoltarea unei aplicații soft pentru colectarea,
stocarea și gestionarea datelor într-un depozit de date pentru o companie de transport
internațional de mărfuri, oferind cele mai importante funcții, orientate pe utilizatori de
business cum ar fi raportarea analitică.
Iar scopul este simplificarea procesului de luare a deciziilor la fel și optimizarea
resurselor și veniturilor cu ajutorul unui depozit de date în cadrul companiei internaționale de
transport a mărfurilor, folosind modelarea multidimensională a datelor și analiza acestora cu
ajutorul OLAP.
Cerințele pentru sistemul informațional sunt următoarele:
1. Integrarea depozitului de date și a unui BDO (operații CRUD, stocarea
informațiilor, etc);
2. Interfața grafică orientata pe utilizator, interactivitate;
3. Prezentarea convenabilă a informațiilor (în format de text, grafice, imagini,
etc.)
 4. Viteză mare de execuție a interogărilor;
5. Integrarea unui sistem de securitate;
6. Sistem informatic fiabil.
Având în vedere sarcina, scopul și cerințele către sistem este posibilă crearea unui
baze sau a unui depozit de date. Etapele procesului de conceptualizare, creare și modelare a
acestora va fi descris în următorul paragraf.

2.2. Elaborarea proiectului BDO pentru sarcina abordată. Schema ER a BDO

Baza de date operațională este sursa de informații pentru depozitul de date. Include
informații detaliate utilizate pentru a rula operațiunile zilnice ale afacerii. Datele se modifică
frecvent pe măsură ce se fac actualizări și reflectă valoarea curentă a ultimelor tranzacții.
O diagramă de relații de entități (ER) arată relațiile seturi de entități stocate într-o
bază de date. O entitate în acest context este un obiect, o componentă a datelor. Un set de
entități este o colecție de entități similare. Aceste entități pot avea atribute care îi definesc
proprietățile.

2.2.1. Descrierea succintă a etapelor procesului de modelare si creare a BDO

pentru sarcina abordată
Procesul de modelare și creare a unei baze de date operaționale constă din 5 etape de
bază. Aceste etape vor fi descrise mai jos.
Etapa I. Formularea problemei. În această etapă, se formează sarcină si scopul
pentru creare bazei de date pentru sarcina abordată.
Sarcina proiectului constă în dezvoltarea unei aplicații soft pentru colectarea,
stocarea și gestionarea datelor într-un depozit de date pentru o companie de transport
internațional de mărfuri, iar scopul este simplificarea procesului de luare a deciziilor la fel și
optimizarea resurselor și veniturilor cu ajutorul unui depozit de date în cadrul companiei
internaționale de transport a mărfurilor.
Etapa II. Modelare. Modelarea datelor este un pas important în construirea unei
baze de date care să funcționeze bine. Pentru ca o bază de date să facă față oferirii afacerii cu
informațiile de care are nevoie, este nevoie de un design bun și de o bază solidă, un model de
date. Modelarea datelor este un pas critic în construirea unei baze de date.
Modelul de date reprezintă informații de afaceri. Dacă există defecte în modelul de
date, atunci defecte vor apărea atât în baza de date în sine, cât și în toate programele care o
accesează. Modelul de date și baza de date în sine ar trebui concepute pentru a oferi
flexibilitate și extensibilitate.

Tabel 2.1. Etapele de modelare a unei BDO

Etapa Scopuri Pași de bază Noțiuni de Prezentarea
principale bază informației
Modelare Colectarea, - Studierea domeniului sub- Entități, Analist
conceptuală analizarea și iectului, colectarea de infor- atribute,
editarea mații despre structura sa conexiuni
cerințelor de informațională;
date - Identificarea tuturor frag-
mentelor din domeniul sub-
iectului, fiecare dintre
acestea fiind caracterizată de
o vizu-alizare a
utilizatorului, obiec-te
informaționale și conexiuni
între ele, procese peste ob-
iecte informaționale;
- La sfârșitul acestei etape,
este obținut un model con-
ceptual – o diagramă ER
care este invariabilă cu
structura bazei de date.
Modelare Conversia - Diagrama ER este conver- Tabele, Programator
logica cerințelor de tită într-un set de tabele; înregistrări,
date în - Este obținută o structură elemente
structuri de de baze de date orientată de date,
date spre SGBD și specificații ale relațiile
programelor de aplicație; dintre
- Bazele de date sunt adesea înregistrări
modelate în raport cu diferite
SGBD-uri și se efectuează o
analiză comparativă a
modelelor.
Modelare Determinarea - Adaptarea modelului logic Gruparea Administrator
fizică caracteristicilor la platforma software aleasă; datelor,
de stocare a - Selectarea şi construirea indici,
datelor, indicilor; metode de
metodelor de - Organizarea jurnalelor, acces
acces la date accesului la date etc.
etc.
 Etapa III. Alegerea modalităților de prezentare a informațiilor și a
instrumentelor software. După crearea modelului, este necesar, în funcție de produsul
software selectat, să se determine forma de prezentare a informațiilor. În majoritatea SGBD-
urilor, datele pot fi stocate în două forme:
1. utilizarea formularelor;
2. fără a folosi formulare.
Un formular este o interfață grafică creată de utilizator pentru introducerea datelor
într-o bază de date.
Etapa IV. Sinteza unui model computerizat al unui obiect. În procesul de creare
a unui model de computer, pot fi distinse unele etape care sunt tipice pentru orice SGBD.
Pasul 1. Pornirea SGBD, crearea unui nou fișier de bază de date sau deschiderea
unei baze de date create anterior.
Pasul 2. Crearea tabelului sau tabelelor sursă – la crearea tabelul original, trebuie
specificate numele și tipul fiecărui câmp. Numele câmpurilor nu trebuie repetate în același
tabel. În procesul de lucru cu baza de date, tabelul poate fi completat cu câmpuri noi. Tabelul
creat trebuie salvat dându-i un nume unic în cadrul bazei de date care este creată.
La proiectarea tabelelor, se recomandă să fie luate în considerație următoarele
principii de bază:
1. Informațiile din tabel nu trebuie duplicate. Nu ar trebui să existe repetări între
tabele. Când anumite informații sunt stocate într-un singur tabel, atunci acestea
vor trebui modificate doar într-un singur loc. Acest lucru face munca mai
eficientă și, de asemenea, elimină posibilitatea nepotrivirii informațiilor în
diferite tabele. De exemplu, un tabel ar trebui să conțină adrese și numere de
telefon ale clienților.
2. Fiecare tabel trebuie să conțină informații despre un singur subiect. Informațiile
despre fiecare subiect sunt mult mai ușor de procesat dacă sunt conținute în
tabele care sunt independente unele de altele. De exemplu, este mai bine de
stocat adresele clienților și comenzile în tabele diferite, astfel încât atunci când
comanda este ștearsă, informațiile despre clienți să rămână în baza de date.
3. Fiecare tabel trebuie să conțină câmpurile obligatorii. Fiecare câmp dintr-un
tabel trebuie să conțină informații separate despre subiectul tabelului. De
exemplu, un tabel cu date despre clienți poate conține câmpuri cu numele
companiei, adresa, orașul, țara și numărul de telefon. La proiectarea câmpurilor
 pentru fiecare tabel, trebuie reținut că fiecare câmp trebuie să fie asociat cu
subiectul tabelului. Nu este recomandată includerea date în tabel care sunt
rezultatul unei expresii. Tabelul trebuie să conțină toate informațiile necesare.
Informațiile ar trebui să fie împărțite în cele mai mici unități logice (de exemplu,
câmpurile Prenume și Nume, nu câmpul general Nume).
4. Baza de date trebuie să aibă o cheie primară. Acest lucru este necesar pentru ca
DBMS să poată lega date din tabele diferite, de exemplu, date despre un client și
comenzile sale.
Pasul 3. Crearea formularelor de ecran – inițial, trebuie specificat tabelul pe baza
căruia va fi creat formularul. Poate fi creat folosind instrumentului de formulare, specificând
ce fel ar trebui să aibă, sau pe cont propriu. Numele formularului poate fi același cu numele
tabelului pe baza căruia a fost creat. Formularul creat poate fi editat prin modificarea locației,
mărimii și formatului câmpurilor.
Pasul 4. Completarea bazei de date. Procesul de completare a bazei de date poate fi
efectuat în două forme: sub formă de tabel și sub formă de formular. Câmpurile numerice și
text pot fi completate ca un tabel, în timp ce câmpurile MEMO și OLE pot fi completate ca
un formular.
Etapa V. Lucrul cu baza de date creată. Lucrul cu baza de date include
următoarele acțiuni:
- căutarea informațiilor necesare;
- sortarea datelor;
- selectarea datelor;
- imprima;
- modificarea și adăugarea datelor.
Având scopul și sarcina proiect, în continuare se poate purcede la crearea modelului
conceptual.

2.2.2. Modelul conceptual. Diagrama MC

Unul dintre momentele cheie în crearea depozitului de date este identificarea și
stabilirea datelor de care va fi nevoie în procesul de analiză și structurarea lor într-un mod cât
mai eficient pentru lucru. Structurarea se face reieșind din mai multe aspecte, inclusiv trebuie
să se țină cont de aplicația cu care se va lucra și posibilitățile oferite de aceasta. Modelul
conceptual al bazei de date este instrumentul ce stabilește la nivel înalt tabelele necesare de
interacțiune pentru reprezentarea tuturor datelor.
 În continuare, luând in considerare importanța problemei studiate, precum si
complexitatea ei, va fi descris domeniului de studiu după cum urmează:
- Producători este subdomeniul de bază care definește prin sine identitățile
producătorilor de mărfuri, caracteristicile generale referitoare la locație,
marfa produsă și volum produs.
- Marfa este subdomeniul de bază ce conține date referitoare la marfa
produsă, țara de origine și cantitatea existentă. Aceasta va permite
utilizatorului final să studieze piața de desfacere internaționale și selectarea
producătorului potrivit.
- Comenzi este subdomeniul de bază care se caracterizează prin datele
individuale ce țin de plasarea comenzii, care împreună cu subdomeniile
Marfa și Producători vor realiza scopul propus de a optimiza serviciul
internațional de transport de mărfuri.
- Tranportatori este subdomeniul de bază care face conexiunea între Traseu
și Unitatea de transport și descrie posibilitatea de colectare a datelor privind
itinerarele, angajații, traseele, și unitățile de transport. Astfel, acest
subdomeniu va oferi informația necesară pentru selectarea persoanei potrivite
cerințelor inițiale pentru transportarea către clienți.

Figura 2.1. Modelul conceptual al BDO

Instrumentul informatic precum baza de date poate servi benefic pentru a întreprinde
primii pași spre găsirea soluției de transport de mărfuri la nivel internațional, care pare să
devină una dintre cele mai proeminente probleme ale întreprinderilor de producere și export.
Astfel, cu ajutorul instrumentelor inovative, va fi posibilă stocarea eficientă şi structurată a
datelor, după care urmează prelucrarea lor în dependență de cerințele stabilite. O bază de date
permite ca accesul la date să fi efectuat solicitând cost minim de la utilizatori/administratori,
în schimb oferind maximă informație. Crearea unei baze de date trebuie să aibă premise şi
sarcini clar stabilite. Pentru a implementa BD în domeniul solicitat studiului este nevoie să se
stabilească schema BD.

2.2.3. Modelul logic al BDO prin abordarea „DE SUS IN JOS”/”OUTPUT –

INPUT”. Diagramele modelelor logice si fizice ale BDO. Schema ER
Un model logic nu necesită un model conceptual, mai ales dacă domeniul de aplicare
al modelului logic include doar dezvoltarea unui sistem informațional distinct. Modelul logic
conține mai multe detalii decât modelul conceptual. În plus față de entitățile de date de bază,
entitățile de date operaționale și tranzacționale sunt acum definite. Sunt dezvoltate detaliile
fiecărei entități de date și sunt stabilite relațiile dintre aceste entități de date. Modelul logic
este totuși dezvoltat independent de sistemul specific de management al bazei de date în care
poate fi implementat.

Figura 2.2. Modelul logic pentru BDO

 Un model entitate-relație este de obicei rezultatul unei analize sistematice pentru a
defini și a descrie ceea ce este important pentru procesele dintr-o zonă a unei afaceri. Nu
definește procesele de afaceri; prezintă doar o schemă de date de afaceri sub formă grafică.

Figura 2.3. Diagrama ER a bazei de date operaționale

Model ER este reprezentarea într-o formă grafică a entităților care sunt conectate
prin relații și care exprimă asocierile și dependențele dintre entități. Entitățile pot fi
caracterizate nu numai prin relații, ci și prin proprietăți suplimentare (atribute), care includ
identificatori numiți „chei primare”. Diagramele create pentru a reprezenta atribute, precum
și entități și relații pot fi numite diagrame entitate-atribut-relație, mai degrabă decât modele
entitate-relație.
În figura 2.3 este prezentată diagrama ER a companiei internaționale de transport de
mărfuri. Aceasta cuprinde 6 tabele (Producători, Transportatori, Unitate de transport,
Comenzi, Marfă și Traseu). Fiecare tabel are un identificator unic care este numit cheie
primară, de asemenea fiecare tabel cuprinde mai multe atribute specifice acelei entități dar și
atribute care fac parte din tabele străine altfel numite chei străine. De exemplu, pentru
entitatea Comenzi au fost folosit atribute din alte entități precum: id_transportator din
entitatea Transport, id_marfă din entitatea Marfă, id_unit_transport din entitatea Unitate
transport, id_traseu din entitatea Traseu. Aceste atribute străine formează o viziune mai clara
și completă asupra informațiilor din entitatea părinte. Relațiile dintre entități sau format in
dependență atributele necesare acesteia, de obicei acestea fiind alese in dependență de
cerințele informaționale din entitatea părinte.
 2.3. Elaborarea Proiectului DWH pentru sarcina abordată
Reieșind din baza de date operațională conceptualizată și creată în paragrafele
precedent urmează să fie elaborat depozitul de date. La rândul său, procesul de creare a
depozitul de date poate fi împărțit în etape. Aceste etape vor fi descrise mai jos. De asemenea
va fi oferită o prezentare referitor la tipul schemei depozitului. Și în cele din urmă, vor fi
descrise tabelele de dimensiuni și de fapte.

2.3.1. Descrierea succintă a etapelor procesului de modelare si creare a unui

DWH pentru sarcina abordată
Procesul de modelare și creare a unui depozit de date este constituit din 5 etape.
Etapa I. Identificați procesul de afaceri. Identificarea procesului real de afaceri pe
care ar trebui să-l acopere un depozit de date. Acesta ar putea fi marketing, vânzări, resurse
umane etc. conform nevoilor de analiză a datelor ale organizației. Selecția procesului de
afaceri depinde și de calitatea datelor disponibile pentru acel proces. Este cel mai important
pas al procesului de modelare a datelor, iar un eșec aici ar avea defecte în cascadă și
ireparabile.
Pentru a descrie procesul de afaceri, poate fi utilizat text simplu sau notația de bază
pentru modelarea proceselor de afaceri (BPMN) sau Limbajul de modelare unificat (UML).
Etapa II. Identificarea granularității. Granularitatea descrie nivelul de detaliu al
problemei/soluției de afaceri. Este procesul de identificare a celui mai scăzut nivel de
informații pentru orice tabel din depozitul de date. Dacă un tabel conține date despre vânzări
pentru fiecare zi, atunci ar trebui să fie granularitate zilnică. Dacă un tabel conține date totale
de vânzări pentru fiecare lună, atunci are o granularitate lunară.
În această etapă, trebuie de răspuns la întrebări precum:
- Trebuie să stocăm toate produsele disponibile sau doar câteva tipuri de
produse? Această decizie se bazează pe procesele de afaceri selectate pentru
DWH.
- Stocăm informațiile despre vânzarea produsului lunar, săptămânal, zilnic sau
orar? Această decizie depinde de natura rapoartelor solicitate de directori.
- Cum afectează cele două opțiuni de mai sus dimensiunea bazei de date?
Etapa III. Identificarea dimensiunilor. Dimensiunile sunt substantive precum
data, magazinul, inventarul etc. Aceste dimensiuni sunt locul unde trebuie stocate toate
datele. Tabelele de dimensiuni oferă informații descriptive pentru toate măsurătorile
înregistrate în tabelul de fapt. Dimensiunile sunt relativ foarte mici ca comparație cu tabelul
de fapte. Dimensiunile utilizate în mod obișnuit sunt oamenii, produsele, locul și timpul.
Etapa IV. Identificarea tabelului de fapte. Acest pas este co-asociat cu utilizatorii
de afaceri ai sistemului, deoarece aici au acces la datele stocate în depozitul de date.
Majoritatea rândurilor din tabelul de fapte sunt valori numerice precum prețul sau costul pe
unitate etc. Conține toate cheile primare ale dimensiunii și faptele sau măsurile asociate (este
o proprietate pe care se pot face calcule) cum ar fi cantitatea vândută, cantitatea vândută și
vânzările medii.
Etapa V. Construirea schemei ER. În acest pas, este implementat modelul de
dimensiuni. O schemă ER nu este altceva decât structura depozitului de date (aranjarea
tabelelor). Există două scheme populare:
- Schema stea,
- Schema fulg.
Având înțelegere a procesului de proiectare, se poate trece la treabă.

2.3.2. Despre schema de prezentare a DWH de tip “stea”

O schemă stea este o structură organizațională a bazei de date optimizată pentru
utilizare într-un depozit de date sau într-un business intelligence care utilizează un singur
tabel mare de fapte pentru a stoca date tranzacționale sau măsurate și unul sau mai multe
tabele dimensionale mai mici care stochează atribute despre date. Se numește schemă stea
deoarece tabelul de fapte se află în centrul diagramei logice, iar tabelele cu dimensiuni mici
se ramifică pentru a forma punctele stelei.
Un tabel de fapte se află în centrul unei baze de date cu schemă stea, iar fiecare bază
de date cu schemă stea are doar un singur tabel de fapte. Tabelul de fapte conține datele
primare specifice măsurabile (sau cuantificabile) care trebuie analizate, cum ar fi
înregistrările vânzărilor, datele de performanță înregistrate sau datele financiare. Poate fi
tranzacțional -- prin aceea că rândurile sunt adăugate pe măsură ce se întâmplă evenimentele
-- sau poate fi un instantaneu al datelor istorice până la un moment dat.
Tabelul de fapte stochează două tipuri de informații: valori numerice și valori ale
atributelor dimensiunii:
- Celulele cu valori numerice sunt unice pentru fiecare rând sau punct de date
și nu se corelează sau se referă la datele stocate în alte rânduri. Acestea pot fi
date despre o tranzacție, cum ar fi un ID de comandă, suma totală, profitul
net, cantitatea comenzii sau ora exactă.
 - Valorile atributelor de dimensiune nu stochează direct date, dar stochează
valoarea cheii externe pentru un rând dintr-un tabel dimensional aferent.
Multe rânduri din tabelul de fapte vor face referire la acest tip de informații.
Tabelele de dimensiuni stochează informații de sprijin în tabelul de fapte. Fiecare
bază de date cu schemă stea are cel puțin un tabel de dimensiuni, dar va avea adesea multe.
Fiecare tabel de dimensiuni se va referi la o coloană din tabelul de fapte cu o valoare de
dimensiune și va stoca informații suplimentare despre acea valoare.

2.3.3. Modelarea multidimensională a DWH. Tabele de dimensiuni

În depozitarea datelor, o dimensiune este o colecție de informații de referință despre
un eveniment măsurabil. În acest context, evenimentele sunt cunoscute ca „fapte”.
Dimensiunile clasifică și descriu faptele și măsurile din depozitul de date în moduri care
sprijină răspunsuri semnificative la întrebările de afaceri. Ele formează însuși miezul
modelării dimensionale.
Un depozit de date organizează atributele descriptive ca coloane în tabelele de
dimensiuni. De exemplu, atributele unui parametru client ar putea include numele și
prenumele, data nașterii, sexul etc., sau o dimensiune a site-ului web ar include numele site-
ului și atributele URL.
Un tabel de dimensiuni are o coloană de cheie primară care identifică în mod unic
fiecare înregistrare de dimensiune (rând). Tabelul de dimensiuni este asociat cu un tabel de
fapte folosind această cheie. Datele din tabelul de fapte pot fi filtrate și grupate („feliate și
tăiate cubulețe”) prin diferite combinații de atribute.
Pentru tema abordată în cadrul acestei lucrări, dimensiunile depozitului de date vor
fi create luând în considerare tabelele din baza de date operațională creată în paragrafele
precedente. Astfel, depozitul de date va conține următoarele dimensiuni:
- Marfa,
- Producător,
- Transportator,
- Transport,
- Locații,
- Timp.
Un nou tabel a fost adăugat – Timpul. Această dimensiune este specifică depozitelor
de date și nu se regăsește în bazele de date. Dimensiunea Locații a fost de asemenea adăugată
pentru a reduce redundanța datelor și a păstra tabelul de fapte doar cu valori cantitative. S-a
ținut cont ca dimensiunile să conțină date descriptive nu și cantitative.

2.3.4. Crearea tabelului de fapte pentru DWH

Un tabel de fapte este un tabel central într-o schemă stea a unui depozit de date. Este
un concept important necesar pentru Data Warehousing și Certificarea BI. Un tabel de fapte
stochează informații cantitative pentru analiză și este adesea denormalizat. Un tabel de fapte
funcționează cu tabele de dimensiuni și deține datele de analizat, iar un tabel de dimensiuni
stochează date despre modalitățile în care datele pot fi analizate.
Astfel, un tabel de fapte este format din două tipuri de coloane. Coloana chei externe
permite asocierea cu tabelele de dimensiuni, iar coloanele de măsură conțin datele care sunt
analizate.
În cazul acestei lucrări, tabelul de fapte va conține chei externe pentru toate tabelele
de dimensiuni menționate în paragraful precedent, 6 la număr.

2.3.5. Prezentarea diagramei ER a schemei modelului DWH

Ca și în cazul bazelor de date, o imagine mai clară o poate oferi prezentarea printr-o
diagramă ER a tuturor tabelelor din depozitul de date atât a celor de dimensiuni, cât și a
tabelului de fapte.
Din figura 2.4 se poate confirma că tipul schemei depozitului de date este stea,
tabelul de fapte – Comenzi – aflându-se în centru, conținând 7 chei externe care se
conectează la tabelele de dimensiuni care sunt 6 la număr.
 Figura 2.4. Diagrama ER a depozitului de date

Tabelul de fapte conține câmpurile cantitative preț marfă, preț livrare, suma totală și
timpul de zile pentru livrare.
2.4. Procesul ETL în cadrul unui DWH
Depozitele de date și instrumentele ETL au fost create pentru a obține informații
utile din toate datele de afaceri. În prezent, pe piață există mai multe instrumente ETL care au
funcționalități extinse pentru curățarea datelor, profilarea datelor, procesarea datelor mari,
managementul datelor de bază, gestionarea datelor și integrarea aplicațiilor pentru
întreprinderi (EAI). Odată cu disponibilitatea datelor în depozit sau cubul de proces analitic
online (OLAP), un software de Business Intelligence (BI) este utilizat pentru a le vizualiza și
analiza. Acest software ajută la raportare, descoperirea datelor, minerit și îmbarcare.
Procesul de extragere și organizare a datelor brute, de transformare pentru a le face
ușor de înțeles și de încărcare a acestora într-un depozit de date pentru a le accesa și analiza
cu ușurință, este cunoscut ca proces ETL. Pe scurt, este o componentă esențială a
ecosistemului de date al oricărei afaceri contemporane.
Deoarece datele care provin din diverse surse au o structură distinctă, fiecare set de
date trebuie transformat diferit înainte de a-l utiliza pentru inteligență și analiză de afaceri. De
exemplu, dacă organizați date din sisteme sursă precum Google Analytics și Amazon
Redshift, aceste două surse ar trebui tratate separat cu întregul proces ETL.
 Pasul de extragere cuprinde extragerea datelor din sistemul sursă în zona de
pregătire. Orice transformare se poate face in zona de staging fără a degrada performantele
sistemului sursa. De asemenea, la copierea oricăror date corupte direct din sursă în baza de
date a depozitului de date, restaurarea ar putea fi o provocare. Utilizatorii pot valida datele
extrase în zona de pregătire înainte de a le muta în depozitul de date.
Depozitele de date ar trebui să îmbine sistemele cu hardware, DBMS, OS și
protocoale de comunicare. Sursele includ aplicații vechi, cum ar fi aplicații personalizate,
mainframe, dispozitive POC, cum ar fi comutatoare de apel, ATM, fișiere text, ERP, foi de
calcul, date de la parteneri și furnizori.
Există trei metode de extragere a datelor:
- Extracție completă,
- Extracție parțială- cu notificare,
- Extracție parțială - fără notificare.
În ciuda metodei utilizate, extragerea datelor nu ar trebui să aibă niciun impact
asupra performanței și timpului de răspuns al sistemelor sursă care sunt baza de date de
producție live.
Datele care sunt extrase de pe serverul sursă sunt incomplete și nu pot fi utilizate în
forma sa originală. Din acest motiv, trebuie să fie curățate, mapate și transformate. Acesta
este cel mai important pas în care procesul ETL îmbunătățește și modifică datele pentru a
genera rapoarte BI intuitive.
Există, de asemenea, unele probleme în integritatea datelor:
- Ortografii diferite ale două persoane care au același nume,
- Diferite moduri de a desemna numele unei companii,
- Utilizarea numelor diferitelor locuri,
- Generarea de numere de cont diferite pentru același client printr-o aplicație,
- Colectarea de produse nevalide la punctul de vânzare din cauza unei greșeli
la o introducere manuală,
Ultimul pas al procesului ETL include încărcarea datelor în baza de date țintă a
depozitului de date. Într-un depozit de date standard, volume mari de date trebuie să fie
încărcate într-o perioadă relativ scurtă. Ca urmare, procesul de încărcare trebuie simplificat
pentru performanță.
 2.5. Concluzii
Subiectul implementării unui sistem informațional unic de gestiune a transportului
internațional de mărfuri devine una tot mai des discutată. Cauza constă în faptul că ratele
moderne de dezvoltare afacerilor de transport subliniază necesitatea introducerii active a unor
noi metode de lucru care să răspundă nevoilor crescute ale consumatorilor.
Utilizatorul final dorește să obțină un singur sistem de informații, ceea ce i-ar
permite să găsească compania care se potrivește pentru toate sau majoritatea cerințelor sale
de transport internațional de mărfuri.
Acest capitol a avut drept scop proiectarea și crearea unui depozit de date prin
prisma modelării conceptuale, logice și fizice. Aceste etape au fost implementate pe parcursul
lucrării accentuând astfel importanța creării unei baze de date. Instrumentul informatic numit
baza de date poate fi benefic pentru a întreprinde primii pași spre găsirea soluției de transport
de mărfuri la nivel internațional, iar pentru elaborarea unui plan strategic efectiv, au fost
stabilite etapele procesului de modelare si creare a unui DWH pentru sarcina abordată.
Procesul de modelare a avut loc structurat în 5 pași care au stabilit parametrii logici și fizici
ce au generat schema ER.
În continuare, a fost descris procesul de creare a unui DWH și a instrumentului ETL,
ce arată relațiile ca seturi de entități stocate într-un depozit de date. O entitate în acest
context este un obiect, o componentă a datelor. Un set de entități este o colecție de entități
similare.
Bibliografie
1. «Базы данных в Интернете», Resursă electrpnică – [Mod de acces]
https://sites.google.com/site/bazydannyhvinternete/
2. Kapterev A.I. «Электронный учебник по информатике», Resursă electrpnică
– [Mod de acces] http://www.mediagnosis.ru/Autorun/Page6/10_5_.htm
3. Taylor David „What is Dimensional Modeling in Data Warehouse?”, Resursă
electronică – [Mod de acces] https://www.guru99.com/dimensional-model-data-
warehouse.html
4. „Star Schema”, Resursă electronică – [Mod de acces]
https://searchdatamanagement.techtarget.com/definition/star-schema
5. “Fact Table and its Types in Data Warehousing”, Resursă electronică – [Mod de
acces]https://www.edureka.co/blog/fact-table-and-its-types-in-data-warehousing/
6. “How to implement the ETL steps for your data warehouse?”, Resursă
electronică – [Mod de acces] https://www.cloudmoyo.com/blog/data-
architecture/how-to-implement-the-etl-steps-into-the-data-warehouse/