CURS 1

Obiective:
1. Semnificaţiile noţiunilor de „dată” şi „informaţie”,
2. Decizia, ca rezultantă a informaţiei,
3. Definirea noţiunilor de „bază de date” şi de „sistem de gestiune a bazelor de date”,
4. Sisteme de fişier,
5. Avantajele şi dezavantajele sistemelor de fişier în raport cu sistemele de gestiune a
bazelor de date,
6. Arhitectura sistemelor de gestiune a bazelor de date,
7. Caracteristicile şi obiectivele sistemelor de gestiune a bazelor de date.

BAZE DE DATE ŞI SISTEME DE GESTIUNE A BAZELOR DE DATE

COLECŢII DE DATE

Datele sunt deţinătoare de informaţie, iar datele informatice prin metode speciale pot fi
transpuse într-un cod recognoscibil pentru calculator. În ambele cazuri informaţia poate fi
identificată, definită, evaluată, structurată şi prelucrată pentru a fi stocată sau memorată.
Informaţiapoate fi stocată de creierul uman prin cunoaştere, înţelegere, învăţare, iar
atunci când volumul informaţional depăşeşte graniţele putinţei receptării, aceasta este stocată pe
diverse suporturi în vederea accesării la nevoie de către individ.
Datele constituie un ansamblu de informaţii care pot fi structurate în ansambluri logice,
ierarhizate sau interconectate cu alte categorii de informaţii mai mult sau mai puţin structurabile.

1
 Data poate fi concomitent obiect de prelucrare, sursă de fundamentare a modelelor şi
proceselor, mijloc de tezaurizare informaţională.
Datele concură la luarea deciziilor. În domeniul socio-economic, informaţiile statistice
pot fi sursa unor decizii manageriale, de proces.
Decizia este rezultatul unor activităţi conştiente, specifice omului. Activităţile decizionale
se bazează pe acumularea de cunoştinţe şi crearea de conexiuni în cadrul unei probleme de
alegere dintr-o multitudine de variante identificabile şi evaluabile, în vederea efectuării de noi
acţiuni care implică antrenarea de noi resurse în scopul realizării obiectivelor propuse.
Sunt identificate cinci categorii de decizii coerente, raţionale:
1. decizia rezultă în urma desfăşurării la întâmplare a activităţilor decizionale,
2. activităţile decizionale se bazează pe rutină,
3. activităţile decizionale se bazează pe învăţare,
4. activităţile decizionale paradigmatice,
5. activităţile decizionale se bazează pe analiza şi modelarea sistemică şi previzională.

Sisteme de fişiere.
Sisteme de gestiune a bazelor de date

Sistemele bazate pe fişiere presupun că fiecărui fişier i se alocă un anume specific, în

care se introduc date de acelaşi tip, cum sunt: situaţia facturilor furnizorilor, situaţia stocurilor din
magaziile specializate sau din magazia centrală, situaţia clienţilor, etc.
Fiecare fişier este stocat şi poate fi modificat de unul sau mai mulţi utilizatori putând
apărea dublări de fişiere rezultate după fiecare nouă prelucrare, dublări de date, etc.
Avantajele sistemului de baze de date, pentru cazul în care sunt monitorizate de un număr
limitat de utilizatori, sunt:
– nu este necesară prelucrarea a două sau mai multe fişiere de date aferente unor activităţi
diferite,
– nu este necesară conlucrarea în reţea sau lucrul în simultan pe acelaşi fişier în locaţii
diferite ale reţelei.

2
 Definirea generală a bazelor de date este aceea că bazele de date sunt o colecţie partajată
de date, între care există relaţii logice, proiectate pentru satisfacerea necesităţilor informaţionale
ale unei organizaţii sau ale unui grup.
Există o diferenţă între date şi informaţii, astfel:
„Datele sunt fapte culese din lumea reală pe bază de observaţii şi măsurători.”
„Informaţia este rezultatul interpretării datelor de către un anumit subiect şi conferă acestuia
capacitatea de a lua decizii.”
În funcţie de gradul de detaliere, datele pot fi:
– date elementare,
– date compuse.
Datele elementare sunt entităţi indivizibile, cuante de informaţie, atât la nivel
informaţional, cât şi la nivel de prelucrare.

Datele compuse sunt mulţimi de date elementare, care ajută la caracterizarea entităţilor
informaţionale şi care pot fi descompuse în date elementare.
Prelucrarea datelor se poate realiza atât la nivelul datelor elementare, cât şi la nivelul
datelor compuse.
Sub aspectul evoluţiei categoriilor de receptare şi memorare informatizată a datelor sunt
identificate patru etape distincte de abordare a acestora:
Prima etapă este aferentă trecerii de la sistemele de prelucrare manuală la computer.
Dezavantajele rezultate în urma organizării datelor în fişiere sunt:
– redundanţă ridicată,
– dificultăţi de acces la date,
– izolarea datelor,
– actualizarea datelor,
– dependenţa programelor faţă de date,
– greutatea de a obţine răspunsuri rapide la problemele nevăzute,
– fiecare dată este descrisă independent în toate fişierele în care apare.
Limitările tratării bazate pe fişier se bazează pe următorii factori:
3
 – definiţia datelor este încorporată în programele aplicaţiei, în loc să fie stocată separat şi
independent,
– nu există un control al accesului şi manipulării datelor, dincolo de cel impus de către
programele aplicaţiei.
A doua etapă se caracterizează prin separarea dintre structura logică de date şi structura
fizică.
Etapa a treia este definită de apariţia fişierelor integrate, prin care datele sunt legate logic
între ele, chiar dacă datele fizice sunt rezidente pe diferite sisteme.
Etapa a patra este etapa bazelor de date propriu-zise şi a dezvoltării sistemelor de
gestiune a bazelor de date.

Arhitectura sistemelor de gestiune a bazelor de date

Cerinţele minimale impuse unei baze de date sunt:
– furnizarea în timp util a informaţiilor solicitate,
– asigurarea unor costuri minime în prelucrarea şi întreţinerea informaţiei,
– capacitatea de satisfacere, cu aceleaşi date, necesităţi informaţionale ale unui număr mare
de utilizatori,
– flexibilitate, în sensul de adaptare la interogări noi, neprevăzute iniţial,
– minimizarea redundanţei datelor,
– posibilitatea exploatării datelor de mai mulţi utilizatori,
– asigurarea securităţii datelor prin măsuri de protecţie de diferite nivele a accesului
neautorizat, denumit şi confidenţialitatea accesului,
– capacitatea recuperării datelor ca urmare a unor manipulări eronate sau deteriorări
accidentale,
– posibilitatea utilizării eforturilor anterioare şi anticiparea nevoilor viitoare.
Avantajele datelor centralizate în baza de date sunt în principal următoarele:
– reducerea redundanţei datelor,
– evitarea inconsistenţei datelor prin actualizarea centralizată a întregii baze de date,
– posibilitatea partajării datelor,
4
 – încurajarea introducerii standardelor de compatibilizare a bazelor de date cu aplicaţii
executabile,
– posibilitatea aplicării restricţiilor de securitate pe mai multe nivele,
– menţinerea integrităţii datelor.
Arhitectura bazelor de date este alcătuită din următoarele componente:
– baza de date propriu-zisă,
– sistemul de gestiune al bazelor de date,
– un dicţionar al bazei de date, care conţine informaţii despre:
○ date,

○ structura datelor,

○ statistici,

○ documentaţie,

– componente hardware,
– reglementări administrative destinate bunei funcţionări a sistemului,
– factorul uman autorizat în diferite limite.

Caracteristicile şi obiectivele SGBD-urilor

Caracteristicile principale ale Sistemelor de gestiune a datelor sunt următoarele
componente:
– limbajul de definire a datelor,
– limbajul de manipulare a datelor,
– limbaj pentru controlul şi securitatea datelor.
Obiectivele principale ale unui sistem de gestiune a bazelor de date sunt:
– independenţa logică,
– independenţa fizică,
– manipularea datelor de către neinformaticieni,
– administrarea centralizată a datelor,
– neredundanţa datelor,
5
 – coerenţa datelor,
– partajarea datelor,
– securitatea şi confidenţialitatea datelor.
În general SGBD, trebuie să includă minimal cinci clase de module:
– programe de gestiune a bazei de date,
– module pentru tratarea limbajului de definire a datelor,
– module pentru tratarea limbajului de manipulare a datelor,
– module utilitare,
– module de control.
Componentele din alcătuirea, configurarea şi utilizarea bazelor de date sunt:
– administratorii de date,
– administratorii de baze de date,
– proiectanţii de baze de date,
– programatorii de aplicaţii,
– utilizatorii pot fi:
○ utilizatori conversaţionali,

○ utilizatori iniţiaţi.

Aspecte generale privind managementul calităţii în producţia software

Unul dintre criteriile de valoare ale unui produs software este calitatea acestuia. Conceptul
de calitate este complex şi face referire la funcţionalitatea produsului în timp, la rapiditatea şi
corectitudinea prelucrărilor, dar şi de uşurinţa utilizatorului în înţelegerea principalelor funcţii ale
acestuia.
Produsul software supus monitorizării de calitate trebuie să răspundă câtorva criterii şi
anume:
– calitatea concepţiei,
– calitatea fabricaţiei,
– calitatea produsului,

6
 – calitatea livrării,
– fiabilitatea în exploatare şi gradul de satisfacţie al utilizatorilor.
Aspectele calitative software îmbinate cu cele hardware sunt de maximă importanţă în
aplicaţiile destinate monitorizării vieţii sau în cele care pot fi generatoare de situaţii care pot pune
viaţa sau mediul în pericol. Aplicaţiile dedicate domeniului financiar bursier sau bancar, dacă
sunt afectate de erori pot afecta pieţe de milioane de conturi, cu implicaţii indirecte într-o
multitudine de domenii economice.
Oricât de performant ar fi produsul software, eroarea umană introdusă de un utilizator
poate fi la rândul ei sursă de disfuncţionalităţi.
Sistemele de gestiune a bazelor de date trebuie să aibă prevăzute nivele de securitate şi
acces diferenţiate, şi soluţii de salvare a celor mai recente acţiuni.
Prevederea de proceduri de elaborare şi uz la toate nivelele, de la concepţie, fabricaţie,
livrare, până la utilizare conduce la ridicarea costurilor produsului software, dar pierderile
generate de disfuncţionalităţi sunt minimizate. Producătorul de software trebuie să aibă în vedere
balanţa dintre costuri şi prejudiciile produse beneficiarului să nu conducă la anomalii. Astfel, un
preţ ridicat, justificat de costuri de producţie şi testare ridicate, poate conduce la îngustarea
segmentului de piaţă căruia îi este dedicat, alungarea clientelei tradiţionale, mai mult chiar şi
ieşirea de pe piaţă.

Curs 2
Modele de realizare a sistemelor informatice
În timp au fost elaborate mai multe modele ale ciclului de viaţă al SI, autorii încercând să
identifice, în viziune proprie, etapele de dezvoltare a produsului software. Numărul, numele, conţinutul
şi înlănţuirea fazelor propuse în cadrul acestor modele diferă în special prin accentul pus pe
anumite componente.

7
 Modelele elaborate au cunoscut îmbunătăţiri permanente încercându-se adaptarea lor la noile
cerinţe ale modelării orintate obiect, precum şi inserarea unor etape specifice managementului
proiectelor.
Modelul cascadă
Modelul cascadă (Waterfall Model) a fost elaborat de W.W. Royce la începutul anilor 70.
Este un model de referinţă în literatura de specialitate caracterizat prin parcurgerea secvenţială a
fazelor ciclului de viaţă, faze care la rândul lor sunt formate din activităţi iar acestea din
urmă din subactivităţi.
Modelul prezintă următoarele avantaje:

• controlul total al fazelor, datorită modului de ordonare a acestora;

• uşor de însuşit de către membrii echipelor de analiză şi proiectare;
• fiecare fază se încheie cu o verificare a soluţiei oferite şi asigură o documentaţie
prezentând soluţia elaborată.
În timp au fost propuse variante îmbunătăţite ale modelului:

• modelul cu revenire la pasul următor (waterfall model with back flow, fig. 1.15.)
• modelul cu reluare de la faza iniţială ("Da Capo" Waterfall Model).
• în versiuni mai noi ale modelului cascadă, primele faze grupează activităţi specifice
gestiunii proiectului aceste elemente lipsind în modelul iniţial.

8
 Modelul în V
Modelul în V este o variantă a modelului cascadă care aduce elemente calitative noi
importante. Un element caracteristic al modelului este introducerea conceptelor de sistem şi
componente2 (subsisteme) aplicându-se teste explicite pentru. Fazele plasate în partea superioară a
modelului se caracterizează prin creşterea controlului asupra modului în care se desfăşoară
etapele implicarea directă a viitorului utilizator.
Braţul stâng al diagramei, parcurs descendent, reuneşte fazele în cadrul cărora se realizează,
pas cu pas, proiectarea şi realizarea sistemului informatic. Detalierea activităţilor de proiectare,
codificare şi asamblare a componentelor se realizează gradual. Dealtfel, Ould, creatorul modelului
în forma lui consacrată, a prevăzut doar latura din stânga unde efortul principal de proiectare se
focalizează pe descompunerea sistemului pe componente.
Braţul drept al diagramei cuprinde reprezentarea fazelor asigurând asamblarea progresivă a
componentelor sistemului pe măsura testării lor individuale, până la obţinerea sistemului global şi
acceptarea acestuia de către beneficiar.
Notă: în cadrul modelului se remarcă realizarea distincţiei dintre verificare şi
validare. Prima se referă la testarea sistemului în diversele stadii pe care le parcurge, iar
validarea urmăreşte să identifice în ce.

9
 Notă: măsură sistemul corespunde cerinţelor iniţiale, ceea ce constituie un punct
slab al modelului datorită întârzierii cu care se produce această validare.

10
 Modelul în W
Acest model reia ideea modelului în V pe care îl dezvoltă şi perfecţionează prin integrarea
activităţilor de validare la nivelul fazelor de proiectare.

Modelul tridimensional

11
 Modelul tridimensional promovat de metoda de proiectare MERISE se
caracterizează prin reprezentarea grafică pe trei axe fiecare dintre acestea
corespunzând ciclului de viaţă al sistemului, ciclul de decizie şi respectiv ciclului

abstractizării.

12
 Modelul spirală
Modelul spirală, elaborat de Barry Boehm, se bazează pe acelaşi principiu ca şi modelul
evolutiv. Modelul presupune construirea mai multor prototipuri succesive în condiţiile realizării
unei analize a riscului pe fiecare nivel. Fazele de dezvoltare sunt reluate la fiecare iteraţie în
aceeaşi succesiune şi presupun:
➢ Analiza riscurilor
➢ Realizarea unui prototip
➢ Simularea şi testarea prototipului
➢ Determinarea cerinţelor în urma rezultatelor testării
➢ Validarea cerinţelor
➢ Planificarea ciclului următor
Ultimul ciclu conduce la realizarea versiunii finale a sistemului informatic.

13
 Prototipul funcţional presupune proiectarea sistemului, realizarea primului prototip
funcţional, verificarea măsurii în care răspunde cererilor formulate de utilizator şi rafinarea acestei
prime soluţii, prin dezvoltări viitoare care adaugă noi funcţionalităţi până la obţinerea variantei
finale a sistemului.

14
 Modelul evolutiv
Modelul evolutiv porneşte de la realizarea unui studiu iniţial privind obiectivele viitorului
SI a cărui arhitectură este definită ulterior. Fiecare componentă astfel definită îşi va urma propriul
său ciclu de viaţă (definirea cerinţelor, analiză, proiectare, realizare, testare, utilizare)
urmând să fie livrată beneficiarului în momentul finalizării.

Modelul minge de baseball

Modelul minge de baseball (dezvoltarea concurenţială) propus de CODD, Yourdon şi
Nicola pleacă de la ideea renunţării la paşii succesivi în realizarea sistemului în favoarea
promovării activităţilor desfăşurate în paralel.

Este vorba de analiza orientată obiect (AOO), proiectarea (design) orientată-obiect (DOO)
şi programarea orientată-obiect (POO).
Într-o astfel de abordare, AOO ar beneficia de rezultatele DOO şi POO; DOO, beneficiază
de rezultatele AOO şi POO, iar POO valorifică rezultatele AOO şi DOO.

15
 Evoluţia metodelor de proiectare
Evoluţia metodelor de proiectare este consecinţa mutaţiilor calitative şi cantitative în
planul:

• Abordării sistemelor informatice

• Dezvoltării bazei conceptuale specifice proiectării şi realizării sistemelor informatice

(mai ales
odată cu promovarea abordării obiectuale)

• Apariţia şi extinderea utilizării tehnicilor rapide de proiectare

• Evoluţia permanentă a limbajelor de programare

• Sporirea considerabilă a complexităţii aplicaţiilor realizate în condiţiile creşterii

nivelului de
integrare a acestora

• Extinderea ariei de utilizare a informaticii

• Utilizării tehnicilor de gestiune în timp real.

Putem spune că în timp s-au conturat mai multe curente de gândire care au promovat şi
dezvoltat anumite metode de proiectare. Este însă greu să realizăm o clasificare a acestor metode
tocmai datorită diversităţii punctelor de vedere asupra acestei probleme.
O clasificare realizată plecând de la abordările promovate de metodele de proiectare ne
conduce la următoarea grupare:
a) Metode timpurii, metode nestructurate specifice perioadei '50 - '60.
b) Metode orientate spre ieşiri (sfârşitul anilor '60) caracterizate prin faptul că
proiectarea sistemului informatic avea ca punct de plecare ieşirile pe care acesta trebuia să le
asigure:rapoarte, grafice etc. Pe baza ieşirilor identificate se determinau apoi datele de intrare şi
prelucrările.
c) Metode orientate spre procese, utilizate în deceniul şapte, prezentând drept
caracteristică utilizarea diagramelor fluxurilor de date.
d) Metode orientate spre date, specifice anilor '80, prezentând ca element caracteristic
utilizarea diagramelor entitate-relaţie;
e) Metode orientate obiect promovate în anii '90 caracterizate prin promovarea
conceptului de obiect care încapsulează date şi metode.

16
 Modelarea
Prin modelare se înţelege reprezentarea unui obiect, fenomen sau proces din lumea reală
într-un anumit sistem (matematic, fizic, grafic, informatic, etc.). Un model este creat pentru a
permite studiul obiectului, fenomenului sau procesului respectiv, într-un anumit context.
În urma analizei obiectului, fenomenului sau procesului din lumea reală, modelul va păstra
numai acele caracteristici ce sunt considerate importante pentru reprezentarea acestuia în
contextul în care va funcţiona. De exemplu, dacă dorim să creăm modelul unei maşini în scopul
studierii performanţelor tehnice ale acesteia, atunci modelul realizat va conţine informaţiile
despre viteză, consum, putere, etc., dar nu va conţine date despre culoarea sau materialul din care
sunt confecţionate scaunele, deoarece acestea nu au nici un rol în contextul respectiv.
Un model informatic, realizat pentru a fi implementat pe calculator, conţine informaţii
(date) şi prelucrări, care provin din caracteristicile (proprietăţile) şi acţiunile (metodele)
obiectului, fenomenului sau procesului din lumea reală.
În acest caz, vom avea deci două procese de modelare, şi anume: modelarea datelor şi
modelarea prelucrărilor. Aceste procese de modelare, vor parcurge mai multe grade de
abstractizare, obţinându-se mai multe tipuri intermediare de modele: conceptual, logic şi tehnic.
Modelul care poate fi implementat pe calculator este cel care are gradul de abstractizare cel
mai mare (modelul tehnic). După efectuarea codificării informaţiilor (datelor) din modelul tehnic,
acestea, într-un calculator, pot fi memorate, transmise sau supuse execuţiei anumitor operaţii.
Scopul modelării este studiul unui obiect, fenomen sau proces real, prin simularea
diferitelor situaţii în care se poate afla acesta.

• În figura de mai
jos este prezentată
activitatea de
modelare
efectuată asupra
unui obiect,
fenomen sau
proces real în
scopul realizării
unei aplicaţii
informatice (care
se concretizează
practic prin
implementarea pe

17
calculator a modelelor tehnice - de date şi prelucrări - prin folosirea anumitor metode, tehnici şi
instrumente).
Modelarea conceptuală
Modelul conceptual - reprezintă definirea realităţii obiectului supus modelării printr-un
ansamblu de concepte şi reguli de combinare a acestor concepte.
Modelul conceptual este definite sub forma unor enunţuri, cu un grad de generalitate foarte
ridicat, ce duc la o asemănare cât mai apropiată între obiect şi model. Fiind cel mai apropiat de
realitatea obiectivă, gradul de abstractizare introdusă de modelul conceptual este scăzut.
Modelul conceptual cuprinde trei aspecte ale analizei obiectului supus modelării şi anume:
1) Analiza structurală, statică - care studiază componentele obiectului supus modelării
precum şi legăturile stabilite între acestea;
1) Analiza comportamentală (temporală), dinamică - care studiază: stările prin care trec
componentele şi legăturile obiectului ca reacţie la apariţia unor anumite evenimente externe,
precum şi a efectelor provocate asupra acestora în perioada tranziţiei de la o stare la alta;
2) Analiza funcţională - care studiază transformările produse în componentele şi legăturile
obiectului pentru satisfacerea cerinţelor determinate de funcţionarea sistemului (cerinţele
informaţionale) - adică a prelucrărilor efectuate asupra datelor;
Modelul conceptual al datelor (MCD) are două părţi esenţiale: conceptele şi legăturile între
concepte. Conceptele se creează în funcţie de scopul urmărit şi de interdependenţa dintre
elemente.
Modelarea logică
Modelarea logică reprezintă aducerea modelului conceptual într-o formă în care prin
precizarea anumitor metode de organizare şi prelucrare a datelor, sunt stabilite anumite cerinţe
informatice pe care modelul trebuie să le îndeplinească.
Astfel, pentru crearea modelului logic al datelor (MLD), trebuie ţinut cont de modul de
organizare pe care îl vor avea acestea pe calculator, şi anume (aşa cum se va arăta în continuare)
în fişiere clasice sau în baze de date. De asemenea dacă se doreşte un model logic bazat pe baze
de date, va exista posibilitatea alegerii între mai multe tipuri de arhitecturi (ierarhic, reţea,
funcţional, deductiv, orientat obiect, etc.).
De asemenea, pentru crearea modelului logic al prelucrărilor (MLP), trebuie ţinut cont în
general de principiile sistemului de programare ce se va utiliza: procedural, formal, LMD (limbaj
de manipulare a datelor) etc.
Modelul logic relaţional, creează suportul necesar pentru definirea bazelor de date
relaţionale (ca Microsoft Access). Elementele de bază definite în acesta sunt relaţiile (ce provin
din entităţile şi asocierile modelului conceptual).

18
 Modelarea tehnică
Modelul tehnic1, reprezintă aducerea modelului logic într-o formă precisă, dependentă
strict de hardware-ul (calculatoarele, reţeaua de calculatoare, echipamentele de transmisie a
datelor, etc.) şi de software-ul(sistemul de operare, limbajele de programare, SGBD-ul (Sistemul
de gestiune al bazelor de date), alte programe utilitare, etc.) ce vor fi efectiv utilizate, prin
modificarea componentelor definite la nivel logic funcţie de facilităţile oferite de echipamentele
şi produsule informatice folosite.

1
În această lucrare ne vom referi la modelul tehnic implementat prin bazele da date
Microsoft Access. Elementele principale ce definesc acest model sunt prezentate în cadrul
acestui capitol.
19
 Curs 3
Modelarea logică şi fizică a datelor
0.1 Modelarea logică a datelor
Modelarea conceptuală are mai multe tipuri de exprimare. Modelul Entitate-Relaţie, model
ce trebuie adus la o structură care să permită prelucrarea datelor pe suport.
Există două tipuri de organizare a datelor pe suport:
− Fişiere de date
− Baze de date
Un fişier clasic este un ansamblu de înregistrări, care în general au aceeaşi structură,
fiecare înregistrare având drept caracteristică noţiunea de câmp.
Un fişier clasic nu poate avea identificatori, ci trebuie supus unor prelucrări pentru a
funcţiona corect, ceea ce înseamnă că nu poate prelua toate caracteristicile unui model
conceptual.
Conceptul de bază de date a apărut pentru crearea unei structuri de date care să elimine
cele trei mari neajunsuri introduse de programarea cu fişiere clasice:
− Independenţa
− Redundanţa
− Integritatea datelor

Modelarea bazată pe conceptul de bază de date

Există 3 categorii de administrare a bazelor de date ce dau naştere la 3 tipuri de modelare logică:
 Modelarea Ierarhic-Arborescentă
 Modelarea în Reţea
 Modelarea Relaţională
Fiecare categorie are o anumită structură, ceea ce presupune ca de la modelul EA să ajungem la
modelul respectiv.

20
Modelul Ierarhic

În acest model, datele sunt organizate într-o structură arborescentă ramificată, cu un singur vârf,
sub forma unei piramide. Fiecare nod din arbore corespunde unei clase de entităţidin lumea
reală, iar drumurile dintre noduri reprezintă relaţiile existente între obiecte. Într-o asemenea
structură, fiecare părinte poate avea mai mulţi copii, dar un copil nu poate avea decât un singur
părinte.
Dezavantajele acestui model sunt următoarele:
 Mărimea exagerată a timpului de regăsire a informaţiilor
 Numărul de ierarhii posibile creşte combinatoric cu numărul înregistrărilor
 Această abordare nu este posibilă pentru anumite structuri de date.
Modelul logic trebuie creat astfel încât să preia cât mai multe caracteristici ale modelului
conceptual.

1Modelul în Reţea

Reţeaua reprezintă o colecţie de noduri – entităţi şi legături – relaţii ( un graf ) fiecare nod
putând fi legat de oricare altul. Modelul este destul de performant – se apropie mai mult de ER –
dar foarte complicat şi dificil de implementat.
1. Redundanţă – nu există.
2. Integrităţi – există pentru că se apropie de modelul ER.
3. Prelucrări – legăturile formează trasee care permit o regăsire uşoară a informaţiilor de pe
orice nivel, însă o actualizare a structurii (modificarea nodurilor sau legăturilor ) creează
probleme deosebit de complicate şi complexe.
0.1.1 Modelul relaţional
Din punct de vedere fizic are mai multe implementări, fiecare fiind mai mult sau mai puţin
fidele MC: ACCESS, SQL , FOX , ORACLE.
Modelul este puternic, dar în acelaşi timp este flexibil , simplu şi natural, permiţând o
proiectare relativ uşoară a structurilor de date. Dezavantajul îl reprezintă creşterea redundanţei
datelor faţă de celelalte 2 modele.

DEFINITII
➢ Relaţia

21
 − este o submulţime a produsului cartezian de N domenii
− se prezintă sub formă bidimensională (tabelară) pe linii şi coloane
− este formată din linii (rânduri) şi coloane
− mai este numită şi tabelă
➢ Tuplul
− reprezintă o linie în cadrul tabelului
− se mai numeşte înregistrare (în engleză "record")
➢ Domeniul
− reprezintă un set de valori pe care le poate lua o dată (un atribut).
Exemplu.Ziua = {luni, marţi, miercuri, joi, vineri, sâmbătă, duminică} | Trimestru =
{1,2,3,4}
➢ Atributul

22
 − reprezintă o caracteristică care poate lua valori într-un domeniu, fiecărei
caracteristici fiindu-i rezervată o coloană în cadrul relaţiei.
➢ Cheia primară
− reprezintă un atribut sau un grup minimal de atribute ale cărui realizări pot permite
identificarea unică a unui tuplu într-o tabelă.
➢ Cheia candidat (alternativă)
− reprezintă un atribut sau grup de atribute care pot prin realizările lor să identifice
un tuplu;
− dintre cheile candidate se alege atributul sau grupul de atribute care va juca rol
de cheie primară.
➢ Cheia externă
− este un atribut din schema unei tabele care joacă rol de cheie primară într-o altă
tabelă;

23
 − atributul cu rol de cheie externă trebuie să respecte cerinţele de integritate
referenţială.

Unde: D2 ⊆ D1 - această incluziune reprezintă integritatea referenţială.

➢ Schema unei relaţii.

− reprezintă lista atributelor aparţinând relaţiei, împreună cu domeniile lor.
➢ Gradul relaţiei.
− reprezintă numărul de coloane (atribute) ale relaţiei.
➢ Cardinalitatea relaţiei.
− reprezintă numărul de rânduri (înregistrări, tupluri) ale acesteia.

Exemplu.

• Schema relaţiei:

− Contracte {Nr.Contract, Data Încheiere, Durata, Valoare, Cod Client} unde:

− Durata {6, 12, 18, 24, 30, 36, 42}

• Gradul relaţiei:5

• Cardinalitatea relaţiei:3

0.1.2 Reguli de trecere de la modelul EA la schema bazei de date

relaţionale.
➢ Regula nr. 1
− Fiecărui tip de entitate din modelul ER, îi este asociată schema unei relaţii formată
din toate atributele tipului de entitate.

•Identificatorul tipului de
entitate devine cheia primară a
relaţiei
➢ Regula nr. 2
−Dacă într-o asociere
binară A, fiecare dintre
entităţi prezintă pentru
cuplul entitate-asociere,

24
cardinalitatea (0,1) sau (1,1), atunci se adaugă la schema relaţiei R1 (corespunzătoare
entităţii E1) cheia primară a celeilalte entităţi E2 participantă la asociere.
− Cheia externă va trebui să respecte restricţia de integritate referenţială.

CARD { NrCard,
DataEmitere,
TipCard,
LimitaCard,
NrCont}
CONT { NrCont,
DataDeschidere }
➢ Regula nr. 3
−Dacă într-o
asociere A,
există o
singură
entitate E1
pentru care
cardinalitatea
cuplului EA
este egală cu
(0,1) sau
(1,1), atunci
se adaugă la
schema
relaţiei R1

25
(corespunzătoare entităţii E1) cheia primară a relaţiei R2 (care corespunde entităţii E2
participante la asociere);
− Acest "transport" al cheii primare a relaţiei R2 la schema relaţiei R1 (unde va juca
rolul de cheie externă) este impus de rolul dominant al primei relaţii asupra celei de a
doua;

•Când între două

entităţi se stabileşte o
asociere (1:n)
înseamnă că entitatea
care prezintă pentru
cuplul EA
cardinalitatea (0,n) sau
(1,n) va fi dominantă,
iar cea de a doua va fi
considerată entitate
"fiu" şi va primi drept
cheie externă cheia
primară a entităţii
"părinte", iar dacă
sunt definite atribute
pentru asocierea A ele
vor fi cuprinse în
schema relaţiei "fiu";

BROKER
{CodId, Nume,
Prenume, Vechime,
CodSVM}
SVM {CodSVM,
Denumire, Adresa,
Telefon }
➢ Regula nr. 4
−Dacă într-o
asociere A,
nu există nici
o entitate E
pentru care
cardinalitatea
cuplului EA
să fie egală

26
cu (0,1) sau (1,1), atunci se va defini o a treia relaţie cuprinzând în schema sa cheile
primare ale celor două relaţii (corespunzătoare entităţilor participante la asociere)
împreună cu toate atributele definite pentru asocierea A.

Punct Schimb
{NrPunctSchimb,
Adresa, Telefon}
Valută {
SimbolValuta,
Denumire, Ţara}
Operează {
NrPunctSchimb,
SimbolValuta}
➢ Asocierile
ciclice
−în cazul
asocierilor
ciclice se
aplică tot
regulile 1-4
in funcţie de
cardinalităţile
celor două
cupluri EA
prezente.
➢ Transpunere
a generalizării şi
specializării
•Definirea
modelului logic al
datelor plecând de la
modelul EA care a
integrat şi conceptele
de generalizare şi
specializare se poate
realiza în două
modalităţi:

27
 − dând prioritate specializării, caz în care atributele tipului sunt aspirate la nivelul
subtipurilor;
− dând prioritate generalizării, cu sau fără conservarea subtipurilor, caz în care se
produce o "aspirare" a atributelor subtipurilor la nivelul tipului.

FAVORIZAREA
SPECIALIZĂRII
Acţiune {SerieNr,
NurneEmitent,
DataEmitere,
ValoareNominala,
ValoareActuală}
Obligaţiune
{SerieNr,
NurneEmitent,
DataEmitere,
ValoareNominala,
Dobândă}
FAVORIZAREA GENERALIZĂRII
Titlu de Valoare {SerieNr, NurneEmitent, DataEmitere, ValoareNominala}
Acţiune {SerieNr, ValoareActuală}
Obligaţiune {SerieNr, Dobândă}
0.2 Modelarea fizică a datelor
➢ Criterii utilizate în alegerea SGBD-ului:
2) Cerinţele utilizatorului privitoare la:
− tipurile de aplicaţii
− timpul de răspuns
− confidenţialitatea datelor
− securitatea datelor
− uşurinţa în exploatare a sistemului
3) Caracteristici, facilităţi, instrumente oferite:
− instrumente pentru generarea de: ecrane, rapoarte, aplicaţii etc.
− interfaţa uşor de utilizat pentru definirea cererilor (interfaţa grafică)

28
 − facilităţi privind importul şi exportul de date
− documentarea bazei de date
− facilităţi oferite administratorului bazei de date
− securitatea bazei de date
− uşurinţa în utilizarea SGBD-ului
4) Cerinţe de ordin tehnic:
− portabilitatea SGBD-ului
− portabilitatea colecţiilor de date şi a aplicaţiilor
− facilităţi de încărcare, exploatare şi refacere a bazei de date
5) Cerinţe de ordin economic:
− încadrarea în bugetul existent
− timpul şi resursele financiare necesare pentru pregătirea utilizatorilor şi trecerea
la exploatarea curentă a bazei de date.
➢ Definirea modelului fizic al datelor (MFD)
• se realizează în conformitate cu SGBD-ul ales;

• rezultatul acestei treceri de la MLD la MFD este reprezentat de schema internă a

bazei de date;

• pentru modelul logic definit anterior în această etapă vor fi create tabelele bazei de
date, pentru fiecare dintre acestea precizându-se toate elementele necesare conform
specificaţiilor de definire caracteristice SGBD-ului;

• această etapă de modelare nu se limitează doar la definirea modelului fizic al datelor

(MFD) ci urmăreşte şi optimizarea MFD ceea ce ar presupune asigurarea:

− unui timp minim de acces la nivel fizic pentru prelucrările cele mai frecvente;
− o mai mare independenţă a stocării fizice a datelor în raport cu prelucrările.

• Realizarea acestor deziderate se poate materializa în:

− definirea indecşilor atât pe cheile primare cât şi pe chei alternative de căutare în

raport cu natura diverselor căutări în baza de date;
− controlul alocării spaţiului de disc afectat bazei de date prin utilizarea de partiţii
(SGBD Oracle);

29
 − asigurarea proximităţii stocării ansamblurilor de date manipulate frecvent în
anumite prelucrări (utilizarea clusterelor de către SGBD Oracle de exemplu).

• Determinarea dimensiunii viitoarei baze de date şi a spaţiului de memorie necesar

sistemului informatic.

• în cazul în care am optat pentru utilizarea SGBD Access crearea tabelelor bazei de
date se va realiza prin iniţierea acţiunii de creare a obiectelor de tip tabel (Table) pentru fiecare
relaţie precizându-se proprietăţile corespunzătoare atributelor declarate.
Exemplu.

Contract {NrContract, DataÎncheiere, Durata, Valoare}

30