Universitatea de Ştiinţe Agricole şi Medicină Veterinară “Ion Ionescu de la Brad” Iaşi

Lector dr. Marius Călin

INFORMATICĂ Partea a II-a

Curs pentru învăţământ la Distanţă

2003

2

Cuprins 1. Introducere … … … … … … … … … … … … … … 3 2. Date şi baze de date … … … … … … … … … … … 5 3. Baze de date relaţionale … … … … … … … … … … 9 3.1. Relaţii, tupluri, atribute … … … … … … … 10 3.2. Diagrama entitate-asociere … … … … … … 11 4. Interogarea bazei de date relaţionale … … … … … … 18 4.1. SGBD-ul şi utilizatorii săi … … … … … … … 18 4.2. Limbajul de manipulare a datelor … … … … 20 4.3. Indexare … … … … … … … … … … … … … 26 4.4. Tenhici declarative de manipulare a datelor … 28 Referat şi temă pentru aplicaţie practică … … … … … 33

3

1 Introducere

În 1880, Biroul de Recensământ al SUA (U.S. Census Bureau) a cerut

matematicianului Herman Hollerith să găsească o posibilitate de sporire a ritmului de prelucrare a datelor obţinute în urma recensământului populaţiei. Ca urmare a acestei solicitări Hollerith a creat cartela perforată, codul de perforaţii prin care datele de pe fişele de recensământ să fie reprezentate pe cartele şi a conceput o maşină care să manipuleze cartelele. El a luat ca sursă de inspiraţie războiul de ţesut automat, inventat de Joseph Marie Jaquard in 1804, la care modelul ţesăturii era codificat şi înregistrat tot pe o suită de cartele perforate pe care maşina le "citea" pentru a face operaţiile corespunzătoare. Prin transpunerea în practică a conceptelor lui Hollreith, rezultatele recensamântului din 1890 au fost finalizate in circa trei ani în loc de unsprezece, cum estimase iniţial U.S. Census Bureau.

Cartelele perforate şi codul Hollerith au făcut carieră în prelucrarea automată a datelor până la începutul anilor optzeci ai secolului nostru, iar creatorul lor a intrat în istoria calculatoarelor. Jaquard a intrat în istoria industriei textile, principiile maşinii lui sunt utilizate şi astăzi, iar furia "jacardurilor" reapare cu o ciclicitate de câţiva ani în moda tricotajelor. Într-o istorie a tehnologiei informaţiei, "momentul Hollerith" este scos în evidenţă pentru a marca o primă utilizare pe scară mare a codificării informaţiilor primare, codul Hollerith, precum şi apariţia unui suport viabil, cartela perforată, pe care codurile să fie înregistrate pentru a fi oferite, spre prelucrare, maşinii. Motivul pentru care acest moment istoric a fost amintit aici este altul, şi anume deznodământul său: durata prelucrării datelor a fost redusă la o treime. Pe de altă parte, mai importantă pentru cele ce vor fi discutate în acest capitol, este următoarea observaţie: acum mai bine de o sută de ani, o organizaţie (U.S. Census Bureau), confruntându-se cu problema stocării şi manipulării unui volum imens de date, a decis să facă un efort considerabil de modernizare în această direcţie.

Organizarea şi exploatarea unor mari colecţii de date este astăzi o cerinţă obişnuită în orice domeniu. ~n orice domeniu de activitate, economie, industrie, administra]ie, agricultur\, cantitatea de informa]ii care trebuie `nregistrate [i manipulate cre[te continuu. În acest punct credem că este utilă sublinierea distincţiei care trebuie făcută între date şi informaţii. Datele sunt "fapte" reprezentate prin valori - numere, şiruri de caractere, sau simboluri care au semnificaţie într-un anumit context [2]. În cazul calculatoarelor aceste

4

valori sunt stocate pe suporturi specifice. Cartela perforată inventată de Herman Hollerith a fost un astfel de suport de stocare; astăzi vorbim despre discuri magnetice, discuri optice (CD-ROM), casete cu bandă magnetică. Datele sunt, deci, fapte, adică materia primă pentru obţinerea informaţiilor. Din acest punct de vedere, ele pot fi considerate informaţii doar într-un sens limitat [3]. Informaţiile sunt ceea ce rezultă în urma prelucrării electronice a datelor într-un anumit scop. Am făcut aceste observaţii având în vedere utilizările "clasice" ale calculatorului, adică în scop ştiinţific, ingineresc, sau economic; cu puţină imaginaţie ele se pot extinde asupra celor mai neconvenţionale situaţii, deci chiar şi atunci când datele de intrare provin de la un microfon, sau când informaţiile de ieşire reprezintă comorile ascunse într-un labirint dintr-un joc video.

Astăzi conceptul de bază de date este foarte des folosit. Trebuie spus că, în destul de multe cazuri, folosirea este abuzivă şi că eticheta de bază de date este aplicată unor colecţii oarecare de înregistrări ce nu îndeplinesc, nici ca mod de organizare şi nici ca mod de exploatare, rigorile impuse de termen. În acest capitol vom trece în revistă ideile principale care definesc noţiunea de bază de date şi vom schiţa o abordare din punctul de vedere al unui profesionist neinformatician. Scopul este de a oferi acestuia un punct de plecare pentru o potenţială colaborare cu informaticianul în dezvoltarea unei baze de date. Vom discuta intâi de ce este recomandată tehnologia bazelor de date atunci când apare situaţia organizării, manipulării şi exploatării unor cantităţi mari de date. Deşi, la prima vedere, poate părea superfluă, credem că o astfel de discuţie este utilă mai ales pentru a clarifica "ce se poate pretinde unei baze de date". De altfel, toate lucrările din domeniu includ un astfel de segment. Un exemplu este [2] cartea lui Gordon G. Everest în care o parte importantă este dedicată unei asfel de discuţii. Începând cu a doua jumătate a anilor cincizeci problema organizării marilor colecţii de date a constituit în permanenţă un domeniu de interes care a devenit un important câmp de activitate pentru cercetători şi pentru proiectanţi, cel al sistemelor de gestiune a bazelor de date. Au rezultat fundamentări teoretice, tipuri de arhitecturi, medii de dezvoltare lansate piaţă de marii producători de software.

Dintre modele consemnate în prezent am ales sistemele de gestiune a bazelor de date relaţionale pentru a exemplifica posibilităţile de rezolvare practică a cerinţelor legate de alegerea materialelor. Aceasta deoarece modelul relaţional este astăzi cel mai utilizat, marile firme de software folosindu-l pentru realizarea mediilor de dezvoltare a bazelor de date. În afară de lucrarea citată anterior să mai menţionăm şi [5], care se ocupă exclusiv de acest model.

Nu vom discuta detalii tehnice şi nu ne vom concentra asupra unui anumit sistem de gestiune a bazelor de date. Considerăm că aceasta ar încărca inutil conţinutul capitolului, ţinând cont de categoria de cititori cărora li se adresează această carte. Produsele software moderne sunt însoţite de documentaţii bine elaborate şi au comenzi tip Help foarte eficiente. În cazul în care o persoană implicată în proiectarea construcţiilor metalice are pasiunea şi timpul necesar aprofundării unui SGBD, o va putea face utilizând direct produsul pe care îl are la dispoziţie.

5

2 Date şi baze de date

Începând cu mijlocul anilor '50 o problemă abordată cu prioritate de specialiştii din

ştiinţa calculatoarelor a fost dezvoltarea limbajelor de programare deoarece, fără programe un calculator nu face nimic, iar fără limbaje dezvoltarea de programe performante nu este posibilă. Un obiectiv avut în vedere a fost ca limbajele să fie cât mai apropiate de necesităţile categoriilor de utilizatori cărora li se adresau. Astfel, primul limbaj de programare de nivel înalt, FORTRAN, a fost creat pentru dezvoltare de programe în scop ştiinţific şi tehnic, iar primul limbaj pentru gestiunea marilor colecţii de date a fost COBOL. De notat că limbajul COBOL a deţinut supremaţia în realizarea aplicaţiilor de gestiune a datelor până la apariţia şi dezvoltarea sistemelor de gestiune a bazelor de date.

În această perioadă preocupările în legătură cu structurile de date au fost mai reduse; ele s-au axat mai degrabă spre perfecţionarea tehnicilor de stocare pe noile suporturi fizice apărute: banda magnetică şi discul magnetic. A fost studiat şi dezvoltat conceptul de fişier care desemnează o colecţie organizată de înregistrări pe un anumit suport. Cercetările s-au concentrat asupra organizării fizice şi logice a înregistrărilor precum şi asupra metodelor de acces la înregistrări. În realizarea aplicaţiilor informatice programul era punctul central (Fig. 1). Fondul de date întreţinut şi exploatat în cadrul unei aplicaţii era stocat pe suport magnetic sub forma mai multor de fişiere de date, un fişier fiind o colecţie de înregistrări. Înregistrările unui fişier de date conţineau o anumită categorie de date structurate în câmpuri, care erau utilizate în cadrul aplicaţiei informatice. La modul cel mai general, nu era obligatoriu ca toate înregistrările din fişier să arate la fel: să aibă aceeaşi dimensiune şi aceleaşi câmpuri. Chiar dacă anumite fişiere de date erau păstrate şi actualizate în permanenţă (de exemplu, fişierul de personal al unei întreprinderi), în schema bloc a aplicaţiei programele şi succesiunea execuţiei lor constituiau firul director.

În această manieră au fost dezvoltate sisteme informatice de mari dimensiuni. Un astfel de sistem întreţinea şi exploata un număr de fişiere de date prin intermediul unei colecţii de programe. Limbajul COBOL a fost cel mai utilizat pentru scrierea acestor programe, el fiind dezvoltat special pentru realizarea aplicaţiilor de gestiune. Însuşi numele său este o prescurtare care exprimă acest lucru (Common Business Oriented Language - limbaj orientat spre probleme de afaceri/gestiune). Pe măsură ce aplicaţiile informatice deveneau mai complexe au apărut şi unele neajunsuri. Să enumerăm câteva.

6

Redundanţa datelor, adică apariţia aceloraşi câmpuri de date în mai multe fişiere. Pe lângă consumul inutil de spaţiu de stocare se punea problema urmăririi foarte atente a acestor redundanţe pentru a nu "scăpa" necorelări între fişierele aplicaţiei.

Fig. 1 Abordarea clasică a unei probleme de prelucrare a datelor; programul este punctul central. Probleme la actualizarea structurii datelor, legate de redundanţa exprimată mai

sus. Atunci când apărea necesitatea unor schimbări în această privinţă, modificările trebuiau făcute în toate fişierele în care apăreau datele respective. Aceasta însemna scriere de programe noi, ceea ce consuma timp şi efort.

Lipsa independenţei între programe şi date. Din această cauză modificările asupra structurii unor date trebuiau urmate de modificarea tuturor programelor care le prelucrau.

Neajunsurile enumerate mai sus şi nu numai ele, duceau la întreţinerea necorespunzătoare a aplicaţiilor de gestiune. În [3] se dă ca exemplu sistemul informatic al unei universităţi în care, elementul NUME-STUDENT apărea în treisprezece fişiere, fiind reprezentat în cinci formate diferite.

Creşterea complexităţii sistemelor informatice, în special a celor de gestiune, a determinat studierea mai profundă a structurilor de date. Datele se dovedeau a fi o resursă importantă pentru organizaţii (economice, financiare etc.), iar gestionarea lor trebuia făcută cu aceeaşi atenţie ca şi a celorlalte resurse. Toate acestea au declanşat o schimbare fundamentală pe care G. C. Everest [2] o numeşte "o revoluţie coperniciană în procesarea datelor". Copernic a răsturnat în secolul al şaisprezecelea orgolioasa teorie geocentrică a lui Ptolemeu şi a demonstrat în cadrul teoriei heliocentrice că, de fapt, Soarele este în centru, iar noi şi celelalte planete ne învârtim în jurul lui. În cazul aplicaţiilor informatice care gestionează colecţii mari de date, schimbarea fundamentală a concepţiei constă în integrarea acestor colecţii într-o schemă de interdependenţă, structurată clar, care să asigure o descriere unitară a datelor şi a relaţiilor dintre ele. Această structură integrată, numită bază de date (BD), trebuie să ocupe punctul central al sistemului, programele aplicaţiei "gravitând" în jurul său (Fig. 2).

Baza da date este creată, întreţinută şi exploatată prin intermediul unui produs software numit sistem de gestiune a bazelor de date (SGBD). Un SGBD asigură realizarea următoarelor activităţi:

- definirea structurii BD, adică a colecţiilor de înregistrări şi a legăturilor dintre ele precum şi descrierea datelor elementare şi a relaţiilor dintre acestea;

- întreţinerea BD, adică încărcarea iniţială, adăugarea unor noi înregistrări, eliminarea altora, modificarea (actualizarea) datelor înregistrate;

Fisiere permanente

(initiale)

Fisiere permanente (actualizate)

PROGRAM

Date de intrare

Rezultatele prelucrãrii

7

- exploatarea BD, adică interogarea (căutarea şi vizualizarea datelor conform unor criterii anumite) şi editarea de rapoarte (liste de date referitoare la anumite probleme).

Fig. 2 Abordarea tip bază de date; datele ocupă poziţia centrală Deci manevrabilitatea bazei de date, în toate privinţele, este dată de către SGBD-ul

care o manipulează; acesta trebuie să permită dezvoltarea unor aplicaţii a căror întreţinere şi exploatare să fie accesibilă nu numai informaticienilor, ci şi utilizatorilor finali, beneficiarii informaţiilor.

În cazul sistemelor mari (societăţi comerciale importante, bănci etc.) baza de date este accesată de o gamă diversă de utilizatori (compartimente administrative, secţii de producţie etc.). Din acest motiv este obligatorie o anumită disciplină a muncii: întreţinerea BD este coordonată de un administrator al bazei de date, singurul care are control total asupra acesteia. Administratorul BD este autoritatea desemnată să stabilească structurile de date şi standardele aferente, să acorde diferitelor categorii de utilizatori drepturile de acces corespunzătoare pentru consultarea sau actualizarea BD, să le pună acestora la dispoziţie imaginea globală a părţii din BD la care au acces şi să le ofere instrumentele adecvate de lucru.

În cazul sistemelor mici, un SGBD este folosit pentru a organiza datele şi a simplifica accesul al ele. Acest lucru este foarte important pentru utilizatorii care trebuie să afecteze o mare parte a timpului de lucru consultării colecţiilor da date (fişe, documentaţii, standarde). Acesta este şi cazul inginerului care caută cea mai bună marcă de oţel pentru o construcţie metalică.

SGBD-urile, aceste medii de dezvoltare, întreţinere şi exploatare a bazelor de date, sunt produse de firmele de software. Cele mai cunoscute, utilizabile pe calculatoarele din familia PC, sunt: "bătrânul" dBase al firmei Ashton Tate, FoxPro şi, în prezent, Visual Fox dezvolate de Microsoft. Marii producători de software au lansat pe piaţă pachete integrate de soft de aplicaţie. Acestea conţin, în principal, trei module: un procesor de texte, un modul de calcul tabelar (spreadsheet) şi un SGBD. Cele mai importante sunt:

BAZA DE

DATE

PROGRAM

Date de intrare

Rezultateleprelucrãrii

PROGRAM

Date de intrare

Rezultatele prelucrãrii

VALIDARE

Date de intrare

EDITARE DE RAPOARTE

Rezultate

8

SGBD-ul Access inclus de Microsoft, împreună cu procesorul de texte Word şi spreadsheet-ul Excel, în pachetul Microsoft Office;

SGBD-ul Paradox inclus de Borland, împreună cu procesorul de texte WordPerfect şi spreadsheet-ul QuatroPro, în pachetul Borland Office;

SGBD-ul Approach inclus de Lotus, împreună cu procesorul de texte Ami Pro şi spreadsheet-ul 1-2-3, în pachetul Lotus SmartSuite.

Să mai menţionăm aici şi pachetul Works al firmei Microsoft. Modulele sale, similare cu cele ale produselor enumerate mai sus, au putere mai mică, dar şi complexitate mai scăzută. De aceea Works este uşor de învăţat, putând fi utilizat de neinformaticieni în rezolvarea problemelor curente de redactare, de calcul şi de gestiune a colecţiilor simple de date.

Toate produsele enumerate mai sus au o trăsătură comună: folosesc modelul relaţional pentru structurarea logică a datelor; este abordarea cea mai utilizată astăzi în realizarea de SGBD-uri. De aceea, în capitolul 3 vom discuta mai pe larg despre baze de date relaţionale.

9

3 Baze de date

relaţionale

O bază de date (nu neapărat relaţională) conţine informaţii despre entităţi. În general, prin entitate înţelegem orice obiect concret sau abstract din lumea reală, în legătură cu care dorim să colectăm date. Entităţile sunt descrise prin atribute. O instanţă, adică o entitate particulară este caracterizată de valorile atributelor. Să dăm un exemplu pentru a ilustra ideea:

- entitatea este PERSOANA; - atributele sale sunt NUME, PRENUME, DATA_NAŞTERII, LOCALITATE, JUD; - o instanţă este: Popa, Ion, 11/04/1951, Roman, NT. Ideea nu este complet diferită de abordarea clasică în care fişierele sunt colecţii de

înregistrări; în principiu, fiecare înregistrare este purtătoare de informaţii în legătură cu un obiect, informaţiile fiind date prin valori ale câmpurilor din care este formată înregistrarea. De aceea, în multe cazuri termenii "fişier", "înregistrare", "câmp" sunt folosiţi şi când se discută despre bazele de date, pentru că sună mai familiar. Dar această utilizare trebuie să aibă permanent în vedere diferenţele esenţiale dintre o sumă de fişiere şi o bază de date.

Conceptul de bază de date relaţională a fost lansat de E. F. Codd în 1970. Modelul relaţional nu este primul în istoria structurării logice a datelor. Dintre tehnicile prerelaţionale care au avut succes în implementare sunt cunoscute: structurile tip listă, structurile ierarhice, structurile tip reţea. Structurile de tip relaţional au câştigat popularitate datorită unor caracteristici care le deosebesc de celelalte; să le enumerăm în continuare.

- simplitatea în exploatare a câştigat simpatia utilizatorilor; - claritatea pe care o oferă asupra sistemului de date a atras deopotrivă pe

proiectanţi şi pe utilizatori; - limbajul de manipulare unificat, simplu şi puternic este atractiv nu numai pentru

profesionişti, ci şi pentru utilizatorii finali; - modelul relaţional teoretic, suportul pe care se bazează implementările practice de

SGBD oferă siguranţa corectitudinii şi garanţii pentru dezvoltările viitoare. În 1985 Codd a lansat conceptul de sistem de gestiune a bazelor de date relaţionale

(SGBDR) sub forma unui set de 13 reguli pe care acesta trebuie să le îndeplinească. Majoritatea SGBDR-urilor nu respectă în totalitate regulile lui Codd, deşi chiar Regula Zero,

10

cea fundamentală, arată că un sistem care este prezentat ca, sau se pretinde a fi un SGBDR, trebuie să fie capabil de a gestiona baze de date în întregime pe căi relaţionale. Setul reprezintă mai degrabă un ideal faţă de care se poate evalua în ce măsură un SGBD poate fi considerat relaţional. O astfel de evaluare este utilă deoarece unii producători, din dorinţa de a fi "în pas cu moda", au prezentat drept SGBDR sisteme care nu respectă de loc acest standard. Regulile lui Codd sunt enumerate şi comentate în lucrările de specialitate (de exemplu [4], [5]). În această prezentare generală a SGBDR vom face doar trimiteri la ele atunci când va fi cazul.

3.1. Relaţii, tupluri, atribute. Esenţa modelului relaţional este de a reprezenta datele ca un set de relaţii, numite şi

tabele, în care sunt stocate datele. Tabelele constau dintr-un număr de tupluri (numite şi linii, înregistrări) fiecare tuplu descriind o entitate. Toate liniile conţin acelaşi atribute (numite coloane, câmpuri); deci într-o tabelă se consemnează aceleaşi lucruri în legătură cu toate entităţile. Fiecare tabelă are un nume. Această reprezentare (Fig. 3) este formulată ca o cerinţă în Regula 1 a lui Codd: Toate informaţiile dintr-o bază de date relaţională sunt reprezentate explicit la nivel logic într-un singur mod - ca valori în tabele. Nivelul logic reprezintă imaginea pe care utilizatorul o are în legătură cu datele din BD. Reprezentarea a avut succes nu numai la proiectanţi, ci şi la utilizatori deoarece seamănă foarte bine cu metodele "pe hârtie", neinformatice, de prezentare şi stocare a datelor.

� Atribut (coloană, câmp)

Tuplu � (linie,

înregistrare)

Fig. 3 Modelul relaţional; relaţia (tabela) este elementul principal În Fig. 4 a, b şi c sunt descrise trei relaţii (tabele): STUDENTI [i CAMINE. La

fiecare se observă atributele (coloanele, câmpurile) şi câteva tupluri (linii, înregistrări).

STUDENŢI Atribute � Nume Prenume Matricola Localit Jud Cămin Cam

valori � Popa Ion 1122 Bacau BC C1 22

valori � Ionescu Dan 1123 Birlad VS

valori � Georgesu Alina 1124 Tecuci GL C3 31

a) Entităţile sunt studenţi

CĂMINE Atribute � Cămin Adresa Telefon Nr. camere

valori � C1 Sadoveanu 2 343434 30

valori � T3 Tudor Vladimirescu 22 565656 50

a) Entităţile sunt c\mine

Fig. 4. Exemple de tabele în care se pot stoca tipuri de entitate într-o BD.

11

În cadrul tabelei trebuie să existe un identificator unic pentru fiecare entitate. Pentru

aceasta se desemnează o cheie primară. Cheia primară este un atribut sau un grup de atribute din cadrul tabelei cu proprietatea că nu va avea niciodată aceeaşi valoare în două entităţi diferite. Cheia primară este un element esenţial. Unul din rolurile sale este de a garanta accesul la date, principiu exprimat de Regula 2 a lui Codd: Pentru orice dată (valoare atomică) este garantat accesul logic prin utilizarea unei combinaţii formate din numele tabelei, valoarea cheii primare şi numele coloanei (atribut). De exemplu, putem afla numărul de telefon al unui c\min de oţel intrând în tabela CAMINE, indicând valoarea din câmpul "Camin" (cheia primară) şi examinând valoarea atributului "Tel".

Pentru tabela STUDENTI atributul "Matricola" poate fi desemnat cheie primară, iar pentru tabela CAMINE acest rol poate fi jucat de atributul "Camin". Deci aceste tabele au cheile primare formate din câte un singur atribut. În cazul unor tabele nu există un atribut care să asigure o valoare unică pentru fiecare linie a tabelei. Într-un astfel de caz cheia primară trebuie să fie o combinaţie de mai multe atribute care, în ansamblu, dau unicitatea valorii. O astfel de combinaţie există întotdeauna, chiar dacă ea ar trebui formată din toate atributele entităţii. În caz contrar ar însemna că există posibilitatea apariţiei a două linii indentice în tabelă, ceea ce ar contrazice Regula 2.

3.2. Diagrama entitate-asociere Când se proiectează o bază de date relaţională, într-o fază iniţială trebuie elaborată o

diagramă entitate-asociere. De fapt o astfel de diagramă nu este legată strict de bazele de date relaţionale ci este valabilă pentru orice aplicaţie de gestiune, inclusiv pentru cele realizate cu fişiere clasice. Rolul ei este de imagine globală a structurilor de date în cadrul aplicaţiei respective; după definitivare, ea va fi punctul de plecare în realizarea bazei de date. Toate metodologiile de analiză de sistem şi de proiectare recomandă realizarea unei astfel de diagrame. Deşi apar diferenţe între diversele abordări, într-o diagramă entitate-asociere apar întotdeauna trei elemente de bază: tipuri de entitate, atribute şi asocieri. Vom discuta în continuare aceste trei categorii de bază, şi vom face particularizările pentru modelul relaţional.

Tipuri de entitate.

Un tip de entitate este orice tip de obiect, fizic sau abstract, din lumea reală, în legătură cu care dorim să stocăm date. Un obiect particular de tipul respectiv este o entitate, sau instanţă (a tipului de entitate). Deci, un tip de entitate desemnează o categorie de obiecte şi, din acest motiv, mai este numit mulţime de entităţi, iar entităţile (instanţele tipului de entitate) sunt numite elemente ale mulţimii de entităţi, fiecare ocupând o linie a tabelei. În modelul relaţional tipurile de entitate se memorează în tabele (devin relaţii).

Atribute.

Un tip de entitate este caracterizat de atribute. În modelul relaţional toate entităţile de un anumit tip au aceleaşi atribute; ele formează coloanele tabelei.

Tabelele din Fig. 4 a, b şi c memorează câte un tip de entitate; fiecare entitate (instanţă) ocupă o linie şi este caracterizată de anumite valori ale atributelor.

În diagrama entitate-relaţie tipurile de entitate şi atributele se reprezintă în diferite forme: prin nume urmat de listarea atributelor (Fig. 5 a) sau prin figurarea numelui într-un

12

dreptunghi central şi a atributelor (eventual, doar a acelora semnificative) în elipse conectate la dreptunghi (Fig. 5. b).

STUDENŢI CĂMINE

Nume Cămin Prenume Adresa Matricola Telefon Localit Nr. Camere Jud Cămin Cam

Fig. 5 Două moduri de reprezentare a tipurilor de entitate şi ale atributelor într-o diagramă entitate-asociere

Asocieri. Pe lângă tipuri de entitate şi de atribute, asocierile (legăturile) sunt al treilea element

important în diagrama entitate-asociere. Asocierile sunt acelea care transformă setul de tabele într-un tot integrat care este baza de date. SGBD-ul oferă mijloace de definire a asocierilor şi apoi de manipulare a datelor din bază exploatând aceste legături.

CURSURI PROFI NOTE Curs Nume Student_matricola Cadru_did Prenume Curs Ore_curs ID_prof Nota Ore_apl Credite Tip

Prenume Cãmin Nume

Cam STUDENTI

Cãmin Adresa

Telefon

Nr.camere CÃMINE

Matricola

Jud

13

Fie, pe lângă tabelele STUDENŢI şi CĂMINE definite anterior, tabelele CURSURI

şi PROFI şi NOTE, având următoarele structuri: Să considerăm tabelele STUDENTI şi CURSURI. Există vreo legătură între cele

două tipuri de entitate? Evident, un student frecventează mai multe cursuri, iar un curs poate fi frecventat de mai mulţi studen]i. Sunt, deci, două legături între tabele, având sensuri opuse. Putem pune reprezenta aceste asocieri ca în Fig. 6. Cele două asocieri au fost figurate prin săgeţi şi li s-au ataşat denumiri care arată semnificaţiile acestora.

Frecventeaza Sunt frecventate de

Fig. 6 Reprezentarea asocierilor între tabelele STUDENTI şi CURSURI Pe lângă semnificaţia unei asocieri este foarte important tipul asocierii. Acesta poate

fi privit din mai multe puncte de vedere, rezultând astfel diverse moduri de clasificare.

Clasificarea după numărul de tabele între care se face asocierea:

• asociere unară - între entităţi din aceeaşi tabelă (de acelaşi tip). • asociere binară - între entităţi din două tabele (de două tipuri). • asociere ternară - între entităţi din trei tabele (de trei tipuri). Asocierile binare sunt cele mai frecvente. În general, asocierile între trei sau mai

multe tabele pot fi descompuse într-un număr de asocieri binare; uneori, pentru aceasta este nevoie de crearea unor tabele suplimentare.

Clasificarea după cardinalitate.

asociere una la una (sau 1-la-1) - fiecărei entităţi dintr-o tabelă îi corespunde o entitate, şi numai una singură, în cealaltă; în acest caz se poate elimina asocierea prin reuniunea celor două tabele iniţiale şi crearea uneia noi.

asociere una la multe (sau 1-la-n) - fiecărei entităţi din prima tabelă îi corespund mai multe entităţi din cea de-a doua; aceasta este situaţia cea mai frecventă. Considerând inversa unei astfel de asocieri, observăm că fiecărei entităţi din a doua tabelă îi corespunde una singură din prima. O astfel de asociere poate fi definită între tabele STUDENTI şi CAMINE: unei entităţi din tabela CAMINE (un cămin) îi pot corespunde mai multe în tabela STUDENTI, câte una pentru fiecare student care locuieste în căminul respectiv.

asociere multe la multe (sau n-la-n) - unei entităţi din prima tabelă îi pot corespunde mai multe entităţi din a doua; de asemenea, unei entităţi din a doua îi pot corespunde mai multe din prima. Acesta este cazul cu relaţia din Fig. 6 exemplificat\ anterior.

Clasificarea după opţionalitate (obligativitatea asocierii).

Opţionalitatea precizează dacă este obligatoriu (prin natura asocierii) ca fiecare entitate dintr-o tabelă să aibă entităţi corespondente (una sau mai multe) în cealaltă tabelă, ori dacă acest lucru este opţional, deci pot exista şi entităţi în prima care să nu aibă neapărat corespondent într-a doua.

STUDENTI CURSURI

14

a. b.

Fig. 7. Asociere de tip una la multe. a) obligatorie. b) opţională Cardinalitatea şi opţionalitatea dau gradul asocierii. Gradul arată câte entităţi din

fiecare tabelă pot fi puse în corespondenţă prin asocierea dată. Cardinalitatea arată numărul maxim, iar opţionalitatea arată numărul minim.

Situaţiile pot fi exprimate intuitiv luând ca exemplu două tipuri de entitate (tabele) A şi B şi o asociere R, de tip una la multe, a lui A cu B. Vom figura grafic (Fig. 7) cele două tipuri de entitate ca mulţimi, entităţile componente ca elemente ale mulţimii, iar asocierea prin conexiunile dintre elementele mulţimilor. Diferenţa între Fig. 7 a şi Fig. 7 b exprimă opţionalitatea: în primul caz, orice entitate din A are, obligatoriu, cel puţin o entitate corespondentă în B, în timp ce în al doilea caz acest lucru este opţional.

Există diferite convenţii de notaţie pentru a figura pe diagrama entitate-asociere gradul unei asocieri. Una dintre ele, destul de simplă şi sugestivă, este convenţia SSADM (Structured System Analysis and Design Method). Pentru exemplul anterior în care R este asocierea lui A cu B, şi în care vom nota cu S inversa lui R, asocierea între B şi A, convenţia de notaţie SSADM arată ca în Fig. 8. Urmărind diagrama de la A spre B se citeşte relaţia R. Cardinalitatea acesteia este exprimată de segmentul unic ce iese din A, având semnificaţia una şi de cele trei segmente care intră în B, având semnificaţia multe; deci R este o relaţie de tip una la multe. Opţionalitatea se exprimă în convenţia SSADM prin două expresii nuanţate: "trebuie să fie asociată", cu semnificaţia "obligatoriu", şi "poate fi asociată", cu semnificaţia "opţional". În reprezentarea grafică, "trebuie să fie" este figurat prin linie continuă, iar "poate fi", prin linie punctată. Urmărind diagrama de la B spre A se citeşte, în acelaşi mod, relaţia S.

a b

Fig. 8. Reprezentarea convenţională în notaţie SSADM pentru relaţiile din Fig. 7

Deci reprezentarea din Fig. 8 a înseamnă: fiecare entitate din A trebuie să fie

asociată prin relaţia R cu (una sau) mai multe entităţi din B; fiecare entitate din B trebuie

B R R

A B A

S R A B

S R A B

15

să fie asociată prin relaţia S cu o singură entitate din A. Reprezentarea din Fig. 8 b înseamnă: o entitate din A poate fi asociată prin relaţia R cu (una sau) mai multe entităţi din B; fiecare entitate din B trebuie să fie asociată prin relaţia S cu o singură entitate din A.

În Fig. 9 sunt ilustrate asocieri de diverse grade. Fiecare schemă intuitivă este însoţită de reprezentarea convenţională SSADM.

a b c d

Fig. 9. Diferite grade de asociere între două tipuri de entităţi În Fig. 9, în a şi b sunt asocieri tip una la una, iar în c şi d sunt asocieri tip multe la

multe. O asociere tip multe la multe se poate înlocui cu două asocieri una la multe, iar aceasta se face prin crearea unei tabele intermediare. În exemplul care va urma vom discuta şi acest aspect.

Să aplicăm cele expuse în legătură cu asocierile asupra tipuilor de entităţi STUDENTI şi CURSURI. În general, un student frecventează mai multe cursuri, iar un curs este frecventat de mai mulţi studenţi; acestea ar fi cele două asocieri, una fiind inversa celeilalte. În privinţa cardinalităţii, suntem în situaţia de tip multe la multe.

S R A B

A B A B

S R A B

S R A B

S R A B

A B A B

16

Analizând opţionalitatea, putem defini asocierea "frecventează" de la STUDENTI la CURSURI ca fiind obligatorie. Deci, oricare entitate din tabela STUDENTI trebuie să fie asociată prin relaţia "frecventează" cu (una sau) mai multe entităţi din tabela CURSURI. La prima vedere asocierea inversă "este frecventat de", între CURSURI şi STUDENTI, trebuie definită ca obligatorie. Dacă, însă, ţinem cont că există cursuri facultative care sunt frecventate doar dacă există studenţi interesaţi de ele, trebuie să admitem că s-ar putea să existe vreun curs care să nu fie frecventat de nimeni. Prin urmare este preferabil ca această asociere să fie opţională, de tip poate fi (Fig. 10.).

Fig. 10. Notaţia SSADM pentru relaţiile dintre tabelele STUDENTI şi CURSURI

Vom discuta în continuare cum se realizează efectiv asocierile în cazul bazelor de

date relaţionale; să nu uităm, diagramele entitate-asociere se utilizează în proiectarea oricăror sisteme de gestiune a datelor, nu numai pentru modelul relaţional. În cazul bazelor de date relaţionale, cheia primară este aceea care, pe lângă rolul pe care îl are în localizarea datelor, este utilizată şi în stabilirea de asocieri între tabele. Astfel, pentru realizarea unei asocieri a unei tabele A cu o tabelă B, cheia primară a tabelei A, câmp sau combinaţie de câmpuri, trebuie să se regăsească şi în cadrul tabelei B.

Aplicând această idee la tabelele STUDENTI şi CURSURI constatăm că, de fapt, asocierile "frecventează" şi "este frecventat de" pe care le-am discutat anterior, nu pot fi realizate pentru că tabela STUDENTI descrie doar datele personale ale fiecărui student, iar tabela CURSURI conţine doar atribute care definesc cursul. În tabela STUDENTII nu există nici un câmp în care să se memoreze coduri de curs, deci în care să se regăsească valori ale cheii primare din CURSURI; la fel, în tabela CURSURI nu este nici un artibut care să ia valori din mulţimea matricolelor de studenţi, cheia primară a tabelei STUDENTI. Se pune problema cum pot fi concretizate aceste legături.

Soluţia de implementare a unei asocieri între două tabele este adăugarea şi în a doua tabelă, a atributelor care constituie cheia primară a primei tabele, astfel încât entităţile din cele două tabele care se conectează prin asociere să aibă aceeaşi valoare. În tabela a doua, corespondenta cheii primare din prima se numeşte cheie externă. Deci, într-o bază de date relaţională, o asociere între două tipuri de entităţi se realizează prin coincidenţa valorilor între cheia primară din prima tabelă şi cheia externă din a doua. Cheia primară este un atribut sau o combinaţie de atribute cu rolul principal de indentificare unică a entităţilor, deci nu vor exista în cadrul tabelei două înregistrări cu aceeaşi valoare a cheii primare. În ceea ce priveşte cheia externă, aceasta poate lua aceeaşi valoare în mai multe înregistrări din a doua tabelă. În acest caz se realizează o asociere de tip una la multe între prima tabelă şi cea de-a doua. Dacă şi cheia externă are valori unice, atunci asocierea este de tip una la una.

Este posibil ca, în afara cheii primare, să mai existe şi alte atribute sau combinaţii de atribute cu proprietatea de unicitate a valorii pentru toate entităţile tabelei, deci prin care acestea pot fi indentificate cu exactitate. Un astfel de atribut sau combinaţie de atribute se

frecventează

suntfrecventate de

STUDENTI CURSURI

17

numeşte cheie candidată pentru că ar putea să joace la fel de bine rolul de cheie primară. Prin urmare, o cheie candidată, ca identificator exact al entităţilor, poate fi pusă în legătură cu o cheie externă pentru definirea unei asocieri.

Revenind la implementarea asocierii dintre tabelele CURSURI şi STUDENTI, vedem că problema nu este, încă, rezolvată. Să presupunem că am include şi în tabela STUDENTI câmpul "Curs" cu intenţia de a-l desemna cheie externă pentru omologul său din tabela CURSURI. Să mai presupunem, pentru exemplificare, că cursul Mate este frecventat de studenţii 1111, 3333 şi 4444, iar cursul Info este frecventat de 2222 şi 4444. Valoarea Mate, din cheia primară a tabelei CURSURI va trebui să se regăsească în cheia externă a înregistrărilor 1111, 3333 şi 4444, iar valoarea Info, în cheia externă a înregistrărilor 2222 şi 4444 din tabela STUDENTI.

În câmpul Curs al înregistrării 4444 din tabela STUDENTI ar trebui să apară atât valoarea Mate cât şi valoarea Info, ceea ce este, evident, imposibil (Fig. 11). Problema a apărut din cauza faptului că asocierea dintre tabelele CURSURI şi STUDENTI este de tip multe la multe.

CURSURI

Curs Cadru_did Ore_curs Ore_apl Credite% TipMate ... ... ... ... ...Info ... ... ... ... ...

STUDENTI

Nume Prenume Matricola Localit Jud Camin Cam Curs... ... 1111 ... ... ... ... Mate... ... 2222 ... ... ... ... Info... ... 3333 ... ... ... ... Mate... ... 4444 ... ... ... ... ????

Fig. 11 Problemele de implementare a asocierilor multe la multe

Rezolvarea unei astfel de situaţii se face prin transformarea legăturii de tip multe la

multe în două legături de tip una la multe. Aceasta presupune introducerea unei tabele suplimentare în care cheia primară să fie o combinaţie a cheilor primare din cele două tabele iniţiale. În cazul nostru, o astfel de tabelă există deja: tabela NOTE care, în plus mai are un atribut: nota primită la examen. Diagrama entitate-asociere va arăta ca în Fig. 12.

Fig. 12 Transformarea unei asocieri multe-la-multe în două asocieri una-la-multe

În legătura de tip una la multe dintre tabelele STUDENTI şi NOTE, atributul

Matricola din prima este cheia primară, iar atributul Student_matricola din a doua este cheia externă. În legătura dintre tabelele CURSURI şi NOTE, de acelaşi tip, atributul Curs

STUDENTI NOTE CURSURI

18

din prima este cheia primară, iar atributul Curs din a doua este cheia externă. Cheia primară a tabelei NOTE este formată din câmpurile Student_matricola şi Curs.

CURSURI

Curs Cadru_did Ore_curs Ore_apl Credite% TipMate ... ... ... ... ...Info ... ... ... ... ...

STUDENTI Nume Prenume Matricola Localit Jud Camin Cam... ... 1111 ... ... ... ...... ... 2222 ... ... ... ...... ... 3333 ... ... ... ...... ... 4444 ... ... ... ...

NOTE

Student_matricola Curs Nota1111 Mate 63333 Mate 84444 Mate 42222 Info 74444 Info 10

Fig. 13. Exemplificarea asocierilor din Fig. 12

În Fig. 13 sunt arătate valorile care trebuie completate în cele trei tabele în aşa fel încât să se rezolve problema din exemplul precedent.

Să mai facem o precizare, deşi credem că lucrurile sunt de la sine înţelese: înregistrarea unei asocieri, precum şi exploatarea ulterioară a acesteia, adică toate căutările, comparaţiile de valori între cheia primară şi cheia externă, sunt făcute automat de către SGBD în urma unor comenzi primite de la utilizator. Acestea vor fi discutate mai pe larg în paragraful următor.

În încheierea acestui paragraf să mai menţionăm pe scurt un aspect legat de corectitudinea bazei de date. Asigurarea acestei corectitudini se face prin verificarea respectării unor reguli de integritate pe care datele din bază trebuie să le respecte. Pentru corectitudinea aplicării modelului relaţional este minimal obligatorie [4,5] respectarea următoarelor reguli:

- regula de unicitate a cheii care interzice ca două entităţi din aceeaşi tabelă să aibă aceeaşi valoare a cheii primare;

- regula entităţii care stabileşte că nici unul din câmpurile din componenţa cheii primare nu poate avea valoarea NULL (nu poate rămâne necompletat);

- regula integrităţii referenţiale care impune ca într-o asociere valorile cheii externe să se regăsească printre valorile cheii primare sau să fie valori NULL.

SGBD-urile relaţionale ţin cont de aceste reguli şi verifică automat respectarea lor.

19

4 Interogarea bazei de

date relaţionale

4.1. SGBD-ul şi utilizatorii săi La punctul precedent am discutat despre structurarea datelor în cadrul unei baze de

date relaţionale. În continuare ne vom ocupa, pe scurt, de partea de exploatare a unei BDR. Scopul creării unei baze de date este asigurarea accesului operativ la fondul de date încărcat în ea. Datorită modificărilor pe care le suferă acest fond, baza de date trebuie supusă unei permanente întreţineri. Iată, deci, că în general bazele de date sunt accesate de diferiţi utilizatori: unii o întreţin, alţii doar o consultă. Toate acestea, prin intermediul SGBD-ului.

În cel mai general sens, utilizatorii unui SGBD pot fi împărţiţi în utilizatori indirecţi şi utilizatori direcţi.

Utilizatorii indirecţi apelează la SGBD prin intermediul altor persoane şi a un rol pasiv faţă de baza de date. De exemplu, un călător apelează o bază de date a SNCFR atunci când cumpără un bilet din Gara de Nord; deşi poate că nu se gândeşte la acest lucru, ca utilizator indirect al bazei de date el are câteva avantaje. Pe de o parte, poate să-şi cumpere biletul de la orice casierie şi nu numai de la "Ghişeul nr. ..."; pe de altă parte, are garanţia că nu va cumpăra un tichet de loc care a mai fost vândut o dată la altă casă sau la agenţia de voiaj.

Utilizatorii direcţi ai SGBD-ului sunt cei care ne interesează aici în primul rând. Ei folosesc nemijlocit instrumentele oferite de SGBD. Există şi aici o distincţie: într-o categorie este informaticianul care foloseşte SGBD-ul ca mediu de lucru pentru realizarea bazei de date şi care, ulterior, se va ocupa de întreţinerea (administrarea) acesteia, iar în cealaltă categorie este utilizatorul final, adică beneficiarul informaţiilor din bază. Efortul informaticianului care dezvoltă şi întreţine baza de date este pus în slujba utilizatorului final. De când au apărut microcalculatoarele această distincţie nu mai este aşa de netă. Operând direct le calculator, utilizatorul final îşi intreţine singur baza de date. El devine, în bună măsură, administratorul acesteia: nu va căuta, în general, să modifice structurarea logică a datelor (tabelele, asocierile etc.), dar va dori să aibă la dispoziţie mijloace puternice şi

20

flexibile pentru tratarea celorlalte aspecte ale administrării: adăugări de înregistrări noi, modificări de câmpuri etc. De asemenea, el va avea nevoie de modalităţi eficace de regăsire a informaţiilor stocate. Un astfel de utilizator este şi inginerul care foloseşte o bază de date pentru alegerea materialelor.

Atunci când apelează la baza de date utilizatorul final se va gândi la tabelele în care sunt înregistrate datele, la operaţii de actualizare a acestor date, la interogarea (consultarea) bazei de date, la editarea de rapoarte (liste) prin extragerea unor informaţii stocate în ea. Se observă că utilizatorul final are în vedere, în general, submulţimi ale unei mulţimi de înregistrări din baza de date. Aceste submulţimi se definesc prin enunţarea unor criterii. Sa dăm câteva exemple.

a) Este necesară lista studentilor care locuiesc in căminul C2 la camera 40 b) Care sunt cursurile opţionale din anul al doilea (semestrele 3 şi 4) c) S-a dat examen la Mate. Este necesară selectarea tuturor studenţilor care au frecventat cursul de Mate pentru a le completa notele luate. Lista să fie pe grupe, alfabetic.

Toate situaţiile din exemplele de mai sus se rezolvă prin interogarea bazei de date; am subliniat condiţiile ce definesc diferitele submulţimi de înregistrări care vor rezulta în urma interogării, adică criteriile de selecţie. Un aspect care trebuie remarcat este acela că interogarea poate fi făcută în diverse scopuri: afişarea unor informaţii, eliminarea unor înregistrări, completarea unor câmpuri etc. Din ultimul exemplu se mai observă ceva. În multe cazuri, pentru a obţine submulţimile respective trebuie investigate mai multe tabele; pentru exemplul c) acestea sunt STUDENTI şi NOTE.

4.2. Limbajul de manipulare a datelor Instrumentele de interogare a bazei de date relaţionale sunt oferite de SGBDR prin

intermediul unui limbaj de manipulare a datelor. Crearea unor asfel de limbaje a fost, pe lângă preocuparea pentru metodele de reprezentare a datelor, o a doua preocupare majoră a cercetătorilor din sfera bazelor de date.

Suportul teoretic pentru dezvoltarea limbajelor relaţionale de manipulare a datelor este algebra relaţională. Aceasta conţine un set de operatori1 relaţionali a căror aplicare succesivă permite realizarea de combinaţii pentru regăsirea oricăror submulţimi ale datelor colectate bază. Dezvoltarea limbajelor de manipulare a datelor bazate pe algebra relaţională a fost stimulată de mai multe considerente, unul important fiind acela că formalizarea matematică a operatorilor relaţionali îşi găseşte un corespondent imediat în fraze-şablon exprimate în limbaj natural. Algebra relaţională oferă deci o formă de exprimare uşoară, dar în bună măsură standardizată, a cererilor de interogare a bazei de date. Astfel, se poate vorbi [5] de două posibilităţi de scriere a expresiilor algebrei relaţionale: forma greacă (adică cea folosind simbolistica specifică matematicii) forma engleză (adică cea folosind fraze-şablon). Această din urmă formă poate constitui sursa pentru implementarea instrucţiunilor unui limbaj puternic de manipulare a datelor, aşa cum este, de exemplu, SQL. În ceea ce ne priveşte, ne putem gândi la o traducere în română a formei engleze a expresiilor relaţionale

1 În sens general, un operator este o funcţie care defineşte o operaţie. Cu toţii am avut ocazia să utilizăm operatori deşi acest lucru nu era, poate, exprimat explicit: încă în liceu, am efectuat operaţii de adunare a două numere complexe, de intersecţie a două mulţimi, de derivare a unei funcţii, deci am aplicat operatorii de adunare, de intersecţie, de derivare. În latină, operator = "care acţionează asupra cuiva"

21

şi, în acest fel, am avea la dispoziţie o posibilitate de descriere "pe hârtie", în româneşte, a operaţiilor de manipulare a conţinutului bazei de date. Am obţine ceva asemănător exprimării în pseudo-cod, care este utilizată în proiectarea programelor clasice (de tip COBOL, PASCAL,...) pentru descrierea preliminară, în limbaj natural, a succesiunii prelucrărilor.

Operatorii acţionează asupra tabelelor. Există diferite clasificări ale acestora. O vom cita aici pe cea din [4] deoarece pune în evidenţă, într-o categorie separată, acei operatori care sunt specifici strict algebrei relaţionale.

Operatori tradiţionali pe mulţimi: reuniunea, intersecţia, diferenţa, produsul cartezian

Operatori relaţionali speciali: selecţia, proiecţia, joncţiunea, diviziunea, etc. Pentru ilustrare, vom da detalii în legătură cu operatorul de selecţie şi cel de proiecţie.

Selecţia. Scopul aplicării acestui operator este de a regăsi anumite linii (tupluri) dintr-o tabelă.

Care sunt aceste linii, rezultă din impunerea unei condiţii, numită predicat, care va fi verificată în legătură cu fiecare tuplu. Submulţimea rezultat este formată din liniile pentru care predicatul este adevărat. În Fig. 14 a se ilustrează intuitiv aplicarea operatorului de selecţie; liniile de culoare mai închisă formează submulţimea celor care îndeplinesc condiţia.

Să exprimăm operaţia în scriere greacă şi în scriere engleză Scrierea greacă. σpredicat (nume-tabelă) σ este notaţia pentru operatorul de selecţie, indicele precizează predicatul (condiţia),

iar parametrul nume-tabela indică tabela asupra căreia acţionează selecţia. Scrierea engleză: SELECT nume-tabela WHERE predicat [GIVING tabelă-nouă];

Precizând că SELECT înseamnă "selectează", WHERE înseamnă "unde", iar GIVING înseamnă "dând, rezultând", să admitem că această formă de scriere, deşi mai lungă, este mai atractivă. Să mai observăm că, făcând o traducere a propoziţiei englezeşti, putem obţine un "pseudocod" în limba română. Rămâne de discutat dacă merită efortul. Să mai observăm că în scrierea engleză mai apare şi segmentul GIVING... ; el este scris în paranteze pătrate, aceasta însemnând că utilizarea sa este opţională. Atunci când este folosită, partea GIVING... indică numele unei noi tabele care va fi creată din prima, prin aplicarea operatorului de selecţie.

a b

Fig. 14. a) Acţiunea operatorului de selecţie b) Acţiunea operatorului de proiecţie

22

Proiecţia.

Operatorul de proiecţie trebuie aplicat atunci când se doreşte alegerea unor anumite coloane ale tabelei.

Scrierea greacă: πcol1,...,colN (nume-tabelă) π este simbolul operatorului de proiecţie nume-tabelă identifică tabela asupra căreia acţionează operatorul col1, ..., colN este lista coloanelor vizate. O imagine intuitivă este dată în Fig. 14 b; coloanele de culoare mai închisă sunt cele

asupra cărora a acţionat operatorul de proiecţie. Scrierea engleză: PROJECT nume-tabelă OVER (col1,...,colN)[GIVING tabelă-nouă]; Compunerea operatorilor. Operatorii fiind funcţii, se poate vorbi despre compunerea acestora. Să luăm ca

exemplu compunerea operatorilor de selecţie şi de proiecţie. Scrierea greacă: πcol1,...,colN (σpredicat (nume-tabelă)) În scrierea engleză apar doi paşi consecutivi:

SELECT nume-tabelăWHERE predicatGIVING tabelă-temporară;PROJECT tabelă-temporarăOVER col1, ..., colN;

Se observă apariţia unei tabele temporare care este necesară pentru a transforma

rezultatul operaturului SELECT în parametru de intrare pentru operatorul PROJECT. În scriere engleză, compunere celor doi operatori ai algebrei relaţionale s-a tradus

într-o aplicare succesivă a acestora. În cazul de faţă, ordinea de aplicare a operatorilor ar putea fi inversată: întâi proiecţia, apoi selecţia. În alte cazuri, însă, este importantă ordinea aplicării operatorilor la fel cum, în cazul unui program (de exemplu în limbajul BASIC), ordinea instrucţiunilor este esenţială pentru corectitudinea desfăşurării prelucrărilor. Aceasta este o abordare de tip limbaj procedural: trebuie descris fiecare pas, precum şi ordinea în care aceştia trebuie executaţi. Chiar şi pentru cazul discutat se poate analiza dacă nu cumva adoptarea uneia dintre succesiunile de aplicare a operatorilor este mai avantajoasă decât cealaltă pentru a mări viteza de extragere a submulţimii finale. Abordarea procedurală poate crea dificultăţi utilizatorilor mai puţin experimentaţi. Există o alternativă pe care o putem adopta, iar despre ea se va discuta mai jos, în partea dedicată limbajului SQL.

Această discuţie a operatorilor de selecţie şi de proiecţie a fost făcută cu scopul de a ilustra conceptul de operator relaţional. Tratări detaliate, în diferite maniere, ale acestei chestiuni se găsesc, de exemplu, în lucrările [4] şi [5].

23

Orice SGBD pune la dispoziţie un limbaj pentru descrierea şi manipularea datelor. Prin intermediul său se realizează practic toate acţiunile legate de o bază de date: creare, întreţinere, exploatare. Dar, deoarece majoritatea acţiunilor asupra unei BD se execută în urma unei interogări a acesteia, iar interogarea se face prin exprimarea unei cereri, limbajele de descriere şi manipulare a datelor mai sunt numite şi limbaje de interogare, sau limbaje de cereri. În cazul BD relaţionale, limbajul trebuie să includă comenzi pentu definirea colecţiei de tabele şi a tuturor aspectelor legate de aceasta, pentru implementarea conceptelor algebrei relaţionale, pentru accesarea datelor, pentru organizarea prezentării rezultatelor (pe ecran, sau la imprimantă). Cel mai cunoscut rezultat în acest domeniu este limbajul SQL (Structured Query Language). Există astăzi câteva standarde SQL; majoritatea SGBD-urilor relaţionale includ în limbajul de descrierea şi manipluarea datelor principalele comezi ale acestui limbaj. Vom face o descriere în linii generale a instrumentelor pe care SQL le pune la dispoziţie.

Câteva dintre caracteristicile care au asigurat popularitatea limbajului SQL sunt legate în primul rând de accesibilitatea pe care acesta o oferă; acest lucru se observă imediat dacă examinăm implementarea noţiunilor algebrei relaţionale. Astfel, cererile exprimate în SQL sunt foarte lizibile, sintaxa limbajului fiind asemănătoare cu "scrierea engleză" a operatorilor relaţionali. Mai mult decât atât, SQL este mai degrabă un limbaj declarativ decât unul procedural. Aceasta înseamnă următorul lucru: utilizatorul trebuie să precizeze în cadrul comenzii doar care sunt criteriile care definesc submulţimea rezultat (al interogării). Secvenţa de operatori relaţionali care trebuie aplicaţi, precum şi operaţiile intermediare asupra structurilor de date sunt în sarcina interpretorului1 SQL; ele rămân invizibile pentru cel care a introdus comanda.

Vom da în continuare câteva exemple de comenzi SQL pentru a ilustra instrumentele pe care acesta le pune la dispoziţia utilizatorului. În redactarea formei generale a comenzilor vom folosi câteva convenţii de notaţie, consacrate, de altfel. Să le explicăm:

- părţile din comandă incluse în paranteze pătrate [ ] sunt opţionale şi, în general, utilizarea, sau nu, a unui astfel de segment opţional dă rezultate diferite;

- bara verticală | arată că trebuie utilizată una din părţile separate prin acest semn, ca o variantă din mai multe posibile; în multe cazuri una dintre ele este implicită, adică va fi aplicată automat de către interpretor atunci când nu s-a introdus în comandă nici una dintre variante;

- trei puncte ... arată că grupul de elemente precedent poate fi folosit de mai multe ori în cadrul comenzii.

1 Interpretor - un program care traduce în cod maşină şi pune efectiv în execuţie, sub această formă, instrucţiunile/comenzile scrise într-un limbaj de programare. De exemplu, mulţi tineri au învăţat să scrie programe în limbajul BASIC. Doar o parte din ei ştiu că maşina ("calculatorul") nu poate decodifica direct instrucţiunile BASIC pentru a le executa; singurele instrucţiuni pe care maşina, mai precis microprocesorul, "le înţelege" şi le poate pune în execuţie sunt cele reprezentate într-un cod binar, specificat la proiectarea acestuia şi care este numit, din acest motiv, cod maşină. Faptul că instrucţiunile programului BASIC sunt executate, se datorează interpretorului BASIC, un program care traduce instrucţiunile din acest limbaj în cod maşină, ele devenind, astfel, executabile. La fel se petrec lucrurile şi în cazul altor limbaje, de exemplu SQL. A lucra ("la calculator") într-un limbaj de programare înseamnă, implicit, a folosi interpretorul pentru acel limbaj. Există şi o altă categorie de programe destinate traducerii dintr-un limbaj de programare în cod maşină, dar care lucrează într-o manieră diferită faţă de interpretoare; un astfel de program se numeşte compliator. Pentru limbajul BASIC, de exemplu, există atât interpretoare, cât şi compilatoare.

24

Comanda CREATE TABLE

Comanda se foloseşte pentru a crea o tabelă şi are sintaxa în următoarele variante: CREATE TABLE nume-tabelă (nume-coloană tip-dată [NULL|NOT NULL] ... ); CREATE TABLE nume-tabelă (nume-coloană tip-dată [NULL|NOT NULL] ... ) AS cerere;

Identificatorul nume-tabelă arată numele pe care îl va primi tabela nou creată. În continuare se vor enumera în paranteză precizările necesare pentru fiecare coloană (atribut): numele acesteia, ce fel de date pot fi stocate în ea (numere, texte etc.) şi care este dimensiunea acestor date.

Să insistăm mai mult asupra opţiunii NULL|NOT NULL. Pentru fiecare coloană, se specifică una din variantele NULL sau NOT NULL prin care se arată dacă este sau nu obligatoriu ca, la încărcarea efectivă a unei noi înregistrări în tabelă, coloana respectivă să aibă neapărat o valoare, sau ar putea fi lăsată, eventual, necompletată; NOT NULL este varianta care impune obligativitatea completării, iar NULL este varianta implicită. Să mai adăugăm că această opţiune este o reflectare a Regulii 3 a lui Codd care impune tratarea riguroasă a valorilor NULL: Un SGBD relaţional trebuie să asigure utilizarea valorii NULL; valoarea NULL semnifică lipsa informaţiilor în legătură cu o anumită dată, indiferent de tipul acesteia, deci trebuie să fie distinctă de valoarea numerică zero, sau de şirul de caractere vid. Orice tabelă trebuie să aibă măcar un câmp pentru care să se impună condiţia NOT NULL, adică pentru care să fie obligatorie existenţa unei valori completate: este vorba de câmpul/câmpurile care constituie cheia primară a tabelei.

Exemplu. Vom scrie comanda pentru a crearea tabelei STUDENTI : CREATE TABLE STUDENTI(Nume CHAR (25) NOT NULL,Prenume CHAR (30) NOT NULL,Matricola NUMBER (4,0) NOT NULL,Localit CHAR (25) NOT NULL,Jud CHAR (2) NOT NULL,Camin CHAR (5),Cam NUMBER (3,0)); Comanda de mai sus este pentru crearea tabelei STUDENTI. În paranteză sunt

enumerate câmpurile din care este compusă această tabelă precizându-se, pentru fiecare, tipul, dimensiunea şi dacă este obligatorie completarea sa.

Să mai facem precizarea, valabilă pentru toate comenzile, că între implementările standardului SQL realizate de diferite firme de software există diferenţe; de pildă, declararea tipurilor de date (caracter, numeric etc.) poate avea alte forme decât în exemplul dat mai sus.

În legătură cu o tabelă creată există comenzi de manipulare a datelor, cum sunt: INSERT - pentru introducere de noi entităţi (înregistrări) în tabelă; DELETE - pentru eliminare de entităţi din tabelă; UPDATE - pentru modificarea valorilor unuia sau mai multor atribute (coloane) ale

tabelei (Update = aducere la zi, actualizare);

25

DROP TABLE - pentru eliminarea unei tabele din arhitectura bazei de date; ALTER TABLE - pentru modificarea structurii tabelei (modificări, adăugări de

coloane).

Comanda SELECT

Aceasta este comanda principală pentru interogarea bazei de date; este folosită interactiv, pentru a se obţine un răspuns imediat, sau poate fi inclusă într-un program pentru a participa la operaţii complexe de regăsire şi manipulare a datelor.

Sintaxa de bază este: SELECT listă-câmpuri-1FROM nume-tabelă[WHERE criteriu-de-căutare-1][GROUP BY listă-câmpuri-2][HAVING criteriu-de-căutare-2][ORDER BY listă-câmpuri-3];

O traducere a cuvintelor cheie sugerează imediat sensul frazei: SELECT = selectează, FROM = din, WHERE = unde, GROUP BY = grupează după, HAVING = având, ORDER BY = ordonează după. Celelalte elemente din comandă au semnificaţiile următoare:

listă-câmpuri-1 arată câmpurile (coloanele) care interesează din tabelă, deci dă informaţii pentru aplicarea operatorului de proiecţie;

nume-tabelă arată tabela în care se face căutarea; criteriu-de-căutare-1 arată condiţiile pe care să le îndeplinească

înregistrările care vor fi selectate, deci constituie predicatul pentru operatorul de selecţie; listă-câmpuri-2 din clauza GROUP BY arată cum vor fi grupate înregistrările

extrase prin interogare; criteriu-de-căutare-2 din clauza HAVING arată care dintre înregistrările

grupate (ca efect al lui GROUP BY) să fie afişate, deci exprimă predicatul într-o nouă aplicare a operatorului de selecţie;

listă-câmpuri-3 din clauza ORDER BY arată ordinea în care vor fi afişate înregistrările selectate; pentru fiecare câmp din listă, reprezentând un criteriu de sortare, se va preciza varianta de ordonare, ASC (ascendentă) sau DESC (descendentă).

Exemplu. Vom scriem fraza SELECT pentru afişarea student[ilor care locuiesc `n c\minul C2, camera 40.

SELECT Nume, Prenume, MatricolaFROM STUDENTIWHERE Cămin = “C2” AND Cam = “40”ORDER BY Nume ASC, Prenume ASC; Comanda SELECT se foloseşte şi pentru căutări mai complexe. În unele situaţii

căutarea se face prin investigarea mai multor tabele. Într-un astfel de caz, listă-câmpuri-1 va conţine numele câmpurilor care interesează din fiecare tabelă, iar în clauza FROM se va preciza lista tabelelor care vor fi examinate. Din punctul de vedere al algebrei relaţionale, în acest tip de căutare este folosit şi operatorul de joncţiune (în engleză, join).

În alte situaţii se foloseşte o comandă SELECT pentru exprimarea unei "subcereri" în cadrul unei cereri, exprimată şi ea printr-o frază SELECT; operaţia se numeşte imbricare (a unei/unor comenzi în cadrul alteia). În aceste cazuri, subcererile SELECT vor apărea ca predicate în clauzele WHERE şi/sau HAVING ale cererii generale, putând avea, la rândul

26

lor, subcereri incluse în caluzele proprii. De asemenea, sunt implicate, de obicei, mai multe tabele.

Eumerarea celor câteva comenzi, făcută mai sus, a avut rolul de a ilsutra caracteristicile generale ale limbajului SQL şi modul său de folosire. S-a observat caracterul declarativ al comenzilor acestuia: în fraza SELECT, de pildă, utilizatorul descrie, de fapt, rezultatul pe care vrea să-l obţină în urma interogării, iar interpretorul SQL este cel care aplică, în ordinea "ştiuă de el", operatorii necesari din algebra relaţională. SQL nu este, totuşi, un limbaj pur declarativ; el are şi trăsături procedurale, un exemplu fiind folosirea blocurilor de comenzi imbricate.

4.3. Indexare Indexarea este o metodă de sporire a vitezei de acces la datele din bază. Conceptul

este legat de aspecte privind organizarea la nivel fizic a datelor; pentru a-l explica, vom puncta din nou câteva momente din istoria evoluţiei tehnicii de calcul. Vom face şi unele analogii cu situaţii pe care le întâlnim zi de zi, care nu au (aparent) nici o legătură cu calculatoarele.

Primele suporturi de mare capacitate pentru stocarea datelor au fost benzile magnetice. Entităţile unei colecţii logice (cum sunt liniile unei tabele) erau înregistrate secvenţial. Pentru a ajunge la o anumită înregistrare, trebuiau parcurse toate înregistrările (deci o "citire în gol") până era găsit ceea ce se căuta. Am putea compara acest lucru cu căutarea unei melodii pe o bandă de magnetofon: ar trebui, în principiu, să le ascultăm pe toate până apare cea căutată. Acesta este accesul secvenţial la înregistrări. Dacă înregistrarea se afla spre sfârşitul benzii, timpul necesar regăsirii era de ordinul minutelor.

Apariţia discurilor magnetice ca nouă soluţie de stocare, a revoluţionat performanţele în privinţa vitezei de acces la informaţii. Pe discul magnetic informaţiile sunt înregistrate pe piste concentrice, iar pistele sunt împărţite în sectoare (Fig 15). Toate pistele au acelaşi număr de sectoare, toate sectoarele au aceeaşi capacitate de înregistrare (deci pe pistele exterioare înregistrarea este mai "rarefiată" decât pe cele interioare), iar această capacitatea are o valoare fixă, independentă de natura informaţiilor care se înregistrează pe disc. Sectorul este unitatea elementară de transfer între disc şi memorie: la o citire de pe (ori la o scriere pe) disc se transferă un întreg sector de informaţii; el reprezintă înregistrarea fizică. Capul de citire/scriere se deplasează pe direcţie pe direcţie radială faţă de disc şi se poziţionează direct pe pista pe care se află înregistrarea dorită (am luat în discuţie citirea de pe disc, dar lucrurile se petrec similar şi la scriere); discul se învârteşte, iar sectorul pe care se află înregistrarea căutată este citit (copiat în memorie) în momentul trecerii prin dreptul capului. Până aici am descris principiul de înregistrare pe o faţă a discului. Dischetele (Floppy Disk) au piste pe ambele feţe, iar staţiile de citire/scriere au două capete, câte unul pentru fiecare faţă; ele se deplasează solidar, poziţionându-se simultan, pe ambele feţe, pe pistele cu acelaşi număr de ordine; pistele cu acelaşi număr de ordine de pe fiecare faţă formează un cilindru. Deci, la un moment dat, capetele sunt poziţionate pe un cilindru, iar unul din ele citeşte sau scrie un sector al acestuia. La discurile dure (Hard Disk) principiul general este acelaşi, dar aici este vorba de mai multe discuri fixate pe un ax comun; deci sunt mai multe feţe şi numărul corespunzător de capete de citiree/scriere. Bineînţeles, un cilindru este format din toate pistele de pe fiecare faţă care au acelaşi număr de ordine. În Fig. 15 sunt ilustrate foarte sumar cele descrise mai sus.

Acest principiu de funcţionare prin care capetele de citire/scriere se poziţionează pe cilindrul unde se află înregistrarea reprezintă accesul direct la

27

informaţie. Datorită acestuia, precum şi ca urmare a progreselor în tehnologia de fabricaţie, în cazul discurilor dure timpul de acces se măsoară, astăzi, în milisecunde. Dacă la accesul secvenţial am făcut o analogie cu banda audio pentru a arăta cum funcţionează banda magnetică pentru stocarea datelor, în cazul discurilor am putea face, iată, o analogie în sens invers. Toată lumea ştie că, în prezent, sistemul cel mai performant de înregistrare a muzicii este CD-ul; mai ştim că aparatele CD-Player dau posibilitatea selectării prealabile a succesiunii de melodii (în maniera 1,5,3,9,...) care vor fi reproduse. Cei care s-au întrebat cum se realizează acest lucru trebuie doar să-şi amintească de principiul accesului direct de la discurile magnetice şi să facă analogia necesară.

Pentru a beneficia de avantajele accesului direct mai trebuia rezolvată o problemă: cum se stabileşte locul în care se găseşte înregistrarea căutată? În lipsa unor informaţii de localizare, pistele şi sectoarele ar trebui parcurse tot secvenţial până la înregistrarea respectivă, deci avantajul accesului direct ar dispărea. Indexarea a fost una din metodele (nu singura) de a introduce informaţii de localizare a înregistrărilor în cadrul fişierelor. Tehnica a fost preluată şi este folosită în tehnologia bazelor de date relaţionale pentru a mări viteza de căutare.

Fig. 15. Principiul de înregistrare a informaţiilor pe Hard Disk; toate pistele cu acelaşi număr de ordine formează un cilindru. Ideea este aceeaşi ca în cazul folosirii unui manual. Dacă dorim să citim un anumit

capitol am putea să răsfoim cartea, pagină cu pagină, până găsim capitolul, dar această "accesare secvenţială" ar lua prea mult timp. Bineînţeles, mult mai rapid este să consultăm întâi cuprinsul care este, iată, o tabelă index în care sunt listate nişte chei de acces (denumirile capitolelor) însoţite de informaţii de localizare (numerele paginilor); căutăm în tabelă (cuprins) cheia de acces (numele capitolului), luăm informaţia de localizare

28

corespunzătoare (numărul paginii), apoi mergem direct la pagina respectivă, deci facem o accesare directă a fondului de informaţii. O altă situaţie, la fel de frecvent întâlnită: dorim informaţii în legătură cu o anumită noţiune tratată în carte. Am putea să folosim aceeaşi metodă, depistând capitolul în care ştim că se află noţiunea, iar în cadrul capitolului căutăm secvenţial. Dar ar fi şi mai convenabil dacă manualul ar avea, ca anexă, un indice alfabetic al noţiunilor, deci o a doua tabelă index, organizată altfel; în ea am găsi mai uşor noţiunea care ne interesează (cheia de acces) şi paginile la care se discută despre ea (informaţiile de localizare). Bineînţeles, aceste două tabele index (cuprinsul şi indicele alfabetic) ocupă pagini suplimentare ("spaţiu de stocare") şi au consumat timp pentru a fi puse al punct, dar acesta este preţul care trebuie plătit pentru a avea la dispoziţie două instrumente de acces direct, rapid, la fondul de informaţii. Să mai subliniem şi faptul, foarte important, că cele două tabele index de care am vorbit mai sus rezolvă căutarea rapidă în două tipuri de situaţii care apar foarte frecvent, dar nu rezolvă orice fel de căutare. Dacă dorim, de exemplu, să revedem Figura 81 din carte, nici cuprinsul, nici indicele alfabetic nu ne ajută cu nimic şi va trebui să folsim tot accesul secvenţial. Am putea să construim o a treia tabelă index, pentru figuri; trebuie, însă, să cântărim dacă ea va fi atât de des folosită pentru a merita să consumăm timp şi pagini de carte pentru a o realiza.

Aplicând ideea la bazele de date relaţionale, rezultă imediat că indexarea unei tabele înseamnă crearea unor tabele suplimentare speciale, tabele index, pentru accesarea directă, în diferite moduri, a informaţiilor din tabela vizată. O tabelă index este definită de către utilizator printr-o comandă cu caracter declarativ şi este generată automat de către SGBD, în urma acestei comenzi. Ea are două coloane: prima coloană conţine valorile cheii de indexare (de acces), iar în a doua coloană se află, corespunzător, pointeri (informaţii de localizare) la înregistrările din tabelă. Cheia din tabela index se defineşte ca o combinaţie de câmpuri din structura înregistrării tabelei care a fost supusă indexării şi foloseşte tocmai la identificarea înregistrărilor (entităţilor). Tabelele index sunt folosite automat de către SGBD. Când face o căutare într-o tabelă a bazei de date folosind o tabelă index asociată ei, SGBD-ul caută valoarea cheii de indexare pentru a identifica înregistrarea, apoi foloseşte pointerul (informaţia de localizare) pentru a accesa direct linia corespunzătoare din tabela de origine.

SQL posedă comandă pentru indexare: comanda CREATE INDEX ("crează index"). Sintaxa de bază a comenzii este:

CREATE [UNIQUE] INDEX nume-indexON (coloană1 [ASC|DESC], ...);

nume-tabela este tabela din baza de date care este supusă indexării. coloană1, coloană2, ... sunt coloanele din tabelă care vor participa (în

această ordine!) la formarea cheii de acces (coloana stângă a tebelei index); pentru fiecare coloană se specifică ordinea de sortare a valorilor din ea: ascendentă (ASC), care este şi varianta implicită, sau descendentă (DESC).

nume-index este numele pe care îl primeşte tabela index nou creată. Utilizatorul nu va folosi explicit acest nume atunci când va face interogări ale bazei de date; după cum am văzut mai sus, sintaxa comenzii SELECT nu conţine nici un segment referitor la index. SGBD-ul decide dacă, pentru rezolvarea unei cereri de interogare, îi este utilă folosirea uneia din tabelele index asociate tabelei investigate. Rolul lui nume-index este de a indentifica tabela index atunci când se va dori eliminarea ei, deci când se va renunţa la indexarea respectivă; comanda corespunzătoare acestei operaţii este DROP INDEX.

UNIQUE este o opţiune care se foloseşte pentru a preveni apariţia valorilor duplicate în câmpurile indexate. Dacă această opţiune a fost folosită şi se face o tentativă de introducere în tabelă a unei linii (înregistrări) care are aceeaşi valoare a indexului cu o

29

înregistrare deja existentă, introducerea va fi refuzată, iar pe ecran va apărea un maesa de eroare.

Exemplu. CREATE UNIQUE INDEX INDX_STUDENTION STUDENTI (Nume, Matricola);

S-a indexat tabela STUDENTI după câmpurile Nume şi Matricola; aceste câmpuri

vor forma, în ordinea specificată în comandă, cheia de acces (partea stângă a tabelei index). Pentru ambele câmpuri se foloseşte ordonarea crescătoare (implicită). Tabela index a primit numele INDX_STUDENTI.

Interogările SQL funcţionează şi fără ajutorul tabelelor index, dar indexarea aduce un plus de viteză, în special când este vorba de tabele de mari dimensiuni. Pe de altă parte, trebuie ţinut cont de faptul că fiecare adăugare a unui index nou unei tabele încetineşte viteza la operaţiile de actualizare (adăugări şi ştergeri de linii). Făcând din nou apel la comparaţia cu cartea vom vedea că, într-adevăr, aşa este. Dacă autorul cărţii introduce un nou capitol printre cele existente, va trebui să modifice cuprinsul (prima "tabelă index"): va introduce titlurile capitolului şi ale paragrafelor şi, din cauza faptului că numerotarea paginilor s-a schimbat, va trebui să facă modificările necesare şi în cuprins. Astfel de modificări de conţinut şi localizare, dar şi mai laborioase, trebuie făcute şi asupra indicelui alfabetic (a doua "tabelă index") unde apar noi termeni proveniţi din capitolul nou introdus. De aceea spuneam la locul respectiv că, înainte de a introduce o nouă "tabelă index" (pentru figuri, de exemplu) trebuie cântărit dacă aceasta va fi suficient de utilă pentru a justifica efortul creării şi întreţinerii sale ulterioare. Deci, atunci când studiem oporunitatea creării unui index asociat unei tabele a bazei de date, trebuie să apreciem dacă avantajul pe care îl obţinem prin mărirea vitezei de căutare la consultarea tabelei este mai mare decât preţul care trebuie plătit, adică micşorarea vitezei la actualizare. În bună măură, acest lucru poate fi decis, nu prin calcule, ci prin experimentări asupra bazei de date; oricum, eficienţa indexării, chiar numai în ce priveşte consultarea, se pune doar în legătură cu tabele care au de la câteva sute de înregistrări în sus.

4.4. Tenhici declarative de manipulare a datelor. Am arătat mai sus că SQL este un limbaj "mai degrabă declarativ, decât procedural",

fiind mai apropiat de maniera declarativă , dar având şi caracteristici procedurale. Din acest punct de vedere, el ocupă o poziţie intermediară între limbajele procedurale, cum sunt COBOL, BASIC, PASCAL etc., numite limbaje de generaţia a treia sau 3GL (third generation language) şi o altă categorie, 4GL, limbajele de generaţia a patra (fourth generation language) la care exprimarea declarativă este o caracteristică fundamentală. Deşi nu este stabilită o definiţie universal acceptată pentru limbajele de generaţia a patra, noţiunile prezentate în continuare sunt considerate [5] ca având caracteristici de tip 4GL. Ele sunt implementate în cadrul SGBD-urilor moderne ca instrumente menite să asigure, pe de o parte, facilităţi suplimentare de interogare la îndemâna utilizatorilor neinformaticieni şi, pe de altă parte, mijloace de creştere a productivităţii muncii pentru informaticienii care proiectează baze de date de mare complexitate. La toate exemplele care vor urma se observă o trăsătură comună care a determinat includerea acestor facilităţi în categoria 4GL: utilizatorul descrie ceea ce doreşte să obţină, iar componenta software corespunzătoare face restul. O caracteristică importantă este aceea nu mai trebuie introduse de la tastatură textele comenzilor dorite (ca în SQL, de exemplu), ci există mijloace garfice, mult mai comode, de

30

dialog cu sistemul1. Vom trece în revistă, în acest context, două tehnici de interogare, QBE şi QBF, după care vom discuta, pe scurt, despre editarea rapoartelor.

QBE.

În traducere liberă, QBE (Query By Example), înseamnă interogare prin exemplu. Aceasta este una din modalităţile grafice, neprocedurale, de exprimare a unei cereri de interogare. Utilizatorul are la dispoziţie, pe ecran, o machetă a tabelei; el va exprima cererea prin completarea spaţiilor libere din machetă.

Exemplu. Pentru tabela STUDENTI, macheta QBE va avea forma din Fig. 16.

STUDENTI Nume Prenume Matricola Localit Jud Camin Cam

Fig. 16 Macheta tip QBE pentru tabela STUDENTI

Pentru a afla studen]ii care locuiesc `n c\minul C2 la camera 40, utilizatorul va completa rubricile corespunzătoare din machetă:

STUDENTI Nume Prenume Matricola Localit Jud Camin Cam

40

Fig. 17 Exemplu de completare a machetei QBE

Am dat mai sus un exemplu foarte simplu pentru ilustrare. Tehnica QBE are, însă, posibilităţi mult mai complexe: în completarea rubricilor se poate folosi o mare diversitate de operatori, interogarea poate fi aplicată mai multor tabele, macheta poate avea linii suplimentare, de exemplu pentru precizarea unor criterii de sortare etc.

QBF.

Am putea traduce QBF (Query By Form) ca "cerere prin formular". Cuvântul englez "form" are multe sensuri, printre care formă şi formular. Am adoptat această din urmă traducere deoarece credem că ilustrează cel mai bine intenţia care pare că a stat iniţial la baza dezvoltării acestei tehnici: apropierea manipulării bazei de date de modul tradiţional de lucru, cu formulare "de hârtie". Oricine se întâlneşte, aproape zilnic, cu formularistica tipizată: la locul de muncă, la bibliotecă, la poştă, la bancă; în fiecare din aceste situaţii, formularul are legătură cu un fond de date (stocuri de materiale, liste de abonaţi, conturi financiare ş.a.m.d.). Formularul devenind o "componentă a modului de viaţă", apare normală conceperea unei modalităţi dialog cu baza de date în această manieră. Ideea generală este că

1 Comunicarea cu utilizatorul prin mijloace grafice este, de altfel, o caracteristică generalizată la produsele software moderne, fiind denumită, generic, GUI (Graphical User Interface - "interfaţă grafică cu utilizatorul"). În privinţa calculatoarelor din familia PC, această manieră de realizare este promovată, în prezent, chiar prin standardul neoficial pe care l-a impus noul sistem de operare WINDOWS care este, el însuşi, produs tip GUI.

31

datele din bază (conţinutul unei tabele, rezultatul unei interogări) pot fi vizualizate în două moduri: ca o listă sau ca un formular1.

Imaginea de tip listă (List View) este tabelară. Pe ecran apar mai multe înregistrări, fiecare ocupând o linie a listei. În cazul vizualizării unei singure tabele, această imagine este aproape identică cu macheta tabelei, aşa cum a fost ea definită şi inclusă în diagrama entitate-relaţie la proiectarea bazei de date. Bineînţeles, imaginea de tip listă poate arăta nu doar întregul conţinut al unei singure tabele, ci poate fi folosită pentru a vizualiza rezultatul oricărei interogări asupra uneia sau mai multor tabele. Utilizatorul se poate deplasa prin listă pentru a face adăugări, ştergeri, modificări de câmpuri, poate elimina unele linii (înregistrări) sau poate insera altele noi.

Imaginea de tip formular (Form View) afişează pe ecran o singură înregistrare la un moment dat. Avantajul ei este, însă, posibilitatea organizării ecranului după dorinţă. Se poate face, de exemplu, o machetare a imaginii astfel încât aceasta să aibă acelaşi aspect cu formularul tipizat de pe care se face preluarea datelor; pentru o operatoare care face culegerea datelor, acest lucru poate fi foarte important. În această machetă pot fi incluse texte suplimentare, explicative, care nu fac parte din înregistrare, dar care măresc sugestivitatea imaginii sau dau indicaţii de operare. La fel ca şi imaginea de tip listă, imaginea de tip formular poate fi rezultatul unei interogări oarecare făcută, eventual, asupra mai multor tabele. Utilizatorul poate intra în rubricile formularului pentru a face actualizări ale câmpurilor corespunzătoare, poate adăuga o nouă înregistrare completând un formular gol sau poate comanda eliminarea din bază a înregistrării care este afişată la un moment dat.

QBF (Query By Form) este tehnica de interogare în care utilizatorul exprimă cererea prin completarea rubricilor necesare în cadrul unui formular ("de cerere") prestabilit; în rubricile formularului se completează, de fapt, criteriile după care se va face selectarea înregistrărilor din tabelele bazei de date. Şi aici este posibilă utilizarea unei multiudini de operatori (logici, de comparare etc.) la completarea rubricilor pentru a defini criteriile interogare. În proiectarea formularului, acestuia i se pot ataşa butoane grafice de acţiune sau de opţiune precum şi orice alte elemente de control care, în prezent, sunt larg utilizate ca mijloace grafice de dialog cu aplicaţiile software.

Editare de rapoarte Una din facilităţile importante 4GL este editarea de rapoarte. Un raport este creat

pentru a vizualiza pe ecran sau, mai frecvent, la imprimantă, informaţii din baza de date. Raportul are caracteristici proprii care îl deosebesc de alte modalităţi de vizualizare a datelor (cum ar fi, de exemplu, imaginea de tip listă): înregistrările pot fi grupate pe mai multe niveluri, iar la fiecare nivel se pot calcula totaluri, medii etc.; se pot defini titluri şi capete de tabel pentru raport şi pentru fiecare pagină a acestuia, variante de numerotare a paginilor precum şi diferite modalităţi de încheiere a acestora sau a întregului raport (de exemplu, rubrici pentru semnături); se pot preciza condiţii de trecere la pagină nouă (de exemplu, care grupuri de linii să înceapă a fi tipărite la pagină nouă). Facilităţi pentru editarea rapoartelor au fost incluse şi în anumite limbaje de generaţia a treia; astfel, limbajul COBOL are secţiune specială pentru definirea rapoartelor şi instrucţiuni speciale pentru generarea acestora, dar modul de lucru era, bineînţeles, procedural. În 4GL definirea şi generarea rapoartelor a căpătat un puternic caracter declarativ; utilizatorul are al dispoziţie mijloace grafice, mult mai comode de a descrie structura şi aspectul raportului (grupurile de

1 Pentru cuvântul englez form se întâlnesc, în acest context, diverse traduceri, de exemplu: "formă" sau "format"; credem că traducerea "formular" este la fel de bună (sau de rea) ca şi celelalte.

32

înregistrări, totalurile parţiale, titlurile şi capetele de tabel etc.), iar generarea şi vizualizarea sau tipărirea raportului cade în sarcina SGBD-ului.

��� În final să menţionăm faptul că, în prezent, Sistemele de Gestiune a Bazelor de

Date oferite de marile firme de software sunt medii complexe de dezvoltare a aplicaţiilor în jurul bazelor de date. Pentru a le face cât mai atractive pentru utilizatori, producătorii acestora includ o gamă largă de facilităţi de tip CASE (Computer Aided Software Engineering - Inginerie Software Asistată de Calculator): instrumente pentru definirea grafică, interactivă, tabelelor şi a diagramei entitate-asociere, pentru descrierea restrucţiilor de validare a datelor de intrare, pentru construirea expresiilor, pentru proiectarea formularelor de afişare, a rapoartelor, a meniurilor şi casetelor de dialog în conformitate cu standardele actuale. Continua apariţie de noi versiuni ale instrumenteor de dezvoltare demonstrează interesul mereu actual atât ştiinţific, cât şi comercial pentru progresul domeniului bazelor de date.

33

REFERAT ŞI TEM| DE APLICAŢIE PRACTICĂ Să se trateze o problemă de gestiune a datelor şi să se realizeze o aplicaţie cu bază de

date relaţională care să rezolve problema respectivă. Baza de date trebuie să conţină: - cel puţin 3 tabele conectate prin asocieri; - cel puţin 2 formulare - cel puţin 3 interogări - cel puţin 1 raport Cel puţin unul dintre tabelele bazei de date să aibă 25-30 de înregistrări. Să se descrie într-un referat problema de prelucrare a datelor abordată şi să se

evidenţieze soluţiile informatice adoptate în proiectarea bazei de date. Să se salveze baza de date pe o dischetă şi să se predea împreună cu referatul. SGBD-ul recomandat a fi folosit este Microsoft Access.