Arhitectura bazei de date pe trei niveluri. Componente ale unui sistem informatic cu o bază de date și o arhitectură pe trei niveluri a unui sistem de gestionare a bazelor de date

Al treilea nivel al arhitecturii este nivelul intern. O vizualizare internă este o vizualizare de nivel scăzut a întregii baze de date; constă din multe instanțe ale fiecărui tip de înregistrare internă. Termenul „înregistrare internă” aparține terminologiei ANSI/SPARC și se referă la un construct numit înregistrare stocată. Reprezentarea internă, ca și reprezentarea externă și conceptuală, nu este legată de stratul fizic deoarece nu ia în considerare zonele fizice ale dispozitivului de stocare, cum ar fi cilindrii și pistele. Cu alte cuvinte, reprezentarea internă presupune un spațiu de adrese liniar infinit; detaliile despre modul în care spațiul de adrese este mapat la dispozitivul de stocare fizic sunt foarte specifice sistemului și nu sunt incluse în mod intenționat în arhitectura generală.

Reprezentarea internă este descrisă folosind o schemă internă, care definește nu numai diferitele tipuri de înregistrări stocate, ci și indecșii care există, modul în care sunt reprezentate câmpurile stocate, secvența fizică a înregistrărilor stocate etc. Schema internă este scrisă folosind un alt limbaj de definire a datelor - intern.

În concluzie, remarcăm că în unele situații excepționale, programele de aplicație, în special cele numite utilități, pot efectua operațiuni direct la nivel intern mai degrabă decât la nivel extern. Desigur, această practică nu este recomandată; definește riscul din punct de vedere al securității (se ignoră regulile de securitate) și integrității (se ignoră și regulile de integritate), în plus, programul va depinde de datele încărcate; dar uneori aceasta poate fi singura modalitate de a realiza funcția necesară sau de a obține performanța necesară - la fel cum un utilizator al unui limbaj de nivel înalt trebuie uneori să recurgă la limbajul de asamblare din aceleași motive.

Aplicațiile care folosesc baze de date sunt de obicei clasificate într-una dintre arhitecturile software, care au propriile avantaje și dezavantaje.

Bazele de date și software-ul pentru crearea și întreținerea lor (DBMS) au o arhitectură pe mai multe niveluri.

Există niveluri conceptuale, interne și externe de reprezentare a datelor bazei de date, care corespund modelelor cu scopuri similare.

Nivelul conceptual corespunde aspectului logic al prezentării datelor de domeniu într-o formă integrată. Modelul conceptual constă din multe instanțe de diferite tipuri de date, structurate în conformitate cu cerințele SGBD pentru structura logică a bazei de date.

Stratul intern reprezintă organizarea necesară a datelor în mediul de stocare și corespunde aspectului fizic al prezentării datelor. Modelul intern constă din instanțe de înregistrare individuale stocate fizic pe medii externe.

Stratul exterior acceptă vizualizări private ale datelor solicitate de anumiți utilizatori. Modelul extern este un subset al modelului conceptual. Este posibil să se intersecteze modele externe pe baza datelor. Structura de date logice private pentru o anumită aplicație (sarcină) sau utilizator corespunde unui model sau subschemă de bază de date externă. Cu ajutorul modelelor externe este suportat accesul autorizat la datele bazei de date aplicației (compoziția și structura datelor modelului conceptual de bază de date disponibil în aplicație este limitată, iar modurile acceptabile de prelucrare a acestor date sunt specificate: introducere, editare, ștergere, căutare).

Apariția unor noi sau modificări ale nevoilor de informații ale aplicațiilor existente impun definirea unor modele externe corecte pentru acestea, în timp ce nu apar modificări la nivelul modelului conceptual și al datelor interne. Modificările în modelul conceptual, cauzate de apariția de noi tipuri de date sau de modificări ale structurilor, pot să nu afecteze toate aplicațiile, de exemplu. se asigură o anumită independenţă a programelor faţă de date. Modificările în modelul conceptual ar trebui să se reflecte în modelul intern, iar dacă modelul conceptual rămâne neschimbat, este posibil să se modifice independent modelul bazei de date interne pentru a-și îmbunătăți caracteristicile (timpul de acces la date, consumul de memorie al dispozitivelor externe etc. ). Astfel, baza de date implementează principiul independenței relative a organizării logice și fizice a datelor.

Vorbind despre cum ar trebui să fie un produs software atât de complex precum un DBMS, în primul rând este necesar să se definească clar conceptul de bază al sistemului, care determină toate etapele ulterioare ale dezvoltării sale.

Arhitectura SGBD trebuie să asigure, în primul rând, distincția între nivelurile de utilizator și de sistem;

Este necesar să se ofere fiecărui utilizator posibilitatea de a avea o idee proprie, diferită de ceilalți, despre proprietățile datelor stocate.

Apoi, etapa inițială de proiectare a oricărui sistem informatic specific ar trebui să fie descrieri abstracte ale nevoilor de informații ale fiecărui grup de utilizatori, pe baza cărora se generează o descriere abstractă, dar deja comună pentru întreaga organizație, a structurilor datelor stocate și SGBD-ul prin care acest IS va fi creat și suportat trebuie să aibă anumite posibilități pentru aceasta.

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. Proiectarea bazelor de date relaționale.

7. Forme normale de relații.

8. Algebră 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 informațional managementului.

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 gestionare a 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) folosind un 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; permite integrarea și partajarea datelor între 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 simultan pentru mulți utilizatori; 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ă ca funcționalitatea de gestionare a fișierelor sistemului gazdă să fie utilizată pentru a servi diferite aplicații. 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). La nivel superior - aplicații cu propriile reprezentări ale acelorași date fizice. Fiecare vizualizare a bazei de date este o structură logică specifică construită din datele fizice subiacente. Pentru a oferi o interfață între memoria fizică a bazei de date și diferitele sale versiuni logice (mai multe vizualizări suportate), SGBD-ul, la rândul său, trebuie să fie format din mai multe straturi.

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. La 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ă a LCBD sunt foarte importante și necesită o analiză detaliată, deoarece se bazează pe abordare centrat pe date. Elementele de date sunt mai stabile decât funcțiile de sistem efectuate. Crearea unei structuri de date corecte necesită o analiză complexă a claselor de unități de date și a relațiilor dintre acestea. 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ă – există fondurile și experții necesari pentru implementarea cu succes a planului bazei de date?

· fezabilitate economică – pot fi determinate concluzii? Se va amortiza sistemul planificat de la sine? Este posibil să se estimeze costurile și beneficiile?

3. Definirea cerințelor include selectarea obiectivelor bazei de date, clarificarea cerințelor de informații pentru sistem și cerințele pentru hardware și software. Astfel, în această etapă de colectare a datelor și definirea cerințelor, a model informativ general, exprimată în următoarele sarcini:

· Obiectivele sistemului sunt determinate prin analiza nevoilor de informații. 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 formă de 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 – procesul de transformare a unui model conceptual într-o bază de date funcțională. 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 al 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 indecșii 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 executată la un nivel foarte înalt (de exemplu, ca interogare 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 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. Dacă operația este efectuată corect, 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 s-ar fi produs dacă 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 este un 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.

· Un domeniu 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 este un număr fix de atribute de relație:

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).

Relația corporală 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 al domeniilor. 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 tuplu 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 al bazei 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 baze 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 analiza dependențelor funcționale dintre atributele relației. Dependențe funcționale definesc relații stabile între obiecte și proprietățile lor în domeniul subiectului luat în considerare.

Metoda descompunerii 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 unui anumit set de constrângeri, iar o relație este într-o anumită formă normală dacă își satisface setul inerent de constrângeri.

Î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 descompunerile sale complete până când toate sunt î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, cheia primară, legea federală

pe , cheie primară

și, cheie 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, trebuie 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ă deplină de cheia primară).

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 este redusă 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 esențială, 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 cheile potențiale sunt într-o relație și cum sunt interconectate atributele, nu se poate spune că o relație dată este în 5NF sau în alte forme normale.

Cheie posibilă 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ă o parte a modelului relațional și se aplică fiecărei baze de date.

Implementările unor SGBD-uri relaționale specifice în prezent nu folosesc algebră relațională pură sau calcul relațional în forma lor pură. Standardul de facto pentru accesarea datelor relaționale a devenit SQL (Structured Query Language).

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.; Sankt 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.: Grupul Editura BHV, 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. CASE-instrumente 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 instituţiile de învăţământ superior / Ed. Prof. A.D. Khomonenko. – Sankt Petersburg: print CORONA, 2000. – 416 p.

Arhitectura DBMS

Arhitectura bazei de date propusă de grupul de cercetare ANSI/SPARC include trei niveluri: intern, conceptual și extern. În termeni generali, acestea sunt după cum urmează:

Nivel extern

Nivelul extern este nivelul utilizatorului individual. Fiecare utilizator are propriul limbaj de comunicare.

Pentru un programator de aplicații, acesta este unul dintre limbajele de programare comune.

Pentru utilizatorul final, acesta este fie un limbaj de interogare special, fie un limbaj cu scop special, poate bazat pe formulare și meniu, adaptat special cerințelor și susținut de o aplicație on-line.

Nivel conceptual

O vedere conceptuală este o reprezentare a tuturor informațiilor bazei de date într-o formă puțin mai abstractă (cum este cazul unei vederi externe) în comparație cu modul fizic de stocare a datelor. Cu toate acestea, o reprezentare conceptuală este destul de diferită de modul în care datele sunt prezentate oricărui utilizator individual. În general, o viziune conceptuală este o reprezentare a datelor așa cum „sunt cu adevărat”, mai degrabă decât așa cum utilizatorul este forțat să le vadă în cadrul, de exemplu, al unui anumit limbaj sau al hardware-ului utilizat.

O reprezentare conceptuală constă din mai multe instanțe ale fiecărui tip de înregistrare conceptuală. De exemplu, poate consta dintr-un set de instanțe de înregistrare care conțin informații despre indivizi, plus un set de instanțe care conține informații despre părți etc. Înregistrarea conceptuală nu trebuie să coincidă neapărat cu înregistrarea externă, pe de o parte, și cu înregistrarea stocată, pe de altă parte.

O vedere conceptuală este definită folosind o schemă conceptuală, care include definiții pentru fiecare tip de înregistrare conceptuală. O schemă conceptuală folosește un limbaj diferit de definire a datelor, conceptual.

O vedere conceptuală este o reprezentare a întregului conținut al unei baze de date, iar o schemă conceptuală este definiția unei astfel de reprezentări. Cu toate acestea, ar fi o greșeală să presupunem că o diagramă conceptuală nu este altceva decât un set de definiții, mai degrabă ca simple relații între intrările dintr-un program.

Nivel intern

O vizualizare internă este o vizualizare de nivel scăzut a întregii baze de date; constă din multe instanțe ale fiecărui tip de înregistrare internă.

Termenul „înregistrare internă” aparține terminologiei ANSI/SPARC și se referă la un construct numit înregistrare stocată. Reprezentarea internă, ca și reprezentarea externă și conceptuală, nu este legată de stratul fizic deoarece nu ia în considerare zonele fizice ale dispozitivului de stocare, cum ar fi cilindrii și pistele. Cu alte cuvinte, reprezentarea internă presupune un spațiu de adrese liniar infinit; detaliile despre modul în care spațiul de adrese este mapat la dispozitivul de stocare fizic sunt foarte specifice sistemului și nu sunt incluse în mod intenționat în arhitectura generală.

Aplicațiile care folosesc baze de date sunt de obicei clasificate într-una dintre arhitecturile software, care au propriile avantaje și dezavantaje.

Arhitectura locala.

Atât programul, cât și baza de date se află pe același computer. Majoritatea aplicațiilor desktop rulează pe această arhitectură.

Fișier - arhitectură server.

Baza de date este situată pe un computer dedicat (server) puternic, iar computerele personale sunt conectate la acesta printr-o rețea locală. Aceste computere au programe client instalate care accesează baza de date prin rețea. Avantajul acestei arhitecturi este capacitatea mai multor utilizatori de a lucra simultan cu o singură bază de date.

Dezavantajul acestei abordări este volumul mare de informații transmise prin rețea. Toată prelucrarea se face pe partea clientului, unde este de fapt creată o copie a bazei de date. Acest lucru duce la o limitare a numărului maxim posibil de utilizatori și la întârzieri mari atunci când se lucrează cu baza de date. Aceste întârzieri sunt cauzate de faptul că accesul simultan nu este posibil la nivelul tabelului specific. Până când un program de pe unul dintre site-urile client nu termină de lucru cu tabelul (de exemplu, modificarea înregistrărilor), alte programe nu pot accesa acest tabel. Aceasta se numește blocare la nivel de tabel și previne confuzia cu privire la conținutul tabelului.

Arhitectura client - server.

În această arhitectură, serverul nu numai că stochează baza de date, ci rulează și un program DBMS care procesează cererile utilizatorilor și le returnează seturi de înregistrări. În acest caz, programele utilizator nu mai funcționează, de exemplu, cu baza de date ca un set de fișiere fizice, ci apelează la DBMS, care efectuează operațiuni. Acest lucru elimină încărcarea de pe site-urile client, deoarece cea mai mare parte a muncii are loc pe server. SGBD monitorizează automat integritatea și securitatea bazei de date și, de asemenea, controlează accesul la informații folosind un serviciu de parole. SGBD-urile client-server permit blocări la nivel de înregistrare și chiar la nivel de câmp individual. Aceasta înseamnă că orice număr de utilizatori poate lucra cu tabelul, dar numai unul dintre ei are acces la funcția de modificare a unei anumite înregistrări sau a unuia dintre câmpurile acesteia.

Principalul dezavantaj al acestei arhitecturi nu este fiabilitatea foarte mare. Dacă serverul se defectează, toate lucrările se opresc.

Arhitectură distribuită.

Există mai multe servere care rulează într-o rețea, iar tabelele bazei de date sunt distribuite între ele pentru a obține o eficiență sporită. Fiecare server are propria copie a SGBD-ului. În plus, o astfel de arhitectură folosește de obicei programe speciale, așa-numitele servere de aplicații. Acestea vă permit să optimizați procesarea solicitărilor de la un număr mare de utilizatori și să distribuiți uniform sarcina între computerele din rețea.

Dezavantajul arhitecturii distribuite este procesul destul de complex și costisitor de creare și întreținere (administrare) a acesteia, precum și cerințele ridicate pentru servere.

Arhitectura internetului.

Accesul la baza de date și DBMS (distribuit pe același computer sau rețea) se realizează dintr-un browser folosind un protocol standard. Aceasta prezintă

cerințe minime pentru echipamentele clientului. Astfel de programe se numesc „clienți subțiri” deoarece sunt capabili să funcționeze chiar și pe computere slabe; de exemplu, nu trebuie să organizați o rețea locală, ci să accesați serverul prin Internet într-o rețea locală (în acest caz vorbim despre tehnologiile intranet). În acest caz, nu este nevoie să dezvoltați programe speciale pentru clienți sau să veniți cu propriile specificații pentru schimbul de date între server și site-urile client. Este suficient să folosiți browsere gata făcute și soluții software.

Arhitectura DBMS trebuie să asigure, în primul rând, distincția dintre nivelurile de utilizator și de sistem. În prezent, arhitectura cel mai frecvent acceptată este o arhitectură de descriere a bazei de date pe trei niveluri, cu trei niveluri de abstractizare la care baza de date poate fi vizualizată. Această arhitectură include: nivel extern, nivel intern, nivel conceptual.

Scopul principal al arhitecturii pe trei niveluri este de a asigura independența datelor. Esența acestei independențe este că schimbările de la nivelurile inferioare nu afectează nivelurile superioare. Există două tipuri de independență a datelor: logică (înseamnă protecția completă a schemelor externe de modificările aduse schemei conceptuale) și fizică (protecția schemei conceptuale față de modificările aduse schemei interne).

La nivel extern, utilizatorii percep datele, unde grupuri individuale de utilizatori au propria lor vedere (PP) asupra bazei de date. Fiecare tip de utilizator poate folosi propriul limbaj de comunicare pentru a lucra cu baza de date. Utilizatorii finali folosesc fie un limbaj de interogare, fie un limbaj special acceptat de aplicații care invocă afișaje specifice utilizatorului și meniuri personalizate.

Stratul conceptual este stratul intermediar în arhitectura cu trei straturi și oferă o reprezentare abstractă a tuturor informațiilor bazei de date. Descrierea bazei de date la acest nivel se numește o schemă conceptuală, care include obiecte și atributele acestora, relații dintre obiecte, restricții impuse datelor, informații semantice despre date, suport de securitate și integritate a datelor.

Schema internă descrie implementarea fizică a bazei de date și este concepută pentru a obține performanțe optime și pentru a asigura utilizarea eficientă a spațiului pe disc. La nivel intern, SGBD interacționează cu metodele de acces ale sistemului de operare în scopul plasării datelor pe dispozitive de stocare, creării de indexuri, preluare de date etc. La nivel intern sunt stocate următoarele informații: distribuția spațiului pe disc pentru stocare date și indici, descrierea detaliilor de salvare a înregistrărilor, informații despre plasarea înregistrărilor, informații despre compresia datelor și metodele selectate de criptare. Sub nivelul intern se află stratul fizic, care este controlat de sistemul de operare, dar sub îndrumarea DBMS. Stratul fizic ia în considerare modul în care datele vor fi reprezentate în mașină.

Implementarea unei arhitecturi de baze de date pe trei niveluri necesită ca SGBD să transfere informații de la un nivel la altul, adică să transforme adrese și pointeri în nume și relații logice corespunzătoare și invers. Beneficiul unei astfel de traduceri este independența reprezentării logice și fizice a datelor, dar prețul pentru această independență nu este mic - o întârziere mare a sistemului.

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 cu clientul 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ă comunicația hardware între computere și face posibilă colaborarea mai multor utilizatori cu aceeași bază de date.

În SGBD-urile server de fișiere, întreaga bază de date se află de obicei pe unul sau mai multe dispozitive de stocare ale unei mașini suficient de puternice, special dedicate acestor scopuri și conectate constant 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 care lucrează pe un computer client trebuie să găsească informații despre una dintre cărțile disponibile în bibliotecă, atunci întregul fișier care conține informații despre toate cărțile este mai întâi transferat prin rețea și numai atunci sunt găsite informațiile necesare. în copia locală a datelor create în acest fel. Când se lucrează intens cu date de la câteva zeci de utilizatori, lățimea de bandă a rețelei poate fi insuficientă, iar utilizatorul va fi enervat de întârzieri semnificative în răspunsul DBMS la cerințele 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 sarcina rețelei, deoarece clientul comunică cu date printr-un intermediar specializat - un server de baze de date, care este situat 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, o cerere relativ scurtă și o singură înregistrare necesară sunt transmise în rețea, chiar dacă baza de date conține sute de mii de înregistrări. De regulă, o solicitare către un server este formată într-un limbaj special de interogare 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-urile client-server oferă operare sau scalare la sute și mii de locații client.

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ă dezvoltării rapide a Internetului. Pe baza capacităților internetului, sistemele distribuite sunt construite nu numai de organizații la nivel de stat, ci și de întreprinderi comerciale relativ mici, permițând angajaților lor să lucreze cu datele corporative acasă și în călătorii de afaceri.