Universitatea Transilvania din Braşov Facultatea de Inginerie tehnologică Catedra de Inginerie economică şi sisteme de producţie

Şef lucr. dr. ing. Andrea DEACONESCU

PRELUCRAREA DATELOR pentru anul II Inginerie economică (4 ani de studiu) resp. BAZE DE DATE Pentru anul IV Inginerie economică (5 ani de studiu)

Braşov 2006
1

2

Cuprins
1. Baze de date. Proiectare. Implementare. Gestionare.................................................................................5 1.1 Introducere în BD. Tratarea datelor. Sisteme de gestionare a bazelor de date. Sisteme bazate pe fişiere..........................................................................................................................................................5 1.1.1 Introducere.....................................................................................................................................5 1.1.2 Tratarea datelor prin sisteme bazate pe fişiere ..............................................................................6 1.1.3 Tratarea datelor prin baze de date (BD).........................................................................................7 1.1.4 Sistemul de gestionare a bazei de date (SGBD)............................................................................7 1.1.5 Componentele mediului SGBD.....................................................................................................8 1.1.6 Proiectarea BD – schimbarea de paradigmă................................................................................10 1.1.7 Poziţiile persoanelor din mediul BD............................................................................................10 1.1.8 Avantajele şi dezavantajele SGBD..............................................................................................11 1.1.8 Rezumatul capitolului 1.1 ...........................................................................................................13 1.1.9 Întrebări la capitolul 1.1...............................................................................................................13 1.2. Modelul relaţional (SGBDR).............................................................................................................14 1.2.1 Terminologie................................................................................................................................14 1.2.2 Integritatea relaţională.................................................................................................................16 1.2.3 Vederi...........................................................................................................................................17 1.2.4 Rezumatul capitolului 1.2............................................................................................................18 1.2.5 Întrebări la capitolul 1.2...............................................................................................................19 1.3 Planificarea, proiectarea şi administrarea BD.....................................................................................19 1.3.1 Ciclul de viaţă al sistemelor informaţionale................................................................................19 1.3.2 Fazele proiectării BD...................................................................................................................21 1.3.3 Proiectarea aplicaţiilor.................................................................................................................22 1.3.4 Administrarea datelor şi a bazei de date......................................................................................23 1.3.5 Rezumatul capitolului 1.3............................................................................................................24 1.3.6 Întrebări la capitolul 1.3...............................................................................................................25 1.4. Modelarea Entitate-Relaţie (ER).......................................................................................................25 1.4.1 Conceptele modelului ER............................................................................................................25 1.4.2 Constrângeri structurale...............................................................................................................31 1.4.3 Problemele modelului ER............................................................................................................35 1.4.4 Rezumatul capitolului 1.4............................................................................................................38 1.4.5 Întrebări la capitolul 1.4...............................................................................................................39 1.5 Normalizarea.......................................................................................................................................39 1.5.1 Scopul normalizării......................................................................................................................39 1.5.2 Redundanţa datelor şi anomaliile de reactualizare......................................................................39 1.5.3 Dependenţe funcţionale...............................................................................................................40 1.5.4 Procesul de normalizare...............................................................................................................41 1.5.5 Prima formă normală...................................................................................................................42 1.5.6 A doua formă normală (2NF)......................................................................................................45 1.5.7 A treia formă normală (3NF).......................................................................................................47 1.5.8 Rezumatul capitolului 1.5............................................................................................................49 1.5.9 Întrebări la capitolul 1.5...............................................................................................................50 1.6 Metodologia de proiectare conceptuală a bazelor de date..................................................................50 1.6.1 Pasul 1. Construirea modelului de date conceptual local pentru fiecare vedere a utilizatorilor..50 1.6.2 Rezumatul capitolului 1.6............................................................................................................54 1.6.3 Întrebări la capitolul 1.6...............................................................................................................54 1.7 Metodologia de proiectare logică a bazelor de date pentru modelul relaţional..................................54
3

1.7.1 Pasul 2. Construirea şi validarea modelului de date logic pentru fiecare vedere a utilizatorilor.54 1.7.2 Pasul 3. Construirea şi validarea modelului de date logic global................................................63 1.7.3 Rezumatul capitolului 1.7............................................................................................................65 1.7.4 Întrebări la capitolul 1.7...............................................................................................................66 1.8 Metodologia de proiectare fizică a bazelor de date pentru bazele de date relaţionale........................66 1.8.1 Pasul 4. Transformarea modelului de date logic global pentru un SGBD ţintă...........................66 1.8.2 Pasul 5. Proiectarea reprezentării fizice.......................................................................................71 1.8.3 Pasul 6. Proiectarea mecanismelor de securitate.........................................................................79 1.8.4 Pasul 7. Monitorizarea şi reglarea sistemului operaţional...........................................................83 1.8.5 Rezumatul capitolului 1.8............................................................................................................84 1.8.6. Întrebări la capitolul 1.8..............................................................................................................85

4

1. Ce atribute ar fi de interes? Depinde de sigur de scopul pentru care a fost creat tabelul. . Vedem BD în viaţa de zi cu zi – listele de ofertă ale diferiţilor furnizori de cărţi.1 Introducere în BD. proiectarea şi administrarea bazelor de date. pentru a extrage informaţiile utile. reţea sau relaţional. şi atributele sunt stabilite la momentul configurării bazei de date. Ca exemplu aplicaţia poate fi un 5 . reprezentând o lume în miniatură. stocuri. o societate poate avea în baza sa de date un tabel cu angajaţii săi. Imaginaţi-vă un set de fişe. CD-uri.1. sau database management system (DBMS) este softul care permite ca bazele de date să fie definite/configurate. Modelul relaţional de BD Există trei modele uzuale de implementare de BD: ierarhic. O astfel de colecţie. resurse umane. fişe sau înregistrări de prelucrat de un anumit program etc. Baze de date. de regulă sunt utilizate pentru sisteme-cadru generale. Sisteme bazate pe fişiere 1. a fost construită pentru a servi pentru o anume aplicaţie. întreprinderi. datorită modelului simplu. De exemplu. Un sistem de gestionare de bază de date (SGBD).Cunoaşterea noţiunilor de bază privind sistemele informatice de gestionare a bazelor de date relaţionale. Sistemele de gestionare a bazelor de date relaţionale (SGBDR) au cunoscut o largă răspândire.Planificarea. Bazele de date au apărut ca răspuns la nevoia organizaţiilor (instituţii. Proiectare. de exemplu. care împreună reprezintă o “cheie” care defineşte fiecare entitate în mod unic. societăţi comerciale etc. au o idee despre ce ar putea fi o bază de date (BD). Implementare. Articolele dintr-o BD se manipulează.1. sistemul de gestionare de baze de date relaţionale.1 Introducere Cu siguranţă cei mai mulţi dintre Dvs. vânzări etc. Tratarea datelor. piesele în stoc de furnizat pentru un anumit proiect. cartea de telefon. cu un rând/înregistrare pentru fiecare angajat. relaţional de date pe care-l utilizează: • Datele se prezintă sub forma unei colecţii (unui set) de relaţii • Fiecare relaţie are forma unui tabel (cea mai importantă componentă a unei BD) • Rândurile (înregistrările) tabelului reprezintă entităţi • Coloanele (câmpurile) tabelului sunt atribute/proprietăţi ale acestor entităţi • Fiecare tabel are un set de atribute. contabilitate. vaste şi nu fac obiectul cursului nostru.) de a eficientiza evidenţa activităţii lor. construite şi exploatate/manipulate. o BD. aprovizionare. Obiectul cursului nostru este SGBDR. cu aplicaţii în MS-Access. Modelele ierarhic şi reţea se bazează pe parcurgerea legăturilor dintre date pentru a lucra cu baza de date. din toate punctele de vedere: producţie. Gestionare Obiectivele acestui modul sunt: . între care există legături logice. atunci când utilizăm termenul de bază de date ne referim la o colecţie structurată de articole de date. Fiecare se bazează pe conceptul de date stocate ca set sau mulţime de înregistrări. Sisteme de gestionare a bazelor de date. Exprimându-ne mai precis.

numele proiectelor către care se livrează. nr. specific fiecărui compartiment. număr contract. Compartimentul magazie (al firmei) va ţine fişiere cu: . Atunci când datele sunt izolate în fişiere separate. seria. că mai multe compartimente au introdus aceleaşi date în fişierele lor.ştat de plată. Observăm în exemplul nostru. va trebui să creăm un fişier temporar care să cuprindă toate aceste date. Dublarea datelor. costul.componentele în stoc. De exemplu dacă vrem să aflăm care componente până la o anumită limită de preţ şi în ce cantitate se află în stoc pentru un anumit proiect. o Alterarea integrităţii datelor. atunci trebuie de identificat toate programele care lucrează cu acest fişier. prin dublare. . seria. denumirea. documentaţie însoţitoare de ieşire (inclusiv numele proiectelor/clienţilor către care se furnizează) Compartimentul vânzări (al firmei) va ţine fişiere cu: . necesitând sincronizarea prelucrării (în compartimente diferite) a două sau mai multe fişiere. pe fişa fiecărei componente apărând denumirea. Dependenţa de date. deci va fi nevoie. tipuri de componente livrate . pentru a opera 6 - - . cele care ar trebui să fie disponibile sunt mai greu de accesat. Compartimentul contabilitate (al firmei) va ţine fişiere cu: . deci alte costuri. Rezultă următoarele limitări ale sistemelor bazate pe fişiere: Separarea şi izolarea datelor.componentele în stoc.cerinţele clienţilor. ocupă spaţiu suplimentar de stocare.1. costul. bucăţi etc. nr. aceleaşi componente vor apărea în fişierele diferitelor compartimente cu preţ diferit. Din cauza modului de abordare descentralizat. va trebui sa extragem date din fişierul cu proiecte şi apoi din cel cu stocuri (fişiere existând la compartimente diferite). Extragerea corectă de date este dificilă. gradul de urgenţă şi prioritate etc.2 Tratarea datelor prin sisteme bazate pe fişiere Superioritatea administrării datelor dintr-o organizaţie cu ajutorul unui sistem de gestionare de baze de date (SGBD) rezultă dintr-o scurtă comparaţie între sistemele tradiţionale de date. inclusiv nume clienţi. dacă intrarea unor componente cu preţ nou nu este comunicată de către compartimentul contabilitate celor de la magazie. Exemplu: o firmă care furnizează componente pentru diferite proiecte/clienţi. cum ar fi producerea de rapoarte. Fiecare program defineşte şi gestionează propriile date.ieşirile de componente. intrare. în afară de nume. Dublarea datelor este de nedorit din următoarele cauze: o Risipă: introducerea datelor de mai multe ori costă timp şi bani. Dacă este necesar de modificat structura unui fişier (de ex. bucăţi etc. 1. deci datele nu mai concordă. bazate pe fişiere şi sistemele de gestionare a bazelor de date (SGBD) Sistemul bazat pe fişiere este o colecţie de programe de aplicaţie care efectuează servicii pentru utilizatorii finali. cu caracteristicile şi cantităţile de componente. inclusiv descrierea componentelor. cu detalierea componentelor necesitate. De exemplu. documentele de achiziţie. mărimea unui câmp). cod angajat şi de informaţii referitoare la adresă şi salariu. tratarea datelor pe bază de fişiere a dus la dublarea necontrolată a datelor.

Vom reveni în detaliu asupra modelului ER de BD. reprezentate printr-o diagramă entitate – relaţie (ER). Interogarea fixă sau proliferarea programelor de aplicaţie.modificările respective în fiecare dintre ele. O bază de date este deci o colecţie autodescrisă de înregistrări integrate. a proliferat numărul de aplicaţii.3 Tratarea datelor prin baze de date (BD) Baza de date este o colecţie partajată de date între care există relaţii logice (şi o descriere a acestor date). cu documentaţie limitată şi dificil de întreţinut. gestionate de sisteme de gestionare a bazelor de date (SGBD). (2) nu există control asupra accesului şi manipulării datelor dincolo de cel impus de programele de aplicaţie. BD conţine datele operaţionale ale organizaţiei şi descrierea acestora. care trebuia să scrie interogările. deci nu exista partajarea accesului pentru mai mulţi utilizatori din acelaşi compartiment. Este posibil ca fiecare compartiment să-şi genereze fişiere în alt limbaj de programare. structura fişierelor va fi dependentă de limbajul în care este scris programul. va trebui să intervină un programator care să scrie un program de transformare a fişierelor într-un format comun. Pentru a satisface numărul crescând de cereri de interogări. Tratarea datelor prin sisteme de fişiere a reprezentat un progres semnificativ faţă de sistemele manuale. Au crescut cererile de interogări noi sau modificate. Această caracteristică a sistemelor bazate pe fişiere se numeşte dependenţă program-date. Ca urmare a apărut o nouă tratare a datelor. prin baze de date (BD). 1. care necesitau de fiecare dată intervenţia programatorului. s-a ajuns la fixarea numărului de interogări disponibile. au rezultat programe ineficiente.1. plecând de la câmpul “denumire componente” existent în fişierele ambelor compartimente. Baza de date nu mai este deţinută de un singur compartiment al unei organizaţii. Pentru a limita volumul de lucru al programatorilor. 1. atributele şi relaţiile logice dintre acestea. în loc de a fi stocată independent. ci este o resursă comună. dacă compartimentul vânzări vrea să afle detaliile legate de stocul existent pentru o anume componentă.date.1. De exemplu.4 Sistemul de gestionare a bazei de date (SGBD) 7 . dacă fişierele sunt generate cu limbaje diferite. Astfel au apărut două situaţii. O BD relaţională conţine entităţile. va încerca să acceseze fişierul corespunzător al compartimentului magazie. Datele sunt integrate. Accesul la fişiere este limitat la un singur utilizator o dată. cu o dublare minimă. scrise în grabă. - Limitările tratării datelor bazată pe fişiere au două cauze: (1) definiţia datelor este încorporată în programele de aplicaţie. partajată. Această caracteristică BD este cunoscută şi ca independenţa program . proiectată pentru a satisface necesităţile informaţionale ale unei organizaţii. Incompatibilitatea fişierelor.

. numită limbaj de interogare. De exemplu redenumirea câmpurilor după preferinţele utilizatorului. Astfel se vor afişa numai acele date din BD care sunt utile utilizatorului. Un astfel de limbaj de interogare este SQL. pentru sistemele de operare Windows 9x şi Windows NT 4+. o Un sistem de control al utilizării simultane. Un SGBD poate necesita un anumit tip de elemente hardware sau de sistem de operare. care restaurează BD într-o stare precedentă concordantă.Oferă accesul controlat la BD. DML poate oferi o interogare generală a acestor date. un SGBD necesită un minimum de memorie (MS-a: size: 2.SGBD este un sistem de programe care permite utilizatorului definirea. pentru a funcţiona. o O imagine coerentă. prin modul de vizualizare se va afişa în continuare structura prestabilită a BD. Un SGBD oferă o serie de facilităţi: . Astfel SGBD poate furniza: o Un sistem de securitate. sau poate funcţiona pe o diversitate de elemente hardware şi platforme. de asemenea. o Un catalog accesibil utilizatorilor. Modurile de vizualizare oferă şi alte avantaje: o Un anumit nivel de securitate. dar care nu interesează utilizatorul. care pot fi un singur PC până la o reţea.Oferă generarea de vederi/views numite şi moduri de vizualizare a BD prin mecanismul de vizualizare.Date -Hardware Maşină Software -Punte -. SGBD constă în elemente de software care interacţionează cu programele de aplicaţie ale utilizatorului pe de o parte şi cu baza de date pe cealaltă. o Un sistem de control al refacerii. Access 2000 este de ex. care permite accesul partajat la BD. care elimină utilizarea unui set fix de interogări disponibile. 8 . reactualizarea. ca urmare a unei defecţiuni hard sau soft. care conţine descrieri ale datelor din BD . BD fiind un depozit unic şi central de date şi descrieri de date. se exclud date care nu trebuie văzute de anumiţi utilizatori.5 Componentele mediului SGBD Mediul SGBD are cinci componente principale: -. pentru a împiedica accesul utilizatorilor neautorizaţi o Un sistem de integritate.32 KB) şi spaţiu de disc (MS-Access: size on disk: 4 KB).1. neschimbată a structurii BD. un SGBD relaţionale pe 32 biţi. chiar dacă BD însăşi este modificată. ştergerea şi extragerea de date printr-un limbaj de manipulare a datelor (DML). crearea şi întreţinerea bazei de date şi accesul controlat la aceasta. pentru crearea de aplicaţii clasice sau de tip client-server pentru BD. care menţine concordanţa datelor stocate.permite definirea BD printr-un limbaj de definire a datelor (DDL) . eliminânduse încărcarea rezultatului unei interogări cu date existente în BD. o O personalizare a aspectului BD.Proceduri – Om Persoane Hardware Evident. 1.permite inserarea. SGBD au nevoie de elemente hardware. ca în cazul tratării datelor prin sisteme de fişiere.

v.1 Software Componenta soft cuprinde programele SGBD şi programele de aplicaţie împreună cu sistemele de operare. al utilizatorului. Cobol. Fortran) sau de generaţia a patra – SQL. SGBD poate avea propriile instrumente de generaţia a patra. adică partea din SGBD care constituie interfaţa cu utilizatorul.deschiderea unei sesiuni de lucru în SGBD. . reorganizarea BD pe mai multe discuri. deservite de un server central. Persoanele 9 .d.O configuraţie / arhitectură client-server este prezentată în figura 1. .p. arhivarea datelor etc.modificarea structurii unui tabel. pentru o organizaţie cu patru filiale legate într-o reţea de PCuri. adică date despre date. d. Pe calculatoarele din diversele locaţii/PC clienţi se află aplicaţiile front-end.Date operaţionale . cât şi utilizatorilor de BD şi pot cuprinde instrucţiuni referitoare la . adică partea din SGBD care administrează şi controlează accesul la BD. inclusiv software de reţea. Pe server se află programele back-end. .utilizarea unei anumite facilităţi a SGBD sau a unui program aplicaţie.efectuarea de copii de siguranţă a BD . care permit dezvoltarea rapidă de aplicaţii prin furnizarea unui limbaj de interogare şi a unor generatoare de rapoarte. .1.tratarea defecţiunilor hard sau soft. Datele Datele reprezintă cea mai importantă componentă a unui SGBD. 1. Fig. BD conţine: .Meta-date. fiecare având mai multe atribute (câmpuri). Instrumentele de generaţia a patra îmbunătăţesc productivitatea şi permit realizarea unor programe uşor de întreţinut. Programele aplicaţie sunt scrise într-un limbaj de programare din generaţia a treia (C.pornirea şi oprirea SGBD. Procedurile Procedurile se referă la instrucţiunile şi regulile care guvernează proiectarea şi utilizarea BD. Structura BD este numită schemă şi are mai multe tabele sau fişiere. Procedurile sunt necesare atât administratorilor. incorporat într-un limbaj de generaţia a treia. . grafică etc. dacă este cazul. datele = punte între componentele maşină şi cele umane. formulare. .

asigurarea de performanţe satisfăcătoare pentru aplicaţii şi utilizatori.responsabil cu proiectarea conceptuală/logică a BD .6 Proiectarea BD – schimbarea de paradigmă Structura unei BD (entităţile.proiectanţii de BD. Astfel rezultă BD ineficiente pentru cerinţele aplicaţiilor. .proiectarea şi implementarea BD. având următoarele sarcini: .programatorii de aplicaţii. atributele.7 Poziţiile persoanelor din mediul BD In acest paragraf se examinează a 5-a componentă a mediului SGBD. întreţinerea dificilă.securitatea şi controlul integrităţii BD.1.1. a. 1. Proiectanţii de BD logice: “ce anume?” 10 . .administratorii de date şi de BD.consultarea şi îndrumarea managerilor superiori cu privire la direcţia de dezvoltare a BD. Se pot identifica patru tipuri distincte de persoane implicate în mediul SGBD: .întreţinerea sistemului operaţional. Cauza principală a eşecurilor sistemelor informaţionale este lipsa aplicării unei metodologii de proiectare a BD în mod structurat. În cazul BD trebuie de considerat întâi datele apoi aplicaţiile. Administratorii de date şi de BD BD şi SGBD sunt resurse comune care trebuie gestionate ca orice resursă.utilizatorii finali. Abordarea proiectării unei BD este diferită de cea a sistemelor pe bază de fişiere.responsabil cu gestionarea resurselor de date: planificarea. . unde totul era dictat de nevoile aplicative ale departamentelor individuale.î BD să sprijine obiectivele generale ale organizaţiei. elaborarea şi întreţinerea strategiilor şi procedurilor bazei de date . . Această schimbare a modului de tratare se numeşte schimbare de paradigmă. 1. documentaţia este limitată. Administratorul de baze de date (DBA – data base administrator) este responsabil cu realizarea fizică a BD. relaţiile) este determinată în timpul proiectării BD.Sunt ultima componentă a unui mediu SGBD şi va fi discutată la paragraful „Poziţiile persoanelor din mediul SGBD”. Proiectanţii de BD Există proiectanţi de BD logice şi proiectanţi de BD fizice. . . Rolul DBA este mai tehnic şi necesită cunoaşterea în detaliu a SGBD şi a mediului acestuia. Sarcinile administratorului de date (DA = data administrator): . anume persoanele.

Proiectanţii de BD fizice (“Cum anume?”) preia modelul logic şi stabileşte realizarea fizică: . Utilizatorul simplu nu ştie nimic despre BD sau SGBD (de ex. reactualizare. Aceasta este sarcina programatorilor de aplicaţii. Utilizatorii finali Sunt clienţii pentru care a fost proiectată. modifică câmpul cu stocul de articole. Fiecare program conţine instrucţiuni care îi cere SGBD să efectueze o operaţie oarecare în BD (extragere. afişează preţul la casă).selectarea de structuri de stocare şi metode de acces specifice. orientat pe obiecte. Accesează BD prin programe de aplicaţie speciale. Strategia de stocare aleasă trebuie să ţină cont de modul de utilizare. Utilizatorii simpli nu sunt conştienţi de SGBD. programele de aplicaţie. Pot scrie programe de aplicaţie pentru uz personal.- se ocupă cu identificarea datelor (entităţi şi atribute) şi relaţiilor dintre acestea. opţiuni din meniu. ştergere de date). Utilizatorii sofisticaţi sunt familiarizaţi cu structura BD şi facilităţile SGBD. 11 . limbajele de programare etc. Ei folosesc comenzi simple.) b) proiectarea logică a BD. trebuie să cunoască foarte bine datele organizaţiei şi a regulilor de operare ale organizaţiei. Pot utiliza un limbaj de interogare de nivel înalt (SQL). caută preţul articolului respectiv în BD. pentru a le satisface necesităţile informaţionale.măsuri referitoare la securitatea datelor. ci se controlează volumul inerent al acesteia în BD. care se bazează pe un anumit model. Există totuşi un program care citeşte codul de bare. Etape de proiectare a BD logice: a) proiectarea conceptuală a BD.8 Avantajele şi dezavantajele SGBD Avantaje . în reţea. inserare. nu se elimină în întregime redundanţa. 1.Controlul redundanţei datelor. relaţional. trebuie să implice toţi posibilii utilizatori ai BD în modelul creat.transpunerea modelului logic de date într-un set de tabele şi constrângeri privind integritatea. . ierarhic. să se obţină performanţe bune ale datelor in activităţile legate de BD. implementată şi este întreţinută BD. independent de detaliile de implementare (de ex. proiectantul trebuie să cunoască funcţionalitatea acestui SGBD şi avantajele şi dezavantajele fiecărei variante de implementare a BD. şi de constrângerile asupra celor care vor fi stocate în BD. vânzătorul care citeşte codul de bare pentru a afla preţul unui produs.î. Programatorii de aplicaţii Odată realizată BD trebuie implementate programele de aplicaţie ce conferă funcţionalitatea cerută de utilizatorii finali. de ex. simplificatoare. SGBD utilizat.1. Proiectarea fizică a unei BD trebuie să ţină cont de SGBDul avut în vedere. Programele pot fi scrise într-un limbaj de generaţia a treia sau a patra. . a.

eliminându-se incoerenţa. 12 . integrarea ar face datele foarte vulnerabile.- Coerenţa datelor. Echilibrul între cerinţele aflate în conflict. Îmbunătăţirea serviciilor de salvare de siguranţă şi refacere. care uşurează întreţinerea aplicaţiilor din BD. Dezavantaje . Capacitatea de întreţinere îmbunătăţită. Productivitatea crescută. Nu este necesară realizarea zilnică de copii de siguranţă. SGBD furnizează standardele necesare aplicaţiei. se garantează alterarea datelor în situaţia când acelaşi fişier este utilizat simultan de mai mulţi utilizatori. Fără sisteme de securitate. de la DA la utilizatorul final. Aplicarea standardelor. dar fiind parte din BD. un sistem mainframe cu sute de utilizatori. prin integrare se pot aplica standarde organizaţionale. pt. . care permite alocarea fondurilor economisite pentru îmbunătăţirea sistemului. SGBD garantează coerenţa tuturor exemplarelor din articolul respectiv. fişierele sunt deţinute de compartimentele organizaţiei care le utilizează. formatul datelor. Îmbunătăţirea accesibilităţii datelor şi capacităţii de răspuns. . Economia de scală. ele sunt la dispoziţia tuturor utilizatorilor interesaţi.000 USD pt. două sau mai multe fişiere pot fi integrate. Se adaugă cheltuieli periodice anuale de întreţinere. orice reactualizare a unui articol (stocat o singură dată) se face o singură dată. Fiind un element soft foarte complicat.Costurile adiţionale pentru elemente hardware. pt. SGBD ocupă mult spaţiu pe disc şi necesită multă memorie pentru a funcţiona eficient. ca un SGBD să fie funcţional. Integritatea este exprimată prin constrângeri. naţionale sau internaţionale. Funcţionalitatea trebuie cunoscută de către toţi cei implicaţi în BD. chiar dedicat rulării SGBD. într-un SGBD descrierile datelor sunt separate de aplicaţii. fără a apela la programator. acesta va evolua într-un sistem soft extrem de complex. Dacă articolul este stocat de mai multe ori. aplicaţiile fiind imune la modificarea descrierii datelor. . este caracteristica de independenţă program-date. care va lua deciziile ce se impun şi va acorda prioritate aplicaţiilor majore. extrăgându-se mai multe informaţii. Partajarea datelor. convenţii referitoare la denumire. există un buget unic combinat. a facilita schimburi între sisteme. se referă la validitatea şi coerenţa datelor stocate. Mai multe informaţii obţinute de la aceeaşi cantitate de date. prin independenţa de date. BD proiectată poate fi greşită.Costul SGBD. un PC cu un utilizator. ca urmare a integrării datelor operaţionale. economisind timpul programatorului. care reprezintă reguli de coerenţă pe care BD nu are voie să le încalce. se referă la protecţia BD faţă de utilizatorii neautorizaţi. în loc de bugete pentru fiecare compartiment pentru crearea unui sistem propriu de BD bazat pe fişiere. variază în funcţie de mediu şi funcţionalitate. Se minimizează pierderile apărute ca urmare a unor defecţiuni. ca de ex. Securitatea crescută. cu toate consecinţele acestei situaţii.Dimensiunea. Securitatea se realizează prin nume de utilizatori plus parole. datorită eliminării redundanţei. la 750. pentru a o putea exploata. cerinţele posibil în conflict ale diferitelor compartimente referitoare la utilizarea BD sunt gestionate la nivel de DBA. De la 150 USD pt. limbajele de interogare şi generatoare de rapoarte asociate SGBD oferă utilizatorilor posibilitatea unor interogări ad-hoc. Integritatea crescută a datelor. cu disc şi memorie mai mari. pentru a sigura performanţele SGBD poate fi nevoie de achiziţionarea unui calculator mai mare.Complexitatea. Se poate limita tipul de operaţie efectuată. Concurenţa/simultaneitatea îmbunătăţită. Dacă SGBD este greşit înţeles.

ştergerea şi extragerea datelor din BD. Impactul crescut al unei defecţiuni. Mediul SGBD constă din elemente hardware (calculatorul). programatorii de aplicaţii şi utilizatorii finali. • Descrieţi principalele diferenţe între tratarea datelor prin baze de date faţă de tratarea bazată pe fişiere. vederi. proceduri şi persoane. coerenţa şi partajarea datelor. Fiecare program îşi defineşte şi îşi gestionează propriile date. Centralizarea (partajarea) resurselor creşte vulnerabilitatea SGBD. adică un sistem mai vechi. Acest sistem reprezintă un mare progres faţă de sistemele manuale de fişare şi îndosariere. proiectanţii de baze de date. dar are şi probleme semnificative cum ar fi redundanţa datelor şi dependenţa program – date. Predecesorul SGBD a fost sistemul bazat pe fişiere. bază de date. Apare termenul de sistem moştenit. şi un limbaj de manipulare a datelor (DML). astfel unele pot funcţiona mai puţin rapid decât în cazul sistemului bazat pe fişiere.9 Întrebări la capitolul 1. crearea şi întreţinerea bazei de date şi acre permite accesul controlat la aceasta. de care organizaţia se cramponează din motive de costuri de conversie. care permite utilizatorilor inserarea. Tratarea datelor prin baze de date rezolvă dificultăţile abordării pe bază de fişiere. îmbunătăţirea securităţii şi integrităţii datelor.8 Rezumatul capitolului 1. creat pentru o anume aplicaţie. SGBD (spre deosebire de cel bazat pe fişiere) este general. inferior. care permite utilizatorilor definirea. Un SGBD este un sistem de elemente software. Eşecul oricărei componente poate duce la sistarea tuturor operaţiilor. 1.1. Avantajele tratării datelor prin BD includ: controlul redundanţei datelor. Performanţa. reactualizarea. sistemul de operare şi programele de aplicaţie). SGBD oferă un limbaj de definire a datelor (DDL). Acesta reprezintă o serie de programe de aplicaţie ce efectuează servicii (de regulă generarea de rapoarte) pentru utilizatorii finali.1 • Daţi patru exemple de sisteme de baze de date (situaţii în care activitatea unei organizaţii ar avea beneficia de pe urma unei baze de date) • Analizaţi termenii: date.- - Costul conversiei. angajarea de personal specializat. • Analizaţi avantajele tratării datelor prin sisteme bazate pe fişiere. 13 .1 Sistemul de gestionare a bazelor de date (SGBD) reprezintă cadrul de bază pentru sistemele informaţionale şi a avut un impact fundamental asupra modului de operare al organizaţiilor. de software (sistemul SGBD. 1. care permite utilizatorilor definirea BD. creat pentru a permite diverse aplicaţii.1. • Descrieţi cele cinci componente ale mediului SGBD şi analizaţi relaţiile dintre acestea. BD este proiectată pentru a satisface necesităţile informaţionale ale unei organizaţii. Persoanele includ administratorii de date şi de baze de date. date. Dezavantajele includ: complexitate. la implementarea unui nou sistem SGBD şi/sau a unei noi configuraţii hard. O bază de date reprezintă un set partajat de date şi descrierea acestora între care există relaţii logice. preţ. impact scăzut al defecţiunilor. sistem de gestionare a bazelor de date. Se include costul instruirii personalului. conversia poate costa semnificativ mai mult decât noile elemente hard.

Grad: Gradul unei relaţii reprezintă numărul de atribute pe care îl conţine.2. Extensia (starea) unei relaţii: tuplurile.• Analizaţi rolurile următoarelor categorii de personal în mediul SGBD: administrator de date.1. Pentru fiecare atribut se defineşte în mod central denumirea domeniului. O BDR constă din relaţii structurate adecvat. Intensitatea este de regulă fixă/fixată. Intensitatea unei relaţii: structura tabelului. sensul acestuia şi domeniul de definiţie.2.1. administrator de baze de date.1 Terminologie 1. Cardinalitate: cardinalitatea unei relaţii este numărul de tupluri conţinute de aceasta. Atribut: Un atribut este o coloană a unei relaţii. 1.2. utilizatori finali. Domeniu: Un domeniu este mulţimea de valori permise pentru unul sau mai multe atribute. Exemplu: Atribut (cap de coloană) Localitatea Nr tel Denumirea domeniului Localitatea Numere telefon Sensul Mulţimea tuturor denumirilor de localităţi din România Mulţimea tuturor numerelor de telefon din România Domeniul de definiţie Caracter: dimensiune 20 Caracter: dimensiune 14 Tuplu: Un tuplu este un rând dintr-o relaţie. de casă. deşi ambele sunt şiruri de caractere. 1. Fiecare relaţie are o anumită denumire (titlu tabel) şi este formată din anumite atribute (coloane) ale datelor. Fiecare tuplu (line) conţine câte o valoare per atribut. (De ex. de exemplu. compararea unui număr de telefon cu nr. deşi primele sunt caractere text.2 Relaţii matematice 14 Alternativa 1 Tabel Rând Coloană Alternativa 2 Fişier Înregistrare (Record) Câmp (Field) . iar celelalte sunt valori monetare). care se modifică în timp.1 Structura relaţională a datelor Relaţie: o relaţie este un tabel cu coloane şi rânduri. proiectant de baze de date fizice. Baza de date relaţională: Un set de relaţii normalizate. se numeşte binară.2. proiectant de baze de date logice. luni este legal de înmulţit cu salariile. O relaţie cu două atribute. Ca urmare sistemul va evita operaţiile incorecte semantic. specificarea domeniilor şi a altor restricţii referitoare la valorile posibile. însă: nr. cu o anumită denumire. programator de aplicaţii. Termeni formali Relaţie Tuplu Atribut 1. Modelul relaţional (SGBDR) În cadrul modelului relaţional (ML) toate datele sunt structurate logic în cadrul unor relaţii (tabele).

R = {(2. . Fiecare element din acest n-tuplu este format dintr-un atribut şi valoarea lui.y)| x ∈ D1. .y)| x ∈ D1. A2:D2. adică: R = {(x. atributele (Ai) vor fi capetele de coloane. ordinea tuplurilor nu are nici o importanţă (în practică poate afecta eficienţa accesării tuplurilor).ordinea atributelor nu are nici o importanţă. nu există dubluri ale tuplurilor. (2. 3.teoretic.3 Relaţii în bazele de date Schema de relaţie: O denumire a relaţiei. (4. 1. iar tuplurile (ntuplurile) vor fi rândurile. . A2:d2. (2. Când relaţia R se scrie sub formă de tabel.1. Orice submulţime a acestui produs cartezian. y ∈ D2 şi y = 1} sau: S = {(x.fiecare relaţie are o denumire. …. o relaţie din modelul relaţional este o submulţime al produsului cartezian al domeniilor atributelor. D1 x D2 = {(2. . Relaţia R va fi definită de schema de relaţie S= {A1:D1.1. Tabelul este o reprezentare fizică a unei astfel de relaţii. i=1.n.3). Aceste proprietăţi rezultă din proprietăţile relaţiilor matematice: 15 n . Astfel. …. Un n-tuplu al relaţiei (o înregistrare din tabel) va avea deci forma: (A1:d1.toate valorile unui atribut aparţin aceluiaşi domeniu. Fie o relaţie R cu atributele Ai cu domeniile corespunzătoare Di.5). D2 = { 1. (4. i=1. D1 = {2. dn. fiecare atribut (Ai . i=1.1)}. este ilegală trecerea de mai multe valori într-o celulă. Fiecare înregistrare (tuplu) din acest tabel (relaţie) va fi descrisă prin n coloane (atribute). d2.fiecare tuplu este distinct. 4}. y ∈ D2 şi x = 2y}.5)} Orice submulţime a produsului cartezian este o relaţie: de ex. Produsul cartezian: D1 x D2. 1..n) luând o valoare (di . An:Dn}.1).. adică este format din n elemente.n) din domeniul corespunzător (Di .n). câte unul din fiecare mulţime de la 1 la n.fiecare celulă a relaţiei conţine exact o valoare atomică (singulară). . adică orice mulţime de n-tupluri reprezintă o relaţie a celor n mulţimi (care formează produsul cartezian). .1).fiecare atribut are o denumire distinctă.3).1). 5}.4 Proprietăţile relaţiilor . An:dn).1)} X Di În general scriem produsul cartezian a n mulţimi ca fiind: i =1 Fiecare element al produsului cartezian va fi un n-tuplu.Pentru a înţelege sensul termenului de relaţie revedem unele concepte matematice.2. Relaţia va fi deci o mulţime (un set) de astfel de n-tupluri. adică S ={(2.. i=1.2. . (4. urmată de un set (mulţime) de perechi formate din atribute şi denumiri de domenii. diferită de toate celelalte denumiri de relaţii. (4. Deci di ∈ Di. va fi deci un ntuplu. de forma d1.

telefon.2 Integritatea relaţională Un model de date relaţional cuprinde: . . caz în care se numeşte cheie combinată. Cheie străină: Un atribut sau o mulţime de atribute din cadrul unei relaţii. adresă facturare. valorile cheii identifică acel tuplu în mod unic) şi ireductibilă (nici o submulţime a cheii candidat nu este unică)..6 Reprezentarea schemelor (de relaţii) din BD relaţionale Schema unei relaţii dintr-o BD are forma: Denumire relaţie [titlu tabel] (Atribute. care defineşte tipurile de operaţii permise asupra datelor. Cheile candidat neselectate se numesc chei alternative.o parte de manipulare. ordinea elementelor nu are importanţă.- din moment ce relaţia este o mulţime. . Cheia candidat: este o supercheie minimă. cont trezorerie. deci nu există tupluri duble. O cheie candidat este unică (în fiecare tuplu al relaţiei R.un set de reguli de integritate care asigură corectitudinea datelor. firmă. crt.o parte structurală. Cheia primară: este cheia candidat care este selectată [din toate cheile candidat identificate] pentru a identifica în mod unic tuplurile din cadrul unei relaţii. care se potrivesc cu o cheie candidate din altă relaţie. începând cu cheia primară. O cheie poate include mai multe atribute. prin valorile atributelor sale. 1. pentru care nici o submulţime nu este supercheie în cadrul relaţiei respective. într-o mulţime nu se repetă nici un element.1.2.2. dată contact). nr. (Spunem că ţinteşte cheia primară din altă relaţie). Atributele comune joacă un rol important în manipularea datelor. judeţ. 16 . Fiecare atribut are un domeniu. localitate. Modelul conceptual (schema conceptuală) al unei BD este mulţimea tuturor schemelor de relaţie pentru BD respectivă. cod poştal. deci asupra valorilor permise pentru fiecare atribut există anumite constrângeri de domeniu. 1. De exemplu o cheie străină dintr-o relaţie poate (spunem că ţinteşte) coincide cu cheia primară din altă relaţie.1. subliniată) Clienţi (Nr. Supercheia: Este un atribut sau un set de atribute care identifică în mod unic un tuplu din interiorul unei relaţii. O supercheie poate conţine şi atribute care nu sunt necesare identificării unice a tuplului.5 Chei relaţionale Trebuie să existe posibilitatea de identificare unică a unui tuplu dintr-o relaţie.2. discutată în paragraful precedent. 1. deci ordinea tuplurilor nu are importanţă.

1. pentru a obţine o altă relaţie. O relaţie de bază (tabel de bază) corespunde unei entităţi în schema conceptuală a BD.2.1 Null-uri Null reprezintă valoarea unui atribut care este curent necunoscută sau nu este aplicabilă tuplului respectiv. 1.2.4 Constrângerile de întreprindere Constrângerile de întreprindere: sunt reguli adiţionale.2. ale cărei tupluri sunt stocate fizic în BD. valoarea acesteia trebuie ori să coincidă cu valoarea unei chei candidat a unui tuplu în relaţia sa de bază. Un Null nu este acelaşi lucru cu o valoare numerică = 0 sau cu un şir de text “spaţii” (zero string). un Null însemnând însă absenţa unei valori. 17 .integritatea referenţială 1. ori să fie în întregime Null.2 Integritatea entităţilor Se aplică cheilor primare ale relaţiilor de bază.3 Vederi Vederea externă este structura BD aşa cum apare ea unui anumit utilizator. corespunzătoare unei entităţi din schema conceptuală. 1.1 Terminologie Relaţie de bază: O relaţie cu o anumită denumire.2.2. Integritatea entităţilor: într-o relaţie de bază nici un atribut al unei chei primare nu poate fi Null.2.2. În modelul relaţional o vedere este o relaţie virtuală.integritatea entităţilor . care în realitate nu există în BD. acestea sunt valori.2. O vedere este o relaţie virtuală. Integritatea referenţială: Dacă într-o relaţie există o cheie străină. 1. ci este produsă în momentul respectiv. Valoare logică “necunoscut”.3 Integritatea referenţială Se aplică cheilor străine.2.3. Vedere: Rezultatul dinamic al uneia sau mai multor operaţii relaţionale care acţionează asupra relaţiilor de bază.2. la cererea unui utilizator. ci este derivată în mod dinamic din una sau mai multe relaţii de bază.Mai există două reguli de integritate importante care sunt constrângeri ce se aplică întregii baze de date. specificate de către utilizatorii sau administratorul bazei de date (DBA). o relaţie care nu este de fapt de sine stătătoare. 1. anume: .

18 . denumirile atributelor sunt diferite. O relaţie unară are un singure atribut. adică modificările în relaţiile de bază sunt reflectate imediat în vederi.Conţinutul unei vederi este definit ca o interogare asupra unei sau mai multor relaţii de bază. Reactualizarea vederilor Există restricţii referitor la modificările care pot fi efectuate prin intermediul vederilor. Integritatea referenţială stabileşte că valorile cheii străine trebuie să corespundă valorilor unei chei candidat a unui tuplu oarecare din relaţia de bază sau să aibă în întregime valoarea Null. Vederile sunt dinamice. Structura relaţiei.2. Nu toate vederile pot fi reactualizate. una ternară are trei. iar relaţia. Gradul unei relaţii reprezintă numărul de atribute. Condiţiile de care depinde reactualizarea datelor prin intermediul vederilor sunt: . ordinea atributelor nu are importanţă. Şi invers. valorile acestora provin din acelaşi domeniu. . în moduri diferite. în timp de cardinalitatea reprezintă numărul de tupluri.2. Vederea oferă securitate şi permite proiectantului să personalizeze modelul unui utilizator.3. împreună cu specificarea domeniilor şi altor constrângeri fac parte din intensitatea bazei de date.sunt permise reactualizările prin intermediul unor vederi definite prin utilizarea unei interogări simple a unei singure relaţii de bază.3. Integritatea entităţilor este o constrângere care stabileşte că. 1. O supercheie este un set de atribute care identifică în mod unic tuplurile dintr-o relaţie. în timp ce o cheie candidat este o supercheie minimă. de către diverşi utilizatori. O cheie primară este o cheie candidat selectată pentru a identifica tuplurile. nici ordinea tuplurilor.nu sunt permise reactualizările prin vederi care implică operaţia de acumulare sau de grupare. În modelul relaţional o vedere este o relaţie virtuală.3.2 Scopul vederilor Mecanismul de vedere este util pentru că: . . nu există tupluri duble. într-o relaţie de bază nici un atribut al unei chei primare nu poate avea valoarea Null.poate simplifica operaţiile complexe asupra relaţiilor de bază. iar coloanele corespunzând atributelor.furnizează un mecanism de securitate puternic. Vederile sunt create dinamic pentru utilizatori.nu sunt permise reactualizările prin vederi care implică relaţii de bază multiple. fie cheia candidat a acesteia. şi care interogare conţine fie cheia primară.2. 1.2 Relaţiile sunt reprezentate fizic sub formă de tabele.4 Rezumatul capitolului 1. . iar o relaţie nară are n atribute. . O cheie străină este un atribut sau set de atribute dintr-o relaţie care constituie o cheie candidat pentru altă relaţie. O relaţie trebuie să aibă întotdeauna o cheie primară. 1. una binară are două. Proprietăţile relaţiilor din bazele de date sunt: fiecare celulă conţine exact o valoare. aceleaşi date pot fi vizualizate simultan. Un Null reprezintă o valoare pentru un atribut care este necunoscut în momentul respectiv sau nu este definit pentru acel tuplu. împreună cu toate tuplurile sale reprezintă o extensie a bazei de date. cu rândurile corespunzând tuplurilor individuale.permite utilizatorilor accesarea datelor în mod personalizat. modificările permise operate asupra vederii se transmit relaţiilor de bază.

intensitate şi extensie. anume: tehnici de analiză şi proiectare structurată (Structured Analysis Design). 1.3. 19 . exprimate de cele mai multe ori neformal trebuie transformate într-o formulare structurată. Informaţiile şi cererile colectate.1 Ciclul de viaţă al sistemelor informaţionale Un sistem informaţional (SI) include resursele care permit colectarea.personalul care utilizează şi dezvoltă sistemul. ciclul de viaţă al aplicaţiei de tip BD cuprinde următoarele etape (fig.elementele software ale BD .5 Întrebări la capitolul 1. proiectarea şi administrarea BD 1. Definiţi cele două reguli de integritate principale din modelul relaţional. Ce se întâmplă când un utilizator accesează o bază de date prin intermediul unei vederi? 1.elementele hardware .2. administrarea. pentru aceasta se utilizează tehnici de specificare a cerinţelor.2 • • • • Analizaţi fiecare dintre următoarele concepte în contextul modelului de date relaţional: relaţie. domeniu. Ce este o cheie străină? Care este legătura dintre cheile străine şi cele candidat ale unei relaţii? Daţi exemple. În cadrul SI.1.software de aplicaţie . Analizaţi de ce sunt necesare aceste reguli.3 Planificarea. Cerinţă: o caracteristică ce trebuie inclusă în noul sistem. . gard şi cardinalitate. Ce este o vedere? Analizaţi diferenţa dintre o vedere şi o relaţie de bază.2): Planificarea BD: activităţile administrative care permit parcurgerea etapelor aplicaţiei de tip BD cât mai eficient posibil.baza de date (BD) . Colectarea şi analiza cerinţelor: colectarea şi analizarea de informaţii despre partea de organizaţie ce urmează să fie deservită de aplicaţia de tip BD şi utilizarea acestor informaţii pentru identificarea cerinţelor utilizatorilor. diagrame de flux de date (Data Flow Diagrams) şi diagrame de tip intrare-prelucrare-ieşire ierarhică (Hierarchic Input Process Output). tuplu. Definirea sistemului: specificarea scopului şi limitelor aplicaţiei de tip BD. SI al unei organizaţii cuprinde. a utilizatorilor săi şi a domeniilor de aplicaţie. controlul şi propagarea informaţiilor în întreaga organizaţie. Analizaţi diferenţele dintre cheile candidat şi cheia primară a unei relaţii. atribut.

client. apoi se identifică atributele: Clienţi (nr.). 20 - - . Această abordare este ilustrată de modelul ER . Proiectarea aplicaţiei: Proiectarea interfeţei cu utilizatorul şi a programelor de aplicaţie care utilizează.) şi Produse (nr. o Testarea de jos în sus. Implementarea: realizarea fizică a proiectelor pentru BD şi aplicaţii. produse. după dependenţele funcţionale ale acestora. o Testarea la suprasolicitare. cu un număr relativ mic de atribute. Se începe cu identificarea entităţilor şi relaţiilor care prezintă interes pentru organizaţie. Realizarea prototipului: Construirea unui model de lucru al unei aplicaţii de tip BD. factură intrare. de exemplu timpul de răspuns. structurat adecvat pentru realizarea cerinţelor stabilite referitor la performanţele sistemului. o Specificarea unui proiect minimal. se alege un sistem adecvat care să accepte o aplicaţie de tip BD. necesare tuturor aplicaţiilor şi utilizatorilor. Exemplu: entităţi: clienţi. care va aborda toate operaţiile şi obiectivele întreprinderii. o de sus în jos. se identifică relaţia dintre aceste entităţi: clientul cumpără produse. această abordare se mai numeşte şi normalizare şi este indicată la proiectarea unor BD mai simple. Conversia şi încărcarea datelor: transferul în noua BD a oricăror date deja existente şi conversia oricăror aplicaţii existente. respectiv prelucrează BD. relaţiile şi atributele asociate de nivel jos. se realizează printr-un DDL corespunzător SGBD ales.î. Visual Basic.). O parte din programele de aplicaţie sunt tranzacţiile bazei de date implementate cu un DML corespunzător SGBD. - Alegerea sistemului SGBD.- Proiectarea bazelor de date: procesul de realizare a unui proiect pentru o BD. În această etapă sunt realizate şi vederile specificate de utilizatori. a. urmând apoi rafinări succesive de sus în jos. urmată apoi de finalizarea atributelor. se stabilesc atributele la un nivel fundamental (adică proprietăţile entităţilor). Cele două abordări în proiectarea unui sistem de BD sunt: o de jos în sus. cu intenţia de a găsi erori. produs. o Testarea pe fir. care apoi sunt grupate în relaţii. Proiectarea BD şi a aplicaţiilor sunt activităţi paralele în ciclul de viaţă al aplicaţiei de tip BD. care poate fi incorporat într-un limbaj de programare gazdă (ex. pentru BD mai complexe. Delphi etc. şi la testare trebuie de implicat utilizatorii. o Furnizarea unui model de date care să accepte efectuarea oricărei tranzacţii necesare asupra datelor. adresă etc. Strategii de testare: o Testarea de sus în jos. Scopurile proiectării BD sunt: o Reprezentarea datelor şi a relaţiilor dintre ele. Testarea: procesul de executare a programelor de aplicaţie. stoc etc. pentru a identifica entităţile. se începe cu realizarea unor modele de date care conţin câteva entităţi şi relaţii de nivel înalt. ca şi la proiectare. să poată funcţiona în cadrul acesteia.

2 Ciclul de viaţă al aplicaţiilor tip bază de date 1. o Monitorizarea performanţelor sistemului. parcurgând etapele precedente. Fig. prin încorporarea de noi cerinţe. 1.2 Fazele proiectării BD 21 .- Întreţinerea operaţională: procesul de monitorizare şi întreţinere a sistemului. care se efectuează după instalarea acestuia.3. o Întreţinerea şi modernizarea.

1 Proiectarea tranzacţiilor Tranzacţie: O acţiune sau serie de acţiuni efectuate de către un singur utilizator sau program de aplicaţie. Tehnica de normalizare este utilizată pentru a testa corectitudinea unui model de date logic. . Un model logic cu multiple vederi ale utilizatorilor asupra organizaţiei se numeşte model de date logic global. modificările efectuate sunt stocate permanent în BD şi nu pot fi pierdute sau anulate (doar printr-o nouă tranzacţie). 1. pentru a asigura performanţele optime ale sistemului de BD. din informaţiile provenite din modelul de date logic global. Proiectarea logică a BD: procesul de construire a unui model al informaţiilor utilizate în cadrul unei organizaţii bazat pe un anumit model de date (de exemplu entitate-relaţie . În proiectarea unui model de date logic global există două moduri principale de abordare: . independent de toate consideraţiile fizice. Principalul scop al proiectării fizice pentru modelul relaţional presupune: . descrie structurile de stocare şi metodele de acces utilizate.deducerea unui set de tabele relaţional şi de constrângeri asupra acestora. Tratarea prin integrarea vederilor: Îmbină modelele de date logice separate.tratarea centralizată . .tratarea prin integrarea vederilor. O tranzacţie poate fi formată din mai multe operaţii şi este un eveniment din lumea reală. SGBD garantează coerenţa BD. după care se construieşte modelul de date logic global. într-un singur model de date logic global. Vederile distincte ale utilizatorilor se numesc modele de date logice locale. Proiectarea logică şi conceptuală a BD presupune considerarea/îmbinarea tuturor vederilor utilizatorilor. deci în urma unei tranzacţii o BD trece dintr-o stare coerentă într-altă stare coerentă. Normalizarea garantează că relaţiile derivate din modelul de date nu prezintă redundanţă a datelor.Proiectarea unei protecţii de securitate pentru sistem. Proiectarea fizică a BD: procesul de realizare a descrierii implementării bazei de date într-o capacitate de stocare. Sistemul de BD nu trebuie să fie prea mare sau complex. SGBD garantează coerenţa BD şi în cazul unei defecţiuni.3. Tratarea centralizată: Îmbină cerinţele separate ale utilizatorilor.ER).identificarea structurilor de stocare specifice şi a metodelor de acces la date. care poate fi cauza anomaliilor după implementare. Odată tranzacţia încheiată.3. 22 .3 Proiectarea aplicaţiilor 1. dar independent de alte consideraţii fizice legate de SGBD. care reprezintă vederi distincte ale utilizatorilor.Proiectarea conceptuală a BD: procesul de construire a unui model al informaţiilor utilizate în cadrul fiecărei organizaţii.3. care reprezintă vederi distincte ale acestora într-un set unic de cerinţe. al SGBD. care accesează şi pot modifica conţinutul bazei de date.

fiecare formular reprezentând un tuplu dintr-un tabel.mişcare convenabilă a cursorului . 1.grupare logică a câmpurilor . .instrucţiuni inteligibile . ci în formulare.terminologie şi prescurtări coerente .mesaje de eroare pentru valori inacceptabile .de reactualizare.utilizare coerentă a culorilor . Înainte de implementare se proiectează macheta unui formular sau raport.semnal de terminare 1.titlu semnificativ .3.4 Administrarea datelor şi a bazei de date Etapele ciclului de viaţă al aplicaţiilor de tip bază de date şi rolurile (principal sau secundar) ale personalului administrator de date (DA) şi administrator de bază de date (DBA) rezultă din tabelul de mai jos: Etapa Planificarea BD Definirea sistemului Colectarea şi analiza cerinţelor Proiectarea conceptuală a bazei de date Alegerea sistemului SGBD Proiectarea logică a bazei de date Proiectarea aplicaţiilor Proiectarea fizică a bazei de date Realizarea prototipului Implementarea Rol principal DA DA DA DA DBA DA DBA DBA DBA DBA 23 Rol secundar DBA DBA DBA DBA DA DBA DA DA DA DA .Tipuri de tranzacţii: .mixte (regăsire plus reactualizare).spaţii şi limite vizibile ale câmpurilor de introducere a datelor . deci se proiectează o tranzacţie care să facă posibilă această acţiune. însoţită de o interfaţă prietenoasă cu utilizatorul. Exemplu: utilizatorul va dori să înregistreze toţi noii clienţi în BD.2 Proiectarea interfeţei cu utilizatorul Utilizatorul va lucra de regulă nu direct în tabele.de regăsire.marcare clară a câmpurilor opţionale .etichete familiare ale câmpurilor .3. .aspect atrăgător al machetei . Indicaţii utile pentru proiectarea unui formular/raport .3.mesaje explicative pentru câmpuri .corectare de erori pentru caractere individuale sau câmpuri întregi . Tranzacţiile se proiectează plecând de la informaţiile din cerinţele utilizatorului.

implementarea. realizarea şi întreţinerea standardelor. alegerea SGBD (opţional). Administrarea bazei de date (DBA): Administrarea realizării fizice a unei aplicaţii de tip BD. Proiectarea aplicaţiei de tip BD presupune: proiectarea tranzacţiilor şi proiectarea interfeţei cu utilizatorul. care include planificarea BD. O tranzacţie a bazei de date este o operaţie care implică acces la baza de date şi reprezintă un eveniment din lumea reală. politicile şi procedurile Stabileşte cerinţele privind datele Realizează proiectarea conceptuală şi logică a bazei de date Dezvoltă şi întreţine modelul general de date Coordonează dezvoltarea sistemului Are o orientare managerială Este independent de SGBD 1.Conversia şi încărcarea datelor Testarea Întreţinerea operaţională DBA DBA DBA DA DA DA Administrarea datelor (DA): Gestionarea resurselor de date. colectarea şi analiza cerinţelor. Principalele etape ale ciclului de viaţă al aplicaţiei tip bază de date sunt: planificarea BD. conversia şi încărcarea datelor.3 Un sistem informaţional (SI) constă în resursele care permit colectarea. integritate.3. proiectarea BD. politicilor şi procedurilor şi proiectarea conceptuală şi logică a bazei de date. În proiectarea acestuia abordările pot fi: tratarea centralizată şi tratarea prin integrarea vederilor. gestionarea.5 Rezumatul capitolului 1. bazat pe un anumit model de date. 24 Administrarea bazei de date (DBA) Evaluează noile SGBD Execută planurile de atingere a scopurilor Întăreşte standardele. stabilirea controlului de securitate. politicile şi procedurile Implementează cerinţele privind datele Realizează proiectarea logică şi fizică a bazei de date Implementează proiectul fizic al bazei de date Monitorizează şi controlează baza de date Are o orientare tehnică Depinde de SGBD . dar independent de un anumit SGBD şi de alte consideraţii fizice. independent de toate consideraţiile fizice. testarea şi întreţinerea operaţională. inclusiv proiectarea şi implementarea fizică a BD. controlul şi difuzarea informaţiilor în cadrul întregii organizaţii. definirea sistemului. Proiectarea fizică a bazei de date este procesul de implementare într-o capacitate de stocare. se descriu structurile de stocare şi metodele de acces la date. monitorizarea performanţelor sistemului şi reorganizarea BD după necesităţi. Proiectarea logică a BD este procesul de construire a unui model al informaţiilor utilizate în întreprindere. Principalele diferenţe dintre sarcinile din DA şi DBA rezultă din tabelul de mai jos: Administrarea datelor (DA) Implicat în planificarea IT strategică Stabileşte scopurile pe termen lung Întăreşte standardele. Proiectarea conceptuală a BD este procesul de construire a unui model al informaţiilor utilizate în întreprindere. realizarea prototipului (opţional). proiectarea aplicaţiilor. Un model logic care reprezintă vederile mai multor utilizatori asupra unei organizaţii se numeşte model de date logic global.

1.atributele 1. entităţi cu existenţă fizică) Vânzare (concepte.tipurile de relaţii .perceperea datelor de către utilizator. Popescu sunt entităţi ale tipului de entitate “Clienţi” Entitate tare (entitate părinte. Administrarea datelor acţionează mai ales la începutul ciclului de viaţă al aplicaţiei tip BD.Administrarea datelor constă în gestionarea resurselor de date. relaţii. Produse. Exemplu: clienţi. 25 . Un model de date conceptual se compune din: .un set de concepte care descriu structura bazei de date (entităţi.tipurile de entităţi .4. Modelarea Entitate-Relaţie (ER) Modelul ER este un model conceptual de nivel înalt. controlul de securitate şi integritate. Administrarea bazei de date constă în gestionarea realizării fizice a BD.3. înainte de implementare. dominantă): Un tip de entitate a cărei existenţă nu depinde de alte tipuri de entităţi. 1. personal. dezvoltarea şi întreţinerea standardelor.1 Tipuri de entităţi Tip de entitate: Un obiect sau concept identificat de organizaţie ca având o existenţă independentă. • Descrieţi principalele scopuri ale fazelor de proiectare conceptuală şi logică a BD. dezvoltat de Chen (1976) pentru a facilita proiectarea BD. entităţi cu existenţă conceptuală) Entitate: o instanţă unic identificabilă a unui tip de entitate. Rudă_apropiată (obiecte. vânzare. Un model de date conceptual este independent de tipul de SGBD utilizat şi de platforma hardware asociată. politicilor şi procedurilor. • Definiţi diferenţele dintre scopurile şi sarcinile DA şi DBA. 1. inclusiv proiectarea fizică şi implementarea BD.6 Întrebări la capitolul 1. atribute) şi . Un tip de entitate conţine un set de obiecte sau concepte cu aceleaşi proprietăţi. Scopul realizării unui model de date de nivel înalt este: . Exemple de tipuri de entităţi: Clienţi. proiectarea conceptuală şi logică a acesteia. monitorizarea performanţelor şi reorganizarea BD după caz.3 • Descrieţi scopul fiecărei etape din ciclul de viaţă al aplicaţiilor de tip BD.4.4. .1 Conceptele modelului ER Conceptele de bază ale modelului ER includ: .ascunderea aspectelor tehnice asociate proiectării BD. inclusiv planificarea BD. 1.tranzacţiile de regăsire şi actualizare asociate. Administrarea BD intervine mai ales în etapele târzii ale ciclului de viaţă al aplicaţiei de tip BD. Personal. proprietar. Exemplu: Georgescu. produse.

Reprezentarea atributelor: elipse.1. Exemplu: atributul vârsta se derivă din data naşterii. entitatea slabă într-un dreptunghi cu chenar dublu (fig.4.4 se referă la modelul ER al unei agenţii imobiliare. Exemplu: Atribute în tipul de entitate Personal: sex. salariu Atribut compus: are mai multe componente. dependentă. Exemplu: Ruda_apropiată. Atributele compuse “radiază” atributele componente. fiecare independentă Exemplu: Adresa (Str. subordonată): Un tip de entitate a cărei existenţă depinde de existenţa uneia sau mai multor alte tipuri de entităţi. Zorilor 13): atributul strada + atributul numărul Atribut cu o singură valoare: Conţine o singură valoare pentru o anumită entitate. cu existenţă independentă. Reprezentare în modelul ER: entitatea tare se trece într-un dreptunghi cu chenar simplu.2 Atribute Atribut: o proprietate a unui tip de entitate sau relaţie. Denumirea atributelor cheie primară se subliniază. 26 . contur dublu pentru atribute cu valori multiple.Entitate slabă (entitate copil. Personal Ruda_apropiata Fig. Domeniul atributului: Mulţimea în care ia valori atributul. 1. Exemplu: un client poate avea mai multe numere de telefon. Atribut cu valori multiple: Conţine mai multe valori pentru o singură entitate. Figura 1. Atribut derivat: are o valoare derivabilă din valoarea unui atribut sau set de atribute de care este legat şi care nu sunt în mod necesar în aceeaşi entitate.3). contur punctat pentru atribute derivate.3 Entitate tare şi entitate slabă 1. Atribut simplu: are o singură componentă. 1.

4. 27 . “Filiala” şi “Ruda apropiată” şi a atributelor acestora.1.Fig. Reprezentarea schematică a tipurilor de entităţi “Personal”.

numită: relaţie. Între fiecare entitate din tipurile de entităţi de mai sus există o prezenţă unic identificabilă a tipului de relaţie dintre ele. Fig. Relaţiile se reprezintă prin romburi. Pentru simplificare în fig. 1. În figura 1. Model semantic în reţea. 1. 1. Pentru simplificare s-au reprezentat numai atributele chei primare.4. adică fiecare angajat este alocat unei filiale. Aceasta este o diagramă la nivel de obiecte.5. rombul are linii duble dacă face legătura dintre o entitate slabă şi una tare.5.5 sunt prezentate apariţiile individuale ale relaţiei „este alocat” . utilizând conceptele modelului ER se prezintă în figura 1. Reprezentarea de nivel înalt a relaţiei “este alocat”. cu apariţiile individuale ale relaţiei „Este Alocat” Reprezentarea schematică a relaţiilor Modele semantice sunt dificil de înţeles datorită detaliilor.1. de care depinde. sunt prezentate numai unele atribute.1. Exemplu: între fiecare entitate din tipul de entitate “Personal” şi fiecare entitate din tipul de entitate “Filială” există o instanţă a relaţiei “este alocat”. unde simbolul • reprezintă entităţile.3 Tipuri de relaţii Tip de relaţie : O asociere semnificativă între tipuri de entităţi. 28 .6 se observă că entitatea slabă Ruda_Apropiată nu are cheie primară. utilizând o diagramă numită reţea semantică.6. În exemplul din fig. Exemplu: Între tipul de entitate “Filiala” şi tipul de entitate “Personal” există tipul de relaţie “este alocat”. iar simbolul ◊ reprezintă relaţiile. Relaţie : o instanţă unic identificabilă a unui tip de relaţie.

1. Reprezentare schematică a entităţilor. 1. 1. Personal şi Ruda_Apropiată Gradul unei relaţii: numărul de entităţi participante într-o relaţie.7. Fig. relaţiilor şi atributelor cheie primară Filiala. Relaţie binară. cu 2 participanţi (2 entităţi participante). Relaţie ternară. relaţie numită “deţine” Fig.Fig.8. numită “Fixează” 29 .6.

11).10.9. numită “Reglementează” Relaţie recursivă: O relaţie în care aceeaşi entitate participă mai mult decât o dată în diferite roluri. Relaţie recursivă numită “supervizează”. Relaţie cvadruplă.4.Fig. 1.1. Nume de roluri pot fi utilizate şi când două entităţi sunt asociate prin mai mult decât o relaţie (fig.11 Entităţi asociate prin două relaţii distincte numite “Administrează” şi “Este alocat”. împreună cu numele de roluri corespunzătoare. Relaţiei i s-au atribuit nume de roluri pentru a indica scopul pe care-l are fiecare entitate participantă în cadrul relaţiei. 1. Fig. cu numele de roluri supervizat şi supervizor. 1. 1.4 Atributele relaţiilor 30 . 1. Fig.

Exemple: o proprietate de închiriat trebuie să aibă un proprietar. 1. Exemplu de relaţie numită “Vizitează“ cu atributele (Data_vizitare şi Comentarii).1 Constrângeri de cardinalitate Raport de cardinalitate al unei relaţii: Descrie numărul de relaţii posibile pentru fiecare entitate participantă.4.12. • 1: M unu la mai mulţi. Modelul semantic corespunzător este prezentat în figura 1. entitatea “Vizitare”).13.Se pot asocia atribute şi relaţiilor (exemplul din fig.4. Pentru relaţii binare raportul de cardinalitate poate fi: • 1:1 unu la unu. aşa cum sunt percepute în lumea reală. 1. anume Personal Administreaza Filiala. Există două mari tipuri de constrângeri structurale: de cardinalitate şi de participare. • M:N mai mulţi la mai mulţi. Relaţii unu la unu (1:1) Se consideră relaţia binară Administreaza. Prezenţa unor atribute asociate relaţiilor poate indica existenţa unei entităţi neidentificate (în exemplul dat. 31 . 1. filiala trebuie să aibă personal. Fig.12).2.2 Constrângeri structurale Entităţilor participante într-o relaţie li se impun anumite constrângeri. Regulile care stabilesc cardinalitatea sunt reguli de afaceri ale organizaţiei (în modelarea unei organizaţii trebuie reprezentate cât mai multe reguli de afaceri). 1.

14 este 1: 1. Liniile sunt etichetate cu raportul de cardinalitate.Fig. 1. iar un angajat poate administra doar o singură filială. 1.15. Pot exista angajaţi (de. 32 .1. ex.14 Diagrama ER a relaţiei 1:1 Personal Administreaza Filiala Relaţii unu la mai mulţi (1:M) Considerăm relaţia binară Personal Supravegheaza Proprietate_de_Inchiriat. În schimb nu pot exista filiale fără administrator. care în fig.14. Acesta este confirmată prin regula de afaceri pe care o reprezintă relaţia: o filială are un singur administrator. Ann Beech) care nu administrează nici o filială. Fig.13 Model tip reţea semantică al relaţiei 1:1 (Personal Administreaza Filiala) Relaţia este de cardinalitate 1:1 deoarece o singură entitate din Personal este asociată cu o singură entitate din Filiala. al cărei model tip reţea semantică este prezentat în figura 1. Diagrama ER a acestei relaţii este prezentată în figura 1.

p2 supraveghează pr1 şi pr2). din punctul de vedere al proprietăţii de închiriat.Fig. În schimb o proprietate poate fi supravegheată numai de un singur membru al personalului. 1. ceea ce corespunde regulilor de funcţionare ale organizaţiei.16.16. Diagrama ER a relaţiei 1:M 33 .15 Diagrama tip reţea semantică a relaţiei 1:M Din diagramă reiese gradul de cardinalitate al relaţiei ca fiind de 1: M. Pentru stabilirea gradului de cardinalitate al relaţiei se va lua în considerare gradul mai înalt. deoarece un membru al personalului poate supraveghea mai multe proprietăţi (de ex. Fig. Relaţia este deci de cardinalitate 1: M citită de la stânga la dreapta. 1. şi de cardinalitate 1:1 citită de la dreapta la stânga. Diagrama ER corespunzătoare acestei relaţii este reprezentată în figura 1. deci în cazul exemplului 1:M.

d.2.participare parţială sau opţională (reprezentată printr-o linie simplă). Altfel participarea este parţială.17. 34 . Diagrama ER corespunzătoare este prezentată în figura 1. Fig. Există două tipuri de constrângeri de participare (a unei entităţi într-o relaţie): .17.2 Constrângeri de participare Constrângerile de participare determină dacă existenţa unei entităţi depinde de legătura sa de altă entitate prin intermediul unei relaţii. Fig. şi unei proprietăţi i se poate face reclamă în mai multe ziare.Relaţii mai mulţi la mai mulţi (M:N) Considerăm relaţia Ziar Face Reclama Proprietate_de_Inchiriat cu reţeaua semantică din figura 1. într-un ziar se poate face reclamă mai multor proprietăţi.4.v.participare totală sau obligatorie (reprezentată printr-o linie dublă) . cât şi din cel al entităţii Proprietate_de_Inchiriat.p.18. Participarea unei entităţi într-o relaţie este totală. dacă existenţa unei entităţi necesită (este condiţionată de) existenţa altei entităţi prin intermediul unei anumite relaţii. 1. 1. al entităţii Ziar. Corespunzător regulilor de afaceri.18. Diagramă tip reţea semantică a relaţiei M:N Din diagramă reiese gradul de cardinalitate al relaţiei de M:N atât d. Diagrama ER a relaţiei M:N 1.

21 Capcană în evantai 35 . dar căile dintre anumite apariţii ale entităţilor sunt ambigue. ştiind că o secţie coordonează mai multe filiale. şi se va reprezenta cu linie simplă Fig. şi se va reprezenta cu linie dublă. Fig.20 Constrângeri de participare.3 Problemele modelului ER În proiectarea unui model de date conceptual pot apărea aşa-numite capcane de conectare. Capcanele în evantai apar când două sau mai multe relaţii 1:M provin din aceeaşi entitate (fig. Deci existenţa entităţii Filiala este condiţionată de existenţa entităţii Personal. 1. o filială poate avea minim 5 şi maxim nedefinit (N) angajaţi.Exemplu. evident. Conform regulilor de afaceri ale organizaţiei.4. numai dacă are alocat personal. datorită interpretării eronate a sensului unei relaţii. Constrângeri de participare O reprezentare alternativă a constrângerilor de participare rezultă din fig.3. Un angajat poate să nu fie alocat unei filiale (valoare minimă 0) sau să fie alocat unei filiale. În cazul exemplului. 1. 1. Fig. 1. şi numai uneia (valoare maximă 1).19.20.22). pot însă exista membri de personal care nu sunt alocaţi unei anumite filiale. În relaţia binară Filiala Este Alocat Personal (fig. 1.4. 1.21). Examinăm modelul la nivel de apariţii individuale prin intermediul reţelei semantice (fig. 1. Din model nu rezultă la ce filială este alocat un anumit membru al personalului dintr-o secţie. unde pe liniile de legătură sunt trecute valorile minimă şi maximă cu care pot participa entităţile în relaţie. Entitatea Personal va avea deci participare parţială (opţională) în relaţia Este Alocat. Ca urmare entitatea Filiala va participa total (obligatoriu) în relaţia Este Alocat. 1.1 Capcane în evantai Capcanele în evantai sunt acele capcane de conectare care într-un model ER reprezintă o relaţie dintre tipuri de entităţi.19) o filială poate exista. notaţie alternativă 1.

Fig. coordonată de secţia S1. 1.23. Reţeaua semantică a modelului ER din fig. Fig.Un angajat (membru al personalului) poate superviza mai multe proprietăţi. 1. 1. nu se ştie la care dintre aceste două filiale este alocat SG 37.3. Capcanele de întrerupere apar când în calea prin care sunt legate entităţile intervine o entitate cu participare parţială.25 se observă următoarele: Pe ramura din stânga: .î.23. acesta să reprezinte corect asocierile dintre entităţi (fig. 1.21 Capcana se rezolvă prin restructurarea modelului ER. a.filiale există numai dacă are personal. Din modelul din fig.Se poate observa capcana în evantai: Angajatul SG37 este alocat secţiei S1.22. fiecare membru al personalului este obligatoriu alocat unei filiale (participări totale – linii duble de legătură). şi ce personal este alocat fiecărei filiale. 1. 1. Se observă care secţie coordonează care filiale. o proprietate poate fi supravegheată de un membru al personalului (relaţie 1: M) 36 .24. 1.24.unei singure filiale îi sunt alocaţi mai mulţi angajaţi (relaţie 1:M) .4. Exemplu.23). dar nu există căi între anumite apariţii ale acestor entităţi. Fig. 1. Pe ramura din dreapta: .2 Capcane de întrerupere Capcanele de întrerupere sunt acele capcane de conectare în care un model sugerează existenţa unei relaţii între tipurile de entităţi. Model ER restructurat Reţeaua semantică a modelului restructurat (corect) este cea din fig. 1. Angajatul SG37 este alocat filialei B3. Reţeaua semantică a modelului ER din fig. dar secţia S1 coordonând filialele B3 şi B7.

-

Nu fiecare membru al personalului supraveghează obligatoriu proprietăţi şi nu toate proprietăţile sunt supravegheate obligatoriu de un membru al personalului (participări parţiale – linii simple de legătură). Din modelul din fig. 1.25 nu se poate deduce ce proprietăţi sunt disponibile la care filiale. Modelul ER sugerează existenţa unei relaţii între entităţile Filiala şi Proprietate_de_Inchiriat, dar, aşa cum rezultă din reţeaua semantică asociată (fig. 1.26) nu există căi între anumite apariţii ale entităţilor.

Fig. 1.25 Capcană de întrerupere

Lipsa căilor între anumite apariţii ale entităţilor Filiala şi Proprietate_de_Inchiriat se observă clar din reţeaua semantică din figura 1.26. Nu se poate deduce la ce filială este disponibilă proprietatea PA14. Fig. 1.26. Reţeaua semantică a modelului ER din fig. 1.25. Participarea parţială a entităţilor Personal şi Proprietate_de_Inchiriat în relaţia Supravegheaza are ca efect faptul că unele proprietăţi nu pot fi asociate cu o filială prin intermediul unui membru al personalului. Pentru rezolvarea acestei capcane de întrerupere trebuie identificată relaţia care lipseşte. Aceasta este relaţia Are dintre entităţile Filiala şi Proprietate_de_Inchiriat. Se restructurează modelul ER, introducând relaţia nou identificată Are între entităţile între care lipseau căile (fig. 1.27). Fig. 1.27. Model ER restructurat pentru eliminarea capcanei de întrerupere.

37

Acum la nivelul apariţiilor individuale, adică din reţeaua semantică, se poate stabili că proprietatea PA14 este disponibilă la filiala B7 (fig. 1.28).

Fig. 1.28. Reţeaua semantică a modelului ER restructurat din fig. 1.27. 1.4.4 Rezumatul capitolului 1.4 Un tip de entitate este un obiect sau un concept care este identificat de organizaţie ca având o existenţă independentă. O entitate este o instanţă unic identificabilă a unui tip de entitate. Un tip de entitate slabă este o entitate a cărei existenţă depinde de existenţa altor entităţi. O entitate tare este o entitate a cărei existenţă nu este dependentă de existenţa altor entităţi. Un atribut este o proprietate a uni tip de entitate sau relaţie. Domeniul atributului reprezintă mulţimea de valori care pot fi atribuite acestuia. Un atribut simplu este compus dintr-o singură componentă, cu existenţă independentă. Un atribut compus este format din mai multe componente, fiecare cu existenţă independentă. Un atribut cu o singură valoare conţine o singură valoare pentru o singură entitate. Un atribut cu valori multiple deţine mai multe valori pentru o singură entitate. Un atribut derivat are o valoare derivabilă dn valoarea altui atribut sau mulţimi de atribute, care nu sunt neapărat ale aceleiaşi entităţi. O cheie candidat este un atribut sau set de atribute care identifică în mod unic apariţiile individuale ale unui tip de entitate. O cheie primară este o cheie candidate aleasă pentru o entitate. O cheie compusă este o cheie candidat care constă din două sau mai multe atribute. Un tip de relaţie este un set de asociaţii, toate cu un acelaşi sens, între tipuri de entităţi. O relaţie este o asociere între entităţi, această relaţie cuprinzând o entitate din fiecare tip de entitate ce participă în relaţie. Gradul unui tip de relaţie este numărul de entităţi participante în aceasta. O relaţie recursivă conţine o aceeaşi entitate care participă de mai multe ori în relaţie, cu roluri diferite. Numele de roluri sunt utilizate pentru determinarea funcţiilor fiecărei entităţi participante într-o relaţie. Raportul de cardinalitate descrie numărul de relaţii posibile pentru fiecare entitate participantă. Constrângerile de participare determină dacă existenţa unei entităţi depinde de legătura sa cu o altă entitate, prin intermediul unei relaţii. O capcană în evantai există acolo unde un model reprezintă o relaţie între tipuri de entităţi, dar calea dintre anumite apariţii ale acestora este ambiguă. O capcană de întrerupere există acolo unde modelul sugerează existenţa unei relaţii între tipuri de entităţi, dar nu există o cale între anumite apariţii ale entităţilor.

38

1.4.5 Întrebări la capitolul 1.4 • Descrieţi conceptele de bază ale modelului ER, şi reprezentarea schematică a acestora. • Descrieţi constrângerile ce pot fi impuse entităţilor participante într-o relaţie. • Descrieţi problemele ce pot apărea în crearea unui model ER.

1.5 Normalizarea
Atunci când proiectăm o BD pentru un SGBD relaţional, principalul obiectiv la crearea unui model de date logic este reprezentarea corectă a datelor, relaţiilor şi constrângerilor. Pentru acesta trebuie de identificat un set de relaţii adecvat, ceea ce se realizează cu ajutorul tehnicii de normalizare. Normalizarea este tratarea de jos în sus a proiectării BD, care începe cu examinarea relaţiilor dintre atribute. 1.5.1 Scopul normalizării Normalizarea este o tehnică de realizare a unui set de relaţii (a unei mulţimi de tabele) cu proprietăţi (atribute) dezirabile, având în vedere cerinţele organizaţiei. Normalizarea este frecvent efectuată ca o serie e teste asupra unei relaţii, pentru a stabili dacă aceasta satisface sau violează cerinţele unei anumite forme normale. Se deosebesc: prima formă normală (1NF), a doua formă normală (2NF), a treia formă normală (3NF), forma normală Bryce-Codd (BCNF), a 4-a şi a 5-a formă normală (4NF, 5NF). Toate formele normale se bazează pe dependenţele funcţionale dintre atributele unei relaţii. Prin aplicarea testelor de normalizare, adică prin normalizarea schemei relaţionale (vezi pct. 1.2.1.3) se previne apariţia anomaliilor de reactualizare. 1.5.2 Redundanţa datelor şi anomaliile de reactualizare Atributele trebuie grupate în relaţii (tabele) astfel încât să se minimizeze redundanţa datelor şi să se reducă spaţiul de stocare necesar relaţiilor de bază implementate. Pentru stocarea în BD a informaţiilor referitoare la angajaţi şi filiale comparăm două posibilităţi: a) Crearea a două tabele, unul cu angajaţi (relaţia Personal) şi unul cu filialele (relaţia Filiala):
Personal Filiala (Nr_Personal, NumeP, AdresaP, Functie, Salariu, Nr_Filiala) (Nr_Filiala, AdresaF, Nr_Tel)

b) stocarea tuturor informaţiilor într-un tabel unic (Personal_Filiala):
Personal_Filiala (Nr_Personal, NumeP, AdresaP, Functie, Salariu, Nr_Filiala, AdresaF, Nr_Tel).

În relaţia Personal_Filiala valorile atributelor referitoare la filială se repetă pentru fiecare membru al personalului alocat unei anumite filiale. Apar astfel date redundante, care pot crea probleme numite anomalii de reactualizare, care sunt împărţite în: - anomalii de inserare - anomalii de ştergere
39

-

anomalii de modificare.

Anomaliile de inserare Există două tipuri de anomalii de inserare. Pentru a le ilustra considerăm relaţia Personal_Filiala (cu date redundante). - La inserarea unui nou membru al personalului, trebuie inserate corect şi toate datele referitoare la filiala la care este alocat, date aflate deja în alte rânduri din acelaşi tabel. - La inserarea de date referitoare la o filială care nu are alocat încă nici un membru de personal, trebuie de trecut Null-uri în celulele pentru atributele personalului. Dar Nr_Personal fiind cheie primară, încercarea de a introduce valoarea Null ar viola integritatea entităţilor şi nu va fi permisă. Ca urmare nu poate fi inserată o filială nouă fără personal alocat. Aceste probleme se evită proiectând şi utilizând două relaţii distincte, anume: Personal şi Filiala. Anomaliile de ştergere Dacă în relaţia Personal_Filiala o anumită filială apare o singură dată (filiala are un singur membru de personal), atunci ştergerea acestui membru de personal va duce la ştergerea şi a informaţiilor referitoare la filiala respectivă. Anomalii de modificare Dacă reactualizăm de exemplu un număr de telefon al unei filiale din tabelul Personal_Filiala, atunci acest număr va trebui de reactualizat în acest tabel în toate rândurile în care apare filiala respectivă (rânduri corespunzătoare diferiţilor membri ai personalului alocaţi filialei respective). Proprietăţile de uniune fără pierderi şi conservare a dependenţei Relaţia Personal_Filiala este expusă anomaliilor de reactualizare şi trebuie descompusă în două relaţii (tabele) distincte: Personal şi Filiala. Descompunerea are două proprietăţi importante: - Uniune fără pierderi: permite regăsirea oricărei instanţe din relaţia iniţială în instanţele corespunzătoare ale relaţiilor mai mici. - Conservarea dependenţei: permite impunerea unei constrângeri asupra relaţiei iniţiale, prin impunerea unei constrângeri asupra fiecăreia dintre relaţiile mai mici. Adică nu este necesară efectuarea uniunii relaţiilor mai mici pentru a verifica dacă este violată o constrângere asupra relaţiei iniţiale. 1.5.3 Dependenţe funcţionale Conceptul de dependenţă funcţională este elementul central în procesul de normalizare. Dependenţă funcţională: descrie legăturile dintre atributele unei relaţii. De exemplu, dacă A şi B sunt atribute ale relaţiei R, atributul B este dependent funcţional de A (se notează A → B) dacă fiecărei valori a atributului A îi este asociată exact o valoare atributului B (A şi B pot fi formate din mai multe atribute fiecare). Atunci când există o dependenţă funcţională, ea este specificată ca o constrângere între atribute.
40

B va avea valoarea Braşov. în fiecare rând din tabel unde A are valoarea Codlea. Nr_Tel → AdresaF. Nr_Personal → AdresaP. Ca urmare cheia primară va fi acel atribut (sau set de atribute) care determină funcţional toate celelalte atribute ale relaţiei. Tehnica presupune o serie de reguli care pot fi utilizate pentru 41 . Nr_Personal → Functie. Diagramă de dependenţă funcţională În relaţia Personal_Filiala există 13 dependenţe funcţionale cu următorii determinanţi. 1. În relaţia Personal_Filiala această cerinţă o îndeplineşte numai atributul Nr_Pers. AdresaF → Nr_Filiala. Toate atributele care nu fac parte din cheia primară trebuie să fie dependente funcţional de aceasta. Cu alte cuvinte cheia primară va fi acel atribut (sau set de atribute) de care sunt dependente funcţional toate celelalte atribute ale relaţiei. Determinantul unei dependenţe funcţionale se referă la atributul din partea stângă a săgeţii. Nr_Personal → AdresaF. Aici A este determinantul lui B. Nr_Personal → Nr_Filiala.29). 1. Nr_Tel → Nr_Filiala. 1. AdresaF → Nr_Tel. adică acele atribute care identifică în mod unic fiecare rând din relaţie. B = atributul „judeţ”. Dependenţa dintre atributele A şi B poate fi reprezentată şi sub formă de diagramă (fig.5. Deoarece A → B (adică B este dependent funcţional de A). Nr_Filiala → Nr_Tel.29. Nr_Personal → Nr_Tel. înscrişi în stânga săgeţii: Nr_Personal → NumeP. Nr_Personal → Salariu. Fig.4 Procesul de normalizare Normalizarea este o tehnică formală de analizare a relaţiilor (tabelelor) bazată pe cheile primare ale acestora şi pe dependenţele funcţionale. Nr_Filiala → AdresaF.A → B: pentru o valoare dată a lui A (în toate rândurile din tabel unde apare această valoare) se va găsi o singură valoare a lui B Exemplu: A = atributul „localitate”. Identificarea cheii primare a unei relaţii cu ajutorul dependenţei funcţionale Pentru a identifica cheia primară a relaţiei (tabelului) Personal_Filiala se identifică întâi toate cheile candidat.

30) pentru introducere în baza de date a agenţiei imobiliare de „Detalii client-închiriere”. Normalizarea se execută ca o serie de paşi corespunzători unei anumite forme normale.a. Prima tratare: se elimină grupurile repetitive prin introducerea datelor adecvate în coloanele goale ale rândurilor care conţin date repetitive. Aceste date se transferă şi se stochează într-un tabel de formă nenormalizată. relaţia care o violează trebuie descompusă în relaţii care satisfac individual cerinţele normalizării. Procesul de normalizare este ilustrat în figura de mai jos. unde se demonstrează legătura dintre diversele forme normale. Pentru simplificare se presupune că un client închiriază o anumită proprietate o singură dată şi nu poate închiria mai mult de o proprietate în acelaşi timp. Un grup repetitiv este un atribut sau grup de atribute dintr-un tabel care are valori multiple pentru o singură apariţie a atributului (atributelor) cheie primară al acelui tabel. Schema legăturilor dintre formele normale 1. Unele relaţii în 1NF sunt şi în 2NF. dar pentru a evita anomaliile de reactualizare se recomandă efectuarea normalizării până la cel puţin forma normală 3NF. Există două tratări uzuale pentru eliminarea grupurilor repetitive din tabele. Se presupune că datele sunt introduse prin intermediul unui formular. rezultând normalizarea bazei de date. Toate formele normale următoare sunt opţionale. Atunci când o cerinţă nu este îndeplinită. Prima formă normală (1NF) este o relaţie în care intersecţia fiecărui rând cu fiecare coloană conţine o singură valoare şi numai una.d. Se identifică şi se elimină grupurile repetitive pentru a aduce tabelul în prima formă normală (1NF). Exemplu: Se consideră un formular (fig.m.testarea relaţiilor individuale. 42 .5 Prima formă normală Forma nenormalizată (UNF) este un tabel care conţine unul sau mai multe grupuri repetitive. Pentru modelul relaţional numai prima formă normală (1NF) este de importanţă critică în crearea de relaţii adecvate. 1.5. unele relaţii în 2 NF sunt şi în 3NF ş.

31.30. 1. Formularul „Detalii client-închiriere” al agenţiei imobiliare Pentru cei doi clienţi datele transformate într-un tabel nenormalizat se prezintă ca în fig. 43 . 1. Tabelul (relaţia) va fi acum în 1NF (fig. Fig. De exemplu pentru clientul John Kay există două proprietăţi: PG4 şi PG 16. a.Fig. să existe o singură valoarea în fiacre celulă.32).31 Tabelul nenormalizat (UNF) Client_Inchiriere Ca urmare există valori multiple la intersecţia dintre anumite rânduri şi coloane. 1.î. Pentru a transforma tabelul în prima formă normală se elimină grupul repetitiv. Conform primei tratări grupul repetitiv se elimină prin introducerea datelor adecvate în fiecare rând. 1.

A doua tratare: se elimină grupul repetitiv prin plasarea într-o relaţie separată a datelor repetitive.33. Relaţia Client_Inchiriere în prima formă normală (1NF) În continuare se identifică cheile candidat. Chirie. împreună cu o copie atributului cheie iniţial (Nr_Client). aşa cum arată figura 1. Nr_Proprietar. Apoi se identifică o cheie primară pentru noua relaţie. (Nr_Client.Fig. 1. Nr_Proprietate. Acum relaţia Client_Inchiriere în 1NF este definită astfel: Client_Inchiriere (Nr_Client.32. adică la intersecţia unui rând cu o coloană există o singură valoare.î. 1. dar are în acelaşi timp date redundante. să fie primele două coloane. în fig.32 ele au fost mutate a. NumeP) Relaţia este în 1NF. ceea ce nu este însă obiectul prezentului curs. NumeC) 44 . Fig.33 Relaţiile Client şi Prop_Inchir_Proprietar în 1NF Formele celor 2 relaţii în 1NF rezultante sunt: Client (Nr_Client. NumeC. InceputInchir) şi (Nr_Proprietate. care pentru acest tabel vor fi chei compuse: (Nr_Client. AdresaP. Va trebui trecută în 2NF. Se selectează drept chei primară al acestei relaţii setul de atribute: (Nr_Client. InceputInchir. SfarsitInchir. 1. InceputInchir). Nr_Proprietate). Nr_Proprietate).

se pierde coerenţa bazei de date. Pentru a evita anomaliile de reactualizare tabelul trebuie de adus în 2NF. Atributul determinat. (Adică. AdresaP. dacă se elimină atributul Nr_Client din cheia primară. 1. dependenţa nu mai are loc.33. A → B. NumeP) Cum rezultă din fig. Se observă că atributul „Chirie” depinde funcţional numai de atributul „Nr_Proprietate” şi nu de întreaga cheie primară compusă. Al doilea tabel din fig. Dacă de exemplu trebuie de modifica valoarea chiriei pentru proprietatea PG4 şi reactualizarea nu se face în fiecare rând în care apare PG4. deoarece la intersecţia dintre fiecare rând şi fiecare coloană există o singură valoare. 1. dacă B este dependent funcţional de A. O dependenţă funcţională A → B este parţială. ambele relaţii sunt în 1NF. deci dependenţa iniţială A → B este una parţială.33 se află în 1NF şi are cheia primară compusă din 2 atribute: Nr_Client. Şi după eliminarea atributului NumeP din componenţa lui A. dependenţa funcţională se păstrează: NumeP → Nr_Filiala. care dacă este eliminat din A. O dependenţă funcţională A → B este totală. Dacă A şi B sunt atributele unei relaţii. A doua relaţie prezintă o oarecare redundanţă a datelor şi poate suferi anomalii de reactualizare. Chirie. 1. Exemplu de dependenţa funcţională parţială: Determinantul A se compune din 2 atribute: Nr_Personal. 2NF (definiţie): O relaţie (tabel) în 1NF în care fiecare atribut care nu este cheie primară este total dependent funcţional de cheia primară (compusă) se află în 2 NF. Nr_Proprietate. A doua formă normală. dar nu de orice submulţime adecvată a lui A. InceputInchir. Nr_Proprietar. NumeP. A doua formă normală (2NF) se aplică relaţiilor cu chei compuse (din mai multe atribute). dacă există un atribut din componenţa lui A. Nr_Proprietate. Tabelul este expus anomaliilor de reactualizare. dependenţa funcţională se păstrează. deci: Nr_Personal.6 A doua formă normală (2NF) A doua formă normală se bazează pe conceptul de dependenţă funcţională totală. SfarsitInchir.Prop_Inchir_Proprietar (Nr_Client. dacă prin eliminarea oricărui atribut din componenţa lui A.5. NumeP → Nr_Filiala. dependent funcţional de A este B: Nr_Filiala. atunci B este total dependent funcţional de A. Se impune trecerea în 2NF. 45 . dependenţa funcţională Nr_Proprietate → Chirie se păstrează).

Observaţie: Dependenţa tranzitivă nu violează 2NF. InceputInchir → Nr_Client. compusă. InceputInchir → Nr_Proprietate. Dependenţe totale SfarsitInchir. AdresaP. Nr_Proprietar. SfarsitInchir). NumeP) În acest tabel există următoarele dependenţe funcţionale: fd1 fd2 fd3 fd4 fd5 fd6 Nr_Client. deoarece s-au depistat dependenţe parţiale ale unor atribute de (unul din atributele din) cheia primară.Trecerea din 1 NF în 2NF se face prin eliminarea dependenţelor parţiale. InceputInchir Tabelul Client_Inchiriere nu se află în 2NF. NumeP Dependenţă parţială de (unul din atributele din) cheia primară Nr_Proprietar → NumeP Dependenţă tranzitivă Nr_Client. Nr_Proprietar. NumeP de cheia candidat Nr_Client. împreună cu determinantul lor.32). AdresaP. şi acele atribute care au dependenţă funcţională totală de cheia primară (fd1). Nr_Proprietate Nr_Client → NumeC Dependenţă parţială de (unul din atributele din) cheia primară Nr_Proprietate → AdresaP. Astfel de dependenţe sunt eliminate la trecerea în 3NF. împreună cu atributul lor determinant fd2.atributele dependente parţial se mută într-un nou tabel. Inchiriere (Nr_Client. Dependenţe totale SfarsitInchir de cheia candidat Nr_Proprietate. fd3): Client (Nr_Client. NumeC. NumeC) Proprietar_Proprietate (Nr_Proprietate.îşi păstrează cheia primară iniţială. Nr_Proprietar. InceputInchir. Nr_Proprietate → InceputInchir. deşi poate cauza anomalii de reactualizare . Chirie.tabelul iniţial – sub alt nume . NumeP) . SfarsitInchir Dependenţe totale de cheia primară Nr_Client. Nr_Proprietate. NumeC. Se consideră tabelul Client_Inchiriere (fig. Atributele identificate ca fiind parţial dependente de cheia primară se plasează într-o nouă relaţie (tabel). Nr_Proprietar. 46 . Chirie. Nr_Proprietate. SfarsitInchir. Chirie. InceputInchir. având o cu cheie primară compusă. AdresaP. InceputInchir Nr_Proprietate. Pentru a aduce tabelul în 2NF: . Client_Inchiriere (Nr_Client. 1. Chirie.

NumeC) Nr_Client → NumeC 47 . NumeP. Reactualizarea numelui unui proprietar (de ex. Ca urmare existenţa dependenţei tranzitive poate cauza anomalii de reactualizare. Tony Shaw) trebuie făcută în fiecare rând în care acesta apare. A treia formă normală. Aducerea unei relaţii (unui tabel) în 3 NF se referă la eliminarea dependenţelor tranzitive. Nr_Filiala. 3NF (definiţie): O relaţie (un tabel) în 1NF şi 2NF în care nici un atribut care nu este cheie primară nu este dependent tranzitiv de cheia primară se află în 3NF Ca exemplu consideră dependenţele funcţionale din relaţiile (tabelele) de mai sus: Client (Nr_Client. Dependenţă tranzitivă (definiţie): Dacă A.5. AdresaF. AdresaP. Salariu. Nr_Tel). B şi C sunt atributele unei relaţii (unui tabel) şi A → B şi B → C.Relaţiile (tabelele) în 2NF derivate din relaţia (tabelul) Client_Inchiriere 1. Această dependenţă este adevărată pentru că atributul Nr_Personal nu este dependent funcţional de atributul Nr_Filiala sau de atributul AdresaF.7 A treia formă normală (3NF) În tabelul Proprietate-Proprietar s-a identificat dependenţa tranzitivă Nr_Proprietar → NumeP. Se consideră de exemplu relaţia Personal_Filiala Personal_Filiala (Nr_Personal. Functie. Există (printre altele) următoarele dependenţe funcţionale: Nr_Personal → Nr_Filiala şi Nr_Filiala → AdresaF Deci dependenţa Nr_Personal → AdresaF are loc prin intermediul atributului Nr_Filiala. În caz contrar BD va deveni incoerentă. atunci C este dependent tranzitiv de A prin intermediul lui B (cu condiţia ca A să nu fie dependent funcţional de B sau C).

deoarece nu conţin dependenţe tranzitive ale unor atribute de cheia primară. AdresaP.32) aflată în 1NF: Client_Inchiriere (Nr_Client. NumeC) Inchiriere (Nr_Client. Nr_Proprietar. AdresaP. NumeP) a fost supusă procesului de normalizare şi descompusă în 4 relaţii (tabele) 3NF: Client (Nr_Client. sau mai exact: Nr_Proprietate → Nr_Proprietar → NumeP. Chirie. Nr_Proprietar. SfarsitInchir Nr_Client. împreună cu determinantul său: Proprietar (Nr_Proprietar. Nr_Proprietate. SfarsitInchir) Proprietate_de_Inchiriat (Nr_Proprietate. SfarsitInchir. Chirie. AdresaP.tabelul iniţial – sub alt nume . NumeC. Nr_Proprietar. InceputInchir.Inchiriere (Nr_Client.atributul determinat. Relaţia „Client_Inchiriere” (fig. SfarsitInchir) Nr_Client. InceputInchir → Nr_Proprietate. NumeP) .îşi păstrează cheia primară iniţială. Nr_Proprietate → InceputInchir. şi acele atribute care au nu au dependenţă funcţională tranzitivă de cheia primară: Proprietate_de_Inchiriat (Nr_Proprietate. Nr_Proprietar) Relaţiile (tabelele) 3NF derivate din relaţia (tabelul) Proprietate_Proprietar Cele 2 noi tabele se află în 3NF. Chirie. InceputInchir → Nr_Client. Celelalte 2 relaţii (tabelele „Inchiriere” şi „Client”) nu conţin dependenţe tranzitive şi se află în 2NF. Chirie. Nr_Proprietate. Nr_Proprietar) Proprietar (Nr_Proprietar. SfarsitInchir Nr_Proprietate. InceputInchir. NumeP) Procesul de normalizare este ilustrat în figura de mai jos: 48 . deci sunt considerate automat ca fiind în 3NF. Tabelul „Proprietar_Proprietate” se aduce în 3NF prin eliminarea dependenţei tranzitive: . 1. Chirie. dependent funcţional tranzitiv se mută în altă relaţie (tabel). AdresaP. NumeP Nr_Proprietar → NumeP Singura dependenţă tranzitivă identificată se află în relaţia (tabelul) Proprietar_Proprietate: Nr_Proprietar → NumeP. SfarsitInchir Proprietar_Proprietate (Nr_Proprietate. InceputInchir. Nr_Proprietate. NumeP) Nr_Proprietate → AdresaP.

bazându-se pe cheile şi dependenţele funcţionale dintre atributele acestora.5. atributul B este dependent funcţional de A (A → B) dacă fiecărei valori a atributului A îi este asociată exact o valoare atributului B (A şi B pot fi formate din mai multe atribute fiecare). care descrie legăturile dintre atributele unei relaţii. De exemplu atributul Nr_Proprietar este cheie primară în relaţia (tabelul) „Proprietar” şi cheie străină în relaţia (Tabelul) „Proprietate_de-închiriat”. Relaţiile (tabelele) sunt prezentate în figura de mai jos: Relaţiile (tabelele) 3NF derivate din relaţia (tabelul) Client-Inchiriere 1. 49 . Normalizarea este legată de conceptul de dependenţă funcţională. Aceasta se realizează prin mecanismul cheie primară – cheie străină. care se clasifică în anomalii de inserare. Normalizarea este o metodă formală.5 Normalizarea este o tehnică de realizare a unui set de relaţii cu proprietăţi adecvate. ştergere şi modificare. Relaţiile cu redundanţă de date pot suferi din cauza anomaliilor de reactualizare. Dacă A şi B sunt atribute ale relaţiei R. avându-se în vedere cerinţele unei întreprinderi privind datele.Descompunerea relaţiei (tabelului) 1NF: Client_Inchiriere în relaţii (tabele) 3NF Relaţia iniţială Client_Inchiriere poate fi recreată prin uniunea relaţiilor (tabelelor) 3 NF rezultate în urma normalizării.8 Rezumatul capitolului 1. ce poate fi utilizată pentru identificarea relaţiilor.

vânzările. În fiecare etapă a normalizării se elimină caracteristici indezirabile din relaţie. în care nici un atribut care nu este cheie primară nu este dependent tranzitiv de cheia primară. 5.9 Întrebări la capitolul 1. 50 . Descrieţi problemele ce decurg din redundanţa datelor. Descrieţi conceptul de dependenţă funcţională. şi 7: proiectarea fizică. 1. a doua şi a treia formă normală.1 Pasul 1.5. independent de consideraţiile de ordin fizic (SGBDul utilizat). B este total dependent funcţional de A dacă B este dependent funcţional de A. Dependenţa funcţională totală arată că dacă A şi B sunt atribute ale unei relaţii (tabel). utilizatorul este o persoană reală individuală sau un grup de persoane.). contabilitatea. Forma nenormalizată (UNF) este un tabel cu unul sau mai multe grupuri repetitive. A doua formă normală (2NF) este o relaţie (tabel) care se află în 1NF şi în care fiecare atribut care nu este cheie primară este total dependent de cheia primară. care o fac sensibilă la anomalii de reactualizare. B şi C ale unei relaţii (tabel) există dependenţele funcţionale: A → B şi B → C. identificarea vederilor utilizatorilor se realizează prin examinarea diagramelor de flux şi prin chestionarea utilizatorilor. marketingul. 1. Construirea modelului de date conceptual local pentru fiecare vedere a utilizatorilor De regulă vederea unui utilizator este o zonă funcţională a întreprinderii (de exemplu producţia. dar nu şi de orice submulţime adecvată a lui A. adică C este dependent tranzitiv de A prin intermediul lui B (cu condiţia ca A să nu fie dependent funcţional de B sau C).6. Dependenţa tranzitivă este situaţia în care între trei atribute A. Cum este legat conceptul de dependenţă funcţională de procesul de normalizare? Definiţi prima. Determinantul unei dependenţe funcţionale se referă la atributul (grupul de atribute) din partea stângă a săgeţii. Procesul de normalizare face ca relaţia să treacă prin diverse forme normale. 6.Un determinant este orice atribut de care un alt atribut este total dependent funcţional.6 Metodologia de proiectare conceptuală a bazelor de date Proiectarea unei baze de date cuprinde următorii paşi: Pasul 1: proiectarea conceptuală Paşii 2 şi 3: proiectarea logică Paşii 4. aprovizionarea etc. resursele umane. Proiectarea conceptuală a bazei de date este procesul de construire a unui model al informaţiilor utilizate în întreprindere. 1. Prima formă normală (1NF) este o relaţie în care la intersecţia dintre fiecare rând cu fiecare coloană apare o singură valoare.5 • • • • • Descrieţi scopul normalizării datelor. A treia formă normală (3NF) este o relaţie (tabel) care se află în 1NF şi 2NF.

Determinarea atributelor chei candidat şi chei primare Cheile primare 1. Pasul 1.e. NumeP. li se atribuie denumiri evidente. se caută substantivele în specificaţia cerinţelor utilizatorului (de exemplu Nr_Personal.Documentarea tipurilor de relaţii.Vizualizarea pe parcurs a t. Specializarea/generalizarea t. Pe măsură ce sunt identificate. . compuse.r.2 Identificarea tipurilor de relaţii (t.Documentarea atributelor: pe măsură ce sunt identificate li se atribuit denumiri evidente şi semnificative pentru utilizatori.se caută obiectele principale de interes.Identificarea relaţiilor: de regulă relaţiile sunt indicate de expresii verbale în specificaţia utilizatorului.studierea specificaţiei cerinţelor utilizatorului referitor la funcţia utilizatorului în întreprindere.e. derivate. pentru a găsi o posibilă relaţie între ele. Pentru fiecare atribut se trec în dicţionarul de date: denumirea. Elemente ale modelului de date Sarcini pentru construirea modelului conceptual local conceptual local (Paşi) Tipuri de entităţi 1. li se atribuie denumiri evidente. Interesează numai relaţiile dintre entităţi cerute. dacă 51 . caracteristici identificatoare ale unei entităţi sau relaţii. Majoritatea relaţiilor sunt binare. Atributele derivate trebuie reprezentate în modelul conceptual pentru a nu pierde informaţii.) .r. excluzându-se calităţile.4.3.) Modalităţi de identificare: .r. personal administrează proprietate.e. Determinarea domeniilor atributelor Cheile candidat 1.e. Atributele sunt proprietăţi. Desenarea diagramei ER 1. eventual se specifică şi valorile limită ale cardinalităţii. Este bine de verificat fiecare pereche de tipuri de entităţi.8. Revizuirea modelului conceptual local cu utilizatorii Pasul 1. care se trec într-un dicţionar de date. şi t. precum şi constrângerile se trec în dicţionarul de date. Se deosebeşte între atribute simple.Modelul de date conceptual corespunzător vederii unui utilizator se numeşte model de date conceptual local corespunzător vederii respective. şi t.e.se identifică obiectele care există pe cont propriu (de exemplu Personal există indiferent de Nr_Personal.3 Identificarea şi asocierea atributelor cu t. . De exemplu: filiale are personal.e. Nr_Proprietate.: după identificarea t. parţială). Identificarea tipurilor de entităţi (t. Chirie etc.discuţii cu utilizatorii (de exemplu pentru eliminarea sinonimelor: Angajat = Personal) Documentarea t.r.e.1 Identificarea tipurilor de entităţi (t. sinonime sau aliasuri. Domeniile atributelor 1. chiriaş vizitează proprietate etc.r. tipul de date şi lungimea. . NumeP. identificarea şi asocierea atributelor cu t.) .r. Fiecare model de date conceptual local cuprinde elementele enumerate în tabelul de mai jos. găsite.7.6.5. identificate prin modelarea ER.Identificare: Se caută substantive sau expresii substantivale în specificaţia cerinţelor utilizatorilor care să caracterizeze t.1. . M:N) şi constrângerilor de participare (totală.) Tipuri de relaţii 1.e. eventuale valori prestabilite (default value). 1:M. din care se desprind sarcinile de proiectare conceptuală.e. etc.) Atribute 1. calităţi. (opţional) 1. Identificarea tipurilor de relaţii (t. Pasul 1. acestea.Determinarea cardinalităţii (1:1.) . se grupează (de exemplu Nr_Personal şi NumeP vor aparţine aceluiaşi tip de entitate Personal) . sau t.2. şi t. AdresaP. .

al utilizatorilor Unei entităţi tari i se poate identifica o cheie primară. Cheia primară aleasă va îndeplini următoarele criterii: o va cuprinde un set minim de atribute o va fi cheia candidat cu cea mai mică probabilitate de modificare a valorilor o va fi cheia candidat cu cea mai mică probabilitate de a-şi pierde caracterul de unicitate o va fi cheia candidat cu cele mai puţine caractere o va fi cheia candidat cel mai uşor de utilizat d. . . Modelul ER din figura 1.v.5 Determinarea atributelor chei candidat şi chei primare . care identifică în mod unic fiecare apariţie a acesteia.Documentarea domeniului atributelor: se înregistrează denumirea şi caracteristicile domeniilor atributelor în dicţionarul de date. Unei entităţi slabe i se poate identifica o cheie primară numai prin plasarea în ea a unei chei străine.34 b.) 52 . nu şi unei entităţi slabe.Determinarea: Domeniul este un recipient de valori din care unul sau mai multe atribute îşi iau valorile. Pasul 1. De exemplu domeniul numerelor de filială valabile este compus din 3 caractere.34 a conţine entităţile Proprietate_de_Inchiriat şi Proprietate_de_Vanzare. literăcifră-literă. formula de calcul. Cheile candidat care nu sunt selectate cheie primară devin chei alternative. Se generalizează prin crearea entităţii Proprietate (fig.p. Diagrama ER finală trebuie să fie cât mai lizibilă. 1.se acceptă Null-uri (required).4 Determinarea domeniilor atributelor .6 Specializarea/generalizarea tipurilor de entităţi (opţional) Acest pas este dictat de reprezentarea cât mai clară a entităţilor importante şi a relaţiilor dintre ele. Pasul 1.Documentarea cheilor primare şi alternative prin înregistrare în dicţionarul de date. Pasul 1. Domeniul va include şi mulţimea valorilor permise. dacă e compus sau derivat.d. dimensiunea şi formatul câmpului.identificare: pentru fiecare entitate se identifică toate cheile candidat şi se secţionează dintre ele cheia primară. în cadrul relaţiei sale cu entitatea tare. dacă are valori multiple. O cheie candidat este o submulţime minimă de atribute ale unei entităţi.

Pasul 1.8 Revizuirea modelului de date conceptual local împreună cu utilizatorii 53 .Fig. cheia primară) şi în baza relaţiilor comune asociate fiecăreia (Proprietar_deţine_Proprietate). Adresa.7 Desenarea diagramei ER Diagrama ER care se desenează va fi reprezentarea conceptuală a vederii unui utilizator asupra întregii întreprinderi. 1.34. Entităţile subclasă au şi atribute diferite (Chirie respectiv Preţ) şi relaţii diferite (Inchiriaza respectiv Cumpara). Diagrama ER va reprezenta modelul de date conceptual local bazat pe o anumită vedere a utilizatorului asupra întreprinderii. Exemplu de generalizare a tipului de entitate Entităţile Proprietate_de_Inchiriat şi Proprietate_de_Vanzare devin subclase ale entităţii Proprietate în baza atributelor comune (Tipul. Pasul 1.

1 Pasul 2. complet independent de detaliile de implementare. Pentru fiecare vedere a utilizatorilor asupra întreprinderii este creat un model de date conceptual local. Se efectuează modificarea structurii modelului conceptual conform cerinţelor modelului de date relaţional (conform cerinţelor caracteristice unui sistem de gestionare relaţional). domeniile atributelor.6 Proiectarea conceptuală a bazei de date este procesul de construire a unui model al informaţiilor utilizate în întreprindere. Descrieţi principalul obiectiv al proiectării conceptuale a bazelor de date. De regulă vederea unui utilizator este o zonă funcţională a întreprinderii. atributele.7 Metodologia de proiectare logică a bazelor de date pentru modelul relaţional Proiectarea logică este procesul de construire a unui model al informaţiilor utilizate în întreprindere pe baza unui anumit model de date. Analizaţi rolul important al utilizatorilor în procesul de proiectare al bazelor de date. 1.6. Construirea şi validarea modelului de date logic pentru fiecare vedere a utilizatorilor Acest pas este bazat pe modelul de date conceptual al vederii utilizatorului asupra întreprinderii (realizat la pasul 1). Fiecare model de date conceptual local este susţinut de către o documentaţie. independent de consideraţiile de ordin fizic. tipurile de relaţii. Identificaţi principalele sarcini asociate proiectării conceptuale a bazelor de date.3 Întrebări la capitolul 1.6 Descrieţi principalele faze implicate în proiectarea BD.7. Proiectarea conceptuală începe prin crearea unui model de date conceptual al întreprinderii. Un utilizator poate fi o persoană sau un grup de persoane care utilizează în mod direct sistemul. 1. 1.6.d. al utilizatorului. Descrieţi ce reprezintă o vedere a utilizatorului şi cum pot fi identificate diferitele vederi.Acest pas este necesar pentru a garanta că modelul este o reprezentare „adevărată” a întreprinderii d.v. 1. cheile candidat şi primare.p. Identificaţi şi descrieţi scopul documentaţiei generate pe parcursul proiectării conceptuale a bazelor de date. 54 . examinarea procedurilor. Vederile utilizatorilor se pot identifica utilizând diagrame de flux de date – care definesc zonele funcţionale şi eventual funcţiile individuale – sau/şi prin chestionarea utilizatorilor. Fiecare model de date conceptual local cuprinde tipurile de entităţi. O vedere a utilizatorului constă în datele cerute de către un anumit utilizator pentru a lua o decizie sau a efectua o anumită sarcină. rapoartelor şi observarea întreprinderii. cum ar fi dicţionarul de date. care este realizat pe parcursul dezvoltării modelului.2 Rezumatul capitolului 1. dar independent de SGBD şi de alte consideraţii de ordin fizic.

Relaţia complexă se înlocuieşte cu un număr corespunzător de relaţii binare de cardinalitate 1:M. AsociatCu şi Ţine. b! 55 . iar unei proprietăţi i se poate face reclamă in mai multe ziare.1 Eliminarea relaţiilor de tip M:N O relaţie M:N (de mai mulţi la mai mulţi) se descompune pentru a identifica o relaţie intermediară.36 relaţia complexă Inchiriaza s-a descompus în trei relaţii 1:M.36.2 Eliminarea relaţiilor complexe O relaţie complexă include cel puţin trei tipuri de entităţi. s-a identificat o entitate slabă: Acord_de_Inchiriere care este legată de entităţile tari (iniţiale) prin cele trei relaţii binare de cardinalitate 1:M identificate. anume Organizeaza. Ea trebuie descompusă pentru a identifica o relaţie intermediară. b! Pasul 2.35 b.1. Fig. 1.1.1 Transpunerea modelului de date conceptual local într-un model de date logic local Se rafinează modelul de date conceptual local prin eliminarea caracteristicilor nedorite. Analizaţi constrângerile de participare din fig. 1.35 Relaţia de cardinalitate M:N se descompune în 2 relaţii de cardinalitate 1:M Apar două tipuri de relaţii noi: Listeaza şi respectiv ReclamaIn care leagă entitatea slabă de cele 2 entităţi tari. Relaţia se descompune conform figurii 1.35 a şi 1.Pasul 2. În exemplul din figura 1. Relaţia M:N se înlocuieşte cu două relaţii 1:M. unde Reclama este o entitate slabă a cărei existenţă depinde de existenţa celorlalte două entităţi tari. 1. Pasul 2.35 a) este de cardinalitate M:N. Exemplu: Relaţia Ziar Face Reclama Proprietate (fig. 1.35. deoarece un ziar poate face reclamă mai multor proprietăţi. Analizaţi constrângerile de participare din fig.36 a şi 1.

1.Fig. Relaţie complexă M:N descompusă în trei relaţii binare 1:M.37 relaţia recursivă Supravegheaza este eliminată prin identificarea unei relaţii adiţionale denumită SupravegheatDe şi a unei entităţi slabe: Personal_Alocat. Analizaţi constrângerile de participare din fig. În exemplul din figura 1.1. Pasul 2. 1.37 a şi 1. b! 56 .3 Eliminarea relaţiilor recursive Acesta este un tip particular de relaţie care trebuie descompusă pentru a identifica o relaţie intermediară.37.36.

1. b! 57 . Exemplul din figura 1. 1.38 se referă la determinarea numărului de ore lucrate de angajaţii temporari atribuiţi fiecărei filiale.38 a şi 1.37.4 Eliminarea relaţiilor cu atribute Atunci când o relaţie are asociat un atribut.38.Fig. Eliminarea unei relaţii recursive Pasul 2. Se descompune în două relaţii binare de cardinalitate 1:M. Acum atributul Ore_Lucrate aparţine noii entităţi slabe identificate: Alocaţie_Filiala. Relaţia LucreazaLa are atributul Ore-Lucrate şi este de cardinalitate M:N. acest lucru sugerează existenţa unui tip de entitate neidentificat.1. Analizaţi constrângerile de participare din fig.

2 Extragerea relaţiilor (tipurilor de entităţi) din modelul de date logic local În urma pasului 2. Se identifică o nouă entitate: Telefon.1. Trebuie deci de aflat dacă există mai mult decât o singură cale între două entităţi.6 relaţiilor 1:1 Reexaminarea Asemenea relaţii pot indica existenţa a două relaţii care să reprezinte acelaşi obiect în cadrul întreprinderii.1 s-a obţinut modelul de date logic local.40 relaţia este neredundantă. Discutaţi posibilitatea declarării entităţii Telefon ca entitate slabă şi a constrângerii de participare a entităţii Filiala ca parţială. Eliminarea unei relaţii cu atribut Pasul 2. deşi există 2 căi intre entitatea Copil şi Barbat. Tatăl ar putea avea copii dintr-o căsătorie precedentă.Fig. Relaţie neredundantă! Pasul 2.38. Cealaltă cheie primară devine alternativă. Eliminarea atributelor cu valori multiple Pasul 2. În exemplul din figura 1. 1. ca urmare a rafinării modelului de date conceptual. Fig. 58 . unde o filială poate avea mai multe numere de telefon.40.1. Trebuie de ţinut cont şi de semnificaţia temporală a relaţiilor.5 Eliminarea atributelor cu valori multiple Este vorba de atribute cu mai multe valori pentru o singură entitate. Exemplul din figura 1. legată de entitatea Filiala prin relaţia Are. 1.39 se referă la evidenţa filialelor. De exemplu entităţile Filiala şi departament pot fi sinonime. Pasul 2. nu înseamnă neapărat că una din relaţii este redundantă. Dacă se identifică 2 căi. sau ar putea să nu fie căsătorit cu mama copilului. În astfel de situaţii cele două entităţi se îmbină. iar în figură se modelează numai căsătoria curentă a tatălui.39.1. Acest atribut trebuie descompus pentru a identifica o nouă entitate. dacă acestea nu coincid.7 Eliminarea relaţiilor redundante O relaţie este redundantă atunci când aceeaşi informaţie se poate obţine şi prin alte relaţii. 1. selectând una din cheile primare. Fig.

Relaţia pe care o entitate o are cu altă entitate este exprimată prin mecanismul cheie primară – cheie străină. NumeR.41.41). Sex. Nr_Tel. Adresa. Functia. prezentate în modelul de date logic (fig. În plus se include cheia primară a entităţii părinte (sau proprietar) ca şi cheie străină. Pentru fiecare entitate slabă se creează o relaţie care să cuprindă toate atributele sale simple. În continuare se prezintă cum relaţiile care reprezintă entităţile şi relaţiile acestora sunt extrase din structurile de date posibile. 1.2. Rudenie) Cheie primară Nr_Personal împreună cu NumeR 59 . Se identifică cheia primară. Componenţa fiecărei relaţii va fi descrisă utilizând un limbaj de definire a bazelor de date (DBDL).La pasul 2. Într-un DBDL apare denumirea relaţiei. Se trece relaţia care conţine cheia străină ca şi cheie primară. Tipuri de entităţi tari: Pentru fiecare entitate tare (obişnuită) se creează o relaţie care să cuprindă toate atributele sale simple. Adică cheia primară din entitatea părinte devine cheie străină în entitatea copil. Nume. Salariu) Cheie primară Nr_Personal b. Orasul. Prenume. Exemplu: entitatea tare Personal Personal (Nr_Personal. Strada. Fig. Compoziţia acestei relaţii va fi: Ruda_Apropiata (Nr_Personal. 1. CodP. apoi între paranteze atributele simple. Tipuri de entităţi slabe: Ruda_Apropiata. se extrag relaţiile pentru a reprezenta entităţile care le compun. Model de date logic Din acest model de date logic se extrag: a. cheile alternative şi/sau cheile străine ale relaţiei.

Compoziţia relaţiilor extrase din modelul de date logic se documentează utilizând DBDL. Şi dicţionarul de date trebuie reactualizat cu noile atribute cheie identificate la pasul 2. Întotdeauna cheia primară din entitatea părinte devine cheie străină în entitatea copil. unde Filiala este părinte iar personal este copil. În prima formă normală se elimină grupurile repetitive. Nr_Fax. deoarece are participare parţială.3 Validarea modelului prin utilizarea normalizării Normalizarea este o procedură de stabilire a atributelor care aparţin împreună unui tip de entitate. Orasul. Nr_Filiala) Cheie primară Nr_Personal Cheie străină Nr_Filiala se referă la Filiala (Nr_Filiala) Filiala (Nr_Filiala. Nr_Tel. Functia. Sintaxa poate fi extinsă pentru a exprima constrângerile de integritate asupra cheilor străine (vezi pasul 2.Cheie străină Nr_Personal se referă la Personal (Nr_Personal) c. Entitatea aflată în partea notată cu „1” este entitatea părinte. Prin normalizare datele sunt organizate conform dependenţelor lor funcţionale şi se elimină riscul anomaliilor de reactualizare. care se referă la Personal (Nr_Personal) Pasul 2. unde devine cheie străină. Compoziţia acestor relaţii va fi: Personal (Nr_Personal. Strada. Strada.2 Pasul 2. Nr_Fax. Sex. Ca urmare se plasează o copie a cheii primare din Personal în Filiala. Pasul 2. Nr_Tel. Salariu.2. Prenume.6). Functia. se încheie cu documentarea relaţiilor şi atributelor chei străine. Nr_Personal_Manager) Cheie primară Nr_Filiala Cheie alternativă Nr_Tel sau Nr_Fax Cheie străină Nr_Personal_Manager. CodP. Adresa. Adresa. Sex. Orasul. iar cea din partea cu „M” este entitatea copil. Tipuri de relaţii binare unu la unu (1:1) În relaţia de cardinalitate 1:1 Personal Administreaza Filiala entitatea părinte este Personal. Tipuri de relaţii binare unu-la-mai-mulţi (1:M) Pentru fiecare relaţie binară 1:M între entităţile E1 şi E2 se plasează o copie a cheii primare din E1 în E2. Nume. Prenume. CodP. Exemplu: Filiala Are Personal. unde devine cheie străină sub denumirea Nr_Personal_Manager. Compoziţia acestor relaţii va fi: Personal (Nr_Personal. Nume. care se referă la Personal (Nr_Personal) d. Nr_Personal_Manager) Cheie primară Nr_Filiala Cheie alternativă Nr_Tel sau Nr_Fax Cheie străină Nr_Personal_Manager. Salariu) Cheie primară Nr_Personal Filiala (Nr_Filiala.4 validarea modelului conform tranzacţiilor utilizatorului 60 .

Integritatea referenţială Se referă la relaţia entitate părinte – entitate copil. Integritatea referenţială înseamnă ca o valoare nenulă a cheii străine din entitatea copil trebuie să se refere la (să coincidă cu) o valoare existentă în entitatea părinte. Se admit atunci când entitatea copil are participare parţială. nu sunt permise Null-uri în câmpul cheie străină. Se verifică pasul 1. Se ştie că cheia primară din părinte se copiază în copil unde devine cheie străină. de cardinalitate 1:M.5 d. integritatea referenţială e. Integritatea entităţilor Cheia primară a unei entităţi nu poate conţine Null-uri. Se consideră 5 tipuri de integritate. Datele cerute Unele atribute nu admit Null-uri. anume referitoare la: a. Dacă entitatea copil are participare totală în relaţie.Modelul trebuie să accepte tranzacţiile cerute de către vederile utilizatorului. care cere date pentru câmpul respectiv. Pasul 2. Pasul 2. domeniile atributelor c.6 Definirea constrângerilor de integritate Prin impunerea de constrângeri se protejează baza de date faţă de riscul de incoerenţă.4 c. integritatea entităţilor d. Constrângerile privind domeniile atributelor Se verifică dacă s-au identificat şi documentat la pasul 1. 61 . Se verifică dacă aceste constrângeri au fost identificate şi documentate în dreptul atributelor în dicţionarul de date (vezi pasul 1. cheie primară: Nr_Personal Entitate copil (Ec): Proprietate. Entitate părinte (Ep): Personal. copie a cheii primare din Personal. reactualizată (modificată) sau ştearsă o cheie candidat sau o cheie străină.2) b. Se ia ca exemplu relaţia Personal Administrează Proprietate. validată prin normalizare şi conform cu tranzacţiile pe care trebuie să le accepte. a dicţionarului de date şi a legăturilor cheie primară/cheie străină prezentate în relaţii se încearcă efectuarea manuală a tranzacţiilor. Asigurarea integrităţii referenţiale se realizează prin constrângeri de existenţă. constrângerile întreprinderii a. Acestea definesc condiţiile în care poate fi inserată. datele cerute b. Tranzacţiile se determină din specificaţiile cerinţelor utilizatorilor. Prin folosirea diagramei ER. În aceste situaţii se selectează proprietatea de câmp required.5 Desenarea diagramei ER Se desenează varianta finală a diagramei ER. cheie străină: Nr_Personal.

Dacă Ec acţionează ca Ep în altă relaţie. Nu are loc nici o verificare de integritate. ştergerea se propagă în cascadă. Dacă apariţie care urmează a fi ştearsă din Ep îi corespunde o apariţie (sau mai multe) din Ec. Când se şterge o apariţie din Ep nu este garantată menţinerea integrităţii referenţiale. Pasul 2. dacă are corespondent(i) în Ec Dacă o apariţie în Ec se şterge.7 Revizuirea modelului de date logic local împreună cu utilizatorii 62 . e. Reactualizarea cheii străine în relaţia (entitatea) copil Similar cazului 1.Cazul 1. Aceasta se face în dicţionarul de date. integritatea referenţială este pierdută. SET DEFAULT NO CHECK Cazul 6. Reactualizarea cheii primare în relaţia (entitatea) părinte Dacă valorii reactualizate a cheii primare în Ep îi corespundeau una (mai multe) valori ale cheii străine în Ec.6. valorile cheii străine corespunzătoare din Ec sunt setate la valori prestabilite (default). Ştergerea unei apariţii din relaţia (entitatea) copil Se poate efectua fără probleme. Inserarea unei apariţii în relaţia (entitatea) copil Pentru a asigura integritatea referenţială se verifică dacă atributul Nr_Personal din apariţia nou inserată în Ec este stabilit ca Null sau are o valoare existentă în Ep. se încheie cu documentarea tuturor constrângerilor de integritate. Se va aplica una din strategiile de la cazul 5. Exemplu: se şterge un membru al personalului în Ep (Personal) şi automat proprietăţile pe care acestea le-a administrat trecute în Ec (Proprietăţi) se setează la atributul Nr_Pers la valoarea corespunzătoare managerului. De exemplu agenţia imobiliară poate stabili ca un membru al personalului să administreze maxim 10 proprietăţi. se şterg automat corespondenţii din Ec. Când se şterge o apariţie din Ep. nu afectează integritatea referenţială. Când se şterge o apariţie din Ep. Inserarea unei apariţii în relaţia (entitatea) părinte Se poate efectua fără probleme. Cazul 2. Cazul 3. valorile cheii străine în Ec sunt setate la Null. Are loc o reactualizare prin setare la Null a valorilor atributelor selectate din cheia străină a Ec. Posibile strategii de luat în considerare: NO ACTION CASCADE SET NULL Blocarea ştergerii apariţiei din Ep. Pasul 2. Ştergerea unei apariţii din relaţia (entitatea) părinte. Cazul 4. pentru a fi luate în considerare la implementarea fizică. Constrângerile întreprinderii Sunt de fapt regulile de afaceri care pot uneori genera reactualizări ele entităţilor. Cazul 5. Ep are participare parţială. atunci integritatea referenţială se pierde prin ştergere. deci poate exista un membru al personalului care nu administrează o proprietate. Această strategie se poate aplica numai dacă atributele cheie străină acceptă Null-uri.

Se procedează ca la (1). Modelul şi documentaţia se revăd împreună cu utilizatorul. Pasul 3. eliminându-se dublurile. Pot exista două sau mai multe entităţi care au aceeaşi denumire dar sunt de fapt diferite. 1.43) 63 .2 Pasul 3. 1. Se utilizează cheile primare pentru a identifica tipurile de entităţi echivalente.42) Astfel de entităţi reprezintă de regulă acelaşi obiect în lumea reală.Se verifică dacă modelul de date logic local este o reprezentare „adevărată” a vederii utilizatorului. Va rezulta o reprezentare a întregii întreprinderi independentă de orice utilizator sau aplicaţie. Se compară conţinutul de date al fiecărui tip de entitate. ca şi orice suprapuneri existente. 1.7.1 Îmbinarea modelelor de date logice locale individuale într-un singur model de date logic global al întreprinderii (1) Revizuirea denumirilor entităţilor şi cheilor primare din modelele locale. dar sunt aceleaşi. Îmbinarea entităţilor cu aceeaşi denumire şi aceeaşi cheie primară În versiunea globală obţinută prin îmbinare s-a utilizat versiunea descompusă a atributului Nume_Prenume (în urma consultării cu utilizatorii). Modelul de date logic local trebuie să fie complet şi in întregime documentat. Construirea şi validarea modelului de date logic global În această etapă se construieşte un model de date logic global prin îmbinarea modelelor de date logice locale individuale.42. respective acre au denumiri diferite. La fuziune se includ atributele entităţilor iniţiale. Fig. care au fost realizate pentru a reprezenta fiecare vedere a utilizatorilor. 1. (2) Revizuirea denumirilor relaţiilor. Îmbinarea entităţilor cu aceeaşi denumire şi chei primare diferite (fig. dar cu denumiri diferite. (3) Îmbinarea entităţilor din vederile locale Îmbinarea entităţilor cu aceeaşi denumire şi aceeaşi cheie primară (fig. După îmbinare trebuie rezolvate conflictele dintre vederi.

Exemplu: Entităţile Personal şi Angajaţi. Dintr-o astfel de corespondenţă rezultă existenţa unei relaţii neidentificate. Îmbinarea entităţilor cu aceeaşi denumire şi chei primare diferite Îmbinarea entităţilor cu denumiri diferite.Îmbinarea relaţiilor cu denumiri diferite dar acelaşi scop (6) Includerea (fără îmbinare) a relaţiilor unice din fiecare vedere locală Relaţiile pentru care nu s-au găsit relaţii identice în alte vederi se includ nemodificate în modelul global. Se examinează atributele fiecărui tip de entitate şi se compară cu atributele entităţilor din alte vederi. cu chei primare similare sau diferite Astfel de entităţi se pot identifica atunci când: denumirile sunt diferite. Poate exista un atribut al unei entităţi dintr-o vedere care corespunde unui atribut cheie primară.43. construibilă prin mecanismul cheie primară/cheie străină.Îmbinarea relaţiilor cu aceeaşi denumire şi acelaşi scop.42. dacă există.Astfel de entităţi nu au aceeaşi cheie primară. dar indică acelaşi scop. prin: . 1. scop. (8) Verificarea cheilor străine Se verifică dacă cheile străine din entităţile copil mai sunt corecte şi se efectuează modificările necesare. după cheia primară. Când se consultă utilizatorii asupra unei anumite vederi. dar au chei candidat similare. ei trebuie rugaţi să examineze şi entităţile şi relaţiile din alte vederi. constrângeri structurale) din toate vederile locale şi se elimină conflictele. 1. (4) Includerea (fără îmbinare) a entităţilor unice din fiecare vedere locală Toate entităţile care nu au echivalent se includ nemodificate în modelul global. apoi . cheie alternativă sau unui atribut simplu al unei entităţi din altă vedere. Fig. (5) Îmbinarea relaţiilor din vederile locale Se examinează toate relaţiile (denumire. Rezultă aceeaşi vedere globală ca în fig. (7) Căutarea entităţilor şi relaţiilor lipsă Identificarea entităţilor şi relaţiilor lipsă dintre diversele vederi ale utilizatorilor şi care nu apar în nici una dintre vederi este o operaţiune dificilă: Acestea pot rezulta din modelul de date general. 64 . după participarea în anumite relaţii.

bazat pe un anumit model de date. Este un pas echivalent cu 2. să poată evolua în condiţiile afectării minime a utilizatorului.7 Proiectarea logică a bazelor de date este procesul de construire a unui model al informaţiilor utilizate în cadrul unei întreprinderi. dacă este necesar. anume se fac aceleaşi validări dar acum pentru modelul de date logic global. Se desenează după ce modelul de date logic global a fost validat. Pasul 3. cu atribute. dar independent de un anumit SGBD şi de alte consideraţii de ordin fizic.5 Revizuirea modelului de date logic global împreună cu utilizatorii Revizuirea va garanta faptul că modelul de date logic global este o reprezentare „adevărată” a întreprinderii.2 Validarea modelului de date logic global Se realizează prin utilizarea normalizării şi conform tranzacţiilor cerute.3 respectiv 2. Se incorporează modificări numai dacă utilizatorul o cere. (11) Reactualizarea documentaţiei Documentaţia trebuie reactualizată în urma modificărilor intervenite la realizarea modelului global.7. Modelul de date logic se validează prin normalizare. Conflictele se rezolvă prin consultarea cu utilizatorii. este coerent. Modelul creat trebuie să fie extensibil. Pasul 3. cu redundanţă minimă şi stabilitate maximă. Documentaţia (schema relaţională şi dicţionarul de date) trebuie reactualizată şi completată.3 Verificarea în vederea dezvoltării locale Se determină dacă este probabil ca în viitorul previzibil să apară modificări şi se evaluează capacitatea modelului de date logic global de a cuprinde aceste modificări. (10) Desenarea modelului de date logic global Se desenează diagrama ER a modelului de date logic global. reexaminarea relaţiilor de tip 1:1 şi eliminarea relaţiilor neredundante. Pasul 3. Modelul de date logic global trebuie să poată fi extins cu uşurinţă.(9) Verificarea constrângerilor de integritate Se verifică dacă constrângerile de integritate ale modelului global nu intră în conflict cu constrângerile de integritate din vederile utilizatorilor. 65 .4. a relaţiilor complexe. Modelul împreună cu documentaţia se revizuiesc în colaborare cu utilizatorii. Documentaţia trebuie să reflecte întotdeauna modelul de date curent. Principalele etape cuprind: construirea şi validarea unui model de date logic local corespunzător fiecărei vederi a utilizatorilor (pasul 2) şi construirea şi validarea unui model de date logic global (pasul 3).4 Desenarea diagramei ER finale Diagrama ER finală reprezintă modelul de date logic global al întreprinderii. Rafinarea unui model de date conceptual pentru a obţine un model de date logic include: eliminarea relaţiilor de tip M:N. prin care se garantează că modelul reprezintă fidel întreprinderea.3 Rezumatul capitolului 1. a atributelor cu valori multiple. care reprezintă îmbinarea tuturor modelelor de date logica locale. pentru a confirma că sunt corecte şi complete. 1. recursive. Pasul 3.

ale domeniilor atributelor.dacă sistemul acceptă definirea datelor necesare (adică a unor atribute ca fiind NOT NULL) .7 • • • • • • • Analizaţi scopul proiectării logice a bazelor de date. 1:m. care sunt realizate pe parcursul construirii modelului. 1. 1. Modelul de date logic este susţinut de către documentaţie. Există 5 tipuri de constrângeri de integritate: asupra datelor necesare.1 Pasul 4.dacă sistemul acceptă definirea domeniilor .4 Întrebări la capitolul 1. străine şi alternative. Transformarea modelului de date logic global pentru un SGBD ţintă Acest pas presupune transformarea relaţiilor extrase din modelul de date logic global într-o formă care să poată fi implementată in SGBD ţintă. cum ar fi dicţionarul de date sau schema relaţională.dacă sistemul acceptă definirea cheilor primare. Descrieţi scopul constrângerilor de integritate şi arătaţi care sunt cele 5 tipuri principale de constrângeri.cum se creează relaţiile de bază. Integritatea referenţială se asigură prin constrângeri de existenţă. Descrieţi etapele rafinării modelului de date conceptual pentru a se obţine modelul de date logic Descrieţi regulile de extragere a relaţiilor care reprezintă tipuri de entităţi tari şi slabe. care definesc în ce condiţii poate fi o cheie candidata sau străină inserată. de integritate referenţială şi ale întreprinderii. SET NULL. pentru obţinerea modelului de date logic global. Constrângerile întreprinderii se numesc uneori şi reguli de afaceri.dacă sistemul acceptă definirea constrângerilor întreprinderii . SET DEFAULT şi NO CHECK. reactualizată sau ştearsă. Există mai multe strategii care pot fi aplicate atunci când o apariţie a entităţii părinte pe care vrem să o ştergem are corespondent în entitatea copil: NO ACTION. 1. 66 .7. tipuri de relaţii binare 1:1. Identificaţi sarcinile asociate cu îmbinarea modelelor de date logice locale. de exemplu: . Este necesară cunoaşterea funcţionalităţii SGBD ţintă. Analizaţi modul in care tehnica de normalizare poate fi utilizată pentru a valida modelul de date logic.8 Metodologia de proiectare fizică a bazelor de date pentru bazele de date relaţionale Proiectarea fizică a bazelor de date este procesul de descriere a implementării bazei de date într-o capacitate de stocare secundară. de integritate a entităţilor. Descrieţi strategiile alternative aplicabile atunci când există o apariţie a Ec care se referă la o apariţie a Ep pe care vrem s-a ştergem.8.Constrângerile de integritate se impun pentru a proteja BD faţă de a deveni incoerentă. CASCADE. . se descriu structurile de stocare şi metodele de acces utilizate pentru asigurarea unui acces eficient la date.

cheile alternative (AK) şi cheile străine (FK) .dacă atributul poate conţine NULLuri .1 Proiectarea relaţiilor de bază pentru SGBD ţintă Trebuie confruntate şi asimilate informaţiile referitoare la relaţii (tabele) obţinute prin modelarea logică a datelor. în DBDL. şi în acest caz cum trebuie calculat.dacă atributul este derivat. pentru fiecare atribut există şi: .cheia primară (PK). lungimea acestora şi constrângeri asupra domeniului .listă de atribute simple (între paranteze) .domeniul atributului. Aceste informaţii sunt obţinute din definiţia relaţiilor (în DBDL) şi din dicţionarul de date.opţional. De exemplu în cazul BD a agenţiei imobiliare discutată.constrângerile de integritate corespunzătoare oricărei chei străine (FK) identificate Din dicţionarul de date. 67 . pentru implementarea cu ajutorului SGBD MS-Access este redat în figura de mai jos.denumirea relaţiei . Pentru fiecare relaţie identificată în modelul de date logic global vom avea o definiţie formată din: . proiectul pentru relaţia de bază (tabelul) Proprietate_de_Închiriat. o valoare prestabilită a atributului .Pasul 4. care constă din tipul de date. şi după caz.

Proiectul logic iniţial a fost adaptat funcţionalităţii SGBD ţintă (MS-Access). În continuare sunt prezentate câteva exemple ale acestui proces de adaptare (rafinare): 68 .

) MS Access oferă doar: Regula de reactualizare: CASCADE Regula de ştergere: NO ACTION MS Access nu acceptă: SET NULL şi SET DEFAULT Nr_ProprietarP (FK) Nr_ProprietarA (FK) Admit NULLuri Nr_Filiala (FK) Se trece la crearea bazei de date în MS_Access.Atributul Nr_Proprietate (PK) Proiectul logic Şir variabil de caractere. lungimea 5 Nr_ProprietarP (FK) → Nr_Proprietar din „Proprietar_Privat” iar Nr_ProprietarA (FK) → Nr_Proprietar din „Proprietar_Afacere” Regula de reactualizare: CASCADE Regula de ştergere: NO ACTION Explicaţii Access nu deosebeşte între şiruri de caractere cu lungime fixă şi variabilă Access nu acceptă ca o aceeaşi FK dintr-un tabel copil să bată în 2 tabele părinte diferite (integrit. Modul de creare a tabelelor (relaţiilor) în MS_Access este detaliat în partea a doua a cursului. 5 Nr_Proprietar → Nr_Proprietar din „Proprietar_Privat” şi în totodată Nr_Proprietar → Nr_Proprietar din „Proprietar_Afacere” Regula de reactualizare: CASCADE Regula de ştergere: SET DEFAULT Proiectul fizic pt. pornind de la Blank Database. max. 69 . MSAccess Tip de date Text. Mai jos este prezentată vizualizarea de proiectare (Design View) a tabelului corespunzător relaţiei Proprietate_de_Închiriat. ref.

input mask. caption. validation rule/text. 70 . format. required. . ca cea pentru tipul de proprietate: O dată create toate tabelele proiectate.Se creează liste de tip „lookup”.În cadrul tabelelor: . se realizează relaţiile dintre acestea şi se impune integritatea referenţială. default value.se setează proprietăţile câmpurilor: field size.se specifică cheia primară .

pot influenţa reactualizările relaţiilor. care lucrează cu baze de date în Access.transferul de tranzacţii: număr de tranzacţii prelucrabile în timp . Proiectarea constrângerilor întreprinderii pentru SGBD ţintă Constrângerile întreprinderii. 71 .8. Proiectarea reprezentării fizice Se determină organizarea fişierelor şi metodelor de acces utilizate pentru stocarea relaţiilor de bază. Proiectantul trebuie să cunoască cele 4 componente hardware care interacţionează şi afectează performanţele sistemului: memoria principală. reţeaua.Cascade Update Related Fields: modificarea unei valori din cheia primară din tabelul părinte declanşează automat reactualizarea valorilor corespunzătoare din toate înregistrările legate. respectiv invers.timpul de răspuns: timpul scurs până la încheierea unei singure tranzacţii (de minimizat) . provenite din lumea reală. Exemplu: Un angajat nu poate administra mai mult de 10 proprietăţi. unitatea CPU.capacitatea de stocare pe disc: spaţiul pe disc necesar stocării fişierelor bazei de date (de minimizat).44.2 Pasul 5. Pasul 4. Distribuirea datelor pe unităţile de disc se observă în figura 1. discul I/O. Stocarea eficientă a datelor se evaluează prin: .2. Cascade Delete Related Records: ştergerea unei înregistrări din tabelul părinte duce la ştergerea tuturor înregistrărilor legate din tabelul copil. Pasul 4. Pentru Access implementarea constrângerilor de întreprindere se realizează de exemplu cu limbajul Visual Basic. 1. Constrângerile trebuie reproiectate în funcţie de SGBD ales.1 se încheie cu documentarea proiectului fizic prin DBDL . SGBD se alege astfel încât să permită implementarea acestei constrângeri.

cunoscând adresele proprietăţilor vizitate Hărţile de utilizare a tranzacţiilor a) Harta cu modelul ER simplificat cu numerele estimate de apariţii ale fiecărei entităţi În colţul din stânga sus al fiecărei entităţi este trecut estimarea numărului total de apariţii ale acesteia (numărul de înregistrări din tabel). Astfel: .frecvenţa estimată cu care vor fi rulate tranzacţiile . o Unei filiale îi sunt alocate în medie 240 şi maxim 300 proprietăţi de închiriat.relaţiile şi atributele accesate de tranzacţie şi tipul de acces (interogare.constrângerile de timp impuse tranzacţiilor În cazul BD a unei agenţii imobiliare se consideră – cu titlu de exemplu – următoarele tranzacţii: A: realizarea unui raport în care sunt enumerate proprietăţile de închiriat din cadrul fiecărei filiale B: crearea şi întreţinerea înregistrărilor referitoare la clienţii din cadrul fiecărei filiale C: enumerarea vizitelor efectuate de clienţi. Configuraţia tipică a discului Pasul 5. o La o filială sunt înregistraţi în medie 400 şi maxim 500 de chiriaşi.1 Analizarea tranzacţiilor Pentru fiecare tranzacţie se determină: . asociate unei apariţii din entitatea părinte. inserare.Fig. ştergere) . reactualizare.În tabelul „Filiala” sunt înregistrate 50 de filiale. 72 . Se indică de asemenea valorile medii şi maxime ale apariţiilor dintr-o entitate copil.44. 1.

o O proprietate de închiriat este vizitată (apare în „Vizitare”) în medie de 20 şi maxim de 40 de ori. B: crearea şi întreţinerea înregistrărilor referitoare la clienţii din cadrul fiecărei filiale Tranzacţia B necesită inserarea (I) a clienţilor (chiriaşilor) înregistraţi în tabelul „Chiriaş” şi în acelaşi timp la o anume filială. citire (C). În tabelul „Vizitare” sunt înregistrate estimativ 360000 vizitări (12000 proprietăţi de închiriat x 30 vizitări /proprietate) b) Harta căilor şi operaţiilor tranzacţiilor A. citi. cunoscând adresele proprietăţilor vizitate 73 . reactualiza sau şterge chiriaşii înregistraţi la fiecare filială.- - În tabelul „Proprietate_de_Închiriat” sunt înregistrate estimativ 12000 proprietăţi (50 filiale x 240 proprietăţi. Prin intermediul atributului Nr_Filială (cheie primară în Filiala şi cheie străină în Proprietate_de_Închiriat) se citesc (C) proprietăţile de închiriat oferite de fiecare filială. B şi C. iar prin atributul Nr_Filială (cheie primară în „Filiala” şi cheie străină în „Chiriaş”) se vor insera. reactualizare (R) sau ştergere (Ş) împreună cu calea corespunzătoare tranzacţiilor A. Pentru executarea tranzacţiei B se va accesa tabelul „Filiala”. În tabelul „Chiriaş” sunt înregistraţi estimativ 20000 de chiriaşi (50 filiale x 400 chiriaşi în medie/filială) o Un chiriaş efectuează în medie 10 şi maxim 20 de vizitări. reactualizarea (R) şi ştergerea (Ş) datelor referitoare la chiriaşi. B şi C În harta b) sunt afişate operaţiile de inserare (I). A: realizarea unui raport în care sunt enumerate proprietăţile de închiriat din cadrul fiecărei filiale Tranzacţia A deci necesită accesarea tabelului „Filiala” şi citirea (C) a datelor din acest tabel. în medie/filială). C: enumerarea vizitelor efectuate de clienţi.

La accesarea unui număr de filială din „Filiala” se accesează tabelul „Proprietate_de_Inchiriat” de 48 – 300 ori (există minim 48 de proprietăţi din fiecare tip disponibile la o filială. Atributele utilizate ca puncte de acces. În cadrul tranzacţiei D se accesează tabelul „Filiala”. documentate în figura de mai sus. ISAM – Indexed Sequential Access Method. Prin atributul Nr_Proprietate (cheie primară în „Proprietate_de_Închiriat” şi cheie străină în „Vizitare”) se citesc (C) vizitelor efectuate la acea proprietate.Tranzacţia C necesită accesarea tabelului „Proprietate_de_Închiriat”. de intrare sunt notate cu (P). inclusiv momentul sau intervalul de încărcare maximă. Analizând toate tranzacţiile (nu numai A.2 Alegerea organizării fişierelor Se alege tipul adecvat de fişier. cunoscut. şi o filială oferă maxim 300 de proprietăţi). Singurele operaţii necesare pentru tranzacţia D sunt de citire (C). modelul lor de execuţie se documentează ca în cazul exemplului de mai jos. Atributul „Tipul” se utilizează ca punct de intrare pentru interogare (clientul caută un anumit tip de proprietate). şi D exemplificate) asupra întregii baze de date a agenţiei imobiliare se constată că foarte multe tranzacţii necesită accesarea tabelului „Proprietate_de_Închiriat”. B. care satisfac un anumit tip de proprietate cerut de un potenţial chiriaş. C. care poate fi: heap. Din tabelul „Filiala”. 74 . prin mecanismul cheie primară-cheia străină (Nr_Filiala) se citesc (C) în tabelul „Proprietate_de_Închiriat” datele referitoare le toate proprietăţile oferite de o anumită filială. punct de acces fiind atributul adresa proprietăţii. arbore B+. punctul de acces fiind atributul cheie primară Nr_Filială. De asemenea se pot înregistra şi ziua şi ora estimată la care va fi rulată fiecare tranzacţie. hash. care se citeşte (C). Pentru tranzacţiile care accesează frecvent baza de date. Pasul 5. referitor la tranzacţia D: D: căutarea proprietăţilor de închiriat oferite de o anumită filială.

Indicaţii referitoare la indexare: .În majoritatea cazurilor SGBDurile bazate pe PCuri (de ex. Exemplu: pentru entitatea Proprietate_de_Inchiriat se va indexa cheia primară Nr_Proprietate (index primar) şi se poate constitui un index secundar pentru atributul Chirie. În cazul interogării a mai multe tabele simultan (interogare de tabele multiple) viteza de interogare poate fi mărită prin indexarea câmpurilor din ambele părţi ale firului relaţiei (din ambele părţi ale uniunii) şi prin indexarea câmpurilor pentru care se utilizează criterii de interogare.nu se indexează relaţii mici . deoarece întreţinerea indexurilor încarcă suplimentar resursele.se indexează cheia primară . Indexurile secundare oferă un mecanism de specificare a unei chei adiţionale. MS-Access indexează automat cheile primare şi cheile străine din tabele.nu se indexează atribute cu şiruri lungi de caractere. Pasul 5.nu se indexează atribute frecvent reactualizate . Este indicat să se creeze numai indexuri care se presupune că vor îmbunătăţi performanţele sistemului. pentru regăsirea mai eficientă a datelor. Crearea indexurilor secundare se documentează. MS-Access) nu permit utilizatorului alegerea sau modificarea organizării fişierelor din tabelele de bază. Pasul 5.4 Considerarea introducerii unei redundanţe controlate 75 . De exemplu în tabelul „Proprietate_de_Închiriat” se vor indexa câmpurile frecvent interogate „tipul” şi „zona”. ceea ce ar putea avea ca rezultat final scăderea vitezei sistemului. ca fiind de interes. împreună cu motivaţia pentru care au fost considerate necesare.3 Alegerea indexurilor secundare Trebuie de determinat dacă adăugarea de indexuri secundare îmbunătăţeşte performanţele sistemului.se indexează cheia străină dacă e frecvent utilizată .

Relaţia Personal simplificată cu atributul derivat Nr_Proprietăţi Dacă BD este interogată frecvent asupra numărului de proprietăţi administrate de fiecare membru al personalului poate fi util de stocat acest atribut derivat în relaţia (entitatea) Personal. 76 . unde se trece avansul pentru fiecare proprietate.costuri suplimentare de stocare şi menţinere a concordanţei datelor derivate cu datele operaţionale din care au fost derivate. Pasul 5. „Proprietate_de_Închiriat”.1 Considerarea datelor derivate Valorile atributelor derivate pot fi calculate din valorile altor atribute. tipului. după atributul NrPer (fig. oraşului. 1. se preferă adăugarea unui câmp suplimentar în tabelul de bază. Exemplu: Entitatea Personal poate conţine un nou atribut derivat (Nr_Proprietati) care arată câte proprietăţi administrează fiecare membru al personalului.45). Fig. Stocarea unui atribut derivat în BD duce la: .45. Interogarea trebuie să cuprindă toate câmpurile cerute plus un câmp calculat (derivat) pentru „avans”. Exemplu: Tranzacţia E: Enumerarea numărului proprietăţii. scade flexibilitatea BD. .4. Deci la executarea tranzacţiei E nu mai trebuie calculat (prin rularea interogării) avansul pentru fiecare proprietate. Datorită denormalizării implementarea BD este mai dificilă. câmp numit „Avans”. 1. chiriei şi avansului pentru închiriere (conform regulilor de afaceri: avansul = 2 x chiria). Pentru a evita rularea repetată a interogării. se pot accelera regăsirile dar se încetinesc reactualizările. calculat de operatorul uman la înregistrarea sau actualizarea proprietăţii respective.costuri de calculare a datelor derivate de fiecare dată când este necesar.Trebuie de determinat dacă introducerea de redundanţă controlată prin relaxarea normalizării (denormalizare) duce la îmbunătăţirea performanţelor sistemului. Valoarea acestui atribut se derivă din entitatea Proprietate_de_Inchiriat.

Strada. Zona. Pentru evitarea redundanţei. Orasul) Astfel la introducerea unei filiale noi nu trebuie de repetat toate informaţiile legate de oraş. Strada. CodP. Nr_Fax) Cod_Postal_Filiala (Nr_Fil. CodP. Nr_Tel. prin normalizare relaţia Filiala (Nr-Fil. Zona. Orasul.4. 77 .Pasul 5.2 Considerarea dublării atributelor sau grupării (uniunii) relaţiilor Există situaţii în care se dublează anumite atribute sau se grupează relaţii pentru a reduce numărul de uniuni necesare pentru efectuarea unei interogări. Nr_Tel. Nr_Fax) se descompune în două relaţii: Filiala (Nr_Fil. CodP.

adică o grupare/uniune de tabele (vezi figura de mai jos). împreună cu numărul de personal şi numele angajatului responsabil pentru administrarea proprietăţii respective. în tabelul „Proprietate_de_Închiriat” se introduce o redundanţă controlată. 78 . pentru a include numele angajatului (din tabelul „Personal”) în rezultatul interogării. anume câmpul „Nume” (care există şi în tabelul „Personal”). oraşul.Totuşi se întâmplă rar să dorim să accesăm adresa filialei fără atributele corespunzătoare zonei şi oraşului. ori de câte ori dorim adresa completă a filialei. Păstrând atributele oraşului într-o relaţie separată înseamnă că. Pentru a evita rularea interogării de fiecare dată (necesitatea realizării uniunii între cele 2 tabele). deşi conţine date redundante. Ca urmare se optează pentru o denormalizare şi se păstrează prima variantă a relaţiei. Se realizează o interogare pe tabele multiple. trebuie de efectuat uniunea celor 2 relaţii. Exemplu: Tranzacţia F: a se enumera pentru fiecare proprietate numărul proprietăţii. strada.

Prenume. Proiectarea mecanismelor de securitate Măsurile de securitate pentru baza de date trebuie să corespundă cerinţelor utilizatorilor. Nume. formular cu care lucrează supervizorul. Nr_Filiala) Cheie primară: Nr_Personal Cheie străină: Nr_Filiala. Pasul 5. Nr_Filiala) Cheie primară: Nr_Personal Cheie străină: Nr_Filiala.3 Pasul 6. Nume. Vederea supervizorului. 79 .Pentru a garanta coerenţa în continuare a BD. Pasul 6.8. In timp ce managerul organizaţiei vede relaţia de bază. se referă la relaţia. Adresa. cu excepţia câmpului „Salariu”. Modelul de date logic trebuie reactualizat. adică răspunsul la interogarea selectivă. astfel încât să reflecte orice modificări apărute prin denormalizare. Functia. Deci supervizorul are dreptul la reactualizări asupra tabelului de bază Personal. Exemplu: Se doresc detalii referitoare la personalul agenţiei imobiliare. MS-Access va scrie reactualizările în tabelul sau tabelele de bază care au fost interogate. 1. utilizând interogarea selectivă QBE. Telefon. Pasul 5. respectiv formular corespunzător interogării.1 Proiectarea vederilor utilizatorilor În baza modelelor de date logice local se proiectează vederile utilizatorilor. Functia. Salariu. se referă la relaţia.5 Estimarea necesarului de spaţiu pe disc Este obligatorie pentru stabilirea performanţelor hardware cerute pentru implementarea bazei de date. Aceasta este o vedere pentru un utilizator cu permisiune de acces la date limitată.3 Documentarea introducerii redundanţei Orice redundanţă introdusă ulterior se documentează şi se motivează. tabelul „Filiala” (cu cheia primară Nr_Filiala). care se bazează pe limbajul de interogare structurată SQL (Structured Query Language). Adresa. Telefon. Sex. Figurile de mai jos arată vizualizarea de proiectare (Design View) a interogării selective QBE (Query By Example) şi formularul realizat în baza interogării. vizibile pentru supervizorul organizaţiei. Prenume. Vederile se creează în MSAccess prin interogări QBE. Sex.4. se poate edita (reactualiza). se proiectează şi se implementează un program de aplicaţie prin care orice modificare în câmpul „Nume” în tabelul părinte „Personal” să se transmită în câmpul „Nume” din tabelul copil „Proprietate_de_Închiriat”. completă: Personal (Nr_Personal. dar fără informaţii referitoare la salarii. tabelul „Filiala” (cu cheia primară Nr_Filiala). În urma interogării selective QBE (implicit cu SQL) se generează vederea: Personal_VedereSupervizor (Nr_Personal. Se determină astfel dacă pe moment sau în viitor este necesare achiziţionarea de hardware mai performant.

2 Proiectarea regulilor de acces De regulă utilizatorii nu au acces la relaţiile de bază. Instrucţiuni pentru acordarea privilegiilor: SELECT: privilegiul de a regăsi date dintr-o relaţie Când utilizatorul creează o relaţie folosind instrucţiunea Create Table din limbajul SQL. Identificatorul de autorizaţie determină la ce obiecte din BD se poate referi utilizatorul şi ce operaţii poate efectua asupra acestor obiecte. Administratorul de BD atribuie fiecărui utilizator un identificator de autorizaţie care are asociată o parolă.Pasul 6. Privilegiile sunt acţiunile pe care un utilizator are voie să le efectueze asupra unei relaţii de bază sau vederi. utilizatorul de vine automat proprietarul noii relaţii cu privilegii complete GRANT: se acordă privilegii altor utilizatori asupra relaţiei nou create 80 . Fiecare obiect creat în SQL are un proprietar identificat prin identificatorul de autorizaţie. ci numai la vederile create pentru ei. Proprietarul este singurul care cunoaşte existenţa obiectului respectiv şi deci poate efectua operaţii asupra lui. Fiecare instrucţiune SQL executată de către SGBD este efectuată în numele unui anumit utilizator.

se utilizează următoarea instrucţiune SQL: GRANT ALL PRIVILEGES ON personal TO manager WITH GRANT OPTION.. 81 . În cadrul fişierului de informaţii al grupului de lucru (Workgroup Administrator) utilizatorii sunt identificaţi ca membri ai unui grup. formulare etc.stabilirea unei parole a BD (pentru deschiderea BD) . Figura de mai jos ilustrează caseta de dialog pentru definirea grupurilor şi conturilor de utilizator. interogări.) sunt puse la dispoziţia utilizatorului. toate obiectele (tabele. Stabilirea unei parole Figura de mai jos arată caseta de dialog care solicită introducerea parolei pentru deschiderea bazei de date. să reactualizeze şi să şteargă date din aceasta. să transmită privilegii utilizatori. Utilizatorului i se cere să se identifice şi să scrie o parolă atunci când porneşte MS-Access. Securitatea la nivel de utilizator Securitatea la nivel de utilizator este similară metodelor utilizate în majoritatea sistemelor (softurilor) de reţele. dar nu neapărat cu privilegii complete. cu următoarea instrucţiune SQL: GRANT SELECT ON personal TO admin MS-Access oferă două metode tradiţionale de securizare a BD: . Access defineşte automat grupurile Admin şi Users. dar pot fi definite şi alte grupuri. O dată deschisă BD.securitatea la nivel de utilizator (se limitează segmentele din BD care pot fi citite sau reactualizate la nivel de utilizator). (ca la SELECT) Exemplu: pentru ca utilizatorul manager să regăsească rânduri din relaţia Personal şi să insereze. Exemplu: Utilizatorului cu identificatorul de autorizaţie ADMIN i se acordă privilegiul SELECT pentru relaţia Personal.REVOKE: revocă privilegii CREATE VIEW: utilizatorul care creează vederea devine automat proprietarul acesteia.

care au implicit toate drepturile grupului din care fac parte. Se reglementează modul în care se lucrează cu fiecare obiect din BD.Figura de mai jos ilustrează caseta de dialog pentru acordarea permisiunilor de utilizator şi de grup. astfel încât să fie mai multe sau mai puţine faţă de grup. 82 . Un control mai fin se realizează prin definirea de grupuri (conturi de grup) noi. dar ale căror drepturi pot fi modificate individual. cărora li se acordă anumite permisiuni (de grup). Apoi se adaugă utilizatorii care fac parte din acest grup.

pentru a corecta deciziile inadecvate de proiectare sau pentru a reflecta cerinţele în schimbare. sau atunci când sistemul nu este complet utilizat (în afara orelor de lucru). Obiectele OLE pot fi legate de sau înglobate într-un câmp dintr-un tabel sau formular în Access şi pot fi afişate. atunci şi aceste diagrame trebuie reactualizate. cu tip de date Memo. Este de dorit să se verifice/testeze întâi modificarea pe o bază de date de încercare. împreună cu comentariile care descriu principalele caracteristici ale acesteia.8. Figura de mai jos ilustrează un formular care cuprinde cele două câmpuri noi.4 Pasul 7. transferul devine mai eficient . În MS-Access se introduc câmpuri cu tip de date (data type): OLE (Object Linking and Embedded = legarea şi înglobarea de obiecte). Calea către imaginea/imaginile stocate pe hard disk se specifică în design view al formularului (sau raportului sau paginii de acces) creat după tabel. Monitorizarea şi reglarea sistemului operaţional Obiectiv: Monitorizarea sistemului operaţional şi îmbunătăţirea performanţelor acestuia.Pasul 6.ca urmare cresc productivitatea întreprinderii.se poate micşora configuraţia hard . figuri. moralul angajaţilor şi satisfacţia clienţilor. sunete sau alte tipuri de date binare create în alte programe. 83 . Reglarea din mers a bazei de date de către administratorul BD prezintă anumite avantaje: . Presupunem că după câteva luni de utilizare a BD complet operaţionale a agenţiei imobiliare au apărut din partea mai multor utilizatori ai sistemului două noi cerinţe: (1) Capacitatea de a păstra fotografii ale proprietăţilor de închiriat.se evită necesitatea procurării de hardware adiţional . capabil de a cuprinde un text mai lung.3 Documentarea proiectului măsurilor de securitate şi vederilor utilizatorilor Proiectarea vederilor individuale şi mecanismele de securitate trebuie complet documentate. Tabelul Proprietate_de_Închiriat se va restructura astfel încât să cuprindă un câmp numit „Vedere” cu tip de date OLE. Orice modificare de reglare poate în acelaşi timp îmbunătăţi o aplicaţie şi strica alta. Dacă proiectul fizic afectează modelele de date logice individuale. Acestea permit stocarea de date cum ar fi documente MS-Word sau MSExcel.timpul de răspuns scade. 1. formular bazat pe tabelul Proprietate_de_Închiriat. şi un câmp numit „Comentarii”.

8. 84 . după care în baza acestui raport se realizează Pagina de acces la date. Proiectarea fizică a bazei de date reprezintă procesul de realizare a descrierii implementării acesteia în capacitatea de stocare secundară. Etapa iniţială (pasul 4) constă în transpunerea modelului de date logic global într-o formă care să poată fi implementată în SGBD relaţional ţintă. Denormalizarea este o opţiune atunci când performanţele sistemului nu sunt satisfăcătoare şi o relaţie are o rată de reactualizare scăzută şi o rată de interogare foarte ridicată. Această cerinţă se satisface prin crearea întâi a unui raport adecvat. Pentru ca pagina de acces la date creată să fie activată.8. introducerea de redundanţă controlată şi estimarea spaţiului necesar pe disc. Indexurile secundare furnizează un mecanism de specificare a unei chei suplimentare pentru o relaţie de bază. pentru regăsirea mai eficientă a datelor. 1. care să conţină câmpurile dorite pentru a fi vizualizate în Internet. Etapa finală (pasul 7) din proiectarea fizică a BD constă în monitorizarea şi reglarea neîntrerupte ale sistemului operaţional pentru maximizarea performanţelor. alegerea organizării adecvate a fişierelor. scrise în limbajul SQL. Următoarea etapă (pasul 5): proiectarea organizării fişierelor şi metodelor de acces care vor fi utilizate pentru stocarea relaţiilor de bază. adăugarea de indexuri secundare.(2) Capacitatea de a publica un raport care să disponibilizeze în Internet proprietăţile de închiriat disponibile.5 Rezumatul capitolului 1. Baza de date trebuie prevăzută cu un mecanism de securitate (pasul 6). Ele se realizează prin crearea de vederi pentru utilizatori şi utilizarea de mecanisme de control al accesului. Aceasta presupune analizarea tranzacţiilor. Măsurile de securitate necesare se identifică pe parcursul proiectării logice. este necesară legătura la Internet şi un browser adecvat.

6. Întrebări la capitolul 1. logică şi fizică a bazelor de date.8 • • • Explicaţie diferenţa dintre proiectarea conceptuală. Descrieţi scopul principalelor etape din metodologia de proiectare fizică a bazelor de date.1. În ce condiţii se justifică denormalizarea unui model de date logic? Utilizaţi exemple. 85 .8.

Sign up to vote on this title
UsefulNot useful