Home » Articole » RO » Calculatoare » Baze de date » Reguli și constrângeri de integritate în bazele de date

Reguli și constrângeri de integritate în bazele de date

postat în: Baze de date 0

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.

Baze de date - Acces referențial în 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.

Baze de date - Poziția conectivității și cardinalității 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.

Baze de date - relație unu la mulți Figura 9.3.

Î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.

Baze de date - markerii Figura 9.4.

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.

Baze de date - Relație de identificare și neidentificativă 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.

Baze de date - un zero și trei vârfuriFigura 9.6.

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ă.

Baze de date - relație zero la multe 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ă.

Baze de date - relație opțională cu zero și unu Figura 9.8.

Figura 9.9 oferă un exemplu al modului în care ar putea fi utilizat un simbol zero la unu.

Baze de date - relație zero la unu opțională 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.

Baze de date - relație unu și doar unuFigura 9.10.

Vedeți Figura 9.11 pentru un exemplu al modului în care este utilizat simbolul obligatoriu unu și doar unu.

Baze de date - unu și doar unu obligatoriu 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.

Baze de date - relație unu la mulți Figura 9.12.

Consultați Figura 9.13 pentru un exemplu despre modul în care simbolul unu la mulți poate fi folosit.

Baze de date - relație obligatorie unu la mulți 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ă).

Baze de date Figura 9.14.

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.

Baze de date Figura 9.15.

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
    1. FK din tabelul Comandă permite valori nule și
    2. FK nu face parte din PK deoarece PK-urile nu trebuie să conțină valori nule.

Baze de date - Relația dintre un tabel Client și un tabel Comanda 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

Ghidul Google SEO
Ghidul Google SEO

Ghidul de iniţiere Google privind optimizarea pentru motoarele de căutare, Versiunea 1.1, 13 noiembrie 2008 Acest document a fost lansat iniţial ca un efort pentru a ajuta echipele Google, însă este la fel de util şi pentru webmasterii începători în … Citeşte mai mult

Nu a fost votat $0,00 Selectează opțiunile
Filosofia tehnologiei blockchain - Ontologii
Filosofia tehnologiei blockchain – Ontologii

Despre necesitatea şi utilitatea dezvoltării unei filosofii specifice tehnologiei blockchain, accentuând pe aspectele ontologice. După o Introducere în care evidenţiez principalele direcţii filosofice pentru această tehnologie emergentă, în Tehnologia blockchain explicitez modul de funcţionare al blockchain, punând în discuţie direcţiile ontologice de dezvoltare … Citeşte mai mult

Nu a fost votat $0,00$2,44 Selectează opțiunile
Excel - Ghid pentru începători
Excel – Ghid pentru începători

Acest ghid este destinat să vă ajute să învățați și să lucrați cu Microsoft Excel. Se bazează pe utilizarea Excel 2016 pe un computer Windows, dar conceptele și instrumentele acoperite rămân destul de consistente cu unele versiuni mai vechi de … Citeşte mai mult

Nu a fost votat $0,00 Selectează opțiunile

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *