Biblioteci si limbaje de programare a aplicatiilor de baze de date

BIBLIOTECI SI LIMBAJE DE PROGRAMARE A APLICATIILOR DE BAZE DE DATE. PREMISELE APLICARII S RESPECTARII RESTRICTIILOR (CONSTRANGERILOR) DE INTEGRITATE

 

 

(52) Aplicatiile de baze de date sunt, in general, mult mai complexe decat alte categorii de aplicatii, deoarece trebuie sa realizeze, atat interfata cu sistemele de gestiune a bazelor de date, pentru introducerea si extragerea datelor, cat si interfata cu utilizatorii, astfel incat acestia sa poata efectua diferite operatii. Pe langa aceste functii de interfatare, programele de aplicatii de baze de date trebuie sa implementeze si algoritmii de calcul necesari. 

Interfetele cu utilizatorii sunt, in general, interfete grafice, cunoscute sub numele de formulare (forms).

Prin intermediul controalelor cu diferite functionalitati din cadrul formularelor, utilizatorii sunt ghidati sa introduca numai datele strict necesare, de cele mai multe ori prin selectarea lor din mai multe valori prezentate (si valide), astfel incat sa se limiteze posibilitatea introducerii unor date eronate. Rezultatele operatiilor cerute de utilizatori sunt afisate, de asemenea in formulare si pot fi tiparite la dorinta, sub forma de rapoarte.

(53) In legatura cu aplicatiile de baze de date se disting doua aspecte:

- utilizarea aplicatiilor (run time);

- elaborarea sau dezvoltarea aplicatiilor (design time).

Din cele expuse pana aici putem concluziona ca utilizarea aplicatiilor se poate reprezenta grafic ca in figura 1.

Dezvoltarea de aplicatii in general, necesita interfete de programare a aplicatiilor cunoscute sub numele de SDK (Software Developing Kit).

(54) Access este un SGBD, dar si un mediu de programare (dispune de limbajul VBA - Visual Basic for Application, dar si de Visual Basic, de editor de programe, de compilator si de un ObjectBrowser). Combinat cu limbajul SQL si cu o tehnologie de conectare la baza de date numita ODBC (Open Database Connectivity) materializata in calculator prin mai multe biblioteci de programe de dezvoltare, Access se comporta ca un adevarat SDK. Ca urmare, Microsoft Access permite dezvoltarea vizuala a aplicatiilor, inclusiv a formularelor si rapoartelor de interfata.

Tot cu SDK pentru baze de date, cum ar fi Access, se dezvolta programele menite sa implementeze algoritmii de calcul necesari, dar si programele de control a rularii instructiunilor SQL.  Aceasta ultima categorie de programe, este necesara deoarece

limbajul SQL (in oricare din standardele definite pana in prezent) este un limbaj neprocedural, care permite definirea datelor  si operatii de manipulare a acestora, dar nu prevede instructiuni de control al ordinii de executie a operatiilor. De aceea, pentru realizarea aplicatiilor de baze de date au fost dezvoltate o multitudine de limbaje si biblioteci de programare: limbaje procedurale de extensie a limbajului SQL, limbajul SQL integrat, biblioteci de functii sau de clase pentru comunicarea cu bazele de date. 

  Un limbaj procedural (procedural language) este o extensie a limbajului SQL si permite combinarea instructiunilor SQL cu instructiuni de control al ordinii de executie. Astfel de limbaje sunt folosite in principal in cadrul sistemelor de gestiune, pentru stocarea unor proceduri de calcul, dar exista si posibilitatea ca programele de aplicatii sa transmita sistemului SGBD blocuri (loturi) de instructiuni intr-un limbaj procedural. Transmiterea

unui bloc de instructiuni in locul transmiterii individuale a fiecarei instructiuni SQL, asigura performante de executie a aplicatiilor mai ridicate, datorita reducerii traficului in retea. 

(55) Desi nu sunt prevazute in standardul SQL, interfetele de programare a aplicatiilor de baze de date s-au dezvoltat  si diversificat deosebit de mult si reprezinta in momentul de fata cea mai folosita tehnologie de realizare a acestor aplicatii. Multe sisteme de gestiune a bazelor de date prezinta biblioteci de programare care ofera o interfata compusa din functii si macrodefinitii ce permit unei aplicatii sa interactioneze cu serverul bazei de date. In general, functiile prevazute in astfel de interfete permit conectarea la server, transmiterea catre server a unor instructiuni SQL si preluarea rezultatelor returnate de server. Cele mai multe biblioteci sunt dezvoltate pentru limbajul C (de exemplu, biblioteca C pentru sistemul Microsoft SQL Server - DB-Library for C), dar exista biblioteci si pentru alte limbaje (C++, Perl, PHP, etc).   

(56) Pe langa aceste biblioteci specifice diferitelor sisteme SGBD, s-au dezvoltat si bibiloteci care ofera interfete cu un grad ridicat de generalitate, care pot fi folosite pentru mai multe tipuri de sisteme SGBD. Cele mai cunoscute sunt interfetele ODBC (Open DataBase Connectivity) si JDBC (Java DataBase Connectivity).

Avand in vedere toate aceste aspecte, situatia din figura 1 poate fi detaliata ca in figura 2.

3.1  LIMBAJE PROCEDURALE DE EXTENSIE A LIMBAJULUI SQL 

 (57) Un limbaj procedural (procedural languages) combina instructiuni SQL cu instructiuni pentru controlul ordinii de executie, asigurand extinderea posibilitatilor sistemelor de gestiune a bazelor de date. 

  Limbajele procedurale permit definirea unor variabile locale,  instructiuni de control al ordinii de executie (bucle while, instructiuni conditionale  if, etc.), precum si suport de creare a cursoarelor, a procedurilor stocate, a functiilor definite de utilizator si a declansatorilor (triggere). 

Un cursor  (cursor) este o structura care permite memorarea (folosind un buffer in memorie) a unei multimi de linii returnate ca rezultat, de o instructiune de interogare. 

Programele de aplicatii nu pot prelucra deodata toate liniile rezultatului si folosesc cursoare pentru extragerea individuala a unei linii (sau a unui grup de linii) din multimea de linii rezultat. In fiecare moment, intr-un cursor exista o pozitie curenta (linie curenta) in multimea de linii rezultat. La fiecare operatie de extragere, se citesc una sau mai multe linii relativ la pozitia curenta a cursorului, iar aceasta pozitie se actualizeaza conform modului de parcurgere (inainte sau inapoi). Cursoarele permit salvarea, folosirea repetata sau derularea de mai multe ori a liniilor pe care le contin. De asemenea, cursoarele ofera mai multe posibilitati de control al accesului concurent a mai multor utilizatori la tabelele unei baze de date.

Cursoarele se pot crea atat la nivelul limbajului SQL2 sau al extensiilor procedurale ale acestuia, cat si prin intermediul limbajului SQL integrat (Embedded SQL) sau a bibliotecilor si interfetelor de programare a aplicatiilor de baze de date (ca, de exemplu, ODBC, JDBC). 

Cursoarele pot fi memorate in server, iar clientul primeste cate o linie (sau un grup de linii) de la server la fiecare instructiune de extragere, sau pot fi memorate in client si sunt folosite direct in programul respectiv. 

Cursoarele create prin intermediul unui limbaj de extensie SQL sunt cursoare la server si pot fi definite in functiile si procedurile stocate din server. In interfetele de programare se pot defini atat cursoare la server cat si cursoare la client. Aceste aspecte vor fi detaliate pentru fiecare limbaj sau interfata in parte. In general, se considera ca este mai avantajos sa fie folosite cursoare la server decat cursoare la client, deoarece memorarea in client necesita ca intreaga multime de tupluri sa fie transferata dintr-o data de la server la client, chiar daca ulterior, din diferite cauze, clientul nu va folosi decat o parte din tuplurile pe care le-a primit prin retea si le-a memorat. 

O procedura stocata (stored procedure) este o procedura care implementeaza o parte din algoritmii de calcul ai aplicatiilor si care este  memorata in baza de date la fel ca si alte obiecte ale bazei de date. 

Procedurile stocate sunt compilate si optimizate de sistemul de gestiune o singura data, atunci cand sunt folosite prima oara si raman memorate in server pentru oricate apeluri ulterioare. 

Apelul unei proceduri stocate de catre un client (aplicatie) produce executia tuturor instructiunilor procedurii si returnarea rezultatului (daca exista), eliminand cerinta ca acel client sa transmita individual fiecare instructiune necesara pentru rezolvarea sarcinii de calcul respective. In felul acesta se reduce, pe de o parte, comunicatia intre aplicatie  si serverul bazei de date si, pe de alta parte, chiar timpul de executie a sarcinii respective, dat fiind ca procedura stocata este deja compilata si optimizata. 

Exista insa si pericolul ca, daca foarte multe aplicatii isi desfasoara operatiile de prelucrare pe server prin intermediul procedurilor stocate, serverul sa fie congestionat si sa nu mai asigure performante satisfacatoare nici uneia din aplicatii. Cu alte cuvinte, utilizarea intensa a procedurilor stocate poate duce la scaderea scalabilitatii sistemului de baze de date. Bineinteles, o analiza atenta a modului de distribuire a operatiilor de prelucrare intre executia la serverul de baze de date (in proceduri stocate) si executia la client, in programele de aplicatii sau in alte niveluri intermediare de executie distribuita (middleware) poate asigura atat perfomante ridicate de executie cat si scalabilitatea sistemelor de baze de date. 

O functie definita de utilizator (user-defined function) este o functie memorata in  baza de date, la fel ca o  procedura stocata; diferenta intre acestea este ca o functie returneaza intotdeauna o valoare si poate fi folosita direct in expresii, pe cata vreme o procedura stocata poate sa nu returneze nici o valoare. 

Un trigger este o procedura stocata cu o functionare speciala, care este executata automat atunci cand se efectueaza o operatie de actualizare a unei relatii. 

Triggerele sunt asociate cu comenzi de inserare (INSERT),  stergere  (DELETE) sau actualizare (UPDATE) a tuplurilor dintr-o anumita relatie si au ca utilizare principala extinderea capacitatii sistemului de gestiune de mentinere a  integritatii datelor relationale.  

  Prin triggere se pot specifica si impune procedural constrangerile explicite, cum sunt dependentele de date (dependente functionale, multivalorice, sau de jonctiune) care nu sunt determinate de chei ale relatiilor.  De asemenea, triggerele mai sunt folosite si pentru generarea automata a unor valori care rezulta din valori ale altor atribute, precum si pentru jurnalizarea transparenta a evenimentelor sau culegerea de date statistice in legatura cu accesarea relatiilor.

Standardul SQL2 nu prevede comenzi pentru crearea triggerelor, dar ele pot fi create folosind instructiuni ale limbajelor procedurale de extensie a limbajului SQL. In general, triggerele definite in diferite limbaje procedurale sunt neportabile.

  Limbajele procedurale de extensie a limbajului SQL, desi au aceeasi utilizare generala in programarea bazelor de date, sunt specifice fiecarui SGBD si nu sunt tocmai compatibile intre ele.

3.2  BIBLIOTECI DE PROGRAMARE A APLICATIILOR DE BAZE DE DATE           

3.2.1  INTERFAT A ODBC

Bibliotecile de programare a aplicatiilor specifice fiecarui SGBD prezinta dezavantajul dependentei codului dezvoltat fata de sistemul folosit la un moment dat; daca se schimba sistemul SGBD, atunci se schimba intreaga interfata si o mare parte din programele de aplicatii trebuie sa fie rescrise. 

Tehnologia ODBC (Open Database Connectivity) ofera o interfata de programare a aplicatiilor (Application Programming Interface - API) prin apel de functii (call-level interface - CLI), independenta de sistemul SGBD folosit. Aceasta independenta se obtine prin intermediul unor drivere, care sunt specifice fiecarui SGBD, in timp ce functiile prevazute in  interfata, care pot fi apelate de aplicatii, sunt aceleasi, definite de standardul ODBC (fig. 3.). 

Pentru a folosi interfata ODBC, trebuie sa fie instalat driverul pentru sistemul SGBD necesar. Unele drivere ODBC se instaleaza atunci cand se instaleaza unele pachete de programe. De exemplu, driverele ODBC pentru baze de date Access, FoxPro se instaleza o data cu pachetul Microsoft Office. Alte drivere ODBC se pot instala separat, daca exista pachetul de instalare respectiv. Administratorul de drivere incarca driverul specific sistemului de gestiune folosit de aplicatie. 

 

 

Fig. 3. Arhitectura ODBC.

 

Administratorul de drivere, precum si driverele specifice diferitelor sisteme de gestiune de baze de date sunt, in general, furnizate ca biblioteci dinamice care sunt legate (link) in programul de aplicatie.

Pentru orice tip de SGBD pentru care este instalat un driver ODBC se poate defini o sursa de date folosind administratorul de surse de date  (ODBC Data Source Administrator) care atribuie unei baze de date un nume de sursa de date (si alte optiuni, depinzand de driverul instalat).

Un program de aplicatie care utilizeaza interfata ODBC apeleaza functii ODBC care sunt implementate in driver. Driverul transforma apelurile de functii ODBC in comenzi SQL (sau intr-un limbaj procedural de extensie a limbajului SQL, implementat de sistemul de gestiune respectiv) pe care le transmite sistemului de gestiune, preia rezultatele si le returneaza programului de aplicatie.

Aceasta tehnologie, care ofera si avantajul unui standard la care au participat majoritatea producatorilor de sisteme de gestiune a bazelor de date, a fost extrem de bine primita de programatorii de aplicatii de baze de date si s-a dezvoltat foarte rapid. Drivere ODBC sunt disponibile pentru majoritatea sistemelor de gestiune a  bazelor de date si sunt produse de furnizorii de SGBD-uri sau de alte firme producatoare de software. 

Interfata ODBC poate fi folosita direct in programarea aplicatiilor, sau poate fi accesata prin intermediul altor interfete, de nivel mai ridicat, care inglobeaza functiile ODBC, oferind modalitati de programare obiect-orientate: RDO (Remote Data Objects), DAO (Data Access Objects), clase MFC (Microsoft Foundation Class) pentru baze de date. 

3.3. SGBD ACCESS

3.3.1. Principalele caracteristici ale sistemului de gestiune a bazelor de date ACCESS

(58)

§                     sistemul de gestiune a bazelor de date este relational si lucreaza sub sistemul de operare Windows;

§         este deschis comunicarii cu alte sisteme de gestiune a bazelor de date, cum ar fi FoxPro, Paradox;

§         este compatibil cu tehnologia ActiveX care permite realizarea aplicatiilor client / server;

§         permite realizarea unor aplicatii complexe prin utilizarea limbajului Visual Basic;

§         permite comunicarea cu SQL Server, un alt produs al firmei Microsoft care gestioneaza baze de date;

§         permite accesul la baze de date din reteaua Internet, fiind un instrument util pentru publicarea informatiilor in paginile Web;

§         este autodocumentat prin help, apelabil contextual la cerere;

§         contine instrumente wizard care permit utilizatorului crearea facila a unor obiecte;

§         accepta nume lungi in definirea fisierelor;

§         permite crearea de comenzi rapide (shortcuts)in vederea accesarii obiectelor ACCESS;

§         permite crearea de grupuri de obiecte definite de utilizator in cadrul bazei de date;

§         permite setarea proprietatilor initiale ale bazei de date cum ar fi titlul aplicatiei, atasarea de pictograme (icons), precum si forma de afisare initiala;

§         ofera posibilitatea de a crea o copie a bazei de date si de a se realiza sincronizarea intre diferitele copii ale bazei de date.

3.3.2. Arhitectura microsoft ACCESS

(59) O baza de date Access poate fi definita ca o colectie de obiecte: tabele (table), cereri de interogare (query), formulare (form), rapoarte (report), pagini Web (pages), comenzi macro (macro) si module (module).

3.3.2. 1. Tabela (Table)

Tabela este un obiect definit de utilizator in care sunt stocate datele primare (expresia modelului relational).

(60) In cadrul bazei de date, intre tabele se pot stabili relatii, care in functie de momentul crearii se impart in doua tipuri:

§         relatii permanente - se stabilesc dupa definirea tabelelor si sunt cerute de modelul ralational, facand parte din structura bazei de date. Acestea se realizeaza de obicei prin corespondentele cheie primara - cheie externa si sunt memorate in baza de date.

§         relatii temporare - se stabilesc intre tabele cu ocazia definirii unor cereri de interogare, nefiind inregistrate in structura bazei de date.

Relatiile care se pot stabili intre tabele sunt de trei tipuri:

§         unu la mai multi (one to many);

§         unu la unu (one to one);

§         mai multi la mai multi (many to many)

3.3.2.2. Formularul (Form)

Formularul este un obiect ce reprezinta interfata principala intre utilizator si o aplicatie Microsoft Access.

In cadrul unei aplicatii, formularele pot indeplini mai multe functii:

§         afisarea si editarea datelor - cea mai des intalnita forma de utilizarea a formularului. Formularul afiseaza datele in forma dorita de proiectantul aplicatiei. De asemenea, datele afisate in cadrul formularelor pot fi modificate si chiar sterse.

§         controlul operatiilor realizate de aplicatie - formularele impreuna cu comenzi macro sau proceduri Visual Basic pot realiza afisarea automata a anumitor date sau executarea automata a unui sir de operatii;

§         introducerea de date;

§         afisarea de mesaje - formularele pot furniza informatii privind modul in care aplicatia poate fi utilizata sau despre operatiile ce urmeaza a fi executate;

§         tiparirea informatiilor - desi mai rar intalnita aceasta functie, totusi sunt cazuri in care prin intermediul formularelor se pot tipari anumite informatii.

3.3.2.3. Cererea de interogare (Query)

Cererea de interogare este un obiect care permite vizualizarea informatiilor obtinute prin prelucrarea datelor din una sau mai multe tabele si/sau alte cereri de interogare.

(61) Se cunosc cinci tipuri de cereri de interogare:

§         selectie (select);

§         analiza incrucisata (crosstab);

§         actiune (action);

§         SQL (Structured Query Language);

§         parametrata (parameter)

3.3.2.4. Raportul (Report)

Raportul este un obiect care permite formatarea si tiparirea la imprimanta a informatiilor obtinute in urma consultarii bazei de date sub forma de documente.

Un raport este de regula o situatie finala in care o grupare de date este prezentata intr-un anumit format si o structura de pagina in functie de necesitatile utilizatorilor si scopurilor pentru care a fost creat: de informare sau de fundamentare a deciziilor.

Un raport poate include totaluri, subtotaluri (dupa anumite criterii), subformulare grafice si obiecte de tip OLE. Sursa datelor unei situatii finale o constituie in principal cererile de interogare sau tabelele, restul facand parte din structura acestora.

Elementele de legatura intre sursa de date si situatiile finale sunt controalele, zonele de text (pentru datele numerice si alfanumerice), cadrele (pentru imagini si grafice) si etichetele (pentru titluri, linii separatoare si patrate decorative).

3.3.2.5. Pagina Web de accesare a datelor (Data Aceess Pages)

(62) Reprezinta un obiect care include un fisier HTML si alte fisiere suport in vederea furnizarii accesului la date prin intermediul browser-elor Internet.

3.3.2.6. Comanda Macro (Macro)

Este un obiect care contine o definitie structurata a uneia sau mai multor actiuni pe care Access lea realizeaza ca raspuns la un anumit eveniment.

3.3.2.7. Modulul (Module)

(63) Reprezinta un obiect care contine proceduri definite de utilizator si scrise in limbajul de programare Visual Basic.

3.4. PREMISELE APLICARII SI RESPECTARII RESTRICTIILOR (CONSTRANGERILOR) DE INTEGRITATE

Relatiile unei baze de date reflecta realitatea modelata si de aceea valorile pe care le contin trebuie sa respecte anumite reguli, care sa corespunda celor din realitate.

(64) Constrangerile de integritate (integrity constraints) sunt reguli care se definesc la proiectarea bazei de date si care trebuie sa fie respectate de orice stare a  acesteia.  Premizele respectarii acestor reguli se creeaza inca din etapa de proiectare a bazei de date cand se au in vedere nu numai constrangerile intra-relatie (de domeniu, de tuplu si impuse prin dependente de date) ci si cele impuse de necesitate mentinerea integritatii referentiale a datelor. De aceea in etapa de proiectare a bazei de date se face normalizarea ei bazata pe analiza anomaliilor ce ar  putea sa apara la efectuarea unor modificari la nivel conceptual si la nivelul datelor.

3.4.1. Sinteza privind proiectarea bazelor de date

Proiectarea unei baze de date presupune realizarea modelelor conceptual, logic si fizic prin trecerea de la Modelul conceptual al datelor (MCD) la Modelul logic al datelor (MLD), apoi de la Modelul logic al datelor (MLD) la Modelul fizic al datelor (MFD).

(65) Modelul conceptual al datelor se bazeaza pe modelul Entitate - Asociere  (EA). Corespondentele intre entitati care se caracterizeaza prin cardinalitati maxime de  1,1 si care de regula nu au proprietati specifice, se concretizeaza in restrictii de integritate functionala (RIF), iar asocierile sunt denumite ierarhice.

Corespondentele pentru care cardinalitatile maxime cu valori egale cu n (sau mai mari ca 1) sunt restrictii de integritate multipla (RIM); asocierile in acest caz, se numesc non-ierarhice.

Acestea din urma se recunosc usor fiindca de cele mai multe ori au proprietati (atribute) specifice, in timp ce asocierile ierarhice, in general, nu au caracteristici proprii.

MLD se obtine aplicand regulile de trecere de la MCD la MLD:

Modelul logic al datelor se poate prezenta astfel:

a)                  scriind numele relatiei, urmat de atributele sale intre paranteze; cheia primara se subliniaza cu linie continua, iar cheia externa - cu linie punctata sau se marcheaza cu semnul diez #

b)                  grafic, utilizand pentru relatie simbolul din MCD pentru entitate, iar pentru evidenta legaturilor - linii orientate; in ceea ce priveste cheile primare si externe, se subliniaza la fel ca la punctul a).

Trecerea de la MLD la MFD se face utilizand facilitatile si instrumentele oferite de SGBD-ul ales. De exemplu, in SGBD Access, care implementeaza in totalitate teoria modelului relational, trecerea de la MLD la MFD se face dupa cum urmeaza:

§         relatiile se transpun in tabele;

§         legaturile dintre tabele sunt asigurate prin corespondentele intre cheile primare si cele externe.

3.4.2. Normalizarea

(66) Este procesul de transformare succesiva a unei BDR in vederea aducerii sale intr-o forma standard optimizata, denumita forma normala.

Prin normalizare se are in vedere:

§         eliminarea anomaliilor,

§         a dependentelor nedorite intre date si

§         eliminarea redundantelor

                        a) Anomaliile se manifesta sub forma

§         Limitarii posibilitatilor de inserare a datelor

§         Pierderilor de date la stergere

§         Aparitiei de inconsistente la modificarea datelor

                        b) Dependente

§                     Dependenta functionala - un atribut B depinde functional de un atribut A dintr-o tabela  daca fiecarei valori a lui A ii corespunde numai o valoare a lui B.

o       Un atribut B depinde functional complet de un grup de atribute daca atributul B este dependent functional de fiecare atribut din grup.

§                     Dependenta tranzitiva - daca un atribut B depinde de un atribut A si C depinde de B atunci C se afla in dependenta tranzitiva fata de A.

§                     Dependenta multivaloare - daca valorii unui atribut A ii corespund doua sau mai multe valori ale atributului B exista dependenta multivaloare

Forme normale

§                     FN1 - eliminarea cimpurilor repetitive si compuse

§                     FN2 - FN1 +  eliminarea dependentelor functionale partiale pentru atributele non- cheie

§                     FN3 - FN2 +  eliminarea dependentelor functionale tranzitive pentru atributele non-          cheie

§                     FN4 - FN3 +  eliminarea dependentelor functionale multivaloare pentru atributele             non-cheie

§                     FN5 - FN4 +  eliminarea dependentelor jonctiune pentru atributele non-cheie

Exemplu de normalizare

Forma nenormalizata a articolului comanda ar fi

comanda(nr_com, data_com cod_client, den_client, adresa_client,cont_client, banca_client, cod_prod, den_prod,um, pu, cant)

Aplicand FN1 rezulta doua articole si deci doua entitati:

comanda(nr_com, data_com, cod_client, den_client, adresa_client, cont_client, banca_client)

detalii_comanda (nr_com, cod_prod, den_prod,um, pu, cant)

Aplicand  FN2 rezulta:

comanda(nr_com, data_com, cod_client, den_client, adresa_client,cont_client, banca_client)

detalii_comanda (nr_com, cod_prod, cant)

produse(cod_prod, den_prod, um, pu)

Aplicand  FN3 rezulta:

comanda(nr_com, data_com, cod_client)

clienti(cod_client, den_client, adresa_client, cont_client, banca_client)

detalii_comanda (nr_com, cod_prod, cant)

produse(cod_prod, den_prod, um, pu)

(67)

3.4.3. Actualizarea

§                     Consta in tinerea la zi a tabelelor, structurii tabelelor si a inregistrarilor din tabele.

§                     Se realizeaza la doua niveluri:

§         Nivel conceptual (nivelul de definire a datelor) actualizarea consta in:

·   Adaugarea de noi tabele

·   Modificarea structurii tabelelor :

·   Adaugarea de coloane

·   Stergerea de coloane

·   Modificarea proprietatilor coloanelor existente

·   Stergerea de tabele

§         Nivelul datelor : adaugarea, modificarea si stergerea de inregistrari din tabelele bazei de date. Actualizarea poate fi la nivel global si la nivel punctual.

Daca la proiectarea bazei de date s-au avut in vedere aspectele enumerate mai sus la normalizare si la actualizare, baza de date are toate sansele sa functioneze corect. Mai ramane ca si utilizatorii bazei de date sa respecte restrictiile de integritate, care de obicei sunt specificate in manualul de utilizare al aplicatiei informatice ce contine baza de date  normalizata.