Modelarea relațională a entităților în bazele de date

O teorie importantă dezvoltată pentru modelul relațional de entitate (ER) (entitate – asociere) implică noțiunea de dependență funcțională (FD). Scopul studierii acestui aspect este de a vă îmbunătăți înțelegerea relațiilor dintre date și de a obține suficient formalism pentru a vă ajuta la proiectarea practică a bazelor de date.

La fel ca și constrângerile, FD-urile sunt extrase din semantica domeniului aplicației. În esență, dependențele funcționale descriu modul în care sunt legate atributele individuale. FD-urile sunt un fel de constrângere între atributele dintr-o relație și contribuie la o bună proiectare a schemei relaționale. În acest scop, vom analiza:

• Teoria de bază și definiția dependenței funcționale
• Metodologia de îmbunătățire a proiectelor de scheme, numită și normalizare

Proiectare relațională și redundanța

În general, o bună proiectare a bazei de date relaționale trebuie să surprindă toate atributele și asociațiile necesare. Proiectarea ar trebui să facă acest lucru cu o cantitate minimă de informații stocate și fără date redundante.

În proiectarea bazei de date, redundanța este în general nedorită, deoarece provoacă probleme la menținerea coerenței după actualizări. Cu toate acestea, redundanța poate duce uneori la îmbunătățiri ale performanței; de exemplu, când redundanța poate fi utilizată în locul unei combinări pentru a conecta date. O combinare este utilizată atunci când trebuie să obțineți informații pe baza a două tabele conexe.

Luați în considerare Figura 10.1: clientul 1313131 este afișat de două ori, o dată pentru contul nr. A-101 și din nou pentru contul A-102. În acest caz, numărul clientului nu este redundant, deși există anomalii de ștergere cu tabelul. A avea un tabel separat pentru clienți ar rezolva această problemă. Cu toate acestea, dacă o adresă a sucursalei s-ar schimba, ar trebui să fie actualizată în mai multe locuri. Dacă numărul clientului a fost lăsat în tabel așa cum este, atunci nu ar fi nevoie de un tabel de sucursală și nu ar fi necesară nicio asociere, iar performanța este îmbunătățită.

Conturi bancare

Figura 10.1. Un exemplu de disponibilizare utilizat cu conturi bancare și sucursale.

Anomalie de inserție

O anomalie de inserție apare atunci când introduceți informații inconsistente într-un tabel. Când introducem o nouă înregistrare, cum ar fi contul nr. A-306 din Figura 10.2, trebuie să verificăm dacă datele sucursalelor sunt în concordanță cu rândurile existente.

Anomalie de inserție – Introduceți contul A-306 la Round Hill

Figura 10.2. Exemplu de anomalie de inserție.

Anomalie de actualizare

Dacă o sucursală schimbă adresa, cum ar fi sucursala Round Hill din Figura 10.3, trebuie să actualizăm toate rândurile referitoare la acea sucursală. Schimbarea incorectă a informațiilor existente se numește o anomalie de actualizare.

Anomalie de actualizare – Adresa sucursalei Round Hill

Figura 10.3. Exemplu de anomalie de actualizare.

Anomalie de ștergere

O anomalie de ștergere apare atunci când ștergeți o înregistrare care poate conține atribute care nu ar trebui șterse. De exemplu, dacă eliminăm informații despre ultimul cont dintr-o sucursală, cum ar fi contul A-101 din sucursala Downtown din Figura 10.4, toate informațiile sucursalei dispar.

Anomalie de ștergere – Cont bancar

Figura 10.4. Exemplu de anomalie de ștergere.

Problema cu ștergerea rândului A-101 este că nu știm unde se află sucursala Downtown și pierdem toate informațiile referitoare la clientul 1313131. Pentru a evita aceste tipuri de probleme de actualizare sau ștergere, trebuie să descompunem tabelul original în câteva mai mici tabele în care fiecare tabel are o suprapunere minimă cu alte tabele.

Fiecare tabel de cont bancar trebuie să conțină informații despre o singură entitate, cum ar fi sucursala sau clientul, așa cum se arată în Figura 10.5.

Figura 10.5. Exemple de tabele de conturi bancare care conțin câte o entitate, de A. Watt.

Urmarea acestei practici va asigura că, atunci când informațiile despre sucursală sunt adăugate sau actualizate, acestea vor afecta doar o înregistrare. Deci, atunci când informațiile despre clienți sunt adăugate sau șterse, informațiile sucursalei nu vor fi modificate accidental sau înregistrate incorect.

Exemplu: tabelul proiectului angajaților și anomalii

Figura 10.6 prezintă un exemplu de tabel de proiect al angajaților. Din acest tabel, putem presupune că:

1. EmpID și ProjectID sunt un PK compozit.
2. ID-ul proiectului determină bugetul (adică, proiectul P1 are un buget de 32 de ore).

Figura 10.6. Exemplu de tabel de proiect pentru angajați, de A. Watt.

În continuare, să analizăm câteva posibile anomalii care ar putea apărea cu acest tabel în timpul următoarelor etape.

1. Acțiune: Adăugați rândul {S85,35, P1,9}
2. Problemă: există două tuple cu bugete contradictorii
3. Acțiune: Ștergeți tupla {S79, 27, P3, 1}
4. Problemă: Pasul 3 șterge bugetul pentru proiectul P3
5. Acțiune: actualizați tupla {S75, 32, P1, 7} la {S75, 35, P1, 7}
6. Problemă: Pasul 5 creează două tuple cu valori diferite pentru bugetul proiectului P1
7. Soluție: Creați un tabel separat, fiecare, pentru proiecte și angajați, așa cum se arată în Figura 10.7.

Figura 10.7. Soluție: tabele separate pentru proiect și angajat, de A. Watt.

Cum să evitați anomaliile

Cea mai bună abordare pentru crearea tabelelor fără anomalii este de a vă asigura că tabelele sunt normalizate și acest lucru este realizat prin înțelegerea dependențelor funcționale. FD se asigură că toate atributele dintr-un tabel aparțin acelui tabel. Cu alte cuvinte, va elimina redundanțele și anomaliile.

Exemplu: tabele separate pentru proiect și angajați

Tabel proiecte – Tabel angajați

Figura 10.8. Separați tabelele de proiecte și angajați cu date, de A. Watt.

Păstrând datele separate utilizând tabelele individuale ale proiectului și ale angajaților:

1. Nu se vor crea anomalii dacă se modifică un buget.
2. Nu sunt necesare valori fictive pentru proiectele care nu au angajați desemnați.
3. Dacă contribuția unui angajat este ștearsă, nu se pierd date importante.
4. Nu se creează anomalii dacă se adaugă contribuția unui angajat.

Termeni cheie

• anomalie de ștergere: apare atunci când ștergeți o înregistrare care poate conține atribute care nu ar trebui șterse
• dependență funcțională (FD): descrie modul în care sunt legate atributele individuale
• anomalie de inserție: apare atunci când introduceți informații incoerente într-un tabel
• combinare: utilizată atunci când trebuie să obțineți informații pe baza a două tabele conexe
• anomalie de actualizare: schimbarea incorectă a informațiilor existente

Sursa: Adrienne Watt, Database Design – 2nd Edition. Descărcare gratuită de la B.C. Open Textbook Collection. © 2014 Adrienne Watt and Nelson Eng. Licența (inclusiv imagini) CC BY 4.0. Traducere Nicolae Sfetcu

© 2021 MultiMedia Publishing, Baze de date, Volumul 1