BAZE DE DATE

Cuvinte de introducere

Baze de date ca o parte indispensabilă a sistemelor informaţionale. Orice sistem informaţional are conţinutul lui informatic (umplerea informatică) care este nu alt ceva decât o reprezentare formalizată a informaţiilor în formă de o colecţie bine structurată de date. Aceasta colecţie structurată de date se numeşte baza de date şi este suportul informaţiilor şi totodată reflectă legăturile dintre obiectele şi procesele din lumea reală. Cu alte cuvinte baza de date este modelul informaţional al careva domeniu concret din lumea reală.

La rândul său sistemele informaţionale fac parte din compartimentele domeniului vast de tehnologii informaţionale în genere.

Importanţa tehnologiilor informaţionale ca o characteristică principală a dezvoltării societăţii: Partea economică; Partea intelectuală

Patru părţi constituiente a cursului nostru:

1. INTRODUCERE GENERALĂ IN SISTEME INFORMAŢIONALE CU BAZE DE DATE (Sisteme Informaţionale cu Baze de Date)

2. TEORIA BAZELOR DE DATE RELAŢIONALE

3. LIMBAJUL BAZELOR DE DATE RELAŢIONALE SQL. STANDARDUL SQL

4. PROIECTAREA APLICAŢIILOR CU BAZE DE DATE

Bibliografie1. Marin Fotache, Proiectarea bazelor de date, Polirom, 2005.2. M.Velicanu, I.Lungu, M.Muntean, “Sisteme de baze de date-teorie şi practică”,

editura Petrion, 2003.3. M.Velicanu – “Dicţionar explicativ al sistemelor de baze de date“, editura

Economică, 2005.4. M.Velicanu, I.Lungu, M.Muntean s.a., “Oracle-platformă pentru baze de date”,

editura Petrion, 2002.

BAZE DE DATE SISTEME INFORMAŢIONALE TEHNOLOGII INFORMAŢIONALE

1. SISTEME INFORMAŢIONALE CU BAZE DE DATE

1.1 Sisteme informaţionale. Noţiuni generale

Primele dispozitive de calcul, începând cu cele primitive, mecanice şi terminând cu maşinele electronice din anii 1950 au fost proiectate şi utilizate pentru rezolvarea problemelor numerice (tabularea funcţiilor trigonometrice şi speciale, calcule astronomice, etc.). Dintre cele două resurse principale ale calculatorului cel mai important era procesorul (primitiv pe atunci), iar unităţi de memorie externe în genere nu existau. În aceata perioadă sau dezvoltat metode complexe de calcul, sau creat limbaje puternice de programare.

Cu timpul însă caracteristicele calculatoarelor au avansat, au apărut unităţi de memorie externă de capacitate considerabilă. Drept o revoluţie în istoria tehnicii de calcul a devinit crarea unităţilor de memorie externă cu acces direct (aleator). Din acest moment calculatoarele au început să se folosească tot mai mult şi mai mult pentru stocarea şi prelucrarea documentelor de text, mai bine zis pentru prelucrarea informaţiei ce se conţine în ele. Pentru acest lucru au fost create sisteme integrate speciale de soft şi hard care se numesc sisteme informaţionale. Ca exemple putem menţiona sisteme bancare, sisteme informaţionale automatizate pentru rezervarea şi procurarea biletelor la transport (tren, avion), catalogul electronic a unei biblioteci, sistemul informaţional a reţelei telefonice a oraşului, etc.

Toate acestea sisteme se caracterizează prin aceea că: Posedă unităţi fizice (hard) pentru transmiterea şi depozitarea datelor; Posedă mijloace de program (soft) pentru crearea structurilor de date în

memoria externă şi manipularea datelor în memoria operativă; Datele cu care ele operează au o organizare structurală complexă; Sistemele acestea, ca de obicei, nu necesită calcule numerice mari şi complexe.

Comentarii la acestea caracteristici.1. Unităţi fizice (hard). Aici este necesar de indicat două resurse principale ale

calculatorului – viteza procesorului şi capacitatea memoriei. Memoria este de două tipuri – memoria operativă (de bază) şi memoria externă (secundară). Viteza procesorului nu este atât de critică. Ea este importantă pentru sistemele mari şi foarte mari, în care informaţiile relevante se caută printre sute de mii şi milioane de înregistrări. Foarte importantă este memoria externă, determinînd în mod direct capacitatea de stocare a cantităţilor mari de date.

2. Mijloace de program (soft). De fapt, mijloacele de program trebuie se permită realizarea tuturor operaţiilor cu informaţii: colectarea, depozitarea, actualizarea, întreţinerea, prelucrarea, transmiterea prin liniile comunicaţionale, utilizarea în practică.

3. Structură complexă de organizare ale datelor. Conţinutul informatic (umplerea informatică) a acestor sisteme este o reprezentare formalizată a informaţiilor din lumea reală în formă de o colecţie bine structurată de date. Aceasta colecţie este suportul informaţiilor şi totodată reflectă legăturile dintre

2

obiectele şi procesele din lumea reală. Cu alte cuvinte ea este modelul informaţional al careva domeniu concret din lumea reală.

4. Nu necesită calcule numerice mari. Evident, aici nu merge vorba despre sisteme supra mari (sistem de prognozare a stării de timp, componenţa speţiilor a unui areal mare de floră şi/sau faună, etc.).

Pentru a lărgi p.3:După cum ştim, datele sunt purtătorul sau suportul fizic a informaţiei. Mai

precis, în calitate de informaţie se manifestă datele care au o interpretare consistentă sau un sens. Dacă A213 este valoarea unei variabile x, atunci asta este data. Dar, dacă A213 este codul unic a angajatului Ciobanu, atunci asta este informaţie.

Datele şi informaţiile reprezintă componentele primare ale sistemului informaţional. Data reprezintă o însuşire de caractere numerice sau alfa numerice, care au o anumită semnificaţie. Informaţiile se obţin în general din prelucrarea datelor, ele nu se confundă însă cu acestea.

În concluzie se poate spune că orice informaţie este o dată dar nu orice dată este o informaţie, ci numai aceea care are pentru receptor un caracter de noutate. O bază de date reprezintă o modalitate de stocare a unor informaţii (date) pe un suport extern, cu posibilitatea regăsirii acestora.De obicei o bază de date este memorată într-unul sau mai multe fişiere. Bazele de date sunt manipulate cu ajutorul sistemelor de gestiune a bazelor de date. Cel mai răspândit model de baze de date este cel relaţional, în care datele sunt memorate în tabele. Pe lânga tabele, o bază de date relaţională mai poate conţine: indecşi, proceduri stocate, trigger-e, utilizatori şi grupuri de utilizatori, tipuri de date, mecanisme de securitate şi de gestiune a tranzacţii Din punct de vedere al teoriei comunicaţiilor, informaţia este un mesaj, un semnal ce reflectă starea unui sistem sau a mediului în care acesta funcţionează şi care aduce receptorului un spor de cunoaşterelor etc.

În ultimul timp, tot mai mulţi cercetători şi oameni de ştiinţă îşi pun întrebarea dacă este posibil de construit o teorie a informaţiei unică, general valabilă.

Cunoştinţele au o natură mai complexă decât datele şi informaţiile şi necesită o contribuţie activă din partea oamenilor pentru gestionarea şi coordonarea lor. De aceea, este necesar să evidenţiem încă de la început principalele diferenţe dintre date, informaţii şi cunoştinţe, pentru a implementa corespunzător managementul bazat pe cunoştinţe.

Relaţia dintre date, informaţii, cunoştinţe şi înţelepciune poate fi reprezentată sub forma unei piramide. Baza piramidei o reprezintă datele, urmate de informaţii, apoi cunoştinţe, iar înţelepciunea se află în vârful piramidei.

Datele: reprezintă un set de fapte obiective, eterogene despre un proces sau un eveniment care au o utilitate redusă dacă nu sunt transformate în informaţii. Datele de exemplu sunt atribute cantitative, numerice sau de altă natură obţinute prin observaţii, experimente sau calcule. Costul, viteza, durata sau capacitatea sunt date cantitative.

Informaţiile: sunt date înzestrate cu relevanţă şi scop. Au o anumită semnificaţie şi sunt organizate pentru anumite scopuri. Informaţiile, de exemplu, constituie o colecţie de date şi explicaţii asociate, interpretări etc despre un obiect, eveniment sau proces.

3

Cunoştinţele: reprezintă o combinaţie fluidă de experienţe, valori, informaţii contextuale şi intuiţie care oferă cadrul pentru evaluarea şi încorporarea unor noi experienţe şi informaţii. Cunoştinţele apar şi se aplică în mintea oamenilor. În organizaţii, cunoştinţele sunt încastrate nu doar în documente şi în depozite, ci şi în procesele, practicile şi normele organizaţionale [3].Întrebările tipice referitoare la date sunt “cine?”, “ce?”, “unde?” şi “când?”, în timp ce întrebările specifice cunoştinţelor sunt “cum?” şi “de ce?”.

Conceptul de informaţie reprezintă o noţiune de maximă generalitate care semnifică o ştire, un mesaj, un semnal, etc. despre evenimente, fapte, stări, obiecte, etc. în general despre forme de manifestare a realităţii care ne înconjoară. Forma de exprimare şi transmitere a informaţiilor o reprezintă comunicarea. Informaţia apare ca o comunicare despre un anumit aspect al realităţii obiective. Din punct de vedere conceptual, informaţia reprezintă o reflectare în planul gândirii umane, a legăturilor de cauzalitate privind aspectele din realitatea ce ne înconjoară.Procesul de sesizare, înţelegere şi însuşire a informaţiilor dintr-un anumit domeniu reprezintă un proces de informare. Informaţiile dobândite în urma unui proces de informare într-un anumit domeniu, formează cunoştinţele despre acel domeniu, iar mulţimea acestora reprezintă patrimoniul de cunoştinţe. Cunoştinţele reprezintă o însumare în timp a tuturor informaţiilor dobândite într-un anumit domeniu. Data este forma de reprezentare materială a informaţiei. Datele reprezintă suportul formal al informaţiei care se concretizează în cifre, litere, simboluri, coduri şi alte semne plasate pe suporţi tehnici de date. Datele reprezintă obiectul prelucrării pentru informatică, materia primă a acesteia şi numai prin asociere cu realitatea pe care o reflectă, se poate spune că informatica generează informaţii. Datele obţinute în urma procesului de prelucrare pot avea calitatea de informaţii pentru o anumită categorie de utilizatori sau rămân simple date dacă îşi pierd calitatea de noutate semantică. În practică, de multe ori termenul de informaţie este utilizat pentru a desemna date, iar expresia "prelucrarea informaţiilor" înlocuieşte expresia "prelucrarea datelor". Se poate considera că datele prelucrate, în măsura în care afectează în sens pozitiv comportamentul receptorilor (oameni sau maşini), au calitatea de informaţii. În procesul prelucrării şi utilizării informaţiilor, acestea sunt privite din trei puncte de vedere: - din punct de vedere sintactic, când se urmăreşte aspectul formal al reprezentării acestora, în sensul că datele care se prelucrează se supun riguros anumitor reguli de validitate; - din punct de vedere semantic, urmărindu-se semnificaţia, înţelesul informaţiei (conţinutul real al informaţiei) ce derivă din datele prelucrate; - din punct de vedere pragmatic, urmărindu-se utilitatea, adică măsura în care sunt satisfăcute cerinţele utilizatorilor.

Aşadar, obiectivele principale ale sistemelor informaţionale sunt crearea astfel de structuri de date care sunt purtătorul anumitor porţiuni concrete de informaţii şi cunoştinţe, precum şi colectarea, depozitarea, prelucrarea şi utilizarea în practică a acestor structuri de date.

4

Înainte de a trece la formularea unor definiţii referitor la noţiunile de sistem informaţional şi bază de date, vom analiza noţiunile de informaţie şi date şi legăturile între ele – datele ca suport al informaţiei.

Datele elementare pot fi unite în structuri de diferită complexitate, care reprezintă porţiuni concrete de informaţii din lumea reală. Spre exemplu, un tip structurat de date din care este alcătuit un fişier este înregistrăre. O înregistrare este un tip compus de date cu o structură alcătuită din câmpuri. Fiecare câmp conţine valori, care reprezintă o caracteristică careva particulară (un atrtibut) al obiectului dat. În intregime o înregistrare reprezintă un exemplar concret al entităţii din lumea reală. De exemplu: A213 ALBU 2500 este o înregistrare, care conţine informaţie despre identificatorul şi salariul persoanei ALBU – un exemplar al obiectului LUCRATORI. Structura acestei înregistrări este alcătuită din câmpurile IDENTIFICATOR, NUME, SALARIU. O colecţie de înregistrări de această structură va reprezenta informaţie despre salariul colectivului de lucrători a unei întreprindere. Printre câmpurile înregistrărilor unul

Pot fi date diferite definiţii a sistemelor informaţionale (SI): O bază de date reprezintă o modalitate de stocare a unor informaţii şi date pe un

suport extern (un dispozitiv de stocare), cu posibilitatea regăsirii rapide a acestora. De obicei o bază de date este memorată într-unul sau mai multe fişiere. Bazele de date sunt manipulate cu ajutorul sistemelor de gestiune a bazelor de date (Wikipedia, enciclopedia liberă).

O colecţie de documente cu o organizare structurată şi de tehnologii informaţionale inclusiv tehnologii computaţionale şi de reţea care permit realizarea proceselor informaţionale (legislaţia Federaţiei Ruse);

Un complex de mijloace de soft şi hard menite pentru memorarea şi/sau gestionarea datelor şi informaţiei şi pentru efectuarea calculelor.

1.2. Evoluţia organizării structurale al datelor. Două forme de organizare

structurală

Orice sistem de bază de date se bazează pe colecţii structurate de date create şi memorate în memoria externă a calculatorului. Acestea colecţii prezintă modelul informaţional a unui domeniu concret din lumea reală. Din acest punct de vedere este importantă forma principală de organizare a datelor în colecţii structurate în memoria externă. Cu alte cuvinte, noţiunea de colecţii structurate de date presupune folosirea unei forme, sau a unui sistem de organizare structurală al datelor in memoria externă.

Sub organizarea structurală al datelor vom subînţelege unele principii globale de organizare al datelor în colecţii structurate, precum şi principiile de stabilire a legăturilor dintre elementele colecţiilor structurate.

Organizarea structurală al datelor ca tehnologie majoră a evoluat odată cu:

5

Creşterea gradului de automatizare a proceselor de prelucrare a informaţiilor şi a complexităţii problemelor rezolvate;

Creşterea resurselor de memorie şi viteză a calculatorului electronic (performanţei calculatorului);

Dezvoltarea tehnologiilor informaţionale.De fapt acestea direcţii de progres sunt strâns legate între ele şi se dezvoltă concomitent, stimulând una pe alta în dezvoltare.

Sunt cunoscute două sisteme de organizare structurală al datelor aşa cum ele au apărut în curs de dezvoltare a sistemelor informaţionale. Anume:

Sisteme de fişiere independente (flat files sau file-based – fişiere „plate” sau fişiere independente). Reprezintă colecţii de date grupate sub formă de fişiere independente care descriu obiecte şi procese izolate din lumea reală;

Sisteme de bază de date – colecţii structurate centralizate de date. Asigură accesarea şi gestiunea datelor comună şi centralizată.

Fiecare din susnumite două sisteme majore de organizare al datelor la apariţia sa a prezentat un salt calitativ în ceea ce priveşte: flexibilitatea descrierii şi utilizării al datelor, reducerea resurselor de calcul (timpul de calcul şi spaţiul de memorie), creşterea nivelului de protecţie al datelor, etc. In continuare vom analiza în mod comparativ avantagele şi dezavantajele fiecărei din aceste două sisteme.

a) Structuri de date în forma sistemelor de fişiere independente…

Avantagele sistemelor de fişiere independente...

Dezavantajelel sistemelor de fişiere independenteProbleme cu care se confruntă aceasta formă de organizare al datelor: Redundanţă datelor. Redundanţa (excedenţa) constă în faptul că unele grupuri

sau fragmente de date sunt memorate de mai multe ori pe suportul de memorare. Date care reprezintă aceeaşi informaţie pot să apară în fişiere diferite de date, de multe ori cu format de reprezentare diferit. De exemplu, datele despre clienţii unei firme comerţiale pot să se repete în fişierele independente Clienti, Vinzari, Comenzi;

Nivelul redus de protecţie a integrităţei şi consistenţei datelor. Probleme de acest gen apar la actualizarea fişierelor. Cerinţa de integritate înseamnă că datele în proces de prelucrare nu trebuie să se piardă şi nu trebuie să apară necontrolat date noi necorecte, fantome, care nu au loc în lumea reală. Consistenţa datelor înseamnă exhaustivitatea lor semnificativă şi logică (coerenţa datelor). Completitudinea datelor semnificativă şi logică, coerenţa lor este echivalentă cu completitudinea conţinutului informaţional a domeniului concret din lumea reală. Pentru menţinerea integrităţei şi

6

consistenţei datelor actualizarea lor trebuie să se facă în toate fişierele în care apar;

Dependenţa programelor de fişierele de date. Pentru întreţinerea şi exploatarea fiecărui fişier de date, programatorii vor scrie câte un program. Orice modificare în structura fişierului de date va avea ca efect modificarea programului de aplicaţie.

b) Structuri de date organizate în formă de bază de date

Rezolvarea problemelor specifice sistemului de organizare al datelor prin fişiere independente s-a găsit în reuniunea acestor fişiere de date într-un ansamblu centralizat integru de colecţii de date – bază de date. Aceasta reuniune se bazează pe anumite principii care minimizează redundanţa datelor.Reprezintă ansambluri de date organizate după anumite criterii. Modelează obiectele şi procesele din lumea reală, precum şi interlegăturile dintre ele.

Astfel de ansamblu structurat integru permite gestiunea centralizată a datelor după standarde unice. Ca urmare, baza de date asigură utilizatorilor acces comun şi centralizat la date. Aici comun înseamnă acces a mai multor utilizatori sau programe la acelaşi fragment de date, iar centralizat înseamnă acces a unui utilizator sau program la mai multe fragmente de date.

În această colecţie pot fi eliminate date dublate (de exemplu informaţiile despre un client care apar şi în fişierul Clienti şi în fişierul Vinzari şi în fişierul Comenzi), micşorându-se foarte mult redundanţa datelor. Deoarece datele de acelaşi tip se vor găsi numai într’un singur loc, într-o colecţie integră, actualizarea lor se poate face mult mai uşor, asigurându-se astfel integritatea şi consistenţa datelor (целостность и непротиворечивость). În plus, angajaţii unui departament pot avea acces şi la datele create în careva alt departament.

Avantagele sistemelor cu baze de dateAşadar, avantajele folosirii bazei de date în locul fişierelor independente de date sunt:

Partajarea informaţiilor şi ca urmare, micşorarea redundanţei datelor (ceea ce rezultă din accesul comun la date);

Creşterea cantităţii de informaţii disponibile unui utilizator (caracterul centralizat al datelor);

Consistenţa datelor (concordanţă, compatibilitate); Integritatea datelor (datele nu se pierd în procesele de prelucrare); Securitatea datelor (acces neautorizat imposibil); Controlul centralizat al datelor; Independenţa datelor de modul de memorare. Independenţa fizică şi

independenţa logică. Transparenţa datelor. Utilizatorul nu trebuie să ştie unde concret sunt

datele;

7

Dezvoltarea standardelor.

Dezavantajelel sistemelor cu baze de date...

Pe ziua de azi predomină aplicaţiile cu sisteme de bază de date, având avantaje incontestabile faţă de sistemele de fişiere independente.

Colecţii de înregistreri ca unităţi specifice de informaţie

Pentru ambele sisteme de organizare comun este structura unităţii minimale de informaţie cu care operează – înregistrare. O înregistrare este un tip compus de date cu o structură alcătuită din câmpuri. Fiecare câmp conţine valori de acelaţi tip, care reprezintă o caracteristică careva particulară (un atrtibut) al obiectului dat. În intregime o înregistrare reprezintă un exemplar concret al entităţii din lumea reală. De exemplu: A213 CIBOTARU 2500 este o înregistrare, care conţine informaţie despre identificatorul şi salariul d-lui CIBOTARU – un exemplar al obiectului LUCRATORI. Structura acestei înregistrări este alcătuită din câmpurile IDENTIFICATOR, NUME, SALARIU. O colecţie de înregistrări de această structură va reprezenta informaţie despre salariul colectivului de lucrători a unei întreprindere.

Printre câmpurile înregistrărilor unul (ca de obicei) sau mai multe se indică ca câmpul cheie. Câmpurile cheie servesc drept unicul mijloc pentru regăsirea înregistrărilor care conţin informaţie despre exemplarul concret. De exemplu: câmpul IDENTIFICATOR al colecţiei de înregistrări LUCRATORI poate fi folosit într’un proces de căutare de tip “să se găsească numele şi salariul lucrătorului cu identificatorul A213”. Atunci câmpul IDENTIFICATOR va servi drept câmp cheie.

Înregistrările sunt unităţi informaţionale minimale care reprezintă exemplarele entităţilor din lumea reală. Din colecţii de înregistrări poate fi alcătuit sau un fişier independent în sistemul de fişiere independente sau o structură tabelară în sistemul cu baze de date. În această structură înregistrările devin linii de tabel.(усилить, отредактировать и решить, где разместить!)

1.3. Sisteme informaţionale şi sisteme informatice

Fiecare din aduse mai sus definiţii de sistem informaţional nu reflectă toate aspectele sistemelor informaţionale. Mai important este de a evidenţia două tipuri majore de astfel de sisteme – sisteme informaţionale şi sisteme informatice.+ de lărgitSisteme informaţionale. В широком смысле информационные системы используют все известные технологии обработки информации произвольной

8

природы, включая ручные, технические, компьютерные (manuale, folosind dispozitive tehnice specializate pentru automatizarea unor procese, etc.).Sisteme informatice. Inportant aici este că SI contemporane se bazează pe tehnologii informaţionale de memorare, prelucrare şi utilizare a datelor subânţelese în sensul larg al cuvântului. Ele includ cât tehnologii computaţionale şi comunicaţionale (de reţea), atât şi metode teoretice de prelucrare a informaţiei în formă de metode algoritmi şi programe.В дальнейшем мы будем рассматривать информационные системы в более узком смысле, а именно, информационные системы, основанные на компьютерных и коммуникационных технологиях хранения, обработки и использования больших массивов структурированных данных. Мы сужаем, таким образом, понятие информационной системы до системы, основанной на компьютерных, коммуникационных (hard) и программных (soft) средствах хранения и обработки больших структур данных (баз данных). Понимаемую таким образом информационную систему будем называть в дальнейшем информационной системой с базой данных или системой базы данных.

Aşadar, sistemele informatice au ca bază exclusiv tehnologiile computaţionale şi comunicaţionale ca partea hard şi tehnologiile informaţionale în formă de metode şi algoritmi teoretice de prelucrare a informaţiei.

Definiţie a sistemului informaric sintetizată:În acest sens un sistemului informaric presupune crearea şi stocarea în memoria externă (secundară) a calculatorului a unei colecţie de date organizată şi structurată după anumite concepte, care modelează careva domeniu concret din lumea reală, precum şi disponibilitatea mijloacelor de program pentru crearea şi manipularea acestei colecţie de date în scopurile automatizării gestiunii proceselor concrete de activitate umană (de producere, de bussiness, etc.) în acest domeniu.

Aşadar, baza de date reprezintă modelul informaţional a unui domeniu concret din lumea reală.

Scopul automatizării gestiunii proceselor de producere (bussiness) constă în optimizarea lor, adica în: Minimizarea resurselor umane şi materialelor necesare şi maximizarea prin

aceasta a rezultatului final; Prelucrarea operativă a datelor şi obţinerea în orice moment de timp şi într-o

formă accesibilă a informaţiei actuale cu privire la starea proceselor de bussiness;

Analiza datelor cu scopul pognozării evoluţiei lor în procesul luării deciziilor.

1.3. Componentele sistemului iformatic cu bază de date

9

Cum s-a spus, datele se consideră în calitate de suport fizic al informaţiei. Din acest punct de vedere SI presupune îndeplinirea următoarelor funcţii cu datele: Crearea structurei de date în memoria externă; Manipulare cu datele în memoria operativă – actualizarea şi prelucrarea datelor; Prezentarea datelor utilizatorului final – utilizarea datelor în gestiunea

proceselor de activitate în domeniul concret al lumii reale.

Pentru a îndeplini funcţiile nominalizate sistemul informatic trebuie să posede anumite componente (Fig. 1.1).O parte indispensabilă a sistemului o prezintă un depozit unic de informaţii – o colecţie structurată de date memorate, permanent actualizată, care poartă denumirea bazei de date. Baza de date este o parte constituientă principală a sistemului informaţional. Ea este conţinutul informatic concret a sistemului informaţional. Baza de date este nucleul de date a sistemului informaţional. Baza de date este totodată modelul informaţional al domeniul concret din lumea reală.

O altă parte principală o prezintă sistemul de gestiune a bazei de date (SGBD) – un sistem specializat de soft pentru crearea structurii colecţiilor de date, actualizarea, întreţinerea, prelucrarea şi consultarea (interogarea) bazei de date.

A treea parte importantă a sistemului informaţional o prezintă utilizatorii – cei care elaborează, întreţin şi utilizează aplicaţii cu baze de date în scopurile automatizării proceselor de gestiune din lumea reală.

Definiţii. Există şi pot fi aduse mai multe definiţii a acestor componente. Ne vom opri la următoarele:

Baza de date – în sensul îngust al cuvântului este o colecţie structurată de date, memorată în memoria externă, permanent actualizată, menită pentru modelarea şi prelucrarea automatizată a datelor în procesele de gestiune în domeniul concret al lumii reale.

Sistemul de Gestiune a Bazei de Date (SGBD) – un complex specializat de mijloace de program şi de limbaje de programare menit pentru crearea şi

10

Sistemul de gestiune cu procesele de creare a

structurii de date, memorare, actualizare şi

consultare a datelor-------------------------------

(SGBD)

Utilizatorii;Partea client a aplicaţiilor cu baze de date

Baza fizică de date

Fig. 1.1. Componentele principale a sistemului informaţional cu bază de date (sistem de bază de date).

expluatarea bazei de date (crearea structurei datelor in memoria externă, manipularea cu datele în memoria operativă, prezentarea datelor utilizatorului final). Înclude două categorii de module – module comune cu sisrtemul de operare şi module cu funcţii specifice bazelor de date.

Utilizatorii – persoane individuale şi grupuri de persoane, care crează, actualizează, întreţin şi utilizează baza de date în procesele practice de gestiune. Aici fac parte următoarele categorii de utilizatori: utilizatorii – specialiştii din domeniul concret a lumii reale (contabili, ingineri,

tehnologi, persone de conducere, etc.). Anume pentru ei se crează BD; programatorii – specialiştii din domeniul informaticii care elaborează aplicaţii

concrete cu baze de date; administratorii – administratorii de date şi administratorii bazelor de date.

Fiecare utilizator are viziunea sa individuală asupra bazei de date.

1.4. Conţinutul semnificativ a unor termeni folosiţi (toţi termenii de prezentat în Glosar)

În continuare vom explica conţinutul unor termeni frecvent folosiţi în domeniul sistemelor de baze de date.Întreţinerea bazei de date – întreţinerea bazei de date în stare actuală în procesul de utilizare. Preponderent – sarcina administratorului BD.

Aplicaţia cu bază de date – un produs de program elaborat în mediul unui SGBD, predestinat gestiunii automatizate a proceselor de activitate din domeniul concret al lumii reale.

Domeniul concret al lumii reale – un domeniul concret, integru de activitate umană, gestiunea proceselor în care se efectuiază în baza tehnologiilor informaţionale.

Domeniul concret din lumea reală se reprezintă printr-o totalitate de fragmente (părţi constituiente)Предметная область представляется множеством фрагментов, например, предприятие представляется подразделениями – цехами, дирекцией, бухгалтерией и т.д. Каждый фрагмент предметной области харакетризуется множеством объектов и процессов, использующих объекты, а также множеством пользователей, характеризуемых различными взглядами на предметную область. Словосочетание "динамически обновляемая" означает, что соответствие базы данных текущему состоянию предметной области обеспечивается не периодически, а в режиме реального времени. При этом одни и те же данные могут быть по-разному представлены в соответствии с потребностями различных групп пользователей.

11

Aici de întrrodus noţiuni de obiecte, procese, entităţi şi exemplare de obiect.

Sistem informatic ca sistem de bază de dateÎn practică termenul baza de date este folosi într-un sens mai larg – ca o colecţie structurată de date memorate precum şi mijloacele de program pentru crearea, actualizarea, prelucrarea şi consultarea (utilizarea) a acestor date. În acest caz vom vorbi despre sistem de baze de date (K. J. Deit) prezentat în Fig. 1.1. Putem vorbi şi despre un sistem informaţional cu bază de date.

На практике термин база данных используется в широком смысле как система базы данных – набор структурированных данных во внешней памяти компьютера, а также программные средства для создания, динамического обновления, обработки и использования этих данных (K. J. Deit). Можно также говорить о информационной ситеме с базой данных.

În curs de dezvoltare sistemele informaţionale în funcţie de menire au căpătat caracteristici concretizate. Se poate menţiona sisteme de baze de date, sisteme de bănci de date, sisteme de baze de cunoştinţe sau sisteme de inteligenţă artificială (sisteme de expert).

Tipuri de sisteme informatice cu baze de date (?)

В зависимости от назначения и принципов организации информационные системы могут быть следующих типов:

Sisteme de baze de date – colecţii strtucturate de date memorate în memoria de bază, precum şi mijloacele şi limbajele de program pentru crearea şi utilizarea bazelor de date.

Bănci de date – totalitatea bazelor de date precum şi mijloacele de program, mijloacele de limbaje de program şi alte mijloace menite pentru, achiziţionarea centralizată al datelor şi prelucrarea şi utilizarea lor în baza tehnologiilor informaţionale.Устаревшее название? Совпадает с определением информационной системы.

Sisteme de expert sau sisteme de inteligenţă artificială sau baze de cunoştinţe – sisteme bazate pe evaluările de expert.Evaluările de expert – evaluările cantitative şi/sau calitative aproximative ale proceselor care nu pot fi direct măsurate, ci sunt bazate pe aprecierile specialiştilor (experţilor).

Примеры: Evidenţa personalului şi volumului de muncă la o întreprindere şi calculul

salariului personalului (sistem de bază de date tipic);

12

Componenţa speţiilor a unui areal de floră şi/sau faună (bancă de date) Sistemul automatizat de obţinere a diagnozei în baza unor simptome ale

pacienţilor în medicină, sistemul de recunoaştere a formelor (din imagini, etc.) – sisteme de expert.

Cele mai dezvoltate şi pe larg folosite sunt sisteme de baze de date, dat fiind faptul că menirea lor principală constă în automatizarea prin intermediul calculatorului a proceselor din domeniile concrete de activitate umană.

Итак, информационная система это структурированный набор данных, отражающий (моделирующий?) объекты и процессы некоторой целостной предметной области, а также программные и аппаратные средства для создания, актуализации, обработки и использования этих данных. Aşadar, un sistem informaţional prezintă o colecţie structurată de date, care modelează procesele informaţionale a unui domeniul concret din lumea reală, precum şi mijloacele de soft şi hard menite pentru crearea, actualizarea, prelucrarea şi utilizarea acestor date.

Această definiţie coincide cu definiţia sistemului de baze de date, dar este mai scurtă.

(? Acolo unde se discut îregistrări?) Pentru bazele de date este specific că datele sunt stocate împreună cu descrierea lor (împreună cu date despre date - metadate). Ca de obicei, metadatele împreună cu informaţii despre utilizatori, … sunt stocate în dicţionarul bazei de date.Отличительной чертой баз данных следует считать то, что данные хранятся совместно с их описанием, а в прикладных программах описание данных не содержится. Независимые от программ пользователя данные обычно называются метаданными. В ряде современных систем метаданные, содержащие также информацию о пользователях, форматы отображения, статистику обращения к данным и др. сведения, хранятся в словаре базы данных.

1.5. Nivele de abstractizare al datelor în acele două sisteme de organizare

Noţiunea de abstractizare al datelor apare în procesul trecerii de la modul de prezentare a lor în lumea reală la modul de memorare fizică. Este o trecere continue de la viziunea utilizatorului de specialitate asupra datelor la conţinutul şi structura datelor prezentate în formă de şiruri de biţi în memoria calculatorului. (Desen?!)

13

Scopul principal de abstractizare constă în asigurarea independenţei conţinutului semantic a datelor de modul de memorare a lor pe suportul fizic şi prin asta, de modul de prelucrare a lor. Există două tipuri de independenţе a datelor: independenţa fizică; independenţa logică.

Independenţa fizică înseamnă independenţa datelor memorate faţă de programele

de aplicaţie, adica orice modificare a structurii datelor memorate nu afectează programul de aplicaţie şi reciproc, orice modificare a programului de aplicaţie nu afectează structura de date.

Independenţa logică înseamnă independenţa fiecărei colecţie individuale de date a unui utilizator faţă de colecţia generală conceptuală de date, adică pot fi definite noi câmpuri şi pot fi adăugate noi înregistrеri fără să fie afectaţi utilizatorii care nu au nevoie de ele.

Acest scop se atinge prin prezentarea datelor pe mai multe nivele de abstractizare a lor. Nominalizate mai sus două forme de organizare a datelor diferă şi prin nivele de abstractizare a datelor.

În cazul fişierelor independente de date există două nivele de abstractizare a datelor: nivelul logic care constă în descrierea structurii de câmpuri a înregistrărilor

de către programator (determină formatul fişierului reieşind din viziunea programatorului asupra datelor);

nivelul fizic care constă în metodele de înregistrare fizică în memoria externă şi regеsirea datelor la nivelul suportului de date. Este funcţia intrinsică de gestiune a fişierelor de către sistemul de operare. Rezultatele acestei gestiune sunt invizibile pentru programator. Datele din fişier se accesează prin mijloacele unui limbaj general de programare (Pascal, C), care se bazează direct pe funcţiile sistemului de operare (SO).

Acestea nivele de abstractizare parţial asigură independenţa fizică şi logică a datelor de modul de stocare a lor pe suportul fizic.

14

Данные в предметной области, имеющие семантическое содержание

Последовательности битов в физической памяти компьютера.

Данные в предметной области.

Последовательности битов в физической памяти.

Модель данных из предметной области.

Структурированные наборы записей.

В отличие от файловой организации данных организация данных в системе базы данных представляет собой метод единой централизованной структурной организации данных, реализуемый системой управления базами данных (СУБД). СУБД как специализированная программная среда заменяет собой обычный язык программирования широкого пользования. СУБД берет на себя функцию отделения пользователя от способа физического хранения данных. СУБД обеспечивает отделение пользователя от способа физического хранения данных. Независимость содержания данных от способа и формы их записи на физический носитель обеспечивается в этом случае представлением (абстрагированием) данных на трех уровнях – внутреннем, концептуальном и внешнем.

Три уровня представления или абстрагирования данных:

1. внутренний (физический) 2. концептуальный (global, conceptual logic) 3. внешний (пользовательский)

Каждому уровню соответствует своя модель данных (свое представление данных). Модель данных специфицируется с помощью языка описания данного уровня. Модель каждого уровня, представленную на языке описания, принято называть схемой.

В основе трехуровневого представления лежит концептуальный уровень.

Nivelul conceptual (conceptual global sau nivelul logic) descrie datele şi interlegăturile între ele din cel mai general punct de vedere. Reprezintă o generalizare bazată pe anumite concepte a viziunilor tuturor utilizatorilor individuali. Este o descriere conceptual globală a domeniului concret din lumea reală în termenii SGBD concret. Reprezintă modelul informaţional integru a domeniului concret din lumea reală.

Является обобщением локальных представлений пользователей, т.е. является общим глобальным описанием предметной области в терминах (концептах) конкретной СУБД. Важно отметить, что концептуальный уровень исполняет роль некоторого стандарта пользователей, согласуя их представление о предметной области в единое целое.

Nivelul intern (fizic) Внутренний уровень наиболее близок к физическим структурам хранимой информации, т.е., именно внутренний уровень учитывает методы доступа операционной системы (ОС) для манипулирования данными на физическом уровне. Позволяет скрыть подробности физического хранения данных от концептуального уровня. Отделение внутреннего уровня от концептуального обеспечивает так называемую физическую независимость данных.

15

На внешнем уровне описываются различные подмножества элементов концептуального уровня для представлений данных различным пользовательским программам. Каждый пользователь получает в свое распоряжение часть представлений о данных, но полная концепция скрыта (частный взгляд пользователя на информационные процессы в предметной области, через концепты конкретной СУБД). Отделение внешнего уровня от концептуального обеспечивает логическую независимость данных.

Spre deosebire de fişiere independente baza de date reprezintă un mod de organizare a datelor oferit de sistemul de gestiune a bazelor de date (SGBD) folosit. SGBD ca sistem de program specializat înlocuieşte limbajul de programare obişnuit. Pentru asigurarea independenţei datelor abstractizarea datelor în cazul bazelor de date trebuie să se facă pe cel puţin trei nivele: Nivelul intern (sau nivelul fizic) sau baza de date fizică este reprezentat de

colecţia de înregistrări memorate pe suportul fizic de memorare, înregistrări care conţin datele propriu-zise dar şi informaţii suplimentare despre structura colecţiilor de înregistrări. În unele SGBD înregistrările pot fi grupate în fişiere. Gestiunea proceselor de manipulare cu înregistrările la nivel fizic este funcţia intrinsică al SGBD+SO (sistemului de operare). Nivelul intern se concretizează în schema internă a bazei de date formată din:1. set de programe care interacţionează cu sistemul de operare şi asigură acces

optimal la date;2. set de fişiere ce conţin datele propriu-zise, alcătuite din articole sau

înregistrări. Nivelul conceptual (conceptual global sau nivelul logic) reprezintă descrierea

unităţilor de structură (структурных элементов) din care este formată baza de date integră (globală) şi a legăturilor dintre ele. Unităţile logice (структурные элементы) reprezintă entităţile din domeniul concret al lumii reale şi interlegăturile dintre ele. La concret ele sunt formate din structuri de înregistrări cu propriertăţi specifice ale câmpurilor care reflectă proprietăţile semantice ale datelor (restricţii, validare, etc.). Cu alte cuvinte, nivelul reprezintă modelul integru a domeniului concret format în cadrul unei sau altei metode concretă. Nivelul exprimă viziunea programatorului de aplicaţie sau mai bine zis a administratorului asupra structurii globale de date formalizată după anumite concepte. În modelul conceptual sunt specificate toate constrângerile (restricţiile) aplicate asupra datelor, care determină restricţiile operaţiilor de actualizare. Ele sunt necesare pentru a asigura integritatea şi consistenţa datelor. Nivelul se concretizează în schema generală a bazei de date în întregime.

Nivelul extern (sau nivelul utilizatorului final) reprezintă modelul extern cu care operează utilizatorul final a bazei de date ca specialist din domeniul concret a lumii reale. Exprimă viziunea utilizatorului final asupra bazei de date (şi a administratorului BD, bineînţeles). Nivelul extern este format din seturi de unităţi de structură (структурных элементов) de la nivelul

16

conceptual cu care operează un utilizator sau un grup de utilizatori concret. Nivelului îi corespunde structura conceptuală a schemelor individuale ale utilizatorilor formate din unităţi de structură (структурных элементов). Se numesc şi scheme externe. Cea mai importantă utilitate a unei scheme individuale este aceea că prin intermediul ei se poate controla accesul unui grup de utilizatori la baza de date. Deoarece utilizatorul are acces la baza de date nu prin modelul conceptual, ci prin schema lui individuală, este posibil de a ascunde unui utilizator acele unităţi de structură cu conţinutul lor informatic la care el nu are dreptul de acces. Schemele individuale pot se controleze şi operaţiile pe care le poate executa utilizatorul cu unităţile de structură: datele din unele unitеţi de structură îi se permite să le actualizeze, iar din altele îi se permite numai sе le consulte. Interacţiunea utilizatorilor cu schemele lor individuale se efectuiază prin interfaţa aplicaţiei.

Acum ne vom întoarce la schema generală a SI din Fig. 1.1 şi vom comenta-o de pe poziţiile de niveluri de abstractizare al datelor.(conţinutul, structura şi funcţiile unui sistem general – socio-uman, informaţional, fizic, etc.; viziunile tuturor persoane întruniţi în SI asupra diferitor scheme; ce este o aplicaţie cu BD, etc.).

Independenţa datelor (независимость данных)

Основная цель системы базы данных – обеспечение независимости данных. Ее можно определить как независимость приложений к изменениям в структуре хранения данных и в методах доступа к ним.

Avantajul principal al organizării structurii datelor în formă de bază de date şi gestiunea datelor prin intermediul SGBD constă în asigurarea a două tipuri de independenţе a datelor: independenţa fizică; independenţa logică.

Independenţa fizică înseamnă independenţa datelor memorate de programele de aplicaţie, adica orice modificare a structurii datelor memorate nu afectează programul de aplicaţie şi reciproc, orice modificare a programului de aplicaţie nu afectează structura de date.

Independenţa logică înseamnă independenţa fiecărei scheme individuale a unui utilizator faţă de schema generală conceptuală, adică pot fi definite noi câmpuri şi pot fi adăugate noi înregistrеri în baza de date fără să fie afectaţi utilizatorii care nu au nevoie de ele. În plus, baza de date poate fi reorganizată (pot fi regrupate câmpurile din înregistrări) pentru a face faţă cerinţelor unui nou utilizator fără a fi afectaţi vechii utilizatori. Eliminarea unor entităţi din baza de date poate afecta însă utilizatorii care fac referiri la acele entităţi.

17

Independenţa datelor înseamnă posibilitatea dezvoltării bazei de date fără prejudiţii logice pentru aplicaţiile existente.

1.6 Obiectivele, structura şi funcţiile principale ale SGBD

Un sistem de bază de date are drept componente mari (Fig. 1.1): baza fizică de date pe hardware (colecţie structurată de date – colecţii de înregistrări propriu-zise, ca de obicei în formă de fişiere fizice invizibile pentru utilizatori), software-ul (SGBD, programele de aplicaţie etc.), utilizatorii. Rolul central între aceste componente evident îl joacă SGBD.

Menirea principală a lui SGBD – susţinerea elaborării şi exploatării a aplicaţiei concrete cu bază de date.

Obiectivele unui SGBDSe are în vedere susţinerea următoarelor acţiuni generale (obiectivele SGBD) asupra datelor: crearea structurilor de date care adecvat reflectă ansamblul integru de procese

din domeniul concret a lumii reale; actualizarea datelor – introducerea datelor noi (INSERT), modificarea datelor

(UPDATE), ştergerea datelor (DELETE); consultarea datelor – interogări de selecţie şi prelucrare (SELECT); administrarea datelor; protecţia datelor; prezentarea datelor (utilizarea datelor)?.

Pentru realizarea acestor obiective sunt necesare mijloace hard şi soft: Hard – memorie de bază (internă, operativă); memorie externă (pe disc, pe

suport magnetic); procesor; unităţi fizice întrare/ieşire. Soft – SGBD; soft-aplicaţie de business proces şi interfaţa utilizatorului,

utilitare.

Acum putem preciza schema din Fig. 1.1. astfel ca în Fig. 1.2.

18

Sistemul de gestiune a proceselor de creare a

structurii, actualizare şi interogare a datelor

-------------------------------(SGBD)

UtilizatoriiBusines aplicaţiiUtilitare

Baza fizică de date

(fişiere/colecţii de înregistrări de date)

Fig. 1.2. Arhitectura unui sistem de bază de date

Remarcă: Trebuie să distingem sistemul de gestiune a bazei de date (SGBD) şi aplicaţia concretă de bază de date: sistemul de gestiune a bazei de date (SGBD) – soft instalat pe hard pentru

crearea, actualizarea şi exploatarea aplicaţiei de bază de date; aplicaţia de bază de date – datele propriu-zise, care reprezintă modelul

informaţional al universului de discurs şi programele de aplicaţie care realizează business-procesele şi interfaţa cu utilizatorul (ca exemplu – baza de date VINZARI).

SGBD este un ansamblu complex de programe care asigură interfaţa între o bază de date fizică şi utilşizatorii acesteia. Deci – este o slugă la doi stăpâni. SGBD este componenta software a unui sistem de bază de date care interacţionează cu toate celelalte componente ale acestuia, asigurând legătura şi interdependenţa între ele.

Aşadar, sistemul de gestiune a bazei de date (SGBD) este unul din cele mai importante componente a sistemului informaţional.

Funcţiile principale ale unui SGBD

Realizarea obiectivelor nominalizate este asigurată de SGBD printr-o serie de componente care permit efectuarea unor operaţii specifice. Acestea operaţii sau activităţi pot fi grupate pe funcţii astfel încât, una sau mai multe activităţi, relativ omogene, vor realiza o anumită funcţie. În ciuda unor particularităţi specifice diferitor SGBD, există câteva funcţii general valabile pentru toate tipurile de SGBD:

Funcţia de descriere a datelor. Gestiunea datelor în memoria externă – definirea (crearea) obiectelor de structură a bazei de date cu ajutorul limbajului de definire a datelor (DDL);

Funcţia de manipulare a datelor. Este cea mai complexă. Realizează regăsirea, actualizarea şi prelucrarea datelor din baza de date cu ajutorului limbajelor de manipulare (DML) şi interogare (DQL) al datelor. Asigură mulţimea de modalităţi necesare pentru accesarea datelor;

Funcţia de susţinere a limbajului BD – interpretarea comenzilor. De fapt istoric există două sublumbaje – limajul de descriere (creare) a datelor (DDL) şi limbajul de manipulare a datelor (DML);

Funcţia de administrare. Este complexă, se îndeplineşte de administratorul cu o bogată experienţă. Constă în autorizarea accesului la date, copierea de rezervă a bazei de date cu o periodicitate predefinită, refacerea bazei de date în caz de incidente, utilizarea eficientă a spaţiului de memorie externă şi internă, efectuarea analizelor statistice pe baza de date.

Funcţia de protecţie al datelor. Asigură securitatea datelor. Se concretizează în jurnalizarea modificărilor (tranzacţiilor) în starea bazei de date şi restaurarea automată a BD în cazurile de blocare fatală a sistemului hard;

Funcţia de utilizare a datelor. Asigură mulţimea de modalităţi necesare pentru accesarea datelor. Ca de obicei se concretizează în mulţimea

19

interfeţelor pentru comunicarea tuturor utilizatori cu baza de date. Oferă prezentarea datelor în forme grafice, textuale, tabelare, etc.

Componentele principale a unui SGBD(De refăcut) nucleul, care asigură:

1. Crearea structurei de date în memoria externă (funcţia de descriere a datelor, Modulul de gestiune a datelor în memoria externă);

2. Manipularea datelor în memoria de bază (funcţia de manipulare a datelor, Modulul…);

3. Integritatea şi securitatea datelor (jurnalizarea datelor); motorul SGBD, asigură îndeplinirea optimă a interogărilor de modificare şi

selecţie al datelor şi crearea codului îndependent-maşină intern pentru subrutine memorate;

subsistemul de interpretare on-line – o versiune prescurtată a lui SGBD care permite numai îndeplinirea aplicaţiei. Nu conţine mijloace de elaborare şi modificare ale structurii datelor şi de programare. Poate fi oferită utilizatorului final împreună cu aplicaţia elaborată.

utilitare externe – programe de deservire care asigură posibilităţi adiţionale de deservire a sistemului informaţional (testarea funcţionalităţii, etc.).

Рис. 1.2. Componentele principale ale SGBD.

СУБД может содержать интегрированную оболочку, из которой можно осуществлять манипуляцию данными, а также встроенный специализированный язык программирования для разработки собственных приложений. Как правило это язык программирования интерпретирующего типа.

20

СУБД однопользовательские и многопользовательские.

Интерфейсы: Встроенный интегрированный интерфейс (управляет процессором языка

запросов), основанный на меню и формах; Командный интерфейс; Интерфейс приложения, разработанный с помощью встроенного языка

программирования.

PS: De modificat aici în stilul: Arhitectura CODASYL a unui SGBD (Velicanu et all, p. 49); Arhitectura ANSI a unui SGBD (Velicanu et all, p. 50); Arhitectura unui SGBD pe componente (Velicanu et all, p. 52).

What are the difference between DDL, DML and DCL commands?http://www.orafaq.com/faq/what_are_the_difference_between_ddl_dml_and_dcl_commands

1.7. Arhitectura unui SGBD. Standardul ANSI/SPARC

Arhitectura SGBD presupune principiu de structură recomandat pentru un SGBD. Utilizate în industrie SGBD au multe diferenţe între ele, dar toate din ele se construiesc după concepţia de arhitectură ANSI/SPARC elaborată de institutul standartelor american ANSI. Proiectul arhitecturii a fost aprobat în 1975 de subcomitetul SPARC (Standards Planning and Requirements Committee) al ANSI.

Conform recomandărilor ANSI/SPARC, arhitectura SGBD se prezintă prin trei nivele de reprezentare al datelor: intern, conceptual şi extern

intern (fizic) conceptual (conceptual global, intermediar, logic) extern (de utilizator)

Каждому уровню соответствует своя модель данных (свое представление данных). Модель данных специфицируется с помощью языка описания данного уровня. Модель каждого уровня, представленную на языке описания, принято называть схемой.

Стандарт ANSI/SPARC. Представленная на рис. 1.3 архитектура СУБД является обобщенной, т.е. с ee помощью можно с единых позиций как

21

рассмотреть общие принципы проектирования баз данных, так и выявить особенности структур конкретных систем.

Рис. 1.3. Arhitectura SGBD în standardul ANSI/SPARC.

Описание архитектурыАрхитектура представлена тремя уровнями: внутренним, концептуальным и внешним.

Внутренний уровень наиболее близок к физическим структурам хранимой информации. Именно внутренний уровень учитывает методы доступа операционной системы для манипулирования данными на физическом уровне, что в некоторой степени снижает независимость операций обработки данных от технических средств, однако, в идеале СУБД может располагать внутренним уровнем, который бы не опирался на средства ОС.

Внешний уровень является уровнем пользователей СУБД, т.к. он является уровнем восприятия каждого пользователя. В принципе для каждого пользователя создается свой внешний уровень (схема - модель с соответствующим языком описания данных). Типичным воплощением

22

внешнего уровня является использование представлений (VIEW) в языке SQL [3].

Концептуальный уровень является обобщением локальных представлений пользователей, т.е. является общим глобальным описанием предметной области в терминах (концептах) конкретной СУБД. Важно отметить, что концептуальный уровень исполняет роль некоторого стандарта пользователей, согласуя их представление о предметной области в единое целое.

Пользователи подразделяются на прикладных программистов и пользователей непрофессионалов. Для каждого пользователя используется свой язык общения с базой данных.

De obicei o bază de date este memorată într-unul sau mai multe fişiere. Bazele de date sunt manipulate cu ajutorul sistemelor de gestiune a bazelor de date.Cel mai răspândit tip de baze de date este cel relaţional, în care datele sunt memorate în tabele. Pe lânga tabele, o bază de date relaţională mai poate conţine: indecşi, proceduri stocate, trigger-e, utilizatori şi grupuri de utilizatori, tipuri de date, mecanisme de securitate şi de gestiune a tranzacţiilor etc. Alte tipuri de baze de date sunt modelul ierarhic, modelul orientat pe obiecte şi, mai nou, modelul XML.

1.8. Structuri şi modele de date generalizate. Tipuri de SGBD

Ne amintim structuri de organizare al datelor deja discutate: două sisteme de organizare al datelor aşa cum ele au evoluţionat în timp –

fişiere independente şi baze de date;

niveluri de abstractizare al datelor în acele două sisteme de organizare. În cazul sistemului de organizare cu baze de date avem: nivelul intern – reprezintă colecţii structurate de înregistrări memorate la nivelul fizic (ca de obicei – structurate în formă de fişiere), nivelul conceptual global (logic) – format din unităţi logice şi reprezintă viziunea programatorului asupra datelor aşa cum ele sunt, nivelul extern – format din scheme individuale, reprezintă viziunea utilizatorului final.

La fiecare nivel de abstractizare al datelor avem structuri specifice de date formate din înregistrări (?): structuri de date memorate la nivel fizic (nivelul intern); ansamblu de colecţii de date integrate într-o structură logică formată după

anumite concepte. Acesta este nivelul conceptual global. Modelul de date care îl prezintă este modelul informaţional al domeniul concret din lumea reală;

Scheme individuale la nivelul extern (nivelul utilizatorului).

23

Acestea trei niveluri evident corespund acelor trei componente principale a sistemului informaţional (veză Fig. 1.2) şi ne asigură independenţa datelor.

În continuare vom analiza în detalii structurarea datelor în fiecare din acestea trei niveluri. Vom începe cu nivelul conceptual global ca cel mai important. modele de date generalizate sau globale – structuri logice conceptuale de

date.

Modele de date generalizate sau globale implementate în SGBD

Pentru structurarea datelor în baza de date la nivelul conceptual global sunt utilizate aşa-numite modele de date generalizate sau modele de date mai pe scurt. Există o diversitate mare de tipuri obişnuite de date, dar dintre ele pot fi construite structuri de date generalizate – modele de date, care vor fi specifice pentru SGBD-ul dat.

Dacă tipul de date este proprietatea principală a unei mărime (variabilă), atunci modelul de date prezintă o structură integră globală al datelor construită după anumite concepţii.

Modele de date – reprezintă structuri de date generalizate, construite după criterii conceptuale care reflectă viziunea programatorului sau proiectantului asupra datelor din lumea reală.

Cu alte cuvinte, modelul de date constituie un ansamblu de concepte şi instrumente necesar pentru a construi (descrie, prezenta) structura globală a bazei de date sau schema bazei de date.

Modele de date se diferă prin modul de stabilire legăturilor dintre colecţii de date.

Amintim aici că ca elemente de structură de date în lumea reală avem entitate ca o colecţie de date de acelaşi tip şi exemplare de entitate ca reprezentanţi concreţi al entităţilor.

Baza de date fiind de fapt o colecţie de entităţi reprezentate prin structuri generalizate sau modele de date foloseşte organizarea acestor entităţi in mai multe moduri astfel încât structura de date să corespundă cât mai bine necesităţilor utilizatorului.

Tipul de date este caracterizat prin specificarea a două momente: domeniului de valori al datelor; operaţiilor admisibile asupra datelor.

Modelul de date reprezintă structuri generalizate de date şi constă din trei componente: 1. obiecte (elemente) de structură a datelor – determină obiectele (elementele)

de structură şi regulile de organizare acestor obiecte în structură. Reprezintă

24

viziunea utilizatorului în general asupra structurilor de date cu care se descriu datele din lumea reală;

2. restricţii de integritate structurală sau integritatea structurală a modelului – un set de reguli (restricţii) asupra valorilor datelor, care asigură integritatea, coerenţa şi consistenţa (целостность, непротиворечивость и устойчивость) datelor. Este un mecanism de susţinere a corespondenţei dintre datele din baza de date şi datele din lumea reală. Se bazează pe set de reguli formale;

3. operatorii modelului – set de operatori pentru definirea obiectelor de structură şi manipularea cu datele propriu zisă. Modelul de date presupune existenţa ca minimum a două grupuri de operatori – două sublimbaje: sublimbajul de creare şi memorare ale elementelor de structură (DDL – Data Definition language) şi sublimbajul de manipulare al datelor în structură (DML – Data Manipulation Language). Include operaţii de actualizare şi interogare a datelor.

Clasificarea modelelor şi bazelor de date

Modelul de date implementat în SGBD concret determină tipul acestui SGBD.Sunt cunoscute următoarele modele de date (şi respectiv baze de date). Le prezentăm în ordinea de evoluţie în timp:

ierarhice (arborescente); de reţea; relaţionale; postrelaţionale (modelul orientat pe obiecte, obiectual). şi, mai nou, modelul XML

Modelul de date este o structură logică sau global conceptuală, iar baza de date care îl implementează este o realizare (aplicaţie) concretă sau o structură fizică. Acest fapt poate fi reprezentat prin următoarea diagramă

1.6.1. Modele de date ierarhice şi de reţea

Modele ierarhiceÎn acest model de date datele se prezintă printr-o structură în formă de noduri. Între fiecare două noduri există relaţii, dar nu de tip egalitate ci de tip subordonare. Nodul conducător în relaţie este nodul părinte iar nodul condus este nodul copil. Sau: nodurile referite să numesc noduri părinte, iar nodurile care referă – noduri copil. (situaţia asimilară cu relaţii client – server)

25

Domeniul concret din lumea reală

(structură din entităţi şi legături dintre ele – modelul lumii reale)

Modelul de date(structuri conceptuale din

obiecte de structură şi legătiri dintre ele –

modelul conceptual)

Baza de date(structuri din unităţi fizic

memorate)

Fiecare nod copil să referă numai la un singur nod părinte. Cu alte cuvinte fiecare nod copil are un singur nod părinte cărui i să supune.

Pentru a forma legături nodurile trebuie se conţină cât datele propriu zise atât şi referinţe (pointeri) la alte noduri. Deci structura unui nod este următoarea

Cu alte cuvinte, nodurile sunt puncte care conectează ramurile unui arbore descendent. (de prezentat desenul structurii arborescente) Un nod de pe nivelul inferior este subordonat unui singur nod din nivelul ierarhic imediat superior, dar poate fi în relaţie cu n noduri aflate la nivelul inferior. Altfel spus fiecare entitate are un singur nod părinte (parent node), dar un părinte poate avea mai multe noduri copil (child nodes). Este cazul legăturii de tip unu la mulţi. Pentru a găsi o înregistrare anumită (? exemplar de entitate sau înregistrare) trebuie să se pornească cu nodul părinte de pe primul nivel şi să se coboare pe arbore până la copilul care conţine această înregistrare.

Baze de date ierarhiceBazele de date care implementează modelul ierarhic de date se numesc baze de date ierarhice (hierarchical database). Un exemplu de organizare ierarhică este baza de date pentru sistemul de rezervare a biletelor la rutele de autobus, structuratе pe 3 nivele.

Avantajele şi dezavantajele a modelului ierarhicAvantaje: Acces rapid la date. Datele se regăsesc după adrese de memorie (pointeri) şi

nu după valori. O structură rigidă de legături se construieşte printr-o structură de referinţe care sunt referinţe la adrese fizice. Aceasta structură se crează în prealabil şi cere eforturi adiţionale;

Există presupuneri că volumul necesar de memorie pentru stocarea datelor şi legeturilor între ele în unele cazuri este mai mic decât în alte modele de date.

Dezavantage. Într-un astfel de tip de organizare apar următoarele probleme: Necesită resurse mari de memorie (?). Odată cu datele propriu zise se

memorează şi totalitatea de pointeri (nu este corect);

26

Data Referinţă 1 Referinţă 2 Referinţă ...

Bucureşti

Cluj Constanţa Timişoara Iaşi

Dacă se şterge un nod părinte, se şterg toate nodurile copil subordonate. Partea negativă a structurii rigide;

Un nod copil poate fi adăugat numai dacă au fost adăugate mai întâi nodurile părinte;

Între nodurile copii nu pot fi stabilite relaţii (dar ele nu pot fi stabilite şi în alte modele. Mai mult ca atît: cu mici excepţii ele nu au loc şi în lumea reală);

Nu orice domeniu din lumea reală poate fi adecvat descris prin acest model.

Drept un alt exemplu de model ierarhic putem menţiona structura de cataloage în sistemul de operare a calculatorului.

Exemplu de Bază de date ierarhică COMENZI.Avem obiecte: Sectoare, Colaboratori, Clienti; Procese: Contracte

27

Sector

SctDenumSctSefSctTelefon

Colaborator

ClbNumeClbFunctiaClbSalariu

Colaborator

SctDenumSctSefSctTelefon

…

Client

ClnNumeClnAdresaClnTelefon

Contract

CntNumarCntDataCntSuma

Contract

CntNumarCntDataCntSuma

…

Colaborator

ClbNumeClbFunctiaClbSalariu

Colaborator

SctDenumSctSefSctTelefon

… Colaborator

SctDenumSctSefSctTelefon

Colaborator

ClbNumeClbFunctiaClbSalariu

Contract

CntNumarCntDataCntSuma

Contract

CntNumarCntDataCntSuma

…

Fig 1.5. Schema conceptuală a bazei de date COMENZI. Model ierarhic.

Dacă vom introduce un sistem de pointeri Cln, Cnt, Clb către fiecare exemplar de Client, Contract şi Colaborator respectiv, atunci un element din lista Contracte asociat de un nod careva cu adresa Cnt124 va avea următoarea formă: |Cln25 124 01.10.2012 35000 Clb17|. Informaţia stocată sună în felul următor: clientul cu pointer Cln25 a îcheeat contract cu numărul 124 pe data de 01.10.2012 în, suma contractului fiind 35000. Aşadar, o structură conceptual globală de date creată după în modelul ierarhic prezintă o colecţie de scheme arborescente. Legăturile dintre nodurile arborelor sunt de tip 1:∞ (unu la mai mult) şi sunt realizate printr-o structură de pointeri – referinţe (adrese) fizice în spaţiul memoral. Arborele Colaborator – Contract este introdus în schema conceptuală pentru admite faptul că un colaborator poate să îndeplinească mai multe contracte.

Model de reţeaPrezintă o aranjare asămănătoare cu cea ierarhizată a nodurilor, cu deosebirea că un nod copil poate să aibă mai multe noduri părinţi. Şi în acest caz există o subordonare dintre noduri, cu deosebirea că un nod copil poate să aibă mai multe noduri părinţi (legătura mulţi la mulţi). Între nodurile părinte şi nodurile copil se adaugă conexiuni adiţionale numite pointere. Aceasta înseamnă că unui nod i se poate adăuga o cale nouă şi că pot fi trasate în jos ramuri noi.

Baze de date reţea (network database).În această organizare, fiecare exemplar de entitate (nod?) poate avea un număr nelimitat de conexiuni, dispărând noţiunea de entitate (nod?) ierarhic superioară.Un exemplu de astfel de organizare este baza de date a produselor care se execută într-o fabrică. Fiecare produs este format din mai multe ansambluri, iar fiecare

ansamblu este format din mai multe piese. Fiecare piesă poate intra în componenţa mai multor ansambluri, iar fiecare ansamblu poate intra în componenţa mai multor produse.

Modelul de tip reţea cum se poate observa este mai flexibil şi în multe cazuri mai eficient decât cel ierarhic. Dar acest avantaj se obţine pe contul mai multor eforturi de organizare preliminare şi folosirei mai multor resurse de memorare. Modificarea structurii în asest caz este şi mai anevoioasă.

28

Exemplu de Bază de date de tip reţea COMENZI.Avem obiecte: Sectoare, Colaboratori, Clienti; Procese: Contracte

În modelul reţea noi pe lingă legături Contract – Colaborator am introdus şi legături Colavborator – Contract (linii întrerupte) şi prin asta am admis faptul că un colaborator păoate să îndeplinească mai multe contracte. Arborele Colavborator – Contract din schema ioerarhica (Fig. 1.5) a devenit de prisos şi a fost înlăturat.

1.6.2. Modelul relaţional de date

29

Sector

SctDenumSctSefSctTelefon

Colaborator

ClbNumeClbFunctiaClbSalariu

Colaborator

SctDenumSctSefSctTelefon

…

Client

ClnNumeClnAdresaClnTelefon

Contract

CntNumarCntDataCntSuma

Contract

CntNumarCntDataCntSuma

…

Colaborator

ClbNumeClbFunctiaClbSalariu

Colaborator

SctDenumSctSefSctTelefon

… Colaborator

SctDenumSctSefSctTelefon

Fig 1.6. Schema conceptuală a bazei de date COMENZI. Model reţea.

Принципы реляционное модели заложены доктором Коддом (E Codd) в 1969-1970 гг.

Формальная теория, которая лежит в основе реляционных систем, называется реляционной моделью. Реляционная модель изучает материал только на логическом уровне и не затрагивает физический уровень. В реляционной модели рассматривается три аспекта данных – структура (объекты структуры), структурная целостность и обработка данных (операторы манипулирования данными).

Реляционная модель/система – это такая теория/система, в которой выполняются условия:

Obiecte de structură: unicele obiecte de structură sunt tabele, şi anume tabele relaţionale. Datele sunt privite în formă de tabele relaţionale şi nici cum astfel;

Integritatea structurală a modelului: este prezentată de un sistem de reguli sau restricţii asupra valorilor admisibile a datelor în tabele. Acestea reguli (restricţii) asigură integritatea structurală a modelului prin stabilirea legăturilor dintre tabele şi corespondenţa dintre datele din baza de date şi datele din lumea reală;

Operatorii modelului: в распоряжении пользователя имеются реляционные операторы для определения структуры и манипулирования данными SELECT (RESTRICT), PROJECT, JOIN.

Exemplu de Bază de date de tip relaţională COMENZI.Avem obiecte: Sectoare, Colaboratori, Clienti; Procese: Contracte

30

Sectoare

SctIdSctDenumSctTelefon

Colaboratori

ClbIdClbNumeClbSectorClbFuncţiaClbSalariu

Contracte

CntNumarCntDataClientExecutantCntSuma

Clienti

ClnIdClnNumeClnAdresaClnTelefon

1

∞∞

1

∞∞

1

∞∞

Fig 1.7. Schema conceptuală a bazei de date COMENZI. Model relşaţional.

Cum vedem, în modelul relaţional legăturile dintre obiectele schemei conceptuale sunt realizate prin valori egale a atributelor din relaţii în legătură. Referirea şi regăsirea datelor se face aici prin valorile datelor şi nu prin adresare fizică ca în modelul ierarhic, ceea ce duce la cea mai mare problemă a modelului relaţional: acces lent la date în cazul bazelor mari de date.

1.9. Starea contemporană în teoria şi practica bazelor de date(? La sfârşitul capitolului?)

Modele şi baze de date postrelaţionale – baze de date obiectuale; Aplicaţii de baze de date în internet. Web tehnologii cu baze de date; Sisteme OLTP operaţionale, tranzacţionale. Sunt sisteme descriptive care

conţin date operative; Sisteme OLAP. Data Warehouse şi Data Mining. Sisteme contemporane de

analiză analitică şi intelectuală a datelor; Baze de date distribuite; Baze de date mari şi supra mari. Tehnologii MapReduce – mpodelul

calculelor distribuite; Baze de date şi Grid Computing.

31

2. MODELUL RELAŢIONAL DE DATE

Cel mai flexibil model de organizare îl reprezintă modelul relaţional de date implementat de bazele de date relaţionale. Autorul modelului este doctor E.Codd (lucrările din 1969, 1970).

Succesul modelului relaţional se explică prin trei momente: Simplicitate şi percepere intuitivă a structurii. Toată lumea foloseşte pe larg

date în formă de tabele; Existenţa metodelor simple şi totodată eficiente de acces la date. În model nu

există căi de acces ierarhizate. Datele nu se regăsesc prin mecanismul de pointeri la adrese fizice ca în modelul ierarhic. Datele se regăsesc şi se referă prin valorile lor. Problema vitezei de acces reduse din acest motiv se rezolvă prin mecanismul de indexare a datelor în tabele;

Şi, în sfârşit, modelul are o fundamentare strictă matematică – teoria mulţimilor. Se poate spus că teoria mulţimilor este o teorie matematică a relaţiilor.

Ca rezultat, metoda relaţională are avantage evidente: Predictibilitatea rezultatelor de prelucrare a datelor. În baza modelului

relaţional se află modelul matematic, de aceea orice interogare faţă de baza de date generează un rezultat unic, independent de organizarea fizică a datelor;

Simlicitatea descrierii datelor. Domeniul concret din lumea reală în mod natural se descrie în termenii de tabele;

Eficienţa prelucrării datelor.

Aici (???) de date trei paragrafe:1. Simplicitatea modelului ca rezultat al nivelului înalt de abstractizare a

datelor. Descrierea datelor se face la nivelul cel mai apropiat de utilizator. Plăţile pentru asta – acces neeficient la date în cazul bazelor de date mari.

2. Metode eficiente de acces la date. Indexarea tabelelor relaţionale.3. Teoria mulţimilor. Definiţia relaţiei în teoria mulţimilor.

În continuare vom analiza în detalii trei părţi de structură a modelului de date relaţional.

2.1. Trei părţi constituiente a modelului relaţional

În cadrul teoriei mulţimilor a fost dată definiţia matematică a relaţiei. Valorile datelor în astfel relaţie au fost elementele mulîimilor – date abstracte.

În teoria lui Codd elementele modelului relaţional precum şi structura modeluluii se definesc reieşind din semantica (sensul) datelor.

32

Conform teoriei lui Codd (lucrarea principală din 1970) modelul relaţional de date constă din trei părţi sau este definit prin trei dimensiuni (elemente), şi anume (în interpretarea lui Date):

Structura modelului relaţional de date. Aici se definesc obiectele care formează structura modelului relaţional. Să postulează că unica structură de date este formată din relaţii normalizate de gradul n şi legături dintre ele;

Integritatea structurală a modelului relaţional de date. Aici se definesc restricţiile de integritate, şi anume acelea restricţii care asigură menţinerea integrităţii, coerenţei (логическая согласованность, совместимость; se compune din elemente strâns legate între ele; связность – interlegături strânsă între date) şi consistenţei (содержательность, семантическая полнота данных в базе данных адекватная информационному содержанию предметной области) datelor. În primul rând vorba merge despre restricţii de integritate obligatorii de definit şi de respectat atunci când se lucrează cu modelul relaţional, şi anume restricţii de tip: unicitatea cheii; integritatea entităţii şi integritatea referenţială;

Operatorii modelului relaţional de date sau operatorii de gestiune a datelor. Aici se descriu două modalităţi de manipulare a datelor – un set de operatori relaţionali şi calculul expresiilor cu aceşti operatori şi anume algebra relaţională şi calculul relaţional. Setul de operatori a algebrei relaţionale constă din operatori care operează cu relaţii, atribute şi corteje.

Consistenţa datelor – логическая согласованность (соответствие) между данными модели и данными (информацией) предметной области, их смысловая полнота и непротиворечивость.

Înainte de a formula noţiunea de relaţie în teoria lui Codd vom da o analiză a tipurilor de date existente sub prisma folosirii lor in modelul relaţional.

În genere există tipuri de date: simple sau scalare (tipuri de date de bază – şiruri de caractere, numerice, logice); compuse sau vectoriale care au o structură dintr-o mulţime de elemente care au indexe

(masive, tablouri, înregistrări); referinţe.

Tipurile compuse, cele mai frecvent folosite sunt înregistrări care prezintă nu alt ceva decât tupluri a produsului cartezian al mulţimilor.

Tipuri şi structuri de date în modelul relaţional. Aici accentuim două momente:

1. Date atomice. Important: De fapt pentru modelul relaţional tipul de date ca atare nu importă – modelul relaţional cere ca tipurile folosite de date să fie considerate ca simple, atomice sau, mai bine zis, indivizibile. Cerinţa de tipuri atomare a modelului relaţional înseamnă că în operaţiile pe relaţii structura intrinsecă a tipurilor (cortejelor) de date nu poate fi luată în considerare.

2. Importanţa semnificaţiei datelor. În relaţie se conţin numai acele date care satisfac predicatul relaţiei, adică au un sens careva (conţinutul semantic).

33

2.2. Definirea relaţiei conform teoriei lui Codd. Noţiuni formal logice de domeniu, atribut, relaţie

Redarea conţinutului semantic al datelor este una din cele mai complexe probleme în teoria bazelor de date. În teoria s-a pentru a rezolva această problemă Codd a mers pe calea logicii formale. El a întrodus noţiuni fundamentale abstracte de domeniu, atribut şi relaţie, care reflectă logica interlegeturilor dintre date, conţinutul şi sensul lor.

Rezolvarea de bază a acestei probleme constă în trecerea pe calea logicii formale în cadrul cărei se formulează noţiuni fundamentale de domeniu, atribut şi relaţie, care reflectă logica şi sensul datelor.

Altfel:În elaborarea modelului relaţional pentru redarea conţinutului semantic al

datelor Codd a mărs pe calea logicii formale. El a introdus noţiuni fundamentale abstracte de domeniu, atribut şi relaţie, care reflectă adecvat logica şi sensul datelor din lumea reală.

Поскольку рассматриваемый подход к разработке реляционной модели базируется на формальной логике, то в его основе должны лежать некоторые фундаментальные

формализации. В теории реляционных баз данных к ним относятся понятия атрибута, отношения, ключа и функциональной зависимости.

Атрибутом будем называть поименованное свойство объекта и обозначать , где .

Домен атрибута обозначим . Тогда отношением называется конечное

множество атрибутов . Ключ отношения является подмножеством

.

Noţiunea de domeniu. Este o extensie importantă a tipurilor standarde de date în care se accentuiază conţinutul semantic (sensul) al datelor.

Definiţie. Domeniul reprezintă un ansamblu (o mulţime) de valori şi: Are nume unic; Este definit pe un tip de date simplu (scalar, standard) sau pe alt domeniu; Există o condiţie logică care determină mulţimea valorilor admisibile; Este un suport semnificativ a datelor.

Exemple. Domenii cu semnificaţia: vârstei lucrătorului V = {nN: n>18 and n<60}; salariu S = {sR: s>2000.00 and s<8000.00}; greutatea piesei G = {nN: n>18 and n<60}; numărul de oameni într-o echipă C = {nN: n>18 and n<60};

Domeniile asigură restricţiile de comparaţie şi ne uşurează (facilitează) modelarea datelor din lumea reală. Exemplu. Putem oare compara greutatea piesei cu vîrsta omului? Formal – da, dar logic?

34

Produsul cartezian al domeniilor D1D2...Dn prezintă un ansamblu de tupluri (v1, v2, ..., vn).

De remarcat necesitatea definirii unei submulţimi de tupluri, din cadrul produsului cartezian al domeniilor, submulţime care să cuprindă numai tuplurile cu semnificaţie.

Noţiunea de atribut. Orice obiect sau proces din lumea reală (entitate, în general) poate fi descris (definit) prin enumerarea proprietăţilor lui definitoare. Acestea proprietăţi, proprii entităţii date sunt atributele ei care o definesc în mod unic. Terminul de atribut înseamnă o particularitate a oricarei entităţi din lumea reală. Proprietatea de semnificaţie a domeniului ne permite să formalizăm întroducerea noţiunii de atribut al unui obiect, de exemplu <vârsta> care este o proprietate sau o particularitate a lucrătorului (obiectului).

Prin seturi de atribute în mod formal se descriu obiecte din lumea reală.Atributul este definit pe domeniu în felul următor:

Atributul este o pereche de tip<Nume_atribut: Nume_domeniu> sau <A:D>

De amintit aici că domeniu este definit pe un tip de date simplu (primitiv).

Atributele capturează informaţia care descrie şi identifică o instanţă specifică a unei claseşi au un tip asociat care poate fi unul din tipurile primitive

Noţiunea de relaţie. Acum sântem gata să dăm definiţia relaţiei:

Relaţia este o unitate de structură logică (reprezintă o submulţime al produsului cartezian a mai multor domenii) definită pe un set de atribute şi valorile lor şi constă din două părţi:Titlul (schema) relaţiei care constă dintr-un număr fixat de atribute{<A1:D1>, <A2:D2>, <A3:D3>, … , <An:Dn>};Corpul (extensia) relaţiei care reprezintă o submulţime de tupluri (corteje) de tip{<A1:Val1>, <A2:Val2>, <A3:Val3>, … , <An:Valn>}astfel că valoarea Val1 a atributului A1 aparţine domeniului D1 ( ) şi aşa mai departe.

În cadrul modelului relaţional nu interesează decât relaţiile finite, ciar dacă la construirea relaţiilor se admit domenii infinite. Numărul tuplurilor dintr-o relaţie reprezintă cardinalul relaţiei, în timp ce numărul de atribute defineşte gradul relaţiei.

În timp ce tuplurile dintr-o relaţie trebuie să fie unice, un domeniu poate apare de mai multe ori în produsul cartezian pe baza căruia este definită relaţia.

35

Titlul relaţiei este static, în timp ce corpul este dinamic. Orice modificare a titlului duce la trecerea la o altă relaţie (se modifică schema relaţiei), în tim ce modificări în colecţia tuplurilor maximum duce la modificarea cardinalului relaţiei.

Numele şi structura (schema) relaţiei se asemenează cu definiţia unei variabile specifice – variabila-relaţie. Corpul relaţiei (tabelului relaţional) în acest context este o valoare a variabilei-relaţie.

Exemplu:

R1 = Salariatii(Numar_tabel, Nume_salariat, Numar_sector, Salariu),R2 = Sportivi(Id, Name, Age, Weight, Speciality).

R1(Numar_tabel:char(5),…, Salariu:S)

Aşadar corpul sau extensia relaţiei este o colecţie de tupluri (corteje) care prezintă o submulţime a produsului cartezian al domeniilor. Anume corpul este relaţie în sensul ei matematic (să ne amintim aici definiţia relaţiei de pe poziţia teoriei mulţimilor).

Din definiţia relaţiei vedem că fiecare atribut a relaţiei conţine date de acelaşi tip, mai mult ca atât – fiecare tuplu (cortej) are aceia-şi structură. Asta ne dă posibilitatea de a prezenta relaţia într-o formă tabelară:

Tabel 1.1. Forma tabelară a relaţiei

Antetul relaţiei

Corpul relaţiei

Proprietăţile relaţiilor. Aşadar, relaţiile sunt mulţimi de înregistrări, care pot fi reprezentate în formă de tabele bidimensionale (Tab. 1.1). Din acest punct de vedere în reprezentare practică trebuie să se ţină cont de diferenţa dintre relaţii şi astfel de tabele:

Tuplurile în relaţie sunt distincte, în timp ce în tabele pot exista linii identice;

Tuplurile în relaţie nu sunt ordonate (sortate) de sus în jos, în timp ce în tebele liniile sunt plasate într-o ordine dată;

Atributele în relaţie nu sunt ordonate (sortate de la dreapta la stânga), în timp ce în tebele coloanele sunt plasate într-o ordine dată;

<A1:D1> <A2:D2> <A3:D3> … <An:Dn… … … … …… … … … …

<A1:Val1> <A2:Val2> <A3:Val3> … <An:Valn>… … … … …… … … … …

36

Valoarele atributelor sunt atomice, în timp ce în tabele la intersecţia linilor şi coloanelor pot exista structuri de date (mulţimi, tabele, etc.).

Aşadar nu orice tabel reprezintă o relaţie. O relaţie poate fi considerată ca clasa de echivalenţă a tabelelor relaţionale. Aceasta înseamnă că perechea relaţie – tabel relaţionl este o pereche de tip variabilă – valoare (obiect – exemlar de obiect?). Relaţia este un tip structurat de date variabilă-relaţie, iar tabelul relaţional este o valoare concretă a acestui tip. Se poate conclude că punctul central în teoria lui Codd este întroducerea unui nou tip de date – relaţie.

Forma normală unu FN1

Conform modelului relaţional de date a lui Codd unica structură de date este formată din relaţii normalizate de gradul n. Există mai multe nivele de aşa numită normalizare şi respectiv forme normale a relaţiilor reieşind din forma relaţiei şi interdependenţele dintre atributele ei. Cea mai inferioară formă normală este forma normală unu – FN1. Definiţia formei nomale unu – FN1 coincide de fapt cu proprietăţile principale a relaţiei:

Relaţia se află în forma normală FN1 dacă şi numai dacă: nu are corteje identice; conţine valori atomare (indivizibile). (valorile atributelor!)

Aceasta proprietate reiesă de fapt din definirea relaţiei ca o mulţime de corteje, anume – ca o submulţime a produsului cartezian a domeniilor. Cu alte cuvinte orice relaţie se află cel puţin în forma normală unu FN1. Relaţii care nu sa-r afla în FN1 nu există.

Другие определения:Переменная отношения находится в первой нормальной форме тогда и

только тогда, когда в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого атрибута.

Отношение находится в FN1 по определению, т.е. всегда. Для таблицы как представления отношения это в общем случае неверно.

Exemplu de tabel care nu prezintă o relaţie:

Nume Sex AdresaOras Strada Bloc

… … … … …

Se mai poate spune că relaţia se află în FN1 dacă poate fi prezentată în forma unui tabel relaţional.?

Despre noţiune de tipuri atomare (de analizat articolul lui Marin Fotache şi de precizat lucrurile odată şi pentru totdeauna):

37

De nu uitat că o relaţie este o mulţime de corteje (acest lucru trebuie accentuat acolo unde se abordează teoria mulţimilor – în genere, de comparat riguros concluziile teoriei mulţimilor cu concluzile teoriei lui Codd) iar un cortej este o concatenare a elementelor de mulţime şi, dat fiind faptul că elementele mulţimei sunt indivizibile după definiţie, valorile atributului trebuie să fie indivizibile. Această proprietate este moştenită de algebra relaţională (în ce legătură este algebra relaţională cu teoria mulţimelor?);

De întemeiat linia de noţiuni relaţie – tabel relaţionl ca perechea obiect – exemlar de obiect. De tratat relaţia ca tip structurat de date, iar tabelul relaţional ca valoare concretă a acestui tip de date sau poate mai bine – relaţia este o clasă de schivalenţă a tabelelor relaţionale. Anume în legătură cu tabele ralaţionale se poate duce discuţii despre FN1;

În teoria lui Codd nu se porneşte de la teoria matematică a mulţimelor ci de la structuri formale de date (relaţii n-are) cu accentuarea semanticei datelor. Deaceea şi apar uneori discuţii îndelungate despre date atomare în FN1. Şi atunci trebuie de precizat că relaţia reprezintă un obiect din lumea reală (sau o clasă de obiecte, având în vedere o colecţie de exemplare a obiectului dat), iar atributele relaţiei sunt o colecţie de caracteristici care unic (la nivel primit de detalizare) evidenţiază acest obiect dintre altele. Din punct de vedere a semanticii atributului, valorile lui trebuie să fie complete şi indivizibile. Atributul „Adresa” nu poate să aibă numai indicaţia strădei (omul nu trăeşte în stradă). Aceasta înseamnă că se poate vorbi de integritate şi completitudine a valoarelor atributului.

La încheierea paragrafului vom formula definiţia bazei de date relaţională.

Baza de date relaţională să numeşte o colecţie de relaţii logic interlegate între ele.

Schema bazei de date relaţională să numeşte colecţia de titluri (scheme) a relaţiilor în legătură care constitue baza de date.

2.3. Obiectele de structură a modelului relaţional. Tabele relaţionale

Unicul element de structură în modelul relaţional de date este relaţie (relation din engl.), mai precis – o relaţie n-ară normalizată. Fiecare relaţie poate fi prezentată în formă de un tabel specific – anume tabel format numai din linii şi coloane simple, care se mai numeşte şi tabel plan sau bidimensional. Prin asta se înţelege că la intersecţia coloanelor şi liniilor nu mai există alte structuri (subtabele, mulţimi, etc.) ci nemijlocit se găsesc datele. Respectiv, baza de date relaţională este formată din colecţii de tabele de acest tip.

Pentru a deosebi tabelele modelului relaţional de orice altă formă de tabele le vom numi tabele relaţionale. Fiecare linie din tabel relaţional este o înregistrare de aceeaşi structură. Prima înregistrare este antetul tabelului. Ea descrie structura tabelului şi se numeşte şi înregistrare de structură. Restul înregistrărilor conţin datele propriu zise, reprezentate în conformitate cu înregistrarea de structură. Ele sunt înregistrări de date. Totalitatea înregistrărilor de date constituie corpul tabelului. Fiecare înregistrare de date conţine informaţii despre un exemplar de entitate din lumea reală (exemplar de obiect sau proces). Din acest punct de vedere ea este unică în tabelul relaţional. Antetul tabelului este static, deoarece se

38

modifică rar. Dimpotrivă, corpul tabeluli este dinamic. În procesul de actualizare al datelor el se modifică des.

Structura tabelului relaţionalÎnregistrare de structură Câmp 1 Câmp 2 … Câmp MÎnregistrare de date 1 Data Data … DataÎnregistrare de date 2 Data Data … Data

… … … … …Înregistrare de date N Data Data … Data

Antetul tabelului ca o înregistrare de structură este determinat de schema relaţiei (?)dacă privim tabelul ca o reprezentare a relaţiei. De exemplu Furnizor(FurnId, FurnNume, …). Datele sunt înregistrate în baza de date în strictă coreaspondenţă cu structura definită în înregistrarea de structură. Datele nu se descriu, sensul lor este predescris de structura tabelului («cum va fi forma vasului aşa va fi şi forma apei în el »). La crearea unui tabel trebuie definită mai întâi structura tabelului (antetul tabelului reieşind din schema relaţiei), adica trebuie precizate câmpurile care îl compun împreună cu caracteristicile lor. Prin descrierea fiecărui câmp al tabelului este definit tipul de date care vor fi memorate în el. Descrierea se face prin tipul datelor, dimensiunea lor şi alte proprietăţi.

Tabelul relaţional permite gruparea unor date înrudite şi poate fi privit ca o colecţie de înregistrări. Prin descrierea fiecărui câmp al tabelului este definit tipul de date care vor fi memorate în el. Descrierea se face prin tipul datelor, dimensiunea lor şi alte proprietăţi. Ele definesc implicit domeniul de definiţie al datelor memorate în câmp. Dacă domeniul datelor este inclus în domeniul implicit de definiţie, se pot defini condiţii de validare a datelor care să controleze corectitudinea datelor introduse sau modificate. De exemplu, datele dintr-un câmp sunt numere întregi cuprinse între 1.000 şi 30.000. Se va alege tipul întreg, ca domeniu implicit al datelor, dar se vor preciza condiţii de validare suplimentare care să oblige utilizatorul să introducă în acest câmp numai date întregi pozitive din domeniul 1.000 - 30.000.

Cum s-a spus, un tabel relaţional reprezintă o relaţie. Noţiunea strictă de relaţie va fi dată mai târziu în acest curs când se va aborda teoria modelului relaţional. Aici numai vom preciza-o prin noţiune de tabele echivalente. Mulţimea tabelelor relaţionale obţinută dintr-un tabel dat prin aplicarea totalităţii operaţiilor de permutări ale liniilor şi coloanelor (?) formează o mulţime de tabele echivalente. Oricare din acestea tabele reprezintă una şi aceeaşi relaţie.

Din acest punct de vedere relaţia poate fi tratată ca un specific tip de date (?), iar fiecare tabel care o reprezintă – ca o valoare a acestui tip de date. Se mai vorbeşte despre o variabilă-relaţie.

De adus aici diferenţa dintre tabele obişnuite şi tabele relaţionale.

Acum putem stabili următoarea analogie terminologică între domeniul concret din lumea reală, un fişier de date, modelul relaţional de date şi o bază relaţională de date:

39

Domeniul din lumea reală Modelul relaţional de date

Baza relaţionalăde date

entitate (obiect, proces) relaţie tabel relaţional (table)

set complet de caracteristici (atribute) a entităţii

schema relaţiei antetul (schema) tabelului relaţional

o caracteristică (atribut) a entităţii

atribut câmp (field)

valorile unui exemplar de entitate

tuplu, cortej înregistrare (record), articol

Deoarece interfeţele puse la dispoziţie de sistemele de gestiune a bazelor de date relaţionale folosesc în general termenii de tabel (table), câmp (field) şi înregistrare (record), vom folosi în continuare aceşti termeni pentru a defini obiectele corespunzătoare ale bazei de date.

Tipuri de tabele în baza de date

Cum s-a spus mai sus în modelul relaţional datele sunt percepute (privite) de utilizatori numai ca tabele şi nici cum altfel. Tot conţinutul informaţional în bază de date este reprezentat printr-un singur mod – prin prezentarea directă a valorilor datelor în tabele relaţionale. Totodată tabelul relaţional descrie şi structura datelor prin descrierea antetului său. În alte locuri structura datelor nu se descrie.

Aşadar, o trăsătură deosebită a bazelor de date relaţionale constă în aceea că datele în baza de date se stochează împreună cu descrierea structurii lor.

În bază de date sunt cunoscute următoarele tipuri principale de tabele: tabele de bază (fizice), tabele derivate din tabele de bază, reprezentări (View), cataloage.

Tebel de bază – tabel independent de date care are nume şi este fizic memorat în memopria externă. În cazul tabelelor de bază atât structura tabelelor cât şi datele din acestea sunt memorate pe disc. Ca de obicei conţine date independente, primare.

Tabel derivat este dependent de tabele de bază. Spre deosebire de tabel de bază, tabelul derivat nu se memorează pe disc. El se defineşte în termenii altor tabele, în fine în termenii tabelelor de bază. Este un tabel intermediar care apare în operaţiile cu tabele de bază (în expresii). Conţinutul lor se calculă în momentul evaluării expresiilor.

40

Tabele View – viziuni sau vederi prezintă o clasă de tabele derivate care au denumiri. Se numesc şi tabele virtuale. Ca şi tabelele derivate, viziunile nu se memorează pe disc. Mai bine zis nu se memorizează datele din ele. Ele sunt derivate din tabelele de bază, astfel încât pe disc este memorată doar structura (descrierea) lor. De fapt, o vedere este o interogare memorată pe disc. Ca şi orice tabel de bază ea poate fi executată ori de câte ori fiind referită direct sau din cadrul unei instrucţiuni. La nivel logic reprezintă modul cum “vede” un utilizator, la un moment dat, o bază de date. O viziune este de fapt o comandă SELECT memorată în dicţionarul BD şi apelată apoi de utilizator.

Catalog – o mulţime de tabele de sistem care conţin descriptori al diferitor elemente importante pentru sistem (tabelelor de bază, viziunilor, indecşilor, etc.). În fond, prezintă descrierea datelor despre date – metadate. Catalog sau Dicţionar de date (?)

2.4. Integritatea structurală a modelului relaţional

Integritatea structurală este partea centrală a modelului relaţional. Как известно, для описания структуры некоторой сложной системы мы должны задать:

объекты (элементы) структуры, служащие кирпичиками, из которых она складывается;

связи между элементами структуры.

Структурная целостность (integritatea structurală) реляционной модели обеспечивается наборами правил (условий, ограничений), накладываемых на данные и обеспечивающих тем самым их объединение в целостную структуру. Это сложный механизм ограничений, который обеспечивает соответствие между данными и связями между ними в базе данных и данными и связями между ними в предметной области. Базируется на наборе формальных правил или ограничений, которые в той или иной мере обеспечивают это соответствие в любом состоянии базы данных. Кроме того, эти правила должны отражать структурные особенности выбранной предметной области или бизнес-логики данного приложения.

Integritatea structurală a modelului relaţional este asigurată prin impunerea unui set de restricţii (reguli, condiţii) asupra valorilor datelor. Descriu legeturile între date şi integrarea lor într-o structură integră. Definirea şi respectarea strictă a acestor restricţii asigură integritatea, consistenţa şi coerenţa datelor.

Кроме указанного соответствия, структурная целостность реляционной модели обеспечивает собственно целостность данных (integritate propriu-zisă), их полноту соответствия данным предметной области (corespundere

41

deplină – consistenţă) и согласованность (coerenţă) в любом состоянии базы данных.

Под целостностью данных (integritatea datelor) следует понимать их устойчивость по отношению к любым операциям над ними. Т.е. данные при операциях над ними не должны теряться и не должны возникать неконтролируемым образом новые данные.

Под полнотой смыслового соответствия (consistenţa datelor) данных следует понимать их достаточность для полного и однозначного описания процессов в предметной области (содержательность, plenitudine, plinătate, conţinut semantic deplin, suficient, plenitudinea conţinutului semantic a datelor, plinătatea conţinutului semantic). В идеале должно быть достигнуто взаимно однозначное соответствие между информацией в предметной области и структурой данных, которая ее моделирует.

Под согласованностью (coerenţa?) данных следует понимать, во первых, их непротиворечивую согласованность и связность между собой как целостной системы и, во вторых, согласованность или совместность данных базы с данными предметной области.

Требования полноты смыслового содержания (consistenţa) и согласованности (coerenţa) данных отвечают требованию чтобы структурированный набор данных представлял собой информационную модель предметной области.

Pot fi evidenţiate (delimitate) două categorii de restricţii: restricţii de integritate structurală. Sunt obligatoriu de definit pentru

susţinerea consistenţei datelor şi integrităţii structurale a modelului de date. Este partea indispensabilă a modelului;

restricţii specifice aplicaţiei dată de bază de date. Aşa numite restricţii de comportament. Например, возраст работника должен быть не больше 60, вес детали не может быть отрицательным и т.д.

În modelul relaţional la restricţiile de integritate structurală se referă: unicitatea cheii relaţiei; integritatea entităţii; integritatea referenţială a datelor.

2.2.1. Identificare unică a înregistrărilor. Unicitatea cheii relaţiei

Выше мы установили, что каждый кортеж отношения и, соответственно, каждая запись в реляционной таблице содержит информацию о конкретном экземпляре сущности из предметной области. Поскольку каждый экземпляр сущности из предметной области уникален, уникальной должна быть и

42

каждая запись в реляционной таблице. Под сущностью мы условились ранее понимать объект или процесс. Следовательно уникальными должны быть как экземпляры объектов, так и экземпляры процессов.

Concluzie: в любом отношении не может быть двух одинаковых кортежей и, соответственно, в любой реляционной таблице не может быть двух одинаковых записей. Întrucât tuplurile unei relaţii sunt unice, ele sunt distincte şi trebuie să existe posibilitatea identificării unice a lor în cadrul unei relaţii. Cum am putea distinge (evidenţia) cortejele? Este evident că există unica posibilitate – prin valorile atributelor. În mod natural există unica posibilitate de a găsi înregistrările din tabele – prin valorile concrete a unor atribute. În realitate însă nu neapărat toate atributele sunt necesare pentru identificarea unică a tuplurilor. Ca de obicei există un număr redus de atribute totalitatea valorilor cărora este unică în relaţie.

Пример:База данных СТУДЕНТЫ

StName StPhone StAddress Имеет два возможных ключа {StName, StPhone} и {StName, StAddress}. Если добавить поле StId

StId StName StPhone StAddress

то ключей будет три: StId, {StName, StPhone} и { StName, StAddress}.

Aşadar, putem conclude că există un set minim de atribute totalitatea valorilor cărora unic identífică înregistrările tabelului relaţional.

Acest ansamblu minim de artribute, numite şi atribute cheie formează cheia relaţiei:

Cheia unei relaţii de bază R reprezintă un set minim de atribute, totalitatea valorilor cărora unic identífică cortejele din R.

Asta înseamnă că cortejii sunt distincţi unul de altul şi poate fi definit un mecanism (o modalitate) de identificare unică a lor. Drept o modalitate de distincţie servesc valorile cheii ??? Mecanismul de identificare unică este în acelaşi timp şi mecanism de referire (adresare) unică.

Это означает, что кортежи (записи) отличимы друг от друга и должен существовать механизм (способ) однозначной идентификации кортежей в отношении или записей в реляционной таблице. Единственная возможность находить записи в таблице состоит в их поиске по заданным значениям отдельных полей. Однако, данные в отдельных полях

43

могут повторяться, что не позволяет однозначно идентифицировать записи. Данные по совокупности значений могут повторяться и для двух и более полей. Выход состоит в использовании такого минимального набора полей, совокупность значений для которых является уникальной. При этом минимальность набора требуется исключительно для удобства. Таким образом, мы приходим к понятию ключа отношения (реляционной таблицы) как единственно возможного средства однозначной идентификации кортежей (записей) в реляционной модели.

Ключ отношения (таблицы) представляет собой минимальный неизбыточный набор атрибутов (полей), совокупность значений которых уникальна для данного отношения (таблицы) в любом состоянии базы данных (т.е. в любое время).Cheia relaţiei este un set minim neexcedent de atribute, totalitatea valorilor cărora este unică pentru relaţia dată în orice stare a bazei de date.

Пример:База данных СТУДЕНТЫ

StName StPhone StAddress Имеет два возможных ключа {StName, StPhone} и {StName, StAddress}. Если добавить поле StId

StId StName StPhone StAddress

то ключей будет три: StId, {StName, StPhone} и { StName, StAddress}.

Aşadar, cheia relaţiei (cheia de identificare) este formată dintr-un număr minim de câmpuri definite astfel încât totalitatea valorilor lor este unică pentru fiecare înregistrare din tabelul dat. Anume asta ne va permite identificarea unică a înregistrărilor din tabel. Aşadar, fiecare înregistrare va putea fi identificată în mod unic prin valorile cheii astfel definită.

Proprietatea principală a cheii relaţiei constă în unicitatea valorilor ei. De aici reiesă regula de unicitate a cheii relaţiei:Valorile cheii relaţiei (tabelului relaţional) sunt unice. Altfel, asta este restricţia de unicitate a cheii

Instrument unic pentru identificare şi referire unică a cortejelor

Таким образом, свойство (или ограничение) уникальности ключа может быть использовано для выполнения однозначной идентификации кортежа (записи). Более того, это свойство ключа дает единственный в реляционной модели способ однозначной идентификации кортежей.

Ключ отношения (таблицы) может использоваться как для собственно поиска записей в ней, так и для связывания этих записей с записями другой

44

таблицы. Таким образом, в реляционной модели имеет место связывание данных по их значению, а не по адресу в памяти, как в иерархической и сетевой моделях (?).

Строгое определение ключа отношения (definiţie strictă a cheii relaţiei)

Se numeşte cheia relaţiei submulţimea K de atribute a relaţiei de bază R, care posedă următoarele proprietăţi:1. proprietatea de unicitate – в отношении R не существует двух кортежей

с одним и тем же значением ключа K;2. proprietatea de neexcedenţă (de a nu fi redundantă) – ни одно из

подмножеств ключа K не обладает свойством уникальности.

В данном отношении может существовать несколько ключей, каждый из которых однозначно идентифицирует кортежи (записи). Поскольку кортежи отношения (записи таблицы) уникальны, то в отношении обязательно должен существовать хотя бы один ключ. В крайнем случае в роли такого ключа могут выступать все атрибуты отношения (все поля таблицы).

Cheia relaţiei poate fi simplă, dacă constă dintr-un singur atribut, sau compusă, dacă constă din mai multe atribute.

Как правило, только один из ключей отношения выбирается в качестве инструмента однозначной идентификации кортежей (în calitate de instrument de identificare unică a cortejelor). Такой ключ называется первичным (cheie primară). Restul cheilor se numesc chei secindare sau alternative. Выбор одного из ключей в качестве первичного осуществляется разработчиком приложения исключительно исходя из семантики (смысла) данных. Reieşind exclusiv din semnificaţia datelor.

Ca de obicei în orice SGBD ea se nimeşte cheia primară (Primary Key) şi este aleasă din mulţimea cheilor de identificare a relaţiei pe baza anumitor criterii (reieşind din semnificaţia datelor!). Ea şi este folosită pentru a face legătura între înregistrările tabelului dat cu înregistrările altor tabele ale bazei de date. Cheia primară va fi folosită de sistemul de gestiune a bazelor de date pentru a identifica unic înregistrările în procesul de regăsire a datelor.

Se recomandă ca din mulţimea cheilor de identificare să se aleagă, pentru cheia primară, cheia care este formată din cele mai puţine câmpuri. În practică pentru simplicitate în calitate de cheie primară se folosesc artificial introduse câmpuri cu valori garantat unice – coduri de identitate. Acestea cîmpuri formează aşa numită cheia surogat (?).

2.2.2. Данные типа NULL. Правило целостности сущности

45

Данные типа NULL. В базах данных есть специальное данное типа NULL. Это не данное в обычном смысле этого слова, а специальный маркер, который применяется для указания того факта, что значение данного неизвестно. Не путать со значениями типа пустая строка (“”) или нуль (0). Это обычные значения.

De adăugat despre logica triplă: tabele binare → tabele ternare (triple) de adevăr - tabele triple (ternare?) de adevăr (valori true, false, unknown).

Поскольку ключ отношения (таблицы) должен по своему назначению однозначно идентифицировать конкретный экземпляр сущности из предметной области, то он должен быть заданным (известным) для своего экземпляра в любом состоянии базы данных.

Cu alte cuvinte – valorile cheei relaţiei nu pot fi necunoscute, adica nu pot fi nedefinite sau să fie valoari de tip NULL în orice stare a bazei de date.

De aici recurge regula de integritate a entităţii:Valorea cheii relaţiei pentru orice cortej din relaţie nu poate fi necunoscută, adica nu poate fi nedefinită sau să fie valoare de tip NULL în orice stare a bazei de date.

2.3. Legăturile dintre tabelele relaţionale. Integritatea referenţială

Как мы установили, в предметной области есть сущности (объекты и процессы). Они связаны между собой в бизнесс-процессах.

Примеры из предметной области – furnizorii livrează marfă, copiii sunt copiii colaboratorilor, conducătorii conduc sectoarele.Примеры связей в этих предметных областях: furnizori – marfă. Legătura de tip mult la mult ∞:∞; colaboratori – copiii lor. Legătura de tip unu la mult 1:∞; conducători – sectoare. Legătura de tip unu la unu 1:1.

(проиллюстрировать в виде таблиц). Acestea legături nu sunt legături de egalitate, ci legături de subordonare. …

46

FurnizoriFurnizorNumeAdresa…Alfa……Orient……

MarfaMarfaNumeTip…Calculator……Televizor……

Furnizor – Marfa …DataFurnizorNumeMarfaNumeCantitatePret…

AlfaCalculatorOrientTelevizor

Как видим из этих примеров, связи (relations) между сущностями задаются описательным перечислением множества всех связей между экземплярами сущностей. Эти связи описывают: действия (операции) в бизнес-процессах (Иванов поставляет

телевизоры); текущие состояния (stări curente) между объектами (Сергей является

сыном Петрова).

В реляционной базе данных сущности предметной области и связи между ними задаются одним и тем же способом – описательным заданием данных в реляционных таблицах.

Каким образом и сколькими таблицами – вопрос, решаемый при моделировании. Он определяет качество проектирования. Для нас здесь важно, что таблицы должны быть связаны между собой таким образом, чтобы однозначно и полно отражать существующие между сущностями в предметной области связи.

Прежде чем установить правила связывания таблиц в единую базу данных, отметим что: Связи между сущностями задаются путем указания всего множества связей между

экземплярами сущностей; Каждый экземпляр сущности уникален; Каждая связь на уровне экземпляров сущностей уникальна, поскольку задает конкретнoe

бизнесс-действие (операцию) или состояние.

Pentru a stabili legătură (asocierea) între două relaţii (tabele relaţionale) trebuie: Se avem în vedere că în legătură participă două tabele. Legătura dintre ele nu

este una de egalitate, ci este o legătură de subordonare. Unul dintre două tabele în legătură este tabelul principal (sau tatăl), iar altul este subordonat (condus - copil). Deci, legătura trebue să fie de tip 1:∞.

Să avem o modalitate de a stabili legături unice dintre cortejele din două relaţii (tabele). Cea mai simplă (şi unica?) modalitate posibilă este de a ne referi din cortejele unui tabel la cortejele altui tabel. Aşadar, legătura dintre două tabele apare când valorile unor atribute dintr-un tabel să referă la valorile unor atribute din alt tabel. Acest lucru este posibil dacă vom crea o structură de referinţe. Pentru asta se întroduce noţiunea de migrare sau propagare a cheii relaţiei. Установить механизм задания однозначных связей между записями двух реляционных таблиц (или кортежами двух

47

отношений). Для этого вводится понятие миграции ключей отношений из одной таблицы в другую (mecanismul de migrare a cheilor);

Să creem o structură de referinţe. Unica posibilitate de a crea referinţe – constă în folosirea valorilor unice. Avem unicul instrument pentru distingere şi identificare unică a cortejelor. Unica distincţie dintre două corteje este distincţia dintre valorile unor atribute din aceste corteje. Această distincţie poate fi folosită în scopul identificării unice a cortejelor. Setul de atribute cu valori distincte în totalitate formează cheia relaţiei, care şi este folosită pentru identificare şi referire unică a cortejelor. Установить механизм различения и однозначной идентификации записей (кортежей) в реляционных таблицах. Для этого вводится понятие ключа идентификации или ключа отношения (реляционной таблицы);

Să definim un set de restricţii asupra datelor cu scopul asigurării integrităţii legăturilor în orice stare a bazei de date.

===========================================================Legăturile dintre entităţile lumii reale pot fi exprimate prin multitudenea propoziţiilor de tip: Furnizorul concret (I. Albu) livrează marfa dată, sau marfa dată (televizorul) este livrată de

furnizorul dat (I. Albu); Fiecare părinte concret (Popa Ion) este părintele copiilor (Mariei şi Andrei), sau copiii

Maria şi Andrei sunt copiii colaboratorului firmei Popa Ion; Etc.

Putem deci spune că legătura dintre entităţile Furnizori şi Livrări înseamnă existenţa unui set de afirmaţii de tip livrează sau este livrat. Acestea legături determină activităţi (operaţii) concrete de bussiness. Deasemenea, legătura dintre entităţile Colaboratori şi Copii înseamnă existenţa setului de afirmaţii de tip este părinte/sunt copii. Acestea legături determină starea actuală dintre exemplarele entităţilor.

Aşadar, legăturile existente între entităţi se determină prin descrierea multitudinii legăturilor de tip activitate sau stare dintre exemplarele entităţilor. Adica, în forma descriptivă. ===========================================================Din aceste exemple se vede că există legături elementare – legături dintre două entităţi. Fiecare astfel de legătură se reduce la un set de legături dintre exemplarele corespunzătoare al acestor entităţi. Important să observăm aici că: Din două entităţi unite în legătură una este activă (este părinte, livrează), iar alta este

pasivă (sunt copii, este livrată); Fiecare exemplar al entităţii active este unic; Fiecare exemplar al entităţii active poate fi legat cu mai multe exemplare al entităţii pasive; Fiecare legătură concretă dintre exemplarele entităţilor este unică. Ea descrie o operaţie

unică sau o stare unică. (? De verificat)===========================================================

Stabilirea legăturilor (relaţiilor) dintre tabele. Mecanismul de propagare a cheilor. Mecanismul de referire

Pentru a stabili o legătură între două tabele rerlaţionale se folosesc câmpuri cu valori egale (identice). De exemplu, în tabelele Furnizori şi Livrari vor fi câmpuri comune cu valori egale ale numelor sau codurilor furnizorilor. Aceasta legătură va

48

prezenta informaţie de tip cine a livrat marfa dată. În tabelele Colaboratori şi Copii, respectiv, vor fi câmpuri cu valori egale a numelor sau codurilor colaboratorilor care vor reda legătura părinte – copil. Aşadar, în cazul tabelelor legătura dintre două tabele înseamnă un set de legături dintre înregistrările unui tabel cu înregistrările altui tabel.

ColaboratoriCod colaborator

Nume colaborator

...

... ... ...C012 I. POPA ...... ... ...

CopiiCod copil Nume

copilParinte ...

... ... ... ...GR63 MARIA C012 ...... ... ... ...

49

Legătura dintre tabelele Colaboratori şi Copii reprezintă faptul că în tabelul Copii sunt prezentaţi acei şi numai acei copii care au ca părinţi persoanele din tabelul Colaboratori. Deci, legătura are un caracter de restricţie asupra unor valori şi este un element de structură a informaţiei despre copiii colaboratorilor.

Unicitatea legăturilor – dat fiind faptul că exemplarele entităţilor din lumea reală sunt unice, sunt unice şi legăturile între aceste exemplare.?? incorect

2. Stabilirea relaţiilor între tabele. Relaţiile care se vor stabili între fiecare pereche de tabele sunt unidirecţionale, adică între două tabele nu se stabileşte o relaţie de egalitate ci o relaţie de subordonare: unul dintre tabele este tabelul conducător, principal sau tabelul părinte (tabelul de la care porneşte legеtura), iar celălalt este tabelul condus, secundar sau tabelul copil (tabelul la care ajunge legеtura). Tabelul condus este subordonat tabelului conducător. Aceasta înseamnă că dacă utilizatorul selecteazе o înregistrare în tabelul conducător, sistemul va selecta automat înregistrarea de care este legată din tabelul condus.

Pentru a stabili legături unice dintre înregistrările a perechei de tabele care întră în legătură trebuie, cum s-a spus, să putem: Identifica unic înregistrările; Stabili corespunderea unică dintre înregistrări.

Stabilirea corespunderei unice dintre înregistrările care întră în legătură

Stabilirea corespunderei dintre înregistrări şi prin acesta a legеturii dintre tabelele bazei de date se realizează prin mecanismul de propagare a cheilor. Prin acest mecanism în tabelul condus din legătură se crează aşa numită cheia externă (Foreign Key). Cheia externă este formată din câmpurile, care formează cheia primară în tabelul conducător. Denumirile câmpurilor din cheia externă pot să difere de denumirele respective din cheia primară, dar valorile lor sunt identice în ambele tabele. Mecanismul de propagare a cheilor se realizează în modul următor. În tabelul sursă, tabelul de la care începe propagarea cheii (tabelul conducător), se crează cheia primară, iar în tabelul destinaţie, tabelul până la care se propagă cheia (tabel condus), se crează cheia externă. Se spune că a avut loc propagarea cheii din tabelul sursă în tabelul destinaţie. Acest mecanism permite stabilirea legăturii între o înregistrare din tabelul sursă şi o înregistrare din tabelul destinaţie. Se mai spune că valorile cheii externe să referă la valorile cheii primare.

Указанные выше свойства ключа отношения обеспечивают однозначную идентификацию кортежей отношения и используются для ссылок на эти кортежи из кортежей другого, связанного с ним отношения. Это достигается использованием механизма миграции ключа отношения в другое, дочернее отношение и его трансформацию во внешний ключ. При этом значения внешнего ключа ссылаются на значения ключа родительского отношения.

Строгое определение внешнего ключа

Пусть дано базовое отношение R1. Подмножество (submulţimea) атрибутов FK отношения R1 назовем внешним ключом (cheie externă), если:1. существует базовое отношение R2 (не обязательно другое) с ключом

отношения K;2. каждое значение FK отношения R1 совпадает со значением ключа K

для некоторого кортежа отношения R2 или принимает значение типа NULL.

Отношение R1 является дочерним (подчиненным) ссылающимся отношением, которое ссылается на родительское отношение R2, а отношение R2 является ссылаемым отношением, на которое ссылается дочернее отношение R1.

Пример, когда отношение ссылается само на себя – отношение Сотрудники, в котором есть атрибут Непосредственный начальник, значения которого ссылаются на значения первичного ключа в этом же отношении. При этом значение, относящееся к руководителю организации, ни на кого не ссылается (имеет значение NULL).

Proprietăţile cheii externe: cheia externă poate fi simplă sau compusă; cheia externă trebuie să fie determinată pe aceleaşi domenii ca şi cheia

primară K; cheia externă ca regulă nu posedă proprietatea de unicitate; dacă cheia externă totu-şi posedă proprietatea de unicitate, atunci asocierea

între relaţii este de tip unu – unu;Corpul didactic

ProfId ProfNume ProfFunctie ConducatorDirect… … … …MI21 Condrea Mihai profesor MI35… … … …MI35 Cepoi Grigore şef catedră MI70… … … …MI70 Apostol Eugen rector NULL… … … …

Aşadar, pentru a stabili legătura dintre două tabele trebuie să: Stabilim cheia primară în tabelul conducător (părinte); Definim prin mecanismul de propagare cheia externă în tabelul condus

(copil);

51

EmpIdEmpNameEmpPositionEmpChief...

Employees

Să impunem restricţii asupra valorilor admisibile atât pentru cheia primară, cât şi pentru cheia externă.

Legatura (asocierea) dintre două tabele se stabileşte prin valori care să referă şi valori referite. Valorile referite se găsesc în tabelul principal şi trebuie să fie unice – sau de tip Primary Key sau de tip UNIQUE. Valorile care să referă se găsesc în tabelul condus (dependent) în cimpurile cheii externe.

După definirea structurii bazei de date începe încărcarea datelor în tabel. La nivelul tabelului entitatea prelucrată este înregistrarea: se pot adăuga înregistrări, se pot şterge înregistrări, se pot modifica înregistrări. Se poate modifica structura unui tabel chiar după ce a fost încărcat cu date. Sistemul de gestiune a bazelor de date nu operează modificarea de structură direct în tabel, ci execută următoarele operaţii: creează noua structură de tabel (rezultată în urma modificărilor cerute), încarcă în noul tabel datele din vechiul tabel şi şterge vechiul tabel. Toate aceste operaţii sunt executate automat de către sistem, fără intervenţia utilizatorului şi fără a fi vizibile pentru utilizator.Tabelele bazei de date pot fi organizate într-o structură arborescentе (sau de reţea) determinată de relaţia dintre tabele.De obicei, modelul relaţional cel mai des întâlnit este cel descris printr-un arbore cu o singurе rădăcină, adică în baza de date existе un singur tabel conducător care reprezintă rеdеcina arborelui. Celelalte tabele sunt legate de tabelul conducător direct sau indirect (prin intermediul altor tabele). ??? este o reţea de tabele!!!

Schema generală a unei baze de date relaţionale este formată din ansamblul schemelor tabelelor şi al legăturilor dintre ele.

Regula (restricţia) integrităţii referenţiale

Legătura odată stabilită între două tabele prin mecanismul de propagare a cheii trebuie să fie permanent menţinută. În orice moment trebuie să fie asigurată determinare unică a legăturii şi corespunderea ei cu datele din lumea reală. Determinarea unică a legăturii este asigurată de mecanismul de propagare a valorilor cheiei primare (este rezultatul unicităţii exemplarului entităţii). Corespunderea ei cu datele din lumea reală se va asigura prin restricţii specifice cheii externe. Condiţia care trebuie respectată pentru a putea fi asigurată menţinerea legăturii în orice stare a bazei de date să numeşte condiţia de integritate referenţială sau restricţia de integritate referenţială.Este specifică relaţiilor dintre tabelele bazei de date. Ea înseamnă o colecţie de reguli şi restricţii impuse tabelelor între care s-au stabilit relaţii (sau, este un sistem integru de referinţe şi se cere menţinerea integrităţii lui în orice stare a bazei de date …). Astfel, a asigura integritatea referenţială înseamnă că atunci când se fac modificări ale valorilor unor înregistrări dintr-un tabel din legătură să nu fie afectată relaţia dintre tabelele legăturii. Această problemă apare în cazul câmpurilor care fac parte dintr-o cheie primară sau externă. Ele trebuie să respecte condiţia de integritate referenţială.

52

Condiţia de integritate referenţială impune ca oricare valoare a cheiei externe să fie inclusă în mulţimea valorilor cheii primare din care s-a propagat, sau să fie de tip NULL. Poate altfel? Prin noţiune de referinţe?

De adăugat despre legături de tip PK → FK şi UNIQUE → FK.

2.2.4. Operaţii care pot încălca (afecta) integritatea referenţială

Integritatea referenţială poate fi încălcată în urma îndeplinirii operaţiilor care modifică starea bazei de date. Astfel de operaţii sunt trei: înserarea (INSERT), modificarea (UPDATE) şi ştergerea (DELETE) datelor. Acestea operaţii pot modifica valorile cheilor primară şi externă. Dat fiind faptul că în formularea regulei de integritate referenţială fac parte două relaţii – relaţia referită şi relaţia care să referă şi în ambele sunt posibile toate trei operaţii avem să analizăm şase variante.

Pentru relaţia referită (relaţia părinte): Înserarea tuplului. Nu poate provoca (duce la)

încălcare. Modificarea tuplului. Poate provoca încălcare. Ştergerea tuplului. Poate provoca încălcare.

Pentru relaţia care să referă (relaţia copil): Înserarea tuplului. Poate provoca încălcare. Modificarea tuplului. Poate provoca încălcare. Ştergerea tuplului. Nu poate provoca încălcare.

(? a duce la încălcare)

Într-un careva mod înserarea tuplului în relaţia părinte este echivalentă (sau inversă) cu ştergerea din relaţia copil a tuplului care se referă la tuplul înserat. În ambele cazuri apar valori de cheie primară nereferite.

Aşadar în principiu integritatea referenţială poate fi încălcată în rezultatul îndeplinirii acelor operaţii care pot afecta valorile cheilor primară şi externă. Acestea operaţii sunt următoarele patru: Modificarea tuplului în relaţia părinte; Ştergerea tuplului în relaţia părinte; Înserarea tuplului în relaţia copil; Modificarea tuplului în relaţia copil.

Strategiile de menţinere (susţinere) a integrităţii referenţiale

Pentru a evita la nivel practic posibilele încălcări a integrităţii referenţiale e necesar să stabilim careva convenţii despre măsurile care pot fi intreprinse şi care ulterior pot fi realizate sau susţinute de SGBD. Cu alte cuvinte, trebuie să elaborăm şi să

53

utilizăm careva “reguli de comportare” atunci când se modifică datele din înregistrări. Convenţiile se referă la un set de restricţii care trebuie (pot fi) aplicate pentru a menţine integritatea referenţială în mod automat. Cu alte cuvinte, pentru menţinerea integrităţii referenţiale trebuie să aplicăm anumite strategii susţinute de SGBD.

Există două strategii principale care pot fi impuse la modificarea stării bazei de date: RESTRICT (A RESTRICŢIONA) – a nu permite exercitarea operaţiilor care

duc la încălcărea integrităţii referenţiale; CASCADE (A EXERCITA ÎN CASCADĂ) – a permite exercitarea operaţiilor

necesare dar concometent cu asta a întroduce în cascadă (în lanţ) în toate relaţiile subordonate în conexiune corectări corespunzătoare pentru a menţine integritatea referenţială.

Acestea strategii sunt standarde şi sunt susţinute de toate SGBD-urile în care este prezentă susţinerea integrităţii referenţială.Există şi strategii adiţionale: SET NULL (A SETA VALOAREA NULL) – a seta valorea NULL în relaţiile

subordonate. SET DEFAULT (A SETA PRIN IMPLICIT) – a seta o valoare primită prin

implicit în relaţiile subordonate. IGNORE (A IGNORA) - a permite exercitarea operaţiilor necesare, ne ţinând

cont de încălcarea integrităţii referenţiale. De fapt, aceasta convenţie înseamnă că nu se aplică nici o strategie. Este lucru care rămâne la discreţia utilizatorului.

Aplicarea strategiilor

Vom analiza aici cum pot fi aplicate în practică strategiile descrise mai sus. Pentru a ne simplifica această analiză vom considera o conexiune de tip unu – la mai multe

În dependenţă de operaţiile de modificare sunt posibile enumerate mai jos strategii.

În tabelul principal:

54

Modificarea (operaţia UPDATE) unei înregistrări. Poate să afecteze integritatea referenţială numai în cazul în care există chei externe valorile cărora să referă la valorile cheii primare care se modifică. Deci, dacă este referire ea trebuie menţinută în orice stare a bazei de date. În acest caz se pot aplica două strategii: RESTRICT – modificarea restricţionată. Nu să acceptă modificarea unui câmp

dacă el este cheie primară şi există cel puţin o cheie externă propagată din această cheiă care are aceeaşi valoare cu cheia primară pe care dorim s-o modificăm;

CASCADE – modificarea în cascadă. Modificarea cheii primare va avea ca efect modificarea tuturor cheilor externe propagate din aceasta în toate tabelele care au aceeaşi valoare cu cheia primară care să modifică.

Ştergerea (operaţia DELETE) unei înregistrări. Amintim aici că cu operatorul DELETE se şterg înregistrări în întregime, dar nu valori din câmpuri. Operaţia poate afecta integritatea referenţială numai în cazul în care există chei externe care au aceeaşi valoare cu valoarea cheii primare din înregistrarea care se doreşte a fi ştearsă. În acest caz iarăşi se pot aplica două strategii de bază: RESTRICT – ştergerea restricţionată. Nu se acceptă ştergerea înregistrării

dacă există cel puţin o cheie externă, propagatе din cheia primară care are aceeaşi valoare cu cheia primară din înregistrarea pe care dorim s-o ştergem;

CASCADE – ştergerea în cascadă. Ştergerea înregistrării va avea ca efect ştergerea din toate tabelele a înregistrărilor care conţin chei externe propagate din cheia primară şi care au aceeaşi valoare cu cheia primară din înregistrarea ştearsă.

În tabelul condus:Operaţia de adăugare (înserare) a unei înregistrări trebuie să se facă numai dacă valorile din câmpurile cheii externe se vor găsi în mulţimea valorilor cheii primare din care s-au propagat. Sau să fie de tip NULL.Operaţia de modificare a valorii unui câmp dintr-o înregistrare trebuie să aibă învedere faptul că dacă acest câmp este un câmp al cheii externe, valoarea sa modificată trebuie să se găsească în mulţimea valorilor cheii primare din care s-a propagat. Sau să fie de tip NULL.

Aici de dat şi analizat un exemplu mai extins cu schema OralulLectiii → Examinare cu relaţii comune Obiecte, Profesori.

Majoritatea SGBD-urilor relaţionale susţin parţial strategiile descrise mai sus. În MS SQL Server strategiile se indică ca proprietăţi ale câmpurilor la descrierea structurii tabelelor prin următorele fragmente din SQL:ON UPDATE CASCADE, ON DELETE CASCADE, IGNORE, etc.

În MS Access strategiile se indică ca proprietăţi ale legăturilor dintre tabele.….

55

În Enterprise Manager al Microsoft SQL Server 2000 strategiile se introduc prin bifarea câmpurilor respective în căsuţa de dialog Properties of relationships: Check existing data on creation Enforce relationship for replication Enforce relationship for INSERTs and UPDATEs – strategia RESTRICT (se

înterzice inserarea şi modificarea datelor care duc la încălcarea integrităţii referenciale) Cascade Update Related fields – strategia CASCADE (la modificarea cheii

primare automat se modifică în cascadă şi cheia externă în relaţia copil) Cascade Delete Related Records – strategia CASCADE (la ştergerea

înregistrării cu cheia primară automat se şterge în cascadă şi înrgistrarea cu cheia externă în relaţia copil)

2.5. Operatorii modelului relaţional

Cum am văzut mai sus pentru modelulu relaţional se îndeplinesc cel puţin două condiţii:

1. Datele se percep de utilizator ca tabele şi nici cum altfel;2. Utilizatorii au la dispoziţie un set de operatori relaţionali pentru operaţii cu

structura datelor şi cu datele însuşi în tabele.

Aşadar, sistemele relaţionale privesc baza de date ca o colecţie de tabele şi prezintă un set de operatori pentru gestionarea datelor în tabele. В качестве базовых операторов служат операторы реляционной алгебры или попросту теории множеств. На их основе разрабатываются языки программирования для реляционных баз данных. Основным является язык SQL – язык реляционных баз данных.

Детально свойства реляционных операторов мы изучим позднее. В данном же пункте мы рассмотрим специфические свойства базовых реляционных операций (operaţiilor relaţionale de bază), котрыми они должны обладать при их применении к реляционным таблицам. Эти свойства являются следствием того, что реляционные операции применяются к таблицам и в результате их применения генерируются новые результирующие таблицы. Как увидим позже эти свойства вытекают непосредственно из теории множеств.

Operaţiile de bază sunt următoare: SELECT – operaţia de selecţie. Este menită pentru regăsirea din tabel a

mulţimilor de înregistrări care satisfac careva condiţie (selecţia după orizontală);

PROJECT – operaţia de proiecţie. Menită pentru extragerea necondiţionată din tabel a submulţimei dată de coloane (selecţia pe verticală);

56

JOIN – operaţia de uniune (reuniune?). Este menită pentru unirea (joncţiunea) a două tabele. În cel mai des caz pe baza valorilor identice în coloane comune.

Vom caracteriza în continuare cele mai importante proprietăţi ale operaţiilor relaţionale.

1. Proprietatea de închidere (cвойство замкнутости). Aplicarea operaţiilor relaţionale asupra tabelelor generează iarăşi tabele. Это реляционное свойство замкнутости – результатом операции является объект того же рода, что и объект, над которым производилась операция, а именно, таблица. А это значит, что над результатом операции можно вновь проделать какую-либо другую операцию, результатом котрой будет тоже таблица. Asta înseamnă că pot fi folosite expresii complexe înglobate, rezultatele intermediare a cărora nu se vor păstra pe disc. Другими словами, можно использовать вложенные выражения, т.е. выражения, в которых операнды представлены выражениями, а не просто именами таблиц. При этом промежуточный результат не обязательно будет существовать в виде полной “материализованной” таблицы (tabel total materializat), т.е. поименованной и записанной в дисковую память. Cauza este clară – să nu pierdem eficienţa de prelucrare.

2. Proprietate de multiplicitate (cвойство множественности). Operaţiile relaţionale se aplică odată asupra totalităţii întreagă de înregistrări ci nu asupra unor înregistrări în parte. Asta înseamnă că cât operanzii, atât şi rezultatele se consideră drept tabele întregi care conţin mulţimi de înregistrări. Такое свойство множественности является главной отличительной чертой реляционных систем.

3. Proprietatea de navigare automată (cвойство автоматической навигации). Так как реляционные операции выполняются на уровне множеств (la nivel de mulţime), то использующие их языки, такие как SQL, часто называют непроцедурными. În operaţiile relaţionale utilizatorul numai indică ce trebuie de făcut şi nu cum trebuie de făcut. De a da exemple. Для выполнения такого задания система автоматически выполняет процесс навигации по строкам, отбирая те из них, которые удовлетворяют запросу пользователя. Такие системы носят название систем с автоматической навигацией (sisteme cu navigare automată).

4. Proprietatea de optimizare (cвойство оптимизации). Реляционные языки, такие как SQL, являются языками с более высоким уровнем абстрактизации, чем такие процедурные языки, как Паскаль, С и др. Этому как раз и призвано служить свойство автоматической навигации. Navigarea automată trebuie să se indeplinească în mod optimal. De asta răspunde un component foarte importatnt al SGBD – optimizatorul interogărilor. Optimizatorul determină cum se va realiza interogarea într-un mod optimal atunci când utilizatorul indică numai ce trebuie de făcut şi nu cum.

57

Sisteme relaţionale – concluzii la capitol

Различать реляционные и нереляционные системы можно по следующему признаку. Пользователь реляционной системы видит данные, представленные в таблицах и никак иначе. Пользователь нереляционной системы, напротив, видит данные, представленные в других структурах вместо таблиц реляционной системы или наряду с ними. И для работы с этими другими структурами применяются другие операции. Например, в иерархической системе данные представлены пользователю в форме выбора древовидных структур (или иерархий), а среди операций работы с иерархическими структурами есть операции перемещения по иерархическим путям вниз и вверх по деревьям.

Sistemele relaţionale se bazează pe următorii principii: Utilizatorii văd datele numai în formă de tabele; Există un set de restricţii (reguli) impuse asupra valorilor de date pentru a

asigura integritatea de structură a datelor şi consistenţa lor ; Utilizatorii au la dispoziţie operatori pentru a gestiona datele.

Aşadar, pentru sistemele relaţionale este specific: определение “реляционной системы” требует, чтобы база данных

воспринималась пользователем только как таблицы. Таблицы в реляционной системе являются логическими, а не физическими структурами. На самом деле на физическом уровне система может использовать любую или все применяемые структуры памяти – последовательные файлы, индексирование, хэширование, цепочки указателей, сжатие и т.п. – лишь бы обеспечивалась возможность отображать эти структуры в таблицы на логическом уровне. Это можно сказать по-другому: таблицы представляют собой абстракцию способа физического хранения данных, в которой множество деталей на уровне памяти, определяющих способ хранения и доступа к хранимым данным, скрыто от пользователя. Естественно, то, как это делает та или иная конкретная СУБД, определяет ее эффективность;

в реляционных базах данных все информационное содержимое базы данных (и ее структура?) представлено одним и только одним способом, а именно: явным заданием значений данных. Задание явным образом значений столбцов в строках таблицы – единственно возможный для реляционных баз данных метод представления данных; Prezentarea datelor prin întroducerea valorile lor directă în sistemele BD relaţionale

все значения данных атомарные (или скалярные). Это означает, что в каждой таблице в позиции на пересечении столбца и строки с точки зрения реляционных операций находится только одно значение и никак не группа из нескольких значений.

58

Перечисленные выше характеристики реляционных систем являются явными ограничениями, принятыми исключительно для упрощения системы. Требования простоты привели к высокому уровнюу абстрактизации в способе представления данных. Данные представляются в наиболее понятном пользователю виде, хотя на физическом уровне представления они имеют гораздо более сложную и конкретизованную структуру.Простота модели привела к главной проблеме реляционной модели – низкой скорости доступа к данным в случае больших баз данных. Для достижения высокой эффективности таких систем нужны специфические средства, ускоряющие метод доступа к данным. Одним из подходов является применение механизма индексации реляционных таблиц.

Развитие и широкое применение реляционных систем начались со знаменитой статьи Кодда:Codd E.F. A Relational Model of Data for Large Shared Data Banks //CACM. – 1970. – 13, Nr. 6.

Важно:1. В концептах какой модели строится логический уровень представления

данных? В реляционной модели – в отношениях и связях между ними. В иерархической – в древовидных структурах. Сетевую модель следует считать непринципиальным расширением иерархической.

2. Следует уточнять насколько развит логический уровень в каждой модели. В реляционной: сильно – высокий уровень абстрактизации, приближенный к уровню понимания пользователя. В других моделях логический уровень развит слабо (???).

3. Важно выяснить степень близости формы представления данных на логическом и физическом уровнях.

4. То же в отношении внешнего уровня.

Avantajele modelului relaţional

Succesul modelului relaţional se explică prin trei momente: Simplicitate şi percepere intuitivă a structurii (utilizarea tabelelor relaţionale); Existenţa metodelor simple şi totodată eficiente de accesare a datelor

(Indexarea datelor, indexarea tabelelor. Indexarea permite utilizarea structurilor de memorie de la nivelul fizic);

Şi, în sfârşit, modelul are o fundamentare strictă matematică – teoria mulţimilor. Se poate spus că teoria mulţimilor este o teorie matematică a relaţiilor.

Ca rezultat, metoda relaţională are avantage evidente:

59

Predictibilitatea rezultatelor de prelucrare a datelor. În baza modelului relaţional se află modelul matematic, de aceea orice interogare faţă de baza de date generează un rezultat unic, independent de organizarea fizică a datelor;

Simlicitatea descrierii datelor. Domeniul concret din lumea reală în mod natural se descrie în termenii de tabele;

Eficienţa prelucrării datelor.

Simplicitatea modelului

Se datoreşte faptului că modelul se bazează pe cel mai simplu obiect de structură – tabel relaţional.

Indexare tabelelor

… aici de explicat mecanismele de indexare

Dezavantajele (problemele critice) modelului

Rigiditatea modelului; Viteza joasă de regăsir a datelor.

60

BAZELE TEORETICE A SISTEMELOR DE

BAZE DE DATE RELAŢIONALE

(ASPECTE TEORETICE A MODELULUI RELAŢIONAL?)

3.1. Bazele matematice a modelului relaţional

Cum s-a menţionat mai sus succesul modelului relaţional se explică prin trei momente:

Simplicitate şi percepere intuitivă a structurii. (se utilizează tabele relaţionale simple);

Existenţa metodelor simple şi totodată eficiente de accesare a datelor (Indexarea datelor, indexarea tabelelor. Indexarea permite utilizarea structurilor de memorie de la nivelul fizic);

Şi, în sfârşit, modelul are o fundamentare strictă matematică – teoria mulţimilor. Se poate spus că teoria mulţimilor este o teorie matematică a relaţiilor.

Ca rezultat, metoda relaţională are avantage evidente: Predictibilitatea rezultatelor de prelucrare a datelor. În baza modelului

relaţional se află modelul matematic, de aceea orice interogare faţă de baza de date generează un rezultat unic, independent de organizarea fizică a datelor;

Simlicitatea descrierii datelor. Domeniul concret din lumea reală în mod natural se descrie în termenii de tabele;

Eficienţa prelucrării datelor.

3.1.1. Elemente ale teoriei mulţimilor

Теория множеств лежит в основе многих математических дисциплин и имеет, поэтому, для них важное значение. Особенно (în mod deosebit) это относится теоретическим основам баз данных. Операции над множествами есть релационные операции, которые положены в основу языка реляционных баз данных – SQL. Поэтому имеет смысл остановиться здесь на основных положениях теории множеств.

Prin mulţime se înţelege o colecţie nestructurată de obiecte numite elemente. Este o totalitate de elemente izolate, între care nu există careva interlegături. Ea nu are o structură intrinsecă. Mulţimea este ce mai simplă organizare a datelor, folosită în matematică.

Noţiunea de mulţime, ca orice noţiune primară, nu se defineşte ca alte noţiuni ci se caracterizează numind individual elementele sau specificând o proprietate pe care o au elementele sale şi nu o au alte obiecte (mulţimea numerilor de tip bait,

61

mulţimea numerilor naturale, etc.). Din acest punct de vedere ea este o noţiune descriptivă.

Понятие множества является, поэтому, неопределяемым понятием. Задание множества носит описательный характер (caracter descriptiv – множество целых чисел типа байт, множество натуральных чисел).

Mulţimea poate fi prezentată ca o totalitate nestructurată de elemente de oricare natură care:

Se diferă unul de altul – sunt distincte sau unice. Din asta rezultă că în mulţime nu pot fi elemente necunoscute, neprecizate (problema valorilor de tip NULL);

Posedă o proprietate comună. Aceasta proprietate reiesă din conţinutul semantic a elementelor. Anume de aceea elementele mulţimii sunt indivizibili sau atomici.

Spre exemplu, consuderăm o mulţime de adrese a studenţilor. Fie proprietatea comună constă în aceea că adresa conţine oraşul, strada şi numarul clădirii. Elementele mulţimii nu pot fi divizate în părţi constituiente dat fiind că asta duce la pierderea proprietăţii comună.

Для того чтобы некоторую совокупность элементов можно было назвать множеством, необходимо, чтобы выполнялись следующие условия două reguli: Regula de apartenenţă (incluziune?). Должно существовать правило,

позволяющее определить, принадлежит ли указанный элемент данной совокупности – предикат множества. Предикат множества задается некоторым логическим выражением, таким что, если это выражение для данного элемента равно логическому значению true, то этот элемент принадлежит множеству, если false, то не принадлежит. Predicatul reflectă proprietatea comună a elementelor mulţimii;

Regula de diferenţiere (deosebire, distingere). Должно существовать правило, позволяющее отличать элементы друг от друга. Это следствие того, что множество не может содержать двух одинаковых элементов, т.е. каждый элемент множества единственен или уникален.

Таким образом, все элементы множества являются элементами одного и того же типа (имеют одну и ту же структуру) и обладают двумя обязательными свойствами: Свойством уникальности или отличимости. (Unicitate sau diferenţiere); Свойством атомарности или неделимости; (indivizibilitate, atomicitate).

Множества обычно обозначаются заглавными латинскими буквами. Элементы множества задаются (перечисляются) в фигурных скобках:

62

. Если элемент принадлежит множеству , то это обозначается:

.

Число элементов множества называется его мощностью (cardinalul mulţimii). Если каждый элемент множества является также и элементом множества , то говорят, что множество является подмножеством множества (B este inclusă în A):

.

В общем случае подмножество может и совпадать с множеством , т.е. (включено или совпадает). Подмножество множества называется

собственным подмножеством (submulţime proprie), если

AND .

Două mulţimi sunt egale, A = B, dacă şi numai dacă conţin aceleaşi elemente: A Ì B şi B Ì A. Nu importă ordinea elementelor în fiecare mulţime.

3.1.2. Operaţii asupra mulţimilor

Операции над множествами есть релационные операции, составляющие основу реляционной алгебры. Используя понятие множества и допустимые операции над множествами можно построить более сложные и содержательные (obiecte mai complexe şi consistente) объекты.

Основными операциями над множествами являются reuniune, intersecţie, diferenţă, şi produsul cartezian.

Definiţie 1. Reuniunea (suma logică) a două mulţimi A şi B este o mulţime nouă (sau ) formată din toate elementele distincte, care se conţin sau în A sau

în B, sau şi în A şi în B

.

Определение 2. Intersecţia (общая часть, логическое произведение, produsul logic) a două mulţimi A şi B este o mulţime nouă (sau ) formată din toate elementele, содержащихся и в A и в B

.

Două mulţimi se numesc disjuncte dacă A∩B = Æ.

63

Определение 3. Разностью двух множеств A и B называется новое множество A \ B всех элементов, содержащихся в A и не содержащихся в B.

.

Пример: A={a,b,c,d,e}, B={c,d,e,g,h,f}, A \ B={a,b}.

Dacă B Ì A atunci A \ B se numeşte complementara lui B în raport cu A. Если класс объектов, на которых определяются различные множества, обозначить

(Универсум), то дополнением (complementul) множества называют разность

.

Например, различные подмножества множества целых чисел. Множество отрицательных чисел = .

Таблица 1. Обозначения для числовых множествNo Notation Description

1 N Натуральные числа ( ) – numere naturale2 Z Целые числа – numere întregi3 Q Рациональные числа – numere raţionale. Представляются

отношениями целых чисел (raport dintre numere întregi)4 R Действительные числа – numere reale5 С Комплексные числа – numere complexe

(И чем в большей степени каждое отдельное требование будет обладать свойствами атомарности и отличимости (обязательные свойства для элемента множества), тем больше математических результатов из теории множеств можно будет применить.?)

3.1.3. Produsul cartezian a mulţimilor. Definirea matematică a relaţiei

Produsul cartezian a mulţimilor prezintă o modalitate de a construi obiecte noi din cele existente.

Пусть и – множества. Expresia de tip , unde şi , se numeşte pereche ordonată. Упорядоченность понимается в том смысле, что и

. Totalitatea (mulţimea totală) a perechelor (a,b) constituie (образует) produsul cartezian a mulţimilor A şi B. Se notează astfel:

.

64

Равенство вида (egalitatea de tip) означает, что и . În cazul general putem considera o înşirare ordonată n-ară – binară, ternară, … (a1, a2, …, an) din elementele acestea înşirări ordonate se numesc tupluri sau cortege.Замечание. Под упорядоченностью здесь следует понимать соответствие между порядком следования множеств и порядком следования элементов в n-ках.

Definişia 4. Produsul cartezian a mulţimilor se numeşte mulţimea înşirărilor ordonate n-are (tuplurilor, cortejelor) de tip

Definişia 5. Gradul produsului cartezian se numeşte numărul n a mulţimilor care întră în acest produs cartezian. Observaţie. Если все множества одинаковы, то используют обозначение

Definişia 6. Se numeşte relaţie de gradul n (relaţie n-ară) submulţimea R a produsului cartezian a mulţimilor , anume . De exemplu este o relaţie binară, R A×B×C – o relaţie ternară, etc (aritatea relaţiei?).

Definişia 7. Se numeşte cardinalul relaţiei R cardinalul mulţimei de corteje , care se conţin în relaţia R.

Замечание. (Remarcă) Мы только что дали математическое определение отношения (numai ce am dat o definiţie matematică a relaţiei). Однако, понятие отношения является очень важным не только с математической точки зрения. Понятие отношения фактически лежит в основе всей реляционной теории баз данных. Как будет показано ниже, отношения являются математическим аналогом таблиц (класса реляционных таблиц?). Сам термин "реляционное представление данных", впервые введенный Коддом, происходит от термина relation, понимаемом именно в смысле этого определения. (в смысле класса эквивалентных таблиц!)

Т.к. любое множество можно рассматривать как декартовое произведение степени 1, то любое подмножество, как и любое множество, можно считать отношением степени 1. Это не очень интересный пример, свидетельствующий лишь о том, что термины "отношение степени 1" и "подмножество" являются синонимами.

65

Нетривиальность понятия отношения для баз данных проявляется, когда степень отношения больше 1. Ключевыми здесь являются два момента (două momente cheie): Во-первых, все элементы отношения есть однотипные кортежи corteje de acelaşi tip. Asta ne permite să le considerăm ca analojii ale linilor în tabele simple, anume în tabele care … Однотипность кортежей позволяет считать их аналогами строк в простой таблице, т.е. в такой таблице, в которой все строки состоят из одинакового числа ячеек и в соответствующих ячейках содержатся одинаковые типы данных. Например, отношение, состоящее из трех следующих кортежей {(1, "Albu", 1000), (2, "Condrea ", 2000), (3, "Moraru", 3000)} можно считать таблицей, содержащей данные о сотрудниках и их зарплатах. Такая таблица будет иметь три строки и три колонки, причем в каждой колонке содержатся данные одного типа:

1 Albu 10002 Condrea 20003 Moraru 3000

Остается только дать колонкам соответствующие наименования. Во-вторых. За исключением крайнего случая (dacă excludim cazul extrem), когда отношение есть само декартово произведение , отношение включает в себя не все возможные кортежи из декартового произведения: . Это значит, что для каждого отношения имеется критерий, позволяющий определить, какие кортежи входят в отношение, а какие - нет. Этот критерий, по существу, определяет для нас смысл – sensul (семантику) отношения. Действительно, каждому отношению можно поставить в соответствие (în corespundere) некоторое логическое выражение , зависящее от n параметров (n-местный предикат un predicat n-poziţional sau n-propoziţional?) и определяющее, будет ли кортеж принадлежать отношению . Это логическое выражение называют предикатом отношения . Более точно, кортеж принадлежит отношению тогда и только тогда, когда предикат этого отношения принимает значение "истина":

В свою очередь, каждый n-местный предикат задает некоторое n-арное отношение. Таким образом, существует взаимно однозначное соответствие между n-арными отношениями и n-местными предикатами. Математически это можно выразить так:

66

Если это не вызывает путаницы, удобно и отношение, и его предикат обозначать одной и той же буквой. Например, отношение имеет предикат

.

67

5. Algebra relaţională şi calculul relaţional

Partea a treia din modelul lui Codd sau partea de manipulare a datelor relaţionale stipulează doua modalităţi echivalente de acces la date: Algebra relaţională; Calculul relaţional.În realizările concrete nu sunt utilizate întocmai nici una nici alta. Drept standard de facto a devenit limbajul SQL pentru care algebra relaţională este o bază teoretică.

5.1. Algebra relaţională

Algebra relaţională constă dintr-un un set de operatori care realizeză operaţii pe relaţii. Cu alte cuvinte, relaţiile sunt operanzii acestori operatori care se numesc şi operatori relaţionali. Toate proprietăţile studiate mai sus referitor la operaţiile relaţionale se referă la operatorii relaţionali întocmai. Cea mai importantă este proprietatea închidere, care constă în aceea că rezultatul acţiunii operatorului relaţional asupra oricărei relaţie este iarăşi o relaţie:

.

Din acest punct de vedere se spune că algebra relaţională este compactă (închisă). Acest lucru ne permite să construim expresii încorporate din operatori relaţionali şi relaţii:

.

De calcularea astfel de expresii este preocupat calculul relaţional.

Conform teoriei lui Codd este primit ca operatorii algebrei relaţionale să se împartă în două grupe: Operatorii teoriei mulţimilor. Operatorii de:

1. reuniune;2. intersecţie;3. diferenţă;4. produsul cartezian.

Operatorii speciali. Operatorii de: 5. selecţie;6. proiecţie;7. joncţiune;8. diviziune.

Aceşti operatori ne permit crearea noilor relaţii din una sau mai multe relaţii iniţiale. Pentru unii operatori binari relaţiile trebuie să fie compatibile după tip.

Relaţii compatibile după tip. Definiţie:

68

Von numi două relaţii compatibile după tip dacă ele au acelaşi titlu (sau aceeaşi schemă), şi anume, au acelaşi set de atribute cu denumiri identice; atributele cu acelaşi nume sunt definite pe aceleaşi domenii.

Operator de redenumire:

5.2. Operatorii teoriei mulţimilor

ReuniuneaReprezintă o operaţie definită pe două relaţii şi compatibile după tip şi este o relaţie nouă cu acelaşi titlu (aceeaşi schemă) şi corpul (sau extensia) care conţine tupluri cât din , atât şi din .

Să notează prinsau .

Aşadar:

≡ = …

Exemplu:

NumarTabel Nume Salariu1 Albu 10002 Ceban 20003 Vitiu 3000

NumarTabel Nume Salariu1 Albu 10002 Proca 25004 Vitiu 3000

NumarTabel Nume Salariu1 Albu 10002 Ceban 20003 Vitiu 30002 Proca 25004 Vitiu 3000

69

În reuniunea relaţiilor tuplurile identice din ambele relaţii întră numai o singură dată. Cum observăm la efectuarea operaţiei de reuniune proprietatea de cheie potenţială nu este moştenită. Cauza este că proprietatea de cheie potenţială nu poate fi dedusă de undeva, ea explicit se inpune reieşind din semnificaţia (semantica) datelor, pe când operatorii algebrei relaţionale acţionează într-un mod formal identic în toate cazurile, independent de semnificaţia datelor. Operatorii relaţionali operează formal logic şi ’nu ştiu’ de semnificaţia datelor.

IntersecţieReprezintă o operaţie definită pe două relaţii şi compatibile după tip şi este o relaţie nouă cu acelaşi titlu (schema) şi corpul (extensia) care conţine tupluri aparţinând concomitent relaţiei şi relaţiei .

Să notează prinsau .

Aşadar:

≡ = …

Exemplu:

NumarTabel Nume Salariu1 Albu 1000

DiferenţaDiferenţa reprezintă o operaţie definită pe două relaţii şi compatibile după tip şi este o relaţie nouă cu acelaşi titlu (schema) şi corpul (extensia) care conţine tupluri aparţinând relaţiei , şi nu aparţinând relaţiei .

Să notează prinsau .

Exemplu:

NumarTabel Nume Salariu2 Ceban 20003 Vitiu 3000

Produsul cartezian

70

Produsul cartezian a relaţiilor şi este o relaţie nouă , a cărei titlu (schema) se obţine prin concatenarea schemelor relaţiilor şi

şi a cărei corpul (extensie) cuprinde toate combinaţiile tuplurilor din cu cele din

.

Să notează prinsau .

Exemplu:

NumarTabel1 Nume1 Salariu1 NumarTabel2 Nume2 Salariu21 Albu 1000 1 Albu 10001 Albu 1000 2 Negru 25001 Albu 1000 4 Vitiu 30002 Ceban 2000 1 Albu 10002 Ceban 2000 2 Negru 25002 Ceban 2000 4 Vitiu 30003 Vitiu 3000 1 Albu 10003 Vitiu 3000 2 Negru 25003 Vitiu 3000 4 Vitiu 3000

Cardinalul este egal cu produsul cardinalelor relaţiilor şi , iar gradul este egal cu suma gradelor lor .

Produsul cartezian prezintă puţin interes de sine stătător fiind că nu reprezintă informaţie nouă. El se foloseşte atunci când din relaţiile date se construiesc noi relaţii prin operatori relaţionali speciali.

5.3. Operatorii speciali

SelecţiaOperaţia de selecţie asupra relaţiei reprezintă o relaţie nouă, a cărei schema este identică cu cea a relaţiei şi a cărei extensia este constituită din acele tupluri din care satisfac o anumită condiţie indicată explicit în cadrul operaţiei.Sintaxa operaţiei de selecţie:

- selecţie condiţionată (selecţie cu condiţie generală);

71

– caz particular de selecţie cu condiţie, aşa numită -selecţie unde X şi Y sunt atributele R.

Condiţia este o expresie logică formată în general din denumiri de atribute, constante, operatori binari (buliene) AND, OR, NOT şi operatori de comparaţie

. Operaţiile binare de bază sunt şi (AND), sau (OR) şi negaţie (NOT). Dintre acestea, primele două sunt operații binare iar a treia este o operație unară.

Condiţia este o expresie logică care leagă valori de atribute prin operatori de comparaţie de tip şi a.m.d.Exemplu:

.

Exemplu cu -selecţie …

Selecţia înseamnă efectuarea de tăieturi orizontale asupra relaţiei .

Selecţia este principală şi unică operaţie de selectare condiţionată a cortejelor.

ProiecţiaProiecţia relaţiei pe atributele reprezintă o relaţie nouă, a cărei schema este construită din atributele şi a cărei extensia constă din tuplurile , astfel că .

Sintaxa operaţiei de proiecţie:

.

Exemplu:.

Remarcă: în relaţia de proiecţie se elimină dublări de corteje.

Proiecţia înseamnă efectuarea de tăieturi verticale asupra relaţiei . Prin operaţia de proiecţie se trece de la o relaţie de gradul la o relaţie de gradul , mai mic (

). Cu alte cuvinte se trece de la un spaţiu cu dimensiuni la un spaţiu cu un număr mai mic de dimensiuni , ceia ce şi înseamnă proiecţie. Relaţia n-ară este proiectată pe relaţia m-ară, unde m < n.

Proiecţia este principală şi unică operaţie de extragere (necondiţionată!) a anumitor atribute din relaţie.

72

Joncţiunea (joinul – unirea relaţiilor)Joncţiunea relaţiilor şi cu condiţia este o relaţie nouă de tip

.Aici:

– produsul cartezian, – operaţia de selecţie.

Expresia este o expresie logică. Aşadar joncţiunea este rezultatul efectuării consecutive a două operaţii – produsului cartezian şi a selecţiei.

În funcţie de tipul de condiţie logică din cadrul operaţiei de joncţiune există mai multe tipuri de joncţiune: operaţie generală de joncţiune (joncţiune generală). Sintaxa operatorului

; -joncţiune. Sintaxa operaţiei , sau în formă

prescurtată , unde atributele ; equijoncţiune (equijoinul). Equijoinul este cazul particular a -joncţiunei

; joncţiune naturală (joinul natural). Joinul natural este atât de important că are o

sintaxă proprie deosebită .

Exemple:-joncţiune

Fie o companie careva are nevoie de a stoca informaţia despre furnizori şi piese livrate. Fiecare furnizor şi fiecare piesă se caracterizează printr-un careva propriu merit sau grad de calitate care poate fi evaluat cu un criteriu numeric. Fie activitatea companiei este organizată astfel că fiecare furnizor nu are drept să livreză piese cu gradul de calitate mai mare decât propriul său grad (merit). Avem relaţiile:

Furnizori

FNUM FNAME FMARK1 Albu 42 Ceban 13 Vitiu 2

Piese

PNUM PNAME PMARK1 Ciocan 32 Cleşte 23 şurubelniţă 1

73

Răspunsul la întrebarea “Care piese are drept să livreze fiecare furnizor?“ va fi -joncţiune :

FNUM FNAME FMARK PNUM PNAME PMARK1 Albu 4 1 ciocan 31 Albu 4 2 cleşte 21 Albu 4 3 şurubelniţă 12 Ceban 1 3 şurubelniţă 13 Vitiu 2 2 cleşte 23 Vitiu 2 3 şurubelniţă 1

EquijoinulFie avem relaţii F, P, L – Furnizori, Piese, Livrari corespunzător:

Furnizori PieseFNUM FNAME

1 Albu2 Ceban3 Vitiu

Livrari

FNUM PNUM VOLUME1 1 1001 2 2001 3 3002 1 1502 2 2503 1 1000

Răspunsul la întrebarea “Care piese şi în ce volum sunt livrate de fiecare furnizor?” va da equijoinul

FNUM1 FNAME FNUM2 PNUM VOLUME1 Albu 1 1 1001 Albu 1 2 2001 Albu 1 3 3002 Ceban 2 1 1502 Ceban 2 2 2503 Vitiu 3 1 1000

(de continuat analiza cu R[PNUM=PNUM]P, R = )

PNUM PNAME1 ciocan2 cleşte3 şurubelniţa

74

Equijoinul are drept neajunsuri dublări de atribute care trebuie să fie încă şi redenumite în prealabil. De acest neajuns este lipsit joinul natural.

Joinul natural. Este atât de important că are definiţie şi sintaxă proprii :

Fie sunt date relaţiile şi cu atributele identice. Atunci joinul

natural a relaţiilor şi este o relaţie nouă cu schema şi cu extensia formată din mulţimea

de tupluri , astfel că şi .

Observăm că:1. În schema R atributele X1, X2, …, Xp întră o singură dată;2. În sintaxa joinului natural nu sunt indicate atributele după care

se formează joinul natural. Acest lucru să subânţelege implicit: Joinul natural se exercită după toate atributele identice.

Joinul natural este eqivalent cu exercitarea următoarei secvenţă de operaţii: a redenumi temporar atributele identice în relaţiile iniţiale; a exercita produsul cartezian a relaţiilor; a exercita selecţia tuplurilor cu valori egale ale atributelor care au fost identice

până la redenumire; a exercita proiecţia, eliminând dublări de atribute; a restabili denumirile iniţiale ale atributelor.

Joinul natural poate fi executat repetat pe mai multe relaţii. Este uşor de verificat în acest context că joinul natural este o operaţie asociativă:

,

deaceia astfel de expresii pot fi scrise fără paranteze: .

Exemplu:Răspunsul la întrebarea “Ce piese şi în ce volum sunt livrate de fiecare furnizor?” va da joinul natural :

FNUM FNAME PNUM PNAME VOLUME1 Albu 1 Ciocan 1001 Albu 2 Cleste 2001 Albu 3 surubelnita 3002 Ceban 1 Ciocan 1502 Ceban 2 Cleste 250

75

3 Vitiu 1 Ciocan 1000În rezultatul final de luat proiecţiaDe dat în formă de interogare SQL

DiviziuneaDefiniţie. Fie sunt date relaţiile şi

cu atributele identice. Diviziunea relaţiei pe relaţia este o relaţie R nouă cu schema şi extensia care constă din mulţimea tuplurilor , acei care întră în tuplurile

din relaţia în concatenare cu toate tuplurile din relatia .

Aici: - divizor (numărător?); - numitor.

Sintaxa: . Se utilizează la apeluri cu cuvântul „toate”.

Exemplu: Cine din furnizori livrează toate piese

- divizor

FNUM PNUM1 11 21 32 12 23 1

Un alt exemplu mai evident pentru a înţelege mai clar efectuarea operaţiei de diviziune:Divizorul : Numitorii :

1) 2) 3)

1) 2) 3)

76

S# P#… …S1 P1S1 P2S1 P3S1 P4S1 P5S1 P6S2 P1S2 P2S3 P2S4 P2S4 P4S4 P5… …

P#P1

P#P2P4

P#P1P2P3P4P5P6

S#S1S2

S#S1S4

S#S1

- numitorPNUM

123

FNUM1

5.4. Operatorii relaţionali dependenţi şi independenţi

Nu toţi operatorii relaţionali sunt independenţi – unii din ei se exprimă prin alţii: operatorul de joncţiune. Se exprimă prin produsul cartezian, selecţie iar în

joinul natural şi prin proiecţie; operatorul de intersecţie. Se exprimă prin diferenţă în modul următor:

operatorul de diviziune. Se exprimă prin diferenţă, produsul cartezian şi proiecţie în modul următor:

Aşadar, operatorii de joncţiune, intersecţie şi diviziune nu sunt operatori elementari sau de bază.

Operatorii relaţionali independenţi (elementari, primitivi, de bază)

Restul operatorilor relaţionali sunt independenţi, ei nu pot fi exprimaţi prin alţii: operatorul de reuniune. Este unicul operator cu care putem uni cortejele a două

relaţii cu aceeaşi schemă; operatorul de diferenţe. Este unicul operator cu care putem elimina acelea

cortejele din relaţie care se conţin în alta relaţie cu aceeaşi schemă. operatorul produsului cartezian. Este unicul operator cu care putem adăuga în

relaţie atribute noi; operatorul de selecţie. Este unicul operator cu care putem selecta condiţionat

tupluri anumite din relaţie; operatorul de proiecţie. Este unicul operator cu care putem selecta

(necondiţionat!) atribute micşorând numărul lor;

5.5. Cereri care nu pot fi exprimate prin operatorii algebrei relaţionale

Ne cătând la puterea algebrei relaţionale există un şir de cereri (interogări) care nu pot fi exprimate numai prin operatorii ei proprii. Pentru a trece această barieră trebuie se recurgem la extensii procedurale a limbajelor relaţionali. Exemple de astfel de cereri sunt: Cereri de selecţie al datelor după atribute. Apar, cum vom vedea mai târziu, în

cazul normalizării insuficiente; Cereri de încheiere tranzitivă; Cereri de tabele încrucişate.

77

Exemplu:Fie dată relaţia COMPONENTA_CHIMICA_SUBSTANTE(SNAME, HIDROGEN, HELIU, …, 105_ELEMENT) în care este reprezentată informaţia despre conţinutul în procente a elementelor chimice în diferite substanţă

SNAME HIDROGEN HELIU … 105_ELEMENTADN(ARN) 5 3 … 0,01Benzina 52 0 … 0acid ortofosforic 24 0 … 0… … … … …

Se pune întrebarea “De a determina tote elementele chimice care se conţin într-o substanţă careva în cantitate mai mare de 50%“. Din punct de vedere algoritmic răspunsul se obţine simplu – examinăm consecutiv valorile atributelor şi memorizăm acele atribute care au valori mai mare de 50%. Dar aceasta înseamnă selectarea condiţionată a atributelor. Formal noi nu putem exprima acest apel prin operatorii algebrei relaţionale, fiind că în algebra relaţională nu există operatori de selecţie condiţionată a atributelor.Problema a apărut de fapt de aceea că relaţia dată nu este bine proiectată sau cum vom spune bine normalizată. Ce înseamnă normalizare bună vom vorbi mai târziu, iar aici vom repartiza informaţiile necesare pe trei relaţii SUBSTANTE(SNUM, SNAME), ELEMENTE(ENUM, ENAME), COMPONENTA(SNUM, ENUM, EPROCENT):

SUBSTANTESNUM SNAME

1 AND2 Benzina3 acid ortofosforic… …

ELEMENTEENUM ENAME

1 Hidrogen2 Heliu… ...105 105_element

COMPONENTASNUM ENUM EPROCENT

1 1 51 2 3… … …1 105 0,01

78

2 1 522 2 0… … …3 24 0… … …

Pe aceste relaţii interogarea dată se realizează prin următoarea secvenţă de operatori relaţionali:

1. R1(SNUM, ENUM, EPROCENT)= COMPONENTA WHERE EPROCENT>50 (selecţie);

2. R2(ENUM)=R1[ENUM] (proiecţie);3. R3(ENUM, ENAME)=R2[ENUM=ENUM] ELEMENTE (equijoinul);4. RASPUNS(ENAME)=R3[ENAME] (proiecţie).

Cum s-a menţionat mai sus problema care a apărut aici se datoreşte normalizării insuficiente, dar mai bine zis – proiectării iniţiale incorecte a bazei de date. În orice caz crearea bazei de date trebuie să se înceapă cu crearea proiectului semantic (logic) folosind tehnologia diagramelor ER (Entity Relationship). Relaţiile de mai sus trebuie se rezulte din următoarea diagrama ER Acum interogarea formulată mai sus uşor se realizează în limbajul SQL cu o

singură comandă:

SELECT ENAME, EPROCENTFROM ELEMENTE, COMPONENTAWHERE ELEMENTE.ENUM=COMPONENTA.ENUM AND

EPROCENT>50;

De observat aici că legăturile din diagrama ER sunt referite în opţiunea comenzii WHERE prin condiţia ELEMENTE.ENUM=COMPONENTA.ENUM.

79

SUBSTANTE

SNUMSNAME...

COMPONENTA

SNUMENUMEPROCENT...

ELEMENTE

ENUMENAME...

1

∞∞

1

Fig. 7.1. ER diagrama bazei de date COMPONENTA CHIMICA

6. PROIECTAREA SCHEMELOR BAZELOR DE DATE RELAŢIONALE. FORME NORMALE

Modele de proiectare a sistemelor informatice: Model infologic. Modelare infologică presupune analiza structurii şi

activităţii în dinamică a domeniului concret din lumea reală. Determinarea scopului de creare a sistemului informatic şi cerinţelor puse în faţă;

Modelul datalogic. Modelarea datalogică presupune crearea unui sistem integru de date interlegate după anumite concepte care va prezenta modelul informaţional al domeniului concret din lumea reală. Aici nu se au în vedere date concrete, ci noţiuni de date, tipuri de date, variabile, domenii, restricţii asupra datelor, etc.;

Modelul tehnic (fizic). Primele modele sunt generalizate. Ele nu depind de metode şi mijloace folosite în realizarea fizică a sistemului informatic. Modelarea fizică se realizează în cadrul unui mediu de elaborare (programare) concret folosind instrumentele şi posibilităţile specifice anume acestui mediu.

Fiecare din aceste modele are limbajul propriu de descriere. Pezentarea lor este dată în formă de diagrame specifice modelului, folosind anumite sisteme de notaţii.

In cazul sistemelor de bază de date acestea modele se concretizează în: Modelul conceptual. Analiza obiectelor şi proceselor de activitate în

dinamică. Argumentarea necesităţii creării, formularea scopului şi cerinţelor faţă de sistem de bază de date. … ;

Modelul relaţional. In modelarea relaţională are loc stabilirea asocierilor şi restricţiilor de structură în conceptele modelului relaţional. … Se finalizează cu diagrama ER.

Modelul fizic. Se realizează în SGBD concret, folosind instrumentele şi posibilităţile lui. Relaţiile se transformă în tabele relaţionale, atributele relaţiilor devin câmpuri în tabele, etc.

In acest capitol vom aborda problemele modelării relaţionale. Sub schema bazei de date relaţională vom înţelege schemele tuturor relaţiilor din aplicaţie unite într-o diagramă entitate – relaţie (modelul ER – Entitate/Relaţie).

6.1. Forme normale a relaţiilor. Forme normale inferioare

6.1.1. Exemplu de bază

Pentru expunerea ulterioară vom considera următorul exemplu de bază: Domeniul concret al lumii reale – universul de discurs: Fie să cere crearea unei aplicaţie de bază de date pentru o instituţie ştiinţifică care îndeplineşte diferite proiecte de cercetare. Proiectele constău din lucrări, care se îndeplinesc de

80

colaboratorii firmei. Aplicaţia trebuie să modeleză activitatea firmei în acest domeniu.Scopul (obiectivele): Trebuie se păstrăm informaţii (se ducem evidenţa operativă) despre mersul îndeplinirii lucrărilor din proiecte la orice moment de timp.(Despre modele infologic, datalogic, tehnic(fizic))După prima convorbire cu specialiştii din domeniul dat s-a stabilit că (modelul domeniului) – физическая модель предметной области:

O firmă ştiinţifică structurată pe sectoare îndeplineşte proiecte; Fiecare proiect constă din mai multe lucrări; Colaboratorii îndeplinesc lucrările din diferite proiecte; Lucrările se îndeplinesc pe etape în limitele prestabilite de timp;

Scopul: Să cere ducerea evidenţei îndeplinirei lucrărilor în timp real (cine îndeplineşte lucrarea dată la momentul dat, cărui proiect ea aparţine, ...).

Aici în formă de text a fost formulat modelul fizic al domeniul concret din lumea reală. Au fost evidenţiate obiectele şi menirea lor. Rolul lor în activitatea domeniului. A fost concretizat scopul creării şi cerinţele faţă de produsul final.

În cadrul convorbirilor ulterioare sau evidenţiat procesele de activitate. S-a precizat că (modelul logic – сu restricţii) – логическая модель:

fiecare colaborator are număr de tabel. Numărul de tabel (codul colaboratorului) este unic pe toată organizaţia. Prezentarea (descrierea) obiectului în formă COLABORATOR(CNUM, CNAME, …);

fiecare sector are număr unic pe toată organizaţia. …; fiecare proiect are număr unic pe toată organizaţia. …; fiecare lucrare are număr unic în cadrul proiectului dat. … fiecare lucrare se îndeplineşte de unul singur colaborator independent de

sector în care el este angajat; fiecare colaborator poate să îndeplinescă mai multe lucrări concomitent

dintr-un proiect sau mai multe sau temporar se nu activeză nici într-un proiect;

...(trebuie extins exemplu cu introducerea etapelor care pot fi îndeplinite de diferiţi colaboratori)

Aici sau precizat şi sau descris toate obiectele, procesele şi restricţiile implicate în activitatea pe care dorim s-o modelăm.

Următoarea etapă – crearea modelului relaţional integru a acestui domeniu din lumea reală.

Ca prima variantă a modelului logic se propune o singură relaţie de tip:

81

COLABORATORI_SECTOARE_PROIECTE_LUCRARI(CNUM, CNAME, SNUM, SNAME, SPHONE, PNUM, PNAME, LNUM, LNAME)

Sau pe scurt: CSPL(CNUM, CNAME, SNUM, SNAME, SPHONE, PNUM, PNAME, LNUM, LNAME)

Starea actuală a domeniului se caracterizează prin următoarele fapte colaboratorul Albu este angajat în primul sector şi în primul proiect “Cosmos”

îndeplineşte lucrarea unu, iar în al doilea proiect “Clima” îndeplineşte tot lucrarea unu;

…

Acestă stare este reprezentată în următorul tabel:CSPL

CNUM CNAME SNUM SNAME SPHONE PNUM PNAME LNUM LNAME1 Albu 1 … 11-22-33 1 Cosmos 1 …1 Albu 1 … 11-22-33 2 Clima 1 …2 Ceban 1 … 11-22-33 1 Cosmos 2 …3 Vitiu 2 … 34-45-56 1 Cosmos 3 …3 Vitiu 2 … 34-45-56 2 Clima 2 …

Acest tabel reprezintă relaţia care în mod automat se află în FN1. Cheia relaţiei este {CNUM, PNUM, LNUM}. Ea reiesă numai din tratarea noastră al datelor care poate fi exprimată prin următoarele enunţuri: fiecare proiect constă din mai multe lucrări (relaţie dintre lucrări şi proiecte); fiecare lucrare se îndeplineşte de un colaborator (relaţie dintre lucrări şi

colaboratori); fiecare colaborator poate să îndeplinească mai multe lucrări din unul sau mai

multe proiecte (relaţie dintre colaboratori, lucrări şi proiecte);

Mulţimea de atribute {CNUM, PNUM, LNUM} unic va determina acestea relaţii dacă vom impune restricţia de cheie a relaţiei. Valorile ei răspund la întrebarea “cine îndeplineşte, care lucrare, din care proiect, în care etapă, dacă vom introduce şi descrierea în dinamica timpului real“. Adica, anume descrie procesul de îndeplinire a lucrărilor în timp. Valorile cheii {CNUM, PNUM, LNUM} unic rîspund şi la scopul creării bazei de date. (? Cheia relaţiei numai unic determină corteje din R).

6.1.2. Anomalii în baza de date

Se analizăm calitatea tabelului obţinut reieşind din relaţia propusă. Uşor să observă că în relaţia dată are loc o redundanţă mare de date. De exemplu: se repetă informaţia despre colaboratorul Albu sau despre proiectul Cosmos etc. Redundanţa

82

datelor rezultă din aceea că în una şi aceeaşi relaţie se păstrează datele despre diferite obiecte. În relaţie este cel puţin o legătură de tip ∞:∞ (Colaboratori:Proiecte, Sectoare:Proiecte). Redundanţa poate avea consecinţe grave în ceea ce ţine de corectitudinea datelor. Modificarea stării bazei de date în prezenţa redundanţei poate duce la distrugerea integrităţii structurale a modelului relaţional. Din acest motiv vom spune că redundanţa datelor duce la prezenţa în relaţie a aşa numitor anomalii de modificare a stării bazei de date. Prezenţa anomaliilor se manifestă prin posibile situaţii când modificarea datelor în relaţie (tabel) sau nu este posibilă de loc sau poate duce la distrujerea corectidudinii sau integrităţii datelor şi cere eforturi adiţionale pentru a evita această distrujere posibilă.

Exemple: Nu putem întroduce datele despre un lucrător nou, dacă el la momentul dat nu

îndeplineşte nici o lucrare (nu este cunoscută valoare atributului cheie LNUM). La fel despre un proiect nou, un colaborator nou. Deci, apare problema de asigurare a integrităţii structurală;

Modificarea eventuală a numărului de telefon în sectorul 1 trebuie să se facă cu mare atenţie, fiind că să repetă în mai multe înregistrări;

Eliminarea informaţiei despre proiectul „Cosmos” (la finisarea etapei sau a lucrărilor) va duce la pierderea informaţiei despre colaboratorul Ceban;

...

Definiţie. Vom spune că relaţia dată conţine anomalii atunci când modificarea unor date din relaţie nu este posibilă sau există pericolul că ea va duce la distrujerea corectidudinii (integrităţii) datelor şi sunt necesare eforturi adiţionale pentru a evita acest pericol.

Consecinţele grave ale anomaliilor se manifestă la efectuarea operaţiilor de modificare a stării bazei de date, deaceea există trei tipuri de anomalii.

Anomalii de înserare (INSERT) Nu putem introduce date despre un lucrător nou, dacă el la momentul

introducerii nu îndeplineşte nici o lucrare; Nu putem introduce date despre o lucrare, dacă încă nu este numită persoana

care va îndeplini-o; …

Cu alte cuvinte: nu putem introduce datele despre un obiect ne introducând date despre alt obiect.

Anomalii de modificare (UPDATE) Modificarea datelor repetate trebuie să se facă în toate înregistrările unde ele

apar şi cere eforturi adiţionale de verificare; ...

83

Anomalii de ştergere (DELETE) Eliminarea datelor repetate trebuie să se facă în toate înregistrările unde ele

apar şi cere eforturi adiţionale de verificare; Eliminarea informaţiei despre proiectul „Cosmos” va duce la pierderea

informaţiei despre colaboratorul Ceban; …

Cu alte cuvinte: eliminarea datelor despre un obiect poate duce la eliminarea datelor despre alt obiect. Sau: modul de păstrare a datelor despre un obiect depinde de modul de păstrare a datelor despre alt obiect.

Anomaliile apar atunci când modelul de date nu este adecvat lumii reale sau nu este bine proiectat. În exemplul nostru nu poate fi păstrată informaţia despre un colaborator care nu îndeplineşte nici o lucrare. Sau despre o lucrare, dacă încă nu este numită persoana care va îndeplini-o. Deci, dacă modelul de date nu este bine proiectat atunci apar probleme adiţionale în realizarea restricţiilor din lumea reală. De observat în acest context că în relaţia CSPL cel puţin avem o legătură de tip ∞:∞ (Sectoare-Proiecte) care cauzează redundanţă de date.

6.3. Forme normale. Noţiuni generale

Pentru a elimina anomaliile din relaţie, dar de fapt pentru a proiecta corect modelul de date se aplică procedeul de normalizare a relaţiilor. Normalizarea relaţiilor constă în descompunerea lor pe relaţii mai mici efectuată după anumite reguli, urmărind scopul principal de a elimina anomaliile (a satisface criteriile de calitate). Procedeul prezintă trecerea consecutivă de la un nivel de normalizare, sau o formă normală a relaţiilor, la un alt nivel mai superior de normalizare, sau la o altă formă normală mai superioară a relaţiilor.

Normalizarea relaţiilor este una din două modalităţi de proiectare a aplicaţiilor de bază de date: proiectare prin normalizarea relaţiilor. Este o modalitate formalizată, logică,

bazată pe regulu formale. Constă în aducerea relaţiilor la diferite forme normale reieşind din diferite forme de dependenţe dintre atribute (în primul rând dependenţe funcţionale, etc.). Proiectarea logică rezultă în crearea modelului relaţional prezentat în formă de aşa numită diagramă ER (Entity Relationships) sau model Entitate-Relaţie;

proiectarea semantică bazată pe sensul datelor. Proiectarea semantică se efectuiază folosind direct diagramele ER (Entity Relationships) sau modele ER.

Există mai multe nivele de normalizare a relaţiilor sau mai multe forme normale în care relaţiile se află. Aceste forme normale sunt divizate în două grupe:

84

forme normale inferioare FN1, FN2, FN3, FNBC (forma normală Boyce-Codd);

forme normale superioare FN4, FN5.

FNBC? În prima grupă? Da, dar ca o generalizare a FN3. Forma normală FNBC a fost descoperită mai târziu decât au fost stabilite formele FN4 şi FN5.

În practică mai des se folosesc primele patru (sau chiar primele trei) forme, adica formele inferioare, dar noi le vom trece pe toate în ordinea nominalizată.

6.4. Forme normale inferioare. Dependenţe funcţionale

În procesul de aducere a relaţiilor la forme normale inferioare rolul cheie îl joacă dependenţe funcţionaeă dintre atribute.

Definiţie 1. Fie este dată relaţia . Mulţimea de atribute este funcţional dependentă de mulţimea de atribute ( în mod funcţional determină ) dacă şi numai dacă pentru orice tupluri din aceea că reiesă că şi

în orice stare a relaţiei .

Sau, altă definiţie:

Definiţie 2. Atributul Y depinde funcţional de atributul X dacă şi numai dacă fiecărei valoare a lui X îi corespunde exact o singură valoare Y. Simbolic dependenţa funcţională se noteză prin . Mulţimea de atribute se numeşte determinantul dependenţei funcţionale iar mulţimea de atribute se numeşte partea dependentă a dependenţei funcţionale.

Dacă mulţimea de atribute constituie cheia potenţială a relaţiei atunci fiecare din restul atributelor (atributelor non-cheie) depinde funcţional de .

Exemplu: Sector Telefon1 11-22-332 34-45-561 11-22-33

Dependenţa funcţională este .

Deoarece, în cazul general, în relaţie pot fi mulţimi de atribute cheie şi mulţimi de atribute non-cheie, dependenţe funcţionale sunt posibile dintre: atrubute cheie şi non-cheie; atribute non-cheie;

85

atribute cheie (în cazul cheii compuse).Cum vom vedea mai jos acestea trei forme de dependenţe duc la diferite nivele de normalizare.

Dependenţe funcţionale în relaţii şi dependeţe matematiceDependenţele funcţionale (DF) şi dependenţele matematice sunt asemănătoare, dar nu sunt identice. Între ele există diferenţă principială. Dacă dependenţa matematică careva are loc în totdeauna, adica este o lege ( ), atunci rezultatul DF depinde de starea bazei de date (sau starea în lumea reală).

Cu alte cuvinte, putem spune că:Dependenţa funcţională ne permite să aflăm valoarea unui atribut după valorea altui atribut dar în fiecare stare a bazei de date acesta valoare va fi diferită. Însă, dependenţa funcţională se păstrează.

La momentul dat numărul de telefon în sectorul 1 este 11-22-33, dar în altă dată el poate fi altul, dependenţa lui de numărul de sector păstrânduse.

Exemple de dependenţe funcţionale în relaţia COLABORATORI_SECTOARE_PROIECTE_LUCRARI:

Dependenţe funcţionale de cheia relaţiei (dependenţe totale de cheie):1. {CNUM, PNUM, LNUM} CNAME

{CNUM, PNUM, LNUM} SNUM{CNUM, PNUM, LNUM} SNAME{CNUM, PNUM, LNUM} SPHONE{CNUM, PNUM, LNUM} PNAME{CNUM, PNUM, LNUM} LNAME

Sau în formă succintă :{CNUM, PNUM, LNUM} {CNAME, SNUM, SNAME, SPHONE, PNAME, LNAME}. Aici ne am folosit de aceea că dacă cheia {CNUM, PNUM, LNUM} determină o mulţime de atribute atunci ea determină şi fiecare atribut în parte.

Dependenţa funcţională a atributelor care conţin informaţie despre colaborator de codul colaboratorului (dependenţe de un atribut al cheii – dependenţe parţiale de cheie):2. CNUM CNAME

CNUM SNUMCNUM SNAMECNUM SPHONE

Sau CNUM {CNAME, SNUM, SNAME, SPHONE}.

Dependenţa funcţională a denumirii proiectului de numărul lui (dependenţă parţială de cheie):3. PNUM PNAME

86

Dependenţa funcţională a denumirii lucrarii de numărului proiectului şi numărul lucrării (dependenţă parţială de cheie):4. {PNUM, LNUM} LNAME

Dependenţa funcţională a denumirii sectorului şi numărului de telefon de numărul sectorului (dependenţe dintre atribute non-cheie):5. SNUM SNAME

SNUM SPHONESau SNUM {SNAME, SPHONE}

Замечание 1. Следует четко раскрыть основной смысл функциональных зависимостей. Он заключается в том, что функциональные зависимости через зависимости между атрибутами задают в явном виде связи (?) между объектами в предметной области. Набор функциональных зависимостей является ключевым элементом логической модели предметной области.

Remarcă 2. Toate dependenţe funcţionale au fost deduse nu din forma relaţiei ci din semnificaţia legăturilor existente dintre atributele relaţiei. Ele prezintă restricţii adiţionale în relaţie care reiesă din sensul datelor. Deci – dependenţa funcţională este o noţiune semantică. Totalitatea dependenţelor funcţionale reprezintă o totalitate de legături (dar nu toate!) dintre obiectele lumii reale.

Замечание 3. Следует различать функциональные зависимости между атрибутами объектов предметной области и атрибутами в данном отношении. Так, код сотрудника функционально (т.е. однозначно) определяет его фамилию, адрес, зарплату и т.д., то есть собственные атрибуты, но не определяет номер отдела, в котором он работает, а тем более, название этого отдела, то есть атрибуты другой сущности. Возможно, следует ввести понятие ключевого атрибута для объектов предметной области (или для сущности) в отличие от ключа данного конкретного отношения и посмотреть, что из этого может вытекать. По крайней мере, это замечание необходимо использовать при обосновании алгоритмов нормализации. А возможно, его можно развить как тему дипломной работы, разработав на его основе программный продукт для интерактивного семантического проектирования информационной системы. Основным моментом такой работы должно стать однозначное отображение множества функциональных зависимостей для объектов и процессов предметной области на множество функциональных зависимостей в реляционной модели. Такое исследование стимулирует необходимость тщательной разработки модели конкретной предметной области до реализации этой модели в виде реляционной структуры данных. Проектировать нужно не на уровне реляционной модели (т.е. в терминах отношений), а на уровне сущностей из предметной области и отношений между ними. Реляционная (логическая) модель должна быть сгенерирована автоматически вместе со всеми ее элементами. Правда, это, возможно, уже и заложено в таких CASE продуктах, как ERWin.

Замечание 4. Нужно определиться, наконец, с понятиями объект, процесс, состояние, сущность! Процесс описывается набором законченных действий, в то время как состояние описывает отношения (т.е. незаконченные действия!) между объектами.

Remarca 5. Anume aici de introdus noţiune de dependenţe funcţionale directe şi tranzitive.

87

Tipuri de dependenţe funcţionale

In relaţie sunt două grupuri de atribute: atribute care fac parte din componenţa cheii – atribute cheie (CNUM, PNUM, …) şi atribute non-cheie (CNAME, SNUM, SNAME, …). Deaceea, dependenţele funcţionale pot se apară de diferite combinaţii: dependenţe funcţionale dintre atribute non-cheie, dependenţe funcţionale dintre atribute cheie şi atribute non-cheie şi, în cazul special, şi dependenţe funcţionale dintre atributele cheie.

Aşa dar, pot fi depistate mai multe tipuri de dependenţe funcţionale: dependenţă funcţională totală de cheia relaţiei (exemplul 1 de mai sus); dependenţă funcţională parţială de cheia relaţiei (exemplele 2, 3,4); dependenţă funcţională dintre atribute cheie şi atribute non-cheie (exemplul

1); dependenţă funcţională dintre atribute non-cheie (exemplul 5); dependenţă funcţională dintre atributele cheie ; dependenţă funcţională directă dintre atribute; dependenţă funcţională indirectă sau tranzitivă dintre două atribute prin

intermediul al treilea atribut. Exemplu: din aceea că CNUM SNUM şi SNUM SPHONE reiesă că CNUM SPHONE. În cuvinte: atributul CNUM determină funcţional atributul SPHONE tranzitiv prin intermediul atributului SNUM.

Remarcă: din exemplul 1 observăm că în dependenţa totală de cheia relaţiei {CNUM, PNUM, LNUM} {CNAME, SNUM, SNAME, SPHONE, PNAME, LNAME} se conţin toate atributele relaţiei CSPL. De aici putem conclude că

dacă în dependenţa funcţională întră toate atributele relaţiei atunci determinantul dependenţei este cheia relaţiei. Se mai numeşte şi superchie.

Deci, dacă în dependenţa funcţională {A1, A2, A3} {B1, B2, …, Bn} se conţin toate atributele relaţiei R, atunci setul de atribute {A1, A2, A3} este cheia relaţiei.

6.5. Aducerea relaţiilor la forme normale inferioare

Dependenţele funcţionale ne permit să repartizăm informaţiile despre diferite entităţi în diferite relaţii eliminând anomaliile şi păstrând totodată legăturile dintre entităţi. Acest lucru se efectuiază prin normalizare – procedeu de descompunere după anumite reguli a relaţiei date pe mai multe relaţii mai mici lipsite de anomalii. Procedeul prezintă trecerea consecutivă de la un nivel de normalizare, sau o formă normală, la un alt nivel mai superior de normalizare, sau la o altă formă normală mai superioară. Forma normală a relaţiei dată depinde de tipul de dependenţe funcţionale în aceasta relaţie.

88

În continuare pentru concretizare vom presupune că cheia {CNUM, PNUM, LNUM} este unică în relaţie şi deaceea normalizarea vom executa-o în raport cu acesta cheie.

Normalizarea ca eliminarea consecutivă a dependenţelor funcţionale nedorite

6.5.1. Forma normală unu FN1

Orice relaţie însuşi după definiţie se află în forma normală FN1 fiind că constă din tupluri unice şi valorile atributelor sunt atomice (indivizibile). Deci – relaţii care să nu fie în forma normală FN1 nu există.

6.5.2. Forma normală doi FN2

Definiţie. Regula FN2:Relaţia este în forma normală doi FN2 dacă şi numai dacă ea este în forma normală unu FN1 şi în ea nu există atribute non-cheie, care depind de o parte a cheii potenţială a relaţiei (depind parţial de cheia relaţiei).

Cu alte cuvinte, relaţia se află în forma normală FN2 dacă în ea nu sunt dependenţe parţiale de cheie a atributelor non-cheie.

Dependenţa funcţională parţială şi totală.

Remarcă. Dacă cheia relaţiei este simplă atunci relaţia în mod automat este în FN2.

Cheia relaţiei CSPL este cheie compusă {CNUM, PNUM, LNUM}. Analizând dependenţele funcţionale existente în relaţie, concludem că relaţia dată nu este în FN2, deoarece în ea există dependenţe funcţionale de o parte a cheii relaţiei (dependenţe parţiale de cheie):CNUM {CNAME, SNUM, SNAME, SPHONE};PNUM PNAME;{PNUM, LNUM} LNAME.

Prezenţa acestor dependenţe este consecinţa redundanţei datelor în relaţie. De exemplu, dacă în sectorul unu lucrează 30 colaboratori atunci, din aceea că CNUM

SNUM, CNUM SNAME, CNUM SPHONE reiesă că în 30 de înregistrări a relaţiei CSPL se va repeta aceeaşi informaţie despre sectorul unu. Este evident, că ar fi mult mai bine ca informaţia despre sectorul unu să fie prezentată numai o singură dată într-o relaţie aparte. Rezultă că dependenţele parţiale de cheia relaţiei sunt nedorite şi trebuie să fie transformate în altă formă de dependenţe prin descompunerea relaţiei dată în mai multe relaţii, fiecare fiind în forma normală FN2. Pur şi simplu eliminate dependenţele parţiale nu pot fi, deoarece provin din lumea reală. Există unica modalitate de a elimina (mai corect de a transforma) dependenţele parţiale de cheia relaţiei şi, tot odată, de a păstra toate dependenţele

89

funcţionale care reprezintă legăturile dintre entităţile domeniului concret din lumea reală. Pentru asta scoatem consecutiv acele grupuri de atribute care întră în dependenţele funcţionale cu acelaşi determinant într-o relaţie separată nouă, în care atributul (atributele) determinant devine cheia relaţiei nouă. În acelaşi timp atributul (atributele) determinant va rămâne şi în relaţia veche în calitate de cheie externă. În sfârşit, relaţia COLABORATORI_SECTOARE_PROIECTE_LUCRARI se descompune în patru relaţii – una INDEPLINIRE_LUCRARI conţine acele atribute care au rămas după descompunere, iar altele trei sunt relaţii noi COLABORATORI_SECTOARE, PROIECTE, LUCRARI în conformitate cu trei grupe de dependenţe parţiale:

COLABORATORI_SECTOARE_PROIECTE_LUCRARI (CSPL)CNUM CNAME SNUM SNAME SPHONE PNUM PNAME LNUM LNAME

COLABORATORI_SECTOARE (CS)CNUM CNAME SNUM SNAME SPHONE

PROIECTE (P)PNUM PNAME

LUCRARI (L)PNUM LNUM LNAME

INDEPLINIRE_LUCRARI (CPL)CNUM PNUM LNUM

Remarcă 1. Observăm regula de bază – atributele determinanţii în dependenţele parţiale au devenit chei potenţiale în relaţiile noi şi tot odată au rămas în relaţia iniţială ca chei externe. Acest fapt ne asigură păstrarea legăturilor dintre obiectele lumii reale.

Aşadar, relaţia iniţială a fost descompusă în patru relaţii care sunt în formă normală FN2. În ele nu mai sunt anomalii de inserţie. Acum putem liber se înscriem colaboratori noi sau lucrări noi. Relaţia COLABORATORI_SECTOARE tot este în FN2, dar analiza ei ne demonstrează că nu toate anomaliile din ea sunt eliminate. În ea a rămas redundanţă al datelor: cortejele cu diferite valori al atributului CNUM conţin informaţie repetată despre sectoare. Numărul de sectoare este în mod natural mult mai mic decât numărul colaboratorilor. Deaceea, dacă spre exemplu, în sectorul 1 lucrează o sută de colaboratori, atunci informaţia despre acest sector se va repeta într-o sută de corteje. Rezolvarea problemei iarăşi constă în descompunerea relaţiei COLABORATORI_SECTOARE în mai multe fiind în formă normală mai superioară formei normale FN2, în astfel mod ca informaţia despre sectorul 1 să fie prezentată numai o singură dată.

90

6.5.3. Forma normală trei FN3

Dependenţele funcţionale pot avea loc dintre atribute cheie şi non-cheie în diferite combinaţii. (Dependenţe tranzitive?!)

Două definiţii adiţionale:Definiţie 1. Atributele unui grup separat de atribute se numesc reciproc independente dacă nici unul din ei nu se află în dependenţă funcţională de altul.

Definiţie 2. Dependenţa tranzitivă. Prin definiţie, atunci când un atribut A determină atributul B, iar B determină atributul C, apare dependenţa tranzitivă a atributului C de atributul determinant A prin intermediul atributului B. Deci, dacă A B şi B C, atunci A C. Dependenţele funcţionale tranzitive dintre atributele unei relaţii pot cauza erori de reactualizare, deoarece dacă să modifică A, atunci trebue să se modifice şi C.

Definiţie 3. Regula FN3:Relaţia este în forma normală trei FN3 dacă şi numai dacă ea este în forma normală doi FN2 şi toate atributele non-cheie în ea sunt reciproc independente.

Definiţie 4. Regula FN3 în altă formă, echivalentă cu prima:Relaţia este în forma normală trei FN3 dacă şi numai dacă ea este în forma normală doi FN2 şi în ea nu sunt dependenţe tranzitive a atributelor non-cheie de cheia relaţiei prin intermediul altor atribute non-cheie.

Relaţia COLABORATORI_SECTOARE nu este în FN3 deoare în ea sunt dependenţe funcţionale între atributele non-cheie:SNUM SNAME;SNUM SPHONE.Sau SNUM {SNAME, SPHONE}

Aici SNUM este determinantul acestor dependenţe funcţionale (DF). Pentru a elimina (mai bine zis, a transforma) aceste dependenţele funcţionale trebuie să descompunem în continuare relaţia COLABORATORI_SECTOARE în mai multe relaţii, scotând din ea atributele, care fac parte în dependenţele funcţionale cu acelaşi determinant în relaţie separată nouă. Pentru asta atributele non-cheie se plasează într-o relaţie nouă împreună cu copia determinantului lor.

COLABORATORI_SECTOARECNUM CNAME SNUM SNAME SPHONE

91

COLABORATORICNUM CNAME SNUM

SECTOARESNUM SNAME SPHONE

De observat că atributul SNUM a rămas în relaţia COLABORATORI în calitate de cheie externă, iar în relaţia SECTOARE el a devenit atribut cheie ca determinantul dependenţelor funcţionale nedorite în relaţia COLABORATORI_SECTOARE. Dacă atributul SNUM nu ar fi rămas în relaţia COLABORATORI , atunci ar fi fost pierdută legătura CNUM SNUM in relaşia iniţială R.

Aşa dar relaţia iniţială COLABORATORI_SECTOARE_PROIECTE_LUCRARI a fost descompusă în mai multe relaţii mici lipsite de anomalii

COLABORATORICNUM CNAME SNUM

SECTOARESNUM SNAME SPHONE

PROIECTEPNUM PNAME

LUCRARIPNUM LNUM LNAME

INDEPLINIRE_LUCRARICNUM PNUM LNUM

Prin această descompunere sau obţinut relaţiile COLABORATORI, SECTOARE, PROIECTE, LUCRARI, INDEPLINIRE_LUCRARI care se află în FN3. În ele sunt eliminate toate anomaliile. Legăturile dintre obiectele bazei de date care au fost prezente în relaţia iniţială sau păstrat în relaţia INDEPLINIRE_LUCRARI

INDEPLINIRE_LUCRARICNUM PNUM LNUM1 1 11 2 12 1 23 1 33 2 2

Acum sistemul nostru informaţional prezintă un set de relaţii legate între ele. Aceste relaţii sunt de două tipuri: relaţii care descriu obiecte şi relaţii care descriu

92

proces sau starea de proces. Primele sunt nomenclatoare (sau dicţionare, справочники, номенклатурные документы). Ele conţin toate informaţiile necesare pentru a descrie procesul de busines sau starea lui in dinamica timpului real. Adesea ori acestea informaţii sunt extrase din acte normative oficiale. Cu alte cuvinte, nomenclatoarele cuprind toate detaliile caracteristice obiectelor necesare pentru a determina procese. Procesele la

Aşadar, relaţiile COLABORATORI, SECTOARE, PROIECTE, LUCRARI sunt nomenclatoare (dicţionare?), iar relaţia INDEPLINIRE_LUCRARI este relaţia dinamică care reprezintă starea actuală a procesului în lumea reală.

ER-diagrama acestei baze de date va fi:

Din schemele relaţiilor obţinute se formează schema (structura) BD.

6.5.4. Forma normală Boyce-Codd FNBC

Până acum noi am presupus că în relaţie este numai o singură cheie candidat. În acest caz ea este şi cheia primară a relaţiei. Din acest moment omitem această restricţie şi presupunem că: Relaţia are două (sau mai multe) cheie candidat; Cheile candidat sunt compusă (compuse din mai multe atribute); Două chei candidat se intersectează (au cel puţin un atribut comun).

Să considerăm următorul exemplu. Fie, avem relaţia FURNIZORI_PIESE_ LIVRARI sau FPL:

FURNIZORI_PIESE_ LIVRARI (FPL)FNUM FNAME PNUM PVOLUME PPRICE

1 Firma 1 1 100 …1 Firma 1 2 200 …1 Firma 1 3 300 …2 Firma 2 1 150 …2 Firma 2 2 250 …

93

∞

1

∞

1

∞

1

1∞

SNUMSNAMESPHONE

SECTOARE

CNUMCNAMESNUM

COLABORATORI

CNUMPNUM ┐LNUM ┘

INDEP_LUCRARI ┌ LNUM└ PNUM LNAME

LUCRARI

PNUMPNAME

PROIECTE

3 Firma 3 1 1000 …(Ar trebui de adăugat aici şi atributul PPRICE)

Presupunem că atributele FNUM şi FNAME au valori unice. Atunci, relaţia FPL are două chei candidat compuse şi intersectate {FNUM, PNUM} şi {FNAME, PNUM}.

Видно, что данные хранятся в отношении с избыточностью - при изменении наименования поставщика, это наименование нужно изменить во всех кортежах, где оно встречается. Можно ли эту аномалию устранить при помощи алгоритма нормализации, описанного в предыдущей главе? Для этого нужно выявить имеющиеся функциональные зависимости (как обычно, курсивом выделены ключевые атрибуты):

Dependenţe funcţionale:{FNUM, PNUM} → PVOLUME – поставляемое количество зависит от первого ключа отношения,{FNUM, PNUM} → FNAME – наименование поставщика зависит от первого ключа отношения,{FNAME, PNUM} → PVOLUME – поставляемое количество зависит от второго ключа отношения, {FNAME, PNUM} → FNUM – номер поставщика зависит от второго ключа отношения,FNUM → FNAME – наименование поставщика зависит от номера поставщика. FNAME → FNUM – номер поставщика зависит от наименования поставщика.

Данное отношение не содержит неключевых атрибутов, зависящих от части сложного ключа (см. определение 2НФ). Действительно, от части сложного ключа зависят атрибуты FNAME и FNUM, но они сами являются ключевыми. Таким образом, отношение находится в 2НФ.

Кроме того, отношение не содержит зависимых друг от друга неключевых атрибутов, т.к. неключевой атрибут всего один - PVOLUME (см. определение 3НФ). Таким образом, показано, что отношение FPL находится в 3НФ.

Следовательно, описанный ранее алгоритм нормализации неприменим к данному отношению. Очевидно, однако, что аномалия данного отношения устраняется (se elimină) путем декомпозиции (prin descompunere) его на два следующих отношения:

FURNIZORI_1FNUM FNAME

1 Firma 12 Firma 2

94

3 Firma 3

LIVRARI_1FNUM PNUM PVOLUME

1 1 1001 2 2001 3 3002 1 1502 2 2503 1 1000

Prin această descompunere relaţia iniţială a fost adusă la aşa numită formă normală Boyce-Codd FNBC:

Определение Отношение R находится в нормальной форме Бойса-Кодда тогда и только тогда, когда детерминанты всех функциональных зависимостей являются потенциальными ключами.

Definiţie. Relaţia R se află în forma normală Boyce-Codd FNBC dacă şi numai dacă determinanţii al tuturor dependenţelor funcţionale în relaţie sunt chei candidat.

Cu alte cuvinte: toate dependenţele funcţionale în relaţie trebuie să fie numai dependenţe de cheie!

Приведя отношения к НФБК, мы исключили в каждом из них все возможные виды функциональных зависимостей, кроме зависимостей от потенциального ключа. Потенциальные ключи при этом являются и детерминантами полной функциональной зависимости, т.е. суперключами. Это означает, что если отношение находится в НФБК, то оно автоматически находится и в 3НФ. Наличие двух составных перекрывающихся потенциальных ключей в условии было необходимо, чтобы прийти к случаю частичной зависимости ключевого атрибута от потенциального ключа. Следовательно, нужно прямо доказать, что наличие двух составных перекрывающихся потенциальных ключей в отношении приводит к двум частичным зависимостям ключевых атрибутов от потенциальных ключей.

Строгое определение впервые дано Хизом (Heath) в 1971 году.

Pentru o relaţie cu o singură cheie candidat care se utilizează implicit ca şi cheia primară, formele FN3 şi FNBC coincid.

95

Замечание. Если отношение находится в НФБК, то оно автоматически находится и в 3НФ. Действительно, это сразу следует из определения 3НФ.

Исходное отношение FURNIZORI_PIESE_ LIVRARI не находится в НФБК, т.к. имеются зависимости (FNUM → FNAME и FNAME → FNUM), детерминанты которых не являются потенциальными ключами (для данного отношения!).

Для того чтобы устранить зависимость от детерминантов, не являющихся потенциальными ключами, необходимо провести декомпозицию, вынося эти детерминанты и зависимые от них части в отдельное отношение. Отношения FURNIZORI_1 и LIVRARI_1, полученные в результате декомпозиции находятся в НФБК. Замечание. Приведенная декомпозиция исходного отношения FPL на отношения FURNIZORI_1 и LIVRARI_1 не является единственно возможной. Альтернативной декомпозицией является декомпозиция на следующие отношения:

FURNIZORI_2FNAME FNUMFirma 1 1Firma 2 2Firma 3 3

LIVRARI_2FNAME PNUM PVOLUMEFirma 1 1 100Firma 1 2 200Firma 1 3 300Firma 2 1 150Firma 2 2 250Firma 3 1 1000

На первый взгляд, такая декомпозиция хуже, чем первая. Действительно, наименования поставщиков по-прежнему повторяются, и при изменении наименования поставщика, это наименование придется менять одновременно в нескольких местах (тем более сразу в двух отношениях!). Кажется, что ситуация стала еще хуже, чем была до декомпозиции. Однако такое ощущение возникает от того, что мы интуитивно считаем, что наименования поставщиков могут меняться, а номера - нет. Если же предположить, что номера поставщиков тоже могут меняться (почему бы нет - директор приказал перенумеровать поставщиков!), то первая декомпозиция получается такой же "плохой" как и вторая - повторяющиеся номера придется менять одновременно в нескольких местах и также сразу в двух отношениях. На самом деле никакого противоречия тут нет. В отношении "Поставки-2" атрибут "Наименование поставщика" (FNAME) является внешним ключом, служащим для связи с отношением "Поставщики-2". Поэтому, при изменении наименования поставщика, это изменение производится в отношении "Поставщики-2" и каскадно (см. стратегии поддержания ссылочной целостности в гл. 3) распространяется на отношение "Поставки-

96

2" совершенно так, как изменение номера поставщика каскадно распространяется на отношение "Поставки-1". Поэтому, формально обе декомпозиции совершенно равноправны. В реальной работе разработчик выберет, конечно, первую декомпозицию, но тут важно подчеркнуть, что его выбор основан совсем на других соображениях, не имеющих отношения к формальной теории нормальных форм.

Замечание. Отношение "Поставки-2", полученное в результате декомпозиции имеет всего один потенциальный ключ. Поэтому, для анализа отношения "Поставки-2" не требуется привлекать определение НФБК, достаточно определения 3НФ. Хотя отношение "Поставщики" имеет два потенциальных ключа, но, т.к. других атрибутов в нем нет, оно уже так просто устроено, что упростить его дальше нельзя (???). Возникает вопрос, имеются ли нетривиальные примеры отношений в НФБК, не находящиеся в 3НФ и не такие простые, как отношение "Поставщики"?

Problemă: De efectuat normalizarea în considerat mai sus exemplu cu relaţia COLABORATORI_SECTOARE_PROIECTE_LUCRARI dacă puţin modificăm condiţiile (modelul logic):

Fiecare colaborator are număr unic de tabel pe toată organizaţia; Fiecare sector are număr unic pe toată organizaţia; Fiecare proiect are număr unic pe toată organizaţia; Fiecare proiect constă din mai multe lucrări; Fiecare lucrare are număr unic în cadrul proiectului dat; Fiecare lucrare are nume unic în cadrul proiectului dat; Fiecare lucrare poate fi îndeplinită de mai mulţi colaboratori, independent de sector în

care ei sunt angajaţi; Fiecare colaborator poate să îndeplinescă mai multe lucrări concomitent; ...

Avem aici două chei compuse şi intersectate:

{CNUM, PNUM, LNUM},{CNUM, PNUM, LNAME}.

6.5.5. Algoritmi stricţi de normalizare

Cum am menţionat mai sus normalizarea relaţiilor este o modalitate formalizată, logică de proiectare a bazelor de date. Graţie acestui fapt pot fi propuşi algoritmi stricţi de normalizare. Aceşti algoritmi se bazează pe dependenţe funcţionale şi prezintă nu alt ceva decât eliminarea consecutivă a dependenţelor funcţionale nedorite.

Выше на основе анализа имеющихся в отношении функциональных зависимостей мы последовательно выявляли те из них, которые нарушали ту или иную нормальную форму вплоть до NFBC и выносили атрибуты этих зависимостей в отдельное отношение. Общее правило такое: атрибуты, нарушающие требования данной нормальной формы выносятся в новое отношение вместе со своим детерминантом. Во вновь образованном отношении атрибут – детерминант функциональной зависимости становится потенциальным ключом. Вместе с тем этот атрибут остается в исходном

97

отношении в качестве внешнего ключа. Таким образом при нормализации отношений функциональные зависимости не теряются. Они трансформируются в транзитивные зависимости атрибутов дочерней таблицы от первичного ключа родительской через внешние ключи.

Pe paşi:

1. Aducerea la forma normală unu FN1. Informaţia se plasează în una sau mai multe relaţii, care reprezintă entităţile lumii reale. Aceste relaţii în mod automat se află în FN1. (dacă sunt relaţii, bineînceles)

2. Aducerea la forma normală doi FN2. Dacă după analiză se află că în careva relaţie există dependenţă funcţională de o parte a cheii potenţiale se recurge la decompoziţia ei în următorul mod:Situaţia iniţială. Relaţia care nu este în FN2 - R(K1,K2, A1,…,An, B1,…,Bm):{K1,K2} – cheia relaţiei compusă,{K1,K2} { A1,…,An, B1,…,Bm } – dependenţe funcţionale,{K1} { A1,…,An } – dependenţa funcţională a unor atribute de o parte a cheii relaţiei;Situaţia finală. Relaţiile decompuse:R1(K1,K2, B1,…,Bm) – restul din relaţia iniţială R,R2(K1, A1,…,An) – relaţia nouă în care a fost scoasă dependenţa funcţională de o parte a cheii potenţiale. (atributul K1 în R1 a devinit şi cheie externă!)

3. Aducerea la forma normală trei FN3. Dacă după analiză relaţiilor noi se află că în careva relaţie există dependenţă funcţională dintre atributele non-cheie recurgem la decompoziţia ei în următorul mod:Situaţia iniţială. Relaţia care nu este în FN3 - R(K, A1,…,An, B, B1,…,Bm):K – cheia relaţiei,K { A1,…,An, B, B1,…,Bm } – dependenţe funcţionale,B { B1,…,Bm } – dependenţa funcţională a unor atribute non-cheie de alte atribute non-cheie;Situaţia finală. Relaţiile decompuse:R1(K, A1,…,An, B) – restul din relaţia iniţială R,R2(B, B1,…,Bm ) – relaţia nouă în care a fost scoasă dependenţa funcţională dintre atributele necheie. (atributul B în R1 a devinit cheie externă!)

Tot acea, dar într-o notaţie puţin mai formală

Fie este dată relaţia R(K1, K2, F1, F2, F3, F4,…),unde {K1, K2} – cheia relaţiei,F1, F2, F3, F4, … – atribute non-cheie. Atunci:

1. Analuza regulii formei normală unu NF1:

98

Relaţia R este în forma normală FN1 după definiţie. Relaţii care să nu fie în forma NF1 nu există.

2. Analuza regulii formei normală doi NF2:Dacă cheia relaţiei R este compusă şi există dependenţă funcţională a atributelor non-cheie de o parte a cheii, de exemplu K2 F2, atunci relaţia R nu satisface cerinţele FN2 şi se descompune în următoarele două

R1(K2, F2); R2(K1, K2, F1, F3, F4, …).

3. Analuza regulii formei normală trei NF3:Dacă în relaţile noi R1 şi R2 există dependenţă funcţională dintre atributele non-cheie, de exemplu F1 F3 în relaţia R2, atunci relaţia R2 nu satisface cerinţele FN3 şi se descompune în următoarele două

R1(K2, F2); R3(F1, F3); R4(K1, K2, F1, F4, …).

Rezume:Aşadar, relaţia iniţială R(K1, K2, F1, F2, F3, F4,…) prin normalizare consecutivă a fost descompusă în trei relaţii: R1(K2, F2), R3(F1, F3), R4(K1, K2, F1, F4, …), toate fiind în FN3. Diagrama ER a schemei normalizată până la forma FN3 va fi următoarea:

4. Analuza regulii formei normală NFBC:Fie este dată relaţia R(K, K1, K2, F1, F2, F3, F4, …) cu două chei candidat compuse şi intersectate:

{K,K1} { F1, F2, F3, F4, …},{K,K2} { F1, F2, F3, F4, …},

K1 K2,K2 K1.

Relaţia dată R satisface forma normală FN3, dar nu satisface forma normală FNBC, deoarece în ea sunt dependenţe funcţionale cu determinantul ne fiind cheia potenţială (K1 K2, K2 K1). Relaţia R trebuie atunci descompusă în două relaţii în felul următor:

99

1

∞∞

1

R4

K1K2F1F4…

R3

F1F3

R1

K2F2

R1(K1, K2); R2(K, K1, F1, F3, F4, …)sau R1(K2, K1); R2(K, K2, F1, F3, F4, …).

Două descompuneri posibile corespund acelor două dependenţe K1 K2, K2 K1.

6.6. Corectitudinea procedurii de normalizare. Descompunere fără pierderi. Teorema lui Heath

Noţiuni generaleКак было показано выше, алгоритм нормализации состоит в выявлении функциональных зависимостей предметной области и соответствующей декомпозиции отношений. Предположим, что мы уже имеем работающую систему, в которой накоплены данные. Пусть данных корректны в текущий момент, т.е. факты предметной области правильно отражаются текущим состоянием базы данных. Если в предметной области обнаружена новая функциональная зависимость (либо она была пропущена на этапе моделирования предметной области, либо просто изменилась предметная область), то возникает необходимость заново нормализовать данные. При этом некоторые отношения придется декомпозировать в соответствии с алгоритмом нормализации. Возникают естественные вопросы - что произойдет с уже накопленными данными? Не будут ли данные потеряны в ходе декомпозиции? Можно ли вернуться обратно к исходным отношениям, если будет принято решение отказаться от декомпозиции, восстановятся ли при этом данные? Для ответов на эти вопросы нужно ответить на вопрос - что же представляет собой декомпозиция отношений с точки зрения операций реляционной алгебры? При декомпозиции мы из одного отношения получаем два или более отношений, каждое из которых содержит часть атрибутов исходного отношения. В полученных новых отношениях необходимо удалить дубликаты строк, если таковые возникли. Это в точности означает, что декомпозиция отношения есть не что иное, как взятие одной или нескольких проекций исходного отношения так, чтобы эти проекции в совокупности содержали (возможно, с повторениями) все атрибуты исходного отношения. Т.е., при декомпозиции не должны теряться атрибуты отношений. Но при декомпозиции также не должны потеряться и сами данные. Данные можно считать не потерянными в том случае, если возможна обратная операция - по декомпозированным отношениям можно восстановить (recompune) исходное отношение в точности в прежнем виде (exact în forma iniţială). Операцией, обратной операции проекции, является операция соединения отношений. Имеется большое количество видов операции соединения (см. гл. 4). Т.к. при восстановлении исходного отношения путем соединения проекций не должны появиться новые атрибуты, то необходимо использовать естественное соединение (joinul natural). Определение 6. Проекция отношения на множество атрибутов называется собственной, если множество атрибутов является собственным подмножеством множества атрибутов отношения (т.е. множество атрибутов не совпадает с множеством всех атрибутов отношения ). Определение 7. Собственные проекции и отношения называются декомпозицией без потерь, если отношение точно восстанавливается из них при помощи естественного соединения для любого состояния отношения :

. Definiţie 1. Proiecţia a relaţiei pe mulţimea de atribute se numeşte proprie dacă mulţimea de atribute este o submulţime proprie a mulţimei de

100

atribute în relaţia (mulţimea de atribute nu coincide cu mulţimea atributelor relaţiei ).

Definiţie 2. Proiecţiile proprii şi a relaţiei prezintă o descompunere fără pierderi (descompunere corectă) dacă relaţia întocmai se recompune din ele prin joinul natural pentru orice stare a relaţiei :

.

ExempleExemplu 1. Fie este dată relaţia R:

R

NUM NAME SALARY

1 Petcu 1000

2 Albu 1000

Considerăm o decompoziţie relaţiei R în următoarele două relaţii:

R1 R2

SALARY

1 1000

2 1000

Joinul natural a acestor relaţii după atributul comun SALARY va fi următorul:

R1 JOIN R2

NUM NAME SALARY

1 Petcu 1000

1 Albu 1000

2 Petcu 1000

2 Albu 1000

Vedem că - decompoziţia dată nu este decompoziţie fără pierderi (corectă). Cu formatul italic sunt arătate tuplurile apărute în plus. Итак, данная декомпозиция не является декомпозицией без потерь, т.к. исходное отношение не восстанавливается в точном виде по проекциям (серым цветом выделены лишние кортежи). Рассмотрим другой вариант декомпозиции. Имеем отношения:

NUM NAME

1 Petcu

2 Albu

NAME SALARY

Petcu 1000

Albu 1000

101

NUM SALARY

1 1000

2 1000

По данным проекциям, имеющие общий атрибут "NUM", исходное отношение восстанавливается в точном виде. Тем не менее, нельзя сказать, что данная декомпозиция является декомпозицией без потерь, т.к. мы рассмотрели только одно конкретное состояние отношения , и не можем сказать, будет ли и в других состояниях отношение

восстанавливаться точно. Например, предположим, что отношение перешло в состояние:

NUM NAME SALARY

1 Petcu 1000

2 Albu 1000

2 Ceban 2000

Таблица 13 Отношение

Кажется, что этого не может быть, т.к. значения в атрибуте НUМ повторяются. Но мы же ничего не говорили о ключе этого отношения! Сейчас проекции будут иметь вид:

NUMNAME

1 Petcu

2 Albu

2 Ceban

Таблица 14 Отношение

NUM SALARY

1 1000

2 1000

2 2000

Таблица 15 Отношение

Естественное соединение этих проекций будет содержать лишние кортежи:

NUM NAME SALARY

1 Petcu 1000

2 Albu 1000

2 Albu 2000

2 Ceban 1000

102

2 Ceban 2000

Таблица 16 Отношение

Concluzie. Ca decompoziţia să fie fără pierderi, trebuie săi impunem careva restricţii adiţionale.Вывод. Таким образом, без дополнительных ограничений на отношение нельзя говорить о декомпозиции без потерь.

Teorema lui HiethDrept acestea restricţii adiţionale sunt dependenţele funcţionale (DF) care se stipulează de către teorema lui Heath. Teorema lui Heath. Fie este dată relaţia cu atributele . Dacă are loc dependenţa funcţională atunci proiecţiile şi formează o decompoziţie fără pierderi.Demonstraţie (probă). Trebuie se demonstrăm că pentru orice stare a relaţiei .Доказательство. Необходимо доказать, что для любого состояния отношения . В левой и правой части равенства стоят множества кортежей, поэтому для доказательства достаточно доказать два включения (încludere) для двух множеств кортежей: и . Докажем первое включение. Возьмем произвольный кортеж . Докажем, что он включается также и в . По определению проекции, кортежи и

. По определению естественного соединения кортежи и , имеющие одинаковое значение общего атрибута , будут соединены в процессе естественного соединения в кортеж . Таким образом, включение доказано. Докажем обратное включение. Возьмем произвольный кортеж . Докажем, что он включается также и в . По определению естественного соединения получим, что имеются кортежи и . Т.к. , то существует некоторое значение , такое что кортеж . Аналогично, т.к.

, то существует некоторое значение , такое что кортеж . Кортежи и имеют одинаковое значение атрибута , равное . Из этого, в силу функциональной зависимости , следует, что . Таким образом, кортеж

. Обратное включение доказано. Теорема доказана. Замечание. В доказательстве теоремы Хеза наличие функциональной зависимости не использовалось при доказательстве включения . Это означает, что при выполнении декомпозиции и последующем восстановлении отношения при помощи естественного соединения, кортежи исходного отношения не будут потеряны. Основной смысл теоремы Хеза заключается в доказательстве того, что при этом не появятся новые кортежи, отсутствовавшие в исходном отношении. Т.к. алгоритм нормализации (приведения отношений к 3НФ) основан на имеющихся в отношениях функциональных зависимостях, то теорема Хеза показывает, что алгоритм нормализации является корректным, т.е. в ходе нормализации не происходит потери информации.

103

7. Критерии качества слабо и сильно нормализованных схем отношений

Criteriile de calitate a relaţiilor slab şi înalt normalizate

Выше мы рассмотрели процесс последовательного приведения отношений к нормальным формам вплоть до NF3 или NFBC. Основной целью нормализации было избавление от аномалий актуализации. Ключевым моментом при этом служили имеющиеся функциональные зависимости. Именно, на основе функциональных зависимостей мы разложили исходное отношение на ряд более мелких, связанным между собой отношений, свободных от аномалий актуализации. Поскольку аномалии исключались на основе зависимостей вполне определенного типа, нет гарантии, что в отношении не остались аномалии по отношению к зависимостям других типов, если таковые могут иметь место. В дальнейшем при рассмотрении высших нормальных форм мы встретимся с другими типами зависимостей между атрибутами, по отношению к которым аномалии актуализации все еще могут присутствовать в отношениях, приведенных к нормальным формам NF3 или NFBC. Таким образом, наличие или отсутствие аномалий актуализации, строго говоря, следует определять по отношению к тому или иному типу имеющихся зависимостей между атрибутами. В отношениях в нормальной форме NF3 или NFBC полностью отсутствуют аномалии лишь в отношении функциональных зависимостей, как особого типа однозначных зависимостей между атрибутами отношения.

В реальной ситуации чаще всего встречаются именно функциональные зависимости между атрибутами и поэтому в практике проектирования приложений баз данных, как правило, имеют дело с подробно рассмотренной выше группой низших нормальных форм. Высшие нормальные формы, в особенности пятая нормальная форма, на практике встречаются гораздо реже. По этой причине принято считать, что отношения, приведенные к нормальным формам NF3 или NFBC являются сильно нормализованными, практически свободными от аномалий актуализации. Соответственно, отношения в нормальных формах NF1 и NF2 являются слабо нормализованными. В них заведомо имеются аномалии актуализации.

Полное избавление от аномалий вовсе не является чем то абсолютно необходимым. Действительно, такая попытка сопровождается сильной нормализацией и приводит к созданию большого количества связанных между собой мелких отношений. Таким образом имеется альтернатива выбора между высоко нормализованной моделью с большим количеством мелких отношений, и слабо нормализованной схемой с небольшим количеством больших отношений. Как поступить – это не простой вопрос, ибо от его решения зависит качество будущей базы данных. В дальнейшем

104

мы увидим, что имеются два типа систем приложений, отличающихся степенью нормализации схемы отношений.

Ниже мы сформулируем некоторые критерии качества базы данных (реляционной схемы данных) вне зависимости от ее принадлежности к той или иной системе приложений. Прежде перечислим вкратце стадии проектирования приложения.

О стадиях проектирования:1. Анализ предметной области. Выяснение целей и задач;2. Формирование модели данных предметной области. Выяснение объектов и

бизнесс-процессов. Определение информационного содержания будущей информационной системы;

3. Построение логической модели данных. Определение всех связей и ограничений в предметной области. Нормализация отношений. Построение нормализованной схемы базы данных. Создание ER модели данных;

4. Построение физической модели данных средствами конкретной СУБД. Трансформация отношений в таблицы. Разработка программ поддержки бизнесс-логики;

5. Всестороннее тестирование и оптимизация быстродействия. Оформление документации.

Решения, принятые на той или иной стадии проектирования, влияют на качество будущей базы данных. Решающее значение при этом имеет качество разработки логической модели. Именно на этой стадии мы можем либо принять высоко нормализованную модель с большим количеством мелких, связанных между собой отношений, либо остановиться на слабо нормализованной схеме, создав небольшое количество больших отношений. Поэтому важно сформулировать критерии качества базы данных (реляционной схемы данных) в зависимости от ее логической модели.

7.1. Критерии качества логической модели

Чтобы ответить на вопрос, как логическая модель данных влияет на качество базы данных, следует сформулировать некоторый набор критериев качества базы данных, характеризующих ее в тех или иных приложениях. Из большого количества возможных критериев мы рассмотрим несколько наиболее значительных.

адекватность базы данных предметной области (baza de date de a fi adecvată lumii reale);

легкость разработки и эксплуатации базы данных (uşurinţa de elaborare);

скорость актуализации данных (вставки, модификации и удаления данных) – viteza de actualizare;

скорость выборки данных (скорость выполнения запросов) – viteza de regăsire a datelor.

105

Адекватность базы данных предметной области означает:

la orice moment de timp starea bazei de date corespunde stării lumii reale pe care o reprezintă;

modificările în starea lumii reală aduc la modificările corespunzetoare în starea bazei de date;

restricţiile din lumea reală, reflectate în modelul logic se consideră de baza de date;

legăturile dintre obiectele lumii reale sunt considerate în baza de date.

Легкость разработки и эксплуатации базы данныхUşurinţă de elaborare înseamnă cerinţa de a elabora cât mai puţine proceduri

memorate şi trigeri.Proceduri memorate – proceduri şi funcţii compilate care fac parte din componenţa aplicaţiei bazei de date. Se folosesc de utilizatori pentru realizarea biznes-proceselor concrete (calculul salariului, imprimarea datelor finale, etc.).Trigeri – proceduri memorate strâns legate de careva evenimente în lumea reală şi, respectiv, în baza de date, ca de obicei – modificări de stare a bazei de date. Dacă în baza de date este prevăzut careva triger el se îndeplineşte în mod automat la apariţia evenimentului de care acest triger este asociat. Este important că utilizatorul nu poate ocoli îndeplinirea trigerului. Trigerul se îndeplineşte independent de modul în care a apărut evenimentul. Rolul principal al trigerului –automatizarea (uşurarea) procesului de prelucrare şi menţinerea integrităţii bazei de date. Trigerii pot fi atât simpli cât şi compuşi. Exemple: la introducerea incorectă a datelor se prevede apariţia la ecranul monitorului a unui mesaj, la termirarea mărfii în depozit se prevede propunerea de a înainta o comandă furnizorilor, la încercarea de a elibera marfa care s-a terminat – iară-şi un mesaj.

Viteza executării operaţiilor de modificare a stării bazei de dateÎn procesul modelării (La nivelul modelului logic) noi am determinat relaţiile şi

atributele acestor relaţii. Cum se procedăm – multe relaţii cu puţine atribute sau invers? Cum aceasta decizie va influenţa la operaţiile de modificare a stării şi interogare? Corectitudinea deciziei se va evidenţia în lucrul cu tabelele. Să analizăm cum depinde în primul rând viteza de lucru cu tabele la diferite operaţii.

Viteza înserării a datelor. Nu depinde de marimea tabelului neindexat. Depinde slab de mărimea tabelului indexat. Depinde mai mult de complexitatea indexului.

Viteza de modificare şi ştergere ale datelor. Depinde mult de mărimea tabelului neindexat fiind că implică operaţie de căutare prin verificări consecutive în toate liniile. Depinde slab de mărimea tabelului indexat (exemplu) şi slab depinde de numărul atributelor. Depinde de numărul şi complexitatea indecşilor.

106

Скорость выборки и представления пользователю данных, скорость выполнения запросовRolul principal a acestei operaţie – prezentarea informaţiei din baza de date. Se

efectuiază prin selectarea datelor din diferite tabele (operatorul SELECT din SQL). Cea mai costisitoare operaţie aici – operaţia de joncţiune a mai multor tabele (ca de obicei – joinul natural) (соединение таблиц – естественное соединение). Deci, cu cât mai multe legate între ele tabele au fost create cu atât mai încet se va îndeplini interogarea datelor. Mai ales dacă interogările nu sunt cunoscute de la bun început.

Rezultatele comparării modelelor slab şi înalt normalizate se poate reprezenta în următorul tabel

CriteriiRelaţii slab

normalizate (NF1, NF2)

Relaţii înalt normalizate (NF3, NFBC)

BD este adecvată universului de discurs

MAI PUŢIN (-) MAI MULT (+)

Uşurinţă de elaborare şi exploatare a BD

MAI COMPLICAT (-) MAI UŞOR (+)

Viteza de modificare a stării BD. Operaţiile INSERT, UPDATE, DELETE

MAI MICĂ (-) MAI MARE (+)

Viteza de selectare a datelor MAI MARE (+) MAI MICĂ (-)

Cum se vede din acest tabel relaţiile înalt normalizate sunt mai bine proiectate (trei plusuri şi un minus). Ele mai bine corespund universului de discurs, cu mai mare uşurinţă se elaborează şi exploatează, viteza de modificare a datelor în ele este mai mare. Dar pentru aceste avantaje trebuie plătit: se încetineşte selectarea datelor compuse.

У слабо нормализованных отношений единственное преимущество - если к базе данных обращаться только с запросами на выборку данных, то для слабо нормализованных отношений такие запросы выполняются быстрее. Это связано с тем, что в таких отношениях уже как бы произведено соединение отношений и на это не тратится время при выборке данных. Таким образом, выбор степени нормализации отношений зависит от характера запросов, с которыми чаще всего обращаются к базе данных.

7.2. Sisteme OLTP şi OLAP

Из множества различных типов приложений баз данных можно выделить два класса (группы) систем проиложений, в которых преимущественно

107

используются либо слабо нормализованные отношения либо сильно нормализованные отношения. Это системы OLTP и OLAP.

OLTP - On-Line Transaction Processing – оперативная обработка транзакций;

OLAP - On-Line Analitical Processing – оперативная аналитическая обработка данных.

Транзакция – целостная, относительно короткая последовательность операторов, изменяющих состояние базы данных, которая либо выполняется целиком, если все входящие в нее операторы усепешно завершены, либо целиком отменяется, если хотя бы один из входящих в нее операторов не завершился успешно.

Schemele de relaţii înalt normalşizate sunt mai bine potrivite pentru OLTP-sisteme. Cauza este că pentru OLTP-sisteme este specific: Se îndeplinesc permanent multe tranzacţii scurte; Tranzacţiile se îndeplinesc ca de obicei concomitent de la mai multe locuri

îndepătate de lucru (de la calculatoare unite în reţea); În caz de apariţie a erorii sau blocaj de sistemă tranzacţia se anulează şi se

restabileşte (restaurează?) starea BD care era la începutul tranzacţiei.

Aplicaţii tipice a sistemelor OLTP sunt: Sisteme de evidenţă în depozite; Sisteme de procurare a biletelor la comandă (în sfera de transport etc.); Sisteme bancare care îndeplinesc operaţii multiple de transfer a banelor de

pe cont pe cont; etc.

Funcţia principală a acestor sisteme constă în îndeplinirea mulţimilor de tranzacţii scurte. Tranzacţiile sunt simple (a transfera banii der pe un cont pe altul, etc.) dar problema este în aceea că ele sunt multe şi se îndeplinesc concomitent de la mai multe calculatoare din reţea (intens se lucrează cu mulţi utilizatori). În al treilea rând în caz de eroare tranzacţia se abandonează şi BD se întoarce la starea care era la începutul tranzacţiei.

Типичными примерами OLTP-приложений являются системы складского учета, системы заказов билетов, банковские системы, выполняющие операции по переводу денег, и т.п. Основная функция подобных систем заключается в выполнении большого количества коротких транзакций. Сами транзакции выглядят относительно просто, например, "снять сумму денег со счета А, добавить эту сумму на счет В". Проблема заключается в том, что, во-первых, транзакций очень много, во-вторых, выполняются они одновременно (к системе может быть подключено несколько тысяч одновременно работающих пользователей), в-третьих, при возникновении ошибки, транзакция должна целиком откатиться и вернуть систему к состоянию, которое было до начала транзакции (не должно быть ситуации, когда деньги сняты со счета А, но не поступили на счет В).

108

Практически все запросы к базе данных в OLTP-приложениях состоят из команд вставки, обновления, удаления. Запросы на выборку в основном предназначены для предоставления пользователям возможности выбора из различных справочников (nomenclatoare, ghid, îndreptar). Большая часть запросов, таким образом, известна заранее еще на этапе проектирования системы. Таким образом, критическим для OLTP-приложений является скорость и надежность выполнения коротких операций обновления данных. Чем выше уровень нормализации данных в OLTP-приложении, тем оно, как правило, быстрее и надежнее (mai rapidă şi mai solidă, cu mai mare siguranţă). Отступления (abateri de la această regulă) от этого правила могут происходить тогда, когда уже на этапе разработки известны некоторые часто возникающие запросы, требующие соединения отношений и от скорости выполнения которых существенно зависит работа приложений. В этом случае можно пожертвовать нормализацией для ускорения выполнения подобных запросов.

Schemele de relaţii slab normalşizate mai bine se potrivesc pentru OLAP-sisteme. Aplicaţia OLAP este un termin comun pentru sisteme de: suport al proceselor de luare a deciziilor – Decision Support System (DSS); depozitare a datelor - Data Warehouse; analiză intelectuală a datelor - Data Mining (căutare a informaţiilor utile în

volumuri mari de date slab structurate).Sistemele OLAP sunt menite pentru determinarea dependenţelor analitice dintre colecţii mari de date (de exemplu, ar fi bine să aflăm cum este legat volumul realizărilor de materiale de caracteristicele cumpărătorilor posibili, cursul valutei, preţurile de petrol, etc.), pentru efectuarea analizei de tip ”ce ar fi dacă presupunem că ...”. Aplicaţiile OLAP operează cu masive mari de date, deja obţinute în aplicaţiile OLTP sau luate din alte surse.Pentru sisteme OLAP este specific: Întroducerea datelor noi se face relativ rar cu seturi mari de date (de exemplu

odată în semestru datele de bilanţ al realizărilor comerciale din aplicaţia OLTP);

La întroducere datele se supun careva prelucrări de totalizare sau de “curăţire”, dat fiind faptul că datele întră în sistem din diferite surse, sunt prezentate în diferite formate, pot fi dublate, eronate etc.;

Datele odată întroduse ca de obicei nu se şterg; Interogările faţă de sistemă sânt nereglamentate şi destul de complicate.

Adesea ori noi interogări sunt formulate pentru precizarea rezultatului, obţinut din interogarea precedentă;

Viteza îndeplinirii interogării este importantă dar nu este critică.Данные OLAP-приложений обычно представлены в виде одного или нескольких гиперкубов, измерения которого представляют собой справочные данные, а в ячейках самого гиперкуба хранятся собственно данные. Например, можно построить гиперкуб, измерениями которого являются: время (в кварталах, годах), тип товара и отделения компании, а в ячейках хранятся объемы продаж. Такой гиперкуб будет содержать данных о продажах различных типов товаров по кварталам и подразделениям. Основываясь на этих данных, можно отвечать на вопросы вроде "у какого подразделения самые лучшие объемы продаж в текущем году?", или "каковы тенденции продаж отделений Юго-Западного региона в текущем году по сравнению с предыдущим годом?"

109

Физически гиперкуб может быть построен на основе специальной многомерной модели данных (MOLAP - Multidimensional OLAP) или построен средствами реляционной модели данных (ROLAP - Relational OLAP). Возвращаясь к проблеме нормализации данных, можно сказать, что в системах OLAP, использующих реляционную модель данных (ROLAP), данные целесообразно хранить в виде слабо нормализованных отношений, содержащих заранее вычисленные основные итоговые данные. Большая избыточность и связанные с ней проблемы тут не страшны, т.к. обновление происходит только в момент загрузки новой порции данных. При этом происходит как добавление новых данных, так и пересчет итогов.

До недавнего времени OLAP (online analytic processing, аналитическая обработка в реальном времени) — это технология для небольших приложений. Теперь подобное отношение устарело и будет дальше становиться все более ошибочным по мере развития OLAP-серверов и их становления ключевым компонентом хранилища данных.

OLAP-системы — “настольные” против серверных

Фраза “аналитическая обработка в реальном времени” стала синонимом анализа по методу “сечение-разбиение” (slice-and-dice). В настольных OLAP-приложениях SQL-запросы выполняются в базе данных, а возвращаемый набор результатов попадает в клиентское приложение, в котором дальнейшие манипуляции и создание сводных таблиц выполняются локально. Настольные OLAP-системы полезны, но не очень масштабируемы. Серверные OLAP-приложения, в которых приложение инициирует запрос к существенно более крупным удаленным базам данных на языке, отличном от SQL, более масштабируемы и обеспечивают возможности более глубокого анализа, чем настольные аналоги. На рынке серверных OLAP-приложений около дюжины игроков, но царствуют четыре продукта — Microsoft SQL Server Analysis Services, различные инкарнации Hyperion Essbase, Oracle Express и MicroStrategy.

OLAP-сервер поддерживает интуитивно понятный механизм просмотра и запроса данных, сложную аналитику и большую эффективность выполнения запросов за счет “прозрачного” перемещения по заранее подготовленным сводным данным. Под поддержкой сложной аналитики на сервере подразумевается поддержка языков, отличных от SQL, например, MDX- или Calc-сценариев. В наиболее продуктивных реализациях на сервере хранятся определения наиболее сложных вычислений, откуда они доступны всем пользователям. В рекомендуемой для большинства целей архитектуре данные на OLAP-сервер поступают из многомерного хранилища данных на базе реляционной СУБД.

Измерения многомерного куба в OLAP состоят из иерархий, или путей свертки. Отношение между иерархией данных и OLAP-измерением очень важно. Многие OLAP-приложения позволяют определять множественные иерархии на основе одного измерения, например, финансовый и стандартный календари. Если OLAP-приложение создавалось на основе реляционного многомерного хранилища данных, в нем должны уже присутствовать свернутые (“суррогатные”) клавиши, которые служат одинаковым целям как в OLAP, так и в реляционных системах.

110

Как и в реляционной базе данных, OLAP-серверы хранят и физические, и рассчитываемые факты. Однако аналитический “движок” OLAP-серверов поддерживает намного больше сложных фактов, определенных и рассчитываемых на сервере, и в этом обычно и заключается ключевое преимущество OLAP-реализации.

Ключевое различие между OLAP-измерениями и простыми реляционными измерениями — центральная роль, которую играют иерархии в OLAP-решении. OLAP-измерение строго структурировано на основе соответствующих иерархий, и метаданные определения куба содержат иерархические уровни. В этом одна из самых сильных сторон OLAP-решений. Средство создания OLAP-запросов извлекает иерархическую информацию с OLAP-сервера и представляет эту структуру пользователю в интуитивно понятном виде.

Также исключительно важно то, что OLAP-средства используют строгие иерархии для определения порядка агрегирования. OLAP-сервер обеспечивает своего рода ссылочную целостность между иерархическими уровнями в измерении. Чисто реляционная система не обеспечивает иерархической целостности, особенно при использовании схемы “звезда”, а не “снежинка”.

8. Forme normale superioare

decomposition = descompunereÎnlocuirea unei relaţii cu schema R, cu o colecţie de relaţii cu sub-schemele R1, R2, ..., Rn, astfel încât reuniunea acestor sub-scheme are ca rezultat R.dependencies preserving decomposition = descompunere care conservã dependenţele.Descompunerea (R1, R2, ..., Rn) a unei scheme de relaţie R, astfel încât închiderea tranzitivã a dependenţelor funcţionale valabile pe R este aceeaşi cu rezultatul reuniunii dependenţelor funcţionale valabile pe subschemele descompunerii

8.1. Dependenţe multivalente şi forma normală FN4

Considererăm următorul exemplu: ducerea evidenţei abuturienţilor care susţin examene de admitere la universitate. Din analiza universului de discurs aflăm că:

Fiecare abiturient are drept să susţie examene de probă la mai multe facultăţi concomitent;

Fiecare facultate are lista proprie de examene de întrare; Unu şi acelaşi obiect poate fi susţinut de abiturient la mai multe facultăţi; Abiturientul este obligat să susţie examene la toate obiectele facultăţii la care

el candidează, necătând la faptul că careva obiect el posibil la susţinut la altă facultate.

Fie trebuie să păstrăm informaţia despre abiturienţi şi obiecte care ei trebuie se le susţină. Vom încerca să memorăm informaţia necesară într-o singură relaţie “Abiturienţi_Facultăţi_Obiecte”:

111

Abiturienţi_Facultăţi_Obiecte AFOAbiturient A Facultate F Obiect O

Albu Matematică MatematicaAlbu Matematică InformaticaAlbu Fizică MatematicaAlbu Fizică FizicaPetcu Matematică MatematicaPetcu Matematică Informatica

La momentul actual avem informaţie că abiturientul Albu candidează la două facultăţi (de matematică şi de fizică), iar abiturientul Petcu – numai la facultatea de matematică. Din relaţie concludem că … Из анализа отношения AFO заключаем, что для каждого факультета имеются свои списки абитуриентов, и списки предметов, по которым нужно сдавать экзамены.

на математическом факультете нужно сдавать математику и информатику, а на физическом - математику и физику.

Кажется, что в отношении имеется аномалия обновления, связанная с тем, что дублируются фамилии абитуриентов, наименования факультетов и наименования предметов.

Однако эта аномалия легко устраняется стандартным способом - вынесением всех наименований в отдельные отношения, оставляя в исходном отношении только соответствующие номера:

Relaţia “Abiturienţi_Facultăţi_Obiecte” modificată AFOANUM FNUM ONUM

1 1 11 1 21 2 11 2 32 1 12 1 2

AbiturienţiANUM ANAME

1 Albu2 Petcu

FacultăţiFNUM FNAME

1 Matematică2 Fizică

112

ObiecteONUM ONAME

1 Matematica2 Informatica3 Fizica

Теперь каждое наименование встречается только в одном месте и его изменение не порождает аномалий.

И все-таки как в исходном, так и в модифицированном отношении имеются аномалии обновления, возникающие при попытке вставить или удалить кортежи.

Anomalia de inserţie. При попытке добавить в отношение "Абитуриенты-Факультеты-Предметы" новый кортеж, например (Ciobanu, Matematică, Matematica), мы обязаны добавить также и кортеж (Ciobanu, Matematică, Informatica), т.к. все абитуриенты математического факультета обязаны иметь один и тот же список сдаваемых предметов. Соответственно, при попытке вставить в модифицированное отношении кортеж (3, 1, 1), мы обязаны вставить в него также и кортеж (3, 1, 2).

Anomalia de eliminare. При попытке удалить кортеж (Albu, Matematică, Matematica), мы обязаны удалить также и кортеж (Albu, Matematică, Informatica) по той же самой причине.

Таким образом, вставка и удаление кортежей не может быть выполнена независимо от других кортежей отношения.

Кроме того, если мы удалим кортеж (Albu, Fizică, Matematica), а вместе с ним и кортеж (Albu, Fizică, Fizica), то будет потеряна информация о предметах, которые должны сдаваться на физическом факультете.

Декомпозиция отношения "Абитуриенты-Факультеты-Предметы" для устранения указанных аномалий не может быть выполнена на основе функциональных зависимостей, т.к. это отношение не содержит никаких функциональных зависимостей. Это отношение является полностью ключевым, т.е. ключом отношения является все множество атрибутов.

Şi totuşi este clar că careva interdependenţă între atribute există. Întradevăr facultatea determină o listă întreagă de obiecte – dependenţă multivalentă . Aceeaşi facultate determină şi o listă întreagă de abiturienţi – dependenţă multivalentă . Aceasta nouă interdependenţă se determină prin noţiune de dependenţă multivalentă.

Definiţie 1. Fie relaţia şi careva din atributele ei (mai concret, submulţimi neintersecte de atribute).Atributele (submulţimele de atribute) şi depind multivalent de atributul (să notează ) dacă şi numai dacă, din aceea că în relaţia se conţin tuplurile

şi , urmează că în să conţine şi tuplul .

113

Замечание. Меняя местами кортежи и в определении многозначной зависимости,

получим, что в отношении должен содержаться также и кортеж . Таким образом, атрибуты и , многозначно зависящие от , ведут себя "симметрично" по отношению к атрибуту .

În justeţa definiţiei uşor ne convingem dacă notăm , . Este clar că

există şi tuplurile şi .

Deci, în relaţia AFO există dependenţă multivalentă . Aceasta reiesă din aceea că

Словами это можно выразить так - для каждого факультета (для каждого значения из F) каждый поступающий на него абитуриент (значение из A) сдает один и тот же список предметов (набор значений из O), и для каждого факультета (для каждого значения из F) каждый сдаваемый на факультете экзамен (значение из O) сдается одним и тем же списком абитуриентов (набор значений из A). Именно наличие этой зависимости не позволяет независимо вставлять и удалять кортежи. Кортежи обязаны вставляться и удаляться одновременно целыми наборами cu seturi întregi. Замечание. Если в отношении R имеется не менее трех атрибутов X, Y, Z и есть функциональная зависимость X→Y, то есть и многозначная зависимость X→→Y│Z. Действительно, действуя формально в соответствии с определением многозначной зависимости, предположим, что в отношении R содержатся кортежи r1=(x,y,z1) и r2=(x,y1,z). Из функциональной зависимости X→Y следует, что y=y1. Но тогда кортеж r3=(x,y,z) в точности совпадает с кортежем r2=(x,y1,z) и, следовательно, содержится в отношении R. Следовательно имеет место многозначная зависимость X→→Y. Точно также в отношении R содержится кортеж r4=(x,y1,z1), который совпадает с кортежем r1. Следовательно имеет место и многозначная зависимость X→→Z. Таким образом, формально в отношении R имеет место многозначная зависимость X→→Y│Z.

Утверждение ???:

Se poate demonstra (Fagin R.) că în relaţia R(X,Y,Z) are loc dependenţa multivalentă dacă şi numai dacă are loc şi dependenţa multivalentă . Aşadar, dependenţele multivalente întotdeauna formează perechi interlegate între ele, deaceea ele ca de obocei se prezintă simbolic în formă .

Aşadar noţiunea de dependenţă multivalentă este o generalizare a noţiunei de dependenţă funcţională.

Definiţie 2. Dependenţă multivalentă să numeşte dependenţă multivalentă netrivială, dacă nu există dependenţe funcţionale şi .

В отношении "Абитуриенты-Факультеты-Предметы" имеется именно нетривиальная многозначная зависимость Факультет Абитуриент|Предмет. В силу нетривиальности этой зависимости мы не можем воспользоваться теоремой Хеза для

114

декомпозиции отношения. Однако Фейджином Р. (Fagin R.[52]) доказана следующая теорема:

Teorema lui Fagin. Fie - mulţimi neintersecte de atribute a relaţiei . Descompunerea relaţiei în proiecţii şi este o

descompunere fără pierderi dacă şi numai dacă în există dependenţă multivalentă .

Замечание. Если зависимость является тривиальной, т.е. существует одна из функциональных зависимостей X→Y или X→Z, то получаем теорему Хеза.

Definiţie 3. Relaţia este în forma normală patru FN4 dacă şi numai dacă este în forma normală Boyce-Codd FNBC şi nu conţine dependenţe multivalente netriviale.

Отношение "Абитуриенты-Факультеты-Предметы" находится в НФБК, но не в 4НФ. Согласно теореме Фейджина, это отношение можно без потерь декомпозировать на отношения:

FAF A

Matematică AlbuFizică AlbuMatematică Petcu

FOF O

Matematică MatematicaMatematică InformaticaFizică MatematicaFizică Fizica

В полученных отношениях устранены аномалии вставки и удаления, характерные для отношения "Абитуриенты-Факультеты-Предметы".

Observăm că în relaţiile obţinute au rămas numai atribute care formează cheia potenţială, dar în ele ca şi până acum nu sunt dependenţe funcţionale.

Заметим, что полученные отношения остались полностью ключевыми, и в них по-прежнему нет функциональных зависимостей.

Отношения с нетривиальными многозначными зависимостями возникают, как правило, в результате естественного соединения двух отношений по общему полю, которое не является ключевым ни в одном из отношений. Фактически это приводит к попытке хранить в одном отношении информацию о двух независимых сущностях. В качестве еще одного примера можно привести ситуацию, когда сотрудник может иметь много работ и

115

много детей. Хранение информации о работах и детях в одном отношении приводит к возникновению нетривиальной многозначной зависимости Работник Работа|Дети.

8.2. Forma normală cinci FN5

Dependenţele funcţionale şi cele multivalente ne permit să supunem relaţia dată descompunerii fără pierderi pe două proiecţii. Anume, avem:

Din R(X,Y,Z), X→Y => R1=R[X,Y], R2=R[X,Z] – descompunere fără pierderi (Teorema lui Heath);

Din R(X,Y,Z), => R1=R[X,Y], R2=R[X,Z] – descompunere fără pierderi (Teorema lui Fagin);

Важно заметить здесь, что разложения R1 и R2 в обеих теоремах соответствуют общему принципу алгоритма нормализации.

Însă pot fi aduse exemple de relaţii pentru care nu există nici o descompunere fără pierderi pe două proiecţii, dar care pot fi supuse descompunerii fără pierderi pe trei sau mai multe proiecţii. Sau pentru care există aşa numită n-descompunere fără pierderi.

Aşadar, afirmăm aici că au loc cazuri când relaţia dată poate fi supusă descompunerii fără pierderi pe n proiecţii, dar pentru care nu există nici o descompunere fără pierderi pe un număr de proiecţii mai mic n-1.

Pentru a demonstra această afirmaţie aducem un exemplu.

Пример 3. Рассмотрим следующее отношение R:

X Y Z1 1 21 2 12 1 11 1 1

Таблица 14 Отношение R

Всевозможные проекции отношения R, включающие по два атрибута, имеют вид:

X Y1 11 22 1

Таблица 15 Проекция R1=R[X,Y]

116

X Z1 21 12 1

Таблица 16 Проекция R2=R[X,Z]

Y Z1 22 11 1

Таблица 17 Проекция R3=R[Y,Z]

Как легко заметить, отношение R не восстанавливается ни по одному из попарных соединений R1 JOIN R2, R1 JOIN R3 или R2 JOIN R3. Действительно, соединение R1 JOIN R2 имеет вид:

X Y Z1 1 21 1 11 2 21 2 12 1 1

Таблица 18 R1 JOIN R2

Черным цветом выделен лишний кортеж, отсутствующий в отношении R. Аналогично (в силу соображений симметрии) и другие попарные соединения не восстанавливают отношения R (отношения R1, R2, R3 отличаются друг от друга лишь перестановкой строк). Однако отношение R восстанавливается соединением всех трех проекций: R1 JOIN R2 JOIN R3 =R.

Это говорит о том, что между атрибутами этого отношения также имеется некоторая зависимость, но эта зависимость не является ни функциональной, ни многозначной зависимостью.

Новую зависимость принято называть зависимостью соединения.

Noua dependenţă să numeşte dependenţă de joncţiune.

Определение 5. Пусть R является отношением, а A, B, ..., Z - произвольными (возможно пересекающимися) подмножествами множества атрибутов отношения R. Тогда отношение R удовлетворяет зависимости соединения

тогда и только тогда, когда оно равносильно соединению всех своих проекций с подмножествами атрибутов A, B, …, Z, т.е. R=R[A] JOIN R[B] JOIN ... JOIN R[Z].

117

Можно предположить, что отношение R в примере 3 удовлетворяет следующей зависимости соединения:

*(XY, XZ, YZ).

Утверждать, что это именно так мы пока не можем, т.к. определение зависимости соединения должно выполняться для любого состояния отношения R, а не только для состояния, приведенного в примере.

Покажем, что зависимость соединения является обобщением понятия многозначной зависимости. Действительно, согласно теореме Фейджина, отношение может быть декомпозировано без потерь на проекции

и тогда и только тогда, когда имеется многозначная зависимость . Согласно определению зависимости соединения, теорема Фейджина может быть переформулирована следующим образом:

Теорема Фейджина (другая формулировка). Отношение удовлетворяет зависимости соединения тогда и только тогда, когда имеется многозначная зависимость .

Т.к. формулировки теоремы Фейджина на основе многозначной зависимости и зависимости соединения эквивалентны (являются взаимно обратными???), то последнюю формулировку можно взять в качестве определения многозначной зависимости. Таким образом, многозначная зависимость является частным случаем зависимости соединения, т.е., если в отношении имеется многозначная зависимость, то имеется и зависимость соединения. Обратное, конечно, неверно.

Определение 6. Зависимость соединения называется нетривиальной зависимостью соединения, если выполняется одно из двух условий:

Одно из множеств атрибутов A, B, ..., Z не содержит потенциального ключа отношения R, либо

Ни одно из множеств атрибутов A, B, ..., Z не совпадает со всем множеством атрибутов отношения R.

По поводу первого условия, вспомним разложение без потерь согласно теоремы Фейджина

R(X,Y,Z), => R1=R[X,Z], R2=R[X,Y],в котором X содержится и в R1 и в R2 и формально играет роль потенциального (?) ключа. Второе условие тривиально. Неверно!!! Нигде не утверждается, что X потенциальный ключ. Нужно сказать по-другому: если все множества атрибутов A, B, ..., Z содержат потенциальный ключ отношения R, то зависимость соединения будет тривиальной, ибо декомпозиция на ее основе осуществляется на самом деле на основе функциональной зависимости от ключа. Т.е., ничего нового, вспомним правило NFBC. (Чтобы сказанное здесь имело большую убедительность следует в соответствующем месте курса (где? в NFBC? )

118

сказать, что формально можно разложить данное отношение на основе только его потенциального ключа. Только, что это даст? Va fi o descompunere trivială care nu va îmbunătăţi calitatea schemei. De dat această remarcă în concluzii referitor la normalizare consecutivă cu scopul eliminării anomaliilor. Sau în teorema lui Heath.)

Для удобства работы сформулируем это определение так же и в отрицательной форме: Определение 7. Зависимость соединения называется тривиальной зависимостью соединения, если выполняется одно из условий:

Либо все множества атрибутов A, B, ..., Z содержат потенциальный ключ отношения R.

Либо одно из множеств атрибутов A, B, ..., Z совпадает со всем множеством атрибутов отношения R.

Определение 8. Отношение R находится в пятой нормальной форме (5НФ) тогда и только тогда, когда любая имеющаяся зависимость соединения является тривиальной.

Определения 5НФ может стать более понятным, если сформулировать его в отрицательной форме:

Определение 9. Отношение R не находится в 5НФ, если в отношении найдется нетривиальная зависимость соединения.

Последнее определение говорить о том, что при наличии в отношении R нетривиальной зависимость, его нужно раскладывать для исключения аномалий.

Возвращаясь к примеру 3, становится понятно, что не зная ничего о том, какие потенциальные ключи имеются в отношении и как взаимосвязаны атрибуты, нельзя делать выводы о том, находится ли данное отношение в 5НФ (как, впрочем, и в других нормальных формах). По данному конкретному примеру можно только предположить, что отношение в примере 3 не находится в 5НФ. Предположим, что анализ предметной области позволил выявить следующие зависимости атрибутов в отношении R: (i) Отношение R является полностью ключевым (т.е. потенциальным ключом отношения является все множество атрибутов). (ii) Имеется следующая зависимость (довольно странная, с практической точки зрения): если в отношении R содержатся кортежи , и , то отсюда следует, что в отношении R содержится также и кортеж . Утверждение. Докажем, что при наличии ограничений (i) и (ii), отношение находится в 4НФ, но не в 5НФ. Доказательство. Покажем, что отношение R находится в 4НФ. Согласно определению 4НФ, необходимо показать, что отношение находится в НФБК и не содержит нетривиальных многозначных зависимостей. Т.к. отношение является полностью ключевым, то оно автоматически находится в НФБК. Если бы в отношении имелась многозначная зависимость (необязательно нетривиальная), то, согласно теореме Фейджина, отношение можно было бы декомпозировать без потерь на две проекции. Но пример 3 показывает, что таких декомпозиций нет (здесь мы воспользовались тем, что для доказательства возможности декомпозиции необходимо доказать ее для всех возможных

119

состояний отношения, а для доказательства невозможности достаточно привести один контрпример). Поэтому в отношении нет никаких многозначных зависимостей. Покажем, что отношение не находится в 5НФ. Для этого нужно привести пример нетривиальной зависимости соединения. Естественным кандидатом на нее является

. Если это действительно зависимость соединения, то она нетривиальна. Действительно, ни одно из множеств атрибутов , и не совпадает с множеством всех атрибутов отношения R и не содержит потенциального ключа. Но является ли такая декомпозиция именно зависимостью соединения? Для этого нужно показать, что декомпозиция на три проекции , и является декомпозицией без потерь для любого состояния отношения R (именно здесь содержится ключевая тонкость, обычно пропускаемая при анализе конкретного состояния отношения R в примере 3, и именно здесь нам понадобятся знания о предметной области, выраженные в утверждении (ii)).

Как и в предыдущих доказательствах, нужно доказать, что для любого состояния отношения .

Включение доказывается как в теореме Хеза. Такое включение выполняется всегда для любой декомпозиции отношения .

Докажем включение .

Пусть кортеж . Это означает, что в проекции

содержится кортеж , в проекции содержится кортеж , а в

проекции содержится кортеж . По определению проекции, найдутся

такие значения , , атрибутов , и соответственно, что отношение содержит

кортежи , и . Но тогда по условию (ii) в отношении

содержится также и кортеж . Этим доказано необходимое включение. Утверждение доказано.

Необходимое заключение к нормальным формам:

Нормальная форма NF5 является окончательной нормальной формой по отношению к операциям проекции и естественного соединения отношений. Поэтому она еще называется проекционно-соединительной нормальной формой (Дейт, стр. 335).

Общие выводы о нормальных формах:

1. Все три типа зависимостей между атрибутами отношения позволяют избавиться от аномалий актуализации с помощью разбиения на проекции без потерь (операции проекции и соединения);

2. При нормализации мы от зависимостей (FD, MV, S) между атрибутами в одном отношении переходим к ограничениям первичного и внешнего ключей для двух отношений. Тем самым мы улучшаем схему базы данных. Теперь СУБД сможет автоматически контролировать ограничения структурной целостности.

120

Продолжение алгоритма нормализации (приведение к 5НФ)В предыдущей главе был описан алгоритм нормализации как алгоритм приведения отношений к 3НФ. Теперь мы можем продолжить этот алгоритм, доведя его до алгоритма приведения к 5НФ. Шаг 4 (Приведение к НФБК). Если имеются отношения, содержащие несколько потенциальных ключей, то необходимо проверить, имеются ли функциональные зависимости, детерминанты которых не являются потенциальными ключами. Если такие функциональные зависимости имеются, то необходимо провести дальнейшую декомпозицию отношений. Те атрибуты, которые зависят от детерминантов, не являющихся потенциальными ключами выносятся в отдельное отношение вместе с детерминантами. Шаг 5 (Приведение к 4НФ). Если в отношениях обнаружены нетривиальные многозначные зависимости, то необходимо провести декомпозицию для исключения таких зависимостей. Шаг 5 (Приведение к 5НФ). Если в отношениях обнаружены нетривиальные зависимости соединения, то необходимо провести декомпозицию для исключения и таких зависимостей.

Выводы

Обобщением 3НФ на случай, когда отношение имеет более одного потенциального ключа, является нормальная форма Бойса-Кодда. Отношение R находится в нормальной форме Бойса-Кодда (НФБК) тогда и только тогда, когда детерминанты всех функциональных зависимостей являются потенциальными ключами. Дальнейшего разложения не требуется.Нормализация отношений вплоть до нормальной формы Бойса-Кодда основывалась на понятии функциональной зависимости и теореме Хиза, гарантировавшей, что декомпозиция будет происходить без потерь информации. Дальнейшая нормализация связана уже с обобщением понятия функциональной зависимости. Атрибуты (множества атрибутов) Y и Z многозначно зависят от X, ( ), тогда и только тогда, когда из того, что в отношении R содержатся кортежи и

следует, что в отношении R содержится также и кортеж . Корректность дальнейшей декомпозиции основывается на теореме Фейджина, которая говорит о том, что декомпозиция отношения на две проекции является декомпозицией без потерь тогда и только тогда, когда в отношении имеется некоторая многозначная зависимость. Если в отношении имеется функциональная зависимость, то автоматически имеется и тривиальная многозначная зависимость, определяемая этой функциональной зависимостью. (на самом деле – однозначная зависимость)Многозначная зависимость называется нетривиальной многозначной зависимостью, если не существует функциональных зависимостей и . Отношение R находится в четвертой нормальной форме (4НФ) тогда и только тогда, когда отношение находится в НФБК и не содержит нетривиальных многозначных зависимостей. Имеют место зависимости специального вида, когда отношение не может быть подвергнуто декомпозиции без потерь на две проекции, но может быть декомпозировано на большее число проекций. Такие зависимости называются зависимостями соединения и являются обобщением понятия многозначной зависимости. Отношение R находится в пятой нормальной форме (5НФ) тогда и только тогда, когда любая имеющаяся зависимость соединения является тривиальной.

121

9. Axiomele lui Armstrong. Clauze de deductie Axiomele de deducţie a lui Maier. Axiomele Armstrong. Teorema despre completitudinea

axiomelor Armstrong.

Un set de axiome care precizeazã modul în care, pornind de la o mulţime de dependenţe funcţionale date, se pot obţine noi dependenţe funcţionale.

Cum s-a demonstrat mai sus formele normale FN1-FN3, FNBC ale unei relaţii utilizează o noţiune foarte importantă, şi anume dependenţa funcţională între diverse submulţimi de atribute. Stabilirea dependenţelor funcţionale este o sarcină a administratorului de date (a proiectantului) şi depinde de semnificaţia (semantica) datelor ce se memorează în relaţie. Operaţiile de actualizare a datelor din relaţie (înserare, ştergere, modificare) nu trebuie să încalce dependenţele funcţionale existente dintre datele concrete (trebuie să păstreze consistenţa datelor).

Dependenţa funcţională este considerată ca o proprietate (restricţie) pe care baza de date trebuie s-o îndeplinească pe perioada existenţei acesteia: se adaugă elemente în relaţie numai dacă dependenţa funcţională este verificată, sau se poate cere ca anumite dependenţe funcţionale să nu apară (?). Dacă într-o bază de date există dependenţe funcţionale, atunci poate să apară o inconsistenţă a bazei de date, deci este necesară eliminarea acestora (???).

În procedurele de normalizare scopul principal a fost minimizarea redundanţei datelor. Am văzut că redundanţa este strâns (univoc) legată de schema relaţională, mai concret de mulţimea dependenţelor funcţionale. Scopul a fost atins prin eliminarea consecutivă a dependenţelor nedorite din punct de vedere a restricţiilor formelor normale inferioare FN1-FNBC.

Avantajul normalizării însă constă nu numai în minimizarea sau eliminarea redundanţei datelor. Mai important este faptul că normalizarea se reduce la transformarea dependenţelor funcţionale dintre atribute în constrângerile (restricţiile) de cheie. Întradevăr, fie avem scema R(A,B,C,D,E,F) cu cheia {A,B,C} şi care conţine dependenţa funcţională {A,B}→{E,F}. În procesul de normalizare noi am descompus schema iniţială R în două scheme: R´(A,B,C,D) şi R2(A,B,E,F). Atributele A, B în relaţia R´ formează cheia externă.

Majoritatea SGBD-urilor nu susţin restricţiile de dependenţe funcţionale dintre atribute (DF atributare), dar toate SGBD-urile relaţionale susţin controlul restricţiilor de cheie şi restricţiilor referenţiale. Acest moment este foarte important, deoarece utilizatorii aplicaţiilor cu baze de date trebuie să fie siguri că toate datele în bază satisfac dependenţele funcţionale în orice stare a bazei de date.

122

Deci, putem conclude: transformarea dependenţelor funcţionale în restricţii de cheie substanţial îmbunătăţăşte calitatea schemei relaţiei, şi anume, din două puncte de vedere:

Minimizarea sau eliminarea totală a redundanţei datelor; Asigură susţinerea controlului restricţiilor de integritate din partea SGBD.

Proiectanţii aplicaţiilor cu baze de date trebuie cât mai precis să stabilească toate (de dorit) dependenţele funcţionale reieşind din semantica (sensul) datelor. Nu întotdeauna însă este evidentă rezolvarea acestei probleme. Cauza adesea ori constă în aceea că noi pur şi simplu nu am înţeles bine sensul. Se pune întrebarea dacă nu se poate stabili alte dependenţe funcţionale pornind de la acelea precis stabilite.

Răspunsul este pozitiv din două puncte de vedere: Este evident că mulţimea de dependenţe valide în R este finită, fiindcă

finită este schema R; Dependenţele funcţionale sunt afirmaţii logice şi trebuie se supună regulilor

de deducţie logică.

Aşadar, dependenţele funcţionale prezintă careva afirmaţii logice pe mulţimi şi trebuie se satisfacă careva expresii logice. De fapt operaţiilor algebrei pe mulţimi. Deaceea pot fi obţinute regule în care, pornind de la o mulţime de dependenţe funcţionale date, se pot obţine noi dependenţe funcţionale.

Întradevăr există un set de reguli de deducţie care precizeazã modul în care, pornind de la o mulţime de dependenţe funcţionale date, se pot obţine noi dependenţe funcţionale. În acest caz apare problema importantă de a găsi toate dependenţele funcţionale posibile – aşa numită închiderea mulţimii de dependenţe funcţionale.

Fie dată o relaţie şi o mulţime de dependenţe funcţionale ( dependenţe). Atunci, determinarea închiderii mulţimii de dependenţe funcţionale constă în următorul:

Pentru mulţimea de dependenţe funcţionale se cere determinarea mulţimii , numită închiderea mulţimii , şi care conţine toate dependenţele funcţionale obţinute logic din .

Se poate spune că mulţimea de dependenţe funcţionale implică logic o dependenţă funcţională dacă pentru orice relaţie în care este îndeplinită rezultă că şi este îndeplinită.

Pentru determinarea închiderii se pot aplica repetat următoarele trei reguli (axiomele lui W. Armstrong, 1974):

123

1. Reflexivitatea. Dacă , atunci .2. Extinderea (mărirea, augmentarea). Dacă , atunci .3. Tranzitivitatea. Dacă şi , atunci .

Aceste reguli sunt logice (determină numai dependenţe funcţionale din închiderea ) şi complete (aplicaţiiile repetate determină toate dependenţele funcţionale din

închiderea ). Plecând de la aceste reguli se poate demonstra că şi următoarele reguli adiţionale sunt adevărate:

4. Reuniunea (aditivitatea). Dacă şi , atunci .5. Descompunerea. Dacă , atunci .6. Pseudotranzitivitatea. Dacă şi , atunci .

Acestea şase regule se numesc axiome sau clauze de deducţie (axiomele de deducţie a lui Maier ?).

Aşadar, axiomele (clauzele) de deducţie reprezintă afirmaţia: dacă relaţia satisface careva dependenţe, atunci ea trebuie să satisfacă şi alte dependenţe.

Ca de obicei se folosesc acestea şase regule de deducţie (clauze de deducţie) cu ajutorul cărora se obţin în mod deductiv toate dependenţele funcţionale. Fie relaţia R, definită pe mulţimea de atribute A şi fie W, X, Y, Z A. Pentru simplicitate notăm reuniunile mulţimilor ca: şi aşa mai departe. Atunci au loc regulele (axiomele) de deducţie:

R1. Regula reflexivităţii. Dacă , atunci .O dependenţă este trivială, dacă . Mulţimea, evident, determină

toate submulţimile ei.

R2. Regula extinderii (măririi, augmentării, incrementării). Dacă , atunci pentru orice .

O formă mai generală. Dacă şi , atunci . Din , deaceia avem o formă particulară a acestei regulă: din şi .

R3. Regula tranzitivităţii. Dacă şi , atunci .

R4. Regula aditivităţii (de uniune). Dacă şi , atunci . Consecinţa regulei R2: XX→YZ sau X→YZ, fiind că XX=X după definiţie.

R5. Regula proiectivităţii (de descompunere, decompoziţie). Dacă , atunci (şi , evident). Este inversă a regulei R4.

R6. Regula pseudotranzitivităţii. Dacă şi , atunci .

124

Primele trei regule se numesc axiomele lui Armstrong (William W. Armstrong, 1974). Armstrong a demonstrat că cu ajutorul primelor trei regule pot fi deduse regulele 4, 5 şi 6.

Regula 1 de reflexitate înseamnă că mulţimea de atribute în mod funcţional determină ori şi ce submulţime proprie .

Regula 2 de augmentare (mărire, alipire) înseamnă că pot fi adăugate atribute la ambele părţi (dreapta şi stânga) a dependenţei funcţionale.

Regula 3 de tranzitivitate ...

Regula 4 de reuniune permite combinarea a două dependenţe funcţionale cu aceeaşi parte stângă.

Regula 5 de descompunere permite eliminarea atributelor din partea dreaptă a dependenţei funcţionale.

Regula 6 de pseudotranzitivitate este o îmbinare a regulelor de augmentare (alipire, extindere) şi tranzitivitate; după regula de extindere – dacă , atunci

şi dacă are loc şi , atunci conform regulei 3 de tranzitivitate avem .

Axiomele de deducţie ne permit deci să stabilim în mod formal toate dependenţele funcţionale în relaţia dată. Dat fiind faptul că regulile R1-R6 se deduc din axiomele Armstrong (AA), vom spune că şi axiomele Armstrong constituie o mulţime de reguli închisă şi completă.

Definiţie 1. Vom numi închiderea a mulţimei de dependenţe funcţionale cea mai mare mulţime de dependenţe , care poate fi obţinută ca rezultatul aplicării multiple a clauzelor de deducţie pe mulţimea iniţială a dependenţelor funcţionale.

În altă formă:Definiţia 2. Închiderea unei mulţimi de dependenţe funcţionale F+ reprezintă

mulţimea tuturor dependenţelor funcţionale care se pot deriva din mulţimea F, aplicând axiomele Armstrong. Este clar că F+=(F+)+.

Definiţia 3. Două mulţimi de dependenţe funcţionale F şi G se numesc echivalente, notat cu , dacă F+=G+. Vom mai spune în acest caz că F acoperă G (sau G acoperă F).

Dacă , adica F+=G+, atunci orice dependenţă X→Y ce urmează logic din F urmează şi din G.

125

Exemplu: mulţimea F={A→B, B→C, A→C, AB→C, A→BC} se deduce din mulţimea F={A→B, B→C}, deci mulţimea G acoperă mulţimea F (G este echivalentă cu F sau F G).Utilizarea mulţimei F este mai preferată: mai puţin control la modificare. Reiesă că trebuie se tindem spre minimumul dependenţelor, acesta favorizeză consistenţa şi integritatea.

Închiderea a mulţimii de dependenţe determină toate dependenţele funcţionale, care pot fi deduse din dependenţele, declarate iniţial ca o parte a schemei relaţiei date. Închiderea a dependenţelor funcţionale se foloseşte în procesele de normalizare cu scopul înbunătăţirii calităţii schemei relaţiei, în primul rând pentru a elimina redundanţa datelor.

Замыкание (închiderea) используется для оценки возможностей улучшения качества схемы, особенно в отношении избыточности данных и простоты обслуживания.

Aici trebuie de redactat şi adăugat despre acoperire minimală.

9.1. Determinarea cheilor potenţiale din dependenţele funcţionale

Axiomele de deducţie – o metodă alternativă de determinare a cheilor relaţiilor (alternative, potenţiale). Determinarea formală a supercheiei relaţiei:

Fie dată relaţia cu schema . Dacă dependenţa funcţională conţine toate atributele schemei, atunci este supercheie.

9.2. Exemplu formal

În calitate de exemplu a utilizării în practică a axiomelor de deducţie vom considera un proces de normalizare a schemei cu atribute care nu au un sens concret. Pornind de la o mulţime de dependenţe funcţionale vom stabili cheile schemei bazei de date şi vom efectua normalizarea.

Considerăm relaţia R=R(A, B, C, D, E, F, G, H). În raport cu schema R au loc dependenţele funcţionale d1, d2, d3, d4:

d1: A→{B, C, D}d2: B→Cd3: E→{F, G, H}d4: G→{H, E}

În formă grafică (?):

126

A B C D E F G H

Din dependenţele d1-d4 putem obţine altele trei d5, d6, d7:

d5: {A, E}→{B, C, D, F, G, H} (regula R2 extinderii)d6: G→{E, F, H} (regulile R5, R3, R4)d7: {A,G}→{B, C, D, E, F, H} (regula R2 extinderii)

Dependenţa d6 se obţine din d3, d4: G→E, E→{F, H} G→{F, H}; G→E, G→{F, H} G→{E, F, H}.

În baza dependenţelor d5-d7 concludem că sunt două cheie: {A, E} şi {A, G}. În mod arbitrar, alegem în calitate de cheie primară mulţimea {A, E}. Dar nu uităm că şi G este componenta cheii primare.

Analizăm dependenţele obţinute:1. Dependenţele de A, E şi G (d1, d3, d4, d6) încalcă (nu satisfac) regula FN2;2. Dependenţele E→G şi G→E (d3, d4, d6) nu încalcă regula FN2, deoarece

determinanţii lor E şi G sunt atribute cheie.Putem elimina G şi E din părţile drepte al d3, d4, şi d6. După acest pas regula FN2 o încalcă dependenţele:

d1: A→{B, C, D}d3´: E→{F, H}d4´: G→Hd6´: G→{F, H}

Pentru prima descompunere (proiecţie) putem alege oricare din aceste dependenţe, spre exemplu d1. Obţinem relaţii:

R1=R1(A, E, G, F, H), restul din RR2=R2(A, B, C, D) relaţie nouă

Dependenţele d3´, d4´ şi d6´ încalcă regula FN2 în relaţia R1. Descompunerea după d3´ ne aduce la relaţiile:

R1´= R1´(A, E, G), restul din R1R2=R2(A, B, C, D),R3=R3(E, F, H) relaţie nouă

Schemele obţinute R1´, R2, R3 nu mai încalcă regula FN2. Descompunerea după d3´ ne a eliminat şi încălcările FN2 în d4´ şi d6´.

Dependenţa d2 încalcă regula FN3 în relaţia R2. Descompunerea R2 după dependenţa d2 ne aduce la schema finală a bazei de date în forma normală FNBC:

R1´= R1´(A, E, G),

127

R2´=R2´ (A, B, D), restul din R2R3=R3(E, F, H),R4=R4(B, C) relaţie nouă

Acum putem reprezenta această schemă şi în formă de ER diagramă.

Observaţie. Cum am dedus, folosind clauzele de deducţie în relaţia iniţială sunt două cheii: {A, E} şi {A, G}. Deci, avem cazul ce ţine de forma normală FNBC. În rezultatul normalizării am obţinut însă că numai în relaţiile şi toţi determinanţii a dependenţelor funcţionale sunt cheile relaţiei , aşa cum cere regula FNBC. Determinantul dependenţei funcţionale în relaţia nu este atributul cheie a relaţiei . Acest rezultat se datoreşte faptului că relaţia iniţiale nu era în FN3, anume în ea era dependenţă funcţională dintre atribute noncheie B→C. Această dependenţă şi a fost plasată într-o relaţie separată .

128

R4

BC

R2´

ABD

R1´

AEG

R3

EFH

10. ER-модель данных. Элементы модели «сущность-связь»

В основополанующей статье Е.Ф.Кодда утверждается, что "реляционная модель предоставляет средства описания данных на основе только их естественной структуры, т.е. без потребности введения какой-либо дополнительной структуры для целей машинного представления". Другими словами, представление данных не зависит от способа их физической организации. Это обеспечивается за счет использования математической теории отношений (само название "реляционная" происходит от английского relation - "отношение"), восходящей к теории множеств.

Таким образом, реляционная модель данных может быть представлена в терминах предметной области или на уровне предметной области без относительно к тому, как эта модель будет реализована на строгом логическом или алгоритмическом уровне. Основой такого представления служит тот факт, что предметная область может быть описана набором сущностей, связанных между собой процессами или состояниями отношения.

Сущности – это объекты самой общей произвольной природы. Два объекта могут быть связаны между собой технологическими или производственными процессами или быть в определенных состояниях отношения.

Процесс – динамически изменяемый во времени, бесконечный набор элементарных операций, связывающих экземпляры двух сущностей в характерном для данной предметной области технологическом или производственном процессе. Например, объекты Поставщик и Товар связаны процессом поставки товаров.

Состояние – статическое во времени состояние отношения между экземплярами двух сущностей. Например, объкты Сотрудник и Ребенок связаны состоянием отношения быть родителем.

Представление реляционной модели в терминах предметной области носит название ER-модели данных или модели сущность-связь (ER – Entity-Relationship). Отличительной особенностью такой модели является то, что она представляется соответственно в виде ER-диаграмм или диаграмм сущность-связь. ER-модель обеспечивает наиболее естественный для человека способ сбора и представления той информации, которую предполагается хранить в создаваемой базе данных.

Первый вариант модели сущность-связь был предложен в 1976 г. Питером Пин-Шэн Ченом. В дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация Мартина, нотация IDEF1X, нотация

129

Баркера и др.). Кроме того, различные программные средства, реализующие одну и ту же нотацию, могут отличаться своими возможностями. По сути, все варианты диаграмм сущность-связь исходят из одной идеи - рисунок всегда нагляднее текстового описания. Все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями.

Ниже мы опишем представление модели сущность-связь близкое к нотации Баркера, как довольно легкой в понимании основных идей. Данный пункт является скорее иллюстрацией методов моделирования с помощью ER-диаграмм, чем полноценным введением в эту область.

10.1. Элементы модели "сущность-связь"

(Основные понятия ER-диаграмм)

Определение 1. Сущность - это класс однотипных объектов, информация о которых должна быть учтена в модели. Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. Примерами сущностей могут быть такие классы объектов как "Поставщик", "Сотрудник", "Накладная". Каждая сущность в модели изображается в виде прямоугольника с наименованием:

Определение 2. Экземпляр сущности - это конкретный представитель данной сущности. Например, представителем сущности "Сотрудник" может быть "Сотрудник Иванов". Экземпляры сущностей должны быть различимы, т.е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности. Определение 3. Атрибут сущности - это именованная характеристика, являющаяся некоторым свойством сущности. Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными). Примерами атрибутов сущности "Сотрудник" могут быть такие атрибуты как "Табельный номер", "Фамилия", "Имя", "Отчество", "Должность", "Зарплата" и т.п.

130

Рис. 1

Атрибуты изображаются в пределах прямоугольника, определяющего сущность: Определение 4. Ключ сущности - это неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности. Неизбыточность заключается в том, что удаление любого атрибута из ключа нарушается его уникальность. Сущность может иметь несколько различных ключей. Ключевые атрибуты изображаются на диаграмме подчеркиванием: Определение 5. Связь - это некоторая ассоциация между двумя сущностями. Одна сущность может быть связана с другой сущностью или сама с собою. Связи позволяют по одной сущности находить другие сущности, связанные с нею. Например, связи между сущностями могут выражаться следующими

фразами - "СОТРУДНИК может иметь несколько ДЕТЕЙ", "каждый СОТРУДНИК обязан числиться ровно в одном ОТДЕЛЕ". Графически связь изображается линией, соединяющей две сущности:

131

Рис. 2

Каждая связь имеет два конца и одно или два наименования. Наименование обычно выражается в неопределенной глагольной форме: "иметь", "принадлежать" и т.п. Каждое из наименований относится к своему концу связи. Иногда наименования не пишутся ввиду их очевидности. Каждая связь может иметь один из следующих типов связи:

Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой). Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две. Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны "один") называется родительской, правая (со стороны "много") - дочерней. Характерный пример такой связи приведен на Рис. 4. Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи много-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-многим путем создания промежуточной сущности. Каждая связь может иметь одну из двух модальностей связи:

Модальность "может" означает, что экземпляр одной сущности может быть связан с одним или несколькими экземплярами другой сущности, а может быть и не связан ни с одним экземпляром.

132

Рис. 6

Рис. 5

Рис. 4

Модальность "должен" означает, что экземпляр одной сущности обязан быть связан не менее чем с одним экземпляром другой сущности. Связь может иметь разную модальность с разных концов (как на Рис. 4). Описанный графический синтаксис позволяет однозначно читать диаграммы, пользуясь следующей схемой построения фраз: <Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>. Каждая связь может быть прочитана как слева направо, так и справа налево. Связь на Рис. 4 читается так: Слева направо: "каждый сотрудник может иметь несколько детей". Справа налево: "Каждый ребенок обязан принадлежать ровно одному сотруднику".

10.2. Пример семантического моделирования с помощью ER-диаграмм(Exemplu de elaborare a unui ER-model simplu)

Здесь мы остановимся на, основанном на ER-модели данных, так называемом, семантическом методе моделирования, как наиболее интуитивно понятном и естественном методе моделирования структуры данных. Естественность метода является следствием существования тесного (взаимно однозначного?) соответствия между сущностями в предметной области и связами между ними с одной стороны и моделирующими их отношениями и связями между ними в реляционной модели с другой.

Семантическое моделирование представляет собой моделирование структуры данных, опираясь на смысл этих данных. В качестве инструмента моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship). Семантическое моделирование отвечает следующему обобщенному алгоритму разработки системы базы данных: Анализ предметной области. Выявление всех сущностей и их

взаимосвязей в бизнесс-процессах. Установление целей и задач разработки системы базы данных (приложения);

Разработка графического представления модели данной предметной области и закономерностей ее функционирования (разработка ER-модели данных);

Создание с помощью конкретной СУБД физической системы базы данных на основе ER-модели данных.

Этап обследования системы. Основная задача обследования - оценка реального объема проекта, его целей и задач, а также получение определений сущностей и функций на высоком уровне.

Этап анализа предполагает подробное исследование бизнес-процессов (функций, определенных на этапе выбора стратегии) и информации, необходимой для их выполнения (сущностей, их атрибутов и связей (отношений)). На этом этапе создается информационная модель, а на следующем за ним этапе проектирования - модель данных.

133

10.3. Пример разработки простой ER-модели

При разработке ER-моделей мы должны получить следующую информацию о предметной области:

1. Список сущностей предметной области.

2. Список атрибутов сущностей.

3. Описание взаимосвязей между сущностями.

ER-диаграммы удобны тем, что процесс выделения сущностей, атрибутов и связей является итерационным. Разработав первый приближенный вариант диаграмм, мы уточняем их, опрашивая экспертов предметной области. При этом документацией, в которой фиксируются результаты бесед, являются сами ER-диаграммы. Предположим, что перед нами стоит задача разработать информационную систему по заказу некоторой оптовой торговой фирмы. В первую очередь мы должны изучить предметную область и процессы, происходящие в ней. Для этого мы опрашиваем сотрудников фирмы, читаем документацию, изучаем формы входных и выходных документов (заказов, накладных и т.п.). Например, в ходе беседы с менеджером (менеджерами) по закупкам и продажам, выяснилось, что он (менеджер) считает, что проектируемая система должна выполнять следующие действия:

Хранить информацию о поставщиках, покупателях и товарах.

Печатать накладные на отпущенные товары.

Следить за наличием товаров на складе.

Выделим все существительные в этих предложениях - это будут потенциальные кандидаты на сущности и атрибуты, и проанализируем их (непонятные термины будем выделять знаком вопроса):

Поставщик, покупатель и товар – явные кандидаты на сущности.

Накладная - явный кандидат на сущность.

(?)Склад - а вообще, сколько складов имеет фирма? Если несколько, то это будет кандидатом на новую сущность.

(?)Наличие товара – это, скорее всего, атрибут, но атрибут какой сущности?

Сразу возникает очевидная связь между сущностями – "покупатели могут покупать много товаров" и "товары могут продаваться многим покупателям". Первый вариант диаграммы выглядит так:

134Рис. 7

Задав дополнительные вопросы менеджеру, мы выяснили, что фирма имеет несколько складов. Причем, каждый товар может храниться на нескольких складах и быть проданным с любого склада. Куда поместить сущности "Накладная" и "Склад" и с чем их связать? Спросим себя, как связаны эти сущности между собой и с сущностями "Покупатель" и "Товар"? Покупатели покупают товары, получая при этом накладные, в которые внесены данные о количестве и цене купленного товара. Каждый покупатель может получить несколько накладных. Каждая накладная обязана выписываться на одного покупателя. Каждая накладная обязана содержать несколько товаров (не бывает пустых накладных). Каждый товар, в свою очередь, может быть продан нескольким покупателям через несколько накладных. Кроме того, каждая накладная должна быть

выписана с определенного склада, и с любого склада может быть выписано много накладных. Таким образом, после уточнения, диаграмма будет выглядеть следующим образом:

Пора подумать об атрибутах сущностей. Беседуя с сотрудниками фирмы, мы выяснили следующее:

Каждый покупатель является юридическим лицом и имеет наименование, адрес, банковские реквизиты.

Каждый товар имеет наименование, цену, а также характеризуется единицами измерения.

Каждая накладная имеет уникальный номер, дату выписки, список товаров с количествами и ценами, а также общую сумму накладной. Накладная выписывается с определенного склада и на определенного покупателя.

Каждый склад имеет свое наименование.

135

Рис. 8

Снова выпишем все существительные, которые будут потенциальными атрибутами, и проанализируем их:

Юридическое лицо - термин риторический, мы не работаем с физическими лицами. Не обращаем внимания.

Наименование покупателя - явная характеристика покупателя.

Адрес - явная характеристика покупателя.

Банковские реквизиты - явная характеристика покупателя.

Наименование товара - явная характеристика товара.

(?)Цена товара - похоже, что это характеристика товара. Отличается ли эта характеристика от цены в накладной?

Единица измерения - явная характеристика товара.

Номер накладной - явная уникальная характеристика накладной.

Дата накладной - явная характеристика накладной.

(?)Список товаров в накладной - список не может быть атрибутом. Вероятно, нужно выделить этот список в отдельную сущность.

(?)Количество товара в накладной - это явная характеристика, но характеристика чего? Это характеристика не просто "товара", а "товара в накладной".

(?)Цена товара в накладной - опять же это должна быть не просто характеристика товара, а характеристика товара в накладной. Но цена товара уже встречалась выше - это одно и то же?

Сумма накладной - явная характеристика накладной. Эта характеристика не является независимой. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную.

Наименование склада - явная характеристика склада.

В ходе дополнительной беседы с менеджером удалось прояснить различные понятия цен. Оказалось, что каждый товар имеет некоторую текущую цену. Эта цена, по которой товар продается в данный момент. Естественно, что эта цена может меняться со временем. Цена одного и того же товара в разных накладных, выписанных в разное время, может быть различной. Таким образом, имеется две цены - цена товара в накладной и текущая цена товара. С возникающим понятием "Список товаров в накладной" все довольно ясно. Сущности "Накладная" и "Товар" связаны друг с другом отношением типа много-ко-многим. Такая связь, как мы отмечали ранее, должна быть расщеплена на две связи типа один-ко-многим. Для этого требуется дополнительная сущность. Этой сущностью и будет сущность "Список товаров в накладной". Связь ее с сущностями "Накладная" и "Товар" характеризуется следующими фразами - "каждая накладная обязана иметь несколько записей из списка товаров в накладной", "каждая запись из списка товаров в накладной обязана включаться ровно в одну накладную", "каждый

136

товар может включаться в несколько записей из списка товаров в накладной", " каждая запись из списка товаров в накладной обязана быть связана ровно с одним товаром". Атрибуты "Количество товара в накладной" и "Цена товара в накладной" являются атрибутами сущности " Список товаров в накладной". Точно также поступим со связью, соединяющей сущности "Склад" и "Товар". Введем дополнительную сущность "Товар на складе". Атрибутом этой сущности будет "Количество товара на складе". Таким образом, товар будет числиться на любом складе и количество его на каждом складе будет свое. Теперь можно внести все это в диаграмму:

Полная схема со многими складами;

Необходимые коментарии к ней. О виртуальном складе;

10.4. Концептуальные и физические ER-модели

Разработанный выше пример ER-диаграммы является примером концептуальной диаграммы. Это означает, что диаграмма не учитывает особенности конкретной СУБД. По данной концептуальной диаграмме можно построить физическую диаграмму, которая уже будет учитывать такие особенности СУБД, как допустимые типы и наименования полей и таблиц, ограничения целостности и т.п. Физический вариант диаграммы, приведенной на Рис. 9 может выглядеть, например, следующим образом: На данной диаграмме каждая сущность представляет собой таблицу базы данных, каждый атрибут становится колонкой соответствующей таблицы.

137

Рис. 9

Обращаем внимание на то, что во многих таблицах, например, "CUST_DETAIL" и "PROD_IN_SKLAD", соответствующих сущностям "Запись списка накладной" и "Товар на складе", появились новые атрибуты, которых не было в концептуальной модели - это ключевые атрибуты родительских таблиц, мигрировавших в дочерние таблицы для того, чтобы обеспечить связь между таблицами посредством внешних ключей. Легко заметить, что полученные таблицы сразу находятся в 3НФ.

По физической модели нужно разработать спецификацию всех таблиц.

Выводы

Реальным средством моделирования данных является не формальный метод нормализации отношений, а так называемое семантическое моделирование. В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship). Диаграммы сущность-связь позволяют использовать наглядные графические обозначения для моделирования сущностей и их взаимосвязей. Различают концептуальные и физические ER-диаграммы. Концептуальные диаграммы не учитывают особенностей конкретных СУБД. Физические диаграммы строятся по концептуальным и представляют собой прообраз конкретной базы данных. Сущности (лучше отношения!), определенные в концептуальной диаграмме становятся таблицами, атрибуты становятся колонками таблиц (при этом учитываются допустимые для данной СУБД типы данных и наименования столбцов), связи реализуются путем миграции ключевых атрибутов родительских сущностей и создания внешних ключей. При правильном определении сущностей, полученные таблицы будут сразу находиться в 3НФ. Основное достоинство метода состоит в том, модель

138

Рис. 10

строится методом последовательных уточнений первоначальных диаграмм. В данной главе, являющейся иллюстрацией к методам ER-моделирования, не рассмотрены более сложные аспекты построения диаграмм, такие как подтипы, роли, исключающие связи, непереносимые связи, идентифицирующие связи и т.п.

Еще раз уточнить:

в предметной области – сущности, процессы, атрибуты, связи;

на концептуальной ER диаграмме – отношения, атрибуты, связи;

на физической ER диаграмме – таблицы, поля, связи с помощью ключей.

139

10.5. Exemplu concret. BD „Vinzari” („Depozit”)

Для лучшего понимания дальнейшего изложения материала, а также для получения предварительных сведений практического характера о

реляционных СУБД, необходимых для выполнения лабораторных работ, ниже подробно рассматривается пример конкретной системы баз

данных, создаваемой для оптового склада.

Elaborarea sistemului informaţional cu baze de date constă din mai multe etape, principalele dintre care sunt elaborarea proiectului (modelarea sistemului) şi realizarea bazei de date fizice în cadrul unui SGBD conret. În acest paragraf în calitate de exemplu ne vom preocupa de elaborarea proiectului logic a bazei de date DEPOZIT.

Problema proiectării a sistemului informaţional are cel puţin două subprobleme: Colectarea informaţiei şi modelarea business-proceselor; Elaborarea structurei a sistemului informaţional.

La modelarea business-proceselor trebuie de considerat trei aspecte: Obiectele cu care operează business-procesul; Procesele implicate în business; Evenimentele care gestionează procesele.

Există două modalităţi (tehnologii) de modelare a sistemului informaţional cu bază de date:

Modelare logică formală. Reprezintă procedeie de normalizare consecutivă a relaţiilor cu scopul înbunătăţirii calităţii proiectului BD;

Modelare semantică, bazată pe sensul datelor. Este o modelare a structurelor de date reieşind din sensul (semantica) acestor date.

Ca instrument de modelare semantică se folosesc diferite variante de diagrame Entitate-relaţie (ER). Diagramele se bazează pe reprezentarea în forma grafică a:

Entităţilor (obiectelor şi proceselor); Atributelor entităţilor; Legăturilor dintre entităţi.

3. Schema logică a bazei de date DEPOZIT

Fie avem de elaborat baza de date pentru o firmă de comerţ angro (cu râdicata). Începem cu studierea acestui domeniu concret: vorbim cu experţii, citim documentaţie, studiem documentele de întrare/ieşire Aici trebuie să clarificăm:Ce prezintă domeniul concret al lumii reale?

140

Care este scopurile elaborării?Ce informaţie trebuie să fie memorată în BD?

Aşadar, aflăm că domeniul concret prezintă:O firmă de comerţ care este posesor de încăperi de depozitare a mărfurilor. Activitatea ei constă în colectarea mărfurilor de la furnizori angro şi vînzarea mărfurilor cu râdicata clienţilor.

Din convorbiri cu managerul de comerţ a firmei aflăm că BD trebuie să: Păstreză informaţie despre mărfuri, furnizori şi clienţi; Să ducă evidenţa mărfurilor primite de la furnizori prin facture de primire

(document de întrare); Să ducă evidenţa mărfurilor în depozit existente în prezent; Să formeză şi să tipărească facture de eliberare a mărfurilor (document de

ieşire);

Din analiza aceastei informaţie determinăm:

Entităţile (obiectele şi procesele); Atributele entităţilor; Legăturile dintre entităţi.

Acum putem construi diagrama ER a bazei de date. Aceasta va fi schema logică a bazei de date.

141

Fig. 2. Diagrama ER a bazei de date VINZARI

Furnizori

FurnIdFurnNameFurnPhoneFurnCont...

Livrari

NumLivrareFactLivrIdMarfaIdVolumePrice....

Clienti

ClientIdClientNameClientPhoneClientCont....

Vinzari

NumVinzareFactVinzIdMarfaIdVolumePriceTVA....

Depozit

NumPozitieMarfaIdVolumePrice....

Marfa

MarfaIdMarfaNameProducator....

FacturaLivrare

FactLivrIdDateFurnIdLivrareSum...

FacturaVinzare

FactVinzIdDateClientIdVinzareSum...

În continuare vom prezenta formatul simplist al operaţiilor SQL de creare a tabelelor precum şi de manipulare cu datele din tabele - selectare, înserare, modificare şi eliminare.

Crearea tabelelor

CREATE TABLE Customers (Cstid CHAR(10) NOT NULL PRIMARY KEY,Cstname VARCHAR(30) NOT NULL,…Cstabout TEXT NULL);

CREATE TABLE Depozit (Vdcid CHAR(10) NOT NULL PRIMARY KEY,Vdcname VARCHAR(20) NOT NULL,…Cstabout TEXT NULL);

CREATE TABLE Hire (Ordnum INTEGER NO NULL PRIMARY KEY,Dategive DATE NOT NULL,Cstid CHAR(10) NOT NULL,Vdcid CHAR(10) NOT NULL,Datereturn DATE NULL,…Payment NUMBER(4,2) NULL,…,CONSTRAINT Constr1 FOREIGN KEY (Cstid) REFERENCES Customers

(Cstid),CONSTRAINT Constr2 FOREIGN KEY (Vdcid) REFERENCES Depozit

(Vdcid),);

Selectarea datelor

SELECT Vdcid, Vdcname, VdcaboutFROM DepozitWHERE Vdcname=’MATRIX’;

SELECT Cstname, Vdcname, DategiveFROM Customers, Hire, DepozitWHERE Dategive < {10.02.03} AND Datereturn = NULL;

Însersrea datelor noi

INSERTINTO Customers (Cstid, Cstname, Cstpassport, Cstphone)VALUES (‘STD23’, ‘ALBU ION‘, ‘A123456789’, ’22-22-22’);

Modificarea datelor

UPDATE DepozitSET Vdcount = 4WHERE Vdcid = ‘MTR5’;

Eliminarea datelor

DELETEFROM CustomersWHERE Cstid = ‘ALB3’;

144

11. Limbajul bazelor de date relaţionale SQL. Elemente de bază a limbajului

11.1. Eелементе де базă

Obiectele bazei de date în SQL: TABLE – tabele memorate (tabele de bază); SCHEMA – scheme. Seturi individuale de obiecte asociate de un utilizator

concret – posesorul schemei. De exemplu: USER1.EMPLOYEE_TBL, USER2.EMPLOYEE_TBL. При доступе к таблице из вашей собственной схемы на имя схемы ссылаться не нужно. Оператор доступа: CONNECT <USER_NAME>@<DATABASE_NAME>

DOMAIN – domene. Tipuri de date cu sens; INDEX – indecşi. Indexarea după câmpuri; VIEW – viziuni (relaţii virtuale, tabele calculate în memoria RAM); SYNONIM – sinonime (ALIAS) ale tabelelor.

1. Tipuri (categorii) de comenzi în SQL (operatori – statements, comenzi – commands) :

DDL (Data Definition Language) – limbajul (sublimbajul) de definire a datelor (structurilor de date);

DML (Data Manipulation Language) – limbajul (sublimbajul) de manipulare a datelor;

DQL (Data Query Language) – limbajul (sublimbajul) de interogare a datelor; DCL (Data Control Language) – limbaj (sublimbaj) de control a datelor; Comenzi de administrare a datelor; Comenzi de gestionare a tranzacţiilor.

2. Comenzile principale a sublimbajului DDL (definirea structurilor date): CREATE/ALTER/DROP TABLE – crearea/modificarea/suprimarea

tabelelor; CREATE/ALTER/DROP INDEX – crearea/modificarea/suprimarea

indexului; CREATE/ALTER/DROP SCHEMA – crearea/modificarea/suprimarea

schemei; CREATE/ALTER/DROP DOMAIN – … a domenului; CREATE/ALTER/DROP SYNONIM – … a sinonimului (ALIAS); CREATE/ALTER/DROP VIEW – … a viziunii (relaţie virtuală);

3. Comenzile principale a sublimbajului DML (manipularea sau actualizarea datelor):

INSERT UPDATE

145

DELETE

4. Comenzile principale a sublimbajului DQL (interogarea datelor): SELECT

5. Comenzile principale a sublimbajului DCL (comenzile de protecţie şi gestiune a datelor – crearea şi eliminarea obiectelor, care determină (reglează) drepturile de acces la baza de date, precum şi acordarea privilegiilor de niveluri cuvenite pentru utilizatori: CREATE/ALTER/DROP PASSWORD GRANT – acordarea privilegiilor de acces; REVOKE – anularea (revocarea, abrogarea) privilegiilor;

6. Comenzile de administrare a datelor: START AUDIT – revizia conturilor; STOP AUDIT

7. Comenzile de gestionare a tranzacţiilor: SET TRANZACTION – a stabili tranzacţia; COMMIT – a îndeplini, a realiza tranzacţia; ROLLBACK– a anula tranzacţia; SAVEPOINT – a stabili puncte de trecere în interiorul tranzacţiei.

Structuri (tipuri) de date

1. Şiruri de simboale CHARACTER (n) CHARACTER VARYING (n) (VARCHAR – Microsoft SQL Server,

VARCHAR2 – Oracle)

2. Date numerice DECFIMAL (n,m) INTERGER SMALLINT FLOAT (p) REAL (s) DOUBLE PRESISSION (p)

3. Data şi ora DATE TIME INTERVAL TIMESTAMP

**YEAR

146

**MONTH**DAY**HOUR**MINUTE**SECOND

4. Constante literale – ‘abc123’.5. Date de tip boolean (logical or boolean). Au valori TRUE, FALSE,

UNKNOWN.6. Tipuri de date create de utilizator:

CREATE TYPE Person AS OBJECT(NAME varchar(30), SALARY real(p), BIRTHDAY date);

11.2. CREAREA TABELELOR. SINTAXA GENERALĂ:

Прежде чем создавать таблицу нужно получить ответы на вопросы: Какого типа данные будут вводиться в таблицу; Имя таблицы; Имена столбцов; Типы данных в столбцах; Длины столбцов; Какие столбцы будут требовать обязательного ввода данных; Какими столбцами будут задаваться ключи.

CREATE TABLE <tabel_name>(field_definition_comma_list constraint_definition_comma_list);

field_definition_comma_list – specificarea câmpurilor după formă

<camp_nume> <tip_date_lungimea> [NULL NOT NULL],

constraint_definition_comma_list – specificarea constrângerilor (restricţiilor), care asigură consistenţa şi integritatea (referenţială – în primul rând) datelor (список ограничений, обеспечивающих целостность и непротиворечивость данных).

Remarcă: Ordinea nu importă

Există trei tipuri de restricţii în tabele de bază: definiţie cheie primară (определение первичного ключа); definiţie cheie externă (определение внешнего ключа); definiţie condiţii de control (условия проверки данных).

147

Pentru formularea acestor restricţii în comanda CREATE TABLE sunt susţinute următoarele opţii (opţii de constrângeri) – PRIMARY KEY, UNIQUE, FOREIGN KEY, REFERENCES, DEFAULT, CHECK.

Sintaxa generală pentru crearea cheilor: cheie primară/proprietatea UNIQUE

PRIMARY KEY (colomn-commalist)UNIQUE (colomn-commalist)

cheie externăFOREIGN KEY (colomn-commalist)

REFERENCES <base_table_name> [(colomn-commalist)][ON DELETE <option>][ON UPDATE <option>]

Вместо <option> в соответствии с выбранной стратегией может стоять NO ACTION, CASCADE, SET DEFAULT sau SET NULL. Opţia NO ACTION, setată implicit este identică cu strategia RESTRICTED analizată în teorie..

Примеры:

CREATE TABLE Supplier (SupplId CHAR(6) NOT NULL PRIMARY KEY,SupplName VARCHAR(30) NOT NULL,…SupplAbout TEXT NULL);

CREATE TABLE InvoiceSuppl (InvSupplId CHAR(6) NOT NULL PRIMARY KEY,InvSupplDate DATE NOT NULL,InvSupplier CHAR(6) NOT NULL FOREIGN KEYREFERENCES Supplier (SupplId),InvSupplSum DECIMAL(18,6) NOT NULL,InvSupplDepozit CHAR(6) NOT NULL FOREIGN KEYREFERENCES Depozit (DepId),DEFAULT (InvSupplDate = Date()));

CREATE TABLE Delivery (OrdNum INTEGER NOT NULL UNIQUE,InvoiceSuppl CHAR(6) NOT NULL,Ware CHAR(6) NOT NULL,Volume INTEGER NULL,Price DECIMAL(18,6) NULL,CONSTRAINT Delivery1 FOREIGN KEY (InvoiceSuppl)REFERENCES InvoiceSuppl (InvSupplId),CONSTRAINT Delivery2 FOREIGN KEY (Ware)

148

REFERENCES Wares (WareId),CHECK (Volume >5));

Привести ER-диаграмму созданных таблиц

11.3. INTRODUCEREA DATELOR ÎN TABELE

Ввод строки данных в таблицу

СинтаксисINSERT INTO <Имя_схемы.Имя_таблицы> VALUES ( значение1, значение2, …, [NULL], …);

ПримерINSERT INTO DeliveryVALUES (‘109’, ‘ORH023’, ‘TEL072’, 15, 2499.99);1 record inserted

Ввод данных в определенные столбцы

СинтаксисINSERT INTO <Имя_схемы.Имя_таблицы> (СТОЛБЕЦ1, СТОЛБЕЦ2, …)VALUES (значение1, значение2, …);

ПримерINSERT INTO Delivery (OrdNum, Supplier, Ware)VALUES (‘109’, ‘ORH023’, ‘TEL072’);1 record inserted

Ввод данных из другой таблицы

СинтаксисINSERT INTO <Имя_схемы.Имя_таблицы> [(Столбец1, Столбец2, …)]SELECT [ * | (Столбец1, Столбец2, …)]FROM <Имя_схемы.Имя_таблицы>[WHERE <условия выбора>];

Если отсутствует условие выбора (опция WHERE) будут введены все записи копируемой таблицы, иначе – только те, которые удовлетворяют условиям выбора.

149

INSERT INTO ORDERS_TMP SELECT * FROM ORDERS_TBL20 records inserted

INSERT INTO ORDERS_TMP SELECT * FROM ORDERS_TBLWHERE COST >= 49.99;7 records inserted

Если таблица, в которую вводятся данные не существует она, как правило, будет создана.

INSERT INTO ORDERS_TMP (ORD_NUM, CUST_ID, PROD_ID, QTY, COST)SELECT (ORD_NUM, CUST_ID, PROD_ID, QTY, COST)FROM ORDERS_TBLWHERE COST>=49.99;7 records inserted

Наименования столбцов, естественно, не обязаны совпадать.

11.4. MODIFICAREA DATELOR ÎN TABELE

Изменение значений одного столбца

СинтаксисUPDATE <имя_схемы.Имя_таблицы>SET <Имя_столбца = значение>[WHERE <условие>];

ИлиUPDATE <table_name >SET <field_name> = <valuie >[WHERE <condition>];

<table_name> ≡ <schema_name.table_name>

Примеры с условием

UPDATE DeliverySET Volume = 5

150

WHERE OrdNum = 109;1 record updated

без условияUPDATE DeliverySET Volume = 5;109 records updated

Обновление нескольких столбцов в одной или нескольких записях

СинтаксисUPDATE <Имя_схемы.Имя_таблицы>SET <Cтолбец1 = значение1>[, Столбец2 = значение2,столбец3 = значение3, …][WHERE <условие>];

ИлиUPDATE <table_name >SET <field_name1> = <valuie1 >,

<field_name2> = <valuie2 >, ...,<field_nameN> = <valuieN >

[WHERE <condition>];

Пример

UPDATE DeliverySET Supplier = ‘BEL007’, Price = 2599.99WHERE Ware = ‘TEL072’;7 records updated

11.5. ŞTERGEREA DATELOR DIN TABELE

Синтаксис словесный

DELETE FROM <Имя таблицы, из которой удаляются строки>[WHERE <условие, при котором эти строки удаляются>];

формальныйDELETE FROM <table_name>[WHERE <condition>];

151

Оператор DELETE удаляет не значения отдельных столбцов, а целые записи.

ПримерDELETE FROM DeliveryWHERE ORD_NUM = 109;1 record deleted

DELETE FROM Delivery;109 records deleted

11.6. EXTRAJEREA (SELECTAREA) DATELOR DIN TABELE

Общий синтаксиссловесный:SELECT <список полей, из которых выбираются данные >FROM <список таблиц, в которых эти поля находятся > [WHERE <условия, при которых выбираются данные >];

(предикат выбора)

формальный:SELECT <* | field_name1, field_name2, ..., field_nameN>FROM <table_name1, table_name2, ..., table_nameN> [WHERE <condition>];

Примеры

SELECT * FROM DeliveryWHERE Volume > 20 AND Price > 2999.00;

SELECT Delivery.OrdNum, Supplier.SupplName, Wares.WareName, Delivery.Volume, Delivery.Price

FROM Supplier, Delivery, Wares

WHERE (Supplier.SupplId = Delivery.Supplier) AND (Delivery.Ware = Wares.WareId);

Сортировка вывода (ключевое слово ORDER BY)

SELECT <* | field_name1, field_name2, ..., field_nameN>FROM <table_name1, table_name1, ..., table_nameN> [WHERE <condition>];

152

ORDER BY < field_name1', field_name2', ...>

Поля, по которым проводится сортировка, указываются своими именами или порядковыми номерами.

Пример

SELECT Delivery.OrdNum, Supplier.SupplName, Wares.WareName, Delivery.Volume, Delivery.Price

FROM Supplier, Delivery, Wares

WHERE (Supplier.SupplId = Delivery.Supplier) AND (Delivery.Ware = Wares.WareId);

ORDER BY 2, 4;

Создание таблицы на основе уже существующей. Комбинация операторов CREATE TABLE и SELECT

Синтаксис:CREATE TABLE <Имя_новой_таблицы> AS SELECT [* | <Поле1>,<Поле2>, …]FROM <Имя_Таблицы>[WHERE <условие>];

Пример

CREATE TABLE Delivery2 AS

SELECT Delivery.OrdNum, Supplier.SupplName, Wares.WareName, Delivery.Volume, Delivery.Price

FROM Supplier, Delivery, Wares

WHERE (Supplier.SupplId = Delivery.Supplier) AND (Delivery.Ware = Wares.WareId);

Crearea şi utilizarea tabelelor virtuale, indecşilor, domenelor, tipurilor proprii de date, etc.

Crearea şi utilizarea tabelelor virtuale - view

CREATE VIEW <view_nume> [<field_comma_list>]ASSELECT * | < field_comma_list >FROM <table_comma_list>

153

WHERE <conditii de selectie>

Пример

CREATE VIEW Delivery AS

SELECT Delivery.OrdNum, Supplier.SupplName, Wares.WareName, Delivery.Volume, Delivery.Price

FROM Supplier, Delivery, Wares

WHERE (Supplier.SupplId = Delivery.Supplier) AND (Delivery.Ware = Wares.WareId);

Созданная таблица Delivery называется представлением (View). Она является не физической а виртуальной таблицей. Это значит, что она создается в динамической (оперативной) памяти в момент открытия. При этом она создается каждый раз на основе текущих (актуальных) данных.

Glosar

Regulile de inferenţă (Cotelea)INFERÉNȚĂ, inferențe, s. f. Operație logică de trecere de la un enunţ la altul şi în care ultimul enunț este dedus din primul. – Din fr. inférence. Sursa: DEX '98 | Adăugată de valeriu | Gre ș eală de tipar | Permalink INFERÉNȚĂ s. f. operație logică de derivare a unui enunț din altul, prin care se admite o judecată în virtutea unei legături a ei cu alte judecăți considerate ca adevărate. (< fr. inférence) Sursa: MDN | Adăugată de raduborza | Gre ș eală de tipar | Permalink

DEDÚCȚIE ~i f. 1) Formă de raționament prin care, pornindu-se de la idei generale, se ajunge la concluzii particulare. 2) Raționament obținut în procesul unor operații mintale; rezultat al deducției. [Art. deducția; G.-D. deducției; Sil. -ți-e] /<fr. déduction, lat. deductio, ~onis Sursa: NODEX | Adăugată de siveco | Gre ș eală de tipar | Permalink DEDÚCȚIE s.f. Raționament logic prin care se obține o judecată nouă (numită concluzie) din două sau mai multe judecăți (numite premise), dintre care una trebuie să fie neapărat universală. [Gen. -iei, var. deducțiune s.f. / cf. lat. deductio, fr. déduction]. Sursa: DN | Adăugată de LauraGellner | Gre ș eală de tipar | Permalink DEDÚCȚIE s. f. formă fundamentală de raționament în care concluzia rezultă cu necesitate din premise. (< fr. déduction, lat. deductio) Sursa: MDN | Adăugată de raduborza | Gre ș eală de tipar | Permalink

CONSISTENŢA DATELOR – concordanţa, compatibilitatea datelor, cu conţinut semantic consistent – содержательность данных – bogăţia semantică a datelor,Conţinut semantic complet

CONSISTÉNT adj. v. deosebit, important, însemnat, mare, notabil, prețios, remarcabil, serios, substanțial, temeinic, valoros.

CONSISTENŢĂ

154

Calitate a unui sistem axiomatic de a nu conține o formulă oarecare în același timp cu negația ei. [Cf. it. consistenza, fr. consistance];(log.) însușire a unui sistem axiomatic de a nu fi contradictoriu. (< fr. consistance, it. consistenza)

REDUNDANŢA DATELOR – excedenţa datelor ca consecinţa dublării lor

SECVENŢE DE DATE – …

SUBSET DE DATE –

MODELUL RELAŢIONAL – restricţii de integritate formate din totalitatea de reguli şi constrîngeri impuse modelului pentru asigurarea corectitidinei datelor

Valori valide pentru fiecare câmp

Securitatea şi protecţia datelor – безопасность и защита данных

Întreţinerea securităţii şi protecţia datelor – Siguranţa – надежностьO suită de protocoale – семейство протоколовTransmitere şi recepţionare – передача и прием

155

Observaţii din lucrările studenţilor

1. Organizarea în trei nivele a sistemelor de baze de date este strâns legată …2. Exerciţiu – упржнение, тренировка.3. Cortejii – de la cortej4. Condiţia care trebuie suspectată5. Elementele mulţimii: să diferă prin “valori” – categoriale sau numerice. Exemple: culoare = {alb, roşu, negru, …} – individualitatea elementelor.6. Legitate

7. Baza de date este nucleul de date a sistemului informaţional8. Centralizarea datelor permite suprimarea redundanţei

Способ организации реляционной зависимости между таблицами – relationship и свойства, имитирующие стандартные фразы SQL – Where и Order by.

156