Curs baze-de-date

3,047 views
2,749 views

Published on

Published in: Education
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,047
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
93
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Curs baze-de-date

  1. 1. InformaŃii Curs- Baze de date –Anul III-Informatică Disciplină obligatorie; Anul III, Sem. 5, ore săptămânal, învăŃământ de zi: 2 curs, 2 laborator, total ore semestru 56; 6 credite; examen. I. CONłINUTUL TEMATIC AL DISCIPLINEI • • • • • • • • Notiuni introductive în domeniul bazelor de date (entitate, relatie, atribut, limbaje pentru baze de date, componenete şi arhitectura unui sistem de gestiune a bazelor de date (SGBD), evoluŃia SGBD-urilor) Proiectarea bazelor de date simple Proiectarea bazelor de date relaŃionale (modelarea Entitate-RelaŃie, diagrama E/R, modelul relational, regulile lui Codd, caracteristicile modelului relational, normalizare, forme normale, dependenŃe funcŃionale) Proiectarea bazelor de date relaŃionale orientate obiect (modelarea orientata pe obiect cu UML, proiectarea diagramelor de clasă şi de obiecte cu programul Visio) Proiectarea bazelor de date relaŃionale cu programul ACCESS (tabele, formulare, interogări, rapoarte, comenzi macro, securitate) Limbaje de manipulare a datelor relaŃionale Concepte de baza ale limbajului SQL Limbajul SQL ACCESS - SQL SINTEZE ASUPRA PROGRAMEI ANALITICE Cursul este structurat în 3 părŃi, astfel: • • • Partea I. Concepte ale bazelor de date relaŃionale Partea a_II-a. Access Partea a_III_a. SQL Partea I. Concepte ale bazelor de date relaŃionale În această parte se face o prezentare generală a conceptelor bazelor de date relaŃionale. O bază de date este o colecŃie de informaŃii interrelaŃionate gestionate ca o singură unitate. A ceastă definiŃie este foarte largă, deoarece există mari diferenŃe între concepŃiile diferiŃilor producători care pun la dispoziŃie sisteme de baze de date. De exemplu, Oracle Corporation defineşte o bază de date ca fiind o colecŃie de fişiere fizice gestionate de o singură instanŃă (copie) a produsului software pentru baze de date, în timp ce Microsoft defineşte o bază de date SQL Server ca fiind o colecŃie de date şi alte obiecte. Un obiect al bazei de date este o structură de date denumită, stocată în bază de date, cum ar fi un tabel, o vizualizare sau un index. Există mari diferenŃe între implementările furnizorilor de baze de date. În majoritatea sistemelor de baze de date, datele sunt stocate în mai multe fişiere fizice,
  2. 2. dar în Microsoft Access toate obiectele bazei de date, împreună cu datele care aparŃin unei baze de date sunt stocate într-un singur fişier fizic.(Un fişier este o colecŃie de înregistrări înrudite stocate ca o singură untiate de sistemul de operare al calculatorului.) Totuşi, unul dintre principalele avantaje ale bazelor de date relaŃionale este faptul că detaliile de implementare fizică sunt separate de definiŃiile logice ale obiectelor bazei de date, astfel încât majoritatea utilizatorilor bazei de date nu au nevoie să ştie unde (şi cum) sunt stocate obiectele bazei de date în sistemul de fişiere al calculatorului. De fapt , pe măsură ce veŃi învăŃa limbajul SQL , veŃi vedea că nu este nevoie să specificaŃi numele unui fişier fizic într-o instrucŃiune SQL decât atunci când definiŃi sau modificaŃi chiar obiectele bazei de date. Sistem de gestionare a bazei de date (DBMS) Un sistem de gestionare a bazei de date (DBMS database management system) este un produs software furnizat de producătorul bazei de date. Produse software precum Microsoft Access, Microsoft SQL Server, Oracle Database,Sybase, DB2,INGRES, MySQL şi Postgre SQL fac parte din categoria DBMS sau, mai corect, DBMS relaŃionale (RDBMS). RDBMS-urile sunt cunoscute şi sub numele de SGBD-uri. Ambele prescurtări vor fi folosite în acestă expunere. Bazele de date relaŃionale sunt definite şi prezentate în secŃiunea următoare a acestu capitol. Sistemul DBMS pune la dispoziŃie toate serviciile de bază necesare pentru organizarea şi întreŃinerea bazei de date, inclusiv următoarele: Transferarea datelor în şi din fişierele fizice de date, în funcŃie de cerinŃe. Gestionarea accesului concurenŃial la date al mai multor utilizatori , inclusiv prevenirea conflictelor care ar putea fi cauzate de actualizările simultane. Gestionarea tranzacŃiilor, astfel încât toate modificările făcute asupra bazei de date printr-o tranzacŃie să fie executate ca o singură unitate.Cu alte cuvinte, dacă tranzacŃia reuşeşte, toate modificările efectuate de tranzacŃie sunt înregistrate în bază de date; dacă tranzacŃia eşuează, nici una dintre modificări nu este înregistrată în bază de date.Totuşi, reŃineŃi ca unele sisteme RDBMS nu asigură suportul pentru tranzacŃii. Acceptă un limbaj de interogare, care reprezintă sistemul de comenzi folosit de utilizator pentru a obŃine date din bază de date.SQL este principalul limbaj folosit pentru sistemele DBMS relaŃionale şi subiectul principal al aceste cărŃi. FuncŃii pentru salvarea bazei de date şi pentru refacerea bazei de date în urma erorilor. Mecanisme de securitate pentru împiedicarea accesului neautorizat la date şi modificarea acestora. Bază de date relaŃională O bază de date relaŃională este o bază de date care respectă modelul relaŃional, dezvoltat de Dr.E.F.Codd. Modelul relaŃional prezintă datele sub forma familiarelor tabele bidimensionale, similar cu o foaie de calcul tabelar. Spre deosebire de o foaie de calcul tabelar, nu este obligatoriu ca datele să fie stocate într-o formă tabelară, iar modelul permite şi combinarea tabelelor (crearea uniunilor (joining), în terminologia relaŃională) pentru formarea vizualizarilor, care sunt prezentate tot ca tabele bidimensionale. Flexibilitatea extraordinară a bazelor de date relaŃionale este dată de
  3. 3. posibilitatea de a folosi tabelele independent sau în combinaŃii, fără nici o ierarhie sau secvenŃa predefinita în care trebuie să se facă accesul la date. Un model este o reprezentare a obiectelor şi evenimentelor lumii reale şi a asocierilor dintre ele. De fapt, el reprezintă o abstracŃie asupra aspectelor semnificative ale unei „întreprinderi“, ale unui sistem real, ignorând proprietăŃile accidentale. Modelul este cel pe care utilizatorii trebuie să-l cunoască; implementarea unui model este cea pe care utilizatorii nu este necesar să o cunoască. DiferenŃa dintre model şi implementare este, de fapt, un caz special şi important al deosebirii uzuale dintre logic şi fizic. Modelele se impun prin sintaxa şi prin semantica lor şi, din acest punct de vedere, există trei tipuri fundamentale de modele: • modele care descriu aspectele statice ale procesului modelat; • modele care descriu aspectele dinamice ale procesului modelat; • modele care descriu aspectele funcŃionale ale procesului modelat. Un model de date reprezintă o colecŃie integrată de concepte necesare descrierii: • datelor, • relaŃiilor dintre ele, • constrângerilor existente asupra datelor sistemului real analizat. Modelarea unei baze de date permite trecerea de la percepŃia unor fapte din lumea reală la reprezentarea lor prin date. Modelul de date trebuie să reflecte fidel fenomene ale lumii reale, să urmărească evoluŃia acestei lumi şi comunicarea dintre fenomenele lumii reale. Modelul trebuie să asigure conceptele de bază care permit proiectantului bazei de date şi utilizatorilor să comunice, fără ambiguităŃi, cunoştinŃele lor privind funcŃionarea şi organizarea modelului real analizat. Prin urmare, un model de date trebuie să reprezinte datele şi să le facă înŃelese. În esenŃă, modelul de date are trei componente: • mulŃime de reguli conform cărora sunt construite bazele de date (partea structurală); • mulŃime de operaŃii permise asupra datelor, care sunt utilizate pentru reactualizarea sau regăsirea datelor (partea de prelucrare); • mulŃime de reguli de integritate, care asigură coerenŃa datelor. • Abordarea generală a problemei modelării semantice a datelor se face în patru etape. • Se identifică o mulŃime de concepte semantice care sunt utile în descrierea lumii reale. Se presupune că lumea reală (modelul real analizat) este formată din entităŃi care au anumite proprietăŃi, că fiecare entitate are o identitate, că există legături, corelaŃii între entităŃi. Conceptul de corelaŃie, ca şi cel de entitate, este util, în mod intuitiv, la descrierea modelului. • Se caută o mulŃime de obiecte formale, simbolice care sunt utilizate pentru reprezentarea conceptelor semantice anterioare. • Se dau reguli de integritate formale şi generale (constrângeri) care să reflecte restricŃiile la care este supus modelul. • Se defineşte o mulŃime de operatori formali prin care pot fi prelucrate şi analizate obiectele formale.
  4. 4. Modelul entitate-relaŃie Una dintre cele mai cunoscute abordări ale modelării semantice (cu siguranŃă una dintre cele mai utilizate) este cea bazată pe modelul entitate-relaŃie (E/R). Acesta a fost introdus de către P.P. Chen în 1976 şi rafinat de atunci în diverse moduri de către acesta şi de mulŃi alŃi cercetători, ca un model de date conceptual, pentru a uşura proiectarea bazelor de date. Pentru reprezentarea grafică a modelului sunt utilizate diagramele E/R, care sunt modele neformalizate pentru reprezentarea unui model, unui sistem din lumea reală. Diagramele E/R constituie o tehnică de reprezentare a structurii logice a bazei de date, într-o manieră grafică. Aceste diagrame oferă un mijloc simplu şi inteligibil de comunicare a caracteristicilor importante ale designului unei anumite baze de date. Diagrama E/R este un model de date conceptual de nivel înalt, independent de platforma hardware utilizată şi de tipul SGBD-ului. Modelul este constituit din concepte care descriu structura bazei de date şi tranzacŃiile de regăsire sau reactualzare asociate. Popularitatea modelului E/R ca modalitate de abordare a proiectării bazelor de date poate fi atribuită în principal tehnicii de realizare a diagramelor E/R. Această tehnică, ca şi modelul E/R însuşi, a evoluat de-a lungul timpului datorită noilor problematici care au apărut în proiectarea bazelor de date. Baza de date poate fi definită ca o mulŃime de date ce modelează un sistem real. Acest sistem este format din obiecte legate între ele. Modelul E/R împarte elementele unui sistem real în două categorii: entităŃi şi relaŃii (legături, asocieri) între aceste entităŃi. EntităŃiile şi legăturile au anumite caracteristici, numite atribute. Nu trebuie confundat conceptul de relaŃie, în sensul de asociere, care intervine în definirea diagramei E/R cu conceptul de relaŃie care este specific modelului relaŃional. Entitate Entitatea este un obiect sau un concept, care este semnificativ pentru modelul real analizat. O entitate poate fi dependentă (slabă), existenŃa sa depinzând de altă entitate sau independentă (tare), caz în care ea nu depinde de existenŃa altei entităŃi. Entitatea poate fi persoană, loc, concept, activitate etc. Prin urmare, ea poate fi un obiect cu existenŃă fizică, reală sau poate fi un obiect cu existenŃă conceptuală, abstractă. Cheia primară este un identificator unic în cadrul entităŃii, făcând distincŃie între valori diferite ale acesteia. Cheia primară: • • • • • trebuie să fie unică şi cunoscută la orice moment; trebuie să fie controlată de administratorul bazei; trebuie să nu conŃină informaŃii descriptive, să fie simplă, fără ambiguităŃi; să fie stabilă; să fie familiară utilizatorului. ObservaŃii • EntităŃile devin tabele în modelele relaŃionale. • În general, entităŃile se scriu cu litere mari.
  5. 5. EntităŃile sunt substantive, dar nu orice substantiv este o entitate. Trebuie ignorate substantivele nerelevante. • Pentru fiecare entitate este obligatoriu să se dea o descriere detaliată. Nu pot exista, în aceeaşi diagramă, două entităŃi cu acelaşi nume, sau o aceeaşi entitate cu nume diferite. • DEPARTAMENT lucreaza_in SARCINA conduce apartine_la SALARIAT atasat_la PROIECT RelaŃie RelaŃia (asocierea) este o comunicare între două sau mai multe entităŃi. O valoare a unei relaŃii este o comunicare între valorile entităŃilor pe care le leagă. RelaŃia exprimă un raport care există între aceste entităŃi. Gradul unei relaŃii este dat de numărul de entităŃi participante într-o relaŃie (de exemplu, relaŃie binară, ternară, cvadruplă, n-ară). ExistenŃa unei relaŃii este subordonată existenŃei entităŃilor pe care le leagă. Între două entităŃi pot exista mai multe relaŃii. O relaŃie în care aceeaşi entitate participă mai mult decât o dată în diferite roluri defineşte o relaŃie recursivă. Uneori, aceste relaŃii sunt numite unare. ObservaŃii: • În modelul relaŃional, relaŃiile devin tabele speciale sau coloane speciale care referă chei primare. • RelaŃiile sunt verbe, dar nu orice verb este o relaŃie. • Pentru fiecare relaŃie este important să se dea o descriere detaliată. • În aceeaşi diagramă pot exista relaŃii diferite cu acelaşi nume. În acest caz, ele sunt diferenŃiate de către entităŃile care sunt asociate prin relaŃia respectivă. • Pentru fiecare relaŃie trebuie stabilită cardinalitatea (maximă şi minimă) relaŃiei, adică numărul de tupluri ce aparŃin relaŃiei. poate (cardinalitate maximă) trebuie (cardinalitate minima) EXEMPLE: CâŃi salariaŃi pot lucra într-un departament? MulŃi! În câte departamente poate lucra un salariat? In cel mult unul!
  6. 6. RelaŃia SALARIAT_lucreaza_in_DEPARTAMENT are cardinalitatea maximă many-one (n:1). Exemplu: CâŃi salariaŃi trebuie să conducă un departament? Cel puŃin unul! Câte departamente trebuie să conducă un salariat? Zero! RelaŃia SALARIAT_conduce_DEPARTAMENT are cardinalitatea minimă one-zero (1:0). Asupra entităŃilor participante într-o relaŃie pot fi impuse constrângeri care trebuie să reflecte restricŃiile care există în lumea reală asupra relaŃiilor. O clasă de constrângeri, numite constrângeri de cardinalitate, este definită de numărul de înregistrări posibile pentru fiecare entitate participantă (raport de cardinalitate). Cel mai întâlnit tip de relaŃii este cel binar, iar în acest caz rapoartele de cardinalitate sunt, în general, one-to-one (1:1), one-to-many (1:n) sau many-to-many (m:n). Atribut Atributul este o proprietate descriptivă a unei entităŃi sau a unei relaŃii. De exemplu, numele , genul unei film, sunt atribute al entităŃii FILM. Atributele pot fi simple (pretul de închiriere a unui film), compuse (de exemplu, numele filmului), cu valori multiple (de exemplu, limbile în care e tradus un film), derivate (de exemplu, vârsta unei persoane se obŃine din data naşterii). ObservaŃii • Trebuie făcută distincŃia între atribut care uzual devine coloană în modelele relaŃionale şi valoarea acestuia, care devine valoare în coloane. • Atributele sunt substantive, dar nu orice substantiv este atribut. • Fiecărui atribut trebuie să i se dea o descriere completă în specificaŃiile modelului (exemple, contraexemple, caracteristici). • Pentru fiecare atribut trebuie specificat numele, tipul fizic (integer, float, char etc.), valori posibile, valori implicite, reguli de validare, constrângeri, tipuri compuse. Diagrama entitate- relaŃie Pentru proiectarea diagramei entitate-relaŃie au fost stabilite anumite reguli • entităŃile sunt reprezentate prin dreptunghiuri; • relaŃiile dintre entităŃi sunt reprezentate prin arce neorientate; • atributele care reprezintă chei primare trebuie subliniate sau marcate prin simbolul „#“ sau (pk), plasat la sfârşitul numelui acestor atribute; • cardinalitatea minimă este indicată în paranteze, iar cardinalitatea maximă se scrie fără paranteze; • nu este necesar să fie specificate, în cadrul diagramei, toate atributele.
  7. 7. SALARIAT cod_salariat nume prenume sex salariu atasat_la M(0) M(0) PROIECT nr_proiect descriere buget_alocat data_initiala functia 1 1 M(0) apartine_la conduce 1(0) lucreaza_in 11 DEPARTAMENT cod_departament nume nr_cladire cod_salariat M SARCINA nr_proiect nr_sarcina data_inceperii stare Diagrama Entitate/relaŃie Cazuri speciale de entităŃi, relaŃii, atribute şi modul lor de reprezentare în cadrul diagramei entitate-relaŃie. 1. Entitate dependentă – nu poate exista în mod independent (SARCINA depinde de PROIECT). Cheia primară a unei entităŃi dependente include cheia primară a sursei (nr_proiect) şi cel puŃin o descriere a entităŃii (nr_sarcina). Entitatea dependentă se desenează prin dreptunghiuri cu linii mai subŃiri. 2. Moştenirea atributelor. Subentitate (subclasă) – submulŃime a unei alte entităŃi, numită superentitate (superclasă) (SALARIAT < –– > PROGRAMATOR). Subentitatea se desenează prin dreptunghiuri incluse în superentitate. Există o relaŃie între o subentitate şi o superentitate, numită ISA, care are cardinalitatea maximă 1:1 şi minimă 1:0. Cheile primare, atributele şi relaŃiile unei superentităŃi sunt valabile pentru orice subentitate. AfirmaŃia reciprocă este falsă. 3. Într-o diagramă E/R se pot defini relaŃii recursive. 4. RelaŃie sau atribut? Dacă un atribut al unei entităŃi reprezintă cheia primară a unei alte entităŃi, atunci el referă o relaŃie (cod_departament în tabelul SALARIAT). 5. Entitate sau relaŃie? Se cercetează cheia primară. Dacă aceasta combină cheile primare a două entităŃi, atunci este vorba de o relaŃie. (cheia primară a relaŃiei
  8. 8. asociat_la combină cod_salariat cu nr_proiect, prin SALARIAT_asociat la_PROIECT va defini o relaŃie şi nu o entitate). urmare, Probleme 1.Să se creeze modelul E/R pentru gestiunea activităŃilor de împrumut dintr-o bibliotecă S-a presupus (restrictiv) că într-o zi un cititor nu poate împrumuta, de mai multe ori, aceeaşi carte. EntităŃile şi relaŃiile care intervin în acest model sunt următoarele: 1. CARTE (entitate independentă) – orice carte care se găseşte în inventarul bibliotecii. Cheia primară este atributul codel. 2. CITITOR (entitate independentă) – orice cititor care poate împrumuta cărŃi. Cheia primară este atributul codec. 3. DOMENIU (entitate independenta) – domeniul căruia îi aparŃine o carte. Cheia primară este atributul coded. 4. IMPRUMUTA – relaŃie având cardinalitatea m:m care leagă entităŃile CITITOR şi CARTE. 5. APARTINE – relaŃie care leagă atributele CARTE şi DOMENIU. RelaŃia are cardinalitatea maximă m:1, iar cardinalitatea minimă 1:1. CITITOR CARTE M(1) codel# titlu autor pret nrex M(0) imprumuta M(0) 1 apartine codec# nume dep DOMENIU coded# intdom 2.EvidenŃa şcolilor de şoferi din Romania. CompletaŃi relaŃiile (lucreaza_la, conduce, sustine, asista, instruieste) dintre entităŃi şi specificaŃi cardinalitatea! SCOALA cod_scoala# CLIENT cod_client#
  9. 9. INSTRUCTOR cod_instructor# EXAMEN cod_examen# EXAMINATOR cod_examinator# MASINA cod_masina# 3. Campionatele de fotbal ale diferitelor Ńări ECHIPA Cod_echipa# Nume Oras M(1) sustine M(1) SPONSOR M(1) Cod_sponsor# Nume 2 joaca M(1) MECI Tara# Nr_etapa# Cod_meci# M(1) apartine_de 1 ETAPA Tara Nr_etapa M(1) atasata_la 1 CAMPIONAT Tara# Modelul relaŃional Modelul relaŃional a fost conceput şi dezvoltat de E.F. Codd. El este un model formal de organizare conceptuală a datelor, destinat reprezentării legăturilor dintre
  10. 10. date, bazat pe teoria matematică a relaŃiilor. Modelul relaŃional este alcătuit numai din relaŃii şi prin urmare, orice interogare asupra bazei de date este tot o relaŃie. Cercetarea în domeniu 3 mari proiecte (System R, INGRES, PRTV) CalităŃi: • este simplu; • riguros din punct de vedere matematic; • nu este orientat spre sistemul de calcul. ModalităŃi pentru definirea unui SGBD relaŃional: • prezentarea datelor în tabele supuse anumitor operaŃii de tip proiecŃie, selecŃie, reuniune, compunere, intersecŃie etc. • un sistem de baze de date ce suportă un limbaj de tip SQL – Structured Query Language; • un sistem de baze de date care respectă principiile modelului relaŃional introdus de E.F. Codd. Caracteristicile unui model relaŃional: • structura relaŃională a datelor; • operatorii modelului relaŃional; • regulile de integritate care guvernează folosirea cheilor în model. Aceste trei elemente corespund celor trei componente ale ingineriei software: informaŃie, proces, integritate. Structura datelor Definirea noŃiunilor de domeniu, relaŃie, schemă relaŃională, valoare null şi tabel vizualizare (view). Conceptele utilizate pentru a descrie formal, uzual sau fizic elementele de bază ale organizării datelor sunt date în următorul tabel: Formal relaŃie tuplu atribut domeniu Uzual tablou linie coloană tip de dată Fizic fişier înregistrare câmp tip de dată Reguli de integritate sunt aserŃiuni pe care datele conŃinute în baza de date trebuie să le satisfacă. Există trei tipuri de constrângeri structurale (de cheie, de referinŃă, de entitate) ce constituie mulŃimea minimală de reguli de integritate pe care trebuie să le respecte un SGBD relaŃional. RestricŃiile de integritate minimale sunt definite în raport cu noŃiunea de cheie a unei relaŃii. O mulŃime minimală de atribute ale căror valori identifică unic un tuplu într-o relaŃie reprezintă o cheie pentru relaŃia respectivă.
  11. 11. Fiecare relaŃie are cel puŃin o cheie. Una dintre cheile candidat va fi aleasă pentru a identifica efectiv tupluri şi ea va primi numele de cheie primară. Cheia primară nu poate fi reactualizată. Atributele care reprezintă cheia primară sunt fie subliniate, fie urmate de semnul #. O cheie identifică linii şi este diferită de un index care localizează liniile. O cheie secundară este folosită ca index pentru a accesa tupluri. Un grup de atribute din cadrul unei relaŃii care conŃine o cheie a relaŃiei poartă numele de supercheie. Fie schemele relaŃionale R1(P1, S1) şi R2(S1, S2), unde P1 este cheie primară pentru R1, S1 este cheie secundară pentru R1, iar S1 este cheie primară pentru R2. În acest caz, vom spune că S1 este cheie externă (cheie străină) pentru R1. Modelul relaŃional respectă trei reguli de integritate structurală. Regula 1 – unicitatea cheii. Cheia primară trebuie să fie unică şi minimală. Regula 2 – integritatea entităŃii. Atributele cheii primare trebuie să fie diferite de valoarea null. Regula 3 – integritatea referirii. O cheie externă trebuie să fie ori null în întregime, ori să corespundă unei valori a cheii primare asociate. Transformarea entităŃilor EntităŃile independente devin tabele independente. Cheia primară nu conŃine chei externe. EntităŃile dependente devin tabele dependente. Cheia primară a entităŃilor dependente conŃine cheia primară a entităŃii de care depinde (cheie externă) plus unul sau mai multe atribute adiŃionale. SubentităŃile devin subtabele. Cheia externă se referă la supertabel, iar cheia primară este această cheie externă (cheia primară a subentităŃii PROGRAMATOR este cod_salariat care este o cheie externă). Transformarea relaŃiilor RelaŃiile 1:1 şi 1:n devin chei externe. RelaŃia conduce devine coloană în tabelul DEPARTAMENT, iar relaŃia lucreaza_in devine coloană în tabelul SALARIAT. Simbolul „ד indică plasamentul cheii externe, iar simbolul „ד exprimă faptul că această cheie externă este conŃinută în cheia primară. RelaŃia 1:1 plasează cheia externă în tabelul cu mai puŃine linii. RelaŃia m:n devine un tabel special, numit tabel asociativ, care are două chei externe pentru cele două tabele asociate. Cheia primară este compunerea acestor două chei externe plus eventuale coloane adiŃionale. Tabelul se desenează punctat. RelaŃiile de tip trei devin tabele asociative. Cheia primară este compunerea a trei chei externe plus eventuale coloane adiŃionale. Transformarea atributelor Un atribut singular devine o coloană.
  12. 12. Atributele multiple devin tabele dependendente ce conŃin cheia primară a entităŃii şi atributul multiplu. Cheia primară este o cheie externă, plus una sau mai multe coloane adiŃionale. EntităŃile devin tabele, iar atributele lor devin coloane în aceste tabele. Ce devin atributele relaŃiilor? Pentru relaŃii 1:1 şi 1:n, atributele relaŃiilor vor aparŃine tabelului care conŃine cheia externă, iar pentru relaŃii m:n şi de tipul trei, atributele vor fi plasate în tabelele asociative. SALARIAT cod_salariat# salariu nume sex job_cod ATASAT_LA cod_salariat# nr_proiect# functie AGENT_TERITORIAL zona comision PROIECT nr_proiect# descriere buget_alocat PROGRAMATOR limbaj nivel apartine_la conduce lucreaza_in DEPARTAMENT cod_departament# nume nr_cladire cod_salariat SARCINA nr_proiect# nr_sarcina# data_inceperii stare casatorit TELFON cod_salariat# nr_telefon# Schemele relaŃionale corespunzătoare acestei diagrame conceptuale sunt următoarele: – SALARIAT(cod_salariat#, forma_plata, nr_depart); nume, prenume, sex, job_cod, – DEPARTAMENT(cod_departament#, nume, numar_cladire, cod_sal); – ATASAT_LA(cod_salariat#, nr_proiect#, functia); – PROIECT(nr_proiect#, descriere, buget_alocat); – SARCINA(nr_proiect#, nr_sarcina, data_inceperii, stare); cod_sot,
  13. 13. – AGENT_TERITORIAL(cod_salariat#, zona, comision); – PROGRAMATOR(cod_salariat#, limbaj, nivel); – TELEFON(cod_salariat#, nr_telefon#). Regulile lui Codd • Caracteristici ale modelului relaŃional: nu există tupluri identice; • ordinea liniilor şi a coloanelor este arbitrară; • articolele unui domeniu sunt omogene; • fiecare coloană defineşte un domeniu distinct şi nu se poate repeta în cadrul aceleiaşi relaŃii; • toate valorile unui domeniu corespunzătoare tuturor cazurilor nu mai pot fi descompuse în alte valori (sunt atomice). Avantajele modelului relaŃional: • fundamentare matematică riguroasă; • independenŃă fizică a datelor; • posibilitatea filtrărilor; • existenŃa unor structuri de date simple; • realizarea unei redundanŃe minime; • • supleŃe în comunicarea cu utilizatorul neinformatician. Ca limite ale modelului relaŃional putem menŃiona: rămâne totuşi redundanŃă, • ocupă spaŃiu, • apar fenomene de inconsistenŃă, • nu există mecanisme pentru tratarea optimă a cererilor recursive, • nu lucrează cu obiecte complexe, • nu există mijloace perfecŃionate pentru exprimarea constrângerilor de integritate, • nu realizează gestiunea totala a datelor distribuite, • nu realizează gestiunea cunoştinŃelor. În anul 1985, E.F. Codd a publicat un set de 13 reguli în raport cu care un sistem de gestiune a bazelor de date poate fi apreciat ca relaŃional. Nici un sistem de gestiune a bazelor de date pus în vânzare pe piaŃa comercială nu respectă absolut toate regulile definite de Codd, dar acest lucru nu împiedică etichetarea acestor sisteme drept relaŃionale. Nu trebuie apreciat un SGBD ca fiind relaŃional sau nu, ci măsura în care acesta este relaŃional, deci numărul regulilor lui Codd pe care le respectă. Regula 1 – regula gestionării datelor. Un SGBD relaŃional trebuie să fie capabil să gestioneze o bază de date numai prin posibilităŃile sale relaŃionale.
  14. 14. Regula 2 – regula reprezentării informaŃiei. Într-o bază de date relaŃională, informaŃia este reprezentată la nivel logic sub forma unor tabele ce poartă numele de relaŃii. Regula 3 – regula accesului garantat la date. Fiecare valoare dintr-o bază de date relaŃională trebuie să poată fi adresată în mod logic printr-o combinaŃie formată din numele relaŃiei, valoarea cheii primare şi numele atributului. Regula 4 – regula reprezentării informaŃiei necunoscute. Un sistem relaŃional trebuie să permită utilizatorului definirea unui tip de date numit „null“ pentru reprezentarea unei informaŃii necunoscute la momentul respectiv. Regula 5 – regula dicŃionarelor de date. Asupra descrierii bazelor de date (informaŃii relative la relaŃii, vizualizări, indecşi etc.) trebuie să se poată aplica aceleaşi operaŃii ca şi asupra datelor din baza de date. Regula 6 – regula limbajului de interogare. Trebuie să existe cel puŃin un limbaj pentru prelucrarea bazei de date. Regula 7 – regula de actualizare a vizualizării. Un SGBD trebuie să poată determina dacă o vizualizare poate fi actualizată şi să stocheze rezultatul interogării într-un dicŃionar de tipul unui catalog de sistem. Regula 8 – regula limbajului de nivel înalt. Regulile de prelucrare asupra unei relaŃii luată ca întreg sunt valabile atât pentru operaŃiile de regăsire a datelor, cât şi asupra operaŃiilor de inserare, actualizare şi ştergere a datelor. Regula 9 – regula independenŃei fizice a datelor: Programele de aplicaŃie şi activităŃile utilizatorilor nu depind de modul de depunere a datelor sau de modul de acces la date. Regula 10 – regula independenŃei logice a datelor. Programele de aplicaŃie trebuie să fie transparente la modificările de orice tip efectuate asupra datelor. Regula 11 – regula independenŃei datelor din punct de vedere al integrităŃii. Regulile de integritate trebuie să fie definite într-un sublimbaj relaŃional, nu în programul de aplicaŃie. Regula 12 – regula independenŃei datelor din punct de vedere al distribuirii. Distribuirea datelor pe mai multe calculatoare dintr-o reŃea de comunicaŃii de date, nu trebuie să afecteze programele de aplicaŃie. Regula 13 – regula versiunii procedurale a unui SGBD. Orice componentă procedurală a unui SGBD trebuie să respecte aceleaşi restricŃii de integritate ca şi componenta relaŃională. Deoarece regulile lui Codd sunt prea severe pentru a fi respectate de un SGBD operaŃional, s-au formulat criterii minimale de definire a unui sistem de gestiune relaŃional. Un SGBD este minimal relaŃional dacă: • toate datele din cadrul bazei sunt reprezentate prin valori în tabele; • nu există pointeri observabili de către utilizator; sistemul suportă operatorii relaŃionali de proiecŃie, selecŃie şi compunere naturală, fără limitări impuse din considerente interne. Un SGBD este complet relaŃional dacă este minimal relaŃional şi satisface în plus condiŃiile: •
  15. 15. • • sistemul suportă restricŃiile de integritate de bază (unicitatea cheii primare, constrângerile referenŃiale, integritatea entităŃii). sistemul suportă toate operaŃiile de bază ale algebrei relaŃionale. Exemplu pentru însuşirea formelor normale şi a instrucŃiunilor SQL Componentelor fundamentale ale bazelor de date relaŃionale sunt utilizate pentru a construi obiectele bazelor de dae pe care le vom folosi . InstrucŃiunile SQL folosite pentru crearea acestor componente ale bazei de date sunt prezentate în parte. Tabele Unitatea primară de stocare a datelor într-o bază de date relaŃională este tabelul, care este o structură bidimensională compusă din rânduri şi coloane. Fiecare tabel reprezintă o entitate, ceea ce înseamnă o persoană, un loc sau un lucru care trebuie să fie reprezentat în baza de date, cum ar fi un client, un cont bancar sau o tranzacŃie bancară. Fiecare rând al tabelului reprezintă o apariŃie a entităŃii. Figura 1-1 reprezintă listingul parŃial al unui tabel numit FILM(filme). Tabelul FILM este parte a unei baze de date pentru un magazin de produse video, folosit ca exemplu în toată aceast curs. Tabelul FILM conŃine date care descriu filmele disponibile în magazinul de produse video. Fiecare rând din tabel reprezintă un film, iar fiecare coloană reprezintă o caracteristică a filmului respectiv, cum ar fi titlul filmului sau categoria MPAA(Motion Picture Associationof America care a fost fondată în 1972 în America ca asociaŃie a producătorilor de film pe lângă industria cinematografică) FILM_I D FILM_C OD_GE N 1 2 3 Drama ActAv Comedie MPA A_CO DRAT ING R R PG-13 4 5 6 ActAv ActAv ActAv PG-13 R PG-13 7 8 9 Drama ActAv ActAv PG-13 R PG-13 10 11 12 13 14 15 16 17 18 Drama Romantic Comedie Comedie Drama Drama Comedie Romantic Drama R PG-13 PG-13 PG-13 R R PG-13 PG-13 R FILM_NUME PRET_INCHIR _VHS PRET_INCHIR _DVD AN_P RODU S Mystic River The Last Samurai Something`s Gotta Give The Italian Job Kill Bill: Vol 1 Pirates of the Caraibbean: The Curse of the Black Pearl Big Fish Man on Fire Master and Commander: The Far Side of the World Lost in translation Two Weeks Notice 50 First Dates Matchstick Men Could Mountain Road to Perdition The School of Rock 13 Going on 30 Monster 58.97 15.95 14.95 19.96 19.96 29.99 2003 2003 2003 11.95 24.99 29.99 19.99 29.99 29.99 2003 2003 2003 14.95 50.99 12.98 19.94 29.98 39.99 2003 2004 2003 49.99 6.93 9.95 6.93 24.99 9.99 11.69 14.94 24.99 14.98 14.97 19.94 19.97 29.99 14.99 29.99 28.95 29.99 2003 2002 2004 2003 2003 2003 2004 2003
  16. 16. 19 ActAv Strain 20 PG-13 R The Day Tomorrow Das Boot After 12.98 29.98 2004 17.99 19.94 1981 Figura 1-1 Listingul tabelului FILM Se poate observa asemănarea dintre tabelele bazelor de date relaŃionale şi foile de calcul tabelar. Totuşi, bazele de date relaŃionale oferă o flexibilitate mult mai mare în organizarea şi afişarea informaŃiilor. RelaŃii RelaŃiile reprezintă asocierile dintre tabelele bazelor de date relaŃionale. Deşi fiecare tabel relaŃional poate exista independent, esenŃa bazelor de date este tocmai stocarea informaŃiilor între care există legături. De exemplu, pe lângă filmele propriuzise, puteŃi stoca informaŃii despre categoriile folosite de magazin pentru organizarea inventarelor de filme. În acelaşi timp, puteŃi stoca şi informaŃii despre copiile fiecărui film, inclusiv data la care a fost primită copia şi formatul acesteia, cum ar fi DVD sau VHS. Prin folosirea realaŃiilor, puteŃi asocia tabelele înrudite, într-un mod formal, uşor de folosit astfel încât puteŃi să combinaŃi date din tabele multiple în aceeaşi interogare a bazei de date, dar păstrând flexibilitatea de a include numai informaŃiile care vă interesează.Posibilitatea de a selecta din baza de date numai informaŃiile care vă interesează vă permite să ajustaŃi informaŃiile din bază de date în funcŃie de cerinŃele specifice ale persoanelor sau aplicaŃiilor care au acces la baza de date. Figura 1-2 prezinta patru tabele din baza de date a magazinului de produse video si relaŃiile dintre acestea, într-un format cunoscut sub numele de diagrama de relatii a entitatilor (ERD – Entity Relationship Diagram). Fiecare dreptunghi din diagrama reprezintă un tabel relaŃional, cu numele tabelului scris deasupra liniei orizontale si coloanele tabelului enumerate pe verticala , in portiunea principala a dreptunghiului. RelaŃiile sunt implementate folosind coloane corespondente din cele două tabele participante. În diagrama ERD coloana sau coloanele subliniate din fiecare tabel. UN tabel poate avea o singură cheie primară. Totuşi , o cheie primară poate fi compusă din mai multe coloane, dacă aceasta este calea de formare a unei chei unice. Dacă o cheie primară este folosită într-un alt tabel pentru stabilirea unei relaŃii, poartă numele de chieie externă. În figură 1-2, observaŃi coloanele cheie externă folosite în tabelul FILM pentru crearea relaŃiilor cu tabelele FILM_GENRE şi MPAA_RATING şi marcate cu identificatoarele „<fk1>” şi „<fk2”> în dreapta numelui coloanei cheie externă. Şi coloana COD_LIMBA este marcată drept cheie externă , dar tabelul LANGUAGE şi relaŃia acestuia cu tabelul FILM au fost omise din figura de mai sus. Cheile primare şi cheile externe sunt blocuri de construcŃie fundamentale ale modelului relaŃional, deoarece stabilesc relaŃii şi permit crearea legăturilor între date, atunci când este necesar. Trebuie să înŃelegeŃi acest concept pentru a putea înŃelege cum funcŃionează bazele de date relaŃionale.
  17. 17. FILM FILM_ID <pk> MPAA_RATING MPAA_COD_RATING <pk> MPAA_DESCRIERE_RATING FILM_COD_GEN <fk1> MPAA_COD_RATING <fk2> FILM_NUME RETAIL_PRET_VHS RETAIL_PRET_DVD AN_PRODUS FILM_GEN FILM_COD_GEN <pk> FILM_DESCRIERE_GEN FILM_COPII FILM_ID <pk, fk>> NUMAR_COPIE <pk> DATA_CUMPARARE DATA_VANZARE FORMAT_MEDIA Figura 1-2 Diagrama ERD a bazei de date (prezentare parŃială) RestricŃii O restricŃie este o regulă specificată pentru un obiect al bazei de date (de obicei un table sau o coloană), având rolul de a limita într-un mod oarecare domeniul de valori permise pentru obiectul respectiv al bazei de date.După ce sunt specificate, restricŃiile sunt impuse automat de sistemul DBMS şi nu pot fi ocolite decât dacă o persoană autorizata le dezactivează sau le şterge(le elimină).Fiecare restricŃie primeşte un nume unic, astfel încât să poată fi referită în mesajele de eroare şi în comenzile folosite ulterior în bază de date.Este recomandabil ca proiectanŃii bazei de date să denumească restricŃiile, deoarece numele generate automat de bază de date nu sunt foare descriptive. Totuşi , nu am denumit restricŃiile din baza de date folosită ca exemplu în această carte, deoarece, din păcate, nu toate produsele RDBMS disponibile în prezent acceptă restricŃiile denumite. Există mai multe tipuri de restricŃii pentru baze de date: RestricŃia NOT NULL Poate fi plasată pe o coloană pentru a împiedica folosirea valorilor nule.O valoare nulă (null) este o modalitate specială prin care sistemul RDBMS tratează valoarea unei coloane pentru a indica faptul că valoarea coloanei respective nu este cunoscută. O valoare nulă nu este acelaşi lucru un un spaŃiu liber, un şir vid sau valoarea zero şi este o valoare specială care nu este egală cu nimic altceva. RestricŃia cheie primară (primary key) Definită pe coloana (coloanele) cheie primară ale unui tabel pentru a garanta că valorile cheie primară sunt întotdeauna unice în întreg tabelul.Atunci când cheia primară este definită pe mai multe coloane, combinaŃia valorilor acelor coloane trebuie să fie unică în tabel - o coloană care reprezintă doar o parte a valorii cheii primare poate conŃine valori duplicate în tabel. RestricŃiile cheie primară sunt aproape inttotdeauna implementate de RDBMS prin folosirea unui index.Indexul este un tip special de obiect al unei baze dedate care permite efectuarea căutărilor rapide în valorile coloanei.Atunci când în tabele sunt înserate rânduri noi, sistemul RDBMS verifică automat indexul pentru a se asigura că cheia primară a noului rând nu este deja folosită în tabel şi , dacă se întâmplă acest lucru , respinge cererea de inserare. Căutarea în indexuri se face mult mai repede decât căutarea în tabel;ca urmare, indexarea cheii primare este esenŃială
  18. 18. pentru orice tabel, indiferent de dimensiunea acestuia, astfel încât căutarea cheilor duplicate la fiecare inserare să nu ducă la o reducere semnificativă a performanŃelor. O caracteristică suplimentară a cheilor primare este faptul că nu pot fi definite decât pe coloane pentru care a fost definită şi restricŃia NOT NULL. RestricŃia de unicitate (unique) Definită pe o coloană sau un set de coloane care trebuie să conŃină valori unice ale tabelului. Ca şi în cazul cheilor primare, sistemul RDBMS foloseşte aproape întotdeauna un index ca modalitate de impunere eficientă a restricŃiei.Totuşi, spre deosebire de cheile primare, un tabel poate avea definite mai multe restricŃii de unicitate, iar coloanele care participă la o restricŃie de unicitate pot conŃine ( în cele mai multe sisteme RDBMS ) şi valori nule. RestricŃia referenŃială (numită uneori restricŃie de integritate referenŃială) O restricŃie care impune o relaŃie între două tabele dintr-o bază de date relaŃională. Prin „impunere” se înŃelege că sistemul RDBMS se asigură întotdeauna, în mod automat, că fiecărei valori a cheii externe îi corespunde o valoarea a cheii primare în tabelul părinte.În tabelul FILM, sistemul RDBMS nu-mi permite să inserez o înregistrare cu valoarea „M” în coloana MPAA_COD_RATING, deoarece „M” nu este o valoarea MPAA_COD_RATING validă şi , ca urmare, nu apare ca valoare a cheii primare din tabelul MPAA_RATING. În sens invers, sistemul RDBMS nu-mi permite să şterg din tabelul MPAA_RATING rândul cu cheia primară „PG-13” , deoarece valoarea respectivă este folosită ca valoare a cheii externe pentru cel puŃin una din înregistrările din tabelul FILM. Pe scurt , restricŃia referenŃială garantează că relaŃia dintre cele două tabele şi valorile corespondente ale cheii primare şi cheii externe îşi păstrează logica în orice moment. RestricŃia CHECK Foloseşte o instrucŃiune logică simplă (scrisă în SQL) pentru a valida valoarea unei coloane.Rezultatul instrucŃiunii trebuie să fie o valoare logică de adevărat (true) sau fals (false), astfel încât un rezultat adevărat să permită înserarea în tabel a valorii coloanei, iar un rezultat fals să ducă la rejectarea valorii coloanei , cu mesajul de eroare corespunzător. Index Un index reprezintă o cale rapidă de localizare şi sortare a Inregistrarilor dintro tabelă prin gruparea tuturor înregistrărilor pentru un anumit atribur sau grup de atribute. Indexarea este utilizată în două scopuri principale: accelerarea căutărilor în baya de date asigurarea unicităŃii înregistrărilor De exemplu, dacă ne intereayă anumite nume dintr-o tabelă StudenŃi, putem crea un index pentru coloana NumeSt, pentru a regăsi mai repede studenŃii cu un anmit nume de familie..
  19. 19. Putem indexa şi mai multe coloane, de exemplu creem un index cu numele NUME , pentru coloanele NumeSt şi PrenumeSt. Deşi accelerează procesul de regăsire a datelor , indecşii îngreunează actualizarea lor.Dupa fiecare operaŃie de actualiyare)inserare, modificare, ştergere, trebuie verificaŃi şi actualiyaŃi indecşii.Folosirea lor trebuie bine întemeiată altfel măresc timpul de răspuns al sistemuluişi ocupă spaŃiul suplimentar pe disc . In Partea a-II-aAccess , se prezintă modul de creare a indecşilor şi în Partea III, la DDL, create index. ObservaŃie: Cheia primară a unei tabele este indexaŃa automat. Nu pot fi indexate coloane de tipul :Memo, Hyperlinksau OLE Când o coloană face parte din cheia primară a unei tabele, proprietatea Indexed are valoarea Yes(No Duplicates), şi proprietatea Required primeşte valoarea Yes, deoarece cheia primară nu poate conŃine valoarea null. Vizualizări O vizualizare (view) este o interogare stocată în baza de date şi pune la dispoziŃia utilizatorului un subset personalizat al datelor din unul sau mai multe tabele ale bazei de date. Cu alte cuvinte, o vizualizare este un tabel virtual, deoarece arată ca un tabel şi în cele mai multe privinŃe se comportă că un tabel, dar nu stochează date ( nu este stocată decât interogarea SQL care defineşte vizualizarea). Vizualizările au mai multe funcŃii utile: Maschează radurile pe care utilizatorul nu este nevoie să le vadă (sau nu-i este permis să le vadă). Maschează coloanele pe care utilizatorul nu are nevoie să le vadă (sau nu-i este permis să le vadă). Maschează operaŃiile complexe efectuate în baza de date, cum ar fi uniunile de tabele (respectiv combinarea coloanelor din tabele multiple într-o singură interogare a bazei de date). ÎmbunătăŃeşte performanŃele interogărilor (în unele sisteme RDBMS, precum Microsoft SQL Server).
  20. 20. Proiectate bazele de date relaŃionale Această secŃiune prezintă, foarte pe scurt, procesul general de proiectare a bazelor de date. Atunci când aŃi văzut pentru prima dată figură 1-2 , mai devreme în acestă lecŃie probabil v-aŃi întrebat de ce coloanele au fost plasate în tabele multiple şi de ce o anumită coloană a fost inclusă într-un anumit tabel şi nu în altul. Scopul acestei secŃiuni este de a vă ajuta să răspundeŃi la întrebările de mai sus şi de a vă oferi un punct de plecare, dacă decideŃi să proiectaŃi propriile baze de date pe măsură ce învăŃaŃi limbajul SQL. Totuşi proiectarea bazelor de date este un domeniu mult mai larg. În 1972, Dr.E.F.Codd, părintele bazelor de date relaŃionale, a pus la punct un set de reguli care trebuie respectate (organizate în trei „forme normale”) şi un poroces numit normalizare, care este o tehinca pentru producerea unui set de relaŃii (termenul folosit de Dr. Codd pentru tabele) cu proprietăŃile dorite. Necesitatea normalizării Normalizarea este procesul reversibil de transformare a unei relaŃii, în relaŃii de structură mai simplă. Procesul este reversibil în sensul că nici o informaŃie nu este pierdută în timpul transformării. O relaŃie este într-o formă normală particulară dacă ea satisface o mulŃime specificată de constrângeri. Procesul normalizării se realizează plecând de la o relaŃie universală ce conŃine toate atributele sistemului de modelat, plus o mulŃime de anomalii. Orice formă normală se obŃine aplicând o schemă de descompunere. Există două tipuri de descompuneri. Descompuneri ce conservă dependenŃele. Această descompunere presupune desfacerea relaŃiei R în proiecŃiile R1, R2, ..., Rk, astfel încât dependenŃele lui R sunt echivalente (au închideri pseudo-tranzitive identice) cu reuniunea dependenŃelor lui R1, R2, ..., Rk. Descompuneri fără pierderi de informaŃie. Această descompunere presupune desfacerea relaŃiei R într-o mulŃime de proiecŃii R1, R2, ..., Rj, astfel încât pentru orice realizare a lui R este adevărată relaŃia: O descompunere fără pierdere de informaŃie, utilizată în procesul normalizării, este dată de regula Casey-Delobel: Fie R(A) o schemă relaŃională şi fie α, β, γ o partiŃie a lui A. Presupunem că α determină funcŃional pe β. Atunci: α∪β α∪γ mulŃimea atributelor care intervin în dependenŃele funcŃionale; reprezintă reuniunea determinantului cu restul atributelor lui A. Tabelul de mai jos prezintă tabelul FILM fără normalizare, aşa cum ar arăta dacă toate informaŃiile despre filme ar fi colectate într-un singur tabel.Acest exemplu va fi folosit pentru ilustrarea procesului de normalizare. În general, numele coloanelor din tabelele relaŃionale folosesc liniuŃe de subliniere pentru separarea cuvintelor. În discuŃia despre normalizare am eliminat aceste liniuŃe din figuri, pentru a face textul mai uşor de citit.
  21. 21. Anomaliile care apar în lucrul cu baza de date se produc datorită dependenŃelor care există între datele din cadrul relaŃiilor bazei de date. DependenŃele sunt plasate greşit în tabele! Există trei probleme care pot apărea în tabelele fără normalizare şi toate trei există în tabelul de mai jos. Scopul procesului de normalizare este de a elimina aceste probleme (anomalii) din proiectul bazei de date. FILM _ID G E N_ C O D Dr am a GE N_ DE SC RIE RE Dra ma LAN G_ COD E MPAA _COD _RATI NG MPAA_RATIN G_DESC FILM_NUM E AN _P RO DU S DATA_CUM PARARE en, fr R Sub 17 ani necesita prezenta parintilor sau a unui adult Mystic River 200 3 2 Ac lA d en, fr, es R Sub 17 ani necesita prezenta parintilor sau a unui adult The Last Samurai 2 Ac tA v en, fr, es R Sub 17 ani necesita prezenta parintilor sau a unui adult 3 Co me die Co me die Ac tA v Act Av si ave ntur a Acti une si ave ntur a Co med ie Co med ie Acti une si ave ntur a en PG-13 Parintii avertizati en PG-13 en, fr PG-13 1 3 4 MEDIA _FORM AT PRETINCHI RIERE 01/01/2005 DVD 19.96 200 3 01/10/2005 DVD 19.96 The Last Samurai 200 3 01/10/2005 VHS 15.95 sunt Something's Gotta Give 200 3 01/10/2005 DVD 29.99 Parintii avertizati sunt Something's Gotta Give 200 3 2/15/2005 DVD 29.99 Parintii avertizati sunt The Job 200 3 2/15/2005 DVD 19.99 Italian DAT A_VA NZA RE 1/30/2 005 Figura 1-3 Tabelul FILM fară normalizare Anomalia de inserare Anomalia de inserare se referă la o situaŃie în care nu puteŃi insera date în baza de date din cauza unei dependenŃe artificiale dintre coloanele unui tabel. Să presupunem că vreti să adăugaŃi în baza de date a magazinului un nou gen de film care urmează a fi folosit pentru clasificarea filmelor.Tabelul de mai sus nu permite acest lucru decât dacă aveŃi un film care să fie plasat în categoria respectivasi pe care va trebui să-l adăugaŃi în tabelul FILM în acelaşi timp.Ar fi mult mai bine dacă aŃi putea adauga noile genuri înainte de primirea filmelor în magazin.
  22. 22. Anomalia de ştergere Anomalia de ştergere este inversul anomaliei de inserare. Se referă la situaŃia în care ştergerea unor date duce la pierderea neintenŃionată a altor date. De exemplu dacă primul film din tabel este singurul rând din tabelul FILM pentru care coloana GEN_COD are valoarea „Drama” , şi este şters, se pierde informaŃia că a existat vreodată un gen numit „Drama” Anomalia de actualizare Anomalia de actualizare se referă la o situaŃie în care actualizarea unei singure valori necesită actualizarea mai multor rânduri. De exemplu , dacă în tabelul prezentat mai sus trebuie să modificaŃi descrierea codului MPAA_COD_RATING „R”, trebuie să modificaŃi şi toate rândurile din tabel pentru filmele cu codul respectiv. Probleme similare apar şi pentru coloana GEN_DESCRIERERIPTION. Chiar şi coloana PRET_INCHIR are această problemă, deoarece toate copiile aceluiaşi film (cu aceeaşi valoare FILM_ID ) pe acelaşi mediu (DVD sau VHS) ar trebui să aibă acelaşi preŃ. Un alt pericol legat de această anomalie este faptul că stocarea unor date redundante poate aduce la posibilitatea de actualiza numai o parte a copiilor respectivelor date, ceea ce ar avea ca rezultat apariŃia inconsecvenŃelor în baza de date. Aplicarea procesului de normalizare De obicei, normalizarea începe de la mijloacele de redare a datelor care sunt (sau vor fi) prezentate utilizatorilor, cum ar fi pagini web, ecrane ale aplicaŃiilor, rapoarte şi aşa mai departe. Colectiv, acestea sunt numite vizualizări de utilizator (user views). Poate părea ciudat la prima vedere, dar este ceva obişnuit ca proiectarea unui sistem de prelucrare a datelor să înceapă de la rezultatele pe care le va vedea utilizatorul, parcurgând apoi drumul înapoi către mijloacele folosite pentru obŃinerea rezultatelor dorite. În timpul proiectării bazei de date, procesul de normalizare este aplicat fiecărei vizualizări , iar rezultatul este un set de relaŃii normalizate care pot fi apoi direct implementate ca tabele ale bazei de date relaŃionale. Stăpânirea procesului de normalizare cere timp şi exerciŃiu, în specia deoarece impune prouectantului să se gândească într-un mod conceptual la datele şi relaŃiile pe care intenŃionează să le folosească. În timpul normalizării , consideraŃi ca fiecare vizualizare este o relaŃie. Cu alte cuvinte, conceptualizaŃi fiecare vizualizare ca şi cum ar fi deja un tabel bidimensional . De asemenea , este nevoie de timp pentru a va obişnui cu terminologia folosită în procesul de normalizare. În timpul acestui proces, majoritatea proiectanŃilor evită folosirea unor termeni fizici, precum tabel, coloană şi cheie primară. Deşi relaŃia pe cale de a fi normalizată reprezintă o propunere de tabel , încă nu există ca tabel fizic, aşa că termenul nu este foarte exact. Procesul de normalizare este aplicat sistematic fiecărei vizualizări. Cel puŃin la început este mai uşor să reprezentaŃi fiecare vizualizare ca un tabel bidimensional, conŃinând date repetitive, aşa cum am făcut în figura 1-3. Pe măsură ce parcurgeŃi procesul de normalizare, veŃi rescrie relaŃiile existente şi veŃi crea altele. Rescrierea vizualizărilor în relaŃii (tabele) cu date reprezentative este un proces obositor şi
  23. 23. consumator de timp. Trebuie să fiŃi foarte atent ca exemplele de date folosite pentru luarea deciziilor în procesul de normalizare să fie cu adevărat reprezentative pentru tipurile de valori care vor apărea în datele reale. Aşa cum probabil vă aşteptaŃi, exemple prost alese duc deseori la proiectarea eronată a bazei de date. Scopul procesului de normalizare este eliminarea anomaliilor de inserare, actualizare si ştergere. Procesul determină crearea unui număr mai mare de relaŃii decât aŃi avea într-un model fără normalizare. RelaŃiile suplimentare sunt necesare pentru eliminarea anomaliilor, dar împărŃirea datelor în mai multe relaŃii face ca extragerea datelor stocate să fie puŃin mai dificilă. Alegerea unui identificator unic Primul pas al procesului de normalizare constă în alegerea unui identificator unic (unique identifier), care este un atribut (o coloană) sau un set de atribute care identifică în mod unic fiecare rând de date dintr-o relaŃie. Identificatorul unic va deveni ulterior cheia primară a tabelului creat din relaŃia normalizată. Pentru normalizare, este obligatoriu ca fiecare relaŃie să aibă un identificator unic. In multe cazuri, puteŃi găsi un atribut care identifică în mod unic datele din fiecare rând al relaŃiei pe care vreŃi să o normalizaŃi. Atunci când nu puteŃi găsi un singur atribut care să poată fi folosit ca identificator unic, este posibil să găsiŃi mai multe atribute care pot fi concatenate (combinate) pentru a forma un identificator unic. Atunci când identificatoarele unice sunt formate din atribute multiple, fiecare atribut rămâne pe propria lui coloană - nu faceŃi decât să definiŃi un identificator unic format din mai multe coloane, în foarte puŃine cazuri, într-o relaŃie nu există un set rezonabil de atribute care să poată fi folosit ca identificator unic. Atunci când se întâmplă acest lucru, trebuie să inventaŃi un identificator unic, deseori cu valori atribuite secvenŃial sau aleatoriu pe măsură ce noile rânduri de date sunt adăugate în tabelul bazei de date. Această tehnică este sursa unor identificatoare unice, precum numărul de asigurări sociale folosit în Statele Unite, numerele de identificare ale angajaŃilor sau numerele de înmatriculare ale maşinilor. RelaŃia FILM din figura 1-3 ne pune o problemă în privinŃa găsirii unui identificator unic. La prima vedere, ar părea că atributul FILM_ID este cel mai potrivit în acest scop. Totuşi, observaŃi că valorile FILM_ID „2" şi „3" apar de câte două ori, aşa că, fără nici un dubiu, această valoare nu este unică. Problema este că valoarea FILM_ID identifică în mod unic fiecare titlu, dar magazinul urmăreşte separat fiecare copie a filmelor pe care le are în stoc Cauza este faptul că magazinul se ocupă şi de închirierea filmelor şi vrea să se asigure că fiecare client returnează exact copia pe care a închiriat-o. După inspectarea datelor folosite ca exemplu şi o scurtă discuŃie cu proprietarul magazinului, ajungeŃi la concluzia că în relaŃia FILM nu există nici o combinaŃie de atribute care să identifice în mod unic fiecare copie a unui film, aşa că inventaŃi un atribut numit NR_ COPIE şi-1 adăugaŃi în relaŃie. Ori de câte ori inventaŃi un identificator unic (sau o parte a unui identificator) este foarte important ca toŃi să înŃeleagă valorile pe care le va lua acest identificator. In acest caz, proprietarul magazinului decide ca valorile NR_ COPIE să reînceapă de la 1 pentru fiecare valoare FILM_ID, ceea ce înseamnă că valorile NR_ COPIE sunt unice numai în combinaŃie cu valorile FILM_ID. RelaŃia rezultată este prezentată în figura 1 –4 Prima formă normală: eliminarea datelor repetate
  24. 24. O relaŃie este în prima formă normală atunci când nu conŃine atribute cu valori multiple (atribute mulŃi valoare), adică atribute care au mai multe valori pentru acelaşi rând de date. Într-o relaŃie, orice intersecŃie a unui rând cu o coloană trebuie să conŃină cel mult o valoare pentru ca relaŃia să fie în prima formă normală. în figura 1-4, atributul pentru limbă (COD_LIMBA) conŃine mai multe valori pentru unele dintre filme, aşa că-l puteŃi considera un atribut cu valori multiple. Atributele de acest tip sunt mai greu de întreŃinut, deoarece valorile din listă trebuie să fie mai întâi separate, astfel încât valorile individuale să poată fi modificate fară a le afecta pe celelalte. Uneori, un atribut multivaloare este deghizat sub forma atributelor multiple. De exemplu, figura 14 ar putea fi modificată astfel încât să conŃină atribute (coloane) separate pentru cel mult trei limbi corespunzătoare fiecărui film, numite Language 1, Language 2 şi Language 3. Totuşi, si acestea ar fi considerate atribute multivaloare, dar într-o forma specială, numită grup repetitiv, care nu este acceptat în prima formă normală. Din punct de vedere logic, un grup repetitiv nu este diferit de un atribut multivaloare. De fapt, grupurile repetitive prezintă deseori chiar mai multe probleme decât atributele multivaloare, deoarece trebuie să adăugaŃi o nouă coloană în tabel ori de câte ori vreŃi să adăugaŃi mai multe valori decât a prevăzut iniŃial proiectantul bazei de date (cum ar fi o a patra limbă pentru un film). Bazele de date relaŃionale cer ca toate rândurile dintr-un tabel să aibă acelaşi număr de coloane, dar un tabel poate conŃine orice număr de rânduri FIL M_I D GEN_ COD GEN_ DESC RIERE CO D_L IMB A MPA A_C OD_ RAT ING MPAA_RATING _DESC FILM_NU ME A N_ PR O D US DATA_ CUMPA RARE Dram a Drama en, fr R Mystic River 20 03 en, fr, es R The Last Samurai en, fr, es R en PG13 Sub 17 ani necesita prezenta parintilor sau a unui adult Sub 17 ani necesita prezenta parintilor sau a unui adult Sub 17 ani necesita prezenta parintilor sau a unui adult Parintii sunt avertizati 1 N R _ C O PI E 1 2 1 AclA d 2 2 ActA v 3 1 Come die Actiune si aventur a Actiune si aventur a Comedi e 3 2 Come die Comedi e en PG13 Parintii avertizati sunt 4 1 ActA v Actiune si aventur a en, fr PG13 Parintii avertizati sunt DA TA_ VA NZ AR E MEDI A FORM AT PRET _INC HIR 01/01/20 05 DVD 19.96 20 03 01/10/20 05 DVD 19.96 The Last Samurai 20 03 01/10/20 05 VHS 15.95 Something' s Gotta Give Something' s Gotta Give The Italian Job 20 03 01/10/20 05 DVD 29.99 20 03 2/15/200 5 DVD 29.99 20 03 2/15/200 5 DVD 19.99 1/30 /200 5 Figura 1-4 RelaŃia FILM . Ca urmare, procesul de normalizare pentru obŃinerea primei forme normale cere să transformaŃi coloanele repetate şi valorile repetate din coloane în rânduri repetate într-un tabel separat . Pentru transformarea relaŃiilor ne-normalizate în prima formă normală, trebuie să mutaŃi atributele multivaloare şi grupurile repetitive în noi relaŃii. Deoarece grupurile repetitive reprezintă un set de atribute care se repetă împreună, toate
  25. 25. atributele dintr-un grup repetitiv ar trebui mutate în aceeaşi relaŃie. Pe de altă parte, un atribut multivaloare (un atribut individual care are valori multiple) ar trebui să fie mutat într-o nouă relaŃie proprie, nu să fie combinat cu alte atribute multivaloare în noua relaŃie. Procedura de mutare a unui atribut multivaloare sau a unui grup repetitiv într-o nouă relaŃie constă în următoarele etape: 1. CreaŃi o nouă relaŃie, cu un nume sugestiv. Deseori, este bine să includeŃi numele relaŃiei originale, parŃial sau în întregime, în numele noii relaŃii. 2. CopiaŃi identificatorul unic din prima relaŃie în noua relaŃie. Datele depind de acest identificator în relaŃia originală, aşa că trebuie să depindă de aceeaşi cheie şi în noua relaŃie. Identificatorul copiat va deveni cheie externă în noua relaŃie. 3. MutaŃi grupul repetitiv sau atributul multivaloare în noua relaŃie. (Am folosit aici verbul a muta, deoarece aceste atribute sunt şterse din relaŃia originală.) 4. FormaŃi un identificator unic în noua relaŃie, adăugând atribute la identificatorul unic copiat din relaŃia originală. Ca întotdeauna, asiguraŃi-vă că identificatorul unic nou format conŃine numai numărul minim de atribute necesar pentru a-1 face unic. Dacă mutaŃi un atribut multivaloare, care, în esenŃă, este un grup repetitiv cu un singur atribut, este adăugat atributul respectiv pentru formarea identificatorului unic. Poate părea ciudat la prima vedere, dar identificatorul unic copiat din relaŃia originală nu este doar o cheie externă, ci, de obicei, şi o parte a identificatorului unic (cheia primară) a noii relaŃii. Acest lucru este absolut normal. De asemenea, este perfect acceptabil să avem o relaŃie în care toate atributele fac parte din identificatorul unic (adică nu există atribute care să nu facă parte din cheie). 5. OpŃional, puteŃi să înlocuiŃi cheia primară cu un singur atribut surogat pentru cheie. Dacă faceŃi acest lucru, trebuie să păstraŃi şi atributele care compun cheia primară naturală, formată la paşii 2 şi 4. Figura 1-5 prezintă rezultatul aducerii relaŃiei din figura 1-4 la prima formă normală. ObservaŃi următoarele:
  26. 26. FIL M_I D NR _C OPI E GEN _CO D GEN_D ESCRIE RE MPA A_CO D_RA TING MPAA_RATING_ DESC FILM_NUME 1 1 Dram a Drama R Sub 17 ani necesita prezenta parintilor sau a unui adult Mystic River 2 1 AclA d Actiune si aventura R Sub 17 ani necesita prezenta parintilor sau a unui adult The Samurai Last 2 2 ActA v Actiune si aventura R Sub 17 ani necesita prezenta parintilor sau a unui adult The Samurai Last 3 1 Come die Comedie PG-13 Parintii avertizati sunt Something's Gotta Give 3 2 Come die Comedie PG-13 Parintii avertizati sunt Something's Gotta Give 4 1 ActA v Actiune si aventura PG-13 Parintii avertizati sunt The Italian Job A N _ P R O D U S 2 0 0 3 2 0 0 3 2 0 0 3 2 0 0 3 2 0 0 3 2 0 0 3 DATA _CUM PARA RE MEDIA FORMAT PRET _INC HIR 01/01/ 2005 DVD 19.96 01/10/ 2005 DVD 19.96 01/10/ 2005 VHS 15.95 DVD 29.99 2/15/2 005 DVD 29.99 2/15/2 005 DVD 19.99 01/10/ 2005 DAT A_VA NZAR E 1/30/2 005 • Am folosit o mică scurtătură în cazul identificatorului unic în noua relaŃie FILM Language. Limba în care este disponibil un film se aplică filmului, în general, nu copiilor individuale. ObservaŃi în figura 1-4 că lista de limbi disponibile nu se schimbă între rândurile duplicate ale aceluiaşi film. Ca urmare, partea NR_ COPIE a identificatorului unic din relaŃia FILM nu a fost copiată în noua relaŃie FILM Language. Dacă aş fi făcut acest lucru, aş fi creat în noua relaŃie o problemă specifică celei de-a doua forme normale, pe care ar fi trebuit să o rezolv în următoarea etapă a procesului de normalizare. VeŃi descoperi că, deseori, proiectanŃii experimentaŃi de baze de date sintetizează cele trei forme normale şi rescriu relaŃiile originale direct în a treia formă normală. Exersând, veŃi putea şi dumneavoastră să faceŃi acelaşi lucru. FILM_ID 1 1 2 2 2 3 4 4 COD_LIMBA en fr en fr es en en fr Figura 1-5 SoluŃia primei forme normale • Atributul FILM_ID a fost copiat din relaŃia originală (FILM) în noua relaŃie (FILM Language). • Atributul multivaloare COD_LIMBA a fost mutat din relaŃia FILM în relaŃia FILM Language, cu numele Language Code. (Numele abreviate ale atributelor din
  27. 27. figura 1-4 au fost folosite doar pentru ilustrare - este recomandabil să prescurtaŃi numele numai dacă este absolut necesar.) • Identificatorul unic din relaŃia FILM Language este format prin combinarea atributelor FILM_ID şi Language Code, adică din toate atributele relaŃiei. • Nici FILM, nici FILM Language din figura 1-5 nu conŃin grupuri repetitive sau atribute multivaloare, aşa că ambele relaŃii sunt în prima formă normală. A doua formă normală: eliminarea dependenŃelor parŃiale Înainte de a explora a doua formă normală, trebuie definit conceptul de dependenŃă funcŃională. Pentru această definiŃie, voi folosi două atribute arbitrare, inteligent denumite „A" şi „B". Atributul B este dependent funcŃional de atributul A dacă în nici un moment nu există mai mult de o valoare a atributului B asociată cu o valoare dată a atributului A. In primul rând, a spune că atributul B este funcŃional dependent de atributul A înseamnă şi că atributul A determină atributul B sau că A este un determinant (identificator unic) pentru atributul B. În al doilea rând, să ne mai uităm o dată la relaŃiile din figura 1-5. În relaŃia FILM, puteŃi să vă daŃi seama cu uşurinŃă că atributul FILM_NUME este dependent funcŃional de atributul FILM_ID, deoarece, în orice moment, poate exista o singură valoare FILM_NUME pentru o valoare FILM_ID dată. Chiar faptul că valoarea FILM_ID defineşte în mod unic valoarea FILM_NUME în relaŃie înseamnă că FILM_NUME este dependent funcŃional de FILM_ID. Se spune că o relaŃie este în a doua formă normală dacă îndeplineşte următoarele criterii: • RelaŃia este în prima formă normală. • Toate atributele non-cheie sunt dependente funcŃional de identificatorul unic (cheia primară), luat ca întreg. Aplicând aceste criterii relaŃiei FILM din figura 1 -5, este clar că avem câteva probleme. Identificatorul unic este o combinaŃie a atributelor FILM_ID şi NR_ COPIE. Totuşi, numai atributele DATA_CUMPARARE, DATA_VANZARE, MEDIA FORMAT şi PRET_INCHIR depind de întregul identificator. Şi este logic să fie aşa. Indiferent câte copii ale unui film avem în baza de date, toate au aceleaşi valori pentru gen, categorie MPAA, TITLU şi AN_PRODUS. Unele atribute descriu filmul în sine, în timp ce altele descriu copiile pe care le deŃine (sau le-a deŃinut) magazinul din filmul respectiv. In esenŃă, am amestecat atribute care descriu în aceeaşi relaŃie două lucruri (entităŃi) diferite (deşi înrudite) din lumea reală. A doua formă normală se aplică numai relaŃiilor care au identificatoare unice concatenate (adică formate din atribute multiple). într-o relaŃie care are un singur atribut ca identificator unic, este imposibil ca un alt atribut să depindă de o parte a identificatorului unic, deoarece acesta, fiind format dintr-un singur atribut, nu are părŃi componente. Ca urmare, orice relaŃie în prima formă normală care are cheia primară formată dintr-un singur atribut este automat în a doua formă normală. După ce descoperiŃi o încălcare a celei de-a doua forme normale, soluŃia este să se mute atributele parŃial dependente într-o nouă relaŃie, în care să depindă de întreaga cheie primară. Figura 1-6 prezintă această soluŃie. Toate atributele care depind numai de FILM_ID sunt acum într-o relaŃie (numită FILM) în care FILM_ID este identificator unic. Cele care depind de combinaŃia FILM_ID şi NR_ COPIE sunt într-o relaŃie (numită FILM Copy) în care FILM_ID şi NR_ COPIE formează
  28. 28. identificatorul unic. RelaŃia FILM Language era deja în a doua formă normală, deoarece nu are atribute non-cheie şi, ca urmare, a rămas nemodificată. FILM: FILM _ID GEN_ COD GEN_DESCRIER E MPAA_ COD_R ATING 1 Drama Drama R 2 ActAv Actiune si aventura R 3 Comed ie Comedie PG-13 4 ActAv Actiune si aventura PG-13 MPAA_DESCRIERE _RATING FILM_NUME Sub 17 ani necesita prezenta parintilor sau a unui adult Sub 17 ani necesita prezenta parintilor sau a unui adult Parintii sunt avertizati Parintii sunt avertizati AN_PRO DUS Mystic River 2003 The Last Samurai Something's Gotta Give The Italian Job 2003 2003 2003 FILM LANGUAGE: FILM_ID LANGUAGE_CODE 1 En 1 Fr 2 En 2 Fr 2 Es 3 En 4 En 4 Fr FILM COPY: FILM ID NR_ COPIE DATA_CUMPARARE 1 2 2 3 3 4 1 1 2 1 2 1 01/01/2005 01/10/2005 01/10/2005 01/10/2005 2/15/2005 2/15/2005 DATA_VAN ZARE 1/30/2005 MEDIA FORMAT PRET_INCHIR DVD DVD VHS DVD DVD DVD 19.96 19.96 15.95 29.99 29.99 19.99 Figura 1-6. SoluŃia pentru a doua formă normală A treia formă normală: eliminarea dependenŃelor tranzitive Pentru a înŃelege a treia formă normală, trebuie să se definescă conceptul de dependenŃă tranzitivă. Despre un atribut care depinde de un atribut care nu este identificator unic (cheie primară) a relaŃiei se spune că este dependent tranzitiv. În relaŃia FILM din figura 1 -6, observăm că atributul GEN_DESCRIEREription depinde de atributul GEN_COD, iar MPAA Ratifig Description depinde de MPAA_COD_RATING. Pericolul păstrării acestor descrieri în relaŃia FILM este faptul că, în final, cele două atribute ajung să depindă de înregistrarea unui film, ceea ce duce la toate cele trei anomalii de date prezentate mai devreme în acest capitol.
  29. 29. Se spune că o relaŃie este în a treia formă normală dacă îndeplineşte următoarele două criterii: RelaŃia este în a doua formă normală. Nu există dependenŃe tranzitive (cu alte cuvinte, toate atributele non-cheie depind numai de identificatorul unic). Pentru a aduce la a treia formă normală o relaŃie aflată în a doua formă normală, se mută atributele dependente tranzitiv în relaŃii în care depind numai de cheia primară. Se lasă atributul de care depind acestea în relaŃia originală, cu rolul de cheie externă.Va trebui apoi să reconstruim vizualizarea originală printr-o uniune. Ca efect secundar, toate atributele uşor de calculat sunt eliminate ca încălcări ale criteriilor celei de-a treia forme normale. De exemplu, într-o bază de date pentru vânzări, Suma Totală este obŃinută înmulŃind Cantitatea Cumpărată cu PreŃul Unitar; aşa cum se observă cu uşurinŃă, Suma Totală este dependentă de Cantitatea Cumpărată şi de PreŃul Unitar. Presupunând ci toate cele trei atribute sunt dependente de identificatorul unic al relaŃiei care le conŃine, este uşor de văzut că Suma Totală (rezultatul calculat) este, de fapt, dependentă tranzitiv te celelalte două atribute. Figura 1-7 conŃine soluŃia în a treia formă normală. S-au creat noi relaŃii pentru MPAA Rating şi FILM Gen, s-a mutat descrierile în noile relaŃii şi am lăsat atributele pentru coduri (MPAA_COD_RATING şi FILM GEN_COD) în relaŃia FILM, definite ca fiind chei externe. MulŃi proiectanŃi de baze de date numesc relaŃiile MPAA Rating şi FILM Genre „tabele de căutare" sau „tabele de coduri” deoarece sunt utilizate, în principal, pentru căutarea codurilor stocate în coloana cheie primară a relaŃiei. Totuşi aceste relaŃii au şi alte roluri, cum ar fi controlul codurilor şi furnizarea unei surse convenabile pentru lista de coduri valide, care poate fi folosită într-o listă derulantă de pe o pagină web. FILM: FILM _ID GEN_ COD MPAA_ COD_R ATING FILM_NUME PRET_ INCHIR VHS 1 Drama Mystic River 58.97 R 2 ActAv R The Samurai Comedi e PG-13 Something's Gotta Give 14.95 3 The Italian Job 11.95 4 ActAv PG-13 PRET_ INCHIR DVD 19.96 AN_PRODUS 2003 Last 15.95 19.96 2003 29.99 2003 FILM_ COPII: FILM_ID NR_ COPIE DATA_CUMPAR DATE ARE VINZARE 1 1 01/01/2005 2 1 01/10/2005 2 2 01/10/2005 3 1 01/10/2005 1/30/2005 3 2 2/15/2005 4 1 2/15/2005 19.99 2003 _ MEDIA_FORMA T DVD DVD VHS DVD DVD DVD
  30. 30. MPAA Rating : MPAA_COD_RATING MPAA_DESCRIERE_RATING PG-13 Parintii sunt avertizati R Sub 17 ani necesita prezenta parintilor sau a unui adult FILM GEN : FILM GEN_COD ActAv Comedie Drama FILM_GEN_DESCRIERE Actiune si aventura Comedie Drama Figura 1-7. SoluŃia pentru a treia formă normală O altă modificare făcută pentru a ajunge la a treia formă normală este legată de atributul PRET_INCHIR (preŃ cu amănuntul) din relaŃia Movie Copy, aşa cum se poate vedea în figura 1-6. După o discuŃie cu proprietarul magazinului, am stabilit că preŃul depinde de combinaŃia dintre Movie ID şi Media Format, toate copiile cu aceleaşi valori pentru FILM_ID şi Media Format având acelaşi preŃ. In mod clar, aceasta este o dependenŃă tranzitivă şi, ca urmare, o încălcare a celei de-a treia forme normale. SoluŃia normală pentru o asemenea problemă ar fi crearea unei relaŃii numite FILM Price, având ca identificator unic combinaŃia dintre FILM_ID şi Media Format, şi mutarea atributului PRET_INCHIR din FILM Copy în noua relaŃie. Totuşi, în timpul discuŃiei s-a aflat că urmează să se renunŃe la furnizarea filmelor în format VHS, deoarece sunt cerute de un număr foarte mic de clienŃi şi că peste câteva luni magazinul va avea numai filme pe DVD. łinând seama de această informaŃie, am decis să mut preŃul în două coloane din tabelul FILM, una cu preŃul pentru DVD şi una cu preŃul pentru VHS. Deşi se poate spune că aceasta este o încălcare a primei forme normale (şi, din punct de vedere tehnic chiar este), mi s-a părut a fi cel mai bun compromis. Proiectarea bazelor de date nu este întotdeauna o ştiinŃă exactă, aşa că de multe ori există posibilitatea unor mici ajustări, cu condiŃia ca proiectantul să ia în calcul consecinŃele potenŃiale (măsurate în termenii anomaliilor de date) ale fiecărui compromis. Forma normală Boyce-Codd (BCNF) Deşi nu ne propunem să discutăm şi alte forme normale avansate, consider necesar să le amintim. Dr. E. F. Codd a participat la definirea unei versiuni mai puternice a celei de-a treia forme normale, numită forma normală Boyce-Codd. Determinantul este un atribut sau o mulŃime de atribute neredundante, care constituie un identificator unic pentru alt atribut sau altă mulŃime de atribute ale unei relaŃii date. Intuitiv, o relaŃie R este în forma normală Boyce-Codd dacă şi numai dacă fiecare determinant este o cheie candidat. Formal, o relaŃie R este în forma normală Boyce-Codd dacă şi numai dacă pentru orice dependenŃă funcŃională totală X → A, X este o cheie (candidat) a lui R.
  31. 31. Exemplu: ADRESA(cod_parsoana#, telefon#, adresa) cod_persoana adresa telefon În dependenŃa adresa telefon se observă că determinantul nu este o cheie candidat. RelaŃia ADRESA se desface în: ADRESA_1(cod_persoana#, adresa); ADRESA_2(adresa#, telefon). RelaŃiile sunt în BCNF, se conservă datele, dar nu se conservă dependenŃele (s-a pierdut cod_persoana, telefon adresa). DiferiŃi alŃi autori şi cercetători au oferit propriile extensii, numite a patra formă normală, a cincea formă normală, forma normală cu cheie de domeniu şi altele. A patra formă normală(FN4) elimină redudanŃele datorită relaŃiilor de tip m:m. Este nevoie de ceva exerciŃiu în procesul de normalizare înainte ca aceste extensii să devină logice. In plus, a treia formă normală acoperă toate anomaliile pe care este posibil să le întâlniŃi în lucrul cu baze de date obişnuite. Prezentarea generală a bazei de date pentru un magazin video Majoritatea exemplelor din acest curs folosesc ca model o bază de date pentru un magayin virtual de produse video. InstrucŃiunile SQL pentru creare obiectelor bazei de date şi pentru popularea acestora cu date vor fi prezentate în lecŃiile următoare. În figura 1-8 se prezintă disgrama entitate relaŃie, ERD (Entity Relationship Diagram) pentru această bază de date.
  32. 32. M PAA_RATING M PAA_COD_RATING MPAA_DESCRIERE_VARSTE PK FILM_LIMBA FILM _ID COD_LIM BA PK,FK1 PK,FK2 FILM FILM _ID FILM_COD_GEN M PAA_COD_RATING FILM_NUM E RETAIL_PRET_VHS RETAIL_PRET_DVD AN_PRODUS FILM_COPII FILM _ID NUM AR_COPIE DATA_CUMPARARE DATA_VANZARE FORMAT_M EDIA PK FK1 FK2 PK,FK1 PK FILM _GEN FILM _COD_GEN FILM_DESCRIERE_GEN FILM_INCHIRIERE FILM _ID NUM AR_COPIE TRANZACTIE_ID DATA_INTOARCERE COST_INCHIRIERE COST_INTARZIERE_SAU_PIERDERE DATA_RETURNARE PK PK,FK1 PK,FK1 PK,FK2 LIM BA COD_LIM BA NUME_LIM BA CLIENT_COD_PERSOANA CLIENT_CONT_ID PERSOANA_ID PERSOANA PERSOANA_ID PERSOANA_PRENUM E PERSOANA_NUME_M IJLOCIU PERSOANA_NUME PERSOANA_ADRESA_1 PERSOANA_ADRESA_2 PERSOANA_ADRESA_ORAS PERSOANA_ADRESA_JUDET_PROV PERSOANA_ADRESA_COD_POSTAL PERSOANA_ADRESA_TARA PERSOANA_TELEFON NASTERE_DATA MOARTE_DATA PK PK,FK1 PK,FK2 CLIENT_CONT CLIENT_CONT_ID PK CLIENT_HOLD_IND DATA_INSCRIS DATA_TERMINAT CLIENT_DEPOZIT_SUM A CARD_CREDIT_LA_DOSAR_INDIC COPIL_INCHIRIERE_PERM IS_INDIC PK CLIENT_TRANZACTIE TRANZACTIE_ID CLIENT_CONT_ID ANGAJAT_PERSOANA_ID TRANZACTIE_DATA VANZARI_TAXA ANGAJAT PERSOANA_ID SUPERVISOR_PERSOANA_ID ANGAJAT_TAXA_ID ANGAJAT_JOB_CATEGORIE ANGAJAT_RATA_PE_ORA ANGAJARE_DATA INCHIDERE_DATA PK FK1 PK,FK1 Figura 1_8. Diagrama entitate relaŃie Probleme: 1. Să se normalizeze tabelul CURS_SUDENT şi PROFESOR Amintim că o tabelă este în prima formă normală(FN1) dacă valorile tuturor atributelor care o compun sunt atomice (indivizibile). În plus, nu trebuie să existe atribute sau grupuri de atribute repetitive. Această primă formă normală este considerată ca fiind o cerinŃa minimală pentru majoritatea sistemelor relaŃionale, utilitatea ei fiind evidentă. Astfel , dacă o coloană ar conŃine o listă de valori , regăsirea şi manipularea informaŃiilor stocate ar fi foarte anevoioase. Presupunem că tabela Curs_Student conŃine următoarele date:
  33. 33. CURS_SUDENT NrMatricol NumeSt 458 Predescu 521 Radu 627 Cristescu 746 Irimia 782 Tanase 982 Bunea 1204 Dragnea S1520 Popa PrenumeSt Alexandru George Lucian Diana Daciela Mihaela Liviu Marius Grupa 114 122 243 361 341 114 412 452 Cursuri-Nota engleza-7,germana-8 desen-tehnic-10,franceza-7 programare-8,engleza-10 analiza numerica-9 gernana-6,programare-10 rezistenta materialelor-8 educatie fizica-10 analiza numerica-7,engleza-9 Coloana Cursuri conŃine mult prea multa informaŃie. Să presupunem că am înlocui coloana Cursuri cu două noi coloane: CURS_SUDENT NrMatricol 458 521 627 746 782 NumeSt Predescu Radu Cristescu Irimia Tanase PrenumeSt Alexandru George Lucian Diana Daciela Grupa 114 122 243 361 341 982 1204 1520 Bunea Dragnea Popa Mihaela Liviu Marius 114 412 452 Curs1 engleza desen tehnic programare analiza numerica germana rezistenta materialelor educatie fizica analiza numerica Nota1 7 10 8 9 6 8 10 7 Curs2 germana franceza engleza Nota2 8 7 10 programare 10 engleza 9 Nici acum nu am rezolvat toate problemele. De exemplu, pentru a afla câŃi studenti s-au înscris în total la un anumit curs , va trebui să parcurgem toate cele trei coloane cu cursuri. În plus, ce se întâmplă în cazul în care un student s-a înscris la mai mult de două cursuri? Să zicem că un student nu se poate inscrie la mai mult de cinci cursuri şi deci putem introduce zece coloane pentru a stoca informaŃiile curs-nota. .Evident , aceasta ar presupune o mare risipă de spaŃiu , de vreme ce ar exista şi unii studenti care au ales doar două cursuri. Pentru a aduce tabela Curs_Student la FN1 vom introduce o nouă coloană în cheia primară a tabelei, astfel încât aceasta va fi formată acum din două coloane: NrMatricol şi IdCurs. Acum putem afla numărul total de studenŃi înscrişi la un anumit curs. CURS_SUDENT Denumire NrMatricol NumeSt PrenumeSt Grupa IdCurs 458 Predescu Alexandru 114 4 germana 521 Radu George 122 3 franceza 521 Radu George 122 5 desen tehnic 627 Cristescu Lucian 243 1 programare 627 Cristescu Lucian 243 2 engleza 746 Irimia Diana 361 8 analiza numerica A doua formă normală (FN2) Amintim că o tabelă este în a doua formă normală dacă este în FN1 şi fiecare atribut care nu face parte din cheia primară este dependent de întreaga cheie primară.
  34. 34. Tabela Curs_Student este în FN1, dar nu îndeplineşte cea de-a doua cerinŃă pentru a fi în FN2. Coloana Denumire care depinde numai de IdCurs, nu şi de NrMatricol , care , împreună cu IdCurs, formează cheia primară. Deci avem o coloană care nu face parte din cheia primară şi nu depinde de toată cheia, în sensul că , pentru o valoare dată a lui IdCurs, cunoaştem denumirea cursului fără a mai trebui să ştim şi NrMatricol. Putem aduce tabelaCurs_Student în FN2 descompunând-o în două tabele, după următoarea regulă: pentru fiecare dependenŃă parŃială se formează o nouă tabelă (pe care o vom numi Curs) conŃinând coloanele determinate de această dependenŃa (în acest caz, Denumirea) şi determinantul lor (IdCurs). Coloanele determinate se elimină din tabela iniŃială. Cheia primară a noii tabele va fi formată din coloanele ce compun determinantul dependenŃei (IdCurs), între cele două tabele rezultate există o relaŃie de tip 1:m asigurată de existenŃa lui IdCurs drept cheie străină în tabela Curs_Student. Analog, deoarece coloanele NumeSt, PrenumeSt şi grupa depind numai de NrMatricol, le eliminăm din tabela Curs_Student şi formăm o nouă tabelă, Student, ce le va conŃine şi va avea drept cheie primară coloana NrMatricol. De asemenea , între tabelele Student şi Curs_Student există o relaŃie de tip 1:m. STUDENT NrMatricol 458 521 627 746 782 982 1204 1520 NumeSt Predescu Radu Cristescu Irimia Tanase Bunea Dragnea Popa PrenumeSt Alexandru George Lucian Diana Daciela Mihaela Liviu Marius Grupa 114 122 243 361 341 114 412 452 CURS_SUDENT IdCurs 1 1 2 NrMatricol 782 982 458 Nota 5 10 7 3 4 4 5 5 521 627 1520 521 1740 7 8 8 10 6 IdCurs 1 2 3 4 5 6 7 8 CURS Denumire programare engleza franceza germana desen tehnic Rezistenta materialelor Educatie Fizica analiza numerica A treia formă normală (FN3) O tabelă este în a treia formă normală dacă este în FN2 şi toate coloanele care nu fac parte din cheia primară sunt mutual independente (depind direct de cheia primară şi numai de ea)
  35. 35. Un exemplu calasic de dependenŃă tranzitivă este cel al coloanelor calculate. Astfel , dacă o tabelă de produse ar conŃine Coloanele PretUnitar şi Cantitate şi , în plus, coloana PretTotal această tabelă nu ar fi în FN3. Coloanele calculate nu sunt singurul caz de dependenŃa tranzitivă într-o tabelă. De exemplu în tabela Profesor se poate observă faptul că salariul depinde de titlul profesorului, coloanele Salariu, Titlu şi IdTitlu nefăcând parte din cheia primară. DependenŃele tranzitivă creează probleme la adăugarea, actualizarea şi ştergerea înregistrărilor. De exemplu, dacă la tabela Profesor se mai adaugă 20 de înregistrări , fiecare cu titlul de preparator (prep), va trebui să introducem de 20 de ori valoarea 5 pentru IdTitlu, descrierea „preparaotr” pentru Titlu şi valoarea 800 pentru Salariu , ceea ce este evident, redundant. De asemenea, dacă salariul unui preparator se modifică, va trebui să asctualizăm toate înregistrările corespunzătoare. Pentru a înlătura toate aceste inconvenienŃe, vom aduce tabela Profesor la FN3 prin crearea unei noi tabele, pe care o vom numi Titlu.Tabela Titlu va avea drept cheie primară coloana IdTitlu şi va mai conŃine coloanele Titlu şi Salariu, pe care leam eliminat din tabela Profesor. Profesor IdProf 1 2 3 4 5 6 7 Nume Popescu Marin Dragnea Ion Iosif Irina Ilie Daniel Savu Cristina Cristea George Ene Dan Catedra Matematici Limbi straine Educatie fizica Informatica Limbi straine Fizica Matematici IdTitlu 1 4 3 2 5 3 7 Titlu : IdTitlu 1 2 3 4 5 6 Titlu lector dr. asistent lector conferentiar dr. prepartor profesor dr. Salariu 1300 950 1100 1700 680 2150 2. Amintim ca regulile de integritate sunt; - unicitatea cheii primare - integritatea entităŃii – valorile cheii primare sa fie diferite de valoarea null(o valoare necunoscuta sau lipseşte) - integritatea referenŃială ) o cheie secundară trebuie să fie null în întregime sau să corespundă unei valori a cheii primare asociate.(in tabela asociată nu trebuie să existe valori fără corespondent). Tabelele Titlu şi Profesor sunt în relaŃia 1:m (un Titlu corespunde la mai multe cadre didactice). Tabele de mai sus păstrează regulile de integritate?
  36. 36. Raspuns Nu, deoarece există cadrul didactic cu IDProf= 7 cu IdTitlu =7 , care nu există in tabelul Titlu, ca funcŃie didactică. 3. Să se determine anomaliile pentru tabelul Avion A# 1 2 3 4 5 6 nume AIRBUS AIRBUS AIRBUS CAR B707 B707 capacitate 250 250 250 100 150 150 localitate PARIS PARIS LONDRA PARIS LONDRA LONDRA Constrângere: toate avioanele cu acelaşi nume au aceeaşi capacitate. Datorită dependenŃei introduse pot exista: anomalii la inserare, modificare sau ştergere, redundanŃă în date, probleme de reconexiune. 1. RedundanŃă logică. Cuplul (AIRBUS, 250) apare de trei ori. 2. Anomalie la inserŃie. S-a cumpărat un B727 cu 150 locuri. El poate fi inserat în relaŃia AVION doar dacă se defineşte o nouă valoare pentru cheia primară. 3. Anomalie la ştergere. Dacă este ştearsă înregistrarea pentru care A# este 4, atunci se pierde informaŃia că un avion CAR are capacitatea 100. 4. Anomalie la modificare. Dacă se modifică capacitatea lui B707 de la 150 la 170, atunci costul modificării este mare pentru a modifica toate înregistrările, iar dacă se modifică doar o înregistrare atunci constrângerea nu va mai fi verificată. 4. Exemplu: variante pentru a implementa FN1 pentru tabelul MASINA: Persoana Vehicul Eu R25 - W14 - R21 Tu 205 El R5 - 305 noi BX - 305 - R12 - R25 Varianta 1 Persoana Eu Eu Vehicul R25 W14
  37. 37. Eu Tu El El Noi Noi R21 205 R5 305 BX 305 Noi Noi R12 R25 Varianta 2 Persoana Prima Doi Trei Eu R25 W14 R21 Tu 205 El R5 305 Noi BX 305 R12 Patru R25 Varianta 3 (4 tabele) Masina 31 (similar se definesc Masina_32, Masina_33, Masina_34).. Persoana Vehicul Eu R25 Tu 205 El R5 Noi BX Masina_34 Persoana Vehicul Noi R25 5. Să se aduca la FN2 O relaŃie R este în a doua formă normală dacă şi numai dacă: relaŃia R este în FN1; fiecare atribut care nu este cheie (nu participă la cheia primară) este dependent de întreaga cheie primară. ATASAT_LA COD_SALARIAT# JOB_COD NR_PROIECT# FUNCTIA SUMA S1 PROGRAMATOR P1 SUPERVIZOR 60 S1 PROGRAMATOR P2 CERCETATOR 25
  38. 38. S1 PROGRAMATOR P3 AUXILIAR 10 S3 S5 VANZATOR INGINER P3 P3 SUPERVIZOR SUPERVIZOR 60 60 ATASAT_2A COD_SALARIAT# NR_PROIECT# FUNCTIA SUMA S1 P1 SUPERVIZOR 60 S1 P2 CERCETATOR 25 S1 S3 P3 P3 AUXILIAR SUPERVIZOR 10 60 S5 P3 SUPERVIZOR 60 ATASAT_2B COD_SALARIAT# JOB_COD S1 PROGRAMATOR S3 S5 VANZATOR INGINER A doua condiŃie exprimă necesitatea total dependenŃei de cheia primară. Această formă normală interzice manifestarea unor dependenŃe funcŃionale parŃiale în cadrul relaŃiei R! Pentru a obŃine o relaŃie FN2 se poate aplica regula Casey-Delobel. α∪β mulŃimea atributelor care intervin în dependenŃele funcŃionale; α∪γ reprezintă reuniunea determinantului cu restul atributelor lui A. 7. Tabelul atasat_2a nu este in FN3. De ce? Forma normală 3 (FN3) Intuitiv, o relaŃie R este în a treia formă normală dacă şi numai dacă: relaŃia R este în FN2; fiecare atribut care nu este cheie (nu participă la o cheie) depinde direct de cheia primară. atasat_3a Cod_salariat# Nr_proiect# S1 P1 S1 P2 S1 P3 S3 P3 S5 P3 atasat_3b Functia Suma Supervizor 60 Cercetator 25 Auxiliar 10 Functia Supervizor Cercetator Auxiliar Supervizor Supervizor
  39. 39. 8. Presupunem că un şantier poate executa mai multe lucrări de bază şi că o lucrare poate fi executată de mai multe şantiere. LUCRARE(cod_obiectiv#, cod_lucrare#, nume); SANTIER(nr_santier#, specialitate, sef); EXECUTA(cod_obiectiv#, cod_lucrare#, nr_santier#, descriere, functie, conducator, data_inceput, data_sfarsit). Pentru relaŃia EXECUTA sunt evidente dependenŃele: {cod_obiectiv#, cod_lucrare#} → {data_inceput, data_sfarsit}, {cod_obiectiv#, cod_lucrare#, nr_santier#} → {descriere, functie, conducator}. 9. Să se aduca la FN3 tabelel EXECUTA_1 rezultat de la 8 În tabelul EXECUTA_1(cod_obiectiv#, cod_lucrare#, nr_santier#, descriere, functie, conducator) continuă să existe redundanŃă în date. Atributul conducator depinde indirect de cheia primară prin intermediul atributului functie. Între atributele relaŃiei există dependenŃele: {cod_obiectiv#, cod_lucrare#, nr_santier#} → {descriere}, {cod_obiectiv#, cod_lucrare#, nr_santier#} → {functie} → {conducator}. Pentru a aduce relaŃia EXECUTA_1 în FN3 se aplică regula Casey- Delobel. RelaŃia se desface, prin eliminarea dependenŃelor funcŃionale tranzitive, în proiecŃiile: EXECUTA11(cod_obiectiv#, cod_lucrare#, nr_santier#, descriere, functie) EXECUTA12(functie, conducator). 10 Să se aducă la forma BCNF (Forma normală Boyce-Codd ) (Formal, o relaŃie R este în forma normală Boyce-Codd dacă şi numai dacă pentru orice dependenŃă funcŃională totală X → A, X este o cheie (candidat) a lui R.) RelaŃia INVESTESTE_IN OBIECTIV_INVESTITIE. leagă entităŃile INVESTITOR şi Ea are schema relaŃională: INVESTESTE_IN(cod_contractant#, cod_obiectiv#, nr_contract, cota_parte). Între atributele relaŃiei există dependenŃele: {cod_contractant#, cod_obiectiv#} → {nr_contract, cota_parte}, {nr_contract} → {cod_obiectiv}. Se aplică regula Casey-Delobel şi se aduce relaŃia în BCNF. INVESTESTE_IN_1(cod_obiectiv, nr_contract#); INVESTESTE_IN_2(cod_contractant#, nr_contract, cota_parte).
  40. 40. PARTEA a_II_a ACCESS În acestă parte a cursului de baze de date, se prezintă aplicaŃia Microsoft Access în 7 lecŃii după cum urmează: LECłIA 1. Elemente introductive despre ACCESS LECłIA 2. TABELE LECłIA 3. Operatori şi FuncŃii LECłIA 4. Stabilirea relaŃiilor ître tabele LECłIA 5. INTEROGĂRI LECłIA 6. FORMULARE LECłIA7. RAPOARTE LECłIA 1. Elemente introductive despre ACCESS În acestă lecŃie se vor prezenta NOŃIUNILEş Conceptul de bază de date Componentele unei baze de date Crearea, Crearea unei baze de date vidă Deschiderea unei baze de date existente Închiderea unei baze de date Conversii, Compactări, ReparaŃii) Ce este o bază de date O bază de date este o colecŃie de informaŃii interrelaŃionate gestionate ca o singură unitate.Această definiŃie este intenŃionat foarte largă, deoarece există mari diferenŃe între concepŃiile diferiŃilor producători care pun la dispoziŃie sisteme de baze de date. De exemplu, Oracle Corporation defineşte o bază de date ca fiind o colecŃie de fişiere fizice gestionate de o singură instanŃă (copie) a produsului software pentru baze de date, în timp ce Microsoft defineşte o bază de date ca fiind o colecŃie de date şi alte obiecte. Un obiect al bazei de date este o structură de date denumită,stocată în bază de date, cum ar fi un tabel, o vizualizare sau un index. Conceptul de bază de date ACESS O bază de date (în acest context) este un document Microsoft Access, folosit pentru a organiza şi accesa informaŃiile. O bază de date este organizată în înregistrări (record-uri), elemente individuale de informaŃie (d.e. datele despre o persoană intr-o agendă) şi câmpuri, fragmente de informaŃii (d.e. numele unei anumite persoane). O bază de date este, de asemenea, o colecŃie de informaŃii în legătură cu un anumit subiect sau scop, de exemplu, urmărirea comenzilor clienŃilor sau întreŃinerea unei colecŃii de muzică. Dacă baza de date nu este stocată pe un computer, sau numai părŃi din ea sunt, se va urmări informaŃia dintr-o varietate de surse ce trebuie coordonate şi organizate chiar de către utilizator.
  41. 41. Componentele unei baze de date ACESS Folosind aplicaŃia Microsoft Access, se poate administra toata informaŃia într-o singură bază de date (Database). În interiorul acestui fişier de tip Microsoft Access, se împart datele în structuri separate numite tabele (Tables); se vizualizează, adaugă şi actualizează datele dintr-o tabelă folosind formele (Forms); se găsesc şi extrag datele folosind interogări (Queries); şi se analizează sau se tipăresc datele într-un format special folosind rapoartele (Reports). Tables, Queries, Forms şi Reports sunt cele mai importante entităŃi care se creayă într+o bayă de date Access. Datele se stochează într-o singură locaŃie (în tabelă), dar se pot vizualiza sub diferite forme: interogare, raport sau formă. În momentul în care se modifică şi salvează informaŃia în tabelă atunci aceasta se va vedea şi în celelalte forme. Pentru stocarea datelor, se creează o tabelă pentru fiecare tip de informaŃie pe care doriŃi să o urmăriŃi. Pentru utilizarea în diverse forme a informaŃiilor din tabele diferite se pot defini relaŃii între tabele. Astfel, se defineşte o relaŃie între un identificator unic din tabela de Furnizori şi comenzile către acest furnizor din tabela ComenziFurnizori. Prin aceasta pentru fiecare furnizor definit în mod unic în tabela Furnizori se pot extrage din tabela ComenziFurnizori toate comenzile către acesta. Pentru a găsi şi extrage numai informaŃiile ce îndeplinesc anumite condiŃii specificate de utilizator şi care includ informaŃii din mai multe tabele, se poate crea o interogare. O interogare poate de asemenea să actualizeze sau să şteargă mai multe înregistrări în acelaşi timp, să execute calcule asupra datelor, etc Pentru a vizualiza, introduce sau schimba uşor datele direct într-un tabel, se creează o formă. Atunci când se deschide o formă, Microsoft Access extrage date dintr-unul sau mai multe tabele şi le afişează pe ecran folosind modalitatea de afişare aleasă/creată de utilizator (prin forma respectivă). Pentru analiza datelor sau pentru prezentarea lor într-o anumită structură la tipărire, este necesar să se creeze un raport. Astfel, se poate tipări un raport care grupează datele şi calculează sumele totale şi alt raport în care se afişează datele pentru diferite înregistrări din tabelă, etc. Pentru a lucra cu toate obiectele dintr-o bază de date se utilizează fereastra Database, cea care permite selectarea Tab-urilor se apasă Tab-ul dorit şi în fereastra afişată se pot vizualiza toate obiectele (de acel tip) disponibile în baza de date accesată. Folosindu-se butoanele din dreapta acestei liste, se pot deschide (Open), modifica (Design) şi crea (New) obiecte noi. CerinŃele sistemului şi posibilităŃile aplicaŃiei Pentru a folosi Microsoft Access 2003 aveŃi nevoie de un Personal Computer cu Intel Pentium 233-megahertz (MHz) sau un procesor mai rapid (Pentium III fiind recomandat) Memoria trebuie să fie de 128 MB de RAM sau mai mare. Hard disk-ul: 180 MB de spatiu liber pe disc; fişierele de instalare optionale(recommendat) necesită 200 MB aditionali de spaŃiu liber pe disc. Este necesară de asemenea şi o unitate CD-ROM sau DVD. Monitorul trebuie să fie Super VGA (800 × 600) sau un monitor cu o rezoluŃie mai mare.
  42. 42. Sistemul de operare trebuie să fie: Microsoft Windows® 2000 cu Service Pack 3 (SP3), Windows XP, sau o versiune ulterioară acestora. In ceea ce priveşte posibilităŃile aplicaŃiei putem spune că Microsoft Access poate îmbunătăŃi modalitatea în care se organizează, accesează şi partajează informatia. Access 2003 este suficient de sofisticat pentru dezvoltatori cât şi suficient de uşor pentru utilizatorii noi. Access 2003 este mai uşor de utilizat ca niciodată pentru toata lumea, oricare ar fi nivelul de pregătire. Există încorporată o experienŃă a utilizatorului îmbunătăŃită, verificarea automată a erorilor, updatarea automată a proprietăŃilor şi abilitatea de a vizualiza interdependenŃele dintre obiecte. Prin intermediul opŃiunilor Import/Export şi al link-urilor către site-urile Microsoft Windows® SharePoint™ Services se permite trasferul de date/informaŃii între membrii unei echipe. Access 2003 dă posibilitatea unei abilităŃi mărite de a importa, exporta şi de a lucra cu fişiere de date de tip Extensible Markup Language (XML). Access 2003 suportă o varietate largă de formate de date incluzând Extensible Markup Language (XML), OLEDB, Open Database Connectivity (ODBC), şi Microsoft Windows® SharePoint™ Services. Se foloseşte informaŃie dintr-o varietate largă de formate într-o interfată familiară. Access 2003 foloseşte Access 2000 ca formatul de fişier implicit pentru noile baze de date. Aceasta permite instalarea şi utilizarea Microsoft Access 2003 prin reutilizarea solutiilor Access deja existente. Microsoft Access oferă de asemenea posibilităŃi de a lucra într-o modalitate sigură cu datele folosite de exemplu prin intermediul parolării bazei de date sau prin mecanisme de back-up al bazei de date. Pornirea şi oprirea aplicaŃiei Pentru a putea utiliza Microsoft Access trebuie ca această aplicaŃie să fie instalată în cadrul pachetului Microsoft Office. După ce utilizatorul s-a asigurat că această aplicaŃie este instalată, pentru a o putea deschide trebuie să intre în meniul Start Programs şi apoi să apese Microsoft Access din acest meniu. La apăsarea acestui buton se va deschide aplicaŃia Microsoft Access în care va apărea o fereastra(Task Pane) în care utilizatorului i se va cere să precizeze acŃiunea următoare. Această acŃiune poate fi : una din cele două opŃiuni de creare a unei noi baze de date deschiderea unei baze de date existente Pentru oprirea aplicaŃiei există două posibilităŃi: fie din meniul aplicaŃiei prin apăsarea butonului Ieşire (Exit) fie din butonul Închide (Close) al fiecărei aplicaŃii de tip fereastră. Crearea unei baze de date Crearea şi deschiderea unei baze de date se pot face în două feluri: fie din fereastra de alegere a următoarei acŃiuni care va apare la pornirea aplicaŃiei (v. punctul 1.3.), fie din meniul File (Fişier – o bază de date este un fişier de tip Microsoft Access) al aplicaŃiei.

×