Fundamentele bazelor de date Proiectarea bazelor de dateIon Cozac, Mariela CorneanuIdeea centrală care stă la baza proiectării unei baze de date relaționale este aceea de dependență a datelor. Aceasta se referă la faptul că între atributele unei relații sau între atribute din relații diferite pot exista anumite legături logice (dependențe) și acestea influențează proprietățile relațiilor în raport cu operațiile de actualizare a bazei de date.
Dependențe funcționale Presupunem că am proiectat o relație cu următoarea structură: CLFACTURI(Nrf,Codc,Numec,Adresa,Dataf). Observăm dependența atributelor Numec și Adresa față de atributul Codc, și de aici rezultă că fiecare valoare a atributului Codc determină în mod univoc valoarea corespunzătoare a celorlalte două atribute. Această structură (schemă de relație) introduce o redundanță relativ la atributele Numec și Adresa, ale căror valori se repetă pentru fiecare factură a aceluiași client. Această redundanță conduce la următoarele anomalii:
Aceste anomalii pot fi evitate dacă se descompune relația CLFACTURI în două relații: CLIENTI și FACTURI, având structurile: CLIENTI(Codc,Numec,Adresa); FACTURI(Nrf,Codc,Dataf). Un "dezavantaj" al descompunerii efectuate este acela că, pentru a obține informațiile despre un client pentru care am emis o factură, este necesară efectuarea unei operații de cuplare a celor două relații. Operația de cuplare (realizată printr-o instrucțiune Select care extrage informații din cele două tabele) nu este atât de costisitoare pe cât ar putea părea la prima vedere, dacă se aleg în mod corespunzător cheile primare și modalitățile de indexare. După cum rezultă din exemplul de mai sus problema alegerii unui model conceptual corect pentru o bază de date relațională este, de cele mai multe ori, formulată în termenii determinării unor descompuneri pentru scheme de relații date, descompuneri care să izoleze dependențele existente și prin aceasta să se evite anomaliile care decurg din ele.
Definiție Fie R(A1, A2, ..., An) o relație, X și Y două atribute (simple sau compuse) submulțimi ale mulțimii de atribute (A1, A2, ..., An). Atributul X determină atributul Y (sau Y depinde funcțional de X) și notăm XźY dacă și numai dacă orice valoare a atributului X determină în mod unic valoarea atributului Y.
Observații
Definiție Fie XźY o dependență funcțională; spunem că avem dependență totală dacă nici o submulțime VÌX nu induce o dependență funcțională VźY; în caz contrar, dacă există o submulțime VźX care induce o dependență funcțională VźY, spunem că avem dependență parțială. Existența în cadrul relațiilor a dependențelor funcționale este un fapt natural. În orice relație există o dependență funcțională a oricărui atribut față de atributul cheie (sau setul de atribute care formează cheia primară): știm că atributul cheie identifică în mod unic fiecare tuplu. Dependențele funcționale existente în cadrul unei relații se datorează semanticii segmentului din lumea reală care se modelează prin această schemă și reprezintă restricții referitoare la realitatea modelată. Aceste restricții constituie informații asociate relației și care nu pot fi înglobate în reprezentarea relației, deși se reflectă indirect în această reprezentare prin valorile concrete pe care le iau atributele relației. Singura cale de a determina dependențele funcționale din cadrul unei scheme de relație este aceea de a lua în considerare semnificația tuturor atributelor componente.
Primele trei forme normale Am arătat mai sus că existența anumitor dependențe funcționale în cadrul unei scheme de relație conduce la o serie de anomalii legate de adăugare, ștergere sau modificare. Am văzut că aceste anomalii pot fi evitate dacă se înlocuiesc schemele de relații date prin altele echivalente, în cadrul cărora dependențele sunt supuse anumitor restricții. Aceste scheme de relații se numesc forme normale. Formele normale constituie criterii de ghidare a proiectantului bazei de date în ceea ce privește alegerea schemelor de relație. Regulile de normalizare se aplică cu scopul de a evita anomaliile legate de adăugare, ștergere sau modificare. Efectul direct al normalizării este reducerea redundanței datelor, redundanță care constituie cauza tuturor acestor anomalii. Prin reducerea redundanței se localizează efectul fiecărei operații de actualizare la un număr cât mai restrâns de tuple, ceea ce înseamnă creșterea gradului de independență reciprocă a tuplelor. În cele ce urmează vom studia doar primele trei forme normale, care se definesc pe baza dependențelor funcționale stabilite între cheia primară și celelalte atribute non-cheie ale unei relații. În majoritatea problemelor practice aceste trei forme normale sunt mai mult decât suficiente.
Definiție O relație R este în prima formă normală dacă și numai dacă toate atributele sale iau numai valori atomice (scalare). Această condiție introduce restricția ca domeniile pe care se definesc atributele relației R să conțină doar valori atomice, ceea ce înseamnă că toate tuplele unei relații au același număr de câmpuri (aceeași dimensiune). Toate atributele unei relații trebuie să fie atribute simple, deci nu pot fi atribute compuse, iar valorile din cadrul tuplelor nu pot fi structuri, vectori sau tuple. Modelul relațional nu studiază relații care au tuple de dimensiuni variabile. A doua și a treia formă normală rezolvă problemele cauzate de existența dependențelor funcționale dintre atributele cheie și cele non-cheie din cadrul tuplelor. Trecerea unei relații din prima formă normală în a doua formă normală în procesul de normalizare a relațiilor constă în izolarea tuturor dependențelor funcționale și crearea unor relații noi definite cu ajutorul atributelor implicate în aceste dependențe. Pentru fiecare dependență funcțională se creează o relație distinctă. Acest lucru este posibil atunci când relația dată are o cheie multiatribut.
Definiție O relație este în a doua formă normală dacă și numai dacă este în prima formă normală și orice atribut non-cheie este total dependent față de cheia primară a relației. Pentru orice relație aflată în prima formă normală se poate găsi o descompunere în relații aflate în a doua formă normală care este echivalentă cu relația inițială. Aceasta înseamnă că din relațiile descompunerii se poate reconstitui prin cuplare întreg conținutul de informație al relației inițiale. Așadar înlocuirea unei relații printr-o descompunere a sa în relații aflate în a doua formă normală este un proces reversibil. Avantajul acestei înlocuiri este evitarea unor anomalii legate de operațiile de adaugare, ștergere și modificare. Dar oare sunt evitate toate aceste anomalii?
Exemplu Fie schema de relație PRODFACT(Nrf,Codc,Dataf,Codp,Cant) având ca și cheie primară setul (Nrf,Codp) și următoarele dependențe funcționale:
Deoarece setul (Codc,Dataf) depinde total numai de Nrf, redundanța are drept consecință o anomalie la adăugare: pentru fiecare poziție de pe factură aceste informații trebuie repetate. Ca dovadă că se poate mai rău decât în exemplul de mai sus, să ne imaginăm ce consecințe ar avea utilizarea unei structuri asemănătoare cu următoarea: TOTFACT(Nrf,Codc,Numec,Adresa,Dataf, Codp,Denp,Pret,Cant). Remarcăm o serie de dependențe funcționale, dintre care prezentăm câteva mai semnificative: Nrfź(Codc,Numec,Adresa,Dataf); Codcź(Numec,Adresa); Codpź(Denp,Pret); (Nrf,Codp)źCant. Dependența Nrfź(Numec,Adresa) se numește tranzitivă, deoarece ea se deduce din dependențele NrfźCodc și Codcź(Numec,Adresa); o ignorăm pentru moment. Să descompunem această schemă astfel: CLFACTURI(Nrf,Codc,Numec,Adresa,Dataf); PRODUSE(Codp,Denp,Pret); DETALII(Nrf,Codp,Cant). Se poate verifica faptul că toate cele trei scheme se află în a doua formă normală. Recompunerea relației originale se poate face cu ajutorul unei instrucțiuni Select SQL. Și, totuși, se observă o redundanță supărătoare în schema CLFACTURI, datorită atributelor Numec și Adresa. Aceasta generează aceleași anomalii la adăugare, ștergere sau modificare, deoarece am ignorat dependențele funcționale tranzitive.
Definiție O relație R este în a treia formă normală dacă și numai dacă este în a doua formă normală și toate atributele non-cheie sunt total dependente numai de cheia primară și nu și de alte atribute non-cheie. Să reluăm exemplul de mai sus. Schema CLFACTURI se descompune mai departe astfel: CLIENTI(Codc,Numec,Adresa); FACTURI(Nrf,Codc,Dataf).
Indicații În continuare vom prezenta câteva recomandări referitoare la proiectarea structurii unei baze de date. Analiza problemei pe care trebuie să o rezolvăm identifică toate informațiile care se introduc în baza de date. Se identifică de asemenea toate corelațiile care există între aceste informații - se identifică în fond dependențele funcționale. Pentru a putea identifica mai ușor aceste corelații se recomandă ca în baza de date fiecare entitate care se înregistrează să aibă o cheie de identificare (un cod). Toate informațiile care se deduc dintr-o astfel de cheie (cod) se înregistrează într-o relație asociată clasei respective de entități. Descompunerea unei scheme de relație se face până când toate schemele de relație se află în a treia formă normală.
Exemplu Analiza unei probleme de evidență a comenzilor a pus în evidență următoarele informații care trebuie înregistrate în baza de date:
Atributele cu care operăm în continuare sunt: Codf, Numef,Adresa,Codp,Denp,Pret,Nrc,Datac,Cant. Dependențele funcționale de bază pe care le-am identificat (am evitat orice dependențe tranzitive) sunt: Codfź(Numef,Adresa); CodpźDenp; prețul nu poate apărea aici deoarece el diferă de la un furnizor la altul; (Codf,Codp)źPret; Nrcź(Codf,Datac); (Nrc,Codp)źCant. Din aceste dependențe funcționale de bază se deduc imediat schemele de relație care vor compune baza de date.
D-na. prof. Mariela Corneanu este cadru didactic la Grupul Școlar de Chimie și Protecția Mediului din Târgu Mureș și poate fi contactată prin e-mail la adresa cmariela@uttgm.ro. Dl. lect. univ. Ion Cozac este cadru didactic la Universitatea "Petru Maior" din Târgu Mureș și poate fi contactat prin e-mail la adresa cozac@uttgm.ro. [cuprins] |