4.1 Introducere

Prin conversia tabelelor bazei de date în tabele obișnuite, acum puteți analiza relațiile dintre ele. Numărul de elemente care interacționează între două tabele înrudite se numește cardinalitate. Cardinalitatea vă ajută să controlați cât de eficient ați partiționat datele în tabele.

Teoretic, toate entitățile pot menține relații între ele, dar în practică, există trei tipuri de relații între entități:

  • Unu la unu
  • Unu la mulți
  • multi la multi

4.2 Comunicare unu-la-unu

Dacă există o singură instanță a entității A pentru fiecare instanță a entității B, se spune că acestea au o relație unu-la-unu (deseori notate ca „1:1”). Pe diagramele ER, o astfel de relație este indicată printr-o linie cu o bară mică la fiecare capăt:

O relație 1:1 indică, în general, că, dacă nu aveți un motiv întemeiat să le păstrați separate, datele celor două tabele sunt cel mai bine combinate într-unul singur.

Cu toate acestea, în unele circumstanțe, este rezonabil să folosiți tabele cu relații 1:1. Dacă tabelele dvs. au câmpuri cu date opționale, cum ar fi descrieri și, în multe cazuri, sunt goale, este logic să mutați toate descrierile într-un tabel separat, ceea ce vă va permite să scăpați de lacunele frecvente și să creșteți eficiența bazei de date. .

Apoi, pentru a mapa corect datele, va trebui să includeți cel puțin o coloană identică în fiecare tabel (cel mai bine este să alegeți o cheie primară pentru aceasta).

4.3 Relația unu-la-mulți

Acest tip de relație apare atunci când o înregistrare dintr-un tabel este asociată cu mai multe entități din altul. De exemplu, același client ar putea plasa mai multe comenzi sau un vizitator al bibliotecii ar putea împrumuta mai multe cărți într-o singură vizită. Relațiile unu-la-mai multe (sau 1:M pe scurt) sunt exprimate într-o diagramă folosind notația labele de corb, așa cum se arată în exemplul de mai jos:

Pentru a aplica o relație 1:M atunci când planificați o bază de date, adăugați pur și simplu cheia primară din tabelul „unu” ca atribut la tabelul „multe”. Dacă cheia primară se află într-un alt tabel, se numește „cheie străină”. Tabelul „unu” este considerat tabelul părinte, în timp ce tabelul „multe” este considerat tabelul copil.

4.4 Relație multi-la-mulți

Atunci când mai multe entități dintr-un tabel pot fi conectate la mai multe entități dintr-un altul, se consideră că ele au o relație multi-la-mulți (sau M:M). De exemplu, o astfel de relație există între studenți și clase, deoarece fiecare elev poate urma mai multe clase diferite și, în consecință, mulți elevi pot veni la fiecare clasă.

Pe diagrama ER, acest tip de relație este afișat după cum urmează:

Din păcate, este imposibil să implementezi direct o astfel de relație în baza de date. Prin urmare, va trebui să fie împărțit în două relații unu-la-mai multe.

Pentru a face acest lucru, va trebui să creați o nouă entitate între cele două tabele. Dacă se stabilește o relație M:M între vânzări și produse, noua entitate poate fi numită „produse vândute” deoarece va reprezenta conținutul fiecărei vânzări.

Cu „marfa vândută” și tabelul „vânzări” și tabelul „mărfuri” vor fi legate prin tipul 1:M. În diferite modele, astfel de entități intermediare sunt numite diferit - „tabele de conectare”, „entități asociative” sau „tabele de noduri”.

Fiecare intrare de tabel de legături conectează două entități diferite ale tabelelor adiacente (și poate conține, de asemenea, informații suplimentare). De exemplu, un tabel de legătură între studenți și clase ar putea arăta astfel:

4.5 Obligatoriu sau nu?

O altă abordare a analizei legăturilor este de a determina care dintre entitățile conectate este o condiție prealabilă pentru prezența altei entități. Partea opțională a legăturii este marcată cu un cerc pe portbagaj.

De exemplu, pentru ca un stat să aibă propriul său reprezentant în ONU, acesta trebuie să existe pe harta lumii, dar afirmația contrară va fi falsă:

Două entități pot fi interdependente (adică una nu poate exista fără cealaltă).

Legături recursive

Uneori, un tabel se poate referi la el însuși. De exemplu, un tabel de angajați poate avea un atribut „manager” care ne-ar trimite la un alt angajat din același tabel. Aceasta este relația recursivă.

Conexiuni suplimentare

Legăturile sunt considerate redundante dacă sunt exprimate de mai multe ori. De regulă, unul dintre ele poate fi șters fără a pierde informații importante. De exemplu, dacă entitatea „studenți” este conectată la entitatea „profesori” nu numai direct, ci și indirect prin „clase”, are sens să se elimine relația dintre entitățile „elevi” și „profesori”. Această decizie este justificată de faptul că este posibilă repartizarea elevilor profesorilor doar prin cursuri.

4.6 Integritatea referenţială a datelor

Când schimbați cheile primare și străine, ar trebui să respectați un aspect precum integritatea referențială a datelor . Ideea sa principală este de a păstra două tabele într-o bază de date care stochează aceleași date consistente.

Integritatea datelor reprezintă relații corect construite între tabele cu legături corecte între ele. În ce cazuri integritatea datelor poate fi încălcată:

  • Anomalie de ștergere . Apare atunci când un rând este șters din tabelul principal. În acest caz, cheia externă din tabelul dependent continuă să se refere la rândul șters din tabelul principal.
  • Anomalie de inserare . Apare atunci când un rând este inserat într-un tabel dependent. În acest caz, cheia externă din tabelul dependent nu se potrivește cu cheia primară a niciunuia dintre rândurile din tabelul principal.
  • Actualizați anomalia. Cu o astfel de anomalie, mai multe rânduri ale unui tabel pot conține date care aparțin aceluiași obiect. Dacă modificați datele pe un rând, acestea pot intra în conflict cu datele de pe alt rând.

Anomalie de ștergere

Pentru a rezolva anomalia de ștergere, cheia externă trebuie setată la una dintre cele două constrângeri:

Dacă un rând dintr-un tabel dependent necesită în mod necesar un rând din tabelul principal, atunci cheia externă este setată la ștergere în cascadă. Adică, atunci când un rând este șters din tabelul principal, rândul(ele) asociat(e) sunt șterse din tabelul dependent.

Dacă un rând dintr-un tabel dependent nu permite nicio relație cu un rând din tabelul principal (adică o astfel de relație este opțională), atunci cheia externă este setată la NULL când rândul aferent este șters din tabelul principal. Coloana cheii externe trebuie să poată fi nulă.

Anomalie de inserare

Pentru a rezolva anomalia de inserare la adăugarea la un tabel de date dependent, coloana care reprezintă cheia străină trebuie să fie nulă. Și astfel, dacă obiectul adăugat nu are nicio legătură cu tabelul principal, atunci coloana cheii externe va avea o valoare NULL.

Actualizați anomaliile

Pentru a rezolva problema anomaliei de actualizare, se aplică normalizarea, care a fost discutată mai devreme.