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ţia poate 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.

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

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.

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.

2

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:

- 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,

3

- 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,

- î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:

o date,

o structura datelor,

o statistici,

o 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

4

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,

- 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:

o utilizatori conversaţionali,

o utilizatori iniţiaţi.

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

5

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,

- 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ţă.

6

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.

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ţieprezentâ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).

7

î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.

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.

9

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

Modelul tridimensional promovat de metoda de proiectare MERISE se caracterizează prin reprezentarea grafică pe trei axe fiecare dintre acestea

10

corespunzând ciclului de viaţă al sistemului, ciclul de decizie şi respectiv ciclului abstractizării.

11

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.

12

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.

13

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.

Evoluţia metodelor de proiectare

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

14

Abordării sistemelor informatice Dezvoltării bazei conceptuale specifice proiectării şi realizării sistemelor informatice (mai

alesodată 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 deintegrare 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.

15

Aplicaţia informatică

Obiect, Proces, FenomenProprietăţi (caracteristci, atribute)

Metode (acţiuni)

Informaţii Prelucrări

Mod

elare

Modelul conceptual al datelor

Modelul tehnic al datelor

Modelul logic al datelor

Modelul conceptual al prelucrărilor

Modelul logic al prelucrărilor

Modelul tehnic al prelucrărilor

calculator

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 calculator a modelelor tehnice - de date şi prelucrări - prin folosirea anumitor metode, tehnici şi instrumente).

16

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;

2) 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;

3) 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).

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.

17

Curs 3Modelarea logică şi fizică a datelor

I.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.

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ăţi din 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.

18

Tabela BROKER

Tuplu (înregistrare)

Cheie primară Atribut

Modelul î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.

I.1.2 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

− 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

− reprezintă o caracteristică care poate lua valori într-un domeniu, fiecărei caracteristici fiindu-i rezervată o coloană în cadrul relaţiei.

Cheia primară

19

Tabela BROKER

D1

Tabela SVM

D2

Tabela CONTRACTE

− 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ă;− 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

I.1.3 Reguli de trecere de la modelul EA la schema bazei de date relaţionale.

Regula nr. 1

20

SVM

CodSVMNumeAdresaCUI

SVM {CodSvm, Nume, Adresa, CUI}

CARD

NrCardDataEmitereTipCardLimitaCard

CONT

NrContDataDeschidere

Corespunde1,1 0,1

BROKER

CodIdNumePrenumeVechime

SVM

CodSVMDenumireAdresaTelefon

Lucrează pentru1,1 1,n

− 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, 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ă.

Exemplu.

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 (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

21

Punct Schimb

NrPunctSchimbAdresaTelefon

Valuta

SimbolValutaDenumireŢara

Operează cu1,n 0,n

Titlu de Valoare

SerieNrNumeEmitentDataEmitereValoareNominală

Obligaţiune

Dobândă

Acţiune

ValoareActuală

#

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ă 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.

Exemplu.

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. Transpunerea 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:

− 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.

Exemplu.

22

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ă}

I.2 Modelarea fizică a datelor

Criterii utilizate în alegerea SGBD-ului:

4) 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

5) 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ă)− 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

6) 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

7) 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:

23

− 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);− 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}

24