Modelul logic descrie conceptele domeniului, interrelația lor, precum și restricțiile asupra datelor impuse de aria de studiu.
Exemple de concepte sunt "angajat", "departament", "proiect", "salariu". Exemple de interacțiuni între concepte - "angajatul este listat exact într-un departament", "un angajat poate executa mai multe proiecte", "câțiva angajați pot lucra la un proiect". Exemple de restricții sunt "vârsta angajatului nu mai mică de 16 ani și nu mai mult de 60 de ani".
Un model de date logic este prototipul inițial al unei baze de date viitoare. Modelul logic este construit în termeni de unități de informații, dar fără a se lega de un anumit DBMS. Mai mult, modelul de date logic nu trebuie să fie exprimat prin intermediul modelului de date relațional. Instrumentul principal pentru dezvoltarea unui model de date logice este în prezent diferite variante ale diagramelor ER (entități-relație, diagrame entitate-relație).
Unul și același model ER poate fi transformat atât într-un model de date relațional, cât și într-un model de date pentru DBMS ierarhic și de rețea sau într-un model de date post-relațional. Deciziile luate la nivelul anterior, atunci când dezvoltăm un model de domeniu, definesc anumite limite în care se poate dezvolta un model logic de date, în cadrul acelorași limite pot fi făcute diferite soluții. De exemplu, modelul domeniului de activitate al contabilității depozitului conține conceptele de "depozit", "conosament", "bunuri". În dezvoltarea unui model relațional adecvat trebuie să fie folosit acești termeni, dar o varietate de moduri de a pune în aplicare aici o mulțime - puteți crea o relație, care va fi prezent ca un „depozit“ atribut, „proiect de lege“, „bunuri“, și este posibil să se creeze trei relații distincte, unul pentru fiecare concept.
La elaborarea unui model de date logic, apar întrebări: relațiile sunt bine proiectate? Acestea reflectă corect modelul de domeniu și, în consecință, domeniul în sine?
Pentru a evalua calitatea deciziilor luate la nivelul modelului de date logic, este necesar să se formuleze anumite criterii de calitate în ceea ce privește modelul fizic și punerea în aplicare specifice și a vedea modul în care diferite decizii luate în timpul simulării logica, afectează calitatea modelului și baza de date performanțele fizice.
Există o mulțime de astfel de criterii și alegerea lor este arbitrară. Unele dintre aceste criterii sunt importante în ceea ce privește obținerea unei baze de date de calitate: caracterul adecvat al domeniului bazei de date, ușurința de dezvoltare și întreținere a bazei de date, viteza operațiunilor de actualizare a datelor (insert, update, șterge tupluri), viteza operațiunilor de recuperare a datelor.
Baza de date trebuie să reflecte în mod corespunzător aria subiectului. Aceasta înseamnă că trebuie îndeplinite următoarele condiții.
1. Starea bazei de date în fiecare moment trebuie să corespundă stării domeniului.
2. Schimbarea stării domeniului ar trebui să conducă la o modificare corespunzătoare a stării bazei de date.
3. Constrângerile de domeniu reflectate în modelul de domeniu ar trebui să se reflecte într-un anumit mod și să fie contabilizate în baza de date.
Aproape orice bază de date, cu excepția bazelor de date complet elementare, conține o anumită cantitate de cod de program sub formă de declanșatori și proceduri stocate.
Procedurile stocate sunt proceduri și funcții care sunt stocate direct în bază de date într-o formă compilată și care pot fi pornite de utilizatori sau de aplicații care lucrează cu baza de date. Scopul principal al procedurilor stocate este implementarea proceselor de afaceri în domeniu.
Declanșatoarele sunt proceduri stocate asociate anumitor evenimente care apar în timp ce baza de date este în desfășurare. Astfel de evenimente sunt operațiile de inserare, actualizare și ștergere a rândurilor de tabele. Dacă un anumit declanșator este definit în baza de date, el este pornit automat automat ori de câte ori apare un eveniment cu care acest asociat este asociat. Declanșatorul este declanșat indiferent de utilizatori și în ce mod a declanșat evenimentul care a declanșat declanșatorul. Astfel, scopul principal al declanșatorilor este menținerea automată a integrității bazei de date.
Evident, cu cât mai mult cod de program sub formă de declanșatori și proceduri stocate conține o bază de date, cu atât mai dificilă este dezvoltarea și menținerea acesteia.
La nivelul modelelor logice se determină relațiile relaționale și atributele acestor relații. La acest nivel, puteți defini toate structurile fizice de stocare (indexuri, hașuri, etc.). Singurul lucru pe care îl puteți gestiona este distribuirea atributelor în diferite relații.
Puteți descrie o mică relație cu un număr mare de atribute sau puteți forma un număr mare de relații, fiecare dintre acestea având câteva atribute. Astfel, este necesar să încercăm să răspundem la întrebarea dacă numărul de relații și numărul de atribute din relație afectează viteza la care sunt efectuate operațiile de actualizare a datelor. O astfel de declarație nu este suficient de corectă, deoarece viteza operațiunilor bazei de date depinde de implementarea fizică a bazei de date. Cu toate acestea, este recomandabil să evaluăm calitativ această influență cu aceleași abordări ale modelării fizice.
Principalele operațiuni care modifică starea bazei de date sunt operațiile de inserare, actualizare și ștergere a înregistrărilor. În bazele de date care necesită schimbări constante (inventar, vânzări de bilete etc.), performanța este determinată de viteza cu care se efectuează un număr mare de operațiuni mici de inserare, actualizare și ștergere.
În mod obișnuit, inserarea unei înregistrări se face într-una din paginile de memorie gratuite alocate pentru acest tabel. DBMS stochează constant informații despre disponibilitatea și locația paginilor libere. Dacă nu se creează indici pentru tabel, operația de inserare este efectuată la aproape aceeași viteză, indiferent de dimensiunea tabelului și numărul de atribute din tabel. Dacă în tabel există indicii, indicele trebuie să fie reconstruit în timpul operației de inserare a insertului. Astfel, viteza operației inserției scade cu creșterea numărului de indici din tabel și depinde foarte puțin de numărul de rânduri din tabel.
Pentru a actualiza și a șterge înregistrările din tabel, înainte de a actualiza sau șterge înregistrarea, trebuie să o găsiți. Dacă tabela nu este indexată, singura modalitate de căutare este scanarea secvențială a tabelului în căutarea înregistrării dorite. În acest caz, viteza operațiilor de actualizare și ștergere crește semnificativ cu numărul de înregistrări din tabel și nu depinde de numărul de atribute. Dar, de fapt, mesele neindexate sunt aproape niciodată folosite. Pentru fiecare tabel, unul sau mai mulți indicatori care corespund cheilor potențiale sunt de obicei declarați. Folosind acești indexuri, căutarea unei înregistrări este foarte rapidă și este practic independentă de numărul de rânduri și atribute din tabel (deși, desigur, există o anumită dependență). Dacă sunt declarate mai mulți indici pentru tabel, atunci în timpul operațiilor de actualizare și ștergere, acești indici trebuie să fie reconstruiți, ceea ce necesită timp suplimentar. Astfel, viteza operațiilor de actualizare și ștergere scade și cu numărul de indici din tabel și depinde foarte puțin de numărul de rânduri din tabel.
Unul dintre scopurile bazei de date este furnizarea de informații utilizatorilor. Informația este extrasă din baza de date relațională utilizând instrucțiunea SQL-SELECT. Una dintre cele mai costisitoare operațiuni atunci când executați instrucțiunea SELECT este operația de conectare a tabelelor. Astfel, mai multe relații interrelaționate au fost create în cursul modelării logice, cu atât mai probabil că atunci când interogările sunt executate, aceste relații vor fi conectate și, în consecință, cu cât vor fi executate mai lent interogările. Astfel, creșterea numărului de relații duce la încetinirea performanței operațiunilor de eșantionare a datelor, mai ales dacă cererile nu sunt cunoscute în avans.
Articole similare
Trimiteți-le prietenilor: