Ce este o schemă relațională? Cum se creează o bază de date eficientă?
Nu există o singură structură de bază de date care să fie întotdeauna mai eficientă decât oricare alta. Acest lucru se datorează faptului că tipul și cantitatea de date stocate modifică structura optimă a bazei de date.
Cu toate acestea, există o mare diferență între a construi o bază de date optimizată pentru performanță față de una optimizată pentru volumul de date.
Utilizând schema relațională în MySQL, puteți crea o bază de date care este optimizată pentru volumul de date. Acest lucru este ideal în situațiile în care costul de stocare, procesare și memorie este prohibitiv.
Chiar dacă acesta nu mai este cazul pentru electronica standard, există încă o mulțime de situații în care programatorii și dezvoltatorii ar dori să utilizeze schema relațională. Deși stocarea, puterea de procesare și memoria sunt necostisitoare pentru utilizatorii de calculatoare convenționale, aceste lucruri sunt masiv de scumpe în lumea calculului cuantic.
De asemenea, o schemă relațională este importantă în bazele de date MySQL care se bazează pe relații pentru a genera sens. Fișele angajaților și dosarele academice, de exemplu, pot fi gândite cu ușurință ca rețele de relații descrise mai bine folosind o schemă relațională decât, de exemplu, bazele de date cheie-valoare sau grafice.
Schema relațională este elementul principal al bazei de date relaționale. Aceste baze de date sunt gestionate folosind un limbaj și o structură care este în concordanță cu logica de ordinul întâi. Aceasta permite gestionarea bazelor de date pe baza relațiilor dintre entități, ceea ce le face ușor de organizat în funcție de volum.
Schema relațională se referă la metadatele care descriu structura datelor dintr-un anumit domeniu. Este planul unei baze de date care descrie modul în care structura sa organizează datele în tabele.
De exemplu, dacă baza dvs. de date conține înregistrări ale angajaților pentru o întreprindere mare, atunci s-ar putea să aveți relații de entitate care descriu fiecare angajat ca o entitate puternică, astfel:
- Numele angajatului
- Numărul de identificare
- Adresa
- Set de competențe ale angajatului
- Data angajării
- Anii de serviciu
În acest exemplu, ați avea două atribute de date din schema relațională. În primul rând, ați avea atributul Employee (Angajat), care este cheia primară a tabelului (deoarece totul este legat de angajat) și un atribut Address (Adresă), care este un atribut compozit alcătuit din diferite elemente.
Atributul Adresă ar fi format din următoarele valori:
- Orașul
- Drumul
- Numărul adresei
- Codul poștal
Cunoscând acest lucru, sunteți gata să mapați o diagramă de relații între entități în schema relațională. Aceasta ar trebui să arate astfel:
- Angajat (nume, număr de identificare, număr de adresă, stradă, oraș, cod poștal, data angajării)
- Set de competențe al angajatului (număr de identificare, set de competențe)
Ar trebui să observați că anii de serviciu sunt excluși din această listă. Acest lucru se datorează faptului că este un atribut derivat care poate fi calculat prin scăderea datei de angajare din data curentă. Motivul pentru care Employee Skillset are propria sa schemă este că este un atribut cu mai multe valori.
Pentru schema relațională, fiecare tip de entitate devine propriul tabel, iar fiecare atribut cu o singură valoare este o coloană în cadrul acelui tabel. Atributele derivate pot fi ignorate în siguranță, în timp ce atributele cu mai multe valori devin tabele separate.
Metoda de conversie a tipurilor de entități slabe în schema relațională este similară procesului descris mai sus, cu excepția faptului că tipurile de entități slabe devin tabele proprii, iar cheia primară a entității puternice acționează ca o cheie externă în tabel.
Aceasta înseamnă că pentru entitatea puternică Angajat, veți crea o cheie primară compozită formată din cheia externă Dependent și cheia entității slabe în sine. Aceasta ar face ca schema să arate astfel:
- Employee (Name, ID Number, Address Number, Street, City, Zip Code, Hiring Date)
- Dependent (Employee, Dependent ID, Name, Address)
Corelația aici este între ID Number din tabelul Employee și elementul Employee din tabelul Dependent.
Cu această muncă făcută, sunteți gata să începeți să convertiți relațiile. Pentru a face acest lucru este necesară înțelegerea cardinalității și a gradului fiecărei relații.
- Există trei cardinalități posibile – 1:1, 1:M, 1:N
- Există trei grade posibile – unitar, binar și ternar.
Prelucrând mai departe cu exemplul de mai sus, Angajat ar putea fi combinat cu un nou tabel Departament pentru a forma o relație binară 1:1. Dacă angajatul gestionează un anumit departament, atunci el sau ea poate fi descris ca participant parțial, în timp ce departamentul ar fi descris ca participant total.
Schema relațională ar arăta astfel:
- Employee (Name, ID Number, Address Number, Street, City, Zip Code, Hiring Date)
- Department (Manager ID Number, Department ID, Name, Address)
În acest caz, cheia primară a participantului parțial devine cheia externă a participantului total. Numărul de identificare al managerului se corelează cu numărul de identificare al angajatului corespunzător.
Aceasta prezintă o parte importantă a creării schemei relaționale. Cheia primară a oricăruia dintre participanți într-o relație binară 1:1 poate deveni o cheie străină în cealaltă. Un alt mod de a descrie relația de mai sus ar fi folosind Manages ca cheie externă în cadrul Employee, în corelație cu cheia primară Department ID în cadrul Department.
Un exemplu de relație binară 1:N ar fi cea dintre un profesor care predă o materie. Într-o anumită sală de clasă, profesorii pot preda mai mult de o Disciplină unei varietăți de elevi, dar toate Disciplinele au aceeași relație cu profesorul.
În relația binară 1:1 de mai sus, fiecare departament avea un manager unic. Cu această relație binară 1:N, un număr variabil de studenți pot împărți același profesor. Cheia primară a profesorului ar fi ID-ul profesorului, care s-ar corela cu cheia externă a subiectului, sub profesor.
Pentru a descrie o relație binară M:N, imaginați-vă un student care se înscrie la un curs. Creați un tabel nou care descrie Student și un altul care descrie Course. Ambele tabele sunt legate între ele prin actul de înscriere și ambele au chei străine.
- Cheia străină pentru Student este ID-ul Studentului.
- Cheia străină pentru Curs este ID-ul Cursului.
Cheia primară a noului tabel este combinația cheilor străine ale fiecărei entități. Ați putea să o descrieți ca fiind (Student ID, Course ID). Aceasta este o schemă relațională binară unică M:N care leagă studenții individuali de cursuri.
Acest lucru funcționează deoarece ID-urile sunt, prin natura lor, create cu scopul de a fi chei străine în bazele de date relaționale.
Puteți utiliza o schemă relațională pentru a descrie relațiile de auto-referință. De exemplu, doi angajați care sunt căsătoriți unul cu celălalt ar putea prezenta cheia externă Spouse. Pentru ambele chei străine ale acestor angajați, referința va fi la ID-ul de angajat al celuilalt angajat, care este cheia primară a tabelului respectiv al fiecărui angajat.
Acest lucru funcționează și în schemele de relații cu o cardinalitate 1:N. Câmpul cheie primară ar deveni el însuși cheia externă a aceluiași tabel în acest caz. Acest lucru este același lucru cu o schemă unară 1:1.
De exemplu, un angajat care este managerul unui subordonat poate avea manager ca cheie externă. În acest caz, ID-ul angajatului ar fi cheia primară în același tabel.
Autoreferențierea unei relații M:N necesită două tabele. Una trebuie să reprezinte entitatea în cauză și cealaltă trebuie să reprezinte relația M:N.
Imaginați-vă un angajat care este responsabil pentru garantarea calității unui anumit produs sau serviciu. Această relație ar trebui să includă atât Garantul, cât și Beneficiarul ca chei străine care se combină pentru a se corela cu ID-ul angajatului din tabelul Angajat. Atât Garantul, cât și Beneficiarul ar acționa ca chei primare și străine în cadrul tabelului nou creat din schema relațională.
În timp ce relațiile binare și unare sunt simplu de descris folosind schema relațională cu unul sau două tabele. Tabelele ternare necesită un al treilea tabel nou.
Cheia primară a acestui tabel nou este formată din cheia externă a fiecărei entități participante, adunate împreună. Acest lucru înseamnă că noul tabel trebuie să conțină trei chei străine cu care să se coreleze.
De exemplu, relația dintre un medic și pacientul său constă, de fapt, din trei entități: Doctorul, pacientul și medicamentul. Pentru a descrie în mod corespunzător această relație ca o schemă relațională, trebuie să atribuiți chei străine fiecăreia dintre aceste entități și să le corelați cu un nou tabel intitulat Prescripție.
Acesta este un mod simplu de a vizualiza modul în care funcționează un tabel ternar. Cheia primară a tabelului Prescription nou creat este (Doctor ID, Patient ID, Drug ID). Orice schemă care nu include aceste trei date importante lipsește o parte importantă a puzzle-ului.
Această abordare ar permite unui manager de bază de date să creeze o arhivă organizată de rețete care să contabilizeze tipuri specifice de medicamente, corelate imediat cu numele pacienților care le folosesc și să ofere numele medicilor care le-au prescris.
Pentru a fi complet, ați putea dori să adăugați data de expirare la tabelul Medicament, astfel încât aceste date să fie disponibile în cadrul matricei principale. Puteți adăuga Data următoarei programări sau Data reîmprospătării la tabelul Rețete. În mod logic, ați dori să adăugați Data nașterii, Adresa și alte date relaționale importante la tabelul Patient.
Toate aceste instrumente se combină pentru a face posibilă crearea de baze de date orientate pe relații în MySQL. Puteți exersa crearea propriilor baze de date MySQL online cu orice browser folosind SQLDBM.
.