Proiectare logică
În metodologia propusă de proiectare a bazei de date, întregul proces de dezvoltare este împărțit în trei etape principale: conceptual, logic și fizic. Proiectarea bazelor de date logice este procesul de construire a unui model general de informații al unei întreprinderi, bazat pe modele individuale de date ale utilizatorilor, care este independent de caracteristicile DBMS utilizate în mod real și de alte condiții fizice.
În etapa anterioară, a fost obținut un set de modele locale de date conceptuale, care reflectă viziunea utilizatorului asupra mediului obiect. Cu toate acestea, aceste modele pot conține anumite structuri de date, a căror implementare în tipurile obișnuite de DBMS va fi dificilă. La acest nivel, aceste structuri de date sunt transformate într-o formă care nu cauzează dificultăți în implementarea lor în mediul de funcționare al DBMS-ului existent. Poate urma observația că aceste acțiuni nu sunt un element al designului bazelor de date logice. Cu toate acestea, procedura propusă obligă dezvoltatorul să se gândească mai atent la semnificația fiecărui element de date, ceea ce are un efect pozitiv asupra corectitudinii afișării caracteristicilor unei întreprinderi în model. În acest stadiu, se fac următoarele acțiuni:
1. Demontarea legăturilor de tip M: N.
2. Eliminarea legăturilor complexe.
3. Eliminarea relațiilor recursive.
4. Ștergerea legăturilor cu atributele.
5. Eliminați mai multe atribute.
6. Verificați din nou legăturile tip 1: 1.
7. Înlăturarea legăturilor redundante.
1. Demontarea legăturilor de tip M: N. Dacă există relații M: N ("multe până la multe") în modelul conceptual, ele trebuie eliminate prin definirea unei entități intermediare. Conectarea tipului M: N este înlocuită cu două legături de tip 1: M. înființat cu entitatea nou creată.
R es. 7. Conexiuni de tip 1. M
2. Eliminarea legăturilor complexe. Complex este conexiunea existentă între trei sau mai multe tipuri de entități. Dacă există o relație complexă în modelul conceptual, ar trebui eliminată cu ajutorul unei entități intermediare. O conexiune complexă este înlocuită de numărul necesar de legături binare de tip 1: M. stabilite cu entitatea nou creată. De exemplu, legătura triplă "Lettings" (reprezentată de un romb) reflectă relațiile existente între angajatul de leasing al companiei, terenul și chiriașul (figura 8).
^
Fig. 8. Comunicarea complicată
Această relație complexă poate fi simplificată prin introducerea unei entități noi și definirea relațiilor binare dintre ea și fiecare dintre entitățile originale ale unei conexiuni complexe.
În exemplul nostru, linkul "Let's lease" poate fi eliminat prin introducerea unei noi entități slab cu acordul de nume. Entitatea nou creată va fi asociată entităților originale cu trei noi linkuri binare (Figura 9).
^
Fig. 9. Facilitarea comunicării complexe
3. Eliminarea relațiilor recursive. Recursive sunt acele legături în care esența unui anumit tip interacționează cu ea însăși. Dacă modelul conceptual conține relații recursive, ele trebuie eliminate prin definirea unei anumite entități intermediare. De exemplu, pentru a afișa situația atunci când un angajat este responsabil de un grup de alți angajați, se poate stabili o relație unu-la-mulți (1: M).
^ 4. Ștergerea legăturilor cu atributele. Dacă există legături în modelul conceptual care au atribute proprii, ele trebuie transformate prin crearea unei entități noi. De exemplu, luați în considerare situația în care este necesar să stabiliți numărul de ore lucrate de personalul temporar al fiecărei ramuri a întreprinderii. Conexiunea "Lucrări în" are un atribut numit "ore petrecute". Conversia relației "Lucrări în" cu o entitate numită "Distribuție după departament", care atribuie atributul "Ore lucrate" și apoi creează două linkuri noi de tipul 1: M.
6. Verificați legăturile de tip 1: 1. În procesul de definire a entităților, s-ar putea crea două entități diferite care reprezintă de fapt același obiect în domeniul aplicației aplicației. De exemplu, s-ar putea crea două entități "Departament" și "Departament", care reprezintă de fapt același tip de obiect. Cu alte cuvinte, numele "Departamentul" este sinonim cu numele "Departamentul". Într-un astfel de caz, trebuie să le unificați pe acestea. Dacă cheile primare ale entităților care fac obiectul unei fuziuni sunt diferite, selectați una dintre ele ca principală și specificați cealaltă ca o cheie alternativă.
^ 7. Înlăturarea legăturilor redundante. Comunicarea este redundantă dacă aceleași informații pot fi obținute nu numai prin intermediul acesteia, ci și printr-un alt link. Trebuie să încercați întotdeauna să creați modele de date minime și, prin urmare, în cazul în care comunicarea redundantă nu este clar necesară, ar trebui eliminată. Este destul de simplu să se stabilească faptul că există mai mult de o legătură între două entități. Cu toate acestea, aceasta nu înseamnă că unul dintre cele două legături este în mod necesar redundant, deoarece ambele pot reprezenta diferitele asociații care există de fapt în organizație.
La eliminarea redundanței, indicatorii de timp sunt foarte importanți. De exemplu, luați în considerare situația când este necesar să simulați conexiunile dintre entitățile "Om", "Femeie" și "Copil". Este evident că există două căi de acces între entitățile "Om" și "Copil": una prin legătura directă "Este tatăl" și cealaltă prin legăturile "Căsătorit cu" și "Este mama". La prima vedere, se pare că conexiunea "Este un tată" este redundantă. Cu toate acestea, această declarație poate fi eronată din două motive. În primul rând, tatăl poate avea copii din căsătoria anterioară și modelăm doar căsătoria curentă a tatălui (printr-o legătură 1: 1). În al doilea rând, tatăl și mama nu pot fi căsătoriți deloc sau tatăl poate fi căsătorit cu o femeie care nu este mama copilului (sau mama poate fi căsătorită cu un bărbat care nu este tatăl copilului). Prin urmare, toate relațiile existente nu pot fi modelate fără a folosi o relație de tip "Este un tată" (Figura 10).
^
Design fizic
Faza care urmează proiectării logice se numește faza de proiectare fizică. Proiectarea logică nu ia în considerare funcționalitatea specifică a bazei de date țintă și a programelor de aplicații, dar sunt luate în considerare caracteristicile modelului de stocare selectat. Rezultatul designului logic este un model global de date logice și un set de documente de însoțire care îl descriu. Împreună, aceste rezultate reprezintă informațiile inițiale pentru faza de proiectare fizică a bazei de date și oferă dezvoltatorului său tot ceea ce este necesar pentru a lua decizii care vizează maximizarea eficacității proiectului creat.
Din punct de vedere figurativ, în cazul designului logic, dezvoltatorul se concentrează asupra a ceea ce trebuie făcut, în timp ce în proiectarea fizică el caută modalități de a face acest lucru. Fiecare caz necesită aptitudini diferite. Astfel, specialistul în proiectarea bazelor de date fizice ar trebui să înțeleagă în mod clar modul în care un anumit DBMS funcționează într-un sistem informatic, precum și cunoaște toate funcționalitățile DBMS-ului țintă. Deoarece funcționalitatea diferitelor DBMS este destul de diferită una de alta, designul fizic este întotdeauna în strânsă legătură cu caracteristicile unui anumit sistem ales. Cu toate acestea, faza de proiectare fizică a bazei de date nu este complet izolată de celelalte - de regulă, există un feedback constant între designul logic și fizic, care adesea cuprinde și dezvoltă aplicații personalizate. De exemplu, deciziile luate la etapa de proiectare fizică pentru a îmbunătăți performanța sistemului pot afecta structura logicii sale.
Metodologia de proiectare a bazelor de date fizice include patru etape principale:
1. Dezvoltarea tabelelor de baze de date și instalarea constrângerilor de integritate a datelor necesare.
2. Alegerea unei scheme de stocare a datelor și definirea metodelor de accesare a tabelelor bazei de date. De regulă, fiecare SGBD oferă mai multe variante alternative ale schemei de stocare a datelor. Singurele excepții sunt singurele sisteme de baze de date pentru platforma IBM PC, în care schema de stocare fixă este cea mai des utilizată. Din punctul de vedere al utilizatorului, organizarea structurii interne de stocare a datelor introduse în tabelele de date trebuie să fie complet transparentă - utilizatorul ar trebui să poată accesa orice tabel și liniile sale individuale fără a fi nevoie să specificați un mod de stocare a acestor date. Acest lucru înseamnă că DBMS ar trebui să furnizeze o independență totală a stocării fizice a datelor din organizarea lor logică. Numai în acest caz introducerea modificărilor în organizarea fizică a bazei de date nu va avea niciun efect asupra activității utilizatorilor. Cartografierea modelului de date logice la structura organizării fizice este determinată de schema internă a bazei de date.
3. Proiectarea unui sistem de protecție a bazei de date împotriva accesului neautorizat. Aceasta include luarea deciziilor cu privire la modul de implementare a fiecărui model logic local de date, precum și măsurile de control al accesului la tabelele individuale de baze de date.
4. Organizarea proceselor de monitorizare a sistemului creat, a cărui sarcină este identificarea și eliminarea oricăror probleme legate de performanța aplicațiilor și care rezultă din caracteristicile proiectului. Aici sunt implementate cerințe noi și în schimbare.
1. Fișiere de date. Sunt destinate pentru stocarea informațiilor care figurează în tabelele unei baze de date. În plus, aceste fișiere conțin, de asemenea, proceduri, restricții, declanșatoare, indici și alte informații;
Orice bază de date trebuie să conțină cel puțin un fișier de date și un fișier jurnal de tranzacții, adică numărul minim de fișiere care alcătuiesc baza de date este 2. Dacă este necesar, administratorul poate adăuga fișiere de date noi sau fișiere de jurnalizare a tranzacțiilor.
^ Există două tipuri de fișiere de date:
- Fișier primar (fișier principal sau principal). Fiecare bază de date are un singur fișier principal. Dacă baza de date include doar un fișier de date, atunci acest fișier va fi unul principal. Fișierul principal este destinat stocării tuturor tabelelor de sistem prezente în orice bază de date. Fișierul principal stochează informații despre structura bazei de date, obiectele create în ea, parametrii fișierelor suplimentare și fișierele log ale tranzacțiilor. În mod implicit, fișierul bazei de date principale este atribuit extensiei MDF (Master Data File);
- Fișier secundar (fișier secundar sau opțional). Spre deosebire de fișierul principal, baza de date poate conține multe fișiere suplimentare sau nu le conține deloc. Fișierele suplimentare pot stoca numai informații despre utilizatori. Stocarea informațiilor despre sistem nu este permisă. În timpul funcționării bazei de date, administratorul poate adăuga fișiere noi sau le poate șterge pe cele existente.
Fișierele jurnalului de tranzacții sunt de un singur tip - fișier Jurnal de tranzacții (fișier jurnal de tranzacții), care este utilizat pentru a stoca jurnalul de tranzacții. Trebuie să existe cel puțin un fișier jurnal de tranzacții în baza de date. Pentru a accelera procesarea tranzacțiilor, puteți utiliza mai multe jurnale de tranzacții situate pe diferite discuri fizice.
Articole similare
Trimiteți-le prietenilor: