Structura unui subd. modern. Arhitectura bazei de date: concept, definiție, niveluri
Conform arhitecturii lor, SGBD-urile sunt împărțite în unul, două și trei niveluri [ 191. Într-o arhitectură cu un singur nivel (Fig. 1.11, a) este utilizată o singură legătură (client), care oferă logica necesară pentru date. management și vizualizarea acestora. Într-o arhitectură cu două niveluri (Fig. 1.11, 6) o parte semnificativă a logicii de gestionare a datelor este implementată de serverul bazei de date (server DB), în timp ce legătura client este ocupată în principal cu afișarea datelor într-o formă ușor de utilizat. În SGBD cu trei niveluri (Fig. 1.11, V) se folosește o legătură intermediară - un server de aplicații,
Orez. 1.11.
A - unică legătură; 6 - cu două legături; V - trei niveluri, care este un intermediar între client și serverul bazei de date. Serverul de aplicații vă permite să eliberați complet clientul de funcțiile de gestionare a datelor și de comunicare cu serverul de baze de date.
În funcție de locația părților individuale ale SGBD, se disting SGBD-urile locale și de rețea. Toate părțile unui SGBD local sunt localizate pe computerul utilizatorului care accesează baza de date. Pentru ca mai mulți utilizatori să lucreze cu aceeași bază de date în același timp, fiecare computer de utilizator trebuie să aibă acces la propria copie a bazei de date locale. O problemă semnificativă la un SGBD de acest tip este sincronizarea conținutului copiilor de date (replicarea datelor), motiv pentru care SGBD-urile locale nu sunt potrivite pentru rezolvarea problemelor care necesită colaborarea mai multor utilizatori.
SGBD-urile de rețea includ server de fișiere, server-client și SGBD-uri distribuite. Un atribut indispensabil al acestor sisteme este o rețea care asigură comunicarea hardware între computere și o face posibilă lucrand impreuna mai mulți utilizatori cu aceeași bază de date.
În SGBD-urile server de fișiere, întreaga bază de date este de obicei localizată pe unul sau mai multe dispozitive de stocare. masina puternica, special dedicat acestor scopuri și conectat permanent la rețea. Un astfel de computer se numește server de fișiere. Avantajul incontestabil al unui SGBD de acest tip este relativa simplitate a creării și întreținerii acestuia, întrucât de fapt totul se reduce la organizarea unei rețele locale și la instalarea sistemelor de operare în rețea pe computerele conectate la aceasta. Nu există diferențe speciale între versiunile locale și cele ale serverului de fișiere ale SGBD, deoarece în acestea toate părțile SGBD sunt concentrate pe computerul utilizatorului. Acestea sunt de obicei cu un singur nivel în arhitectură, dar în unele cazuri pot folosi un server de aplicații. Dezavantajul sistemelor server de fișiere este încărcarea semnificativă a rețelei. De exemplu, dacă un utilizator lucrează la computer client, trebuie să găsiți informații despre una dintre cărțile disponibile în bibliotecă, apoi întregul fișier care conține informații despre toate cărțile este mai întâi transmis prin rețea, și abia apoi în cel creat astfel copie locală date, se găsesc informațiile necesare. La muncă intensivă cu date de la câteva zeci de utilizatori debitului rețeaua poate să nu fie suficientă, iar utilizatorul va fi enervat de întârzieri semnificative în răspunsul DBMS la solicitările sale. SGBD-urile server de fișiere pot fi utilizate cu succes în organizații relativ mici cu până la câteva zeci de site-uri client.
Sistemele client-server (două niveluri) reduc semnificativ încărcarea rețelei, deoarece clientul comunică cu date printr-un intermediar specializat - un server de baze de date, care se află pe mașina cu baza de date. Serverul bazei de date primește o solicitare de la client, găsește înregistrarea necesară în date și o transmite clientului. Astfel, dar rețelele sunt transmise relativ cerere scurtă si singurul intrarea obligatorie, chiar dacă baza de date conține sute de mii de înregistrări. De regulă, o cerere către server este formată într-o limbă specială interogări SQL, motiv pentru care serverele de baze de date sunt adesea numite servere SQL. Serverele de baze de date sunt programe relativ complexe dezvoltate de diverse companii, de exemplu: Microsoft SQL Server ( SQL Server) produs de Microsoft Corporation, Sybase Adaptive Server de Sybase Corporation, Oracle produs de corporația cu același nume, DB2 de IBM Corporation, InterBase de Borland Corporation etc. SGBD client-server asigura operarea sau scalarea la sute si mii de locatii clienti.
SGBD-urile distribuite pot conține câteva zeci sau sute de servere de baze de date. Numărul de locuri de clienți din ele poate ajunge la zeci și sute de mii. De obicei, astfel de SGBD susțin activitatea organizațiilor la nivel de stat (de exemplu, Comisia Electorală Centrală a Federației Ruse), ale căror divizii individuale sunt dispersate pe un teritoriu mare. În SGBD-urile distribuite, unele servere se pot duplica între ele pentru a obține o probabilitate extrem de scăzută de eșecuri și defecțiuni care pot distorsiona informații vitale.
Relevanța SGBD-urilor distribuite a crescut datorită dezvoltare rapida Internet. Pe baza puterii Internetului, sisteme distribuite Ei construiesc nu numai organizații la nivel de stat, ci și întreprinderi comerciale relativ mici, oferind angajaților lor date corporative de lucru acasă și în călătorii de afaceri.
Concept. Un sistem de gestionare a bazelor de date (DBMS) este un set de limbaje și instrumente software concepute pentru crearea, întreținerea și partajarea unei baze de date cu mulți utilizatori.
Un SGBD modern conține software crearea de baze de date (limbaj pentru descrierea și manipularea datelor, ajutoare vizuale, depanatoare), instrumente de manipulare a datelor și instrumente de service. Funcţiile elementelor SGBD: - limbajul de descriere este utilizat pentru a converti modelul logic într-unul fizic; - limbajul de manipulare implementeaza operatii asupra datelor; - mijloacele vizuale sunt implicate în procesul de proiectare a obiectelor grafice; - programe de depanare se conectează și testează blocurile programului de control creat de baza de date; - instrumentele pentru lucrul cu baza de date oferă o interfață de utilizator convenabilă; instrumentele de service implică alte programe (Excel) pentru a lucra cu baza de date.
Arhitectură. În mediul DBMS, se pot distinge următoarele. cinci componente principale:
Hardware. Unele SGBD-uri sunt proiectate să funcționeze numai cu anumite tipuri de sisteme de operare sau hardware, în timp ce altele pot funcționa cu o gamă largă de hardwareși diverse sisteme de operare. Un DBMS necesită, de obicei, un anumit minim de memorie RAM și de disc pentru a funcționa, dar acest lucru poate să nu fie suficient pentru a obține performanțe acceptabile ale sistemului.
Software. Această componentă include sistemul de operare, software-ul SGBD în sine, programe de aplicație, inclusiv software de rețea dacă SGBD-ul este utilizat într-o rețea. Aplicațiile sunt de obicei scrise în limbaje de generația a treia, cum ar fi C, COBOL, Fortran, Ada sau Pascal, sau în limbaje de generația a patra, cum ar fi SQL, ale căror instrucțiuni sunt încorporate în programe de limbaj de generația a treia.
Datele sunt cele mai multe componentă importantă din punct de vedere utilizatori finali. Baza de date conține atât date operaționale, cât și metadate, adică. „date despre date”.
Proceduri, care includ instrucțiuni și reguli care trebuie luate în considerare la proiectarea și utilizarea unei baze de date: înregistrarea în SGBD; utilizarea unui instrument sau aplicație DBMS separat; pornirea și oprirea SGBD; crearea de copii de rezervă DBMS; Gestionarea defecțiunilor hardware și software, inclusiv procedurile de identificare a componentei defectate, corectarea componentei defectate (de exemplu, apelând un tehnician de reparații hardware) și restaurarea bazei de date după ce defecțiunea a fost rezolvată; modificarea structurii tabelului, reorganizarea unei baze de date situate pe mai multe discuri, modalități de îmbunătățire a performanței și metode de arhivare a datelor pe dispozitive de stocare secundare.
Utilizatori: clienți baze de date, administrator baze de date, programatori de aplicații. Această componentă este discutată mai detaliat în prelegerea nr. 9 (Administrarea bazei de date)
Subsistemul instrumente de proiectare este un set de instrumente care simplifică proiectarea și implementarea bazelor de date și a aplicațiilor acestora. De obicei, acest set include instrumente pentru crearea de tabele, formulare, interogări și rapoarte.
Subsistemul de procesare asigură procesarea componentelor aplicației create folosind instrumente de proiectare. De exemplu, Access 2003 are o componentă care construiește un formular și conectează elementele formularului cu datele din tabel.
A treia componentă a DBMS, nucleul său (DBMS Engine), acționează ca intermediar între subsistemul de instrumente și date de proiectare și procesare. Motorul bazei de date primește interogări de la celelalte două componente, exprimate în tabele, rânduri și coloane, și convertește aceste interogări în comenzi sistem de operare, care scrie și citește date de pe un dispozitiv fizic.
Microsoft introduce două motoare diferite pentru Access 2003: Jet Engine și SQL Server. Jet Engine este folosit pentru baze de date personale și colective mici. Motorul SQL Server este proiectat pentru baze de date mari.
35. Oportunități oferite de SGBD utilizatorilor. Performanță DBMS.
Principalele funcții ale SGBD includ: Menținerea unui catalog de sistem, Catalog de sistem, sau dicționar de date, este un depozit de informații care descrie datele din baza de date (în esență, este vorba de „date despre date” sau metadate). De obicei, catalogul de sistem stochează următoarele informații: nume, tipuri și dimensiuni ale elementelor de date; nume de conexiuni; restricții de suport de integritate impuse datelor; numele utilizatorilor autorizați cărora li se acordă acces la date; scheme externe, conceptuale și interne și mapări între ele; Statistici, cum ar fi ratele tranzacțiilor și numărul de acces la obiectele bazei de date.
¨ Asistență pentru tranzacții. O tranzacție este un set de acțiuni efectuate de un utilizator individual sau de un program de aplicație pentru a accesa sau modifica conținutul unei baze de date. Exemplele de tranzacții includ adăugarea în baza de date, actualizarea sau ștergerea oricărei informații.
¨ Acceptă operarea în paralel.
¨ Recuperarea bazei de date după eșecuri. Jurnalul este o parte specială a bazei de date, nu este disponibil pentru utilizatori DBMS și întreținut cu grijă deosebită (uneori sunt acceptate două copii ale jurnalului, situate pe diferite discuri fizice), care primește înregistrări ale tuturor modificărilor aduse părții principale a bazei de date.
¨ Controlul accesului la date. SGBD-ul trebuie să aibă un mecanism care să asigure că numai utilizatorii autorizați pot accesa baza de date.
¨ Sprijină schimbul de date. SGBD-urile trebuie să suporte lucrul într-o rețea locală, astfel încât în loc de mai multe baze de date separate pentru fiecare utilizator individual, o bază de date centralizată poate fi instalată și utilizată ca resursă comună pentru toți utilizatorii existenți. Această topologie se numește procesare distribuită.
¨ Suport pentru integritatea datelor. Integritatea bazei de date înseamnă corectitudinea și consistența datelor stocate. Poate fi considerat un alt tip de securitate a bazei de date.
¨ Sprijină independența datelor. Independența datelor este de obicei obținută prin implementarea unui mecanism de suport pentru vizualizare sau subschemă. Independența datelor fizice se realizează pur și simplu deoarece există de obicei mai multe tipuri de modificări permise ale caracteristicilor fizice ale bazei de date care nu afectează în niciun fel vizualizările.
Funcții secundare. conceput pentru administrarea bazei de date, importul și exportul bazei de date, monitorizarea caracteristicilor de performanță și utilizarea bazei de date, analiză statistică, reorganizare a indicilor, redistribuire a memoriei.
Aplicațiile îndeplinesc cinci funcții principale: 1. Creați, citiți, actualizați și ștergeți vizualizări. 2. Formatarea vizualizărilor. 3. Implementarea restricțiilor. 4. Asigurarea mecanismelor de securitate și control. 5. Implementarea logicii de prelucrare a informaţiei. Performanța DBMS este evaluată:
Solicitare timp de executare; viteza de căutare a informațiilor în câmpuri neindexate; timpul de executare a operațiunilor de import al bazei de date din alte formate; viteza de creare a indexurilor și efectuarea de operațiuni în masă precum actualizarea, inserarea, ștergerea datelor; numărul maxim de accesări paralele la date în modul multi-utilizator; timpul de generare a raportului. Performanța unui SGBD este influențată de doi factori: SGBD-urile care monitorizează integritatea datelor poartă o sarcină suplimentară pe care alte programe nu o experimentează; performanta proprie programe de aplicație depinde foarte mult de proiectarea și construcția corectă a bazei de date.
Principalul interes al utilizării unui SGBD este de a oferi utilizatorului (sau proceselor aplicației) o reprezentare abstractă a datelor, ascunzând caracteristicile stocării și gestionării acestora. SGBD-ul trebuie să ofere acces la date prin procesele de aplicare oricăror utilizatori, inclusiv celor care habar nu au:
Despre plasarea fizică a datelor și descrierile acestora în memorie;
Despre mecanismul de căutare a datelor solicitate;
Despre probleme care apar atunci când un număr mare de utilizatori (programe de aplicație) solicită simultan aceleași date;
Despre modalități de a proteja datele de actualizări incorecte și (sau) acces neautorizat;
Despre menținerea la zi a bazei de date.
Structura generalizată a conexiunilor dintre programe și date atunci când se utilizează un SGBD este prezentată în Figura 6.6.
Atunci când se efectuează principalele dintre aceste funcții, SGBD-ul trebuie să utilizeze descrieri diverse date care ar trebui să ia în considerare:
Esența domeniului de interes;
Atribute care caracterizează proprietățile inerente ale fiecărei entități;
Relații care asociază entități selectate.
Orez. 6.6. Structura generalizată a conexiunilor dintre programe și date într-un SGBD
Abordarea arhitecturii și a descrierii datelor a fost propusă de comitetul ANSISPARC (Comitetul de planificare pentru standarde și coduri
Institutul Național de Standarde din SUA) și urmărește să separe viziunea utilizatorului asupra bazei de date de cea a acesteia organizarea fizică. În conformitate cu această propunere, arhitectura SGBD ar trebui să fie pe trei niveluri și ar trebui să conțină niveluri externe, conceptuale și interne (Fig. 6.7).
Orez. 6.7. Arhitectură ANSI-SPARC pe trei niveluri
Această separare pe niveluri asigură independența datelor stocate, care este necesară din următoarele motive:
1. Fiecare utilizator ar trebui să poată accesa datele folosind propria sa vizualizare asupra acestora, să-și schimbe vizualizarea asupra datelor fără a afecta vizualizarea altor utilizatori.
2. Utilizatorii nu trebuie să se ocupe de detaliile organizării fizice a datelor, de ex. nu ar trebui să depindă de caracteristicile stocării fizice a datelor.
3. Administratorul bazei de date trebuie să poată schimba structura de stocare a datelor, astfel încât aceste modificări să rămână transparente pentru alți utilizatori.
4. Structura bazei de date nu ar trebui să depindă de aspectele fizice ale stocării, de exemplu, atunci când treceți la una nouă dispozitiv extern memorie.
Nivelul extern este o reprezentare a bazei de date din punctul de vedere al anumitor utilizatori. Acest nivel poate include mai multe vederi diferite ale bazei de date de la diferite grupuri de utilizatori. În acest caz, fiecare utilizator se ocupă de o reprezentare domeniul subiectului, exprimat în cea mai înțeleasă și convenabilă formă pentru el. O astfel de reprezentare conține doar acele entități, atribute și conexiuni care îl interesează atunci când rezolvă probleme profesionale. Diferite reprezentări la nivel extern se pot suprapune, i.e. utilizare descrieri generale abstracții de domeniu. La nivel extern se creează un model de bază de date infologică, complet independent de platformă ( sistem de calcul pe care va fi folosit).
Modelul informațional este orientat spre om: mediul său de stocare poate fi memoria umană, nu un computer. Modelul informațional nu se schimbă până când unele schimbări din lumea reală necesită modificări ale unor definiții, astfel încât modelul continuă să reflecte domeniul de studiu.
Nivelul conceptual este o reprezentare generală a bazei de date care descrie ce date sunt stocate în baza de date, precum și relațiile care există între ele. Nivelul conceptual este intermediar în arhitectura cu trei niveluri. Conține structura logică a întregii baze de date. De fapt, este o reprezentare completă a cerințelor de date ale organizației, independent de considerentele privind modul în care sunt stocate. La nivel conceptual, este necesar să evidențiem:
1) entități, atributele și conexiunile acestora;
2) restricții impuse datelor;
3) informații semantice despre date;
4) informații despre măsurile de siguranță.
Nivelul conceptual susține fiecare reprezentare externă. Prin urmare, acest nivel conține orice disponibile utilizatorului date, cu excepția informațiilor despre metodele de stocare a acestor date. La nivel conceptual se creează un model datalogic.
Un model datalogic este o descriere a unui model de informații în limbajul de definire a datelor unui anumit SGBD. Acest model este orientat pe computer (în funcție de SGBD și sistemul de operare utilizat pe computer).
Nivelul intern este reprezentarea fizică a bazei de date, descriind metodele de stocare a acesteia în sistemul de calcul. Acest nivel descrie implementarea fizică a bazei de date și are scopul de a obține performanțe optime și de a asigura o utilizare economică spatiu pe disc.
Conține o descriere a structurilor de date și a fișierelor individuale utilizate pentru stocarea pe dispozitivele de stocare.
La nivel intern, SGBD interacționează cu metodele de acces ale sistemului de operare pentru a plasa eficient datele pe medii, a crea indici etc. La acest nivel se folosesc următoarele:
Harta alocarii spatiului pe disc pentru stocarea datelor si indexari;
O descriere a detaliilor stocării înregistrărilor (indicând dimensiunile reale ale elementelor de date stocate);
Informații despre postarea înregistrărilor;
Informații despre posibilitatea comprimării datelor și metodele de criptare selectate.
Implementarea informațiilor enumerate se realizează pe nivel fizic sistem de calcul care este controlat de sistemul de operare. În prezent, funcțiile SGBD și sistemul de operare nu se disting strict. Există SGBD-uri care utilizează toate metodele de acces furnizate într-un anumit sistem de operare, în timp ce altele folosesc doar unele dintre metode sau implementează propriul sistem de fișiere.
La nivel intern se creează un model fizic.
Modelul fizic permite SGBD-ului să ofere programelor și utilizatorilor acces la datele stocate după nume, fără a-și face griji cu privire la locatie fizica. Este orientat către computer (în funcție de SGBD și sistemul de operare). Conform acestui model, SGBD caută date pe dispozitive de stocare externe.
În conformitate cu propunerile ANSI-SPARC, poate fi reprezentat un model de date corespunzător pe trei niveluri (Figura 6.8):
Orez. 6.8. Straturi de model de date
SGBD-ul este construit pe un principiu modular, deoarece este destul de complicat software. Compoziția și interconectarea modulelor SGBD-urilor reale variază foarte mult, dar pot fi identificate o serie de componente generalizate (Fig. 6.9):
Orez. 6.9. Componentele principale ale unui SGBD
Să ne uităm la principalele componente ale SGBD.
Procesor de interogări - componenta principală a SGBD care convertește interogările într-o secvență instrucțiuni de nivel scăzut pentru controlerul bazei de date.
Controlerul bazei de date interacționează cu programele și interogările utilizator care rulează. Controlerul bazei de date acceptă interogări și examinează schemele externe și conceptuale pentru a determina acele înregistrări conceptuale care sunt necesare pentru a satisface cerințele de interogare. Controlorul bazei de date apelează controlorul de fișiere pentru a îndeplini cererea primită.
Controlerul de fișiere manipulează fișierele destinate stocării datelor și este responsabil pentru alocarea spațiului disponibil pe disc. Acesta creează și menține o listă de structuri și indici definiți în circuit intern. (Controlerul de fișiere nu gestionează intrarea fizică - aceasta este o funcție a sistemului de operare).
Preprocesorul DML convertește instrucțiunile DML încorporate în programele de aplicație în apeluri specificații standard limbajul de bază. Pentru a genera codul adecvat, preprocesorul DML trebuie să comunice cu procesorul de interogare. Limbajul de manipulare a datelor (DML) este un set de instrumente lingvistice pentru organizarea accesului la date într-un anumit model de date și în DBMS-ul corespunzător.
Compilatorul limbajului DDL convertește comenzile DDL într-un set de tabele care conțin metadate. Aceste tabele sunt apoi stocate în directorul de sistem și informații de control- în anteturile fișierelor de date. Limbajul de definire a datelor (DDL) este o lege formală utilizată în anumite modele de date pentru a defini structura datelor.
Controlerul dicționarului controlează accesul și funcționarea directorului de sistem. Catalogul de sistem este accesibil pentru majoritatea componentelor SGBD.
Controlerul bazei de date, ca și alte componente DBMS, conține un numar mare de unități de program. De exemplu, controlerul bazei de date include următoarele componente software (Figura 6.10):
1. Controlul drepturilor de acces (utilizatorul are sau nu drepturi asupra operațiunii solicitate).
2. Procesor de comenzi (pentru a executa cererea, controlul este transferat procesorului de comenzi).
3. Controale de integritate (la efectuarea operațiunilor legate de modificarea conținutului bazei de date se verifică integritatea cheilor).
4. Optimizatorul de interogări determină cea mai buna strategieîndeplini cererea.
5. Controlorul tranzacțiilor efectuează prelucrarea necesară a operațiunilor primite în timpul executării tranzacțiilor.
6. Planificatorul este responsabil pentru execuția fără conflicte a operațiunilor în paralel cu bazele de date.
7. Controlerul de recuperare se asigură că datele sunt restaurate la o stare consecventă după o eroare.
8. Controlerul buffer-ului este responsabil pentru transferul datelor între RAM și mediile externe.
Orez. 6.10. Componentele controlerului bazei de date
Prin organizarea interacțiunii cu baza de date prin intermediul rețelei, SGBD-urile sunt împărțite în:
SGBD cu arhitectură centralizată;
SGBD cu arhitectură file-server;
SGBD cu arhitectura client-server;
SGBD cu o arhitectură pe trei niveluri: „client subțire” - server de aplicații - server de baze de date.
Într-un SGBD cu arhitectura centralizata, SGBD și baza de date în sine sunt localizate și funcționează pe un minicalculator central (mainframe), iar utilizatorii accesează baza de date folosind terminale obișnuite - computerul este considerat simplu ca un dispozitiv pentru introducerea și afișarea informațiilor: apăsările de taste sunt transmise către mainframe, datele este transmis în sens invers, afișat direct pe monitorul utilizatorului. Exemple de SGBD cu arhitectură centralizată sunt versiuni timpurii DB2 DBMS, versiunile timpurii ale Oracle și Ingres DBMS.
ÎN SGBD cu arhitectură server de fișiere baza de date este stocată pe server, iar copiile DBMS sunt instalate pe computerele utilizatorului. Fișierul bazei de date aflat pe server este partajat de toți utilizatorii simultan, folosind software-ul de rețea și sistemul de operare în sine. Un exemplu izbitor de astfel de arhitectură este MS Access DBMS: copii ale DBMS sunt instalate pe computerul fiecărui utilizator, iar fișierul bazei de date în sine este localizat pe server într-un folder de rețea.
Arhitectura serverului de fișiere vă permite să obțineți performanțe acceptabile, deoarece... Fiecare copie a SGBD are la dispoziție toate resursele computerului utilizatorului. Pe de altă parte, performanța unei astfel de scheme pentru fiecare utilizator depinde direct de caracteristicile computerului utilizatorului. În plus, această schemă de operare încarcă semnificativ rețeaua.
Să presupunem că utilizatorul trebuie să selecteze rânduri de tabel cu produse pentru care volumul vânzărilor nu depășește 100 de mii de ruble. Deoarece rândurile din tabel nu sunt ordonate, cel mai probabil vor fi transmise prin rețea Toate rânduri de tabel, din care SGBD le va selecta pe cele necesare deja „la fața locului” (pe computerul utilizatorului).
Evident, o astfel de schemă este irațională când volume mari informații prelucrate sau Mai mult utilizatorii bazei de date. Prin urmare, pentru astfel de baze de date este mai indicat să se folosească o arhitectură client-server.
La arhitectura client-server baza de date este stocată pe server, iar SGBD-ul este împărțit în două părți: clientȘi cameră cu servere. Partea client a SGBD rulează pe partea client și oferă interacțiune interactivă cu utilizatorul și generarea de interogări la baza de date (în limbaj SQL).
Partea de server rulează pe server și interacționează cu baza de date, asigurând executarea solicitărilor din partea client, adică. dacă facem o analogie cu exemplul discutat mai sus, partea client va genera și trimite către partea de server solicitarea „Selectați-mă pentru un rând de tabel cu produse pentru care volumul vânzărilor nu depășește 100 de mii de ruble”, partea de server executată aceasta cerereși va trimite clientului acele linii care sunt necesare, fără a transmite toate liniile prin rețea.
Majoritatea SGBD-urilor moderne sunt implementate folosind o arhitectură client-server: Oracle, MS SQL Server, PostgreSQL, MySQL, Informix, DB2 etc.
Cu toate acestea, arhitectura client-server nu este lipsită de dezavantaje.
Dacă se modifică logica de afaceri a interacțiunii cu baza de date (logica care determină ordinea întreprinderii: ce tabele trebuie completate și în ce ordine, ce trebuie făcut la adăugarea unui nou angajat etc.), atunci programele client au să fie rescrise (creați formulare noi, modificați ordinea de completare a acestora etc.).
Dacă modificările apar prea des și numărul de joburi este mare, atunci reinstalarea constantă a software-ului (care, apropo, ar trebui făcută destul de repede) devine o problemă serioasă.
În astfel de cazuri, ar trebui să treceți la o arhitectură cu trei niveluri: „client subțire” - server de aplicații - server de baze de date.
La arhitectura pe trei niveluri Funcțiile părții client („thin client”) includ doar interacțiunea interactivă cu utilizatorul, iar toată logica de afaceri este transferată către serverul de aplicații, care asigură de fapt generarea de interogări către baza de date, care sunt transferate pentru execuție în baza de date. Server.
« Client slab" se află pe computerul utilizatorului și reprezintă cel mai adesea un browser Web (de exemplu, Internet Explorer) folosind pagina HTML corespunzătoare, applet-uri Java sau componente ActiveX.
Serverul de aplicații se află pe server și poate fi program de specialitate(de exemplu, Oracle Forms Server) sau un server Web obișnuit care apelează pentru a procesa o solicitare HTTP program extern prin interfața CGI (Fig. 33).
Orez. 33. Arhitectura bazei de cunoștințe pe trei niveluri.
Avantajele unei arhitecturi pe trei niveluri sunt evidente: dacă sunt necesare modificări în logica afacerii, modificările se fac o singură dată - pe serverul de aplicații. Nu este nevoie să schimbați sau să reinstalați programele client.
REVIZUIREA NOTELOR DE PRELEGERE
Pentru studenții de specialitate
T1002 „Software pentru tehnologia informației”
(L.V. Rudikova, Ph.D., conferențiar)
Întrebarea 31. ARHITECTURA DBMS. MODEL DE DATE RELAȚIONALE
1. Conceptul de bază de date.
2. Arhitectura bazei de date pe trei niveluri.
3. Ciclul de viață al bazei de date.
4. Arhitectura DBMS.
5. Model de date relaționale.
6. Proiecta baze de date relaționale date.
7. Forme normale relatii.
8. Algebra relațională.
1. Conceptul de bază de date.
Un sistem de baze de date este orice sistem informatic bazat pe computer în care datele pot fi partajate între mai multe aplicații.
Sistem informatic – un sistem automat care organizează datele și furnizează informații.
Sistem de informare și management – un sistem care oferă suport informativ management.
Date – fapte dispersate.
informație – date organizate și prelucrate.
Sub Bază de date se referă la un set de grupuri elementare interconectate de date (informații) care pot fi procesate de unul sau mai multe sisteme de aplicație. Sistem de baze de date constă dintr-o bază de date; software de uz general numit sistem de management al bazelor de date (DBMS) , și servește la gestionarea bazei de date; echipament și oameni adecvati.
Fiecare SGBD trebuie să îndeplinească următoarele cerințe:
· oferă utilizatorului posibilitatea de a crea baze de date noi și de a le defini schema (structura logica a datelor) prin utilizarea limbaj special - limbaj de definire a datelor; acceptă mai multe vizualizări ale acelorași date;
· lăsa " cerere» date și modificați-le folosind limbajul de interogare, sau limbaj de manipulare a datelor; permit integrarea şi partajarea date din diverse aplicații;
· susțin stocarea unor cantități foarte mari de date, măsurate în gigaocteți sau mai mult, pentru o perioadă lungă de timp, protejându-le împotriva deteriorării accidentale și a utilizării neautorizate și, de asemenea, oferă modificarea bazei de date și accesul la date prin interogări, de ex. garanta securitatea și integritatea datelor;
· controlează accesul la date pentru mulți utilizatori simultan; exclude influența cererii unui utilizator asupra cererii altuia și împiedică accesul simultan, care ar putea corupe datele, de ex. asigura controlul simultan al accesului la date.
Sistemul de baze de date este format din următoarele componente:
· Utilizatorii, adică persoane care folosesc date.
· Aplicații, de ex. programe de utilizator care necesită date din sistem.
· DBMS este un software care gestionează accesul la date și oferă funcționalitatea specificată a unui sistem de baze de date.
· Date, adică șiruri stocate în fișiere.
· Sistemul gazdă este sistemul informatic pe care sunt stocate fișierele. Rândurile de date sunt accesate de sistemul gazdă. Rolul SGBD este de a genera interogări care să permită utilizarea funcționalității sistemului de gestionare a fișierelor din sistemul gazdă pentru a servi aplicatii diverse. Un DBMS este un strat suplimentar de software construit peste software-ul sistemului gazdă.
Astfel, un sistem cu o bază de date poate fi reprezentat ca următoarea secvență de niveluri:
La cel mai de jos nivel se află datele stocate în fișiere fizice (memoria fizică a bazei de date). Pe nivelul superior– aplicații cu reprezentări proprii ale acelorași date fizice. Fiecare vizualizare a bazei de date are un specific structura logica, construit din datele fizice subiacente. Pentru a oferi o interfață între memorie fizică Baza de date și diferitele sale versiuni logice (multe vizualizări acceptate) SGBD-ul, la rândul său, trebuie să fie format din mai multe niveluri.
2. Arhitectura bazei de date pe trei niveluri.
Distincția dintre reprezentarea logică și cea fizică a datelor a fost recunoscută oficial în 1978, când comitetul ANSI/SPARC a propus o structură generalizată a sistemelor de baze de date. Această structură se numește arhitectură cu trei niveluri. Cele trei niveluri de arhitectură sunt: intern, conceptual și extern.
Nivel intern – acesta este nivelul care determină aspectul fizic al bazei de date, cel mai apropiat de stocarea fizică și este asociat cu metode de stocare a informațiilor pe dispozitivele fizice de stocare. Asociate cu acest strat sunt unități de disc, adrese fizice, indecși, pointeri etc. Acest nivel este responsabilitatea designerilor de baze de date fizice care decid ce dispozitive fizice vor stoca date, ce metode de acces vor fi utilizate pentru a prelua și actualiza datele și ce măsuri ar trebui luate pentru a menține sau îmbunătăți performanța sistemului de management al bazei de date. Utilizatorii nu ating acest nivel.
Nivel conceptual – nivel structural care definește proiectarea logică a bazei de date. Pe acest nivel se realizează proiectarea conceptuală a bazei de date, care include analiza nevoilor de informații ale utilizatorilor și identificarea elementelor de date de care au nevoie. Rezultatul designului conceptual este o diagramă conceptuală, o descriere logică a tuturor elementelor de date și a relațiilor dintre ele.
Nivel extern – nivelul structural al bazei de date, care definește vizualizările utilizatorilor asupra datelor. Fiecare grup de utilizatori primește propria sa vizualizare a datelor din baza de date. Fiecare astfel de vizualizare de date oferă o descriere centrată pe utilizator a elementelor de date care alcătuiesc vizualizarea de date și a relațiilor dintre acestea. Poate fi derivat direct din cadrul conceptual. Colectarea unor astfel de vizualizări ale datelor utilizatorului oferă nivelul extern.
|
Vizualizări utilizator și aplicație |
Nivel extern |
|
Afișări |
|
|
Diagrama conceptuală |
Nivel conceptual |
|
Afişa |
Nivel intern |
|
Sistem gazdă |
|
|
Date stocate |
Orez. Niveluri DBMS
3. Ciclul de viață al bazei de date.
Procesul de proiectare, implementare și întreținere a unui sistem de baze de date este numit ciclul de viață al bazei de date (LDC). Se numește procedura de creare a unui sistem ciclul de viață al sistemului (SLC).
Înțelegerea și abordarea corectă la LCBD este foarte important și necesită considerație detaliată, deoarece se bazează pe abordare centrat pe date. Elementele de date sunt mai stabile decât funcțiile de sistem efectuate. Creare structura corecta datele necesită o analiză complexă a claselor de unități de date și a relațiilor dintre ele. Dacă construiți o schemă de bază de date logică, atunci în viitor puteți crea orice număr de sisteme funcționale care utilizează această schemă. Abordarea orientată pe funcție poate fi utilizată numai pentru a crea sisteme temporare care sunt proiectate pentru o perioadă scurtă de funcționare.
LCBD constă din următoarele etape:
1. Pre-planificare – planificarea bazei de date, realizată în procesul de elaborare a unui plan strategic de bază de date. În timpul procesului de planificare, sunt colectate următoarele informații:
· ce programe de aplicație sunt folosite și ce funcții îndeplinesc;
· ce fișiere sunt asociate cu fiecare dintre aceste aplicații;
· ce aplicații și fișiere noi sunt în lucru.
Aceste informații ajută la determinarea modului în care sunt utilizate informațiile aplicației și la determinarea cerințelor viitoare pentru sistemul de baze de date.
Informațiile din această etapă sunt documentate sub forma unui model de date generalizat.
2. Verificarea fezabilității . Aici se determină fezabilitatea tehnologică, operațională și economică a planului de creare a bazei de date, adică:
· fezabilitate tehnologică – este tehnologia disponibilă pentru implementarea bazei de date planificate?
· Fezabilitate operațională – Sunt necesare fonduri și experți pentru a implementa cu succes planul bazei de date?
· fezabilitate economică – se pot determina concluziile? Se va amortiza sistemul planificat de la sine? Este posibil să se estimeze costurile și beneficiile?
3. Definirea cerințelor include selecția obiectivelor bazei de date, clarificarea cerințelor de informații pentru cerințele de sistem și hardware și software. Astfel, pe în această etapă se creează colectarea datelor și definirea cerințelor model informativ general, exprimată în următoarele sarcini:
· Obiectivele sistemului sunt determinate prin analiză nevoi de informare. De asemenea, indică în mod necesar ce tip de bază de date ar trebui creată (distribuită, holistică) și ce instrumente de comunicare sunt necesare. Documentul de ieșire este un comentariu care descrie obiectivele sistemului.
· Determinarea cerințelor utilizatorilor: documentare sub formă de informații generalizate (comentarii, rapoarte, sondaje, chestionare etc.); fixarea funcţiilor sistemuluiși identificarea sistemelor de aplicații care vor îndeplini aceste cerințe. Datele sunt prezentate sub forma unor documente relevante.
· Determinarea cerințelor generale hardware și software legate de menținerea nivelului dorit de performanță. (Aflați numărul de utilizatori ai sistemului, numărul de mesaje introduse pe zi, numărul de imprimări). Aceste informații sunt folosite pentru a selecta tipuri de computere și DBMS, capacitatea discului și numărul de imprimante. Datele din această etapă sunt prezentate într-un raport care conține exemple de configurații hardware și software.
· Elaborarea unui plan pentru crearea în etape a sistemului, inclusiv selecția aplicațiilor inițiale.
4. Design conceptual – crearea unei diagrame conceptuale a bazei de date. Specificațiile sunt dezvoltate în măsura în care este necesar pentru a trece la implementare.
Documentul principal de ieșire este un singur model informativ(sau schema bazei de date la nivel conceptual). La elaborarea acestui model sunt utilizate informații și funcții pe care sistemul trebuie să le îndeplinească, determinate în etapa de colectare și determinare a cerințelor sistemului. În această etapă, este de asemenea de dorit să se definească: 1) reguli pentru date; 2) reguli pentru procese; 3) reguli pentru interfață.
5. Implementarea – proces de transformare model conceptualîntr-o bază de date funcțională. Acesta include următorii pași.
1) Selectarea și achiziționarea DBMS-ului necesar.
2) Transformarea modelului conceptual (infologic) al bazei de date într-un model de date logic și fizic:
· Pe baza modelului de date infologice, se construiește o schemă de date pentru un anumit SGBD, dacă este necesar, baza de date este denormalizată pentru a accelera procesarea interogărilor în toate aplicațiile critice de timp;
· se determină ce procese de aplicație trebuie implementate în schema de date ca proceduri stocate;
· implementează constrângeri menite să asigure integritatea datelor și să aplice regulile privind datele;
· proiectează și generează declanșatori pentru a implementa toate regulile de date definite la nivel central și regulile de integritate a datelor care nu pot fi specificate ca constrângeri;
· dezvoltarea unei strategii de indexare și grupare; estimați dimensiunile tuturor tabelelor, clusterelor și indicilor;
· determina nivelurile de acces ale utilizatorilor, dezvoltă și implementează reguli de securitate și audit. Creați roluri și sinonime pentru a oferi acces multi-utilizator cu niveluri consistente de permisiuni de acces.
· dezvoltarea unei topologii de rețea a bazei de date și a unui mecanism de acces fără probleme la datele de la distanță (bază de date replicată sau distribuită).
3) Construirea unui dicționar de date care definește stocarea definițiilor structurii datelor bazei de date. Dicționarul de date conține, de asemenea, informații despre permisiunile de acces, regulile de protecție a datelor și controlul datelor.
4) Completarea bazei de date.
5) Crearea de programe aplicative, control de management.
6) Instruirea utilizatorilor.
6. Evaluarea și îmbunătățirea schemei bazei de date. Implică chestionarea utilizatorilor pentru a identifica nevoile funcționale nesatisfăcute. Modificările sunt făcute după cum este necesar, adăugând noi programe și elemente de date pe măsură ce nevoile se modifică și se extind.
Astfel, LCBD include:
· Studiați domeniul de studiu și furnizați documentația relevantă (1-3).
· Construirea unui model de informare (4).
· Implementare (5).
· Evaluarea performanței și suportul bazei de date (6).
4. Arhitectura DBMS.
Orez. Componentele principale ale SGBD
Date, metadate - conține nu numai date, ci și informații despre structura datelor ( metadate). Într-un SGBD relațional, metadatele includ tabele de sistem (relații), numele relațiilor, numele atributelor acelor relații și tipurile de date ale acelor atribute.
Adesea DBMS acceptă indici date. Index este o structură de date care ajută la găsirea rapidă a elementelor de date date o parte din valoarea lor (de exemplu, un index care găsește tupluri ale unei anumite relații care au o anumită valoare a unuia dintre atribute). Indecșii fac parte din datele stocate, iar descrierile care indică atributele pe care le au indicii fac parte din metadate.
Manager de memorie -primește informațiile solicitate de la locația de stocare a datelor și modifică informațiile din acesta la solicitarea nivelurilor superioare ale sistemului.
În sistemele de baze de date simple, managerul de memorie poate fi sistemul de fișiere al sistemului de operare. Cu toate acestea, pentru a îmbunătăți eficiența, SGBD-ul efectuează de obicei un control direct al memoriei. Managerul de memorie este format din două componente:
· Manager de fișiere monitorizează locația fișierelor de pe disc și obține blocul sau blocurile care conțin fișierele atunci când este solicitat de managerul de buffer (discul este în general împărțit în blocuri de discuri- zone de memorie adiacente care conțin de la 4000 la 16000 de octeți).
· Manager tampon gestionează memoria principală. Acesta primește blocuri de date de pe disc printr-un manager de fișiere și selectează o pagină de memorie principală pentru a stoca un anumit bloc. Poate stoca temporar un bloc de disc în memoria principală, dar îl readuce pe disc atunci când este necesară o pagină de memorie principală pentru un alt bloc. Paginile sunt, de asemenea, returnate pe disc la cererea managerului de tranzacții.
Procesor „Solicitare”. - procesează cereri și solicită modificări ale datelor sau metadatelor. Acesta sugerează cel mai bun mod de a efectua operația necesară și emite comenzi adecvate managerului de memorie.
Procesorul de interogări (managerul) transformă o acțiune de interogare sau de bază de date care poate fi finalizată foarte rapid nivel inalt(de exemplu, sub forma unei cereri SQL ), într-o secvență de solicitări de date stocate, cum ar fi tupluri individuale ale unei relații sau părți ale unui index pe o relație. Adesea cea mai dificilă parte a procesării cerere este al lui organizare, adică alegerea unuia bun plan de interogare sau o secvență de solicitări către sistemul de memorie care răspunde la cerere.
Manager de tranzacții - este responsabil de integritatea sistemului și trebuie să asigure procesarea simultană a mai multor cereri, absența interferenței cererilor (adăugare, minim maxim ) și protecția datelor în caz de defecțiune a sistemului. Interacționează cu managerul de interogări deoarece trebuie să știe ce date sunt afectate de interogările curente (pentru a evita conflictele) și poate amâna unele interogări și operațiuni pentru a evita conflictele. Managerul de tranzacții interacționează, de asemenea, cu managerul de memorie, deoarece schemele de protecție a datelor implică de obicei stocarea unui jurnal de modificare a datelor. La În ordinea corectă efectuați operația cu fișierul înregistrare va conține o înregistrare a modificărilor, astfel încât să puteți reexecuta chiar și acele modificări care nu au ajuns pe disc din cauza unei defecțiuni a sistemului.
SGBD-urile tipice permit utilizatorului să grupeze mai multe interogări și/sau modificări într-o singură tranzacție. Tranzacţie este un grup de operații care trebuie efectuate secvenţial ca un întreg.
De obicei, un sistem de baze de date acceptă mai multe tranzacții simultan. Este executarea corectă a tuturor acestor tranzacții care asigură manager de tranzacții. Este asigurată executarea corectă a tranzacțiilorACID -proprietăți (atomicitate, consistență, izolare, durabilitate):
· atomicitate- executarea fie a tuturor tranzacțiilor, fie a niciuna dintre ele (de exemplu, retragerea de bani de la un bancomat și efectuarea unui debit corespunzător în contul clientului trebuie să fie o singură tranzacție atomică; fiecare dintre aceste operațiuni nu este permisă să fie efectuată separat);
· consistenta - o stare în care datele îndeplinesc toate așteptările posibile (de exemplu, condiția de consistență pentru o bază de date a unei companii aeriene este ca niciun loc în avion să nu fie rezervat pentru doi pasageri);
· izolatie- cand doua sau mai multe tranzactii sunt executate in paralel, rezultatele acestora trebuie izolate unele de altele. Executarea simultană a două tranzacții în același timp nu ar trebui să conducă la un rezultat care nu ar fi avut loc dacă acestea ar fi fost executate secvențial (de exemplu, la vânzarea biletelor pentru același zbor în cazul unui ultimul loc liber când doi agenți solicită simultan , cererea unuia trebuie îndeplinită, a celuilalt - Nu);
· longevitate - după finalizarea tranzacției, rezultatul nu trebuie pierdut în cazul unei defecțiuni a sistemului, chiar dacă această defecțiune apare imediat după finalizarea tranzacției.
Să luăm în considerare și 3 tipuri de acces la DBMS:
1. Cereri - Întrebările despre date pot fi generate în două moduri:
A)prin utilizarea interfață comună de interogare(de exemplu, un SGBD relațional permite interogări SQL , care sunt transmise procesorului de cereri și primește și răspunsuri la acestea);
b) cu ajutorul interfețele programelor de aplicație- cererile sunt transmise printr-o interfață specială (cererile arbitrare nu pot fi transmise prin această interfață);
2. Modificări - Acestea sunt operațiuni de modificare a datelor. Ele pot fi, de asemenea, executate fie printr-o interfață comună, fie printr-o interfață de program de aplicație;
3. Modificări ale circuitului - Acestea sunt echipe de administratori de baze de date care au dreptul de a modifica schema bazei de date sau de a crea o nouă bază de date.
Arhitectura client/server. Multe versiuni de software modern implementează arhitectura client server: Un proces (clientul) trimite o cerere către alt proces (server) pentru a fi executat. De obicei, o bază de date este adesea împărțită într-un proces server și mai multe procese client.
În cea mai simplă arhitectură client/server, întregul SGBD este un server, cu excepția interfețelor de interogare, care interacționează cu utilizatorul și trimit interogări sau alte comenzi către server. De exemplu, un SGBD relațional folosește adesea limbajul SQL pentru a reprezenta cereri de la client la server. Serverul bazei de date oferă apoi clientului un răspuns sub forma unui tabel (relație). Există o tendință de a crește sarcina asupra clientului, deoarece dacă există mulți utilizatori de baze de date care lucrează simultan, pot apărea probleme cu serverul.
5. Model de date relaționale.
RMD-ul unui anumit domeniu este un set de relații care se schimbă în timp. Atunci când creați un sistem informațional, un set de relații vă permite să stocați date despre obiecte din domeniul subiectului și să modelați conexiunile dintre ele.
Atitudine este un tabel bidimensional care conține unele date. Matematic subN relație -ariană R înţelege setul de produse carteziane D 1 D 2 … D n seturi ( domenii) D 1, D 2, …, D n (), opțional diferit:
R D 1 D 2 … D n ,
unde D 1 D 2 … D n – produs cartezian complet, i.e. un set de toate combinațiile posibile de n elemente fiecare, unde fiecare element este preluat din domeniul său propriu.
Domeniu - Acest concept semantic. Un domeniu poate fi gândit ca un subset de valori ale unui tip de date care au o semnificație specifică. Domeniul este caracterizat de următoarele proprietăți:
· Domeniul are nume unic(în baza de date).
· Domeniul este definit la unii simplu tip de date sau pe un alt domeniu.
· Domeniul poate avea unele condiție logică, care vă permite să descrieți subsetul de date care este valabil pentru un anumit domeniu.
· Domeniul poartă un anumit încărcătură semantică.
Atribut de relație sunt câteva de acest fel<Имя_атрибута: Имя_домена>. Numele atributelor trebuie să fie unice în cadrul relației. Adesea, numele atributelor unei relații sunt aceleași cu numele domeniilor corespunzătoare.
Raport , definit pe mai multe domenii, conține două părți: un antet și un corp.
Antetul relației - Acest cantitate fixă atribute ale relatiei:
Capul relației descrie produsul cartezian al domeniilor pe care este definită relația. Antetul este static, nu se modifică în timpul lucrului cu baza de date. Dacă atributele sunt modificate, adăugate sau șterse într-o relație, atunci rezultatul va fi alte relație (chiar cu același nume).
Organul de relație conţine multe tupluri relaţie. Fiecare relație de tuplu reprezintă un set de perechi de formă<Имя_атрибута: Значение_атрибута>:
astfel încât valoarea atributului să aparțină domeniului . Corpul relației este un set de tupluri, adică. un subset al produsului cartezian de domenii. Astfel, corpul unei relații este de fapt o relație în sensul matematic al cuvântului. Corpul relației se poate schimba în timpul lucrului cu baza de date - tuplurile pot fi modificate, adăugate și șterse.
Relația este de obicei scrisă astfel:
sau mai scurt
,
sau pur și simplu
Numărul de atribute dintr-o relație este numit grad (sau -aritate ) relație. Cardinalitatea unui set de tupluri ale unei relații se numește putere relaţie.
Diagrama relațiilor este o listă de nume de atribute ale unei relații date, indicând domeniul căruia îi aparțin:
Dacă atributele iau valori din același domeniu, atunci ele sunt numite -comparabile, unde este setul de operațiuni de comparare valide specificate pentru un anumit domeniu. De exemplu, dacă un domeniu conține date numerice, atunci toate operațiunile de comparare sunt valabile pentru el, atunci . Cu toate acestea, pentru domeniile care conțin date de caractere, nu pot fi specificate numai operațiuni de comparare pentru egalitatea și inegalitatea valorilor. Dacă un domeniu dat are o ordonare lexicografică, atunci are și o gamă completă de operații de comparare.
Se numesc scheme a două relații echivalent , dacă au același grad și este posibil să ordonați numele atributelor în scheme în așa fel încât atributele comparabile, adică atributele care iau valori din același domeniu, să fie în aceleași locuri:
Lăsa 
– diagrama relațiilor. 
– schema relatiei dupa ordonarea numelor de atribute. Apoi
~ 
Astfel, pentru relațiile echivalente sunt îndeplinite următoarele condiții:
· Tabelele au același număr de coloane.
· Tabelele conțin coloane cu aceleași nume.
· Coloanele cu aceleași nume conțin date din aceleași domenii.
· Tabelele au aceleași rânduri, dar ordinea coloanelor poate varia.
Toate aceste tabele sunt diferite Imagini aceeași relație.
Proprietățile relațiilor. Proprietățile relațiilor decurg direct din definiția de mai sus a relației. Aceste proprietăți sunt principalele diferențe dintre relații și tabele.
· Nu există tupluri identice într-o relație .
· Tuplurile nu sunt comandate (de sus în jos) .
· Atributele nu sunt ordonate (de la stânga la dreapta) .
· Toate valorile atributelor sunt atomice .
Orez. Reprezentarea schematică a relației
Model relațional este o bază de date sub forma unui set de relații interconectate. În fiecare conexiune, o relație poate acționa ca principală, iar o altă relație acționează ca una subordonată. Astfel, un tuplu dintr-o relație principală poate fi asociat cu mai multe tupluri ale unei relații subordonate. Pentru a susține aceste relații, ambele relații trebuie să conțină seturile de atribute prin care sunt legate. Practic asta este cheia primară a relației , care definește în mod unic tuplu al relației principale. Pentru a modela o relație, o subrelație trebuie să aibă un set de atribute care să se potrivească cu cheia primară a relației principale. Cu toate acestea, aici este deja acest set de atribute cheie secundară sau cheie externă , adică definește un set de tupluri de relație care sunt asociate cu un singur tuplu al relației principale.
6. Proiectarea bazelor de date relaţionale.
La proiectarea unei baze de date relaționale, trebuie rezolvate următoarele probleme:
1) Ținând cont de semantica materiei, este necesar să se reprezinte cel mai bine obiectele domeniului sub forma unui model de date abstract (design de date). Acestea. - decide asupra schemei bazei de date: din ce relații ar trebui să constea baza de date, ce atribute ar trebui să aibă aceste relații, care sunt conexiunile dintre relații.
2) Asigurarea eficienței executării interogărilor bazei de date (design fizic baze de date).
După etapa de proiectare datalogică, trebuie obținute următoarele documente rezultate:
· Construirea unei scheme corecte de date bazată pe modelul de date relaționale.
· Descrierea schemei bazei de date în termeni de SGBD selectat.
· Descrierea modelelor externe în ceea ce privește DBMS-ul selectat.
· Descrierea regulilor declarative pentru menținerea integrității bazei de date.
· Dezvoltarea procedurilor de menținere a integrității semantice a bazei de date.
Deci, sarcina de a proiecta o bază de date relațională este de a selecta o schemă de bază de date dintre multe opțiuni alternative.
Corect este o schemă de bază de date în care nu există dependențe nedorite între atributele relației. Procesul de dezvoltare a unei scheme corecte de bază de date este numit design logic .
Proiectarea unei scheme de bază de date se poate face în două moduri:
· Metoda de descompunere (partiție). – setul original de relații inclus în schema bazei de date este înlocuit cu un alt set de relații care sunt proiecții ale relațiilor originale! În același timp, numărul relațiilor crește.
· Metoda de sinteză – layout-ul unei scheme de bază de date din dependențele elementare inițiale date între obiectele domeniului subiect.
Designul clasic al bazelor de date este asociat cu teoria normalizare , care se bazează pe analiză dependențe funcționaleîntre atributele relaţiilor. Dependențe funcționale definesc relații stabile între obiecte și proprietățile lor în domeniul subiectului luat în considerare.
Metoda de descompunere este un proces de normalizare secvențială a schemelor de relații: fiecare nouă iterație corespunde unei forme normale de ordin superior și are proprietăți mai bune în comparație cu cea anterioară. Astfel, se presupune inițial existența unei relații universale care conține toate atributele bazei de date, apoi, pe baza analizei conexiunilor dintre atribute, se realizează (sau se încearcă o descompunere a relației universale), adică. trecerea la mai multe relații de dimensiune inferioară, iar relația inițială trebuie restabilită folosind o operație de îmbinare naturală.
Deci, fiecare formă normală corespunde unora set specific restricții și relații este într-o formă normală dacă își satisface setul inerent de restricții.
În teoria bazelor de date relaționale, se disting de obicei următoarele forme normale:
prima formă normală (1 NF);
· a doua formă normală (2 NF);
· a treia formă normală (3 NF);
· Bays-Codd formă normală ( BCNF);
· a patra formă normală (4 NF);
· a cincea formă normală sau formă de proiecție - compuși (5 NF sau PYNF).
Proprietățile de bază ale formelor normale:
· fiecare formă normală succesivă este într-un fel mai bună decât cea anterioară;
· la trecerea la următoarea formă normală, proprietățile proprietăților normale anterioare sunt păstrate.
Sunt denumite scheme de baze de date echivalent, dacă conținutul bazei de date sursă poate fi obținut printr-o conexiune naturală a relațiilor incluse în schema rezultată și nu apar tuplu noi în baza de date sursă.
7. Forme normale de relaţii.
Procesul de normalizare se bazează pe o reflectare adecvată a domeniului subiectului sub formă de tabele care conțin date despre obiectul modelat și pe capacitatea de a schimba starea bazei de date în timp. De regulă, din cauza unei nepotriviri între modelul de date de domeniu, pot apărea anomalii care apar la efectuarea operațiunilor corespunzătoare:
· Anomalii de inserare (INSERT) – stocarea de informații eterogene într-un singur aspect.
· Anomalii de actualizare (UPDATE) – Redundanța datelor de relație datorită stocării eterogene.
· Anomalii de ștergere (DELETE) – stocarea de informații eterogene într-o relație.
De asemenea, este necesar să se țină cont de emergente nedefinit ( NUL) valori. În diferite SGBD, atunci când se efectuează diverse operații (comparare, îmbinare, sortare, grupare etc.) două NUL -valorile pot fi sau nu egale între ele, au efecte diferite asupra rezultatului efectuării operațiilor de determinare a valorilor medii și de a afla numărul de valori. Pentru a elimina erorile din multe SGBD-uri este posibilă înlocuirea NUL -valorile sunt zero la efectuarea calculelor, declarând toate NUL -valori egale între ele etc.
Normalizare – împărțirea unui tabel în mai multe, care au proprietăți mai bune la actualizarea, inserarea și ștergerea datelor. Acestea. normalizarea este procesul de înlocuire secvențială a unui tabel cu descompunerea lui completă până când acestea sunt toate în 5NF, totuși, în practică, este suficient să convertiți tabelele în BCNF;
Procedura de normalizare se bazează pe faptul că singurele dependențe funcționale din orice tabel ar trebui să fie dependențe de forma , unde este cheia primară și este un alt câmp. Prin urmare, în timpul procesului de normalizare, ar trebui să scăpați de toate „celelalte” dependențe funcționale, de exemplu. din cele care au un aspect diferit de .
Dacă înlocuim codurile cheilor primare (străine) în timpul normalizării, atunci ar trebui să luăm în considerare 2 cazuri:
1. Tabelul are o cheie primară compusă, de exemplu, și un câmp care depinde funcțional de o parte a acestei chei, de exemplu, de (nu depinde de cheia completă). Se recomandă să creați un alt tabel care să conțină și ( – cheia primară) și să ștergeți din tabelul original:
Înlocuiește, cheie primară, legea federală
pe , cheie primară
și cheia primară.
2. Tabelul are o cheie primară (posibilă), un câmp care nu este o cheie posibilă, dar de care depinde funcțional și un alt câmp fără cheie care depinde funcțional de:. Se recomandă crearea unui tabel care să conțină atât ( - cheia primară) cât și - ștergerea din tabelul original: Trebuie remarcat faptul că pentru a efectua astfel de operațiuni, ar trebui să aveți inițial unele relații „mari” (universale) ca date de intrare.
Def.1. Relația este în prima formă normală (1NF) dacă și numai dacă niciunul dintre rândurile sale nu conține o singură valoare în niciunul dintre câmpurile sale și niciunul dintre câmpurile cheie ale relației nu este gol.
Conform definiției 1, orice relație va fi în 1NF, adică. o relație care satisface proprietățile relațiilor: nu există tuple identice în relație; tuplurile nu sunt ordonate; atributele nu sunt ordonate și diferă după nume; toate valorile atributelor sunt atomice.
Def.2. Relația este în a doua formă normală (2NF) dacă și numai dacă relația este în 1NF și nu există atribute non-cheie care depind de o parte a cheii complexe (adică toate câmpurile care nu sunt incluse în cheia primară sunt legate prin dependență funcțională completă de cheia principala).
Dacă cheia candidată este primă, atunci relația este automat în 2NF.
Pentru a elimina dependența atributelor de o parte a unei chei complexe, este necesar să efectuați descompunere relații cu mai multe relații. Atributele care depind de o parte a unei chei complexe sunt plasate într-o relație separată.
Atributele unei relații sunt numite independent reciproc , dacă niciunul dintre ele nu este dependent funcțional de celălalt.
Def.3. Relația este în a treia formă normală (3NF) dacă și numai dacă relația este în 2NF și toate atributele non-cheie sunt reciproc independente (adică niciunul dintre câmpurile non-cheie ale relației nu depinde funcțional de orice alt câmp non-cheie).
Pentru a elimina dependența atributelor non-cheie, trebuie să descompuneți relația în mai multe relații. În acest caz, acele atribute non-cheie care sunt dependente sunt plasate într-o relație separată.
Când se reduc relațiile folosind algoritmul de normalizare la relații în 3NF, se presupune că toate relațiile conțin o cheie candidată. Acest lucru nu este întotdeauna adevărat. Există momente când o relație poate conține mai multe chei.
Def.4. Relația este în Bays-Codd formă normală (NFBK) dacă și numai dacă determinanții tuturor dependențelor funcționale sunt chei potențiale (sau dacă orice dependență funcțională între prietenii săi se reduce la o dependență funcțională completă de o posibilă cheie).
Dacă o relație este în BCNF, atunci este automat în 3NF, după cum reiese din Definiția 4. Pentru a elimina dependența de determinanți care nu sunt chei potențiale, trebuie efectuată descompunerea, plasând acești determinanți și părțile care depind de ei într-un relatie separata.
Există momente când o relație nu conține nicio dependență funcțională. Acestea. atitudinea este complet cheie, adică. cheia unei relații este întregul set de atribute. Astfel, avem o dependență multivalorică, deoarece Există încă o relație între atribute.
Def.5. Relația este în a patra formă normală (4NF) dacă și numai dacă relația este în BCNF și nu conține dependențe multivalorice netriviale.
Relațiile cu dependențe multivalorice netriviale apar, de regulă, ca urmare a unei conexiuni naturale a două relații pe un câmp comun, care nu este cheie în niciuna dintre relații. În realitate, acest lucru duce la stocarea informațiilor despre două entități independente într-o singură relație.
Pentru a elimina dependențele multivalorice non-triviale, puteți descompune relația inițială în câteva noi.
Def.6. Relația este în a cincea formă normală (5NF) dacă și numai dacă orice dependență de conexiune prezentă este trivială.
Def.6. identic urmează și definiția.
Def.7. O relație nu este în 5NF dacă relația are o dependență de unire non-trivială.
Acea. Dacă în fiecare descompunere completă toate proiecțiile relației originale conțin o cheie posibilă, putem concluziona că relația este în 5NF. O relație care nu are nicio descompunere completă este, de asemenea, în 5NF.
Fără a ști nimic despre potențialele chei într-o relație și cum sunt interconectate atributele, nu se poate spune că această atitudine este în 5NF sau în alte forme normale.
Posibil indiciu relația este un set de atribute de relație care complet și unic (complet funcțional) determină valorile tuturor celorlalte atribute ale relației. În general, o relație poate avea mai multe chei posibile. Dintre toate cheile posibile ale unei relații, de obicei este selectată una, care este considerată cea principală și care se numește cheia primară a relației.
Atribute independente reciproc – Acestea sunt atribute care nu depind una de alta. Dacă într-o relație există mai multe legi fizice, atunci fiecare atribut sau set de atribute de care depinde un alt atribut se numește determinant al relației.
9. Algebră relațională.
Algebra relațională oferă un cadru pentru accesarea datelor relaționale. Scopul principal al algebrei este de a oferi expresii care pot fi scrise. Expresiile pot fi folosite pentru:
· definițiile zonei mostre, adică definirea datelor pentru selecție ca urmare a operațiunii de eșantionare;
· definițiile zonei actualizări, adică definirea datelor care urmează să fie inserate, modificate sau șterse ca urmare a unei operațiuni de actualizare;
· definiție (numite) relații virtuale, adică prezentare de date pentru vizualizare prin vizualizări;
· definiție instantanee, de ex. definirea datelor de stocat ca „instantaneu” al relației;
· definirea regulilor de siguranță, de ex. determinarea datelor pentru care se efectuează controlul accesului;
· determinarea cerințelor de sustenabilitate, de ex. determinarea datelor care sunt incluse în domeniul de aplicare pentru anumite operațiuni de control al concurenței;
· definirea regulilor de integritate, de ex. unele reguli specifice pe care o bază de date trebuie să le îndeplinească, împreună cu reguli generale care reprezintă parte din model relaționalși aplicat fiecărei baze de date.
Implementările unor SGBD-uri relaționale specifice nu sunt utilizate în prezent în formă pură nici algebră relațională și nici calcul relațional. Standardul de facto pentru accesarea datelor relaționale a devenit Limbajul SQL(Limbajul de interogare structurat).
Algebra relațională, definită de Codd, constă din 8 operatori cuprinzând 2 grupuri:
- operații tradiționale de set (unire, intersecție, scădere, produs cartezian);
- operații relaționale speciale (selecție, proiecție, legătură, împărțire).
În plus, algebra include o operație de atribuire, care vă permite să salvați rezultatele calculării expresiilor algebrice în baza de date și o operație de redenumire a atributelor, care face posibilă formarea corectă a antetului (schemei) relației rezultate.
O scurtă prezentare a operatorilor de algebră relațională.
Probă– returnează o relație care conține toate tuplurile unei anumite relații care îndeplinesc anumite condiții. Operația de eșantionare se mai numește și operațiune de restricție ( restrânge - limitare, acum eșantionarea este mai des acceptată - SELECTAȚI ).
Proiecție– returnează o relație care conține toate tuplurile (adică - sub-tuplurile) unei anumite relații după excluderea unor atribute din aceasta.
Muncă– returnează o relație care conține toate tuplurile posibile care sunt o combinație de două tupluri aparținând, respectiv, la două relații definite.
O asociere– returnează o relație care conține toate tuplurile care aparțin uneia sau ambelor relații definite.
Intersecție -returnează o relație care conține toate tuplurile care aparțin simultan la două relații definite.
Scăderea –returnează o relație care conține toate tuplurile care aparțin primei dintre cele două relații definite și nu celei de-a doua.
Conexiune (naturală) – returnează o relație ale cărei tupluri sunt o combinație de două tupluri (aparținând, respectiv, două relații definite) care au o valoare comună pentru unul sau mai multe atribute comune ale celor două relații (și astfel de valori comune apar o singură dată în tuplul rezultat, nu de două ori).
Divizia -pentru două relații, binare și unare, returnează o relație care conține toate valorile unui atribut al relației binare care se potrivesc (în celălalt atribut) cu toate valorile din relația unară.
LITERATURĂ
1. Data K.J. Introducere în sistemele de baze de date, ediția a 6-a: Trans. din engleza - LA.; M.; St.Petersburg: Editura„Williams”, 2000. – 848 p.
2. Connolly T., Begg K., Strachan A. Baze de date: proiectare, implementare și întreținere. Teorie și practică, ed. a II-a: Trad. din engleza – M.: Editura Williams, 2000. – 1120 p.
3. Karpova T.S. Baze de date: modele, dezvoltare, implementare. – Sankt Petersburg: Peter, 2001. – 304 p.
4. Faronov V.V., Shumakov P.V. Delphi 4. Ghidul dezvoltatorului bazelor de date. – M.: „Cunoașterea”, 1999. – 560 p.
5. J. Groff, P. Weinberg. SQL: Ghid complet: Per. din engleza – K.: BHV Publishing Group, 2001. – 816 p.
6. Ken Goetz, Paul Litwin, Mike Gilbert. Access 2000. Ghidul dezvoltatorului. T.1, 2. Per. din engleza – K.: Grupul Editura BHV, 2000. – 1264 p., 912 p.
7. Maklakov S.V BPwin și EPwin. Instrumente CASE pentru dezvoltarea sistemelor informatice. – M.: DIALOG-MEPhI, 2001. – 304 p.
8. Ullman D., Widom D. Introducere în sistemele de baze de date / Transl. din engleza – M.: „Lori”, 2000. – 374 p.
9. Khomonenko A.D., Tsygankov V.M., Maltsev M.G. Baze de date: Manual pentru învăţământul superior institutii de invatamant/ Ed. Prof. A.D. Khomonenko. – Sankt Petersburg: print CORONA, 2000. – 416 p.
