Evidenta Elevilor Intr O Scoala. Analiza Sistemului Informatic

INTRODUCERE

Evidența cu ajutorul calculatorului reprezintă o activitate care se regăsește în multe domenii de activitate cum sunt: evidența populației, evidența elevilor și studenților, evidența mărfurilor într-un depozit, evidenta cărților intr-o bibliotecă etc.

Când vorbim de evidența cu ajutorul calculatorului atunci automat trebuie să vorbim de baze de date.

Lucrarea de fața prezintă modul de proiectare și implementare a unei baze de date destinate realizării evidenței automate a elevilor într-o școală.

Conceptul de bază de date se referă la stocarea volumelor mari de date pe suport de memorie de capacitate corespunzătoare. Pentru a realiza stocarea și prelucrarea acestor volume de date s-au dezvoltat tehnici și metode specifice domeniului.

Primele baze de date erau dezvoltate pe sisteme de calcul de tip mainframe și erau manipulate de oameni special pregătiți pentru a gestiona aceste sisteme.

O dată cu dezvoltarea sistemelor personale (PC), au apărut și primele aplicații de baze de date care foloseau un singur fișier pentru a stoca toată informația din baza de date (denumite baze de date „flat file"). Ele erau de tip Xbase, un limbaj care s-a răspândit foarte repede fiind folosit în special la manipularea datelor. Sistemele care l-au folosit au fost dBase, FoxBase, FoxPro. Aceste versiuni rulau sub sistemul MS-DOS și împărtășeau limitările acestuia. Cea mai răspândită aplicație care folosește limbajul xBase a fost FoxPro, sistem dezvoltat inițial de firma Fox Software sub numele de Foxbase. Chiar și în zilele noastre există firme care stochează date extrem de importante în baze de date FoxPro, iar cel mai cunoscut exemplu este cel al organizației care gestionează Euro Tunel.

La începutul anilor 90, firma Microsoft Corporation a lansat aplicația Access, aplicație care se bazează în mare parte pe logica de stocare a sistemului FoxPro, sistem care fusese achiziționat de firmă în 1989. Aplicația Access a devenit, în scurt timp, cea mai folosită aplicație de gestiune a bazelor de date „flat file" de pe sistemele personale. Ajuns acum la versiunea 2003 SGBD-ul MS-Access s-a schimbat fiind scalabil către baze de date Microsoft SQL Server. Totodată, începând cu versiunea 7 i s-a adăugat un limbaj de programare dedicat (Visual Basic for Applications – VBA), bazat pe limbajul de programare Visual Basic. Prin intermediul acestuia se puteau manipula datele mai ușor, se puteau folosi automatisme pentru diverse interogări, afișări etc. Începând cu versiunea 9, limbajul integrat este compatibil cu Visual Basic și cu limbajul folosit de MS SQL Server. Versiunea 2003 poate genera programe executabile (fișiere *.exe) astfel încât nu mai este nevoie de prezența acestuia pe mașina pe care rulează o aplicație specifică MS-Access. Acest mod de lucru amintește de posibilitatea de a genera executabile adăugată SGBD-ului FoxPro chiar de la versiunile sub MS-DOS.

În privința sistemelor server, piața s-a dezvoltat uimitor de repede deoarece s-a constatat cât de folositoare sunt sistemele dedicate acestui lucru. Oracle a lansat și și-a dezvoltat baza de aplicații server, astăzi ajungând la versiunea 9. Începând cu versiunea 8i, au fost introduse extensii orientate pe obiecte. Lansată cu ocazia Oracle OpenWorld, Oracle 9i reprezintă cea mai completă infrastructura pregătită pentru rularea aplicațiilor Internet. Oracle 9i include Oracle 9i Database și Oracle 9i Application Server si pachetul de unelte de dezvoltare Oracle 9i Developer Suite.

În ceea ce privește corporația Microsoft, aceasta a lansat tot în anul 2000 serverul de baze de date SQL Server 2000. Aplicația se dorește a fi un concurent direct pentru aplicațiile Oracle, iar pentru acest fapt i s-a adăugat suport 100% pentru limbajul XML prin intermediul căruia se poate interoga direct serverul dintr-un browser (dacă serverul a fost configurat să suporte această facilitate).

Tot în 2000, compania IBM a lansat varianta 7 a aplicației DB2. Aceasta aplicație, ca și Oracle, este implementata pe mai multe platforme (inclusiv Linux), fiind o aplicație pur obiectuală.

Pe sistemele Linux, cel mai folosit server de baze de date este MySQL. Cu toate că există un alt produs gratuit (MySQL este gratuit atât timp cât aplicația dezvoltata nu este revânduta) – PostgreSQL, MySQL rămâne preferatul programatorilor de Linux. De ce? Pentru că limbajul cel mai folosit pe partea de server web – PHP – dispune de o extensie MySQL înglobată. Dar nu numai acest lucru a influențat folosirea MySQL. Una dintre alegeri a fost și datorită ușurinței administrării acestui server, el dispunând de un client de accesare inclus.

Există sute de modalități de depozitare a datelor în baza de date. Cele mai utile aplicații de computer stochează date, dar adesea ele o fac în moduri proprii, specifice.

În tot mai mare măsură, oamenii de afaceri își dau seama că o mulțime de informații importante rămân neutilizate sau neintegrate, fiindcă nu sunt într-un format „adecvat”. Companiile se instalează pe Internet și se interesează de reacțiile la produsele lor. Tot mai mult, acele reacții vin sub formă de e-mail-uri. Foarte puține companii pot face uz pe scară largă de informația din acele e-mail-uri, le pot sorta, căuta sau exploatade o manieră organizată. Și mai puține companii încă pot utiliza eficient datele pe bază de HTML, cum ar fi cataloagele Web ale competitorilor lor.

Baze de date

Concepte generale

Conceptul de bază de date a apărut în anul 1969, la prezentarea primului raport CODASYL. Ideea de bază în organizarea datelor se întemeia pe existența unui fișier de descriere globală a datelor prin care se realiza independența programelor față de date și a datelor față de programe.

Prin intermediul acestui fișier se realiza accesul utilizatorilor. Acest fișier de date conținea colecțiile de date și legăturile dintre ele. Ulterior, acest concept a fost preluat și dezvoltat pentru bazele de date rețea, apoi relaționale și orientate pe obiect.

O bază de date poate fi definită de una sau mai multe colecții de date (Ki) aflate în interdependență, împreună cu descrierea datelor și a relațiilor dintre ele, (B=(K1, K2, … )). O bază de date trebuie să îndeplinească următoarele condiții:

să asigure o independență sporită a datelor față de programe și invers;

concepția structurii bazei de date trebuie făcută astfel încât să se asigure informațiile necesare și suficiente pentru necesitățile de informare și decizie;

să asigure o redundanță minimă și controlată a datelor;

să permită un acces rapid la informațiile stocate în baza de date.

Din punctul de vedere al criteriilor luate în considerare, bazele de date se împart:

după orientare:

generalizate;

specializate;

după modelul de date:

ierarhice;

rețea;

relaționale;

orientate pe obiect;

după amploarea geografică:

locale;

distribuite;

după limbajele utilizate:

autonome (dispun de limbaje proprii);

cu limbaj gazdă;

mixte;

Arhitectura bazei de date cuprinde:

baza de date propriu-zisă – se memorează colecțiile de date;

Sistemul de Gestiune a Bazei de Date (SGBD) – ansamblu de programe care realizează gestiunea și prelucrarea complexă a bazei de date;

un set de proceduri manuale și automate;

un dicționar al bazei de date – informații despre date, structura acestora, elementele de descriere a semanticii, elemente de statistică, documentații, etc.;

mijloace hard utilizate;

personal implicat.

Complexitatea problemelor care apar în activitatea unei unități economice implică prelucrarea operativă a datelor și obținerea de rezultate (informații) care sunt suportul deciziei managerilor.

Volumul acestor date este în continuă creștere, ceea ce determină necesitatea organizării și memorării lor pe suporturi tehnice adresabile, organizare care poate fi făcută în fișiere sau în baze de date.

Fișierele reprezintă colecții de date omogene din punct de vedere al conținutului, colecții care reprezintă înregistrări fizice. O înregistrare fizică poate conține una sau mai multe înregistrări logice. Înregistrarea logică este definitivă ca o unitate de prelucrare din punct de vedere al programului utilizator. Organizarea datelor în fișiere și accesul la ele sunt asigurate de un set de programe dedicate care sunt reunite sub denumirea de Sistem de Gestiune a Fișierelor (SGF), componenta a Sistemului de Operare (SO).

Conceptul de bază de date pornește de la ideea că există un fișier de descriere globală a datelor, prin care se realizează independența programelor față de date și acestora față de programe. Astfel, putem spune ce o bază de date este o colecție de date aflate în interdependență, împreună cu descrierea datelor și a relațiilor dintre ele.

Acest ansamblu structurat de date conține structuri de date legate funcțional între ele. Datele organizate în astfel de colecții trebuie să fie interogabile prin conținut după orice fel de criterii si trebuie să ofere posibilitatea regăsirii structurii datelor.

Descrierea unei baze de date presupune:

determinarea structurilor de date;

legăturile dintre aceste structuri;

regulile care să asigure coerența datelor, reguli care se mai numesc și reguli de integritate.

Sisteme de Gestiune a Bazelor de Date

Sistemul de gestiune a bazelor de date (SGBD) reprezintă interfața între utilizator și baza de date efectivă, care are ca rol crearea, actualizarea și consultarea acesteia. De aici rezulta că SGBD este de fapt un instument pentru asamblarea, codificarea, protecția și regăsirea datelor din baza de date. Dar, pentru a realiza aceste deziderate, SGBD are ca obiectiv principal separarea descrierii datelor față de programele de aplcație care se realizează prin abstractizarea datelor memorate în baza de date. O bază de date se poate reprezenta pe trei niveluri: extern, conceptual și intern. Acestor niveluri le corespunde o schemă a bazei de date.

Schema externă presupune stabilirea efectivă a datelor ce nu constituie obiectivul bazei de date, necesară unui utilizator sau unui grup de utilizatori. Fiind o subschema a schemei conceptuale ea este de fapt o sursă pentru întocmirea acesteia.

Conceptual, prin analiza schemei externe și eliminând redundanțele apare ce se numește schema concepuală.

Schema internă implementează schema conceptuală prin utilizarea unui SGBD. O aceeași bază de date poate avea definite mai multe scheme externe, o singură schemă conceptuală și o singură schemă internă.

Principalele obiective ale unui SGBD sunt:

Independența fizică a datelor, care constă în capacitatea de a putea schimba organizarea internă a datelor și structurilor de înregistrare, fară a modifica programele de utilizator. Aceasta mai înseamnă și independența schemei interne față de cea conceptuală. De exemplu, având anumite criterii pentru accesul la date, se pot adauga noi indecși, se pot reorganiza fișiere fara o schimbare a schemei conceptuale.

Independența logică a datelor constă în posibilitatea modificării schemei externe fară a modifica schema conceptuală, aceasta rezultând din necesitățile utilizatorilor de a-și modifica în timp cerințele informaționale. Această independență logică a datelor permite vizualizarea datelor în maniera dorită de utilizatori, evoluția schemelor externe pentru fiecare grup de utilizatori, fără a afecta schema conceptuală.

Manipularea datelor prin limbaje neprocedurale. Aceasta presupune existența a două categorii de utilizatori interactivi. O categorie de utilizatori neprofesioniști are nevoie de limbaje de interogare simple, apropiate de limbajul natural, cum este, de exemplu, SQL (Structured Query Language). O altă categorie, formată din programatorii de aplicație, vor folosi limbaje procedurale precum: C, COBOL, PL/1, limbaje orientate obiect (C++, Java), limbaje vizuale (Visual C++, Visual Basic, etc.).

Administrarea cât mai ușoară a datelor. Un SGBD are posibilitatea de a pune la dispoziție instrumente pentru descrierea datelor din punct de vedere al schemei externe, cât și al schemei interne. Administrarea datelor este desemnatăvoluția schemelor externe pentru fiecare grup de utilizatori, fără a afecta schema conceptuală.

Manipularea datelor prin limbaje neprocedurale. Aceasta presupune existența a două categorii de utilizatori interactivi. O categorie de utilizatori neprofesioniști are nevoie de limbaje de interogare simple, apropiate de limbajul natural, cum este, de exemplu, SQL (Structured Query Language). O altă categorie, formată din programatorii de aplicație, vor folosi limbaje procedurale precum: C, COBOL, PL/1, limbaje orientate obiect (C++, Java), limbaje vizuale (Visual C++, Visual Basic, etc.).

Administrarea cât mai ușoară a datelor. Un SGBD are posibilitatea de a pune la dispoziție instrumente pentru descrierea datelor din punct de vedere al schemei externe, cât și al schemei interne. Administrarea datelor este desemnată de totalitatea operațiilor de descriere și de modificare a descrierii datelor, pentru a evita conflictele care pot surveni în definirea acestora. Acestă operație se face de un grup restrâns de specialiști care se vor numi administratori de date.

Performanțele sporite de acces la date sunt date de doi parametrii care evidențiază eficacitatea acestui tip de acces: numărul de tranzacții pe secunda si timpul de răspund. Acești parametrii sunt dependenți de modul în care SO al calculatorului, sub care lucrează SGBD-ul, aloca și partajează resursele fizice (unitatea centrală, memorie internă, memorie externă).

2.2.1. Funcțiile unui SGBD

Funcțiile unui SGBD se pot grupa în:

memorarea pe suport extern prin sistemul de gestiune al fișierelor;

gestiunea datelor și a legaturilor dintre ele pentru o regăsire rapidă;

introducerea și extragerea datelor sub forma cerută de utilizator prin SGBD-ul extern.

Ultimele SGBD-uri au încorporate funcții avansate pentru gestiunea procedurilor și a evenimentelor.

Funcția de descriere a datelor presupune ca SGBD-ul să poată defini datele (schema extenă, schema conceptuală, schema internă și legăturile corespondente) cu ajutorul unui limbaj specializat DDL (Description Data Language), într-o formă numită schema sursă, să compileze apoi această schemă într-o formă internă numită schema obiect. Dacă un SGBD suportă cele trei niveluri de descriere a datelor (extern, conceptual, intern) vor exista si trei administratori de date, și anume:

administratorul bazei de date, care va defini schema internă și regulile de trecere de la schema conceptuală la cea internă;

administratorul unitații economice, care are rolul de a defini schema conceptuală;

administratorul aplicației, care va defini schema externă și regulile de corespondență cu schema conceptuală.

Aceste scheme, precum și procedurile de trecere de la o schemă la cealaltă sunt înregistrate în dicționarul de date, care are două parți:

dicționarul unității economice, care cuprinde schema conceptuală cu procedurile acesteia;

dicționarul bazei de date, care conține schema externă și cea internă împreună cu procedurile de trecere aferente. Informațiile memorate în aceste dicționare sunt în forma sursă sau obiect. Dicționarul de date organizat sub formă de baze de date poartă numele de metabază.

1. O funcție esențială a unui SGBD este interogarea bazei de date.

De obicei, în această funcție se includ căutarea și extragerea datelor, precum și operațiile de actualizare a bazei de date, concretizate în: adăugare, modificare, ștergere.

La început, primii pași în crearea și utilizarea SGBD-urilor presupunea o existență a unor limbaje procedurale prin care localizarea datelor se facea prin căutări succesive. SGBD-urile din ulimele generații implementeaa funcția de interogare a bazei de date cu ajutorul unor limbaje declarative, care au posibilitatea căutării datelor după conținut, fără însă a preciza procedurile de acces. Astfel de limbaje trebuie să permită definirea oricarei cereri de interogare a bazei de date, care este formulată de utilizator, și din acestă categorie face parte limbajul SQL. De menționat este faptul că o cerere de interogare se derulează în patru etape, și anume:

formulare, care folosesc limbajul de manipulare a datelor (DMC – Data Manipulation Language), care este un subset al SQL-ului;

compilare;

optimizare;

execuție.

De asemenea, SGBD-urile trebuie să aibă obligatoriu un compilator (analizor) al cererilor de interogare, care să permită analiza sintactică și evaluarea acesteia. Pentru validarea cererilor, compilatorul utilizează dicționarul de date și le descompune în operatori relaționali pe care îi structurează sub formă de arbore. În arborele astfel construit nodurile indică operatori, iar frunzele reprezintă relațiile. O cerere de interogare compilată este apoi transmisă către etapa de optimizare în care se caută modul cel mai rapid de execuție a acesteia. Rezultatul acestei etape constă în transformarea cererilor de interogare în tranzacții. Tranzacția reprezintă una sau mai multe cereri de interogare, care se vor executa din punct de vedere logic, împreună, ca o entitate funcțională. Tranzacția se execută prin doua operații principale:

gestiunea tranzacțiilor concurente;

execuția în sine.

2. Conversia datelor este una din posibilitățile pe care le oferă SGBD-ul pentru a trece datele în cele trei niveluri: extern, conceptual și intern, motiv pentru care SGBD-ul trebuie să cunoască corespondențele dintre aceste niveluri.

3. Controlul integrității datelor. Această funcție presupune ca SGBD-ul să asigure coerența datelor, adică toate regulile implicite sau explicite care trebuie să asigure integritatea datelor (restricții de integritate).

4. Gestiunea tranzacțiilor. Tranzacția are rolul de a trece informațiile dintr-o bază de date în alta (în același format sau în alt format) cu condiția ca baza de date inițială să rămână într-o stare coerentă.

Conceptele cu care se lucrează sunt:

atomicitatea tranzacțiilor (Transaction Atomicity), ceea ce înseamnă că o tranzacție este executată total sau nu este executată deloc;

corectitudinea tranzacțiilor (Transaction Correctness), care semnifică respectarea coerenței bazei de date după execuția tranzacțiilor;

izolarea tranzacțiilor, ceea ce înseamnă că modificările nu sunt percepute din exterior până când nu se termină tranzacția.

5. Securitatea datelor. SGBD-ul are posibilitatea de a garanta securitatea datelor printr-un mecanism de control al accesului la date și de resturare a acesteia în caz de pene sau erori. Mai nou, ultimele SGBD-uri au o serie de alte funcții, cum ar fi:

posibilitatea de execuție a unor proceduri atunci când sunt îndeplinite anumite condiții asupra bazelor de date;

reguli de inferențe, care permit deducerea unor date noi pe baza celor existente;

posibilitatea de a gestiona obiecte complexe, cum ar fi: hărți, grafice, filme, ceea ce a dus la apariția bazelor de date multimedia.

2.2. Etapele realizării unei baze de date

În proiectarea unei baze de date sunt prevăzute mai multe etape:

analiza sistemului sau a domeniului economic și a cerințelor informaționale asociate, pentru care se realizeauă baza de date;

proiectarea structurii bazei de date, adică elaborarea schemei conceptuale externe și a schemei conceptuale interne;

încărcarea datelor în baza de date;

exploatarea și întreținerea bazei de date.

Analiza sistemului economic presupune patru etape:

analiza componentelor sistemului și a legăturilor dintre acestea, sau analiza structurală în urma căreia rezultă modelul structural sau static al sistemului;

analiza stărilor sistemului și a tranzițiilor posibile între aceste stări, în raport cu anumite evenimente. În urma acestei analize rezultă modelul dinamic sau temporal;

analiza transferurilor informaționale (a tranzacțiilor), în urma căreia se obține modelul funcțional al modelului economic;

integrarea modelelor sistemului economic (structural, dinamic și funcțional), în scopul corelării și completării lor.

Tehnica diagramelor entitate-asociere

Analiza sistemului economic are ca obiectiv evidențierea componentelor din cadrul sistemului pentru care urmează să se colecteze și să se memoreze informații în baza de date, precum și evidențierea legăturilor dintre aceste componente.

Tehnica diagramelor entitate-asociere permite construirea modelului structural sub forma unei diagrame entitate-asociere, prin parcurgerea următorilor pași:

Identificarea componentelor (entităților) din cadrul sistemului economic. Fiecare entitate prezintă mai multe realizări. În urma acestei etape se elaborează o primă formă a diagramei entitate-asociere.

Identificarea asocierilor dintre entități și codificarea acestora. Legăturile dintre entități sunt reprezentate prin arce neorientate, care fac legătura între nodurile ce reprezintă entitățile participante la asociere.

Fig.1. Diagramă entitate-asociere

Tipul sau forma legăturii se exprimă cu ajutorul cardinalității. Cardinalitatea asocierilor exprimă numărul minim și numărul maxim de realizări (instanțe) de entitate, care pot fi asociate cu o realizare a partenerului de asociere. Cardinalitatea se exprimă prin perechi de numere, câte o pereche pentru fiecare entitate din cadrul legăturii.

Identificarea atributelor aferente entităților și asocierile dintre entitați.

Stabilirea atributelor de identificare a entităților.

Tipuri de legături între entități

După cardinalitatea asocierii. În acest caz, se are în vedere gradul asocierii și obligativitatea participării entităților la asociere.

După gradul asocierii (maximele cardinalității), identificăm următoarele tipuri de asocieri (legături):

asociere de tip „unu la unu”

asocieri de tip „unu la mulți”

asocieri de tip „mulți la mulți”

După obligativitatea participării entităților la asociere (minimele cardinalității), există:

asocieri parțiale

asocieri totale

Concomitent, după gradul asocierii și după obligativitatea participării la asociere, sunt:

asocieri pațiale de tip „unu la unu”

asocieri totale de tip „unu la unu”

asocieri parțiale de tip „unu la mulți”

asocieri totale de tip „unu la mulți”

asocieri parțiale de tip „mulți la mulți”

asocieri totale de tip „mulți la mulți”

După numărul de entități distincte care participă la asociere:

asocieri binare (între două entități distuncte)

asocieri recursive (asocieri ale entităților cu ele însele)

asocieri complexe (între mai mult de două entități distincte)

Asocierile parțiale sunt acele asocieri care nu obligă participarea la asociere a tuturor entităților vizate, ci numai a unora dintre ele sau a nici uneia. Această obligativitate este reflectată de minimele cardinalității. Valoarea zero a uneia dintre minime arată lipsa de obligativitatea participării partenerului la această asociere, în timp ce o valoare mai mare decât zero exprimă obligativitatea participării la asociere.

Tipuri de atribute

Atributele exprimă caracteristici ale componentelor domeniului economic analizat sau ale asocierilor dintre aceste componente.

De obicei, atributele sunt asociate entităților, dar ele pot descrie și asocierile dintre acestea.

Atributele pot fi clasificate astfel:

Atribut compus sau bloc, constituit din cel puțin alte două atribute. Valoarea sa este reprezentată de valorile atributelor componente;

Atribut calculat sau dedus. Valoarea sa nu este cunoscută direct, ci calculată pe baza valorilor altor atribute;

Atributul simplu este acel atribut care are valori atomice;

Atributul repetitiv sau multivaloare. Este un atribut care la un moment dat are mai multe valori ce apar sub forma unor liste de valori.

Un atribut de identificare se numește cheie dacă se caracterizează prin unicitatea valorii sale pentru fiecare instanță a entității.

Baze de date relaționale

Generalități

Modelul de date relațional pornește de la faptul că orice structură de date poate fi reprezentată prin una sau mai multe tabele de date, în care trebuie să existe și informații de legătură pentru a asigura corespondența între tabele.

Baza matematică pentru modelul relațional este dată de teoria ansamblurilor. Orgnizarea datelor în baze de date relaționale asigură o interdependență mai mare a programelor de aplicație față de organizarea datelor și utilizează limbaje de manipulare a datelor și instrumente eficace de control al coerenței și redundanței datelor.

Avantajele modelului relațional al datelor:

Programele de aplicație pentru o bază de date relațională nu fac apel la pointeri, fișiere inverse sau alte elemente ale schemei interne ale bazei de date.

Utilizează metode și tehnici de control al coerenței și redundanței datelor. Modelul relațional, prin tehnica normalizării relațiilor, permite definirea unei structuri conceptuale a datelor optime, prin care să se minimizeze riscurile apărute la actualizare.

Oferă facilități multiple de definire și manipulare a datelor prin folosirea unor limbaje procedurale bazate pe algebra relațională, și limbaje neprocedurale, având la bază calculul relațional.

Ameliorează integritatea și confidențialitatea datelor, prin utilizarea restricțiilor de integritate și a relațiilor virtuale.

Modelul relațional se compune din:

Structura relațională a datelor. Datele sunt organizate sub forma unor tablouri bidimensionale de date care poartă numele de relații. Asocierea dintre relații se reprezintă explicit prin atribute de legătură. Atributele figurează într-una din relațiile implicate în asociere, în cazul legăturilor „unu la mulți” sau sunt plasate într-o relație distinctă construită special pentru exprimarea legăturilor între relații (în cazul legăturilor de tip „mulți la mulți”). O bază de date relațională reprezintă un ansamblu de relații prin care se prezintă atât datele, cât și legăturile dintre ele.

Operatorii modelului relațional definesc operațiile care se pot efectua asupra relațiilor în scopul realizării funcțiior de prelucrare aplicate bazei de date, respectiv consultarea, inserarea, modificarea și stergerea datelor.

Restricțiile de integritate ale modelului relațional permit definirea stărilor coerente ale bazei de date.

Restricțiile de integritate ale modelului relațional

Aceste restricții se numesc și reguli de integritate și definesc cerințele pe care trebuie să satisfacă datele din baza de date pentru a fi corecte și coerente în raport cu ceea ce reprezintă.

Restricțiile de integritate se pot clasifica în:

Structurale, care se definesc în raport cu egalitatea sau inegalitatea unor valori din cadrul lor. Din această categorie fac parte:

Restricția de unicitate a cheii;

Restricția referențială

Restricția entității;

Dependențele între date.

De integritate a comportamentului propriu al unei anumite baze de date. Aceste restricții au în vedere semnificația valorilor din cadrul bazei de date.

Utilizarea modelului relațional nu impune definirea și verificarea tuturor tipurilor de restricții de integritate, ci numai a unor restricții minimale.

Acestea sunt obligatoriu de definit și de respectat atunci când se lucrează cu modelul relațional. Din această categorie de restricții fac parte:

Restricția de unicitate a cheii

Restricția referențială

Restricția entității

Alte restricții, cum ar fi: dependențele între date și cele de comportament.

Restricțiile de integritate minimale sunt definite în raport cu noțiunea de cheie a unei relații.

Relația se reprezintă ca o mulțime de tupluri (înregistrări) și pentru că o mulțime nu poate conține elemente duplicate, relația nu poate prezenta tupluri identice. Identificarea unui tuplu se face cu ajutorul cheii. Cheia unei relații R reprezintă un ansamblu minimal de atribute prin care se poate identifica în mod unic orice tuplu din R. Cheia este formată fie dintr-un singur atribut, fie din mai multe atribute din schema relației respective. În primul caz se numește cheie simplă, iar în cazul al doilea cheie compusă.

Într-o relație pot exista mai multe atribute sau combinații de atribute cu proprietatea de identificare a tuplurilor. Astfel de chei formate din combinații de atribute se numesc chei candidate. Din acest motiv, administratorul bazei de date va alege o cheie care să idendifice efectiv tuplurile și aceasta se va numi cheie primară; restul de chei candidate vor purta numele de chei alternate.

Un grup de atribute din cadrul unei relații care conține o cheie a relației se numește supercheie.

O cheie externă reprezintă un atribut sau un grup de atribute dintr-o relație R1, ale cărei sau căror valor sunt definitepe același sau aceleași domeniu/domenii ca și cheie primară a unei relații R2 și care are rolul de a modela asocierea între entitățile reprezentate prin relațiile R1 și R2. R1 este denumită relație care se referă, în timp ce R2 este relație referită.

Modelul relațional are următoarele restricții de integritate minimale:

Restricția de unicitate a cheii, care impune într-o relație R care are cheia K, oricare ar fi tuplurile t1 și t2, să fie satisfăcută inegalitatea: t1(K)≠t2(K), aceasta însemnând că într-o relație nu pot exista două tupluri co o aceeași valoare pentru atributele cheie.

Restricția referențială (integritatea referirii), ce impune ca, într-o relație R1 care referă o relație R2, valorile cheii externe să figureze printre valorile cheii primare din relația R2 sau să fie valori NULL (nedefinite). Relațiile R1, R2 trebuie să fie distincte una de alta. O asociere nu poate exista decât între parteneri cunoscuți, deci care sunt deja definiți.

Restricția entității (integritatea entității). Ea impune ca într-o relație atributele cheii primare să fie nenule. Unicitatea cheii presupune ca la încărcarea unui tuplu, valoarea cheii să fie cunoscută pentru a putea verifica faptul că această valoare nu este deja încărcată.

O altă restricție de integritate este restricția care se referă la dependența datelor; ea semnifică modul în care datele depind unele de altele, iar această dependență poate fi:

a) dependența funcțională, prin care se poate identifica un atribut/grup de atribute prin intermediul altui atribut/grup de atribute.

Fiind dată o relație R, un atribut Y din R este dependent funcțional de un alt atribut X din R, dacă și numai dacă fiecare valoare a lui X are asociată o valoare precisă a lui Y.

Notație: , sau .

Partea stângă a dependenței funcționale se numește determinant, iar partea dreaptă se numește determinat. Pentru exemplul de mai sus X este determinantul, iar Y este determinatul;

b) dependențele multivaloare sunt acele tipuri de dependențe între date în care un atribut/grup de atribute poate prezenta mai multe valori pentru o singură valoare a unui alt atribut/grup de atribute;

c) dependențele joncțiune. Reconstruirea relației R se realizează prin joncționarea proiecțiilor: P1, P2 și P3, unde P1, P2, P3 sunt proiecții ale relației R descompuse. Din acest motiv, dependența din cadrul relației R a primit numele de dependență joncțiune.

Formele normale ale unei relații

Anomaliile care apar în lucrul cu baza de date relațională se produc datorită dependențelor nedorite ce se manifestă între datele din cadrul relațiilor bazei de date. Aceste dependențe determină creșterea redundanței datelor și reducerea flexibilității structurii bazei de date. Anomaliile care pot apărea sunt:

De actualizare, datorate dependențelor funcționale parțiale;

De actualizare, datorate dependențelor funcționale tranzitorii;

De actualizare, datorate dependențelor multivaloare.

Formele normale ale relațiilor într-o bază de date relațională sunt definite în raport cu anomaliile care apar în lucrul efectiv cu aceste baze de date.

În cadrul relațiilor dintr-o asfel de bază de date apar dependențe nedorite, care vor fi înlăturate, folosind urmatoarele forme normale:

FN1: O relație R este în FN1 (formă normală 1) dacă domenile pe care sunt definite atributele relației sunt constituite numai din valori elementare. Un tuplu nu trebuie să conțină atribute sau grupuri de atribute repetitive.

FN2: O relație R este în FN2 (formă normală 2) dacă este în FN1 și oricare din atributele noncheie este dependent funcțional complet de cheia primară a relației.

FN3: O relație R este în FN3 (formă normală 3) dacă este în FN2 și atributele noncheie nu sunt dependente tranzitiv de cheia primară a relației.

FN Boyce-Codd: O relație R este în BCFN dacă dependențele funcționale netriviale care se manifestă în cadrul relației conțin în partea stângă, ca determinant, o cheie candidată.

Fie relația: ; să presupunem că relația R are cheia (K1, K2) și că în cadrul relației se manifestă, alături de alte dependențe funcționale, și de dependența: . De aici rezultă că relația R nu este în forma normală Boyce-Codd.

FN4: O relație R este în FN4 (formă normală 4) dacă este în cadrul ei nu se manifestă mai mult de o dependență multivaloare.

FN5: O relație R este în FN5 (formă normală 5) dacă fiecare dependență joncțiune este implicată printr-un candidat cheie al lui R.

Sisteme de gestiune ale bazelor de date relaționale

SGBDR-ul este un SGBD care utilizează, ca și concepție de organizare a datelor, modelul relațional.

În acest sens, Codd a formulat 13 reguli ce exprimă cerințele pe care trebuie să le satisfacă un SGBDR:

R0: regula privind gestionarea datelor la nivel de relație.

Acest lucru înseamnă că sistemul trebuie să utilizeze ca unitate de informații relația, adică limbaje, ca SQL, care să opereze pe întreaga relație.

R1: regula privind reprezentarea logică a datelor.

Toate datele din BDR (baza de date relațională) trebuie să fie reprezentate explicit la nivel logic într-un singur mod, și anume ca valori în tebelele de date. Aeasta înseamnă că toate datele trebuie să fie memorate și prelucrate în același mod. Informațiile privind numele de tabele, coloane, domenii, definițiile tabelelor virtuale și restricțiile de integritate trebuie să fie memorate tot în tabele de date (catalog).

R2: regula privind garantarea accesului la date.

Orice dată din BDR trebuie să poată fi accestă prin specificarea numelui de tabelă, a valorii cheie primare și numelui de coloană.

R3: regula privind valorile NULL.

Sistemul trebuie să permită declararea și manipularea sistematică a valorilor NULL, cu semnificația unor date lipsă sau inaplicabile. Valorile NULL care diferă de șirurile de caractere „_” sau de șirurile vide de caractere sunt importante în implementarea restricțiilor de integritate.

R4: regula privind metadatele.

Descrierea bazei de date trebuie să se prezinte la nivel logic în același mod cu descrierea datelor propriu-zise, sistemele nu trebuie să facă diferențieri în ce privește definirea și tratarea datelor și a metadatelor, utilizând o singură structură, cea relațională.

R5: regula privind facilitățile limbajelor utilizate.

Trebuie să existe cel puțin un limbaj de nivel înalt ale cărui instrucțiuni să poată exprima oricare din următoarele operații: definirea tabelelor de bază, definirea tabelelor virtuale, manipularea datelor (interactiv sau prin program), definirea restricțiilor de integritate, autorizarea accesului, precizarea limitelor tranzacțiilor.

R6: toate tabelele virtuale care teoretic sunt posibil de actualizat trebuie să fie practic actualizate.

R7: regula pentru inserări, modificări și ștergeri în baze de date.

Această regulă exprimă cerința ca în operațiile prin care se schimbăconținutul bazelor de date să se lucreze la un moment dat pe toată relația.

R8: regula privind independența fizică a datelor.

Programele de aplicație nu trebuie să fie afectate de schimbările efectuate în modul de reprezentare a datelor sau în metodele de acces. O schimbare a structurii fizice a datelor nu trebuie să blocheze funcționarea programelor de aplicație.

R9: regula privind independența logică a datelor.

Programele de aplicație nu trebuie să fie afectate de schimbările efectuate asupra relațiilor bazelor de date.

R10: regula privind restricțiile de integritate.

Aceste restricții trebuie să poată fi definite în limbajul utilizat de sistem pentru definirea datelor și să fie memorate în catalogul bazelor de date și nu în cadrul programelor de aplicație.

R11: regula privind distribuirea geografică a datelor.

Limbajul de manipulare a datelor utilizat de sistem trebuie să permită ca, în situația în care datele sunt distribuite, programele de aplicație să fie logic aceleași cu cele utilizate în cazul în care datele sunt fiăic centralizate.

R12: regula privind prelucrarea datelor la nivelul de bază.

Dacă sistemul posedă un limbaj de bază de nivel scăzut orientat pe prelucrarea de tupluri și nu pe prelucrarea mulțimilor (relațiilor), acest limbaj nu trebuie utilizat, deoarece nu respectă lucrul cu restricțiile de integritate sau restricțiile introduse prin utilizarea limbajelor relaționale de nivel înalt. Se obișnuiește ca, în conformitate cu tipul de cerințe pe care le exprimă, regulile să fie grupate în 5 categorii:

reguli de bază: R0, R12;

reguli structurale: R1, R6;

reguli privind integritatea datelor: R3, R10;

reguli privind manipularea datelor: R2, R4, R5, R7;

reguli privind independența datelor: R8, R9, R11;

Nici unul dintre SGBD-urile disponibile astăzi nu respectă în totalitate cerințele celor 13 reguli ale lui Codd.

Totuși, un SGBD este minimal relațional dacă satisface condițiile:

Toate datele din bazele de date sunt reprezentate prin valori în tabele;

Nu există pointeri observabili de către utilizator între tabele, în sensul că operațiile cu relații nu fac apel la pointeri, indecși, fișiere inverse, etc.;

Sistemul suportă operatori relaționali de proiecție, selecție și join natural, fără limitări impuse. Unitatea de informație cu care se lucrează este relația;

Sistemul suportă operațiile de bază ale algebrei relaționale;

Sistemul suportă două dintre restricțiile de integritate de bază ale modelului relațional, și anume: unicitatea cheii unei relații și restricția referențială.

Securitatea bazei de date

Asigurarea securității bazei de date presupune interzicerea accesului neautorizat la date și se realizează cu un set de măsuri de protcție umană, software și hardware. Astfel se pot stabili parole pe baza cărora să le poată fi permis accesul la resursele sistemului de calcul. SGBD-ul poate activa și un jurnal pentru urmărirea accesului la baza de date, cu ajutorul lui fiind posibilă detectarea încercărilor de acces neutorizat. Pentru cererile de I/O transmise sistemului de operare de către SGBD, sunt posibile verificări suplimentare referitoare la utilizarea corectă a fișierelor sau a funcțiilor sistemului de operare.

Hardware-ul poate oferi și el o protecție suplimentară prin transferarea datelor numai în zone de memorie care sunt controlate de SGBD.

Modalitățile de asigurare a securității bazei de date sunt:

autorizarea și controlul acceului la date, care presupune identificarea utilizatorilor, restricționarea accesului acestora la date, precum și stabilirea de restricții pentru datele accesate. SGBD-urile actuale folosesc pentru identificarea utilizatorului, parole, fiecare parolă fiind asociată cu anumite drepturi de acces la date. SGBD-ul va menține pentru fiecare parolă o listă de privilegii pentru user-ul care folosește acea parolă. User-ii pot fi asociați unor grupuri, la drepturile fiecăruia adăugându-se drepturile stabilite pentru grupul respectiv. Administratorul bazei de date este user-ul care, implicit, are toate drepturile asupra bazei de date, precum și dreptul de a stabili sau revoca privilegii pentru ceilalți utilizatori. Utilizatorii obișnuiți sunt cei care nu au în proprietate obiecte și nu au alte privilegii decât celel moștenite ca membrii unui grup sau menționate explicit de administratorul bazei de date sau de proprietarii de obiecte.

Definirea și utilizarea viziunilor (a schemei externe a bazei de date). Viziunile sunt partiții logice ale bazei de date. Ele sunt diferite pentru diferiți utilizatori în raport cu necesitățile acestora de a avea acces la date. Securitatea datelor va fia asigurată prin definirea tuturor drepturilor necesare unui utilizator, pentru o viziune, și revocarea drepturilor, pentru obiecte inițiale. Utilizatorul nu va avea acces la efectuarea unor operații asupra viziunii care să afecteze obiectele inițiale.

Realizarea de proceduri speciale. Sunt SGBD-uri care au facilitatea definirii unor proceduri care să fie păstrate la nivelul sistemului, într-o formă precompilată. În aceste proceduri se vor specifica explicit operațiile care se vor efectua aupra datelor.

Criptarea datelor este operația de codificare a datelor pe timpul stocării sau al transportului lor, astfel încât descifrarea lor să poată fi facută numai de posesorii autorizați de cod. La nivelul SGBD-ului această facilitate are două forme:

Existența unor rutine speciale care realizează criptarea datelor la cerere sau automat;

Existența unor instrumente care permit utilizatorului să-și realizeze rutine proprii de criptare.

Utilizarea unei baze de date

O bază de date este o colecție de informații organizate într-un anumit fel și depozitate într-un calculator. Dacă aveți acasă o agendă de adrese, aceasta este aproape o bază de date. Tot ce are nevoie pentru a fi recunoscută ca o bază de date propriu-zisă este să copiați informația într-un computer și s-o salvați – într-o manieră ordonată – într-un fișier.

Gândiți-vă însă ce se întâmplă de fapt dacă luați numele, adresele și numerele de telefon ale tuturor prietenilor și rudelor dumneavoastră și copiați acele date în calculator. Dactilografierea pur și simplu la întâmplare a datelor nu va avea ca rezultat o stocare organizată a informației. Mai întâi trebuie să definiți o structură de bază de date. Ea poate fi similară cu structura din agenda dumneavoastră de adrese.

Există diferite modele de baze de date, dar noi ne vom concentra asupra tipului care este cel mai răspândit – baza de date relațională. O bază de date relațională are trei calități principale:

Datele sunt stocate în tabele (subdivizate în câmpuri);

Puteți atașa (uni) într-o relație, tabelele astfel încât mai târziu să puteți extrage date din mai multe tabele în același timp.

Puteți interoga tabelele, obținând seturi de înregistrări (submulțimi ale unuia sau mai multor tabele)

Să presupunem că agenda dumneavoastră cuadrese conține informații despre o persoană per pagină. Fiecare pagină, după completarea ei cu informații, va fi echivalentă, în termenii bazelor de date, cu o înregistrare. Primul rând de pe fiecare pagină a agendei are eticheta Nume, următorul Adresă, etc. În termenii bazelor de date, aceste etichete se numesc câmpuri.

Vă puteți imagina un câmp ca un tip de informație; fiecare câmp are propriul său nume, dar o înregistrare nu are nume. Ea conține datele propriu-zise, informația concretă ce completează câmpurile. În terminologia bazelor de date, o înregistrare este deseori desemnată ca o linie, iar un câmp mai este numit și coloană.

În funcție de tipul de programare care-l faceți, dacă numele unui câmp este alcătuit din două cuvinte ar putea fi necesară închiderea sa în paranteze sau, uneori, în ghilimele simple. Bazele de date în stilul Access cu care am lucrat în Visual Basic permit utilizarea spațiilor. Totuși să reținem următorul aspect: majoritatea bazelor de date relaționale nu permit acest lucru, astfel că trebuie să recurgeți la caracatere de subliniere pentru separarea cuvintelor.

Să revenim la agenda de adrese ce ilustrare a bazelor de date. Întreaga agendă este echivalentă cu un tabel întrâo bază de date a unui computer. Tebelele sunt colecții de datela scară relativ mare, cum ar fi întreaga dumneavoastră agendă, dar o bază de date poate conține mai multe tabele – conținutul unei baze de date îl definiți atunci când o creați, astfel că determinați câte tabele are și ce câmpuri conține fiecare tabel.

Poate că ați marcat în tabel zilele de naștere ale prietenilor și rudelor dumneavoastră. Ați putea introduce aceste date într-un al doilea tabel al bazei dumneavoastră de date numit, eventual, Cadouri, în care veți avea de asemenea un câmp Nume. Această caracteristică vă poate fi utilă mai târziu, deoarece vă va permite să uniți tabelele. Puteți astfel să interogați ambele tabele deoadată. Rezultatul acestei interogări este făcut disponibil în ceea ce se numește set de înregistrări.

Bazele de date având un singur tabel supradimensionat sunt mai puțin flexibile și mai puțin eficiente decât mai multe tabele mai mici. Bineînțeles că dacă baza de date este mică, organizarea ei nu contează foarte mult. Dar dacă proiectați o bază de date multifuncțională cu 250.000 de înregistrări, orice mică facilitate contează. Prin crearea mai multor tabele, puteți să îmbunătățiți organizare bazei dumneavoastră de date, să scrieți mai ușor programe pentru ea și, în general, să găsiți mai ușor înregistrările.

Figura.2. Exemplu de bază de date cu tabele multiple

Când specificați o relație între tabele în timp ce proiectați o bază de date, spuneți de fapt că s-ar putea să aveți nevoie de informații suplimentare despre acest individ, caz în care ele pot fi găsite în acest nou tabel folosind un câmp, indexul primar, folosit în ambele tabele.

Astfel să presupunem că într-un tabel angajatul Ion Ionescu are un număr Marca egal cu 686 (două tabele din baza de date au fiecare acest câmp Marca). Pentru a afla mai multe despre Ion Ionescu, caut același număr Marca în tabelul al doilea, unde pot găsi stocate informații suplimentare despre el.

Într-o bază de date relațională, informația nu este automat stocată alfabetic (sau în ordine numerică, pentru un câmp numeric). Într-un câmp Nume valoarea Andrei poate să apară după Zamfir.

Esențialul este că nu ne putem aștepta ca înregistrările să fie într-o anumită ordine. Când cineva adaugă o nouă înregistrare la baza de date aceasta este pur și simplu așezată la sfârșitul tabelului. Atunci când proiectați o bază de date, puteți preciza că unele din câmpurile sale trebuie să fie indexuri. Un index este un fișier special în care sunt stocate valorile câmpului cheie al tabelei într-o succesiune care conduce la aparența că baza de date este ordonată după valorile unui anumit câmp (de obicei diferit de câmpul cheie). Indexul ocupă mult mai puțin spațiu decât baza de date și se pot defini mai mulți indecși pentru aceeași bază de date. Totodată, crearea unui index nou (pentru o sortare particulară a bazei de date) se poate realiza mult mai rapid decât sortarea întregii baze de date.

3. PROIECTAREA BAZEI DE DATE

3.1. PREZENTAREA PROBLEMEI

Așa cum am precizat mai sus, problema care trebuie rezolvată este cea a implementării unei baze de date pentru realizarea evidenței automate a elevilor. Pentru aceasta trebuie precizate informațiile care sunt stocate pentru o perioada mai mare de timp.

Informațiile care se păstrează uzual într-o școală (bineînțeles, cele despre elevii școlii) sunt următoarele:

nume;

prenume;

numele tatălui;

numele mamei;

numărul matricol;

data nașterii;

locul nașterii;

telefon acasă;

telefon părinți;

disciplinele parcurse și notele obținute;

repetările.

3.2. ANALIZA PROBLEMEI

Analiza problemei care trebuie rezolvată are ca scop elaborarea modelelor care să permită ulterior elaborarea structurii bazei de date. Această analiză presupune următoarele etape:

identificarea entităților informaționale care vor fi stocate în baza de datei și a legăturilor dintre acestea, activitate cunoscută sub numele de analiză statică sau structurală;

identificarea stărilor în care se pot afla aceste entități și a tranzițiilor posibile între aceste stări în raport cu anumite evenimente (analiza dinamică);

identificarea transferurilor de date din cadrul sistemului (analiza funcțională).

Pentru construirea modelului structural trebuie parcurse următoarele etape:

identificarea componentelor din cadrul sistemului informatic;

identificarea asocierilor dintre entități și calificarea lor;

identificarea atributelor aferente entităților și asocierilor lor;

stabilirea atributelor de identificare a entităților.

Pentru problema prezentată se pot identifica trei entități care se află în legătură una cu alta, și anume: entitatea ELEV, entitatea CATALOG și entitatea DISCIPLINA.

Diagrama structurală, corespunzătoare celor trei entități și a legăturilor dintre ele, este prezentată în figura următoare.

Figura 2. Diagrama entitate-relație

Legătura dintre entitățile ELEV și CATALOG este de tipul “unu la unu” de la entitatea ELEV la entitatea CATALOG, și de tipul “unu la mulți” de la entitatea CATALOG la entitatea ELEV. Aceasta înseamnă ca un elev va apare în catalog cel puțin o dată dar, în mod normal, el va apare în mai multe instanțe ale entității CATALOG.

Entitățile identificate sunt caracterizate fiecare de o serie de atribute.

În continuare sunt prezentate entitățile din diagrama structurală împreună cu atributele fiecăreia.

Figura 3. Atributele entității ELEV

Figura 4. Atributele entității CATALOG

Figura 5. Atributele entității DISCIPLINA

Ca atribut de identificare pentru entitatea ELEV se alege atributul NRMATRICOL. Pentru entitatea CATALOG, atributul de identificare este atributul NRMATRICOL, iar pentru entitatea DISCIPLINA acesta este coddiscip.

Analiza dinamică are drept scop explicarea comportamentului elementelor componente ale sistemului informatic analizat.

În urma acestei analize se obține modelul dinamic al sistemului analizat.

Construirea modelului dinamic presupune următoarele etape :

identificarea stărilor în care se pot afla componentele sistemului;

identificarea evenimentelor care determină trecerea unei componente dintr-o stare în alta;

stabilirea succesiunii (fluxului) de evenimente și construirea unei diagrame care să reflecte tranzițiile de stare pentru componentele sistemului (diagrama de flux a evenimentelor).

Figura 6. Diagrama de flux a evenimentelor, corespunzătoare stărilor

celor două entități

La realizarea diagramei de flux a evenimentelor este necesar să se țină cont de restricțiile dinamice ale sistemului care servesc la identificarea tranzițiilor admisibile între două stări.

În figura 6 sunt prezentate stările în care se pot afla cele două entități care compun sistemul.

Tranzițiile entităților sistemului dintr-o stare în alta influențează tranzacțiile (transferurile de date) care au loc în interiorul sistemului, iar acestea la rândul lor influențează modul de realizare a aplicațiilor software destinate sistemului.

Analiza funcțională are drept scop determinarea transformărilor de date care se produc în cadrul sistemului informatic analizat în scopul satisfacerii cerințelor informaționale aferente acestuia. Transformările de date se vor reprezenta sub forma unei diagrame de flux a prelucrărilor, în care nodurile reflectă procesele de prelucrare informațională, iar arcele reflectă fluxurile informaționale.

În cadrul analizei funcționale, accentul se deplasează de la realitatea analizată către cerințele informaționale ale utilizatorilor, cerințe a căror satisfacere constituie obiectivul realizării bazei de date.

Construirea modelului funcțional presupune parcurgerea următoarelor etape:

identificarea datelor de intrare și a datelor de ieșire din sistem;

construirea diagramelor de flux, prin care sunt reflectate legăturile procedurale dintre intrări și ieșiri;

identificarea restricțiilor;

precizarea criteriilor de optimizare.

Datele de intrare pentru problema analizată sunt următoarele:

datele care descriu atributele entității ELEV, în cazul adăugării de noi elevi;

datele care descriu atributele entității CATALOG, pentru evidența notelor și a absențelor;

datele care descriu atributele entității DISCIPLINA, pentru evidența disciplinelor care trebuie predate conform planului de studiu;

Datele de ieșire sunt reprezentate de:

lista elevilor dintr-o anumită clasă;

catalogul în formă electronică;

alte rapoarte la cerere.

Prelucrările de date care trebuiesc efectuate constau în următoarele acțiuni:

adăugarea de noi elevi în baza de date;

ștergerea unui elev;

extragerea de rapoarte privind elevii care studiază, eventual acest raport trebuie sa fie ordonate.

Diagramele de flux a prelucrărilor sunt prezentate în figurile următoare.

Figura 6. Diagrame de flux a prelucrărilor

În final cele trei modele ale sistemului vor fi integrate pentru se obține o reprezentare completă a sistemului analizat. Modelul structural și cel dinamic sunt obținute prin investigarea sistemului real, a proprietăților intrinseci, statice și dinamice ale componentelor acestui sistem, proprietăți care sunt independente de aplicațiile care operează asupra lor.

Modelul funcțional este rezultatul analizei cerințelor informaționale ale utilizatorilor, mai precis a tranzacțiilor prin care pot fi satisfăcute aceste cerințe.

Perspectiva diferita din care este realizata analiza explica de ce rezultatele obtinute pot sa difere fiind necesara o coordonare, deci o integrare a lor.

În cadrul etapei de integrare a modelelor sistemului se stabilește în ce măsură modelul structural și cel dinamic satisfac necesitățile diferitelor aplicații, verificându-se complitudinea (existența elementelor informaționale solicitate) și consistența lor (în ce măsură componentele modelelor sunt necesare și suficiente în raport cu procesele de prelucrare). Se verifică dacă relațiile dintre componentele sistemului sunt stabilite în mod corespunzator, pentru a face posibilă regăsirea informațiilor din mai multe entități. Se determină, de asemenea, dacă legăturile dintre entități asigură coerența informațiilor, posibilitatea efectuării de actualizări concomitente asupra datelor redundante.

Se urmăreăte ca toate elementele informaționale participante la diferitele tranzacții să fie asignate ca atribute ale diferitelor entități.

Pe baza acestei analize integrate se efectuează adăugările și/sau corelările necesare între modelele sistemului.

În final se ajunge ca modelul dinamic și cel structural să nu mai fie complet independente de aplicații, iar modelul funcțional să nu mai fie orientat exclusiv pe aplicații.

Modelele obținute în urma analizei sistemului informațional sunt modele ale datelor despre sistem. O caracteristică esențiala a acestor modele este faptul că sunt independente de instrumentul, respectiv SGBD-ul prin intermediul căruia devin operaționale.

Etapa de analiză a sistemului informatic este important să se realizeze independent de un SGBD specificat. Orientarea pe conceptele proprii unui anumit SGBD prezintă numeroase dezavantaje cum sunt:

schimbarea SGBD-ului impune reproiectarea bazei de date;

conceptele tehnice ale SGBD-ului pot influența negativ activitatea de analiză și modelare, prin restricții impuse de acesta, care pot descuraja sau încuraja anumite reprezentări;

fixând ca punct de plecare facilitățile unui SGBD, utilizatorul neinformatician, care nu stăpânește acest SGBD, nu își poate exprima cerințele în deplină cunoștință de cauză.

Trecerea la proiectarea structurii bazei de date impune luarea în considerare a SGBD-ului cu ajutorul caruia va fi implementată și exploatată baza de date. Aceasta deoarece baza de date reprezintă un model al datelor exprimat cu ajutorul conceptelor specifice unui anumit SGBD, ceea ce face proiectarea structurii bazei de date să reprezinte transpunerea modelelor conceptuale în termenii unui model al datelor suportat de un anumit tip de SGBD.

Etapele de proiectare a structurii bazei de date constau în următoarele activități:

alegerea SGBD-ului care va fi utilizat pentru implementarea si exploatarea bazei de date;

proiectarea schemei conceptuale a bazei de date;

proiectarea schemei externe a bazei de date.

3.3. ALEGEREA SISTEMULUI DE GESTIUNE A BAZEI DE DATE UTILIZAT

Alegerea unui SGBD presupune realizarea următoarelor activități:

Stabilirea cerințelor utilizatorilor, sub aspectul:

tipurilor de aplicații dorite,

timpului de răspuns,

confidențialității datelor,

securității datelor,

ușurinței de utilizare.

Stabilirea cerințelor de ordin tehnic privind realizarea bazei de date, cum sunt:

portabilitatea SGBD-ului, adica posibilitatea folosirii SGBD-ului pe diferite sisteme de calcul;

portabilitatea colecțiilor de date și a programelor. Aceasta înseamnă că datele pregătite cu ajutorul unui calculator să poată fi transferate direct pe alt tip de calculator, împreună cu programele aferente, fără alte operații auxiliare;

facilitățile de încărcare, exploatare și întreținere a bazei de date care trebuiesc asigurate.

Stabilirea cerințelor de ordin economic, privind:

încadrarea în bugetul alocat pentru realizarea bazei de date;

timpul necesar pentru pregătirea utilizatorilor și trecerea la exploatarea curentă a bazei de date.

Ierarhizarea cerințelor de la punctele anterioare, în funcție de importanța acordată fiecărei cerințe în parte.

Analiza comparativă a SGBD-urilor disponibile și/sau posibil de achiziționat, în funcție de caracteristicile pe care le prezintă aceste SGBD-uri.

Stabilirea corespondenței între cerințele formulate la punctele 1-3 și caracteristicile diferitelor SGBD-uri analizate, pentru a determina măsura în care diferite SGBD-uri analizate permit satisfacerea cerințelor formulate.

Alegerea propriu-zisă a SGBD-ului care va fi folosit la realizarea bazei de date.

Aplicația care trebuie realizată presupune manevrarea unui volum mediu de date, ce pot fi reprezentate și manevrate comod folosind un model de date relațional. Din această cauză se va alege un SGBD relațional care să posede și un limbaj comod pentru dezvoltarea de aplicații.

SGBD-urile relaționale utilizate astăzi în România pentru baze de date de mică anvergură sunt următoarele: Microsoft FoxPro (versiunile sub DOS sau VisualFoxPro sub Windows), MS-Acces, Paradox ș.a. Pe lângă aceste SGBD-uri se mai pot dezvolta aplicații de baze de date și în mediile de programare vizuale (Visual C++, Borland C++ Builder, Borland Delphi, Visual Basic).

Ținând cont de cele prezentate mai sus se alege, pentru realizarea aplicației, SGBD-ul MS-Acces, care face parte din pachetul MS-Office și este eficient pentru baze de date de dimensiuni medii și mari.

3.4. PROIECTAREA SCHEMEI CONCEPTUALE

Proiectarea schemei conceptuale a bazei de date presupune următoarele activități:

Stabilirea colecȚiilor de date și definirea detaliată a conținutului acestora. La stabilirea acestora se pleacă de la entitățile identificate în etapa de analiză a sistemului. Fiecărei entități îi corespunde, de obicei, o colecție de date în cadrul schemei conceptuale. În aceste colecții vor figura atributele specifice entităților plus eventual o serie de atribute pentru exprimarea legăturilor cu celelalte componente ale sistemului real, atribute cunoscute sub numele de chei externe. Deoarece nu întotdeauna există o corespondență strictă între entitățile din modelele semantice și colecțiile de date din schema conceptuală a bazei de date și din considerente de ameliorare a lucrului pe aceste colecții de date se poate decide “spargerea” unei entități în două sau mai multe colecții de date. Acest lucru duce la o creștere a flexibilității de operare cu colecțiile de date respective. “Spargerea” unei entități în două sau mai multe colecții de date se realizează ținând seama de cerințele informaționale ale sistemului și de durata de existență a datelor în cadrul sistemului. Astfel, datele care sunt solicitate mai des de către utilizatori, cele care se modifică la intervale reduse de timp sau cele care, deși nu se modifica prea des, sunt solicitate frecvent de către programe pentru a genera alte date (prin calcul sau în alt mod), pot constitui colecții separate de date pentru a reduce timpul necesar regăsirii informațiilor căutate. Cu toate acestea, îmbunătățirea performanțelor în manipularea entităților nu presupune obligatoriu mărirea numărului colecțiilor de date folosite în cadrul schemei conceptuale. Aceasta deoarece nu se poate admite o creștere nelimitată a numărului de colecții de date lucru care determină creșterea dificultăților de localizare și accesare a datelor. Legăturile între un numar mare de colecții de date impune și creșterea redundanței datelor în cadrul bazei de date și deci o utilizare ineficientă a suportului de memorare.

determinarea legaturilor dintre colectiile de date și a modului de reprezentare a acestora în cadrul schemei conceptuale se realizează, în principiu pe baza legăturilor dintre entitățile identificate în cadrul etapei de analiză a sistemului și a cerințelor informaționale. Este necesar să se determine, de asemenea și legăturile dintre colecțiile care nu au corespondent direct în entitățile care compun sistemul, dar care la rândul lor se află în asociere, unele cu altele. Modul de reprezentare a legăturilor dintre colecțiile de date depinde de modelul datelor suportate de SGBD. Astfel, modelul ierarhic și cel rețea utilizează pointeri (adrese legatură) pentru înlănțuirea datelor în cadrul colecțiilor. Modelul relațional reprezintă legăturile dintre colecțiile de date (relații) cu ajutorul cheilor externe sau cu ajutorul unor colecții de date distincte. Această reprezentare uniformă a datelor și a asocierilor între date prin intermediul relațiilor constituie o caracteristică a modelului relațional, care conferă acestuia o mare simplitate și flexibilitate.

testarea schemei CONCEPTUALE obȚinute presupune verificarea completitudinii și consistenței schemei conceptuale, adică determinarea gradului în care schema conține elementele informaționale necesare satisfacerii cerințelor informaționale ale diferiților utilizatori și măsura în care legăturile stabilite între aceste elemente informaționale reflectă raporturile naturale dintre componentele sistemului real. De asemenea, prin testarea schemei conceptuale trebuie să se verifice dacă redundanța datelor este la un nivel minim și poate fi controlată. Testarea schemei conceptuale permite identificarea unor eventuale erori de proiectare care fac necesară revizuirea schemei. În acest caz se va relua etapa de proiectare a structurii bazei de date, și, uneori, și etapa de analiză a sistemului și a cerințelor informaționale.

descrierea schemei conceptuale în limbajul de descriere a datelor de care dispune SGBD-ul și încărcarea acestei descrieri în baza de date.

Descrierea schemei conceptuale a bazei de date se realizează în limbajul de descriere a datelor de care dispune SGBD-ul folosit. Rezultatul acestei descrieri îl constituie proiectul bazei de date sau schema bazei de date.

Compilatorul limbajului de descriere a datelor permite aducerea schemei bazei de date în forma la care aceasta poate fi memorata in baza de date.

La realizarea acestor activitati sunt utilizate, în principal modelul structural și cel dinamic al sistemului analizat.

Pentru aplicația noastră, colecțiile de date care definesc cele trei entități ale sistemului vor fi identice cu descrierea entităților realizată prin diagramele entitate-relație.

În continuare sunt descries colecțiile de date utilizate în cadrul bazei de date.

ELEV

NRMATRICOL CARACTER 4

NUME CARACTER 30

PRENUME CARACTER 33

DATANAST DATE/TIME

TATA CARACTER 15

MAMA CARACTER 15

ADRESA CARACTER 40

TELEFON CARACTER 15

CATALOG

NRMATRICOL CARACTER 4

CODDISCIP CARACTER 6

DATA DATE/TIME

ABSENTA CARACTER 1

NOTA CARACTER 2

DISCIPLINA

CODDISCIP CARACTER 5

DENUMIRE CARACTER 23

ANSTUDIU CARACTER 2

3.5. PROIECTAREA SCHEMEI EXTERNE

Schema externă a bazei de date reprezintă forma sub care apare schema conceptuală pentru un utilizator oarecare. Programele de aplicație operează asupra schemei conceptuale prin intermediul schemei externe, având acces doar la acele elemente care sunt incluse în schema externă.

În general, elementele care compun schema externă sunt similare celor care compun schema conceptuală, depinzând totuși de tipul de SGBD utilizat.

În cazul aplicației de față, schema externă cuprinde structura rapoartelor care trebuiesc întocmite de către programe prin selectarea informațiilor corespunzătoare.

Rapoartele care trebuiesc întocmite de către aplicație sunt următoarele:

lista ordonată descrescător a elevilor dintr-o clasă anumită pe baza mediei obținute;

catalogul;

alte rapoarte, la cererea utilizatorului.

Raportul care cuprinde rezultatele elevilor va conține, practic următoarele informații: antetul documentului, clasa pentru care se extrag date, titlul raportului, lista propriu-zisă a elevilor și a mediilor acestora.

Pentru vizualizarea situației școlare a unui elev se întocmește un raport ce va conține: numele și prenumele elevului, clasa în care este, lista disciplinelor cu notele obținute și cu absențele acumulate. Acest raport poate fi vizualizat pe ecran sau trimis la imprimanta.

3.6. PROIECTAREA SCHEMEI INTERNE

Schema internă reprezintă modul cum sunt stocate datele pe suportul de memorie externă.

Pentru problema analizată, schema internă este reprezentată de descrierea structurii tabelelor din baza de date.

Structura tabelelor MS-Access se poate observa mai jos.

Relațiile generate automat între cele trei tabele sunt prezentate mai jos.

4. PROIECTAREA APLICAȚIEI

Această etapă a realizării aplicației presupune efectuarea următoarelor activități :

identificarea datelor de intrare și iesire;

identificarea acțiunilor;

proiectarea structurii aplicației;

proiectarea procedurilor;

proiectarea formularelor de introducere a datelor

proiectarea rapoartelor;

implementarea aplicației;

testarea și depanarea aplicației.

Acțiunile programului se pot identifica din schema funcțională și constau în următoarele:

introducere date pentru înregistrarea unui elev nou;

modificare date privind anumiti elevi;

ștergerea informațiilor privind un anumit elev dacă aceasta a absolvit sau a fost transferat la altă școala;

introducere date privind acumularea de noi absențe;

căutare elev pentru care se specifică numele sau numărul matricol;

afișare date elevi, la cererea utilizatorului;

modificare date personale ale elevilor;

ștergerea unui elev din baza de date;

Fiecare din aceste activități va fi implementată prin intermediul unei unelte specializate din cele oferite de MS-Acces

Pentru acțiuni deosebite se pot realize și proceduri de lucru în limbajul Visual Basic for Application. Acest limbaj permite dezvoltarea de aplicații direct din mediul MS-Office.

Interogarea bazei de date se va realiza prin intermediului instrumentului numit Querry care implementează căutarea de tip QBE (Querry By Example) și prin intermediul limbajului SQL. De altfel, în MS-Access orice interogare realizată prin QBE are asociată și o frază SQL care conduce la rezultatul dorit.

Introducerea datelor în tabele se realizează prin intermediul formularelor pentru introducere date prezentate mai jos.

Procedurile care implementează acțiunile programului sunt prezentate în anexă, împreună cu comentariile necesare. Alături de codul programului sunt anexate și câteva din ferestrele de lucru ale programului și un rezultat al executării acestuia.

BIBLIOGRAFIE

Fusaru D., Mareș D., Mihai G., Visual Basic și Access, Editura Fundației România de Mâine, București, 2001

Lungu I., ș.a., Baze de date. Organizare, proiectare, implementare, Editura All, București 1998

Mansfield R., Visual Basic 6, Editura Tehnică, 2001

Perkins J., Bryan M., SQL fără profesor în 14 zile, Editura Teora, București, 1998

Popa Gh., Ivancenco V., Andronache V., Visual Basic, Editura Cison, București, 1999