Modelul

ierarhi

Din punct de vedere istoric, acesta a fost primul model de date ce a fundamentat un sistem
de gestiune al bazelor de date şi a fost dezvoltat de către firma IBM pentru produsul său IMS care
utiliza limbajul DL/1.

Modelul ierarhic lucrează cu grupuri repetitive prin utilizarea unei structuri de date ce se
bazează pe parcurgerea de sus în jos a unui arbore: datele aflate în înregistrările primare reprezintă
ramurile arborelui, în timp ce datele ce formează grupurile repetitive reprezintă frunzele acestuia.

Avantajul modelului ierarhic este acela că metodele folosite la regăsirea înregistrărilor

asociate din baza de date sunt mai simple decât cele folosite în modelul reţea.

Intensia modelului de date ierarhic este reprezentată cu ajutorul unui arbore de definiţie ce

reprezintă o diagramă a structurii de date în care sensul legăturilor funcţionale este întotdeauna de la
nodul părinte către nodul copil. O astfel de diagramă este un graf orientat alcătuit cu scopul
reprezentării tipurilor de entităţi şi a relaţiilor dintre acestea. Nodurile grafului corespund tipurilor
de entităţi, iar arcele grafului reprezintă legăturile funcţionale dintre tipurile de entităţi.

Extensia modelului de date ierarhic se reprezintă sub forma unui tabel în care fiecare linie a
tabelului este o înregistrare ce corespunde unei instanţieri a tipului de entitate. În tabele sunt
permise duplicatele şi, prin urmare, pot exista două instanţieri identice ale aceluiaşi tip de entitate.
Un singur tabel din baza de date are rolul de rădăcină a arborelui în timp ce restul tabelelor
formează mulţimea părinţilor şi copiilor arborelui.

O relaţie într-o bază de date ierarhică este reprezentată prin intermediul perechii
părinte/copil. În acest tip de relaţie, tabelul părinte poate fi asociat cu unul sau mai multe tabele
copil, dar un singur tabel copil poate fi asociat doar cu un singur tabel părinte. Aceste tabele sunt
asociate în mod explicit cu ajutorul unor pointeri sau pe baza unui aranjament fizic al înregistrărilor
în tabele.

Utilizatorul accesează datele pornind din rădăcina arborelui şi parcurge un anumit drum unic
până ajunge la datele căutate. O astfel de metodă de acces cere utilizatorului o foarte bună
cunoaştere a structurii bazei de date.

Un
avantaj
al utilizării bazelor de date ierarhice este acela că utilizatorul poate extrage datele foarte rapid
datorită legăturilor explicite definite în structura tabelelor. Un alt avantaj este acela că integritatea
referenţială se obţine prin crearea structurii şi nu poate fi încălcată, ceea ce face ca o înregistrare din
tabelul copil să fie obligatoriu asociată unei înregistrări existente în tabelul părinte, iar o înregistrare
ştearsă din tabelul părinte să impună eliminarea tuturor înregistrărilor asociate din tabelul copil.

Probleme deosebite vor apare în momentul în care utilizatorul doreşte să introducă o

înregistrare în tabelul copil care nu are asocieri cu nici o înregistrare din tabelul părinte. Acest tip de
bază de date nu poate suporta asocierile complexe şi, de aceea, deseori sunt probleme referitoare la
redundanţa datelor, deoarece este posibil să-i fie permisă introducerea de date inconsistente.
Această problemă poate fi însă rezolvată prin crearea a două baze de date pentru a înlocui tipurile de
relaţii mulţi-la-mulţi, aşa cum se prezintă în figura de mai jos:

Deşi bazele de date ierarhice ofereau un acces direct şi rapid la date, dovedindu-şi
superioritatea într-o multitudine de situaţii specifice, devenise evident că era necesară introducerea
unui nou model de date pentru a remedia problemele tot mai presante referitoare la redundanţa
datelor şi la rezolvarea asocierilor complexe dintre înregistrări.

Baze de date Input-Output

Bazele de date pentru LCA care se bazează pe statisticile naționale economice și de mediu
sunt cunoscute ca „baze de date de intrare-ieșire” sau „baze de date IO” pe scurt. Un număr de baze
de date IO pentru LCA bazate pe statisticile naționale economice și de mediu sunt acum disponibile
 în SimaProformat. Principalul avantaj al bazelor de date IO este că nu trebuie să facem cut-off,
adică să excludem părți din sistemul produsului. Un alt avantaj este consistența lor în ceea ce
privește modul în care sunt colectate datele. Deoarece datele sunt colectate pentru aceleași
schimburi de mediu și în același mod în mod consecvent pentru toate procesele din economie,
evitați problemele de inconsecvență și rezultate false, adică faptul că un proces se afișează ca fiind
important deoarece sunt disponibile date despre o anumită emisie de substanță. proces specific, în
timp ce nu este disponibil pentru celelalte procese. Dezavantajul bazelor de date IO pentru LCA
este că procesele sunt relativ agregate, adică la nivelul grupurilor de produse, mai degrabă decât la
nivelul produselor individuale. Cu toate acestea, acest dezavantaj poate fi depășit prin utilizarea
analizei hibride, vezi mai jos. Baza de date IO pentru SUA 2002 este disponibilă ca parte a bazei de
date standard care vine cu software-ul SimaPro . Documentația acestei baze de date poate fi găsită
în Suh S. (2003). Ghidul utilizatorului MIET 3.0 . Amersfoort: PRé consultants (cu referire la
versiunea din 1998). Baza de date IO pentru UE27 și Danemarca 2003 este disponibilă ca parte a
bazei de date standard care vine cu software-ul SimaPro . 750 de mărfuri care acoperă întreaga
economie daneză și UE27. Modelele IO sunt dezvoltate de consultanți LCA 2.-0 ca parte a
proiectului EU FP6 FORWAST . Datele din modelul DK IO referitoare la activitățile agricole din
economie au fost validate și îmbunătățite în continuare printr-un proiect „ Proiect pilot – evaluarea
efectului cercetării ” finanțat de Ministerul Danez al Alimentației, Agriculturii și Pescuitului.

Modelul FORWAST diferă de majoritatea celorlalte modele IO în următoarele moduri:

 Modelul IO este un model hibrid de unitate IO bazat pe tabele

complete echilibrate monetare și fizice aferente utilizării ofertei. Faptul că modelul este în unități
hibride permite să funcționeze cu prețuri diferite în funcție de activități, de exemplu industriile
consumatoare de energie, cum ar fi generarea de electricitate și producția de metale de bază, adesea
plătesc mai puțin pentru combustibili decât alte activități. Implicația acestui lucru este că modelele
tradiționale IO subestimează adesea utilizarea combustibililor și a electricității pentru activități
consumatoare de energie.
 Modelul include generarea și tratarea deșeurilor în unități fizice.
 Modelul distinge între producția virgină de material și reciclarea
deșeurilor, precum și distinge între mai multe opțiuni de tratare a deșeurilor din diferite fracțiuni de
deșeuri: incinerare, depozitare și tratare a apelor uzate.
 Fluxurile de deșeuri sunt calculate pe baza analizei naționale
detaliate ale fluxului de masă, inclusiv bilanțurile de masă la nivel de produse, precum și de
activități.
 În conformitate cu standardele ISO14040 / 44 privind LCA și Manualul
ILCD despre LCA, modelul gestionează alocarea produselor secundare prin extinderea sistemului.

Versiunile în care industriile specifice sunt reprezentate mai detaliat ( baze de date hibride ,
vezi mai jos) sunt disponibile la comandă.
Baza de date FORWAST poate fi utilizată atât în SimaPro, cât și în Brightway2 ( acces la baza
de date ). Mai jos sunt oferite explicații suplimentare despre cum să utilizați funcțiile SimaPro
pentru a analiza și compara produsele din baza de date FORWAST.

Utilizați funcțiile SimaPro pentru a analiza și compara produsele. Manualele de utilizare pot fi

găsite în meniul „Ajutor”.

Pentru îndrumări suplimentare cu privire la modul de utilizare a funcționalităților din software-

ul SimaPro, vă rugăm să consultați manualul de utilizare SimaPro, care este inclus în versiunea
demo gratuită (în meniul „Ajutor”).

SimaPro (și în versiunea demo gratuită) oferă mai multe moduri diferite de a analiza un sistem
de produs și impactul acestuia asupra mediului. Folosind opțiunea Calculate Network (F10)
legăturile dintre procesul selectat și celelalte procese sunt furnizate într-o formă grafică, vezi figura
de mai jos.
 Figura prezintă un exemplu de rețea (cu limită de 3,2%) care arată procese importante care
contribuie la 140 g echivalent CO2 din ciclul de viață a 1 DKK de produse din industria „Băuturi,
DK” (valori de emisie acumulate în partea stângă jos a fiecărei casete).

Este posibil să tăiați procesele contributive minore în prezentarea grafică a rețelei. De

exemplu, în figura de mai sus, a fost selectată o limită de 3,2% pentru a limita numărul de procese
prezentate în diagramă. Limita se referă numai la procesele afișate în diagramă, nu la limitele din
calcul (adică calculul de bază include în continuare toate procesele contributive).

Schema este o descriere logică a întregii baze de date. Include numele și descrierea

înregistrărilor pentru toate tipurile de înregistrări, inclusiv toate elementele de date și agregatele
asociate. La fel ca o bază de date, un depozit de date necesită și menținerea unei scheme. O bază de
date folosește un model relațional, în timp ce un depozit de date utilizează schema Star, Snowflake
și Fact Constellation. În acest capitol, vom discuta schemele utilizate într-un depozit de date.

Schema stea

 Fiecare dimensiune dintr-o schemă stea este reprezentată doar cu un tabel cu o singură
dimensiune.

 Acest tabel de dimensiuni conține setul de atribute.

 Următoarea diagramă prezintă datele de vânzări ale unei companii cu privire la cele patru
dimensiuni, și anume timp, articol, sucursală și locație.
  Există un tabel de fapte în centru. Conține cheile pentru fiecare dintre cele patru dimensiuni.

 Tabelul de fapte conține și atributele, și anume dolari vânduți și unități vândute.

Notă − Fiecare dimensiune are un singur tabel de dimensiuni și fiecare tabel deține un set de
atribute. De exemplu, tabelul cu dimensiunile locației conține setul de atribute {location_key,
street, city, province_or_state, country}. Această constrângere poate cauza redundanță a
datelor. De exemplu, „Vancouver” și „Victoria”, ambele orașe sunt în provincia canadiană British
Columbia. Intrările pentru astfel de orașe pot cauza redundanță de date de-a lungul atributelor
provincie_sau_stat și țară.

Schema fulgilor de nea

 Unele tabele de dimensiuni din schema Snowflake sunt normalizate.

 Normalizarea împarte datele în tabele suplimentare.

 Spre deosebire de schema Star, tabelul de dimensiuni într-o schemă fulg de zăpadă este
normalizat. De exemplu, tabelul de dimensiuni ale articolului din schema stea este
normalizat și împărțit în tabele cu două dimensiuni, și anume tabelul articol și furnizor.
  Acum, tabelul de dimensiuni ale articolului conține atributele cheie_articol, nume_articol,
tip, marcă și cheie-furnizor.

 Cheia furnizorului este legată de tabelul cu dimensiunile furnizorului. Tabelul de

dimensiuni furnizor conține atributele cheie_furnizor și tip_furnizor.

Notă − Datorită normalizării în schema Snowflake, redundanța este redusă și, prin urmare, devine
ușor de întreținut și economisește spațiu de stocare.

Schema constelației de fapt

 O constelație de fapte are mai multe tabele de fapte. Este cunoscută și sub numele de
schema galaxiei.

 Următoarea diagramă prezintă două tabele de fapte, și anume vânzări și expediere.

  Tabelul de date despre vânzări este același cu cel din schema stea.

 Tabelul cu informații despre expediere are cele cinci dimensiuni, și anume cheia_articol,
cheia_timp, cheia_expeditorului, de la locație, la_locație.

 Tabelul cu fapte de expediere conține și două măsuri, și anume dolari vânduți și unități
vândute.

 De asemenea, este posibilă partajarea tabelelor de dimensiuni între tabelele de fapte. De

exemplu, tabelele cu dimensiunea oră, articol și locație sunt partajate între tabelul de date
privind vânzările și expedierea.

Definiția schemei

Schema multidimensională este definită utilizând limbajul de interogare pentru minarea datelor
(DMQL). Cele două primitive, definiția cubului și definiția dimensiunii, pot fi utilizate pentru
definirea depozitelor de date și a marților de date.

Sintaxă pentru definiția cubului

define cube < cube_name > [ < dimension-list > }: < measure_list >

Sintaxă pentru definirea dimensiunii

define dimension < dimension_name > as ( < attribute_or_dimension_list > )

Definiția Schemei Stelare

Schema stea despre care am discutat poate fi definită utilizând limbajul de interogare pentru
minarea datelor (DMQL) după cum urmează -

define cube sales star [time, item, branch, location]:

dollars sold = sum(sales in dollars), units sold = count(*)

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier type)
define dimension branch as (branch key, branch name, branch type)
define dimension location as (location key, street, city, province or state, country)

Definiția schemei fulgi de nea

Schema Snowflake poate fi definită folosind DMQL după cum urmează -

define cube sales snowflake [time, item, branch, location]:

dollars sold = sum(sales in dollars), units sold = count(*)

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier (supplier key, supplier type))
define dimension branch as (branch key, branch name, branch type)
define dimension location as (location key, street, city (city key, city, province or state, country))

Definiția schemei constelației de fapt

Schema constelației de fapt poate fi definită folosind DMQL după cum urmează −

define cube sales [time, item, branch, location]:

dollars sold = sum(sales in dollars), units sold = count(*)

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier type)
define dimension branch as (branch key, branch name, branch type)
define dimension location as (location key, street, city, province or state,country)
define cube shipping [time, item, shipper, from location, to location]:
dollars cost = sum(cost in dollars), units shipped = count(*)

define dimension time as time in cube sales

define dimension item as item in cube sales
define dimension shipper as (shipper key, shipper name, location as location in cube sales, shipper
type)
define dimension from location as location in cube sales
define dimension to location as location in cube sales