Elemente structurale ale unei baze de date relaționale. Baza de date relațională - Concepte de bază

Funcții DBMS.

Funcțiile DBMS sunt de nivel înalt și scăzut.

Funcții de nivel înalt:

1. Definirea datelor – folosind această funcție, se determină ce informații vor fi stocate în baza de date (tipul, proprietățile datelor și modul în care acestea vor fi legate între ele).

2. Procesarea datelor. Informațiile pot fi prelucrate în diferite moduri: eșantionare, filtrare, sortare, combinarea unei informații cu alta, calcularea totalurilor.

3. Management de date. Folosind această funcție, specificați cine are permisiunea de a vizualiza datele, de a le corecta sau de a adăuga informații noi și, de asemenea, definiți regulile de acces colectiv.

Funcții de nivel scăzut:

1. Gestionarea datelor din memoria externă;

2. Gestionarea bufferelor RAM;

3. Managementul tranzacțiilor;

4. Introducerea unui jurnal de modificări în baza de date;

5. Asigurarea integritatii si securitatii bazei de date.

Tranzacţie este o secvență indivizibilă de operații care este monitorizată de SGBD de la început până la finalizare și în care, dacă o operație nu este finalizată, întreaga secvență este anulată.

Jurnal DBMS – o bază de date specială sau o parte din baza de date principală, inaccesibilă utilizatorului și utilizată pentru a înregistra informații despre toate modificările aduse bazei de date.

Introducere în jurnalul DBMS este conceput pentru a asigura o stocare fiabilă în baza de date în prezența defecțiunilor hardware și a erorilor, precum și a erorilor în software.

Integritatea bazei de date – aceasta este o proprietate a unei baze de date, ceea ce înseamnă că conține informații complete, consecvente și care reflectă în mod adecvat despre domeniul subiectului.

Clasificarea SGBD.

SGBD-urile pot fi clasificate:

1. După tipul de program:

A. Servere de baze de date (de exemplu, MS SQL Server, InterBase (Borland)) – sunt destinate organizării centrelor de prelucrare a datelor în rețele de calculatoare și implementării funcțiilor de gestionare a bazelor de date solicitate de programele client folosind instrucțiuni SQL (adică programe care răspund solicitărilor);

b. Clienți baze de date – programe care solicită date. PFDBMS, foile de calcul, procesoarele de text și programele de e-mail pot fi utilizate ca programe client;

c. Baze de date complet funcționale (MS Access, MS Fox Pro) – un program care are o interfață dezvoltată care vă permite să creați și să modificați tabele, să introduceți date, să creați și să formatați interogări, să dezvoltați rapoarte și să le imprimați.

2. Conform modelului de date DBMS (precum și baza de date):

A. Ierarhic – bazat pe o structură arborescentă pentru stocarea informațiilor și care amintește de un sistem de fișiere computerizat; principalul dezavantaj este incapacitatea de a implementa o relație multi-la-mulți;

b. Reţea – care le-a înlocuit pe cele ierarhice și nu a durat mult deoarece principalul dezavantaj a fost dificultatea dezvoltării aplicațiilor serioase. Principala diferență dintre o rețea și una ierarhică este că într-o structură ierarhică „descendentul-record” are un singur strămoș, dar într-un descendent de rețea poate avea orice număr de strămoși;

c. Relațional – ale căror date sunt plasate în tabele, între care există anumite legături;

d. Orientat pe obiecte – stochează date sub formă de obiecte iar principalul avantaj atunci când se lucrează cu ele este că li se poate aplica o abordare orientată pe obiecte;

e. Hibrid, adică obiect-relațional – combina capacitățile bazelor de date relaționale și orientate pe obiecte. Un exemplu de astfel de bază de date este Oracle (anterior era relațională).

3. În funcție de locația părților individuale ale SGBD, acestea se disting:

A. local – ale căror toate părțile sunt situate pe un singur computer;

b. reţea.

Rețelele includ:

- cu organizare file-server;

Cu această organizare, toate datele sunt localizate pe un singur computer, care se numește server de fișiere și care este conectat la rețea. Când se găsesc informațiile necesare, se transferă întregul fișier, inclusiv o mulțime de informații redundante. Și numai atunci când se creează o copie locală este găsită înregistrarea necesară.

- cu o organizatie client-server;

Serverul bazei de date primește o solicitare de la client, găsește înregistrarea necesară în date și o transmite clientului. O cerere către server este formată în limbajul de interogare structurat SQL, motiv pentru care serverele de baze de date sunt numite servere SQL.

- SGBD distribuit conțin câteva zeci și sute de servere situate pe o suprafață mare.

Prevederi de bază ale modelului bazei de date relaționale.

Baza de date relațională este o bază de date în care toate datele sunt organizate sub formă de tabele, iar toate operațiunile asupra acestor date sunt reduse la operațiuni pe tabele.

Caracteristicile bazelor de date relaționale:

1. Datele sunt stocate în tabele formate din coloane și rânduri;

2. La intersecția fiecărei coloane și rând există o singură valoare;

3. Fiecare coloană - câmp are propriul nume, care servește ca nume - atribut, iar toate valorile dintr-o coloană au același tip;

4. Coloanele sunt aranjate într-o anumită ordine, care este specificată la crearea tabelului, spre deosebire de rândurile, care sunt aranjate într-o ordine aleatorie. Tabelul poate să nu aibă un singur rând, dar trebuie să aibă cel puțin o coloană.

Terminologia bazelor de date relaționale:

La proiectarea unei baze de date relaționale, datele sunt plasate în mai multe tabele. Relațiile se stabilesc între tabele folosind chei. La conectarea tabelelor, se disting un tabel principal și unul suplimentar (subordonat).

Există următoarele tipuri de relații între tabele:

1. Relație 1:1 (unu la unu) înseamnă că fiecare înregistrare din tabelul principal corespunde unei înregistrări din tabelul suplimentar și, invers, fiecare înregistrare din tabelul suplimentar corespunde unei înregistrări din tabelul principal.

2. Tipul de comunicare 1:M (unu la mulți) înseamnă că fiecare înregistrare din tabelul principal corespunde mai multor înregistrări din tabelul suplimentar și, invers, fiecare înregistrare din tabelul suplimentar corespunde unei singure înregistrări din tabelul principal.

3. Tipul de relație M:1 (mai multe la unul) înseamnă că una sau mai multe înregistrări din tabelul principal corespund unei singure înregistrări din tabelul secundar.

4. Relația M:M (mulți la mulți) – acesta este atunci când mai multe înregistrări ale tabelului principal corespund mai multor înregistrări ale tabelului suplimentar și invers.

5. Componentele de bază ale MS Access.

Principalele componente (obiecte) ale MS Access sunt:

1. Tabele;

3. Formulare;

4. Rapoarte;

5. Macrocomenzi:

Module

Masa este un obiect conceput pentru a stoca date sub formă de înregistrări (rânduri) și câmpuri (coloane). Fiecare câmp conține o parte diferită a unei înregistrări și fiecare tabel este utilizat pentru a stoca informații despre o problemă specifică.

Cerere – o întrebare despre datele stocate în tabele sau instrucțiuni pentru selectarea înregistrărilor care urmează să fie modificate.

Formă este un obiect în care puteți plasa controale destinate introducerii, afișarii și modificării datelor în câmpurile tabelului.

Raport este un obiect care vă permite să prezentați informații definite de utilizator într-o anumită formă, să le vizualizați și să le imprimați.

Macro – una sau mai multe macrocomenzi care pot fi folosite pentru a automatiza o anumită sarcină. O macrocomandă este elementul de bază al unei macrocomenzi; o instrucțiune de sine stătătoare care poate fi combinată cu alte instrucțiuni macro pentru a automatiza finalizarea unei sarcini.

Modul – un set de descrieri, instrucțiuni și proceduri stocate sub un singur nume. MS Access are trei tipuri de module: modul formular, modul raport și modul general. Modulele formulare și rapoarte conțin program local pentru formulare și rapoarte.

6. Tabele în MS Access.

MS Access are următoarele metode pentru a crea tabele:

1. Modul de masă;

2. Constructor;

3. Expert tabel;

4. Import tabele;

5. Comunicarea cu tabelele.

ÎN modul de masă Datele sunt introduse într-un tabel gol. Pentru introducerea datelor este furnizat un tabel cu 30 de câmpuri. După salvarea acestuia, MS Access decide însuși ce tip de date să atribuie fiecărui câmp.

Constructor oferă posibilitatea de a crea în mod independent câmpuri, de a selecta tipuri de date pentru câmpuri, de dimensiunile câmpurilor și de a seta proprietățile câmpului.

Pentru a defini un câmp în mod Constructor sunt intrebati:

1. Numele domeniului , care în fiecare tabel trebuie să aibă un nume unic, care este o combinație de litere, cifre, spații și caractere speciale, cu excepția " .!” “ " Lungimea maximă a numelui este de 64 de caractere.

2. Tip de date definește tipul și intervalul de valori valide, precum și cantitatea de memorie alocată pentru acest câmp.

Tipuri de date MS Access

3. Cele mai importante proprietăți ale câmpului:

- Dimensiunea campului specifică dimensiunea maximă a datelor stocate în câmp.

- Format câmp este un format pentru afișarea unui anumit tip de date și stabilește regulile de prezentare a datelor atunci când le afișează pe ecran sau le imprimă.

- Semnătura câmpului setează textul care este afișat în tabele, formulare și rapoarte.

- Condiție de valoare vă permite să controlați intrarea, stabilește restricții asupra valorilor introduse, dacă condițiile sunt încălcate, interzice introducerea și afișează textul specificat de proprietatea Mesaj de eroare;

- Mesaj de eroare setează textul mesajului afișat pe ecran atunci când sunt încălcate restricțiile specificate de Condiția de valoare.

Tip control– o proprietate care este setată în fila Înlocuire din fereastra de proiectare a tabelului. Această proprietate determină dacă câmpul va fi afișat în tabel și sub ce formă - ca câmp sau casetă combinată.

Cheie unică (primară). tabelele pot fi simple sau complexe, incluzând mai multe câmpuri.

Pentru a defini o cheie, selectați câmpurile care alcătuiesc cheia și faceți clic pe butonul din bara de instrumente câmp cheie sau comanda este executată Câmp de editare/cheie.

©2015-2019 site
Toate drepturile aparțin autorilor lor. Acest site nu pretinde autor, dar oferă o utilizare gratuită.
Data creării paginii: 2016-02-16

Nivelul 1: Nivelul modelelor externe este cel mai înalt nivel în care fiecare model are propria sa viziune asupra datelor. Acest strat definește punctul de vedere al bazei de date a aplicațiilor individuale.

Nivel conceptual: Legătura centrală de control, unde baza de date este prezentată în cea mai generală formă, care combină datele utilizate de toate aplicațiile. De fapt, nivelul conceptual reflectă un model generalizat al disciplinei.

Stratul fizic (bază de date): Acestea sunt datele în sine aflate în fișiere sau în structuri de pagină situate pe medii de stocare externe.

Modele de date

Se disting următoarele modele de date:

1. Infologic

2. Data logică

3. Fizic

Procesul de proiectare a bazei de date începe cu proiectarea unui model de informații. Un model de date infologice este o descriere informală generalizată a bazei de date care este creată, realizată folosind limbaj natural, formule matematice, tabele, grafice și alte instrumente care sunt înțelese de toți oamenii care lucrează la proiectarea bazei de date.

Tuplu de domeniu

Modelul informațional reflectă lumea reală într-un concept ușor de înțeles de om, complet independent de mediul de stocare a datelor. Prin urmare, modelul de infologie nu ar trebui să se schimbe până când unele schimbări în lumea reală necesită o schimbare în afara definiției, astfel încât modelul să continue să reprezinte domeniul.

Există multe abordări pentru construirea acestui model: modele grafice, rețele semantice, conexiune-entitate și altele.

Model datalogic

Modelul infologic trebuie să fie afișat într-un model datalogic care să fie înțeles de SGBD. Un model datalogic este o descriere formală a unui model de informații în limbajul DBMS.

Model ierarhic

Acest model este o colecție de elemente înrudite care formează o structură ierarhică. Conceptele de bază ale ierarhiei includ nivelul, nodul și relația.

nivelul de comunicare

Un nod este o colecție de atribute de date care descriu un obiect. Fiecare nod este conectat la un nod la un nivel superior și la orice număr de noduri la un nivel inferior. Excepția este nodul de cel mai înalt nivel. Numărul de arbori din baza de date este determinat de numărul de rădăcini ale copacilor. Fiecare înregistrare a bazei de date are o singură cale de la înregistrarea rădăcină. Un exemplu simplu este sistemul de nume de domeniu de Internet\adresă. Pe primul nivel (rădăcina copacului) se află planeta noastră, pe al doilea Țara, pe al treilea Regiunea, pe al patrulea - așezarea, strada, casa, apartamentul. Un reprezentant tipic este un DBMS de la IBM - IMS.

Toate instanțele unui tip descendent dat cu o instanță comună a unui tip de strămoș sunt numite gemeni. O ordine de parcurgere completă este definită pentru baza de date. De sus în jos și de la dreapta la stânga.

Modelul fizic

Un model fizic este construit pe baza modelului datalogic. Organizarea fizică a datelor are un impact major asupra performanței bazei de date. Dezvoltatorii DBMS încearcă să creeze cele mai productive modele de date fizice, oferind utilizatorilor unul sau altul instrument pentru a personaliza modelul pentru o anumită bază de date.

Exemplu: În special pentru o bază de date relațională, aceasta ia deja în considerare:

1. Aspecte fizice ale stocării tabelelor în fișiere specifice.

2. Crearea de indici care optimizează viteza operațiunilor de date folosind aplicația.

3. Efectuarea diferitelor acțiuni asupra datelor asupra anumitor evenimente definite de utilizatori folosind declanșatoare și proceduri stocate.

Modele fizice

Pentru toate nivelurile și pentru orice metodă de reprezentare a unui domeniu, există o codificare a conceptelor de relații dintre concepte. Etapa cheie în dezvoltarea oricărui sistem informațional este efectuarea unei analize de sistem:

Formalizarea disciplinei și reprezentarea sistemului ca ansamblu de componente.

Compoziția ca bază a analizei sistemului poate fi funcțională (construirea unei ierarhii).

Cu toate acestea, în majoritatea sistemelor, când vine vorba de baze de date, tipurile de date sunt un element mai static decât modul în care sunt procesate. Prin urmare, metode de analiză a sistemului, cum ar fi diagrama fluxului de date, au primit o dezvoltare intensivă. Dezvoltarea bazelor de date relaționale. A stimulat dezvoltarea metodologiilor de dezvoltare a datelor, în special diagramele ER ER. Modelul de date relațional folosește în mod direct conceptul de relație ca o mapare. Este cel mai apropiat de modelul conceptual de reprezentare a datelor. Și adesea se află în centrul acesteia.

Spre deosebire de teoreticianul modelului de graf, în modelul relațional, conexiunile dintre relații sunt implementate într-un mod neexplicit, pentru care se folosesc chei de relație. De exemplu, relațiile de tip ierarhic sunt implementate prin mecanismul cheilor primare și străine, când faptul de atribute trebuie să fie prezent în relația de subordonare.

Un astfel de atribut al relațiilor din relația principală va fi numit cheie primară, iar într-o relație subordonată, una secundară.

Progresul în dezvoltarea limbajelor de programare asociate în primul rând cu tastarea datelor și apariția limbajelor orientate pe obiecte a făcut posibilă abordarea analizei sistemelor complexe din punctul de vedere al reprezentărilor ierarhice, adică folosind clase de obiecte cu proprietăți de polimorfism, moștenire și încapsulare.

RELAȚIA ESTE O TABELĂ.

Ștergerea a ceea ce ați creat și

Editare.

Modelul bazei de date relaționale

Modelele de date relaționale au câștigat în prezent cea mai mare popularitate tocmai pentru această reprezentare a datelor.

Modelul relațional poate fi gândit ca o metodă specială de reprezentare a datelor care conține propriile date (sub formă de tabele) și modalități de lucru și manipulare a acestora (sub formă de relații). Modelul relațional presupune trei elemente conceptuale: Structură, Integritate și Procesarea datelor. Aceste elemente au propriile lor concepte obligatorii care trebuie explicate pentru prezentare ulterioară.

Tabelul este considerat ca un depozit de date direct. În mod tradițional, în sistemele relaționale se numește un tabel atitudine. Se numește un rând de tabel caravană, și coloana atribut. În acest caz, atributele au nume unice (în cadrul relației).

Numărul de tupluri dintr-un tabel este numit numar cardinal. Numărul de atribute grad. Se stabilește un identificator unic pentru o relație, adică unul sau mai multe atribute ale căror valori nu sunt aceleași în același timp - identificatorul se numește cheie primară.Domeniu acesta este setul de valori omogene valide pentru un anumit atribut. Astfel, un domeniu poate fi considerat ca un set de date numit, iar componentele acestui set sunt unități indivizibile din punct de vedere logic (de exemplu, o listă de nume de angajați ai unei instituții poate acționa ca un domeniu, dar nu toate numele pot fi prezente in masa).

Atitudine

atribute

Câmpurile KOD, NAME, SUMM sunt atribute de tabel conținute în antet.

Perechile KOD 5216, NAME Kireeva, SUMM 25.50 sunt elemente ale corpului relației.

În bazele de date relaționale, spre deosebire de alte modele, utilizatorul specifică ce date este nevoie pentru el și nu cum să o facă. Din acest motiv, procesul de mutare și navigare a unei baze de date în sisteme relaționale este automat, iar această sarcină este efectuată într-un SGBD. optimizator. Sarcina sa este de a prelua datele din baza de date la cerere în cel mai eficient mod. Astfel, optimizatorul trebuie să poată determina cel puțin din ce tabele sunt selectate datele, câte informații sunt în aceste tabele și care este ordinea fizică a înregistrărilor din tabele și cum sunt grupate.

În plus, o bază de date relațională îndeplinește și funcții de director. Directorul stochează o descriere a tuturor obiectelor care alcătuiesc baza de date: tabele, indecși, declanșatoare etc. Evident, o componentă precum optimizatorul este vitală pentru buna funcționare a întregului sistem. Optimizatorul folosește informațiile stocate în director. Un fapt interesant este că catalogul în sine este un set de tabele, astfel încât SGBD-ul îl poate manipula în moduri tradiționale, fără a recurge la vreo tehnici sau metode speciale.

Domenii și relații

Definiții de bază: Domenii, tipuri de relații, predicate.

Relațiile au o serie de proprietăți de bază:

1. În cel mai general caz, nu există tuple comune în relații - acest lucru rezultă din însăși definiția relațiilor. Cu toate acestea, pentru unele SGBD-uri, în unele cazuri sunt permise abateri de la această proprietate. Atâta timp cât există o cheie primară în relație, tuplurile identice sunt excluse.

2. Tuplurile nu sunt ordonate de sus în jos - pur și simplu nu există un concept de număr pozițional într-o relație. În relații, fără a pierde informații, puteți aranja cu succes tupluri în orice ordine.

3. Atributele nu sunt ordonate de la stânga la dreapta. Atributele din antetul relației pot fi aranjate în orice ordine fără a compromite integritatea datelor. Prin urmare, nici conceptul de număr pozițional în raport cu un atribut nu există.

4. Valorile atributelor constau din unități logic indivizibile - acest lucru rezultă din faptul că valorile sunt preluate din domenii, în caz contrar, putem spune că relațiile nu conțin grupuri de repetiție; Adică sunt normalizate.

Sistemele relaționale suportă mai multe tipuri de relații:

1. Cele numite sunt variabile de relație definite în SGBD de către operatorii de creație și, de regulă, necesare pentru o prezentare mai convenabilă a informațiilor pentru utilizator.

2. Relațiile de bază sunt o parte direct importantă a bazei de date, astfel încât în ​​timpul proiectării le este dat propriul nume.

3. O relație derivată este una care a fost definită prin alte relații, de obicei de bază, prin utilizarea instrumentelor DBMS.

4. Această reprezentare este de fapt o relație numită derivată, iar reprezentarea este exprimată exclusiv prin operatori DBMS aplicați relațiilor numite, deci nu există fizic în baza de date.

5. Rezultatul interogărilor este o relație derivată fără nume care conține date (rezultatul unei anumite interogări). Rezultatul nu este stocat în baza de date, dar există atâta timp cât utilizatorul are nevoie de el.

6. O relație stocată este una care este menținută fizic în memoria relațiilor stocate cel mai adesea includ baza relațiilor; Pe baza celor de mai sus, putem defini o bază de date relațională ca un set de relații interconectate.

O conexiune în acest caz este o asociere a două sau mai multe relații.

Conexiuni ternare

Integritatea datelor

În modelele relaționale, problemei integrității datelor i se acordă un loc special. Amintiți-vă că o cheie sau o cheie potențială este un set minim de atribute ale căror valori pot fi folosite pentru a găsi în mod unic tuplul necesar înseamnă că excluderea oricărui atribut din set nu permite identificarea tuplului prin atributele rămase;

Fiecare relație are cel puțin o cheie posibilă. Una dintre ele este luată ca cheie primară.

Atunci când alegeți o cheie primară, ar trebui să se acorde preferință cheilor non-compozite sau cheilor formate dintr-un set minim de atribute. De asemenea, nu este de dorit să folosiți chei cu valori de text lungi (este de preferat să folosiți atribute întregi ca chei). Deci, pentru a identifica un angajat, puteți utiliza fie un număr unic de personal, fie un număr de pașaport, fie un set de nume de familie, nume de mijloc și numere de departament. Nu este permis ca cheia primară a unei relații, adică orice atribut care participă la cheia primară, să ia valori nedefinite. În acest caz, va apărea o situație contradictorie ( coliziune): Apare un element cheie primară neunică. Prin urmare, acest lucru ar trebui monitorizat cu atenție atunci când proiectați o bază de date.

Despre cheile externe. Este de remarcat faptul că, deoarece relația C leagă relațiile B și A, trebuie să includă chei străine corespunzătoare cheilor primare ale relațiilor A și B.

Cheia externă a unui tabel este formată folosind mai multe chei primare ale altor tabele.

Astfel, când luăm în considerare problema alegerii unei metode de conectare a unei relații într-o bază de date, se pune întrebarea care ar trebui să fie cheile străine. În același timp, pentru fiecare cheie străină este necesar să se rezolve problema asociată cu posibilitatea (sau imposibilitatea) apariției unor valori nedefinite în cheile străine (NULL - valori - valoare de atribut pentru informațiile lipsă). Cu alte cuvinte, poate exista un tuplu într-o relație pentru care tuplu în relațiile sale asociate nu este cunoscut?

Pe de altă parte, este necesar să ne gândim în avans la ceea ce se va întâmpla atunci când eliminați tuplurile dintr-o relație la care face referire o cheie străină. Există următoarele posibilități posibile:

· Operațiune cascade– adică ștergerea tuplurilor din relații duce la ștergerea tuplurilor asociate relației. De exemplu, ștergerea informațiilor despre nume, prenume etc. angajatul într-o privință duce la ștergerea salariului în altă privință;

· Operațiune limitat - adică numai acele tupluri pentru care nu există alte informații asociate sunt eliminate. Nu toate informațiile sunt șterse (nu în toate privințele), deoarece acestea pot fi utilizate și în altă privință, eliminarea informațiilor în care duce la o încălcare a integrității datelor. Dacă astfel de informații sunt disponibile, ștergerea nu poate fi efectuată, de exemplu, ștergerea informațiilor despre prenume, prenume etc. angajatul este posibil numai dacă nu există informații legate de salariul său.

Este necesar să oferiți tehnologie pentru ceea ce se va întâmpla atunci când încercați să actualizați cheia primară a unei relații la care face referire o cheie străină. Aici aveți aceleași opțiuni ca atunci când ștergeți:

· Operația este în cascadă, adică atunci când cheia primară este actualizată, cheia externă din relația aferentă este actualizată. De exemplu, actualizarea cheii primare într-o relație în care sunt stocate informații despre angajați duce la o actualizare a cheii străine într-o relație care conține informații despre salariu.

· Operația se limitează la actualizarea doar a acelor chei primare pentru care altfel nu există informații asociate. Dacă astfel de informații sunt disponibile, actualizarea nu poate fi făcută. De exemplu, actualizarea cheii primare într-o relație în care sunt stocate informații despre un angajat este posibilă numai dacă informațiile despre salariul său lipsesc în relația aferentă.1

Algebră relațională

Baza formală a modelului bazei de date relaționale este algebra relațională, bazată pe teoria mulțimilor și luând în considerare un operator special asupra relațiilor, și calculul relațional bazat pe logica matematică.

Trebuie remarcat faptul că algebra relațională este foarte puternică - interogările complexe ale bazelor de date pot fi exprimate folosind o singură expresie. Din acest motiv, aceste mecanisme sunt incluse în modelul de date relaționale. Orice interogare exprimată folosind o expresie de algebră relațională sau o formulă de calcul relațional poate fi exprimată folosind un operator în acest limbaj.

Algebra relațională are o proprietate importantă - este închisă față de conceptul de relație. Aceasta înseamnă că o expresie de algebră relațională este efectuată asupra relațiilor bazelor de date relaționale și rezultatele calculului acestora reprezintă, de asemenea, relații.

Ideea principală a algebrei relaționale este că mijloacele de manipulare a relațiilor considerate ca o mulțime se bazează pe operații multiple tradiționale completate de unele operații specifice bazei de date.

Să descriem versiunea de algebră care a fost propusă de CODD. Operațiunea constă din 8 operatori principali:

Preluare relație (operație unară)

Proiecția relației (operație unară)

· Fuzionarea relațiilor

· Intersecția relațiilor (operație binară)

· Scăderea rapoartelor

Produsul relațiilor

· Relații de legătură

· Împărțirea relațiilor

Aceste operațiuni pot fi explicate după cum urmează:

· Rezultatul selectării unei relații bazate pe o anumită condiție este o relație care include doar acele tupluri ale relației originale care îndeplinesc această condiție.

· La proiectarea unei relații pe un set dat de atribute ale acesteia, se va obține o relație ale cărei tupluri sunt luate din tuplurile corespunzătoare primei relații.

· La efectuarea operației de îmbinare a două relații se va obține o relație care include toate tuplurile incluse în cel puțin una dintre relațiile care participă la operație.

· La efectuarea operației de intersecție a două relații se va obține o relație care include toate tuplurile incluse în ambele relații inițiale.

· La efectuarea operației de scădere a două relații se va obține o relație care include toate tuplurile incluse în prima relație, cu excepția celor care sunt incluse și în a doua relație.

· La efectuarea produsului direct a două relaţii se obţine o relaţie ale cărei tupluri sunt o combinaţie a tuplurilor primei şi celei de-a doua relaţii.

· Când două relații sunt conectate în funcție de o anumită condiție, se formează o relație rezultată de tupluri ale căror tupluri sunt o combinație de tupluri ale primei și celei de-a doua relații care îndeplinesc această condiție.

· Operația de împărțire relațională are doi operanzi – o relație binară (formată din două atribute) și o relație unară (formată dintr-un atribut). Rezultatul operației este o relație constând din tupluri, inclusiv relația primului atribut de tupluri din prima relație și astfel încât setul de valori al celui de-al doilea atribut să coincidă cu setul de valori al celui de-al doilea atribut. .

Pe lângă cele de mai sus, există o serie de operațiuni speciale specifice lucrului cu baze de date:

· Ca rezultat al operației de redenumire, o relație este un set de tupluri care coincide cu corpul relației originale, dar numele atributelor au fost schimbate.

Rezultă că rezultatul unei operații relaționale este o anumită relație este posibil să se formeze expresii relaționale în care, în loc de relația originală (operand), se va folosi o expresie relațională încorporată. Acest lucru se datorează faptului că operațiile algebrei relaționale sunt cu adevărat închise conceptului de relație. Să începem cu operația unificarea relaţiilor, cu toate acestea, acest lucru se aplică în mod egal la operațiile de intersecție și combinare, adică în algebra relațională, rezultatul operației de unire este o relație. Dacă presupunem în algebra relaţională posibilitatea asociațiile arbitrare două relații cu seturi diferite de atribute, atunci rezultatul unei astfel de operații va fi o mulțime, dar un set de tupluri de diferite tipuri, adică, în general, nu o relație. Dacă pornim de la cerința ca algebra relațională să fie închisă în raport cu conceptul de relație, atunci o astfel de operație asociațiile este lipsit de sens. Aceasta duce la apariția conceptului compatibilitatea relațiilor De unificare: Două relații sunt compatibile doar dacă au aceleași antete, adică au același set de nume de atribute, iar atributele cu același nume sunt definite în același domeniu.

Cu condiția ca două relații să fie compatibile în unirea lor, atunci când operația de unire, intersecție și scădere este efectuată în mod normal asupra lor, rezultatul operației este o relație cu un antet corect definit care se potrivește cu antetul fiecăruia dintre relațiile operandului. Dacă două relații nu sunt pe deplin compatibile cu îmbinarea, adică compatibile în toate, cu excepția numelor de atribute, atunci înainte de a efectua o operație de tip de îmbinare, aceste relații pot fi făcute compatibile pe deplin cu îmbinarea prin aplicarea unei operații de redenumire.

Funcționarea produsului direct al două relații ridică noi probleme. În teoria mulțimilor, produsul direct poate fi obținut pentru orice mulțime. Elementele setului rezultat vor fi perechi formate din elemente ale primului și celui de-al doilea set. Deoarece relațiile sunt mulțimi, pentru oricare două relații este posibil să se obțină un produs direct. Cu toate acestea, rezultatul nu va fi o relație. Elementele rezultatului nu vor fi tupluri, ci perechi de tupluri. Prin urmare, în algebra relațională, se utilizează o formă specială a operațiunii de luare a unui produs direct - produsul direct extins al relațiilor. Atunci când se ia produsul direct extins a două relații, elementul relației rezultate este un tuplu format prin fuzionarea unui tuplu din prima relație și un tuplu din a doua relație. Imediat apare o a doua problemă legată de obținerea unui antet corect format al relației rezultate, aceasta duce la necesitatea introducerii conceptului de compatibilitate relațională prin luarea unui produs direct extins.

Două relații sunt compatibile prin luarea unui produs direct numai dacă setul de nume de atribute ale acestor relații nu se intersectează. Orice două relații pot fi convertite într-o formă de produs direct compatibil, aplicând o operație de redenumire uneia dintre relații.

Operația de preluare necesită două relații: o relație inițială, operandul și o condiție simplă de constrângere. În urma operației de selecție, se produce o relație al cărei cap coincide cu antetul relației de operand, iar corpul include acele tuple ale relației de operand care satisfac valorile condiției de constrângere.

Să introducem un număr de operatori.

Fie unire să însemne operația de unire, intersectare – operația de intersecție, minus – operația de scădere. Pentru a desemna operația de eșantionare, vom folosi construcția A unde B, unde A este relația operandului și B este o condiție simplă de comparație. Fie C1 și C2 două condiții simple de eșantionare

A unde C1 ȘI C2 este identic (A unde C1) se intersectează (A unde C2)

A unde C1 SAU C2 este identică cu (A unde C1) uniunea (A unde C2)

A unde C1 nu C2 este identic cu (A unde C1) minus (A unde C2)

Folosind aceste definiții, este posibilă implementarea operațiunilor de eșantionare în care condiția de eșantionare este o expresie logică arbitrară compusă din condiții simple folosind conexiuni logice (și, sau, nu). Operația de preluare a proiecțiilor relației A pe lista de atribute a1, a2,…,an va fi o relație al cărei cap este mulțimea de atribute, a1,a2,…,an. Corpul rezultatului va fi format din tupluri pentru care în relația A există un tuplu, atributul a1 are valoarea b1, atributul a2 are valoarea b2< и так далее атрибут an – bn. По сути при выполнении операции проекции определяется «Вертикальная» вырезка отношения - операнда с удалением возникающих кортежей –дубликатов.

Operația de îmbinare, numită uneori îmbinare condiționată, necesită doi operanzi, relațiile fiind unite și un al treilea operand, condiția simplă. Fie conectate relația A și B Ca și în cazul operației de selecție, condiția de îmbinare C are forma, (a comp –op b) sau (a comp –op const) unde A și B sunt numele de. atribute ale relațiilor A și B, const este literalmente specificată constantă. Comp-op este o operațiune de comparație validă în acest context. Atunci, prin definiție, rezultatul operației de conectare este relația obținută prin efectuarea operației de restricție, conform condiției C, produsul direct al relației A și B.

Există un caz special important de legătură, legătura naturală. O operație de îmbinare se numește operație de îmbinare naturală dacă condițiile de îmbinare sunt de forma (a=b) unde a și b sunt atribute ale operanzilor de îmbinare diferiți. Acest caz este important deoarece este deosebit de comun în practică și există algoritmi de implementare eficienți pentru acesta într-un SGBD. Operația natural join se aplică unei perechi de relații A și B care au un atribut comun P, adică un atribut cu același nume și definit pe același domeniu. Fie ab să desemneze uniunea antetelor relațiilor A și B. Atunci o îmbinare naturală este rezultatul îmbinării lui A și B proiectate pe ab. Operațiile de îmbinare naturală nu sunt incluse direct în setul de operații algebrei relaționale. dar au o semnificație practică foarte importantă.

Operația de împărțire a relațiilor necesită o explicație mai detaliată deoarece este greu de înțeles. Să fie date două relații A (a1,a2,..,an,b1,b2,…,bm)

B (b1,b2,…,bn) Presupunem că atributul b1 al relației A și atributul b1 al relației B sunt definite pe același domeniu. Să numim mulțimea de atribute (aj) un atribut compus a, iar mulțimea (bj) c un atribut compus b. După aceasta, vom vorbi despre împărțirea relațională a relației binare A (a,b) în relația unară B (b).

Rezultatul împărțirii lui A la B este o relație unară C (a), constând din tupluri v astfel încât în ​​relația A există tupluri care în setul de valori (w) includ setul de valori ale lui b în raport cu B.

Deoarece împărțirea este cea mai dificilă operațiune, să o explicăm cu un exemplu. Să existe două relații în baza de date a studenților: STUDENTI (NUME COMPLET, NUMĂR) și NUME (NUME COMPLET), iar relația unară NUME conține toate numele pe care le au studenții institutului. Apoi, după efectuarea operației de împărțire relațională a relației STUDENTI în relația NUME, se va obține o relație unară care să conțină numerele de carnete de studenți aparținând studenților cu toate prenumele posibile la acest institut.

Notație relațională

Să presupunem că există o bază de date cu structura STUDENTI (număr, nume, bursă, cod grup) și relația GRUPURI (gr_nom, gr_kol, gr vechi) Să presupunem că trebuie să aflați numele și numerele studenților. bilete pentru studenții care sunt prefecți ai grupelor cu mai mult de 25 de persoane În algebra relațională, trebuie să întreprindeți următoarele acțiuni pentru o astfel de solicitare:

1. Conectați relațiile STUDENTI și GRUPURI, conform condiției „număr_elev = stea_grup”;

2. Limitați raportul rezultat prin condiția gr_col>25.

3. Proiectați rezultatul operației anterioare pe atributul student_name, student_number.

Iată o formulare pas cu pas a secvenței de execuție a interogării în baza de date, fiecare dintre acestea corespunzând unei singure operații relaționale. dacă formulăm aceeași interogare folosind calculul relațional, atunci am obține o formulă care poate fi citită: Emite STUDY_NAME și STUDY_NUMBER pentru astfel de studenți, astfel încât un astfel de grup GR_STAR și valoarea GR_NUM>25 să coexiste. În a doua formulare, am indicat doar caracteristicile relației rezultate, dar nu am spus nimic despre metoda de formare a acesteia. În acest caz, SGBD însuși trebuie să decidă ce fel de operațiuni și în ce ordine trebuie efectuate asupra relațiilor STUDENTI și GRUPURI. Ambele metode discutate în exemplu sunt de fapt echivalente și nu există conversii foarte complexe de la una la alta.

Conceptele de bază ale calculului relațional sunt conceptele unei variabile cu o anumită zonă a valorii sale și conceptele unei formule corect construite bazate pe variabile și funcții speciale. Funcții. Care este domeniul de definire al unei variabile diferă între calculul tuplu și calculul domeniului, adică de-a lungul sau peste. În calculul tuplilor, domeniul definiției variabilei este relația bazei de date, adică valoarea validă a fiecărei variabile este un tuplu al unei relații. În calculul domeniului, domeniile de definire a variabilei sunt domeniile pe care sunt definite atributele relațiilor de baze de date, adică valoarea validă a fiecărei variabile este valoarea fiecărei variabile.

Comanda RANGE este folosită pentru a defini tupluri. De exemplu, pentru a defini variabila STUDENT al cărei scop este STUDENTS, trebuie să utilizați construcția RANGE STUDENT IS STUDENTS. Din această definiție rezultă că în orice moment al timpului variabila student reprezintă un anumit tuplu al relației STUDENTI. Când utilizați variabile tuple în formule, puteți face referire la valorile atributelor variabilelor. De exemplu, pentru a face referire la valoarea atributului STUDENT_NAME al variabilei STUDENT, trebuie să utilizați construcția STUDENT.STUDENT_NAME.

Formulele construite corect sunt folosite pentru a exprima condițiile impuse variabilelor tuple. Astfel de formule se bazează pe comparații simple, care sunt operații de comparare a valorilor atributelor variabilelor și constantelor literale. De exemplu, construcția STUDENT.STUD_NOM=123456. Este o comparație simplă. O versiune mai complexă a formulelor compuse folosește conexiuni logice AND, OR, NOT, IF...THEN. În cele din urmă, este posibil să se construiască formule bine formate folosind cuantificatori. Dacă F este o formulă bine formată care implică variabila var, atunci construcția EXIST (cuantificator de existență) ​​var (F) și FORALL (pentru toate tuplurile) var (F) sunt corecte.

Variabilele incluse în formulele corect construite pot fi libere sau legate. Toate variabilele incluse în componența lor în timpul construcției cărora nu s-au folosit cuantificatori sunt libere. Aceasta înseamnă că dacă pentru un set de valori ale variabilelor tuple libere se obține valoarea „adevărată” la calcularea formulelor, atunci aceste valori pot fi incluse în relația rezultată. Dacă se folosește un cuantificator la construirea formulelor, atunci variabilele sunt legate. Atunci când se calculează valoarea unei astfel de formule corect construite, nu se utilizează o singură valoare a variabilei asociate, ci întregul său domeniu de definire.

1)EXISTĂ STUD2 (STUD.1STUD_STIP> STUD2.STUD_STIP)

2) FORALL STUD2 (STUD.1STUD_STIP> STUD2.STUD_STIP)

Fie STUD1 și STUD2 două variabile tuplu definite pentru relația elevi, atunci formula pentru tuplu curent al variabilei STUD1 ia valoarea adevărată numai dacă în întreaga relație elevi există un astfel de tuplu asociat cu variabila STUD2 astfel încât valoarea atributului său STUD_STIP satisface condiția de comparație internă. Formula corect construită nr. 2 pentru tuplul construit STUDENT 1 ia valoarea adevărată dacă pentru toate tuplurile relația STUDENTS asociată variabilei STUDENT 2, valoarea atributului STUDENT.STIP satisface condiția internă.

Astfel, formulele bine formate oferă un mijloc de exprimare a condițiilor de eșantionare dintr-o relație de bază de date. Pentru a putea folosi calculul relațional pentru a lucra efectiv cu o bază de date, este necesară o altă componentă care determină setul și numele coloanelor relației rezultate. Această componentă se numește lista tinta.

Lista țintelor are forma:

· Var.attr este numele unei variabile libere, attr este numele atributului relației pe care este definită variabila var.

· Var care este echivalent cu relația din listă, Var.attr1, Var.attr1... Var.attr№ include numele tuturor atributelor relației definitorii.

· Nume_nou = var.attr; noul nume al atributului corespunzător relației rezultate.

Ultima opțiune este necesară în cazurile în care codul din formulă folosește mai multe variabile libere cu același domeniu. În calculul domeniului, domeniul de definire a domeniilor nu este relațiile, ci domeniile. În raport cu baza de date STUDENTS GROUP, putem vorbi despre variabilele de domeniu NUME (Valorile de domeniu sunt nume valide sau NOM STUD). (Valorile domeniului sunt numere de student valide).

Principala diferență dintre calculul de domeniu și calculul tuplu este prezența unui set suplimentar de predicate care fac posibilă exprimarea așa-numitelor condiții de apartenență. Dacă R este o relație n-ară cu atribute (a1, a2, … an), atunci condiția de apartenență are forma R(ai1:Vi1,ai2:Vi2,...aim:Vim) unde (m<=n). Где в Vij это либо литерально заданная константа либо имя кортежной переменной. Условие членства принимает значение истина, только в том случае если в отношении R существует кортеж, содержащий следующие значения указанных атрибутов. Если от Vij константа то на атрибут aij накладывается жёсткое условие независящее от текущих доменных переменных. Если же Vij имя доменной переменной то условие членства может принимать различные значения при разных значениях этой переменной.

Un predicat este o funcție logică care returnează adevărat sau fals pentru un argument. O relație poate fi considerată ca un predicat cu argumente care sunt atribute ale relației în cauză. Dacă un anumit set specific de tupluri este prezent în relație, atunci predicatul va produce un rezultat adevărat, altfel va produce un rezultat fals.

În toate celelalte privințe, formulele și expresiile calculului de domeniu arată similar cu formulele și expresiile calculului tuplu. Evaluarea domeniului relațional este baza pentru majoritatea interogărilor de limbaj bazate pe formulare.

Informații conexe.

Un model de date este un set de structuri de date și operațiuni pentru prelucrarea lor. Folosind un model de date, puteți reprezenta vizual structura obiectelor și relațiile stabilite între ele. Terminologia modelului de date este caracterizată de conceptele de „element de date” și „reguli obligatorii”. Un element de date descrie orice set de date, iar regulile de asociere definesc algoritmi pentru interconectarea elementelor de date. Până în prezent, au fost dezvoltate multe modele de date diferite, dar în practică sunt utilizate trei modele principale. Există modele de date ierarhice, de rețea și relaționale. În consecință, ei vorbesc despre SGBD-uri ierarhice, de rețea și relaționale.

O Model ierarhic de date. Datele organizate ierarhic sunt foarte frecvente în viața de zi cu zi. De exemplu, structura unei instituții de învățământ superior este o structură ierarhică pe mai multe niveluri. O bază de date ierarhică (arboresc) constă dintr-un set ordonat de elemente. În acest model, elementele inițiale dau naștere altor elemente, iar aceste elemente, la rândul lor, dau naștere la elemente ulterioare. Fiecare element copil are un singur element părinte.

Structurile organizaționale, listele de materiale, cuprinsul din cărți, planurile de proiect și multe alte seturi de date pot fi prezentate într-o formă ierarhică. Integritatea legăturilor dintre strămoși și descendenți este menținută automat. Regula de bază: niciun copil nu poate exista fără părintele său.

Principalul dezavantaj al acestui model este necesitatea de a utiliza ierarhia care a stat la baza bazei de date în timpul proiectării. Nevoia de reorganizare constantă a datelor (și adesea imposibilitatea acestei reorganizări) a condus la crearea unui model mai general - un model de rețea.

O Model de date de rețea. Abordarea în rețea a organizării datelor este o extensie a abordării ierarhice. Acest model diferă de cel ierarhic prin faptul că fiecare element generat poate avea mai mult de un element generator. ■

Deoarece o bază de date de rețea poate reprezenta direct tot felul de relații inerente datelor organizației corespunzătoare, aceste date pot fi navigate, explorate și interogate în diferite moduri, adică modelul de rețea nu este legat de o singură ierarhie. Cu toate acestea, pentru a face o cerere către o bază de date de rețea, este necesar să se aprofundeze în structura acesteia (să aveți la îndemână schema acestei baze de date) și să dezvoltați un mecanism de navigare în baza de date, ceea ce este un dezavantaj semnificativ al acestui model de bază de date. .

O Model de date relaționale. Ideea de bază a unui model de date relaționale este de a reprezenta orice set de date ca un tabel bidimensional. În forma sa cea mai simplă, un model relațional descrie un singur tabel bidimensional, dar cel mai adesea, modelul descrie structura și relațiile dintre mai multe tabele diferite.

Model de date relaționale

Deci, scopul sistemului informatic este de a procesa date despre obiecte lumea reală, ținând cont conexiuniîntre obiecte. În teoria bazelor de date, datele sunt adesea numite atribute și obiecte - entitati. Obiectul, atributul și legătura sunt concepte fundamentale ale I.S.

Un obiect(sau esența) este ceva care există și distins, adică un obiect poate fi numit acel „ceva” pentru care există un nume și o modalitate de a distinge un obiect similar de altul. De exemplu, fiecare școală este un obiect. Obiectele sunt și o persoană, o clasă la școală, o companie, un aliaj, un compus chimic etc. Obiectele pot fi nu numai obiecte materiale, ci și concepte mai abstracte care reflectă lumea reală. De exemplu, evenimente, regiuni, opere de artă; cărți (nu ca produse tipărite, ci ca lucrări), spectacole de teatru, filme; norme juridice, teorii filozofice etc.

Atribut(sau dat)- acesta este un anumit indicator care caracterizează un anumit obiect și ia o anumită valoare numerică, text sau altă valoare pentru o anumită instanță a obiectului. Sistemul informațional funcționează cu seturi de obiecte proiectate în raport cu un anumit domeniu, utilizând specific valorile atributelor(date) anumitor obiecte. De exemplu, să luăm cursuri într-o școală ca un set de obiecte. Numărul de elevi dintr-o clasă este o dată care capătă o valoare numerică (o clasă are 28, alta are 32). Numele clasei este unul dat care ia o valoare text (unul are 10A, altul are 9B etc.).

Dezvoltarea bazelor de date relaționale a început la sfârșitul anilor 60, când au apărut primele lucrări care au discutat; posibilitatea utilizării unor modalități familiare și naturale de prezentare a datelor - așa-numitele modele datalogice tabulare - la proiectarea bazelor de date.

Fondatorul teoriei bazelor de date relaționale este considerat a fi un angajat IBM, Dr. E. Codd, care a publicat un articol pe 6 iunie 1970. Un model relațional de date pentru bănci de date mari partajate(Model de date relaționale pentru bănci mari de date colective). Acest articol a fost primul care a folosit termenul „model de date relaționale”. Teoria bazelor de date relaționale, dezvoltată în anii 70 în SUA de Dr. E. Codd, are o bază matematică puternică care descrie regulile de organizare eficientă a datelor. Cadrul teoretic dezvoltat de E. Codd a devenit baza pentru dezvoltarea teoriei proiectării bazelor de date.

E. Codd, matematician de pregătire, a propus să utilizeze aparatul teoriei mulţimilor (unire, intersecţie, diferenţă, produs cartezian) pentru prelucrarea datelor. El a demonstrat că orice set de date poate fi reprezentat sub formă de tabele bidimensionale de un tip special, cunoscute în matematică ca „relații”.

Relațional O bază de date este considerată a fi una în care toate datele sunt prezentate utilizatorului sub formă de tabele dreptunghiulare cu valorile datelor, iar toate operațiunile din baza de date sunt reduse la manipulări cu tabele.

Tabelul este format din coloane (câmpuri)Și linii (înregistrări); are un nume unic în baza de date. Masa reflectă Tipul obiectului lumea reala (entitate), si fiecare dintre ei șir este un obiect specific. Fiecare coloană a tabelului este o colecție de valori pentru un anumit atribut al unui obiect. Valorile sunt selectate din setul tuturor valorilor posibile pentru un atribut al obiectului, care este numit domeniu.

În forma sa cea mai generală, un domeniu este definit prin specificarea unui tip de date de bază căruia îi aparțin elementele domeniului și o expresie booleană arbitrară aplicată elementelor de date. Dacă evaluați o condiție booleană pentru un element de date și rezultatul este adevărat, atunci acel element aparține domeniului. În cel mai simplu caz, un domeniu este definit ca un set potențial valid de valori de același tip. De exemplu, colecția datelor de naștere ale tuturor angajaților constituie „domeniul datei de naștere”, iar numele tuturor angajaților constituie „domeniul numelui angajatului”. Domeniul data nașterii trebuie să aibă un tip de date punct-in-time, iar domeniul numelui angajatului trebuie să aibă un tip de date caracter.

Dacă două valori provin din același domeniu, atunci se poate face o comparație între cele două valori. De exemplu, dacă două valori sunt luate din domeniul datelor de naștere, le puteți compara și determina care angajat este mai în vârstă. Dacă valorile sunt luate din domenii diferite, atunci compararea lor nu este permisă, deoarece, după toate probabilitățile, nu are sens. De exemplu, nu va rezulta nimic cert din compararea numelui și a datei de naștere a unui angajat.

Fiecare coloană (câmp) are un nume, care este de obicei scris în partea de sus a tabelului. Când proiectați tabele într-un anumit SGBD, este posibil să selectați pentru fiecare câmp acesta tip, adică să definească un set de reguli pentru afișarea acestuia, precum și să determine operațiunile care pot fi efectuate asupra datelor stocate în acest câmp. Seturile de tipuri pot varia între diferitele SGBD.

Numele câmpului trebuie să fie unic în tabel, dar diferite tabele pot avea câmpuri cu același nume. Orice tabel trebuie să aibă cel puțin un câmp; Câmpurile sunt amplasate în tabel în conformitate cu ordinea în care au apărut numele lor când a fost creat. Spre deosebire de câmpuri, șirurile nu au nume; ordinea lor în tabel nu este definită, iar numărul lor este logic nelimitat.

Deoarece rândurile din tabel nu sunt ordonate, este imposibil să selectați un rând după poziția sa - nu există „primul”, „al doilea” sau „ultimul” printre ele. Orice tabel are una sau mai multe coloane, ale căror valori identifică în mod unic fiecare dintre rândurile sale. O astfel de coloană (sau combinație de coloane) este numită cheia principala. Un câmp artificial este adesea introdus în înregistrările numerice dintr-un tabel. Un astfel de câmp, de exemplu, ar putea fi câmpul său ordinal, care poate asigura unicitatea fiecărei înregistrări din tabel. Cheia trebuie să aibă următoarele proprietăți.

Unicitatea. La un moment dat, nu există două tupluri de relații diferite să aibă aceeași valoare pentru combinația de atribute incluse în cheie. Adică nu pot exista două rânduri în tabel care să aibă același număr de identificare sau număr de pașaport.

Minimalism. Niciunul dintre atributele incluse în cheie nu poate fi exclus din cheie fără a încălca unicitatea. Aceasta înseamnă că nu ar trebui să creați o cheie care să includă atât numărul pașaportului, cât și numărul de identificare. Este suficient să folosiți oricare dintre aceste atribute pentru a identifica unic un tuplu. De asemenea, nu ar trebui să includeți un atribut neunic în cheie, adică utilizarea unei combinații a unui număr de identificare și a numelui unui angajat ca cheie este interzisă. Prin excluderea numelui angajatului din cheie, fiecare rând poate fi identificat în mod unic.

Fiecare relație are cel puțin o cheie posibilă, deoarece totalitatea tuturor atributelor sale satisface condiția unicității - aceasta rezultă din însăși definiția relației.

Una dintre cheile posibile este selectată aleatoriu în ca cheie primară. Cheile posibile rămase, dacă există, sunt luate ca chei alternative. De exemplu, dacă selectați un număr de identificare ca cheie primară, atunci numărul pașaportului va fi cheia alternativă.

Relația dintre tabele este cel mai important element al modelului de date relaționale. Este suportat chei externe.

Atunci când se descrie un model de bază de date relațională, sunt adesea folosiți termeni diferiți pentru același concept, în funcție de nivelul de descriere (teorie sau practică) și de sistem (Access, SQL Server, dBase). În tabel 2.3 oferă un rezumat al termenilor utilizați.

Tabelul 2.3. Terminologia bazei de date

Teoria bazelor de date____________ Baze de date relaționale_________ SQL Server __________

Tabelul de relații

Rând de înregistrare tuplu

AttributeField_______________Coloană

Baze de date relaționale

Baza de date relațională este un set de relații care conțin toate informațiile care trebuie stocate în baza de date. Adică baza de date reprezintă un set de tabele necesare pentru a stoca toate datele. Tabelele unei baze de date relaționale sunt legate logic între ele. Cerințele pentru proiectarea unei baze de date relaționale în general pot fi reduse la mai multe reguli.

О Fiecare tabel are un nume unic în baza de date și este format din rânduri de același tip.

O Fiecare tabel constă dintr-un număr fix de coloane și valori. Mai multe valori nu pot fi stocate într-o singură coloană de rând. De exemplu, dacă există un tabel cu informații despre autor, data publicării, tiraj etc., atunci coloana cu numele autorului nu poate stoca mai mult de un nume de familie. Dacă cartea este scrisă de doi sau mai mulți autori, va trebui să utilizați tabele suplimentare.

O În niciun moment nu vor exista două rânduri în tabel care să se dubleze reciproc. Rândurile trebuie să difere în cel puțin o valoare pentru a putea identifica în mod unic orice rând din tabel.

О Fiecărei coloane i se atribuie un nume unic în tabel; un anumit tip de date este setat pentru acesta, astfel încât în ​​această coloană să fie plasate valori omogene (date, nume de familie, numere de telefon, sume monetare etc.).

O Conținutul complet de informații al unei baze de date este reprezentat ca valori explicite ale datelor în sine, iar aceasta este singura metodă de reprezentare. De exemplu, relațiile dintre tabele se bazează pe datele stocate în coloanele corespunzătoare și nu pe baza oricăror indicatori care definesc în mod artificial relațiile.

О Când procesați date, puteți accesa liber orice rând sau orice coloană a tabelului. Valorile stocate în tabel nu impun nicio restricție cu privire la ordinea în care sunt accesate datele. Descrierea coloanelor,

Model relațional

Modelul bazei de date relaționale a fost propus în 1969 de matematicianul și cercetătorul IBM E.F. Codd (E.F. Codd). Pentru câteva informații de bază despre bazele de date relaționale, consultați articolul de prezentare generală „ DB și DBMS" 2. Deoarece bazele de date relaționale sunt în prezent dominante, în acest articol (precum și în articolele " Descrierea datelor”, “Procesarea datelor" Și " Proiectarea bazei de date” 2) sunt discutate în detaliu conceptele cele mai esențiale ale modelului relațional.

Să observăm imediat că teoria bazelor de date relaționale a fost formulată inițial într-un limbaj matematic strict și tocmai conceptele matematice stricte, definite formal, descriu cel mai bine esența lucrurilor. Totodată, în cele mai multe cazuri este posibil, fără prea multă pagubă, să sacrificăm rigoarea terminologiei în favoarea transparenței prezentării, ceea ce vom încerca să facem.

Ideea principală a modelului relațional este următoarea. Baza de date constă dintr-o serie de neordonate Mese(în cel mai simplu caz - dintr-un singur tabel). Tabelele pot fi manipulate prin operațiuni non-procedurale (declarative) - cereri, ale căror rezultate sunt tot tabele.

Adesea, cuvântul „relațional” ( relaționale) în termenul „model relațional” se interpretează pe baza faptului că conexiunile sunt stabilite într-o bază de date relațională ( raporta) între mese. Această explicație este convenabilă, dar nu este exactă. În sistemul original de termeni al lui Codd, termenii de conexiune ( relaţii), atribute ( atribute) și tupluri ( tupluri) au fost folosite acolo unde majoritatea dintre noi folosim termenii mai familiari tabele, coloane (câmpuri) și rânduri (înregistrări).

Când construiți un model de informare al unui domeniu (vezi „ DB și DBMS”, “Proiectarea bazei de date” 2) ies în evidență esență(obiecte), descrie-le proprietăți a (caracteristici, atribute) care sunt esențiale pentru scopuri de modelare și se stabilesc conexiuni între entități. În etapa de trecere de la un model relațional infologic la unul datalogic, apar tabele. De obicei, fiecare entitate este reprezentată de un tabel. Fiecare rând al tabelului (o înregistrare) corespunde unei instanțe a entității, iar fiecare câmp descrie o anumită proprietate (atribut).

De exemplu, dacă trebuie să stocăm informații despre persoane, inclusiv numele de familie, prenumele, patronimul, TIN, țara de reședință și data nașterii fiecărei persoane, atunci entitatea este persoana, iar datele specificate sunt atributele. Entitatea însăși devine în mod natural numele tabelului.

Masa „Bărbat”

Modelul relațional necesită ca fiecare rând dintr-un tabel să fie unic, adică. astfel încât oricare două rânduri diferă în valoarea a cel puțin unui atribut.

Forma tabelară tradițională este utilă atunci când trebuie să prezentați datele în sine. Dacă, ca în exemplul de mai sus, vă interesează doar structura- numele câmpurilor, apoi din punct de vedere al clarității, ușurinței de utilizare în diagrame și economisirii spațiului, este mai convenabil să le descrieți după cum urmează:

Chei

Cheie Meseeste un câmp sau un grup de câmpuri care conțin valori unice într-un tabel dat. Cheia identifică în mod unic rândul corespunzător al tabelului. Dacă cheia constă dintr-un singur câmp, este adesea numită simplu, dacă din mai multe - compozit. În exemplul de mai sus, cheia este câmpul TIN (presupunem că este cunoscut faptul că TIN-urile sunt unice într-o țară).

Să ne uităm la un exemplu de tabel cu o cheie compusă. Site-urile de prognoză meteo prezintă adesea informații astfel: pentru fiecare dată, indică temperatura prognozată noaptea, dimineața, după-amiaza și seara. Pentru a stoca aceste informații, puteți utiliza un tabel ca acesta:

În acest tabel, nici câmpurile Data, Ora zilei și nici Temperatură nu sunt cheie - valorile pot fi repetate în fiecare dintre aceste câmpuri. Dar combinația câmpurilor Data + Ora zilei este unică și identifică în mod unic un rând de tabel. Aceasta este o cheie compusă.

Există adesea situații în care alegerea cheii nu este clară. Să revenim la primul exemplu. Să presupunem că, pe lângă nume, prenume, patronim, TIN, data nașterii, este necesar să se păstreze seria și numărul unui pașaport general și seria și numărul unui pașaport străin. Tabelul va arăta așa.

Puteți selecta până la trei chei în acest tabel. Una dintre ele este simplă (TIN), celelalte două sunt compuse (Seria + Număr pașaport general și Seria + Număr pașaport străin). Într-o astfel de situație, dezvoltatorul alege cheia care este cea mai convenabilă din punctul de vedere al organizării bazei de date (în general, cheia a cărei valoare durează cel mai puțin timp pentru a fi găsită). Tasta selectată în acest caz este adesea numită cheia principală sau primar, cheie și alte combinații de coloane din care se poate face o cheie sunt posibil, sau chei alternative. Rețineți că există întotdeauna cel puțin o cheie posibilă într-un tabel, deoarece rândurile nu pot fi repetate și, prin urmare, combinația tuturor coloanelor este garantată a fi o cheie posibilă.

Când descrieți tabele, se obișnuiește să evidențiați cheile primare ale tabelelor. De exemplu, câmpurile relevante sunt adesea subliniate. Și Microsoft Access evidențiază câmpurile cheie cu caractere aldine.

Chiar mai des decât cu ambiguitatea în alegerea unei chei, dezvoltatorii se confruntă cu absența unei chei printre datele care trebuie stocate. Un fapt similar poate fi stabilit în procesul de analiză a domeniului subiectului. De exemplu, dacă trebuie să stocați o listă simplă de persoane - prenume, nume de familie, patronimice și date de naștere, atunci nu există nicio cheie în acest set de atribute - este posibilă o situație când două persoane diferite au același datele complet. În acest caz, trebuie să introduceți artificial un câmp suplimentar, de exemplu, un număr unic de persoană. O astfel de cheie este uneori numită în literatură surogat. Adesea, o cheie surogat este introdusă din motive de eficiență. Dacă, de exemplu, un tabel are o cheie compusă lungă, atunci dezvoltatorii introduc adesea o cheie surogat numerică scurtă suplimentară și o fac cheia primară. Acest lucru se face adesea chiar dacă există o cheie simplă care are un tip de date „incomod” (ineficient pentru căutare), de exemplu, un șir. Astfel de operații nu mai sunt relevante pentru teorie, dar sunt adesea întâlnite în practică.

Cititorul atent poate observa că cheia poate fi aproape întotdeauna extinsă (cu excepția cazului în care include toate câmpurile tabelului) prin includerea câmpurilor redundante. Formal, o astfel de cheie va rămâne o cheie, dar din punct de vedere practic, acesta este doar un joc de concepte. Astfel de chei nici măcar nu sunt considerate posibile, deoarece este întotdeauna necesar să se depună eforturi pentru a minimiza lungimea (complexitatea) cheii.

Forme normale, normalizare

Nu orice tabel pe care îl putem desena pe hârtie sau în Word poate fi un tabel de bază de date relaționale. Și nu orice tabel care poate fi utilizat într-o bază de date relațională este corect din punctul de vedere al cerinței modelului relațional.

In primul rand, necesită ca toate datele din aceeași coloană să fie de același tip(despre tipuri vezi“Descrierea datelor” 2). Din acest punct de vedere, exemplul de mai jos nici nu are sens să discutăm:

În al doilea rând, necesită ca tabelul să aibă o cheie primară atribuită.

Aceste cerințe sunt necesare, dar nu suficiente. Teoria bazelor de date relaționale introduce conceptele de așa-numitele „forme normale” - cerințe pentru organizarea datelor în tabele. Formele normale sunt numerotate secvenţial pe măsură ce cerinţele devin mai stricte. Într-o bază de date proiectată corespunzător, tabelele sunt în cel puțin a treia formă normală. În consecință, vom lua în considerare primele trei forme normale. Să reamintim că avem de-a face cu tabele care satisfac cele două cerințe de bază formulate mai sus.

Prima formă normală (1NF)

Prima formă normală dictează că toate datele conținute într-un tabel trebuie să fie atomice(indivizibil). Lista tipurilor de date atomice corespunzătoare este determinată de SGBD. Cerința 1NF este complet naturală. Înseamnă că fiecare câmp al fiecărei înregistrări ar trebui să conțină o singură valoare, și nu o matrice sau orice altă structură de date. Să dăm un exemplu semnificativ de tabel care nu este în 1NF. Să avem liste cu notele studenților la o anumită materie.

Deoarece valoarea câmpului Evaluări nu este atomică, tabelul nu îndeplinește cerințele 1NF.

O posibilă modalitate de a prezenta o listă de evaluări este descrisă în instrucțiunile pentru articol. „Design DB” 2.

A doua formă normală (2NF)

Se spune că un tabel este în a doua formă normală dacă este în 1NF și fiecare coloană fără cheie este complet dependentă de cheia primară. Cu alte cuvinte, valoarea fiecărui câmp trebuie să fie determinată în întregime de valoarea cheii primare. Este important de menționat că dependența de o cheie primară este înțeleasă tocmai ca o dependență de cheie în ansamblu, și nu de componenta sa individuală (în cazul unei chei compuse). Să dăm un exemplu de tabel care nu este în 2NF. Pentru a face acest lucru, să revenim la exemplul prognozei meteo și să adăugăm o altă coloană la tabel - ora răsăritului (acesta este un exemplu complet plauzibil; acest tip de informații sunt adesea furnizate pe site-urile de prognoză meteo).

După cum ne amintim, acest tabel are o cheie compusă Data+Ora zilei. Câmpul Temperatură este complet dependent de cheia primară - nu există probleme cu acesta. Dar câmpul Răsărit depinde doar de câmpul Data. Ora zilei nu afectează în mod natural ora răsăritului.

Aici este potrivit să punem întrebarea: care este sensul practic al 2NF? La ce folosesc aceste restricții? Se dovedește că este mare. Să presupunem că în exemplul de mai sus, dezvoltatorul ignoră cerințele 2NF. În primul rând, cel mai probabil va exista un așa-numit redundanţă- stocarea datelor inutile. La urma urmei, dacă pentru o înregistrare cu o dată dată, ora răsăritului este deja stocată, atunci pentru toate celelalte înregistrări cu o dată dată ar trebui să fie aceeași și, în general, nu este nevoie să o stocați.

Să fim atenți la cuvintele „ar trebui să fie”. Ce se întâmplă dacă nu? La urma urmei, la nivelul bazei de date, acest lucru nu este controlat în niciun fel - cheia din tabel este compusă, pot exista date identice (și din punct de vedere al semnificației, cel mai probabil vor exista). Și nicio restricție formală (și înțelegerea noastră că „asta nu se poate întâmpla” nu este una dintre ele) interzice indicarea orelor diferite de răsărit pentru aceeași dată.

A treia formă normală (3NF)

Se spune că un tabel este în 3NF dacă este 2NF și toate coloanele care nu sunt cheie sunt independente reciproc.

Dependența reciprocă a coloanelor este convenabil înțeleasă după cum urmează: Coloanele sunt reciproc dependente dacă este imposibil să schimbați una dintre ele fără a o schimba pe cealaltă.

Să dăm un exemplu de tabel care nu este în 3NF. Să luăm în considerare un exemplu de notebook simplu pentru stocarea numerelor de telefon de acasă ale persoanelor care locuiesc, poate, în diferite regiuni ale țării.

Acest tabel are o dependență între coloanele non-cheie Oraș și Cod oraș, prin urmare tabelul nu este în 3NF.

Rețineți că dezvoltatorul determină prezența dependenței de mai sus analizând domeniul subiectului - o astfel de coliziune nu poate fi văzută prin nicio metodă formală. La modificarea proprietăților domeniului subiectului, dependența dintre coloane poate dispărea. De exemplu, dacă în același oraș sunt introduse coduri diferite (cum ar fi 495 și 499 în Moscova), coloanele corespunzătoare nu mai sunt legate în ceea ce privește încălcarea cerințelor 3NF.

În teoria bazelor de date relaționale sunt considerate și forme de ordin superior - forma normală Boyce-Codd, 4NF, 5NF și chiar mai mare. Aceste forme nu au o semnificație practică prea mare, iar dezvoltatorii, de regulă, se opresc întotdeauna la 3NF.

Normalizarea bazei de date

Normalizarea este procesul de reducere a tabelelor bazei de date la o formă normală selectată. Normalizarea la 2NF, de regulă, se reduce la descompunere - împărțirea unui tabel în mai multe. Normalizarea la 3NF poate fi realizată de obicei prin eliminarea coloanelor dependente (calculate). În unele cazuri, atunci când normalizați la 3NF, trebuie să efectuați și descompunerea.

Baze de date cu mai multe tabele, relații între tabele, chei externe

În practică, bazele de date cu un singur tabel sunt destul de rare, deoarece din punctul de vedere al modelării unei baze de date de domeniu, prezența unui singur tabel înseamnă prezența unei entități. La rândul său, prezența mai multor entități înseamnă de obicei prezența unor legături între ele.

Fără a stabili scopul unui design complet de baze de date, să luăm în considerare un exemplu care ne permite să demonstrăm relațiile în baze de date cu mai multe tabele.

Să presupunem că avem de-a face cu o școală în care sunt elevi grupați pe clase și profesori care predau anumite materii. Deosebim imediat patru entități: elevi, profesori, clase și obiecte. Aceste entități ne oferă deja patru tabele.

În continuare, trebuie să rezolvăm problema atributelor entității - ce fel de informații vom stoca. Deoarece exemplul nostru are doar scop demonstrativ, vom încerca să minimizăm cantitatea de informații stocate. Vom fi de acord să păstrăm numele de familie și prenumele pentru fiecare elev, pentru clasă - numărul paralel și litera de identificare a clasei în cadrul paralelei, pentru profesor - numele de familie, prenumele și patronimul, pentru materie - doar numele acesteia .

Acum trebuie să rezolvăm problema cu cheile primare. Tabelele pentru elevi și profesori practic nu au o cheie, așa că vom introduce o cheie numerică surogat în ele - un număr. Tabelele de clase și articole, în general, au chei. În tabelul de clase, cheia este compusă, este formată din atributele Număr paralel + Literă, iar în tabelul de obiecte, o cheie simplă este formată dintr-un singur câmp - numele obiectului. Amintiți-vă că atunci când am vorbit despre chei, am menționat că cheile surogat sunt adesea adăugate din motive de eficiență, încercând să scăpați de cheile compuse sau câmpurile cheie de tipuri incomode, cum ar fi șirurile de caractere. Asta vom face. Să adăugăm o cheie numerică surogat la fiecare dintre tabele.

Ca urmare, vom primi următorul set de tabele corespunzătoare entităților descrise.

Înțelegând de ce domeniu ne ocupăm, știm că entitățile noastre nu există de la sine - sunt conectate prin anumite relații pe care le-am subliniat mai sus. Dar cum să le conectăm din punct de vedere tehnic? Aici nu puteți face fără introducerea de câmpuri suplimentare și chiar tabele suplimentare. Să ne uităm la relațiile dintre entități în ordine.

Pentru a atribui un elev la o anumită clasă, adăugăm un câmp suplimentar Număr de clasă în tabelul „Student”. (Este clar că tipul său trebuie să coincidă complet cu tipul câmpului Numărul clasei din tabelul „Clasă”.) Acum putem lega tabelele „Student” și „Clasă” folosind valorile potrivite ale câmpurilor Numărul clasei. (Nu întâmplător am numit aceste câmpuri la fel, în practică Acest lucru se face adesea pentru a naviga cu ușurință în câmpurile de legătură). Rețineți că o înregistrare din tabelul „Clasă” poate corespunde multor înregistrări din tabelul „Student” (și, în practică, cel mai probabil corespunde - este dificil să vă imaginați o clasă de un student). Se spune că astfel de tabele sunt legate de relația „ unu la multi" Și câmpul Număr de clasă din tabelul „Student” este numit cheie externă. După cum puteți vedea, scopul cheilor externe este de a lega tabele. Rețineți că o cheie externă se referă întotdeauna la cheia primară a tabelului aferent (adică cheia externă se află pe partea „multe”). Cheia primară asociată cu o străină este apelată părintească, deși acest termen este folosit mai rar.

Să ilustrăm acest lucru cu o diagramă în stilul Microsoft Access (mai multe informații despre „Schema de date” Access sunt scrise în articol „Descrierea datelor” 2).

Acum să ne gândim la profesori și materii. Analizând tematica (asta este singura modalitate - la urma urmei, este imposibil să extragem adevărata stare a lucrurilor din modelul formal în sine), observăm că tipul de legătură dintre entitățile „profesor” și „subiect” este diferit. din cele discutate mai sus. La urma urmei, nu numai că mulți profesori pot preda o singură materie, dar un profesor poate preda multe discipline. Astfel, există o legătură între aceste entități” multi la multi" Aici nu te poți descurca fără să introduci câmpuri suplimentare (încearcă!). Relațiile multi-la-multe sunt întotdeauna rezolvate prin introducerea unui tabel suplimentar. Și anume, organizăm tabelul „Profesor-Subiect”, care are următoarea structură:

Tabelul „Profesor-Materia”

Acest tabel are o cheie compusă formată din două dintre câmpurile sale. Atât tabelul „Profesor”, cât și tabelul „Subiect” sunt legate de acest tabel într-o relație unu-la-mai mulți (desigur, în ambele cazuri „mulți” se află pe partea „Profesor-Subiect”). În consecință, în tabelul „Profesor-Subiect” există două chei străine (ambele sunt părți ale unei chei primare compuse, care nu este interzisă), care servesc la conectarea cu tabelele corespunzătoare.

În practică, pe lângă relațiile considerate „unu-la-mulți” și „mulți-la-mulți”, există și relația „ unu la unu" Din punct de vedere teoretic, o astfel de relație nu prezintă interes, deoarece două tabele conectate printr-o relație unu-la-unu pot fi întotdeauna combinate într-unul singur. Cu toate acestea, în bazele de date reale, o relație unu-la-unu este utilizată pentru a optimiza procesarea datelor. Să ilustrăm acest lucru cu un exemplu.

Să presupunem că stocăm o mulțime de informații diferite despre oameni - date din tot felul de documente, numere de telefon, adrese etc. Cel mai probabil, majoritatea acestor date vor fi folosite foarte rar. Și de multe ori avem nevoie doar de un nume de familie, prenume, patronimic și număr de telefon. Apoi, are sens să organizezi două mese și să le relaționezi într-o relație unu-la-unu. Stocați informațiile utilizate frecvent într-un tabel (mic), iar restul într-un altul. Desigur, tabelele legate printr-o relație unu-la-unu au aceeași cheie primară.

Reguli de integritate

Modelul relațional definește două reguli generale pentru integritatea bazei de date: integritatea obiectului și integritatea referențială.

Regula de integritate obiecte foarte simplu. Aceasta necesită ca cheile primare de tabel să nu conțină valori nule (nule)..

Regula de integritate referenţială cere ca cheile străine să nu conțină valori care sunt incompatibile cu cheile lor părinte. Revenind la exemplul discutat mai sus, trebuie să cerem, de exemplu, ca elevii să aparțină numai clasei al cărei număr este indicat în tabelul „Clasuri”.

Majoritatea SGBD-urilor sunt capabile să monitorizeze integritatea datelor (desigur, acest lucru necesită eforturi corespunzătoare din partea dezvoltatorului în etapa de descriere a structurilor de date). În special, mecanismele sunt utilizate pentru a menține integritatea referențială în cascadă operațiuni. Cascada implică, în special, că, atunci când ștergeți o înregistrare dintr-un tabel „părinte” care este conectat la un alt tabel printr-o relație unu-la-mai mulți, toate înregistrările asociate sunt șterse automat din tabelul „mai multe” (de către SGBD însuși, fără intervenția utilizatorului). Și acest lucru este firesc, deoarece astfel de înregistrări „atârnă în aer” nu mai sunt legate de nimic.

Indexarea

Indexarea este extrem de importantă din punct de vedere al aplicării practice, dar opțională din punctul de vedere al teoriei pure. Scopul principal al indexării este optimizarea (accelerarea) căutării (și, în consecință, alte operațiuni cu baza de date). Indexarea necesită în orice caz resurse suplimentare (fișierele index speciale sunt cel mai adesea create la nivel fizic). Indexarea poate chiar încetini operațiunile legate de modificarea datelor, prin urmare, tabelele care sunt rar modificate și căutate frecvent sunt de obicei indexate.

Un fișier index este foarte asemănător cu un index obișnuit de carte. Pentru fiecare valoare de index, este stocată o listă de rânduri de tabel care conțin acea valoare. În consecință, pentru a căuta, nu trebuie să vă uitați prin întregul tabel - doar căutați în index. Cu toate acestea, atunci când modificați înregistrările, poate fi necesar să reconstruiți indexul. Și asta necesită timp suplimentar.

Desigur, nu se pune problema de a prezenta teoria bazelor de date relaționale ca parte a unui curs de bază de informatică! Cu toate acestea, acest articol este foarte important pentru enciclopedia noastră, deoarece în acest caz avem de-a face cu materiale care nu pot fi prezentate pe deplin în lecții, dar profesorul trebuie să-l stăpânească. De ce?

În primul rând, pentru că în cadrul cursului de bază sunt studiate o serie de concepte. Aceasta include o vizualizare de tabel a datelor și cheilor de tabel. Și știm cu toții că este foarte dificil să prezinți corect și precis doar unele concepte fără a prezenta imaginea de ansamblu.

În al doilea rând, efectuarea de interogări simple în baza de date cu copii (materialul relevant este prezentat în articol "Procesarea datelor" 2), este necesar să se ocupe de tabele care sunt corecte din punctul de vedere al teoriei relaționale. Nu este nevoie să le explicați elevilor că aceste tabele sunt corecte, dar „dacă doar..., atunci tabelul ar fi incorect”, dar este inacceptabil să folosiți exemple proaste.

Într-un curs specializat de informatică, situația poate fi fundamental diferită. Cea mai importantă și extrem de productivă formă de muncă în clasele de specialitate este munca pe proiecte. În cadrul proiectelor educaționale, este posibil și necesar să se dezvolte baze de date simple, iar aici nu se poate face fără fundamentele teoriei prezentate. Cu toate acestea, trebuie luate în considerare următoarele:

Temele care se modelează nu trebuie să fie prea mari;

Ar trebui să fie foarte familiari studenților (în acest sens, proiectul „Școala”, de care toată lumea s-a săturat, nu este cea mai proastă alegere!);

Este naiv să ne așteptăm ca, după ce au ascultat elementele de bază ale teoriei, studenții vor putea să proiecteze ei înșiși ceva. Fiecare pas trebuie făcut împreună cu ei, justificându-vă acțiunile în detaliu.

Sisteme de management al bazelor de date și sisteme expert. Concepte de bază ale bazelor de date relaționale. Lucrul cu cereri. Forme. Rapoarte. Crearea bazei de date.

Sisteme de management al bazelor de date și funcțiile acestora

În tehnologia modernă a bazelor de date, software specializat - sisteme de gestionare a bazelor de date - este utilizat pentru a crea baze de date, a le susține și a le întreține. Un SGBD este un set de instrumente software și lingvistice necesare pentru crearea și operarea bazelor de date.

În stadiul dezvoltării bazei de date, SGBD este utilizat pentru a descrie structura bazei de date: definirea tabelelor; determinarea numărului de câmpuri; tipul de date afișate în acestea; dimensiunile câmpurilor; definirea relaţiilor dintre tabele. Pe lângă tabele, majoritatea SGBD-urilor prevăd crearea de instrumente speciale pentru lucrul cu date - formulare, interogări.

În timpul funcționării bazelor de date, SGBD asigură editarea structurii bazei de date, completarea acesteia cu date, căutarea, sortarea, selectarea datelor conform criteriilor specificate și generarea de rapoarte.

În sistemele informaționale care rulează pe computere personale compatibile cu IBM, așa-numitele sisteme de gestionare a bazelor de date asemănătoare dBASE, de exemplu, dBASE, FoxPro și Clipper, au devenit larg răspândite. Ceea ce este semnificativ pentru utilizatori este că, deși diferă în limbajele de comandă și formatele de fișiere index, toate aceste SGBD folosesc aceleași fișiere de bază de date cu extensia .DBF, al cărei format a devenit de ceva timp un fel de standard de bază de date.

În bazele de date asemănătoare dBASE, se utilizează de fapt o abordare relațională a organizării datelor, adică Fiecare fișier .DBF este un tabel bidimensional care constă dintr-un număr fix de coloane și un număr variabil de rânduri (înregistrări). În termenii acceptați în documentația tehnică, fiecare coloană corespunde unui câmp de unul din cinci tipuri (N - numeric, C - simbolic, D - dată, L - logic, M - notă), iar fiecare linie corespunde unei înregistrări cu lungime fixă. constând dintr-un câmp cu număr fix. Folosind limbajele de comandă ale acestor SGBD, sunt create și corectate machetele de fișiere .DBF (descrieri de tabel), sunt create fișiere index, sunt descrise procedurile de lucru cu bazele de date (citire, căutare, modificare a datelor, raportare și multe altele). O trăsătură caracteristică a fișierului .DBF este simplitatea și claritatea acestuia: reprezentarea fizică a datelor de pe disc corespunde exact cu prezentarea tabelului pe hârtie. Cu toate acestea, în general, sistemele construite pe fișiere .DBF ar trebui să fie considerate învechite.

Alte SGBD-uri (cu un alt format de fișier) sunt, de asemenea, foarte populare - Paradox, Clarion etc. Trebuie subliniat faptul că sistemele enumerate își au originea în MS-DOS, dar acum aproape toate au fost îmbunătățite și au versiuni pentru Windows.

Dintre sistemele relaționale moderne, cel mai popular SGBD pentru Windows este Access de la Microsoft, Approach de la Lotus, Paradox de la Borland. Multe dintre aceste sisteme suportă tehnologia OLE și pot manipula nu numai informații numerice și textuale, ci și imagini grafice (desene, fotografii) și chiar fragmente de sunet și clipuri video.

SGBD-urile enumerate sunt adesea numite desktop, adică cantitatea relativ mică de date deservită de aceste sisteme. Cu toate acestea, nu numai utilizatorii individuali, ci și echipe întregi (în special în rețelele locale de calculatoare) lucrează adesea cu aceștia.

În același timp, SGBD-urile relaționale mai puternice, cu așa-numitul acces SQL, trec treptat în centrul tehnologiei informaționale moderne. Aceste SGBD-uri se bazează pe tehnologia client-server. Printre principalii producători de astfel de sisteme se numără Oracle, Centura (Gupta), Sybase, Informix, Microsoft și alții.

Tipuri de date în baze de date

Sistemele informaționale funcționează cu următoarele tipuri principale de date.

Date text. Valoarea fiecărei date text (caracter) este reprezentată de un set de caractere alfanumerice arbitrare, a căror lungime de cele mai multe ori nu depășește 255 (de exemplu, 5, 10, 140). Datele text reprezintă numele și pozițiile persoanelor, numele companiilor, produse, dispozitive etc. în IS. Într-un caz particular, valoarea unei date text poate fi numele unui fișier care conține informații nestructurate de lungime arbitrară (de exemplu, o biografie sau o fotografie a unui obiect). De fapt, acesta este un link structurat care vă permite să extindeți în mod dramatic conținutul de informații din tabelul dvs.

Date numerice. Datele de acest tip sunt de obicei folosite pentru a reprezenta atribute ale căror valori trebuie utilizate pentru operații aritmetice (greutăți, prețuri, coeficienți etc.). O dată numerică, de regulă, are caracteristici suplimentare, de exemplu: un număr întreg de 2 octeți, un număr în virgulă mobilă (4 octeți) într-un format fix etc. Separatorul dintre părțile întregi și fracționale este de obicei un punct.

Date de tip dată și/sau oră. Datele tip dată sunt specificate într-un format cunoscut de mașină, de exemplu, ZZ.LL.AA (zi, lună, an). La prima vedere, acesta este un caz special de date text. Cu toate acestea, utilizarea unui tip de dată special într-un IC are următoarele avantaje. În primul rând, sistemul are posibilitatea de a menține un control strict (de exemplu, valoarea lunii poate fi doar discretă în intervalul 01-12). În al doilea rând, devine posibil să se reprezinte automat formatul de dată în funcție de tradițiile unei anumite țări (de exemplu, formatul MM-DD-GT este adoptat în SUA). În al treilea rând, la programare, operațiile aritmetice cu date sunt mult simplificate (încercați, de exemplu, să calculați manual o dată la 57 de zile după o dată dată). Folosirea acestui tip de timp are aceleași avantaje.

Date logice. O dată de acest tip (uneori numită boolean) poate lua doar una dintre cele două valori care se exclud reciproc - Adevărat sau Fals (condițional: 1 sau 0). Este de fapt un comutator a cărui valoare poate fi interpretată ca „Da” și „Nu” sau ca „Adevărat” și „Fals”. Tipul boolean este convenabil de utilizat pentru acele atribute care pot lua una dintre cele două valori care se exclud reciproc, de exemplu, a avea un permis de conducere (da sau nu), serviciul militar (da sau nu), etc.

Câmpuri obiect OLE. Valoarea unor astfel de date poate fi orice obiect OLE care este disponibil pe computer (grafică, sunet, video). În special, lista studenților poate include nu numai o fotografie statică a elevului, ci și vocea acestuia.

Tipuri personalizate. În multe sisteme, utilizatorilor li se oferă posibilitatea de a-și crea propriile tipuri de date, de exemplu: „Ziua săptămânii” (luni, marți etc.), „Adresă” (cod poștal - oraș - ...), etc.

Într-un caz particular, valoarea unei date text poate fi o colecție de spații, iar valoarea unei date numerice poate fi zero. Dacă nu este introdusă nicio informație în tabel, valoarea va fi goală (Null). Nulul nu trebuie confundat cu zero sau spații. În multe sisteme, este important ca utilizatorul să înregistreze absența datelor pentru unele instanțe ale unui obiect (de exemplu, absența unei adrese, „Adresa este nulă”). Dacă introduceți accidental un spațiu într-un astfel de rând de tabel, sistemul va considera că adresa a fost specificată, iar această instanță nu va fi inclusă în lista de obiecte cu adrese lipsă.

Baze de date relaționale

Cea mai convenabilă modalitate atât pentru utilizator, cât și pentru computer este de a prezenta datele sub forma unui tabel bidimensional - majoritatea sistemelor informatice moderne funcționează doar cu astfel de tabele. Sunt numite baze de date care constau din tabele bidimensionale relaționale , (în engleză „relație” - relație). Ideea principală a abordării relaționale este de a reprezenta o structură de date arbitrară sub forma unui tabel bidimensional simplu.

Un exemplu de implementare a unui model de date relaționale ar putea fi un tabel cu informații despre elevi.

După cum se poate vedea din exemplul de mai sus, un tabel relațional are următoarele proprietăți:

· fiecare rând al tabelului este un element de date (informații despre un student);

· toate coloanele din tabel sunt omogene, i.e. Toate articolele dintr-o coloană sunt de același tip și lungime (de exemplu, coloana Nume afișează nume de elevi de tip caracter de până la 17 caractere lungime);

· fiecare coloană are un nume unic (de exemplu, nu există două coloane Nume în tabel);

· nu sunt permise rânduri identice în tabel (se face o singură intrare pentru fiecare elev);

· ordinea rândurilor și coloanelor din tabel poate fi arbitrară (o înregistrare despre elev în tabel se face la admiterea la școală, iar ordinea coloanelor nu contează).

Elemente structurale ale unei baze de date relaționale

Folosind un tabel relațional ca exemplu, să ne uităm la principalele elemente structurale ale unei baze de date.

1. În bazele de date relaționale, orice colecție de date este prezentată sub formă de tabele (relații) bidimensionale, similare listei de elevi descrise mai sus. Mai mult, fiecare tabel constă dintr-un număr fix de coloane și un anumit număr (variabil) de rânduri. Descrierea coloanelor se numește de obicei aspectul tabelului.

2. Fiecare coloană a tabelului reprezintă un câmp - o unitate elementară de organizare logică a datelor, care corespunde unei unități indivizibile de informații - detaliile unui obiect de date (de exemplu, numele de familie al elevului, adresa).

Următoarele caracteristici sunt utilizate pentru a descrie domeniul:

· numele câmpului (de exemplu, Nr. dosar personal, Nume);

· tipul câmpului (de exemplu, caracter, dată);

· caracteristici suplimentare (lungimea câmpului, format, precizie).

De exemplu, câmp Data nașterii poate fi de tipul „data” și lungimea 8 (6 cifre și 2 puncte care separă ziua, luna și anul în înregistrarea datei).

3. Fiecare rând al unui tabel se numește înregistrare. Înregistrarea combină în mod logic toate câmpurile care descriu un obiect de date, de exemplu, toate câmpurile din primul rând al tabelului de mai sus descriu date despre studentul Ivan Vasilyevich Petrov, născut la 12 martie 1989, care locuiește la adresa st. Gorki, 12-34, învață la clasa 4A, număr dosar personal - P-69. Sistemul numerotează înregistrările în ordine: 1,2, ..., n, unde n este numărul total de înregistrări (rânduri) din tabel în acest moment. Spre deosebire de numărul de câmpuri (coloane) dintr-un tabel, numărul de înregistrări în timpul funcționării bazei de date poate varia după cum se dorește (de la zero la milioane). Numărul de câmpuri, numele și tipurile acestora pot fi, de asemenea, modificate, dar aceasta este o operațiune specială numită modificarea aspectului mesei .

4. Structura de înregistrare a fișierului specifică câmpuri ale căror valori sunt o cheie simplă care identifică instanța de înregistrare. Un exemplu de cheie atât de simplă în tabelul Studenți este câmpul numărul de fișier personal, a cărui valoare identifică în mod unic un obiect din tabel - un student, deoarece nu există doi studenți în tabel cu același număr de fișier personal.

5. Fiecare câmp poate fi inclus în mai multe tabele (de exemplu, un câmp Nume de familie pot fi incluse în tabelul Lista elevilor din grupa de teatru).