| CATEGORII DOCUMENTE |
DOCUMENTE SIMILARE |
||
|
||
Baze de date. Proiectare. Implementare. Gestionare
Obiective
o Cunoasterea notiunilor de baza privind prelucarea datelor prin sisteme informatice de gestionare a bazelor de date relationale;
o Planificarea, proiectarea si administrarea bazelor de date;
Introducere in BD. Tratarea datelor. Sisteme de gestionare a bazelor de date. Sisteme bazate pe fisiere
1.1.1 Introducere
Prelucrarea datelor prin BD: raspuns la nevoia organizatiilor (institutii, intreprinderi etc.) de a eficientiza evidenta activitatii lor, d.p.d.v. al fluxului datelor si informatiilor.
BD:o colectie structurata de articole de date, intre care exista legaturi logice.
Sistem de gestionare de baza de date (SGBD) softul prin care BD sunt:
definite/configurate,
construite
exploatate/manipulate.
Introducere Modelul relational de BD
Exista trei modele uzuale de implementare de BD:
ierarhic
retea
relational
Fiecare se bazeaza pe conceptul de date stocate ca set sau multime de inregistrari.
Modelele ierarhic si retea
se bazeaza pe parcurgerea legaturilor dintre date pentru a lucra cu baza de date;
sunt utilizate pentru sisteme-cadru generale, vaste
Sistemele de gestionare a bazelor de date relationale (SGBDR) utilizeaza un model simplu, relational de date
o Datele se prezinta sub forma unei colectii (unui set) de relatii
o Fiecare relatie are forma unui tabel (cea mai importanta componenta a unei BD)
o Randurile (inregistrarile) tabelului reprezinta entitati
o Coloanele (campurile) tabelului sunt atribute/proprietati ale acestor entitati
o Fiecare tabel are un set de atribute, care impreuna reprezinta o "cheie" care defineste fiecare entitate in mod unic.
1.1.2 Tratarea datelor prin sisteme bazate pe fisiere
Sistemul bazat pe fisiere
o colectie de programe de aplicatie care efectueaza servicii pentru utilizatorii finali (de ex. producerea de rapoarte
Fiecare program defineste si gestioneaza propriile date.
1.1.2Tratarea datelor prin sisteme bazate pe fisiere
Ex : firma furnizeaza componente pt. diferite proiecte/clienti.
o Compartimentul magazie va tine fisiere cu:
n componentele in stoc, pe fisa fiecarei componente aparand denumirea, seria, costul, nr. bucati etc.
o Compartimentul contabilitate va tine fisiere cu:
n componentele in stoc, documentele de achizitie, intrare, denumirea, seria, costul, nr. bucati etc.
n iesirile de componente, cu caracteristicile si cantitatile de componente, documentatie insotitoare de iesire (inclusiv numele proiectelor/clientilor)
o Compartimentul vanzari va tine fisiere cu:
n numele proiectelor, inclusiv nume clienti, numar contract, tipuri de componente
n cerintele clientilor, detalierea, descrierea componentelor, gradul de urgenta prioritate etc.
Limitari ale sistemelor bazate pe fisiere:
Separarea si izolarea datelor
Dublarea datelor
o Risipa
o Alterarea integritatii datelor prin dublare
Dependenta de date
dependenta program-date
Incompatibilitatea fisierelor
Interogarea fixa sau proliferarea programelor de aplicatie
Limitarile tratarii datelor bazata pe fisiere au doua cauze:
o definitia datelor este incorporata in programele de aplicatie, in loc de a fi stocata independent;
o nu exista control asupra accesului si manipularii datelor dincolo de cel impus de programele de aplicatie.
Tratarea datelor prin baze de date (BD)
BD:
o colectie partajata de date intre care exista relatii logice (si o descriere a acestor date), proiectata pentru a satisface necesitatile informationale ale unei organizatii
o resursa comuna, partajata
datele sunt integrate, cu o dublare minima
o colectie autodescrisa de inregistrari integrate. Aceasta caracteristica BD este cunoscuta si ca independenta program - date
o BD relationala contine entitatile, atributele si relatiile logice dintre acestea, reprezentate printr-o diagrama entitate - relatie (ER).
Sistemul de gestionare al bazei de date (SGBD)
SGBD
o un sistem de programe care permite utilizatorului definirea, crearea si intretinerea bazei de date si accesul controlat la aceasta.
o consta in elemente software care interactioneaza cu
n programele de aplicatie ale utilizatorului
n baza de date
Facilitati ale SGBD
o permite definirea BD printr-un limbaj de definire a datelor (DDL)
o permite inserarea, reactualizarea, stergerea si extragerea de date printr-un limbaj de manipulare a datelor (DML).
n prin DML o interogare generala a acestor date, numita limbaj de interogare SQL elimina utilizarea unui set fix de interogari disponibile, ca in cazul tratarii datelor prin sisteme de fisiere.
Facilitati SGBD (continuare):
o
acces
controlat
n Un sistem de securitate, pentru a impiedica accesul utilizatorilor neautorizati
n Un sistem de integritate, care mentine concordanta datelor stocate;
n
Un
sistem de control al utilizarii simultane, care permite accesul partajat
n Un sistem de control al refacerii, care restaureaza BD intr-o stare precedenta concordanta, ca urmare a unei defectiuni hard sau soft;
n Un catalog accesibil utilizatorilor, care contine descrieri ale datelor din BD
Faciliatati SGBD (continuare):
o generarea de vederi/views numite si moduri de vizualizare a BD prin mecanismul de vizualizare.
n se vor afisa numai acele date din BD care sunt utile utilizatorului
n ofera un anumit nivel de securitate; se exclud date care nu trebuie vazute de anumiti utilizatori;
n personalizare a aspectului BD. De ex redenumirea campurilor dupa preferintele utilizatorului;
o O imagine coerenta, neschimbata a structurii BD, chiar daca BD insasi este modificata; prin modul de vizualizare se va afisa in continuare structura prestabilita a BD
1.1.5 Componentele mediului SGBD
o Hardware un singur PC pana la o retea. Un SGBD poate necesita
n un anumit tip de elemente hardware sau sistem de operare
n poate functiona pe o diversitate de elemente hardware si platforme
o
Pe
server se afla programele back-end, adica partea din SGBD care
administreaza si controleaza accesul
o Pe calculatoarele din diversele locatii/PC clienti se afla aplicatiile front-end, adica partea din SGBD care constituie interfata cu utilizatorul.
Software
o programele SGBD si programele de aplicatie impreuna cu sistemele de operare, inclusiv software de retea, daca este cazul.
n Programele aplicatie limbaj de programare din generatia a treia (C, Cobol, Fortran) sau a patra - SQL, incorporat intr-un limbaj de generatia a treia.
o SGBD poate avea propriile instrumente de generatia a patra, care permit
n dezvoltarea rapida de aplicatii prin furnizarea unui limbaj de interogare si a unor generatoare de rapoarte, formulare, grafica etc.
Datele
o cea mai importanta componenta SGBD, d.p.d.v. al utilizatorului; datele = punte intre componentele masina si cele umane. BD contine:
n Date operationale
n Meta-date, adica date despre date.
Procedurile
Sunt instructiunile si regulile care guverneaza proiectarea si utilizarea BD. Sunt necesare
n administratorilor BD
n utilizatorilor de BD
cuprind instructiuni referitoare la
n deschiderea unei sesiuni de lucru in SGBD;
n utilizarea unei anumite facilitati a SGBD sau a unui program aplicatie;
n pornirea si oprirea SGBD;
n efectuarea de copii de siguranta a BD ;
n tratarea defectiunilor hard sau soft;
n modificarea structurii unui tabel, reorganizarea BD pe mai multe discuri, arhivarea datelor etc.
Persoanele
Sunt ultima componenta a unui mediu SGBD si va fi discutata la paragraful "Pozitiile persoanelor din mediul SGBD".
1.1.6 Proiectarea BD - schimbarea de paradigma
Structura BD (entitatile, atributele, relatiile) este determinata in timpul proiectarii BD.
Proiectarea unei BD ¹ a sistemelor pe baza de fisiere nevoile aplicative ale departamentelor individuale
BD se considera intai datele apoi aplicatiile.
Aceasta schimbare a modului de tratare se numeste schimbare de paradigma.
o Esecurile sistemelor informationale lipsa aplicarii unei metodologii de proiectare a BD in mod structurat
o Rezulta BD ineficiente pentru cerintele aplicatiilor, documentatia este limitata, intretinerea dificila.
1.1.7 Pozitiile persoanelor din mediul BD
o administratorii de date si de BD;
o proiectantii de BD;
o programatorii de aplicatii;
o utilizatorii finali.
BD si SGBD resurse comune care trebuie gestionate
Sarcinile administratorului de date (DA
o gestionarea resurselor de date: planificarea, elaborarea si intretinerea strategiilor si procedurilor bazei de date
o proiectarea conceptuala/logica a BD
o consultarea si indrumarea managerilor superiori, a.i BD sa sprijine obiectivele generale ale organizatiei.
Administratorul de baze de date (DBA) este responsabil cu realizarea fizica a BD, avand urmatoarele sarcini:
o proiectarea si implementarea BD
o securitatea si controlul integritatii BD
o intretinerea sistemului operational
o asig performante satisfacatoare pt. aplicatii si utilizatori;
o Rolul DBA este mai tehnic si necesita cunoasterea in detaliu a SGBD si a mediului acestuia.
Proiectantii de BD logice: "ce anume?"
o identificarea datelor (entitati si atribute), a relatiilor dintre ele a constrangerilor asupra celor care vor fi stocate in BD;
o cunosc foarte bine datele organizatiei si a regulilor de operare ale organizatiei;
o trebuie sa implice toti posibilii utilizatori ai BD in modelul creat.
o Etape de proiectare a BD logice:
n proiectarea conceptuala a BD, independent de detaliile de implementare (de ex. SGBD utilizat, programele de aplicatie, limbajele de programare etc.)
n proiectarea logica a BD, care se bazeaza pe un anumit model, de ex. relational, ierarhic, in retea, orientat pe obiecte.
Proiectantii de BD fizice ("Cum anume?") preia modelul logic si stabileste realizarea fizica:
o transpunerea modelului logic de date intr-un set de tabele si constrangeri privind integritatea;
o selectarea de structuri de stocare si metode de acces specifice, a.i. sa se obtina performante bune ale datelor in activitatile legate de BD;
o masuri referitoare la securitatea datelor.
o Proiectarea fizica a unei BD trebuie sa tina cont de SGBDul avut in vedere;
implementeaza programele de aplicatie ce confera functionalitatea ceruta de utilizatorii finali.
Fiecare program contine instructiuni care ii cere SGBD sa efectueze o operatie oarecare in BD (extragere, inserare, reactualizare, stergere de date).
Programele pot fi scrise intr-un limbaj de generatia a treia sau a patra.
Utilizatorii simpli nu sunt constienti de SGBD.
Acceseaza BD prin programe de aplicatie speciale, simplificatoare.
folosesc comenzi simple, optiuni din meniu.
Utilizatorii sofisticati sunt familiarizati cu structura BD si facilitatile SGBD.
Pot utiliza un limbaj de interogare de nivel inalt (SQL).
Pot scrie programe de aplicatie pentru uz personal.
1.1.8
Avantajele si dezavantajele SGBD
Avantaje
o Controlul redundantei datelor; se controleaza volumul inerent al redundantei datelor in BD.
o Coerenta datelor; orice reactualizare a unui articol (stocat o singura data) se face o singura data, eliminandu-se incoerenta. SGBD garanteaza coerenta tuturor exemplarelor din articolul respectiv.
o Mai multe informatii obtinute de la aceeasi cantitate de date; doua sau mai multe fisiere pot fi integrate, extragandu-se mai multe informatii.
o Partajarea datelor; fisierele sunt detinute de compartimentele organizatiei care le utilizeaza, dar fiind parte din BD, ele sunt la dispozitia tuturor utilizatorilor.
o Integritatea crescuta a datelor; se refera la validitatea si coerenta datelor stocate. Integritatea este exprimata prin constrangeri, care reprezinta reguli de coerenta pe care BD nu are voie sa le incalce.
o Securitatea crescuta; protectia BD fata de utilizatorii neautorizati.Se realizeaza prin nume de utilizatori plus parole. Se poate limita tipul de operatie efectuata.
o Aplicarea standardelor; prin integrare se pot aplica standarde organizationale, nationale sau internationale, ca de ex. formatul datelor, conventii referitoare la denumire, pt. a facilita schimburi intre sisteme.
o Economia de scala; in loc de bugete pentru fiecare compartiment exista un buget unic combinat.
o Echilibrul intre cerintele aflate in conflict; cerintele posibil in conflict ale diferitelor compartimente sunt gestionate la nivel de DBA, care va acorda prioritate aplicatiilor majore.
o Imbunatatirea accesibilitatii datelor si capacitatii de raspuns; limbajele de interogare si generatoare de rapoarte asociate SGBD ofera utilizatorilor posibilitatea unor interogari ad-hoc, fara a apela la programator.
o Productivitatea crescuta; SGBD furnizeaza standardele necesare aplicatiei, economisind timpul programatorului.
o Capacitatea de intretinere imbunatatita, prin independenta de date; intr-un SGBD descrierile datelor sunt separate de aplicatii, aplicatiile fiind imune la modificarea descrierii datelor; este caracteristica de independenta program-date, care usureaza intretinerea aplicatiilor din BD.
o Concurenta/simultaneitatea imbunatatita; se garanteaza alterarea datelor in situatia cand acelasi fisier este utilizat simultan de mai multi utilizatori.
o Imbunatatirea serviciilor de salvare de siguranta si refacere. Se minimizeaza pierderile aparute ca urmare a unor defectiuni. Nu este necesara realizarea zilnica de copii de siguranta.
Dezavantaje
o Complexitatea; pt. ca un SGBD sa fie functional, acesta va
evolua intr-un sistem soft extrem de complex. Functionalitatea trebuie
cunoscuta de catre toti cei implicati in BD, de
o Dimensiunea; Fiind un element soft foarte complicat, SGBD ocupa mult spatiu pe disc si necesita multa memorie pentru a functiona eficient.
o Costul SGBD; variaza in functie de mediu si funtionalitate. De la 150 USD pt. un PC cu un utilizator, la 750.000 USD pt. un sistem mainframe cu sute de utilizatori. Se adauga cheltuieli periodice anuale de intretinere.
o Costurile aditionale pentru elemente hardware; pentru a sigura performantele SGBD poate fi nevoie de achizitionarea unui calculator mai mare, chiar dedicat rularii SGBD, cu disc si memorie mai mari.
o Costul conversiei; la implementarea unui nou sistem SGBD si/sau a unei noi configuratii hard, conversia poate costa semnificativ mai mult decat noile elemente hard. Se include costul instruirii personalului, angajarea de personal specializat. Apare termenul de sistem mostenit, adica un sistem mai vechi, inferior, de care organizatia se cramponeaza din motive de costuri de conversie.
o Performanta; SGBD (spre deosebire de cel bazat pe fisiere) este general, creat pentru a permite diverse aplicatii; astfel unele pot functiona mai putin rapid decat in cazul sistemului bazat pe fisiere, creat pentru o anume aplicatie.
o Impactul crescut al unei defectiuni. Centralizarea (partajarea) resurselor creste vulnerabilitatea SGBD. Esecul oricarei componente poate duce la sistarea tuturor operatiilor.
1. Baze de date.
Proiectare. Implementare. Gestionare
Pana acum:
1.1 Introducere in BD. Tratarea datelor. Sisteme de gestionare a bazelor de date. Sisteme bazate pe fisiere
1.1.1 Introducere
1.1.2 Tratarea datelor prin sisteme bazate pe fisiere
1.1.3 Tratarea datelor prin baze de date (BD)
1.1.4 Sistemul de gestionare a bazei de date (SGBD)
1.1.5 Componentele mediului SGBD
1.1.6 Proiectarea BD - schimbarea de paradigma
1.1.7 Pozitiile persoanelor din mediul BD
1.1.8 Avantajele si dezavantajele SGBD
1.2. Modelul relational (SGBDR)
1.2.1 Terminologie
1.2.1.1 Structura relationala
a datelor
o Relatie un tabel cu coloane si randuri
o Atribut: o coloana a unei relatii, cu o anumita denumire.
o Domeniu: multimea de valori permise pentru unul sau mai multe atribute.
n Pentru fiecare atribut se defineste in mod central - denumirea domeniului
- sensul acestuia
- domeniul de definitie.
Þ Se evita operatiile incorecte semantic
- nu se compara un numar de telefon cu nr. de casa, desi ambele sunt siruri de caractere
- este insa legal de inmultit nr. luni cu salariile
(caractere text cu valori monetare).
Terminologie
o Tuplu: un rand dintr-o relatie.
o Intensitatea unei relatii: structura tabelului, specificarea domeniilor s a restrictii regula fixa/fixata
o Extensia (starea) unei relatii: tuplurile se modifica in timp.
o Grad: numarul de atribute.
n relatie cu atribute binara
o Baza de date relationala: Un set de relatii normalizate. O BDR consta din relatii (tabele) structurate adecvat.
1.2.1 Terminologie
1.2.1.2 Relatii matematice
Sensul termenului de relatie
o Produs cartezian: D1 x D2;
n Ex: D1 = ; D2 = ;
n D1 x D2 =
o Orice submultime a produsului cartezian este o relatie, de ex
n R = , adica: R =
n S = adica S =
o Produsul caterzian - continuare
Fiecare element Di este n-tuplu
are n elemente,
unul din fiecare multime de la 1 la n.
Orice submultime a acestui produs cartezian, adica orice multime de n-tupluri reprezinta o relatie a celor n multimi (care formeaza produsul cartezian).
o Schema de relatie:
n Denumirea relatiei (perechi de atribute & denumiri de domenii)
o R atributele Ai domeniile Di, i=1,n.
o schema de relatie S= .
o Fiecare inregistrare n coloane (atribute), Þ n-tuplu
n fiecare Ai , i=1,n ia o valoare di, i=1,n di I Di.
o n-tuplu: (A1:d1, A2:d2, ., An:dn).
o n-tuplu: (A1:d1, A2:d2, ., An:dn)
o Fiecare element un atribut&valoarea lui.
o Relatia o multime (set) de n-tupluri.
o Relatia R ca tabel
n atributele (Ai) capete de coloane
n tuplurile (n-tuplurile) randurile d1, d2, ., dn.
o O relatie din modelul relational o submultime a produsului cartezian al domeniilor atributelor.
o Tabelul este o reprezentare fizica a unei astfel de relatii.
o denumire, unica;
o fiecare celula exact o valoare atomica (singulara);
o fiecare atribut denumire distincta;
o toate valorile unui atribut I aceluiasi domeniu;
o ordinea atributelor nu are importanta;
o fiecare tuplu distinct; nu exista dubluri;
n Elementele unei multimi nu se repeta
o ordinea tuplurilor nu are importanta.
n Relatia este o multime
o Supercheia: atribut set de atribute care identifica in mod unic un tuplu dintr-o relatie
o O supercheie poate contine si atribute care nu sunt necesare identificarii unice a tuplului.
o Cheia candidat: este o supercheie minima, pentru care nici o submultime nu este supercheie in cadrul relatiei respective.
o O cheie combinata include mai multe atribute.
o Cheia primara este cheia candidat selectata pentru a identifica in mod unic tuplurile din cadrul unei relatii.
o Cheile candidat neselectate se numesc chei alternative.
o Cheie straina: Un atribut set de atribute din cadrul unei relatii, care se potrivesc cu o cheie candidat (cel mai des: cheie primara) din alta relatie.
o O cheie straina dintr-o relatie tinteste coincide cheia primara din alta relatie.
1.2.2 Integritatea relationala
Un model de date relational cuprinde:
o o parte structurala;
o reguli de integritate care asigura corectitudinea datelor;
o o parte de manipulare tipurile de operatii permise asupra datelor
Fiecare atribut are un domeniu Þ exista constrangeri de domeniu
Mai exista constrangeri pt. intreaga BD, anume:
o integritatea entitatilor
o integritatea referentiala
1.2.2 Integritatea relationala 1.2.2.1 Null-uri
o Null valoarea unui atribut curent necunoscuta sau care nu este aplicabila tuplului respectiv.
o Null: valoare logica "necunoscut"
o Null: indica absenta unei valori
o Un Null ≠ valoarea numerica = 0
o Un Null ≠ sir de "spatii" (zero string);
n spatiile sunt valori
1.2.2 Integritatea relationala Integritatea entitatilor
o Se aplica cheilor primare ale relatiilor de baza.
n relatie de baza (tabel de baza) corespunde unei entitati in schema conceptuala a BD.
o Integritatea entitatilor: intr-o relatie de baza
n nici un atribut al unei chei primare nu poate fi Null
n cheia primara nu isi repeta valorile
1.2.2 Integritatea relationala Integritatea referentiala
o Se aplica cheilor straine.
o Integritatea referentiala: Daca intr-o relatie exista o cheie straina, valoarea acesteia trebuie
n ori sa coincida cu valoarea unei chei candidat (chei primare) in relatia sa de baza
n ori sa fie in intregime Null.
o sunt reguli aditionale, specificate de catre utilizatorii sau administratorul bazei de date (DBA).
1.2.3 Vederi (Views)
o Vederea externa este structura BD cum apare ea unui anumit utilizator.
o o relatie virtuala, nu este de sine statatoare, este derivata in mod dinamic din una sau mai multe relatii de baza.
o Relatie de baza
o are o anumita denumire
o corespunde unei entitati din schema conceptuala
o Tuplurile relatiei de baza sunt stocate fizic in BD.
o Vedere: Rezultatul dinamic al operatiilor efectuate asupra relatiilor de baza, pentru a obtine o alta relatie.
o o relatie virtuala, in realitate nu exista in BD
o este produsa in momentul respectiv, la cererea unui utilizator
o Dinamica modificarile in relatiile de baza sunt reflectate imediat in vederi
o Invers modificarile permise operate asupra vederii se transmit relatiilor de baza.
o Continutul unei vederi
o o interogare asupra unei sau mai multor relatii de baza.
o furnizeaza un mecanism de securitate puternic;
o accesarea datelor in mod personalizat aceleasi date vizualizate de catre diversi utilizatori
n simultan,
n in moduri diferite;
o poate simplifica operatiile complexe asupra relatiilor de baza.
o sunt permise reactualizarile prin vederi cand:
n Vederea a fost definita printr-o interogare simpla a unei singure relatii de baza
n Interogarea (vederea obtinuta contine fie cheia primara, fie cheia candidat a rel. de baza
o nu sunt permise reactualizarile prin vederi care implica relatii de baza multiple;
o nu sunt permise reactualizarile prin vederi care implica operatia de acumulare sau de grupare.
1.3 Planificarea, proiectarea si administrarea BD
Sistem informational (SI) include resursele pentru:
colectarea
administrarea
controlul
propagarea informatiilor in intreaga organizatie.
SI al unei organizatii cuprinde
o baza de date (BD)
o elementele software ale BD
o software de aplicatie
o elementele hardware
o personalul care utilizeaza si dezvolta sistemul.
o Planificarea BD: activitati administrative pt. parcurgerea etapelor aplicatiei de tip BD cat mai eficient posibil.
o Definirea sistemului: specificarea scopului si limitelor BD, a utilizatorilor sai si a domeniilor de aplicatie.
o Colectarea si analiza cerintelor: despre organizatie si utilizarea acestor informatii pentru identificarea cerintelor utilizatorilor;
o Cerinta: o caracteristica ce trebuie inclusa in noul sistem;
o Informatiile si cererile colectate sunt exprimate neformal
o transformate structurat, cu tehnici de specificare a cerintelor
o tehnici de analiza si proiectare structurata (Structured Analysis Design)
o diagrame de flux de date (Data Flow Diagrams)
o diagrame de tip intrare-prelucrare-iesire ierarhica (Hierarchic Input Process Output).
o Proiectarea bazelor de date:
Scopurile proiectarii BD
n Reprezentarea datelor si a relatiilor dintre ele;
n Furnizarea unui model de date care sa accepte efectuarea tranzactiilor necesare;
n Proiect minim.
Doua abordari in proiectarea unui sistem de BD:
n de jos in sus atribute grupate in relatii, dupa dependentele functionale ale acestora normalizare Se aplica pt. BD simple, cu putine atribute;
n de sus in jos; pt. BD complexe; modele de date contin cateva entitati si relatii de nivel inalt rafinari succesive de sus in jos identificarea entitatilor, relatiilor si atributelor asociate de nivel jos), adica modelul ER
Continuare modelul ER (abordarea proiectarii BD de sus in jos):
o identificarea entitatilor si relatiilor de interes pt. organizatie
o finalizarea atributelor.
o Exemplu
n entitati: clienti, produse;
n se identifica relatia dintre aceste entitati: clientul cumpara produse
n se identifica atributele: Clienti (nr. client, adresa etc.) si Produse (nr. produs, factura intrare, stoc etc.).
o Alegerea sistemului SGBD
o Proiectarea aplicatiei: interfata cu utilizatorul si programele de aplicatie care utilizeaza, respectiv prelucreaza BD.
o Realizarea prototipului: model de lucru al unei BD.
o Implementarea:
n realizarea fizica a proiectelor pentru BD si aplicatii;
n se realizeaza printr-un DDL corespunzator SGBD ales.
n se realizeaza si vederile specificate de utilizatori.
n parte din programele de aplicatie tranzactiile BD implementate cu un DML; DML care poate fi incorporat intr-un limbaj de programare gazda (ex. Visual Basic, Delphi etc.).
o Conversia si incarcarea datelor
o Testarea: executarea programelor de aplicatie, pt. a gasi erori; la proiectare si testare trebuie de implicat utilizatorii
Strategii de testare:
n Testarea de sus in jos;
n Testarea de jos in sus;
n Testarea pe fir;
n Testarea la suprasolicitare.
o Intretinerea operationala: monitorizarea si intretinerea sistemului se efectueaza dupa instalarea acestuia.
n Monitorizarea performantelor sistemului;
n Intretinerea si modernizarea, prin incorporarea de noi cerinte, parcurgand etapele precedente.
1.3.2 Fazele proiectarii BD
o Proiectarea conceptuala a BD: construirea unui model al informatiilor dintr-o organizatie, independent de toate consideratiile fizice.
o Proiectarea logica a BD: construirea unui model al informatiilor utilizate din organizatie bazat pe un model de date al SGBD (de ex entitate-relatie - ER), dar independent de alte consideratii fizice legate de SGBD.
o Tehnica de normalizare
n testeaza corectitudinea unui model de date logic.
n garanteaza ca relatiile nu prezinta redundanta a datelor.
Proiectarea logica si conceptuala a BD imbinarea tuturor vederilor utilizatorilor
o model de date logic global multiple vederi ale utilizatorilor asupra organizatiei
o proiectarea unui model de date logic global:
n tratarea centralizata
n tratarea prin integrarea vederilor.
Proiectarea unui model de date logic global:
o Tratarea centralizata:
n cerintele separate ale utilizatorilor set unic de cerinte
n se construieste modelul de date logic global.
o Tratarea prin integrarea vederilor:
n modelele de date logice separate vederi distincte ale utilizatorilor un singur model de date logic global.
n vederile distincte ale utilizatorilor se numesc modele de date logice locale.
o Proiectarea fizica a BD:
n descrierea implementarii bazei de date intr-o capacitate de stocare
n descriea structurilor de stocare si metodelor de acces
o Principalul scop al proiectarii fizice presupune:
n Stabilirea unui set de tabele relational si de constrangeri asupra acestora, din informatiile provenite din modelul de date logic global;
n identificarea structurilor de stocare specifice si a metodelor de acces la date
n Proiectarea unei protectii de securitate pentru sistem;
1.3.3 Proiectarea aplicatiilor 1.3.3.1 Proiectarea tranzactiilor
o Tranzactie: actiune actiuni efectuate de un singur utilizator sau program de aplicatie, care acceseaza si pot modifica continutul BD
o O tranzactie poate fi formata din mai multe operatii si este un eveniment din lumea reala.
o Tranzactiile se proiecteaza plecand de la informatiile din cerintele utilizatorului.
o Tipuri de tranzactii:
n de regasire;
n de reactualizare;
n mixte (regasire plus reactualizare).
Ex : inregistrare de noi clienti in BD se proiecteaza
- o tranzactie pt. aceasta actiune
- o interfata prietenoasa cu utilizatorul.
o Pt. utilizatori: formular sau raport (nu tabel!)
o Fiecare formular este un tuplu dintr-un tabel
o Indicatii utile pentru proiectarea unui formular/raport
n titlu semnificativ
n instructiuni inteligibile
n grupare logica a campurilor
n aspect atragator al machetei
n etichete familiare ale campurilor
n terminologie si prescurtari coerente
n utilizare coerenta a culorilor
n spatii si limite vizibile ale campurilor de introducere a datelor
n miscare convenabila a cursorului
n corectare de erori pentru caractere individuale sau campuri intregi
n mesaje de eroare pentru valori inacceptabile
n marcare clara a campurilor optionale
n mesaje explicative pentru campuri
n semnal de terminare
1.3.4 Administrarea datelor si a bazei de date
o Administrarea datelor (DA): Gestionarea resurselor de date
o planificarea BD
o realizarea si intretinerea standardelor si procedurilor
o proiectarea conceptuala si logica a bazei de date.
o Administrarea bazei de date (DBA) Administrarea realizarii a BD, inclusiv
o proiectarea si implementarea fizica a BD,
o stabilirea controlului de securitate,integritate
o monitorizarea performantelor sistemului
o reorganizarea BD dupa necesitati.
1.4. Modelarea Entitate-Relatie (ER)
Modelul ER
model conceptual de nivel inalt Chen
independent de:
tipul de SGBD utilizat
platforma hardware asociata.
Model de date conceptual
o un set de concepte care descriu structura BD (entitati, relatii, atribute)
o tranzactiile de regasire si actualizare asociate.
Scopul realizarii unui model de date de nivel inalt:
o perceperea datelor de catre utilizator
o ascunderea aspectelor tehnice asociate proiectarii BD
1.4.1 Conceptele modelului ER
o tipurile de entitati
o tipurile de relatii
o atributele
1.4.1.1 Tipuri de entitati
Tip de entitate
Un obiect sau concept identificat de organizatie ca avand o existenta independenta.
contine un set de obiecte sau concepte cu aceleasi proprietati
Exemple: obiecte: Clienti, Produse, Personal
concepte: Vanzare
o Entitate: o instanta unica a unui tip de entitate.
Exemplu: Georgescu, Popescu sunt entitati ale tipului de entitate "Clienti"
o Entitate tare (parinte, proprietar, dominanta):
Un tip de entitate a carei existenta nu depinde de alte tipuri de entitati.
Exemplu: clienti, produse, personal,
o Entitate slaba (copil, dependenta, subordonata):
Un tip de entitate a carei existenta depinde de existenta uneia sau mai multor alte tipuri de entitati.
Exemplu: Ruda_apropiata, vanzari.
1.4.1.2 Atribute
o Atribut: proprietate a unui tip de entitate sau relatie.
o Domeniul atributului: Multimea in care ia valori atributul.
o Atribut simplu: o singura componenta, independenta.
Ex : Atribute in tipul de entitate Personal: sex, salariu
o Atribut compus mai multe componente, indep
Ex : Adresa: atributul strada + atributul numarul
o Atribut cu o singura valoare
o Atribut cu valori multiple
Ex : un client mai multe numere de telefon.
o Atribut derivat: valoare derivabila din valoarea unui atribut sau set de atribute nu neaparat in aceeasi entitate.
Ex : varsta se deriva din data nasterii.
Elipse
o contur punctat pentru atribute derivate
o contur dublu pentru atribute cu valori multiple
o Atributele compuse "radiaza" atributele componente
o Atributele cheie primara se subliniaza.
1.4.1.3 Tipuri de relatii
o Tip de relatie : O asociere semnificativa intre tipuri de entitati.
Ex : tipul de entitate "Filiala" tip de entitate "Personal" tip de relatie "este alocat".
o Relatie : o instanta unic identificabila a unui tip de relatie.
o O retea semantica prezinta aparitiile individuale ale unei relatii
o Este o diagrama la nivel de obiecte
n simbolul reprezinta entitatile
n simbolul à reprezinta relatiile
1.4.2 Constrangeri structurale
o Impuse entitatilor participante intr-o relatie ca in lumea reala.
Ex : o proprietate de inchiriat trebuie sa aiba un proprietar, filiala trebuie sa aiba personal.
o Doua mari tipuri de constrangeri structurale:
n de cardinalitate
n de participare.
o Raport de cardinalitate al unei relatii: numarul de relatii posibile pentru fiecare entitate participanta.
Pt. relatii binare raportul de cardinalitate poate fi:
o 1:1 unu la unu;
o 1: M unu la mai multi;
o M:N mai multi la mai multi.
Regulile care stabilesc cardinalitatea sunt reguli de afaceri ale organizatiei
1.4.2.2 Constrangeri de participare
o Constrangerile de participare determina daca existenta unei entitati depinde de legatura sa cu alta entitate printr-o relatie
o Doua tipuri de constrangeri de participare (a unei entitati intr-o relatie):
n participare totala sau obligatorie (linie dubla)
n participare partiala sau optionala (linie simpla).
o Participarea unei entitati intr-o relatie este totala, daca existenta ei este conditionata de existenta altei entitati prin intermediul unei anumite relatii.
o Altfel participarea este partiala.
1.4.3 Problemele modelului ER
Intr-un model de date conceptual capcane de conectare, datorita interpretarii eronate a sensului unei relatii.
1.4.3.1 Capcane in evantai
intr-un model ER se reprezinta o relatie dintre tipuri de entitati, dar caile dintre anumite aparitii ale entitatilor sunt ambigue.
doua sau mai multe relatii 1:M provin din aceeasi entitate
se stie ca o sectie coordoneaza mai multe filiale
nu rezulta la ce filiala este alocat un anumit membru al personalului dintr-o sectie
1.5 Normalizarea
Crearea unui model de date logic - obiectiv principal:
reprezentarea corecta a
datelor
relatiilor
constrangerilor.
De identificat un set de relatii adecvat: cu tehnica de normalizare.
Normalizarea este
tratarea de jos in sus a proiectarii BD,
incepe cu examinarea relatiilor dintre atribute.
o Normalizarea
n o tehnica de realizare a unui set de relatii (a unei multimi de tabele) cu proprietati (atribute) dezirabile
n o serie e teste asupra unei relatii, pentru a stabili daca aceasta satisface sau violeaza cerintele unei anumite forme normale.
o Se deosebesc:
n prima forma normala (1NF),
n a doua forma normala (2NF),
n a treia forma normala (3NF),
n forma normala Bryce-Codd (BCNF),
n a 4-a forma noramal si (4NF)
n a 5-a forma normala (5NF).
Toate formele normale se bazeaza pe dependentele functionale dintre atributele unei relatii (aceluiasi tabel). Prin aplicarea testelor de normalizare, adica prin normalizarea schemei relationale se previne aparitia anomaliilor de reactualizare.
o Atributele trebuie grupate in relatii (tabele) a i
n sa se minimizeze redundanta datelor
n sa se reduca spatiul de stocare necesar relatiilor de baza.
o Pentru stocarea in BD a informatiilor referitoare la angajati si filiale comparam doua posibilitati:
a) Crearea a doua tabele, unul cu angajatii (relatia Personal) si unul cu filialele (relatia Filiala):
o Personal (Nr_Personal, NumeP, AdresaP, Functie, Salariu, Nr_Filiala)
o Filiala (Nr_Filiala, AdresaF, Nr_Tel)
b) stocarea tuturor informatiilor intr-un tabel unic (Personal_Filiala):
o Personal_Filiala (Nr_Personal, NumeP, AdresaP, Functie, Salariu, Nr_Filiala, AdresaF, Nr_Tel).
o In relatia Personal_Filiala
o valorile atributelor ref la filiala se repeta pentru fiecare membru al personalului alocat unei anumite filiale.
o Apar astfel date redundante, care pot crea probleme numite anomalii de reactualizare, care sunt impartite in:
o anomalii de inserare
o anomalii de stergere
o anomalii de modificare.
Anomaliile de inserare
o Doua tipuri.Consideram relatia Personal_Filiala (cu date redundante).
o Inserarea unui nou membru al personalului: trebuie de inserat corect si toate datele ref la filiala la care este alocat, date aflate deja in alte randuri din acelasi tabel.
o Inserarea de date referitoare la o filiala care nu are alocat inca nici un membru de personal: de trecut Null-uri in celulele pentru atributele personalului.
n Dar Nr_Personal fiind cheie primara, introducerea de Null-uri violeaza integritatea entitatilor si nu va fi permisa
n Deci nu poate fi inserata o filiala noua fara personal alocat.
o Aceste probleme se evita proiectand si utilizand doua relatii distincte, anume: Personal si Filiala.
Anomaliile de stergere
o Daca in relatia Personal_Filiala o anumita filiala apare o singura data (filiala are un singur membru de personal), atunci stergerea acestui membru de personal va duce la stergerea si a informatiilor referitoare la filiala respectiva.
Anomalii de modificare
o Daca reactualizam de exemplu un numar de telefon al unei filiale din tabelul Personal_Filiala, atunci acest numar va trebui de reactualizat in acest tabel in toate randurile in care apare filiala respectiva
o Proprietatile de uniune fara pierderi si conservare a dependentei
Relatia Personal_Filiala este expusa anomaliilor de reactualizare si trebuie descompusa in doua relatii (tabele) distincte: Personal si Filiala.
o Descompunerea are doua proprietati importante:
n Uniune fara pierderi: permite regasirea oricarei instante din relatia initiala in instantele corespunzatoare ale relatiilor mai mici.
n Conservarea dependentei: permite impunerea unei constrangeri asupra relatiei initiale, prin impunerea unei constrangeri asupra fiecareia dintre relatiile mai mici. Adica nu este necesara efectuarea uniunii relatiilor mai mici pentru a verifica daca este violata o constrangere asupra relatiei initiale.
1.5.3 Dependente functionale
o Dependenta functionala: descrie legaturile dintre atributele unei relatii (unei tabel)
n De ex , daca A si B sunt atribute ale relatiei R, atributul B este dependent functional de A (se noteaza A B) daca fiecarei valori a atributului A ii este asociata exact o valoare atributului B (A si B pot fi formate din mai multe atribute fiecare).
o Atunci cand exista o dependenta functionala, ea este specificata ca o constrangere intre atribute.
o A B: pentru o valoare data a lui A (in toate randurile din tabel unde apare aceasta valoare) se va gasi o singura valoare a lui B
A = atributul "localitate";
B = atributul "judet".
A B (B este dependent functional de A), in fiecare rand unde A are valoarea Codlea, B va avea valoarea Brasov
Determinantul unei dependente functionale se refera la atributul
din partea stanga a sagetii.
Aici A este determinantul lui B.
1.5.3 Dependente functionale
In Personal_Filiala exista 13 dependente functionale cu urmatorii determinanti, in stanga sagetii
o Nr_Personal NumeP;
o Nr_Personal AdresaP;
o Nr_Personal Functie;
o Nr_Personal Salariu;
o Nr_Personal Nr_Filiala;
o Nr_Personal AdresaF;
o Nr_Personal Nr_Tel;
o Nr_Filiala AdresaF;
o Nr_Filiala Nr_Tel;
o AdresaF Nr_Filiala;
o AdresaF Nr_Tel;
o Nr_Tel Nr_Filiala;
o Nr_Tel AdresaF;
Identificarea cheii primare a unei relatii cu ajutorul dependentei functionale
o Se identifica intai toate cheile candidat
o Toate atributele care nu fac parte din cheia primara trebuie sa fie dependente functional de aceasta.
o Deci cheia primara va fi acel atribut (sau set de atribute) care determina functional toate celelalte atribute ale relatiei.
o Cheia primara va fi acel atribut (sau set de atribute) de care sunt dependente functional toate celelalte atribute ale relatiei.
o In relatia Personal_Filiala aceasta cerinta o indeplineste numai atributul Nr_Pers.
1.5.4 Procesul de normalizare
o Normalizarea tehnica formala de analizare a relatiilor bazata pe cheile primare ale acestora si pe dependentele functionale.
n Tehnica presupune o serie de reguli pentru testarea relatiilor individuale,
n rezulta normalizarea bazei de date.
n Cand o cerinta nu este indeplinita, relatia care o violeaza trebuie descompusa in relatii care satisfac individual cerintele normalizarii.
o Normalizarea o serie de pasi corespunzatori unei anumite forme normale.
o Pentru modelul relational numai prima forma normala (1NF) este de importanta critica in crearea de relatii adecvate.
Prima forma normala
o Forma nenormalizata (UNF) un tabel care contine unul sau mai multe grupuri repetitive.
o Prima forma normala (1NF) o relatie in care intersectia fiecarui rand cu fiecare coloana contine o singura valoare si numai una.
o Datele sunt introduse prin intermediul unui formular.
o Se stocheaza intr-un tabel de forma nenormalizata.
o Se identifica si se elimina grupurile repetitive pentru a aduce tabelul in prima forma normala (1NF).
o Un grup repetitiv este un atribut grup de atribute dintr-un tabel care are valori multiple pentru o singura aparitie a atributului (atributelor) cheie primara din acel tabel
Exista doua tratari uzuale pentru eliminarea grupurilor repetitive din tabele.
o Prima tratare: se introduc datele adecvate in coloanele goale ale randurilor care contin date repetitive.
o Exemplu Formular pt. introducere in BD de "Detalii client-inchiriere".
n Simplificare
o un client inchiriaza o anumita proprietate o singura data
o nu poate inchiria mai mult de o proprietate in acelasi timp.
Aducerea in 1NF - prima tratare
o Se identifica cheile candidat vor fi chei compuse
n (Nr_Client, Nr_Proprietate);
n (Nr_Client, InceputInchir)
n (Nr_Proprietate, InceputInchir).
Cheia primara selectata: (Nr_Client, Nr_Proprietate);
o Relatia Client_Inchiriere in 1NF:
Client_Inchiriere (Nr_Client, Nr_Proprietate, NumeC, AdresaP, InceputInchir, SfarsitInchir, Chirie, Nr_Proprietar, NumeP)
o 1NF la intersectia unui rand cu o coloana exista o singura valoare
o in acelasi timp date redundante.
o Relatia va trebui trecuta in 2NF sau se aplica tratrea a doua a relatiei UNF pt. a o aduce in 1NF.
Aducerea in 1NF - a doua tratare
Se elimina grupul repetitiv prin
plasarea intr-o relatie separata (tabel copil) a datelor repetitive
plasarea in relatia separata a unei copii a atributului cheie primara initial (Nr_Client), care devine cheie straina
plasarea in relatia separata a atributului ce contine grupul repetitiv
se identifica o cheie primara pentru noua relatie
Formele celor 2 relatii rezultante in 1NF:
Client (Nr_Client, NumeC)
Prop_Inchir_Proprietar (Nr_Client, Nr_Proprietate, AdresaP, InceputInchir, SfarsitInchir, Chirie, Nr_Proprietar, NumeP)
Ambele sunt in 1NF (la intersectia dintre fiecare rand si fiecare coloana exista o singura valoare
A doua relatie o oarecare redundanta a datelor
anomalii de reactualizare
trecerea in 2NF.
1.6 Metodologia de proiectare conceptuala a bazelor de date
o Pasul 1: proiectarea conceptuala
o Pasii 2 si 3: proiectarea logica
o Pasii 4, 5, 6, si 7: proiectarea fizica.
Proiectarea conceptuala a bazei de date
procesul de construire a unui model al informatiilor utilizate in organizatii
independent de consideratiile de ordin fizic (SGBDul utilizat).
Vederea unui utilizator o zona functionala a intreprinderii (productia, marketingul, vanzarile, resursele umane, contabilitatea, aprovizionarea etc.).
vederii respective ii corespunde un model de date conceptual local
Pasul 1.1 Identificarea tipurilor de entitati (t.e.)
Modalitati de identificare:
o se cauta substantivele in specificatia cerintelor utilizatorului (de exemplu Nr_Personal; NumeP; Nr_Proprietate; AdresaP; Chirie etc.)
o se cauta obiectele principale de interes, excluzandu-se calitatile; se grupeaza (de exemplu Nr_Personal si NumeP vor apartine aceluiasi tip de entitate Personal)
o se identifica obiectele care exista pe cont propriu (de exemplu Personal exista indiferent de Nr_Personal, NumeP, etc.)
o discutii cu utilizatorii (de exemplu pentru eliminarea sinonimelor: Angajat = Personal)
o Documentarea t.e.: dupa identificarea t.e. li se atribuie denumiri evidente, care se trec intr-un dictionar de date.
Pasul 1.2 Identificarea tipurilor de relatii (t.r.)
o Identificare: expresii verbale in specificatia utilizatorului.
n filiale are personal;
n personal administreaza proprietate;
n chirias viziteaza proprietate etc.
Intereseaza numai relatiile dintre entitati cerute. Majoritatea relatiilor sunt binare. Este bine de verificat fiecare pereche de tipuri de entitati, pentru a gasi o posibila relatie intre ele.
o Determinarea cardinalitatii (1:1; 1:M; M:N) si constrangerilor de participare (totala, partiala); eventual se specifica si valorile limita ale cardinalitatii.
o Documentarea tipurilor de relatii. Pe masura ce sunt identificate, li se atribuie denumiri evidente; acestea, precum si constrangerile se trec in dictionarul de date.
o Vizualizarea pe parcurs a t.e. si t.r. identificate prin modelarea ER.
Pasul 1.3 Identificarea si asocierea atributelor cu t.e. sau t.r.
o Identificare: Substantive in specificatia utilizatorilor caracterizeaza t.e. si t.r. gasite
o Atributele sunt proprietati, calitati, caracteristici identificatoare ale unei entitati sau relatii.
o Se deosebeste intre atribute simple, compuse, derivate. Atributele derivate trebuie reprezentate in modelul conceptual pentru a nu pierde informatii.
o Documentarea atributelor:
n denumiri evidente si semnificative pentru utilizatori.
n Pt. fiecare atribut se trec in dictionarul de date: denumirea, sinonime sau aliasuri, tipul de date si lungimea, eventuale valori prestabilite (default value), daca se accepta Null-uri (required: Y/N), daca e compus sau derivat, formula de calcul, daca are valori multiple.
Pasul 1.4 Determinarea domeniilor atributelor
o Determinarea:
n Domeniul un recipient de valori din care unul sau mai multe atribute isi iau valorile.
n Domeniul numerelor de filiala valabile este compus din 3 caractere, litera-cifra-litera. Domeniul va include si multimea valorilor permise, dimensiunea si formatul campului.
o Documentarea domeniului atributelor: se inregistreaza denumirea si caracteristicile domeniilor atributelor in dictionarul de date.
Pasul 1.5 Determinarea atributelor chei candidat si chei primare
o pt. fiecare entitate
n se identifica toate cheile candidat
n se selecteaza dintre ele cheia primara.
n Cheia primara aleasa:
o va cuprinde un set minim de atribute
o va fi cheia candidat cu cea mai mica probabilitate de modificare a valorilor
o va fi cheia candidat cu cea mai mica probabilitate de a-si pierde caracterul de unicitate
o va fi cheia candidat cu cele mai putine caractere
o va fi cheia candidat cel mai usor de utilizat d.p.d.v. al utilizatorilor
o Entitate tare: i se poate identifica o cheie primara
o Entitate slaba: i se poate identifica o cheie primara numai prin plasarea in ea a unei chei straine, in cadrul relatiei sale cu entitatea tare.
o Cheile candidat care nu sunt selectate cheie primara devin chei alternative.
o Documentarea cheilor primare si alternative prin inregistrare in dictionarul de date.
Pasul 1.6 Specializarea/generalizarea tipurilor de entitati (optional)
o Reprezentarea cat mai clara a entitatilor importante si a relatiilor dintre ele. Diagrama ER finala trebuie sa fie cat mai lizibila.
o Model ER entitatile Proprietate_de_Inchiriat si Proprietate_de_Vanzare.
o Se generalizeaza prin crearea entitatii Proprietate
Pasul 1.7 Desenarea diagramei ER
o Reprezentarea conceptuala a vederii unui utilizator asupra intregii intreprinderi.
Pasul 1.8 Revizuirea modelului de date conceptual local impreuna cu utilizatorii
o Pentru a garanta ca modelul este o reprezentare "adevarata" a intreprinderii d.p.d.v. al utilizatorului.
1.7 Metodologia de proiectare logica a bazelor de date pentru modelul relational
Proiectarea logica
construirea unui model al informatiilor din intreprindere pe baza unui anumit model de date
independent de SGBD si de alte consideratii de ordin fizic.
1.7.1 Pasul 2.
Construirea si validarea modelului de date logic pentru fiecare vedere a utilizatorilor
o bazat pe modelul de date conceptual al vederii utilizatorului asupra intreprinderii (realizat la pasul 1).
o se modifica structura modelului conceptual conform cerintelor modelului de date relational (conf cerintelor caracteristice unui SGBD relational).
o Pasul 2.1 Transpunerea modelului de date conceptual local intr-un model de date logic local
Se rafineaza modelul de date conceptual local prin eliminarea caracteristicilor nedorite.
o Pasul 2.1.1 Eliminarea relatiilor de tip M:N
o Pasul 2.1.1 Eliminarea relatiilor de tip M:N
o O relatie M:N se descompune pentru a identifica o relatie intermediara.
o Relatia M:N se inlocuieste cu doua relatii 1:M.
o Ex
o Relatia Ziar Face Reclama Proprietate
o de cardinalitate M:N.
o Pasul 2.1.2 Eliminarea relatiilor complexe
o O relatie complexa cel putin trei tipuri de entitati.
o Se descompune pentru a identifica o relatie intermediara.
o Se inlocuieste cu un numar corespunzator de relatii binare de cardinalitate 1:M.
o Un tip particular de relatie care trebuie descompusa pentru a identifica o relatie intermediara.
o Relatia recursiva Supravegheaza este eliminata prin identificarea unei relatii aditionale denumita SupravegheatDe si a unei entitati slabe: Personal_Alocat
o Pot indica existenta a doua relatii care sa reprezinte acelasi obiect.
o De exemplu entitatile Filiala si Departament pot fi sinonime.
o Cele doua entitati se imbina, selectand una din cheile primare, daca acestea nu coincid.
o Cealalta cheie primara devine alternativa.
o Relatie redundanta aceeasi informatie se poate obtine si prin alte relatii.
o De aflat daca exista mai mult decat o singura cale intre doua entitati.
o Daca se identifica 2 cai, nu inseamna neaparat ca una din relatii este redundanta.
o Trebuie de tinut cont si de semnificatia temporala a relatiilor
o Pasul 2.1 Transpunerea modelului de date conceptual local intr-un model de date logic local
o Pasul 2.2 Extragerea relatiilor (tipurilor de entitati) din modelul de date logic local
o Se extrag relatiile pentru a reprezenta entitatile care le compun.
o Componenta fiecarei relatii se descrie printr-un limbaj de definire a bazelor de date (DBDL).
o Intr-un DBDL apare
o denumirea relatiei
o intre paranteze atributele simple.
o Se identifica cheia primara, cheile alternative si/sau cheile straine ale relatiei.
o Se trece relatia care contine cheia straina ca si cheie primara.
o Relatia dintre o entitate si alta este exprimata prin mecanismul cheie primara - cheie straina.
o Cheia primara din entitatea parinte devine cheie straina in entitatea copil.
Din acest model de date logic se extrag:
o a. Tipuri de entitati tari:
Pentru fiecare entitate tare (obisnuita) se creeaza o relatie care sa cuprinda toate atributele sale simple.
n Exemplu: entitatea tare Personal
n Personal (Nr_Personal, Prenume, Nume, Strada, Orasul, CodP, Functia, Sex, Salariu)
n Cheie primara Nr_Personal
o b. Tipuri de entitati slabe: Ruda_Apropiata.
Pentru fiecare entitate slaba se creeaza o relatie care sa cuprinda toate atributele sale simple se include cheia primara a entitatii parinte (sau proprietar) ca si cheie straina.
n Ruda_Apropiata (Nr_Personal, NumeR, Adresa, Nr_Tel, Rudenie)
n Cheie primara Nr_Personal impreuna cu NumeR
n
Cheie
straina Nr_Personal se
refera
c. Tipuri de relatii binare 1:1
o In relatia Personal Administreaza Filiala entitatea parinte este Personal, deoarece are participare partiala.
n Se plaseaza o copie a cheii primare din Personal in Filiala, unde devine cheie straina sub denumirea Nr_Personal_Manager.
Compozitia acestor relatii va fi:
o Personal (Nr_Personal, Prenume, Nume, Strada, Orasul, CodP, Functia, Sex, Salariu)
n Cheie primara Nr_Personal
o Filiala (Nr_Filiala, Adresa, Nr_Tel, Nr_Fax, Nr_Personal_Manager)
n Cheie primara Nr_Filiala
n Cheie alternativa Nr_Tel sau Nr_Fax
n
Cheie
straina
Nr_Personal_Manager, care se refera
d. Tipuri de relatii binare 1:M
Pentru fiecare relatie binara 1:M intre entitatile E1 si E2
Se copiaza cheia primara din E1 in E2, unde devine cheie straina.
Entitatea aflata in partea notata cu "1" este entitatea parinte,
Enitatea din partea cu "M" este entitatea copil.
Ex : Filiala Are Personal Filiala este parinte Personal este copil.
Compozitia acestor relatii va fi:
o Personal (Nr_Personal, Prenume, Nume, Strada, Orasul, CodP, Functia, Sex, Salariu, Nr_Filiala)
n Cheie primara Nr_Personal
n Cheie straina Nr_Filiala se refera
o Filiala (Nr_Filiala, Adresa, Nr_Tel, Nr_Fax, Nr_Personal_Manager)
n Cheie primara Nr_Filiala
n Cheie alternativa Nr_Tel sau Nr_Fax
n
Cheie
straina
Nr_Personal_Manager, care se refera
o Pasul 2.2. se incheie cu documentarea relatiilor si atributelor chei straine.
o Compozitia relatiilor extrase din modelul de date logic se documenteaza utilizand DBDL.
o Sintaxa poate fi extinsa pentru a exprima constrangerile de integritate asupra cheilor straine (vezi pasul 2.6).
o Si dictionarul de date trebuie reactualizat cu noile atribute cheie identificate la pasul 2.2
o Normalizarea procedura de stabilire a atributelor care apartin impreuna unui tip de entitate.
o Prin normalizare datele sunt organizate conform dependentelor lor functionale
o Se elimina riscul anomaliilor de reactualizare.
o In prima forma normala se elimina grupurile repetitive.
o Modelul trebuie sa accepte tranzactiile cerute de catre vederile utilizatorului.
o Tranzactiile se determina din specificatiile cerintelor utilizatorilor.
o Prin folosirea diagramei ER, a dictionarului de date si a legaturilor cheie primara/cheie straina prezentate in relatii se incearca efectuarea manuala a tranzactiilor.
o Se deseneaza varianta finala a diagramei ER
n validata prin normalizare
n conform cu tranzactiile pe care trebuie sa le accepte.
Prin impunerea de constrangeri se protejeaza baza de date fata de riscul de incoerenta.
Se considera 5 tipuri de integritate, anume referitoare la:
o datele cerute
o domeniile atributelor
o integritatea entitatilor
o integritatea referentiala
o constrangerile intreprinderii
Pasul 2.6 Definirea constrangerilor de integritate
Prin impunerea de constrangeri se protejeaza baza de date fata de riscul de incoerenta.
Se considera 5 tipuri de integritate, anume referitoare la:
o datele cerute
o domeniile atributelor
o integritatea entitatilor
o integritatea referentiala
o constrangerile intreprinderii
o a. Datele cerute
n Unele atribute nu admit Null-uri.
n Se selecteaza proprietatea de camp required,
n Se verifica daca aceste constrangeri au fost identificate si documentate in dreptul atributelor in dictionarul de date (vezi pasul 1.2)
o b. Constrangerile privind domeniile atributelor
n Se verifica daca s-au identificat si documentat la pasul 1.4
c. Integritatea entitatilor
o Cheia primara a unei entitati nu poate contine Null-uri si nu-si repeta valoarea. Se verifica pasul 1.5
d. Integritatea referentiala
o Se refera la relatia entitate parinte - entitate copil.
o Se stie ca cheia primara din parinte se copiaza in copil unde devine cheie straina.
Integritatea referentiala inseamna ca o valoare nenula a cheii straine din entitatea copil trebuie sa se refere la (sa coincida cu) o valoare existenta in entitatea parinte.
d. Integritatea referentiala - continuare
o Daca entitatea copil are participare totala in relatie, nu sunt permise Null-uri in campul cheie straina.
n Null-uri pt. cheia straina se admit atunci cand entitatea copil are participare partiala.
o Asigurarea integritatii referentiale se realizeaza prin constrangeri de existenta. Acestea definesc conditiile in care poate fi inserata, reactualizata (modificata) sau stearsa o cheie candidat sau o cheie straina.
Se ia ca exemplu relatia Personal Administreaza Proprietate, de cardinalitate 1:M.
o Entitate parinte (Ep): Personal, cheie primara: Nr_Personal
o Entitate copil (Ec): Proprietate, cheie straina: Nr_Personal, copie a cheii primare din Personal.
d. Integritatea referentiala - continuare
o Cazul 1. Inserarea unei aparitii in relatia (entitatea) copil
n Pentru a asigura integritatea referentiala se verifica daca atributul Nr_Personal din aparitia nou inserata in Ec este Null sau are o valoare existenta in Ep.
o Cazul 2. Stergerea unei aparitii din relatia (entitatea) copil
n Se poate efectua fara probleme, nu afecteaza integritatea referentiala.
d. Integritatea referentiala - continuare
o Cazul 3. Reactualizarea cheii straine in relatia (entitatea) copil
n Similar cazului 1.
o Cazul 4. Inserarea unei aparitii in relatia (entitatea) parinte
n Se poate efectua fara probleme. Ep are participare partiala, deci poate exista un membru al personalului care nu administreaza o proprietate.
d. Integritatea referentiala - continuare
o Cazul 5. Stergerea unei aparitii din relatia (entitatea) parinte.
n Daca aparitiei care urmeaza a fi stearsa din Ep ii corespunde o aparitie (sau mai multe) din Ec, atunci integritatea referentiala se pierde prin stergere.
n Posibile strategii de luat in considerare:
d. Integritatea referentiala - continuare
o NO ACTION: Blocarea stergerii aparitiei din Ep, daca are corespondent(i) in Ec
o CASCADE: Daca o aparitie in Ep se sterge, se sterg automat corespondentii din Ec. Daca Ec actioneaza ca Ep in alta relatie, stergerea se propaga in cascada.
o
SET NULL: Cand se sterge o aparitie din Ep, valorile
cheii straine in Ec sunt setate
d. Integritatea referentiala - continuare
o SET DEFAULT: Cand se sterge o aparitie din Ep, valorile cheii straine corespunzatoare din Ec sunt setate la valori prestabilite (default).
n Exemplu: se sterge un membru al personalului in Ep (Personal) si automat proprietatile pe care acestea le-a administrat trecute in Ec (Proprietati) se seteaza la atributul Nr_Pers la valoarea corespunzatoare managerului.
o NO CHECK: Nu are loc nici o verificare de integritate. Cand se sterge o aparitie din Ep nu este garantata mentinerea integritatii referentiale.
d. Integritatea referentiala - continuare
o Cazul 6. Reactualizarea cheii primare in relatia (entitatea) parinte
n Daca valorii reactualizate a cheii primare in Ep ii corespundeau una (mai multe) valori ale cheii straine in Ec, integritatea referentiala este pierduta. Se va aplica una din strategiile de la cazul 5.
e. Constrangerile intreprinderii
o Regulile de afaceri care pot uneori genera reactualizari ele entitatilor.
n De exemplu agentia imobiliara poate stabili ca un membru al personalului sa administreze maxim 10 proprietati.
Pasul 2.6. se incheie cu documentarea tuturor constrangerilor de integritate. Aceasta se face in dictionarul de date, pentru a fi luate in considerare la implementarea fizica.
Pasul 2.7 Revizuirea modelului de date logic local impreuna cu utilizatorii
o Se verifica daca modelul de date logic local este o reprezentare "adevarata" a vederii utilizatorului.
o Modelul de date logic local trebuie sa fie complet si in intregime documentat.
o Modelul si documentatia se revad impreuna cu utilizatorul.
Proiectarea bazelor de date
o Pasul 1: proiectarea conceptuala
n Pasul 1. Construirea modelului de date conceptual local pentru fiecare vedere a utilizatorilor
o Pasii 2 si 3: proiectarea logica
n Pasul 2. Construirea si validarea modelului de date logic local pentru fiecare vedere a utilizatorilor
n Pasul 3. Construirea si validarea modelului de date logic global
o Pasii 4, 5, 6, si 7: proiectarea fizica.
o Pasul 3.1 Imbinarea modelelor de date logice locale individuale intr-un singur model de date logic global al intreprinderii
n Revizuirea denumirilor entitatilor si cheilor primare din modelele locale.
o doua sau mai multe entitati care au aceeasi denumire dar sunt de fapt diferite
o doua sau mai multe entitati care au denumiri diferite, dar sunt aceleasi.
o Se compara continutul de date al fiecarui tip de entitate. Se utilizeaza cheile primare pentru a identifica tipurile de entitati echivalente, dar cu denumiri diferite.
n Revizuirea denumirilor relatiilor. Se procedeaza ca la (1).
n Imbinarea entitatilor din vederile locale
n - 11. urmeaza incepand cu slide 7
Imbinarea ent cu aceeasi denumire si aceeasi cheie primara
Imbinarea entitatilor cu denumiri diferite, cu chei primare similare sau diferite
o denumirile sunt diferite, dar indica acelasi scop; se pot identifica
n dupa cheia primara
n dupa participarea in anumite relatii.
o Exemplu: Entitatile Personal si Angajati.
(4) Preluarea in modelul global, (fara imbinare) a entitatilor unice din fiecare vedere locala
Toate entitatile care nu au echivalent se includ nemodificate in modelul global.
Imbinarea relatiilor din vederile locale
Se examineaza toate relatiile (denumire, scop, constrangeri structurale) din toate vederile locale si se elimina conflictele, prin:
- Imbinarea relatiilor cu aceeasi denumire si acelasi scop, apoi
- Imbinarea relatiilor cu denumiri diferite dar acelasi scop
Includerea (fara imbinare) a relatiilor unice din fiecare vedere locala
Relatiile pentru care nu s-au gasit relatii identice in alte vederi se includ nemodificate in modelul global.
Cautarea entitatilor si relatiilor lipsa
Pot rezulta din modelul de date general, daca exista.
utilizatorii trebuie sa examineze si entitatile si relatiile din alte vederi.
Se examineaza atributele fiecarui tip de entitate si se compara cu atributele entitatilor din alte vederi.
Un atribut dintr-o vedere poate corespunde unui atribut cheie primara, cheie alternativa sau unui atribut simplu al unei entitati din alta vedere.
Dintr-o astfel de corespondenta rezulta existenta unei relatii neidentificate, construibila prin mecanismul cheie primara/cheie straina.
Verificarea cheilor straine
Cheile straine din entitatile copil mai sunt corecte? Se efectueaza modificarile necesare.
Verificarea constrangerilor de integritate
Constrangerile de integritate ale modelului global intra in conflict cu constrangerile de integritate din vederile utilizatorilor Se rezolva prin consultarea cu utilizatorii.
Desenarea modelului de date logic global
Se deseneaza diagrama ER a modelului de date logic global
Reprezinta imbinarea tuturor modelelor de date logice locale.
Reactualizarea documentatiei
Documentatia trebuie reactualizata
Documentatia trebuie sa reflecte intotdeauna modelul de date curent.
Pasul 3. Construirea si validarea modelului logic global
Pasul 3.2 Validarea modelului de date logic global
Prin normalizare si conform tranzactiilor cerute, daca este necesar (Echivalent cu 2.3 resp 2.4, dar pentru modelul de date logic global
Pasul 3.3 Verificarea in vederea dezvoltarii locale
Modelul de date logic global trebuie sa poata fi extins sa poata evolua in conditiile afectarii minime a utilizatorului.
Se incorporeaza modificari numai daca utilizatorul o cere.
Pasul 3.4 Desenarea diagramei ER finale
Reprezinta modelul de date logic global al intreprinderii. Dupa ce modelul de date logic global a fost validat. Documentatia (schema relationala si dictionarul de date) trebuie reactualizata si completata.
Pasul 3.5 Revizuirea modelului de date logic global impreuna cu utilizatorii
Pt. a garanta ca modelul de date logic global este o reprezentare "adevarata" a intreprinderii.
Modelul impreuna cu documentatia se revizuiesc in colaborare cu utilizatorii, pentru a confirma ca sunt corecte si complete.
1.8 Metodologia de proiectare fizica a bazelor de date pentru bazele de date relationale
Pasul 4. Transformarea modelului de date logic global pentru un SGBD tinta
Proiectantul trebuie sa cunoasca foarte bine SGBD tinta, anume:
daca sistemul accepta definirea cheilor primare, straine, alternative
daca sistemul accepta definirea datelor necesare (adica daca sistemul permite definirea datelor ca NOT NULL)
daca sistemul accepta definirea domeniilor
daca sistemul accepta definirea constrangerilor intreprinderii
cum se creeaza relatiile de baza.
Se alege un SGBD ale carui facilitati permit implementarea tuturor informatiilor documentate prin DBDL si dictionarul de date.
Pasul 4.1 Proiectarea relatiilor de baza pentru SGBD tinta
Trebuie confruntate si asimilate informatiile referitoare la relatii (tabele) obtinute prin modelarea logica a datelor.
Aceste informatii sunt obtinute din definitia relatiilor (in DBDL) si din dictionarul de date.
Pentru fiecare relatie identificata in modelul de date logic global vom avea o definitie formata din:
o denumirea relatiei
o lista de atribute simple (intre paranteze)
o cheia primara (PK), si dupa caz, cheile alternative (AK) si cheile straine (FK)
o constrangerile de integritate corespunzatoare oricarei chei straine (FK) identificate
Pasul 4.1 Proiectarea relatiilor de baza pentru SGBD tinta
Din dictionarul de date, pentru fiecare atribut exista si:
o domeniul atributului, care consta din tipul de date, lungimea acestora si constrangeri asupra domeniului
o optional, o valoare prestabilita a atributului
o daca atributul poate contine NULL uri
o daca atributul este derivat, si in acest caz cum trebuie calculat.
Pasul 4.1 Proiectarea relatiilor de baza pentru SGBD tinta
Proiectul (fizic) pentru
relatia de baza (tabelul) Proprietate_de_Inchiriat,
in DBDL, pentru implementarea cu ajutorului SGBD MS-Access
Pasul 4. Transformarea modelului de date logic global pentru un SGBD tinta
Proiectul logic initial a fost adaptat functionalitatii SGBD tinta (MS-Access).
Exemple ale acestui proces de adaptare (rafinare):
Pasul 4.1 Proiectarea relatiilor de baza pentru SGBD tinta
Se trece la
crearea bazei de date in MS_Access, pornind de
Vizualizarea de proiectare (Design View) a tabelului corespunzator relatiei Proprietate_de_Inchiriat.
toate tabelele proiectate au fost create
se realizeaza relatiile dintre acestea
se impune integritatea referentiala
In cadrul tabelelor:
o se specifica cheia primara
o se seteaza proprietatile campurilor: field size, format, input mask, caption, default value, validation rule/text, required.
o Se creeaza liste de tip "lookup", ca cea pentru tipul de proprietate
Pasul 4.1 Proiectarea relatiilor de baza pentru SGBD tinta
o Cascade Update Related Fields: modificarea unei valori din cheia primara din tabelul parinte declanseaza automat reactualizarea valorilor corespunzatoare din toate inregistrarile legate.
o Cascade Delete Related Records: stergerea unei inregistrari din tabelul parinte duce la stergerea tuturor inregistrarilor legate din tabelul copil.
(vezi exemplu "stergere conturi inchise")
Pasul 4.2. Proiectarea constrangerilor intreprinderii pentru SGBD tinta
o Exemplu: Un angajat nu poate administra mai mult de 10 proprietati. Constrangerile trebuie reproiectate in functie de SGBD ales, respectiv invers, SGBD se alege astfel incat sa permita implementarea acestei constrangeri.
o Pentru Access implementarea constrangerilor de intreprindere se realizeaza de exemplu cu limbajul Visual Basic, care lucreaza cu baze de date in Access
Se determina organizarea fisierelor si metodelor de acces utilizate pentru stocarea relatiilor de baza.
Stocarea eficienta a datelor se evalueaza prin:
o transferul de tranzactii: numar de tranzactii prelucrabile in timp
o timpul de raspuns: timpul scurs pana la incheierea unei singure tranzactii (de minimizat)
o capacitatea de stocare pe disc: spatiul pe disc necesar stocarii fisierelor bazei de date (de minimizat).
Pasul 5.1 Analizarea tranzactiilor
Pentru fiecare tranzactie se determina:
frecventa estimata cu care vor fi rulate tranzactiile
relatiile (tabelele) accesate de tranzactie
atributele accesate de tranzactie
tipul de acces (interogare, inserare, reactualizare, stergere)
constrangerile de timp impuse tranzactiilor
o In cazul BD a unei agentii imobiliare se considera - cu titlu de exemplu - urmatoarele tranzactii:
o A: realizarea unui raport in care sunt enumerate proprietatile de inchiriat din cadrul fiecarei filiale
o B: crearea si intretinerea inregistrarilor referitoare la clientii din cadrul fiecarei filiale
o C: enumerarea vizitelor efectuate de clienti, cunoscand adresele proprietatilor vizitate
a) Harta cu modelul ER simplificat cu numerele estimate de aparatii ale fiecarei entitati
o In tabelul "Fililala" sunt inregistrate 50 de filiale.
n Unei filiale ii sunt alocate in medie 240 si maxim 300 proprietati de inchiriat.
n La o filiala sunt inregsitarti in medie 400 si maxim 500 de chiriasi.
o In tabelul "Proprietate_de_Inchiriat" sunt inregistrate estimativ 12000 proprietati (50 filiale x 240 proprietati, in medie/filiala).
n O proprietate de inchiriat este vizitata (apare in "Vizitare") in medie de 20 si maxim de 40 de ori.
o In tabelul "Chirias" sunt inregistrati estimativ 20000 de chiriasi (50 filiale x 400 chiriasi in medie/filiala)
n Un chirias efectueaza in medie 10 si maxim 20 de vizitari.
o In tabelul "Vizitare" sunt inregistrate estimativ 360000 vizitari (12000 proprietati de inchiriat x 30 vizitari /proprietate)
b) Harta cailor si operatiilor tranzactiilor A, B si C
In harta b) operatiile de
inserare (I)
citire (C)
reactualizare (R)
stergere (S)
impreuna cu calea corespunzatoare tranzactiilor A, B si C.
A: realizarea unui raport in care sunt enumerate proprietatile de inchiriat din cadrul fiecarei filiale
o accesarea tabelului "Filiala"
o citirea (C) a datelor din acest tabel
o prin Nr_Filiala (ch pr in Filiala ch str in Proprietate_de_Inchiriat) se citesc (C) proprietatile de inchiriat oferite de fiecare filiala.
B: crearea si intretinerea inregistrarilor referitoare la clientii din cadrul fiecarei filiale
o inserarea (I) a clientilor (chiriasilor)
n in tabelul "Chirias" si
n la o anume filiala
o reactualizarea (R)
o stergerea (S) datelor referitoare la chiriasi
o se va accesa tabelul "Filiala",
o prin Nr_Filiala (ch pr in "Filiala" ch str in "Chirias") se vor insera, citi, reactualiza sau sterge chiriasii inregistrati la fiecare filiala.
C: enumerarea vizitelor efectuate de clienti, cunoscand adresele proprietatilor vizitate
o accesarea tabelului "Proprietate_de_Inchiriat", punct de acces fiind atributul adresa proprietatii, cunoscut.
o Prin atributul Nr_Proprietate (cheie primara in "Proprietate_de_Inchiriat" si cheie straina in "Vizitare") se citesc (C) vizitelor efectuate la acea proprietate.
Se pot inregistra si
ziua si ora estimata la care va fi rulata fiecare tranzactie
momentul sau intervalul de incarcare maxima.
Pentru tranzactiile care acceseaza frecvent baza de date, modelul lor de executie se documenteaza ca in cazul exemplului de mai jos, referitor la tranzactia D:
D: cautarea proprietatilor de inchiriat oferite de o anumita filiala, care satisfac un anumit tip de proprietate cerut de un potential chirias.
o Operatii necesare D citire (C)
o Atributele puncte de acces de intrare notate cu (P).
o se acceseaza tabelul "Filiala",
n punct de acces cheia primara Nr_Filiala, care se citeste (C).
o Din "Filiala"
n prin Nr_Filiala ch pr./ch.str se citesc (C) in "Proprietate_de_Inchririat" proprietatile oferite de o anumita filiala.
n Atributul "Tipul" punct de intrare pentru interogare (clientul cauta un anumit tip de proprietate).
o La accesarea unui numar de filiala din "Filiala" se acceseaza tabelul "Proprietate_de_Inchiriat" de 48 - 300 ori
n exista minim 48 de proprietati din fiecare tip disponibile la o filiala,
n o filiala ofera maxim 300 de proprietati).
Analizand toate tranzactiile (nu numai A, B, C, si D ) asupra intregii BD a agentiei imobiliare
Þ foarte multe tranzactii necesita accesarea tabelului "Proprietate_de_Inchiriat".
Pasul 5.2 Alegerea organizarii fisierelor
Se alege tipul adecvat de fisier, care poate fi:
Heap
Hash
ISAM - Indexed Sequential Access Method;
arbore B+.
SGBD bazate pe (de ex. MS-Access) nu permit utilizatorului alegerea sau modificarea organizarii fisierelor din tabelele de baza.
Imbunatateste adaugarea de indexuri secundare performantele sistemului (Mecanism de specificare a unei chei aditionale, pentru regasirea mai eficienta a datelor
Exemplu: entitatea Proprietate_de_Inchiriat
se va indexa cheia primara Nr_Proprietate (index primar)
- eventual index secundar pt. atributul Chirie, de interes
Indicatii referitoare la indexare:
o se indexeaza cheia primara
o nu se indexeaza relatii (entitati) mici
o se indexeaza cheia straina daca e frecvent utilizata
o nu se indexeaza atribute frecvent reactualizate
o nu se indexeaza atribute cu siruri lungi de caractere.
MS-Access indexeaza automat cheile primare si cheile straine din tabele.
o Interogare de tabele multiple viteza de interogare poate fi marita prin
n indexarea campurilor din ambele parti ale firului relatiei (din ambele parti ale uniunii)
n indexarea campurilor pentru care se utilizeaza criterii de interogare. (de ex in "Proprietate_de_Inchiriat" se vor indexa campurile frecvent interogate "tipul" si "zona"
o de creat numai indexuri pentru imbunatatirea performantele sistemului
n intretinerea indexurilor incarca suplimentar resursele Þ scaderea vitezei sistemului.
o Crearea indexurilor secundare se documenteaza si se motiveaza
Introducerea de redundanta controlata prin relaxarea normalizarii (denormalizare) imbunatateste performantele sistemului
Datorita denormalizarii
implementarea BD mai dificila
flexibilitatea BD scade
se pot accelera regasirile
se incetinesc reactualizarile.
Pasul 5.4.1 Considerarea datelor derivate
Valorile atributelor derivate se calculeaza din valorile altor atribute.
Stocarea unui atribut derivat in BD duce la:
costuri suplimentare de stocare si mentinere a concordantei datelor derivate cu datele operationale din care au fost derivate;
costuri de calculare a datelor derivate de fiecare data cand este necesar.
Exemplu: Entitatea Personal poate contine un nou atribut derivat (Nr_Proprietati) arata cate proprietati administreaza fiecare angajat Se deriva din entitatea Proprietate_de_Inchiriat, dupa atributul NrPer
Exemplu Tranzactia E: Enumerarea numarului proprietatii, orasului, tipului, chiriei si avansului pentru inchiriere (conform regulilor de afaceri: avansul = 2 x chiria).
o Interogare
n toate campurile cerute
n un camp calculat (derivat) pentru "avans".
o se prefera adaugarea unui camp suplimentar in tabelul de baza, "Proprietate_de_Inchiriat"
n campul "Avans"
n avansul pt. fiecare proprietate, calculat de operatorul uman la inregistrarea sau actualizarea proprietatii respective.
o Þ la executarea tranzactiei E nu mai trebuie calculat (prin rularea interogarii) avansul pentru fiecare proprietate.
Prin normalizare relatia
Filiala (Nr Fil, Strada, Zona, Orasul, CodP, Nr_Tel, Nr_Fax)
se descompune in doua relatii (tabele)
Filiala (Nr Fil, Strada, CodP, Nr_Tel, Nr_Fax)
Cod_Postal Filiala (Nr_Fil, CodP, Zona, Orasul)
Þ la introducerea unei filiale noi nu trebuie de repetat toate informatiile legate de oras.
Se opteaza totusi pentru denormalizare, acceptand redundanta
Exemplu
o Tranzactia F: a se enumera pentru fiecare proprietate
n numarul proprietatii, strada, orasul,
n impreuna cu numarul de personal si numele angajatului resp. pt. administrarea proprietatii
o Interogare pe tabele multiple
n grupare/uniune de tabele, pentru a include numele angajatului (din tabelul "Personal") in rezultatul interogarii.
Prin interogare: de fiecare data uniune intre cele 2 tabele)
In "Proprietate_de_Inchiriat" se introduce o redundanta controlata campul "Nume" (care exista si in tabelul "Personal").
Se proiecteaza si se implementeaza un program de aplicatie
orice modificare in campul "Nume" in tabelul parinte "Personal" se transmite in campul "Nume" din tabelul copil "Proprietate_de_Inchiriat".
Pasul 5.4.3 Documentarea introducerii redundantei
Orice redundanta introdusa ulterior se documenteaza si se motiveaza.
Modelul de date logic trebuie reactualizat, a i sa reflecte orice modificari aparute prin denormalizare.
Pasul 5.5 Estimarea necesarului de spatiu pe disc
Obligatorie pentru stabilirea performantelor hardware cerute pentru implementarea bazei de date.
Se determina daca va fi necesara achizitionarea de hardware mai performant.
Pasul 6.1 Proiectarea vederilor utilizatorilor
In baza modelelor de date logice locale
Vederile se creeaza prin limbajul de interogare structurata SQL (Structured Query Language).
In Access interogarile QBE (Query BY Example) inglobeaza implicit comenzile SQL
Vederile sunt generate pentru utilizatorii cu permisiune de acces limitata la date.
Exemplu Supervizorul organizatiei are o vedere partiala asupra tabelului Personal, fara informatii referitoare la salarii.
Managerul vede relatia de baza, completa:
Personal (Nr_Personal, Prenume, Nume, Adresa, Functia, Sex, Salariu, Nr_Filiala)
o Cheie primara: Nr_Personal
o Cheie straina: Nr_Filiala
In urma interogarii selective cu QBE (SQL se genereaza vederea:
Personal_VedereSupervizor (Nr_Personal, Prenume, Nume, Adresa, Telefon, Sex, Functia, Nr_Filiala)
o Cheie primara: Nr_Personal
o Cheie straina: Nr_Filiala
o MS-Access reactualizeaza tabelul sau tabelele de baza care au fost interogate.
Supervizorul
o are dreptul la reactualizari asupra tabelului de baza Personal,
n cu exceptia campului "Salariu",
o utilizand interogarea selectiva QBE, respectiv formular corespunzator interogarii.
Pasul 6.2 Proiectarea regulilor de acces
Utilizatorii
nu au acces la relatiile de baza
au acces numai la vederile create pentru ei.
DBA atribuie fiecarui utilizator un identificator de autorizatie care are asociata o parola.
Fiecare instructiune SQL executata de SGBD este efectuata in numele unui anumit utilizator.
Identificatorul de autorizatie determina
la ce obiecte din BD se poate referi utilizatorul
ce operatii poate efectua asupra acestor obiecte.
Fiecare obiect creat in SQL are un proprietar identificat prin identificatorul de autorizatie. Proprietarul este singurul care cunoaste existenta obiectului respectiv si deci poate efectua operatii asupra lui.
Privilegii actiunile pe care un utilizator are voie sa le efectueze asupra unei relatii de baza sau vederi.
Instructiuni pentru acordarea privilegiilor:
o SELECT: privilegiul de a regasi date dintr-o relatie
o Cand utilizatorul creeaza o relatie folosind instructiunea Create Table din limbajul SQL, utilizatorul devine automat proprietarul noii relatii cu privilegii complete
o GRANT: se acorda privilegii altor utilizatori asupra relatiei nou create
o REVOKE: revoca privilegii
o
CREATE
VIEW: utilizatorul care creeaza vederea devine automat proprietarul acesteia,
dar nu neaparat cu privilegii complete, (ca
Exemplu: utilizatorul manager trebuie:
o sa regaseasca randuri din relatia Personal
o sa insereze
o sa reactualizeze
o sa stearga date din aceasta
o sa transmita privilegii utilizatorilor.
Se utilizeaza urmatoarea instructiune SQL:
GRANT ALL PRIVILEGES
ON personal
TO manager WITH GRANT OPTION.
Exemplu: Utilizatorului cu identificatorul de autorizatie ADMIN i se acorda privilegiul SELECT pentru relatia Personal, cu urmatoarea instructiune SQL:
GRANT SELECT
ON personal
TO admin
MS-Access ofera doua metode traditionale de securizare a BD:
o stabilirea unei parole a BD (pentru deschiderea BD)
o securitatea la nivel de utilizator (se limiteaza segmentele din BD care pot fi citite sau reactualizate la nivel de utilizator)..
Stabilirea unei parole
O data deschisa BD cu parola, toate obiectele (tabele, interogari, formulare etc.) sunt puse la dispozitia utilizatorului.
Securitatea la nivel de utilizator
similara metodelor din majoritatea sistemelor (softurilor) de retele.
Utilizatorului i se cere
sa se identifice
sa scrie o parola cand porneste MS-Access.
In fisierul de informatii al grupului de lucru (Workgroup Administrator) utilizatorii sunt identificati ca membri ai unui grup.
Access defineste automat grupurile
Admin
Users
pot fi definite si alte grupuri.
Caseta de dialog pentru definirea grupurilor si conturilor de utilizator
Control mai fin
o prin definirea de noi grupuri (conturi de grup)
o Grupurilor noi li se acorda anumite permisiuni
o Se adauga utilizatorii care fac parte din acest grup
o Utilizatorii grupului:
n au implicit toate drepturile grupului din care fac parte
n Drepturile lor pot fi modificate individual, astfel incat sa fie mai multe sau mai putine fata de drepturile grupului
Pasul 6. Documentarea proiectului masurilor de securitate si vederilor utilizatorilor
Proiectarea vederilor individuale si mecanismele de securitate trebuie complet documentate.
Daca proiectul fizic afecteaza modelele de date logice individuale, atunci si aceste diagrame trebuie reactualizate.
o Monitorizarea sistemului operational
o imbunatatirea performantelor acestuia
Pentru:
o corectarea deciziilor inadecvate de proiectare
o reflectarea cerintele in schimbare.
Reglarea din mers a bazei de date de catre DBA prezinta avantaje:
se evita necesitatea procurarii de hardware aditional
se poate micsora configuratia hard
timpul de raspuns scade
transferul devie mai eficient
creste productivitatea intreprinderii, moralul angajatilor si satisfactia clientilor.
Orice modificare de reglare poate in acelasi timp imbunatati o aplicatie si strica alta. Este de dorit sa se verifice/testeze intai modificarea pe o baza de date de incercare, sau atunci cand sistemul nu este complet utilizat (in afara orelor de lucru).
Dupa cateva luni de utilizare a BD apar doua noi cerinte:
(1) Capacitatea de a pastra fotografii ale proprietatilor de inchiriat, impreuna cu comentariile care descriu principalele caracteristici ale acesteia.
Capacitatea de a publica un raport care sa disponibilizeze in Internet proprietatile de inchiriat disponibile.
Cerinta in MS-Access: fotografii ale proprietatilor plus comentarii
o se introduc campuri cu tip de date (data type): OLE (Object Linking and Embedded = legarea si inglobarea de obiecte).
o Acestea permit stocarea de date cum ar fi
n documente MS-Word
n Documente MS-Excel
n Figuri
n Sunete
n alte tipuri de date binare create in alte programe.
o Obiectele OLE pot fi legate de sau inglobate intr-un camp dintr-un tabel sau formular in Access si pot fi afisate intr-un formular, raport sau pagina de acces la date (pagina Internet)
o In tabelul Proprietate_de_Inchiriat
n un camp "Vedere" cu tip de date OLE
n un camp numit "Comentarii", cu tip de date Memo, capabil de a cuprinde un text mai lung.
o Formular cu cele doua campuri noi, bazat pe tabelul Proprietate_de_Inchiriat (figura urmatoare)
o Calea catre imaginea/imaginile stocate pe hard disk se specifica in design view al formularului (sau raportului sau paginii de acces) creat dupa tabel.
Cerinta (2): publicarea in Internet a unui raport cu proprietatile de inchiriat disponibile (in MS-Access):
crearea unui raport cu campurile de vizualizat in Internet
Pagina de acces la date in baza acestui raport
Cerinte: legatura
|
|
|
|
|
|
|
|
|
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 3874
Importanta: 
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved
