Constrângerile sunt o caracteristică foarte importantă într-un model relațional. De fapt, modelul relațional susține teoria bine definită a constrângerilor asupra atributelor sau tabelelor. Constrângerile sunt utile, deoarece permit unui proiectant să specifice semantica datelor din baza de date. Constrângerile sunt regulile care obligă SGBD-urile să verifice dacă datele satisfac semantica.
Integritatea domeniului
Domeniul restricționează valorile atributelor din relație și este o constrângere a modelului relațional. Cu toate acestea, există semantică din lumea reală pentru date care nu pot fi specificate dacă sunt utilizate numai cu constrângeri de domeniu. Avem nevoie de modalități mai specifice de a stabili ce valori de date sunt sau nu permise și ce format este potrivit pentru un atribut. De exemplu, ID-ul angajaților (EID) trebuie să fie unic, sau Data nașterii angajatului să fie în intervalul [1 ianuarie 1950, 1 ianuarie 2000]. Astfel de informații sunt furnizate în declarații logice numite constrângeri de integritate.
Există mai multe tipuri de constrângeri de integritate, descrise mai jos.
Integritatea entității
Pentru a asigura integritatea entității, este necesar ca fiecare tabel să aibă o cheie primară (PK). Nici PK și nici o parte a acestuia nu pot conține valori nule. Acest lucru se datorează faptului că valorile nule pentru cheia primară înseamnă că nu putem identifica unele rânduri. De exemplu, în tabelul ANGAJAT, Telefonul nu poate fi o cheie primară, deoarece este posibil ca unele persoane să nu aibă telefon.
Integritate referențială
Integritatea referențială necesită ca o cheie externă să aibă o cheie primară potrivită sau trebuie să fie nulă. Această constrângere este specificată între două tabele (părinte și copil); menține corespondența între rândurile din aceste tabele. Înseamnă că referința de la un rând dintr-un tabel la alt tabel trebuie să fie validă.
Exemple de constrângere referențială de integritate în baza de date Client / Comandă a Companiei:
- Client (CustID. CustName)
- Comandă (QrderID, CustID, OrderDate)
Pentru a ne asigura că nu există înregistrări orfane, trebuie să impunem integritatea referențială. O înregistrare orfană este una a cărei valoare FK a cheii externe nu se găsește în entitatea corespunzătoare – entitatea în care se află PK. Amintiți-vă că o asociere tipică este între un PK și FK.
Constrângerea referențială de integritate afirmă că ID-ul clientului (CustID) din tabelul Comenzii trebuie să se potrivească cu un CustID valid din tabelul Clientului. Majoritatea bazelor de date relaționale au integritate referențială declarativă. Cu alte cuvinte, atunci când tabelele sunt create, constrângerile referențiale de integritate sunt configurate.
Iată un alt exemplu dintr-o bază de date Curs / Clasă:
- Curs (CrsCode, DeptCode, Descriere)
- Clasa (CrsCode, Section. ClassTime)
Constrângerea referențială de integritate afirmă că CrsCode din tabelul Class trebuie să se potrivească cu un CrsCode valid din tabelul Course. În această situație, nu este suficient ca CrsCode și Section din tabelul Class să alcătuiască PK, trebuie să impunem și integritatea referențială.
La configurarea integrității referențiale este important ca PK și FK să aibă aceleași tipuri de date și să provină din același domeniu, altfel sistemul de gestionare a bazelor de date relaționale (SGBDR) nu va permite unirea. SGBDR este un sistem popular de baze de date care se bazează pe modelul relațional introdus de E. F. Codd de la San Jose Research Laboratory IBM. Sistemele de baze de date relaționale sunt mai ușor de utilizat și de înțeles decât alte sisteme de baze de date.
Integritate referențială în Microsoft Access
În Microsoft (MS) Access, integritatea referențială este configurată prin alăturarea PK din tabela Client la CustID în tabelul Order. Vedeți Figura 9.1 pentru a vedea cum se realizează acest lucru pe ecranul Edit Relationships din MS Access.
Figura 9.1. Acces referențial în MS Access, de A. Watt.
Integritate referențială utilizând Transact-SQL (MS SQL Server)
Atunci când utilizați Transact-SQL, integritatea referențială este setată la crearea tabelei Order cu FK. Mai jos sunt enunțate declarațiile care arată FK în tabelul Order referitoare la PK în tabelul Customer.
CREATE TABLE Customer
( CustID INTEGER PRIMARY KEY,
CustName CHAR(35) )
CREATE TABLE Orders
( OrderID INTEGER PRIMARY KEY,
CustID INTEGER REFERENCES Customer(CustID),
OrderDate DATETIME )
Reguli cheie externe
La stabilirea integrității referențiale pot fi adăugate reguli de cheie externe suplimentare, cum ar fi ce să faci cu rândurile copil (în tabelul Comenzi) atunci când înregistrarea cu PK, parte a părintelui (Client), este ștearsă sau modificată (actualizată). De exemplu, fereastra Editare relații din MS Access (vezi Figura 9.1) prezintă două opțiuni suplimentare pentru regulile FK: Actualizare în cascadă și Ștergere în cascadă. Dacă acestea nu sunt selectate, sistemul va împiedica ștergerea sau actualizarea valorilor PK din tabelul părinte (tabelul Client) dacă există o înregistrare secundară. Înregistrarea copil este orice înregistrare cu un PK corespunzător.
În unele baze de date, există o opțiune suplimentară la selectarea opțiunii Ștergere numită Setare la NULL. Când aceasta este aleasă, rândul PK este șters, dar FK din tabelul copil este setat la NULL. Deși acest lucru creează un rând orfan, este acceptabil.
Constrângeri de întreprindere
Constrângerile de întreprindere – denumite uneori constrângeri semantice – sunt reguli suplimentare specificate de utilizatori sau de administratorii de baze de date și se pot baza pe mai multe tabele.
Aici sunt cateva exemple.
- O clasă poate avea maximum 30 de elevi.
- Un profesor poate preda maximum patru clase pe semestru.
- Un angajat nu poate participa la mai mult de cinci proiecte.
- Salariul unui angajat nu poate depăși salariul managerului angajatului.
Reguli de afaceri
Regulile de afaceri sunt obținute de la utilizatori atunci când se colectează cerințe. Procesul de colectare a cerințelor este foarte important, iar rezultatele acestuia ar trebui să fie verificate de utilizator înainte ca proiectarea bazei de date să fie construită. Dacă regulile de afaceri sunt incorecte, designul va fi incorect și, în cele din urmă, aplicația construită nu va funcționa așa cum se așteptau utilizatorii.
Câteva exemple de reguli de afaceri sunt:
- Un profesor poate preda la mai mulți elevi.
- O clasă poate avea maximum 35 de elevi.
- Un curs poate fi predat de mai multe ori, dar de un singur instructor.
- Nu toți profesorii predau cursuri.
Cardinalitate și conectivitate
Regulile de afaceri sunt utilizate pentru a determina cardinalitatea și conectivitatea. Cardinalitatea descrie relația dintre două tabele de date prin exprimarea numărului minim și maxim de apariții ale entității asociate cu o apariție a unei entități conexe. În figura 9.2, puteți vedea cum cardinalitatea este reprezentată de marcajele cele mai interioare de pe simbolul relației. În această figură, cardinalitatea este 0 (zero) în dreapta și 1 (una) în stânga.
Figura 9.2. Poziția conectivității și cardinalității asupra unui simbol de relație, de A. Watt.
Simbolul cel mai exterior al simbolului relației, pe de altă parte, reprezintă conectivitatea dintre cele două tabele. Conectivitatea este relația dintre două tabele, de exemplu, unu la unu sau unu la mulți. Singura dată când este zero este când FK poate fi nul. Când vine vorba de participare, există trei opțiuni pentru relația dintre aceste entități: 0 (zero), 1 (una) sau multe. În Figura 9.2, de exemplu, conectivitatea este 1 (una) pe partea exterioară, din partea stângă a acestei linii și multe pe partea exterioară, din partea dreaptă.
Figura 9.3. arată simbolul care reprezintă o relație unu la mulți.
În Figura 9.4, sunt afișați atât markerii interiori (reprezentând cardinalitatea), cât și cei externi (reprezentând conectivitatea). Partea stângă a acestui simbol este citită ca minim 1 și maxim 1. În partea dreaptă, este citită ca: minim 1 și maxim mulți.
Tipuri de relații
Linia care conectează două tabele, într-un ERD, indică tipul de relație dintre tabele: fie identificare, fie neidentificativă. O relație de identificare va avea o linie continuă (în care PK conține FK). O relație neidentificativă este indicată printr-o linie întreruptă și nu conține FK în PK.
Figura 9.5. Relație de identificare și neidentificativă, de A. Watt.
Relații opționale
Într-o relație opțională, FK poate fi nulă sau tabelul părinte nu trebuie să aibă o apariție corespunzătoare a tabelului copil. Simbolul, prezentat în Figura 9.6, ilustrează un tip cu un zero și trei vârfuri (indicând multe), care este interpretat ca zero SAU mulți.
De exemplu, dacă vă uitați la tabelul Comenzi din partea dreaptă a figurii 9.7, veți observa că un client nu trebuie să plaseze o comandă pentru a fi client. Cu alte cuvinte, partea multe este opțională.
Figura 9.7. Exemplu de utilizare a unui simbol de relație zero la multe opțională, de A. Watt.
Simbolul relației din Figura 9.7 poate fi, de asemenea, citit după cum urmează:
- Partea stângă: entitatea comandă trebuie să conțină cel puțin o entitate corespunzătoare în tabelul Clienți și maximum o entitate corespunzătoare .
- Partea dreaptă: un client poate plasa un minim de zero comenzi sau maximum multe comenzi.
Figura 9.8 prezintă un alt tip de simbol de relație opțională cu zero și unu, adică zero SAU unu. Partea unu este opțională.
Figura 9.9 oferă un exemplu al modului în care ar putea fi utilizat un simbol zero la unu.
Figura 9.9. Exemplu de utilizare a unui simbol de relație zero la unu opțională, de A. Watt.
Relații obligatorii
Într-o relație obligatorie, o apariție a unei entități necesită o apariție a entității corespunzătoare. Simbolul pentru această relație arată unu și doar unu, așa cum se arată în Figura 9.10. Partea unu este obligatorie.
Vedeți Figura 9.11 pentru un exemplu al modului în care este utilizat simbolul obligatoriu unu și doar unu.
Figura 9.11. Exemplu de simbol unu și doar unu obligatoriu, de A. Watt.
Figura 9.12 ilustrează cum arată un simbol de relație unu la mulți, acolo unde partea mulți este obligatorie.
Consultați Figura 9.13 pentru un exemplu despre modul în care simbolul unu la mulți poate fi folosit.
Figura 9.13. Exemplu de simbol de relație obligatorie unu la mulți, de A. Watt.
Până acum am văzut că partea cea mai interioară a unui simbol de relație (în partea stângă a simbolului din Figura 9.14) poate avea o cardinalitate 0 (zero) și o conectivitate de mulți (prezentată în partea dreaptă a simbolului în Figura 9.14), sau unu (nu este prezentată).
Cu toate acestea, nu poate avea o conectivitate de 0 (zero), așa cum este afișat în Figura 9.15. Conectivitatea poate fi doar 1.
Simbolurile de conectivitate arată maximele. Deci, dacă gândiți logic, dacă simbolul de conectivitate din partea stângă arată 0 (zero), atunci nu ar exista nicio conexiune între tabele.
Modul de a citi un simbol de relație, cum ar fi cel din Figura 9.16, este după cum urmează.
- Codul CustID din tabelul Comenzii trebuie să fie, de asemenea, găsit în tabelul Client de minimum 0 și maxim de 1 ori.
- 0 înseamnă că CustID din tabelul Comenzi poate fi nul.
- Cel mai stâng 1 (chiar înainte de 0 reprezentând conectivitatea) spune că, dacă există un CustID în tabelul Comenzi, acesta poate fi în tabelul Client o singură dată.
- Când vedeți simbolul 0 pentru cardinalitate, puteți presupune două lucruri: T
- FK din tabelul Comandă permite valori nule și
- FK nu face parte din PK deoarece PK-urile nu trebuie să conțină valori nule.
Figura 9.16. Relația dintre un tabel Client și un tabel Comanda, de A. Watt.
Termeni cheie
- reguli de afaceri: obținute de la utilizatori atunci când se colectează cerințe, și sunt utilizate pentru a determina cardinalitatea
- cardinalitate: exprimă numărul minim și maxim de apariții ale entității asociate cu o apariție a unei entități conexe
- conectivitate: relația dintre două tabele, de exemplu, unu la unu sau unu la mulți
- constrângeri: regulile care obligă SGBD-urile să verifice dacă datele satisfac semantica
- integritatea entității: necesită ca fiecare tabel să aibă o cheie primară; nici cheia primară și nici o parte a acesteia nu pot conține valori nule
- relație de identificare: unde cheia primară conține cheia externă; indicată într-un ERD printr-o linie continuă
- constrângeri de integritate: declarații logice care afirmă ce valori de date sunt sau nu permise și ce format este potrivit pentru un atribut
- relație obligatorie: o apariție a unei entități necesită o apariție a entității corespunzătoare.
- relație neidentificativă: nu conține cheia externă în cheia primară; indicată într-un ERD printr-o linie punctată
- relație opțională: FK poate fi nulă sau tabelul părinte nu trebuie să aibă o apariție corespunzătoare a tabelului copil
- înregistrare orfană: o înregistrare a cărei valoare a cheii externe nu se găsește în entitatea corespunzătoare – entitatea în care se află cheia primară
- integritate referențială: necesită ca o cheie externă să aibă o cheie primară potrivită sau trebuie să fie nulă
- sistemul de gestionare a bazelor de date relaționale (SGBDR): un sistem popular de baze de date bazat pe modelul relațional introdus de E. F. Codd de la San Jose Research Laboratory IBM
- tip de relație: tipul de relație dintre două tabele dintr-un ERD (fie identificatoare, fie neidentificativă); această relație este indicată de o linie trasată între cele două tabele.
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
Lasă un răspuns