2.1. Design conceptual
Proiectarea bazei de date se realizează în trei etape:
- design conceptual;
- design logic;
- design fizic.
Scopul fazei de proiectare conceptuală este de a crea un model conceptual de date bazat pe ideile utilizatorilor despre domeniul subiectului. Pentru a-l realiza, se efectuează o serie de proceduri secvenţiale. Un exemplu de schemă de entitate (conceptuală):
![](https://cdn.codegym.cc/images/article/f8e01a34-8cc9-49cd-a834-2941721c4c08/800.jpeg)
1. Definirea entităților și documentația acestora. Pentru a identifica entități, sunt definite obiecte care există independent de altele. Astfel de obiecte sunt entități. Fiecare entitate primește un nume semnificativ pe care utilizatorii îl pot înțelege. Numele și descrierile entităților sunt introduse în dicționarul de date. Dacă este posibil, este setat numărul așteptat de instanțe ale fiecărei entități.
2. Determinarea relațiilor dintre entități și documentația acestora. Sunt definite doar acele relații între entități care sunt necesare pentru a satisface cerințele de proiectare a bazei de date. Tipul fiecăruia este stabilit. Clasa de membru de entități este dezvăluită. Legăturilor li se atribuie nume semnificative exprimate prin verbe. O descriere detaliată a fiecărei conexiuni, indicând tipul acesteia și clasa de apartenență a entităților care participă la conexiune, este introdusă în dicționarul de date.
3. Crearea unui model ER al domeniului de studiu. Diagramele ER sunt folosite pentru a reprezenta entitățile și relațiile dintre ele. Pe baza acestora, este creată o singură imagine vizuală a domeniului subiectului modelat - modelul ER al zonei subiectului.
4. Definirea atributelor și documentarea acestora. Sunt dezvăluite toate atributele care descriu entitățile modelului ER creat. Fiecare atribut primește un nume semnificativ pe care utilizatorii îl pot înțelege. Următoarele informații sunt stocate în dicționarul de date pentru fiecare atribut:
- numele și descrierea atributului;
- tipul și dimensiunea valorilor;
- valoarea implicită pentru atribut (dacă există);
- dacă atributul poate avea valori NULL;
- dacă atributul este compus și, dacă da, din ce atribute simple constă. De exemplu, atributul „Numele complet al clientului” poate consta din atribute simple „Nume”, „Prenumele”, „Patronimic”, sau poate fi simplu, care conține valori unice, cum ar fi „Sidorsky Evgeniy Mikhailovich”. Dacă utilizatorul nu are nevoie de acces la elementele individuale ale „Nume”, atunci atributul este prezentat ca simplu;
- dacă atributul este calculat și, dacă da, cum sunt calculate valorile acestuia.
5. Definirea valorilor atributelor și documentația acestora. Pentru fiecare atribut al unei entități care participă la modelul ER, se determină un set de valori valide și i se atribuie un nume. De exemplu, atributul „Tip cont” poate avea doar valorile „depozit”, „actual”, „la cerere”, „cont de card”. Intrările din dicționarul de date legate de atribute sunt actualizate cu numele seturilor de valori ale atributelor.
6. Definirea cheilor primare pentru entități și documentația acestora. Acest pas este ghidat de definirea unei chei primare - ca atribut sau set de atribute ale unei entități care permite identificarea unică a instanțelor sale. Informațiile cheie primare sunt plasate în dicționarul de date.
7. Discuție despre modelul conceptual de date cu utilizatorii finali. Modelul conceptual de date este reprezentat de un model ER cu documentația însoțitoare care conține o descriere a modelului de date dezvoltat. Dacă se găsesc inconsecvențe în domeniu, atunci se fac modificări la model până când utilizatorii confirmă că modelul propus de ei reflectă în mod adecvat opiniile lor personale.
2.2 Proiectare logică
Scopul etapei de proiectare logică este de a transforma modelul conceptual bazat pe modelul de date selectat într-un model logic care este independent de caracteristicile SGBD utilizate ulterior pentru implementarea fizică a bazei de date. Pentru a-l realiza, se efectuează următoarele proceduri.
Un exemplu de schemă de bază de date logică.
![](https://cdn.codegym.cc/images/article/1909a097-a8bd-47be-b164-6fb55d1af2b0/1024.jpeg)
1. Alegerea unui model de date. Cel mai adesea, un model de date relaționale este ales datorită clarității prezentării tabelare a datelor și a comodității de a lucra cu acestea.
2. Definirea unui set de tabele pe baza modelului ER și documentarea acestora. Se creează un tabel pentru fiecare entitate a modelului ER. Numele entității este numele tabelului. Relațiile dintre tabele sunt stabilite prin mecanismul cheilor primare și străine. Sunt documentate structurile tabelelor și relațiile stabilite între ele.
3. Normalizarea tabelelor. Pentru a efectua corect normalizarea, designerul trebuie să înțeleagă profund semantica și modelele de utilizare ale datelor. La acest pas, el verifică corectitudinea structurii tabelelor create în pasul anterior aplicând procedura de normalizare acestora. Constă în aducerea fiecărei mese la cel puțin a 3-a NF. Ca urmare a normalizării, se obține un design foarte flexibil al bazei de date, ceea ce facilitează realizarea extensiilor necesare acesteia.
4. Verificarea modelului logic de date pentru posibilitatea efectuarii tuturor tranzactiilor furnizate de utilizatori. O tranzacție este un set de acțiuni efectuate de un utilizator individual sau de un program de aplicație pentru a modifica conținutul unei baze de date. Deci, un exemplu de tranzacție în proiectul BANK poate fi transferul dreptului de administrare a conturilor unui anumit client către un alt client. În acest caz, mai multe modificări vor trebui făcute simultan în baza de date. Dacă un computer se blochează în timpul unei tranzacții, baza de date va fi într-o stare inconsistentă, deoarece unele modificări au fost deja făcute, iar altele nu. Prin urmare, toate modificările parțiale trebuie anulate pentru a readuce baza de date la starea anterioară consecventă.
Lista tranzacțiilor este determinată de acțiunile utilizatorilor din domeniul subiectului. Folosind modelul ER, dicționarul de date și relațiile stabilite între cheile primare și străine, se încearcă efectuarea manuală a tuturor operațiunilor necesare de acces la date. Dacă orice operațiune manuală eșuează, atunci modelul de date logic compilat este inadecvat și conține erori care trebuie eliminate. Poate că sunt legate de un decalaj în modelul unei entități, relații sau atribute.
5. Determinarea cerințelor de suport pentru integritatea datelor și documentația acestora. Aceste cerințe sunt restricții care sunt puse în aplicare pentru a preveni introducerea datelor în conflict în baza de date. La acest pas, problemele de integritate a datelor sunt acoperite fără a ține cont de aspectele specifice ale implementării acesteia. Trebuie luate în considerare următoarele tipuri de restricții:
- datele solicitate. Aflarea dacă există atribute care nu pot avea valori NULL;
- restricții asupra valorilor atributelor. Sunt definite valori valide pentru atribute;
- integritatea entității. Se realizează dacă cheia primară a entității nu conține valori NULL;
- integritate referenţială. Se înțelege că valoarea cheii străine trebuie să fie prezentă în cheia primară a unuia dintre rândurile de tabel pentru entitatea părinte;
- restricții impuse de regulile de afaceri. De exemplu, în cazul proiectului BANCĂ, poate fi adoptată o regulă care interzice clientului să gestioneze, să zicem, mai mult de trei conturi.
Informațiile despre toate constrângerile de integritate a datelor stabilite sunt plasate în dicționarul de date.
6. Crearea versiunii finale a modelului de date logice și discuție cu utilizatorii. Acest pas pregătește versiunea finală a modelului ER, care reprezintă modelul de date logic. Modelul în sine și documentația actualizată, inclusiv dicționarul de date și schema de legături cu tabelul relațional, sunt prezentate pentru revizuire și analiză de către utilizatori, care trebuie să se asigure că reprezintă cu acuratețe domeniul subiectului.
2.3. Design fizic
Scopul etapei de proiectare fizică este de a descrie o implementare specifică a unei baze de date aflate în memoria externă a unui computer. Aceasta este o descriere a structurii de stocare a datelor și a metodelor eficiente de accesare a datelor bazei de date. În designul logic, ei răspund la întrebarea - ce trebuie făcut, iar în designul fizic - se alege o modalitate de a face acest lucru. Procedurile de proiectare fizică sunt după cum urmează.
1. Proiectarea tabelelor bazei de date utilizând SGBD selectat. Un SGBD relațional este selectat pentru a fi utilizat pentru a crea o bază de date găzduită pe suportul mașinii. Funcționalitatea sa pentru proiectarea meselor este profund studiată. Apoi se realizează proiectarea tabelelor și schema conexiunii acestora în mediul DBMS. Proiectul de bază de date pregătit este descris în documentația însoțitoare.
2. Implementarea regulilor de afaceri în mediul SGBD selectat. Actualizarea informațiilor din tabele poate fi limitată de regulile de afaceri. Modul în care sunt implementate depinde de SGBD-ul ales. Unele sisteme de implementare a cerințelor domeniului de studiu oferă mai multe caracteristici, altele mai puține. În unele sisteme, nu există deloc suport pentru implementarea regulilor de afaceri. În acest caz, aplicațiile sunt dezvoltate pentru a le implementa limitările.
Toate deciziile luate în legătură cu implementarea regulilor de afaceri ale domeniului sunt descrise în detaliu în documentația însoțitoare.
3. Proiectarea organizării fizice a bazei de date. Acest pas selectează cea mai bună organizare a fișierelor pentru tabele. Sunt identificate tranzacțiile care vor fi efectuate în baza de date în curs de proiectare, iar cele mai importante dintre ele sunt evidențiate. Debitul tranzacțiilor este analizat - numărul de tranzacții care pot fi procesate într-un interval de timp dat, iar timpul de răspuns - perioada de timp necesară pentru a finaliza o tranzacție. Ei se străduiesc să mărească debitul tranzacțiilor și să reducă timpul de răspuns.
Pe baza acestor indicatori se iau decizii de optimizare a performanței bazei de date prin definirea de indici în tabele care accelerează selecția datelor din baza de date, sau prin reducerea cerințelor pentru nivelul de normalizare a tabelelor. Spațiul pe disc necesar pentru a găzdui baza de date creată este estimat. Străduiți-vă să o minimizați.
Deciziile luate cu privire la aspectele de mai sus sunt documentate.
4. Dezvoltarea unei strategii de protectie a bazei de date. Baza de date este o resursă corporativă valoroasă și se acordă multă atenție protecției acesteia. Pentru a face acest lucru, designerii trebuie să aibă o înțelegere completă și clară a tuturor protecțiilor oferite de SGBD selectat.
5. Organizarea monitorizării funcționării bazei de date și ajustarea acesteia. După realizarea proiectului fizic al bazei de date se organizează monitorizarea continuă a funcționării acesteia. Informațiile rezultate despre nivelul de performanță al bazei de date sunt utilizate pentru reglarea acesteia. Pentru aceasta sunt implicate și mijloacele SGBD selectate.
Deciziile de a face orice modificări la o bază de date funcțională trebuie luate în considerare și cântărite temeinic.