MODELUL BAZEI DE DATE RELAȚIONALE: ELEMENTE, CUM SE FACE, DE EXEMPLU - TEHNOLOGIE - 2025

Modelul relațional al bazei de date este o metodă de structurare a datelor utilizând relații, folosind structuri asemănătoare grilei, constând din coloane și rânduri. Este principiul conceptual al bazelor de date relaționale. A fost propus de Edgar F. Codd în 1969.

De atunci a devenit modelul de bază de date dominant pentru aplicațiile de afaceri, în comparație cu alte modele de baze de date, cum ar fi ierarhic, rețea și obiect.

Sursa: pixabay.com

Codd nu avea nici o idee cât de extrem de vitală și influentă ar fi munca sa ca platformă de baze de date relaționale. Majoritatea oamenilor sunt foarte familiari cu expresia fizică a unei relații dintr-o bază de date: tabelul.

Modelul relațional este definit ca baza de date care permite gruparea elementelor de date într-una sau mai multe tabele independente, care pot fi legate între ele prin utilizarea câmpurilor comune fiecărui tabel aferent.

Managementul bazelor de date

Un tabel de baze de date este similar cu o foaie de calcul. Cu toate acestea, relațiile care pot fi create între tabele permit unei baze de date relaționale să stocheze eficient o cantitate mare de date, care pot fi recuperate eficient.

Scopul modelului relațional este furnizarea unei metode declarative pentru specificarea datelor și întrebărilor: utilizatorii declară direct ce informații conține baza de date și ce informații doresc de la aceasta.

Pe de altă parte, îl lasă în software-ul sistemului de gestionare a bazelor de date pentru a descrie structurile de date pentru stocare și procedura de regăsire pentru a răspunde la întrebări.

Majoritatea bazelor de date relaționale utilizează limbajul SQL pentru interogarea și definirea datelor. În prezent, există multe sisteme relaționale de gestionare a bazelor de date sau RDBMS (Sistem de relații de baze de date relaționale), cum ar fi Oracle, IBM DB2 și Microsoft SQL Server.

Caracteristici și elemente

- Toate datele sunt reprezentate conceptual ca un aranjament ordonat de date în rânduri și coloane, numit relație sau tabel.

- Fiecare masă trebuie să aibă un antet și un corp. Antetul este pur și simplu lista de coloane. Corpul este setul de date care umple tabelul, organizat pe rânduri.

- Toate valorile sunt scalare. Adică, la orice poziție dată de rând / coloană din tabel, există o singură valoare.

-Elements

Figura următoare prezintă un tabel cu numele elementelor sale de bază, care alcătuiesc o structură completă.

tuplu

Fiecare rând de date este un tuple, cunoscut și sub numele de înregistrare. Fiecare rând este un n-tuple, dar „n-” este în general aruncat.

Coloană

Fiecare coloană dintr-un tuple se numește atribut sau câmp. Coloana reprezintă setul de valori pe care le poate avea un atribut specific.

Cheie

Fiecare rând are una sau mai multe coloane numite cheie de tabel. Această valoare combinată este unică pentru toate rândurile dintr-un tabel. Prin intermediul acestei taste, fiecare tuple va fi identificat în mod unic. Adică, cheia nu poate fi duplicată. Se numește cheia primară.

Pe de altă parte, o cheie străină sau secundară este câmpul dintr-un tabel care se referă la cheia primară a unui alt tabel. Este utilizat pentru a face referire la tabelul primar.

-Reguli de integritate

Când proiectați modelul relațional, definiți anumite condiții care trebuie îndeplinite în baza de date, numite reguli de integritate.

Integritatea cheie

Cheia primară trebuie să fie unică pentru toate tuplurile și nu poate fi nulă (NULL). În caz contrar, nu veți putea identifica unic rândul.

Pentru o cheie cu mai multe coloane, niciuna dintre aceste coloane nu poate conține NULL.

Integritate referențială

Fiecare valoare a unei chei străine trebuie să corespundă unei valori a cheii primare a tabelului referit sau primar.

Un rând cu o cheie străină poate fi introdus în tabelul secundar numai dacă această valoare există într-un tabel primar.

Dacă valoarea cheii se modifică în tabelul primar, datorită actualizării sau ștergerii rândului, atunci toate rândurile din tabelele secundare cu această cheie străină ar trebui actualizate sau șterse în consecință.

Cum se face un model relațional?

-Colectați datele

Datele necesare trebuie colectate pentru a fi stocate în baza de date. Aceste date sunt împărțite în diferite tabele.

Trebuie să fie ales un tip de date adecvat pentru fiecare coloană. De exemplu: numere întregi, numere între virgule, text, dată etc.

-Definirea cheilor primare

Pentru fiecare tabel, trebuie să fie aleasă o coloană (sau câteva coloane) ca cheie primară, care va identifica în mod unic fiecare rând din tabel. Cheia primară este de asemenea folosită pentru a face referire la alte tabele.

-Crearea relațiilor dintre tabele

O bază de date formată din tabele independente, fără legătură, are un scop redus.

Cel mai crucial aspect în proiectarea unei baze de date relaționale este identificarea relațiilor dintre tabele. Tipurile de relații sunt:

Unul la mulți

Într-o bază de date „Listing Class”, un profesor poate să predea zero sau mai multe clase, în timp ce o clasă este predată de un singur profesor. Acest tip de relație este cunoscut drept unul la mulți.

Această relație nu poate fi reprezentată într-un singur tabel. În baza de date «Lista claselor» puteți avea un tabel numit Profesori, care stochează informații despre profesori.

Pentru a stoca clasele predate de fiecare profesor, puteți crea coloane suplimentare, dar vă confruntați cu o problemă: câte coloane să creați.

Pe de altă parte, dacă aveți un tabel numit Classes, care stochează informații despre o clasă, puteți crea coloane suplimentare pentru a stoca informații despre profesor.

Cu toate acestea, din moment ce un profesor poate învăța multe clase, datele sale ar fi duplicate pe mai multe rânduri din tabelul Claselor.

Proiectează două tabele

Prin urmare, trebuie să proiectați două tabele: un tabel Classes pentru a stoca informații despre clase, cu Class_Id ca cheie primară și un tabel Teachers pentru a stoca informații despre profesori, cu Teacher_Id ca cheie primară.

Relația unu-la-mulți poate fi creată apoi prin stocarea cheii primare din tabelul Master (Master_Id) din tabelul Claselor, așa cum este ilustrat mai jos.

Coloana Master_Id din tabelul Classes este cunoscută sub numele de cheie străină sau cheie secundară.

Pentru fiecare valoare Master_Id din tabelul Master, pot exista zero sau mai multe rânduri în tabelul Classes. Pentru fiecare valoare Class_Id din tabelul Classes, există un singur rând în tabelul Teachers.

De la mulți la mulți

Într-o bază de date „Vânzarea produsului”, o comandă pentru clienți poate conține mai multe produse și un produs poate apărea în mai multe comenzi. Acest tip de relație este cunoscut ca mulți pentru mulți.

Puteți porni baza de date „Vânzări de produse” cu două tabele: Produse și Comenzi. Tabelul Produse conține informații despre produse, cu produsID ca cheie principală.

Pe de altă parte, tabelul Comenzi conține comenzile clientului, cu comanda ID ca cheie primară.

Nu puteți stoca produsele comandate în tabelul Comenzi, deoarece nu știți câte coloane de rezervat pentru produse. Nici comenzile nu pot fi stocate în tabelul Produse din același motiv.

Pentru a susține o relație de la mulți la mulți, trebuie să creați o a treia tabelă, cunoscută sub numele de tabelă de alăturare (OrderDetails), în care fiecare rând reprezintă un element dintr-o anumită ordine.

Pentru tabelul OrderDetails, cheia principală este formată din două coloane: orderID și productID, identificând în mod unic fiecare rând.

Coloanele OrderID și productID din tabelul OrderDetails sunt utilizate pentru a face referire la tabelele Comenzi și produse. Prin urmare, acestea sunt, de asemenea, chei străine în tabelul OrderDetails.

Unul câte unul

În baza de date „Vânzarea produselor”, un produs poate avea informații opționale, cum ar fi descrierea suplimentară și imaginea acestuia. Păstrarea ei în interiorul tabelului Produse ar genera o mulțime de spații goale.

Prin urmare, un alt tabel (ProductExtras) poate fi creat pentru a stoca datele opționale. O singură înregistrare va fi creată pentru produsele cu date opționale.

Cele două tabele, Products și ProductExtras, au o relație unu la unu. Pentru fiecare rând din tabelul Produse există maximum un rând în tabelul ProductExtras. Același produs ID trebuie utilizat ca cheie principală pentru ambele tabele.

Avantaj

Independență structurală

În modelul relațional al bazei de date, modificările la structura bazei de date nu afectează accesul la date.

Când este posibil să se facă modificări la structura bazei de date fără a afecta capacitatea DBMS de a accesa datele, se poate spune că sa obținut independența structurală.

Simplitatea conceptuală

Modelul relațional al bazei de date este chiar mai simplu conceptual decât modelul bazei de date ierarhice sau de rețea.

Întrucât modelul relațional de bază de date îl eliberează pe proiectant de detaliile stocării fizice a datelor, proiectanții se pot concentra asupra vizualizării logice a bazei de date.

Ușurință de proiectare, implementare, întreținere și utilizare

Modelul relațional al bazei de date realizează atât independența datelor, cât și independența structurii, ceea ce face proiectarea, menținerea, gestionarea și utilizarea bazei de date mult mai ușor decât celelalte modele.

Capacitate de interogare ad-hoc

Prezența unei capacități de interogare foarte puternice, flexibile și ușor de utilizat este unul dintre motivele principale ale popularității imense a modelului relațional de baze de date.

Limbajul de interogare al modelului relațional al bazei de date, numit limbaj de interogare structurat sau SQL, face căutările ad-hoc să devină o realitate. SQL este un limbaj de a patra generație (4GL).

Un 4GL permite utilizatorului să specifice ceea ce trebuie făcut, fără a specifica cum trebuie făcut. Astfel, cu SQL, utilizatorii pot specifica ce informații doresc și lasă detaliile despre cum să obțină informațiile în baza de date.

Dezavantaje

Cheltuieli hardware

Modelul relațional al bazei de date ascunde complexitatea implementării sale și detaliile stocării fizice a datelor utilizatorilor.

Pentru a face acest lucru, sistemele de baze de date relaționale au nevoie de computere cu dispozitive hardware și dispozitive de stocare a datelor mai puternice.

Prin urmare, RDBMS are nevoie de mașini puternice pentru a funcționa fără probleme. Cu toate acestea, întrucât puterea de procesare a computerelor moderne crește într-un ritm exponențial, nevoia de mai multă putere de procesare în scenariul actual nu mai este o problemă foarte mare.

Ușuritatea designului poate duce la un design deficitar

Baza de date relațională este ușor de proiectat și utilizat. Utilizatorii nu trebuie să cunoască detaliile complexe ale stocării fizice a datelor. Ei nu trebuie să știe cum datele sunt stocate efectiv pentru a le accesa.

Această ușurință de proiectare și utilizare poate duce la dezvoltarea și implementarea sistemelor de gestionare a bazelor de date prost proiectate. Deoarece baza de date este eficientă, aceste ineficiențe de proiectare nu vor apărea atunci când baza de date este proiectată și când există doar o cantitate mică de date.

Pe măsură ce baza de date crește, bazele de date slab proiectate vor încetini sistemul și vor duce la degradarea performanței și corupția datelor.

Fenomenul „insulelor informaționale”

Așa cum am menționat anterior, sistemele de baze de date relaționale sunt ușor de implementat și utilizat. Acest lucru va crea o situație în care prea multe persoane sau departamente își vor crea propriile baze de date și aplicații.

Aceste insule de informații vor împiedica integrarea informațiilor, care este esențială pentru buna funcționare eficientă a organizației.

Aceste baze de date individuale vor crea, de asemenea, probleme precum inconsistența datelor, duplicarea datelor, redundanța datelor etc.

Exemplu

Să presupunem o bază de date formată din tabele Furnizori, piese și expedieri. Structura tabelelor și unele înregistrări de mostre sunt următoarele:

Fiecare rând din tabelul Furnizori este identificat de un număr unic de furnizor (SNo), identificând în mod unic fiecare rând din tabel. De asemenea, fiecare parte are un număr de piesă unic (PNo).

Mai mult, nu poate exista mai mult de o expediere pentru o combinație furnizor / piesă dată în tabelul Expediții, deoarece această combinație este cheia principală a expedierilor, care servește ca uniune, deoarece este o relație de mai multe la multe.

Relația dintre tabelele Piese și Expediții este dată de faptul că câmpul PNo (număr de piesă) este comun și relația dintre furnizori și expedieri se produce prin faptul că câmpul SNo (numărul furnizorului) este comun.

Analizând tabelul Expediții este posibil să obțineți informații conform cărora în total 500 de nuci sunt trimise de la furnizorii Suneet și Ankit, câte 250.

În mod similar, 1.100 de șuruburi au fost livrate în total de la trei furnizori diferiți. 500 de șuruburi albastre au fost livrate de la furnizorul Suneet. Nu există expedieri cu șuruburi roșii.

Referințe

1. Wikipedia, enciclopedia gratuită (2019). Model relațional. Preluat de la: en.wikipedia.org.
2. Techopedia (2019). Modelul relațional. Preluat de la: plafonpedia.com.
3. Dinesh Thakur (2019). Modelul relațional. Note pentru computer. Luate de la: ecomputernotes.com.
4. Geeks for Geeks (2019). Modelul relațional. Luat de la: geeksforgeeks.org.
5. Universitatea Tehnologică Nanyang (2019). Un tutorial de pornire rapidă despre proiectarea relațională a bazelor de date. Luat de la: ntu.edu.sg.
6. Adrienne Watt (2019). Capitolul 7 Modelul relațional de date. Manuale deschise BC. Preluat de la: opentextbc.ca.
7. Toppr (2019). Baze de date relaționale și scheme. Luat de la: toppr.com.