Universitatea Transilvania din Braov Facultatea de Inginerie tehnologic Catedra de Inginerie economic i sisteme de producie

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)

Braov 2006
1

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 fiiere..........................................................................................................................................................5 1.1.1 Introducere.....................................................................................................................................5 1.1.2 Tratarea datelor prin sisteme bazate pe fiiere ..............................................................................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 Poziiile persoanelor din mediul BD............................................................................................10 1.1.8 Avantajele i dezavantajele SGBD..............................................................................................11 1.1.8 Rezumatul capitolului 1.1 ...........................................................................................................13 1.1.9 ntrebri la capitolul 1.1...............................................................................................................13 1.2. Modelul relaional (SGBDR).............................................................................................................14 1.2.1 Terminologie................................................................................................................................14 1.2.2 Integritatea relaional.................................................................................................................16 1.2.3 Vederi...........................................................................................................................................17 1.2.4 Rezumatul capitolului 1.2............................................................................................................18 1.2.5 ntrebri la capitolul 1.2...............................................................................................................19 1.3 Planificarea, proiectarea i administrarea BD.....................................................................................19 1.3.1 Ciclul de via al sistemelor informaionale................................................................................19 1.3.2 Fazele proiectrii BD...................................................................................................................21 1.3.3 Proiectarea aplicaiilor.................................................................................................................22 1.3.4 Administrarea datelor i a bazei de date......................................................................................23 1.3.5 Rezumatul capitolului 1.3............................................................................................................24 1.3.6 ntrebri la capitolul 1.3...............................................................................................................25 1.4. Modelarea Entitate-Relaie (ER).......................................................................................................25 1.4.1 Conceptele modelului ER............................................................................................................25 1.4.2 Constrngeri structurale...............................................................................................................31 1.4.3 Problemele modelului ER............................................................................................................35 1.4.4 Rezumatul capitolului 1.4............................................................................................................38 1.4.5 ntrebri la capitolul 1.4...............................................................................................................39 1.5 Normalizarea.......................................................................................................................................39 1.5.1 Scopul normalizrii......................................................................................................................39 1.5.2 Redundana datelor i anomaliile de reactualizare......................................................................39 1.5.3 Dependene funcionale...............................................................................................................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 ntrebri 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 ntrebri la capitolul 1.6...............................................................................................................54 1.7 Metodologia de proiectare logic a bazelor de date pentru modelul relaional..................................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 ntrebri la capitolul 1.7...............................................................................................................66 1.8 Metodologia de proiectare fizic a bazelor de date pentru bazele de date relaionale........................66 1.8.1 Pasul 4. Transformarea modelului de date logic global pentru un SGBD int...........................66 1.8.2 Pasul 5. Proiectarea reprezentrii fizice.......................................................................................71 1.8.3 Pasul 6. Proiectarea mecanismelor de securitate.........................................................................79 1.8.4 Pasul 7. Monitorizarea i reglarea sistemului operaional...........................................................83 1.8.5 Rezumatul capitolului 1.8............................................................................................................84 1.8.6. ntrebri la capitolul 1.8..............................................................................................................85

1. Baze de date. Proiectare. Implementare. Gestionare

Obiectivele acestui modul sunt: - Cunoaterea noiunilor de baz privind sistemele informatice de gestionare a bazelor de date relaionale; - Planificarea, proiectarea i administrarea bazelor de date;

1.1 Introducere n BD. Tratarea datelor. Sisteme de gestionare a bazelor de date. Sisteme bazate pe fiiere
1.1.1 Introducere Cu siguran cei mai muli dintre Dvs. au o idee despre ce ar putea fi o baz de date (BD). Bazele de date au aprut ca rspuns la nevoia organizaiilor (instituii, ntreprinderi, societi comerciale etc.) de a eficientiza evidena activitii lor, din toate punctele de vedere: producie, stocuri, aprovizionare, contabilitate, resurse umane, vnzri etc. Vedem BD n viaa de zi cu zi listele de ofert ale diferiilor furnizori de cri, CD-uri, cartea de telefon, piesele n stoc de furnizat pentru un anumit proiect, fie sau nregistrri de prelucrat de un anumit program etc. Exprimndu-ne mai precis, atunci cnd utilizm termenul de baz de date ne referim la o colecie structurat de articole de date, ntre care exist legturi logice. O astfel de colecie, o BD, a fost construit pentru a servi pentru o anume aplicaie, reprezentnd o lume n miniatur. Articolele dintr-o BD se manipuleaz, pentru a extrage informaiile utile. Un sistem de gestionare de baz de date (SGBD), sau database management system (DBMS) este softul care permite ca bazele de date s fie definite/configurate, construite i exploatate/manipulate. Obiectul cursului nostru este SGBDR, sistemul de gestionare de baze de date relaionale, cu aplicaii n MS-Access. Modelul relaional de BD Exist trei modele uzuale de implementare de BD: ierarhic, reea sau relaional. Fiecare se bazeaz pe conceptul de date stocate ca set sau mulime de nregistrri. Imaginai-v un set de fie, de exemplu. Modelele ierarhic i reea se bazeaz pe parcurgerea legturilor dintre date pentru a lucra cu baza de date; de regul sunt utilizate pentru sisteme-cadru generale, vaste i nu fac obiectul cursului nostru. Sistemele de gestionare a bazelor de date relaionale (SGBDR) au cunoscut o larg rspndire, datorit modelului simplu, relaional de date pe care-l utilizeaz: Datele se prezint sub forma unei colecii (unui set) de relaii Fiecare relaie are forma unui tabel (cea mai important component a unei BD) Rndurile (nregistrrile) tabelului reprezint entiti Coloanele (cmpurile) tabelului sunt atribute/proprieti ale acestor entiti Fiecare tabel are un set de atribute, care mpreun reprezint o cheie care definete fiecare entitate n mod unic. De exemplu, o societate poate avea n baza sa de date un tabel cu angajaii si, cu un rnd/nregistrare pentru fiecare angajat. Ce atribute ar fi de interes? Depinde de sigur de scopul pentru care a fost creat tabelul, i atributele sunt stabilite la momentul configurrii bazei de date. Ca exemplu aplicaia poate fi un
5

tat de plat, deci va fi nevoie, n afar de nume, cod angajat i de informaii referitoare la adres i salariu. 1.1.2 Tratarea datelor prin sisteme bazate pe fiiere Superioritatea administrrii datelor dintr-o organizaie cu ajutorul unui sistem de gestionare de baze de date (SGBD) rezult dintr-o scurt comparaie ntre sistemele tradiionale de date, bazate pe fiiere i sistemele de gestionare a bazelor de date (SGBD) Sistemul bazat pe fiiere este o colecie de programe de aplicaie care efectueaz servicii pentru utilizatorii finali, cum ar fi producerea de rapoarte. Fiecare program definete i gestioneaz propriile date. Exemplu: o firm care furnizeaz componente pentru diferite proiecte/clieni. Compartimentul magazie (al firmei) va ine fiiere cu: - componentele n stoc, pe fia fiecrei componente aprnd denumirea, seria, costul, nr. buci etc. Compartimentul contabilitate (al firmei) va ine fiiere cu: - componentele n stoc, documentele de achiziie, intrare, denumirea, seria, costul, nr. buci etc. - ieirile de componente, cu caracteristicile i cantitile de componente, documentaie nsoitoare de ieire (inclusiv numele proiectelor/clienilor ctre care se furnizeaz) Compartimentul vnzri (al firmei) va ine fiiere cu: - numele proiectelor ctre care se livreaz, inclusiv nume clieni, numr contract, tipuri de componente livrate - cerinele clienilor, cu detalierea componentelor necesitate, inclusiv descrierea componentelor, gradul de urgen i prioritate etc. Rezult urmtoarele limitri ale sistemelor bazate pe fiiere: Separarea i izolarea datelor. Atunci cnd datele sunt izolate n fiiere separate, cele care ar trebui s fie disponibile sunt mai greu de accesat. De exemplu dac vrem s aflm care componente pn la o anumit limit de pre i n ce cantitate se afl n stoc pentru un anumit proiect, va trebui sa extragem date din fiierul cu proiecte i apoi din cel cu stocuri (fiiere existnd la compartimente diferite), va trebui s crem un fiier temporar care s cuprind toate aceste date. Extragerea corect de date este dificil, necesitnd sincronizarea prelucrrii (n compartimente diferite) a dou sau mai multe fiiere. Dublarea datelor. Din cauza modului de abordare descentralizat, specific fiecrui compartiment, tratarea datelor pe baz de fiiere a dus la dublarea necontrolat a datelor. Observm n exemplul nostru, c mai multe compartimente au introdus aceleai date n fiierele lor. Dublarea datelor este de nedorit din urmtoarele cauze: o Risip: introducerea datelor de mai multe ori cost timp i bani, ocup spaiu suplimentar de stocare, deci alte costuri; o Alterarea integritii datelor, prin dublare, deci datele nu mai concord. De exemplu, dac intrarea unor componente cu pre nou nu este comunicat de ctre compartimentul contabilitate celor de la magazie, aceleai componente vor aprea n fiierele diferitelor compartimente cu pre diferit. Dependena de date. Dac este necesar de modificat structura unui fiier (de ex. mrimea unui cmp), atunci trebuie de identificat toate programele care lucreaz cu acest fiier, pentru a opera
6

modificrile respective n fiecare dintre ele. Aceast caracteristic a sistemelor bazate pe fiiere se numete dependen program-date. Incompatibilitatea fiierelor. Este posibil ca fiecare compartiment s-i genereze fiiere n alt limbaj de programare; structura fiierelor va fi dependent de limbajul n care este scris programul. De exemplu, dac compartimentul vnzri vrea s afle detaliile legate de stocul existent pentru o anume component, va ncerca s acceseze fiierul corespunztor al compartimentului magazie, plecnd de la cmpul denumire componente existent n fiierele ambelor compartimente; dac fiierele sunt generate cu limbaje diferite, va trebui s intervin un programator care s scrie un program de transformare a fiierelor ntr-un format comun. Interogarea fix sau proliferarea programelor de aplicaie. Tratarea datelor prin sisteme de fiiere a reprezentat un progres semnificativ fa de sistemele manuale. Au crescut cererile de interogri noi sau modificate, care necesitau de fiecare dat intervenia programatorului, care trebuia s scrie interogrile. Astfel au aprut dou situaii. Pentru a limita volumul de lucru al programatorilor, s-a ajuns la fixarea numrului de interogri disponibile. Pentru a satisface numrul crescnd de cereri de interogri, a proliferat numrul de aplicaii; au rezultat programe ineficiente, scrise n grab, cu documentaie limitat i dificil de ntreinut. Accesul la fiiere este limitat la un singur utilizator o dat, deci nu exista partajarea accesului pentru mai muli utilizatori din acelai compartiment.

Limitrile tratrii datelor bazat pe fiiere au dou cauze: (1) definiia datelor este ncorporat n programele de aplicaie, n loc de a fi stocat independent; (2) nu exist control asupra accesului i manipulrii datelor dincolo de cel impus de programele de aplicaie. Ca urmare a aprut o nou tratare a datelor, prin baze de date (BD), gestionate de sisteme de gestionare a bazelor de date (SGBD).

1.1.3 Tratarea datelor prin baze de date (BD) Baza de date este o colecie partajat de date ntre care exist relaii logice (i o descriere a acestor date), proiectat pentru a satisface necesitile informaionale ale unei organizaii. Baza de date nu mai este deinut de un singur compartiment al unei organizaii, ci este o resurs comun, partajat. Datele sunt integrate, cu o dublare minim. BD conine datele operaionale ale organizaiei i descrierea acestora. O baz de date este deci o colecie autodescris de nregistrri integrate. Aceast caracteristic BD este cunoscut i ca independena program - date. O BD relaional conine entitile, atributele i relaiile logice dintre acestea, reprezentate printr-o diagram entitate relaie (ER). Vom reveni n detaliu asupra modelului ER de BD. 1.1.4 Sistemul de gestionare a bazei de date (SGBD)

SGBD este un sistem de programe care permite utilizatorului definirea, crearea i ntreinerea bazei de date i accesul controlat la aceasta. SGBD const n elemente de software care interacioneaz cu programele de aplicaie ale utilizatorului pe de o parte i cu baza de date pe cealalt. Un SGBD ofer o serie de faciliti: - permite definirea BD printr-un limbaj de definire a datelor (DDL) - permite inserarea, reactualizarea, tergerea i extragerea de date printr-un limbaj de manipulare a datelor (DML). BD fiind un depozit unic i central de date i descrieri de date, DML poate oferi o interogare general a acestor date, numit limbaj de interogare. Un astfel de limbaj de interogare este SQL, care elimin utilizarea unui set fix de interogri disponibile, ca n cazul tratrii datelor prin sisteme de fiiere. - Ofer accesul controlat la BD. Astfel SGBD poate furniza: o Un sistem de securitate, pentru a mpiedica accesul utilizatorilor neautorizai o Un sistem de integritate, care menine concordana datelor stocate; o Un sistem de control al utilizrii simultane, care permite accesul partajat la BD; o Un sistem de control al refacerii, care restaureaz BD ntr-o stare precedent concordant, ca urmare a unei defeciuni hard sau soft; o Un catalog accesibil utilizatorilor, care conine descrieri ale datelor din BD - Ofer generarea de vederi/views numite i moduri de vizualizare a BD prin mecanismul de vizualizare. Astfel se vor afia numai acele date din BD care sunt utile utilizatorului, eliminnduse ncrcarea rezultatului unei interogri cu date existente n BD, dar care nu intereseaz utilizatorul. Modurile de vizualizare ofer i alte avantaje: o Un anumit nivel de securitate; se exclud date care nu trebuie vzute de anumii utilizatori; o O personalizare a aspectului BD. De exemplu redenumirea cmpurilor dup preferinele utilizatorului; o O imagine coerent, neschimbat a structurii BD, chiar dac BD nsi este modificat; prin modul de vizualizare se va afia n continuare structura prestabilit a BD.

1.1.5 Componentele mediului SGBD Mediul SGBD are cinci componente principale: -- Date -Hardware Main Software -Punte -- Proceduri Om Persoane

Hardware Evident, pentru a funciona, SGBD au nevoie de elemente hardware, care pot fi un singur PC pn la o reea. Un SGBD poate necesita un anumit tip de elemente hardware sau de sistem de operare, sau poate funciona pe o diversitate de elemente hardware i platforme; Access 2000 este de ex. un SGBD relaionale pe 32 bii, pentru crearea de aplicaii clasice sau de tip client-server pentru BD, pentru sistemele de operare Windows 9x i Windows NT 4+; de asemenea, un SGBD necesit un minimum de memorie (MS-a: size: 2,32 KB) i spaiu de disc (MS-Access: size on disk: 4 KB).
8

O configuraie / arhitectur client-server este prezentat n figura 1.1, pentru o organizaie cu patru filiale legate ntr-o reea de PCuri, deservite de un server central. Pe server se afl programele back-end, adic partea din SGBD care administreaz i controleaz accesul la BD. Pe calculatoarele din diversele locaii/PC clieni se afl aplicaiile front-end, adic partea din SGBD care constituie interfaa cu utilizatorul. Fig. 1.1 Software Componenta soft cuprinde programele SGBD i programele de aplicaie mpreun cu sistemele de operare, inclusiv software de reea, dac este cazul. Programele aplicaie sunt scrise ntr-un limbaj de programare din generaia a treia (C, Cobol, Fortran) sau de generaia a patra SQL, incorporat ntr-un limbaj de generaia a treia. SGBD poate avea propriile instrumente de generaia a patra, care permit dezvoltarea rapid de aplicaii prin furnizarea unui limbaj de interogare i a unor generatoare de rapoarte, formulare, grafic etc. Instrumentele de generaia a patra mbuntesc productivitatea i permit realizarea unor programe uor de ntreinut. Datele Datele reprezint cea mai important component a unui SGBD, d.p.d.v. al utilizatorului; datele = punte ntre componentele main i cele umane. BD conine: - Date operaionale - Meta-date, adic date despre date. Structura BD este numit schem i are mai multe tabele sau fiiere, fiecare avnd mai multe atribute (cmpuri). Procedurile Procedurile se refer la instruciunile i regulile care guverneaz proiectarea i utilizarea BD. Procedurile sunt necesare att administratorilor, ct i utilizatorilor de BD i pot cuprinde instruciuni referitoare la ; - deschiderea unei sesiuni de lucru n SGBD; - utilizarea unei anumite faciliti a SGBD sau a unui program aplicaie; - pornirea i oprirea SGBD; - efectuarea de copii de siguran a BD ; - tratarea defeciunilor hard sau soft; - modificarea structurii unui tabel, reorganizarea BD pe mai multe discuri, arhivarea datelor etc. Persoanele
9

Sunt ultima component a unui mediu SGBD i va fi discutat la paragraful Poziiile persoanelor din mediul SGBD. 1.1.6 Proiectarea BD schimbarea de paradigm Structura unei BD (entitile, atributele, relaiile) este determinat n timpul proiectrii BD. Abordarea proiectrii unei BD este diferit de cea a sistemelor pe baz de fiiere, unde totul era dictat de nevoile aplicative ale departamentelor individuale. n cazul BD trebuie de considerat nti datele apoi aplicaiile. Aceast schimbare a modului de tratare se numete schimbare de paradigm. Cauza principal a eecurilor sistemelor informaionale este lipsa aplicrii unei metodologii de proiectare a BD n mod structurat. Astfel rezult BD ineficiente pentru cerinele aplicaiilor, documentaia este limitat, ntreinerea dificil. 1.1.7 Poziiile persoanelor din mediul BD In acest paragraf se examineaz a 5-a component a mediului SGBD, anume persoanele. Se pot identifica patru tipuri distincte de persoane implicate n mediul SGBD: - administratorii de date i de BD; - proiectanii de BD; - programatorii de aplicaii; - utilizatorii finali. Administratorii de date i de BD BD i SGBD sunt resurse comune care trebuie gestionate ca orice resurs. Sarcinile administratorului de date (DA = data administrator): - responsabil cu gestionarea resurselor de date: planificarea, elaborarea i ntreinerea strategiilor i procedurilor bazei de date - responsabil cu proiectarea conceptual/logic a BD - consultarea i ndrumarea managerilor superiori cu privire la direcia de dezvoltare a BD, a. BD s sprijine obiectivele generale ale organizaiei. Administratorul de baze de date (DBA data base administrator) este responsabil cu realizarea fizic a BD, avnd urmtoarele sarcini: - proiectarea i implementarea BD, - securitatea i controlul integritii BD, - ntreinerea sistemului operaional, - asigurarea de performane satisfctoare pentru aplicaii i utilizatori; Rolul DBA este mai tehnic i necesit cunoaterea n detaliu a SGBD i a mediului acestuia. Proiectanii de BD Exist proiectani de BD logice i proiectani de BD fizice. Proiectanii de BD logice: ce anume?
10

se ocup cu identificarea datelor (entiti i atribute) i relaiilor dintre acestea, i de constrngerile asupra celor care vor fi stocate n BD; trebuie s cunoasc foarte bine datele organizaiei i a regulilor de operare ale organizaiei; trebuie s implice toi posibilii utilizatori ai BD n modelul creat.

Etape de proiectare a BD logice: a) proiectarea conceptual a BD, independent de detaliile de implementare (de ex. SGBD utilizat, programele de aplicaie, limbajele de programare etc.) b) proiectarea logic a BD, care se bazeaz pe un anumit model, de ex. relaional, ierarhic, n reea, orientat pe obiecte. Proiectanii de BD fizice (Cum anume?) preia modelul logic i stabilete realizarea fizic: - transpunerea modelului logic de date ntr-un set de tabele i constrngeri privind integritatea; - selectarea de structuri de stocare i metode de acces specifice, a.. s se obin performane bune ale datelor in activitile legate de BD; - msuri referitoare la securitatea datelor. Proiectarea fizic a unei BD trebuie s in cont de SGBDul avut n vedere; proiectantul trebuie s cunoasc funcionalitatea acestui SGBD i avantajele i dezavantajele fiecrei variante de implementare a BD. Strategia de stocare aleas trebuie s in cont de modul de utilizare. Programatorii de aplicaii Odat realizat BD trebuie implementate programele de aplicaie ce confer funcionalitatea cerut de utilizatorii finali. Aceasta este sarcina programatorilor de aplicaii. Fiecare program conine instruciuni care i cere SGBD s efectueze o operaie oarecare n BD (extragere, inserare, reactualizare, tergere de date). Programele pot fi scrise ntr-un limbaj de generaia a treia sau a patra. Utilizatorii finali Sunt clienii pentru care a fost proiectat, implementat i este ntreinut BD, pentru a le satisface necesitile informaionale. Utilizatorii simpli nu sunt contieni de SGBD. Acceseaz BD prin programe de aplicaie speciale, simplificatoare. Ei folosesc comenzi simple, opiuni din meniu. Utilizatorul simplu nu tie nimic despre BD sau SGBD (de ex. vnztorul care citete codul de bare pentru a afla preul unui produs. Exist totui un program care citete codul de bare, caut preul articolului respectiv n BD, modific cmpul cu stocul de articole, afieaz preul la cas). Utilizatorii sofisticai sunt familiarizai cu structura BD i facilitile SGBD. Pot utiliza un limbaj de interogare de nivel nalt (SQL). Pot scrie programe de aplicaie pentru uz personal. 1.1.8 Avantajele i dezavantajele SGBD Avantaje - Controlul redundanei datelor; nu se elimin n ntregime redundana, ci se controleaz volumul inerent al acesteia n BD.
11

Coerena datelor; datorit eliminrii redundanei, orice reactualizare a unui articol (stocat o singur dat) se face o singur dat, eliminndu-se incoerena. Dac articolul este stocat de mai multe ori, SGBD garanteaz coerena tuturor exemplarelor din articolul respectiv. Mai multe informaii obinute de la aceeai cantitate de date; ca urmare a integrrii datelor operaionale, dou sau mai multe fiiere pot fi integrate, extrgndu-se mai multe informaii. Partajarea datelor; fiierele sunt deinute de compartimentele organizaiei care le utilizeaz, dar fiind parte din BD, ele sunt la dispoziia tuturor utilizatorilor interesai. Integritatea crescut a datelor; se refer la validitatea i coerena datelor stocate. Integritatea este exprimat prin constrngeri, care reprezint reguli de coeren pe care BD nu are voie s le ncalce. Securitatea crescut; se refer la protecia BD fa de utilizatorii neautorizai. Fr sisteme de securitate, integrarea ar face datele foarte vulnerabile. Securitatea se realizeaz prin nume de utilizatori plus parole. Se poate limita tipul de operaie efectuat. Aplicarea standardelor; prin integrare se pot aplica standarde organizaionale, naionale sau internaionale, ca de ex. formatul datelor, convenii referitoare la denumire, pt. a facilita schimburi ntre sisteme. Economia de scal; n loc de bugete pentru fiecare compartiment pentru crearea unui sistem propriu de BD bazat pe fiiere, exist un buget unic combinat, care permite alocarea fondurilor economisite pentru mbuntirea sistemului. Echilibrul ntre cerinele aflate n conflict; cerinele posibil n conflict ale diferitelor compartimente referitoare la utilizarea BD sunt gestionate la nivel de DBA, care va lua deciziile ce se impun i va acorda prioritate aplicaiilor majore. mbuntirea accesibilitii datelor i capacitii de rspuns; limbajele de interogare i generatoare de rapoarte asociate SGBD ofer utilizatorilor posibilitatea unor interogri ad-hoc, fr a apela la programator. Productivitatea crescut; SGBD furnizeaz standardele necesare aplicaiei, economisind timpul programatorului. Capacitatea de ntreinere mbuntit, prin independena de date; ntr-un SGBD descrierile datelor sunt separate de aplicaii, aplicaiile fiind imune la modificarea descrierii datelor; este caracteristica de independen program-date, care uureaz ntreinerea aplicaiilor din BD. Concurena/simultaneitatea mbuntit; se garanteaz alterarea datelor n situaia cnd acelai fiier este utilizat simultan de mai muli utilizatori. mbuntirea serviciilor de salvare de siguran i refacere. Se minimizeaz pierderile aprute ca urmare a unor defeciuni. Nu este necesar realizarea zilnic de copii de siguran.

Dezavantaje - Complexitatea; pt. ca un SGBD s fie funcional, acesta va evolua ntr-un sistem soft extrem de complex. Funcionalitatea trebuie cunoscut de ctre toi cei implicai n BD, de la DA la utilizatorul final, pentru a o putea exploata. Dac SGBD este greit neles, BD proiectat poate fi greit, cu toate consecinele acestei situaii. - Dimensiunea; Fiind un element soft foarte complicat, SGBD ocup mult spaiu pe disc i necesit mult memorie pentru a funciona eficient. - Costul SGBD; variaz n funcie de mediu i funcionalitate. De la 150 USD pt. un PC cu un utilizator, la 750.000 USD pt. un sistem mainframe cu sute de utilizatori. Se adaug cheltuieli periodice anuale de ntreinere. - Costurile adiionale pentru elemente hardware; pentru a sigura performanele SGBD poate fi nevoie de achiziionarea unui calculator mai mare, chiar dedicat rulrii SGBD, cu disc i memorie mai mari.
12

Costul conversiei; la implementarea unui nou sistem SGBD i/sau a unei noi configuraii hard, conversia poate costa semnificativ mai mult dect noile elemente hard. Se include costul instruirii personalului, angajarea de personal specializat. Apare termenul de sistem motenit, adic un sistem mai vechi, inferior, de care organizaia se cramponeaz din motive de costuri de conversie. Performana; SGBD (spre deosebire de cel bazat pe fiiere) este general, creat pentru a permite diverse aplicaii; astfel unele pot funciona mai puin rapid dect n cazul sistemului bazat pe fiiere, creat pentru o anume aplicaie. Impactul crescut al unei defeciuni. Centralizarea (partajarea) resurselor crete vulnerabilitatea SGBD. Eecul oricrei componente poate duce la sistarea tuturor operaiilor.

1.1.8 Rezumatul capitolului 1.1 Sistemul de gestionare a bazelor de date (SGBD) reprezint cadrul de baz pentru sistemele informaionale i a avut un impact fundamental asupra modului de operare al organizaiilor. Predecesorul SGBD a fost sistemul bazat pe fiiere. Acesta reprezint o serie de programe de aplicaie ce efectueaz servicii (de regul generarea de rapoarte) pentru utilizatorii finali. Fiecare program i definete i i gestioneaz propriile date. Acest sistem reprezint un mare progres fa de sistemele manuale de fiare i ndosariere, dar are i probleme semnificative cum ar fi redundana datelor i dependena program date. Tratarea datelor prin baze de date rezolv dificultile abordrii pe baz de fiiere. O baz de date reprezint un set partajat de date i descrierea acestora ntre care exist relaii logice. BD este proiectat pentru a satisface necesitile informaionale ale unei organizaii. Un SGBD este un sistem de elemente software, care permite utilizatorilor definirea, crearea i ntreinerea bazei de date i acre permite accesul controlat la aceasta. SGBD ofer un limbaj de definire a datelor (DDL), care permite utilizatorilor definirea BD, i un limbaj de manipulare a datelor (DML), care permite utilizatorilor inserarea, reactualizarea, tergerea i extragerea datelor din BD. Mediul SGBD const din elemente hardware (calculatorul), de software (sistemul SGBD, sistemul de operare i programele de aplicaie), date, proceduri i persoane. Persoanele includ administratorii de date i de baze de date, proiectanii de baze de date, programatorii de aplicaii i utilizatorii finali. Avantajele tratrii datelor prin BD includ: controlul redundanei datelor, coerena i partajarea datelor, mbuntirea securitii i integritii datelor. Dezavantajele includ: complexitate, pre, impact sczut al defeciunilor. 1.1.9 ntrebri la capitolul 1.1 Dai patru exemple de sisteme de baze de date (situaii n care activitatea unei organizaii ar avea beneficia de pe urma unei baze de date) Analizai termenii: date; baz de date; sistem de gestionare a bazelor de date; vederi. Analizai avantajele tratrii datelor prin sisteme bazate pe fiiere. Descriei principalele diferene ntre tratarea datelor prin baze de date fa de tratarea bazat pe fiiere. Descriei cele cinci componente ale mediului SGBD i analizai relaiile dintre acestea.
13

Analizai rolurile urmtoarelor categorii de personal n mediul SGBD: administrator de date; administrator de baze de date; proiectant de baze de date logice; proiectant de baze de date fizice; programator de aplicaii; utilizatori finali.

1.2. Modelul relaional (SGBDR)

n cadrul modelului relaional (ML) toate datele sunt structurate logic n cadrul unor relaii (tabele). Fiecare relaie are o anumit denumire (titlu tabel) i este format din anumite atribute (coloane) ale datelor. Fiecare tuplu (line) conine cte o valoare per atribut. 1.2.1 Terminologie 1.2.1.1 Structura relaional a datelor Relaie: o relaie este un tabel cu coloane i rnduri. Atribut: Un atribut este o coloan a unei relaii, cu o anumit denumire. Domeniu: Un domeniu este mulimea de valori permise pentru unul sau mai multe atribute. Pentru fiecare atribut se definete n mod central denumirea domeniului, sensul acestuia i domeniul de definiie. Ca urmare sistemul va evita operaiile incorecte semantic. (De ex. compararea unui numr de telefon cu nr. de cas, dei ambele sunt iruri de caractere; ns: nr. luni este legal de nmulit cu salariile, dei primele sunt caractere text, iar celelalte sunt valori monetare). Exemplu: Atribut (cap de coloan) Localitatea Nr tel Denumirea domeniului Localitatea Numere telefon Sensul Mulimea tuturor denumirilor de localiti din Romnia Mulimea tuturor numerelor de telefon din Romnia Domeniul de definiie Caracter: dimensiune 20 Caracter: dimensiune 14

Tuplu: Un tuplu este un rnd dintr-o relaie. Intensitatea unei relaii: structura tabelului, specificarea domeniilor i a altor restricii referitoare la valorile posibile. Intensitatea este de regul fix/fixat. Extensia (starea) unei relaii: tuplurile, care se modific n timp. Grad: Gradul unei relaii reprezint numrul de atribute pe care l conine. O relaie cu dou atribute, de exemplu, se numete binar. Cardinalitate: cardinalitatea unei relaii este numrul de tupluri coninute de aceasta. Baza de date relaional: Un set de relaii normalizate. O BDR const din relaii structurate adecvat. Termeni formali Relaie Tuplu Atribut 1.2.1.2 Relaii matematice
14

Alternativa 1 Tabel Rnd Coloan

Alternativa 2 Fiier nregistrare (Record) Cmp (Field)

Pentru a nelege sensul termenului de relaie revedem unele concepte matematice. Produsul cartezian: D1 x D2; D1 = {2, 4}; D2 = { 1, 3, 5}; D1 x D2 = {(2,1); (2,3); (2,5); (4,1); (4,3); (4,5)} Orice submulime a produsului cartezian este o relaie: de ex. R = {(2,1); (4,1)}, adic: R = {(x,y)| x D1, y D2 i y = 1} sau: S = {(x,y)| x D1, y D2 i x = 2y}, adic S ={(2,1)}

X Di n general scriem produsul cartezian a n mulimi ca fiind: i =1 Fiecare element al produsului cartezian va fi un n-tuplu, adic este format din n elemente, cte unul din fiecare mulime de la 1 la n. Orice submulime a acestui produs cartezian, adic orice mulime de n-tupluri reprezint o relaie a celor n mulimi (care formeaz produsul cartezian).
1.2.1.3 Relaii n bazele de date Schema de relaie: O denumire a relaiei, urmat de un set (mulime) de perechi formate din atribute i denumiri de domenii. Fie o relaie R cu atributele Ai cu domeniile corespunztoare Di, i=1,n. Relaia R va fi definit de schema de relaie S= {A1:D1, A2:D2, ..., An:Dn}. Fiecare nregistrare (tuplu) din acest tabel (relaie) va fi descris prin n coloane (atribute), va fi deci un ntuplu, fiecare atribut (Ai , i=1,n) lund o valoare (di , i=1,n) din domeniul corespunztor (Di , i=1,n). Deci di Di. Un n-tuplu al relaiei (o nregistrare din tabel) va avea deci forma: (A1:d1, A2:d2, , An:dn). Fiecare element din acest n-tuplu este format dintr-un atribut i valoarea lui. Relaia va fi deci o mulime (un set) de astfel de n-tupluri. Cnd relaia R se scrie sub form de tabel, atributele (Ai) vor fi capetele de coloane, iar tuplurile (ntuplurile) vor fi rndurile, de forma d1, d2, , dn. Astfel, o relaie din modelul relaional este o submulime al produsului cartezian al domeniilor atributelor. Tabelul este o reprezentare fizic a unei astfel de relaii. 1.2.1.4 Proprietile relaiilor - fiecare relaie are o denumire, diferit de toate celelalte denumiri de relaii; - fiecare celul a relaiei conine exact o valoare atomic (singular); este ilegal trecerea de mai multe valori ntr-o celul; - fiecare atribut are o denumire distinct; - toate valorile unui atribut aparin aceluiai domeniu; - ordinea atributelor nu are nici o importan; - fiecare tuplu este distinct; nu exist dubluri ale tuplurilor; - teoretic, ordinea tuplurilor nu are nici o importan (n practic poate afecta eficiena accesrii tuplurilor). Aceste proprieti rezult din proprietile relaiilor matematice:
15

din moment ce relaia este o mulime, ordinea elementelor nu are importan; deci ordinea tuplurilor nu are importan; ntr-o mulime nu se repet nici un element; deci nu exist tupluri duble.

1.2.1.5 Chei relaionale Trebuie s existe posibilitatea de identificare unic a unui tuplu dintr-o relaie, prin valorile atributelor sale. Supercheia: Este un atribut sau un set de atribute care identific n mod unic un tuplu din interiorul unei relaii. O supercheie poate conine i atribute care nu sunt necesare identificrii unice a tuplului. Cheia candidat: este o supercheie minim, pentru care nici o submulime nu este supercheie n cadrul relaiei respective. O cheie poate include mai multe atribute, caz n care se numete cheie combinat. O cheie candidat este unic (n fiecare tuplu al relaiei R, valorile cheii identific acel tuplu n mod unic) i ireductibil (nici o submulime a cheii candidat nu este unic). Cheia primar: este cheia candidat care este selectat [din toate cheile candidat identificate] pentru a identifica n mod unic tuplurile din cadrul unei relaii. Cheile candidat neselectate se numesc chei alternative. Cheie strin: Un atribut sau o mulime de atribute din cadrul unei relaii, care se potrivesc cu o cheie candidate din alt relaie. De exemplu o cheie strin dintr-o relaie poate (spunem c intete) coincide cu cheia primar din alt relaie. (Spunem c intete cheia primar din alt relaie). Atributele comune joac un rol important n manipularea datelor. 1.2.1.6 Reprezentarea schemelor (de relaii) din BD relaionale Schema unei relaii dintr-o BD are forma: Denumire relaie [titlu tabel] (Atribute, ncepnd cu cheia primar, subliniat) Clieni (Nr. crt., firm, localitate, adres facturare, jude, cod potal, nr. telefon, cont trezorerie, dat contact). Modelul conceptual (schema conceptual) al unei BD este mulimea tuturor schemelor de relaie pentru BD respectiv.

1.2.2 Integritatea relaional Un model de date relaional cuprinde: - o parte structural, discutat n paragraful precedent; - un set de reguli de integritate care asigur corectitudinea datelor; - o parte de manipulare, care definete tipurile de operaii permise asupra datelor. Fiecare atribut are un domeniu, deci asupra valorilor permise pentru fiecare atribut exist anumite constrngeri de domeniu.
16

Mai exist dou reguli de integritate importante care sunt constrngeri ce se aplic ntregii baze de date, anume: - integritatea entitilor - integritatea referenial 1.2.2.1 Null-uri Null reprezint valoarea unui atribut care este curent necunoscut sau nu este aplicabil tuplului respectiv. Valoare logic necunoscut. Un Null nu este acelai lucru cu o valoare numeric = 0 sau cu un ir de text spaii (zero string); acestea sunt valori, un Null nsemnnd ns absena unei valori. 1.2.2.2 Integritatea entitilor Se aplic cheilor primare ale relaiilor de baz. O relaie de baz (tabel de baz) corespunde unei entiti n schema conceptual a BD. Integritatea entitilor: ntr-o relaie de baz nici un atribut al unei chei primare nu poate fi Null. 1.2.2.3 Integritatea referenial Se aplic cheilor strine. Integritatea referenial: Dac ntr-o relaie exist o cheie strin, valoarea acesteia trebuie ori s coincid cu valoarea unei chei candidat a unui tuplu n relaia sa de baz, ori s fie n ntregime Null. 1.2.2.4 Constrngerile de ntreprindere Constrngerile de ntreprindere: sunt reguli adiionale, specificate de ctre utilizatorii sau administratorul bazei de date (DBA).

1.2.3 Vederi Vederea extern este structura BD aa cum apare ea unui anumit utilizator. n modelul relaional o vedere este o relaie virtual, o relaie care nu este de fapt de sine stttoare, ci este derivat n mod dinamic din una sau mai multe relaii de baz. 1.2.3.1 Terminologie Relaie de baz: O relaie cu o anumit denumire, corespunztoare unei entiti din schema conceptual, ale crei tupluri sunt stocate fizic n BD. Vedere: Rezultatul dinamic al uneia sau mai multor operaii relaionale care acioneaz asupra relaiilor de baz, pentru a obine o alt relaie. O vedere este o relaie virtual, care n realitate nu exist n BD, ci este produs n momentul respectiv, la cererea unui utilizator.

17

Coninutul unei vederi este definit ca o interogare asupra unei sau mai multor relaii de baz. Vederile sunt dinamice, adic modificrile n relaiile de baz sunt reflectate imediat n vederi. i invers, modificrile permise operate asupra vederii se transmit relaiilor de baz. 1.2.3.2 Scopul vederilor Mecanismul de vedere este util pentru c: - furnizeaz un mecanism de securitate puternic; - permite utilizatorilor accesarea datelor n mod personalizat; aceleai date pot fi vizualizate simultan, n moduri diferite, de ctre diveri utilizatori; - poate simplifica operaiile complexe asupra relaiilor de baz. 1.2.3.3. Reactualizarea vederilor Exist restricii referitor la modificrile care pot fi efectuate prin intermediul vederilor. Condiiile de care depinde reactualizarea datelor prin intermediul vederilor sunt: - sunt permise reactualizrile prin intermediul unor vederi definite prin utilizarea unei interogri simple a unei singure relaii de baz, i care interogare conine fie cheia primar, fie cheia candidat a acesteia; - nu sunt permise reactualizrile prin vederi care implic relaii de baz multiple; - nu sunt permise reactualizrile prin vederi care implic operaia de acumulare sau de grupare. 1.2.4 Rezumatul capitolului 1.2 Relaiile sunt reprezentate fizic sub form de tabele, cu rndurile corespunznd tuplurilor individuale, iar coloanele corespunznd atributelor. Structura relaiei, mpreun cu specificarea domeniilor i altor constrngeri fac parte din intensitatea bazei de date, iar relaia, mpreun cu toate tuplurile sale reprezint o extensie a bazei de date. Proprietile relaiilor din bazele de date sunt: fiecare celul conine exact o valoare, denumirile atributelor sunt diferite, valorile acestora provin din acelai domeniu, ordinea atributelor nu are importan, nici ordinea tuplurilor, nu exist tupluri duble. Gradul unei relaii reprezint numrul de atribute, n timp de cardinalitatea reprezint numrul de tupluri. O relaie unar are un singure atribut, una binar are dou, una ternar are trei, iar o relaie nar are n atribute. O supercheie este un set de atribute care identific n mod unic tuplurile dintr-o relaie, n timp ce o cheie candidat este o supercheie minim. O cheie primar este o cheie candidat selectat pentru a identifica tuplurile. O relaie trebuie s aib ntotdeauna o cheie primar. O cheie strin este un atribut sau set de atribute dintr-o relaie care constituie o cheie candidat pentru alt relaie. Un Null reprezint o valoare pentru un atribut care este necunoscut n momentul respectiv sau nu este definit pentru acel tuplu. Integritatea entitilor este o constrngere care stabilete c, ntr-o relaie de baz nici un atribut al unei chei primare nu poate avea valoarea Null. Integritatea referenial stabilete c valorile cheii strine trebuie s corespund valorilor unei chei candidat a unui tuplu oarecare din relaia de baz sau s aib n ntregime valoarea Null. n modelul relaional o vedere este o relaie virtual. Vederea ofer securitate i permite proiectantului s personalizeze modelul unui utilizator. Vederile sunt create dinamic pentru utilizatori. Nu toate vederile pot fi reactualizate.
18

1.2.5 ntrebri la capitolul 1.2 Analizai fiecare dintre urmtoarele concepte n contextul modelului de date relaional: relaie, atribut, domeniu, tuplu, intensitate i extensie, gard i cardinalitate. Analizai diferenele dintre cheile candidat i cheia primar a unei relaii. Ce este o cheie strin? Care este legtura dintre cheile strine i cele candidat ale unei relaii? Dai exemple. Definii cele dou reguli de integritate principale din modelul relaional. Analizai de ce sunt necesare aceste reguli. Ce este o vedere? Analizai diferena dintre o vedere i o relaie de baz. Ce se ntmpl cnd un utilizator acceseaz o baz de date prin intermediul unei vederi?

1.3 Planificarea, proiectarea i administrarea BD

1.3.1 Ciclul de via al sistemelor informaionale Un sistem informaional (SI) include resursele care permit colectarea, administrarea, controlul i propagarea informaiilor n ntreaga organizaie. SI al unei organizaii cuprinde; - baza de date (BD) - elementele software ale BD - software de aplicaie - elementele hardware - personalul care utilizeaz i dezvolt sistemul. n cadrul SI, ciclul de via al aplicaiei de tip BD cuprinde urmtoarele etape (fig. 1.2): Planificarea BD: activitile administrative care permit parcurgerea etapelor aplicaiei de tip BD ct mai eficient posibil. Definirea sistemului: specificarea scopului i limitelor aplicaiei de tip BD, a utilizatorilor si i a domeniilor de aplicaie. Colectarea i analiza cerinelor: colectarea i analizarea de informaii despre partea de organizaie ce urmeaz s fie deservit de aplicaia de tip BD i utilizarea acestor informaii pentru identificarea cerinelor utilizatorilor; Cerin: o caracteristic ce trebuie inclus n noul sistem; Informaiile i cererile colectate, exprimate de cele mai multe ori neformal trebuie transformate ntr-o formulare structurat; pentru aceasta se utilizeaz tehnici de specificare a cerinelor, anume: tehnici de analiz i proiectare structurat (Structured Analysis Design), diagrame de flux de date (Data Flow Diagrams) i diagrame de tip intrare-prelucrare-ieire ierarhic (Hierarchic Input Process Output).

19

Proiectarea bazelor de date: procesul de realizare a unui proiect pentru o BD, care va aborda toate operaiile i obiectivele ntreprinderii. Scopurile proiectrii BD sunt: o Reprezentarea datelor i a relaiilor dintre ele, necesare tuturor aplicaiilor i utilizatorilor; o Furnizarea unui model de date care s accepte efectuarea oricrei tranzacii necesare asupra datelor; o Specificarea unui proiect minimal, structurat adecvat pentru realizarea cerinelor stabilite referitor la performanele sistemului, de exemplu timpul de rspuns. Cele dou abordri n proiectarea unui sistem de BD sunt: o de jos n sus; se stabilesc atributele la un nivel fundamental (adic proprietile entitilor), care apoi sunt grupate n relaii, dup dependenele funcionale ale acestora; aceast abordare se mai numete i normalizare i este indicat la proiectarea unor BD mai simple, cu un numr relativ mic de atribute; o de sus n jos; pentru BD mai complexe; se ncepe cu realizarea unor modele de date care conin cteva entiti i relaii de nivel nalt, urmnd apoi rafinri succesive de sus n jos, pentru a identifica entitile, relaiile i atributele asociate de nivel jos. Aceast abordare este ilustrat de modelul ER . Se ncepe cu identificarea entitilor i relaiilor care prezint interes pentru organizaie, urmat apoi de finalizarea atributelor. Exemplu: entiti: clieni, produse; se identific relaia dintre aceste entiti: clientul cumpr produse, apoi se identific atributele: Clieni (nr. client, adres etc.) i Produse (nr. produs, factur intrare, stoc etc.).

Alegerea sistemului SGBD; se alege un sistem adecvat care s accepte o aplicaie de tip BD; Proiectarea aplicaiei: Proiectarea interfeei cu utilizatorul i a programelor de aplicaie care utilizeaz, respectiv prelucreaz BD. Proiectarea BD i a aplicaiilor sunt activiti paralele n ciclul de via al aplicaiei de tip BD. Realizarea prototipului: Construirea unui model de lucru al unei aplicaii de tip BD. Implementarea: realizarea fizic a proiectelor pentru BD i aplicaii; se realizeaz printr-un DDL corespunztor SGBD ales. n aceast etap sunt realizate i vederile specificate de utilizatori. O parte din programele de aplicaie sunt tranzaciile bazei de date implementate cu un DML corespunztor SGBD, care poate fi incorporat ntr-un limbaj de programare gazd (ex. Visual Basic, Delphi etc.). Conversia i ncrcarea datelor: transferul n noua BD a oricror date deja existente i conversia oricror aplicaii existente, a.. s poat funciona n cadrul acesteia. Testarea: procesul de executare a programelor de aplicaie, cu intenia de a gsi erori; ca i la proiectare, i la testare trebuie de implicat utilizatorii. Strategii de testare: o Testarea de sus n jos; o Testarea de jos n sus; o Testarea pe fir; o Testarea la suprasolicitare.
20

ntreinerea operaional: procesul de monitorizare i ntreinere a sistemului, care se efectueaz dup instalarea acestuia. o Monitorizarea performanelor sistemului; o ntreinerea i modernizarea, prin ncorporarea de noi cerine, parcurgnd etapele precedente.

Fig. 1.2 Ciclul de via al aplicaiilor tip baz de date 1.3.2 Fazele proiectrii BD

21

Proiectarea conceptual a BD: procesul de construire a unui model al informaiilor utilizate n cadrul fiecrei organizaii, independent de toate consideraiile fizice. Proiectarea logic a BD: procesul de construire a unui model al informaiilor utilizate n cadrul unei organizaii bazat pe un anumit model de date (de exemplu entitate-relaie - ER), al SGBD, dar independent de alte consideraii fizice legate de SGBD. Tehnica de normalizare este utilizat pentru a testa corectitudinea unui model de date logic. Normalizarea garanteaz c relaiile derivate din modelul de date nu prezint redundan a datelor, care poate fi cauza anomaliilor dup implementare. Proiectarea logic i conceptual a BD presupune considerarea/mbinarea tuturor vederilor utilizatorilor. Un model logic cu multiple vederi ale utilizatorilor asupra organizaiei se numete model de date logic global. n proiectarea unui model de date logic global exist dou moduri principale de abordare: - tratarea centralizat - tratarea prin integrarea vederilor. Tratarea centralizat: mbin cerinele separate ale utilizatorilor, care reprezint vederi distincte ale acestora ntr-un set unic de cerine, dup care se construiete modelul de date logic global. Sistemul de BD nu trebuie s fie prea mare sau complex. Tratarea prin integrarea vederilor: mbin modelele de date logice separate, care reprezint vederi distincte ale utilizatorilor, ntr-un singur model de date logic global. Vederile distincte ale utilizatorilor se numesc modele de date logice locale. Proiectarea fizic a BD: procesul de realizare a descrierii implementrii bazei de date ntr-o capacitate de stocare; descrie structurile de stocare i metodele de acces utilizate. Principalul scop al proiectrii fizice pentru modelul relaional presupune: - deducerea unui set de tabele relaional i de constrngeri asupra acestora, din informaiile provenite din modelul de date logic global; - identificarea structurilor de stocare specifice i a metodelor de acces la date, pentru a asigura performanele optime ale sistemului de BD. - Proiectarea unei protecii de securitate pentru sistem; 1.3.3 Proiectarea aplicaiilor 1.3.3.1 Proiectarea tranzaciilor Tranzacie: O aciune sau serie de aciuni efectuate de ctre un singur utilizator sau program de aplicaie, care acceseaz i pot modifica coninutul bazei de date. O tranzacie poate fi format din mai multe operaii i este un eveniment din lumea real. SGBD garanteaz coerena BD, deci n urma unei tranzacii o BD trece dintr-o stare coerent ntr-alt stare coerent. SGBD garanteaz coerena BD i n cazul unei defeciuni. Odat tranzacia ncheiat, modificrile efectuate sunt stocate permanent n BD i nu pot fi pierdute sau anulate (doar printr-o nou tranzacie).
22

Tipuri de tranzacii: - de regsire; - de reactualizare; - mixte (regsire plus reactualizare). Tranzaciile se proiecteaz plecnd de la informaiile din cerinele utilizatorului. Exemplu: utilizatorul va dori s nregistreze toi noii clieni n BD, deci se proiecteaz o tranzacie care s fac posibil aceast aciune, nsoit de o interfa prietenoas cu utilizatorul. 1.3.3.2 Proiectarea interfeei cu utilizatorul Utilizatorul va lucra de regul nu direct n tabele, ci n formulare, fiecare formular reprezentnd un tuplu dintr-un tabel. nainte de implementare se proiecteaz macheta unui formular sau raport. Indicaii utile pentru proiectarea unui formular/raport - titlu semnificativ - instruciuni inteligibile - grupare logic a cmpurilor - aspect atrgtor al machetei - etichete familiare ale cmpurilor - terminologie i prescurtri coerente - utilizare coerent a culorilor - spaii i limite vizibile ale cmpurilor de introducere a datelor - micare convenabil a cursorului - corectare de erori pentru caractere individuale sau cmpuri ntregi - mesaje de eroare pentru valori inacceptabile - marcare clar a cmpurilor opionale - mesaje explicative pentru cmpuri - semnal de terminare 1.3.4 Administrarea datelor i a bazei de date Etapele ciclului de via al aplicaiilor 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 cerinelor Proiectarea conceptual a bazei de date Alegerea sistemului SGBD Proiectarea logic a bazei de date Proiectarea aplicaiilor 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

Conversia i ncrcarea datelor Testarea ntreinerea operaional

DBA DBA DBA

DA DA DA

Administrarea datelor (DA): Gestionarea resurselor de date, care include planificarea BD, realizarea i ntreinerea standardelor, politicilor i procedurilor i proiectarea conceptual i logic a bazei de date. Administrarea bazei de date (DBA): Administrarea realizrii fizice a unei aplicaii de tip BD, inclusiv proiectarea i implementarea fizic a BD, stabilirea controlului de securitate, integritate, monitorizarea performanelor sistemului i reorganizarea BD dup necesiti. Principalele diferene dintre sarcinile din DA i DBA rezult din tabelul de mai jos: Administrarea datelor (DA) Implicat n planificarea IT strategic Stabilete scopurile pe termen lung ntrete standardele, politicile i procedurile Stabilete cerinele privind datele Realizeaz proiectarea conceptual i logic a bazei de date Dezvolt i ntreine modelul general de date Coordoneaz dezvoltarea sistemului Are o orientare managerial Este independent de SGBD 1.3.5 Rezumatul capitolului 1.3 Un sistem informaional (SI) const n resursele care permit colectarea, gestionarea, controlul i difuzarea informaiilor n cadrul ntregii organizaii. Principalele etape ale ciclului de via al aplicaiei tip baz de date sunt: planificarea BD, definirea sistemului, colectarea i analiza cerinelor, proiectarea BD, alegerea SGBD (opional), proiectarea aplicaiilor, realizarea prototipului (opional), implementarea, conversia i ncrcarea datelor, testarea i ntreinerea operaional. Proiectarea conceptual a BD este procesul de construire a unui model al informaiilor utilizate n ntreprindere, independent de toate consideraiile fizice. Proiectarea logic a BD este procesul de construire a unui model al informaiilor utilizate n ntreprindere, bazat pe un anumit model de date, dar independent de un anumit SGBD i de alte consideraii fizice. Un model logic care reprezint vederile mai multor utilizatori asupra unei organizaii se numete model de date logic global. n proiectarea acestuia abordrile pot fi: tratarea centralizat i tratarea prin integrarea vederilor. 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. Proiectarea aplicaiei de tip BD presupune: proiectarea tranzaciilor i proiectarea interfeei cu utilizatorul. O tranzacie a bazei de date este o operaie care implic acces la baza de date i reprezint un eveniment din lumea real.
24

Administrarea bazei de date (DBA) Evalueaz noile SGBD Execut planurile de atingere a scopurilor ntrete standardele, politicile i procedurile Implementeaz cerinele 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

Administrarea datelor const n gestionarea resurselor de date, inclusiv planificarea BD, proiectarea conceptual i logic a acesteia, dezvoltarea i ntreinerea standardelor, politicilor i procedurilor. Administrarea datelor acioneaz mai ales la nceputul ciclului de via al aplicaiei tip BD, nainte de implementare. Administrarea bazei de date const n gestionarea realizrii fizice a BD, inclusiv proiectarea fizic i implementarea BD, controlul de securitate i integritate, monitorizarea performanelor i reorganizarea BD dup caz. Administrarea BD intervine mai ales n etapele trzii ale ciclului de via al aplicaiei de tip BD. 1.3.6 ntrebri la capitolul 1.3 Descriei scopul fiecrei etape din ciclul de via al aplicaiilor de tip BD. Descriei principalele scopuri ale fazelor de proiectare conceptual i logic a BD. Definii diferenele dintre scopurile i sarcinile DA i DBA.

1.4. Modelarea Entitate-Relaie (ER)

Modelul ER este un model conceptual de nivel nalt, dezvoltat de Chen (1976) pentru a facilita proiectarea BD. Un model de date conceptual se compune din: - un set de concepte care descriu structura bazei de date (entiti, relaii, atribute) i - tranzaciile de regsire i actualizare asociate. Scopul realizrii unui model de date de nivel nalt este: - perceperea datelor de ctre utilizator, - ascunderea aspectelor tehnice asociate proiectrii BD. Un model de date conceptual este independent de tipul de SGBD utilizat i de platforma hardware asociat. 1.4.1 Conceptele modelului ER Conceptele de baz ale modelului ER includ: - tipurile de entiti - tipurile de relaii - atributele 1.4.1.1 Tipuri de entiti Tip de entitate: Un obiect sau concept identificat de organizaie ca avnd o existen independent. Un tip de entitate conine un set de obiecte sau concepte cu aceleai proprieti. Exemple de tipuri de entiti: Clieni, Produse, Personal, Rud_apropiat (obiecte, entiti cu existen fizic) Vnzare (concepte, entiti cu existen conceptual) Entitate: o instan unic identificabil a unui tip de entitate. Exemplu: Georgescu, Popescu sunt entiti ale tipului de entitate Clieni Entitate tare (entitate printe, proprietar, dominant): Un tip de entitate a crei existen nu depinde de alte tipuri de entiti. Exemplu: clieni, produse, personal, vnzare.
25

Entitate slab (entitate copil, dependent, subordonat): Un tip de entitate a crei existen depinde de existena uneia sau mai multor alte tipuri de entiti. Exemplu: Ruda_apropiat. Reprezentare n modelul ER: entitatea tare se trece ntr-un dreptunghi cu chenar simplu, entitatea slab ntr-un dreptunghi cu chenar dublu (fig. 1.3). Personal Ruda_apropiata

Fig. 1.3 Entitate tare i entitate slab 1.4.1.2 Atribute Atribut: o proprietate a unui tip de entitate sau relaie. Domeniul atributului: Mulimea n care ia valori atributul. Atribut simplu: are o singur component, cu existen independent. Exemplu: Atribute n tipul de entitate Personal: sex, salariu Atribut compus: are mai multe componente, fiecare independent Exemplu: Adresa (Str. Zorilor 13): atributul strada + atributul numrul Atribut cu o singur valoare: Conine o singur valoare pentru o anumit entitate. Atribut cu valori multiple: Conine mai multe valori pentru o singur entitate. Exemplu: un client poate avea mai multe numere de telefon. 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 aceeai entitate. Exemplu: atributul vrsta se deriv din data naterii. Reprezentarea atributelor: elipse; contur punctat pentru atribute derivate, contur dublu pentru atribute cu valori multiple. Atributele compuse radiaz atributele componente. Denumirea atributelor cheie primar se subliniaz. Figura 1.4 se refer la modelul ER al unei agenii imobiliare.

26

Fig.1.4. Reprezentarea schematic a tipurilor de entiti Personal, Filiala i Ruda apropiat i a atributelor acestora.

27

1.4.1.3 Tipuri de relaii Tip de relaie : O asociere semnificativ ntre tipuri de entiti. Exemplu: ntre tipul de entitate Filiala i tipul de entitate Personal exist tipul de relaie este alocat. ntre fiecare entitate din tipurile de entiti de mai sus exist o prezen unic identificabil a tipului de relaie dintre ele, numit: relaie. Relaie : o instan unic identificabil a unui tip de relaie. Exemplu: ntre fiecare entitate din tipul de entitate Personal i fiecare entitate din tipul de entitate Filial exist o instan a relaiei este alocat, adic fiecare angajat este alocat unei filiale. n figura 1.5 sunt prezentate apariiile individuale ale relaiei este alocat , utiliznd o diagram numit reea semantic. Aceasta este o diagram la nivel de obiecte, unde simbolul reprezint entitile, iar simbolul reprezint relaiile. Pentru simplificare n fig. 1.5. sunt prezentate numai unele atribute.

Fig. 1.5. Model semantic n reea, cu apariiile individuale ale relaiei Este Alocat Reprezentarea schematic a relaiilor Modele semantice sunt dificil de neles datorit detaliilor. Reprezentarea de nivel nalt a relaiei este alocat, utiliznd conceptele modelului ER se prezint n figura 1.6. Pentru simplificare s-au reprezentat numai atributele chei primare. Relaiile se reprezint prin romburi; rombul are linii duble dac face legtura dintre o entitate slab i una tare, de care depinde. n exemplul din fig. 1.6 se observ c entitatea slab Ruda_Apropiat nu are cheie primar.

28

Fig. 1.6. Reprezentare schematic a entitilor, relaiilor i atributelor cheie primar Filiala, Personal i Ruda_Apropiat Gradul unei relaii: numrul de entiti participante ntr-o relaie.

Fig. 1.7. Relaie binar, cu 2 participani (2 entiti participante), relaie numit deine

Fig. 1.8. Relaie ternar, numit Fixeaz

29

Fig. 1.9. Relaie cvadrupl, numit Reglementeaz Relaie recursiv: O relaie n care aceeai entitate particip mai mult dect o dat n diferite roluri.

Fig. 1.10. Relaie recursiv numit supervizeaz, cu numele de roluri supervizat i supervizor. Relaiei i s-au atribuit nume de roluri pentru a indica scopul pe care-l are fiecare entitate participant n cadrul relaiei. Nume de roluri pot fi utilizate i cnd dou entiti sunt asociate prin mai mult dect o relaie (fig. 1.11).

Fig. 1.11 Entiti asociate prin dou relaii distincte numite Administreaz i Este alocat, mpreun cu numele de roluri corespunztoare. 1.4.1.4 Atributele relaiilor
30

Se pot asocia atribute i relaiilor (exemplul din fig. 1.12).

Fig. 1.12. Exemplu de relaie numit Viziteaz cu atributele (Data_vizitare i Comentarii). Prezena unor atribute asociate relaiilor poate indica existena unei entiti neidentificate (n exemplul dat, entitatea Vizitare).

1.4.2 Constrngeri structurale Entitilor participante ntr-o relaie li se impun anumite constrngeri, aa cum sunt percepute n lumea real. Exemple: o proprietate de nchiriat trebuie s aib un proprietar, filiala trebuie s aib personal. Exist dou mari tipuri de constrngeri structurale: de cardinalitate i de participare. 1.4.2.1 Constrngeri de cardinalitate Raport de cardinalitate al unei relaii: Descrie numrul de relaii posibile pentru fiecare entitate participant. Pentru relaii binare raportul de cardinalitate poate fi: 1:1 unu la unu; 1: M unu la mai muli; M:N mai muli la mai muli. Regulile care stabilesc cardinalitatea sunt reguli de afaceri ale organizaiei (n modelarea unei organizaii trebuie reprezentate ct mai multe reguli de afaceri). Relaii unu la unu (1:1) Se consider relaia binar Administreaza, anume Personal Administreaza Filiala. Modelul semantic corespunztor este prezentat n figura 1.13.

31

Fig.1.13 Model tip reea semantic al relaiei 1:1 (Personal Administreaza Filiala) Relaia este de cardinalitate 1:1 deoarece o singur entitate din Personal este asociat cu o singur entitate din Filiala. Acesta este confirmat prin regula de afaceri pe care o reprezint relaia: o filial are un singur administrator, iar un angajat poate administra doar o singur filial. Pot exista angajai (de. ex. Ann Beech) care nu administreaz nici o filial. n schimb nu pot exista filiale fr administrator. Diagrama ER a acestei relaii este prezentat n figura 1.14. Liniile sunt etichetate cu raportul de cardinalitate, care n fig. 1.14 este 1: 1. Fig. 1.14 Diagrama ER a relaiei 1:1 Personal Administreaza Filiala

Relaii unu la mai muli (1:M) Considerm relaia binar Personal Supravegheaza Proprietate_de_Inchiriat, al crei model tip reea semantic este prezentat n figura 1.15.

32

Fig. 1.15 Diagrama tip reea semantic a relaiei 1:M Din diagram reiese gradul de cardinalitate al relaiei ca fiind de 1: M, deoarece un membru al personalului poate supraveghea mai multe proprieti (de ex. p2 supravegheaz pr1 i pr2), ceea ce corespunde regulilor de funcionare ale organizaiei. n schimb o proprietate poate fi supravegheat numai de un singur membru al personalului. Relaia este deci de cardinalitate 1: M citit de la stnga la dreapta, i de cardinalitate 1:1 citit de la dreapta la stnga, din punctul de vedere al proprietii de nchiriat. Pentru stabilirea gradului de cardinalitate al relaiei se va lua n considerare gradul mai nalt, deci n cazul exemplului 1:M. Diagrama ER corespunztoare acestei relaii este reprezentat n figura 1.16. Fig. 1.16. Diagrama ER a relaiei 1:M

33

Relaii mai muli la mai muli (M:N) Considerm relaia Ziar Face Reclama Proprietate_de_Inchiriat cu reeaua semantic din figura 1.17.

Fig. 1.17. Diagram tip reea semantic a relaiei M:N Din diagram reiese gradul de cardinalitate al relaiei de M:N att d.p.d.v. al entitii Ziar, ct i din cel al entitii Proprietate_de_Inchiriat. Corespunztor regulilor de afaceri, ntr-un ziar se poate face reclam mai multor proprieti, i unei proprieti i se poate face reclam n mai multe ziare. Diagrama ER corespunztoare este prezentat n figura 1.18.

Fig. 1.18. Diagrama ER a relaiei M:N 1.4.2.2 Constrngeri de participare Constrngerile de participare determin dac existena unei entiti depinde de legtura sa de alt entitate prin intermediul unei relaii. Exist dou tipuri de constrngeri de participare (a unei entiti ntr-o relaie): - participare total sau obligatorie (reprezentat printr-o linie dubl) - participare parial sau opional (reprezentat printr-o linie simpl). Participarea unei entiti ntr-o relaie este total, dac existena unei entiti necesit (este condiionat de) existena altei entiti prin intermediul unei anumite relaii. Altfel participarea este parial.
34

Exemplu. n relaia binar Filiala Este Alocat Personal (fig. 1.19) o filial poate exista, evident, numai dac are alocat personal. Deci existena entitii Filiala este condiionat de existena entitii Personal. Ca urmare entitatea Filiala va participa total (obligatoriu) n relaia Este Alocat, i se va reprezenta cu linie dubl. Conform regulilor de afaceri ale organizaiei, pot ns exista membri de personal care nu sunt alocai unei anumite filiale. Entitatea Personal va avea deci participare parial (opional) n relaia Este Alocat, i se va reprezenta cu linie simpl Fig. 1.19. Constrngeri de participare O reprezentare alternativ a constrngerilor de participare rezult din fig. 1.20, unde pe liniile de legtur sunt trecute valorile minim i maxim cu care pot participa entitile n relaie. n cazul exemplului, o filial poate avea minim 5 i maxim nedefinit (N) angajai. Un angajat poate s nu fie alocat unei filiale (valoare minim 0) sau s fie alocat unei filiale, i numai uneia (valoare maxim 1). Fig. 1.20 Constrngeri de participare, notaie alternativ

1.4.3 Problemele modelului ER n proiectarea unui model de date conceptual pot aprea aa-numite capcane de conectare, datorit interpretrii eronate a sensului unei relaii. 1.4.3.1 Capcane n evantai Capcanele n evantai sunt acele capcane de conectare care ntr-un model ER reprezint o relaie dintre tipuri de entiti, dar cile dintre anumite apariii ale entitilor sunt ambigue. Capcanele n evantai apar cnd dou sau mai multe relaii 1:M provin din aceeai entitate (fig. 1.21). Din model nu rezult la ce filial este alocat un anumit membru al personalului dintr-o secie, tiind c o secie coordoneaz mai multe filiale. Examinm modelul la nivel de apariii individuale prin intermediul reelei semantice (fig. 1.22). Fig. 1.21 Capcan n evantai

35

Se poate observa capcana n evantai: Angajatul SG37 este alocat seciei S1, dar secia S1 coordonnd filialele B3 i B7, nu se tie la care dintre aceste dou filiale este alocat SG 37. Fig. 1.22. Reeaua semantic a modelului ER din fig. 1.21 Capcana se rezolv prin restructurarea modelului ER, a.. acesta s reprezinte corect asocierile dintre entiti (fig. 1.23). Se observ care secie coordoneaz care filiale, i ce personal este alocat fiecrei filiale.

Fig. 1.23. Model ER restructurat Reeaua semantic a modelului restructurat (corect) este cea din fig. 1.24. Angajatul SG37 este alocat filialei B3, coordonat de secia S1.

Fig. 1.24. Reeaua semantic a modelului ER din fig. 1.23. 1.4.3.2 Capcane de ntrerupere Capcanele de ntrerupere sunt acele capcane de conectare n care un model sugereaz existena unei relaii ntre tipurile de entiti, dar nu exist ci ntre anumite apariii ale acestor entiti. Capcanele de ntrerupere apar cnd n calea prin care sunt legate entitile intervine o entitate cu participare parial. Exemplu. Din modelul din fig. 1.25 se observ urmtoarele: Pe ramura din stnga: - unei singure filiale i sunt alocai mai muli angajai (relaie 1:M) - filiale exist numai dac are personal, fiecare membru al personalului este obligatoriu alocat unei filiale (participri totale linii duble de legtur). Pe ramura din dreapta: - Un angajat (membru al personalului) poate superviza mai multe proprieti, o proprietate poate fi supravegheat de un membru al personalului (relaie 1: M)

36

Nu fiecare membru al personalului supravegheaz obligatoriu proprieti i nu toate proprietile sunt supravegheate obligatoriu de un membru al personalului (participri pariale linii simple de legtur). Din modelul din fig. 1.25 nu se poate deduce ce proprieti sunt disponibile la care filiale. Modelul ER sugereaz existena unei relaii ntre entitile Filiala i Proprietate_de_Inchiriat, dar, aa cum rezult din reeaua semantic asociat (fig. 1.26) nu exist ci ntre anumite apariii ale entitilor.

Fig. 1.25 Capcan de ntrerupere

Lipsa cilor ntre anumite apariii ale entitilor Filiala i Proprietate_de_Inchiriat se observ clar din reeaua semantic din figura 1.26. Nu se poate deduce la ce filial este disponibil proprietatea PA14. Fig. 1.26. Reeaua semantic a modelului ER din fig. 1.25. Participarea parial a entitilor Personal i Proprietate_de_Inchiriat n relaia Supravegheaza are ca efect faptul c unele proprieti nu pot fi asociate cu o filial prin intermediul unui membru al personalului. Pentru rezolvarea acestei capcane de ntrerupere trebuie identificat relaia care lipsete. Aceasta este relaia Are dintre entitile Filiala i Proprietate_de_Inchiriat. Se restructureaz modelul ER, introducnd relaia nou identificat Are ntre entitile ntre care lipseau cile (fig. 1.27). Fig. 1.27. Model ER restructurat pentru eliminarea capcanei de ntrerupere.

37

Acum la nivelul apariiilor individuale, adic din reeaua semantic, se poate stabili c proprietatea PA14 este disponibil la filiala B7 (fig. 1.28).

Fig. 1.28. Reeaua 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 organizaie ca avnd o existen independent. O entitate este o instan unic identificabil a unui tip de entitate. Un tip de entitate slab este o entitate a crei existen depinde de existena altor entiti. O entitate tare este o entitate a crei existen nu este dependent de existena altor entiti. Un atribut este o proprietate a uni tip de entitate sau relaie. Domeniul atributului reprezint mulimea 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 conine o singur valoare pentru o singur entitate. Un atribut cu valori multiple deine mai multe valori pentru o singur entitate. Un atribut derivat are o valoare derivabil dn valoarea altui atribut sau mulimi de atribute, care nu sunt neaprat ale aceleiai entiti. O cheie candidat este un atribut sau set de atribute care identific n mod unic apariiile 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 relaie este un set de asociaii, toate cu un acelai sens, ntre tipuri de entiti. O relaie este o asociere ntre entiti, aceast relaie cuprinznd o entitate din fiecare tip de entitate ce particip n relaie. Gradul unui tip de relaie este numrul de entiti participante n aceasta. O relaie recursiv conine o aceeai entitate care particip de mai multe ori n relaie, cu roluri diferite. Numele de roluri sunt utilizate pentru determinarea funciilor fiecrei entiti participante ntr-o relaie. Raportul de cardinalitate descrie numrul de relaii posibile pentru fiecare entitate participant. Constrngerile de participare determin dac existena unei entiti depinde de legtura sa cu o alt entitate, prin intermediul unei relaii. O capcan n evantai exist acolo unde un model reprezint o relaie ntre tipuri de entiti, dar calea dintre anumite apariii ale acestora este ambigu. O capcan de ntrerupere exist acolo unde modelul sugereaz existena unei relaii ntre tipuri de entiti, dar nu exist o cale ntre anumite apariii ale entitilor.

38

1.4.5 ntrebri la capitolul 1.4 Descriei conceptele de baz ale modelului ER, i reprezentarea schematic a acestora. Descriei constrngerile ce pot fi impuse entitilor participante ntr-o relaie. Descriei problemele ce pot aprea n crearea unui model ER.

1.5 Normalizarea
Atunci cnd proiectm o BD pentru un SGBD relaional, principalul obiectiv la crearea unui model de date logic este reprezentarea corect a datelor, relaiilor i constrngerilor. Pentru acesta trebuie de identificat un set de relaii adecvat, ceea ce se realizeaz cu ajutorul tehnicii de normalizare. Normalizarea este tratarea de jos n sus a proiectrii BD, care ncepe cu examinarea relaiilor dintre atribute. 1.5.1 Scopul normalizrii Normalizarea este o tehnic de realizare a unui set de relaii (a unei mulimi de tabele) cu proprieti (atribute) dezirabile, avnd n vedere cerinele organizaiei. Normalizarea este frecvent efectuat ca o serie e teste asupra unei relaii, pentru a stabili dac aceasta satisface sau violeaz cerinele 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 dependenele funcionale dintre atributele unei relaii. Prin aplicarea testelor de normalizare, adic prin normalizarea schemei relaionale (vezi pct. 1.2.1.3) se previne apariia anomaliilor de reactualizare. 1.5.2 Redundana datelor i anomaliile de reactualizare Atributele trebuie grupate n relaii (tabele) astfel nct s se minimizeze redundana datelor i s se reduc spaiul de stocare necesar relaiilor de baz implementate. Pentru stocarea n BD a informaiilor referitoare la angajai i filiale comparm dou posibiliti: a) Crearea a dou tabele, unul cu angajai (relaia Personal) i unul cu filialele (relaia Filiala):
Personal Filiala (Nr_Personal, NumeP, AdresaP, Functie, Salariu, Nr_Filiala) (Nr_Filiala, AdresaF, Nr_Tel)

b) stocarea tuturor informaiilor ntr-un tabel unic (Personal_Filiala):

Personal_Filiala (Nr_Personal, NumeP, AdresaP, Functie, Salariu, Nr_Filiala, AdresaF, Nr_Tel).

n relaia 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 mprite 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 considerm relaia 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 rnduri din acelai 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 entitilor i nu va fi permis. Ca urmare nu poate fi inserat o filial nou fr personal alocat. Aceste probleme se evit proiectnd i utiliznd dou relaii distincte, anume: Personal i Filiala. Anomaliile de tergere Dac n relaia 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 informaiilor referitoare la filiala respectiv. Anomalii de modificare Dac reactualizm de exemplu un numr de telefon al unei filiale din tabelul Personal_Filiala, atunci acest numr va trebui de reactualizat n acest tabel n toate rndurile n care apare filiala respectiv (rnduri corespunztoare diferiilor membri ai personalului alocai filialei respective). Proprietile de uniune fr pierderi i conservare a dependenei Relaia Personal_Filiala este expus anomaliilor de reactualizare i trebuie descompus n dou relaii (tabele) distincte: Personal i Filiala. Descompunerea are dou proprieti importante: - Uniune fr pierderi: permite regsirea oricrei instane din relaia iniial n instanele corespunztoare ale relaiilor mai mici. - Conservarea dependenei: permite impunerea unei constrngeri asupra relaiei iniiale, prin impunerea unei constrngeri asupra fiecreia dintre relaiile mai mici. Adic nu este necesar efectuarea uniunii relaiilor mai mici pentru a verifica dac este violat o constrngere asupra relaiei iniiale. 1.5.3 Dependene funcionale Conceptul de dependen funcional este elementul central n procesul de normalizare. Dependen funcional: descrie legturile dintre atributele unei relaii. De exemplu, dac A i B sunt atribute ale relaiei R, atributul B este dependent funcional de A (se noteaz A B) dac fiecrei valori a atributului A i este asociat exact o valoare atributului B (A i B pot fi formate din mai multe atribute fiecare). Atunci cnd exist o dependen funcional, ea este specificat ca o constrngere ntre atribute.
40

A B: pentru o valoare dat a lui A (n toate rndurile din tabel unde apare aceast valoare) se va gsi o singur valoare a lui B Exemplu: A = atributul localitate; B = atributul jude. Deoarece A B (adic B este dependent funcional de A), n fiecare rnd din tabel unde A are valoarea Codlea, B va avea valoarea Braov. Dependena dintre atributele A i B poate fi reprezentat i sub form de diagram (fig. 1.29). Determinantul unei dependene funcionale se refer la atributul din partea stng a sgeii. Aici A este determinantul lui B. Fig. 1.29. Diagram de dependen funcional n relaia Personal_Filiala exist 13 dependene funcionale cu urmtorii determinani, nscrii n stnga sgeii: Nr_Personal NumeP; Nr_Personal AdresaP; Nr_Personal Functie; Nr_Personal Salariu; Nr_Personal Nr_Filiala; Nr_Personal AdresaF; Nr_Personal Nr_Tel; Nr_Filiala AdresaF; Nr_Filiala Nr_Tel; AdresaF Nr_Filiala; AdresaF Nr_Tel; Nr_Tel Nr_Filiala; Nr_Tel AdresaF; Identificarea cheii primare a unei relaii cu ajutorul dependenei funcionale Pentru a identifica cheia primar a relaiei (tabelului) Personal_Filiala se identific nti toate cheile candidat, adic acele atribute care identific n mod unic fiecare rnd din relaie. Toate atributele care nu fac parte din cheia primar trebuie s fie dependente funcional de aceasta. Ca urmare cheia primar va fi acel atribut (sau set de atribute) care determin funcional toate celelalte atribute ale relaiei. Cu alte cuvinte cheia primar va fi acel atribut (sau set de atribute) de care sunt dependente funcional toate celelalte atribute ale relaiei. n relaia Personal_Filiala aceast cerin o ndeplinete numai atributul Nr_Pers.

1.5.4 Procesul de normalizare Normalizarea este o tehnic formal de analizare a relaiilor (tabelelor) bazat pe cheile primare ale acestora i pe dependenele funcionale. Tehnica presupune o serie de reguli care pot fi utilizate pentru
41

testarea relaiilor individuale, rezultnd normalizarea bazei de date. Atunci cnd o cerin nu este ndeplinit, relaia care o violeaz trebuie descompus n relaii care satisfac individual cerinele normalizrii. Normalizarea se execut ca o serie de pai corespunztori unei anumite forme normale. Pentru modelul relaional numai prima form normal (1NF) este de importan critic n crearea de relaii adecvate. Toate formele normale urmtoare sunt opionale, dar pentru a evita anomaliile de reactualizare se recomand efectuarea normalizrii pn la cel puin forma normal 3NF. Procesul de normalizare este ilustrat n figura de mai jos, unde se demonstreaz legtura dintre diversele forme normale. Unele relaii n 1NF sunt i n 2NF, unele relaii n 2 NF sunt i n 3NF .a.m.d.

Schema legturilor dintre formele normale 1.5.5 Prima form normal Forma nenormalizat (UNF) este un tabel care conine unul sau mai multe grupuri repetitive. Prima form normal (1NF) este o relaie n care intersecia fiecrui rnd cu fiecare coloan conine o singur valoare i numai una. Se presupune c datele sunt introduse prin intermediul unui formular. Aceste date se transfer i se stocheaz ntr-un tabel de form nenormalizat. Se identific i se elimin grupurile repetitive pentru a aduce tabelul n prima form normal (1NF). Un grup repetitiv este un atribut sau grup de atribute dintr-un tabel care are valori multiple pentru o singur apariie a atributului (atributelor) cheie primar al acelui tabel. Exist dou tratri uzuale pentru eliminarea grupurilor repetitive din tabele. Prima tratare: se elimin grupurile repetitive prin introducerea datelor adecvate n coloanele goale ale rndurilor care conin date repetitive. Exemplu: Se consider un formular (fig. 1.30) pentru introducere n baza de date a ageniei imobiliare de Detalii client-nchiriere. Pentru simplificare se presupune c un client nchiriaz o anumit proprietate o singur dat i nu poate nchiria mai mult de o proprietate n acelai timp.
42

Fig. 1.30. Formularul Detalii client-nchiriere al ageniei imobiliare Pentru cei doi clieni datele transformate ntr-un tabel nenormalizat se prezint ca n fig. 1.31.

Fig. 1.31 Tabelul nenormalizat (UNF) Client_Inchiriere Ca urmare exist valori multiple la intersecia dintre anumite rnduri i coloane. De exemplu pentru clientul John Kay exist dou proprieti: PG4 i PG 16. Pentru a transforma tabelul n prima form normal se elimin grupul repetitiv, a.. s existe o singur valoarea n fiacre celul. Conform primei tratri grupul repetitiv se elimin prin introducerea datelor adecvate n fiecare rnd. Tabelul (relaia) va fi acum n 1NF (fig. 1.32).

43

Fig. 1.32. Relaia Client_Inchiriere n prima form normal (1NF) n continuare se identific cheile candidat, care pentru acest tabel vor fi chei compuse: (Nr_Client, Nr_Proprietate); (Nr_Client, InceputInchir) i (Nr_Proprietate, InceputInchir). Se selecteaz drept chei primar al acestei relaii setul de atribute: (Nr_Client, Nr_Proprietate); n fig. 1.32 ele au fost mutate a.. s fie primele dou coloane. Acum relaia Client_Inchiriere n 1NF este definit astfel: Client_Inchiriere (Nr_Client, Nr_Proprietate, NumeC, AdresaP, InceputInchir, SfarsitInchir, Chirie, Nr_Proprietar, NumeP) Relaia este n 1NF, adic la intersecia unui rnd cu o coloan exist o singur valoare, dar are n acelai timp date redundante. Va trebui trecut n 2NF, ceea ce nu este ns obiectul prezentului curs. A doua tratare: se elimin grupul repetitiv prin plasarea ntr-o relaie separat a datelor repetitive, mpreun cu o copie atributului cheie iniial (Nr_Client), aa cum arat figura 1.33. Apoi se identific o cheie primar pentru noua relaie.

Fig. 1.33 Relaiile Client i Prop_Inchir_Proprietar n 1NF Formele celor 2 relaii n 1NF rezultante sunt: Client (Nr_Client, NumeC)
44

Prop_Inchir_Proprietar (Nr_Client, Nr_Proprietate, AdresaP, InceputInchir, SfarsitInchir, Chirie, Nr_Proprietar, NumeP) Cum rezult din fig. 1.33, ambele relaii sunt n 1NF, deoarece la intersecia dintre fiecare rnd i fiecare coloan exist o singur valoare. A doua relaie prezint o oarecare redundan a datelor i poate suferi anomalii de reactualizare. Se impune trecerea n 2NF. 1.5.6 A doua form normal (2NF) A doua form normal se bazeaz pe conceptul de dependen funcional total. Dac A i B sunt atributele unei relaii, atunci B este total dependent funcional de A, dac B este dependent funcional de A, dar nu de orice submulime adecvat a lui A. O dependen funcional A B este total, dac prin eliminarea oricrui atribut din componena lui A, dependena nu mai are loc. O dependen funcional A B este parial, dac exist un atribut din componena lui A, care dac este eliminat din A, dependena funcional se pstreaz. Exemplu de dependena funcional parial: Determinantul A se compune din 2 atribute: Nr_Personal, NumeP. Atributul determinat, dependent funcional de A este B: Nr_Filiala. A B, deci: Nr_Personal, NumeP Nr_Filiala. i dup eliminarea atributului NumeP din componena lui A, dependena funcional se pstreaz: NumeP Nr_Filiala, deci dependena iniial A B este una parial. A doua form normal (2NF) se aplic relaiilor cu chei compuse (din mai multe atribute). Al doilea tabel din fig. 1.33 se afl n 1NF i are cheia primar compus din 2 atribute: Nr_Client, Nr_Proprietate. Tabelul este expus anomaliilor de reactualizare. Dac de exemplu trebuie de modifica valoarea chiriei pentru proprietatea PG4 i reactualizarea nu se face n fiecare rnd n care apare PG4, se pierde coerena bazei de date. Se observ c atributul Chirie depinde funcional numai de atributul Nr_Proprietate i nu de ntreaga cheie primar compus. (Adic, dac se elimin atributul Nr_Client din cheia primar, dependena funcional Nr_Proprietate Chirie se pstreaz). Pentru a evita anomaliile de reactualizare tabelul trebuie de adus n 2NF. A doua form normal, 2NF (definiie): O relaie (tabel) n 1NF n care fiecare atribut care nu este cheie primar este total dependent funcional de cheia primar (compus) se afl n 2 NF.

45

Trecerea din 1 NF n 2NF se face prin eliminarea dependenelor pariale. Atributele identificate ca fiind parial dependente de cheia primar se plaseaz ntr-o nou relaie (tabel), mpreun cu determinantul lor. Se consider tabelul Client_Inchiriere (fig. 1.32), avnd o cu cheie primar compus. Client_Inchiriere (Nr_Client, Nr_Proprietate, NumeC, AdresaP, InceputInchir, SfarsitInchir, Chirie, Nr_Proprietar, NumeP) n acest tabel exist urmtoarele dependene funcionale: fd1 fd2 fd3 fd4 fd5 fd6 Nr_Client, Nr_Proprietate InceputInchir, SfarsitInchir Dependene totale de cheia primar Nr_Client, Nr_Proprietate Nr_Client NumeC Dependen parial de (unul din atributele din) cheia primar Nr_Proprietate AdresaP, Chirie, Nr_Proprietar, NumeP Dependen parial de (unul din atributele din) cheia primar Nr_Proprietar NumeP Dependen tranzitiv Nr_Client, InceputInchir Nr_Proprietate, AdresaP, Dependene totale SfarsitInchir, Chirie, Nr_Proprietar, NumeP de cheia candidat Nr_Client, InceputInchir Nr_Proprietate, InceputInchir Nr_Client, NumeC, Dependene totale SfarsitInchir de cheia candidat Nr_Proprietate, InceputInchir

Tabelul Client_Inchiriere nu se afl n 2NF, deoarece s-au depistat dependene pariale ale unor atribute de (unul din atributele din) cheia primar. Observaie: Dependena tranzitiv nu violeaz 2NF, dei poate cauza anomalii de reactualizare . Astfel de dependene sunt eliminate la trecerea n 3NF. Pentru a aduce tabelul n 2NF: - atributele dependente parial se mut ntr-un nou tabel, mpreun cu atributul lor determinant fd2, fd3): Client (Nr_Client, NumeC) Proprietar_Proprietate (Nr_Proprietate, AdresaP, Chirie, Nr_Proprietar, NumeP) - tabelul iniial sub alt nume - i pstreaz cheia primar iniial, compus, i acele atribute care au dependen funcional total de cheia primar (fd1). Inchiriere (Nr_Client, Nr_Proprietate, InceputInchir, SfarsitInchir).

46

Relaiile (tabelele) n 2NF derivate din relaia (tabelul) Client_Inchiriere 1.5.7 A treia form normal (3NF) n tabelul Proprietate-Proprietar s-a identificat dependena tranzitiv Nr_Proprietar NumeP. Reactualizarea numelui unui proprietar (de ex. Tony Shaw) trebuie fcut n fiecare rnd n care acesta apare. n caz contrar BD va deveni incoerent. Ca urmare existena dependenei tranzitive poate cauza anomalii de reactualizare. Aducerea unei relaii (unui tabel) n 3 NF se refer la eliminarea dependenelor tranzitive. Dependen tranzitiv (definiie): Dac A, B i C sunt atributele unei relaii (unui tabel) i A B i B C, atunci C este dependent tranzitiv de A prin intermediul lui B (cu condiia ca A s nu fie dependent funcional de B sau C). Se consider de exemplu relaia Personal_Filiala
Personal_Filiala (Nr_Personal, NumeP, AdresaP, Functie, Salariu, Nr_Filiala, AdresaF, Nr_Tel).

Exist (printre altele) urmtoarele dependene funcionale: Nr_Personal Nr_Filiala i Nr_Filiala AdresaF Deci dependena Nr_Personal AdresaF are loc prin intermediul atributului Nr_Filiala. Aceast dependen este adevrat pentru c atributul Nr_Personal nu este dependent funcional de atributul Nr_Filiala sau de atributul AdresaF. A treia form normal, 3NF (definiie): O relaie (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 dependenele funcionale din relaiile (tabelele) de mai sus: Client (Nr_Client, NumeC) Nr_Client NumeC
47

Inchiriere (Nr_Client, Nr_Proprietate, InceputInchir, SfarsitInchir) Nr_Client, Nr_Proprietate InceputInchir, SfarsitInchir Nr_Client, InceputInchir Nr_Proprietate, SfarsitInchir Nr_Proprietate, InceputInchir Nr_Client, SfarsitInchir Proprietar_Proprietate (Nr_Proprietate, AdresaP, Chirie, Nr_Proprietar, NumeP) Nr_Proprietate AdresaP, Chirie, Nr_Proprietar, NumeP Nr_Proprietar NumeP Singura dependen tranzitiv identificat se afl n relaia (tabelul) Proprietar_Proprietate: Nr_Proprietar NumeP, sau mai exact: Nr_Proprietate Nr_Proprietar NumeP. Celelalte 2 relaii (tabelele Inchiriere i Client) nu conin dependene tranzitive i se afl n 2NF, deci sunt considerate automat ca fiind n 3NF. Tabelul Proprietar_Proprietate se aduce n 3NF prin eliminarea dependenei tranzitive: - atributul determinat, dependent funcional tranzitiv se mut n alt relaie (tabel), mpreun cu determinantul su: Proprietar (Nr_Proprietar, NumeP) - tabelul iniial sub alt nume - i pstreaz cheia primar iniial, i acele atribute care au nu au dependen funcional tranzitiv de cheia primar: Proprietate_de_Inchiriat (Nr_Proprietate, AdresaP, Chirie, Nr_Proprietar)

Relaiile (tabelele) 3NF derivate din relaia (tabelul) Proprietate_Proprietar Cele 2 noi tabele se afl n 3NF, deoarece nu conin dependene tranzitive ale unor atribute de cheia primar. Relaia Client_Inchiriere (fig. 1.32) aflat n 1NF: Client_Inchiriere (Nr_Client, Nr_Proprietate, NumeC, AdresaP, InceputInchir, SfarsitInchir, Chirie, Nr_Proprietar, NumeP) a fost supus procesului de normalizare i descompus n 4 relaii (tabele) 3NF: Client (Nr_Client, NumeC) Inchiriere (Nr_Client, Nr_Proprietate, InceputInchir, SfarsitInchir) Proprietate_de_Inchiriat (Nr_Proprietate, AdresaP, Chirie, Nr_Proprietar) Proprietar (Nr_Proprietar, NumeP) Procesul de normalizare este ilustrat n figura de mai jos:
48

Descompunerea relaiei (tabelului) 1NF: Client_Inchiriere n relaii (tabele) 3NF Relaia iniial Client_Inchiriere poate fi recreat prin uniunea relaiilor (tabelelor) 3 NF rezultate n urma normalizrii. Aceasta se realizeaz prin mecanismul cheie primar cheie strin. De exemplu atributul Nr_Proprietar este cheie primar n relaia (tabelul) Proprietar i cheie strin n relaia (Tabelul) Proprietate_de-nchiriat. Relaiile (tabelele) sunt prezentate n figura de mai jos:

Relaiile (tabelele) 3NF derivate din relaia (tabelul) Client-Inchiriere 1.5.8 Rezumatul capitolului 1.5 Normalizarea este o tehnic de realizare a unui set de relaii cu proprieti adecvate, avndu-se n vedere cerinele unei ntreprinderi privind datele. Normalizarea este o metod formal, ce poate fi utilizat pentru identificarea relaiilor, bazndu-se pe cheile i dependenele funcionale dintre atributele acestora. Relaiile cu redundan de date pot suferi din cauza anomaliilor de reactualizare, care se clasific n anomalii de inserare, tergere i modificare. Normalizarea este legat de conceptul de dependen funcional, care descrie legturile dintre atributele unei relaii. Dac A i B sunt atribute ale relaiei R, atributul B este dependent funcional de A (A B) dac fiecrei valori a atributului A i este asociat exact o valoare atributului B (A i B pot fi formate din mai multe atribute fiecare).
49

Un determinant este orice atribut de care un alt atribut este total dependent funcional. Determinantul unei dependene funcionale se refer la atributul (grupul de atribute) din partea stng a sgeii. Procesul de normalizare face ca relaia s treac prin diverse forme normale. n fiecare etap a normalizrii se elimin caracteristici indezirabile din relaie, care o fac sensibil la anomalii de reactualizare. Forma nenormalizat (UNF) este un tabel cu unul sau mai multe grupuri repetitive. Prima form normal (1NF) este o relaie n care la intersecia dintre fiecare rnd cu fiecare coloan apare o singur valoare. A doua form normal (2NF) este o relaie (tabel) care se afl n 1NF i n care fiecare atribut care nu este cheie primar este total dependent de cheia primar. Dependena funcional total arat c dac A i B sunt atribute ale unei relaii (tabel), B este total dependent funcional de A dac B este dependent funcional de A, dar nu i de orice submulime adecvat a lui A. A treia form normal (3NF) este o relaie (tabel) care se afl n 1NF i 2NF, n care nici un atribut care nu este cheie primar nu este dependent tranzitiv de cheia primar. Dependena tranzitiv este situaia n care ntre trei atribute A, B i C ale unei relaii (tabel) exist dependenele funcionale: A B i B C, adic C este dependent tranzitiv de A prin intermediul lui B (cu condiia ca A s nu fie dependent funcional de B sau C). 1.5.9 ntrebri la capitolul 1.5 Descriei scopul normalizrii datelor. Descriei problemele ce decurg din redundana datelor. Descriei conceptul de dependen funcional. Cum este legat conceptul de dependen funcional de procesul de normalizare? Definii prima, a doua i a treia form normal.

1.6 Metodologia de proiectare conceptual a bazelor de date

Proiectarea unei baze de date cuprinde urmtorii pai: Pasul 1: proiectarea conceptual Paii 2 i 3: proiectarea logic Paii 4, 5, 6, i 7: proiectarea fizic. Proiectarea conceptual a bazei de date este procesul de construire a unui model al informaiilor utilizate n ntreprindere, independent de consideraiile de ordin fizic (SGBDul utilizat). 1.6.1 Pasul 1. Construirea modelului de date conceptual local pentru fiecare vedere a utilizatorilor De regul vederea unui utilizator este o zon funcional a ntreprinderii (de exemplu producia, marketingul, vnzrile, resursele umane, contabilitatea, aprovizionarea etc.). utilizatorul este o persoan real individual sau un grup de persoane. identificarea vederilor utilizatorilor se realizeaz prin examinarea diagramelor de flux i prin chestionarea utilizatorilor.

50

Modelul de date conceptual corespunztor vederii unui utilizator se numete model de date conceptual local corespunztor vederii respective. Fiecare model de date conceptual local cuprinde elementele enumerate n tabelul de mai jos, din care se desprind sarcinile de proiectare conceptual. Elemente ale modelului de date Sarcini pentru construirea modelului conceptual local conceptual local (Pai) Tipuri de entiti 1.1. Identificarea tipurilor de entiti (t.e.) Tipuri de relaii 1.2. Identificarea tipurilor de relaii (t.r.) Atribute 1.3. identificarea i asocierea atributelor cu t.e. i t.r. Domeniile atributelor 1.4. Determinarea domeniilor atributelor Cheile candidat 1.5. Determinarea atributelor chei candidat i chei primare Cheile primare 1.6. Specializarea/generalizarea t.e. (opional) 1.7. Desenarea diagramei ER 1.8. Revizuirea modelului conceptual local cu utilizatorii Pasul 1.1 Identificarea tipurilor de entiti (t.e.) Modaliti de identificare: - studierea specificaiei cerinelor utilizatorului referitor la funcia utilizatorului n ntreprindere; se caut substantivele n specificaia cerinelor utilizatorului (de exemplu Nr_Personal; NumeP; Nr_Proprietate; AdresaP; Chirie etc.) - se caut obiectele principale de interes, excluzndu-se calitile; se grupeaz (de exemplu Nr_Personal i NumeP vor aparine aceluiai tip de entitate Personal) - se identific obiectele care exist pe cont propriu (de exemplu Personal exist indiferent de Nr_Personal, NumeP, etc.) - discuii cu utilizatorii (de exemplu pentru eliminarea sinonimelor: Angajat = Personal) Documentarea t.e.: dup identificarea t.e. li se atribuie denumiri evidente, care se trec ntr-un dicionar de date. Pasul 1.2 Identificarea tipurilor de relaii (t.r.) - Identificarea relaiilor: de regul relaiile sunt indicate de expresii verbale n specificaia utilizatorului. De exemplu: filiale are personal; personal administreaz proprietate; chiria viziteaz proprietate etc. Intereseaz numai relaiile dintre entiti cerute. Majoritatea relaiilor sunt binare. Este bine de verificat fiecare pereche de tipuri de entiti, pentru a gsi o posibil relaie ntre ele. - Determinarea cardinalitii (1:1; 1:M; M:N) i constrngerilor de participare (total, parial); eventual se specific i valorile limit ale cardinalitii. - Documentarea tipurilor de relaii. Pe msur ce sunt identificate, li se atribuie denumiri evidente; acestea, precum i constrngerile se trec n dicionarul de date. - Vizualizarea pe parcurs a t.e. i t.r. identificate prin modelarea ER. Pasul 1.3 Identificarea i asocierea atributelor cu t.e. sau t.r. - Identificare: Se caut substantive sau expresii substantivale n specificaia cerinelor utilizatorilor care s caracterizeze t.e. i t.r. gsite. Atributele sunt proprieti, caliti, caracteristici identificatoare ale unei entiti sau relaii. Se deosebete ntre atribute simple, compuse, derivate. Atributele derivate trebuie reprezentate n modelul conceptual pentru a nu pierde informaii. - Documentarea atributelor: pe msur ce sunt identificate li se atribuit denumiri evidente i semnificative pentru utilizatori. Pentru fiecare atribut se trec n dicionarul de date: denumirea, sinonime sau aliasuri, tipul de date i lungimea, eventuale valori prestabilite (default value), dac
51

se accept Null-uri (required), dac e compus sau derivat, formula de calcul, dac are valori multiple. Pasul 1.4 Determinarea domeniilor atributelor - Determinarea: Domeniul este un recipient de valori din care unul sau mai multe atribute i iau valorile. De exemplu domeniul numerelor de filial valabile este compus din 3 caractere, litercifr-liter. Domeniul va include i mulimea valorilor permise, dimensiunea i formatul cmpului. - Documentarea domeniului atributelor: se nregistreaz denumirea i caracteristicile domeniilor atributelor n dicionarul de date. Pasul 1.5 Determinarea atributelor chei candidat i chei primare - identificare: pentru fiecare entitate se identific toate cheile candidat i se secioneaz dintre ele cheia primar. O cheie candidat este o submulime minim de atribute ale unei entiti, care identific n mod unic fiecare apariie a acesteia. Cheia primar aleas va ndeplini urmtoarele 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 puine caractere o va fi cheia candidat cel mai uor de utilizat d.p.d.v. al utilizatorilor Unei entiti tari i se poate identifica o cheie primar, nu i unei entiti slabe. Unei entiti slabe i se poate identifica o cheie primar numai prin plasarea n ea a unei chei strine, n cadrul relaiei sale cu entitatea tare. Cheile candidat care nu sunt selectate cheie primar devin chei alternative. - Documentarea cheilor primare i alternative prin nregistrare n dicionarul de date. Pasul 1.6 Specializarea/generalizarea tipurilor de entiti (opional) Acest pas este dictat de reprezentarea ct mai clar a entitilor importante i a relaiilor dintre ele. Diagrama ER final trebuie s fie ct mai lizibil. Modelul ER din figura 1.34 a conine entitile Proprietate_de_Inchiriat i Proprietate_de_Vanzare. Se generalizeaz prin crearea entitii Proprietate (fig. 1.34 b.)

52

Fig. 1.34. Exemplu de generalizare a tipului de entitate Entitile Proprietate_de_Inchiriat i Proprietate_de_Vanzare devin subclase ale entitii Proprietate n baza atributelor comune (Tipul, Adresa, cheia primar) i n baza relaiilor comune asociate fiecreia (Proprietar_deine_Proprietate). Entitile subclas au i atribute diferite (Chirie respectiv Pre) i relaii diferite (Inchiriaza respectiv Cumpara). Pasul 1.7 Desenarea diagramei ER Diagrama ER care se deseneaz va fi reprezentarea conceptual a vederii unui utilizator asupra ntregii ntreprinderi. Diagrama ER va reprezenta modelul de date conceptual local bazat pe o anumit vedere a utilizatorului asupra ntreprinderii. Pasul 1.8 Revizuirea modelului de date conceptual local mpreun cu utilizatorii
53

Acest pas este necesar pentru a garanta c modelul este o reprezentare adevrat a ntreprinderii d.p.d.v. al utilizatorului. 1.6.2 Rezumatul capitolului 1.6 Proiectarea conceptual a bazei de date este procesul de construire a unui model al informaiilor utilizate n ntreprindere, independent de consideraiile de ordin fizic. Proiectarea conceptual ncepe prin crearea unui model de date conceptual al ntreprinderii, complet independent de detaliile de implementare. Pentru fiecare vedere a utilizatorilor asupra ntreprinderii este creat un model de date conceptual local. O vedere a utilizatorului const n datele cerute de ctre un anumit utilizator pentru a lua o decizie sau a efectua o anumit sarcin. De regul vederea unui utilizator este o zon funcional a ntreprinderii. Un utilizator poate fi o persoan sau un grup de persoane care utilizeaz n mod direct sistemul. Vederile utilizatorilor se pot identifica utiliznd diagrame de flux de date care definesc zonele funcionale i eventual funciile individuale sau/i prin chestionarea utilizatorilor, examinarea procedurilor, rapoartelor i observarea ntreprinderii. Fiecare model de date conceptual local cuprinde tipurile de entiti, tipurile de relaii, atributele, domeniile atributelor, cheile candidat i primare. Fiecare model de date conceptual local este susinut de ctre o documentaie, cum ar fi dicionarul de date, care este realizat pe parcursul dezvoltrii modelului. 1.6.3 ntrebri la capitolul 1.6 Descriei principalele faze implicate n proiectarea BD. Analizai rolul important al utilizatorilor n procesul de proiectare al bazelor de date. Descriei principalul obiectiv al proiectrii conceptuale a bazelor de date. Descriei ce reprezint o vedere a utilizatorului i cum pot fi identificate diferitele vederi. Identificai principalele sarcini asociate proiectrii conceptuale a bazelor de date. Identificai i descriei scopul documentaiei generate pe parcursul proiectrii conceptuale a bazelor de date.

1.7 Metodologia de proiectare logic a bazelor de date pentru modelul relaional

Proiectarea logic este procesul de construire a unui model al informaiilor utilizate n ntreprindere pe baza unui anumit model de date, dar independent de SGBD i de alte consideraii de ordin fizic. 1.7.1 Pasul 2. 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). Se efectueaz modificarea structurii modelului conceptual conform cerinelor modelului de date relaional (conform cerinelor caracteristice unui sistem de gestionare relaional).
54

Pasul 2.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. Pasul 2.1.1 Eliminarea relaiilor de tip M:N O relaie M:N (de mai muli la mai muli) se descompune pentru a identifica o relaie intermediar. Relaia M:N se nlocuiete cu dou relaii 1:M. Exemplu: Relaia Ziar Face Reclama Proprietate (fig. 1.35 a) este de cardinalitate M:N, deoarece un ziar poate face reclam mai multor proprieti, iar unei proprieti i se poate face reclam in mai multe ziare. Relaia se descompune conform figurii 1.35 b, unde Reclama este o entitate slab a crei existen depinde de existena celorlalte dou entiti tari.

Fig. 1.35 Relaia de cardinalitate M:N se descompune n 2 relaii de cardinalitate 1:M Apar dou tipuri de relaii noi: Listeaza i respectiv ReclamaIn care leag entitatea slab de cele 2 entiti tari. Analizai constrngerile de participare din fig. 1.35 a i 1.35. b! Pasul 2.1.2 Eliminarea relaiilor complexe O relaie complex include cel puin trei tipuri de entiti. Ea trebuie descompus pentru a identifica o relaie intermediar. Relaia complex se nlocuiete cu un numr corespunztor de relaii binare de cardinalitate 1:M. n exemplul din figura 1.36 relaia complex Inchiriaza s-a descompus n trei relaii 1:M, anume Organizeaza, AsociatCu i ine; s-a identificat o entitate slab: Acord_de_Inchiriere care este legat de entitile tari (iniiale) prin cele trei relaii binare de cardinalitate 1:M identificate. Analizai constrngerile de participare din fig. 1.36 a i 1.36. b!

55

Fig. 1.36. Relaie complex M:N descompus n trei relaii binare 1:M. Pasul 2.1.3 Eliminarea relaiilor recursive Acesta este un tip particular de relaie care trebuie descompus pentru a identifica o relaie intermediar. n exemplul din figura 1.37 relaia recursiv Supravegheaza este eliminat prin identificarea unei relaii adiionale denumit SupravegheatDe i a unei entiti slabe: Personal_Alocat. Analizai constrngerile de participare din fig. 1.37 a i 1.37. b!

56

Fig. 1.37. Eliminarea unei relaii recursive Pasul 2.1.4 Eliminarea relaiilor cu atribute Atunci cnd o relaie are asociat un atribut, acest lucru sugereaz existena unui tip de entitate neidentificat. Exemplul din figura 1.38 se refer la determinarea numrului de ore lucrate de angajaii temporari atribuii fiecrei filiale. Relaia LucreazaLa are atributul Ore-Lucrate i este de cardinalitate M:N. Se descompune n dou relaii binare de cardinalitate 1:M. Acum atributul Ore_Lucrate aparine noii entiti slabe identificate: Alocaie_Filiala. Analizai constrngerile de participare din fig. 1.38 a i 1.38. b!

57

Fig. 1.38. Eliminarea unei relaii cu atribut Pasul 2.1.5 Eliminarea atributelor cu valori multiple Este vorba de atribute cu mai multe valori pentru o singur entitate. Acest atribut trebuie descompus pentru a identifica o nou entitate. Exemplul din figura 1.39 se refer la evidena filialelor, unde o filial poate avea mai multe numere de telefon. Se identific o nou entitate: Telefon, legat de entitatea Filiala prin relaia Are. Discutai posibilitatea declarrii entitii Telefon ca entitate slab i a constrngerii de participare a entitii Filiala ca parial. Fig. 1.39. Eliminarea atributelor cu valori multiple Pasul 2.1.6 relaiilor 1:1 Reexaminarea

Asemenea relaii pot indica existena a dou relaii care s reprezinte acelai obiect n cadrul ntreprinderii. De exemplu entitile Filiala i departament pot fi sinonime. n astfel de situaii cele dou entiti se mbin, selectnd una din cheile primare, dac acestea nu coincid. Cealalt cheie primar devine alternativ. Pasul 2.1.7 Eliminarea relaiilor redundante O relaie este redundant atunci cnd aceeai informaie se poate obine i prin alte relaii. Trebuie deci de aflat dac exist mai mult dect o singur cale ntre dou entiti. Dac se identific 2 ci, nu nseamn neaprat c una din relaii este redundant. Trebuie de inut cont i de semnificaia temporal a relaiilor. n exemplul din figura 1.40 relaia este neredundant, dei exist 2 ci intre entitatea Copil i Barbat. Tatl ar putea avea copii dintr-o cstorie precedent, sau ar putea s nu fie cstorit cu mama copilului, iar n figur se modeleaz numai cstoria curent a tatlui.

Fig. 1.40. Relaie neredundant! Pasul 2.2 Extragerea relaiilor (tipurilor de entiti) din modelul de date logic local n urma pasului 2.1 s-a obinut modelul de date logic local, ca urmare a rafinrii modelului de date conceptual.
58

La pasul 2.2. se extrag relaiile pentru a reprezenta entitile care le compun. Componena fiecrei relaii va fi descris utiliznd un limbaj de definire a bazelor de date (DBDL). ntr-un DBDL apare denumirea relaiei, apoi ntre paranteze atributele simple. Se identific cheia primar, cheile alternative i/sau cheile strine ale relaiei. Se trece relaia care conine cheia strin ca i cheie primar. Relaia pe care o entitate o are cu alt entitate este exprimat prin mecanismul cheie primar cheie strin. Adic cheia primar din entitatea printe devine cheie strin n entitatea copil. n continuare se prezint cum relaiile care reprezint entitile i relaiile acestora sunt extrase din structurile de date posibile, prezentate n modelul de date logic (fig. 1.41).

Fig. 1.41. Model de date logic Din acest model de date logic se extrag: a. Tipuri de entiti tari: Pentru fiecare entitate tare (obinuit) se creeaz o relaie care s cuprind toate atributele sale simple. Exemplu: entitatea tare Personal Personal (Nr_Personal, Prenume, Nume, Strada, Orasul, CodP, Functia, Sex, Salariu) Cheie primar Nr_Personal b. Tipuri de entiti slabe: Ruda_Apropiata. Pentru fiecare entitate slab se creeaz o relaie care s cuprind toate atributele sale simple. n plus se include cheia primar a entitii printe (sau proprietar) ca i cheie strin. Compoziia acestei relaii va fi: Ruda_Apropiata (Nr_Personal, NumeR, Adresa, Nr_Tel, Rudenie) Cheie primar Nr_Personal mpreun cu NumeR
59

Cheie strin Nr_Personal se refer la Personal (Nr_Personal) c. Tipuri de relaii binare unu la unu (1:1) n relaia de cardinalitate 1:1 Personal Administreaza Filiala entitatea printe este Personal, deoarece are participare parial. Ca urmare se plaseaz o copie a cheii primare din Personal n Filiala, unde devine cheie strin sub denumirea Nr_Personal_Manager. Compoziia acestor relaii va fi: Personal (Nr_Personal, Prenume, Nume, Strada, Orasul, CodP, Functia, Sex, Salariu) Cheie primar Nr_Personal Filiala (Nr_Filiala, Adresa, Nr_Tel, Nr_Fax, Nr_Personal_Manager) Cheie primar Nr_Filiala Cheie alternativ Nr_Tel sau Nr_Fax Cheie strin Nr_Personal_Manager, care se refer la Personal (Nr_Personal) d. Tipuri de relaii binare unu-la-mai-muli (1:M) Pentru fiecare relaie binar 1:M ntre entitile E1 i E2 se plaseaz o copie a cheii primare din E1 n E2, unde devine cheie strin. Entitatea aflat n partea notat cu 1 este entitatea printe, iar cea din partea cu M este entitatea copil. ntotdeauna cheia primar din entitatea printe devine cheie strin n entitatea copil. Exemplu: Filiala Are Personal, unde Filiala este printe iar personal este copil. Compoziia acestor relaii va fi:
Personal (Nr_Personal, Prenume, Nume, Strada, Orasul, CodP, Functia, Sex, Salariu, Nr_Filiala)

Cheie primar Nr_Personal Cheie strin Nr_Filiala se refer la Filiala (Nr_Filiala) Filiala (Nr_Filiala, Adresa, Nr_Tel, Nr_Fax, Nr_Personal_Manager) Cheie primar Nr_Filiala Cheie alternativ Nr_Tel sau Nr_Fax Cheie strin Nr_Personal_Manager, care se refer la Personal (Nr_Personal) Pasul 2.2. se ncheie cu documentarea relaiilor i atributelor chei strine. Compoziia relaiilor extrase din modelul de date logic se documenteaz utiliznd DBDL. Sintaxa poate fi extins pentru a exprima constrngerile de integritate asupra cheilor strine (vezi pasul 2.6). i dicionarul de date trebuie reactualizat cu noile atribute cheie identificate la pasul 2.2 Pasul 2.3 Validarea modelului prin utilizarea normalizrii Normalizarea este o procedur de stabilire a atributelor care aparin mpreun unui tip de entitate. Prin normalizare datele sunt organizate conform dependenelor lor funcionale i se elimin riscul anomaliilor de reactualizare. n prima form normal se elimin grupurile repetitive. Pasul 2.4 validarea modelului conform tranzaciilor utilizatorului
60

Modelul trebuie s accepte tranzaciile cerute de ctre vederile utilizatorului. Tranzaciile se determin din specificaiile cerinelor utilizatorilor. Prin folosirea diagramei ER, a dicionarului de date i a legturilor cheie primar/cheie strin prezentate n relaii se ncearc efectuarea manual a tranzaciilor. Pasul 2.5 Desenarea diagramei ER Se deseneaz varianta final a diagramei ER, validat prin normalizare i conform cu tranzaciile pe care trebuie s le accepte. Pasul 2.6 Definirea constrngerilor de integritate Prin impunerea de constrngeri se protejeaz baza de date fa de riscul de incoeren. Se consider 5 tipuri de integritate, anume referitoare la: a. datele cerute b. domeniile atributelor c. integritatea entitilor d. integritatea referenial e. constrngerile ntreprinderii a. Datele cerute Unele atribute nu admit Null-uri. n aceste situaii se selecteaz proprietatea de cmp required, care cere date pentru cmpul respectiv. Se verific dac aceste constrngeri au fost identificate i documentate n dreptul atributelor n dicionarul de date (vezi pasul 1.2) b. Constrngerile privind domeniile atributelor Se verific dac s-au identificat i documentat la pasul 1.4 c. Integritatea entitilor Cheia primar a unei entiti nu poate conine Null-uri. Se verific pasul 1.5 d. Integritatea referenial Se refer la relaia entitate printe entitate copil. Se tie c cheia primar din printe se copiaz n copil unde devine cheie strin. Integritatea referenial nseamn ca o valoare nenul a cheii strine din entitatea copil trebuie s se refere la (s coincid cu) o valoare existent n entitatea printe. Dac entitatea copil are participare total n relaie, nu sunt permise Null-uri n cmpul cheie strin. Se admit atunci cnd entitatea copil are participare parial. Asigurarea integritii refereniale se realizeaz prin constrngeri de existen. Acestea definesc condiiile n care poate fi inserat, reactualizat (modificat) sau tears o cheie candidat sau o cheie strin. Se ia ca exemplu relaia Personal Administreaz Proprietate, de cardinalitate 1:M. Entitate printe (Ep): Personal, cheie primar: Nr_Personal Entitate copil (Ec): Proprietate, cheie strin: Nr_Personal, copie a cheii primare din Personal.
61

Cazul 1. Inserarea unei apariii n relaia (entitatea) copil Pentru a asigura integritatea referenial se verific dac atributul Nr_Personal din apariia nou inserat n Ec este stabilit ca Null sau are o valoare existent n Ep. Cazul 2. tergerea unei apariii din relaia (entitatea) copil Se poate efectua fr probleme, nu afecteaz integritatea referenial. Cazul 3. Reactualizarea cheii strine n relaia (entitatea) copil Similar cazului 1. Cazul 4. Inserarea unei apariii n relaia (entitatea) printe Se poate efectua fr probleme. Ep are participare parial, deci poate exista un membru al personalului care nu administreaz o proprietate. Cazul 5. tergerea unei apariii din relaia (entitatea) printe. Dac apariie care urmeaz a fi tears din Ep i corespunde o apariie (sau mai multe) din Ec, atunci integritatea referenial se pierde prin tergere. Posibile strategii de luat n considerare: NO ACTION CASCADE SET NULL Blocarea tergerii apariiei din Ep, dac are corespondent(i) n Ec Dac o apariie n Ec se terge, se terg automat corespondenii din Ec. Dac Ec acioneaz ca Ep n alt relaie, tergerea se propag n cascad. Cnd se terge o apariie din Ep, valorile cheii strine n Ec sunt setate la Null. Are loc o reactualizare prin setare la Null a valorilor atributelor selectate din cheia strin a Ec. Aceast strategie se poate aplica numai dac atributele cheie strin accept Null-uri. Cnd se terge o apariie din Ep, valorile cheii strine corespunztoare din Ec sunt setate la valori prestabilite (default). Exemplu: se terge un membru al personalului n Ep (Personal) i automat proprietile pe care acestea le-a administrat trecute n Ec (Proprieti) se seteaz la atributul Nr_Pers la valoarea corespunztoare managerului. Nu are loc nici o verificare de integritate. Cnd se terge o apariie din Ep nu este garantat meninerea integritii refereniale.

SET DEFAULT

NO CHECK

Cazul 6. Reactualizarea cheii primare n relaia (entitatea) printe Dac valorii reactualizate a cheii primare n Ep i corespundeau una (mai multe) valori ale cheii strine n Ec, integritatea referenial este pierdut. Se va aplica una din strategiile de la cazul 5. e. Constrngerile ntreprinderii Sunt de fapt regulile de afaceri care pot uneori genera reactualizri ele entitilor. De exemplu agenia imobiliar poate stabili ca un membru al personalului s administreze maxim 10 proprieti. Pasul 2.6. se ncheie cu documentarea tuturor constrngerilor de integritate. Aceasta se face n dicionarul de date, pentru a fi luate n considerare la implementarea fizic. Pasul 2.7 Revizuirea modelului de date logic local mpreun cu utilizatorii
62

Se verific dac modelul de date logic local este o reprezentare adevrat a vederii utilizatorului. Modelul de date logic local trebuie s fie complet i in ntregime documentat. Modelul i documentaia se revd mpreun cu utilizatorul.

1.7.2 Pasul 3. Construirea i validarea modelului de date logic global n aceast etap se construiete un model de date logic global prin mbinarea modelelor de date logice locale individuale, care au fost realizate pentru a reprezenta fiecare vedere a utilizatorilor. Dup mbinare trebuie rezolvate conflictele dintre vederi, ca i orice suprapuneri existente. Va rezulta o reprezentare a ntregii ntreprinderi independent de orice utilizator sau aplicaie. Pasul 3.1 mbinarea modelelor de date logice locale individuale ntr-un singur model de date logic global al ntreprinderii (1) Revizuirea denumirilor entitilor i cheilor primare din modelele locale. Pot exista dou sau mai multe entiti care au aceeai denumire dar sunt de fapt diferite, respective acre au denumiri diferite, dar sunt aceleai. Se compar coninutul de date al fiecrui tip de entitate. Se utilizeaz cheile primare pentru a identifica tipurile de entiti echivalente, dar cu denumiri diferite. (2) Revizuirea denumirilor relaiilor. Se procedeaz ca la (1). (3) mbinarea entitilor din vederile locale mbinarea entitilor cu aceeai denumire i aceeai cheie primar (fig. 1.42) Astfel de entiti reprezint de regul acelai obiect n lumea real. La fuziune se includ atributele entitilor iniiale, eliminndu-se dublurile.

Fig. 1.42. mbinarea entitilor cu aceeai denumire i aceeai cheie primar n versiunea global obinut prin mbinare s-a utilizat versiunea descompus a atributului Nume_Prenume (n urma consultrii cu utilizatorii). mbinarea entitilor cu aceeai denumire i chei primare diferite (fig. 1.43)
63

Astfel de entiti nu au aceeai cheie primar, dar au chei candidat similare. Rezult aceeai vedere global ca n fig. 1.42.

Fig. 1.43. mbinarea entitilor cu aceeai denumire i chei primare diferite mbinarea entitilor cu denumiri diferite, cu chei primare similare sau diferite Astfel de entiti se pot identifica atunci cnd: denumirile sunt diferite, dar indic acelai scop, dup cheia primar, dup participarea n anumite relaii. Exemplu: Entitile Personal i Angajai. (4) Includerea (fr mbinare) a entitilor unice din fiecare vedere local Toate entitile care nu au echivalent se includ nemodificate n modelul global. (5) mbinarea relaiilor din vederile locale Se examineaz toate relaiile (denumire, scop, constrngeri structurale) din toate vederile locale i se elimin conflictele, prin: - mbinarea relaiilor cu aceeai denumire i acelai scop, apoi - mbinarea relaiilor cu denumiri diferite dar acelai scop (6) Includerea (fr mbinare) a relaiilor unice din fiecare vedere local Relaiile pentru care nu s-au gsit relaii identice n alte vederi se includ nemodificate n modelul global. (7) Cutarea entitilor i relaiilor lips Identificarea entitilor i relaiilor lips dintre diversele vederi ale utilizatorilor i care nu apar n nici una dintre vederi este o operaiune dificil: Acestea pot rezulta din modelul de date general, dac exist. Cnd se consult utilizatorii asupra unei anumite vederi, ei trebuie rugai s examineze i entitile i relaiile din alte vederi. Se examineaz atributele fiecrui tip de entitate i se compar cu atributele entitilor din alte vederi. Poate exista un atribut al unei entiti dintr-o vedere care corespunde unui atribut cheie primar, cheie alternativ sau unui atribut simplu al unei entiti din alt vedere. Dintr-o astfel de coresponden rezult existena unei relaii neidentificate, construibil prin mecanismul cheie primar/cheie strin. (8) Verificarea cheilor strine Se verific dac cheile strine din entitile copil mai sunt corecte i se efectueaz modificrile necesare.
64

(9) Verificarea constrngerilor de integritate Se verific dac constrngerile de integritate ale modelului global nu intr n conflict cu constrngerile de integritate din vederile utilizatorilor. Conflictele se rezolv prin consultarea cu utilizatorii. (10) Desenarea modelului de date logic global Se deseneaz diagrama ER a modelului de date logic global, care reprezint mbinarea tuturor modelelor de date logica locale. (11) Reactualizarea documentaiei Documentaia trebuie reactualizat n urma modificrilor intervenite la realizarea modelului global. Documentaia trebuie s reflecte ntotdeauna modelul de date curent. Pasul 3.2 Validarea modelului de date logic global Se realizeaz prin utilizarea normalizrii i conform tranzaciilor cerute, dac este necesar. Este un pas echivalent cu 2.3 respectiv 2.4, anume se fac aceleai validri dar acum pentru modelul de date logic global. Pasul 3.3 Verificarea n vederea dezvoltrii locale Se determin dac este probabil ca n viitorul previzibil s apar modificri i se evalueaz capacitatea modelului de date logic global de a cuprinde aceste modificri. Modelul de date logic global trebuie s poat fi extins cu uurin. Modelul creat trebuie s fie extensibil, s poat evolua n condiiile afectrii minime a utilizatorului. Se incorporeaz modificri numai dac utilizatorul o cere. Pasul 3.4 Desenarea diagramei ER finale Diagrama ER final reprezint modelul de date logic global al ntreprinderii. Se deseneaz dup ce modelul de date logic global a fost validat. Documentaia (schema relaional i dicionarul de date) trebuie reactualizat i completat. Pasul 3.5 Revizuirea modelului de date logic global mpreun cu utilizatorii Revizuirea va garanta faptul c modelul de date logic global este o reprezentare adevrat a ntreprinderii. Modelul mpreun cu documentaia se revizuiesc n colaborare cu utilizatorii, pentru a confirma c sunt corecte i complete.

1.7.3 Rezumatul capitolului 1.7 Proiectarea logic a bazelor de date este procesul de construire a unui model al informaiilor utilizate n cadrul unei ntreprinderi, bazat pe un anumit model de date, dar independent de un anumit SGBD i de alte consideraii de ordin fizic. Principalele etape cuprind: construirea i validarea unui model de date logic local corespunztor fiecrei vederi a utilizatorilor (pasul 2) i construirea i validarea unui model de date logic global (pasul 3). Rafinarea unui model de date conceptual pentru a obine un model de date logic include: eliminarea relaiilor de tip M:N, a relaiilor complexe, recursive, cu atribute, a atributelor cu valori multiple, reexaminarea relaiilor de tip 1:1 i eliminarea relaiilor neredundante. Modelul de date logic se valideaz prin normalizare, prin care se garanteaz c modelul reprezint fidel ntreprinderea, este coerent, cu redundan minim i stabilitate maxim.
65

Constrngerile de integritate se impun pentru a proteja BD fa de a deveni incoerent. Exist 5 tipuri de constrngeri de integritate: asupra datelor necesare, ale domeniilor atributelor, de integritate a entitilor, de integritate referenial i ale ntreprinderii. Integritatea referenial se asigur prin constrngeri de existen, care definesc n ce condiii poate fi o cheie candidata sau strin inserat, reactualizat sau tears. Exist mai multe strategii care pot fi aplicate atunci cnd o apariie a entitii printe pe care vrem s o tergem are corespondent n entitatea copil: NO ACTION, CASCADE, SET NULL, SET DEFAULT i NO CHECK. Constrngerile ntreprinderii se numesc uneori i reguli de afaceri. Modelul de date logic este susinut de ctre documentaie, cum ar fi dicionarul de date sau schema relaional, care sunt realizate pe parcursul construirii modelului. 1.7.4 ntrebri la capitolul 1.7 Analizai scopul proiectrii logice a bazelor de date. Descriei etapele rafinrii modelului de date conceptual pentru a se obine modelul de date logic Descriei regulile de extragere a relaiilor care reprezint tipuri de entiti tari i slabe, tipuri de relaii binare 1:1, 1:m. Analizai modul in care tehnica de normalizare poate fi utilizat pentru a valida modelul de date logic. Descriei scopul constrngerilor de integritate i artai care sunt cele 5 tipuri principale de constrngeri. Descriei strategiile alternative aplicabile atunci cnd exist o apariie a Ec care se refer la o apariie a Ep pe care vrem s-a tergem. Identificai sarcinile asociate cu mbinarea modelelor de date logice locale, pentru obinerea modelului de date logic global.

1.8 Metodologia de proiectare fizic a bazelor de date pentru bazele de date relaionale
Proiectarea fizic a bazelor de date este procesul de descriere a implementrii bazei de date ntr-o capacitate de stocare secundar; se descriu structurile de stocare i metodele de acces utilizate pentru asigurarea unui acces eficient la date. 1.8.1 Pasul 4. Transformarea modelului de date logic global pentru un SGBD int Acest pas presupune transformarea relaiilor extrase din modelul de date logic global ntr-o form care s poat fi implementat in SGBD int. Este necesar cunoaterea funcionalitii SGBD int, de exemplu: - dac sistemul accept definirea cheilor primare, strine i alternative; - dac sistemul accept definirea datelor necesare (adic a unor atribute ca fiind NOT NULL) - dac sistemul accept definirea domeniilor - dac sistemul accept definirea constrngerilor ntreprinderii - cum se creeaz relaiile de baz.
66

Pasul 4.1 Proiectarea relaiilor de baz pentru SGBD int Trebuie confruntate i asimilate informaiile referitoare la relaii (tabele) obinute prin modelarea logic a datelor. Aceste informaii sunt obinute din definiia relaiilor (n DBDL) i din dicionarul de date. Pentru fiecare relaie identificat n modelul de date logic global vom avea o definiie format din: - denumirea relaiei - list de atribute simple (ntre paranteze) - cheia primar (PK), i dup caz, cheile alternative (AK) i cheile strine (FK) - constrngerile de integritate corespunztoare oricrei chei strine (FK) identificate Din dicionarul de date, pentru fiecare atribut exist i: - domeniul atributului, care const din tipul de date, lungimea acestora i constrngeri asupra domeniului - opional, o valoare prestabilit a atributului - dac atributul poate conine NULLuri - dac atributul este derivat, i n acest caz cum trebuie calculat. De exemplu n cazul BD a ageniei imobiliare discutat, proiectul pentru relaia de baz (tabelul) Proprietate_de_nchiriat, n DBDL, pentru implementarea cu ajutorului SGBD MS-Access este redat n figura de mai jos.

67

Proiectul logic iniial a fost adaptat funcionalitii SGBD int (MS-Access). n continuare sunt prezentate cteva exemple ale acestui proces de adaptare (rafinare):

68

Atributul Nr_Proprietate (PK)

Proiectul logic ir variabil de caractere, max. 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. MSAccess Tip de date Text, 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

Explicaii Access nu deosebete ntre iruri de caractere cu lungime fix i variabil Access nu accept ca o aceeai FK dintr-un tabel copil s bat n 2 tabele printe diferite (integrit. ref.) 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, pornind de la Blank Database. Modul de creare a tabelelor (relaiilor) n MS_Access este detaliat n partea a doua a cursului. Mai jos este prezentat vizualizarea de proiectare (Design View) a tabelului corespunztor relaiei Proprietate_de_nchiriat.

69

n cadrul tabelelor: - se specific cheia primar - se seteaz proprietile cmpurilor: field size, format, input mask, caption, default value, validation rule/text, required. - Se creeaz liste de tip lookup, ca cea pentru tipul de proprietate:

O dat create toate tabelele proiectate, se realizeaz relaiile dintre acestea i se impune integritatea referenial.

70

Cascade Update Related Fields: modificarea unei valori din cheia primar din tabelul printe declaneaz automat reactualizarea valorilor corespunztoare din toate nregistrrile legate. Cascade Delete Related Records: tergerea unei nregistrri din tabelul printe duce la tergerea tuturor nregistrrilor legate din tabelul copil. Pasul 4.1 se ncheie cu documentarea proiectului fizic prin DBDL . Pasul 4.2. Proiectarea constrngerilor ntreprinderii pentru SGBD int Constrngerile ntreprinderii, provenite din lumea real, pot influena reactualizrile relaiilor. Exemplu: Un angajat nu poate administra mai mult de 10 proprieti. Constrngerile trebuie reproiectate n funcie de SGBD ales, respectiv invers, SGBD se alege astfel nct s permit implementarea acestei constrngeri. Pentru Access implementarea constrngerilor de ntreprindere se realizeaz de exemplu cu limbajul Visual Basic, care lucreaz cu baze de date n Access.

1.8.2 Pasul 5. Proiectarea reprezentrii fizice Se determin organizarea fiierelor i metodelor de acces utilizate pentru stocarea relaiilor de baz. Stocarea eficient a datelor se evalueaz prin: - transferul de tranzacii: numr de tranzacii prelucrabile n timp - timpul de rspuns: timpul scurs pn la ncheierea unei singure tranzacii (de minimizat) - capacitatea de stocare pe disc: spaiul pe disc necesar stocrii fiierelor bazei de date (de minimizat). Proiectantul trebuie s cunoasc cele 4 componente hardware care interacioneaz i afecteaz performanele sistemului: memoria principal, unitatea CPU, discul I/O, reeaua. Distribuirea datelor pe unitile de disc se observ n figura 1.44.

71

Fig. 1.44. Configuraia tipic a discului Pasul 5.1 Analizarea tranzaciilor Pentru fiecare tranzacie se determin: - frecvena estimat cu care vor fi rulate tranzaciile - relaiile i atributele accesate de tranzacie i tipul de acces (interogare, inserare, reactualizare, tergere) - constrngerile de timp impuse tranzaciilor n cazul BD a unei agenii imobiliare se consider cu titlu de exemplu urmtoarele tranzacii: A: realizarea unui raport n care sunt enumerate proprietile de nchiriat din cadrul fiecrei filiale B: crearea i ntreinerea nregistrrilor referitoare la clienii din cadrul fiecrei filiale C: enumerarea vizitelor efectuate de clieni, cunoscnd adresele proprietilor vizitate Hrile de utilizare a tranzaciilor a) Harta cu modelul ER simplificat cu numerele estimate de apariii ale fiecrei entiti

n colul din stnga sus al fiecrei entiti este trecut estimarea numrului total de apariii ale acesteia (numrul de nregistrri din tabel). Se indic de asemenea valorile medii i maxime ale apariiilor dintr-o entitate copil, asociate unei apariii din entitatea printe. Astfel: - n tabelul Filiala sunt nregistrate 50 de filiale. o Unei filiale i sunt alocate n medie 240 i maxim 300 proprieti de nchiriat. o La o filial sunt nregistrai n medie 400 i maxim 500 de chiriai.
72

n tabelul Proprietate_de_nchiriat sunt nregistrate estimativ 12000 proprieti (50 filiale x 240 proprieti, n medie/filial). o O proprietate de nchiriat este vizitat (apare n Vizitare) n medie de 20 i maxim de 40 de ori. n tabelul Chiria sunt nregistrai estimativ 20000 de chiriai (50 filiale x 400 chiriai n medie/filial) o Un chiria efectueaz n medie 10 i maxim 20 de vizitri. n tabelul Vizitare sunt nregistrate estimativ 360000 vizitri (12000 proprieti de nchiriat x 30 vizitri /proprietate)

b) Harta cilor i operaiilor tranzaciilor A, B i C

n harta b) sunt afiate operaiile de inserare (I), citire (C), reactualizare (R) sau tergere () mpreun cu calea corespunztoare tranzaciilor A, B i C. A: realizarea unui raport n care sunt enumerate proprietile de nchiriat din cadrul fiecrei filiale Tranzacia A deci necesit accesarea tabelului Filiala i citirea (C) a datelor din acest tabel. Prin intermediul atributului Nr_Filial (cheie primar n Filiala i cheie strin n Proprietate_de_nchiriat) se citesc (C) proprietile de nchiriat oferite de fiecare filial. B: crearea i ntreinerea nregistrrilor referitoare la clienii din cadrul fiecrei filiale Tranzacia B necesit inserarea (I) a clienilor (chiriailor) nregistrai n tabelul Chiria i n acelai timp la o anume filial, reactualizarea (R) i tergerea () datelor referitoare la chiriai. Pentru executarea tranzaciei B se va accesa tabelul Filiala, iar prin atributul Nr_Filial (cheie primar n Filiala i cheie strin n Chiria) se vor insera, citi, reactualiza sau terge chiriaii nregistrai la fiecare filial. C: enumerarea vizitelor efectuate de clieni, cunoscnd adresele proprietilor vizitate

73

Tranzacia C necesit accesarea tabelului Proprietate_de_nchiriat, punct de acces fiind atributul adresa proprietii, cunoscut. Prin atributul Nr_Proprietate (cheie primar n Proprietate_de_nchiriat i cheie strin n Vizitare) se citesc (C) vizitelor efectuate la acea proprietate. De asemenea se pot nregistra i ziua i ora estimat la care va fi rulat fiecare tranzacie, inclusiv momentul sau intervalul de ncrcare maxim. Pentru tranzaciile care acceseaz frecvent baza de date, modelul lor de execuie se documenteaz ca n cazul exemplului de mai jos, referitor la tranzacia D: D: cutarea proprietilor de nchiriat oferite de o anumit filial, care satisfac un anumit tip de proprietate cerut de un potenial chiria.

Singurele operaii necesare pentru tranzacia D sunt de citire (C), documentate n figura de mai sus. Atributele utilizate ca puncte de acces, de intrare sunt notate cu (P). n cadrul tranzaciei D se acceseaz tabelul Filiala, punctul de acces fiind atributul cheie primar Nr_Filial, care se citete (C). Din tabelul Filiala, prin mecanismul cheie primar-cheia strin (Nr_Filiala) se citesc (C) n tabelul Proprietate_de_nchiriat datele referitoare le toate proprietile oferite de o anumit filial. Atributul Tipul se utilizeaz ca punct de intrare pentru interogare (clientul caut un anumit tip de proprietate). La accesarea unui numr de filial din Filiala se acceseaz tabelul Proprietate_de_Inchiriat de 48 300 ori (exist minim 48 de proprieti din fiecare tip disponibile la o filial, i o filial ofer maxim 300 de proprieti). Analiznd toate tranzaciile (nu numai A, B, C, i D exemplificate) asupra ntregii baze de date a ageniei imobiliare se constat c foarte multe tranzacii necesit accesarea tabelului Proprietate_de_nchiriat. Pasul 5.2 Alegerea organizrii fiierelor Se alege tipul adecvat de fiier, care poate fi: heap; hash; ISAM Indexed Sequential Access Method; arbore B+.
74

n majoritatea cazurilor SGBDurile bazate pe PCuri (de ex. MS-Access) nu permit utilizatorului alegerea sau modificarea organizrii fiierelor din tabelele de baz. Pasul 5.3 Alegerea indexurilor secundare Trebuie de determinat dac adugarea de indexuri secundare mbuntete performanele sistemului. Indexurile secundare ofer un mecanism de specificare a unei chei adiionale, pentru regsirea mai eficient a datelor. 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, ca fiind de interes. Indicaii referitoare la indexare: - se indexeaz cheia primar - nu se indexeaz relaii mici - se indexeaz cheia strin dac e frecvent utilizat - nu se indexeaz atribute frecvent reactualizate - nu se indexeaz atribute cu iruri lungi de caractere. MS-Access indexeaz automat cheile primare i cheile strine din tabele.

n cazul interogrii a mai multe tabele simultan (interogare de tabele multiple) viteza de interogare poate fi mrit prin indexarea cmpurilor din ambele pri ale firului relaiei (din ambele pri ale uniunii) i prin indexarea cmpurilor pentru care se utilizeaz criterii de interogare. De exemplu n tabelul Proprietate_de_nchiriat se vor indexa cmpurile frecvent interogate tipul i zona. Este indicat s se creeze numai indexuri care se presupune c vor mbunti performanele sistemului, deoarece ntreinerea indexurilor ncarc suplimentar resursele, ceea ce ar putea avea ca rezultat final scderea vitezei sistemului. Crearea indexurilor secundare se documenteaz, mpreun cu motivaia pentru care au fost considerate necesare. Pasul 5.4 Considerarea introducerii unei redundane controlate
75

Trebuie de determinat dac introducerea de redundan controlat prin relaxarea normalizrii (denormalizare) duce la mbuntirea performanelor sistemului. Datorit denormalizrii implementarea BD este mai dificil, scade flexibilitatea BD, se pot accelera regsirile dar se ncetinesc reactualizrile. Pasul 5.4.1 Considerarea datelor derivate Valorile atributelor derivate pot fi calculate din valorile altor atribute. Stocarea unui atribut derivat n BD duce la: - costuri suplimentare de stocare i meninere a concordanei datelor derivate cu datele operaionale din care au fost derivate; - costuri de calculare a datelor derivate de fiecare dat cnd este necesar. Exemplu: Entitatea Personal poate conine un nou atribut derivat (Nr_Proprietati) care arat cte proprieti administreaz fiecare membru al personalului. Valoarea acestui atribut se deriv din entitatea Proprietate_de_Inchiriat, dup atributul NrPer (fig. 1.45).

Fig. 1.45. Relaia Personal simplificat cu atributul derivat Nr_Proprieti Dac BD este interogat frecvent asupra numrului de proprieti administrate de fiecare membru al personalului poate fi util de stocat acest atribut derivat n relaia (entitatea) Personal. Exemplu: Tranzacia E: Enumerarea numrului proprietii, oraului, tipului, chiriei i avansului pentru nchiriere (conform regulilor de afaceri: avansul = 2 x chiria). Interogarea trebuie s cuprind toate cmpurile cerute plus un cmp calculat (derivat) pentru avans. Pentru a evita rularea repetat a interogrii, se prefer adugarea unui cmp suplimentar n tabelul de baz, Proprietate_de_nchiriat, cmp numit Avans, unde se trece avansul pentru fiecare proprietate, calculat de operatorul uman la nregistrarea sau actualizarea proprietii respective. Deci la executarea tranzaciei E nu mai trebuie calculat (prin rularea interogrii) avansul pentru fiecare proprietate.
76

Pasul 5.4.2 Considerarea dublrii atributelor sau gruprii (uniunii) relaiilor Exist situaii n care se dubleaz anumite atribute sau se grupeaz relaii pentru a reduce numrul de uniuni necesare pentru efectuarea unei interogri. Pentru evitarea redundanei, prin normalizare relaia Filiala (Nr-Fil, Strada, Zona, Orasul, CodP, Nr_Tel, Nr_Fax) se descompune n dou relaii: Filiala (Nr_Fil, Strada, CodP, Nr_Tel, Nr_Fax) Cod_Postal_Filiala (Nr_Fil, CodP, Zona, Orasul) Astfel la introducerea unei filiale noi nu trebuie de repetat toate informaiile legate de ora.
77

Totui se ntmpl rar s dorim s accesm adresa filialei fr atributele corespunztoare zonei i oraului. Pstrnd atributele oraului ntr-o relaie separat nseamn c, ori de cte ori dorim adresa complet a filialei, trebuie de efectuat uniunea celor 2 relaii. Ca urmare se opteaz pentru o denormalizare i se pstreaz prima variant a relaiei, dei conine date redundante. Exemplu: Tranzacia F: a se enumera pentru fiecare proprietate numrul proprietii, strada, oraul, mpreun cu numrul de personal i numele angajatului responsabil pentru administrarea proprietii respective. Se realizeaz o interogare pe tabele multiple, adic o grupare/uniune de tabele (vezi figura de mai jos), pentru a include numele angajatului (din tabelul Personal) n rezultatul interogrii.

Pentru a evita rularea interogrii de fiecare dat (necesitatea realizrii uniunii ntre cele 2 tabele), n tabelul Proprietate_de_nchiriat se introduce o redundan controlat, anume cmpul Nume (care exist i n tabelul Personal).
78

Pentru a garanta coerena n continuare a BD, se proiecteaz i se implementeaz un program de aplicaie prin care orice modificare n cmpul Nume n tabelul printe Personal s se transmit n cmpul Nume din tabelul copil Proprietate_de_nchiriat. Pasul 5.4.3 Documentarea introducerii redundanei Orice redundan introdus ulterior se documenteaz i se motiveaz. Modelul de date logic trebuie reactualizat, astfel nct s reflecte orice modificri aprute prin denormalizare. Pasul 5.5 Estimarea necesarului de spaiu pe disc Este obligatorie pentru stabilirea performanelor hardware cerute pentru implementarea bazei de date. Se determin astfel dac pe moment sau n viitor este necesare achiziionarea de hardware mai performant. 1.8.3 Pasul 6. Proiectarea mecanismelor de securitate Msurile de securitate pentru baza de date trebuie s corespund cerinelor utilizatorilor. Pasul 6.1 Proiectarea vederilor utilizatorilor n baza modelelor de date logice local se proiecteaz vederile utilizatorilor. Vederile se creeaz n MSAccess prin interogri QBE, care se bazeaz pe limbajul de interogare structurat SQL (Structured Query Language). Exemplu: Se doresc detalii referitoare la personalul ageniei imobiliare, vizibile pentru supervizorul organizaiei, dar fr informaii referitoare la salarii. In timp ce managerul organizaiei vede relaia de baz, complet:
Personal (Nr_Personal, Prenume, Nume, Adresa, Telefon, Sex, Functia, Salariu, Nr_Filiala)

Cheie primar: Nr_Personal Cheie strin: Nr_Filiala, se refer la relaia, tabelul Filiala (cu cheia primar Nr_Filiala). n urma interogrii selective QBE (implicit cu SQL) se genereaz vederea:
Personal_VedereSupervizor (Nr_Personal, Prenume, Nume, Adresa, Telefon, Sex, Functia, Nr_Filiala)

Cheie primar: Nr_Personal Cheie strin: Nr_Filiala, se refer la relaia, tabelul Filiala (cu cheia primar Nr_Filiala). Aceasta este o vedere pentru un utilizator cu permisiune de acces la date limitat. Vederea supervizorului, adic rspunsul la interogarea selectiv, se poate edita (reactualiza). MS-Access va scrie reactualizrile n tabelul sau tabelele de baz care au fost interogate. Deci supervizorul are dreptul la reactualizri asupra tabelului de baz Personal, cu excepia cmpului Salariu, utiliznd interogarea selectiv QBE, respectiv formular corespunztor interogrii. Figurile de mai jos arat vizualizarea de proiectare (Design View) a interogrii selective QBE (Query By Example) i formularul realizat n baza interogrii, formular cu care lucreaz supervizorul.

79

Pasul 6.2 Proiectarea regulilor de acces De regul utilizatorii nu au acces la relaiile de baz, ci numai la vederile create pentru ei. Administratorul de BD atribuie fiecrui utilizator un identificator de autorizaie care are asociat o parol. Fiecare instruciune SQL executat de ctre SGBD este efectuat n numele unui anumit utilizator. Identificatorul de autorizaie determin la ce obiecte din BD se poate referi utilizatorul i ce operaii poate efectua asupra acestor obiecte. Fiecare obiect creat n SQL are un proprietar identificat prin identificatorul de autorizaie. Proprietarul este singurul care cunoate existena obiectului respectiv i deci poate efectua operaii asupra lui. Privilegiile sunt aciunile pe care un utilizator are voie s le efectueze asupra unei relaii de baz sau vederi. Instruciuni pentru acordarea privilegiilor: SELECT: privilegiul de a regsi date dintr-o relaie Cnd utilizatorul creeaz o relaie folosind instruciunea Create Table din limbajul SQL, utilizatorul de vine automat proprietarul noii relaii cu privilegii complete GRANT: se acord privilegii altor utilizatori asupra relaiei nou create
80

REVOKE: revoc privilegii CREATE VIEW: utilizatorul care creeaz vederea devine automat proprietarul acesteia, dar nu neaprat cu privilegii complete, (ca la SELECT) Exemplu: pentru ca utilizatorul manager s regseasc rnduri din relaia Personal i s insereze, s reactualizeze i s tearg date din aceasta, s transmit privilegii utilizatori, se utilizeaz urmtoarea instruciune SQL: GRANT ALL PRIVILEGES ON personal TO manager WITH GRANT OPTION. Exemplu: Utilizatorului cu identificatorul de autorizaie ADMIN i se acord privilegiul SELECT pentru relaia Personal, cu urmtoarea instruciune SQL: GRANT SELECT ON personal TO admin MS-Access ofer dou metode tradiionale de securizare a BD: - stabilirea unei parole a BD (pentru deschiderea BD) - securitatea la nivel de utilizator (se limiteaz segmentele din BD care pot fi citite sau reactualizate la nivel de utilizator).. Stabilirea unei parole Figura de mai jos arat caseta de dialog care solicit introducerea parolei pentru deschiderea bazei de date.

O dat deschis BD, toate obiectele (tabele, interogri, formulare etc.) sunt puse la dispoziia utilizatorului. Securitatea la nivel de utilizator Securitatea la nivel de utilizator este similar metodelor utilizate n majoritatea sistemelor (softurilor) de reele. Utilizatorului i se cere s se identifice i s scrie o parol atunci cnd pornete MS-Access. n cadrul fiierului de informaii al grupului de lucru (Workgroup Administrator) utilizatorii sunt identificai ca membri ai unui grup. Access definete automat grupurile Admin i Users, dar pot fi definite i alte grupuri. Figura de mai jos ilustreaz caseta de dialog pentru definirea grupurilor i conturilor de utilizator.

81

Figura de mai jos ilustreaz caseta de dialog pentru acordarea permisiunilor de utilizator i de grup. Se reglementeaz modul n care se lucreaz cu fiecare obiect din BD. Un control mai fin se realizeaz prin definirea de grupuri (conturi de grup) noi, crora li se acord anumite permisiuni (de grup). Apoi se adaug utilizatorii care fac parte din acest grup, care au implicit toate drepturile grupului din care fac parte, dar ale cror drepturi pot fi modificate individual, astfel nct s fie mai multe sau mai puine fa de grup.

82

Pasul 6.3 Documentarea proiectului msurilor de securitate i vederilor utilizatorilor Proiectarea vederilor individuale i mecanismele de securitate trebuie complet documentate. Dac proiectul fizic afecteaz modelele de date logice individuale, atunci i aceste diagrame trebuie reactualizate. 1.8.4 Pasul 7. Monitorizarea i reglarea sistemului operaional Obiectiv: Monitorizarea sistemului operaional i mbuntirea performanelor acestuia, pentru a corecta deciziile inadecvate de proiectare sau pentru a reflecta cerinele n schimbare. Reglarea din mers a bazei de date de ctre administratorul BD prezint anumite avantaje: - se evit necesitatea procurrii de hardware adiional - se poate micora configuraia hard - timpul de rspuns scade, transferul devine mai eficient - ca urmare cresc productivitatea ntreprinderii, moralul angajailor i satisfacia clienilor. Orice modificare de reglare poate n acelai timp mbunti o aplicaie i strica alta. Este de dorit s se verifice/testeze nti modificarea pe o baz de date de ncercare, sau atunci cnd sistemul nu este complet utilizat (n afara orelor de lucru). Presupunem c dup cteva luni de utilizare a BD complet operaionale a ageniei imobiliare au aprut din partea mai multor utilizatori ai sistemului dou noi cerine: (1) Capacitatea de a pstra fotografii ale proprietilor de nchiriat, mpreun cu comentariile care descriu principalele caracteristici ale acesteia. n MS-Access se introduc cmpuri cu tip de date (data type): OLE (Object Linking and Embedded = legarea i nglobarea de obiecte). Acestea permit stocarea de date cum ar fi documente MS-Word sau MSExcel, figuri, sunete sau alte tipuri de date binare create n alte programe. Obiectele OLE pot fi legate de sau nglobate ntr-un cmp dintr-un tabel sau formular n Access i pot fi afiate. Tabelul Proprietate_de_nchiriat se va restructura astfel nct s cuprind un cmp numit Vedere cu tip de date OLE, i un cmp numit Comentarii, cu tip de date Memo, capabil de a cuprinde un text mai lung. Figura de mai jos ilustreaz un formular care cuprinde cele dou cmpuri noi, formular bazat pe tabelul Proprietate_de_nchiriat. Calea ctre imaginea/imaginile stocate pe hard disk se specific n design view al formularului (sau raportului sau paginii de acces) creat dup tabel.

83

(2) Capacitatea de a publica un raport care s disponibilizeze n Internet proprietile de nchiriat disponibile. Aceast cerin se satisface prin crearea nti a unui raport adecvat, care s conin cmpurile dorite pentru a fi vizualizate n Internet, dup care n baza acestui raport se realizeaz Pagina de acces la date. Pentru ca pagina de acces la date creat s fie activat, este necesar legtura la Internet i un browser adecvat. 1.8.5 Rezumatul capitolului 1.8. Proiectarea fizic a bazei de date reprezint procesul de realizare a descrierii implementrii acesteia n capacitatea de stocare secundar. Etapa iniial (pasul 4) const n transpunerea modelului de date logic global ntr-o form care s poat fi implementat n SGBD relaional int. Urmtoarea etap (pasul 5): proiectarea organizrii fiierelor i metodelor de acces care vor fi utilizate pentru stocarea relaiilor de baz. Aceasta presupune analizarea tranzaciilor, alegerea organizrii adecvate a fiierelor, adugarea de indexuri secundare, introducerea de redundan controlat i estimarea spaiului necesar pe disc. Indexurile secundare furnizeaz un mecanism de specificare a unei chei suplimentare pentru o relaie de baz, pentru regsirea mai eficient a datelor. Denormalizarea este o opiune atunci cnd performanele sistemului nu sunt satisfctoare i o relaie are o rat de reactualizare sczut i o rat de interogare foarte ridicat. Baza de date trebuie prevzut cu un mecanism de securitate (pasul 6). Msurile de securitate necesare se identific pe parcursul proiectrii logice. Ele se realizeaz prin crearea de vederi pentru utilizatori i utilizarea de mecanisme de control al accesului, scrise n limbajul SQL. Etapa final (pasul 7) din proiectarea fizic a BD const n monitorizarea i reglarea nentrerupte ale sistemului operaional pentru maximizarea performanelor.
84

1.8.6. ntrebri la capitolul 1.8 Explicaie diferena dintre proiectarea conceptual, logic i fizic a bazelor de date. Descriei scopul principalelor etape din metodologia de proiectare fizic a bazelor de date. n ce condiii se justific denormalizarea unui model de date logic? Utilizai exemple.

85