manual licenta - calculatoate si tehnologia informatiei 2012

7/31/2019 Manual Licenta - Calculatoate si Tehnologia informatiei 2012

1/200

CUNOTINE DE SPECIALITATE

INFORMATIC ECONOMIC

CAP.1. BAZE DE DATE Conf.univ.dr. ANCA MEHEDINU

CAP.2. PROGRAMARE ORIENTAT OBIECT I STRUCTURI DE DATE Prof. univ.dr. GEORGETA OAV i Conf.univ.dr. AMELIA BDIC

CAP.3. SISTEME DE OPERARE Conf.univ.dr. SORIN POPA

CAP.4. PROIECTAREA SISTEMELOR INFORMATICE Conf.univ.dr.RZVAN BUE

CAP.5. PROGRAMARE N INTERNET- Conf.univ.dr. AMELIA BDIC

2011


2/200

1

CUPRINS

CAP.1. BAZE DE DATE 31.1. CONCEPTE ALE BAZELOR DE DATE RELAIONALE 3

1.1.1. Definiii. 31.1.2. Componente ale bazelor de date relaionale 31.1.3. Niveluri de abstractizare a datelor 71.1.4. Proiectarea bazelor de date relaionale. Etape.Normalizarea bazelor de date 8

1.2. CONCEPTE SQL 161.2.1. Conectarea la baza de date 181.2.2. Convenii de sintax SQL 19

1.3. DEFINIREA I INTEROGAREA DATELOR FOLOSIND LIMBAJUL SQL 211.3.1. Instruciuni DDL (Data Definition Language) 211.3.2. Instruciuni DQL (Data Query Language 261.3.3. Interogri din tabele multiple 33

1.3.4. Funcii SQL avansate 371.3.5. Folosirea avantajelor oferite de vizualizri 391.4. ACTUALIZAREA DATELOR FOLOSIND LIMBAJUL SQL 39

CAP.2. PROGRAMARE ORIENTAT OBIECT I STRUCTURI DE DATE 432.1. CARACTERISTICI GENERALE ALE PROGRAMRII ORIENTATE OBIECT 43

2.1.1. Principiile ce stau la baza programrii orientate obiect 432.1.2. Avantajele programrii orientate obiect 452.1.3. Caracteristici generale ale claselor n Visual C++ 47

2.2. UTILIZAREA BAZELOR DE DATE, PROGRAMAREA OLE I COM 582.2.1. Utilizarea bazelor de date 58

2.2.2. Noiuni de programare OLE i COM 592.3. TIPURI SI STRUCTURI DE DATE. TIPURI DE DATE ABSTRACTE 622.4. LISTE, STIVE, COZI 692.5. ARBORI. REPREZENTARE, PARCURGERE 73

CAP.3. SISTEME DE OPERARE 783.1. NOIUNI INTRODUCTIVE PRIVIND SISTEMELE DE OPERARE 78

3.1.1. Definiie i rol 783.1.2. Funcii 783.1.3. Componentele sistemelor de operare 793.1.4. Moduri de operare 81

3.1.5. ntreruperi 823.2. PROCESE CONCURENTE 84

3.2.1. Noiunea de proces 843.2.2 Strile unui proces 853.2.3. Planificarea unitii centrale 86

3.3. GESTIUNEA MEMORIEI 933.3.1 Gestiunea n cazul multiprogramrii 933.3.2. Strategii de administrare a spaiului din memoria intern 973.3.3. Mecanismul de swapping 99

3.4. SISTEMUL DE OPERARE UNIX 1003.4.1. Elemente introductive privind sistemul de operare UNIX 1003.4.2. Gestiunea utilizatorilor i grupurilor 1033.4.3. Permisiunile de acces asupra fiierelor i directoarelor 1073.4.4. Sistemul de fiiere al UNIX 112


3/200

2

CAP.4. PROIECTAREA SISTEMELOR INFORMATICE 1174.1. SISTEME INFORMATICE 1174.2. METODOLOGII DE REALIZARE A SISTEMELOR INFORMATICE 119

4.2.1. Etapele de realizare a sistemelor informatice 1194.2.2. Ordinea executrii etapelor 120

4.2.3. Metode i tehnici de realizare a sistemelor informatice 1224.3. ANALIZA SISTEMULUI INFORMAIONAL EXISTENT 1244.3.1. Conceptul de analiz a sistemelor informaionale 1244.3.2. Obiectivele i fazele analizei sistemului informaional existent (ASIE) 1254.3.3. Organizarea i conducerea ASIE 1264.3.4. Realizarea analizei sistemului informaional existent 127

4.4. PROIECTAREA GENERAL A SISTEMELOR INFORMATICE 1344.4.1. Obiective i activiti specifice proiectrii generale 1344.4.2. Proiectarea ieirilor sistemului informatic 1364.4.3. Proiectarea bazei informaionale de intrare 1394.4.4. Proiectarea codurilor 142

4.5. PROIECTAREA DE DETALIU 1454.5.1. Caracteristicile generale ale proiectrii de detaliu 1454.5.2. Proiectarea fiierelor 1464.5.3. Stabilirea ordinii de prelucrare a fiierelor de baz 1464.5.4. Determinarea procedurilor 1474.5.5. Proiectarea procedurilor 147

4.6. IMPLEMENTAREA SISTEMELOR INFORMATICE 1494.6.1. Asigurarea condiiilor de punere n funciune 1504.6.2. Funcionarea experimental i punerea n funciune a sistemului proiectat 1514.6.3. Documentaia final a sistemelor informatice 152

4.7. EVALUAREA SISTEMELOR INFORMATICE 1534.7.1. Eficiena economic a sistemelor informatice 1534.7.2. Managementul calitii sistemelor informatice 154

CAP.5. PROGRAMARE N INTERNET 1565.1. INTERNET I WEB. ARHITECTURI DE SISTEME DISTRIBUITE 156

5.1.1. Noiuni generale 1565.1.2. World Wide Web 1585.1.3. Protocolul HTTP 1595.1.4. Arhitecturi multistrat 1625.1.5. Paradigme de programare distribuit 163

5.2. PROGRAMARE PE PARTE DE CLIENT 1665.2.1. Limbajul HTML 1665.2.2. Tehnologii DynamicHTML 1705.2.3. Miniaplicatii Java 1735.2.4. Programare la client folosind scripting 175

5.3. PROGRAMARE PE PARTEA DE SERVER 1785.3.1. Servere WWW 1785.3.2. Gazde virtuale 1795.3.3. Tehnologiile SSI i CGI 1805.3.4. Miniservere Java 181

5.4. SERVERE DE BAZE DE DATE 184

5.5. LIMBAJUL DE METAMARCARE XML 188

BIBLIOGRAFIE 197


4/200

3

CAP.1. BAZE DE DATE

1.1. CONCEPTE ALE BAZELOR DE DATE RELAIONALE

1.1.1. DefiniiiBaze de dateO baz de dateeste o colecie de informaii interrelaionate gestionate ca o singur unitate.

Aceast definiie este intenionat foarte larg, deoarece exist mari diferene ntre concepiilediferiilor productori care pun la dispoziie sisteme de baze de date. De exemplu, OracleCorporation definete o baz de date ca fiind o colecie de fiiere fizice gestionate de o singurinstan (copie) a produsului software pentru baze de date, n timp ce Microsoft definete o bazde date SQL Server ca fiind o colecie de date i alte obiecte. Un obiect al bazei de date este ostructur de date denumit stocat n baza de date, cum ar fi un tabel, o vizualizare sau un index.

Sisteme de gestiune a bazelor de dateUn sistem de gestionare a bazei de date (DBMS - database management system) este un

produs software furnizat de productorul bazei de date. Produse software precum MicrosoftAccess, Microsoft SQL Server, Oracle Database, Sybase, DB2, INGRES, MySQL iPostgreSQL fac parte din categoria DBMS sau, mai corect,DBMS relaionale (RDBMS).

Sistemul DBMS pune la dispoziie toate serviciile de baz necesare pentru organizarea intreinerea bazei de date, inclusiv: Transferarea datelor n i din fiierele fizice de date, n funcie de cerine. Gestionarea accesului concurenial la date al mai multor utilizatori, inclusiv prevenirea

conflictelor care ar putea fi cauzate de actualizrile simultane. Gestionarea tranzaciilor, astfel nct toate modificrile fcute asupra bazei de date printr-o

tranzacie s fie executate ca o singur unitate. Cu alte cuvinte, dac tranzacia reuete, toatemodificrile efectuate de tranzacie sunt nregistrate n baza de date; dac tranzacia eueaz,nici una dintre modificri nu este nregistrat n baza de date. Totui, unele sisteme RDBMSnu asigur suportul pentru tranzacii.

Accept un limbaj de interogare, care reprezint sistemul de comenzi folosit de utilizatorpentru a obine date din baza de date. SQL este principalul limbaj folosit pentru sistemeleDBMS relaionale.

Funcii pentru salvarea bazei de date i pentru refacerea bazei de date n urma erorilor. Mecanisme de securitate pentru mpiedicarea accesului neautorizat la date i modificarea

acestora.

Baze de date relaionaleO baz de date relaional este o baz de date care respect modelul relaional, dezvoltat de

Dr. E. F. Codd. Modelul relaional prezint datele sub forma familiarelor tabele bidimensionale,similar cu o foaie de calcul tabelar Excel. Spre deosebire de o foaie de calcul tabelar, nu esteobligatoriu ca datele s fie stocate ntr-o form tabelar, iar modelul permite i combinareatabelelor(crearea uniunilor (joining), n terminologia relaional) pentru formarea vizualizrilor,care sunt prezentate tot ca tabele bidimensionale. Flexibilitatea extraordinar a bazelor de daterelaionale este dat de posibilitatea de a folosi tabelele independent sau n combinaii, fr nici oierarhie sau secven predefinit n care trebuie s se fac accesul la date.

1.1.2. Componente ale bazelor de date relaionale

1. Tabele


5/200

4

Unitatea primar de stocare a datelor ntr-o baz de date relaional este tabelul, care este ostructur bidimensional compus din rnduri i coloane. Fiecare tabel reprezint o entitate, ceeace nseamn o persoan, un loc, un lucru sau un eveniment care trebuie s fie reprezentat n bazade date, cum ar fi un client, un cont bancar sau o tranzacie bancar. Fiecare rnd al tabeluluireprezint o apariie a entitii.

Figura 1.1 reprezint coninutul parial al unui tabel numit MOVIE (Film).

Tabelul MOVIE este parte a unei baze de date pentru un magazin de produse video,folosit ca exemplu. Tabelul MOVIE conine date care descriu filmele disponibile n magazinulde produse video. Fiecare rnd din tabel reprezint un film, iar fiecare coloan reprezint ocaracteristic a filmului respectiv, cum ar fi titlul filmului.

MOVIE_ID MOVIE_GENRE_

CODE

MPAA_RATING_

CODE

MOVIE_TITLE RETAIL_PRICE_VHS

RETAIL_PRICE_DVD

YEAR_PRODUCED

1 Drama R Mystic River 58,97 19,96 2003

2 ActAd R The Last Samurai 15,95 19,96 2003

Fig. 1.1 Structura tabelei Movie (Film)

2. RelaiiRelaiile reprezint asocierile dintre tabelele bazelor de date relaionale. Dei fiecare tabel

relaional poate exista independent, esena bazelor de date este tocmai stocarea informaiilorntre care exist legturi. De exemplu, pe lng filmele propriu-zise, se pot stoca i informaiidespre categoriile folosite de magazin pentru organizarea inventarelor de filme. n acelai timp,

putei stoca i informaii despre copiile fiecrui film, inclusiv data la care a fost primit copia iformatul acesteia, cum ar DVD sau VHS. Prin folosirea relaiilor, se pot asocia tabelele nrudite,ntr-un mod formal, uor de folosit astfel nct s combinm date din tabele multiple n aceeai

interogare a bazei de date, dar pstrnd flexibilitatea de a include numai informaiile care lintereseaz pe utilizator. Posibilitatea de a selecta din baza de date numai informaiile care neintereseaz ne permite s ajustm informaiile din baza de date n funcie de cerinele specificeale persoanelor sau aplicaiilor care au acces la baza de date.

Figura 1.2 prezint patru tabele din baza de date a magazinului de produse video i relaiiledintre acestea, ntr-un format cunoscut sub numele de diagram de relaii a entitilor (ERD -Entity Relationship Diagram).

Fig. 1.2 Diagrama ERD a bazei de date pentru magazinul de produse video(prezentare parial)

MPAA_RATINGMPAA_RATING_CODE (pk)MPAA_RATING_DESCRIPTION

MOVIEMOVIE_ID (pk)MOVIE_GENRE_CODE (fk1)MPAA_RATING_CODE (fk2)MOVIE_TITLERETAIL_PRICE_VHSRETAIL_PRICE_DVDYEAR_PRODUCED

MOVIE_GENREMOVIE_GENRE_CODE (pk)MOVIE_GENRE_DESCRIPTION

MOVIE_COPYMOVIE_ID (pk, fk)COPY_NUMBER (pk)DATE_ACQUIREDDATE_SOLDMEDIA_FORMAT


6/200

5

Diagramele ERD ne pun la dispoziie o modalitate de prezentare a proiectului general alunei baze de date relaionale, ntr-un format uor de neles pentru utilizatorii bazei de date,indiferent dac au sau nu cunotine tehnice. Fiecare dreptunghi din diagram reprezint un tabelrelaional, cu numele tabelului scris deasupra liniei orizontale i coloanele tabelului enumerate

pe vertical, n poriunea principal a dreptunghiului.

n funcie de numrul de elemente, ntre care se stabilesc relaii, aparinnd celor doucolecii, aceste relaii pot fi de tip unu la unu, unu la muli i muli lamuli.

Relaiile de tipul 11 (unu la unu), care presupun c unuimembru din colecia A i corespunde un singur membru din colecia B.

Relaiile de tipul 1m sau m1 (unu lamuli sau muli la unu), care presupun c

unui membru din prima entitate A icorespund mai muli membri din a doua

entitate B; astfel de relaii se mai numesc irelaii ierarhice.

Relaiile de tipul mm (muli la muli), n care unuimembru din entitatea A i corespund mai multe date din colecia B imai multor date din colecia A i corespunde o singur dat dincolecia B.

Relaii de tip muli la muli se mai numesc i relaii de tip reea. O relaie muli la muli seva descompune ntotdeauna n dou relaii, o relaie tip unu la muli i respectiv o a doua relaiede tip muli la unu prin intermediul unei entiti de legtur.

Fiecare relaie este prezentat n diagrama ERD ca o linie ce conecteaz dou tabele. Celedou capete ale liniei arat cardinalitatea maxim a relaiei, respectiv numrul maxim de rnduridintr-un tabel care pot fi asociate cu un rnd dat din tabelul aflat la cellalt capt al relaiei.

Cardinalitatea maxim poate fi: unu (caz n care linia nu are nici un simbol special la capt) sau mai multe (caz n care linia se termin cu un simbol numit picior de cioar (crow's foot) -

linia se mparte la capt n trei segmente).n apropiere de captul liniei se afl un alt simbol, care arat cardinalitatea minim, adic

numrul minim de rnduri dintr-un tabel care poate fi asociat cu tabelul de la cellalt capt alrelaiei.

Cardinalitatea minim poate fi zero, indicat printr-un cerc desenat pe linie, sau unu,indicat printr-o liniu care taie linia relaiei.

De exemplu, relaia dintre tabelele MPAA_RATING i MOVIE din figura 1-2 este orelaie de tip unu-la-mai-muli, ceea ce nseamn c fiecare rnd din tabelul MPAA_RATING(tabelul din partea unu, numit i tabelprinte")poate fi asociat cu mai multe rnduri din tabelulMOVIE (tabelul din partea mai muli" a relaiei, numit i tabel copil'"), dar fiecare rnd dintabelul MOVIE poate fi asociat cu un singur rnd din tabelul MPAA_RATING.

Relaia este logic, deoarece orice film lansat n SUA poate avea o singur categorieMPAA, dar o categorie poate fi asociat mai multor filme diferite. Este adevrat ca filmele suntuneori cenzurate" pentru a putea fi ncadrate n diferite categorii, dar aceast problem esterezolvat uor, prin tratarea diferitelor versiuni ale aceluiai film ca i cum ar fi filme diferite, lafel cum facem atunci cnd un film este reluat cu ali actori. Este foarte important s inei seamade aceste lucruri, deoarece bazele de date relaionale accept numai relaiile de tip unu-la-mai-

muli sau unu-la-unu.Cardinalitatea minim arat dac participarea la o anumit relaie este obligatorie sau

opional. Toate relaiile din fig. 1.2 sunt obligatorii n partea unu" i opionale n partea mai


7/200

6

muli", aceasta fiind cea mai frecvent folosit form de relaie. Dac ne uitm din nou la relaiadintre tabelele MPAA_RATING i MOVIE, aceasta nseamn c fiecare rnd din tabelulMOVIE trebuie s aib un rnd corespondent n tabelul MPAA_RATING, dar nu esteobligatoriu ca fiecare rnd din tabelul MPAA_RATING s aib asociat un rnd din tabelulMOVIE. Dac vrei s permitei ca inventarul de filme al magazinului s conin titluri care nuau asociat o categorie MPAA, liniua de la captul dinspre tabelul MPAA_RATING al liniei

care reprezint relaia cu tabelul MOVIE va fi nlocuit de un cerc. Dei sunt relativ frecventntlnite cazurile n care partea unu" a unei relaii nu este obligatorie, este foarte neobinuit savei o relaie n care s fie obligatorie partea mai muli" a relaiei, ceea ce ar nsemna c tabelul

printe trebuie s aib n orice moment cel puin un copil" n baza de date.Relaiile sunt implementate folosind coloane corespondente din cele dou tabele

participante. n diagrama ERD, coloana sau coloanele subliniate din fiecare tabel, avnd ndreapta notaia pk", reprezint cheia primar (primary key), adic o coloan sau un set decoloane care identific n mod unic fiecare rnd dintr-un tabel.

Un tabel poate avea o singur cheie primar. Totui, o cheie primar poate fi compus dinmai multe coloane, dac aceasta este calea de formare a unei chei unice. Dac o cheie primareste folosit ntr-un alt tabel pentru stabilirea unei relaii, poart numele de cheie extern.

n fig. 1.2, observai coloanele cheie extern folosite n tabelul MOVIE pentru crearearelaiilor cu tabelele MOVIE_GENRE i MPAA_RATING i marcate cu identificatoarele" i " n dreapta numelui coloanei cheie extern.

Cheile primare i cheile externe sunt blocuri de construcie fundamentale ale modeluluirelaional, deoarece stabilesc relaii i permit crearea legturilor ntre date, atunci cnd estenecesar. Trebuie s nelegei acest concept pentru a putea nelege cum funcioneaz bazele dedate relaionale.

3. RestriciiO restricie este o regul specificat pentru un obiect al bazei de date (de obicei, un tabel

sau o coloan), avnd rolul de a limita ntr-un mod oarecare domeniul de valori permise pentruobiectul respectiv al bazei de date

Dup ce sunt specificate, restriciile sunt impuse automat de sistemul DBMS i nu pot fiocolite dect dac o persoan autorizat le dezactiveaz sau le terge (le elimin). Fiecarerestricie primete un nume unic, astfel nct s poat fi referit n mesajele de eroare i ncomenzile folosite ulterior n baza de date. Este recomandabil ca proiectanii bazei de date sdenumeasc restriciile, deoarece numele generate automat de baza de date nu sunt foartedescriptive.

Exist mai multe tipuri de restricii pentru baze de date: Restricia NOT NULL. Poate fi plasat pe o coloan pentru a mpiedica folosirea valorilor

nule. O valoare nul (null) este o modalitate special prin care sistemul RDBMS trateaz

valoarea unei coloane pentru a indica faptul c valoarea coloanei respective nu este cunoscut.O valoare nul nu este acelai lucru cu un spaiu liber, un ir vid sau valoarea zero este ovaloare special care nu este egal cu nimic altceva.

Restricia cheie primar (primary key). Definit pe coloana (coloanele) cheie primar aleunui tabel pentru a garanta c valorile cheie primar sunt ntotdeauna unice n ntreg tabelul.Atunci cnd cheia primar este definit pe mai multe coloane, combinaia valorilor acelorcoloane trebuie s fie unic n tabel - o coloan care reprezint doar o parte a cheii primare

poate conine valori duplicate n tabel. Restriciile cheie primar sunt aproape ntotdeaunaimplementate de RDBMS prin folosirea unui index. Indexul este un tip special de obiect al

bazei de date care permite efectuarea cutrilor rapide n valorile coloanei. Atunci cnd ntabele sunt inserate rnduri noi, sistemul RDBMS verific automat indexul pentru a se asigura

c pk a noului rnd nu este deja folosit n tabel i, dac se ntmpl acest lucru, respingecererea de inserare. Cutarea n indexuri se face mult mai repede dect cutarea n tabel; caurmare, indexarea cheii primare este esenial pentru orice tabel, indiferent de dimensiunea


8/200

7

acestuia, astfel nct cutarea cheilor duplicate la fiecare inserare s nu duc la o reduceresemnificativ a performanelor. O caracteristic suplimentar a cheilor primare este faptul cnu pot fi definite dect pe coloane pentru care a fost definit i restricia NOT NULL.

Restricia de unicitate (unique). Definit pe o coloan sau un set de coloane care trebuie sconin valori unice n cadrul tabelului. Ca i n cazul cheilor primare, sistemul RDBMSfolosete aproape ntotdeauna un index ca modalitate de impunere eficient a restriciei,

Totui, spre deosebire de cheile primare, un tabel poate avea definite mai multe restricii deunicitate, iar coloanele care particip la o restricie de unicitate pot conine (n cele mai multesisteme RDBMS) i valori nule.

Restricia referenial(numita uneori restricie de integritate referenial). O restricie careimpune o relaie ntre dou tabele dintr-o baz de date relaional. Prin impunere se nelegec sistemul RDBMS se asigur ntotdeauna, n mod automat, c fiecrei valori a cheii externei corespunde o valoare a cheii primare n tabelul printe. Pe scurt, restricia referenialgaranteaz c relaia dintre cele dou tabele i valorile corespondente ale cheii primare i cheiiexterne i pstreaz logica n orice moment.

Restricia CHECK. Folosete o instruciune logic simpl (scris n SQL) pentru a validavaloarea unei coloane. Rezultatul instruciunii trebuie s fie o valoare logic de adevrat

(true) sau fals (false), astfel nct un rezultat adevrat s permit inserarea n tabel a valoriicoloanei, iar un rezultat fals s duc la rejectarea valorii coloanei, cu mesajul de eroarecorespunztor.

4. VizualizriO vizualizare (view) este o interogare stocat n baza de date care pune la dispoziia

utilizatorului un subset personalizat al datelor din unul sau mai multe tabele ale bazei de date.Cu alte cuvinte, o vizualizare este un tabel virtual, deoarece arat ca un tabel i, n cele maimulte privine, se comport ca un tabel, dar nu stocheaz date (nu este stocat dect interogareaSQL care definete vizualizarea). Vizualizrile au mai multe funcii utile: Mascheaz coloanele pe care utilizatorul nu este nevoie s le vad (sau nu-i este permis s le

vad). Mascheaz rndurile pe care utilizatorul nu este nevoie s le vad (sau nu-i este permis s le

vad). Mascheaz operaiile complexe efectuate n baza de date, cum ar fi uniunile de tabele

(respectiv combinarea coloanelor din tabele multiple ntr-o singur interogare a bazei dedate).

mbuntesc performanele interogrilor (n unele sisteme RDBMS precum Microsoft SQLServer).

1.1.3. Niveluri de abstractizare a datelorntr-un sistem informatic ce utilizeaz BD,

organizarea datelor poate fi analizat din maimulte puncte de vedere i pe diferite niveluri. Deobicei, abordarea se face pe trei niveluri: intern,conceptuali extern(figura 1.3).

Fig. 1.3 Niveluri de abstractizare

Nivelul intern. Structura datelor este descris foarte detaliat, fiind accesibil numai

Nivelextern Grup 1 . Grup n

Nivelconceptual Schema conceptuala

Nivel Schema internaintern

Mediul de stocare


9/200

8

specialitilor (ingineri de sistem, programatori n limbaje de asamblare sau alte limbaje apropiatede main"). Cele dou pri principale ale bazei la acest nivel sunt:1. un set de programe care interacioneaz cu sistemul de operare pentru mbuntirea

managementului bazei de date.2. fiierele stocate n memoria extern a calculatorului.

Fiierele ce conin datele propriu-zise sunt alctuite din articole sau nregistrri cu format

comun. La acest nivel, structura BD se concretizeaz n schema intern.Nivelul conceptual. Este nivelul imediat superior celui fizic, datele fiind privite prinprisma semanticii lor; intereseaz coninutul lor efectiv, ca i relaiile care le leag de alte date.Reprezint primul nivel de abstractizare a lumii reale observate. Obiectivul acestui nivel lconstituie modelarea realitii considerate, asigurndu-se independena bazei fa de oricerestricie tehnologic sau echipament anume. ntreaga baz este descris prin intermediul unuinumr restrns de structuri. Toi utilizatorii i exprim nevoile de date la nivel conceptual,

prezentndu-le administratorului bazei de date, acesta fiind cel care are o viziune globalnecesar satisfacerii tuturor cerinelor informaionale. La acest nivel, structura BD seconcretizeaz n schema conceptual.

Nivelul extern. Este ultimul nivel de abstractizare la care poate fi descris o baz de date.

Structurile de la nivelul conceptual sunt relativ simple, ns volumul lor poate fi deconcertant. Iardac la nivel conceptual baza de date este abordat n ansamblul ei, n practic un utilizator sauun grup de utilizatori lucreaz numai cu o poriune specific a bazei, n funcie de departamentuln care i desfoar activitatea i de atribuiile sale (lor). Simplificarea interaciunii utilizatori-BD, precum i creterea securitii BD sunt deziderate ale unui nivel superior de abstractizare,care este nivelul extern. Astfel, structura BD se prezint sub diferite machete, referite uneori ica sub-scheme, scheme externe sau imagini (view-uri), n funcie de nevoile fiecrui utilizatorsau grup de utilizatori.

1.1.4. Proiectarea bazelor de date relaionale. Etape. Normalizarea bazelor de date

Proiectarea unei baze de date este o activitate laborioas i necesit parcurgereaurmtoarelor etape: formularea problemei; analiza cerinelor informaionale i definirea datelor de ieire i a datelor de intrare; definirea tabelelor, a structurii acestora i a relaiilor dintre tabele; optimizarea structurii bazei de date.

Odat ce acest proces a fost finalizat se continu cu: proiectarea procedurilor tehnologice, pentru prelucrarea bazei de date; elaborarea programelor; testarea programelor;

definitivarea documentaiei.Toate aceste activiti necesit, pentru proiectele reale complexe, o munc n echip pe

baza unei metodologii riguroase, cunoscut ca metodologia de analiz i proiectare a sistemelorinformatice. n cadrul unui sistem informatic baza de date reprezint elementul central n jurulcruia se concentreaz celelalte componente ale sistemului.

Formularea problemei presupune stabilirea obiectivelor aplicaiei informatice careasigur actualizarea i exploatarea bazei de date n concordan cu cerinele managementuluiactivitii economice pentru care este proiectat baza de date. Obiectivele unei aplicaiiinformatice sunt legate de asigurarea informaional a desfurrii proceselor decizionalespecifice actului de conducere. Deci, noi trebuie s ne gndim c, prin existena unei baze dedate, s asigurm fondul de informaii, ntr-o structur i de o calitate corespunztoare cucerinele managementului firmei. Baza de date trebuie s permit att obinerea unor informaiide detaliu, elementare, ct i calculul i prezentarea unor indicatori sintetici, agregai. Dac amlua doar dou obiective: reducerea costurilor i creterea productivitii muncii ntr-o firm,


10/200

9

atunci o baz de date trebuie s furnizeze informaii despre consumul factorilor de producie,costurile medii i globale, despre personalul muncitor i producia realizat, despre cheltuielilesalariale etc. Aceste informaii vor servi conducerii la identificarea cilor de reducere a costurilori adoptarea celor mai adecvate msuri pentru reducerea acestor costuri. Dup aplicareamsurilor n practic, informaiile stocate n baza de date trebuie s permit de data aceasta i oanaliz comparat a costurilor noi cu cele vechi, de exemplu, o analiz a dinamicii costurilor pe

baza indicilor statistici. Am ales acest mic exemplu didactic pentru a accentua nc o datcomplexitatea procesului de proiectare a bazei de date.Analiza cerinelor informaionale, pornind de la obiectivele formulate anterior, se

concentreaz asupra a dou probleme: indicatorii, rapoartele, listele i datele de ieire care trebuie obinute; datele de intrare necesare pentru obinerea datelor de ieire.

Acestea sunt cerinele informaionale care nglobeaz att cerinele pentru datele de intrarepe baza crora se creeaz i se actualizeaz baza de date, ct i cerinele pentru datele de ieirefolosite pentru urmrirea, controlul i dirijarea activitii economice. Datele de intrare se culeg,de regul, din documentele primare care circul n cadrul fluxului informaional al firmei. Datelefinale se vor integra n ansamblul de rapoarte, liste, situaii cu rezultate pe care le furnizeaz

sistemul informaional compartimentelor de conducere. Pentru indicatorii inclui n rapoartelefinale, n general pentru oricare din indicatorii de ieire, trebuie s fie foarte clar modul n caresunt obinui prin prelucrarea datelor de intrare. n consecin, acolo unde este cazul, se

precizeaz algoritmii de calcul, regulile de totalizare, sau alte reguli de obinere a fiecreicoloane, sau totaluri din rapoartele finale.

Aceasta are ca punct de plecare inventarierea cmpurilor prezente n situaiile finale i apoigruparea lor n tabele. Gruparea cmpurilor pe tabele se realizeaz prin diverse metode. Dintreaceste metode, dou sunt cele mai utilizate: analiza concordanei IEIRI INTRRI; analiza semnificaiei semantice a datelor.

Analiza concordanei IEIRI INTRRI este o tehnic specific proiectrii sistemelorinformatice care identific documentele primare din care se preiau datele de intrare folosite ncalculul datelor de ieire. Aceste documente vor constitui sursele de creare i actualizare atabelelor bazei de date.

Tehnica este util n cazul n care proiectantul bazei de date este familiarizat cu sistemulinformaional existent.

Un indicator prezent ntr-o situaie final se poate obine astfel: prin preluarea direct din documentul primar, respectiv din tabelul bazei de date; prin aplicarea unui algoritm de calcul.

Tabelele se compun prin gruparea cmpurilor pe principiul apartenenei acestora la anumitedocumente primare care circul n cadrul sistemului informaional.

Analiza semantic se practic atunci cnd proiectantul bazei de date nu are la dispoziie unset de documente primare i apare n cazul sistemelor informaionale care se proiecteaz pentrufirmele noi.

Definirea tabelelor i relaiilor dintre tabele este etapa urmtoare n proiectarea bazei dedate. Analiza cerinelor informaionale i a proceselor de prelucrare va conduce la identificareadatelor ce vor trebui stocate i care vor alctui tabelele bazei de date. O tabel va pstra datele fiedespre toate caracteristicile unei colecii de date, fie numai pentru o parte dintre acestecaracteristici. Aici intervine spiritul analitic al proiectantului. Structura unei tabele estereprezentat de lista cmpurilor asociate tabelei mpreun cu descrierea atributelor fiecrui cmp(natur, lungime, numr de zecimale etc.). n structura unui tabel se regsesc urmtoarelecategorii de cmpuri:

cmpuri de identificare (chei primare i chei condiionate); cmpuri tip dat calendaristic; cmpuri cantitativ-valorice;


11/200

10

cmpuri de legtur cu alte tabele; cmpuri de stare care pstreaz informaii privind ultimele operaii de prelucrare care au fost

efectuate pe nregistrrile din tabel.Relaiile dintre tabele se caracterizeaz prin plasarea unor cmpuri comune n structura

fiecruia dintre tabelele aflate n relaie direct. Pe baza acestor cmpuri, chei, fiecare sistem degestiune a bazelor de date i construiete un mecanism propriu de accesare a nregistrrilor de

date. Aceste mecanisme sunt transparente pentru utilizatorul obinuit. Totui este bine de reinutc nu orice cmp poate fi folosit la stabilirea unei relaii, a unei legturi ntre dou tabele. Numaicmpurile de tip cheie candidat, care au proprietatea de a identifica n mod unic o nregistraredintr-o tabel, pot fi folosite n acest scop. Cheile candidate se mai numesc i indeci. Operaia

prin care se construiete sistemul de legturi pentru ordonarea n vederea regsirii nregistrrilorntr-o tabel se numete indexare. Prin indexare, fiecrei tabele principale de date i se va asocia otabel index corespunztoare cheilor de indexare.

Optimizarea structurii bazei de date este un proces prin care se urmrete: reducerea redundanei datelor; eliminarea anomaliilor de actualizare.

Reducerea redundanei datelorpn la un nivel minim i controlat urmrete eliminareaduplicrii inutile a unor cmpuri n mai multe tabele sau eliminarea cmpurilor obinute princalcul pe baza cmpurilor atomice. Un anumit nivel de redundan, ns, trebuie admis pentru anu denatura realitatea reflectat de date. De exemplu, cmpulVALOAREA_CONTRACTULUI, se calculeaz dup relaia:VALOAREA_CONTRACTULUI=CANTITATE*PRET

Nu este recomandat eliminarea acestui cmp pe considerentul c el se obine automatprin calcul. De exemplu, n cazul n care dup un anumit interval de timp, preurile suport omajorare global, cum se practic foarte des, atunci automat se vor modifica i valorilecontractelor ncheiate anterior datei de majorare a preurilor ori acest lucru nu este corect,contractul odat perfectat nu-i poate modifica preul convenit prin negociere.

Anomaliile de actualizare se refer la anomaliile de tergere, respectiv de modificare. Deexemplu, se consider o firm care deruleaz lunar mii de contracte de aprovizionare, pentru unnomenclator foarte mare de produse agroalimentare, dar care opereaz numai cu civa furnizori.Dac n tabela CONTRACTE sunt incluse alturi de codul furnizorului i denumireafurnizorului, contul su bancar i denumirea bncii, atunci va aprea urmtoarea anomalie deactualizare, n cazul schimbrii bncii i a contului bancar de ctre furnizor. Acest lucru necesit

parcurgerea tuturor nregistrrilor n care exist aceste valori i actualizarea acestora (figura 1.4).

Fig. 1.4 Eliminarea anomaliilor de actualizare

Soluia este de a crea o tabel separat, care are n structur: codul furnizorului, denumirea,

contul i banca acestuia, n tabela CONTRACTE pstrndu-se doar codul furnizorului caelement de legtur, ceea ce previne pierderea de informaii prin spargerea unui tabel n dou. nacest fel modificarea se realizeaz numai asupra unei singure nregistrri.


12/200

11

n 1972, Dr. E. F. Codd, printele bazelor de date relaionale, i-a dat seama c tabelelerelaionale care ndeplinesc anumite criterii pun mai puine probleme la inserarea, actualizareasau tergerea datelor. Ca urmare, a pus la punct un set de reguli care trebuie respectate(organizate n trei forme normale") i un proces numit normalizare, care este o tehnic pentru

producerea unui set de relaii (termenul folosit de Dr. Codd pentru tabele) cu proprietile dorite.Necesitatea normalizrii

Figura 1.5 prezint tabelul MOVIE fr normalizare, aa cum ar arta dac toateinformaiile despre filme ar fi colectate ntr-un singur tabel. Acest exemplu va fi folosit pentruilustrarea procesului de normalizare.

n general, numele coloanelor din tabelele relaionale folosesc liniue de subliniere pentrusepararea cuvintelor. n discuia despre normalizare am eliminat aceste liniue din figuri, pentru aface textul mai uor de citit.

Exist trei probleme care pot aprea n tabelele fr normalizare din bazele de daterelaionale i toate trei exist i n tabelul din figura 1.5. Scopul procesului de normalizare estede a elimina aceste probleme (anomalii) din proiectul bazei de date.MOVIE_ID

MOVIE_GENRE_CODE

MOVIE_GENRE_DESC

LANG_CODE

MPAA_RATING_CODE

MPAA_RATING_DESC

MOVIE_TITLE

YEAR_PRODUCED

DATA_ACQUIRED

DATE_SOLD

MEDIA_FORMAT

RETAIL_PRICE

1 Drama Drama en,fr R under 17requiresaccompanying parentor adultguardian

MysticRiver

2003 01/01/2005

DVD 19.96

2 ActAd Action andAdventure

en,fr,es

R under 17requiresaccompanying parentor adultguardian

The LastSamurai

2003 10/01/2005

DVD 19.96


en,fr,es

R under 17requiresaccompanying parentor adultguardian

The LastSamurai

2003 10/01/2005

VHS 15.95

3 Comdy Comedy en PG-13 Parentsstronglycautioned

Somethings GottaGive

2003 1/10/2005 1/30/2005

DVD 29.99

3 Comdy Comedy en PG-13 Parentsstronglycautioned

Somethings GottaGive

2003 2/15/2005 DVD 29.99

Fig 1.5 Tabelul MOVIE fr normalizare

Anomalia de inserareAnomalia de inserare se refer la o situaie n care nu putei insera date n baza de date din

cauza unei dependene artificiale dintre coloanele unui tabel. S presupunem c vrei sadugai n baza de date a magazinului de produse video un nou gen de film (n coloaneleGENRE_CODE i GENRE_DESCRIPTION) care urmeaz a fi folosit pentru clasificarea

filmelor. Modelul din figura 1.5 nu permite acest lucru dect dac avei un film care s fie plasatn categoria respectiv i pe care va trebui s-1 adugai n tabelul MOVIE n acelai timp.Aceeai restricie este valabil i pentru coloanele MPAA_RATING_CODE iMPAA_RATING_DESCRIPTION. Ar fi mult mai bine dac ai putea aduga noile genuri icategorii nainte de primirea filmelor n magazin.

Anomalia de tergereAnomalia de tergere este inversul anomaliei de inserare. Se refer la situaia n care

tergerea unor date duce la pierderea neintenionat a altor date.De exemplu, dac primul filmdin figura 1.5 (Mystic River) este singurul rnd din tabelul MOVIE pentru care coloanaGENRE_CODE are valoarea Drama" i este ters, se pierde informaia c a existat vreodat ungen numit Drama".

Anomalia de actualizareAnomalia de actualizare se refer la o situaie n care actualizarea unei singure valori

necesit actualizarea mai multor rnduri. De exemplu, dac n tabelul prezentat n figura 1.5


13/200

12

trebuie s modificai descrierea codului MPAA_RATING_CODE R", trebuie s modificai itoate rndurile din tabel pentru filmele cu codul respectiv. Probleme similare apar i pentrucoloana GENRE_DESCRIPTION. Chiar i coloana RETAIL_PRICE are aceast problem,deoarece toate copiile aceluiai film (cu aceeai valoare MOVIE_ID) pe acelai mediu (DVDsau VHS) ar trebui s aib acelai pre. Un alt pericol legat de aceast anomalie este faptul cstocarea unor date redundante poate duce la posibilitatea de a actualiza numai o parte a copiilor

respectivelor date, ceea ce ar avea ca rezultat apariia inconsecvenelor n baza de date.Aplicarea procesului de normalizareDe obicei, normalizarea ncepe de la mijloacele de redare a datelor care sunt (sau vor fi)

prezentate utilizatorilor, cum ar fi pagini web, ecrane ale aplicaiilor, rapoarte i aa mai departe.Colectiv, acestea sunt numite vizualizri de utilizator (user views). Poate prea ciudat la primavedere, dar este ceva obinuit ca proiectarea unui sistem de prelucrare a datelor s nceap de larezultatele pe care le va vedea utilizatorul, parcurgnd apoi drumul napoi ctre mijloacelefolosite pentru obinerea rezultatelor dorite.

n timpul proiectrii bazei de date, procesul de normalizare este aplicat fiecrei vizualizri,iar rezultatul este un set de relaii normalizate care pot fi apoi direct implementate ca tabele ale

bazei de date relaionale. Procesul n sine este destul de simplu, iar regulile nu sunt foarte

dificile. Totui, stpnirea procesului de normalizare cere timp i exerciiu, n special deoareceimpune proiectantului s se gndeasc ntr-un mod conceptual la datele i relaiile pe careintenioneaz sa le foloseasc.

n timpul normalizrii, considerai c fiecare vizualizare este o relaie. Cu alte cuvinte,conceptualizai fiecare vizualizare ca i cum ar fi deja un tabel bidimensional - un mod de lucru

pentru care avei nevoie de experien.Reinei c scopul procesului de normalizare este eliminarea anomaliilor de inserare,

actualizare i tergere. Procesul determin crearea unui numr mai mare de relaii dect ai aveantr-un model fr normalizare. Relaiile suplimentare sunt necesare pentru eliminareaanomaliilor, dar mprirea datelor n mai multe relaii face ca extragerea datelor stocate s fie

puin mai dificil. De fapt, sacrificai o parte din performanele de extragere a datelor i dinuurina utilizrii pentru ca operaiile de inserare, actualizare i tergere s fie mai simple.

Alegerea unul identificator unicPrimul pas al procesului de normalizare const n alegerea unui identificator unic (unique

identifier), care este un atribut (o coloan) sau un set de atribute care identific n mod unicfiecare rnd de date dintr-o relaie.

Identificatorul unic va deveni ulterior cheia primar a tabelului creat din relaianormalizat. Pentru normalizare, este obligatoriu ca fiecare relaie s aib un identificator unic,n multe cazuri, putei gsi un atribut care identific n mod unic datele din fiecare rnd al relaiei

pe care vrei s o normalizai. Atunci cnd nu putei gsi un singur atribut care s poat fi folositca identificator unic, este posibil s gsii mai multe atribute care pot fi concatenate (combinate)

pentru a forma un identificator unic. Atunci cnd identificatoarele unice sunt formate din atributemultiple, fiecare atribut rmne pe propria lui coloan - nu facei dect s definii un identificatorunic format din mai multe coloane.

n foarte puine cazuri, ntr-o relaie nu exist un set rezonabil de atribute care s poat fifolosit ca identificator unic. Atunci cnd se ntmpl acest lucru, trebuie s inventai unidentificator unic, deseori cu valori atribuite secvenial sau aleatoriu pe msur ce noile rnduride date sunt adugate n tabelul bazei de date. Aceast tehnic este sursa unor identificatoareunice, precum numrul de asigurri sociale folosit n Statele Unite, numerele de identificare aleangajailor, numerele de nmatriculare ale mainilor sau CNP.

Relaia Movie din figura 1.5 ne pune o problem n privina gsirii unui identificator unic.La prima vedere, ar prea c atributul Movie_ID este cel mai potrivit n acest scop. Totui,

observai c valorile Movie_ID 2" i 3" apar de cte dou ori, aa c, fr nici un dubiu,aceast valoare nu este unic. Problema este c valoarea Movie_ID identific n mod unic fiecaretitlu, dar magazinul urmrete separat fiecare copie a filmelor pe care le are n stoc. Cauza este


14/200

13

faptul c magazinul se ocup i de nchirierea filmelor i vrea s se asigure c fiecare clientreturneaz exact copia pe care a nchiriat-o. Dup inspectarea datelor folosite ca exemplu i oscurt discuie cu proprietarul magazinului, ajungei la concluzia c n relaia Movie nu existnici o combinaie de atribute care s identifice n mod unic fiecare copie a unui film, aa cinventai un atribut numit Copy_Number i-l adugai n relaie. Ori de cte ori inventai unidentificator unic (sau o parte a unui identificator) este foarte important ca toi s neleag

valorile pe care le va lua acest identificator.n acest caz, proprietarul magazinului decide ca valorile Copy_Number s renceap de la1 pentru fiecare valoare Movie_ID, ceea ce nseamn c valorile Copy_Number sunt unicenumai n combinaie cu valorile Movie_ ID. Relaia rezultat este prezentat n figura 1.6.

Prima form normal: eliminarea datelor repetateO relaie este n prima form normal atunci cnd nu conine atribute cu valori multiple

(atribute multivaloare), adic atribute care au mai multe valori pentru acelai rnd de date. ntr-orelaie, orice intersecie a unui rnd cu o coloan trebuie s conin cel multo valoare pentru carelaia s fie n prima form normal. n figura 1.6, atributul pentru limb (Lang. Code) coninemai multe valori pentru unele dintre filme, aa c-1 putei considera un atribut cu valori multiple.

MOVIE_ID (pk)

COPY_NUMBER(pk)

MOVIE_GENRE_CODE

MOVIE_GENRE_DESC

LANG_CODE

MPAA_RATINGCODE

MPAA_RATING_DESC

MOVIE_TITLE

YEAR_PRODUCED

DATA_ACQUIRED

DATE_SOLD

MEDIA_FORMAT

RETAIL_PRICE

1 1 Drama Drama en,fr R under 17requiresaccompanyingparent oradultguardian

MysticRiver

2003 01/01/2005

DVD 19.96

2 1 ActAd Action andAdventure

en,fr,es

R under 17requiresaccompanyingparent or

adultguardian

TheLastSamurai

2003 10/01/2005

DVD 19.96

Fig. 1.6 Relaia Movie dup adugarea atributului Copy_Number

Pentru transformarea relaiilor ne-normalizate n prima form normal, trebuie mutateatributele multivaloare i grupurile repetitive n noi relaii.

Procedura de mutare a unui atribut multivaloare sau a unui grup repetitiv ntr-o nou relaieconst n urmtoarele etape:

1.Creai o nou relaie, cu un nume sugestiv. Deseori, este bine s includei numelerelaiei originale, parial sau n ntregime, n numele noii relaii.

2.Copiai identificatorul unic din prima relaie n noua relaie. Datele depind de acest

identificator n relaia original, aa c trebuie s depind de aceeai cheie i n noua relaie.Identificatorul copiat va deveni cheie extern n noua relaie.3.Mutai grupul repetitiv sau atributul multivaloare n noua relaie.4. Formai un identificator unic n noua relaie, adugnd atribute la identificatorul unic

copiat din relaia original. Ca ntotdeauna, asigurai-v ca identificatorul unic nou formatconine numai numrul minim de atribute necesar pentru a-1 face unic. Dac mutai un atributmultivaloare, care, n esen, este un grup repetitiv cu un singur atribut, este adugat atributulrespectiv pentru formarea identificatorului unic. Poate prea ciudat la prima vedere, daridentificatorul unic copiat din relaia original nu este doar o cheie extern, ci, de obicei, i o

parte a identificatorului unic (cheia primar) a noii relaii. Acest lucru este absolut normal. Deasemenea, este perfect acceptabil s avem o relaie n care toate atributele fac parte din

identificatorul unic (adic nu exist atribute care s nu fac parte din cheie).5. Opional, putei nlocui cheia primar cu un singur atribut surogat pentru cheie. Dac

facei acest lucru, trebuie s pstrai i atributele care compun cheia primar natural, format la


15/200

14

paii 2 i 4. Figura 1.7 prezint rezultatul aducerii relaiei din figura 1.6 la prima form normal.Movie

MOVIE_ID(pk)

COPY_NUMBER(pk)

MOVIE_GENRE_CODE

MOVIE_GENRE_DESC

MPAA_RATING_CODE

MPAA_RATING_DESC

MOVIE_TITLE

YEAR_PRODUCED

DATA_ACQUIRED

DATE_SOLD

MEDIA_FORMAT

RETAIL_PRICE

1 1 Drama Drama R under 17requiresaccompan

yingparent oradultguardian

MysticRiver

2003 01/01/2005

DVD 19.96


R under 17requiresaccompanyingparent oradultguardian

TheLastSamurai

2003 10/01/2005

DVD 19.96


R under 17requiresaccompanyingparent oradultguardian

TheLastSamurai

2003 10/01/2005

VHS 15.95

Movie_LanguageMOVIE_ID (fk) LANGUAGE_CODE1 en1 fr2 en2 fr2 es

Fig 1.7 Soluia primei forme normale

A doua form normal: eliminarea dependenelor parialenainte de a explora a doua form normal, trebuie s nelegem conceptul de dependen

funcional.Pentru aceast definiie, vom folosi dou atribute arbitrare, inteligent denumite A" i B".

Atributul B este dependent funcional de atributul A dac n nici un moment nu exist mai multde o valoare a atributului B asociat cu o valoare dat a atributului A.

n relaia Movie, putem s ne dm seama cu uurina c atributul Movie_Title estedependent funcional de atributul Movie_ID, deoarece, n orice moment, poate exista o singurvaloare Movie_Title pentru o valoare Movie_ID dat. Chiar faptul c valoarea Movie_IDdefinete n mod unic valoarea Movie_Title n relaie nseamn c Movie_Title este dependentfuncional de Movie ID.

Se spune c o relaie este n a doua form normala dac ndeplinete urmtoarele criterii:

Relaia este n prima form normal. Toate atributele non-cheie sunt dependente funcional de identificatorul unic(cheia primar), luat ca ntreg.

Aplicnd aceste criterii relaiei Movie din fig. 1.7, este clar c avem cteva probleme.Identificatorul unic este o combinaie a atributelor Movie_ID i Copy_Number. Totui, numaiatributele Date_Acquired, Date_Sold, Media_Format i Retail_Price depind de ntregulidentificator. i este logic s fie aa. Indiferent cte copii ale unui film avem n baza de date,toate au aceleai valori pentru gen, categorie MPAA, titlu i an de producie. Cum a aprutaceast problem? Ar trebui s fie clar c unele atribute descriu filmul n sine, n timp ce alteledescriu, copiile pe care le deine (sau le-a deinut) magazinul din filmul respectiv. n esen, amamestecat atribute care descriu n aceeai relaie dou lucruri (entiti) diferite (dei nrudite) din

lumea real. Nici nu e de mirare c am obinut un asemenea haos. A doua form normal ne vaajuta s rezolvm problemele.A doua form normal se aplic numai relaiilor care au identificatoare unice concatenate


16/200

15

(adic formate din atribute multiple). ntr-o relaie care are un singur atribut ca identificator unic,este imposibil ca un alt atribut s depind de o parte a identificatorului unic, deoarece acesta,fiind format dintr-un singur atribut, nu are pri componente. Ca urmare, orice relaie n primaform normal care are cheia primar format dintr-un singur atribut este automat n adoua form normal.

MovieMOVIE_ID(pk)

MOVIE_GENRE_CODE

MOVIE_GENRE_DESC

MPAA_RATING_CODE

MPAA_RATING_DESC

MOVIE_TITLE

YEAR_PRODUCED

1 Drama Drama R under 17 requiresaccompanying parent oradult guardian

MysticRiver

2003


R under 17 requiresaccompanying parent oradult guardian

The LastSamurai

2003

Movie_LanguageMOVIE_ID (fk) LANGUAGE_CODE1 en1 fr2 en

2 fr2 es

Movie_CopyMOVIE_ID(pk)

COPY_NUMBER(pk)

DATA_ACQUIRED DATE_SOLD MEDIA_FORMAT RETAIL_PRICE

1 1 01/01/2005 DVD 19.962 1 10/01/2005 DVD 19.962 2 10/01/2005 VHS 15.953 1 10/01/2005 30/01/2005 DVD 29.993 2 15/02/2005 DVD 29.99

Fig. 1.8 Soluia pentru a doua form normal

A treia form normal: eliminarea dependenelor tranzitive

Pentru a nelege a treia form normal, trebuie s nelegem mai nti conceptul dedependen tranzitiv.Despre un atribut care depinde de un atribut care nu este identificator unic (cheie primar)

a relaiei se spune c este dependent tranzitiv.Uitndu-ne la relaia Movie din figura 1.8, observm c atributul Genre_Description

depinde de atributul Genre_Code, iar MPAA_Rating_Description depinde deMPAA_Rating_Code. Pericolul pstrrii acestor descrieri n relaia Movie este faptul c, n final,cele dou atribute ajung s depind de nregistrarea unui film, ceea ce duce la toate cele treianomalii de date prezentate mai devreme n acest capitol.

Se spune c o relaie este n a treia form normal dac ndeplinete urmtoarele doucriterii:

Relaia este n a doua form normal. Nu exist dependene tranzitive (cu alte cuvinte, toate atributele non-cheie depindnumai de identificatorul unic).

Pentru a aduce la a treia form normal o relaie aflat n a doua form normal, mutmatributele dependente tranzitiv n relaii n care depind numai de cheia primar

Avem grij s lsm atributul de care depind acestea n relaia original, cu rolul de cheieextern. Va trebui apoi s reconstruim vizualizarea original printr-o uniune. Ca efect secundar,toate atributele uor de calculat sunt eliminate ca nclcri ale criteriilor celei de-a treia formenormale.

De exemplu, ntr-o baz de date pentru vnzri, Suma Total este obinut nmulindCantitatea Cumprat cu Preul Unitar; aa cum se observ cu uurin, Suma Total este

dependent de Cantitatea Cumprat i de Preul Unitar. Presupunnd c toate cele trei atributesunt dependente de identificatorul unic al relaiei care le conine, este uor de vzut c SumaTotal (rezultatul calculat) este, de fapt, dependent tranzitiv de celelalte dou atribute. Figura


17/200


18/200

17

Fig. 1.10 Diagrama ERD a magazinului de produse video

De exemplu, dac vrei s obinei media numerelor de pe o coloan, folosii funcia AVG.Nu este nevoie s numrai valorile din coloan i s mprii suma acestora la numrul obinut -procesorul limbajului SQL din DBMS se ocup de toate aceste lucruri n locul dumneavoastr.

Este important s nelegem c SQL nu este un limbaj procedural, ca C, Pascal, Basic,FORTRAN, COBOL sau Ada. Un limbajproceduralfolosete o serie de instruciuni executatesecvenial. De asemenea, limbajele procedurale includ instruciuni care pot modifica secvena deexecuie, prin ramificarea la alte poriuni ale procedurii sau prin parcurgerea ciclic a unui set deinstruciuni din procedur. Muli productori de sisteme RDBMS ofer extensii procedurale alelimbajului SQL de baz, cum ar fi Oracle PL/SQL {Procedural Language/SQL) sau Microsoft

Transact-SQL, dar reinei c acestea sunt extensii SQL care formeaz noi limbaje - codul SQLpe care-1 conin rmne neprocedural. De asemenea, SQL nu trebuie confundat cu limbajeleorientate spre obiecte, precum Java i C++.

Simplu spus, SQL este un limbaj pentru gestionarea i ntreinerea bazelor de daterelaionale, nu un limbaj potrivit pentru programarea general a aplicaiilor, cum ar fi sistemelede prelucrare a comenzilor sau a plilor.

SQL este deseori folosit n combinaie cu limbajele procedurale sau orientate spre obiectemenionate anterior pentru a manipula stocarea i extragerea datelor, folosind instruciuni dinlimbajul de programare cu destinaie general pentru alte sarcini de programare, precum

prezentarea datelor pe o pagin web sau furnizarea rspunsurilor la informaiile introduse deutilizatori de la tastatur sau mouse. Atunci cnd este necesar interacionarea cu baza de date,

instruciunile din limbajul procedural formeaz instruciunea SQL, o transmit ctre RDBMS nvederea prelucrrii, primesc rezultatele returnate de RDBMS i le prelucreaz ntr-un modcorespunztor.

MPAA_RATINGMPAA_RATING_CODE MPAA_RATING_DESCRIPIO

N

MOVIEMOVIE_ID MOVIE_GENRE_CODEMPAA_RATING_CODEMOVIE_TITLERETAIL_PRICE_DVDRETAIL_PRICE_VHSYEAR_PRODUCED

MOVIE_GENREMOVIE_GENRE_CODE MOVIE_GENRE_DESCRIPTION

MOVIE_LANGUAGEMOVIE_ID LANGUAGE_CODE

LANGUAGELANGUAGE_CODE LANGUAGE_NAME

MOVIE_COPYMOVIE_ID COPY_NUMBER DATE_ACQUIREDDATE_SOLDMEDIA_FORMAT

MOVIE_RENTALMOVIE_ID COPY_NUMBER TRANSACTION_ID DUE_DATERENTAL_FEELATE_OR_LOSS_FEERETURNED_DATE

CUSTOMER_TRANSACTIONTRANSACTION_ID CUSTOMER_ACCOUNT_IDEMPLOYEE_PERSON_ID TRANSACTION_DATE

SALES_TAX

CUSTOMER_ACCOUNTCUSTOMER_ACCOUNT_ID CUSTOMER_HOLD_INDDATE_ENROLLEDDATE_TERMINATED

CUSTOMER_DEPOSIT_AMOUNTCREDIT_CARD_ON_FILE_INDICCHILD_RENTAL_ALLOWED_INDIC

CUSTOMER_ACCOUNT_PERSONCUSTOMER_ACCOUNT_ID PERSON ID < k, fk1>

PERSONPERSON_ID PERSON_GIVEN_NAMEPERSON_MIDDLE_NAMEPERSON_FAMILY_NAMEPERSON_ADDRESS_1PERSON_ADDRESS_2PERSON_ADDRESS_CITYPERSON_ADDRESS_STATE_PROVPERSON_ADDRESS_POSTAL_CODEPERSON_ADDRESS_COUNTRYPERSON_PHONEBIRTH_DATEDEATH_DATE

EMPLOYEEPERSON_ID SUPERVISOR_PERSON_ID EMPLOYEE_TAX_IDEMPLOYEE_JOB_CATEGORYEMPLOYEE_HOURLY_RATEHIRE_DATETERMINATION_DATE


19/200

18

1.2.1. Conectarea la baza de date

Atunci cnd folosii limbajul SQL pe un calculator personal, cu o copie personal a unuisistem DBMS, precum Microsoft Access sau Oracle Personal Edition, toate componentele bazeide date ruleaz pe acelai sistem de calcul. Totui, acest aranjament nu este potrivit pentru bazele

de date care trebuie s fie folosite n comun de mai muli utilizatori.Ca urmare, sunt mult mai frecvent ntlnite situaiile n care baza de date este instalat ntr-o arhitectur client/server, ca n figura 2.1.

Fig. 2.1 Conexiunea clientului SQL cu baza de date

ntr-o arhitectur client/server: Sistemul RDBMS ruleaz pe un server, care este un sistem de calcul partajat.

Pentru scopurile acestei definiii un sistem mainframe poate fi considerat unserver de dimensiuni mari.

Fiierele care compun baza de date din punct de vedere fizic sunt stocate pe discuri conectatela serverul de baze de date.

Utilizatorii care au acces la baza de date folosesc staii de lucru, numite clieni. Clientul

trebuie s aib o conexiune de reea la baza de date, care poate fi o reea privat, instalatacas sau la birou, ori o reea publica, precum Internet. Componentele software furnizate de productorul DBMS ruleaz pe staiile de

lucru alte clienilor pentru a oferi utilizatorilor posibilitatea s introducinstruciuni SQL, s le transmit sistemului DBMS n vederea prelucrrii i svad rezultatele returnate de DBMS. n general, acest software se numete clientSQL.

De reinut c: nimic nu ne oprete s instalm clientul SQL pe acelai calculator cusistemul DBMS. De fapt, muli dezvoltatori care utilizeaz sisteme DBMS precum MySQL,Microsoft SQL Server i Oracle fac n mod obinuit acest lucru, deoarece este foarte convenabils aib ntregul mediu de dezvoltare pe un singur calculator, cum ar fi un laptop.

Totui, n momentul n care este necesar accesul partajat al mai multor utilizatori, este multmai convenabil i mai eficient s avei o singur copie a sistemului DBMS pe un server partajati s avei numai clientul SQL instalat pe staia de lucru a fiecrui client.

server de BD pe care ruleaz componente software ale DBMS

baza de date

conexiune de reea

staie de lucru client pe care ruleaz componentele software ale clientului SQL


20/200

19

n funcie de interfaa cu utilizatorul de pe staia de lucru client, clienii SQL suntclasificai n trei categorii: n linia de comand: o interfa n linia de comand sebazeaz exclusiv pe intrri i ieiri de

tip text, cu comenzile introduse de la tastatur i rspunsurile afiate ca mesaje de tip text.Principalul avantaj al interfeelor n linia de comand este c pot fi rulate pe aproape oricesistem de operare.

grafici: o interfa grafic cu utilizatorul (GUI-graphical user interface) ruleaz sub un tipoarecare de sistem bazat pe ferestre, cum ar fi X Window System, Mac OS sau MicrosoftWindows, i afieaz datele sau opiunile comenzilor folosind elemente grafice, precum

pictograme, butoane i casete de dialog. bazai pe web: o interfa bazat pe web ruleaz pe serverul de baze de date, folosind un

browser web de pe staia de lucru client pentru a interaciona cu utilizatorul bazei de date. Dinpunct de vedere tehnic, un client SQL bazat pe web nici nu este o aplicaie client, deoarece nuexist nici o component software specific productorului DBMS rulat pe staia de lucra aclientului. Totui, aproape ntotdeauna exist componente furnizate de productorul DBMScare sunt descrcate n fundal de browser-ul web pentru a asista n procesul de reprezentaregrafic a formularelor web folosite pentru introducerea instruciunilor SQL i afiarea

rezultatelor.

1.2.2. Convenii de sintax SQL

Aceast seciune prezint conveniile generale de sintax folosite pentru construireainstruciunilor SQL. Conveniile de sintax SQL sunt mai uor de neles folosind un exemplusimplu. Instruciunea de mai jos returneaz valorile Movie_ID i Movie_Title pentru toatefilmele din magazinul de produse video pentru care categoria MPAA este PG":

SELECT MOVIE_ID, MOVIE_TITLE FROM MOVIE WHERE MPAA_RATING_CODE = 'PG';

Conveniile de baz sunt urmtoarele: Fiecare instruciune ncepe cu o comand, de obicei sub forma unui singur cuvnt, care

aproape ntotdeauna este un verb (n limba englez) care descrie o aciune, n acest exemplu,instruciunea ncepe cu comanda SELECT.

Fiecare instruciune se termin cu un delimitator, care este, de obicei, un caracter punct ivirgul (;).

Instruciunile sunt construite ntr-o manier similar cu propoziiile din limba englez, cu unulsau mai multe spaii pentru separarea elementelor de limbaj. Un element de limbaj,asemntor cu un cuvnt dintr-o propoziie, poate fi un cuvnt cheie (SELECT, FROM,WHERE), numele unui obiect al bazei de date (MOVIE, MOVIE_ID, MOVIE_TITLE), un

operator (=) sau o constant ('PG') care apare ntr-o instruciune. Instruciunile sunt scrise ntr-o form liber, ceea ce nseamn c nu exist reguli stricte

privind poziia elementelor de limbaj pe o linie sau locul n care se poate face trecerea la olinie nou. Totui, n general nu este o idee bun s mprii un element de limbaj pe maimulte linii.

Instruciunile sunt organizate ntr-o serie de clauze i, de obicei, clauzele trebuie s apar ntr-o anumit ordine atunci cnd sunt folosite (multe clauze sunt opionale). n exemplul nostru,exist trei clauze, fiecare ncepnd cu un cuvnt cheie (SELECT, FROM, WHERE).

Elementele de limbaj SQL pot fi scrise cu litere mari, cu litere mici sau n combinaii. Aceastanu nseamn c datele nu pot conine litere mici, ci c numele obiectelor din baza de date(tabele, coloane etc.) i comenzile trebuie s fie scrise cu litere mari.

Virgulele sunt folosite pentru separarea articolelor dintr-o list. n exemplul nostru, numele adou coloane sunt specificate ntr-o list separat prin virgule (MOVIE_ID, MOVIE_TITLE).Spaiile care urmeaz dup virgule sunt opionale putei aduga orice numr de spaii, inclusiv


21/200

20

zero. irurile de caractere care apar n instruciunile SQL trebuie s fie ncadrate cu apostrofuri

(unele implementri SQL permit i folosirea ghilimelelor). Constantele numerice nu suntniciodat ncadrate cu apostrofuri. Dac n irul de caractere trebuie s apar un caracterapostrof sunt inserate dou apostrofuri unul lng cellalt. De exemplu, dac vrei s gsii n

baza de date un film numit Sophie's Choice, vei scrie clauza WHERE astfel;

o WHERE MOVIE_NAME = 'Sophie' 's Choice' Numele obiectelor bazei de date sunt formate folosind numai litere, cifre i liniue desubliniere. Caracterul underscore (liniua de subliniere) este folosit, de obicei, ca separatorntre cuvinte, pentru mbuntirea lizibilitii.

n fiecare implementare SQL este definit un set de cuvinte rezervatetcare sunt cuvinte cu osemnificaie specific pentru procesorul SQL al sistemului DBMS i, ca urmare, nu trebuiefolosite ntr-un alt context de exemplu ca nume pentru obiectele bazei de date.

Un comentariu pe o singur linie ncepe cu dou liniue de desprire (--), Cele dou liniue sepot afla la nceputul unei linii, ceea ce nseamn c ntreaga linie este considerat comentariu,sau oriunde n cadrul liniei, caz n care restul liniei, pn la sfrit, este considerat comentariu.De exemplu:

--Acesta este un comentariu pe o singur linie n SQL. Un comentariu pe mai multe linii ncepe cu combinaia dintre o diagonal la

dreapta (slash) i un asterisc (/*) i continu pn la ntlnirea combinaiei inverse(*/). Un exemplu de comentariu pe mai multe linii:

/* Acesta este un comentariu pe mai multe linii.Continu pn la ntlnirea combinaiei de caractere care marcheaz sfritul

comentariului. */Instruciunile SQL sunt mprite n categorii, dup funciile pe care le ndeplinesc.

Categoriile de instruciuni, descrise n seciunile urmtoare, sunt: Limbajul de definire a datelor (DDL - Data Definition Language)

Limbajul de interogare a datelor (DQL - Data Query Language) Limbajul de manipulare a datelor (DML - Data Manipulation Language) Limbajul pentru controlul datelor (DCL - Data Control Language) Comenzile pentru controlul tranzaciilor (Transaction Control Commands)

Limbajul de definire a datelor (DDL): include instruciuni SQL care permit utilizatoruluibazei de date s creeze i s modifice structura obiectelor bazei de date, cum ar fi tabele,vizualizri i indexuri. Instruciunile SQL care folosesc comenzile CREATE, ALTER i DROPsunt considerate parte a DDL.

Este important s nelegei c instruciunile DDL afecteaz containerele care stocheazdatele n baza de dale, nu datele propriu-zise. Ca urmare, exist instruciuni DDL pentru crearea,tergerea i modificarea tabelelor, dar nici una dintre aceste instruciuni nu ofer posibilitatea de

a crea sau modifica rnduri de date din tabelele respective.Limbajul de interogare a datelor (DQL): include instruciuni SQL care permit obinereadatelor din baza de date. Dei reprezint o parte foarte important a limbajului SQL, DQL esteformat din instruciuni care folosesc o singur comand: SELECT.

Limbajul de manipulare a datelor (DML): include instruciuni SQL care permitutilizatorului bazei de date s adauge date n baza de date (sub forma rndurilor din tabele), stearg date i s modifice datele existente n baza de date. Instruciunile SQL care folosesccomenzile INSERT, UPDATE i DELETE sunt considerate parte a DML.

Limbajul pentru controlul datelor (DCL): include instruciuni SQL care permitadministratorilor s controleze accesul la datele din baza de date i folosirea diferitelor privilegiiale sistemului DBMS, cum ar fi privilegiul de oprire i pornire a bazei de date. Instruciunile

SQL care folosesc comenzile GRANT i REVOKE sunt considerate parte a DCL.Comenzile pentru controlul tranzaciilor: o tranzacie n baza de date este un set de

comenzi pe care utilizatorul bazei de date vrea s le trateze ca pe o unitate funcional de tip


22/200

21

totul sau nimic, nelegnd prin aceasta c ntreaga tranzacie trebuie s reueasc sau seueze. Comenzile pentru controlul tranzaciilor (Transaction Control Commands) nu respect cuexactitate sintaxa instruciunilor SQL, dar afecteaz puternic comportamentul instruciunilorSQL incluse n tranzacii.

1.3. DEFINIREA I INTEROGAREA DATELOR FOLOSIND LIMBAJUL SQL

1.3.1. Instruciuni DDL (Data Definition Language)

Instruciunile DDL (Data Definition Language) definesc obiectele bazei de date, dar nuinsereaz i nu actualizeaz date n obiectele respective (aceast funcie fiind ndeplinit deinstruciunile DML).

n SQL, exist trei comenzi de baz pentru instruciunile DDL: CREATE - Creeaz n baza de date un nou obiect, de tipul specificat n instruciune.

Deoarece sintaxa este diferit, vom prezenta separat instruciunile CREATE DATABASE,CREATE TABLE, CREATE INDEX i CREATE VIEW.

ALTER - Modific definiia unui obiect existent n baza de date, de tipul specificat ninstruciune.

DROP - terge (distruge) un obiect existent n baza de date, de tipul specificat ninstruciune.

Instruciunea CREATE DATABASESintaxa general pentru instruciunea CREATE DATABASE esteCREATE DATABASE nume_baza_de_date [opiuni specifice productorului]Instruciunea CREATE TABLECREATE TABLE este una din instruciunile fundamentale din SQL. Modelul relaional

cere ca toate datele stocate s fie ancorate ntr-un tabel, aa c posibilitatea de a stoca orice ntr-obaz de date ncepe ntotdeauna cu crearea unui tabel. Sintaxa de baz pentru instruciuneaCREATE TABLE este

CREATE TABLE nume tabel( [, ...])[, ... ] ;Fiecare instruciune include numele tabelului i o list cu una sau mai multe definiii de

coloane, separate prin virgule i ncadrate ntre paranteze. Numele tabelului trebuie s fie unic nbaza de. Fiecare tabel trebuie s aib cel puin o coloan.

Definirea coloanelor n SQL DDLSintaxa de baz folosit pentru definirea coloanelor unui tabel este: :numecoloan tipdedate [DEFAULT expresie] [ NULL | NOT NULL]

[]Restriciile coloanelorRestriciile unei coloane limiteaz (constrng) ntr-un mod oarecare valorile ce pot fi

stocate ntr-o coloan a unui tabel.Din punct de vedere tehnic, clauzele DEFAULT i NULL sau NOTNULL sunt forme

speciale de restricii, dar acestea nu sunt implementate ntotdeauna n acelai mod n toatesistemele DBMS. Restricia unei coloane se poate referi la o singur coloan, dar exist omodalitate simpl de ocolire, deoarece orice restricie de coloan poate fi rescris ca restricie detabel. Restriciile coloanelor pot avea oricare dintre urmtoarele forme:

Clauza DEFAULTO expresie care este aplicat coloanei atunci cnd n tabel este inserat un nou rnd, care nu

conine o valoare explicit pentru coloana respectiv. Expresia poate fi orice expresie valid carepoate fi interpretat de SQL, cum ar fi o constant, o funcie SQL sau o alt sintax care, n urmaevalurii de ctre motorul SQL din DBMS, produce o valoare corespunztoare pentru coloana


23/200

22

respectiv.Ca exemplu, observai clauza DEFAULT N pentru coloana

CUSTOMER_HOLD_INDIC din tabelul CUSTOMER_ACCOUNT. Prin specificarea acesteivalori prestabilite v asigurai c orice cont de client nou creat va primi ntotdeauna valoarea N'(contul nu este blocat) dac instruciunea care insereaz noul rnd nu furnizeaz o valoare pentruaceast coloan sau folosete cuvntul cheie DEFAULT pentru valoarea coloanei. O alt

utilizare obinuit a clauzei DEFAULT este inserarea unor date, cum ar fi stocarea datei curentepentru efectuarea unei tranzacii, la inserarea noilor rnduri n baza de date. Iat sintaxa SQL iun exemplu de coloan cu o clauz DEFAULT:

[DEFAULT expresie]Exemplu:CUSTOMER_HOLD_INDIC CHAR(l) DEFAULT 'N' NOT NULLRestricia NULL | NOT NULLSpecificarea cuvntului cheie NULL permite stocarea valorilor nule ntr-o

coloan, n timp ce NOT NULL nu permite stocarea valorilor nule n coloanarespectiv. Iat sintaxa SQL i cteva exemple:

NULL | NOT NULL

Exemple:DATE_ENROLLED DATE NOT NULLDATE_TERMINATED DATE NULLRestricia CHECKO restricie de verificare (check) poate fi folosit pentru impunerea unei reguli care poate fi

aplicat unei singure coloane a unui tabel. Condiia inclus n restricie trebuie s fie ndeplinitori de cte ori datele din coloana respectiv a tabelului sunt modificate - n caz contrar, sistemulDBMS va respinge modificarea i va afia un mesaj de eroare. Condiia din restricia CHECK aunei coloane nu poate referi nici o alt coloan a tabelului.

Iat sintaxa restriciei CHECK i un exemplu:[CONSTRAINT nume_restrictie] CHECK (conditie)

Exemplu:CREDIT_CARD_ON_FILE_INDIC CHAR(l) NOT NULLCHECK (CREDIT_CARD_ON_FILE_INDIC IN 'Y', 'N')Restricia UNIQUEO restricie UNIQUE impus asupra unei coloane garanteaz unicitatea valorilor din

coloana respectiv a tabelului, de obicei cu ajutorul unui index creat automat de DBMS.Iat sintaxa restriciei de unicitate i un exemplu de utilizare:[CONSTRAINT nume_restricie] UNIQUE

Exemplu:CUSTOMER_ACCOUNT_ID INTEGER NOT NULL UNIQUE

Restricia PRIMARY KEYO restricie de cheie primar (PRIMARY KEY) impus asupra unei coloane declar

coloana respectiv ca fiind cheia primar a tabelului, ceea ce nseamn c n coloana respectivnu pot exista valori nule, iar valorile trebuie s fie unice n cadrul tabelului. Ca i n cazulrestriciilor de unicitate, majoritatea sistemelor DBMS impun restricia de cheie primar cuajutorul unui index creat automat.

Iat sintaxa restriciei de cheie primar i un exemplu de utilizare:[CONSTRAINT nume_restricie] PRIMARY KEY

Exemplu:CUSTOMER_ACCOUNT_ID INTEGER NOT NULL PRIMARY KEY

Restricia referenial (FOREIGN KEY)O restricie referenial impus asupra unei coloane (numit uneori i restricie de cheie


24/200

23

extern) definete relaia dintre o cheie extern i o cheie primar, astfel nct sistemul DBMS spoat garanta c valoarea, dac nu este nul, refer ntotdeauna valoarea unei chei primareexistente. Iat sintaxa restriciei refereniale:

[CONSTRAINT nume_restricie]REFERENCES nume_ tabel(nume_coloan)[ON DELETE CASCADE | ON DELETE SET NULL]

Exemplu:MPAA_RATING_CODE CHAR(5) NOT NULLREFERENCES MPAA_RATING (MPAA_RATING_CODE)Clauza opional ON DELETE spune sistemului DBMS ce s fac atunci cnd este ters

rndul referit din tabelul printe (rndul care conine cheia primar corespondent), cu opiuneade a terge toate rndurile care conin cheia extern (CASCADE) sau de a insera valori nule

pentru toate cheile externe (SET NULL). Reinei c majoritatea sistemelor DBMS, dar nu toate,accept clauza ON DELETE.

Restriciile tabelelorRestricia unei coloane poate fi rescris i ca restricie a ntregului tabel, astfel nct clauza

care definete restricia s apar n instruciunea CREATE TABLE dup definiiile tuturorcoloanelor, nu dup definiia unei coloane. Principalul avantaj al restriciilor la nivelul tabeluluieste c pot referi mai multe coloane. Semnificaia fiecrei restricii a fost deja discutat (nseciunea despre restriciile coloanelor) aa c aici vom prezenta numai sintaxa general i ctevaexemple.

Toate exemplele folosesc tabelul CUSTOMER_ACCOUNT, dar unele au fost modificate,astfel nct s ilustreze ideile principale prezentate.

Restricia CHECK[CONSTRAINT nume_restricie] CHECK (condiie)

Exemplu:CONSTRAINT CK_CUSTOMER_DEPOSIT_AMOUNTCHECK (CUSTOMER_DEPOSIT_AMOUNT >= 0 OR

CUSTOMER_DEPOSIT_AMOUNTIS NULL)Restricia din exemplul de mai sus mpiedic stocarea unei valori negative n coloana

CUSTOMER_DEPOSIT_AMOUNT. Observai operatorul SAU, folosit pentru a permitestocarea valorilor nule n coloan. Dac nu ar fi fost inclus aceast condiie, coloana nu ar fiacceptat valori nule, deoarece o valoare nul nu este mai mare sau egal cu zero.

Restricia UNIQUE[CONSTRAINT nume_restricie] UNIQUE(nume_coloana[, nume coloana ...,])

Exemplu:

CONSTRAINT UK_CUST_ACCT_DATE_ENROLLEDUNIQUE (CUSTOMER_ACCOUNT_ID, DATE_ENROLLED)Conform acestei restricii, combinaia de coloane CUSTOMER_ACCOUNT_ID i

DATE_ENROLLED trebuie s fie unic n rndurile din tabelul CUSTOMER_ACCOUNT.n acest exemplu, coloana CUSTOMER_ACCOUNT_ID este oricum unic, aa c

impunerea noii restricii nu prea are sens, dar am inclus-o aici pentru a ilustra folosirea uneirestricii de unicitate bazate pe mai multe coloane.

Restricia PRIMARY KEY[CONSTRAINT nume_restricie] PRIMARY KEY(nume_coloana[,nume coloana..,])Exemplu:CONSTRAINT PK_CUSTOMER_ACCOUNT

PRIMARY KEY (CUSTOMER_ACCOUNT_ID)Restricia de mai sus este chiar definiia cheii primare din tabelulCUSTOMER_ACCOUNT folosit ca exemplu n aceast seciune, dar n acest caz am denumit


25/200

24

explicit restricia.Restricia referenial (FOREIGN KEY)[CONSTRAINT nume_restricie]FOREIGN KEY (nume coloan [, nume_coloan.., ]) REFERENCES

nume_tabel(nume_coloan [ , nume_coloan... ]) [ON DELETE CASCADE | ON DELETESET NULL)

Observai c, spre deosebire de forma pentru coloane a restriciei refereniale, aceasta poatereferi coloane multiple. Aa cum a fost proiectat, tabelul CUSTOMER_ACCOUNT nu arecoloane chei externe, dar s ne gndim la un alt model.

Unii proiectani de baze de date nu sunt de acord cu folosirea restriciilor CHECK pentru acontrola valorile din coloane, deoarece adugarea sau eliminarea valorilor implic modificarea

proiectului bazei de date. S presupunem, de exemplu, c la o mbuntire ulterioar a bazei dedate pentru magazinul de produse video trebuie s permitem stocarea unei noi valori, 'E' (de laexceptat"), n coloana CREDIT_CARD_ON FILE INDIC. Putei modifica restricia CHECK

pentru a permite stocarea noii valori n tabel, dar dac ai fi pus toate valorile i descrierile ntr-un tabel separat (deseori numit tabel de coduri", referin" sau de cutare"), ar fi fost suficients adugai noul cod n tabelul respectiv, fr nici o modificare asupra proiectului bazei de date.

Tocmai pentru obinerea acestei flexibiliti, baza de date a magazinului de produse videoconine tabele pentru informaii precum MPAA_RATING_CODE - dac asociaia MPAA ischimb sistemul de clasificare, este suficient s modificai datele din tabelul de coduri. Deasemenea, tabelele de coduri sunt o surs elegant pentru popularea cu valori a listelor derulantedin componente de aplicaie, precum formularele din paginile web.

Presupunnd c a fost creat un tabel numit CARD ON_FILE_TYPE, cu o cheie primarnumit CARD_ON_FILE_CODE, iat cum arat restricia referenial care definete coloanaCREDIT_CARD_ON_FILE_INDIC ca fiind cheie extern:CONSTRAINT FK_CARD_ON_FILE_INDIC FOREIGN KEY(CREDIT_CARD_ON_FILE_INDIC) REFERENCES CARD_ON_FILE_TYPE(CARD_ON_FILE_CODE)

Aa cum putei vedea, nu ntotdeauna exist un singur mod corect" de proiectare a uneibaze de date, ci mai multe soluii din care putei alege. Altfel spus, proiectarea bazelor de date nueste o tiin exact. n general, este recomandabil s dai cheii externe acelai nume ca i cheii

primare, dar aa cum putei vedea din acest exemplu, SQL v permite s folosii un alt nume,dac aa vrei sau aa trebuie.

InstruciuneaCREATE INDEXCREATE [UNIOUE] INDEX nume_index ON nume tabel (nume coloan [,nume

coloan [ASC | DESC]...]); Cuvntul cheie opional UNIQUE definete indexul ca unic, nsemnnd c nu pot exista dou

rnduri din tabel cu exact aceeai combinaie de valori n coloanele specificate.

Cuvntul cheie opional ASC creeaz indexul n ordine cresctoare, n timp ce DESC creeazindexul n ordine descresctoare. Dac nu este specificat nici una dintre cele dou opiuni,ordinea prestabilit este cresctoare.

Un index trebuie s aib cel puin o coloan, dar, practic, nu exist o limit superioar anumrului de coloane.

Indexurile sunt instrumente puternice, deoarece permit sistemului DBMS s gseascdatele mult mai repede, aa cum indexul unei cri v permite s gsii rapid ceea ce vintereseaz. Mai mult, indexurile pe coloanele cheilor externe cresc mult performanele la unireatabelelor. Totui, indexurile ocup spaiu de stocare i trebuie s fie ntreinute de fiecare datcnd se modific o valoare de pe o coloan referit de un index, trebuie s fie modificat iindexul corespunztor. Sistemul DBMS ntreine automat indexul, dar activitatea de ntreinere

consum din resursele calculatorului.Instruciunea CREATE VIEWVizualizrile ofer mari avantaje utilizatorilor unei baze de date, deoarece permit ajustarea


26/200

25

datelor afiate n funcie de cerinele individuale i mascheaz operaiile complexe. Atunci cndsunt create corect, vizualizrile implic suprasarcini minime i nu stocheaz date.

n esen, o vizualizare este o interogare SQL stocat, care poate fi referit de instruciunileSQL DML i DQL ca i cum ar fi un tabel real. Unii consider c vizualizrile sunt tabelevirtuale, deoarece se comport la fel ca tabelele (cu unele restricii), dar nu exist ca tabelefizice.

Sintaxa general a instruciunii CREATE VIEW este:CREATE [OR REPLACE] VIEW nume_vizualizare AS interogare_sql Cuvntul cheie opional OR REPLACE elimin necesitatea de a terge o

vizualizare existent nainte de a o crea din nou. Dac specificai parametrul opional ORREPLACE i vizualizarea exist deja, este nlocuit, iar dac nu exist, noua vizualizare esteadugat n baza de date.

Numele vizualizrii trebuie s respecte aceleai reguli de denumire ca i tabelelei alte obiecte ale bazei de date. n interogrile SQL sunt specificate numele obiectelor dincare sunt selectate datele, dar nu i tipul acestor obiecte. Ca urmare, numele vizualizrilortrebuie s fie unice pentru toate tabelele i vizualizrile din baza de date. Cu alte cuvinte,numele vizualizrilor i numele tabelelor trebuie s provin din acelai spaiu de nume,

adic acelai domeniu de nume. Interogarea SQL inclus n definiia vizualizrii poate fi orice instruciunea SQL

SELECT valid. Vom nva despre aceast instruciune SQL esenial ncapitolul 4. Crearea vizualizrilor urmeaz o cale natural de evoluie - lucrai cuinterogarea SQL, facei modificrile necesare i rulai din nou interogarea pncnd obinei rezultatele dorite. Apoi adugai instruciunea CREATE VIEW nfaa interogrii cu care ai lucrat i rulai instruciunea pentru a stoca permanentinterogarea n baza de date, ca vizualizare. Aceasta este o modalitate foarte

productiv (i plcut) de a lucra cu bazele de date.Instruciunea ALTER TABLEDup ce creai un tabel, aproape orice ai specificat n instruciunea CREATE TABLE

poate fi modificat folosind instruciunea ALTER TABLE.Utilizarea instruciunii ALTER TABLE este un alt domeniu n care au un rol important

stilul i preferinele personale. Muli administratori de baze de date prefer s foloseascinstruciuni CREATE TABLE ct mai simple, evitnd s defineasc restricii n instruciunileCREATE TABLE. Acetia adaug dup instruciunea CREATE TABLE instruciuni ALTERTABLE prin care specific toate restriciile necesare (cheie primar, cheie extern, unicitate,verificare i aa mai departe). Dezavantajul acestei metode este acela c necesita scrierea uneicantiti mai mari de cod. Pe de alt parte, instruciunea CREATE TABLE este mult mai uor deneles fr restricii, iar scrierea separat a restriciilor simplific refolosirea instruciunilor, daceste nevoie s eliminai i apoi s creai din nou restriciile.

*Adugarea unei coloane la un tabel. Definirea coloanei se face cu aceeai sintax ca in cazul instruciunii CREATE TABLE.ALTER TABLE nume tabelADD ( [,]);

Exemplu:ALTER TABLE CUSTOMER ACCOUNT ADD (CUSTOMER_HOLD_DATE DATE

NULL,HOLD_PLACED_BY VARCHAR(50));*Modificarea definiiei unei coloane.ALTER TABLE nume_tabel MODIFY | CHANGE [COLUMN] ( [,]);

Exemplu:

ALTER TABLE CUSTOMER_ACCOUNT MODIFY(CUSTOMER_DEPOSIT_AMOUNT NUMERIC(7,2) DEFAULT 0 NOT NULL);

* Adugarea unei restricii. Definiia restriciei este identic cu definiia unei restricii


27/200

26

care ar putea aprea ntr-o instruciune CREATE TABLE.ALTER TABLE nume tabel ADD CONSTRAINT ;

Exemplu:ALTER TABLE CUSTOMER_ACCOUNT ADD CONSTRAINT CK_CUSTOMERDEPOSIT_AMOUNT CHECK (CUSTOMER_DEPOSIT_AMOUNT >= 0 ORCUSTOMER DEPOSIT AMOUNT IS NULL);

* tergerea cheii primare a unui tabel. Dac cheia primar este referit de restriciirefereniale, trebuie mai nti terse restriciile respective.ALTER TABLE nume tabelDROP PRIMARY KEY;* Redenumirea unei coloane.ALTER TABLE nume_tabel RENAME nume_vechi_coloan TO nume_nou_coloan;n MySQL este implementat varianta:ALTER TABLE nume_tabel

CHANGE [COLUMN] nume_col_vechi nume_col_nouacolumn_definition[FIRST|AFTERcol_name]

Instruciunea DROPInstruciunea DROP este cea mai simpl dintre instruciunile DDL. Sintaxa de baz este:

DROP nume_obiect[] Tipul de obiect specific tipul obiectului care urmeaz s fie ters, cum ar fi INDEX, TABLE

sau VIEW. Opiunile de tergere sunt specifice fiecrui DBMS. n general, dac un tabel este referit de o

restricie referenial, sistemul DBMS nu v va permite s tergei tabelulIat cteva exemple:DROP TABLE CUSTOMER_ACCOUNT;DROP TABLE CUSTOMER ACCOUNT CASCADE CONSTRAINTS; (Oracle)DROP TABLE CUSTOMER_ACCOUNT CASCADE; (MySQL / PostgreSQL)DROP INDEX IX MOVIE_TITLE ON MOVIE;

1.3.2. Instruciuni DQL (Data Query Language)

Limbajul SQL de interogare a datelor (DQL - Data Query Language) include o singurcomand, dar una foarte important: SELECT. Comanda SELECT este folosit pentru a obinedate din baza de date (fr s le modifice), astfel nct acestea s poate fi prelucrate de o aplicaiesau afiate pentru un utilizator.

Rezultatul unei instruciuni SELECT, numit set de rezultate, este returnat ntotdeauna subforma unui tabel (adic rnduri i coloane). Nu uitai c SQL este un limbaj neprocedural, aa cspecificai rezultatele pe care vrei s le obinei (adic modul n care vrei s fie returnat setul de

rezultate), nui modul n care vor fi obinute acestea.Instruciunea SELECT de bazForma elementar a instruciunii SELECT conine dou clauze:

SELECT [DISTINCT] - Specific lista de coloane care urmeaz s fiereturnate n setul de rezultate, separate prin virgule. Putei folosi simbolul asterisc(*) n locul listei de coloane pentru a selecta toate coloanele dintr-un tabel saudintr-o vizualizare. Cuvntul cheie DISTINCT poate fi adugat dup cuvntul cheie SELECT

pentru a elimina rndurile duplicate din rezultatele interogrii. FROM - Specific lista tabelelor sau vizualizrilor din care urmeaz s fie

selectate datele. n locul numelor reale ale tabelelor sau vizualizrilor putei folosisinonime, adic pseudonime pentru tabele sau vizualizri definite n baza de date.

Exemplul urmtor selecteaz coloanele MOVIE_GENRE_CODE,MPAA_RATlNG_CODE i MOVIE_TITLE din tabelul MOVIE.SELECT MOVIE_GENRE_CODE, MPAA_RATING_CODE, MOVIE_TITLE FROM


28/200

27

MOVIE;Pseudonime pentru numele coloanelorSe observ din interogarea anterioar c numele coloanelor din tabel apar automat ca titluri

ale coloanelor din setul de rezultate. Totui, nu este obligatoriu s se ntmple aa, deoareceinstruciunea SQL v pune la dispoziie o modalitate simpl de a specifica pseudonime pentrucoloane. Pseudonimele (aliases) specificate devin numele coloanelor din setul de rezultate.

Atenie la un aspect - pseudonimele nu exist dect dup rularea instruciunii SQL, aa c nu potfi folosite n alte pri ale instruciunii SQL. Pseudonimul unei coloane este specificat prinplasarea cuvntului cheie AS" dup numele coloanei n lista SELECT (cu cel puin un spaiunainte si dup), urmat de numele pe care vrei s-l atribuii coloanei n setul de rezultate. Iatcum arat instruciunea SQL rulat mai devreme, dar cu coloana MOVIE_GENRE_CODEredenumit GENRE i coloana MPAA_RATING_CODE redenumit RATING.

SELECT MOVIE_GENRE_CODE AS GENRE,MPAA_RATING_CODE AS RATING, MOVIE_TITLE FROM MOVIE;Sortarea rezultatelorRezultatele interogrilor sunt deseori mult mai utile dac specificai pentru rndurile

returnate o ordine care s aib o semnificaie pentru persoana sau aplicaia care folosete

informaiile. Nu exist nici o garanie n privina ordinii n care sunt returnate rndurile din setulde rezultate dect dac ordinea dorit este specificat n interogare.

n SQL, acest lucru este fcut prin adugarea n instruciunea SELECT a clauzei ORDERBY, cu o list de una sau mai multe coloane care vor fi folosite pentru sortarea rndurilor nordine ascendent sau descendent, n conformitate cu valorile datelor din coloane.

n cazul instruciunii SELECT folosite mai devreme, s presupunem c ar fi utilordonarea ascendent a rndurilor dup coloanele MPAA_Rating i Movie_Genre_Code. Din

perspectiva uman, cel mai bine este s plasai aceste coloane pe primele poziii n rezultateleinterogrii i s le specificai n aceeai ordinea n lista ORDER BY (cel puin n limbile citite dela stnga la dreapta). Astfel, ordonarea rndurilor este evident pentru cel care citete rezultatele.Mai jos este prezentat instruciunea SELECT modificat.

SELECT MPAA_RATING_CODE AS RATING, MOVIE_GENRE_CODE AS GENRE,MOVIE_TITLE FROM MOVIE ORDER BY MPAA_RATING_CODE,MOVIE_GENRE_CODE;

Utilizarea clauzei WHERE pentru filtrarea rezultatelorSQL folosete clauza "WHERE pentru a filtra rndurile ce urmeaz s fie afiate. Aa cum

ai vzut deja, o interogare fr o clauz WHERE returneaz un set de rezultate care coninetoate rndurile din tabelele sau vizualizrile referite n clauza FROM. Dac este inclus o clauzWHERE, sunt folosite regulile algebrei booleene, numite astfel dup numele logicianului GeorgeBoole, evalund clauza WHERE pentru fiecare rnd de date. n rezultatele interogrii sunt afiatenumai rndurile pentru care clauza WHERE este evaluat la valoarea logic adevrat".

Operatori de comparareOperatorii de comparare sunt folosii n clauza WHERE pentru compararea a dou valori,avnd ca rezultat o valoare logic de adevrat" sau fals". Cele dou valori comparate pot ficonstante furnizate n clauza WHERE, valori ale unor coloane din baza de date sau combinaiiale celor dou. Operatorii de comparare care pot fi folosii n clauza WHERE sunt prezentai ntabelul urmtor:

Operator Descriere

= Egal cu< Mai mic dect Mai mare dect

>= Mai mare sau egal cu!= Diferit de Diferit de (standard ANSI)

Exemple:


29/200

28

Afiai toate filmele pentru care MPAA_Rating are valoarea PG-13SELECT MPAA_RATING_CODE AS RATING, MOVIE_TITLEFROM MOVIE WHERE MPAA_RATING_CODE = 'PG-13'ORDER BY MOVIE_TITLE;

Afiai toate filmele cu preul de vnzare cu amnuntul pentru formatul DVD (DVD RetailPrice) mai mic de 19.99, n ordinea descresctoare a preurilor.

SELECT RETAIL_PRICE_DVD, MOVIE_TITLEFROM MOVIE WHERE RETAIL_PRICE_DVD < 19.99ORDER BY RETAIL_PRICE_DVD DESC;

Operatori conjunctiviUneori sunt necesare condiii multiple pentru a ngusta setul de rezultate al unei interogri.

Atunci cnd sunt folosite mai multe condiii, ele trebuie s fie combinate din punct de vederelogic n clauza WHERE, iar aceasta este sarcina operatorilor conjunctivi. Aceti operatori sunt: AND (I) Clauza WHERE este evaluat ca adevrat" dac toate condiiile conectate cu

operatorul AND sunt adevrate. OR (SAU) Clauza WHERE este evaluat ca adevrat" dac oricare din condiiile

conectate cu operatorul OR este adevrat.Lucrurile devin complicate dac operatorii AND i OR sunt combinai n aceeai clauz

WHERE. Operatorul AND are prioritate mai mare i, ca urmare, este evaluat nainteaoperatorilor OR. Condiiile din interiorul parantezelor sunt evaluate ntotdeauna primele.

Iat un exemplu de folosire a operatorilor conjunctivi; Afiai toate filmele pentru care categoria MPAA este PG-13 i preul de vnzare cu

amnuntul pentru formatul DVD este 19.99 sau mai mic, n ordinea cresctoare a preurilor.SELECT MPAA_RATING_CODE AS RATING, RETAIL_PRICE_DVD AS PRICE,MOVIE_TITLE FROM MOVIE WHERE MPAA_RATING_CODE = 'PG-13'

AND RETAIL_PRICE_DVD


30/200

29

Exemplu: Afiai toate filmele cu preul de vnzare cu amnuntul pentru formatul DVD (coloana

RETAIL_PRICE_DVD) ntre 14.99 i 19.99, ordonate cresctor duppre. Observai c n setul de rezultate sunt incluse si filmele pentru care preuleste exact 14.99 sau 19.99.SELECT MOVIE_TITLE, RETAIL_PRICE_DVD

FROM MOVIE WHERE RETAIL_PRICE_DVD BETWEEN 14.99 AND 19.99ORDER BY RETAIL PRICE DVD;LIKEOperatorul LIKE este folosit pentru a compara o valoare de tip caracter cu un tipar,

returnnd valoarea logic adevrat" dac valoarea de tip caracter se ncadreaz n tipar i fals"n caz contrar. Pentru definirea tiparului pot fi folosite dou caractere de nloc

manual licenta - calculatoate si tehnologia informatiei 2012

Documents