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
1

CUPRINS

CAP.1. BAZE DE DATE 3
1.1. CONCEPTE ALE BAZELOR DE DATE RELAIONALE 3
1.1.1. Definiii. 3
1.1.2. Componente ale bazelor de date relaionale 3
1.1.3. Niveluri de abstractizare a datelor 7
1.1.4. Proiectarea bazelor de date relaionale. Etape.Normalizarea bazelor de date 8
1.2. CONCEPTE SQL 16
1.2.1. Conectarea la baza de date 18
1.2.2. Convenii de sintax SQL 19
1.3. DEFINIREA I INTEROGAREA DATELOR FOLOSIND LIMBAJUL SQL 21
1.3.1. Instruciuni DDL (Data Definition Language) 21
1.3.2. Instruciuni DQL (Data Query Language 26
1.3.3. Interogri din tabele multiple 33
1.3.4. Funcii SQL avansate 37
1.3.5. Folosirea avantajelor oferite de vizualizri 39
1.4. ACTUALIZAREA DATELOR FOLOSIND LIMBAJUL SQL 39

CAP.2. PROGRAMARE ORIENTAT OBIECT I STRUCTURI DE DATE 43
2.1. CARACTERISTICI GENERALE ALE PROGRAMRII ORIENTATE OBIECT 43
2.1.1. Principiile ce stau la baza programrii orientate obiect 43
2.1.2. Avantajele programrii orientate obiect 45
2.1.3. Caracteristici generale ale claselor n Visual C++ 47
2.2. UTILIZAREA BAZELOR DE DATE, PROGRAMAREA OLE I COM 58
2.2.1. Utilizarea bazelor de date 58
2.2.2. Noiuni de programare OLE i COM 59
2.3. TIPURI SI STRUCTURI DE DATE. TIPURI DE DATE ABSTRACTE 62
2.4. LISTE, STIVE, COZI 69
2.5. ARBORI. REPREZENTARE, PARCURGERE 73

CAP.3. SISTEME DE OPERARE 78
3.1. NOIUNI INTRODUCTIVE PRIVIND SISTEMELE DE OPERARE 78
3.1.1. Definiie i rol 78
3.1.2. Funcii 78
3.1.3. Componentele sistemelor de operare 79
3.1.4. Moduri de operare 81
3.1.5. ntreruperi 82
3.2. PROCESE CONCURENTE 84
3.2.1. Noiunea de proces 84
3.2.2 Strile unui proces 85
3.2.3. Planificarea unitii centrale 86
3.3. GESTIUNEA MEMORIEI 93
3.3.1 Gestiunea n cazul multiprogramrii 93
3.3.2. Strategii de administrare a spaiului din memoria intern 97
3.3.3. Mecanismul de swapping 99
3.4. SISTEMUL DE OPERARE UNIX 100
3.4.1. Elemente introductive privind sistemul de operare UNIX 100
3.4.2. Gestiunea utilizatorilor i grupurilor 103
3.4.3. Permisiunile de acces asupra fiierelor i directoarelor 107
3.4.4. Sistemul de fiiere al UNIX 112
2

CAP.4. PROIECTAREA SISTEMELOR INFORMATICE 117
4.1. SISTEME INFORMATICE 117
4.2. METODOLOGII DE REALIZARE A SISTEMELOR INFORMATICE 119
4.2.1. Etapele de realizare a sistemelor informatice 119
4.2.2. Ordinea executrii etapelor 120
4.2.3. Metode i tehnici de realizare a sistemelor informatice 122
4.3. ANALIZA SISTEMULUI INFORMAIONAL EXISTENT 124
4.3.1. Conceptul de analiz a sistemelor informaionale 124
4.3.2. Obiectivele i fazele analizei sistemului informaional existent (ASIE) 125
4.3.3. Organizarea i conducerea ASIE 126
4.3.4. Realizarea analizei sistemului informaional existent 127
4.4. PROIECTAREA GENERAL A SISTEMELOR INFORMATICE 134
4.4.1. Obiective i activiti specifice proiectrii generale 134
4.4.2. Proiectarea ieirilor sistemului informatic 136
4.4.3. Proiectarea bazei informaionale de intrare 139
4.4.4. Proiectarea codurilor 142
4.5. PROIECTAREA DE DETALIU 145
4.5.1. Caracteristicile generale ale proiectrii de detaliu 145
4.5.2. Proiectarea fiierelor 146
4.5.3. Stabilirea ordinii de prelucrare a fiierelor de baz 146
4.5.4. Determinarea procedurilor 147
4.5.5. Proiectarea procedurilor 147
4.6. IMPLEMENTAREA SISTEMELOR INFORMATICE 149
4.6.1. Asigurarea condiiilor de punere n funciune 150
4.6.2. Funcionarea experimental i punerea n funciune a sistemului proiectat 151
4.6.3. Documentaia final a sistemelor informatice 152
4.7. EVALUAREA SISTEMELOR INFORMATICE 153
4.7.1. Eficiena economic a sistemelor informatice 153
4.7.2. Managementul calitii sistemelor informatice 154

CAP.5. PROGRAMARE N INTERNET 156
5.1. INTERNET I WEB. ARHITECTURI DE SISTEME DISTRIBUITE 156
5.1.1. Noiuni generale 156
5.1.2. World Wide Web 158
5.1.3. Protocolul HTTP 159
5.1.4. Arhitecturi multistrat 162
5.1.5. Paradigme de programare distribuit 163
5.2. PROGRAMARE PE PARTE DE CLIENT 166
5.2.1. Limbajul HTML 166
5.2.2. Tehnologii DynamicHTML 170
5.2.3. Miniaplicatii Java 173
5.2.4. Programare la client folosind scripting 175
5.3. PROGRAMARE PE PARTEA DE SERVER 178
5.3.1. Servere WWW 178
5.3.2. Gazde virtuale 179
5.3.3. Tehnologiile SSI i CGI 180
5.3.4. Miniservere Java 181
5.4. SERVERE DE BAZE DE DATE 184
5.5. LIMBAJUL DE METAMARCARE XML 188

BIBLIOGRAFIE 197
3

CAP.1. BAZE DE DATE

1.1. CONCEPTE ALE BAZELOR DE DATE RELAIONALE

1.1.1. Definiii

Baze de date
O baz de date este o colecie de informaii interrelaionate gestionate ca o singur unitate.
Aceast definiie este intenionat foarte larg, deoarece exist mari diferene ntre concepiile
diferiilor productori care pun la dispoziie sisteme de baze de date. De exemplu, Oracle
Corporation definete o baz de date ca fiind o colecie de fiiere fizice gestionate de o singur
instan (copie) a produsului software pentru baze de date, n timp ce Microsoft definete o baz
de date SQL Server ca fiind o colecie de date i alte obiecte. Un obiect al bazei de date este o
structur de date denumit stocat n baza de date, cum ar fi un tabel, o vizualizare sau un index.

Sisteme de gestiune a bazelor de date
Un sistem de gestionare a bazei de date (DBMS - database management system) este un
produs software furnizat de productorul bazei de date. Produse software precum Microsoft
Access, Microsoft SQL Server, Oracle Database, Sybase, DB2, INGRES, MySQL i
PostgreSQL fac parte din categoria DBMS sau, mai corect, DBMS relaionale (RDBMS).
Sistemul DBMS pune la dispoziie toate serviciile de baz necesare pentru organizarea i
ntreinerea 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, toate
modificrile 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 RDBMS
nu asigur suportul pentru tranzacii.
- Accept un limbaj de interogare, care reprezint sistemul de comenzi folosit de utilizator
pentru a obine date din baza de date. SQL este principalul limbaj folosit pentru sistemele
DBMS 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 relaionale
O 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 este
obligatoriu ca datele s fie stocate ntr-o form tabelar, iar modelul permite i combinarea
tabelelor (crearea uniunilor (joining), n terminologia relaional) pentru formarea vizualizrilor,
care sunt prezentate tot ca tabele bidimensionale. Flexibilitatea extraordinar a bazelor de date
relaionale este dat de posibilitatea de a folosi tabelele independent sau n combinaii, fr nici o
ierarhie sau secven predefinit n care trebuie s se fac accesul la date.


1.1.2. Componente ale bazelor de date relaionale

1. Tabele
4
Unitatea primar de stocare a datelor ntr-o baz de date relaional este tabelul, care este o
structur bidimensional compus din rnduri i coloane. Fiecare tabel reprezint o entitate, ceea
ce nseamn o persoan, un loc, un lucru sau un eveniment care trebuie s fie reprezentat n baza
de date, cum ar fi un client, un cont bancar sau o tranzacie bancar. Fiecare rnd al tabelului
reprezint 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 magazinul
de produse video. Fiecare rnd din tabel reprezint un film, iar fiecare coloan reprezint o
caracteristic 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. Relaii
Relaiile reprezint asocierile dintre tabelele bazelor de date relaionale. Dei fiecare tabel
relaional poate exista independent, esena bazelor de date este tocmai stocarea informaiilor
ntre care exist legturi. De exemplu, pe lng filmele propriu-zise, se pot stoca i informaii
despre 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 i
formatul 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 l
intereseaz pe utilizator. Posibilitatea de a selecta din baza de date numai informaiile care ne
intereseaz ne permite s ajustm informaiile din baza de date n funcie de cerinele specifice
ale 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 relaiile
dintre 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_RATING
MPAA_RATING_CODE (pk)
MPAA_RATING_DESCRIPTION

MOVIE
MOVIE_ID (pk)
MOVIE_GENRE_CODE (fk1)
MPAA_RATING_CODE (fk2)
MOVIE_TITLE
RETAIL_PRICE_VHS
RETAIL_PRICE_DVD
YEAR_PRODUCED
MOVIE_GENRE
MOVIE_GENRE_CODE (pk)
MOVIE_GENRE_DESCRIPTI
ON
MOVIE_COPY
MOVIE_ID (pk, fk)
COPY_NUMBER (pk)
DATE_ACQUIRED
DATE_SOLD
MEDIA_FORMAT
5

Diagramele ERD ne pun la dispoziie o modalitate de prezentare a proiectului general al
unei 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 tabel
relaional, 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 dou
colecii, aceste relaii pot fi de tip unu la unu, unu la muli i muli la
muli.
Relaiile de tipul 11 (unu la unu), care presupun c unui
membru din colecia A i corespunde un singur membru din colecia B.
Relaiile de tipul 1m sau m1 (unu la
muli sau muli la unu), care presupun c
unui membru din prima entitate A i
corespund mai muli membri din a doua
entitate B; astfel de relaii se mai numesc i
relaii ierarhice.

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

Relaii de tip muli la muli se mai numesc i relaii de tip reea. O relaie muli la muli se
va descompune ntotdeauna n dou relaii, o relaie tip unu la muli i respectiv o a doua relaie
de tip muli la unu prin intermediul unei entiti de legtur.
Fiecare relaie este prezentat n diagrama ERD ca o linie ce conecteaz dou tabele. Cele
dou capete ale liniei arat cardinalitatea maxim a relaiei, respectiv numrul maxim de rnduri
dintr-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 al
relaiei.
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 o
relaie de tip unu-la-mai-muli, ceea ce nseamn c fiecare rnd din tabelul MPAA_RATING
(tabelul din partea unu, numit i tabel printe") poate fi asociat cu mai multe rnduri din tabelul
MOVIE (tabelul din partea mai muli" a relaiei, numit i tabel copil'"), dar fiecare rnd din
tabelul 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 categorie
MPAA, dar o categorie poate fi asociat mai multor filme diferite. Este adevrat ca filmele sunt
uneori cenzurate" pentru a putea fi ncadrate n diferite categorii, dar aceast problem este
rezolvat uor, prin tratarea diferitelor versiuni ale aceluiai film ca i cum ar fi filme diferite, la
fel cum facem atunci cnd un film este reluat cu ali actori. Este foarte important s inei seama
de 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
6
muli", aceasta fiind cea mai frecvent folosit form de relaie. Dac ne uitm din nou la relaia
dintre tabelele MPAA_RATING i MOVIE, aceasta nseamn c fiecare rnd din tabelul
MOVIE trebuie s aib un rnd corespondent n tabelul MPAA_RATING, dar nu este
obligatoriu ca fiecare rnd din tabelul MPAA_RATING s aib asociat un rnd din tabelul
MOVIE. Dac vrei s permitei ca inventarul de filme al magazinului s conin titluri care nu
au 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 frecvent
ntlnite cazurile n care partea unu" a unei relaii nu este obligatorie, este foarte neobinuit s
avei 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 n
dreapta notaia pk", reprezint cheia primar (primary key), adic o coloan sau un set de
coloane 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 din
mai multe coloane, dac aceasta este calea de formare a unei chei unice. Dac o cheie primar
este 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 crearea
relaiilor cu tabelele MOVIE_GENRE i MPAA_RATING i marcate cu identificatoarele
<fk1>" i <fk2>" n dreapta numelui coloanei cheie extern.
Cheile primare i cheile externe sunt blocuri de construcie fundamentale ale modelului
relaional, deoarece stabilesc relaii i permit crearea legturilor ntre date, atunci cnd este
necesar. Trebuie s nelegei acest concept pentru a putea nelege cum funcioneaz bazele de
date relaionale.

3. Restricii
O 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 pentru
obiectul respectiv al bazei de date
Dup ce sunt specificate, restriciile sunt impuse automat de sistemul DBMS i nu pot fi
ocolite dect dac o persoan autorizat le dezactiveaz sau le terge (le elimin). Fiecare
restricie primete un nume unic, astfel nct s poat fi referit n mesajele de eroare i n
comenzile folosite ulterior n baza de date. Este recomandabil ca proiectanii bazei de date s
denumeasc restriciile, deoarece numele generate automat de baza de date nu sunt foarte
descriptive.
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 o
valoare special care nu este egal cu nimic altceva.
Restricia cheie primar (primary key). Definit pe coloana (coloanele) cheie primar ale
unui 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 acelor
coloane 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 ntotdeauna
implementate 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 n
tabele 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, respinge
cererea de inserare. Cutarea n indexuri se face mult mai repede dect cutarea n tabel; ca
urmare, indexarea cheii primare este esenial pentru orice tabel, indiferent de dimensiunea
7
acestuia, astfel nct cutarea cheilor duplicate la fiecare inserare s nu duc la o reducere
semnificativ a performanelor. O caracteristic suplimentar a cheilor primare este faptul c
nu 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 s
conin valori unice n cadrul tabelului. Ca i n cazul cheilor primare, sistemul RDBMS
folosete 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 de
unicitate, iar coloanele care particip la o restricie de unicitate pot conine (n cele mai multe
sisteme RDBMS) i valori nule.
Restricia referenial (numita uneori restricie de integritate referenial). O restricie care
impune o relaie ntre dou tabele dintr-o baz de date relaional. Prin impunere se nelege
c sistemul RDBMS se asigur ntotdeauna, n mod automat, c fiecrei valori a cheii externe
i corespunde o valoare a cheii primare n tabelul printe. Pe scurt, restricia referenial
garanteaz c relaia dintre cele dou tabele i valorile corespondente ale cheii primare i cheii
externe i pstreaz logica n orice moment.
Restricia CHECK. Folosete o instruciune logic simpl (scris n SQL) pentru a valida
valoarea 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 valorii
coloanei, iar un rezultat fals s duc la rejectarea valorii coloanei, cu mesajul de eroare
corespunztor.

4. Vizualizri
O 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 mai
multe privine, se comport ca un tabel, dar nu stocheaz date (nu este stocat dect interogarea
SQL 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 de
date).
mbuntesc performanele interogrilor (n unele sisteme RDBMS precum Microsoft SQL
Server).


1.1.3. Niveluri de abstractizare a datelor

ntr-un sistem informatic ce utilizeaz BD,
organizarea datelor poate fi analizat din mai
multe puncte de vedere i pe diferite niveluri. De
obicei, abordarea se face pe trei niveluri: intern,
conceptual i extern (figura 1.3).




Fig. 1.3 Niveluri de abstractizare

Nivelul intern. Structura datelor este descris foarte detaliat, fiind accesibil numai
Nivel
extern Grup 1 . Grup n

Nivel
conceptual Schema conceptuala

Nivel Schema interna
intern


Mediul de stocare
8
specialitilor (ingineri de sistem, programatori n limbaje de asamblare sau alte limbaje apropiate
de 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 prin
prisma 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 l
constituie modelarea realitii considerate, asigurndu-se independena bazei fa de orice
restricie tehnologic sau echipament anume. ntreaga baz este descris prin intermediul unui
numr 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 global
necesar satisfacerii tuturor cerinelor informaionale. La acest nivel, structura BD se
concretizeaz 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. Iar
dac la nivel conceptual baza de date este abordat n ansamblul ei, n practic un utilizator sau
un grup de utilizatori lucreaz numai cu o poriune specific a bazei, n funcie de departamentul
n 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 i
ca sub-scheme, scheme externe sau imagini (view-uri), n funcie de nevoile fiecrui utilizator
sau 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 parcurgerea
urmtoarelor 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 sistemelor
informatice. n cadrul unui sistem informatic baza de date reprezint elementul central n jurul
cruia se concentreaz celelalte componente ale sistemului.
Formularea problemei presupune stabilirea obiectivelor aplicaiei informatice care
asigur actualizarea i exploatarea bazei de date n concordan cu cerinele managementului
activitii economice pentru care este proiectat baza de date. Obiectivele unei aplicaii
informatice sunt legate de asigurarea informaional a desfurrii proceselor decizionale
specifice actului de conducere. Deci, noi trebuie s ne gndim c, prin existena unei baze de
date, s asigurm fondul de informaii, ntr-o structur i de o calitate corespunztoare cu
cerinele managementului firmei. Baza de date trebuie s permit att obinerea unor informaii
de detaliu, elementare, ct i calculul i prezentarea unor indicatori sintetici, agregai. Dac am
lua doar dou obiective: reducerea costurilor i creterea productivitii muncii ntr-o firm,
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 cheltuielile
salariale etc. Aceste informaii vor servi conducerii la identificarea cilor de reducere a costurilor
i adoptarea celor mai adecvate msuri pentru reducerea acestor costuri. Dup aplicarea
msurilor n practic, informaiile stocate n baza de date trebuie s permit de data aceasta i o
analiz 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 dat
complexitatea 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 intrare
pe baza crora se creeaz i se actualizeaz baza de date, ct i cerinele pentru datele de ieire
folosite 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. Datele
finale se vor integra n ansamblul de rapoarte, liste, situaii cu rezultate pe care le furnizeaz
sistemul informaional compartimentelor de conducere. Pentru indicatorii inclui n rapoartele
finale, n general pentru oricare din indicatorii de ieire, trebuie s fie foarte clar modul n care
sunt 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 fiecrei
coloane, sau totaluri din rapoartele finale.
Aceasta are ca punct de plecare inventarierea cmpurilor prezente n situaiile finale i apoi
gruparea lor n tabele. Gruparea cmpurilor pe tabele se realizeaz prin diverse metode. Dintre
aceste metode, dou sunt cele mai utilizate:
- analiza concordanei IEIRI INTRRI;
- analiza semnificaiei semantice a datelor.
Analiza concordanei IEIRI INTRRI este o tehnic specific proiectrii sistemelor
informatice care identific documentele primare din care se preiau datele de intrare folosite n
calculul datelor de ieire. Aceste documente vor constitui sursele de creare i actualizare a
tabelelor bazei de date.
Tehnica este util n cazul n care proiectantul bazei de date este familiarizat cu sistemul
informaional 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 anumite
documente primare care circul n cadrul sistemului informaional.
Analiza semantic se practic atunci cnd proiectantul bazei de date nu are la dispoziie un
set de documente primare i apare n cazul sistemelor informaionale care se proiecteaz pentru
firmele noi.
Definirea tabelelor i relaiilor dintre tabele este etapa urmtoare n proiectarea bazei de
date. Analiza cerinelor informaionale i a proceselor de prelucrare va conduce la identificarea
datelor ce vor trebui stocate i care vor alctui tabelele bazei de date. O tabel va pstra datele fie
despre toate caracteristicile unei colecii de date, fie numai pentru o parte dintre aceste
caracteristici. Aici intervine spiritul analitic al proiectantului. Structura unei tabele este
reprezentat de lista cmpurilor asociate tabelei mpreun cu descrierea atributelor fiecrui cmp
(natur, lungime, numr de zecimale etc.). n structura unui tabel se regsesc urmtoarele
categorii de cmpuri:
- cmpuri de identificare (chei primare i chei condiionate);
- cmpuri tip dat calendaristic;
- cmpuri cantitativ-valorice;
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 de
gestiune 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 reinut
c nu orice cmp poate fi folosit la stabilirea unei relaii, a unei legturi ntre dou tabele. Numai
cmpurile de tip cheie candidat, care au proprietatea de a identifica n mod unic o nregistrare
dintr-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 nregistrrilor
ntr-o tabel se numete indexare. Prin indexare, fiecrei tabele principale de date i se va asocia o
tabel 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 datelor pn la un nivel minim i controlat urmrete eliminarea
duplicrii inutile a unor cmpuri n mai multe tabele sau eliminarea cmpurilor obinute prin
calcul pe baza cmpurilor atomice. Un anumit nivel de redundan, ns, trebuie admis pentru a
nu denatura realitatea reflectat de date. De exemplu, cmpul
VALOAREA_CONTRACTULUI, se calculeaz dup relaia:
VALOAREA_CONTRACTULUI=CANTITATE*PRET
Nu este recomandat eliminarea acestui cmp pe considerentul c el se obine automat
prin calcul. De exemplu, n cazul n care dup un anumit interval de timp, preurile suport o
majorare global, cum se practic foarte des, atunci automat se vor modifica i valorile
contractelor 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. De
exemplu, se consider o firm care deruleaz lunar mii de contracte de aprovizionare, pentru un
nomenclator foarte mare de produse agroalimentare, dar care opereaz numai cu civa furnizori.
Dac n tabela CONTRACTE sunt incluse alturi de codul furnizorului i denumirea
furnizorului, contul su bancar i denumirea bncii, atunci va aprea urmtoarea anomalie de
actualizare, 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 ca
element de legtur, ceea ce previne pierderea de informaii prin spargerea unui tabel n dou. n
acest fel modificarea se realizeaz numai asupra unei singure nregistrri.
11
n 1972, Dr. E. F. Codd, printele bazelor de date relaionale, i-a dat seama c tabelele
relaionale care ndeplinesc anumite criterii pun mai puine probleme la inserarea, actualizarea
sau 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 toate
informaiile despre filme ar fi colectate ntr-un singur tabel. Acest exemplu va fi folosit pentru
ilustrarea procesului de normalizare.
n general, numele coloanelor din tabelele relaionale folosesc liniue de subliniere pentru
separarea cuvintelor. n discuia despre normalizare am eliminat aceste liniue din figuri, pentru a
face textul mai uor de citit.
Exist trei probleme care pot aprea n tabelele fr normalizare din bazele de date
relaionale i toate trei exist i n tabelul din figura 1.5. Scopul procesului de normalizare este
de a elimina aceste probleme (anomalii) din proiectul bazei de date.
MOVI
E_
ID
MOVIE_GEN
RE_
CODE
MOVIE_GEN
RE_
DESC
LAN
G_
COD
E
MPAA_
RATIN
G_
CODE
MPAA_
RATING_
DESC
MOVIE_
TITLE
YEAR_
PRODUC
ED
DATA_
ACQUIR
ED
DATE
_
SOLD
MEDIA
_
FORM
AT
RETAI
L_
PRICE
1 Drama Drama en,fr R under 17
requires
accompany
ing parent
or adult
guardian
Mystic
River
2003 01/01/200
5
DVD 19.96
2 ActAd Action and
Adventure
en,
fr,
es
R under 17
requires
accompany
ing parent
or adult
guardian
The Last
Samurai
2003 10/01/200
5
DVD 19.96
2 ActAd Action and
Adventure
en,
fr,
es
R under 17
requires
accompany
ing parent
or adult
guardian
The Last
Samurai
2003 10/01/200
5
VHS 15.95
3 Comdy Comedy en PG-13 Parents
strongly
cautioned
Somethin
gs Gotta
Give
2003 1/10/2005 1/30/20
05
DVD 29.99
3 Comdy Comedy en PG-13 Parents
strongly
cautioned
Somethin
gs Gotta
Give
2003 2/15/2005 DVD 29.99
Fig 1.5 Tabelul MOVIE fr normalizare

Anomalia de inserare
Anomalia 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 s
adugai n baza de date a magazinului de produse video un nou gen de film (n coloanele
GENRE_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 plasat
n 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 i
MPAA_RATING_DESCRIPTION. Ar fi mult mai bine dac ai putea aduga noile genuri i
categorii nainte de primirea filmelor n magazin.
Anomalia de tergere
Anomalia 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 film
din figura 1.5 (Mystic River) este singurul rnd din tabelul MOVIE pentru care coloana
GENRE_CODE are valoarea Drama" i este ters, se pierde informaia c a existat vreodat un
gen numit Drama".
Anomalia de actualizare
Anomalia 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
12
trebuie s modificai descrierea codului MPAA_RATING_CODE R", trebuie s modificai i
toate rndurile din tabel pentru filmele cu codul respectiv. Probleme similare apar i pentru
coloana GENRE_DESCRIPTION. Chiar i coloana RETAIL_PRICE are aceast problem,
deoarece toate copiile aceluiai film (cu aceeai valoare MOVIE_ID) pe acelai mediu (DVD
sau VHS) ar trebui s aib acelai pre. Un alt pericol legat de aceast anomalie este faptul c
stocarea 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 normalizare
De 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 prima
vedere, dar este ceva obinuit ca proiectarea unui sistem de prelucrare a datelor s nceap de la
rezultatele pe care le va vedea utilizatorul, parcurgnd apoi drumul napoi ctre mijloacele
folosite 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 deoarece
impune proiectantului s se gndeasc ntr-un mod conceptual la datele i relaiile pe care
intenioneaz 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 avea
ntr-un model fr normalizare. Relaiile suplimentare sunt necesare pentru eliminarea
anomaliilor, 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 din
uurina utilizrii pentru ca operaiile de inserare, actualizare i tergere s fie mai simple.
Alegerea unul identificator unic
Primul 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 unic
fiecare rnd de date dintr-o relaie.
Identificatorul unic va deveni ulterior cheia primar a tabelului creat din relaia
normalizat. 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 folosit
ca 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 atribute
multiple, fiecare atribut rmne pe propria lui coloan - nu facei dect s definii un identificator
unic format din mai multe coloane.
n foarte puine cazuri, ntr-o relaie nu exist un set rezonabil de atribute care s poat fi
folosit ca identificator unic. Atunci cnd se ntmpl acest lucru, trebuie s inventai un
identificator unic, deseori cu valori atribuite secvenial sau aleatoriu pe msur ce noile rnduri
de date sunt adugate n tabelul bazei de date. Aceast tehnic este sursa unor identificatoare
unice, precum numrul de asigurri sociale folosit n Statele Unite, numerele de identificare ale
angajailor, 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 fiecare
titlu, dar magazinul urmrete separat fiecare copie a filmelor pe care le are n stoc. Cauza este
13
faptul c magazinul se ocup i de nchirierea filmelor i vrea s se asigure c fiecare client
returneaz exact copia pe care a nchiriat-o. Dup inspectarea datelor folosite ca exemplu i o
scurt discuie cu proprietarul magazinului, ajungei la concluzia c n relaia Movie nu exist
nici o combinaie de atribute care s identifice n mod unic fiecare copie a unui film, aa c
inventai un atribut numit Copy_Number i-l adugai n relaie. Ori de cte ori inventai un
identificator 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 la
1 pentru fiecare valoare Movie_ID, ceea ce nseamn c valorile Copy_Number sunt unice
numai n combinaie cu valorile Movie_ ID. Relaia rezultat este prezentat n figura 1.6.

Prima form normal: eliminarea datelor repetate
O 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-o
relaie, orice intersecie a unui rnd cu o coloan trebuie s conin cel mult o valoare pentru ca
relaia s fie n prima form normal. n figura 1.6, atributul pentru limb (Lang. Code) conine
mai multe valori pentru unele dintre filme, aa c-1 putei considera un atribut cu valori multiple.

MOVIE
_ID (pk)
COPY
_
NUMB
ER
(pk)
MOVIE_GE
NRE_
CODE
MOVIE_GE
NRE_
DESC
LAN
G_
COD
E
MPA
A_
RATI
NG
CODE
MPAA_
RATING
_
DESC
MOVI
E_
TITL
E
YEAR_
PRODU
CED
DATA_
ACQUI
RED
DAT
E_
SOL
D
MEDI
A_
FORM
AT
RETAI
L_
PRICE
1 1 Drama Drama en,fr R under 17
requires
accompan
ying
parent or
adult
guardian
Mystic
River
2003 01/01/20
05
DVD 19.96
2 1 ActAd Action and
Adventure
en,
fr,
es
R under 17
requires
accompan
ying
parent or
adult
guardian
The
Last
Samur
ai
2003 10/01/20
05
DVD 19.96
Fig. 1.6 Relaia Movie dup adugarea atributului Copy_Number

Pentru transformarea relaiilor ne-normalizate n prima form normal, trebuie mutate
atributele multivaloare i grupurile repetitive n noi relaii.
Procedura de mutare a unui atribut multivaloare sau a unui grup repetitiv ntr-o nou relaie
const n urmtoarele etape:
1. Creai o nou relaie, cu un nume sugestiv. Deseori, este bine s includei numele
relaiei 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 format
conine numai numrul minim de atribute necesar pentru a-1 face unic. Dac mutai un atribut
multivaloare, care, n esen, este un grup repetitiv cu un singur atribut, este adugat atributul
respectiv pentru formarea identificatorului unic. Poate prea ciudat la prima vedere, dar
identificatorul 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. De
asemenea, 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
14
paii 2 i 4. Figura 1.7 prezint rezultatul aducerii relaiei din figura 1.6 la prima form normal.
Movie
MOVI
E_
ID
(pk)
COPY_
NUMB
ER
(pk)
MOVIE_GE
NRE_
CODE
MOVIE_GE
NRE_
DESC
MPAA_RATI
NG_
CODE
MPAA_
RATING
_
DESC
MOVI
E_
TITL
E
YEAR_
PRODUC
ED
DATA_
ACQUIR
ED
DAT
E_
SOL
D
MEDI
A_
FORM
AT
RETAI
L_
PRICE
1 1 Drama Drama R under 17
requires
accompan
ying
parent or
adult
guardian
Mystic
River
2003 01/01/200
5
DVD 19.96
2 1 ActAd Action and
Adventure
R under 17
requires
accompan
ying
parent or
adult
guardian
The
Last
Samur
ai
2003 10/01/200
5
DVD 19.96
2 2 ActAd Action and
Adventure
R under 17
requires
accompan
ying
parent or
adult
guardian
The
Last
Samur
ai
2003 10/01/200
5
VHS 15.95

Movie_Language
MOVIE_ID (fk) LANGUAGE_CODE
1 en
1 fr
2 en
2 fr
2 es
Fig 1.7 Soluia primei forme normale

A doua form normal: eliminarea dependenelor pariale
nainte 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 mult
de 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 este
dependent funcional de atributul Movie_ID, deoarece, n orice moment, poate exista o singur
valoare Movie_Title pentru o valoare Movie_ID dat. Chiar faptul c valoarea Movie_ID
definete n mod unic valoarea Movie_Title n relaie nseamn c Movie_Title este dependent
funcional 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, numai
atributele Date_Acquired, Date_Sold, Media_Format i Retail_Price depind de ntregul
identificator. 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 aprut
aceast problem? Ar trebui s fie clar c unele atribute descriu filmul n sine, n timp ce altele
descriu, copiile pe care le deine (sau le-a deinut) magazinul din filmul respectiv. n esen, am
amestecat 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 va
ajuta s rezolvm problemele.
A doua form normal se aplic numai relaiilor care au identificatoare unice concatenate
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 prima
form normal care are cheia primar format dintr-un singur atribut este automat n a
doua form normal.

Movie
MOVIE_ID
(pk)
MOVIE_
GENRE_
CODE
MOVIE_
GENRE_
DESC
MPAA_
RATING_
CODE
MPAA_
RATING_
DESC
MOVIE_
TITLE
YEAR_
PRODUCED
1 Drama Drama R under 17 requires
accompanying parent or
adult guardian
Mystic
River
2003
2 ActAd Action and
Adventure
R under 17 requires
accompanying parent or
adult guardian
The Last
Samurai
2003
Movie_Language
MOVIE_ID (fk) LANGUAGE_CODE
1 en
1 fr
2 en
2 fr
2 es
Movie_Copy
MOVIE_ID
(pk)
COPY_NUMBER
(pk)
DATA_ACQUIRED DATE_SOLD MEDIA_FORMAT RETAIL_PRICE
1 1 01/01/2005 DVD 19.96
2 1 10/01/2005 DVD 19.96
2 2 10/01/2005 VHS 15.95
3 1 10/01/2005 30/01/2005 DVD 29.99
3 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 de
dependen 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 de
MPAA_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 trei
anomalii de date prezentate mai devreme n acest capitol.
Se spune c o relaie este n a treia form normal dac ndeplinete urmtoarele dou
criterii:
- Relaia este n a doua form normal.
- Nu exist dependene tranzitive (cu alte cuvinte, toate atributele non-cheie depind
numai de identificatorul unic).
Pentru a aduce la a treia form normal o relaie aflat n a doua form normal, mutm
atributele 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 cheie
extern. 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 forme
normale.
De exemplu, ntr-o baz de date pentru vnzri, Suma Total este obinut nmulind
Cantitatea 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 atribute
sunt dependente de identificatorul unic al relaiei care le conine, este uor de vzut c Suma
Total (rezultatul calculat) este, de fapt, dependent tranzitiv de celelalte dou atribute. Figura
16
1.9 conine soluia n a treia form normal.
Movie
MOVIE_ID
(pk)
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
Movie_Language
MOVIE_ID (fk) LANGUAGE_CODE
1 en
1 fr
2 en
2 fr
2 es
Movie_Copy
MOVIE_ID (pk) COPY_NUMBER (pk) DATA_ACQUIRED DATE_SOLD MEDIA_FORMAT
1 1 01/01/2005 DVD
2 1 10/01/2005 DVD
2 2 10/01/2005 VHS
3 1 10/01/2005 30/01/2005 DVD
3 2 15/02/2005 DVD
MPAA_Rating
MPAA_RATING_CODE (pk) MPAA_RATING_DESCRIPTION
PG-13 parents strongly cautioned
R under 17 requires accompanying parent or adult guardian
Movie_Genre
MOVIE_GENRE_CODE (pk) MOVIE_GENRE_DESCRIPTION
ActAd Action and Adventure
Comedy Comedy
Drama Drama
Fig 1.9 Soluia pentru a treia form normal

Prezentare general a bazei de date pentru un magazin de produse video
Toate exemplele prezentate n cadrul cursului folosesc ca suport o baz de date pentru un
magazin de produse video.
Figura 1.10 prezint diagrama de relaii a entitilor (ERD - Entity Relationship Diagram)
pentru ntreaga baz de date a magazinului de produse video.


1.2. CONCEPTE SQL

SQL a devenit limbajul universal pentru bazele de date relaionale i este acceptat de
aproape toate sistemele RDBMS moderne. Fr ndoial, acceptarea pe scar larg este rezultatul
timpului i eforturilor depuse pentru dezvoltarea caracteristicilor limbajului i a standardelor,
crescnd nivelul de portabilitate a codului SQL ntre diferitele produse RDBMS.
SQL (Structured Query Language - limbaj structurat de interogare) este un limbaj
standard folosit pentru comunicarea cu bazele de date. Numele limbajului poale fi pronunat pe
litere (es-q-el) sau la fel ca i cuvntul englezesc sequel". O interogare (query) este o simpl
cerere transmis ctre baza de date, la care aceasta rspunde ntr-o anumit form. SQL este
limbajul folosit cel mai frecvent pentru interogarea bazelor de date. SQL este considerat un
limbaj neprocedural sau declarativ ceea ce nseamn c-i spunei calculatorului ce rezultate
vrei, fr s-i spunei cum s le obin.




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 limbaj procedural folosete o serie de instruciuni executate
secvenial. De asemenea, limbajele procedurale includ instruciuni care pot modifica secvena de
execuie, prin ramificarea la alte poriuni ale procedurii sau prin parcurgerea ciclic a unui set de
instruciuni din procedur. Muli productori de sisteme RDBMS ofer extensii procedurale ale
limbajului 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 SQL
pe care-1 conin rmne neprocedural. De asemenea, SQL nu trebuie confundat cu limbajele
orientate spre obiecte, precum Java i C++.
Simplu spus, SQL este un limbaj pentru gestionarea i ntreinerea bazelor de date
relaionale, nu un limbaj potrivit pentru programarea general a aplicaiilor, cum ar fi sistemele
de prelucrare a comenzilor sau a plilor.
SQL este deseori folosit n combinaie cu limbajele procedurale sau orientate spre obiecte
menionate anterior pentru a manipula stocarea i extragerea datelor, folosind instruciuni din
limbajul de programare cu destinaie general pentru alte sarcini de programare, precum
prezentarea datelor pe o pagin web sau furnizarea rspunsurilor la informaiile introduse de
utilizatori 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 n
vederea prelucrrii, primesc rezultatele returnate de RDBMS i le prelucreaz ntr-un mod
corespunztor.
MPAA_RATING
MPAA_RATING_CODE <pk>
MPAA_RATING_DESCRIPIO
N
MOVIE
MOVIE_ID <pk>
MOVIE_GENRE_CODE
<fk1>
MPAA_RATING_CODE
<fk2>
MOVIE_TITLE
RETAIL_PRICE_DVD
RETAIL_PRICE_VHS
YEAR_PRODUCED
MOVIE_GENRE
MOVIE_GENRE_CODE <pk>
MOVIE_GENRE_DESCRIPTI
ON
MOVIE_LANGUAGE
MOVIE_ID <pk, fk2>
LANGUAGE_CODE <pk, fk1>
LANGUAGE
LANGUAGE_CODE <pk>
LANGUAGE_NAME
MOVIE_COPY
MOVIE_ID <pk, fk>
COPY_NUMBER <pk>
DATE_ACQUIRED
DATE_SOLD
MEDIA_FORMAT
MOVIE_RENTAL
MOVIE_ID <pk, fk1>
COPY_NUMBER <pk, fk1>
TRANSACTION_ID <pk, fk2>
DUE_DATE
RENTAL_FEE
LATE_OR_LOSS_FEE
RETURNED_DATE


CUSTOMER_TRANSACTION
TRANSACTION_ID <pk>
CUSTOMER_ACCOUNT_ID
<fk2>
EMPLOYEE_PERSON_ID <fk1>
TRANSACTION_DATE
SALES_TAX
CUSTOMER_ACCOUNT
CUSTOMER_ACCOUNT_ID <pk>
CUSTOMER_HOLD_IND
DATE_ENROLLED
DATE_TERMINATED
CUSTOMER_DEPOSIT_AMOUNT
CREDIT_CARD_ON_FILE_INDIC
CHILD_RENTAL_ALLOWED_IN
DIC
CUSTOMER_ACCOUNT_PERSON
CUSTOMER_ACCOUNT_ID <pk,
fk2>
PERSON_ID <pk, fk1>
PERSON
PERSON_ID <pk>
PERSON_GIVEN_NAME
PERSON_MIDDLE_NAME
PERSON_FAMILY_NAME
PERSON_ADDRESS_1
PERSON_ADDRESS_2
PERSON_ADDRESS_CITY
PERSON_ADDRESS_STATE_PRO
V
PERSON_ADDRESS_POSTAL_C
ODE
PERSON_ADDRESS_COUNTRY
PERSON_PHONE
BIRTH_DATE
DEATH_DATE
EMPLOYEE
PERSON_ID <pk, fk1>
SUPERVISOR_PERSON_ID <fk2>
EMPLOYEE_TAX_ID
EMPLOYEE_JOB_CATEGORY
EMPLOYEE_HOURLY_RATE
HIRE_DATE
TERMINATION_DATE

18

1.2.1. Conectarea la baza de date

Atunci cnd folosii limbajul SQL pe un calculator personal, cu o copie personal a unui
sistem DBMS, precum Microsoft Access sau Oracle Personal Edition, toate componentele bazei
de 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 un
server de dimensiuni mari.
Fiierele care compun baza de date din punct de vedere fizic sunt stocate pe discuri conectate
la 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, instalat
acas 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 introduc
instruciuni SQL, s le transmit sistemului DBMS n vederea prelucrrii i s
vad rezultatele returnate de DBMS. n general, acest software se numete client
SQL.
De reinut c: nimic nu ne oprete s instalm clientul SQL pe acelai calculator cu
sistemul 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 convenabil
s 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 mult
mai convenabil i mai eficient s avei o singur copie a sistemului DBMS pe un server partajat
i 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

19
n funcie de interfaa cu utilizatorul de pe staia de lucru client, clienii SQL sunt
clasificai n trei categorii:
- n linia de comand: o interfa n linia de comand se bazeaz 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 orice
sistem de operare.
- grafici: o interfa grafic cu utilizatorul (GUI - graphical user interface) ruleaz sub un tip
oarecare de sistem bazat pe ferestre, cum ar fi X Window System, Mac OS sau Microsoft
Windows, 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. Din
punct de vedere tehnic, un client SQL bazat pe web nici nu este o aplicaie client, deoarece nu
exist nici o component software specific productorului DBMS rulat pe staia de lucra a
clientului. Totui, aproape ntotdeauna exist componente furnizate de productorul DBMS
care sunt descrcate n fundal de browser-ul web pentru a asista n procesul de reprezentare
grafic 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 construirea
instruciunilor SQL. Conveniile de sintax SQL sunt mai uor de neles folosind un exemplu
simplu. Instruciunea de mai jos returneaz valorile Movie_ID i Movie_Title pentru toate
filmele 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 i
virgul (;).
- Instruciunile sunt construite ntr-o manier similar cu propoziiile din limba englez, cu unul
sau 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 o
linie nou. Totui, n general nu este o idee bun s mprii un element de limbaj pe mai
multe 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. Aceasta
nu 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 a
dou 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
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 sunt
niciodat ncadrate cu apostrofuri. Dac n irul de caractere trebuie s apar un caracter
apostrof 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 de
subliniere. Caracterul underscore (liniua de subliniere) este folosit, de obicei, ca separator
ntre cuvinte, pentru mbuntirea lizibilitii.
- n fiecare implementare SQL este definit un set de cuvinte rezervate
t
care sunt cuvinte cu o
semnificaie specific pentru procesorul SQL al sistemului DBMS i, ca urmare, nu trebuie
folosite 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 se
pot 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 utilizatorului
bazei 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 DROP
sunt considerate parte a DDL.
Este important s nelegei c instruciunile DDL afecteaz containerele care stocheaz
datele 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 obinerea
datelor din baza de date. Dei reprezint o parte foarte important a limbajului SQL, DQL este
format din instruciuni care folosesc o singur comand: SELECT.
Limbajul de manipulare a datelor (DML): include instruciuni SQL care permit
utilizatorului bazei de date s adauge date n baza de date (sub forma rndurilor din tabele), s
tearg date i s modifice datele existente n baza de date. Instruciunile SQL care folosesc
comenzile INSERT, UPDATE i DELETE sunt considerate parte a DML.
Limbajul pentru controlul datelor (DCL): include instruciuni SQL care permit
administratorilor s controleze accesul la datele din baza de date i folosirea diferitelor privilegii
ale 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
21
totul sau nimic, nelegnd prin aceasta c ntreaga tranzacie trebuie s reueasc sau s
eueze. Comenzile pentru controlul tranzaciilor (Transaction Control Commands) nu respect cu
exactitate sintaxa instruciunilor SQL, dar afecteaz puternic comportamentul instruciunilor
SQL 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 nu
insereaz i nu actualizeaz date n obiectele respective (aceast funcie fiind ndeplinit de
instruciunile 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 n
instruciune.
- DROP - terge (distruge) un obiect existent n baza de date, de tipul specificat n
instruciune.
Instruciunea CREATE DATABASE
Sintaxa general pentru instruciunea CREATE DATABASE este
CREATE DATABASE nume_baza_de_date [opiuni specifice productorului]
Instruciunea CREATE TABLE
CREATE 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-o
baz de date ncepe ntotdeauna cu crearea unui tabel. Sintaxa de baz pentru instruciunea
CREATE TABLE este
CREATE TABLE nume tabel ( <definiiecoloana> [,<definiiecoloan> ...])
[, <restricietabel> ... ] ;
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 n
baza de. Fiecare tabel trebuie s aib cel puin o coloan.
Definirea coloanelor n SQL DDL
Sintaxa de baz folosit pentru definirea coloanelor unui tabel este:
<definiiecoloana> :
numecoloan tipdedate [DEFAULT expresie] [ NULL | NOT NULL]
[<restriciecoloan>]
Restriciile coloanelor
Restriciile 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 toate
sistemele DBMS. Restricia unei coloane se poate referi la o singur coloan, dar exist o
modalitate simpl de ocolire, deoarece orice restricie de coloan poate fi rescris ca restricie de
tabel. Restriciile coloanelor pot avea oricare dintre urmtoarele forme:
Clauza DEFAULT
O 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 care
poate fi interpretat de SQL, cum ar fi o constant, o funcie SQL sau o alt sintax care, n urma
evalurii de ctre motorul SQL din DBMS, produce o valoare corespunztoare pentru coloana
22
respectiv.
Ca exemplu, observai clauza DEFAULT 'N' pentru coloana
CUSTOMER_HOLD_INDIC din tabelul CUSTOMER_ACCOUNT. Prin specificarea acestei
valori 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 pentru
aceast 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 curente
pentru efectuarea unei tranzacii, la inserarea noilor rnduri n baza de date. Iat sintaxa SQL i
un exemplu de coloan cu o clauz DEFAULT:
[DEFAULT expresie]
Exemplu:
CUSTOMER_HOLD_INDIC CHAR(l) DEFAULT 'N' NOT NULL
Restricia NULL | NOT NULL
Specificarea cuvntului cheie NULL permite stocarea valorilor nule ntr-o
coloan, n timp ce NOT NULL nu permite stocarea valorilor nule n coloana
respectiv. Iat sintaxa SQL i cteva exemple:
NULL | NOT NULL
Exemple:
DATE_ENROLLED DATE NOT NULL
DATE_TERMINATED DATE NULL
Restricia CHECK
O 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 ndeplinit
ori de cte ori datele din coloana respectiv a tabelului sunt modificate - n caz contrar, sistemul
DBMS va respinge modificarea i va afia un mesaj de eroare. Condiia din restricia CHECK a
unei 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 NULL
CHECK (CREDIT_CARD_ON_FILE_INDIC IN 'Y', 'N')
Restricia UNIQUE
O 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 KEY
O 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 respectiv
nu pot exista valori nule, iar valorile trebuie s fie unice n cadrul tabelului. Ca i n cazul
restriciilor de unicitate, majoritatea sistemelor DBMS impun restricia de cheie primar cu
ajutorul 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
23
extern) definete relaia dintre o cheie extern i o cheie primar, astfel nct sistemul DBMS s
poat garanta c valoarea, dac nu este nul, refer ntotdeauna valoarea unei chei primare
existente. 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 NULL
REFERENCES 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 opiunea
de 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 tabelelor
Restricia 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 tuturor
coloanelor, nu dup definiia unei coloane. Principalul avantaj al restriciilor la nivelul tabelului
este c pot referi mai multe coloane. Semnificaia fiecrei restricii a fost deja discutat (n
seciunea despre restriciile coloanelor) aa c aici vom prezenta numai sintaxa general i cteva
exemple.
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_AMOUNT
CHECK (CUSTOMER_DEPOSIT_AMOUNT >= 0 OR
CUSTOMER_DEPOSIT_AMOUNT
IS NULL)
Restricia din exemplul de mai sus mpiedic stocarea unei valori negative n coloana
CUSTOMER_DEPOSIT_AMOUNT. Observai operatorul SAU, folosit pentru a permite
stocarea valorilor nule n coloan. Dac nu ar fi fost inclus aceast condiie, coloana nu ar fi
acceptat 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_ENROLLED
UNIQUE (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 unei
restricii 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 tabelul
CUSTOMER_ACCOUNT folosit ca exemplu n aceast seciune, dar n acest caz am denumit
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 DELETE
SET NULL)
Observai c, spre deosebire de forma pentru coloane a restriciei refereniale, aceasta poate
referi coloane multiple. Aa cum a fost proiectat, tabelul CUSTOMER_ACCOUNT nu are
coloane 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 a
controla 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 de
date pentru magazinul de produse video trebuie s permitem stocarea unei noi valori, 'E' (de la
exceptat"), 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 suficient
s 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 video
conine tabele pentru informaii precum MPAA_RATING_CODE - dac asociaia MPAA i
schimb sistemul de clasificare, este suficient s modificai datele din tabelul de coduri. De
asemenea, tabelele de coduri sunt o surs elegant pentru popularea cu valori a listelor derulante
din componente de aplicaie, precum formularele din paginile web.
Presupunnd c a fost creat un tabel numit CARD ON_FILE_TYPE, cu o cheie primar
numit CARD_ON_FILE_CODE, iat cum arat restricia referenial care definete coloana
CREDIT_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 unei
baze de date, ci mai multe soluii din care putei alege. Altfel spus, proiectarea bazelor de date nu
este 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.
Instruciunea CREATE INDEX
CREATE [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 creeaz
indexul 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 a
numrului de coloane.
Indexurile sunt instrumente puternice, deoarece permit sistemului DBMS s gseasc
datele mult mai repede, aa cum indexul unei cri v permite s gsii rapid ceea ce v
intereseaz. Mai mult, indexurile pe coloanele cheilor externe cresc mult performanele la unirea
tabelelor. Totui, indexurile ocup spaiu de stocare i trebuie s fie ntreinute de fiecare dat
cnd se modific o valoare de pe o coloan referit de un index, trebuie s fie modificat i
indexul corespunztor. Sistemul DBMS ntreine automat indexul, dar activitatea de ntreinere
consum din resursele calculatorului.
Instruciunea CREATE VIEW
Vizualizrile ofer mari avantaje utilizatorilor unei baze de date, deoarece permit ajustarea
25
datelor afiate n funcie de cerinele individuale i mascheaz operaiile complexe. Atunci cnd
sunt create corect, vizualizrile implic suprasarcini minime i nu stocheaz date.
n esen, o vizualizare este o interogare SQL stocat, care poate fi referit de instruciunile
SQL DML i DQL ca i cum ar fi un tabel real. Unii consider c vizualizrile sunt tabele
virtuale, deoarece se comport la fel ca tabelele (cu unele restricii), dar nu exist ca tabele
fizice.
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 OR
REPLACE i vizualizarea exist deja, este nlocuit, iar dac nu exist, noua vizualizare este
adugat n baza de date.
- Numele vizualizrii trebuie s respecte aceleai reguli de denumire ca i tabelele
i alte obiecte ale bazei de date. n interogrile SQL sunt specificate numele obiectelor din
care sunt selectate datele, dar nu i tipul acestor obiecte. Ca urmare, numele vizualizrilor
trebuie 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 n
capitolul 4. Crearea vizualizrilor urmeaz o cale natural de evoluie - lucrai cu
interogarea SQL, facei modificrile necesare i rulai din nou interogarea pn
cnd obinei rezultatele dorite. Apoi adugai instruciunea CREATE VIEW n
faa interogrii cu care ai lucrat i rulai instruciunea pentru a stoca permanent
interogarea n baza de date, ca vizualizare. Aceasta este o modalitate foarte
productiv (i plcut) de a lucra cu bazele de date.
Instruciunea ALTER TABLE
Dup 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 foloseasc
instruciuni CREATE TABLE ct mai simple, evitnd s defineasc restricii n instruciunile
CREATE TABLE. Acetia adaug dup instruciunea CREATE TABLE instruciuni ALTER
TABLE prin care specific toate restriciile necesare (cheie primar, cheie extern, unicitate,
verificare i aa mai departe). Dezavantajul acestei metode este acela c necesita scrierea unei
cantiti mai mari de cod. Pe de alt parte, instruciunea CREATE TABLE este mult mai uor de
neles fr restricii, iar scrierea separat a restriciilor simplific refolosirea instruciunilor, dac
este nevoie s eliminai i apoi s creai din nou restriciile.
* Adugarea unei coloane la un tabel. Definirea coloanei se face cu aceeai sintax ca i
n cazul instruciunii CREATE TABLE.
ALTER TABLE nume tabel ADD ( <definiie_coloan> [,<definiie_coloan>]);
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] ( <definiie_coloan>
[,<definiie_coloan>]);
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
26
care ar putea aprea ntr-o instruciune CREATE TABLE.
ALTER TABLE nume tabel ADD CONSTRAINT <definiie_restricie>;
Exemplu:
ALTER TABLE CUSTOMER_ACCOUNT ADD CONSTRAINT CK_CUSTOMER
DEPOSIT_AMOUNT CHECK (CUSTOMER_DEPOSIT_AMOUNT >= 0 OR
CUSTOMER DEPOSIT AMOUNT IS NULL);
* tergerea cheii primare a unui tabel. Dac cheia primar este referit de restricii
refereniale, trebuie mai nti terse restriciile respective.
ALTER TABLE nume tabel DROP 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_noua column_definition
[FIRST|AFTER col_name]
Instruciunea DROP
Instruciunea DROP este cea mai simpl dintre instruciunile DDL. Sintaxa de baz este:
DROP <tip_obiect> nume_obiect [<opiuni_de_tergere>]
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 tabelul
Iat 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 singur
comand, dar una foarte important: SELECT. Comanda SELECT este folosit pentru a obine
date din baza de date (fr s le modifice), astfel nct acestea s poate fi prelucrate de o aplicaie
sau afiate pentru un utilizator.
Rezultatul unei instruciuni SELECT, numit set de rezultate, este returnat ntotdeauna sub
forma unui tabel (adic rnduri i coloane). Nu uitai c SQL este un limbaj neprocedural, aa c
specificai rezultatele pe care vrei s le obinei (adic modul n care vrei s fie returnat setul de
rezultate), nu i modul n care vor fi obinute acestea.
Instruciunea SELECT de baz
Forma elementar a instruciunii SELECT conine dou clauze:
- SELECT [DISTINCT] - Specific lista de coloane care urmeaz s fie
returnate n setul de rezultate, separate prin virgule. Putei folosi simbolul asterisc
(*) n locul listei de coloane pentru a selecta toate coloanele dintr-un tabel sau
dintr-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 folosi
sinonime, 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
27
MOVIE;
Pseudonime pentru numele coloanelor
Se 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, deoarece
instruciunea SQL v pune la dispoziie o modalitate simpl de a specifica pseudonime pentru
coloane. 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 pot
fi folosite n alte pri ale instruciunii SQL. Pseudonimul unei coloane este specificat prin
plasarea cuvntului cheie AS" dup numele coloanei n lista SELECT (cu cel puin un spaiu
nainte si dup), urmat de numele pe care vrei s-l atribuii coloanei n setul de rezultate. Iat
cum arat instruciunea SQL rulat mai devreme, dar cu coloana MOVIE_GENRE_CODE
redenumit GENRE i coloana MPAA_RATING_CODE redenumit RATING.
SELECT MOVIE_GENRE_CODE AS GENRE,
MPAA_RATING_CODE AS RATING, MOVIE_TITLE FROM MOVIE;
Sortarea rezultatelor
Rezultatele 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 setul
de rezultate dect dac ordinea dorit este specificat n interogare.
n SQL, acest lucru este fcut prin adugarea n instruciunea SELECT a clauzei ORDER
BY, cu o list de una sau mai multe coloane care vor fi folosite pentru sortarea rndurilor n
ordine ascendent sau descendent, n conformitate cu valorile datelor din coloane.
n cazul instruciunii SELECT folosite mai devreme, s presupunem c ar fi util
ordonarea 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 rezultatele
interogrii i s le specificai n aceeai ordinea n lista ORDER BY (cel puin n limbile citite de
la 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 rezultatelor
SQL 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 conine
toate rndurile din tabelele sau vizualizrile referite n clauza FROM. Dac este inclus o clauz
WHERE, sunt folosite regulile algebrei booleene, numite astfel dup numele logicianului George
Boole, evalund clauza WHERE pentru fiecare rnd de date. n rezultatele interogrii sunt afiate
numai rndurile pentru care clauza WHERE este evaluat la valoarea logic adevrat".
Operatori de comparare
Operatorii 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 fi
constante furnizate n clauza WHERE, valori ale unor coloane din baza de date sau combinaii
ale celor dou. Operatorii de comparare care pot fi folosii n clauza WHERE sunt prezentai n
tabelul urmtor:
Operator Descriere
= Egal cu
< Mai mic dect
<= Mai mic sau egal cu
> Mai mare dect
>= Mai mare sau egal cu
!= Diferit de
<> Diferit de (standard ANSI)
Exemple:
28
- Afiai toate filmele pentru care MPAA_Rating are valoarea PG-13
SELECT MPAA_RATING_CODE AS RATING, MOVIE_TITLE
FROM MOVIE WHERE MPAA_RATING_CODE = 'PG-13'
ORDER BY MOVIE_TITLE;
- Afiai toate filmele cu preul de vnzare cu amnuntul pentru formatul DVD (DVD Retail
Price) mai mic de 19.99, n ordinea descresctoare a preurilor.
SELECT RETAIL_PRICE_DVD, MOVIE_TITLE
FROM MOVIE WHERE RETAIL_PRICE_DVD < 19.99
ORDER BY RETAIL_PRICE_DVD DESC;
Operatori conjunctivi
Uneori 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 vedere
logic 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 naintea
operatorilor 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 <= 19.99 ORDER BY RETAIL_PRICE_DVD;
Operatori logici
Operatorii logici folosesc cuvinte cheie n locul simbolurilor la formarea expresiilor de
comparare. Operatorii logici disponibili n majoritatea implementrilor SQL sunt prezentai n
seciunile care urmeaz. La oricare dintre aceti operatori poate fi adugat cuvntul cheie NOT,
pentru a inversa valoarea logic a comparaiei.
IS NULL
Operatorul IS NULL este folosit pentru a determina dac o valoare este nul. Este
important s reinei c valorile nule din baza de date nu sunt egale cu nimic altceva, nici chiar cu
alte valori nule. Din aceast cauz, o condiie precum "= NULL" este ntotdeauna incorect.
Niciodat nimic nu este egal cu o valoare nul.
Exemplu:
- Gsii toate conturile de clieni active, adic toate conturile pentru care coloana
DATE_TERMINATED conine o valoare nul:
SELECT CUSTOMER_ACCOUNT_ID FROM CUSTOMER_ACCOUNT
WHERE DATE TERMINATED IS NULL;
- Gsii toate conturile de clieni inactive, adic toate conturile pentru care coloana
DATE_TERMINATED conine o alt valoare dect NULL:
SELECT CUSTOMER_ACCOUNT_ID FROM CUSTOMER_ACCOUNT
WHERE DATE_TERMINATED IS NOT NULL;
BETWEEN
Operatorul BETWEEN este folosit pentru a determina dac o valoare se ncadreaz ntr-un
interval specificat. Intervalul este specificat folosind o valoare minim i o valoare maxim, fiind
un interval inclusiv, ceea ce nseamn c include i valorile specificate. Aceasta este o
prescurtare elegant, uor de citit i de neles, pentru specificare unei condiii de interval. De
exemplu, condiia WHERE MOVIE_ID BETWEEN 7 AND 9" este aceeai cu condiia
WHERE MOVIE_ID >= 7 AND MOVIE_ID <= 9.
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 dup
pre. Observai c n setul de rezultate sunt incluse si filmele pentru care preul
este exact 14.99 sau 19.99.
SELECT MOVIE_TITLE, RETAIL_PRICE_DVD
FROM MOVIE WHERE RETAIL_PRICE_DVD BETWEEN 14.99 AND 19.99
ORDER BY RETAIL PRICE DVD;
LIKE
Operatorul 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 nlocuire:
- Liniua de subliniere (_). Caracterul liniua de subliniere poate fi folosit drept
caracter de nlocuire poziional, ceea ce nseamn c se potrivete cu orice
caracter aflat pe poziia respectiv n irul de caractere evaluat.
- Procent (%). Simbolul procent (%) poate fi folosit drept caracter de nlocuire
nepoziional, ceea ce nseamn c se potrivete cu orice numr de caractere, indiferent de
lungime.
Exemplu de utilizare a operatorului LIKE:
SELECT 'David!' LIKE 'David_'; // returneaz valoarea 1
SELECT 'David!' LIKE 'David\_'; // returneaz valoarea 0
- Afiai toate titlurile de filme care conin irul de caractere on":
SELECT MOVIE_TITLE FROM MOVIE WHERE MOVIE_TITLE LIKE '%on%' ;
sau
SELECT 'David!' LIKE '%D%v%'; // returneaz valoarea 1
IN
Operatorul IN este folosit pentru a determina dac o valoare face parte dintr-o list de
valori. Lista poate fi specificat ca valori literale, folosind o list de valori separate prin virgule
i ncadrat ntre paranteze, sau poate fi selectat din baza de date folosind o subselecie (o
subinterogare), care este o interogare n cadrul unei alte interogri.
Exemplu:
- Afiai toate filmele pentru care MOVIE_GENRE_CODE este Drama, Forgn sau Rmce.
Evident, aceast interogare ar putea fi scris folosind trei condiii de egalitate, separate prin
operatorul logic OR, dar este mult mai simplu s o scriem cu ajutorul operatorului IN:
SELECT MOVIE_GENRE_CODE AS GENRE, MOVIE_TITLE FROM MOVIE
WHERE MOVIE_GENRE_CODE IN ('Drama','Forgn',' Rmce')
ORDER BY MOVIE_GENRE_CODE, MOVIE_TITLE;
EXISTS
Operatorul EXISTS este folosit pentru a determina dac o subinterogare conine
nregistrri. Dac n setul de rezultate al subinterogrii nu exist, operatorul returneaz valoarea
logic false"; dac setul de rezultate conine cel puin un rnd, valoarea logic devine
adevrat".
Exemplu:
Proprietarul magazinului a auzit c filmul The Last Samurai se nchiriaz bine att n
format DVD, ct i-n format VHS i vrea s se asigure c n inventarul magazinului exist o
copie VHS. Tabelul MOVIE_COPY conine un rnd pentru fiecare copie a unui film din
inventarul magazinului, aa c putei folosi o subinterogare pentru a afla dac exist copii VHS
ale filmului n inventar.
De cele mai multe ori, operatorul EXISTS este folosit n conjuncie cu o form mai
complex de subinterogare, numit subinterogare corelat (correlated subquery), n care
valorile datelor din interogarea extern (MOVIE_ID, n acest caz) sunt comparate cu rndurile
din interogarea intern. Este suficient s tii c subinterogarea va returna un rnd dac exist o
30
copie VHS n stoc i nu va returna nici un rnd dac nu exist o astfel de copie. Aceeai
interogare ar putea fi scris i folosind operatorul IN sau folosind o uniune, care leag rndurile
din dou tabele.
SELECT m.MOVIE_ID, m.MOVIE_TITLE FROM MOVIE m
WHERE m.MOVIE_TITLE = 'The Last Samurai' AND EXISTS
(SELECT c.MOVIE_ID FROM MOVIE_COPY c WHERE m.MOVIE_ID =
c.MOVIE_ID)
Operatori aritmetici
n SQL, operatorii aritmetici sunt folosii pentru efectuarea calculelor matematice - la fel
ca i-n formulele dintr-o foaie de calcul tabelar sau ntr-un limbaj de programare, precum Java
sau C. Cei patru operatori aritmetici din SQL sunt:
Operator Descriere
+ adunare
- scdere
* nmulire
/ mprire

Funcii SQL elementare
O funcie este un tip special de program, care returneaz o singur valoare de fiecare dat
cnd este apelat. Termenul provine de la conceptul matematic al unei funcii. n SQL, funciile
necesit ntotdeauna specificarea unei expresii, care deseori include numele unei coloane. Cel
mai des, funciile sunt folosite n lista de coloane a unei instruciuni SELECT. Sunt apelate
pentru fiecare rnd prelucrat de interogare i, ca urmare, returneaz o singur valoare pentru
fiecare rnd din setul de rezultate.
Funcii pentru caractere
Funciile pentru caractere sunt numite astfel deoarece manipuleaz date de tip text.
Concatenarea irurilor de caractere
Funcia de concatenare a irurilor de caractere reunete mai multe iruri de caractere
pentru a forma o singur valoare n rezultatele interogrii. Funcia standard de concatenare a
irurilor de caractere din SQL este apelat cu dou bare verticale (||), dar exist i excepii, cum
ar fi Microsoft SQL Server, care folosete semnul plus (+) pentru concatenarea irurilor de
caractere.
UPPER
Funcia UPPER transform literele dintr-un ir de caractere n litere mari. Numerele i
caracterele speciale sunt lsate ca atare.
Exemplu:
- Afiai comediile (MOVIE_GENRE_CODE = 'Comdy') scriind titlurile cu
majuscule. Remarcai c am folosit un pseudonim pentru a ne asigura c numele
coloanei MOVIE_TITLE apare n setul de rezultate.
SELECT UPPER(MOVIE_TITLE) AS MOVIE_TITLE FROM MOVIE
WHERE MOVIE GENRE CODE ='Comdy';
Observaie: La folosirea funciilor SQL n condiiile WHERE, n cele mai multe situaii,
pentru o coloan creia i este aplicat o funcie nu poate fi folosit indexarea. Ca urmare, n
cazul tabelelor mari, utilizarea funciilor n condiiile WHERE poate duce la probleme de
performan cu adevrat memorabile. n concluzie, trebuie s specificai ntotdeauna clauza
ORDER BY dac ordinea n care apar rezultatele este important.
LOWER
Funcia LOWER este inversa funciei UPPER - transform literele dintr-un ir de caractere
n litere mici.
Exemplu de utilizare a funciei LOWER:
- Afiai comediile (MOVIE_GENRE_CODE = 'Comdy) scriind titlurile cu minuscule.
Remarcai c am folosit un pseudonim pentru a ne asigura c numele coloanei
31
MOVIE_TITLE apare n setul de rezultate.
SELECT LOWER(MOVIE_TITLE) AS MOVIE_TITLE FROM MOVIE
WHERE MOVIE GENRE CODE ='Comdy';
SUBSTR
Funcia SUBSTR apare n majoritatea implementrilor SQL, dar uneori are un nume puin
diferit. De exemplu, funcia se numete SUBSTRING n Microsoft SQL Server, Sybase
Adaptive Server i MySQL, dar SUBSTR n Oracle i DB2, Funcia returneaz o poriune a
irului de caractere, n funcie de parametrii furnizai, care specific numele coloanei, poziia de
nceput a subirului n datele coloanei i lungimea subirului returnat (numrul de caractere).
Dei este o utilizare mai puin obinuit, funcia SUBSTR accept i un ir de caractere literal n
locul numelui unei coloane. Iat forma generala a funciei, urmat de un exemplu:
SUBSTR (numele_coloanei, poziia_ de_ nceput, lungimea_subirului)
- n tabelul PERSON, unele persoane au al doilea nume n ntregime, alii au numai iniiala.
Afiai numele complet al persoanelor al cror nume de familie ncepe cu litera B", sub
forma unui singur ir de caractere care conine prenumele, iniiala i numele de familie.
SELECT PERSON_GIVEN_NAME as SUBSTRING(PERSON_MIDDLE_NAME,1,1)
AS INITIALA,' ', PERSON_FAMILY_NAME AS NUME
FROM PERSON WHERE SUBSTRING(PERSON_FAMILY_NAME,1,1)='B'
LENGTH
Funcia LENGTH returneaz lungimea unui ir de caractere. Reinei c implementrile
Microsoft SQL Server i Sybase Adaptive Server folosesc numele LEN pentru versiunea proprie
a acestei funcii.
Exemple:
- Afiai lungimea titlului pentru filmul a crui valoare MOVIE_ID este 1.
Presupunem c folosii o baz de date Oracle, DB2 sau MySQL.
SELECT MOVIE_TITLE, LENGTH(MOVIE_TITLE) AS LENGTH FROM MOVIE
WHERE MOVIE_ID = 1;
- Afiai lungimea titlului pentru filmul a crui valoare MOVIE_ID este 1.
Presupunem c folosii o baza de date Microsoft SQL Server.
SELECT MOVIE_TITLE, LEN(MOVIE_TITLE) AS LENGTH FROM MOVIE WHERE
LEN(MOVIE_TITLE)<10;

Funcii matematice
Funciile matematice manipuleaz valori numerice, n conformitate cu regulile
matematicii.
Funcia ROUND este prezentat n detaliu, inclusiv cu un exemplu, apoi urmeaz un tabel
cu funciile matematice existente n majoritatea implementrilor SQL.
ROUND
Funcia ROUND rotunjete o valoare la un numr specificat de zecimale. Valoarea
numeric este furnizat prin primul parametru, iar numrul de zecimale prin cei de-al doilea. n
continuare este prezentat formatul general al funciei ROUND, urmat de un exemplu.
ROUND (expresie_numeric, nr_de_poziii_zecimale)
- Care este costul mediu al unei copii a filmului The Last Samurai, rotunjit la dou zecimale?
SELECT ROUND((RETAIL_PRICE_VHS + RETAIL_PRICE_DVD) / 2, 2) AS
AVG_COST FROM MOVIE WHERE MOVIE_TITLE = 'The Last Samurai';
Tabelul care urmeaz prezint funciile matematice cel mai des ntlnite. Pentru toate,
sintaxa general este aceeai:
NUME_FUNCIE (expresie)
Funcie Descriere
ABS Valoarea absolut a unui numr dat
COS Cosinusul trigonometric al unui unghi specificat n radiani
EXP

Valoarea exponenial a unui numr dat
32
Funcie Descriere
POWER Ridic un numr la o putere (numrul i puterea sunt furnizate ca parametri)
SIN Sinusul trigonometric al unui unghi specificat n radiani
TAN Tangenta trigonometric a unui unghi specificat n radiani

Funcii de conversie
Funciile de conversie transform date dintr-un tip de date n altul.
CAST
Funcia CAST transform date dintr-un tip de date n altul. Reinei c aceast funcie nu
este implementat de DB2.
CAST (expresie AS tip de date)
- Afiai preul pentru formatul DVD al filmului The Last Samurai, cu un simbol dolar n faa
sumei. Valoarea numeric trebuie s fie convertit ntr-un ir de caractere pentru a putea fi
concatenat cu o valoare literal coninnd simbolul dolar.
SELECT CONCAT('$: ', CAST(RETAIL_PRICE_DVD AS char(6))) as Price
FROM MOVIE WHERE MOVIE_TITLE = 'The Last Samurai'
sau
SELECT NOW();
SELECT concat('Data: ', CAST(NOW() AS DATE));

Funcii de agregare i gruparea rndurilor
O funcie de agregare este o funcie care combin mai multe rnduri de date ntr-un singur
rnd. Tabelul urmtor prezint funciile de agregare acceptate n majoritatea implementrilor
SQL:
Funcie Descriere
AVG Calculeaz valoarea medie pentru o coloan sau o expresie.
COUNT Numr valorile dintr-o coloan. Putei folosi cuvntul cheie distinct pentru a numra
valorile unice, n locul tuturor valorilor (rndurilor) dintr-o coloan.
MAX Gsete valoarea maxim dintr-o coloan.
MIN Gsete valoarea minim dintr-o coloan.
SUM nsumeaz valorile dintr-o coloan.
Exemple:
- Care este preul mediu al unui DVD? Observai c funciile ROUND i AVG sunt imbricate,
astfel nct s obinei rezultatul n dolari i ceni.
SELECT ROUND(AVG(RETAIL_PRICE_DVD),2) AS AVG_PRICE FROM MOVIE;
- Cte filme exist n tabelul MOVIE?
SELECT COUNT(*) AS NUM_MOVIES FROM MOVIE;
- Cte genuri diferite de filme sunt reprezentate n tabelul MOVIE? Observai
folosirea cuvntului cheie DISTINCT, astfel nct sistemul DBMS s numere
numai valorile MOVIE_GENRE_CODE unice.
SELECT COUNT(DISTINCT(MOVIE_GENRE_CODE)) AS NUM_GENRES FROM
MOVIE;

Clauza GROUP BY
Aa cum ai observat, dac folosii o funcie de agregare, ca atare, ntr-o interogare,
obinei ca rezultat un singur rnd din ntreaga interogare. Este logic, deoarece sistemul RDBMS
nu tie ce alte rezultate ai dori s obinei, dect dac-i spunei acest lucru - i tocmai acesta este
scopul clauzei GROUP BY. Aceasta cere sistemului DBMS s grupeze rndurile selectate de
interogare pe baza valorilor din una sau mai multe coloane i s aplice funcia (sau funciile) de
agregare fiecrui grup, returnnd un rnd pentru fiecare grup din setul de rezultate. Este ca i
cum ai cere subtotaluri pentru fiecare departament, n locul unui singur total pentru ntreaga
33
companie, dar, aa cum ai vzut, funciile de agregare pot face multe alte lucruri, nu numai
nsumarea unor valori. Sistemul DBMS va ordona rndurile selectate de interogare dup
coloanele din clauza GROUP BY, aa c grupurile vor fi returnate n ordine ascendent,
exceptnd cazul n care adugai o clauz ORDER BY care specific un alt mod de ordonare.
Exemplu:
- Afiai fiecare cod de gen, mpreun cu numrul de filme asociate fiecrui cod.
SELECT MOVIE_GENRE_CODE AS GENRE, COUNT(*) AS COUNT FROM MOVIE
GROUP BY MOVIE_GENRE_CODE;

Operatori pentru interogri compuse
Uneori este util s rulm interogri multiple i s combinm rezultatele ntr-un singur set
de rezultate.
UNION
Operatorul UNION adaug rndurile din setul de nregistrri al unei interogri la cel al
unei alte nregistrri i, n acelai timp, elimin rndurile duplicate, ntr-un mod similar cu cel al
cuvntului cheie DISTINCT. Operaia este permis numai dac interogrile sunt compatibile din
punctul de vedere al uniunii, ceea ce nseamn c au acelai numr de coloane i c tipurile de
date ale coloanelor corespondente sunt compatibile.
Exemplu:
- Afiai pe o singur coloan toate valorile nenule pentru taxa de nchiriere i taxa de ntrziere
din tabelul MOVIE_RENTAL
SELECT RENTAL_FEE AS FEE FROM MOVIE RENTAL
WHERE RENTAL_FEE IS NOT NULL UNION
SELECT LATE_OR_LOSS FEE AS FEE1 FROM MOVIE_RENTAL
WHERE LATE_OR_LOSS_FEE IS NOT NULL;
UNION ALL
UNION ALL funcioneaz la fel ca i operatorul UNION, exceptnd faptul c rndurile
duplicate nu sunt eliminate.
INTERSECT
Operatorul INTERSECT gsete valorile selectate dintr-o interogare, care apar i ntr-o alt
interogare. n esen, gsete intersecia valorilor din cele dou interogri. Totui, doar un numr
mic de sisteme DBMS (cele mai importante fiind Oracle i DB2) implementeaz acest operator.
Nu este implementat n Microsoft SQL Server sau MySQL.
EXCEPT
EXCEPT este operatorul standard ANSI/ISO care gsete diferenele dintre dou seturi de
rezultate, returnnd, n esen, valorile din prima interogare care nu apar n cea de-a doua
interogare. Foarte puine sisteme DBMS implementeaz acest operator. n unele implementri,
precum Oracle, operatorul se numete MINUS, nu EXCEPT.


1.3.3. Interogri din tabele multiple

Uniuni (join)
O uniune (join) este o operaie ntr-o baz de date relaional care combin coloane din
dou sau mai multe tabele n rezultatele unei singure interogri. O uniune apare de fiecare dat
cnd clauza FROM a unei instruciuni SELECT specific numele mai multor tabele.
Uniuni de egalitate (equijoin)
Avem o uniune de egalitate (equijoin), numit i uniune intern (innerjoin), atunci cnd
legm una sau mai multe coloane dintr-un tabel (de obicei, o cheie extern) cu coloane similare
dintr-un alt tabel (de obicei, cheia primar), folosind condiia de egalitate (cu alte cuvinte,
considerm c acele coloane se potrivesc dac valorile datelor sunt egale).
Aceasta este cea mai des folosit form de uniune. Totui, termenul uniune de egalitate
34
(equijoin) este rareori folosit n afara mediilor academice, fiind preferate denumirile uniune
intern (innerjoin) sau uniune standard (standard join).
Exist dou modaliti de specificare a coloanelor corespondente: folosind clauza WHERE
sau folosind clauza JOIN. Clauza JOIN a fost adugat relativ recent n standardul SQL, aa c
programatorii mai vechi sunt obinuii cu metoda bazat pe clauza WHERE.
Realizarea uniunilor folosind clauza WHERE
Folosirea clauzei WHERE pentru unirea tabelelor seamn cu folosirea acesteia pentru
eliminarea rndurilor de care nu avei nevoie din setul de rezultate. Totui, exist unele diferene.
n primul rnd, n condiia WHERE comparai o coloan cu o alt coloan, nu o coloan cu o
constant sau o expresie. n al doilea rnd, atunci cnd coloanele din cele dou tabele au acelai
nume (o soluie recomandat) trebuie s specificai numele complet al coloanelor (adic numele
cu calificator), astfel nct motorul SQL s tie care dintre cele dou coloane este referit. Cea
mai simpl form de calificator este chiar numele tabelului, separat cu un caracter punct de
numele coloanei.
n continuare este prezentat un exemplu de uniune realizat prin clauza WHERE, cu
numele coloanelor specificate complet, folosind numele tabelelor. Observai c interogarea
selecteaz coloanele MOVIE_ID i MOVIE_TITLE din tabelul MOVIE i genul corespunztor
(MOVIE_GENRE_DESCRIPTION) din tabelul MOVIE_GENRE.
SELECT MOVIE_ID, MOVIE_GENRE_DESCRIPTION AS GENRE, MOVIE_TITLE
FROM MOVIE, MOVIE_GENRE
WHERE MOVIE.MOVIE_GENRE_CODE=MOVIE_GENRE.MOVIE_GENRE_CODE
ORDER BY MOVIE_ID;
Observaie: Folosirea numelor complete ale tabelelor pentru specificarea coloanelor poate
fi obositoare i consumatoare de timp, mai ales deoarece numele tabelelor pot avea 30 sau mai
multe caractere n sistemele DBMS moderne. Din aceasta cauz, n SQL este permis folosirea
pseudonimelor (aliases) pentru numele tabelelor.
Exemplul urmtor prezint instruciunea anterioar, dup adugarea pseudonimelor pentru
numele tabelelor. Dei nu era necesar, pseudonimele au fost adugate i n lista de coloane din
clauzele SELECT i ORDER BY, pentru a v arta cum sunt folosite.
SELECT A.MOVIE_ID, B.MOVIE_GENRE_DESCRIPTION AS GENRE, A.MOVIE_TITLE
FROM MOVIE A, MOVIE_GENRE B
WHERE A.MOVIE_GENRE_CODE=B.MOVIE_GENRE_CODE
ORDER BY A.MOVIE_ID;
Realizarea uniunilor folosind clauza JOIN
Clauza JOIN este scris ca o referin de tabel n clauza FROM i, n esen, combin lista
de tabele din clauza FROM i condiia de legtur scris anterior n clauza WHERE ntr-o
singur clauz.
Sintaxa general a clauzei JOIN pentru o uniune intern:
nume_tabel [INNER] JOIN nume tabel { ON condiie | USING (nume_coloan
[,nume_coloan]) }
Observai cele dou opiuni. Clauza ON permite specificarea unei condiii similare cu cea
din clauza WHERE folosit n exemplul anterior. Clauza USING, pe de alt parte, specific
numele coloanelor folosite pentru legarea rndurilor. Totui, clauza USING funcioneaz numai
atunci cnd coloanele pe care se face legtura au nume identice n ambele tabele. Iat cteva
exemple:
- JOIN cu condiie ON:
SELECT MOVIE_ID, MOVIE_GENRE_DESCRIPTION AS GENRE, MOVIE_TITLE
FROM MOVIE JOIN MOVIE_GENRE ON
MOVIE.MOVIE_GENRE_CODE = MOVIE GENRE.MOVIE_GENRE_CODE
ORDER BY MOVIE_ID;
- JOIN folosind cuvntul cheie USING (n locul condiiei ON) - o scurttur
elegant atunci cnd coloanele din cele dou tabele au acelai nume.
35
SELECT MOVIE_ID, MOVIE_GENRE_DESCRIPTION AS GENRE, MOVIE_TITLE
FROM MOVIE JOIN MOVIE_GENRE USING (MOVIE_GENRE_CODE)
ORDER BY MOVIE_ID;
- JOIN cu cheie extern pe mai multe coloane. Aceasta interogare afieaz lista cu copiile
filmelor din tabelul MOVIE_COPY cave nu au fost vndute (coloana DATE_SOLD conine o
valoare nul) i care au fost nchiriate (uniune cu tabelul MOVIE_RENTAL) dar nu au fost
nc returnate (coloana RETURNED_DATE conine o valoare nul).
SELECT MOVIE_ID, COPY_ NUMBER, DUE_DATE
FROM MOVIE_COPY JOIN MOVIE_RENTAL USING (MOVIE_ID, COPY_NUMBER)
WHERE DATE_SOLD IS NULL AND RETURNED_DATE IS NULL;

Uniuni naturale
O uniune natural (natural join) se bazeaz pe toate coloanele cu acelai nume din dou
tabele. n esen, toate uniunile de egalitate pe care le-ai vzut deja sunt uniuni naturale. Totui,
sintaxa unei uniuni naturale este mult mai simpl, deoarece nu este necesar s specificai o
condiie sau o list de coloane - se nelege de la sine care sunt coloanele folosite.
Exemplu: uniunea tabelelor MOVIE i MOVIE_GENRE, rescris sub forma unei uniuni
naturale:
SELECT MOVIE_ID, MOVIE_GENRE_DESCRIPTION AS GENRE, MOVIE_TITLE
FROM MOVIE NATURAL JOIN MOVIE_GENRE
ORDER BY MOVIE_ID;

Uniuni externe (outer joins)
O uniune extern (outer join) - pentru care un nume mai potrivit ar fi uniune inclusiv -
include n setul de rezultate i rndurile pentru care nu exist legturi din cel puin unul dintre
tabele. Atunci cnd exist rnduri fr legturi, datele selectate din tabelul n care nu a fost gsit
o legtur primesc valoarea nul. Exist trei tipuri de baz:
- Uniune extern ctre stnga (left outer join). Returneaz toate rndurile din tabelul din
stnga (cel specificat primul n clauza JOIN), mpreun cu toate rndurile din tabelul din
dreapta pentru care poate fi gsit o legtur.
- Uniune extern ctre dreapta (right outer join). Returneaz toate rndurile din tabelul din
dreapta (cel specificat al doilea n clauza JOIN), mpreun cu toate rndurile din tabelul din
stnga pentru care poate fi gsit o legtur. n esen, o uniune extern ctre stnga poate fi
rescris ca o uniune extern ctre dreapta inversnd ordinea de specificare a tabelelor i
nlocuind cuvntul cheie LEFT cu RIGHT.
- Uniune extern complet (full outer join). Returneaz toate rndurile din ambele tabele.
Acest tip de uniune este cel mai puin probabil s fie acceptat de implementarea SQL pe care
o avei, deoarece sintaxa ei standard este mai nou dect a celorlalte dou. Este esenial s
nelegei c aceast uniune nu este acelai lucru cu un produs cartezian, care leag fiecare
rnd dintr-un tabel cu fiecare rnd din cellalt tabel. O uniune extern complet (full outer
join) leag fiecare rnd dintr-un tabel cu zero sau mai multe rnduri corespondente din
cellalt tabel. n realitate, nu vei ntlni prea multe situaii n care s folosii o uniune extern
complet, dar aceasta poate fi util dac ntre dou tabele avei o relaie opional n ambele
direcii.
Sintaxa general pentru o uniune extern este:
nume_tabel {RIGHT | LEFT | FULL} [OUTER] JOIN nume_tabel
{ON conditie | USING (nume_coloana [, nume_coloana ] ) }
Exemplu de uniuni externe:
- Afiai toate descrierile genurilor de filme, mpreun cu filmele asociate fiecrui gen.
Observai n setul de rezultate rndurile care nu au nici o valoare n coloana MOVIE_TITLE -
acestea sunt genurile de filme care nu au filme asociate. Dac implementarea DBMS nu
accept uniuni realizate cu cuvntul cheie USING, modificai instruciunea astfel nct s
36
utilizeze cuvntul cheie ON.
SELECT MOVIE_GENRE_DESCRIPTION AS GENRE, MOVIE_TITLE FROM
MOVIE_GENRE LEFT OUTER JOIN MOVIE USING (MOVIE_GENRE_CODE);
Auto-uniuni (self joins)
O auto-uniune (self join) este o uniune a unui tabel cu el nsui. Acest tip de uniune poate
prea ciudat la prima vedere, dar uneori exist relaii n care cheia primar i cheia extern se
afl n acelai tabel. Acestea se numesc relaii recursive i exist o asemenea relaie i n baza de
date a magazinului de produse video.
Exemplu:
Tabelul EMPLOYEE are o coloan numit SUPERVISOR_PERSON_ID, care este o cheie
extern ctre coloana PERSON_ID din acelai tabel. Este folosit pentru a lega fiecare angajat
de eful direct, care, desigur, este un alt angajat, ceea ce nseamn c i eful respectiv are o
coloan n tabelul EMPLOYEE. Interogarea urmtoare afieaz trei coloane din tabelul
EMPLOYEE, inclusiv PERSON_ID i SUPERVISOR_PERSON_ID:
SELECT PERSON_ID, EMPLOYEE_HOURLY_RATE AS HOURLY_RATE,
SUPERVISOR_PERSON_ID FROM EMPLOYEE;
Acum s presupunem c magazinul trebuie s produc un raport cu diferenele de salariu
dintre efi i subordonai. Putei lega nregistrarea fiecrui angajat de cea a efului direct, astfel
nct s obinei plata pe or a efului. Iat interogarea care face acest lucru:
SELECT A.PERSON_ID, A.EMPLOYEE_HOURLY_RATE AS HOURLY_RATE,
B.EMPLOYEE_HOURLY_RATE AS SUPV_HOURLY_RATE
FROM EMPLOYEE A JOIN EMPLOYEE B
ON A.SUPERVISOR_PERSON_ID = B.PERSON_ID;
Iat i interogarea final, care include calcularea diferenei de salariu i realizeaz o uniune
cu tabelul PERSON pentru a obine numele angajailor;
SELECT A.PERSON_ID, C.PERSQN_GIVEN_NAME AS FIRST_NAME,
C.PERSON_FAMILY_NAME AS LAST_NAME,
B.EMPLOYEE_HOURLY_RATE - A.EMPLOYEE_HOURLY_RATE AS
RATE_DIFF
FROM EMPLOYEE A JOIN EMPLOYEE B
ON A.SUPERVISOR_PERSON_ID = B.PERSON_ID
JOIN PERSON C ON A.PERSON_ID = C.PERSON_ID;
Uniuni ncruciate (cross joins)
O uniune ncruciat (cross join) nu este altceva dect sintaxa standard pentru un produs
cartezian. Interogarea care unea tabelele MOVIE i MOVIE_GENRE i obinea un produs
cartezian poate fi rescris ca mai jos, folosind o uniune ncruciat:
SELECT MOVIE_ID, MOVIE_GENRE_DESCRIPTION AS GENRE, MOVIE_TITLE
FROM MOVIE CROSS JOIN MOVIE_GENRE ORDER BY MOVIE_ID;
Subinterogri
O caracteristic foarte puternic a limbajului SQL sunt subinterogrile (numite i
subselecii), care, aa cum sugereaz i numele, se refer la o instruciune SELECT care conine
o instruciune SELECT subordonat. De obicei, subinterogrile sunt folosite n clauza WHERE,
ca modalitate de limitare a rndurilor returnate n setul de rezultate al interogrii externe. Aceasta
poate fi o modalitate foarte flexibil de selectare a datelor.
O regul esenial de sintax este ca subinterogarea s fie ncadrat de paranteze. O alt
idee important pe care trebuie s o nelegei este c orice operaie efectuat cu o subinterogare
poate fi fcut i printr-o uniune.
Subinterogri necorelate
O subinterogare necorelat este o subinterogare n care interogarea intern nu face nici o
referire la interogarea extern care o conine. Aceasta nseamn c poate fi rulat mai nti
interogarea intern, apoi setul de rezultate obinut poate fi folosit n interogarea extern.
Exemplu:
37
- Afiai toate limbile n care nu exist nici un film n inventarul magazinului de produse video.
SELECT LANGUAGE_CODE, LANGUAGE_NAME
FROM LANGUAGE WHERE LANGUAGE_CODE NOT IN
(SELECT DISTINCT LANGUAGE_CODE FROM MOVIE_LANGUAGE)
ORDER BY LANGUAGE_CODE;
Subinterogri corelate
O subinterogare corelat este o subinterogare n care interogarea intern refer valorile
furnizate de interogarea extern. Aceste subinterogri sunt mult mai puin eficiente dect
subinterogrile necorelate, deoarece interogarea intern trebuie s fie apelat pentru fiecare rnd
gsit de interogarea extern.
Exemplu:
- Proprietarul magazinului vrea s transmit prin pot un cupon valoric tuturor clienilor care
au pltit mai mult de 15$ pentru o singur tranzacie de nchiriere.
SELECT DISTINCT CUSTOMER_ACCOUNT_ID
FROM CUSTOMER_TRANSACTION A
WHERE 15 < (SELECT SUM(RENTAL_FEE) FROM MOVIE_RENTAL B
WHERE A.TRANSACTION_ID = B.TRANSACTION_ID);
Vizualizri n linie
Foarte puine implementri, printre care Oracle, permit folosirea unei subinterogri n
clauza FROM a unei interogri, ntr-o construcie numit vizualizare n linie, n esen, aceast
construcie permite ca setul de rezultate al unei interogri s fie tratat ca i cum ar fi un tabel sau
o vizualizare predefinit.
Exemplu:
- Aceast interogare afl numrul maxim de nchirieri ale unui singur film:
SELECT MAX(RENTAL_COUNT) AS MAX_RENTAL_COUNT FROM
(SELECT MOVIE_ID, COUNT(*) AS RENTAL_COUNT
FROM MOVIE_RENTAL GROUP BY MOVIE_ID);


1.3.4. Funcii SQL avansate

Funcii pentru caractere
Funciile pentru caractere opereaz asupra datelor de tip text.
REPLACE
Funcia REPLACE caut un ir de caractere i nlocuiete caracterele gsite cu caracterele
din irul de nlocuire. Iat sintaxa general a funciei;
REPLACE (ir de_caractere, ir_cutat, ir_de_nlocuire)
ir_de caractere reprezint irul de caractere n care se face cutare i, n cele mai multe
cazuri, este numele unei coloane dintr-un tabel, dar poate fi orice expresie care are ca rezultat
un ir de caractere.
ir_cutat este un ir format dintr-un caracter sau mai multe, care trebuie cutate n ir_de
caractere.
ir_de nlocuire este irul de caractere cu care se nlocuiete orice apariie a irului_cutat n
ir_de_caractere.
Exemplu care nlocuiete toate liniuele de desprire, din numrul de telefon al unei
persoane cu puncte:
SELECT PERSON_PHONE,
REPLACE(PERSON PHONE,'-','.') AS DISPLAY PHONE FROM PERSON;
LTRIM
Funcia LTRIM elimin spaiile de la nceputul unui ir de caractere. Reinei c sunt
eliminate numai spaiile de la nceputul irului - cele din mijlocul i de la sfritul irului sunt
lsate ca atare.
38
Exemplu general:
LTRIM(' String with spaces ')
Returneaz acest ir: 'String with spaces '
RTRIM
Funcia RTRIM este similar cu LTRIM, dar elimin spaiile de la sfritul unui ir de
caractere.
Funcii pentru valori nule (NVL, ISNULL, IFNULL)
Oracle, Microsoft SQL Server i MySQL pun la dispoziie o funcie care nlocuiete
valorile nule cu o valoare specificat. Din nefericire, fiecare implementare folosete propriul
nume pentru aceast funcie: NVL n Oracle, ISNULL n SQL Server i IFNULL n MySQL. Se
pare c n DB2 nu exist o funcie echivalent.
Exemplu:
SELECT IFNULL(LATE_OR_LOSS_FEE, 0) AS LATE_OR_LOSS_FEE FROM
MOVIE_RENTAL WHERE TRANSACTION ID=9;

ASCII
Funcia ASCII returneaz valoarea din setul de caractere ASCII (un numr ntre 0 i 255)
pentru un ir format dintr-un singur caracter. De exemplu, codul ASCII pentru spaiu este 32, aa
c ASCII(' ') returneaz valoarea 32.

CHAR (CHR)
Funcia CHAR (numit CHR n Oracle i DB2) returneaz caracterul corespunztor unei
valori ASCII (un numr ntre 0 i 255). De exemplu, funcia ASCII(44) returneaz o virgul,
deoarece codul ASCII pentru virgul este 44. Aceast funcie este util n special pentru
concatenarea caracterelor care nu pot fi afiate sau sunt greu de manipulat n SQL. Cteva dintre
caracterele ASCII folosite frecvent cu aceast funcie sunt prezentate n tabelul urmtor. Putei
folosi funcia ASCII sau un tabel cu setul de caractere ASCII (uor de gsit n Internet) dac vrei
s aflai si alte valori.
Valoare ASCII Caracter
9 Tab
10 Linie nou
13 Retur de car (CR)
39 Apostrof
Funcii matematice
Funciile matematice returneaz rezultatul unei operaii matematice i, de obicei, accept
ca parametru de intrare o expresie numeric, care poate fi o valoare literal, o valoare numeric
dintr-o coloan a unui tabel sau orice expresie (inclusiv rezultatul unei alte funcii) care produce
o valoarea numeric.
SIGN
Funcia SIGN primete ca argument o expresie numeric i returneaz una dintre
urmtoarele valori, n funcie de semnul numrului de intrare.
Valoare returnat Semnificaie
-1 nr de intrare este negativ
0 nr de intrare este zero
1 nr de intrare este pozitiv
null valoarea de intrare este nul
Exemplu:
SELECT LATE_OR_LOSS_FEE, SIGN(LATE_OR_LOSS_FEE) AS FEE_SIGN FROM
MOVIE_RENTAL WHERE LATE_OR_LOSS_FEE IS NOT NULL;
SQRT
Funcia SQRT primete ca argument o expresie numeric i returneaz rdcina ptrat a
39
acesteia. Sintaxa general a funciei este:
SQRT (expresie_numeric)
Exemplu:
SELECT LATE_OR_LOSS_FEE, SQRT(LATE_OR_LOSS_FEE) AS FEE_SQRT FROM
MOVIE_RENTAL WHERE LATE_OR_LOSS_FEE IS NOT NULL;
CEILING (CEIL)
Funcia CEILING returneaz cel mai mic ntreg mai mare sau egal cu valoarea expresiei
numerice furnizat ca parametru de intrare. Cu alte cuvinte, rotunjete numrul prin adugire
pn la urmtorul numr ntreg. Exist cteva probleme interesante de compatibilitate legate de
denumire ntre implementrile SQL: Microsoft SQL Server folosete numele CEILING, Oracle
folosete numele CEIL, n timp ce DB2 i MySQL permite folosirea ambelor nume (CEIL i
CEILING).
Exemplu:
SELECT LATE_OR_LOSS_FEE, CEILING(LATE_OR_LOSS_FEE) AS FEE_CEILING
FROM MOVIE_RENTAL WHERE LATE_OR_LOSS_FEE IS NOT NULL;
FLOOR
Funcia FLOOR este inversa logic a funciei CEILING - returneaz cel mai mare ntreg
mai mic sau egal cu valoarea expresiei numerice furnizat ca parametru de intrare. Cu alte
cuvinte, rotunjete numrul prin scdere pn la urmtorul numr ntreg.
Exemplu:
SELECT LATE_OR_LOSS_FEE, FLOOR(LATE_OR_LOSS_FEE) AS FEE_FLOOR
FROM MOVIE_RENTAL WHERE LATE_OR_LOSS_FEE IS NOT NULL;


1.3.5. Folosirea avantajelor oferite de vizualizri

O vizualizare (view) este o interogare stocat n baza de date, care pune la dispoziia
utilizatorului bazei de date un subset particularizat de date din unul sau mai multe tabele ale
bazei de date. Frumuseea vizualizrilor const n faptul c dup ce sunt create, pot fi interogate
ca i cum ar fi tabele reale. De fapt, nu este nevoie ca utilizatorul s tie dac folosete o
vizualizare sau un tabel real. Mai mult, vizualizrile ofer i alte avantaje:
- Mascheaz coloanele pe care utilizatorul nu este nevoie sau nu trebuie s le vad
- Mascheaz rndurile pe care utilizatorul nu este nevoie sau nu trebuie s le vad
- Mascheaz operaiile complexe, precum uniunile
- Cresc performanele interogrilor (n unele sisteme RDBMS, cum ar fi Microsoft SQL
Server). Sintaxa general pentru crearea unei vizualizri este:
CREATE [OR REPLACE] VIEW nume_vizualizare AS interogare_sql;


1.4. ACTUALIZAREA DATELOR FOLOSIND LIMBAJUL SQL

Instruciunile DML (Data Manipulation Language), reprezint o parte a limbajului SQL
folosit pentru ntreinerea datelor stocate n tabelele relaionale ale bazei de date.
Limbajul DML este format din trei comenzi SQL:
- INSERT Adaug noi rnduri ntr-un tabel al bazei de date
- UPDATE Actualizeaz rndurile existente ntr-un tabel al bazei de date
- DELETE terge rnduri dintr-un tabel al bazei de date.
Observaie: instruciunile DML individuale afecteaz datele dintr-un singur tabel. Atunci
cnd o instruciune DML folosete o vizualizare, toate coloanele vizualizrii referite n
instruciunea DML trebuie s corespund unor coloane dintr-un singur tabel fizic al bazei de
date.
Instruciunile SQL din acest capitol presupun c sistemul DBMS pe care l utilizai
40
folosete formatul AAAA-LL-ZZ pentru datele calendaristice.
La formarea instruciunilor DML trebuie s inei seama de urmtoarele aspecte referitoare
la restriciile tabelului modificat:
Restricii de tip cheie primar. Atunci cnd inserai un nou rnd ntr-un tabel, cheia primar a
noului rnd trebuie s fie unic n ntregul tabel. Cnd modificai valoarea unei chei primare
(ceea ce se ntmpl rareori), noua valoare trebuie s fie unic n ntregul tabel.
Restricii de unicitate. Ca i n cazul cheilor primare, coloanele pe care a fost definit o
restricie de unicitate trebuie s aib valori unice n ntregul tabel.
Restricii refereniale. Nu putei insera sau actualiza valoarea unei chei externe dect dac
exist deja rndul printe corespondent care conine valoarea cheii n coloana cheii primare.
n sens invers, nu putei terge un rnd printe dac exist rnduri subordonate care refer
valoarea din rndul printe, dect dac restricia a fost definit cu opiunea ON DELETE
CASCADE. n general, inserrile n tabele trebuie s fie fcute ierarhic (mai nti rndurile
printe, apoi rndurile copii), iar tergerile trebuie fcute n ordine invers (copiii naintea
prinilor).
Restricii NOT NULL. n cazul instruciunilor INSERT, trebuie s specificai valori pentru
toate coloanele cu restricii NOT NULL. n cazul instruciunilor UPDATE, nu putei nlocui
valorile unei coloane cu valori nule dac pe coloana respectiv este definit o restricie NOT
NULL. Dac instruciunea DML refer o vizualizare, nu o putei folosi ntr-o instruciune
INSERT dac una dintre coloanele obligatorii ale tabelului (o coloan cu o restricie NOT
NULL) lipsete din definiia vizualizrii.
Restricii de verificare (CHECK). O instruciune INSERT sau UPDATE nu poate stoca ntr-o
coloan o valoare care ncalc o restricie CHECK definit pentru coloana respectiv.
Instruciunea INSERT
Instruciunea SQL INSERT este folosit pentru inserarea noilor rnduri de date n tabele.
Instruciunea are dou forme de baz: una n care valorile coloanelor sunt specificate chiar n
instruciune i alta n care valorile sunt selectate dintr-un tabel sau o vizualizare, folosind o
subinterogare.
Inserarea unui singur rnd de date folosind clauza VALUES
Instruciunea INSERT care folosete o clauz VALUES poate crea un singur rnd la
fiecare rulare, deoarece valorile pentru rndul de date respectiv sunt specificate chiar n
instruciune.
Sintaxa general a instruciunii este:
INSERT INTO nume_tabel sau vizualizare [ (list_de_coloane) ] VALUES
(list_de_valori);
Reinem urmtoarele aspecte:
- Lista de coloane este opional, dar dac este inclus trebuie s fie ncadrat n paranteze.
- Dac lista de coloane este omis, trebuie specificat o valoare pentru fiecare coloan din
tabel, n ordinea n care sunt definite coloanele n tabel. Este bine ca ntotdeauna s includei
lista de coloane, deoarece omiterea acesteia face ca instruciunea INSERT s fie dependent
de definiia tabelului. Dac o coloan este modificat sau n tabel este adugat o nou
coloan, chiar i opional, probabil instruciunea INSERT va eua la urmtoarea rulare.
- Dac lista de coloane este specificat, lista de valori trebuie s conin o valoare pentru
fiecare coloan din list, n aceeai ordine. Cu alte cuvinte, ntre lista de coloane i lista de
valori trebuie s exist o coresponden unu-la-unu. Orice coloan care lipsete din list va
primi o valoare nul, presupunnd c valorile nule sunt acceptate n coloana respectiv.
- Cuvntul cheie NULL poate fi folosit n lista de valori pentru specificarea unei valori nule
pentru o coloan.
Exemplu care conine dou instruciuni INSERT, una care creeaz un nou rnd n tabelul
MOVIE, cu o list opional de coloane din care este omis coloana RETAIL_PRICE_VHS, i
alta care creeaz un rnd n tabelul MOVIE_COPY pentru acelai timp, dar fr lista opional
de coloane:
41
INSERT INTO MOVIE
(MOVIE_ID, MOVIE_GENRE_CODE, MPAA_RATING_CODE, MOVIE_TITLE,
RETAIL_PRICE_DVD, YEAR_PRODUCED) VALUES (21, 'Drama', 'PG-13', 'Ray', 29.95, '2004');
INSERT INTO MOVIE_COPY VALUES (21, 1, '2005-04-01', null, 'V');
Inserri masive folosind o instruciune SELECT intern
O alt soluie, care poate fi folosit pentru a insera rnduri multiple ntr-un tabel, este
forma care folosete o instruciune SELECT intern. Aceast form este util i pentru stabilirea
urmtoarei valori disponibile pentru o cheie primar cu valori secveniale, cum este coloana
MOVIE_ID din tabelul MOVIE. De asemenea, poate fi folosit atunci cnd creai un tabel
temporar pentru testare i vrei s-1 populai cu toate datele dintr-un alt tabel.
Sintaxa general a instruciunii este:
INSERT INTO nume_tabel sau vizualizare [(lista de coloane)] SELECT
instruciune_select;
Reinem urmtoarele aspecte:
- Lista de coloane este opional, dar dac este inclus trebuie s fie ncadrat n paranteze.
- Dac lista de coloane este omis, instruciunea SELECT intern trebuie s furnizeze o valoare
pentru fiecare coloan din tabel, n ordinea n care sunt definite coloanele n tabel. Este bine
ca ntotdeauna s includei lista de coloane, deoarece omiterea acesteia face ca instruciunea
INSERT s fie dependent de definiia tabelului. Dac o coloan este modificat sau n tabel
este adugat o nou coloan, chiar i opional, probabil instruciunea INSERT va eua la
urmtoarea rulare.
- Dac lista de coloane este specificat, instruciunea SELECT intern trebuie s furnizeze o
valoare pentru fiecare coloan din list, n aceeai ordine. Cu alte cuvinte, ntre lista de
coloane i setul de rezultate al instruciunii SELECT trebuie s exist o coresponden unu-la-
unu. Orice coloan care lipsete din list va primi o valoare nul, presupunnd c valorile nule
sunt acceptate n coloana respectiv.
- Cuvntul cheie NULL poate fi folosit n instruciunea SELECT pentru specificarea unei valori
nule pentru o coloan.
Exemplu: s presupunem c toate filmele sunt acum disponibile i n limba francez.
Tabelul MOVIE_LANGUAGE conine rnduri pentru limba francez pentru o parte din filme,
aa c acum vrem s le adugm numai pe cele care lipsesc.
INSERT INTO MOVIE_LANGUAGE (MOVIE_ID, LANGUAGE_CODE)
SELECT MOVIE_ID, 'fr' FROM MOVIE WHERE MOVIE_ID NOT IN
(SELECT MOVIE_ID FROM MOVIE_LANGUAGE WHERE LANGUAGE_CODE = 'fr');
Exemplul urmtor insereaz un nou rnd n tabelul MOVIE, folosind instruciunea
SELECT pentru a gsi valoarea maxim din coloana MOVIE_ID, pe care o incrementeaz cu o
unitate, obinnd astfel cheia primar a noului rnd:
INSERT INTO MOVIE
(MOVIE_ID, MOVIE_GENRE_CODE, MPAA_RATING_CODE, MOVIE_TITLE,
RETAIL_PRICE_DVD, YEAR_PRODUCED) SELECT MAX(MOVIE_ID)+1, 'Drama', 'PG-13', 'The
Terminal', 24.95, '2004' FROM MOVIE;
Instruciunea UPDATE
Instruciunea UPDATE este folosit pentru actualizarea datelor din coloanele unui tabel
(sau ale unei vizualizri).
Sintaxa general a instruciunii UPDATE este:
UPDATE nume tabel sau vizualizare SET nume_coloan = expresie
[, nume_ coloan = expresie...] [WHERE condiie];
Reinem urmtoarele aspecte:
- Clauza SET conine o list cu una sau mai multe coloane, mpreun cu o expresie
care specific noua valoare pentru fiecare coloan. n esen, aceasta este o list
de perechi nume-valoare, separate prin virgule, cu un operator de egalitate ntre
fiecare nume i valoare.
42
- Expresia poate fi o constant, un alt nume de coloan sau orice alt expresie pe care SQL o
poate transforma ntr-o singur valoare, care va fi apoi atribuit coloanei respective.
- Clauza WHERE conine o expresie care limiteaz rndurile actualizate. Dac
aceast clauz este omis, motorul SQL va ncerca s actualizeze toate rndurile
din tabel sau din vizualizare.
Exemple:
- Un film adugat cu MOVIE_ID = 21 a fost introdus cu un pre incorect. Preul pentru copia
VHS ar trebui s fie 29.95, iar preul pentru copia DVD ar trebui s fie 34.95. Instruciunea
urmtoare actualizeaz preurile, introducnd valorile corecte. Observai c instruciunea
actualizeaz dou coloane din acelai rnd al tabelului MOVIE.
UPDATE MOVIE SET RETAIL_PRICE_VHS = 29.95, RETAIL_PRICE_DVD = 34.95
WHERE MOVIE_ID = 21;
- Proprietarul magazinului de produse video a decis s creasc salariul tuturor
funcionarilor (EMPLOYEE_JOB_CATEGORY = 'C') cu 8 procente. Aceast
instruciune va actualiza o singur coloan de pe mai multe rnduri (toate
rndurile pentru care corespunde categoria postului). Putei folosi un calcul
pentru a crete fiecare salariu cu 8 procente, nmulind valoarea existent cu 1.08
i rotunjind rezultatul la dou cifre zecimale, cu ajutorul funciei ROUND.
UPDATE EMPLOYEE SET EMPLOYEE_HOURLY_RATE =
ROUND(EMPLOYEE_HOURLY_RATE * 1.08, 2) WHERE EMPLOYEE JOB CATEGORY = 'C';
Instruciunea DELETE
Instruciunea DELETE terge unul sau mai multe rnduri dintr-un tabel. Instruciunea
poate s foloseasc i o vizualizare, dar numai dac aceasta se bazeaz pe un singur tabel (ceea
ce nseamn c instruciunile DELETE nu pot fi folosite pentru vizualizri care conin uniuni). n
instruciunile DELETE nu sunt referite niciodat coloane, deoarece instruciunea terge rnduri
ntregi de date, inclusiv toate valorile datelor (toate coloanele) din rndurile afectate. Dac vrei
s tergei o singur valoare din rndurile existente, folosii instruciunea UPDATE pentru a
nlocui valorile respective cu valori nule (presupunnd c valorile nule sunt permise n acele
coloane). Sintaxa generala a instruciunii DELETE este: DELETE FROM nume_tabel sau
vizualizare [WHERE condiie];
Reinem urmtoarele aspecte:
- Clauza WHERE este opional. Totui, este folosit aproape ntotdeauna, deoarece o
instruciune DELETE fr o clauz WHERE ncearc s tearg toate rndurile din tabel -
ceea ce, n majoritatea cazurilor, nu este rezultatul care se dorete.
- Atunci cnd este inclus, clauza WHERE specific rndurile care urmeaz s fie terse. Orice
rnd pentru care condiia WHERE este evaluat ca adevrat este ters din tabel.
- Reinei c nu putei terge rnduri dac nclcai astfel o restricie referenial. n general,
rndurile subordonate trebuie terse nainte rndurilor printe.
Exemple:
- tergei filmul (cu MOVIE_ID = 21). Observai c trebuie s tergei mai nti rndurile
corespondente din tabelele MOVIE_COPY i MOVIE_LANGUAGE, deoarece acestea sunt
rnduri copii" ale rndului din tabelul MOVIE. Dac ncercai s tergei mai nti rndul din
tabelul MOVIE, sistemul DBMS va afia un mesaj de eroare referitor la
nclcarea unei restricii refereniale.
DELETE FROM MOVIE_COPY WHERE MOVIE_ID = 21;
DELETE FROM MOVIE_LANGUAGE WHERE MOVIE_ID = 21;
DELETE FROM MOVIE WHERE MOVIE_ID = 21;
- tergei din tabelul MOVIE_LANGUAGE toate rndurile pentru limba spaniol
(LANGUAGE_CODE = 'es'. Reinei c n multe implementri SQL se face
diferenierea literelor mari de cele mici, caz n care valoarea codului de limb
trebuie specificat cu litere mici pentru a se potrivi cu datele din tabel.
DELETE FROM MOVIE_LANGUAGE WHERE LANGUAGE_CODE = 'es';
43
CAP.2. PROGRAMARE ORIENTAT OBIECT I STRUCTURI DE DATE

2.1. CARACTERISTICILE GENERALE ALE
PROGRAMRII ORIENTATE OBIECT

2.1.1. Principiile ce stau la baza programrii orientate obiect

Programarea orientat obiect este unul din cei mai importani pai fcui n evoluia
limbajelor de programare spre o mai puternic abstractizare n implementarea programelor. Ea a
aprut din necesitatea exprimrii problemei ntr-un mod mai natural fiinei umane. Astfel
unitile care alctuiesc un program se apropie mai mult de modul nostru de a gndi dect modul
de lucru al calculatorului.
Programarea obiect se desfoar ca programarea modular cu tipuri abstracte de date, n
scopul crerii posibilitii de ncapsulare a structurilor de date. Ea favorizeaz reutilizarea i
extensibilitatea aplicaiilor.
Principalele concepte ce stau la baza programrii orientate obiect sunt:

A) Abstractizarea.
Abstractizarea este una din cile fundamentale prin care noi, oamenii, ajungem s
nelegem i s cuprindem complexitatea, oferind posibilitatea ca un program s ignore unele
aspecte ale informaiei pe care o manipuleaz, adic posibilitatea de a se concentra asupra
esenialului. Fiecare obiect n sistem are rolul unui actor abstract, care poate executa aciuni,
i poate modifica i comunica starea i poate comunica cu alte obiecte din sistem fr a dezvlui
cum au fost implementate acele facilitai. Procesele, funciile sau metodele pot fi de asemenea
abstracte, i atunci cnd sunt, sunt necesare o varietate de tehnici pentru a extinde abstractizarea.
O abstraciune exprim toate caracteristicile eseniale ale unui obiect, care fac ca
acesta s se disting de alte obiecte, oferind o definire precis a granielor conceptuale ale
obiectului.
Comportament vs. Implementare.
n procesul de abstractizare atenia este ndreptat exclusiv spre aspectul exterior al
obiectului, adic spre comportarea lui, ignornd implementarea acestei comportri. Cu alte
cuvinte abstractizarea ne ajuta sa delimitam ferm "CE face obiectul" de "CUM face obiectul
ceea ce face".
Modelul Client-Server. Responsabiliti. Protocol.
Comportarea unui obiect se caracterizeaz printr-o sum de servicii sau resurse pe care el
le pune la dispoziia altor obiecte. Un asemenea comportament, n care un obiect, numit server,
ofer servicii altor obiecte, numite clieni, este descris de aa-numitul model client-server.
Totalitatea serviciilor oferite de un obiect server constituie un contract sau o
responsabilitate a obiectului fa de alte obiecte. Responsabilitile sunt ndeplinite prin
intermediul unor operaii, fiecare operaie a unui obiect caracterizndu-se printr-o semntur
unic, format din: nume, o list de parametrii formali i un tip returnat. Mulimea operaiilor
unui obiect, mpreun cu regulile lor de apelare constituie protocolul obiectului.

B) ncapsularea
ncapsularea este conceptul complementar abstractizrii. Dac rezultatul operaiei de
abstractizare pentru un anumit obiect este identificarea protocolului su, atunci ncapsularea are
de a face cu selectarea unei implementri i tratarea acesteia ca pe un secret al respectivei
abstraciuni. ncapsularea numit i ascunderea de informaii, asigur faptul c obiectele nu
pot schimba starea intern a altor obiecte n mod direct (ci doar prin metode puse la dispoziie de
obiectul respectiv); doar metodele proprii ale obiectului pot accesa starea acestuia. Fiecare tip de
obiect expune o interfa pentru celelalte obiecte care specific modul cum acele obiecte pot
interaciona cu el.
44
Prin urmare, ncapsularea este procesul n care are loc ascunderea implementrii fa de
majoritatea obiectelor-client. Determinarea protocolului pentru un obiect trebuie s precead
decizia privind implementarea sa. Sintetiznd putem defini ncapsularea astfel: ncapsularea
este procesul de compartimentare a elementelor care formeaz structura i comportamentul
unei abstraciuni; ncapsularea servete la separarea interfeei "contractuale" de
implementarea acesteia.

Interfaa vs. Implementare
Din definiia de mai sus rezult c un obiect este format din dou pri distincte: interfaa
(protocolul) i respectiv implementarea acestei interfee. Abstractizarea este procesul prin care
este definit interfaa obiectului, n timp ce ncapsularea definete reprezentarea (structura)
obiectului mpreun cu implementarea interfeei. Ascunderea structurii obiectului i a
implementrii metodelor sale este ceea ce se nelege prin noiunea de ascundere a informaiei.

Beneficiile ncapsulrii
Separarea interfeei de reprezentarea unui obiect permite modificarea reprezentrii
fr a afecta n vreun fel pe nici unul din clienii si, ntruct acetia depind de
interfa i nu de reprezentarea obiectului-server.
ncapsularea permite modificarea programelor ntr-o manier eficient, cu un efort
limitat i bine localizat.
ncapsularea aplic principiul abstraciei: un obiect nu este accesibil pentru operaiile
vizibile (interfaa sa extern) i implementarea sa (structurile datelor asociate) este ascuns.
Astfel, modificrile datelor rmn locale, la obiecte, fr s afecteze programele utilizatorilor.
Aceast ncapsulare confer independen ntre programe, operaii i date. Un avantaj
imediat este acela c diferitele programe de aplicaii pot fi partajate pe aceleai obiecte fr a
cunoate mecanismul de intrare-ieire (import/export). Principiul ncapsulrii poate fi uneori
temporar lsnd un acces mai mult sau mai puin liber datelor dintr-un obiect, fcnd posibil
stabilitatea n timp a alegerii implementrii datelor.
Accesul direct al datelor la obiecte este un plus de eficien care apeleaz procedura
impus de ncapsulare. ntre timp cnd implementarea datelor este modificat (de exemplu se
schimb tipul lor), se va face modificarea n toate programele utilizatoare ale datelor, n mod
direct prin programarea structurat. Decizia de ncapsulare se va lua fcndu-se un compromis
ntre performan i flexibilitate. Putem spune c cele dou tipuri de orientri permit rspunsul
parial la problema proiectrii structurate.

C) Modularitatea
Scopul descompunerii n module este reducerea costurilor prin posibilitatea de a proiecta
i revizui modulele n mod independent. Clasele i obiectele obinute n urma abstractizrii i
ncapsulrii trebuie grupate i apoi stocate ntr-o form fizic, denumit modul.
Modulele pot fi privite ca i containere fizice n care declarm clasele i obiectele
rezultate n urma proiectrii la nivel logic. Modulele formeaz aadar arhitectura fizic a
programului.
Modularizarea const n divizarea programului ntr-un numr de module care pot fi
compilate separat, dar care sunt conectate (cuplate) ntre ele. Limbajele care suport conceptul de
modul fac n acelai timp distincia ntre interfaa modulului i implementarea sa.

Reguli Generale de Modularizare
1. Structura fiecrui modul trebuie s fie suficient de simpl pentru a putea fi complet
neleas.
2. Implementarea unui modul trebuie s depind doar de interfeele altor module,
respectiv trebuie s fie posibil modificarea implementrii unui modul fr a avea cunotine
despre implementarea altor module i fr a afecta comportarea celorlalte module.
45
3. Detaliile sistemului care se presupune c se vor modifica independent vor fi plasate n
module diferite.
4. Singurele legturi ntre module vor fi acelea a cror modificare este improbabil.
5. Orice structur de date este ncapsulat ntr-un modul, ea putnd fi accesat direct din
interiorul modulului dar nu poate fi accesat din afara modului dect prin intermediul obiectelor
i claselor coninute n acel modul.
Putem defini modularitatea ca fiind proprietatea unui sistem care a fost descompus
ntr-un set de module coezive i slab cuplate.

D) Ierarhizarea
Abstractizarea este un lucru bun, dar n majoritatea aplicaiilor - excepie fcnd doar
aplicaiile banale - vom descoperi mai multe abstraciuni dect putem cuprinde la un moment
dat. ncapsularea ne ajut s tratm aceast complexitate prin ascunderea interiorului
abstraciunilor noastre. Modularitatea ne ajut i ea, oferindu-ne o modalitate de a grupa
abstraciuni legate logic ntre ele. Toate acestea dei utile, nu sunt suficiente. Adesea un grup de
abstraciuni formeaz o ierarhie, iar prin identificarea acestor ierarhii, putem simplifica
substanial nelegerea problemei. Ierarhizarea reprezint o ordonare a abstraciunilor.
Polimorfismul
Este abilitatea de a procesa obiectele diferit n funcie de tipul sau de clasa lor. Mai exact,
este abilitatea de a redefini metode pentru clasele derivate.
Motenirea (ierarhia de clase)
Motenirea organizeaz i faciliteaz polimorfismul i ncapsularea permind
definirea i crearea unor clase specializate plecnd de la clase (generale) care sunt deja definite -
acestea pot mprti (i extinde) comportamentul lor fr a fi nevoie de redefinirea aceluiai
comportament. Aceasta se face de obicei prin gruparea obiectelor n clase i prin definirea de
clase ca extinderi ale unor clase existente. Conceptul de motenire permite construirea unor clase
noi, care pstreaz caracteristicile i comportarea, deci datele i funciile membru, de la una sau
mai multe clase definite anterior, numite clase de baz, fiind posibil redefinirea sau adugarea
unor date i funcii noi. O clas motenitoare a uneia sau mai multor clase de baz se numete
clas derivat.
Motenirea definete o relaie ntre clase n care o clas mprtete structura i
comportarea definit n una sau mai multe clase (dup caz vorbim de motenire simpl sau
multipla). Motenirea implic o ierarhie de tip generalizare/specializare, n care clasa derivat
specializeaz structura i comportamentul mai general al clasei din care a fost derivat.
Agregarea (ierarhia de obiecte)
Agregarea este relaia ntre dou obiecte n care unul dintre obiecte aparine celuilalt
obiect. Agregarea red apartenena unui obiect la un alt obiect.


2.1.2. Avantajele programrii orientate obiect

Orientarea obiect aduce avantaje decisive cum ar fi: modelarea obiectelor aplicaiilor,
modularitatea, reutilizabilitatea i extensibilitatea codului care conduc la o mai mare
productivitate, i dezvoltarea unei mari caliti a aplicaiilor.
Deoarece utilizatorii doresc ca programele lor s se comporte ntr-o manier fiabil i
previzibil, este important s se neleag modul n care POO i condus de evenimente va
contribui la corecta structurare i modularizare a programului.
ntr-o manier global, un program orientat obiect este un ansamblu de obiecte care
printr-un schimb de mesaje declaneaz anumite operaii sau metode, facilitndu-le strile lor
interne i returnndu-le parametrii.
Prin crearea n mod vizual a unei singure linii de cod, se obine un program funcional
care, dei banal, demonstreaz toate elementele unei corecte proiectri orientate obiect i
conduse de evenimente.
46
Obiectele permit reprezentarea n mod direct a entitilor lumii reale i a relaiilor dintre
entiti. Se definesc concepte noi, ca tip, clas, motenire, obinndu-se o nsumare a avantajelor
sistemelor de gestiune a bazelor de date, care interogheaz eficient datele, i a limbajelor
procedurale care permit calcule complexe.
n timp ce structura unei pri din variabile conine date i cealalt funcii de tratare, se
organizeaz programele n entiti active compuse din structuri de date ce ascund modul de
funcionare. Acelai nume de funcie poate fi utilizat pentru efectuarea de aciuni similare la
obiecte diferite, ceea ce permite constituirea unui limbaj abstract i prezentarea n maniere
similare a obiectelor nainte difereniate.

Avantajele utilizrii POO se pot sintetiza astfel:
Uurina proiectrii i reutilizrii codului: odat ce este testat corectitudinea
funcionrii unor obiecte dintr-o aplicaie, acestea vor putea fi folosite fr nici o problem i n
alt aplicaie. Acest avantaj poate fi valorificat prin constituirea de biblioteci de obiecte. n ceea
ce privete proiectarea, se faciliteaz descompunerea problemelor complexe n subprobleme
simple, care pot fi uor modelate cu ajutorul obiectelor.
Abstractizare - proiectanii pot obine o imagine de ansamblu, urmrind comportarea
obiectelor i interaciunile dintre ele, detaliile fiind ngropate n compoziia obiectelor.
Programarea orientat-obiect constituie o bun metod de organizare a programelor de calcul
(software). Proprietile POO conduc la un cod principal compact i elegant. Obiectele pot
descrie mai bine conceptele pe care le reprezint, fiind mai logice i intuitive dect modul
tradiional, cu simple structuri de date.
Sigurana datelor - abilitatea obiectelor de a se comporta ca nite cutii negre, de a
putea fi folosite fr a se cunoate compoziia lor, asigur confidenialitatea datelor utilizate i
micoreaz frecvena apariiilor i efectul erorilor legate de manipularea greit a tipurilor de
date. Modelnd realitatea complex, tehnicile orientate obiect, pun accentul pe comportamentul
datelor, ncapsulnd n conceptul de obiect att datele, ct i operaiile posibile asupra lor.
Din punct de vedere educaional, aplicarea POO conduce la formarea rapid a unor
concepte globale de funcionare a metodei elementului finit. POO permite construcia unor
aplicaii prin asamblarea unor module existente, la nivel global, reprezentnd astfel o metod
modern, logic i eficient nu numai n dezvoltarea de programe, dar i n utilizarea i
nelegerea acestora.
n programarea orientat obiect interfaa este separat de implementare. Interfaa este
partea vizibil a clasei, parte care trebuie neleas de utilizatorul acesteia. Implementarea este
partea ascuns, intern clasei, care este important doar pentru autorul clasei. Pot exista una sau
mai multe implementri pentru o aceeai interfa. O implementare satisface cerinele unei
interfee dac comportamentul definit de interfa este realizat de implementare.
Pe lng avantajul simplificrii, separarea aduce un plus de flexibilitate pentru
implementatori, deoarece mai multe implementri pot servi o aceeai interfa. Implementrile
pot s difere n ceea ce privete eficiena de timp, spaiu, preul sau calitatea documentaiei puse
la dispoziie, sau orice ale caracteristici non-funcionale. De asemenea o singur implementare
poate s satisfac mai multe interfee. n acest caz implementarea conine o uniune de metode
cerute de fiecare din interfee.
Numeroase limbaje de programare includ tehnici POO. n lucrarea de fa se folosete,
pentru exemplificare, limbajul Visual C++, deoarece C++ reprezint limbajul standard n lumea
POO. C++ permite ca programarea procedural i cea orientat-obiect s fie folosite mpreun
ntr-un limbaj destul de uniform.
Limbajul C++ prezint i alte avantaje fa de celelalte limbaje obiectuale, cum ar fi:
\ C++ produce un cod cu un timp de execuie foarte eficient;
\ existena multor compilatoare, inclusiv a celor gratuite;
\ posibilitatea utilizrii modulelor existente Fortran i C;
\ legturile cu sistemul de operare Unix (datorate limbajului C);
47
\ larga utilizare i acceptare a limbajului C++ a produs numeroase implementri, pe
platforme diferite, existnd multe biblioteci i programe de calcul reutilizabile;
\ posibilitatea de interfaare cu numeroase programe importante.


2.1.3. Caracteristici generale ale claselor n Visual C++

2.1.3.1. Conceptul de clas i tipuri de clase
O clas este schema, planul dup care este creat un obiect. n interiorul unei clase sunt
precizate denumirile tuturor variabilelor i tipurile de valori pe care acestea le vor stoca
(numeric, ir de caractere, etc.), alturi de toate operaiile (metodele) pe care un obiect,
construit din respectiva clas, le va conine.
Clasa reprezint o abstractizarea a elementelor (proprietilor i operaiilor) comune
partajate de o mulime de obiecte i descrie implementarea acestora.
Folosind instrumentele moderne precum Visual C++, alctuirea unui program este cu
mult mai simpl. Mediul Visual C++ permite editarea, compilarea, executarea i depanarea unui
program n interiorul aceluiai mediu.
Programarea orientat-obiect presupune ordonarea obiectelor i a aciunilor din lumea
real sub form de clase care pot fi create, manevrate i distruse.
Datele care alctuiesc un obiect i funciile exercitate asupra acelui obiect sunt combinate
pentru a forma o clas, sau o descriere a acelui obiect.
Clasele pot moteni funcionalitatea altor obiecte, putnd fi cu uurin adugate clase noi
care depesc clasele existente.
O clas trebuie s asigure o interfa, utilizat pentru manipularea obiectelor existente n
acea clas. Pe ct posibil, detaliile de implementare trebuie ascunse utilizatorului, ceea ce
permite programatorului dotarea claselor complicate cu o interfa simpl, precum i modificarea
detaliilor de implementare, dac este necesar.
Deoarece structurile orientate obiect descriu integral clasa din care face parte obiectul
respectiv, fiecare clas poate fi reutilizat cu uurin, ntruct datele i funciile descrise de clasa
respectiv sunt integrate.
Deoarece implementarea unei clase poate fi ascuns n spatele unei interfee, detaliile de
implementare ale respectivei clase sunt uor de modificat fr a-i afecta pe utilizatorii acesteia,
atta timp ct interfaa nu se modific.
Atunci cnd se utilizeaz limbajul Visual C++, obiectele sunt descrise printr-o clas. O
clas are dou componente principale:
declaraia clasei - conine interfaa clasei i informaii privind datele membre ale
respectivei clase. Interfaa clasei este de obicei localizat ntr-un fiier antet cu extensia .h.
Orice fiier din program care folosete clasa respectiv trebuie s foloseasc directiva
#include, pentru ca declaraia de clas s fie adugat fiierului surs de ctre preprocesor;
implementarea clasei - include toate funciile membru care au fost declarate ca parte a
clasei. De obicei implementarea clasei este localizat ntr-un fiier avnd extensia .CPP.
Pentru a face clasele uor de citit i de ntreinut, se va descompune codul asociat n dou
tipuri de fiiere: fiiere header i fiiere de cod. Fiierele din prima categorie conin declaraiile
atributelor i funciilor membru clasei n cauz. Aceasta nu conine altceva dect structura clasei.
Fiierele din a doua categorie coninnd codul sau implementarea nu sunt altceva dect fiiere
ASCII care conin definiia fiecrei metode declarate n fiierele header corespunztoare.
Fiierul header trebuie s conin urmtoarele informaii:
numele fiierului trebuie s reprezinte clasa;
descriere a ceea ce face clasa;
structura clasei, cea care este implementat n poriunea privat;
funciile membru mprite pe categorii;
48
comentarii tactice i strategice ale funciilor membru i grupurile de funcii membru, chiar
i de atribute.
Funciile membru trebuie s fie documentate n fiierele header prin aa numitele
comentarii tactice (comentarii coninute ntr-o singur linie ce sunt utile noilor utilizatori ai
clasei n scopul nelegerii acesteia). Comentariile strategice sunt utilizate n documentarea
grupurilor sau blocurilor de funcii aflate ntr-o anume legtur unele cu altele.
Fiecare funcie membru declarat n fiierul header trebuie s-i gseasc implementarea
corespunztoare n fiierul de cod asociat clasei. Mai mult, fiierul de cod este amplasat acolo
unde detaliile de modificare ale programului pot fi documentate.
C++ permite definirea de funcii avnd acelai nume, dar tipuri i numr diferite de
parametri. Tipul valorilor returnate de astfel de funcii este irelevant n identificarea variantei
apelate. Aceasta este o form ad-hoc de polimorfism, cunoscut sub denumirea de redefinirea
funciilor.
O alt form de polimorfism acceptat n C++ este redefinirea operatorilor. De fapt,
aceasta nu este altceva dect o variant restrns a primei forme de polimorfism ad-hoc. Prin
aceast metod, este posibil redefinirea operatorilor n vederea operrii acestora asupra tipurilor
de date definite de utilizator, fiind o soluie deosebit de important n toate aplicaiile cu un bogat
suport matematic, n special.
Redefinirea funciilor i operatorilor poate crete gradul de nelegere a codului. Totui,
este important s nu se uite c utilizarea excesiv a acestei tehnici poate conduce la obinerea
unui cod mult mai criptat dect este cazul. n cazul redefinirii funciilor, se vor utiliza nume care
s aib sens n cadrul problemei.
Privitor la diferitele clase care pot aprea ntr-un program, exist dou modaliti de
organizare a claselor:
\ ierarhii - o ierarhie poate fi folosit pentru organizarea claselor dup modelul unui
arbore genealogic, cu clase care motenesc datele i funciile de la predecesorii lor;
\ categorii - adesea, un set de clase se folosesc mpreun i prezint un fel de dependen
sau o alt categorie de relaii ntre ele. Aceste clase pot fi organizate ntr-o categorie,
pentru a simplifica utilizarea lor.
n majoritatea limbajelor orientate obiect, clasele pot moteni proprietile unei clase de
baz. O clas de baz are anumite proprieti generale care sunt incluse n clasele derivate din
acestea.
Organizarea claselor ntr-o ierarhie nainte de nceperea scrierii declaraiilor de clas este
o modalitate de a cuta punctele comune ale claselor. Prin organizarea claselor, se pot determina
cu uurin relaiile care exist ntre toate clasele, ceea ce poate contribui la selectarea clasei de
baz i la determinarea claselor care trebuie create.
n multe cazuri, ntre clasele care lucreaz mpreun, exist o strns interdependen.
Clasele ntre care exist legturi strnse sunt adesea grupate n categorii care sunt frecvent
folosite n grup; n multe cazuri nu are nici un rost utilizarea unei clase care este component a
unui grup mai mare.
C++ suport att motenirea simpl ct i pe cea multipl, ns dintre cele dou, cea
simpl este cea mai utilizat n cadrul proiectelor C++, aplicarea motenirii multiple fiind mult
mai dificil. Utilizarea motenirii n C++ poate ajuta la creterea productivitii, dac este
aplicat corespunztor.
Clasele identificate drept clase predecesor, sau clase de baz, conin date i funcii
membru care sunt incluse n toate clasele descendent, sau derivate.
Cnd se folosete conceptul de motenire, o clas de baz stabilete un fel de contract
care trebuie respectat de ctre toate subclasele. Dac o operaie poate fi executat utiliznd o
clas de baz, toate subclasele trebuie s fie capabile s execute acea operaie. Cu alte cuvinte,
ntr-o structur cu adevrat orientat-obiect se impune posibilitatea nlocuirii unei subclase cu
o clas de baz. Acesta este cunoscut sub numele de principiul de nlocuire al lui Liskov.
49
Unul din obiectivele motenirii este acela de a partaja un cod ntre mai multe clase, ceea
ce nu face altceva dect s creasc factorul de reutilizare al codului. n general, este bine de
evitat ierarhiile de motenire stufoase.
Principiile de ascundere a informaiei i ncapsulare sunt suportate de Visual C++. Acest
limbaj implementeaz aceste dou noiuni prin intermediul cuvintelor cheie public i private.
Astfel, membrii clasei care sunt declarai n seciunea privat sunt vizibili numai instanelor i
membrilor clasei, fiind n acelai timp inaccesibili celorlalte clase i instane ale acestora.
Seciunea privat este utilizat n primul rnd pentru informaiile strii unui obiect. Ea
conine declaraii ale datelor ce reprezint atributele unui obiect. Aceast seciune poate conine,
de asemenea, declaraiile funciilor membru care nu sunt oferite spre utilizare clienilor clasei.
Membrii claselor care sunt declarai n seciunea public a acesteia sunt accesibili tuturor
obiectelor i funciilor, seciunea public constituind implementarea serviciilor pe care o clas le
ofer clienilor si.
Pentru apelul funciilor membre publice sau pentru accesul la datele publice ale unui
obiect, din funcii care nu sunt membre, se folosesc operatorii de selecie (.) i (->), ca n cazul
structurilor i uniunilor din C.
Un caz special al paradigmei client/server ne este oferit de C++, respectiv cazul relaiei
dintre o clas dat i derivatele sale, unde este posibil s se defineasc zone protejate. Membrii
acestor zone se comport ca membrii publici n clasele derivate, astfel aceste elemente violeaz
principiul de ascundere a informaiei.
Numele tuturor funciilor membru sunt prefixate de numele de clas ale acestora, aceasta
fiind unica modalitate prin care compilatorul poate determina clasa creia i aparine funcia
respectiv. Unica excepie de la regul o constituie o funcie definit n interiorul declaraiei de
clas.

Constructori i destructori
n cazul variabilelor obinuite, compilatorul asigur alocarea spaiului de memorie i
eventual iniializarea explicit cu valori iniiale n declaraie. Pentru variabilele dinamice,
compilatorul C nu dispune de nici o metod de iniializare i nici operatorul new nu rezolv toate
situaiile. n acest caz, rmne n grija programatorului atribuirea de valori adecvate datelor
nainte de utilizare. Aceast abordare este nesatisfctoare n multe situaii n cazul obiectelor.
Pentru crearea, iniializarea, copierea i respectiv distrugerea obiectelor, n C++ se
folosesc funcii speciale, numite constructori i destructori.
Un constructor, numit uneori i ctor, este o funcie membru special, creat la crearea
unui obiect al unei clase. Constructorul se apeleaz automat la crearea fiecrui obiect al clasei,
static, automatic sau dinamic (cu operatorul new), inclusiv pentru obiecte temporare. Un obiect
se creeaz atunci cnd este definit, sau cnd este creat din punct de vedere dinamic.
Utilitatea constructorilor este evident cel puin sub dou aspecte:
constructorul asigur iniializarea corect a tuturor variabilelor membru ale unui obiect;
constructorul ofer o garanie c iniializarea unui obiect se va realiza exact o dat.
De multe ori este util s existe mai multe moduri de iniializare a obiectelor unei clase.
Acest lucru se poate realiza furniznd diferii constructori. Atta timp ct constructorii difer
suficient n tipurile argumentelor lor, compilatorul le poate selecta corect, unul pentru fiecare
utilizare.
Un destructor, cunoscut i sub numele de dtor, este o funcie membru special care este
apelat la distrugerea unui obiect. Destructorul este declarat ca neavnd tip de valoare returnat
i nu este declarat niciodat cu o list de parametrii. Numele destructorului este alctuit din
numele clasei, precedat de un caracter tilda (~). Nu este absolut necesar definirea unui
destructor, dect dac exist operaii specifice care trebuie efectuate pentru a face curenie, cum
ar fi eliberarea resurselor unui sistem care au fost alocate.
Destructorul este apelat automat la eliminarea unui obiect, la ncheierea timpului sau de
viata, sau poate fi solicitat prin program, cu operatorul delete.
50
Constructorii i destructorii se declar i se definesc similar cu celelalte funcii membre,
dar se disting de acestea printr-o serie de caracteristici specifice:
numele funciilor constructor sau destructor coincide cu numele clasei creia i aparin;
n declaraie i definiie nu se specific nici un tip de rezultat, nici mcar void;
constructorii pot avea parametrii, inclusiv parametrii implicii, i pot fi supradefinii;
destructorii nu au aceste proprieti;
nu se pot utiliza pointeri ctre constructori sau destructori;
dac o clas nu dispune de constructori i destructori definii, compilatorul va genera
automat un constructor implicit, respectiv un destructor, funcii publice.
constructorii sunt lansai n ordinea declarrii obiectelor iar destructorii n ordine
invers.
Alt categorie de constructor este constructorul de copiere. Necesitatea de copiere a
obiectelor intervine cnd un obiect este transferat ca parametru sau rezultat al unei funcii, sau la
crearea unui obiect temporar. Soluia oferit de C++ const n utilizarea unui constructor special,
numit constructor de copiere. n absena unei definiii explicite n cadrul clasei, compilatorul
genereaz automat un constructor de copiere care iniializeaz datele noului obiect cu valorile
corespunztoare din obiectul specificat, prin copiere membru cu membru. Aceasta nu este o
soluie bun n cazul n care clasa conine membrii variabile dinamice, caz n care este necesar
scrierea unui constructor de copiere special. Declaraia constructorului de copiere pentru o clas
trebuie s specifice un parametru unic de tipul referin de obiecte a acelei clase.

Suprancrcarea funciilor membre i a operatorilor
Funciile membre ale unei clase pot fi suprancrcate. Mecanismul nu difer de cel al
suprancrcrii funciilor independente.
Programele manipuleaz obiecte care sunt reprezentri concrete ale unor concepte
abstracte. De exemplu, datele de tip "int" din C++, mpreun cu operatorii +, - , *, /, etc.,
furnizeaz o implementare restrictiv a conceptului matematic de ntregi. Astfel de concepte
includ de obicei un set de operatori care reprezint operaiile de baz asupra obiectelor.
Clasele furnizeaz o facilitate de reprezentare a obiectelor neprimitive mpreun cu un set
de operaii care pot fi efectuate cu astfel de obiecte. Se permite programatorului s furnizeze o
notaie mai convenional i mai convenabil pentru a manipula obiectele unei clase. Acest lucru
se realizeaz prin suprancrcarea operatorilor. Trebuie evideniat faptul c operatorii sunt deja
suprancrcai, fie pentru a putea opera asupra mai multor tipuri de baz (de ex. operatorii
aritmetici admit ca operand orice tip numeric), fie pentru a efectua mai multe operaii
matematice (de ex. * este asociat nmulirii dar i referirii datelor de tip pointer). Operaia
adecvat este selectat de compilator n funcie de tipul operanzilor.
Procedeul de suprancrcare const n definirea unei funcii cu numele operator simbol
unde:
- operator este cuvntul cheie dedicat
- simbol este simbolul oricrui operator C++, mai puin urmtorii: . (punct) .* :: ?:
intaxa suprancrcrii unui operator :
TipNumeClasa::operatorNumeOperator (ListaArgumente)
{
BlocInstructiuni
}

Funcii virtuale i clase de baz abstracte
Cuvntul cheie virtual este utilizat n header-ul unei clase de baz n vederea declarrii
funciilor care definesc comportamentul tuturor claselor derivate din aceast clas de baz. O
funcie membru virtual trebuie s posede un corp, acesta situndu-se n fiierul de cod asociat
clasei. Acest mecanism permite implementarea polimorfismului.
51
Cnd se folosete o funcie virtual, compilatorul construiete un tabel special, denumit
tabel de funcii virtuale (virtual function table) sau vtabl, care se folosete pentru a pstra
evidena funciilor care trebuie apelate pentru fiecare obiect din clasa respectiv. Cnd este
apelat o funcie virtual, vtab-ul este folosit pentru accesarea indirect a funciei corecte.
Suprasarcina (overhead) adugat prin utilizarea tabelului de funcii virtuale este destul
de redus, dar poate deveni semnificativ dac se dispune de mii de obiecte mici sau dac viteza
de execuie este hotrtoare. Din acest motiv, o funcie trebuie precizat ca fiind virtual,
deoarece acest caracter nu este prestabilit.
Principalul, avantaj al utilizrii funciilor virtuale poate fi observat n momentul rulrii,
sistemul putnd determina tipul obiectului din care provine funcia membru apelat.
O funcie virtual pur este o funcie virtual fr corp. Aceste funcii sunt declarate n
clasele de baz. Derivarea unei clase dintr-o clas de baz care conine cel puin o funcie
virtual pur presupune declararea i definirea acestor funcii n cadrul clasei derivate, n caz
contrar producndu-se o eroare de compilare.
Utilizarea acestor funcii autorizeaz presupunerea c o clas de baz a fost declarat ca
avnd un comportament normal dar trebuie implementat n toate cazurile speciale. Este nevoie
de ceva mult mai puternic pentru a asigura implementarea funciilor de ctre clieni (n acest caz
clase derivate).
Scrierea de funcii virtuale pure n clasa de baz este echivalent cu adoptarea unei
asigurri: clasa de baz tie c viitorii si clieni trebuie s implementeze aceste funcii, iar
clienii sunt obligai s o fac.
O clas de baz abstract (CAB) este o clas care are cel puin o funcie membru
virtual pur. Clasele de baz abstracte nu pot avea instane.
ntotdeauna se va ncerca s se gseasc ct mai multe clase abstracte atunci cnd se
proiecteaz un produs software utiliznd tehnicile orientate obiect. O clas de baz abstract
apare dintr-un set de clase care partajeaz atribute i/sau comportament util. Dac se descoper
un comportament care este partajat de un numr de clase, va trebui proiectat o superclas pentru
capturarea acestuia ntr-un singur loc.
Un alt avantaj al claselor abstracte de baz l constituie faptul c pot ine locul oricreia
din clasele derivate. Cu alte cuvinte, avnd o colecie de clase abstracte de baz, este mult mai
uor s se clasifice clasele, deoarece majoritatea noilor clase pot fi considerate ca fiind derivate
ale cel puin unei clase abstracte.
Este posibil derivarea de clase att din cele abstracte ct i din cele concrete.
Combinarea corect a celor dou tipuri de clase va permite obinerea ierarhiilor de clase C++.
Regulile de baz sunt:
+ alegerea unei clase abstracte de baz pentru a servi drept clas de baz tuturor celorlalte
clase (abstracte sau nu). Clasele abstracte de baz vor deriva direct din aceasta;
+ este posibil crearea unei clase de baz abstracte prin derivarea dintr-o alt clas de baz
abstract;
+ clasele concrete sunt proiectate pentru a fi instaniate. Acestea pot proveni din derivare,
fie dintr-o clas abstract fie dintr-una concret;
+ niciodat nu se va deriva o clas abstract dintr-una concret.

Polimorfismul
Polimorfismul este cel mai adesea folosit n programarea orientat obiect pentru a
desemna funciile sau operatorii care pot fi aplicai mai multor categorii diferite de obiecte. Un
aspect al polimorfismului este capacitatea utilizrii unei funcii n mai multe obiecte diferite, fr
a fi necesar un nume nou de funcie pentru fiecare obiect.
Limbajul Visual C++ permite suprancrcarea numelui unei funcii, ceea ce nseamn
c aceasta poate avea mai multe definiii. Compilatorul determin funcia care trebuie apelat n
funcie de lista de parametri.

52
Domeniu
Domeniul unei variabile se refer la vizibilitatea acesteia ntr-un program. Un
identificator folosit pentru a denumi o variabil sau o funcie, are un anumit domeniu atunci cnd
este creat, iar acest domeniu determin modul i locul n care poate fi folosit respectivul nume.
Dac o variabil se afl n domeniu ntr-un anume punct din program, atunci este vizibil i
poate fi folosit n majoritatea cazurilor. Dac variabila se afl n afara domeniului atunci nu este
vizibil i programul nu o va putea folosi.
n general, un program trebuie s foloseasc variabile al cror domeniu s fie ct mai
redus posibil. Cu ct domeniul este mai restrns, cu att sunt mai mici ansele unei utilizri
accidentale a unui identificator sau expunerii acestuia la efecte colaterale. De exemplu,
ntotdeauna este mai indicat transferul obiectelor ca parametrii ai unei funcii dect utilizarea
variabilelor globale. Utilizarea variabilelor locale pentru o anumit funcie contribuie la
capacitatea de reutilizare a funciei i elimin problemele de sincronizare ntr-un mediu cu
execuii simultane cum este Windows.
Domeniul de definiie al unui nume prin care se identific o entitate a unui program este
zona din program n care numele este cunoscut i poate fi folosit. Dat fiind c un nume este fcut
cunoscut printr-o declaraie, domeniile numelor se difereniaz n funcie de locul n care este
introdus declaraia n program. Un nume declarat ntr-un bloc este local blocului i poate fi
folosit numai n acel bloc, ncepnd din locul declaraiei i pn la sfritul blocului i n toate
blocurile incluse dup punctul de declaraie.
Argumentele formale ale unei funcii sunt tratate ca i cnd ar fi declarate n blocul cel
mai exterior al funciei respective. Un nume declarat n afara oricrui bloc are ca domeniu
fiierul n care a fost declarat i poate fi utilizat din punctul declaraiei pn la sfritul fiierului.
Numele cu domeniu fiier se numesc nume globale.
Un nume este vizibil n ntregul su domeniu de definiie dac nu este redefinit ntr-un
bloc inclus n domeniul respectiv. Dac ntr-un bloc interior domeniului unui nume se
redefinete (sau se redeclar) acelai nume, atunci numele iniial (din blocul exterior) este parial
ascuns, i anume n tot domeniul redeclarrii. Un nume cu domeniu fiier poate fi accesat ntr-un
domeniu n care este ascuns prin redefinire, dac se folosete operatorul de rezoluie pentru nume
globale (::). Redefinirea unui nume este admis numai n domenii diferite. Dac unul din
domenii este inclus n cellalt domeniu, atunci redefinirea provoac ascunderea numelui din
domeniul exterior n domeniul interior. Redefinirea n domenii identice produce eroare de
compilare.
O entitate este creat atunci cnd se ntlnete definiia sa (care este unic) i este distrus
(n mod automat) cnd se prsete domeniul ei de definiie. O entitate cu nume global se
creeaz i se iniializeaz o singur dat i are durata de via pn la terminarea programului.
Entitile locale se creeaz de fiecare dat cnd execuia programului ajunge n punctul de
definire a acestora, cu excepia variabilelor locale declarate de tip static, care se iniializeaz o
singur dat la prima execuie a instruciunii. O variabil global sau static neiniializat
explicit, este iniializat automat cu 0.
Domeniul unui identificator intr n aciune la fiecare declarare a unui identificator.
Tipurile de domenii disponibile ntr-un program C++ sunt urmtoarele:
- Domeniu local
Exist mai multe categorii de domenii locale, cel mai simplu exemplu de domeniu local
reprezentndu-l o variabil sau un alt obiect care este declarat n exteriorul oricrei funcii. Cnd
variabila se afl n domeniu, de la punctul n care a fost declarat i pn la finalul fiierului
surs, acest tip de domeniu local este denumit domeniu fiier. Toate declaraiile care survin n
exteriorul definiiilor de clase sau funcii au acest tip de domeniu.
Variabilele declarate n interiorul corpului unei funcii au domeniu local. Acestea sunt
vizibile numai n interiorul funciei.
O alt categorie de domenii locale este domeniul bloc, unde o variabil din interiorul
unei instruciuni compuse sau al unui alt bloc este vizibil pn la captul blocului. Variabilele
53
declarate n interiorul instruciunilor condiionale au de asemenea domeniu tip bloc.
- Domeniu tip prototip de funcie - acest domeniu exist numai n interiorul unui
prototip de funcie, fiind extrem de limitat. O variabil cu astfel de domeniu, este n
realitate numai o variabil definit ntr-un prototip de funcie, al crei domeniu se
ncheie la finalul prototipului.
- Domeniu tip funcie - acest tip de domeniu este rar ntlnit. Conceptul care a stat la
baza sa este desemnarea etichetelor declarate n interiorul definiiei unei funcii.
Limbajul C++ nu accept saltul la o etichet situat n exteriorul funciei curente i
respectiv c acelai nume de etichete pot fi folosite n mai multe funcii.
- Domeniu tip clas - numele unui membru tip clas, uniune sau structur este strns
asociat cu clasa respectiv i are domeniu tip clas. Un identificator cu domeniu tip
clas poate fi folosit n interiorul clasei, uniunii sau structurii. Dac numele unei clase
sau al unei variabile este utilizat pentru a controla accesul la un identificator, atunci
acesta este vizibil i n afara clasei.

Durata de via a unui identificator
ntr-un program Visual C++, fiecare variabil sau obiect are o anumit durat de via,
care este separat de vizibilitatea sa. Astfel, programatorul are posibilitatea controlrii
momentului crerii i a distrugerii unei variabile.
Durata de via a unui identificator este foarte important n conceperea unui program.
Obiectele de dimensiuni mari pot fi costisitor de creat, dar i de distrus.
O variabil poate fi ascuns de ctre alt variabil avnd acelai nume, dar nu un alt
domeniu, ceea ce nseamn c este posibil ca o variabil s existe i n afara domeniului propriu.
Aceasta se ntmpl deseori atunci cnd numele unei variabile este folosit n domenii tip bloc sau
clas i mascheaz o alt variabil care folosete aceleai nume.
O variabil declarat static ntr-o funcie este creat la nceputul programului i nu este
distrus nainte de ncheierea acestuia. Acest fapt este util cnd se dorete ca variabila sau
obiectul s-i aminteasc valoarea ntre dou apelri ale funciei.

2.1.3.2. Clasele de baz MFC
Biblioteca de clase MFC poate fi mprit pe trei nivele. La primul nivel se afl clasele
care descriu comportamentul obiectelor grafice i ncapsuleaz funciile API (Application
Program Interface).
Aceste obiecte (cum ar fi de exemplu ferestrele, butoanele, fonturile, contextul dispozitiv,
etc.) sunt create i accesate de ctre programatorii Windows prin intermediul unor funcii sistem.
Prin urmare clasele din MFC de la acest nivel ncapsuleaz practic obiectele i funciile care le
sunt ataate existente n API Windows, oferind un grad ridicat de abstractizare.
La al doilea nivel se afl clasele care nu depind de sistemul de operare Windows i care
implementeaz structuri fundamentale de date (liste, tablouri, dicionare, iruri de caractere,
dat calendaristic etc.).
Un mediu de lucru al aplicaiilor este o colecie de componente soft (clase, macro-uri,
funcii globale) care pot fi utilizate n realizarea unei aplicaii generice.
Biblioteca de clase MFC include un mare numr de clase corespunztoare programrii n
Windows. Majoritatea acestor clase sunt derivate din CObject, clas care se afl la rdcina
ierarhiei de clase din MFC. Suplimentar, orice clas care reprezint o fereastr sau un control
este derivat din clasa CWnd, care manevreaz funciile de baz comune tuturor ferestrelor.
Clasele CObject i CWnd utilizeaz funciile virtuale, care permit programului s
acceseze funcii de uz general, prin intermediul unui pointer de baz. Aceasta permite utilizarea
cu uurin a oricrui obiect derivat din CObject sau CWnd la interaciunea cu cadrul de lucru
MFC.
Clasa de baz CObject
Aproape orice clas utilizat ntr-un program MFC este derivat din CObject. Clasa
54
CObject asigur patru tipuri de servicii:
diagnosticarea gestiunii memoriei furnizeaz mesaje de diagnostic la detectarea unor
pierderi de memorie (memory leak). Aceste pierderi sunt adeseori provocate de euarea
operaiei de eliberare a unor obiecte create dinamic;
suportul crerii dinamice folosete clasa CRuntimeClass pentru a permite crearea
obiectelor la rularea programului. Aceast operaie este diferit de crearea dinamic a
obiectelor utiliznd operatorul new;
suportul de serializare permite stocarea i ncrcarea unui obiect ntr-o modalitate
orientat-obiect;
informaia de clas runtime (n timpul execuiei). Biblioteca de clase MFC folosete
informaia de clas runtime pentru a oferi informaie de diagnosticare la detectarea erorilor
n program sau la serializarea obiectelor n sau din spaiul de stocare.

Clasa de baz CWnd
Aceast clas, este derivat din CObject i ofer un grad mare de funcionalitate, propriu
tuturor ferestrelor dintr-un program MFC. Sunt incluse aici i casetele de dialog i controalele,
care nu sunt dect versiuni specializate de ferestre. Clasa CWnd definete funcii care pot fi
aplicate oricrui obiect din CWnd, inclusiv acelor obiecte care sunt exemplare ale claselor
derivate din CWnd.
Clasele de baz CObject i CWnd sunt dou exemple de clase de baz care se utilizeaz
pentru a asigura funciile eseniale ale unui mare numr de clase prin intermediul unei clase de
baz.
Aproape fiecare obiect semnificativ dintr-un program MFC este un exemplar din clasa
CObject. Aceasta permite utilizarea suportului MFC pentru descoperirea multor pierderi
frecvente de memorie i a altor tipuri de erori de programare. De asemenea clasa CObject
declar funcii care pot fi utilizate pentru a oferi diagnosticri n timpul rulrii i suport pentru
serializare.
Fiecare fereastr dintr-un program MFC este un obiect CWnd. Clasa CWnd deriv din
clasa CObject, deci are ncorporate toate funciile acesteia. Utilizarea clasei CWnd pentru
manevrarea controalelor i a ferestrelor din program permite programatorului s beneficieze de
avantajele polimorfismului: clasa CWnd asigur toate funciile generale de fereastr pentru
toate tipurile de ferestre. Aceasta nseamn c n multe cazuri nici nu este necesar cunoaterea
exact a tipului controlului sau ferestrei accesate prin intermediul unui pointer CWnd.
Clasele CObject i CWnd sunt folosite n diverse moduri. Clasa CObject este folosit n
mod normal drept clas de baz atunci cnd programatorul i creeaz propriile clase. Clasa
CWnd este adeseori transferat drept parametru de funcie i este folosit ca pointer generic
pentru orice tip de fereastr ntr-un program MFC.
Cnd este folosit drept clas de baz CObject asigur o mare parte din funciile de baz
pentru o alt clas. Se poate controla numrul acestor funcii asigurate de CObject utiliznd
funcii macro n declaraia clasei derivate i n fiierele de definire.
Exist patru nivele de asisten asigurate de clasa CObject claselor sale derivate:
\ nivelul de baz, cu detecia pierderilor de memorie, nu necesit funcii macro;
\ asistena pentru identificarea claselor la rulare necesit utilizarea funciei macro
DECLARE_DYNAMIC n declaraia clasei i a funciei IMPLEMENT_DYNAMIC n
definiia clasei;
\ asistena pentru crearea dinamic a obiectelor necesit utilizarea funciei macro
DECLARE_DYNCREATE n declaraia clasei i a funciei macro
IMPLEMENT_DYNCREATE n definiia clasei;
\ asistena de serializare necesit utilizarea funciei macro DECLARE_SERIAL n
declaraia clasei i a funciei macro IMPLEMENT_SERIAL n definiia clasei.
Toate funciile macro ale clasei CObject au un mod de utilizare asemntor. Toate
funciile macro de tip DECLARE au un singur parametru, numele clasei. Funciile macro de tip
55
IMPLEMENT necesit, n general doi parametrii: numele clasei i numele clasei de baz imediat
superioare. Funcia IMPLEMENT_SERIAL reprezint o excepie, deoarece necesit trei
parametrii.
Exist dou moduri de creare dinamic a obiectelor. Prima metod, utilizeaz operatorul
C++ new pentru a aloca dinamic un obiect din spaiul de alocare disponibil. O a doua metod
este folosit n special n cadrul MFC i folosete o clas special CRuntimeClass, i funcia
macro RUNTIME_CLASS. Clasa CRuntimeClass se poate folosi pentru a determina tipul unui
obiect sau pentru crearea unui obiect nou.
Biblioteca de clase MFC ofer mai multe faciliti de diagnosticare, majoritatea aflndu-
se sub forma unor funcii macro folosite numai ntr-o versiune de depanare a programului, care
ofer posibilitatea de a beneficia de avantajele ambelor situaii (rulare i depanare). n faza de
dezvoltare i de testare a programului, se pot folosi funciile de diagnosticare MFC pentru a
verifica existena unui numr minim de erori, dei programul ruleaz cu o suprasolicitare indus
de operaia de diagnosticare. Ulterior, cnd programul este compilat i devine o versiune
utilizabil, aceste verificri sunt eliminate i programul se execut la vitez maxim.
Exist trei funcii macro utilizate frecvent ntr-un program MFC:
+ ASSERT prezint o caset de dialog cu un mesaj de eroare cnd primete o expresie evaluat
drept fals, aceast funcie macro este compilat numai n variantele de depanare;
+ VERIFY funcioneaz exact ca ASSERT, cu deosebirea c expresia evaluat este
ntotdeauna compilat, chiar i n variantele non-depanare, dei expresia nu este testat n
versiunile finale;
+ ASSERT_VALID testeaz un pointer ctre un exemplar din clasa CObject i verific dac
obiectul este un pointer valid ntr-o stare valid. O clas derivat din CObject poate invalida
funcia ASSERT_VALID pentru a permite testarea strii unui obiect.
Funciile macro ASSERT i VERIFY sunt utilizate cu orice expresie, nu numai cu cele
care implic CObject. Dei ambele efectueaz teste pentru a se asigura c expresia evaluat are
valoarea TRUE, exist o diferen important ntre modurile de operare ale acestora. Cnd se
compileaz pentru o versiune final, funcia ASSERT i expresia evaluat de aceasta sunt
complet ignorate n timpul compilrii. i funcia macro VERIFY este ignorat, dar expresia este
compilat i utilizat n versiunea final.
O surs comun de erori n programele MFC este plasarea de coduri importante n
interiorul unei funcii macro ASSERT n loc de VERIFY. Dac acea expresie este necesar
pentru ca programul s lucreze corect, trebuie amplasat n interiorul unei funcii macro
VERIFY i nu ASSERT .
n afara funciilor de diagnosticare i a celor macro, clasa CObject mai declar o funcie
virtual care afieaz coninutul unui obiect n timpul rulrii. Aceast funcie dump, este
utilizat pentru a transmite mesaje cu privire la starea curent a unui obiect ctre o fereastr a
programului de depanare.
Dac se depaneaz un program MFC, mesajele sunt afiate ntr-o fereastr de ieire a
programului de depanare. Se va aduga declaraiei de clas CObiectMeu codul surs, funcia
dump este plasat, de obicei n seciunea de implementare a declaraiei de clas. Deoarece dump
este apelat numai de cadrul de lucru MFC, este de obicei declarat drept protected sau private.
Deoarece funcia dump este apelat numai n variantele de depanare, declaraia este nconjurat
de instruciunile #ifdef i #endif, care elimin declaraia funciei dump pentru versiunile finale.
Clasa CWnd este utilizat n mod normal ca un pointer generic de fereastr, i conine
funcii suplimentare ce pot fi aplicate majoritii ferestrelor. Cele mai des folosite sunt:
ShowWindow, este folosit pentru ascunderea sau afiarea unei ferestre; funcia trebuie s
aib un parametru care s indice modul n care comanda influeneaz fereastra (exist 10
parametrii posibili cei mai frecveni sunt SW_HIDE pentru ascunderea ferestrei i
SW_SHOW, care afieaz fereastra folosind dimensiunea i poziia curent a acesteia);
SetWindowText este utilizat pentru a stabili legenda sau bara de titlu a unei ferestre, dac
fereastra este un control de editare, se returneaz coninutului controlului;
56
GetWindowText returneaz legenda sau bara de titlu a unei ferestre;
MoveWindow este utilizat pentru a preciza noua poziie a unei ferestre sau a unui
control;
SetFont permite definirea corpului de liter utilizat pentru o fereastr, este valabil pentru
toate ferestrele, inclusiv pentru controalele de editare.
GetFont returneaz corpul de liter curent utilizat de o anumit fereastr.

Clasa MFC CString
Clasa CString reprezint o implementare a obiectului iruri tip matrice i a metodelor
aferente acestuia. Aceast clas, creeaz iruri inteligente care pot fi cu uurin adunate, copiate
sau manevrate n alt mod, fr a avea nici una dintre problemele care apar la lucrul cu matricele
de caractere.
Unul dintre marile avantaje ale clasei CString este faptul c un obiect CString se
comport exact ca unul dintre tipurile fundamentale, ca un ntreg. Un obiect CString poate fi
adugat, atribuit sau copiat exact ca un ntreg, ns totui exist anumite funcii membru definite
pentru clasa CString.
Clasa CString ofer o funcie membru GetLength care returneaz numrul de caractere
stocate ntr-un obiect CString. Aceast funcie este util la stocarea de obiecte CString sau la
pregtirea pentru diverse tipuri de date de ieire. Pentru localizarea n interiorul unui obiect
CString a unui caracter sau a unui ir de caractere se poate folosi funcia membru Find. Aceast
funcie este util atunci cnd se caut caracterele de control n irurile de intrare.
Funcia membru SetAt este utilizat pentru a transforma caracterul retur de car (CR) ntr-
un spaiu. Funcia se poate folosi pentru a transforma orice caracter, atta timp ct noul caracter
nu este nul.

2.1.3.3. Clase tip colecie
O clas tip colecie este utilizat pentru a crea obiecte capabile de a stoca alte obiecte, aa
cum este cazul claselor container. Obiectele stocate pot aparine unuia dintre tipurile ncorporate,
cum ar fi int, char sau long, sau pot fi obiecte de tip CStrings. Exist trei tipuri fundamentale de
clase tip colecie coninute de biblioteca de clase MFC.
Matrice. O colecie tip matrice permite stocarea i accesarea datelor utiliznd operatorul
indice sau [ ]. Clasa de matrice este optimizat pentru a permite un acces facil la un anumit
articol din matrice, dac poziia sa este cunoscut. Totui inserarea unui articol n mijlocul
unei matrice poate fi foarte costisitoare sub aspectul timpului de procesare.
Liste. O colecie tip list i stocheaz articolele ntr-o list tip lan (chain-like list), ceea ce
faciliteaz n mare msur adugarea sau eliminarea articolelor, indiferent de amplasarea
acestora. Coleciile tip list au un cap i o coad. Articolele pot fi inserate cu uurin la
capul sau la coada listei. Totui, cutarea unui articol ntr-o list mare poate fi dificil
deoarece articolele din list trebuie testate pentru a gsi un anumit articol; n medie,
aceasta nseamn testarea a aproximativ jumtate din articolele unei liste la fiecare cutare.
Hri. O hart este o colecie ceva mai complex. Fiecrui articol stocat ntr-o hart i este
asociat o cheie unic.
Cheia fiecrui articol este unic i este utilizat pentru accesul la articolul stocat n hart.
Adugarea, eliminarea sau accesarea oricrui articol stocat ntr-o hart este o operaie foarte
simpl; totui este necesar cheia articolului care trebuie recuperat. Aceast cheie este convertit
ntr-un index folosit la accesarea fiecrui articol n parte. Fiecare cheie este convertit mai nti
ntr-o valoare codificat (hash value), care este folosit apoi ca indice ntr-o matrice cu articolele
coleciei, cunoscut sub numele de tabel de codificare (hash table). Dimensiunea acestui tabel
se poate specifica la crearea hrii; un tabel de mari dimensiuni impune spaiu de stocare mrit,
n timp ce un tabel redus mrete posibilitatea ca dou chei s genereze valori codificate egale,
proces cunoscut sub numele de coliziune. Clasele MFC tip hart trateaz coliziunile prin crearea
unor liste de articole care au chei egale.
57
Cele trei tipuri de colecie sunt disponibile n versiuni ablon i non ablon. Versiunile
non-ablon, specific un anumit tip de articol care urmeaz a fi stocat n colecie.
Clasele tip colecie MFC ofer o mare varietate de colecii care se pot folosi n programe
MFC. Clasele tip colecie sunt furnizate ca parte a bibliotecii de clase, deci utilizarea acestora
necesit foarte puin efort de scriere din partea programatorului. Reutilizarea acestor clase
permite economisirea a mii de linii de cod n aplicaii.
Colecia CList
Este folosit adeseori atunci cnd o colecie de articole este utilizat ca un lan de articole
nrudite, de exemplu dac se dorete accesarea articolelor de la nceputul sau de la sfritul listei.
Colecia CList permite adugarea de articole la nceputul i la sfritul listei. Pentru a insera un
articol n capul unei liste din CList, se folosete funcia membru AddHead.
Pentru a traversa sau a examina fiecare articol stocat ntr-o colecie, este utilizat o
variabil POSITION. O variabil POSITION este asemntoare unui cursor ntr-un program de
procesare a textelor. Prin apelarea funciei membru GetHeadPosition variabila POSITION este
plasat exact anterior primului articol stocat n list. Funcia membru GetNext execut dou
operaii: returneaz urmtorul articol stocat pe list i avanseaz variabila POSITION ctre
urmtorul articol din CList. Dac aceast variabil are valoarea NULL, atunci nu mai exist
articole n CList.
Toate clasele tip colecie dispun de o funcie RemoveAll, care este utilizat pentru a
nltura i a terge toate articolele stocate ntr-o colecie.

Clasa tip colecie CArray
Clasa CArray este utilizat pentru a crea colecii care sunt mai utile dect matricele
ncorporate n C++. Clasa CArray asigur verificarea de domeniu, sub form de apeluri ale
funciei ASSERT la compilarea programului, cu activarea opiunilor de depanare. De asemenea,
permite dezvoltarea dinamic a matricei la adugarea de elemente noi, aspect imposibil n cadrul
matricelor ncorporate.
Numrul de articole stocate n CArray poate fi furnizat prin apelarea funciei membru
GetSize, accesul la diverse articole stocate n CArray poate fi realizat folosind operatorul de
indexare (_), ca i n cazul matricelor ncorporate. Funcia GetSize se folosete pentru garantarea
faptului c articolul respectiv exist, iar dac nu exist certitudinea stocrii unui anumit membru,
se va folosi n schimb funcia GetAt.

Clasa tip colecie CMap
Clasa CMap este folosit pentru crearea coleciilor care se indexeaz folosind o cheie
unic pentru fiecare articol stocat n colecie. Fiecare articol stocat n colecie trebuie s aib o
cheie unic; dac se ncearc stocarea a dou articole cu aceiai cheie, primul articol va fi
nlocuit de ctre al doilea articol.
Clasa tip colecie CMap este ideal pentru stocarea articolelor care dein numere de
identitate sau de serie unice. De exemplu, mrcile salariailor, seria mpreun cu numrul
buletinului de identitate sau indicii ISBN ai crilor reprezint toate exemple bune de chei,
deoarece sunt n mod garantat unice.
Lista de parametri ai ablonului CMap este mult mai complicat dect listele de
parametrii folosite pentru CList i CArray. Primii doi parametrii sunt folosii pentru tipul de
cheie. Primul parametru reprezint tipul de cheie folosit ca argument n funciile membru.
Urmtorii doi parametrii se refer la articolul stocat n colecie. Al treilea parametru
reprezint tipul de articol stocat n colecie, iar al patrulea parametru reprezint tipul de articol
folosit ca argument n funciile membru.
Funcia membru SetAt este folosit pentru stocarea unui articol i a unei chei n colecia
CMap. Funcia membru CMap este adesea folosit pentru recuperarea unui articol din colecie,
n funcie de o anumit cheie. n coleciile de mari dimensiuni, CMap este cu mult mai rapid
dect CList sau CArray n materie de cutare, inserare sau tergere a unui articol arbitrar, n
58
funcie de o cheie.
Cutarea ntr-o CMap este foarte asemntoare cu procesul analog ntr-o CList. Funcia
membru GetStartPosition returneaz o variabil POSITION care este avansat ctre articolul
urmtor folosind funcia membru GetNextAssoc. Totui, n afar de valoarea cheii, nu exist nici
o ordine a articolelor stocate ntr-o CMap. Dac CMap este traversat folosind funcia
GetNextAssoc, articolele din colecie sunt returnate n funcie de structura intern a CMap, i nu
n funcie de ordinea n care au fost inserate.


2.2. UTILIZAREA BAZELOR DE DATE, PROGRAMAREA OLE I COM

2.2.1. Utilizarea bazelor de date

Organizaiile cu profil economic acumuleaz o cantitate mare de informaii n urma
activitilor comerciale de zi cu zi. Sunt nregistrate detalii despre clieni i furnizori, despre
vnzri i necesarul de stocuri etc. Marea majoritate a corporaiilor opteaz pentru stocarea
acestor date vitale n cadrul bazelor de date sau, mai exact, ntr-un DMS
(DataManagementSystem - sistem de gestionare a bazelor de date). Un sistem de gestionare
a bazelor de date este un produs software care stocheaz datele ntr-o structur bine organizat i
ofer mijloace eficiente de accesare i actualizare a acestor date.
Exist dou tipuri de baze de date: baze de date relaionale i baze de date obiectuale.
Diferena dintre ele provine din modul conceptual n care sunt gestionate datele.
Bazele de date relaionale au la baz tipuri de date simple, recunoscute (caractere,
iruri, ntregi etc.) i nu permit crearea unor noi tipuri de date.
Bazele de date obiectuale opereaz cu tipurile de date la un nivel mai nalt, permind
crearea prin definire a unor noi tipuri de date. Aceste obiecte corespund celor create ntr-un
limbaj orientat-obiect, de exemplu un obiect stocat ntr-o baz de date obiectual ar putea fi o
persoan sau un automobil.
Exist mai muli productori care ofer baze de date relaionale, fiecare baz de date are
propria sa structur i, n consecin, un set propriu de funcii API. Din ce n ce mai mult se cere
ca aplicaiile s poat lucra cu orice baz de date. Pentru a putea dezvolta aplicaii care s
utilizeze o baz de date relaional, indiferent de productorul acesteia, este nevoie de o metod
generic de programare. O astfel de metod exist i se numete ODBC (Open Database
Connectivity - conectivitate deschis a bazelor de date).
ODBC aduce o interfa de programare standard prin care pot fi utilizate diferite tipuri de
baze de date relaionale. n acest scop este necesar existena unui intermediar care s traduc
apelurile ODBC standard n apeluri de funcii specifice bazei de date. Acest intermediar este
driverul ODBC, oferit de ctre productorul bazei de date sau de ctre o firm ter specializat
n astfel de produse. ODBC a fost adoptat ca standard i astfel de drivere exist acum pentru
toate bazele de date rspndite.
Procedura de instalare a unor aplicaii Microsoft, precum Office i Visual Studio, permite
instalarea celor mai folosite drivere ODBC produse de Microsoft.
Comenzile sunt transmise driverului ODBC i pasate mai departe bazei de date cu
ajutorul SQL (limbaj structurat de interogare). Acest limbaj a fost dezvoltat anume pentru
accesarea bazelor de date i este acum standardul de facto. Exist aproape tot attea variante de
SQL cte baze de date sunt, fiecare productor aducnd propriile mbuntiri. Dar exist cerine
minime care asigur un set de comenzi care nu sunt standard, deoarece ODBC ofer o metod de
scurt-circuitare ce permite execuia direct a instruciunilor SQL. Utilizarea unor comenzi n
afara standardului nseamn ca aplicaia s-i piard capacitatea de a accesa bazele de date ale
altor productori, tocmai aceast capacitate fiind avantajul major adus de ODBC.
Limbajul structurat de interogare SQL conine trei tipuri de comenzi: DDL, DML i
DCL.
59
Comenzile DDL (Data Definition Language - limbaj pentru definirea datelor) sunt
folosite pentru crearea i modificarea schemelor de baze de date.
Comenzile DML (Data Manipulation Language - limbaj pentru manipularea datelor)
sunt folosite pentru interogarea i manipularea informaiilor.
Comenzile DCL (Data Control Language - limbaj pentru controlul datelor) sunt folosite
pentru acordarea unor drepturi de acces specifice diferiilor utilizatori.
Prima sarcin legat de utilizarea ODBC este configurarea unei surse de date. O surs de
date indic programului unde se afl fiierele care conin baza de date i ce driver ODBC trebuie
folosit pentru interpretarea administratorului ODBC pentru sursele de date, accesibil din panoul
de control.


2.2.2. Noiuni de programare OLE i COM

Complexitatea crescnd a dezvoltrii aplicaiilor n cadrul unor medii complexe, aa
cum este Windows, cu multele sale interfee de programare a aplicaiilor (API), precum i nevoia
de standardizare, de control al versiunilor, de accelerare a dezvoltrii i de calcul distribuit, au
dus la apariia unei tehnologii numite programare bazat pe componente.
Urmtorul pas n evoluia COM va fi COM +, Microsoft promite c acesta va simplifica
n bun msur scrierea codului necesar pentru COM, astfel c obiectele COM vor avea un
comportament mai similar cu obiectele C++ i vor putea fi create prin intermediul cuvintelor
cheie new i delete din C++.
Componentele sunt entiti software de dimensiuni mici (asemeni instanelor unei clase)
care efectueaz operaii specifice prin intermediul unor interfee bine definite. Spre deosebire de
instanele claselor, componentele nu sunt legate definitoriu de o instan a unui program sau de
un sistem gazd, pot fi scrise ntr-o multitudine de limbaje, i cu toate acestea, comunic fr
probleme, prin intermediul interfeelor, cu programe i componente implementate n alte limbaje.
Microsoft a dezvoltat aceast tehnologie pn la forma actual, fiind denumit n prezent
Component Object Model (COM) - modelul componentelor obiectuale. Se pot ntlni i ali
temeni nrudii, precum legarea i ncapsularea obiectelor (Object Linking and Embedding-
OLE) sau controale ActiveX. Acestea reprezint implementri particulare ale programrii
COM. Propriu-zis COM este un standard independent de limbaj i de platform care definete
modul n care obiectele pot comunica ntre ele prin intermediul unui protocol acceptat n comun.
Cel mai important element privind obiectele COM l reprezint interfeele acestora;
obiectele propriu-zise nu sunt dect cutii negre care implementeaz o funcionalitate particular.
Pentru a putea s se utilizeze aceast funcionalitate, programele trebuie s respecte un contract
bine definit privind transmiterea parametrilor i obinerea rezultatelor. Acest contract dintre
programul client i obiect se numete interfa.
ntregi biblioteci API pot fi definite i proiectate n termeni de interfa. Dac se dezvolt
o aplicaie client, se poate scrie programul astfel nct s comunice cu un server prin intermediul
acestor interfee acceptate, fr a mai conta ce aplicaie server va fi utilizat. Reciproc, se poate
decide dezvoltarea unor componente de tip server care respect definiiile interfeelor,
comercializndu-le ca alternativ viabil la componentele altor productori.
Interfaa de programare a aplicaiilor pentru mesagerie reprezint un set de interfee
standard pentru obiectele COM. Oricine este liber s scrie obiecte COM care efectueaz operaii
precum stocarea mesajelor, transportul mesajelor i oferirea ctre destinatarii mesajelor a unei
agende de adrese.
Microsoft Exchange este o implementare particular a acestor componente server, dar
exist multe alte implementri. Codul efectiv s-ar putea s difere enorm ntre diferite
implementri, dar toate obiectele COM respect aceleai specificaii de interfa. Aceasta
nseamn c, toi clienii acestor servicii, Microsoft Outlook, pot folosi componentele
compatibile MAPI ale oricrui productor n scopul trimiterii, primirii i stocrii mesajelor. n
60
mod similar, orice productor poate s ofere propriile programe client (i muli o fac) care
folosesc Exchange sau orice alte componente server MAPI, chiar fr a ti ale cui sunt
componentele utilizate. Singura cerin n ceea ce privete componentele client i server este ca
acestea s se apeleze reciproc prin intermediul acestor interfee definite de comun acord, reunite
sub numele de MAPI.

Interfee COM
O interfa este o definiie a unei mulimi de funcii i a parametrilor acestora. Orice
obiect COM dispune de cel puin o interfa, iar n mod frecvent sunt oferite mai multe interfee,
fiecare coninnd propriul su set unic de funcii.
Un obiect COM poate fi scris n orice limbaj care are capacitatea de a suporta aceste
interfee. Unele limbaje sunt mai potrivite n acest sens dect altele, de exemplu JAVA este
foarte potrivit, din cauz c, fiecare obiect JAVA poate avea mai multe interfee, deci se
mapeaz natural peste un obiect COM. Obiectele COM conin codul efectiv aflat n spatele
acestor interfee, astfel c un program care apeleaz o funcie declarat ntr-o interfa va gsi o
implementare ce efectueaz operaia definit de acea funcie n cadrul interfeei respective.
Structura interfeei COM standard este exact aceeai cu structura tabelei de funcii
virtuale din Visual C++, ceea ce nseamn c este posibil s se foloseasc mecanismul tabelelor
de funcii virtuale pentru a defini i implementa interfee COM.
n mod normal, funciile virtuale sunt folosite ca o metod de supradefinire n cadrul unei
clase derivare a unei funcii din clasa de baz. n acest scop este declarat o tabel de funcii
virtuale asociat clasei respective.
Orice instan de memorie a unui obiect C++ are ataat o tabel de funcii virtuale (chiar
dac se poate ca unele tabele s nu conin nici o intrare i deci, s fie vide). Fiecare intrare din
tabel conine un pointer ctre codul care implementeaz o funcie virtual. De fiecare dat cnd
se apeleaz una dintre funciile virtuale ale obiectului, tabela ataat ofer adresa corect,
corespunztoare fie funciei din clasa de baz, fie funciei din clasa derivat.
Declararea unei clase C++ care conine exclusiv funcii virtuale pure, se numete clas de
baz abstract. Nu este posibil instanierea unei clase abstracte, dar aceste clase se pot utiliza
pentru crearea unei definiii de interfa COM compatibil cu C++. La crearea unei instane a
unui obiect COM, un proces server aflat n rulare se va ocupa de iniializarea i gestionarea
acesteia. Procesul server poate fi propriul program client, un DLL ataat, un executabil (.exe)
aflat pe propriul calculator sau un program aflat pe un sistem la distan. Fiecare din aceste
ipostaze diferite se numete context.
Cnd se apeleaz funcii pe baza acestui pointer la interfa, propriul client i obiectul
COM sunt puse n legtur cu ajutorul unui DLL ter, care se numete de intermediere, tehnica
purtnd numele de apel intermediat. Biblioteca de intermediere are n sarcin mpachetarea
parametrilor ntr-un format independent de main, n scopul transmisiei. Este posibil apoi, s
foloseasc apelurile de procedur la distan pentru a apela o funcie a unui obiect COM aflat la
distan. Bibliotecile de intermediere pot fi generate automat, prin crearea definiiilor n limbajul
de definire a interfeelor (IDL) i prelucrarea acestora de ctre compilatorul Microsoft IDL.
Vechea problem a ntreinerii versiunii corecte a aplicaiei este rezolvat printr-o simpl
regul. Odat ce s-a eliberat un obiect COM pentru a fi folosit de utilizatorii de pretutindeni,
versiunile ulterioare trebuie s pstreze ne-alterate interfeele originale. Aceasta nseamn c
noile versiuni ale unui obiect COM trebuie s implementeze interfee suplimentare, fr a le
modifica pe cele originale. Programele client mai vechi, care nu tiu s utilizeze dect interfaa
mai veche, vor solicita n continuare aceast interfa, n timp ce programele client care cunosc
noile faciliti pot s solicite versiunea mai nou de interfa.

Automatizarea OLE
Legarea i ncapsularea obiectelor (OLE) este un termen folosit iniial pentru a descrie
capacitatea de a insera obiecte de diferite tipuri n documente avnd un tip propriu, un exemplu
61
fiind inserarea foilor de calcul Excel n documentele Word.
Documentele care suport operaiile de legare i ncapsulare se numesc documente
compuse. Obiectele inserate pot fi ncapsulate, ceea ce nseamn c pot fi salvate odat cu
documentul, sau legate, ceea ce nseamn c n document va fi inserat o referin la alt fiier
(numit identificator). Acestea sunt cele dou operaii care au dat natere termenului OLE
original.
Semnificaia acestui termen, s-a lrgit ns, incluznd acum tragerea i plasarea OLE i
automatizarea OLE, acestea din urm referindu-se la situaia n care un program poate s
apeleze metodele unui alt program care ruleaz ascuns, fr ca utilizatorul s fie contient de
aceast interaciune.
Un obiect COM care ofer o interfa dispecer conine o tabel de metode (funcii),
evenimente (funcii care utilizeaz apeluri inverse ale clientului n scopul unei notificri a
acestuia) i proprieti (funcii care furnizeaz sau stabilesc valoarea unei anumite variabile a
obiectului COM). Programele client pot s acceseze aceste informaii dinamic (procedeul se
numete legare trzie), n timpul rulrii, pentru a afla detalii privind obiectul de automatizare.
Se poate ntlni termenul de interfa dual folosit n legtur cu COM i OLE. Un obiect
COM poate s implementeze o interfa dual, oferind funciile att printr-o interfa direct
COM, ct i printr-o interfa dispecer. Astfel, programele client pot beneficia de avantajele
ambelor soluii; programele C++ rapide pot s acceseze obiectul direct prin interfaa COM
rapid, iar Visual Basic i limbajele de scriptare pot s acceseze funciile prin interfaa dispecer
mai nceat.

Crearea unui server propriu de automatizare OLE
Multe aplicaii, printre care Word, Excel sau chiar Developer Studio, sunt servere de
automatizare. Acestea pun la dispoziia aplicaiilor client o interfa dispecer care poate fi
utilizat pentru apelarea funciilor proprii, oferind servicii specializate precum verificarea
ortografic.
Visual Basic Scripting, instrumentul utilizat pentru crearea macro-comenzilor, folosete
aceste metode n scopul crerii i manipulrii documentelor din cadrul serverelor de
automatizare. De fiecare dat cnd se scrie o macro-comand pentru unul din aceste programe,
se folosete o versiune redus de Visual Basic care permite apelarea funciilor din interfaa
dispecer a serverului de automatizare respectiv.
Serverele de automatizare sunt asociate de obicei cu un nume inteligibil care poate fi
utilizat pentru determinarea identificatorilor de clas corespunztori, care sunt reinute ntr-un
registru intern, coninnd subchei ce specific identificatorul de clas al serverului de
automatizare respectiv.
Infrastructura unei aplicaii server de automatizare poate fi creat prin intermediul
AppWizard, validnd opiunea Automation din pasul trei din MFC AppWizard.

Servere i containere OLE
Un server OLE este o aplicaie care poate fi lansat n cadrul unei ferestre a unei
aplicaii container. De exemplu, foile de calcul Excel, pot fi inserate i editate n Word. n acest
caz, Word reprezint aplicaia container OLE, iar Excel este aplicaia server OLE.
Se mai ntlnete termenul de document activ, folosit n legtur cu serverele i
containerele OLE, ceea ce este o terminologie relativ nou, legate de ActiveX, care dezvolt
arhitectura container/server OLE pentru a permite obiectelor ncapsulate s ctige controlul
asupra ntregii zone client a containerului (nu doar asupra unui mic cadru) i s manipuleze
direct fereastra, meniurile i barele cu instrumente ale acestuia.
Aplicaiile pot fi concomitent containere OLE i servere OLE, caz n care pot juca ambele
roluri. Word-ul i Excel-ul sunt exemple potrivite n acest sens, deoarece se pot rula Excel i s
se insereze documente Word i viceversa.
Un server complet poate s ruleze ca aplicaie de sine stttoare sau ca obiect inserat, n
62
timp ce mini-serverele pot fi lansate doar din cadrul unui program container. La inserarea unui
obiect server OLE, acesta poate fi editat n interiorul unei suprafee rectangulare care este
mrginit de un chenar gros, haurat, de culoare neagr, numit cadru local. Operaia se numete
activare local i este iniiat prin transmiterea unor indicatori, numii verbe, de la container
ctre server. Atunci cnd nu este activ, cadrul dispare i imaginea afiat este ultima generat
atunci cnd acesta era activ (stocat i reprodus pe baza unui context dispozitiv de tip
metafiier). Atunci cnd este activ, cadrul este afiat, iar la meniul propriu al container-ului sunt
adugate elemente de meniu ale obiectului server.
Datele documentului ncapsulat pot fi serializate de ctre documentul container prin
intermediul funciilor obinuite de serializare. Dac un document ncapsulat este stocat integral
n cadrul documentului compus al aplicaiei client, obiectele legate sunt stocate sub forma unor
simpli identificatori. Un astfel de identificator este un mic obiect care identific n mod unic
locaia datelor propriu-zise i modul de afiare a acestora n cadrul aplicaiei client.
Infrastructura standard pentru servere OLE i containere OLE poate fi creat cu ajutorul
AppWizard, ns cu toate acestea, ntre container i server exist o cooperare complex care
trebuie implementat pentru a asigura funcionarea corespunztoare a ambelor pri. Prin
personalizarea a dou clase adugate pe partea de server i a clasei suplimentare a containerului
se poate implementa suport pentru operaii destul de complexe de editare local la rularea ntr-un
cadru n fereastra unei aplicaii container. Nici serverul i nici containerul nu au voie s cunoasc
tipul obiectului care ncapsuleaz sau al celui coninut. Att timp ct obiectele server i client
respect acelai standard, containerul i serverul pot fi integrate perfect pentru a da utilizatorului
impresia unei aplicaii unitare.


2.3. TIPURI SI STRUCTURI DE DATE. TIPURI DE DATE ABSTRACTE

Studiul datelor cuprinde urmtoarele probleme:
maini pentru stocarea datelor
limbaje de descriere a manipularii datelor
fundamente care descriu ce date putem obine prelucrnd date primare
structuri de reprezentare a datelor
Obiectivele studiului structurilor de date sunt urmtoarele:
explorarea diverselor modaliti de structurare a datelor
identificarea clasei de operaii care pot executate asupra fiecrei structuri
modul de reprezentare n calculator al obiectelor aparinnd structurii respective astfel
inct aceste operaii s poat fi executate ct mai eficient
Scopul studiului structurilor de date este reprezentat de nsuirea i stpnirea urmtoarelor dou
tehnici fundamentale:
proiectarea unor reprezentri adecvate ale datelor
proiectarea i analiza algoritmilor care opereaz cu aceste reprezentri
Orice constant, variabil, expresie sau funcie se caracterizeaz printr-un anumit tip de
date. Prin tip de date se nelege o multime de elemente numite valori sau obiecte, care pot clar
distinse intre ele. ntr-un limbaj de programare, orice constant aparine unui anumit tip de date,
orice variabil poate stoca valori de un anumit tip, orice expresie se evalueaz la o valoare de un
anumit tip i orice funcie ntoarce o valoare de un anumit tip.
Dup modul de definire n raport cu un anumit limbaj de programare, tipurile de date se
clasific n:
tipuri predefinite - limbajul permite folosirea variabilelor de tipul respectiv i furnizeaz
o mulime de operaii predefinite pentru manipularea acestor variabile n cadrul unui
program.
tipuri definite de utilizator
Obiectele unui limbaj de programare sunt:
63
constante: tipul rezult din forma sintactic (modul de scriere) a lor
variabile: tipul rezult prin specificarea n program a unui enun special declaraie
expresii: tipul rezult din tipurile operanzilor i modul lor de compunere cu ajutorul
operatorilor.
funcii: tipul rezult din declaraia funciei (n C - prototip sau semntur).
Declaraia este un enun care asociaz o variabil sau o funcie cu tipul su. Definiia este un
enun care asociaz o variabil sau funcie cu tipul su i aloc spaiu de memorie variabilei sau
corpului funciei respective.
Dupa modul de definire n termenii altor tipuri de date, tipurile de date se clasific n:
tipuri primitive
tipuri derivate
Un obiect poate fi:
- compus: se poate descompune n mai multe componente
- simplu sau scalar.
La rndul su, un tip de date poate fi:
- compus: valorile sale sunt compuse
- simplu sau scalar
Un tip de date este ordonat dac pe multimea valorilor sale se poate defini o relatie de
ordine. n caz contrar, se spune c este neordonat. Un tip de date este ordinal dac pe mulimea
elementelor sale se poate defini o relaie de ordonare liniar (este posibil definirea
predecesorului i succesorului unui element). Un tip ordinal modeleaz o mulime finit sau
numrabil.
Cardinalitatea unui tip T reprezint numrul de valori distincte aparinnd tipului T.
O structur de date se definete ca mulimea de obiecte care alctuiesc un anumit tip,
proprietile obiectelor, relaiile dintre obiecte i operaiile asupra obiectelor. Definiia unei
structuri de date trebuie s conin trei elemente:
i) numele structurii
ii) operaiile asupra structurii
iii) proprietile structurii
Operaiile de baz aplicabile obiectelor unei structuri de date sunt:
- constructori se refer la modul de generare a noi obiecte apartinand structurii
respective;
- destructori se utilizeaz atunci cnd gestiunea obiectelor se face explicit de ctre
programator; elibereaz memoria alocat obiectelor;
- selectori - se refer la modul de accesare a elementelor care compun un obiect compus;
- modificatori se refer la modul de actualizare a elementelor care compun un obiect
compus;
- recunosctori se utilizeaz pentru recunoaterea diverselor proprieti ale obiectelor
aparinnd structurii respective;
- testori se utilizeaz pentru compararea obiectelor aparinnd structurii respective
Proprietile structurii nu descriu modul n care trebuie implementate operaiile structurii.
Cu toate acestea, proprietile unei structuri de date exprim maniera n care trebuie s
funcioneze operaiile structurii, indiferent de modul lor de implementare. Cu alte cuvinte,
proprietile abstractizeaz operaiile de modul lor de implementare. Din acest motiv, noiunea
de structur de date este cunoscut i sub numele de tip abstract de date, iar aceast manier de
definire a structurilor de date se numete abstractizarea datelor.
Formal, o structur de date poate fi definit ca un tuplu S = {D, d, O, P}, unde:
i) D este o mulime de tipuri de date implicate n definirea lui S
ii) d D este tipul de date al obiectelor structurii S
iii) O este mulimea operaiilor definite pe structura S
iv) P este mulimea proprietilor structurii S

64
O implementare a unei structuri de date S este o transfomare care definete modul de
reprezentare a obiectelor aparinnd tipului de date al structurii n funcie de obiectele altei
structuri de date T. Fiecare operaie a lui S trebuie definit n termenii operaiilor lui T
Cele mai ntlnite tipuri primitive n limbajele moderne de programare sunt:
a) tipuri numerice: ele sunt reprezentri ale unor mulimi de numere cunoscute din
matematic, precum N, Z sau R. Vom avea n consecin date ntregi fr semn, ntregi cu semn
sau reali. Numerele ntregi se reprezint intern n calculator sub forma unei succesiuni de bii, cu
ajutorul codului complement (cod complement fa de 2). Numerele reale se reprezint intern n
calculator cu ajutorul reprezentrii n virgul mobil (flotant), care cuprinde semnul, mantisa i
exponentul. Pentru a reprezenta corect i numerele subunitare, se utilizeaz reprezentarea cu
semn, caracteristic i exponent.
b) tipul caracter: este destinat reprezentrii caracterelor alfanumerice. Tipul caracter
modeleaz mulimea finita a tuturor caracterelor afiabile. Din nefericire, nu exist un set
standard de caractere specific tuturor sistemelor de calcul. Din acest motiv, termenul "standard"
trebuie interpretat n acest context ca referindu-se la sistemul de calcul particular pe care este
executat programul n cauz. Cel mai folosit set "standard" de caractere este cel definit de
Organizaia Internaional pentru Standarde (ISO) i anume versiunea sa american (codul
ASCII), care const din 128 de caractere, dintre care primele 33 sunt caractere de control i
celelalte 95 sunt caractere afiabile.Caracterele sunt codificate intern prin valori ntregi numite
coduri. Deoarece codul ASCII are 128 de caractere, pentru codificarea caracterelor sale sunt
suficieni 7 bii. Cu toate acestea se folosete pentru codifiare un octet, deoarece memoria intern
a sistemelor de calcul este structurat de obicei sub forma unei secvene de locaii cu
dimensiunea de un octet.Pentru seturile cu peste 256 de caractere, a fost introdus specificaia
standard Unicode (cum este cazul limbii chineze sau japonenze), pentru reprezentarea creia se
folosesc doi octei.
c) tipul logic: este destinat reprezentrii mulimii valorilor logice fals i adevrat.
d) tipul enumerare: este destinat reprezentrii unei mulimi finite de valori, fiecare
valoare fiind desemnat printr-un nume simbolic. Se utilizeaz de obicei atunci cnd este
necesar definirea unui tip de date prin indicarea explicit a elementelor sale. Elementele unui tip
enumerare se reprezint intern prin codificare cu ajutorul unor constante ntregi.
e) tipul subdomeniu: este destinat reprezentrii unui interval al unui tip ordonat liniar.
Tipurile subdomeniu se utilizeaz de obicei pentru reprezentarea indicilor tablourilor.
f) tipul referin: este destinat reprezentrii adreselor altor obiecte. Tipul referin se
utilizeaz de obicei pentru implementarea unor obiecte abstracte complexe cum sunt listele i
arborii. Numeroase prelucrri se refer la relaiile dintre obiectele prelucrate i nu doar la valorile
lor. n astfel de cazuri poate fi necesar reprezentarea explicit a acestor relaii. Pentru aceasta
anumite obiecte trebuie s se poat referi la alte obiecte. Este posibil chiar ca un acelai obiect s
fie referit din dou sau mai multe locuri. ntruct copierea valorii obiectului n locul de unde a
fost referit nu este o soluie acceptabil din cauza consumului mare de memorie i dificultilor de
meninere a consistenei, rezult c trebuie apelat la o alt tehnic i anume de a defini n
program obiecte care s poat referi alte obiecte. Pentru aceasta se folosesc tipul referin i
obiectele pointer. O referin la un obiect se implementeaz ca adres a locaiei de memorie,
corespunztoare obiectului respectiv.
Fiind dat un obiect o de tip T , el poate fi referit utiliznd un obiect de tipul referin la T .
Vom nota acest tip prin Ref(T ), definiia sa axiomatic fiind ilustrat n figura urmtoare:


65



Constanta vid desemneaz valoarea unui pointer care nu se refer la nici un alt obiect
(o referin vid).
Tipul referin la T se reprezint n limbaj pseudocod prin ref (T) , ca n exemplul
urmtor:
var int x, y
var ref int px
x 10
px ref(x)
y deref(px)

n urma executrii acestei secvene de instruciuni, variabila y primete aceeai valoare ca
i x, adic 10, deoarece px are ca valoare o referin la x.
Un alt exemplu care realizeaz n mod diferit aceeai prelucrare este urmtorul:
var int x, y
var ref int px, py
x 10
px ref(x)
py ref(y)
deref(px) deref(py)

Se obinuiete ca "legturile" create ntre obiecte prin intermediul pointerilor s se
reprezinte grafic. Spre exemplu, efectul executrii secvenei:

var int x
var ref int p1, p2
x 10
p1 ref(x)
p2 ref(x)


se poate reprezenta grafic astfel:

66
O referin la un obiect se implementeaz ca adres a locaiei de memorie,
corespunztoare obiectului respectiv. Operaia ref devine astfel operaia de ncrcare a adresei
unui obiect. Operaia deref se implementeaz utiliznd tehnica adresrii indirecte, prin care o
anumit valoare este interpretat drept adresa unei locaii de memorie de unde se va extrage
valoarea propriu-zis.

Alocare static i alocare dinamic

n cele discutate pn acum, singura modalitate de a crea obiecte a constituit-o declararea
acestora. O declaraie are ca efect alocarea memoriei pentru obiectul respectiv la momentul
compilarii programului, obiectul fiind creat la ncrcarea programului, deci naintea execuiei
sale efective. Aceast modalitate de alocare a memoriei se numete static. Principala
caracteristic a acestui mod de alocare este faptul c obiectele sunt referite n program prin
identificatorul introdus la declararea lor. Acest lucru este posibil deoarece asocierea dintre
identificator i locaia de memorie rezervat obiectului s-a fcut n faza de compilare a
programului.
Obiectele pot fi ns create i la momentul execuiei. Aceast modalitate de alocare a
memoriei se numete alocare dinamic. Un astfel de obiect nu va putea fi ns accesibil prin
program utiliznd un identificator, deoarce momentul execuiei succede momentului compilrii
programului. Din acest motiv, un obiect creat dinamic se numete i obiect anonim.
O modalitate elegant de a accesa obiectele create dinamic o constituie utilizarea tipului
referin. Pentru aceasta se introduce operatorul nou care primete un tip T i creeaz un obiect
aparinnd lui T , ntorcnd o referin la T. Fie mulimea tuturor tipurilor i Ref mulimea
tuturor referinelor. Semntura acestui operator este nou : Ref .
Dac operatorul nou ntoarce referina vid vid, atunci nseamn c obiectul nu a putut fi
creat. Dac valoarea ntoars este p vid, atunci obiectul a fost creat i el poate fi accesat
utiliznd "numele" deref(p).
Operaia invers alocrii dinamice a unui obiect este eliberarea memoriei alocate. Aceast
operaie se poate realiza automat, atunci cnd obiectul respectiv nu mai este referit n program,
sau manual de ctre programator prin apelul operatorului standard elib : Ref . Un exemplu de
folosire este urmtorul:

var int x, y
var ref int p
...
p nou(int)
deref(p) x
x y
y deref(p)
elib(p)


Tipuri de date compuse

Din punct de vedere conceptual, orice obiect compus este un n-tuplu o = (o
1
, o
2
, ..., o
n
),
de obiecte o
i
, 1 i n, fiecare obiect o
i
avnd tipul Ti. Tipul lui o este tipul compus T = (T1, ...,
Tn). Fiecare dintre tipurile Ti poate fi la rndul su primitiv sau compus.
Pentru orice tip compus, pe lng operaiile fundamentale de atribuire i test de
egalitate/inegalitate, se mai definesc de obicei urmtoarele dou:
- operatorul constructor, care construiete un obiect compus o = (o
1
, o
2
, ..., o
n
), din obiectele
componente o
i

67
- operatorul de selecie, care permite accesul att n citire ct i n scriere la fiecare dintre
componentele unui obiect compus

Cele mai des utilizate tipuri de date compuse predefinite de majoritatea limbajelor de
programare sunt:
- tipul agregat
Un obiect agregat, numit i nregistrare sau structur, este un obiect compus ale crui
componente (numite i cmpuri) sunt eterogene (au tipuri diferite) i au fiecare asociat cte un
nume simbolic, folosit n cadrul operaiei de selecie.
Cardinalitatea tipului compus agregat este egal cu produsul cardinalitilor tipurilor sale
componente. La nivelul implementrii, unui obiect agregat i corespunde o zon compact de
memorie a crei mrime rezult din mrimile componentelor obiectului repectiv suma acestora.
Orice referin la un cmp al unui obiect agregat se transform n distana zonei alocate
acestuia fa de nceputul zonei alocate obiectului. Distanele se calculeaz de regul la
momentul compilrii programului. Accesarea unui cmp al un agregat se implementeaz de
regul utiliznd tehnica adresrii relative.

Reprezentarea axiomatic a tipului Agregat


- tipul tablou
Deseori este necesar folosirea unui tip compus ale crui componente sunt toate de
acelai tip. Un astfel de tip se numete omogen. n plus, accesul la componente are loc prin
selectori care sunt elemente ale unei mulimi finite i ordonate liniar. n aceste situaii se va
folosi tipul tablou.
Tipul tablou se definete pornind de la un tip de baz T care modeleaz tipul
componentelor i de la un tip subdomeniu I, care modeleaz mulimea selectorilor, numii n
acest caz indeci. Cardinalitatea tipului tablou se determin ridicnd cardinalitatea tipului de
baz la puterea cardinalitii tipului indecilor.




Reprezentarea axiomatic a tipului Tablou

68

La nivelul implementrii, unui tablou i corespunde o zon contigu de memorie,
caracterizat prin adres de nceput i mrime. S presupunem c min i respectiv max sunt
limitele inferioar i respectiv superioar ale indicilor tabloului T i s presupunem de
aasemenea c pentru reprezentarea unui element al tabloului, aparinnd tipului de baz T , sunt
necesare n cuvinte de memorie. Rezult c zona de memorie alocat tabloului va avea (max-
min+1) x n celule, iar zona n care este memorat elementul T[I] va ncepe la adresa A = B + (I -
min) x n, unde B este adresa de nceput a zonei alocate tabloului.
Accesarea unui element al un tablou se implementeaz de regul utiliznd tehnica
adresrii indexate.
- tipul mulime
Numeroi algoritmi prelucreaz colecii de obiecte n care ordinea elementelor nu
conteaz. n astfel de situaii se recomand folosirea tipului mulime.
Tipul mulime se definete pornind de la un tip de baz T i el reprezint toate
submulimile lui T . Un astfel de tip se mai numete i mulimea putere a lui T.
Pentru reprezentarea intern a obiectelor de tip mulime se folosete de obicei funcia
caracteristic.



Reprezentarea axiomatic a tipului mulime

- tipuri cu variante
n practic este uneori convenabil s se considere c mai multe tipuri diferite sunt
variante ale aceluiai tip. n acest caz se va defini un tip cu variante a crei mulime de valori
este egal cu reuniunea disjunct a tipurilor iniiale. Cardinalitatea unui tip cu variante se
determin ca sum a cardinalitilor tipurilor variante ale sale.


69
2.4. LISTE, STIVE, COZI

Una dintre cele mai simple i mai des folosite structuri de date este lista liniar, cunoscut
i sub numele de list ordonat sau secven. O list liniar const dintr-o niruire de n
elemente X1, X2, ..., Xn, numite noduri, aparinnd de obicei unui acelai tip de baz T.
Proprietile structurale eseniale ale acestui ir se rezum la poziia relativ a elementelor, aa
cum apar ele n cadrul irului, adic:
- dac n>0 atunci X1 este primul nod i Xn este ultimul nod
- daca 1< i< n atunci nodul al i-lea, Xi, este precedat de nodul Xi-1 i urmat de nodul Xi+1.
Ultima proprietate exprima esena accesului secvenial, care afirm c dac se cunoate nodul
curent Xi atunci se poate accesa eficient nodul predecesor Xi-1 i nodul succesor Xi+1.
Exist o mare varietate de operaii ce pot fi realizate asupra listelor liniare. Acestea
includ:
- determinarea lungimii a numarului de elemente - unei liste
- determinarea valorii primului, respectiv ultimului element al unei liste
- descompunerea unei liste n primul element i lista format din restul elementelor, respectiv n
ultimul element i lista restului elementelor
- adugarea unui element la nceputul, respectiv sfritul unei liste
- testarea dac lista este sau nu vid
- parcurgerea listei de la nceput la sfrit sau invers
- determinarea valorii celui de al i-lea element al listei
- modificarea valorii celui de al i-ea element al listei
- inserarea unui element pe poziia i
- tergerea elementului din poziia i
Alegerea setului corespunzator de operaii depinde de aplicaia n care sunt folosite
listele. Restrngerea setului de operaii ne conduce la obinerea unor noi structuri de date gen
list, dintre care unele apar foarte frecvent n aplicaii i din acest motiv au cptat nume
speciale:
- stiva este o list liniar pentru care toate inserrile i tergerile i n general orice tip de
accese au loc numai la unul dintre capetele sale. Acesta se numete vrful stivei, iar cellalt
capat inaccesibil n mod direct se numete baza stivei
- coada este o list liniar n care toate inserarile se fac la unul dintre capete, numit spate, iar
tergerile i citirile au loc la cellalt capt numit faa cozii.
Listele pot fi definite recursiv astfel: o lista este fie lista vid, fie este format din
elementul din capul listei - primul element al listei - i lista format din restul elementelor.
Aceasta definiie ne conduce la definiia axiomatic din figura urmtoare. Am notat cu T tipul
elementelor listei.
70
O list cu n elemente se poate construi prin apeluri repetate ale constructorului cons().
Numrul de elemente ale unei liste se numete lungimea listei.
Listele pot fi reprezentate folosind fie alocarea secvenial, fie alocarea nlnuit.

Reprezentarea listelor folosind alocarea secvenial

Cel mai simplu i mai natural mod de a reprezenta n memorie o list liniar este de a
plasa elementele listei n locaii consecutive, un nod dup altul, folosind n acest scop o structur
de tip tablou. O component a tabloului poate stoca fie un nod al listei, fie un pointer la un nod al
listei.
Accesul la un element din list, parcurgerea listei sau adugarea/tergerea unui element
la/de la sfritul listei se fac cu uurin, n timp ce inserarea/tergerea de elemente din interiorul
listei sunt operaii costisitoare, doarece presupun deplasarea unor elemente.
Reprezentarea unei liste folosind alocarea secvenial folosete un tablou. Alegem n cele
ce urmeaz soluia n care componentele acestui tablou sunt pointeri la informaia util. Aceast
metod de reprezentare are avantajul c lista poate fi eterogen, adic informaiile din noduri pot
aparine unor tipuri diferite. Elementele listei vor ocupa poziiile 1, 2, ..., din cadrul acestui
tablou. n plus, trebuie cunoscut poziia ultimului element din list.
Pentru parcurgerea listei este necesar utilizarea unei variabile numite cursor, care ne
indic poziia elementului curent din list (elementul care trebuie prelucrat). Dac lista este
folosit ntr-o aplicaie n cadrul creia o singur parcurgere a listei este activ la un moment dat,
aceast variabil poate fi adugat la reprezentarea listei. n caz contrar, aceast variabil va
trebui reprezentat separat de list. Vom presupune n continuare c ne aflm n primul caz.
Pentru reprezentarea listei se folosete urmtoarea structur de date, care ncapsuleaz
variabila cursor, poziia ultimului element al listei i tabloul de pointeri n care se aloc
elementele listei.



Reprezentarea listelor folosind alocarea secvenial
71


n cazul alocrii nlnuite, nodurile listei nu vor mai fi plasate n locaii adiacente de
memorie, ci n locaii dispersate. Ordinea relativ a lor se pstreaz prin includerea n cadrul
fiecrui nod a unor informaii de legtur. Spaiul suplimentar de memorie necesar includerii
informaiilor de legtur reprezint preul pltit pentru nlturarea neajunsurilor alocrii
secveniale.
O list liniar a crei reprezentare intern folosete alocarea nlnuit a nodurilor se
numete list nlnuit sau list legat.
Un nod al unei liste poate conine o singur legtur { ctre nodul succesor, caz n care
vom spune c avem o list simplu nlnuit sau dou legturi { ctre nodurile predecesor i
succesor, caz n care vom spune c avem o list dublu nlnuit. Se obinuiete ca informaia de
legtur s fie indicat grafic printr-o sgeat orientat ctre informaia "legat" de informaia
curent. Spre exemplu, lista nlnuit a primelor 3 numere prime este reprezentat grafic n
figura urmtoare:

Pentru a se putea detecta sfritul listei, ultimul nod va conine o legtur nul sau
echivalent vid (reprezentat printr-o celul "tiat" n figur). O alt posibilitate este folosirea
unei structuri n care ultimul nod s indice spre primul, ca n figura urmtoare. O list nlnuit
reprezentat printr-o astfel de structur circular se numete list circular.

Exemplu de list circular

Evident, putem avea liste circulare simple i liste circulare duble.
Pentru reprezentarea informaiei de legtur se folosesc pointeri sau indici (numere ntregi). n
cazul n care informaia de legtur se reprezint prin pointeri, se obinuiete ca nodurile listei s
fie create dinamic. Legturile se vor completa cu valorile pointerilor, obinute n urma operaiilor
de alocare dinamic a memoriei.
72


Exemplu de list creat folosind alocare nlnuit i programul aferent



Dac se realizeaz implementarea listelor nlnuite folosind pointeri i alocare dinamic,
pentru reprezentarea unei liste vom folosi un obiect agregat care conine urmtoarele cmpuri:
lungimea listei, pointerul la primul nod, pointerul la ultimul nod i pointerul la nodul curent
(cursorul).
Pentru ca operaiile de inserare i tergere s se fac la fel pentru orice nod al listei, se
adaug listei dou noduri fictive numite i santinele, plasate la nceputul i la sfritul listei
(naintea primului, respectiv dup ultimul nod al listei). n acest fel, orice nod neredundant al
listei va avea att succesor ct i predecesor.



Reprezentarea listelor simplu nlnuite cu pointeri i alocare dinamic


73
Reprezentarea listelor dublu nlnuite cu pointeri i alocare dinamic



2.5. ARBORI. REPREZENTARE, PARCURGERE

Listele sunt potrivite pentru reprezentarea datelor organizate liniar. Dac ns dorim s
descriem date structurate ierarhic, simpla enumerare a obiectelor componente cu ajutorul unor
liste este insuficient.
Organizarea datelor sub form ierarhic este frecvent ntlnit n cele mai diverse
domenii aplicative. Cteva exemple sunt: organizarea administrativ sau managerial a unei
societi, planificarea meciurilor unei competiii sportive de tip turneu, structurarea unei cri sau
a directorului de fiiere dintr-un sistem de operare, reprezentarea expresiilor aritmetice i logice
ntr-un compilator, n vederea evalurii lor. Generaliznd, orice entitate poate fi descris la un
nivel abstract printr-un obiect primitiv sau la un nivel detaliat sub forma unei ierarhii de obiecte
componente.
Pentru definirea structurilor arborescente o atenie important trebuie acordat relaiei de
"ramificare" sau echivalent "subordonare".
Se numete arbore o mulime A de unul sau mai multe noduri astfel nct:
i) exist un nod special rad(A) A numit rdcina arborelui A
ii) mulimea celorlalte noduri din A cu excepia rdcinii este partiionat n n 0 mulimi
nevide i disjuncte Ai; 1 i n, care sunt la rndul lor arbori. A1...An se numesc subarborii lui
A. Dac ordinea relativ a subarborilor A1...An n punctul ii) al definiiei este important,
spunem c A este un arbore ordonat. n acest caz A
i
este al i-lea subarbore al lui A pentru 1 i
n.
Dac pentru a distinge ntre doi arbori se consider c ordinea subarborilor este
nerelevant, atunci arborii se numesc orientai pentru a sugera faptul c are importan doar
orientarea arcelor (de la rdcin spre rdcinile subarborilor,) nu i ordinea relativ a acestora.
Arborii orientai sunt un caz particular de grafuri orientate. Ei trebuie deosebii de arborescene,
care sunt un caz particular de grafuri neorientate.
Definirea axiomatic a arborilor cu noduri de tipul N este urmtoarea:
74


Un exemplu de creare a unui arbore folosind aceast modalitate de definire este:

















75
Structurile arborescente pot fi reprezentate grafic sau alfanumeric n diverse moduri care
sugereaz n fapt o aceeai structur.


Numrul de subarbori ai unui arbore se numete gradul arborelui.
Maximul gradelor subarborilor corespunztori fiecrui nod al unui arbore se numete
aritatea arborelui. Nodurile cu gradul egal cu 0 se numesc noduri frunz sau noduri terminale.
Celelalte noduri se numesc noduri neterminale.
Rdcinile subarborilor unui arbore cu rdcina X se numesc copiii sau fiii nodului X.
Orice nod este tatl sau printele fiilor si. Copiii unui aceluiai nod printe se numesc frai.
Pentru orice nod X al unui arbore exist o cale unic ce unete rdcina R a arborelui cu
nodul X. Toate nodurile de pe aceast cale, exceptndu-l pe X, formeaz mulimea strmoilor
lui X. Numrul strmoilor lui X plus 1 reprezint nivelul nodului X. Prin nlimea sau
adncimea unui arbore vom nelege nivelul maxim al nodurilor sale.
O mulime de n 0 arbori distinci se numete pdure. Dac ordinea arborilor unei pduri
este relevant atunci avem o pdure ordonat.
Cel mai natural mod de a reprezenta o pdure este folosirea unei liste Lista(Arb(N)).
Se observ c prin eliminarea rdcinii unui arbore se obine o pdure format din subarborii
rdcinii. Rezult c o modalitate elegant de a construi un arbore pornete de la rdcina
arborelui i pdurea subarborilor si. Un astfel de constructor se definete axiomatic astfel:
76
cons_arb : N x Lista(Arb(N)) Arb(N)
Aceast funcie are proprietile urmtoare:
cons_arb(R, vid) = nod_2_arb(R)
cons_arb(R, cons(N,L)) = ad_prim_fiu(N, cons_arb(R,L))
Fiecare nod N al unei pduri se poate eticheta cu o secven de numere (N).
Mulimea acestor secvene luate mpreun sugereaz o structur arborescent. Dac pdurea are
k arbori, rdcinilor li se asociaz numerele 1, 2, ..., k. Dac este secvena asociat unui nod
oarecare de grad m, atunci copiilor li se vor asocia secvenele .1, .2, ..., .m. Aceast metod
de codificare a nodurilor unei pduri se numete notaia Dewey.
Spre exemplu, nodurile arborelui reprezentat axiomatic anterior se codific astfel:
(A) = 1
(B) = 1.1
(C) = 1.2
(D) = 1.3
(E) = 1.2.1
Un caz special de arbore frecvent ntlnit n diverse domenii aplicative este arborele
binar. ntr-un astfel de arbore fiecare nod are maxim doi subarbori; mai mult, cnd este prezent
un singur subarbore, se face distincie ntre subarborele stng i subarborele drept. Se numete
arbore binar o mulime finit de noduri care fie este vid, fie const dintr-o rdcin i
elementele a doi arbori binari disjunci numii subarborele stng i subarborele drept ai rdcinii.
Prelucrarea informaiilor dintr-un arbore implic parcurgerea arborelui. Se numete
parcurgere o metod de examinare sistematic a nodurilor unui arbore astfel nct fiecare nod s
fie vizitat exact o singur dat. Parcurgerea arborilor ne ofer o aranjare liniar a nodurilor, astfel
nct n orice moment vom ti precis care este urmtorul nod care va fi vizitat i prelucrat.
n cazul parcurgerii n lrgime, se prelucreaz mai nti informaia din rdcini, n
ordinea n care arborii apar n cadrul pdurii, dup care sunt prelucrate, de la stnga la dreapta,
nodurile aflate pe primul nivel n arborii pdurii, apoi cele aflate pe al doilea nivel, .a.m.d.
Parcurgerea n lrgime presupune folosirea unei cozi. Iniial coada este vid. Dac att coada ct
i pdurea sunt vide nu se efectueaz nici o prelucrare. Dac pdurea este nevid, se depune
primul arbore al pdurii n coad i parcurgerea continu cu restul pdurii i noua coad. Altfel
(pdurea este vid), dac coada este nevid, se extrage un arbore din coad, se viziteaz rdcina
i se continu parcurgerea cu pdurea subarborilor arborelui extras din coad i cu restul cozii.
n cazul parcurgerii n adncime, copiii unui nod sunt vizitai tot de la stnga la dreapta,
ns trecerea de la nodul curent la fratele din dreapta are loc numai dup ce a fost parcurs tot
subarborele cu rdcina n nodul curent. Pentru a memora informaiile relative la punctul de
revenire (nodul tat i urmtorul fiu neprelucrat al su) se folosete o stiv. Operaia de
parcurgere n adncime decurge absolut la fel ca i cea de parcurgere n lrgime, cu deosebirea
c n locul operaiilor cu cozi se folosesc operaii cu stive. n plus, la parcurgerea n preordine
rdcina este prelucrat naintea parcurgerii subarborilor si, iar la parcurgerea n postordine
rdcina este prelucrat dup parcurgerea subarborilor si.
n cazul arborilor binari este consacrat parcurgerea n adncime. Datorit faptului c un
arbore binar este compus din 3 componente: rdcina R, subarborele stng S i subarborele drept
D, rezult c se pot defini 3!=6 parcurgeri n adncime, simbolizate sugestiv prin urmtoarele
mnemonice: SRD, RSD, SDR, DSR, DRS, RDS. Dintre acestea, doar primele 3 au denumiri
consacrate i anume: inordine, preordine i respectiv postordine. Prefixele in, pre i post
sugereaz ordinea relativ de vizitare a rdcinii n raport cu cei doi subarbori.
Arborii binari se reprezint fie utiliznd alocarea secvenial, fie utiliznd alocarea
nlnuit.
n continuare sunt prezentate grafic cteva exemple de parcurgere a arborilor.


77
Parcurgerea n lrgime a unei pduri



Parcurgerea n adncime(preordine) a unei pduri




78
CAP.3. SISTEME DE OPERARE

3.1. NOIUNI INTRODUCTIVE PRIVIND SISTEMELE DE OPERARE

3.1.1 Definiie i rol

Se poate defini sistemul de operare, ca fiind un set de programe specializate ce asigur
legtura funcional ntre elementele componente ale unui sistem de calcul, controlnd i
coordonnd utilizarea resurselor acestuia ntre diferitele programe de aplicaii ale utilizatorilor.
El acioneaz ca o interfa ntre utilizator i hardware-ul sistemului de calcul, mascnd
complexitatea acestuia.
Rolul su este, pe de o parte, de a crea un mediu n care utilizatorul s poat executa
programe cu mai mult uurin, iar pe de alt parte, de a asigura utilizarea eficient a hardware-
ului. Aceste dou obiective sunt de multe ori contradictorii.
Sistemul de operare furnizeaz instrumentele cu ajutorul crora s fie folosite n mod
corespunztor resursele de baz ale sistemului de calcul (hardware, software, date). Din acest
punct de vedere sistemul de operare poate fi privit ca administrator al resurselor pe care le aloc
n funcie de necesiti programelor i utilizatorilor. Deoarece pot exista multe cereri (uneori
conflictuale) adresate resurselor, sistemul de operare are menirea de a decide strategia de alocare,
astfel nct exploatarea sistemului de calcul s fie corect i eficient.
O alt definiie a sistemului de operare, uor diferit de cea anterioar, pune accentul pe
necesitatea controlului asupra dispozitivelor de intrare/ieire i a programelor utilizatorilor. n
aceast abordare, un sistem de operare este un program de control care urmrete executarea
programelor utilizatorilor pentru a putea preveni eventualele erori, precum i folosirea
necorespunztoare a sistemului de calcul i are deci ca principal sarcin operarea i controlul cu
i asupra dispozitivelor de I/E.
Sistemul de operare poate fi gndit ca o main virtual interpus ntre programele
utilizator i hardware furniznd astfel o main extins mult mai uor de programat dect
hardware-ul brut.
De asemenea, sistemul de operare poate fi gndit ca un sistem care reacioneaz, care
rspunde, la cereri ce sosesc de la programele utilizator (apeluri supervizor + excepii) i de la
dispozitivele periferice (ntreruperi).


3.1.2. Funcii

Un prim set de funcii pe care trebuie s le ndeplineasc un sistem de operare, sunt legate
de rolul su de interfa ntre hardware i utilizatori. Astfel, sistemul de operare trebuie s fie
capabil s asigure:
1) posibilitatea de pregtire i lansare n execuie a programelor de aplicaie;
n acest scop, un sistem de operare trebuie s dispun de cel puin urmtoarele componente:
un editor de texte pentru a introduce i modifica un program surs (PS) scris ntr-un limbaj
de programare;
un translator pentru limbajul de programare folosit (asamblor, compilator sau interpretor),
care s traduc instruciunile programului surs, ntr-o form recunoscut de sistemul de
calcul (forma binar) - program obiect sau module obiect (PO);
un editor de legturi care s realizeze legtura dintre diverse module obiect, sau s apeleze la
module obiect din bibliotecile sistemului, respectiv la modulele obiect din biblioteca
utilizatorului - care au fost catalogate n prealabil, pentru a construi structur pe segmente
impus de sistemul de calcul n vederea execuiei programelor (program obiect executabil-
POE).
79
Odat construit structura pe segmente, programul va fi gata de execuie, ceea ce va implica
ncrcarea acestuia n memoria intern i execuia efectiv; componenta sistemului de operare ce
realizeaz acest lucru se numete ncrctor.
2) alocarea resurselor necesare execuiei programelor prin:
identificarea programelor ce se execut i a necesarului de resurse;
alocarea memoriei interne i a dispozitivelor periferice;
identificarea i protecia coleciilor de date.
3) acordarea unor faciliti prin programe utilitare de interes general:
gestiune cataloage (directoare, subdirectoare) i fiiere;
creare, modificare, copiere, mutare, tergere, recuperare directoare i fiiere;
sortare/interclasare;
depistare i eliminare virui informatici i altele.
4) planificarea execuiei mai multor programe (multiprogramare) dup anumite criterii, n
vederea utilizrii eficiente a unitii centrale (UC);
5) coordonarea execuiei mai multor programe ce se execut simultan, prin urmrirea modului
de execuie a instruciunilor programelor, depistarea i tratarea erorilor, lansarea n execuie a operaiilor
de intrare/ieire;
6) asistarea execuiei programelor de ctre utilizator, prin comunicaia sistem de calcul-
utilizator att la nivel hardware ct i la nivel software;
7) asigurarea organizrii i proectiei datelor n memorie;
8) posibilitatea generrii unui sistem de operare pe msura configuraiei existente.

Un al doilea set de funcii pe care trebuie s le ndeplineasc un sistem de operare, sunt
legate de utilizarea eficient a resurselor sistemului de calcul, lucru ce impune o gestionare
corespunztoare a acestora. Ca urmare, sistemul de operare trebuie s asigure:
1) gestiunea memoriei, care const n:
evidena acestei resurse - ct memorie este alocat i pentru care programe;
crui proces i se aloc memorie, la ce moment i n ce cantitate - n cazul multiprogramrii;
alocarea de pri din memorie i asigurarea demetode de acces i protecie pentru procesele
solicitante;
dezalocarea zonele de memorie alocate.
2) gestiunea procesorului, se refer la:
evidena procesoarelor i strilor acestora;
decide cine poate s utilizeze procesorul, la ce moment de timp i pentru ct timp;
aloc procesorul la un proces prin pregtirea i ncrcarea unor registre hardware;
retrage alocarea cnd procesul renun la utilizarea procesorului, s-a terminat sau a depit
cuanta de timp alocat.
3) gestiunea dispozitivelor periferice, care const n urmtoarele activiti:
evidena dispozitivelor, a unitilor de control i a canalelor de I/E;
decide metoda cea mai eficient de alocare a dispozitivelor periferice;
dac are loc o utilizare simultan, decide cine folosete resursa i ct timp;
alocarea dispozitivelor periferice i iniiaz operaia de intrare/ieire;
dezalocarea dispozitivelor periferice la terminarea execuiei operaiilor de intrare/ieire.
4) gestiunea informaiei, care se materializeaz n:
evidenierea resursei (informaia), localizarea ei, utilizarea, starea, etc.;
decide cine utilizeaz informaia, impune protecia cerut i ofer rutine de acces necesare;
aloc resursele prin deschiderea fiierului;
dezaloc resursele prin nchiderea fiierului.


3.1.3. Componentele sistemelor de operare

Din punctul de vedere al interaciunii cu componentele hardware ale sistemului de calcul
i dup modul de implementare a software-ului, sistemul de operare este organizat pe dou
niveluri: fizic i logic.
Nivelul fizic ofer servicii privind lucrul cu componentele hardware ale sistemului de
80
calcul i cuprinde acele elemente ce depind de configuraia sistemului.
Nivelul logic include partea de programe prin care utilizatorului poate exploata sistemul
de calcul. Comunicarea utilizatorului cu sistemul de calcul se realizeaz prin comenzi adresate
sistemului de operare sau prin intermediul instruciunilor programelor pe care le execut; invers,
comunicarea se realizeaz prin intermediul mesajelor transmise de sistemul de operare ctre
utilizator.
Din punct de vedere funcional, programele sistemului de operare se mpart n dou
categorii:
- programe de comand i control (cunoscute i sub numele de monitoare,
supervizoare sau executive) - care vizeaz optimizarea utilizrii resurselor sistemului
de calcul prin coordonarea i controlul tuturor funciilor acestuia;
- programe de serviciu - care sunt destinate optimizrii accesului la resursele
sistemului de calcul, fiind utilizate de programator pentru dezvoltarea programelor de
aplicaii.
Programele de comand i control, coordoneaz activitatea celorlalte componente ale
sistemului de operare, ndeplinind urmtoarele funcii majore:
- gestiunea resurselor fizice i logice (gestiunea memoriei, gestiunea fiierelor,
gestiunea fizic a intrrilor i ieirilor, gestiunea proceselor, evidena gradului de
utilizare a componentelor, etc.);
- planificarea, lansarea i urmrirea execuiei (planificarea lucrrilor i alocarea
resurselor, evidena lucrrilor executate, a utilizatorilor i a resurselor consumate,
etc.);
- depistarea i tratarea evenimentelor la execuie (evidena erorilor hardware, evidena
ntreruperilor etc.).
Cele mai frecvent utilizate componente ale supervizorului sunt ncrcate n memoria intern nc
de la generarea sistemului de operare, fiind pstrate n aceasta pe tot parcursul execuiei aplicaiilor de
ctre sistemul de calcul; aceste programe se numesc rutine rezidente, i formeaz nucleul sistemului de
operare; celelalte componente rmn n memoria extern fiind apelate i executate numai atunci cnd sunt
solicitate de ctre nucleu (se numesc rutine tranziente) asemenea oricrui program de aplicaie (figura
3.1):

Fig. 3.1 Rutine rezidente i rutine tranziente

Programele de serviciu se execut sub supravegherea programelor de comand i control
i pot fi diferite de la un sistem de operare la altul, sau chiar ntre versiunile aceluiai sistem de
operare. Ele permit utilizatorului s foloseasc resursele fizice i logice ale sistemului de calcul
pentru realizarea aplicaiilor. Cele mai utilizate programe din aceast categorie sunt:
- Translatoarele de limbaje - au rolul de a transforma instruciunile programelor surs
(scrise de utilizatori ntr-un limbaj de programare), n coduri executabile de calculator
(format obiect). Din aceast categorie fac parte:
asambloarele, care au rolul de a traduce programele surs, scrise n
limbaje de asamblare, n programe obiect executabile. Aceste programe
81
sunt specifice unui anumit tip de sistem de calcul fiind determinate de
limbajul main al acestuia.
compilatoarele, care sunt specifice limbajelor de programare de nivel
nalt, independent de sistemul de calcul, asigurnd traducerea
programelor surs n programe obiect.
interpretoarele care analizeaz i execut pas cu pas instruciunile
programului surs, permind o punere mai rapid la punct a programelor.
- Editorul de legturi - are rolul de a transforma modulele obiect (obinute cu ajutorul
translatoarelor) n programe executabile.
- Bibliotecarul - asigur crearea, gestionarea i ntreinerea bibliotecii sistem (care
conine programele sistemului de operare) i a bibliotecilor utilizator. Bibliotecile de
programe sunt colecii de programe organizate sub forma unor fiiere partajate n
scopul utilizrii lor ulterioare;
- Programele de ncrcare - sunt componente ale programelor de serviciu, cu rolul de a
ncrca n memoria intern (RAM), n vederea execuiei, programele obiect
executabile;
- Generatorul sistemului de operare - permite utilizatorului s genereze un sistem de
operare compatibil cu configuraia hardware de care dispune (memorie intern,
echipamente periferice utilizate, tipuri de interfee etc.) i cu modalitile de
exploatare adoptate n funcie de opiunile domeniului de utilizare;
- Depanatorul este un program de serviciu ce ofer utilizatorului mijloace convenabile pentru
depanarea i controlul operaiilor programului.
- Programele de organizare a coleciilor de date - asigur operaiile de intrare /ieire
prin colecii de date (fiiere, baze de date, depozite de date);
- Mediile de programare - sunt programe destinate automatizrii procesului de
construire i testare a programelor. Cu ajutorul mediilor de programare se realizeaz:
editarea, compilarea i, eventual, editarea de legturi, lansarea n execuie i
depanarea unui program;
- Programele utilitare - s-au dezvoltat i diversificat odat cu perfecionarea
calculatoarelor, a modalitilor de exploatare i a domeniilor de aplicare, fiind adesea
incluse n sistemul de operare i destinate s extind funcionalitatea acestuia.


3.1.4. Moduri de operare

Pentru a proteja sistemul de calcul mpotriva unei utilizri necorespunztoare, folosirea
de ctre programele utilizatorilor a anumitor instruciuni main este restricionat, acestea
putnd fi efectuate numai de ctre sistemul de operare. Astfel, programele utilizator nu pot:
- s adreseze dispozitivele de I/E, direct;
- s utilizeze instruciunile care manipuleaz starea memoriei;
- s seteze bitul de mod care determin modul utilizator sau supervizor;
- s opreasc calculatorul (instruciunea Halt).
Instruciunile main respective se numesc instruciuni privilegiate.
Pentru ca sistemul de calcul s se comporte diferit fa de sistemul de operare pe de o
parte, i fa de programele utilizatorilor, pe de alt parte, au fost adoptate dou moduri de
operare distincte, i anume: modul utilizator, n cadrul cruia nu sunt utilizate instruciuni
privilegiate i modul supervizor (numit i mod monitor sau mod sistem) n cadrul cruia toate
instruciunile pot fi executate. Aceast distincie ntre modurile de operare este o consecin a
necesitii realizrii unei protecii fa de utilizarea necontrolat a instruciunilor, i ca urmare,
arhitectura oricrui sistem de operare trebuie s suporte cel puin cele dou moduri: utilizator i
cel supervizor.
Deoarece nucleul reprezint partea protejat a sistemului de operare el ruleaz n modul
82
supervizor, protejnd astfel structurile de date critice ale sistemului de operare i regitrii de
dispozitiv mpotriva programelor utilizator.
Pentru identificarea modului curent de operare se utilizeaz un bit de mod din cadrul unui
registru al unitii centrale, registru protejat. Semnificaia bitului de mod respectiv este: 0 =
supervizor, 1 = utilizator.
Transferul din modul utilizator n modul supervizor poate s se ntmple din cauza
execuiei explicite a unei instruciuni apel supervizor (sau sistem) (numit i SVC sau TRAP)
sau din cauza unei ntreruperi hardware sau a unei excepii. Transferul napoi din modul
supervizor n modul utilizator apare din cauza unei instruciuni return explicite (uzual numit
REI, Return din ntrerupere).


3.1.5. ntreruperi

Necesitatea sistemului de ntreruperi devine evident n momentul n care studiem modul
n care se execut programele. Uzual, procesorul execut instruciunile ntr-o ordine dat de
urmtoarele reguli:
1. dac instruciunea curent este una de salt, va fi executat n continuare instruciunea de
la adresa la care se face saltul;
2. n caz contrar, va fi executat n continuare instruciunea aflat n memorie la adresa
imediat urmtoare dup instruciunea curent.
Ca o concluzie general, ntotdeauna o instruciune care face parte dintr-un program va fi
urmat de o alt instruciune din acelai program. Pn aici nu exist nici o posibilitate de a
prsi programul aflat n execuie dect dac acesta se termin singur. Acest model corespunde
n general cerinelor, deoarece un program aflat n execuie ruleaz n majoritatea timpului fr a
ine cont de existena sistemului de operare, totui, acesta trebuie s poat interveni n anumite
situaii bine definite, cum ar fi:
- o cerere explicit adresat de programul de aplicaie, privind efectuarea unui anumit
serviciu de ctre sistemul de operare, serviciu pe care aplicaia nu-l poate efectua
singur;
- o cerere de ntrerupere venit din partea unui dispozitiv periferic, care poate s nu
aib legtur cu programul aflat n execuie, dar care trebuie tratat imediat (altfel
datele se pot pierde);
- o operaie executat de UC care s-a terminat anormal (de exemplu o operaie de
mprire la zero, depirea de capacitate, un acces anormal la o zon de memorie,
etc.), ceea ce indic ncercarea unui program de a efectua o aciune nepermis.
Sistemul de operare va lsa deci orice program s se execute fr interferene pn la
apariia uneia din situaiile descrise mai sus, dar n acest moment trebuie s preia imediat
controlul. Soluia este, aa cum am precizat deja, de natur hardware i este reprezentat de
sistemul de ntreruperi. Concret, acesta ofer posibilitatea ntreruperii execuiei programului
curent, n anumite condiii, pentru a trata o sarcin considerat ca fiind mult mai urgent.
Fiecreia din situaiile prezentate mai sus i corespunde unul tipurile de ntrerupere:
- ntreruperi software (externe);
- ntreruperi hardware (externe);
- excepii (ntreruperi hardware interne).
Deoarece anumite ntreruperi pot fi mai importante de ct altele ele dovedindu-se deci a
fi prioritare, i ca urmare este necesar stabilirea unei anumite ierarhii de prioriti a acestora.
Unitile centrale ale sistemelor de calcul sunt prevzute cu instruciuni ce autorizeaz
sau interzic ntreruperile n anumite cazuri. Astfel, dac programul aflat n execuie nu trebuie s
fie ntrerupt, luarea n considereare i tratarea ntreruperilor va fi interzis pentru a preveni
perturbarea acestuia. Totui anumite ntreruperi nu vor fi interzise, fie datorit necesitii lor, fie
datorit nivelului lor de prioritate. Exemplul cel mai reprezentativ este cazul ntreruperii datorate
83
ntreruperii tensiunii de alimentare, care nu va fi interzis. Asemenea ntreruperi sunt numite
nemascabile.
Din contr, o ntrerupere se spune c este mascabil cnd exist posibilitatea ca unitatea
central s o ignore. Putem astfel s mascm, la un moment dat, anumite ntreruperi pentru
conservarea derulrii programului n curs fa de orice ntrerupere intempestiv (cu excepia
evident a ntreruperilor nemascabile).
Tratarea unei ntreruperi, indiferent care este cauza care a produs-o, se deruleaz n
general de urmtoarea manier:
- se recepioneaz de ctre unitatea central o cerere de ntrerupere intern sau extern;
- dup acceptarea ei are loc sfritul tratrii instruciunii n curs de execuie;
- se salveaz starea sistemului, adic se salveaz coninutul diverselor regitri
(numrtorul de program, etc.), n aa fel nct s se poat relua execuia programului
ntrerupt din starea n care se gsea la momentul ntreruperii;
- se ncarc numrtorul de program cu valoarea adresei primei instruciuni a sub-
programului (rutinei) de tratare asociat acestei ntreruperi.
- sub-programul de tratare a ntreruperii odat terminat provoac restaurarea strii n
care gsea sistemul la momentul lurii n considerare a ntreruperii.
Evident, rutinele care trateaz situaiile generatoare de ntreruperi fac parte din sistemul
de operare, care poate astfel rezolva problemele aprute.

Apeluri sistem (supervizor)

Una din sursele ntreruperilor, prezentate anterior, o constituie solicitrile formulate n
mod explicit de programele de aplicaii ctre sistemul de operare, pentru efectuarea anumitor
servicii. De ce este ns necesar ca aceste servicii s fie implementate de ctre sistemul de
operare i nu pot fi lsate n seama programelor ? n primul rnd, unele operaii uzuale (afiarea,
cutarea pe disc etc.) se desfoar ntotdeauna n acelai mod; deci, n loc de a scrie practic
aceeai rutin n fiecare program, este mai economic de a o scrie o singur dat ca parte a
sistemului de operare, astfel ca toate aplicaiile s o poat utiliza. De altfel, apelul ctre un
asemenea serviciu oferit de sistem nu se deosebete prea mult de apelul ctre o procedur sau
funcie din acelai program.
Pe de alt parte, o serie de aciuni, n special accesele la dispozitivele periferice, prezint
riscuri considerabile pentru ntregul sistem de calcul n cazul n care nu sunt realizate corect. Nu
este deci convenabil de a permite programelor de aplicaii s realizeze singure aciunile din
aceast categorie; se prefer ca activitile de acest tip s fie ndeplinite numai prin intermediul
unor rutine incluse n sistemul de operare. Pentru a pune n practic o asemenea abordare, trebuie
s se poat interzice pur i simplu realizarea anumitor operaii de ctre programele de aplicaii.
Din nou este necesar un suport hardware.
n acest moment putem studia ce se ntmpl atunci cnd un program cere sistemului de
operare furnizarea unui anumit serviciu. O asemenea cerere poart numele de apel sistem
(system call) i ea reprezint interfaa dintre un program aflat n execuie i sistemul de operare.
Apelurile sistem sunt disponibile att sub forma de instruciuni scrise n limbaj de asamblare, ct
i ca funcii sau subrutine apelabile n cadrul programelor scrise n limbaj de nivel nalt.
Apelurile sistem pot fi generate prin intermediul unei rutine specializate, sau direct, i ele sunt
cerute n mod explicit de ctre un program utilizator pentru a trece din modul utilizator n modul
supervizor.
Apelurile sistem creeaz, distrug i utilizeaz diferite obiecte logice gestionate de ctre
sistemul de operare. Procesele i fiierele sunt cele mai importante obiecte, dar exist apeluri
supervizor i pentru administrarea memoriei, efectuarea de intrri/ieiri pe un terminal sau o
imprimant, etc.
Apelul sistem este tratat de ctre hardawre ca o ntrerupere software, controlul fiind dat
unei rutine a monitorului rezident, iar bitul de mod primete valoarea corespunztoare modului
84
supervizor.
Fiecrui apel sistem i corespunde o procedur de bibliotec pe care programul
utilizatorului poate s o apeleze. Aceast procedur plaseaz parametri de apel supervizor ntr-un
loc predefinit cum ar fi registrele unitii centrale apoi execut o instruciune TRAP (un apel de
procedur protejat ntr-un anumit fel) pentru a activa sistemul de operare. Procedura de
bibliotec are ca scop de a masca detaliile instruciunii TRAP i de a face s apar apelurile
supervizor ca i apeluri de proceduri obinuite. Atunci cnd sistemul de operare preia controlul
dup TRAP, el verific validitatea parametrilor i efectueaz n acest caz tratarea cerut. Cnd a
terminat, sistemul de operare plaseaz un cod de stare ntr-un registru indicnd dac tratarea a
reuit sau a euat, apoi execut instruciunea RET (REturn fromTrap) pentru a reda controlul
procedurii din bibliotec. Aceast procedur red controlul apelantului (programului utilizator) i
retrimite codul de stare ca o valoare de retur a funciei. Anumite valori complementare sunt de
asemenea returnate n parametrii de apel.
Numrul i tipul apelurilor sistem variaz de la un sistem de operare la altul.

^ Excepii
Multe dintre erorile de programare pot fi detectate de ctre hardware i sunt controlate, n
mod normal, de ctre monitorul rezident. Dac ntr-un program apare o instruciune nepermis
sau o greeal de adresare a memoriei, hardware-ul va genera o ntrerupere ctre monitorul
rezident, numit excepie ce va determina comutarea din modul utilizator n modul supervizor.
Aa cum s-a artat, termenul de excepie este folosit pentru a desemna o ntrerupere hardware
intern, generat de obicei ca urmare a apariiei unei erori de program cum ar fi: ncercrare
efecturii unei mpriri cu zero, utilizarea unei adrese de memorie ilegale, scrierea ntr-o locaie
de tip read-only, etc. Acionnd ca o ntrerupere, aceasta va determina memorarea codului
program asociat ultimei instruciuni executate i va da controlul unei rutine de tratare a excepiei
din monitorului rezident. nainte de a aborda urmtorul program, monitorul va executa n mod
automat un vidaj de memorie i de registre, care poate fi utilizat pentru depanarea programului
abandonat.


3.2. PROCESE CONCURENTE

3.2.1. Noiunea de proces

n cadrul sistemelor de operare moderne, se consider ca unitate de lucru, procesul
secvenial. Acesta, definit ca entitate activ, este reprezentat de un program aflat n execuie
mpreun cu datele sale i cu toate celelalte informaii necesare execuei, instruciunile fiind
parcurse una cte una, la momente de timp diferite.
Trebuie fcut deosebirea dintre proces i program. Procesul are un caracter dinamic, el
precizeaz o secven de activiti
1
n curs de execuie, iar programul are un caracter static, el
numai descrie textual aceast secven de activiti.
Procesele concurente numite i procese paralele, presupun c la un moment dat, mai multe
programe pot fi urmrite ntre punctul de ncepere i terminare a execuiei; n acest caz procesele
interacioneaz n dou moduri:
- indirect, prin concurarea la aceiai resurs a sistemului;
- direct, prin utilizarea simultan a acelorai resurse.





1
Activitatea (task) este o unitate de lucru intern creat de sistemul de operare, atunci cnd o etap din lucrare este
acceptat de sistemul de calcul. Lucrarea reprezint o colecie de activiti ce se execut de ctre sistemul de calcul.
85
3.2.2 Strile unui proces

Pe durata execuiei lor procesele trec printr-o serie de stri discrete, o stare fiind definit
ca o activitate curent a procesului. Aceste stri sunt:
- starea de execuie (running) - un proces n starea de execuie are alocate toate resursele
necesare rulrii, inclusiv UC-ul. n cazul unui sistem cu un sigur procesor, vom avea un
singur proces activ la un moment dat n sistem. Procesul curent activ execut secvena sa
de instruciuni main, putnd cere sistemului de operare servicii ca operaii I/E sau
sincronizare printr-un semnal. Depinde de politica de planificare dac sistemul returneaz
controlul acestui proces dup terminarea serviciului sau alege un altul (din procesele n
starea pregtit) pentru execuie;
- starea gata de execuie (ready) - un proces este n starea pregtit (gata de execuie) cnd
are alocate toate resursele de care are nevoie, cu execepia UC-ului. De obicei, n aceast
stare ajung procesele imediat dup creare. Toate procesele n starea gata de execuie
ateapt ca sistemul de operare s le aloce UC-ul. Un modul al sistemului de operare,
numit planificator, alege unul din aceste procese ori de cte ori UC-ul devine liber pentru
a rula un nou proces.
- starea blocat (blocked) - procesul se afl n ateptarea realizrii unui eveniment (de
exemplu, terminarea unei operaii de I/E).
Schimbarea strii unui proces poate fi determinat fie de procesul nsui (de exemplu prin
efectuarea unui apel sistem), fie datorit apariiei unui eveniment extern (de exemplu cnd
unitatea de comand genereaz o ntrerupere de ceas).
S considerm un sistem cu o singur unitate de central. La un moment dat aceasta poate
executa un singur proces, dar mai multe procese pot fi gata de execuie iar altele pot fi blocate.
Din acest motiv se stabilete o list a proceselor gata de execuie i o list a proceselor blocate.
Lista proceselor gata de execuie este inut n ordinea prioritilor astfel nct primul proces ce
va intra n prelucrarea unitii de comand va fi primul din list. Lista proceselor blocate este
neordonat deoarece aceste procese nu se vor debloca n ordinea din list ci n ordinea n care se
vor finaliza evenimentele ce au determinat blocarea lor. Exist situaii n care mai multe procese
pot fi blocate ateptnd realizarea aceluiai eveniment, n acest caz fiind necesar introducerea
unor prioriti.
Cnd un proces este creat el este trecut la sfritul listei proceselor gata de execuie. Pe
msur ce procesele intr n execuie, lista lor se decaleaz ctre nceput. Al doilea proces va lua
locul primului, al treilea va lua locul celui de-al doilea, .a.m.d. Cnd procesul trece n capul
listei i cnd unitatea de comand a devenit disponibil pentru a-l prelua, se spune despre proces
c se gsete n starea de tranziie de la starea gata de execuie la starea de execuie. Dup cum
am mai spus, un proces este format din cod i date, fiind caracterizat de atribute i stare
dinamic. Atributele asociate unui proces pot fi asignate de ctre programator sau de ctre
sistemul de operare i includ prioritatea i drepturile de acces. Prezentm mai jos diagrama de
tranziie a strilor proceselor (figura 3.2):











Fig 3.2. Strile de tranziie ale unui proces
Blocked Ready

Running
Block Dispatch
Wakeup
Timerrunout
86
Operaia de asignare (atribuire) a unitii de centrale ctre primul proces gata din lista
proceselor gata de execuie se numete expediere (dispatch) i este executat de o entitate a
sistemului de operare numit expeditor (dispatcher). Aceast stare de tranziie se indic astfel:
dispatch (nume_proces): ready running
Pentru a preveni situaia n care un singur proces s monopolizeze sistemul de calcul,
sistemul de operare este prevzut cu o component software numit ceas de control care permite
execuia procesului un interval de timp bine precizat. Dac procesul nu elibereaz unitatea de
comand naintea expirrii timpului, ceasul de control genereaz o ntrerupere care permite
unitii de centrale s treac procesul din starea de execuie n starea gata de execuie i s
lanseze n execuie primul proces din lista celor gata de execuie.
Aceast stare de tranziie se indic astfel:
timerrunout (nume_proces_1): running ready
i
dispatch (nume_proces_2): ready running
Dac procesul aflat n execuie lanseaz o operaie de I/E naintea expirrii intervalului de
timp ce i-a fost alocat, atunci el va trece n lista proceselor blocate, urmnd ca primul proces din
lista celor gata de execuie s fie lansat n execuie. Aceast stare de tranziie o precizm astfel:
block (nume_proces_1): running blocked
i
dispatch (nume_proces_2): ready running
n cazul n care operaia de I/E s-a terminat, procesul este trecut din starea blocat n starea
gata de execuie. Starea de tranziie este:
wakeup (nume_proces_1): blocked ready
Un proces ajunge n starea suspendat cnd are nevoie de o resurs pe care sistemul de
operare nu i-o poate nc aloca, cnd invoc o rutin I/E sau ateapt un semnal care nu s-a
produs nc. Astfel de procese ies afar din competiia pentru UC pn cnd condiia de
suspendare dispare. Sistemul de operare nregistreaz motivul suspendrii pentru a putea relua
procesul mai trziu, cnd condiia de suspendare dispare datorit aciunii altor procese sau
apariiei unui eveniment extern. Dup apariia evenimentului, se poate ntmpla ca UC s nu
execute acest proces, ntruct n sistem exist un altul cu prioritate mai mare.
La un moment dat, procesele din sistem se pot afla n diverse stri, totalitatea acestora
definind starea global a sistemului. Ca rspuns la aciunile interne sau externe, procesele i pot
schimba repede starea rezultnd a nou stare global a sistemului.


3.2.3. Planificarea unitii centrale

Existena simultan n memorie a mai multor procese face posibil ca prin intermediul
unui mecanism de planificare a UC, s se mbunteasc eficiena global a sistemului de
calcul, realizndu-se un volum mai mare de lucru ntr-un timp mai scurt
2
.
Procesele ncrcate n memorie i gata de a fi lansate n execuie sunt grupate ntr-un ir
de ateptare (ir ready) n vederea alocrii UC. Implementarea acestui ir (numit de multe ori
coad de ateptare) se realizeaz de obicei sub forma unei liste nlnuite ale crei elemente
sunt blocurile de control asociate proceselor (BCP), fiecare BCP incluznd un indicator (pointer)
ctre procesul care i urmeaz n irul ready. Deoarece pe lng UC, procesele folosesc i alte
resurse ale sistemului de calcul, pentru fiecare dintre aceste resurse pot exista iruri de ateptare
(cozi), numite, de exemplu, iruri de dispozitiv sau iruri I/E dac este vorba despre procesele
ce ateapt eliberarea unui dispozitiv de I/E.
Ori de cte ori UC devine inactiv, sistemul de operare, prin intermediul unei

2
n general, un proces folosete UC pn n momentul n care trebuie s atepte realizarea unei operaii de I/E. Fr
multiprogramare, pe durata realizrii acestei operaii UC rmne inactiv. Cu multiprogramare ns, sistemul de
operare permite imediat unui alt proces s foloseasc UC, eliminnd timpul de ateptare din primul caz.
87
componente numite planificator (scheduler), selecteaz pentru execuie unul dintre procesele
aflate n irul ready. Planificatorul UC poate fi planificator pe termen lung (de perspectiv) sau
planificator pe termen scurt (imediat) (figura 3.3).












Fig. 3.3. Planificarea execuiei proceselor

Planificatorul pe termen scurt (numit i planificator UC) selecteaz unul dintre procesele
gata de execuie aflate deja n memoria intern i i aloc UC. Deoarece multe procese conin
cicluri rafal UC foarte scurte (cteva milisecunde), planificatorul pe termen scurt are o
frecven de execuie foarte mare i, prin urmare, trebuie s fie foarte rapid pentru a nu irosi
timpul de lucru al UC.
Planificatorul pe termen lung (numit i planificator de job-uri) stabilete care sunt
procesele ce vor fi ncrcate n memoria intern a sistemului pentru a fi executate atunci cnd
exist mai multe cerere dect posibilitile imediate de execuie. De obicei, n astfel de situaii,
procesele se afl memorate pe disc magnetic, de unde planificatorul pe termen lung le selecteaz
i le ncarc n memorie n vederea execuiei. Cu alte cuvinte, planificatorul pe termen lung
controleaz gradul multiprogramrii (numrul proceselor din memorie). n mod evident,
frecvena de execuie a acestui tip de planificator este mult mai mic i el poate folosi mai mult
timp, dect planificatorul pe termen scurt, pentru a selecta procesele. Exist i sisteme care
folosesc un nivel suplimentar de planificare prin intermediul unui planificator pe termen mediu
(vezi figura 3.4).















Fig. 3.4. Planificare pe termen mediu

Rolul acestuia este de a modifica gradul de multiprogramare atunci cnd este necesar,
evacund din memorie anumite procese (care altfel ar concura pentru dobndirea UC) i
reintroducndu-le n momentul n care ncrcarea sistemului permite reluarea execuiei din
ir ready
Unitate
central
I/E
iruri de
ateptare I/E
ncrcare
(swap)
evacuare
(swap out)
ncheierea
execuiei
procese
executate
parial
(evacuate)
ir ready Unitate
central
I/E iruri de
ateptare I/E
planificare de
perspectiv
planificare
imediat ncheierea
execuiei
88
punctul n care fusese ntrerupt. Pentru aceast metod se folosete n limbajul de specialitate
denumirea de swapping ceea ce ar nsemna interschimbare sau, mai sugestiv, evacuare i
introducere din/n memorie a procesului. Planificatoarele pe termen mediu sunt incluse mai ales
n cadrul sistemelor de tip time-sharing i a celor cu memorie virtual.

3.2.3.1 Algoritmi de planificare a UC
Prezentarea ct mai fidel a funcionrii algoritmilor de planificare UC ar presupune
utilizarea unor exemple care s includ un numr mare de procese, fiecare dintre ele fiind o
secven de sute de cicluri rafal UC i I/E. Pentru ca toate acestea s nu afecteze nelegerea
elementelor eseniale, s-a preferat folosirea unei variante simplificate n care fiecare proces
conine un singur ciclu rafal UC, iar performanele sunt apreciate cu ajutorul duratei medii de
ateptare (notat DMA).

^ Algoritmul FCFS

Algoritmul FCFS (First Come First Served) este cel mai simplu algoritm de planificare a
UC: primul proces care cere alocarea UC este cel care o obine. irul ready este de tip FIFO
(First In First Out); atunci cnd un nou proces devine gata de execuie, blocul su de control se
adaug la sfritul irului ready; ori de cte ori devine disponibil, UC este alocat procesului
aflat pe prima poziie a irului.
Dac n sistem exist urmtoarele procese, sosite la acelai moment de timp n ordinea
numerotrii:
Proces Durata ciclului rafal
1 10
2 29
3 3
4 7
5 12
algoritmul de planificare a UC de tip FCFS va determina executarea proceselor conform
diagramei din figura urmtoare:

Proces 1 Proces 2 Proces 3 Proces 4 Proces 5
0 10 39 42 49 61
Duratele de ateptare impuse fiecrui proces pn la ocuparea UC sunt:

Proces Durata de ateptare
1 0
2 10
3 39
4 42
5 49
Durata medie de ateptare este deci (0 + 10 + 39 + 42 + 49) : 5 = 28. Se observ c dac
procesele ar fi sosit n alt ordine (de exemplu 3, 4, 1, 5, 2), execuia lor ar fi avut evoluia din
figura urmtoare:
Proces 3 Proces 4 Proces 1 Proces 5 Proces 2
0 3 10 20 32 61

89
durata medie de ateptare fiind mult mai mic: (0 + 3 + 10 + 20 + 32) : 5 = 13
Exemplul ales ilustreaz unul dintre dezavantajele algoritmului FCFS: durata medie de
ateptare, n general, nu este minimal i poate varia ntre limite foarte largi, n funcie de
caracteristicile proceselor implicate n planificare. n plus, dac ncrcarea sistemului nu este
echilibrat poate s apar aa-numitul efect de convoi.
Presupunnd c n sistem exist un proces limitat UC i mai multe procese limitate I/E, se
poate ntmpla ca la un moment dat s se aloce UC procesului limitat UC. n timp ce acesta se
execut, toate celelalte procese i ncheie operaiile de I/E i intr n irul ready, n ateptarea
eliberrii UC. Pe durata ateptrii, dispozitivele de I/E stau nefolosite. n momentul n care
procesul limitat UC i ncheie ciclul rafal i trece ntr-un ir de ateptare I/E, toate procesele
limitate I/E (care au cicluri rafal UC foarte scurte) se execut rapid i intr pe rnd n irurile
de ateptare I/E. Este deci rndul UC s stea nefolosit. Apoi ciclul de funcionare prezentat se
reia, genernd o utilizare ineficient att a UC ct i a dispozitivelor de I/E.

^ Algoritmul SJF

Algoritmul SJF (Shortest Job First - se execut mai nti cel mai scurt job) ia n
considerare pentru fiecare proces urmtorul ciclu rafal UC pe care l conine i aloc UC
(atunci cnd ea devine disponibil) procesului cu cel mai scurt ciclu rafal UC urmtor
existent n irul ready. n cazul n care exist dou procese cu aceeai durat a ciclului rafal
UC urmtor, ntre ele se aplic regula FCFS.
Ca exemplu, se poate folosi acelai set de procese utilizat n cazul algoritmului FCFS n
care procesele soseau n sistem la acelai moment de timp, n ordinea numerotrii:
Proces Durata ciclului rafal
1 10
2 29
3 3
4 7
5 12
Algoritmul de planificare a UC de tip SJF, examinnd durata ciclului rafal asociat
fiecrui proces, va planifica execuia conform figurii anterioare, rezultnd o valoare a duratei
medii de ateptare de 13 uniti de timp. Pentru comparaie, se poate observa c algoritmul
FCFS, folosind acelai set de procese genera o durat medie de ateptare de 28 de uniti de
timp.
Se poate demonstra c planificnd un proces scurt naintea unuia lung, durata de ateptare
a procesului scurt se micoreaz cu mai mult dect crete durata de ateptare a procesului lung i,
prin urmare, durata medie de ateptare se reduce n mod substanial. Din acest motiv, algoritml
SJF este optimal, asigurnd o durat medie de ateptare minim, oricare ar fi setul de procese
luat n considerare. Singura problem care apare este legat de cunoaterea duratei ciclului
rafal UC urmtor asociat fiecrui proces analizat.
Dac se dorete planificarea pe termen lung ntr-un sistem de tip cu prelucrare pe loturi
(batch), se folosete ca valoare durata limit a job-ului precizat de ctre fiecare utilizator n
parte
3
. Dac ns se dorete folosirea algoritmului pentru planificarea pe termen scurt, deoarece
nu se pot cunoate cu exactitate duratele ciclurilor rafal urmtoare ale proceselor implicate, se
poate realiza doar o aproximare a funcionrii reale.

^ Algoritmi bazai pe prioriti
n cadrul acestui tip de algoritmi, fiecrui proces i se asociaz o prioritate (reprezentat,

3
n cazul n care utilizatorul estimeaz i precizeaz o valore prea mic, poate s apar eroare de depre a limitei de
timp, fiind necesar replanificarea job-ului.
90
n general ca un numr cuprins ntr-o gam fixat de valori), UC fiind alocat (n momentul n
care devine disponibil) procesului cu cea mai mare prioritate din irul ready. SJF este un caz
particular de algoritm bazat pe prioriti n care prioritatea fiecrui proces este un numr invers
proporional cu mrimea ciclului rafal UC urmtor.
Prioritatea se poate defini intern sau extern. Atunci cnd este de tip intern, prioritatea
procesului se calculeaz pe baza unei entiti msurabile cum ar fi, de exemplu, limita de timp,
necesarul de memorie, numrul fiierelor deschise sau raportul dintre numrul mediu de cicluri
rafal I/E i numrul mediu de cicluri rafal UC. Dac definirea este de tip extern, criteriile
folosite sunt din afara sistemului de operare: tipul i mrimea fondurilor rambursate pentru
utilizarea calculatorului, departamentul care sponsorizeaz lucrarea, factorii politici, etc.
Principala problem a algoritmilor bazai pe prioriti este posibilitatea apariiei blocrii
la inifinit a proceselor care sunt gata de execuie, dar, deoarece au prioritate redus nu reuesc s
obn accesul la UC
4
. O astfel de situaie poate s apar ntr-un sistem cu ncrcare mare n care
se execut un numr considerabil de procese cu prioritate ridicat; acestea vor obine mereu
accesul la UC n detrimentul proceselor cu prioritate redus care este posibil s nu se mai
execute niciodat.
O metod de rezolvare a acestei probleme este mbtrnirea proceselor, o tehnic prin
care se mrete treptat prioritatea proceselor care se constat c rmn n sistem un timp mai
ndelungat. De exemplu, dac prioritile sunt cuprinse n domeniul 0 pn la 64, se poate stabili
ca la fiecare 10 minute s fie incrementat cu cte o unitate prioritatea proceselor rmase n
ateptare. n acest fel chiar i un proces cu prioritatea iniial 0 va reui ca ntr-un timp destul de
scurt s ajung cel mai prioritar i, prin urmare s obin accesul la UC (s se execute).

Algoritmi preemtivi

Toi algoritmii de planificare a UC descrii anterior (FCFS, SJP i algoritmii bazai pe
prioriti) sunt algoritmi ne-preemtivi: odat alocat UC ea este folosit de ctre proces pn n
momentul n care acesta dorete s o elibereze (i ncheie execuia sau urmeaz s efectueze o
operaie de I/E). Un algoritm preemtiv permite ns ntreruperea execuiei unui proces n
momentul n care n irul ready apare un alt proces cu drept prioritar de execuie, sistemul de
operare alocndu-i imediat acestuia UC.
Algoritmul FCFS este prin definiie ne-preemtiv; ceilali doi algoritmi prezentai pot fi
modificai, astfel nct s devin preemtivi.
SJF preemtiv se formuleaz astfel: dac n irul ready sosete un proces al crui ciclu
rafal UC urmtor este mai scurt dect ceea ce a mai rmas de executat din ciclul rafal UC
al procesului curent, se ntrerupe execuia celui din urm i se aloc UC noului proces.
Un algorim preemtiv bazat pe prioriti funcioneaz ntr-un mod similar: ori de cte ori
sosete n irul ready un nou proces, prioritatea sa este comparat cu cea a procesului curent;
dac se constat c este mai mare, se ntrerupe execuia procesului curent i se aloc UC
procesului nou
5
.
Ca exemplu pot fi folosite urmtoarele trei procese, sosite n irul ready la momentele de
timp specificate:

Proces Momentul sosirii n
irul ready
Durata ciclului
rafal
1 0 12
2 3 3

4
Fenomenul se mai numete i nfometarea proceselor.
5
Dac algoritmul bazat pe prioriti este de tip ne-preemtiv, execuia nu se ntrerupe, noul proces fiind pus la
nceputul irului ready, conform prioritii pe care o are i ateptnd eliberarea UC.
91
3 4 6
Utiliznd un algoritm de planificare de tip SJF fr preemie se obine o evoluie a
execuiei proceselor ca n figura urmtoare:

Proces 1 Proces 2 Proces 3
0 12 15 21

durata medie de ateptare fiind: (0 + (12-3) + (15-4)) : 3 = 6,67
Dac se folosete un algoritm SJF preemtiv, durata medie de ateptare devine: (0 + (12-3)
+ (3-3) + (6-4)) : 3 = 3,67 evoluia execuiei fiind ilustrat n figura urmtoare:

Proces 1 Proces 2 Proces 3 Proces 1
0 3 4 6 12 21

Deoarece iniial n irul ready exist numai procesul 1, acesta se execut pn n
momentul 3, cnd apare n ir procesul 2, a crui durat de ciclu rafal (3 uniti de timp) este
mai mic dect ceea ce a mai rmas de executat din procesul 1 (9 uniti de timp). Prin urmare,
procesul 1 va fi ntrerupt, UC fiind alocat procesului 2, care se va executa fr ntrerupere
deoarece la momentul 4, cnd n irul ready sosete i procesul 3, necesarul duratelor de execuie
se prezint astfel:
Proces Necesar
1 9
2 2
3 6

n momentul ncheierii execuiei procesului 2 va fi planificat mai nti procesul 3 i abia
dup aceea procesul 1.

^ Algoritmul Round-Robin

Round-Robin este un algoritm de planificare a UC proiectat special pentru sistemele
time-sharing. Principalele sale caracteristici sunt definirea i folosirea unei cunate temporale (cu
valori cuprinse n domeniul 10 ms pn la 100 ms) i tratarea irului ready ca ir FIFO circular.
Planificatorul aloc pe rnd UC fiecrui proces din ir pe o durat egal cu cel mult o cunat (se
folosete un ceas setat n mod corespunztor).
Dac durata ciclului rafal UC al procesului curent este mai mic dect durata cuantei,
nsui procesul elibereaz UC prin emiterea unei cereri de I/E sau prin comunicarea ncheierii
execuiei. Dac ns durata ciclului rafal UC depete durata cuantei, ceasul va genera o
ntrerupere i procesul va fi inclus la sfritul irului ready, dup ce n prealabil contextul su a
fost salvat n blocul de control asociat.
Se poate spune deci c algoritmul Round-Robin este un algoritm preemtiv, care asigur
un timp aproape egal de ateptare pentru toate procesele din sistem. ntr-adevr, dac n irul
ready exist N procese i se lucreaz cu o cuant de valore C, fiecare proces va folosi n total
1
N
din timpul UC, fiecare alocare durnd cel mult C uniti de timp. ntre dou alocri succesive
ctre acelai proces durata de ateptare va fi de cel mult (N-1) x C uniti de timp.
Ca exemplu vom fi folosit acelai set de procese ca i n cazul algoritmului FCFS:


92
Proces Durata ciclului rafal
1 10
2 29
3 3
4 7
5 12
Presupunnd c se alege ca valoare a cuantei durata de 10 uniti de timp, evoluia
execuiei proceselor planificate cu ajutorul algoritmului Round-Robin va fi cea din figura
urmtoare:

Proces 1 Proces 2 Proces 3 Proces 4 Proces 5 Proces 2 Proces 5 Proces 2
0 10 20 23 30 40 50 52 61

Procesul 1 folosete complet prima cuant, ncheindu-i execuia. Procesul 2 avnd
nevoie de 29 de uniti de timp este ntrerupt n momentul expirrii celei de a doua cuante, UC
fiind alocat urmtorului proces din irul ready. Procesul 3 se ncheie nainte de epuizarea
cuantei curente, elibernd UC pentru procesul 4, care are o comportare asemntoare. n final
rmn n irul ready numai procesele 5 i 2 care folosesc alternativ UC pe durata a nc dou
cuante complete i dou cuante incomplete.
Exemplul prezentat permite compararea performaelor algoritmilor FCFS, SJF i Round-
Robin. Durata medie de ateptare generat de planificarea setului de procese cu ajutorul
algoritmului Round-Robin este: (0 + (10+20+2) + 20 + 23 + (30+10)) : 5 = 23 uniti de timp
Reamintim c, pentru acelai set de procese, algoritmul FCFS genereaz 28 uniti de
timp, iar algoritmul SJF doar 13 uniti de timp. Se observ c algoritmul Round-Robin asigur o
valoare intermediar, n timp ce SJF este n mod evident cel mai performant.
Performanele algoritmului Round-Robin depin n mod esenial de mrimea cuantei
folosite.

^ iruri de procese multinivel

Atunci cnd procesele existente n sistem pot fi clasificate n grupe diferite, n funcie de
anumite caracteristici (de exemplu: valori ale timpului de rspuns, prioritate definit extern,
necesar de memorie, etc.), se utilizeaz un algoritm de planificare pentru iruri multinivel.
irul ready este format din mai multe subiruri, fiecare dintre acestea coninnd cte o
categorie de procese i avnd propriul algoritm de planificare. De exemplu,se pot crea dou
subiruri: unul pentru procese interactive (foreground) i altul pentru procese de tip batch
(background); pentru primul se poate folosi un algoritm de tip Round-Robin, iar pentru cel de-al
doilea un algoritm FCFS. Este important de reinut faptul c i ntre subiruri trebuie s existe un
algoritm de planificare (de cele mai multe ori un algoritm preemtiv bazat pe prioriti
nemodificabile). De exemplu, se poate stabili ca subirul proceselor interactive s aib prioritate
mai mare dect cel al proceselor de tip batch, ceea ce va face ca procesele din al doilea subir s
se poat executa numai atunci cnd primul ir este vid; dac ntre timp apare un proces n primul
ir, se ntrerupe execuia procesului curent i UC este alocat noului sosit. O alt variant de
planificare ntre subiruri este stabilirea a cte unei perioade de timp n care fiecare dintre acestea
s dein UC n mod exclusiv. De exemplu, pentru subirul proceselor interactive se poate acorda
80% din timpul total al UC, iar pentru subirul proceselor de tip batch restul de 20%.

^ iruri de procese multinivel cu feedback
Spre deosebire de algoritmul prezentat anterior, n care procesele, odat introduse ntr-un
subir, rmneau n cadrul acestuia pn la ncheierea execuiei, n cazul unui algoritm de
93
planificare pentru iruri multinivel cu feedback, se permite mutarea unui proces dintr-un subir
n altul, n funcie de anumite caracteristici dinamice. Metoda favorizeaz procesele interactive i
procesele limitate I/E care sunt plasate n subiruri cu prioritate ridicat, retrogradnd
procesele care folosesc UC un timp prea ndelungat n subiruri cu prioritate redus. De
asemenea, ea previne apariia fenomenului de nfometare (blocare la infinit) printr-o form de
mbtrnire: permite proceselor care ateapt de prea mult timp n irurile de prioritate redus
s promoveze n cadrul irurilor de prioritate ridicat.
Pentru a putea defini complet un algoritm de planificare pentru irui multinivel cu
feedback este necesar precizarea mai multor parametri:
- numrul de subiruri;
- algoritmul de planificare asociat fiecrui subir;
- metoda de stabilire a subirului n care intr procesul atunci cnd dorete s se execute;
- criteriul i metoda de promovare a unui proces ntr-un subir cu prioritate ridicat;
- criteriul i metoda de retrogradare a unui proces ntr-un subir cu prioritate redus.
Avnd un nalt grad de generalitate, algoritmul de planificare pentru iruri multinivel cu
feedback este cel mai complex, oferind avantajul unor performane ridicate, dar necesitnd n
acelai timp un numr mare de informaii pentru stabilirea valorilor optime n cazul parametrilor
de configurare menionai anterior.


3.3. GESTIUNEA MEMORIEI

3.3.1 Gestiunea n cazul multiprogramrii

Organizarea memoriei cu partiii fixe
Cea mai simpl metod pentru administrarea memoriei n acest caz este de a o mpri n
n partiii fixe, posibil inegale (mecanism de alocare static). O partiie este alocat unui proces pe
toat durata execuiei lui, indiferent dac o ocup complet sau nu. Cnd sosete un proces, el va
fi pus n coada format pentru cea mai mic partiie suficient de mare pentru a-l cuprinde.
Deoarece partiiile sunt fixe (au lungimi prestabilite, nemodificabile), orice spaiu
neocupat de un proces dintr-o partiie va fi pierdut. Se produce astfel o fragmentare intern a
memoriei (figura 3.5.):















Fig. 3.5. Organizarea memoriei cu partiii fixe

n general exist dou moduri de legare a proceselor la partiii :
- fiecare partiie are o coad proprie - operatorul stabilete de la nceput care sunt
procesele ce vor fi executate n fiecare partiie;
Partiia 4
700 K

Partiia 3
Partiia 2
Partiia 1
Sistem de
operare
Partiia 4

Partiia 3
Partiia 2
Partiia 1
Sistem de
operare
400 K
200 K
100 K
0
700 K
400 K
200 K
100 K
0




Cozi multiple de
intrare
O singur coad
de intrare
a). b).
94
- o singur coad pentru toate partiiile - sistemul de operare alege, pentru procesul
care urmeaz s intre n lucru, n ce partiie se va executa.
Dezavantajul prezentat n figura 3.5.a) - coada pentru partiii mari este goal (rezult
partiie liber, posibil de a fi alocat, dar nu exit cerere), iar cea pentru partiii mici este plin.
n cazul 3.5 b), ori de cte ori o partiie devine liber, primul proces din coad care
ncape n acea partiie este ncrcat i rulat. Deoarece nu se dorete folosirea unei partiii mari
pentru un proces mic (pierdere de spaiu), o alternativ ar fi cutarea n ntreaga coad a celui
mai mare proces care se potrivete partiiei devenite libere. Aceast alternativ are dezavantajul
c proceselor mici (de obicei interactive) li se acord cel mai prost serviciu i nu cel mai bun,
cum ar fi de dorit.
O soluie este aceea de a avea cel puin o partiie mic ce permite proceselor mici s
ruleze fr s atepte alocarea unei partiii mai mari.
O alt soluie ar fi ca un proces ce poate rula s nu fie omis de mai mult de k ori, de
fiecare dat cnd este omis, un contor asociat lui este incrementat; iar cnd a ajuns la valoarea k,
el nu va mai fi omis la urmtoarea cutare n coad.
Multiprogramarea ridic cteva probleme eseniale ce trebuie rezolvate (indiferent de
modul de organizare a memoriei): relocarea, protecia i partajarea.
Discutm aceste probleme relativ la organizarea memoriei n partiii fixe.
Relocarea. Din figur se observ c procese diferite pot rula la adrese diferite,
depinznd de partiia n care este ncrcat. Dac, de exemplu, prima instruciune este un apel de
procedur la o adres relativ, adresa absolut se obine prin adunarea adresei relative cu 100
KB, dac programul este ncrcat n prima partiie, respectiv cu 200 KB, dac este ncrcat n a
doua partiie, etc. O soluie ar fi de a modifica adresa relativ n adresa absolut la ncrcarea
programului (se cunoate adresa de nceput a partiiei). Pentru aceasta, trebuie inclus n codul
programului executabil o list sau o hart de bii care s specifice care cuvinte din program sunt
adrese (ce trebuie relocate) i care nu (sunt coduri de operaii, constante, etc.).
Relocarea n timpul ncrcrii programului (numit i relocare static) nu rezolv
problema proteciei. Astfel, un program poate s acceseze n scriere sau citire orice cuvnt din
memorie.
O soluie care rezolv relocarea este de a echipa calculatorul cu un registru special, numit
registru de baz (coninutul lui este pstrat n BCP-ul procesului). n acest caz avem de a face cu
relocarea dinamic.
Astfel, cnd un proces este ales s ruleze, registrul de baz este ncrcat cu adresa de
nceput a partiiei. Orice adres de memorie generat de program este adunat cu coninutul
registrului de baz.
Un avantaj oferit de utilizarea acestui registru este acela c mutarea programului n
memorie n timpul rulrii presupune doar schimbarea valorii din registrul de baz. n cazul
relocrii n timpul ncrcrii, mutarea unui program presupune reluarea procesului de generare a
adreselor absolute.
Protecia. n sistemele multiutilizator, nu se accept ca procesele unui utilizator s scrie
sau s citeasc datele aparinnd altui utilizator.
Problema se pune att la protecia proceselor ntre ele ct i la protecia spaiului de
memorie alocat sistemului de operare, de accese neautorizate.
n sistemele ce folosesc registrul de baz pentru relocare, se utilizeaz un alt registru
hardware numit registru limit, al crui coninut este de asemenea pstrat n BCP-ul procesului,
i care se ncarc cu lungimea partiiei. Orice adres generat (cu ajutorul registrului de baz)
este verificat s nu depeasc partiia curent.
Partajarea. Pe lng protecie, un bun mecanism de gestionare a memoriei trebuie s
asigure partajarea datelor i codului ntre procesele care coopereaz. Probabil c cel mai simplu
mod de implementare a partajrii, fr a compromite protecia, este de a lsa n seama sistemului
de operare controlul accesului la resursele partajate. Aceast soluie are unele dezavantaje:
creterea codului sistemului de operare precum i dificultatea protejrii obiectelor create
95
dinamic.
O soluie este de a copia obiectul partajat n spaiul privat (partiia) al fiecrui proces ce l
partajeaz. Astfel, protecia este asigurat. Ca urmare, actualizrile se realizeaz doar pe copiile
obiectului, nu i pe obiectul nsui. De asemenea, aceste actualizri trebuie propagate i spre
celelalte copii. De obicei, la fiecare comutare de context, sistemul de operare copiaz datele
partajate din spaiul de adrese al procesului curent activ, n spaiul de adrese al celorlalte procese
participante.
Dezavantaje: meninerea n memorie a mai multor copii; n cazul partajrii codului,
copierea lui nu are nici un sens deoarece nu are loc nici o modificare.
O alt soluie este de a plasa datele ntr-un loc comun, dedicat acestui scop. n acest caz
se pune problema rezolvrii proteciei: orice acces dincolo de partiia alocat este privit ca o
violare a proteciei. Cum se rezolv:
n sistemele cu chei de protecie, la fiecare comutare de context se schimb cheile tuturor
blocurilor partajate cu scopul de a acorda drepturi de acces procesului curent activ. Aceasta
presupune inerea unei evidene a blocurilor, care sunt partajate i de ctre cine, precum i a
frecventelor modificri ale cheilor.
n sistemele ce folosesc regitrii de baz i limit, avem nevoie de seturi diferite de
perechi de regitri dedicai spaiului de memorie privat i respectiv celui partajat. Aceasta
implic existena unui anumit mijloc, preferabil automat, de a desemna care este setul potrivit de
regitri pentru fiecare referire la memorie.
Cele mai multe dezavantaje ale acestei metode de organizare a memoriei se datoreaz
partiionrii statice, sistemul devenind inflexibil, neputndu-se adapta la schimbri.
O prim problem este fragmentarea intern ce rezult din diferena dintre dimensiunea
partiiei i dimensiunea procesului ce o ocup.
Partiionarea fix impune resticii severe dimensiunii programului: nici un proces nu are
voie s depeasc dimensiunea celei mai mari partiii. Astfel, ea devine ineficient n sistemele
n care programele i modific dinamic structurile de date (heap i stiv). Un alt dezavantaj este
gradul de multiprogramare limitat la numrul de partiii.

Organizarea memoriei cu partiii variabile
Un nou mod de organizare a memoriei care elimin multe dintre problemele create de
partiionarea fix a memoriei este organizarea memoriei cu partiii variabile (mecanism de
alocare dinamic). n funcie de solicitri i de capacitatea de memorie nc disponibil la un
moment dat, numrul i dimensiunile partiiilor se modific automat. Se mbuntete factorul
de utilizare a memoriei dar se complic alocarea i dezalocarea memoriei.
n figura 3.6. sunt prezentate mai multe stri succesive ale memoriei:











Fig. 3.6. Organizarea memoriei cu partiii variabile

Este uor de observat c dac sistemul funcioneaz timp ndelungat, atunci numrul
spaiilor libere va crete, iar dimensiunile lor vor scdea, rezultnd o fragmentarea extern a
memoriei.
Sistem de
operare
Sistem de
operare
Sistem de
operare
Sistem de
operare
Sistem de
operare
Sistem de
operare
Sistem de
operare
D D D

E
C


C


B
C


B
C


A
B
C


A
B


A

96
n momentul n care un proces nu are spaiu liber de memorie n care s se ncarce,
sistemul de operare poate lua una din urmtoarele trei decizii:
1. procesul ateapt pn cnd i se elibereaz un spaiu suficient de mare de memorie;
2. sistemul de operare ncearc alipirea unor spaii libere vecine, n sperana c va obine
un spaiu de memorie suficient de mare (cumularea golurilor);
3. sistemul de operare decide efectuare unei operaii de compactare a memoriei
(relocare), adic de deplasare a partiiilor active pentru a se absorbi toate zonele
(fragmentele) de memorie neutilizate (compactarea).
Fragmentarea memoriei poate s apar din mai multe motive, unul dintre ele fiind faptul
c un program i-a terminat execuia, iar locul rmas liber prin ieierea acestuia din memorie nu
poate fi ocupat de un alt program. Golurile n utilizarea memoriei astfel rezultate pot fi folosite
de alte programe cu dimensiuni mai mici sau cel mult egale cu cele ale golului. ntr-o astfel de
situaie dac un program a ncput ntr-o partiie astfel eliberat este posibil ca el s nu ocupe
toat zona de memorie aferent partiiei, rezultnd o nefolosire optim a memoriei. Se impune
deci realizarea unei operaii de colectare a golurilor astfel aprute, adic dou sau mai multe
goluri adiacente s se cumuleze ntr-un singur gol de dimensiune mai mare. Acest proces se
numete cumularea golurilor, i el este ilustrat n figura 3.7.











Fig. 3.7. Cumularea golurilor

Chiar n cazul n care golurile sunt colectate totui este posibil, ca n cadrul memoriei
interne, s apar goluri dispersate. i n aceast situaie poate aprea un job care s nu ncap n
nici unul din golurile prezente. Job-ul respectiv s-ar putea rula totui dac toate golurile ce sunt
n mod normal dispersate ar fi cumulate ntr-unul singur. Realizarea acestui proces se numete
compactarea memoriei, o astfel de situaie fiind ilustrat n figura 3.8.













Fig. 3.8. Compactarea memoriei
De regul, compactarea este o operaie costisitoare i de aceea n practic se aleg soluii
de compromis, cum ar fi :
Sistem de
operare
Zon
utilizat 1
Zon
liber 1
Zon
utilizat 2
Zon
utilizat 3
Sistem de
operare
Zon
utilizat 1
Zon
liber 1
Zon
liber 2
Zon
utilizat 3
Sistem de
operare
Zon
utilizat 1

Zon
liber 1+2
Zon
utilizat 3
Sistem de
operare
Zon
utilizat 1
Zon
liber 1
Zon
utilizat 2
Zon
liber 2
Zonutiliz
at 3
Sistem de
operare
Zon
utilizat 1
Zon
utilizat 2
Zon
utilizat 3

Zon
liber 1+2
97
- se lanseaz periodic compactarea (de exemplu, la 10 sec.), indiferent de starea
sistemului. n intervalul dintre compactri, memoria apare ca un mozaic de spaii
ocupate care alterneaz cu spaii libere. Procesele ce nu au loc n memorie ateapt
compactarea sau terminarea altui proces;
- se realizeaz o compactare parial pentru a asigura loc numai procesului care
ateapt;
- se realizeaz compactarea ori de cte ori se elibereaz o partiie.
Dei aceast schem este cea mai bun din punct de vedere al eficienei, totui ea prezint
urmtoarele inconveniente:
- consumarea resurselor calculatorului cu mutarea programelor dintr-o zon n alta a
memoriei;
- sistemul s-ar putea opri n timp ce se execut operaia de compactare, ceea ce ar avea
consecine grave pentru programele utilizator;
- compactarea consum foarte mult memorie secundar;
- compactarea mrete timpul de obinere a rezultatelor rulrii programelor utilizator.

Protecia i partajarea.
Protecia i partajarea, nu difer semnificativ fa de cazul partiionrii fixe. O diferen
este aceea c se permite ca partiii adiacente s se suprapun. Astfel, o singur copie a unui
obiect partajat poate fi accesibil din dou spaii de adres diferite. Partajarea, ns, este limitat la
dou procese. n cazul n care sunt n joc mai multe procese, trebuie aplicate metodele de la
partiionarea fix.
Partajarea codului impune ca acesta s fie reentrant sau executat n manier strict
exclusiv, fr posibilitatea ntreruperii de ctre alte procese. Reentrana presupune ca variabilele
s fie pstrate n stiv sau n regitri astfel nct, n cazul ntreruperii procesului curent, s nu fie
afectat starea procesului ntrerupt.
Dintre avantajele acestei metode amintim:
- un proces poate ocupa ntreaga memorie, n cazul n care i este necesar (nu doar
partiia cea mai mare, dac are loc);
- n cazul extinderii unui proces dincolo de partiia pe care o ocup, sistemul de operare
poate crea o partiie mai mare i poate muta procesul n ea, sau partiia alocat
procesului se poate extinde folosind zonele libere adiacente.
Partiionarea dinamic nu este lipsit de dezavantaje. Ea consum mult timp i spaiu.
Fragmentarea extern poate deveni o problem serioas, ducnd la creterea timpului n vederea
compactrii. Partajarea poate ridica, de asemenea, probleme dac obiectele partajate se supun
compactrii.
Se poate realiza un compromis i anume: o parte din memorie s fie mprit n partiii
fixe. Nucleul sistemul de operare-ului, driverele de dispozitive i poriuni ale sistemului de
fiiere sunt buni candidai pentru partiionarea fix. Restul memoriei poate fi alocat altor
procese utiliznd partiionarea variabil.


3.3.2. Strategii de administrare a spaiului din memoria intern

Categorii de strategii:
- strategii de apel - se bazeaz pe determinarea momentului cnd trebuie obinut
urmtoarea poriune din program sau de date pentru a o transfera din memoria
secundar n memoria real. Mult timp s-a folosit strategia de apel la cerere n care
urmtoarea parte de program sau de date era ncrcata n memorie la momentul n
care programul aflat n execuie fcea referire la aceasta. n prezent, se tinde ctre
utilizarea unor strategii anticipatorii, care s prevad momentul de timp la care
programul aflat n execuie va avea nevoie de o anumit poriune de program din
98
memoria secundar pentru a o ncrca din timp n memoria principal, mbuntind
n acest fel performanele sistemului.
- strategii de plasare n memorie - n general, n memorie se afl risipite mai
multe zone nealocate de diferite dimensiuni. Atunci cnd apare un job care necesit
memorie, este aleas una dintre acestea, cu dimensiune suficient de mare pentru a
satisface cerinele job-ului. Dac zona este prea mare, o parte se aloc job-ului, iar
restul se integreaz setului de zone disponibile. n momentul terminrii execuiei, job-
ul elibereaz zona de memoria aferent, care va fi inclus i ea n set. Dac zona de
memorie disponibilizat este adiacent celorlate, ele se pot contopi pentru a forma o
zon de dimensiune mare, moment n care se poate verifica dac nu cumva exist job-
uri aflate n ateptare care ar putea folosi aceast nou zon. Situaia prezentat este
un caz particular al problemei de alocare dinamic a memoriei (care are ca obiect
modul n care se poate satisface o cerere de dimensiune precizat avnd la dispoziie
o list de zone de memorie disponibile), pentru care exist mai multe variante de
rezolvare. Deci, startegiile de plasare n memorie se concentreaza asupra determinrii
locului n care se va ncrca un program n memoria primar.
- strategii de nlocuire - se ocup cu determinarea acelei pri din program ce va fi
scoas din memorie pentru a face loc noului program ce intr n execuie.
n cazul pstrrii listei zonelor de memorie disponibile, ordonate dup adres, avem
urmtorii algoritmi de alocare a memoriei (strategii de plasare n memorie) pentru un proces nou
creat sau adus de pe disc :
First Fit (prima potrivire) - n cadrul acestei strategii, job-ului care vine s se execute i
se va aloca prima zon de memorie disponibil cu dimensiune suficient de mare n care acesta
poate s ncap. Cutarea zonei respective se poate face pornind fie de la nceputul listei zonelor
de memorie liber, fie din oricare alt loc n care s-a terminat o cutare anterioar de acelai tip.














Next Fit (urmtoarea potrivire) strategia lucreaz la fel ca First Fit, dar cutarea
pornete de la elementul alocat n potrivirea anterioar, nu de la captul listei.

Best Fit (cea mai bun potrivire) - strategia alege, dintre toate zonele de memorie
disponibile a cror dimensiune permite alocarea job-ului, zona cu cea mai mic dimensiune ce
poate s-l ncap, minimizndu-se astfel fragmentarea intern. Lista zonelor de memorie liber
este ordonat cresctor dup dimensiunile golurilor.






a 16K
c 14K
e 5K
g 30K
cerere pentru
13 K
Sistem de
operare
16K liberi
utilizai
14K liberi
utilizai
5K liberi
utilizai
30K liberi
0
a
b
c
d
e
f
g
h
Lista zonelor de
memorie liber inut
n ordinea adreselor
99
^
^
^
^
^
^
^
^
^
^
^
Worst Fit (cea mai rea potrivire) - n cadul acestei strategii se aloc job-ului zona de
memorie disponibil care are cea mai mare dimensiune. Lista zonelor de memorie liber este
ordonat descresctor dup dimensiunea golurilor.














Quick Fit (potrivire rapid) - se pstreaz liste diferite pentru diverse dimensiuni ce pot
fi cerute. De exemplu, putem avea un tablou cu n intrri n care prima intrare este un pointer spre
capul listei spaiilor de 4K, a doua intrare spre lista de spaii de 8K, a treia spre cele de 12K, etc.
Cu acest algoritm, cutarea spaiului de dimensiune cerut este foarte rapid, dar se pierde mult
timp pentru gsirea spaiilor adiacente libere pentru colaionare (altfel, memoria se umple de
spaii mici, neutilizabile).


3.3.3. Mecanismul de swapping

n mod normal, sunt mai muli utilizatori i deci mai multe procese dect pot fi pstrate
n memoria principal i de aceea este necesar pstrarea proceselor n exces, pe disc (memoria
secundar). Pentru rularea acestor procese, ele trebuie aduse n memoria principal. Aceast
mutare a proceselor pe i de pe disc se numete swapping.
n principiu, swapping-ul se poate aplica i n cazul organizrii memoriei n partiii fixe
dar n general, acest mecanism se asociaz organizrii memoriei folosind partiii variabile.
O problem o reprezint dimensiunea spaiului de memorie ce trebuie alocat unui proces
atunci cnd acesta este creat sau adus din nou n memorie prin swapping. Dac procesele create
i pstreaz dimensiunea pe toat durata execuiei, alocarea este foarte simpl: se aloc exact
spaiul necesar, nici mai mult, nici mai puin.
n timpul execuiei, ns, segmentul de date poate crete, de exemplu, prin alocare
dinamic a memoriei din heap. Dac exist un spaiu liber adiacent procesului curent, acesta i
poate fi alocat. Dac nu, fie trebuie mutat procesul ntr-un spaiu suficient de mare, fie unul sau
mai multe procese trebuie salvate pe disc pentru crearea acestui spaiu. Dac un proces nu are loc
e 5K
c 14K
a 16K
g 30K
cerere pentru
13 K
Sistem de
operare
16K liberi
utilizai
14K liberi
utilizai
5K liberi
utilizai
30K liberi
0
a
b
c
d
e
f
g
h
Lista zonelor de memorie
liber inut n ordinea
cresctoare a dimensiunii
golurilor
g 30K
a 16K
c 14K
e 5K
cerere pentru
13 K
Sistem de
operare
16K liberi
utilizai
14K liberi
utilizai
5K liberi
utilizai
30K liberi
0
a
b
c
d
e
f
g
h
Lista zonelor de memorie
liber inut n ordinea
descresctoare a
dimensiunii golurilor
100
n memorie pentru extindere iar spaiul de swap de pe disc este plin, procesul este pus n starea
de ateptare sau este distrus.
Dac este de ateptat ca majoritatea proceselor s creasc n timpul execuiei, o idee bun
este aceea de a aloca un mic extraspaiu ori de cte ori procesul este adus n memorie de pe disc
sau este mutat. n momentul salvrii pe disc, doar zona de memorie utilizat va fi supus
swapping-ului.
Ori de cte ori planificatorul trebuie s lanseze n execuie un proces i nu este suficient
loc n memorie, va apela procesul de swapping. Procesele ce se supun swapping-ului se vor alege
dintre procesele suspendate care ocup un spaiu ce este suficient de mare pentru a fi alocat
procesului curent.
n cazul operaiei de swapping pe disc, se vor salva locaiile ce conin datele procesului,
stiva i regitrii UC relevani, precum i codul, n cazul sistemelor ce permit modificarea codului
n timpul execuiei.
n ceea ce privete spaiul alocat pe disc swapping-ului, exist dou opiuni :
- toate procesele salvate pe disc se vor depune ntr-un unic fiier de swap;
- fiecare proces va fi salvat separat.
n ambele situaii, spaiul de swap corespunztor fiecrui proces din memorie se aloc
static, la crearea procesului.
O alt problem este dac legarea proces-partiie se face static sau dinamic, adic dac un
proces salvat pe disc n urma unei operaii de swap, va fi readus n memorie n acceai partiie pe
care o ocupa anterior swapping-ului sau n alt partiie. Legarea static se recomand n cazul
partiionrii statice a memoriei, eliminndu-se astfel timpul afectat de ctre sistemul de operare
alocrii unei alte partiii. Pe de alt parte, sistemele unde procesele nu sunt legate permanent de o
partiie specific sunt mai flexibile i duc la o utilizare mai bun a memoriei.


3.4. SISTEMUL DE OPERARE UNIX

3.4.1. Elemente introductive privind sistemul de operare UNIX

Sesiunea de lucru sub UNIX
Dup pornirea sistemului de calcul, i ncrcarea sistemului de operare, iniierea unei
sesiuni de lucru sub UNIX ncepe cu aciunea de conectare (login). n cadrul acesteia,
utilizatorului i se va solicita, n prim faz, identificatorul de conectare unic (login ID)
asociat. Acesta identific utilizatorul i orice caracteristici asociate cu el, fiind n fapt un nume de
recunoatere autorizat. Dup furnizarea de ctre utilizator a identificatorului respectiv, i se va
solicita i parola de acces corespunztoare (password). Cele dou elemente sunt verificate, i
n cazul n care sunt corecte, conectarea se realizeaz, fiind afiate o serie de informaii
referitoare la ultima conectare nereuit, ultima conectare reuit, dac sunt mesaje de pot
electronic, mesaje de la administratorul de sistem, .a. Apoi se lanseaz automat n execuie
interpretorul de comenzi implicit (shell)
6
afindu-se un prompter
7
. Din acest moment
utilizatorul are acces la resursele sistemului, i poate folosi comenzile UNIX.

6
Interpretorul de comenzi este un program executabil situat, de regul, n directorul /bin, i care este tratat de ctre
nucleul (kernel) sistemului de operare, ca orice proces utilizator neprivilegiat. La deschiderea unei sesiuni de lucru,
se lanseaz n execuie un proces shell la terminalul la care lucreaz utilizatorul, ateptnd comenzi.
Interpretorul de comenzi (shell) (care pornete dup introducerea numelui utilizatorului i a parolei) poate fi ales de
ctre utilizator. Exist mai multe interpretoare clasice, fiecare rspunznd anumitor cerine. Interpretorul "standard"
n UNIX este Bourne shell (sh), dar foarte folosite sunt i Bourne Again shell (bash), Korn shell (ksh), Berkeley C
shell (csh), Turbo C shell (tcsh).
7
n funcie de shell-ul utilizat, prompter-ul este reprezentat printr-un caracter specific. Astfel, n cazul shell-ului sh
(Bourne shell), prompter-ul este $ (n cazul utilizatorilor neprivilegiai) sau * (pentru utilizatori privilegiai -
superuser, root). Dac shell-ul este csh (C shell), prompter-ul va fi %, iar n cazul shell-ului ksh (Korn shell)
prompter-ul va fi :.
101
Terminarea unei sesiuni de lucru UNIX se face folosind una din comenzile: exit,
respectiv bye, sau tastnd combinaia de taste <Ctrl><D>.
Pentru oprirea, ntr-o manier ordonat, a calculatorului pe care ruleaz sistemul UNIX,
se utilizeaz comanda shutdown.
Aceasta poate fi executat numai de ctre utilizatorul privilegiat (superuser, root).
Cnd comanda este executat, toi utilizatorii primesc un mesaj shutdown i apoi
recepioneaz un mesaj final de terminare.
Civa dintre indicatorii utilizai cu comanda shutdown sunt:
-h oprete sistemul complet
-i permite afiarea de mesaje care ghidez utilizatorul n cadrul procesului de
shutdown
-k simuleaz un shutdown sistem
-m oprete sistemul i l trece n modul ntreinere (single user), astfel nct
administratorul de sistem s poat efectua ntreinerea acestuia (instalarea de hardware/software
sau ntreinerea planificat a hardware-ului/software-ului existent)
-r permite oprirea sistemului urmat de restartare (reboot).
Este de asemenea posibil specificarea momentului de timp la care oprirea (sau
restartarea) s fie fcut, prin indicarea unei date viitoare sau a unui timp relativ. n acest caz
sistemul trimite periodic mesaje utilizatorilor, referitoare la oprire.
Variantele cele mai des folosite ale acestei comenzi sunt:
shutdown -h now
shutdown -r now

Specificarea numelui fiierelor i directoarelor
UNIX are o structur de directoare i fiiere asemntoare cu cea a sistemelor DOS i
Windows.
Fiierele sunt stocate n directoare i sunt identificate printr-un nume, care este o secven
de caractere.
Toate numele de fiiere, oricare ar fi tipul lor (text, binare) se supun acelorai reguli, i
anume:
1. Spre deosebire de sistemul DOS unde numele de fiiere era specificat n formatul
8.3, (maxim 8 caractere pentru nume i maxim 3 caractere pentru o eventual
extensie), n UNIX se pot utiliza nume lungi de fiiere (pn la 255 de caractere,
dac este instalat sistemul de fiiere ext2 sau umsdos), iar numele pot conine
mai mult de un punct (de exemplu, mihai.stud.txt);
2. n toate cazurile, n cadrul numelui unui fiier, UNIX face distincie ntre caracterele
minuscule i majuscule
8
, (de exemplu, numele FILENAME.tar.gz i
filename.tar.gz fac referire la fiiere diferite);
3. Caracterele ce pot fi utilizate pentru numele de fiiere sunt funcie de sistemul UNIX
folosit, existnd particulariti. n general, pot fi utilizate literele de la A la Z sau de la
a la z; numerele de la 0 la 9, linia de subliniere
9
, punctul
10
. n tabelul 4.1 sunt date o
serie de caractere (sau combinaii de caractere) ce au o semnificaie special pentru

8
Este case-sensitive.
9
Linia de subliniere poate separa cuvinte n cadrul numelui unui fiier, fcnd numele mai uor de citit. De exemplu,
n loc de a numi un fiier fisierdetest, putem s-l numim fisier_de_test.
10
Un punct poate fi folosit pentru a aduga o extensie la un nume de fiier, ntr-o modalitatea similar fiierelor
DOS. De exemplu, un fiier surs C care conine un program numit prog poate fi denumit prog.c. Aa cum s-a
artat, n UNIX nu suntem limitai la o singur extensie. n cazul n care un punct este folosit ca prim caracter n
cadrul numelui unui fiier, acesta confer fiierului statutul de fiier ascuns (hidden). De exemplu, dac n directorul
curent exist fiierele doc1 i .doc1, tastnd comanda ls va fi afiat numai fiierul doc1. Pentru afiarea ambelor
fiiere se va tasta comanda ls a.
102
UNIX, i ca urmare utilizarea lor trebuie fcut cu precauie. Lista nu este exhaustiv
i ea depinde de shell-ul UNIX folosit.

Tabelul 3.1.
Semnificaia ctorva caractere speciale
Caracter Semnificaie
$
Indic nceputul numelui unei variabile shell. De exemplu $var va
nsemna numele unei variabile numite var.
|
Leag ieirea standard a unei comenzi la intrarea standard a altei comenzi
(pipe).
# ncepe un comentariu.
& Execut un proces n fundal (background).
? Specificator pentru nume de fiier global ce ine locul unui singur caracter.
* Specificator pentru nume de fiier global ce ine locul mai multor caractere.
$# Numrul de argumente transmise unui script shell.
$* Argumente transmise unui script shell.
$? Returneaz cod de la comanda executat anterior.
> Operator pentru redirectarea ieirii.
< Operator pentru redirectarea intrrii.
' Substituie comand.
>> Operator pentru redirectarea ieirii (pentru a aduga la un fiier).
[ ]
Afieaz un domeniu de caractere. [a-z] semnific toate caracterele dintre
a i z. [a,z] semnific caracterele a sau z.
.nume_fisier Execut fiierul cu numele specificat.
: Separator de nume de director din cadrul cii.

Observaii:
1. Sub UNIX, dac un nume de fiiere conine spaii (nu este recomandat, dar este
posibil), ori de cte ori ne referim la el, va trebuie s includem numele respectiv ntre ghilimele
duble.
2. Pentru fiierele executabile ("programe") nu exist obligativitatea utilizrii extensiilor:
.COM, .EXE, .BAT. Aceste fiiere sunt marcate printr-un caracter * existent la sfritul
numelului lor, atunci cnd sunt afiate cu comanda ls -F.
3. Sub DOS numele fiierelor arhiv (backup) au extensia .BAK, sub UNIX numele
acestora se termin cu caracterul ~ (tilda).

Comenzi UNIX
n cadrul unui sistem UNIX utilizatorul are la dispoziie comenzi native UNIX precum
i comenzi pe el nsui le poate scrie (fiiere de comenzi - fiiere script). n funcie de
versiunea de UNIX ce ruleaz i de shell-ul utilizat, comenzile difer.
Comenzile UNIX sunt de fapt programe executabile care pot fi gsite n directoarele
/bin, /usr/bin. Diferenele ntre interpretoarele de comenzi se vd mai ales n contextul
fiierelor de comenzi. Practic, aceste interpretoare permit scrierea de programe complexe,
folosind comenzile UNIX i directivele speciale.
Forma sintactic general a unei comenzi shell este urmtoarea:
Comanda[indicatori][argument1][argument2]..
unde:
comanda - reprezint numele comenzii ce urmeaz a fi executat. Cutarea comenzii (a
fiierului executabil), pn cnd aceasta este gsit, se face n urmtoarea secven: n directorul
curent; n directorul /bin; n directorul /usr/bin. n cazul n care comanda nu este gsit,
103
va fi afiat un mesaj de eroare.
[indicatori] - reprezint opiuni desemnate printr-o liter, precedat de semnul -
sau +, ce sunt destinate pentru a obine o rafinare a aciunii comenzii. n cadrul unei comenzi
pot fi specificai mai muli indicatori, precedai de unul din cele dou semne menionate anterior.
De exemplu, comenzile ls -a-l i ls -al sunt echivalente.
[argument1] [argument2] .. - reprezint nume de fiiere/directoare sau iruri
de caractere i constituie parametrii comenzii.
n funcie de comand, argumentele pot fi opionale sau obligatorii. Specificarea
argumentelor opionale, n cadrul sintaxei unei comenzi, se face prin introducerea lor ntre
paranteze ptrate.
Specificarea argumentelor (fiierelor) este permis de ctre shell i prin utilizarea
urmtoarelor metacartere (specificatori pentru nume de fiier global - wildcard):
* semnific orice ir de caractere, inclusiv irul vid
? semnific orice caracter
[] semnific o mulime de caractere
- semnific o secven lexicografic
Pe baza acestor metacaractere, shell-ul va genera nume de fiiere utilizate n cadrul
comenzilor.
Exemple:
*.c - indic toate fiierele avnd sufixul c;
Def[0-9] - indic fiierele def0, def1, , def9;
Prog[09] - indic fiierele prog0, prog9;
cap? - indic fiierele existente cap1, cap2, cap3;
cap* - indic fiierele existente cap1, cap2, cap3, cap1.c, cap2.c;
prog[*?] - indic att varianta prog*, ct i varianta prog?.
p*r - face referire la cele care ncep cu p i se termin cu r;
*c* - face referire la cele care conin litera c.
[abc]* - face referire la toate fiierele al cror nume ncepe cu a,b,c;
*[[I-N1-3] - face referire la fiierele ce se termin cu I,J,K,L,M,N,1,2,3;

Observaii:
1. Cele trei construcii lexicale comanda, [indicatori], [argument1]
[argument2] .., trebuie s fie separate prin spaii.
2. Toate comenzile accept intrri de la intrarea standard (de regul, tastatura), afieaz
ieirea la ieirea standard (de regul, ecranul terminalului).
3. UNIX ofer posibilitatea introducerii n linia de comand a mai multor comenzi ce se
vor executa serial. Comenzile trebuiesc separate prin caracterul ;.


3.4.2. Gestiunea utilizatorilor i grupurilor

UNIX este un sistem multiuser i multisesiune, utilizatorii putnd avea deschise mai
multe sesiuni de lucru pe un acelai calculator sau pe calculatoare diferite din reea.
Gestiunea utilizatorilor n cauz, precum i a grupurilor din care acetia fac parte,
reprezint o sarcin important a administratorului de sistem. Pentru ndeplinirea acesteia
UNIX-ul pune la dispoziie cteva instrumente i convenii care fac ca aceast sarcin s fie mai
uor de realizat. Astfel, accesul la resursele unui sistem UNIX se realizeaz, de regul, prin
intermediul unor conturi utilizator ce sunt setate de ctre administatorul de sistem, ulterior
instalrii sistemului de operare. Accesul se poate realiza i prin intermediul unor conturi sistem,
dintre acestea cel mai important fiind cel aferent utilizatorului root (superuser).
104
Prin folosirea de conturi separate pentru fiecare utilizator, securitatea sistemului este mult
mai bine asigurat, corespondena de unu-la-unu ntre utilizatori i conturi fcnd ca activitatea
de gestionare a acestora s fie mai uoar.

Contul utilizatorului root
Este un cont creat automat la momentul instalrii sistemului de operare UNIX. n timp ce
majoritatea conturilor utilizatorilor sunt setate astfel nct s se previn distrugerea accidental a
sistemelor de fiiere, contul root nu prezint nici o restricie, accesul su la toate resursele
sistemului, fiind deplin. Din acest motiv, folosirea acestui cont revine numai administratorului de
sistem, fiind utilizat n realizarea operaiilor de configurare i ntreinere a sistemului UNIX.
Pentru prevenirea apariiei unor incidente nedorite datorate folosirii necorespunztoare a
acestui cont, este indicat crearea unor conturi asociate unor nume de utilizator, care s aib ca
scop realizarea anumitor sarcini de administrare a sistemului, sarcini ce nu necesit un acces
deplin la resursele acestuia. De exemplu, se poate seta un cont utilizator destinat efecturii
copiilor de siguran (backup), un altul pentru accesul la pota electronic, la Internet, etc.
Protecia contului utilizatorului root, dar i a celorlalte conturi utilizator, se realizeaz
prin asignarea de parole. Alegerea acestora este indicat s se fac astfel nct depistarea lor de
ctre ceilali utilizatori ai sistemului, s fie dificil, iar schimbarea lor periodic se constituie
ntr-o msur de securitate obligatorie.

Nume de utilizator implicite (standard)
Aa cum am menionat anterior, exist o serie de nume de utilizator implicite ale cror
conturi sunt create n timpul procesului de instalare a sistemului de operare (n fapt este vorba de
crearea fiierului /etc/passwd) .
Aceste nume sunt utilizate de ctre sistemul de operare i administratorul de sistem,
pentru realizarea unor scopuri speciale.
Fiierul /etc/passwd
Toate informaiile referitore la conturile utilizatorilor sunt pstrate n fiierul
/etc/passwd. Acest fiier se afl n proprietatea utilizatorului root i are identificatorul
grupului (GID) setat la zero. Permisiunea de scriere este setat numai utilizatorului root,
ceilali utilizatori avnd numai permisiunea de citire.
Liniile din fiierul /etc/passwd sunt divizate n urmtorul format strict:
nume_utilizator:parola:UID:GID:comentariu:director_implicit:coma
nda_login
Fiecare linie este alctuit din cmpuri ce sunt separate prin simbolul :. Dac ntr-un
cmp nu este nimic introdus, acesta va rmne gol, iar simbolul : se va pstra pentru a asigura
c fiecare linie conine apte cmpuri. Denumirea cmpurilor (de la stnga la dreapta pentru
fiecare linie) i semnificaia lor, este urmtoarea:
Cmp Semnificaie
nume_utilizator Un identificator unic pentru utilizator
parola Parola utilizatorului (criptat)
UID Un numr unic care identific utilizatorul pentru sistemul de
operare
GID Un numr unic care identifc grupul la care aparine utilizatorul
comentariu Uzual, numele real al utilizatorului, sau o alt informaie
referitoare la acesta
director_implicit Directorul n care utilizatorii sunt plasai cnd se conecteaz la
sistem (director home)
comanda login Comanda executat cnd utilizatorul se conecteaz, n mod
normal un shell

105
Descrierea detaliat a cmpurilor respective este prezentat n continuare.
nume_utilizator
Este un cmp ce conine un ir format din opt caractere sau mai puin, ce identific n
mod unic fiecare utilizator. n specificarea numelui se pot folosi, pe lng litere, i linia de
subliniere, numerele, virgula i anumite caractere speciale. Deoarece cele mai multe comenzi
UNIX sunt scrise cu litere mici, convenia este ca numele de utilizator s fie i el scris tot cu
litere mici.
parola
n acest cmp sistemul stocheaz parola criptat a utilizatorului. Informaia respectiv
este foarte sensibil la modificri necorespunztoare, acestea putnd conduce la blocarea
contului utilizator cruia i este asociat. Parola poate fi modificat numai de ctre
administratorul de sistem (care s-a conectat cu numele de utilizator root), sau de ctre
utilizatorul nsui. Comanda folosit n acest scop este passwd.

Observaie:
Anumite versiuni de UNIX, datorit unor probleme poteniale de securitate, nu
stocheaz parolele utilizatorilor n fiierul /etc/passwd.

La momentul conectrii unui utilizator la sistem, parola introdus de acesta se compar n
mod logic cu un bloc de zero-uri, iar rezultatul este comparat cu intrarea corespunztoare din
fiierul de parole. Utilizatorului i este permis accesul numai dac cele dou informaii se
potrivesc.
Cmpul de parol este folosit pentru restricionarea accesului la sistem. Astfel, dac se
dorete ca un cont s nu poat fi folosit pentru accesarea sistemului, se plaseaz n cmpul de
parol corespunztor lui, un asterisc. n exemplul prezentat anterior, se poate observa c multe
conturi de utilizator standard au un asterisc n cmpul de parol, lucru ce efectiv blocheaz
accesul.
n situaia n care acest cmp nu conine nimic (este gol), la contul respectiv se permite un
acces nerestrictiv. Prin urmare, oricine poate folosi numele de utilizator respectiv pentru a i se
acorda accesul imediat, fr a i se solicita introducerea unei parole.

Observaie:
Nu se va completa cmpul de parol cu o parol (editndu-se fiierul
/etc/passwd) deoarece n acest fel, nu este posibil recrearea parolei criptate, iar contul
utilizatorului respectiv se va bloca.

UID
Fiecare nume de utilizator are asociat un identificator unic (UID). Acesta este folosit de
ctre sistemul de operare UNIX pentru a identifica anumite informaii ce sunt asociate cu
utilizatorul. Folosirea UID n locul numelui utilizatorului este preferabil, deoarece cu
numerele se lucreaz mai uor dect cu caracterele, i n plus ocup i mai puin spaiu
11
.
Numerele UID sunt n general asignate ntr-un domeniu specific. Cele mai multe
sisteme UNIX, de exemplu, aloc numerele de la 0 la 99 pentru conturile utilizator standard,
i numere UID de la 100 n sus pentru ceilali utilizatori. Asignarea numerelor UID pentru
utilizatorii obinuii ai sistemului, este bine s se fac secvenial.

GID
Identificatorul grupului, GID, este un numr folosit pentru a pstra urma grupului la
care utilizatorii aparin cnd ei se conecteaz la sistem (grup de startup). Numerele GID se

11
De exemplu, sistemul de operare Linux pstreaz urma tuturor proceselor lansate n execuie de ctre utilizator,
folosind UID i nu numele acestuia.
106
situeaz ntr-un domeniu ce ncepe cu 0 .am.d., numrul GID 100 fiind asignat grupului
users ce conine toi utilizatorii neprivilegiai ai sistemului.

comentariu
Acest cmp este folosit de ctre administratorul de sistem pentru adugarea oricrei
informaii pe care acesta o consider necesar n identificarea utilizatorului. Tipic, aceast zon
este folosit pentru a introduce numele complet al utilizatorului, cu toate c anumii
administratori de sisteme prefer s adauge alte informaii (de exemplu numele departamentului
unde lucreaz utilizatorul, sau numrul de telefon al acestuia).
Anumite comenzi ale sistemului de operare pot s foloseasc acest cmp pentru a afia
diverse informaii despre utilizatori, prin urmare coninutul su poate fi alterat.

directorul_implicit (home directory)
Acest cmp specific directorul n care va fi comutat utilizatorul dup ce acesta s-a
conectat la sistem (directorul curent). Fiecare utilizator din sistem trebuie s aib dedicat un
director implicit propriu
12
, variabila de mediu HOME din cadrul fiierelor de startup fiind
iniializat cu aceast valoare. Directoarele implicite ale utilizatorilor sunt localizate ntr-un
director comun, numit /home, ce este creat la momentul instalrii sistemului Linux. Calea
aferent directoarele implicite gsite aici este de forma: /home/nume_utilizator.
Alte versiuni de UNIX folosesc ca directoare implicite directoarele /usr sau /u .

comanda_login
Reprezint comanda ce va fi executat cnd procedura de conectare se termin. n cele
mai multe cazuri se lanseaz n execuie o comand shell, cum este csh sau bsh, pentru a
furniza utilizatorului un interpretor de comenzi (C Shell , respectiv Bourne Shell).
Dac cmpul este lsat gol, sistemul de operare lanseaz ca implicit shell-ul
Bourne. Schimbarea shell-ului ce va fi lansat poate fi realizat cu ajutorul comenzilor
chsh sau passwd s. Indiferent de comanda ce este folosit, verificarea faptului c aceasta
este permis se face prin cutarea ei n fiierul /etc/shells. Numai comenzile care se afl n
acest fiier sunt permise ca i intrri valide. Dac sistemul folosete fiierul /etc/shells,
trebuie verificat ca permisiunile de acces asupra sa i proprietarul s fie aceleai ca ale fiierului
/etc/passwd, altfel un utilizator i va putea modifica comanda_login.

Observaii:
1. n cazul n care se dorete invalidarea temporar a unui cont utilizator se va plasa un
asterisc ca prim caracter al parolei criptate. Nu se va altera nici un caracter al parolei existente, ci
numai se va aduga un asterisc n faa acesteia. Cnd se dorete reactivarea contului se va
elimina asteriscul introdus anetrior.
2. Din cauza unor poteniale probleme de securitate, anumite versiuni de UNIX nu
pstreaz parolele n fiierul /etc/passwd. Dac n cmpul de parol din cadrul tuturor
liniilor ce compun acest fiier, ntlnim caracterul x, atunci pentru stocarea parolelor este folosit
un alt fiier, numit shadow password file, situat n directorul /etc/shadow, i care
poate fi citit numai de ctre utilizatorul root.

Grupuri
Fiecare utilizator al unui sistem UNIX aparine unui grup. Un grup este o colecie de
utilizatori realizat n virtutea faptului c membrii ei au o caracteristic comun (de exemplu, pot
s lucreze toi n cadrul aceluiai departament, pot avea acces la un set de programe particular,
pot avea acces la un dispozitiv special cum este un scanner sau o imprimant laser, etc.) n

1 12 2
n cadrul sistemului Linux, acesta poart chiar numele utilizatorului.
107
general utilizatorii ce aparin unui grup, au aceleai permisiuni de acces asupra unor fiiere i
directoare particulare.
Utilizatorii pot aparine mai multor grupuri, dar la un moment dat, un utilizator poate fi
membru numai al unui grup (grup primar). Aceasta deoarece la orice moment de timp, este
permis un GID per utilizator.
Datorit faptului c grupurile pot avea setul lor de permisiuni de acces asupra unor fiiere
i directoare, apartenena sau nu a unui utilizator la un grup anume, poate determina sau
restriciona accesul la fiierele i directoarele respective.

Grupuri implicite (standard)
n urma procesului de instalare a sistemului de operare UNIX sunt create mai multe
grupuri implicite (standard) (n fapt este vorba de crearea fiierului /etc/group).
Apartenena la aceste grupuri este restricionat pentru utilizatorii obinuii deoarece
aceasta implic obinerea unor permisiuni de acces care sunt aceleai cu cele ale utilizatorului
root. Ca urmare membri acestor grupuri sunt reprezentai de utilizatorii implicii ai sistemului.
Informaia referitoare la grupuri este stocat n fiierul /etc/group, care este similar
n format cu fiierul /etc/passwd.
Fiecare grup are o linie proprie n cadrul acestui fiier, iar fiecare linie este compus din
patru cmpuri ce sunt separate prin simbolul :. Dou simboluri : imediat alturate semnific
faptul c nu a fost specificat o valoare anume pentru cmpul respectiv (cmpul este gol).
Formatul aferent fiecrei linii din cadrul fiierului /etc/group este urmtorul:
nume_grup:parola_grup:GID:utilizatori
unde:
nume_grup
Este un cmp ce conine un nume unic alctuit, n general, din opt caractere sau mai puin
(se folosesc de regul numai caractere alfanumerice) i care specific numele grupului respectiv.

parola
Acest cmp, de regul, fie este liber, fie conine un asterisc. El poate conine totui i o
parol, pe care utilizatorul trebuie s o introduc dac dorete s se asocieze grupului. Dei nu
toate versiunile de UNIX folosesc cmpul n cauz, el este pstrat din raiuni de compatibilitate
cu versiunile mai vechi.

GID
Ca i n cazul fiierului /etc/passwd, acest cmp este folosit pentru a stoca un numr
ce reprezint identificatorul grupului.

utilizatori
Este un cmp ce conine o list a tuturor utilizatorilor ce aparin acelui grup.


3.4.3. Permisiunile de acces asupra fiierelor i directoarelor

Sistemul de operare UNIX este un sistem multiuser, iar permisiunile de acces asupra
fiierelor i directoarelor reprezint una dintre facilitile de securitate ale acestui sistem.
n fapt, este vorba de o modalitate prin care sistemul protejeaz fiierele i directoarele
mpotriva oricrui acces neautorizat, intenionat sau accidental.
Toate fiierele i directoarele UNIX au permisiuni de acces i proprietari.
La momentul crerii unui fiier sau director, utilizatorul ce le-a creat devine n mod
automat proprietarul acestora (owner). Aceasta nseamn c el are privilegiul de a schimba
permisiunile (specific cine i ce permisiuni are) sau poate schimba proprietarul fiierului
108
(directorului)
13
.
Schimbarea permisiunilor de acces sau a proprietarului are drept scop furnizarea unui
acces mai complet asupra fiierelor i directoarelor.
Schimbarea proprietarului unui fiier sau director se face cu comanda:
chown proprietar_nou nume_fisier
Utilizatorii (dar i fiierele i directoarele) aparin grupurilor. Grupurile reprezint o
modalitate convenabil de a furniza autorizri de acces mai multor utilizatori, dar nu oricrui
utilizator din sistem. La momentul crerii unui utilizator, grupul implicit al acestuia este cel ce i
poart numele i care este creat odat cu utilizatorul.
Comanda prin care se poate schimba grupul cruia i aparine un fiier (director) este:
chgrp grup_nou nume_fisier
Proprietarul fiierului trebuie s fie membru al noului grup (grup_nou).

Observaie:
Grupul users este cel ce conine toi utilizatorii neprivilegiai ai sistemului.

Permisiunile de acces asupra fiierelor (directoarelor) acceptate de UNIX sunt:
- permisiunea de citire (r) - permite vizualizarea (citirea) coninutului unui fiier. n
cazul unui director permite afiarea coninutul acestuia (utiliznd, de exemplu,
comanda ls).
- permisiunea de scriere (w) - permite modificarea, tergerea i redenumirea unui
fiier. n cazul unui director existena acestei permisuni permite actualizarea,
tergerea i redenumirea directorului.
- permisiunea de execuie (x) - permite executarea fiierului prin tastarea numelui
acestuia. Pentru directoare permite accesul (comutarea) n directorul respectiv, i
efectuarea de operaii asupra fiierelor din cadrul su.

Observaii:
1. Dac un utilizator are permisiunea de scriere asupra unui director ce conine fiiere,
permisiunile asupra fiierelor respectiv sunt rescrise de permisiunile pe acel director.
2. Orice utilizator care are permisiunea de a citi un fiier poate s copieze acel fiier.
Cnd un fiier este copiat, copia se afl n proprietatea utilizatorului care a efectuat copierea.
Acesta poate s schimbe proprietarul i permisiunile, s editeze fiierul .a.m.d.
3. tegerea permisiunii de scriere asupra unui fiier nu permite ca acesta s fie ters.

Pentru a vizualiza permisiunile existente asupra unui fiier (director) se folosete
comanda:
ls l nume_fisier
De exemplu, se tasteaz:
ls l test.txt
Se va afia:
-rw-rw-r--1 student student 150 Dec 19 08:08 test.txt
Interpretarea informaiei afiate se face astfel:
Primul caracter din irul afiat indic tipul fiierului. Astfel, dac acest caracter este -
atunci este vorba de un fiier normal. Dac caracterul este d, atunci este vorba de un director,
iar dac caracterul este l este vorba de o legtur simbolic ctre un alt program sau fiier din
sistem
14
.
Urmtoarele nou caractere din irul afiat specific, n seturi de cte trei, permisiunile de

13
Utilizatorul root are permisiunea de a citi, scrie, i executa orice fiier din sistem, indiferent cine este proprietarul
acestora.
14
Sunt posibile i alte caractere.
109
acces pentru urmtoarele trei categorii diferite de entiti:
- proprietarul (owner) fiierului (directorului);
- grupul (group) (utilizatorii ce aparin aceluiai grup ca i proprietarul fiierului
/directorului)
15
;
- alii (others) (utilizatorii i grupurile altele dect proprietarul i cei din grupul
cruia i aparine proprietarul).
Dac unul din caracterele ce specific permisiunile (r, w, x) va aprea ca fiind nlocuit
prin caracterul -, atunci permisiunea respectiv, pentru entitatea n cauz, nu va fi acordat.
Alte informaii afiate de ctre comanda ls l includ: numele fiierului, data i timpul
crerii sale, mrimea acestuia.

Schimbarea permisiunilor de acces asupra fiierelor
Pentru a schimba permisiunile de acces asupra fiierelor se utilizeaz comanda:
chmod indicator nume_fisier.
unde indicator se va nlocui cu identitatea entitii pentru care se face schimbarea de
permisiune:
u utilizatorul care este proprietar al fiierului (owner)
g grupul cruia i aparine utilizatorul
o alii (alii dect utilizatorul i grupul acestuia) (others)
a oricine (u, g i o) (everyone)
urmat de tipul aciunii ce se dorete:
+ adaug o permisiune
- elimin o permisiune
= marcheaz permisiunea ca fiind singura acceptat
i litera (literele) aferente permisiunilor (r, w, x).

Observaii:
1. n cadrul sintaxei comenzii chmod, indicator se poate nlocui i cu un numr
format din trei cifre, a crui codificare este explicat n continuare.
2. Att timp ct suntem proprietar al unui fiier (director), sau suntem conectai ca
utilizator privilegiat (root), putem s modificm permisiunile fiierului (directorului) n orice
combinaie pentru proprietar, grup i alii.

Exist dou modaliti de modificare a permisiunilor.
O prim modalitate este cea n care se folosesc literele. Pentru a specifica entitile pentru
care se schimb permisiunile, se vor tasta literele u, g, o sau a n sintaxa comenzii
chmod. Litera (literele) vor fi urmate de unul dintre semnele +, -, sau =, pentru a
aduga, terge sau marca permisiunea ca fiind singura acceptat Semnul este urmat de litera
permisiunii respective (r, w, x).
Exemple:
Presupunem c permisiunile iniiale ale fiierului test.txt sunt:
-rw-rw-r--1 student student 150 Dec 19 08:08 test.txt
Conform permisiunilor afiate proprietarul (student) i grupul (student) pot citi i
scrie n fiier. Oricine alt utilizator ce nu aparine grupului student poate numai s citeasc
fiierul.
Dac tastm comanda:
chmod o+rw test.txt
numai alii (ce nu sunt nici proprietari i nici nu aparin grupului student) vor putea s
citeasc i s scrie fiierul.

15
Grupul din care face parte proprietarul.
110
Deoarece utilizatorul student este proprietar al acestui fiier, el va putea ntotdeauna s
schimbe permisiunile pentru a recpta accesul n citire i scriere.
Comanda ce se va tasta va fi:
chmod u+rw test.txt
cat test.txt
acesta este un test
S-a verificat i permisiunea n citire cu ajutorul comenzii cat.
Pentru tergerea tuturor permisiunilor asupra fiierului test.txt pentru oricine, se va
tasta comanda:
chmod a-rw test.txt
S vedem dac fiierul poate fi citit:
cat test.txt
cat: test.txt: Permission denied
Mesajul de eroare returnat de sistem, Permission denied, semnific faptul c
execuia comenzii anterioare (cat), nu este posibil datorit lipsei permisiunii de citire necesare.
Alte exemple de setri ce pot fi folosite n cadrul comenzii chmod sunt:
g+w adaug permisiunea de scriere pentru grup
o-rwx terge toate permisiunile pentru alii
u+x permite proprietarului fiierului s execute fiierul
a+rw pemite oricui s citeasc i s scrie n fiier
ug+r permite proprietarului i grupului s citeasc fiierul
g=rx permite grupului numai s citeasc i s execute fiierul, fr scriere

O a doua metod de modificare a permisiunilor asupra fiierelor este cea bazat pe un
sistem de codificare numeric. Acesta permite specificarea permisiunilor asupra fiierelor sub
forma unui numr din 3 cifre octale.
Este important de a nelege cum lucreaz acest sistemul de codificare, deoarece numerele
n cauz sunt folosite, att pentru a schimba permisiunile asupra fiierelor, ct i de ctre
mesajele de eroare ce implic permisiunile.
n cadrul unui astfel de numr prima cifr codific permisiunile pentru proprietar, a doua
pe cele pentru grup i a treia pe cele pentru alii.
Conform sistemului de codificare respectiv, seturile de cte trei permisiuni (rwx) pot fi
interpretate ca un numr binar pe 3 bii. Astfel, o permisiune acordat corespunde unei cifre de 1,
iar o permisiune neacordat corespunde unei cifre de 0. Prin urmare pentru setul (rx)
combinaia binar corespondent va fi 101 care n zecimal este egal cu: 4+0+1=5.
Cifrele individuale sunt codificate prin nsumarea tuturor permisiunilor, "permise" pentru
acel utilizator particular16 dup cum urmeaz:

Permisiune citire 4
Permisiune scriere 2
Permisiune execuie 1

Sunt posibile urmtoarele combinaii:
0 - nici o permisiune
4 - numai citire
2 - numai scriere
1 - execuie
6 - citire i scriere
5 - citire i execuie
3 - scriere i execuie

16
Deci dintr-un set de trei.
111
7 - toate
Prin urmare o permisiune asupra unui fiier, codificat prin numrul 751, nseamn c
proprietarul are permisiunile r,w,x (4+2+1=7), grupul are permisiunile r i x
(4+0+1=5) i alii au numai permisiunea x (0+0+1=1).

Observaie:
Setarea permisiunilor 666 sau 777 va permite ca orice utilizator s poat citi i scrie
ntr-un fiier sau director. Asemenea setri pot determina fraudarea fiierelor, i ca urmare nu
sunt recomandate.
n continuare sunt prezentate cteva dintre cele mai obinuite setri, valori numerice,
precum i semnificaia lor:
-rw------- (600) - numai proprietarul are permisiunile r i w
-rw-r--r-- (644) - numai proprietarul are permisiunile r i w; grupul i alii
pot numai s citeasc
-rwx------ (700) - numai proprietarul are permisiunile r w x
-rwxr-xr-x (755) - proprietarul are permisiunile r w i x; grupul i alii pot
numai s citeasc i s execute
-rwx--x--x (711) - proprietarul are permisiunile r w x; grupul i alii pot
numai s execute
-rw-rw-rw- (666) - oricine poate s citeasc i s scrie n fiier
-rwxrwxrwx (777) - oricine poate s citeasc, s scrie, s execute.

Schimbarea permisiunilor asupra directoarelor
Se poate realiza exact n acelai fel ca i n cazul fiierelor, deci tot cu ajutorul comenzii
chmod. Orice utilizator care are permisiunea de scriere ntr-un director poate terge fiiere din
acel director, chiar dac utilizatorul are sau nu permisiunea de scriere asupra fiierului.
Deoarece nu putem "executa" un director, cnd se seteaz sau terge permisiunea de
execuie asupra acestuia, n fapt se seteaz sau se terge permisiunea de a cuta n acel director.
De exemplu s tastm:
chmod a-x aplicatii
pentru a terge permisiunea de execuie pentru toi utilizatorii.
Iat ce se ntmpl cnd se ncearc folosirea comenzii cd n directorul aplicatii:
cd aplicatii
bash:aplicatii: Permission denied
S restaurm permisiunea de execuie pentru proprietar i pentru grupul acestuia:
chmod ug+x aplicatii
Acum, dac vom verifica cu ajutorul comenzii ls dl se va vedea c numai
others au interzis accesul la directorul aplicatii.
Pentru a permite oricui de a avea acces n citire i scriere asupra directorului
aplicatii se va tasta:
chmod R a+rw aplicatii
Prin adugarea indicatorului R, se pot schimba permisiunile pentru ntreaga structur
director.

Observaii:
1. Modalitatea de a obine acces la un fiier atunci cnd nu avem permisiunile necesare, i
fr a ne deconecta de la sistem, este de a utiliza comanda su. Acesta permite conectarea cu
numele altui utilizator ce are permisiunile necesare. Evident va trebui s cunoatem parola
utilizatorului respectiv.
2. Unele versiuni de UNIX furnizeaz un bit suplimentar numit sticky bit ca
parte a permisiunii asupra unui director. Scopul acestui bit este de a permite numai proprietarului
112
directorului, proprietarului fiierului sau utilizatorului root s tearg i s redenumeasc
fiiere.


3.4.4. Sistemul de fiiere al UNIX

Un sistem de fiiere reprezint modul de organizare i exploatare a informaiilor stocate
pe un suport de memorie extern n vederea accesrii i prelucrrii lor de ctre sistemul de
operare.
Din punctul de vedere al utilizatorului, sistemele de fiiere prezint o organizare bazat
pe conceptele de fiier i director.
Fiierele sunt entiti care ncapsuleaz informaia de un anumit tip, iar directoarele
grupeaz n interiorul lor fiiere i alte directoare.
Deci sistemul de fiiere are o organizare ierarhic, fiierele fiind grupate n directoare
care sunt structurate pe mai multe niveluri ntr-o structur arborescent. Directorul de nivel cel
mai nalt, din cadrul acestei arborescene, se numete director rdcin, i este simbolizat prin
caracterul /.
Orice fiier sau director poate fi identificat prin numele su indicat ca nume de cale, fie n
mod absolut, fa de directorul rdcin, fie n mod relativ, fa de directorul curent.

3.4.4.1 Partiii
Un sistem de fiiere este n general creat pe hard disc. Sub sistemul de operare UNIX este
posibil instalarea mai multor sisteme de fiiere, fiecare dintre acestea fiind plasat ntr-o
zon proprie pe hard disc. Aceste zone n care este subdivizat hard discul se numesc partiii
17
.
La nivel utilizator, fiecare partiie se comport ca un disc de sine stttor memornd un
sistem de fiiere. Informaia referitoare la partiii se memoreaz la nceputul discului, n aa-
numita tabel de partiii. Aceasta conine 4 intrri (cte una pentru fiecare partiie posibil) n
care sunt memorate poziiile, dimensiunile i tipurile partiiilor de pe disc. Cele 4 partiii se
numesc partiii primare, fiind posibil ca n interiorul oricreia dintre ele s se creeze cte o nou
tabel de partiii, referind partiii care fizic se afl n interiorul partiiei curente i care se numesc
partiii extinse.
Sistemul de operare UNIX necesit prezena a cel puin o partiie. Partiia necesar
menionat anterior se numete partiie root. n cadrul ei rezid software-ul de sistem i
fiierele de configurare. Deoarece partiia root nu are menirea de a pstra datele utilizatorilor,
este necesar crearea de partiii separate pentru directoarele home ale utilizatorilor, pentru
fiierele temporare, .a.
n UNIX, echipamentelor periferice le sunt asociate fiiere de dispozitiv, ceea ce permite
utilizarea i n cazul acestora, a comenzilor ce sunt folosite pentru fiierele obinuite. Acest lucru
este valabil i pentru hard discuri. Ca urmare, perntru identificarea lor se folosete urmtoarea
schem, ce este funcie de tipul unitii de control la care s-a conectat hard discul.
Astfel, sub sistemul Linux, hard discurile conectat la o unitate de control IDE, sunt
denumite:
/dev/hd[unitate_hard_disc]
Fiecare unitate de hard disc IDE este identificat printr-o liter. Astfel, discul master
(primul) din cadrul primei uniti de control este a, cel de-al doilea disc (slave) din cadrul
aceleiai uniti de control este b. Primul disc ataat celei de a doua uniti de control este c,
.a.m.d.
Pentru a referi partiiile create pe astfel de hard discuri, se utilizeaz numere de ordine.
De exemplu, cea de a treia partiie a unitii de hard disc slave de pe prima unitatea de

17
Fiecare partiie este o mulime continu de blocuri. Un bloc este format dintr-un sigur sector (cum este cazul la
dischete) sau din mai multe sectoare (cazul hard discurilor).
113
control este referit: /dev/hdb3.
Unitile de hard disc conectate unei uniti de control SCSI folosesc aceeai schem
de identificare, cu excepia c n loc s utilizeze drept prefix construcia /dev/hd, folosesc
/dev/sd, urmat de litera corespunztoare. Referirea partiiilor este similar.
Astfel, cnd ne referim la a doua partiie de pe primul hard disc ataat unei uniti de
control SCSI, vom folosi specificaia: /dev/sda2. Atunci cnd dorim s ne referim la
ntregul disc, vom specifica toat informaia cu excepia numrului asociat partiiei. De
exemplu, pentru a ne referi la ntregul disc master conectat pe prima unitatea de control SCSI,
vom utiliza specificaia: /dev/sda.
n cele dou scheme de identificare anterioare, /dev este numele directorului
aparinnd arborescenei standard UNIX, ce conine fiierele de dispozitiv asociate
echipamentelor periferice din cadrul sistemului.

3.4.4.2.Tipuri de fiiere
n cadrul sistemului de fiiere al UNIX exist mai multe tipuri de fiiere. Acestea sunt:
- fiiere normale (obinuite)
- directoare (fiiere catalog)
- legturi hard
- legturi simbolice
- socket-uri
- conducte cu nume (fiiere FIFO)
- fiiere de dispozitiv (fiiere speciale)

Fiiere normale
Un fiier normal este un fiier permanent, ce este privit de ctre sistemul de operare ca un
ir de octei fr o organizare logic special, i a crui structur intern este irelevant din
punctul de vedere al administratorului de sistem.
Un astfel de fiier poate conine informaie binar (n cazul unui fiier n format
executabil), sau linii de text separate prin caracterul linie nou (012
8
), structurarea sa logic
revenind exclusiv n sarcina programatorului.
O comand ls l va afia n cazul unui fiier normal, o informaie similar cu
urmtoarea:
-rw------- 1 student ise 42 May 12 13:09 fistest
Se observ c primul caracter afiat este -. Acesta semnific faptul c fiierul respectiv
este un fiier normal.

Directoare
Sunt fiiere de un tip special ce conin o list de alte fiiere. Informaiile din lista
respectiv fac referire la numele i locaiile fiierelor, mrimea lor, timpul aferent crerii i
modificrii acestora.
Directoarele pot ele nile s conin subdirectoare, care la rndul lor pot s conin alte
subdirectoare, .a.m.d., formnd n acest fel o structur ierarhic (arborescent).
Se poate aprecia deci c fiierele director reprezint o modalitate de a structura logic
sistemul de fiiere.
Un director poate fi citit numai de ctre sistemul de operare UNIX sau de ctre
programe special scrise pentru a efectua procesarea acestuia.
Cu ajutorul comenzii ls l se pot identifica directoarele datorit apariiei caracterului
d ce este plasat naintea permisiunilor de acces:
drwx------ 2 student ise 512 May 12 13:08 public


114
3.4.4.3 Legturi la fiiere
n anumite circumstane este necesar
18
, de a furniza nume alternative pentru un acelai
fiier.
Acest lucru poate fi realizat prin legarea unui nume de fiier la altul, o legtur fiind o
modalitate de a furniza un alt nume unui acelai fiier
19
. Legarea unui fiier la un alt nume nu
implic duplicarea coninutului fiierului respectiv.
Este posibil de a lega un fiier la un alt nume n cadrul aceluiai director sau la acelai
nume n cadrul unui alt director.
Orice operaie care se execut asupra fiierului legtur (mai puin tergerea) i va avea
efectul de fapt asupra fiierului indicat de legtur. Dac este solicitat tergerea, efectul depinde
de tipul legturii respective.
Legturi hard (hard links)
Acest tip de legtur creeaz o referin (un pointer) ctre un fiier deja existent, fr
duplicarea coninutului fiierului respectiv. Deci, numele original al fiierului i numele fiierului
legtur fac referire ctre aceeai adres fizic (acelai i-nod).
Ca urmare, la afiarea coninutului unui director acesta apare c ar conine dou fiiere
identice, lucru ce determin sistemul s le trateze n consecin.
Exist dou limitri importante ale unei legturi hard, i anume: un director nu poate avea
o legtur hard, i o astfel de legtur nu poate exista peste mai multe sisteme de fiiere deoarece
ea partajeaz un i-nod.
Este posibil de a terge numele fiierului original fr a terge numele fiierului legtur.
Sub aceste circumstane, fiierul nu este ters, dar intrarea n director a fiierului original va fi
tears iar contorul numrului de legturi este decrementat cu 1. Blocurile de date ale fiierului
original sunt terse atunci cnd contorul numrului de legturi devine zero.
Legturi simbolice (symbolic links)
Legturile simbolice sunt de fapt fiiere distincte, marcate cu un cod special, care au ca i
coninut numele complet al fiierului indicat.
Exist deci dou fiiere: unul este fiierul original, i altul este fiierul legtur ce
conine numele fiierului original.
Spre deosebire de o legtur hard, o legtur simbolic poate s existe peste mai multe
sisteme de fiiere i poate fi folosit pentru a lega att directoare ct i fiiere.
Dezavantajul unui legtrui simbolice este c pentru ea (fiind fiier) trebuie creat un i-nod
separat i, n plus, ocup spaiu pe disc prin coninutul ei.
tergerea unei astfel de legturi nu afecteaz fiierul original, dar dac acesta este ters,
legtura simbolic va face referire ctre un fiier care nu mai exist.
Pentru a genera legturi hard sau simbolice la fiiere, se utilizeaz o comand specific,
numit ln. Sintaxa ei general este:
ln nume_fisier nume_legatura
unde nume_fisier este fiierul ce exist deja, iar nume_legatura, este numele
fiierului legtur creat.
Implicit comanda creeaz o legtur hard.
De exemplu, dac n directorul curent exist un fiier numit test1, i tastm comanda
ls -l, se vor afia urmtoarele informaii:
-rw------- 1 stud1 ise 42 May 12 13:04 test1
Pentru a lega hard fiierul test1 la fiierul test2 n directorul curent, vom executa
comanda:
ln test1 test2

18
De exemplu, dac dorim s permitem accesul altor utilizatori, la propriile noastre fiiere, fr ca pentru aceasta s
le punem la dispoziie o copie a fiierelor respective.
19
Practic, o legtur este vzut de ctre utilizator ca un fiier cu un nume propriu, dar care n realitate face referire
la un alt fiier de pe disc.
115
Tastnd din nou comanda ls l, se vor afia informaiile:
-rw------- 2 stud1 ise 42 May 12 13:04 test2
-rw------- 2 stud1 ise 42 May 12 13:04 test1
Apar deci dou fiiere care au aceeai mrime, 42. Totodat numrul de legturi (coloana
a doua), a fost incrementat de la 1 la 2.
Tastnd comanda ls il, se vor afia informaiile:
9180 -rw------- 2 stud1 ise 42 May 2 8:04 test2
9180 -rw------- 2 stud1 ise 42 May 2 8:04 test1
Se observ c ambele nume de fiier fac referire ctre un acelai i-nod, 9180. Este
deci vorba de dou nume care fac referire ctre un acelai fiier.
Unul dintre indicatorii cei mai utilizai ai comenzii ln este -s, folosirea acestuia
pemind generarea unei legturi simbolice. Formatul comenzii ln, n acest caz, este:
ln -s nume_fisier nume_legatura
De exemplu, pentru a crea o legtur simbolic la fiierul test1 n directorul curent,
se va tasta comanda urmtoare:
ln s test1 test2
Aceasta creeaz un fiier test2 legat, care va conine numele lui test1.
Tastnd o comand ls -l n directorul curent, se vor afia informaiile:
-rw------- 2 stud1 ise 42 May 12 13:04 test1
lrw------- 1 stud1 ise 42 May 12 13:04 test2test1
Fiierul test2 apare marcat ca fiind o legtur simbolic n cadrul sistemului de
fiiere.
Socket-uri
Un socket nu este n fapt un fiier real, ci un mecanism folosit de UNIX pentru a
comunica ntre dou calculatoare gazd, utiliznd pentru aceasta porturi reea.
Fiierele socket sunt identificate de ctre setrile lor de permisiuni ce ncep cu
caracterul s. O comand ls l asupra unui fiier socket afieaz o informaie similar
cu urmtoarea:
srwxrwxrwx 1 root admin 0 May 10 14:38 X0
Pentru tergerea unui fiier socket se va folosi comanda rm.
Conducte cu nume (named pipes)
O conduct cu nume este un fiier temporar ce permite comunicaia ntre procese prin
mecanismul pipe (conduct). Astfel, procesul emitent scrie date n conducta cu nume, iar
procesul receptor citete datele din aceasta. Procesarea datelor din conducta cu nume se face pe
baze FIFO.




Existena unui astfel de fiier este limitat la intervalul de timp n care procesele
comunic.
Recunoaterea conductelor cu nume se face datorit caracterului p cu care ncepe
informaia aferent permisiunilor lor de acces, informaie afiat la executarea unei comenzi ls
l:
prw------- 1 root admin 0 May 12 22:02 nume_conducta

Fiiere de dispozitiv
O particularitate care difereniaz sistemul de operare UNIX de alte sisteme, o
constituie asocierea dispozitivelor periferice cu fiiere de dispozitiv (fiiere speciale). Fiierele
de dispozitiv sunt citite/scrise, din punctul de vedere al utilizatorului, exact ca i cele normale,
rezultatul unei astfel de operaii fiind activarea driver-ului asociat perifericului respectiv. Un
Proces 1 Proces 2
Scrie Citete fiier pipe
116
program de aplicaie poate deci utiliza aceeai sintax pentru a accesa un fiier normal sau un
fiier de dispozitiv. Fie, de exemplu, comanda de copiere a fiierului test.p:
cp test.p /usr/diploma/copie.p
Prin lansarea acestei comenzi se realizeaz copierea fiierului test.p n fiierul
destinaie /usr/diploma/copie.p. Dac numele fiierului destinaie se nlocuiete cu un
nume de fiier de dispozitiv, de exmplu imprimanta (/dev/lp0), obinem o listare a fiierului
test.p.
cp test.p /dev/lp0
Unui dispozitiv periferic i este asociat cel puin un fiier de dispozitiv, care va conine
ntotdeauna informaii despre driver-ul (programul de comand) al acelui periferic. Toate
fiierele de dispozitiv rezid n directorul /dev.
Spre exemplu, fiecrei uniti de disc i corespunde cte un fiier n directorul /dev. n
Linux, primei uniti de dischet i corespunde fiierul /dev/fd0, celei de-a doua
/dev/fd1, .a.m.d. Primei uniti de hard disc cu interfa IDE, din sistem, i corespunde
fiierul special /dev/hda, iar primei sale partiii, fiierul /dev/hda1. A doua partiie de pe
primul disc are ca i corespondent fiierul /dev/hda2, a doua unitate de hard disc IDE este
referit ca fiind /dev/hdb, .a.m.d.
n funcie de unitatea de informaie pe care o transmit/recepioneaz la un moment dat,
dispozitivele periferice se mpart n dou tipuri:
- dispozitive orientate pe caractere (terminale, imprimante)
- dispozitive orientate pe blocuri (uniti de disc)
Evident, funcie de aceast caracteristic, dispozitivelor n cauz le corespund fiiere de
dispozitiv specifice.
n cadrul unui sistem pot exista mai multe dispozitive periferice de acelai tip. Pentru a
distinge ntre ele, UNIX-ul asociaz fiecrui dispozitiv, dou numere:
- un numr major, care indic tipul dispozitivului (de exemplu, imprimanta)
- un numr minor, care indic al ctelea dispozitiv periferic este n clasa de dispozitive
de acelai tip (de exemplu, a doua imprimant)
Fiierele de dispozitiv caracter se gsesc localizate n directorul /dev i furnizeaz un
mecansim pentru comunicarea, un caracter la un moment dat, cu drivere-le dispozitivelor din
sistem.
Informaia afiat de o comand ls l n cazul unui astfel de fiier, este similar cu
urmtoarea:
crw-rw-rw- 1 root wheel 21, 4 May 12 13:40 ptyp4
Se observ c permisiunile de acces n acest caz ncep cu caracterul c.
Fiierele de dispozitiv bloc se gsesc, de asemenea, localizate n directorul /dev, fiind
folosite pentru a comunica cu drivere-le de dispozitiv. Ele sunt asociate ns, unor dispozitive
periferice ce transfer blocuri mari de date la un moment dat (cum este hard discul).
Aceste fiiere sunt identificate de ctre caracterul b ce apare n faa permisiunilor de
acces, atunci cnd se tasteaz comanda ls l:
brw------- 2 root staff 16, 2 Jul 29 2006 fd0c
Crearea fiierelor de dispozitiv, bloc sau caracter, ct i a conductelor cu nume, se poate
realiza utiliznd comanda mknod. Sintaxa acestei comenzi este:
mknod fisier_dispozitiv b|c|p|u major minor, unde:
b semnific faptul c fisier_dispozitiv este un fiier asociat unui dispozitiv bloc
c i u semnific faptul c fisier_dispozitiv este un fiier asociat unui dispozitiv
caracter
p semnific faptul c fisier_dispozitiv este un fiier asociat unei conducte cu nume
Unul dintre aceste argumente trebuie s fie prezent n sintaxa comenzii. Este necesar, de
asemenea, specificarea numerelor major i minor (cu excepia cazului cnd se creeaz o conduct
cu nume). tergerea fiierelor create cu comanda mknod se face cu ajutorul comenzii rm.
117

CAP.4. PROIECTAREA SISTEMELOR INFORMATICE

4.1. SISTEME INFORMATICE

Din punct de vedere funcional, sistemul informatic are mai multe definiii, n funcie de
scop, elementele din structur i relaiile dintre elemente; cea mai general definiie l prezint ca
pe un sistem de colectare, memorare, prelucrare i distribuire a informaiilor care utilizeaz
calculatorul electronic.
Fiecrui sistem informatic i se asociaz un sistem de prelucrare a datelor, n care datele se
prezint pe diferii supori de memorare, iar procesele de prelucrare sunt concretizate n
proceduri (automate i manuale) executate de diferite echipamente de tehnic de calcul i
teletransmisie i de ctre personal specializat.
Punnd n eviden faptul c utilizarea tehnicii de calcul a produs modificri majore n
modul de realizare a activitilor informaionale, Gh. Sabu i I. Lungu definesc sistemul
informatic ca fiind un ansamblu de elemente interconectate funcional n scopul automatizrii
obinerii informaiei i fundamentrii deciziilor
20
.
Aceiai autori identific n structura sistemului informatic urmtoarele elemente:
1. Baza tehnic (hardware-ul sistemului informatic), cuprinde totalitatea mijloacelor
tehnice de culegere, transmitere, prelucrare i stocare a datelor.
2. Sistemul de programe (software-ul), se refer la totalitatea programelor necesare
funcionrii sistemului informatic n conformitate cu funciile i obiectele ce i-au fost stabilite,
respectiv programele de baz i programele aplicative.
3. Baza tiinifico-metodologic este constituit din sistemul indicatorilor economici,
procese i fenomene economice, precum i din metodologiile de realizare a sistemelor
informatice.
4. Baza informaional cuprinde datele supuse prelucrrii fluxurilor informaionale,
sistemele i nomenclatoarele de coduri.
5. n resursele umane se include personalul implicat cu funcionarea sistemului
informatic, iar cadrul organizatoric este cel specificat n regulamentul de organizare i
funcionare al organismului economic n care funcioneaz sistemul informatic.
Sistemul informatic al unei ntreprinderi este definit de Robert Reix ca fiind elementul
care nglobeaz toate componentele automatizate ale cror interaciuni sunt la nivel
informaional. Obiectivul su const n furnizarea la diferite niveluri de organizare a
informaiilor ce pot nsoi i controla funcionarea ntreprinderii
21
.
Exist alte opinii potrivit crora sistemul informatic poate fi avut n vedere att ca model
extern, ct i sub aspectul unui model intern
22
.
Modelul extern al sistemului informatic se refer la arhitectura funcional orientat
ctre utilizator, pe care l intereseaz informaiile i procesele lor de prelucrare.
Modelul intern al sistemului informatic se refer la structura fizic orientat ctre
echipamente, unde intereseaz datele, procedurile de prelucrare, echipamentele, mediile de
programare i sistemele de operare.
Tipuri de sisteme informatice. Sistemele informatice pot fi clasificate n funcie de
diferite criterii
23
.
I. Clasificarea n concordan cu nivelurile organizatorice. Organizaiile sunt

20
Sabu, Gh., Lungu, I. - Sisteme informatice i baze de date, ASE, Bucureti, 1993, p. 229
21
Reix, R. - Systemes d'information et management des organisation, Vuibert, Paris, 1995, p.46;
22
Turbu, Gh. (coordonator) - Inginerie de sistem, automatizri i informatic n transporturi, vol. 2, Editura
Tehnic, Bucureti, 1989
23
Turban, E., McLean, E., Wetherbe, J., - Information Tehnology for Management, John Wiley & Sons, New-
York, 1996
118
compuse din componente cum ar fi departamente, divizii, echipe etc. Aceste departamente
raporteaz unui nivel organizatoric mai nalt cum ar fi o divizie sau un sediu central ntr-o
manier ierarhic. Aceasta este o structur ierarhic tradiional cu mai multe niveluri.
O cale pentru organizarea sistemului informatic este construirea lui n conformitate cu
structura organizatoric. Aceste sisteme pot fi independente sau pot fi interconectate. De
exemplu, un departament de resurse umane poate fi att la nivel central ct i ct i n fiecare
divizie sau sucursal. Sistemele informatice construite conform cu nivelurile organizatorice sunt:
1. Sisteme informatice departamentale. Frecvent, o organizaie folosete mai multe
programe aplicative ntr-o singur arie funcional. De exemplu n gestiunea personalului, este
posibil s se foloseasc un program pentru selectarea solicitanilor de locuri de munc i un
program pentru monitorizarea fluctuaiei personalului. Unele aplicaii sunt complet independente
n timp ce altele sunt interconectate. Colecia de programe aplicative n domeniul resurselor
umane se poate numi Sistem informatic pentru resurse umane.
2. Sisteme informatice organizaionale. n timp ce un sistem informatic departamental
este n mod obinuit legat de o arie funcional, se poate vorbi frecvent de colecii de aplicaii n
mai multe sau n toate ariile funcionale. O astfel de colecie poate fi descris ca un sistem
informatic organizaional.
3. Sisteme informatice interorganizaionale. Unele sisteme informatice sunt foarte
complexe i implic mai multe organizaii. De exemplu sistemul de rezervare a biletelor de avion
n lumea ntreag este compus din mai multe sisteme aparinnd diferitelor companii aeriene.
Deci sistemele informatice interorganizaionale sunt formate din mai multe sisteme informatice
organizaionale la care se adaug sistemele de legtur dintre acestea.
II. Clasificarea n concordan cu ariile funcionale. Dup cum s-a observat, sistemele
informatice departamentale sunt construite n concordan cu ariile funcionale tradiionale:
1. Sistemul financiar-contabil,
2. Sistemul pentru producie,
3. Sistemul pentru activitatea comercial,
4. Sistemul pentru gestiunea resurselor umane,
5. Sistemul pentru management.
n fiecare arie funcional, sunt efectuate operaii de baz computerizate care sunt
eseniale pentru activitatea organizaiei. Pregtirea unui tat de plat sau nregistrarea unui client
sunt exemple tipice. Asemenea operaii sunt numite operaii scop central (mission-central tasks).
Sistemele informatice care suport asemenea operaii se numesc sisteme tranzacionale (TPS).
Sistemele tranzacionale execut operaii care se efectueaz n toate ariile funcionale dar n
special n contabilitate i finane.
III. Clasificarea n concordan cu suportul furnizat de sistem. A treia modalitate de a
clasifica sistemele informatice este in concordan cu tipul suportului pe care l furnizeaz,
indiferent de aria funcional implicat. De exemplu, un sistem informatic poate fi un suport
pentru funcionari n aproape orice arie funcional. Similar, managerii, indiferent unde lucreaz,
pot utiliza un sistem computerizat ca suport pentru luarea deciziilor.
Principalele sisteme dup aceast clasificare sunt:
1. Sisteme tranzacionale (TPS - Transaction Processing System);
2. Sisteme manageriale (MIS - Management Information System);
3. Sisteme automatizate pentru birouri (OAS - Office Automation System);
4. Sisteme suport pentru grup (GSS - Group Support System);
5. Sisteme suport pentru decizii (DSS - Decision Support System);
6. Sisteme executive sau sisteme suport (EIS - Executive Information System or Support
System), utilizate n activitatea de execuie;
7. Sisteme suport inteligente (ISS - Intelligent Support System), cuprind sisteme expert
(ES - Expert Systems) i reele neuronale artificiale (ANN - Artificial Neural Networks).
Implementarea unei aplicaii specifice poate implica dou sau mai multe din sistemele prezentate
mai sus. De exemplu, un sistem suport pentru decizii poate fi combinat cu un sistem expert
119
pentru a realiza un sistem informatic care s fie utilizat n realizarea unui program promoional
de marketing.
IV. Clasificarea n concordan cu arhitectura sistemelor informatice - depinde de
scopul pentru care a fost construit. Arhitectura i infrastructura sunt dou aspecte ale sistemelor
informatice ce se intercondiioneaz reciproc.
Sistemele informatice pot fi clasificate n concordan cu arhitectura lor i principalele
categorii sunt:
1. Sisteme informatice bazate pe mainframe-uri;
2. Sisteme informatice bazate pe PC-uri;
3. Sisteme informatice distribuite.
V. Clasificarea dup natura activitilor pentru care sunt construite sistemele
informatice. Potrivit acestei clasificri sistemele informatice se mpart n:
1. sisteme operaionale;
2. sisteme tactice (manageriale);
3. sisteme strategice.
Sistemele operaionale ofer suportul necesar operaiilor zilnice ale unei organizaii cum
ar fi nregistrarea unei facturi sau a numrului de ore pe care le lucreaz un muncitor. De
asemenea, acestea ofer suport i deciziilor operaionale, decizii care se refer la un interval de
timp scurt. Sistemele informatice necesare activitilor i deciziilor operaionale sunt n general
cele tranzacionale, executive precum i sistemele informatice suport pentru decizii. Sistemele
operaionale sunt utilizate de ctre conductorii de la nivelele joase, operatori i funcionari.
Sisteme tactice (numite i sistemele manageriale) sunt legate de activitile efectuate de
ctre managerii de la nivelele medii ale ntreprinderii, activiti precum planificarea organizarea
i controlul pe termen scurt i mediu. Sistemele tactice fa de cele operaionale au o sfer mai
larg de cuprindere. Sistemele manageriale se bazeaz n general pe sistemele informatice
manageriale, dar i pe sistemele informatice suport pentru decizii, sisteme informatice executive
i chiar sisteme informatice inteligente.
Sistemele strategice sunt legate de situaiile pe termen lung i de deciziile care schimb
semnificativ maniera n care vor fi realizate obiectivele firmei. n mod tradiional sistemele
strategice implic doar planificarea de lung durat. Cele mai utilizate sisteme informatice ca
suport pentru sistemele strategice sunt cele suport pentru luarea deciziilor i sistemele expert.


4.2. METODOLOGII DE REALIZARE A SISTEMELOR INFORMATICE

Realizarea sistemelor informatice este o activitate complex care mbin un mare numr
de activiti eterogene: analiz, proiectare, programare cu un pronunat caracter creativ i la
care coopereaz mai multe uniti organizatorice, ocazionnd eforturi materiale, financiare i
umane pe o perioad ndelungat.
Folosirea eficient a resurselor i necesitatea realizrii unor sisteme informatice
performante au repus ordonarea ntr-o succesiune bine stabilit pe etape i subetape a acestui
proces determinnd conturarea unor metodologii de realizare a sistemelor informatice.
Prin metodologia de realizare a sistemelor informatice se stabilesc: componentele
procesului de realizare:
- etapele, subetapele, activitile i coninutul lor;
- fluxul executrii componentelor;
- metodele, tehnicile i instrumentele de realizare.

4.2.1. Etapele de realizare a sistemelor informatice
Sistemul informatic are un ciclu propriu de via, care ncepe cu decizia de realizare,
cuprinde faza de elaborare, faza de utilizare, faza de perfecionare i se ncheie cu decizia de
abandonare n forma existent i nlocuirea cu un nou sistem.
120
Acestui ciclu de via i corespund etape specifice strilor succesive prin care trece sistemul
informatic, etape caracterizate prin activiti distincte. Etapele realizrii unui sistem
informatic sunt:
- analiza sistemului informaional existent (analiza de sistem);
- proiectarea sistemului informatic;
- elaborarea i testarea programelor;
- implementarea sistemului informatic;
- exploatarea curent i meninerea n funciune a sistemului informatic.
1) Analiza sistemului informaional existent urmrete delimitarea ariei de cuprindere a
sistemului i formularea cerinelor i restriciilor globale de realizare. Pentru a atinge acest scop,
n aceast etap se face un studiu amnunit al sistemului existent, se apreciaz msura n care
sistemul existent este capabil s rspund n continuare exigenelor conducerii tiinifice a
agentului economic, se apreciaz oportunitatea realizrii unui sistem informatic i se formuleaz
principalele restricii i cerine pentru viitorul sistem informatic.
2) Proiectarea const n definirea modelului de ansamblu (conceptual) al sistemului
informatic, innd seama de evalurile fcute n etapa anterioar, dar i n transformarea
modelului conceptual stabilit anterior ntr-un model tehnic, operaional.
n acest scop se proiecteaz ieirile noului sistem, se determin entitile bazei informaionale de
intrare, se codific atributele i se proiecteaz fluxul general de prelucrare a datelor n noul
sistem. De asemenea, se definitiveaz soluia n organizarea datelor (fiiere sau baze de date), se
proiecteaz fiierele sau bazele de date, se determin i se proiecteaz procedurile (programele
de aplicaie) pentru crearea, actualizarea i exploatarea structurilor de date n vederea realizrii
obiectivelor stabilite sistemului informatic.
3) Elaborarea programelor are la baz soluiile stabilite n proiectare i urmrete scrierea
i testarea individual a programelor utiliznd medii i tehnici de programare adecvate.
4) Implementarea sistemului informatic realizat const n verificarea modului de
comportare practic a modelului proiectat i realizat n vederea trecerii lui n exploatare curent.
5) Exploatarea curent i meninerea n funciune urmrete att ndeplinirea obiectivelor
iniiale ale sistemului informatic ct i adaptarea acestuia la modificrile intervenite n cerinele
informaionale ale beneficiarului.
Realizarea unui sistem informatic se concretizeaz i sub forma unui proiect de sistem
informatic prin intermediul cruia se definesc ntr-o form standardizat soluiile adoptate.


4.2.2. Ordinea executrii etapelor

Dac etapizarea procesului de realizare a sistemelor informatice, dei controversat, este
n general stabilit, cu privire la ordinea parcurgerii etapelor exist diferite orientri generate de
diversitatea sistemelor informatice i a realizatorilor lor.
Aceste orientri sunt concretizate n:
- modelul liniar;
- modelul cu prototip;
- modelul cu extensii;
- modelul documentaiei anticipate;
- modelul ierarhic;
- modele mixte.
Modelul liniar este un model teoretic i presupune parcurgerea secvenial a etapelor cu
eventuale reveniri doar la etapa precedent. Este aplicat doar pentru sisteme informatice de mic
anvergur, dar n realitate parcurgerea etapelor este un proces iterativ, desfurndu-se n paralel
cu mai multe activiti din etape diferite de realizare.
Modelul cu prototip se aplic atunci cnd se ia decizia elaborrii complete, rapide i la
costuri sczute a unei versiuni iniiale, simplificate cu caracter de prototip pe baza creia se
121
stabilesc noi specificaii de definire a sistemului informatic i se desfoar activiti de realizare
a unei noi versiuni a sistemului informatic. Elaborarea noii versiuni se poate face prin
parcurgerea integral sau parial a etapelor i se modific numai anumite pri din prototip.
Modelul cu extensii pornete de la premisa c sistemele informatice se pot realiza i da n
funciune parial pe aplicaii. Realizarea lor se face n manier extensibil astfel nct o prim
versiune s includ componentele de baz, celelalte urmnd s fie realizate i integrate prin
extensii ulterioare. Se realizeaz astfel reducerea eforturilor i fructificarea experienei ctigate
n elaborarea componentelor iniiale, deci rezult c extensiile se ramific din proiectarea
general.
Modelul documentaiei anticipate presupune ntocmirea n devans a documentaiei prin
parcurgerea etapelor de proiectare, deci el permite analiza critic a documentaiei urmat de
reformularea unor probleme i aspecte nainte de darea n exploatare a sistemului.
Modelul ierarhic se caracterizeaz prin structurarea ierarhic coerent a activitilor
corespunztoare fiecrei etape, coninutul acestora fiind conform specificului fiecrui nivel.
Modele mixte. n activitatea practic se ntlnesc combinaii ale modelelor de parcurgere
a etapelor anterior prezentate, adaptate condiiilor concrete de realizare a sistemelor informatice.
O metodologie este o implementare a ciclului de via al sistemului informatic care
face referire la:
- activitile din fiecare etap i faz i ordinea lor de desfurare;
- rolul individual i de grup pe care l are fiecare activitate;
- condiiile de livrare i standardele de calitate pentru fiecare activitate;
- instrumentele i tehnicile care vor fi utilizate de fiecare activitate.
Exist mai multe metodologii de realizare a sistemelor informatice, din care cele mai
frecvent utilizate la noi n ar sunt:
A. SSADM, care se bazeaz pe analiza structurat i pune accentul pe prelucrri;
B. MERISE;
C. OMT, care integreaz datele i prelucrrile pentru a crea obiecte care pot fi uor
adaptate i reutilizate;
D. Prototipizarea, care pune accentul pe realizarea i asamblarea de prototipuri.
A. Elemente de baz ale metodologiei SSADM.
SSADM (Structured System Analysis and Design Methology) este o metodologie
structurat de analiz i proiectare a sistemelor informatice. A fost dezvoltat n Marea Britanie,
i se bazeaz pe trei principii metodologice dup cum urmeaz:
- folosirea modelrii descendente, de tip top-down, ca mod de abordare; acest mod de
abordare permite s se porneasc de la cerinele conducerii i s se detalieze cerinele
pn la nivelul utilizatorilor finali;
- considerarea datelor i prelucrrilor egale ca importan;
- folosirea unor simboluri grafice unice pe toat durata de realizare a sistemului.
Metodologia SSADM se concentreaz cu precdere pe acele etape din ciclul de via care
se refer la elaborarea sistemului: analiza sistemului existent; proiectarea logic; proiectarea
fizic.
Tehnicile de analiz i proiectare specifice acestei metodologii sunt: diagrama de flux a
datelor; modelul entitilor; matricea entiti-funciuni; normalizarea; structurarea ierarhic a
prelucrrilor; documentarea.
Dac se utilizeaz aceast metodologie, echipa de realizare trebuie s acorde atenie
deosebit fiecrei faze i s ntocmeasc documentaia pentru fiecare etap, fapt care conduce la
micorarea duratei de realizare i a costului proiectului.
B. Elemente ale metodologiei MERISE.
Aceast metodologie elaborat n Frana de Ministerul Industriei. Are la baz un model
tridimensional care structureaz componentele metodologice pe trei cicluri:
- ciclul de abstractizare;
- ciclul de decizie;
122
- ciclul de via al sistemului informatic.
Ciclul de abstractizare se dezvolt, conform modelului ANSI/SPARC de definire a
bazelor de date, pe trei niveluri:
- nivelul conceptual,
- nivelul logic,
- nivelul fizic,
cu precizarea c modelul datelor se dezvolt independent de modelul prelucrrilor.
n cadrul acestui ciclu se realizeaz succesiv modelul conceptual al datelor i modelul
conceptual al prelucrrilor, apoi se elaboreaz modelul logic al datelor i modelul logic al
prelucrrilor (sau modelul organizaional) i apoi se dezvolt modelul fizic al datelor i modelul
fizic al prelucrrilor (sau modelul operaional).
Ciclul de decizie se compune din mulimea deciziilor ce se iau pe durata ciclului de via
al sistemului informatic, aceste decizii fiind structurate pe tipuri de decizii astfel:
- decizii generale,
- decizii organizatorice,
- decizii tehnice,
- decizii funcionale.
C. Elemente ale metodologiei OMT (Object Modeling Technique)
Creat de ctre James Rumbaugh, este cea mai cunoscut i utilizat metodologie de
proiectare orientat pe obiecte (POO). Dorina de a construi produse software prin asamblarea de
componente, adic n aceeai manier n care se construiete hardware-ul, a stat la baza
metodelor POO. Astfel, un sistem informatic este privit ca un ansamblu de obiecte care
coopereaz ntre ele, iar obiectele sunt tratate ca instane ale unei clase n interiorul unei ierarhii.
Orientarea pe obiecte foreaz ca toate structurile de date ale unui program s fie ncapsulate.
Etapele parcurse n cadrul metodologiei OMT sunt:
1. definirea problemei,
2. elaborarea unei modaliti informale de identificare a datelor i funciilor relevante
din cadrul problemei,
3. formalizarea strategiei prin:
a) identificarea obiectelor i a atributelor lor,
b) identificarea operaiilor asupra obiectelor,
c) stabilirea instanelor,
d) implementarea prelucrrilor.
Metodologia OMT folosete pentru proiectarea sistemelor informatice ca mijloace de
reprezentare diagrama de flux de date pentru surprinderea comportamentului dinamic i
diagrama modular pentru surprinderea comportamentului static.
Printre avantajele acestei metodologii se pot enumera:
- produsul informatic este construit din componente care au o calitate probat n
implementrile anterioare;
- un obiect poate fi modificat fr a afecta celelalte obiecte i deci sistemul informatic
astfel construit este modular i poate fi uor dezvoltat i modificat;
- prin reutilizarea componentelor existente se asigur un timp mai scurt i costuri mai
reduse n procesul de realizare a sistemului informatic.


4.2.3. Metode i tehnici de realizare a sistemelor informatice

n activitatea practic au aprut i s-au dezvoltat dou tipuri de strategii de abordare i
realizare a sistemelor informatice: n funcie de rolul sistemelor informatice n cadrul agentului
economic i n funcie de modul de abordare a subsistemelor si aplicaiilor ce compun sistemul
informatic.
123
A. n ceea ce privete strategia de realizare a unui sistem informatic, n funcie de rolul
sistemelor informatice n cadrul agentului economic rezult trei categorii de strategii:
ameliorative; inovatoare; adaptive.
Strategiile ameliorative urmresc automatizarea activitilor i operaiilor de rutin sau
cu caracter repetitiv. Sistemele informatice ce rezult nu antreneaz mari modificri n sistemul
agentului economic. Ele au grad redus de complexitate, nu folosesc personal numeros, timpul de
realizare i implementare este scurt, dar sistemul este lipsit de flexibilitate.
n cazul strategiilor inovatoare, introducerea sistemului informatic trebuie nsoit de
schimbri importante n organizarea i funcionarea agentului economic. Aceste strategii asigur
valorificarea superioar a calculatorului electronic, dar presupun un timp mai mare pentru
conceperea i realizarea noului sistem, cheltuieli sporite i personal de nalt calificare.
n cazul strategiilor adaptive, sistemul informatic este conceput i realizat astfel nct s
fie compatibil cu schimbrile care apar n cerinele informaionale i organizatorice i n
funcionarea agentului economic. La baza acestor strategii st principiul invariaiei sau
modificrii lente impuse de existena proceselor i structurii de baz ale agentului economic.
Elementele informaionale invariante sunt surprinse n baza informaional care ocup locul
central n sistemul informatic. Aceste strategii au avantajul unei flexibiliti ridicate datorit
conceptului de baz informaional.
Prin comparaie, strategiile ameliorative pleac de la un set bine precizat de ieiri n
funcie de care se determin celelalte elemente ale sistemului informatic: bazele de date,
algoritmi, proceduri, iar strategiile adaptive pleac de la determinarea setului de intrri strict
necesare asigurrii bazei informaionale astfel nct acestea s modeleze ct mai fidel sistemul
agentului economic.
Baza informaional se transpune n colecii de date, proceduri de creare i actualizare
care constituie nucleul sistemului informatic. Acesta d posibilitatea modificrii cerinelor
informaionale astfel nct s se asigure reglarea fenomenelor i proceselor economice.
B. n funcie de modul de abordare a subsistemelor si aplicaiilor ce compun sistemul
informatic pot exista trei tipuri de strategii: descendent, ascendent i mixt.
Metoda descendent TOP-DOWN este impus de faptul c proiectarea sistemelor
informatice de mare complexitate face necesar descompunerea ierarhic prin modularizare ca
modalitate de control a complexitii. Ea const n descompunerea unui sistem complex pe
niveluri ierarhice, succesiv, pn la module elementare, simple i relativ independente care sunt
controlate de module coordonatoare.
Metoda are ca cerin de aplicare modularizarea sistemului, deci obiectivul principal este
realizarea modularizrii de sus n jos, iar din obiectivul principal rezult urmtoarele obiective
specifice: crearea posibilitii de realizare n paralel a componentelor sistemului informatic i
eliminarea din sistem a redundanelor.
Modul de lucru n cadrul acestei metode este urmtorul :
- se realizeaz mai nti o descompunere a sistemului n funcii principale i se stabilesc
relaiile dintre acestea, aceste funcii stnd la baza unei prime modularizri;
- se face apoi analiza modulelor obinute i dac se identific noi funcii se trece la
descompunerea pe urmtorul nivel;
- procesul descompunerii continu pn toate modulele sunt terminale (un modul este
terminal cnd nu se mai poate descompune n alte module).
Descompunerea are la baz urmtoarele reguli:
- nivelul 0 sau punctul iniial de pornire l constituie un modul neterminal sau
coordonator;
- pentru toate modulele neterminale ale sistemului se aplic descompuneri succesive, n
pai, de sus n jos;
- descompunerea este terminat cnd modulele ultimului nivel sunt terminale.
Aplicarea n practic prezint dezavantaje generate de definirea modelului de ansamblu a
sistemului informatic pe baza unei analize complexe cu personal numeros, ceea ce determin
124
prelungirea termenului de dare n exploatare a sistemului, iar erorile n definirea structurii i a
relaiilor dintre module pot afecta toat activitatea ulterioar.
Metoda ascendent BOTTOM-UP const n agregarea modulelor de jos n sus punnd n
eviden legturile dintre ele pn se ajunge la un singur modul.
Conceptele care stau la baza acestei metode sunt ca i la metoda descendent:
modularizarea i abordarea sistemic.
Regulile care stau la baza metodei sunt:
- nivelul de agregare iniial este nivelul la care se afl modulele terminale;
- agregarea se face succesiv de jos n sus;
- cnd se obine un nivel de agregare se realizeaz integrarea modulelor de nivel inferior
n module de nivel superior;
- agregarea este terminat cnd la un nivel de agregare se obine un singur modul.
Aplicarea acestei metode prezint avantajul c sistemul se dezvolt treptat, n
concordan cu cerinele reale ale utilizatorilor. Agentul economic poate beneficia mai repede de
rezultatele prelucrrii automate a datelor, se familiarizeaz cu sistemul n mod gradat, se reduc
riscurile realizrii unor sisteme de mare anvergur, neoperaionale.
Dezavantajele acestei metode rezult din gradul de integrare redus a modulelor datorit
lipsei unei concepii iniiale de ansamblu, ceea ce face necesar reproiectarea unor componente.


4.3. ANALIZA SISTEMULUI INFORMAIONAL EXISTENT

4.3.1. Conceptul de analiz a sistemelor informaionale

n general, analiza se definete ca fiind descompunerea real sau mintal a unui obiect,
fenomen sau a relaiilor dintre obiecte, fenomene etc, n pri componente n scopul cunoaterii.
Ea presupune deci examinarea amnunit, parte cu parte, a unei probleme, a unui obiect de
studiu.
Analiza sistemelor informaionale economice este activitatea prin care se realizeaz
cunoaterea sistemului obiect si a cerinelor de informaii din sistemul de decizie. Vom numi
sistem obiect orice parte a realitii (a sistemului informaional economic, n cazul nostru) care
genereaz date i care posed entiti, ce poate prelucra i atribui semnificaie datelor, parte
delimitat n vederea realizrii unui nou sistem informaional.
Scopul analizei sistemului informaional ar putea fi unul din urmtoarele:
1) proiectarea unui model al sistemului existent, adic a unui sistem sinonim cu ajutorul
cruia s se simuleze funcionarea sistemului real;
2) proiectarea unui sistem care s nlocuiasc sistemul existent, avnd ns performane
superioare;
3) proiectarea unui sistem raionalizat:
a) care pe baza acelorai intrri elaboreaz aceleai ieiri, dar cu o structur mai
simpl; de exemplu se raionalizeaz structura organizatoric n paralel cu
raionalizarea sistemului de eviden;
b) care simplific intrrile, structura i in cazul n care se dovedete necesar, ieirile
sistemului.
Exista dou concepte care stau la baza stabilirii elementelor sistemului obiect, care aplicate
la activitatea de analiz identific dou tipuri de structuri:
- conceptul orientat pe organism, care determina structura organizatoric; n acest caz
analiza sistemului informaional se va face pe compartimente funcionale;
- conceptul orientat pe activitate, care determin structura funcional; caz n care
analiza sistemului informaional se va face pe funcii si subfuncii ale agentului
economic analizat.
125
n general sunt studiate ambele tipuri de structuri, accentul punndu-se ns pe activiti, in
timp ce elementele organizatorice intereseaz doar prin prisma aportului lor la realizarea
activitilor.
Activitatea de analiza a unui sistem informaional economic se poate descompune in
urmtoarele operaii:
- culegerea datelor
- sistematizarea datelor culese;
- evaluarea sistemului informaional existent.
n vederea delimitrii corecte a cerinelor informaionale se pot distinge dou variante de
abordare a sistemului obiect, si anume de la analiza deciziilor de la analiza datelor:
Abordarea pornind de la analiza deciziilor caut s determine cerinele de informaii
pornind de la analiza obiectivelor i a deciziilor ce trebuie luate. Sunt culese i investigate doar
acele informaii care sunt necesare modelului de decizie, i anume:
- identificarea obiectivelor i a deciziilor curente si poteniale, precum si a atributelor
conducerii, corespunztoare obiectivelor si deciziilor;
- identificarea sau construirea unui model, a unei proceduri de elaborare a fiecrei
decizii sau a unui model al procesului de luare a deciziilor;
- testarea senzitivitii modelului la acurateea si disponibilitatea datelor de intrare,
specificarea limitelor si disponibilitilor datelor cerute de model.
Avantajul acestui mod de abordare este acela c rezulta un volum mic de date de prelucrat.
n abordarea pornind de la analiza datelor se caut s se obin cerinele informaionale
prin analiza datelor folosite curent in sistemul existent, sau a datelor potenial folosibile.
Sunt identificate datele colectate din sistemul existent, pentru care s-a perceput o
necesitate, ct i datele necolectate n sistemul existent, dar semnalate ca fiind utile, i anume:
- cercetarea tuturor documentelor, fiierelor folosite in mod curent i identificarea
datelor care sunt culese si prelucrate in mod curent;
- identificarea datelor suplimentare, care nu sunt culese i prelucrate n mod curent,
dar care se dovedesc a fi utile;
- stabilirea datelor inutile, care se culeg n mod curent si nu sunt utilizate.
Acest mod de abordare pleac de la premisa c toate datele utile trebuie s fac parte din
sistem, pentru a preveni schimbrile ce pot surveni n mediul agentului economic studiat, n stilul
de decizie sau n cerinele informaionale.
Abordarea pornind de la analiza datelor conduce la un volum mai mare de date, dar are
avantajul c deciziile ce se vor lua pe baza acestor date vor fi mai puin afectate de modificrile
ce pot surveni pe parcurs.
Fiecare dintre cele dou abordri este mai potrivit pentru un anumit tip de probleme,
aplicaii sau sisteme, analiza deciziilor se recomand n special la activitile de conducere, n
cazul sistemelor informaionale de management i n cazul sistemelor suport de decizie, iar
analiza datelor se recomand n special n cazul activitilor de rutin, n cazul sistemelor de
gestiune.

4.3.2. Obiectivele i fazele analizei sistemului informaional existent (ASIE)

Aceast etap de realizare a unui sistem informatic mai este cunoscut i sub denumirea de
elaborarea temei de realizare, analiza diagnostic sau studiul de oportunitate.
Aceast etap are urmtoarele obiective :
1) Delimitarea ariei de cuprindere a sistemului informaional existent care va deveni sistem
obiect pentru conceperea i realizarea unui sistem informatic. (Vom numi sistem obiect acea
parte a realiti economice care genereaz date i care posed entiti ce pot prelucra i atribui
semnificaie datelor, parte delimitat n vederea realizrii unui sistem informatic).
2) Reflectarea activitilor i operaiilor de culegere, transmitere i prelucrare a datelor
specifice sistemului informaional existent.
126
3) Surprinderea modificrilor ce se impun n organizarea i funcionarea sistemului
informaional existent n viziunea conceperii unui sistem informatic.
4) Evidenierea dotrii cu tehnic de calcul, prin prisma concordanei dintre sistemele
electronice de calcul i viitorul sistem informatic, inclusiv identificarea problemelor ce urmeaz
a fi rezolvate de noul sistem cu ajutorul calculatorului electronic.
5) Fundamentarea unei soluii de principiu care s precizeze activitile i operaiile ce vor
fi informatizate, costul antecalculat al sistemului, tipul calculatorului electronic, sistemul de
operare aferent, inclusiv soluia de gestiune a datelor (sistem de gestiune a fiierelor sau sistem
de gestiune a bazelor de date) pe care se va baza conceperea i realizarea noului sistem,
implicaiile n organizarea intern a unitii, precum i planificarea global a realizrii sistemului
informatic.
ASIE este necesar pentru a fundamenta direciile de perfecionare a sistemului
informaional existent i nlocuirea acestuia cu un sistem informatic care s satisfac toate
cerinele informaionale ale agentului economic. De asemenea analiza de sistem este oportun i
n cazul agenilor economici nou nfiinai pentru fundamentarea proiectului de sistem
informaional, ca parte a proiectului de nfiinare a unitii.
ASIE trebuie s ofere conducerii agentului economic informaiile necesare fundamentrii
deciziei de perfecionare a sistemului informaional i de proiectare a unui sistem informatic.
ASIE se desfoar n urmtoarele faze :
1) Organizarea i conducerea analizei sistemului informaional prin: pregtirea
condiiilor necesare analizei; constituire colectivului pentru ASIE; elaborarea
programului de realizare;
2) Realizarea ASIE prin: documentarea pentru analiza de sistem; alegerea tehnicilor de
analiz a sistemului informaional existent; studiul componentelor sistemului
informaional existent; evaluarea critic a sistemului informaional existent; elaborarea
variantelor de realizare a sistemului informatic.
3) Finalizarea ASIE prin: definitivarea documentaiei ASIE; avizarea ASIE de ctre
beneficiar.


4.3.3. Organizarea i conducerea ASIE

Pregtirea condiiilor necesare ASIE. Iniierea i declanarea analizei de sistem este
atributul conducerii unitii beneficiare care precizeaz tema i obiectivele analizei printr-o Not
de comand. Pe baza Notei de comand se ncheie Contractul de execuie pentru ASIE ntre
unitatea beneficiar i unitatea de analiz proiectare. Valoarea contractului se determin pe baza
unui deviz n care se stipuleaz: numrul de ore/om preconizat pentru executarea analizei,
personalul implicat, tarifele de realizare, termenele de execuie, inclusiv obligaiile prilor i
modul de decontare a lucrrilor.
Constituirea colectivului pentru ASIE. Colectivul poate fi alctuit din :
- personalul propriu al unitii beneficiare;
- personalul unei uniti specializate n analiza i proiectarea de sisteme informatice;
- din personalul unitii beneficiare i al unei uniti specializate.
Prima variant prezint avantajul cunoaterii sistemului informaional de ctre colectivul
de analiz, ceea ce asigur efectuarea unei analize de calitate ntr-un termen relativ scurt, dar
prezint dezavantajul c membrii colectivului nu pot sesiza toate deficienele i limitele reale ale
sistemului informaional, deoarece sunt familiarizai cu structura i funcionarea acestuia.
Varianta a doua prezint avantajul c membrii colectivului de analiz sunt specializai n
rezolvarea unor astfel de probleme, cunosc deficienele i limitele unor sisteme similare cu cel
analizat, dar prezint dezavantajul realizrii analizei ntr-un termen relativ ndelungat, deoarece
se impune o cunoatere detaliat a unor anumite pri cu caracter specific, de multe ori unicat,
ale sistemului informaional.
127
Varianta a treia este cea mai indicat datorit maximizrii avantajelor i minimizrii
dezavantajelor primelor dou variante.
n orice variant, pe lng analitii de sistem, din componena colectivului trebuie s fac
parte conductori i membri ai compartimentelor funcionale supuse analizei. Aceasta deoarece
conductorii compartimentelor funcionale pot identifica informaiile utile, pe cele de prisos i
pot formula cerine informaionale pentru noul sistem, iar personalul de specialitate din
compartimentele funcionale, cunoscnd detaliat toate activitile i operaiile desfurate, poate
sesiza neajunsurile segmentului de sistemului informaional pe care lucreaz.
Numrul membrilor colectivului depinde de obiectivele analizei, de sfera de cuprindere, de
complexitatea i particularitile sistemului informaional i de termenele de realizare.
Elaborarea programului de realizare. Desfurarea activitii de analiz a sistemului se
efectueaz pe baza unui program prin care se urmrete folosirea raional a personalului,
termenele intermediare i finale, precum i procedurile de control i avizare a realizrii ASIE.
Programarea realizrii ASIE se poate face prin folosirea grafului de tip PERT iar urmrirea
operativ a execuiei se poate efectua prin intermediul Graficelor de tip GANTT.


4.3.4. Realizarea analizei sistemului informaional existent

Documentarea pentru ASIE. Activitatea de documentare necesar analizei de sistem
presupune studiul unor probleme de organizare ale agentului economi, a particularitilor
procesului tehnologic, a fluxurilor informaionale i a activitilor desfurate, precum i a
cadrului legislativ impus funcionrii sistemului informaional.
n aceast viziune se studiaz modul de organizare i conducere a agentului economic;
obiectul activitii de baz; particularitile procesului tehnologic; strategia i tactica conducerii
n realizarea activitilor de baz; principalele aciuni pentru dezvoltarea unitii; etc.
n continuare se studiaz actele normative care reglementeaz activitatea agentului
economic n ansamblu i activitatea fiecrui compartiment funcional precum i modul n care se
respect cadrul legal i deciziile de funcionare efectiv a sistemului informaional al unitii
analizate.
Documentarea este bine s fie completat cu studiul literaturii de specialitate i a celor mai
noi realizri n organizarea i funcionarea sistemelor informaionale, precum i cu experiena
pozitiv din uniti care fac parte din aceeai ramur de activitate cu unitatea studiat.
Alegerea tehnicilor de analiz. Analiza sistemelor informaionale se poate realiza
utiliznd mai multe tehnici. Astfel distingem doua categorii de tehnici de analiz a sistemelor
informaionale economice :
- tehnici elementare;
- tehnici complexe.
Tehnicile elementare realizeaz doar operaia de culegere a datelor i asigur o
sistematizare redus a acestora. n grupa tehnicilor elementare de analiza se ncadreaz:
- observarea directa;
- studierea documentaiei existente;
- participarea analistului la efectuarea lucrrilor din sistemul informaional;
- interviul;
- chestionarul.
Tehnicile complexe realizeaz toate activitile de analiza, respectiv culegerea i
sistematizarea datelor, precum i evaluarea sistemului informaional. Culegerea datelor, n cadrul
tehnicilor complexe de analiz, se realizeaz utiliznd, de regul, mai multe tehnici elementare.
Sistematizarea datelor, constnd nu doar intr-o simpl ordonare a lor, ci i ntr-o
sintetizare, se realizeaz folosind una sau mai multe tehnici de reprezentare. Dintre tehnicile de
reprezentare amintim:
- scrierea tehnica;
128
- reprezentarea grafic a fluxurilor informaionale prin: organigrame (scheme
logice), schema bloc a fluxurilor informaionale (diagrama de rutina sau diagrama
de relaii), schema orizontal a fluxurilor informaionale, schema vertical a
fluxurilor informaionale;
- grilele;
- listele de aciuni condiionate;
- tabelele de decizii;
- limbajul pseudocod etc.
Dintre tehnicile complexe de analiza a sistemelor informaionale fac parte:
- analiza diagnostic;
- analiza celulara;
- analiza S.O.P. (Study Organization Plan).
n general, alegerea uneia sau alteia din tehnicile elementare de investigare a sistemului
informaional existent i din tehnicile de reprezentare se face n funcie de: complexitatea i
particularitile sistemului informaional existent; aria de cuprindere a acestuia; condiiile
concrete de lucru; termenele de realizare; experiena analitilor.
Practica a cristalizat cteva recomandri privind alegerea i utilizarea tehnicilor de analiz:
1) Nici o tehnic nu poate, ea singur, s asigure culegerea tuturor datelor pentru
caracterizarea complex a sistemului informaional existent, de aceea se impune utilizarea mai
multor tehnici. De regul se utilizeaz ca tehnic principal interviul completat cu chestionarul
sau cu inventarul documentelor.
2) n vederea alegerii corecte a tehnicii de culegere a datelor i stabilirii modului de
realizare, se impune o bun documentare prealabil privind unitatea ce va fi supus analizei, n
special personalul su.
3) n culegerea datelor analistul nu va avea idei preconcepute despre problemele unitii i
despre modul de rezolvare a lor, deoarece, n loc s descopere adevratul mecanism al activitii
investigate, va primi doar confirmarea propriilor preri i construirea proiectului pe aceast baz
va conduce sigur la eec.
4) n timpul culegerii datelor nu se elaboreaz soluii, eventualele idei de soluii se noteaz
fr a insista asupra lor (din acelai motiv ca n cazul anterior).
Studiul componentelor sistemului informaional existent. Analiza elementelor
componente ale sistemului informaional urmtoarele obiective:
a) identificarea caracteristicilor generale ale agentului economic;
b) studiul activitilor desfurate de agentul economic;
c) studiul deciziilor din sistemul agentului economic;
d) studiul dotrii cu tehnic de calcul;
e) studiul fluxurilor informaionale;
f) studiul volumului datelor;
g) studiul costului de funcionare a sistemului informaional.
a) n cadrul primului obiectiv se studiaz: profilul i obiectivele agentului economic, cadrul
juridic de funcionare, dinamica unor indicatori tehnico-economici privind capacitatea de
producie, gradul de folosire a utilajelor, cifra de afaceri, numrul de salariai, metodele de
previziune, forma de contabilitate, metoda de eviden a valorilor materiale, metoda de calculaie
a costurilor, relaiile informaionale ale unitii analizate cu ali ageni economici i cu organe
ierarhice superioare i inferioare, determinarea modului de ierarhizare a seciilor de producie i
a compartimentelor funcionale prin organigrama structurii organizatorice.
b) n cadrul celui de-al doilea obiectiv se studiaz: funciile unitii pe baza statutului de
funcionare: activitile i sarcinile din cadrul funciilor, atribuiile fiecrui post de lucru, dar i
funcia de baz a agentului economic.
c) Studiul deciziilor din sistemul agentului economic urmrete modul cum sunt
fundamentate aceste decizii documentele existente i informaiile de baz.
129
d) Studiul dotrii cu tehnic de calcul permite analiza dotrii cu tehnic de calcul, gradul ei
de utilizare i msura n care aceasta contribuie la funcionarea sistemului informaional existent.
Se analizeaz modul n care configuraia existent rspunde cerinelor actuale din punct de
vedere al capacitii de stocare i prelucrare, precum i posibilitile de integrare n noul sistem.
e) Studiul fluxurilor informaionale verific circuitul documentelor avnd n vedere:
- descrierea fluxurilor informaionale printr-o organigram unde se precizeaz:
activitile, compartimentele sau posturile de lucru, procedurile efectuate asupra
documentelor i circuitul documentelor ntre posturile de lucru;
- evidenierea fluxurilor paralele de date i a circuitelor neraionale care trebuie
eliminate din noul sistem;
- identificarea documentelor vehiculate n mod inutil sau care circul ntr-un numr
de exemplare necorespunztor cerinelor reale ale sistemului informaional;
- determinarea gradului de utilizare a documentelor tipizate pentru eliminarea din
sistem a documentelor netipizate;
- determinarea gradului de ncrcare i solicitare a fiecrui compartiment i post de
lucru implicat n sistemul informaional;
- integrarea sistemului informaional analizat cu alte sisteme informaionale.
f) Studiul volumului datelor se refer la evidenierea i cuantificarea urmtoarelor
elemente: simbolul i denumirea documentelor, frecvena de ntocmire a documentelor, numrul
maxim i mediu de documente corespunztor frecvenei de ntocmire a documentelor, numrul
maxim i mediu de rnduri pe document, numrul maxim i mediu de caractere pe rnd, numrul
de exemplare pe document, estimarea numrului mediu de documente pentru perioada viitoare.
Concomitent cu analiza documentelor se urmrete sistemul de coduri pentru a fi preluat n
noul sistem informatic deoarece activitatea de codificare este complex i personalul din unitate
este familiarizat cu codurile existente.
Pe baza evalurilor fcute, echipa de analiz poate formula recomandri privind tipul i
capacitatea perifericelor, suporturile tehnice de date necesare n sistem i poate face o evaluare
critic a sistemului informaional existent.
g) Studiul costului de funcionare al sistemului informaional se refer la analiza
cheltuielilor cu salariile personalului implicat n funcionarea sistemului, a cheltuielilor cu
amortizarea i ntreinerea tehnicii de calcul, a cheltuielilor cu materiale consumabile.
Identificarea costului de funcionare a sistemului informaional existent servete n faza de
analiz de sistem pentru a aprecia performanele acestuia i dup implementarea sistemului
pentru calculul eficienei economice a noului sistem cnd se compar cheltuielile cu efectele
noului i vechiului sistem.

Evaluarea sistemului informaional. Prin aceasta se urmrete evaluarea performanelor
i limitelor sistemului informaional n raport cu cerinele sistemului de conducere i evaluarea
gradului de pregtire a unitii analizate pentru realizarea unui sistem informatic.
Evaluarea performanelor unui sistem informaional se face pe baza urmtoarelor criterii:
- msura n care sistemul informaional asigur realizarea obiectivelor i ndeplinirea
funciilor de baz ale unitii;
- gradul de asigurare cu informaiile necesare la diferite niveluri de conducere;
- operativitatea n culegerea, prelucrarea datelor, transmiterea informaiilor i
adoptarea deciziilor prin prisma timpului de rspuns;
- calitatea informaiilor rezultate din prelucrare, privit sub aspectul preciziei de
exprimare, al flexibilitii i frecvenei de difuzare;
- calitatea i sigurana legturilor ntre posturile de lucru n cadrul fluxurilor
informaionale;
- posibilitile sistemului informaional de a sesiza tendinele n evoluia unitii;
- posibilitile de control i efectuare de corecii, reacia la apariia unor evenimente
externe, posibilitile de corectare n timp util a abaterilor;
130
- gradul de integrare a sistemului informaional sub aspectul reducerii informaiilor
redundante, a compatibilitii informaiilor cu datele de intrare, a organizrii datelor
n baze de date unitare i posibilitatea de asigurare a unui cadru organizatoric
adecvat;
- gradul de automatizare a lucrrilor n totalul lucrrilor din sistemul informaional.
Evaluarea gradului de pregtire a unitii analizate pentru proiectarea unui sistem
informatic are n vedere: pregtirea personalului, disciplina tehnologic n sistemul
informaional, existena cadrului organizatoric, existena bazei tiinifico-metodologice i
informaionale.
Concret, evaluarea sistemului informaional trebuie s fac referiri la:
- obiectivele sistemului;
- mijloacele i metodele de prelucrare;
- personalul implicat;
- costurile de funcionare ale sistemului.
Evaluarea critic a obiectivelor urmrete s determine modul n care sunt rezolvate
cerinele informaionale din sistem, msura n care informaiile solicitate lipsesc sau sunt
necorespunztoare. Trebuie pus n eviden concordana dintre structura organizatoric i
categoriile de informaii necesare fiecrui post. Existena n sistemul informaional a unor
informaii de prisos este la fel de duntoare ca i lipsa de informaii, deci, trebuie fcut o
inventariere exact a informaiilor din sistem, evideniate procedurile asemntoare de prelucrare
a datelor i fluxurile paralele de date.
Evaluarea critic a mijloacelor tehnice utilizate trebuie s pun n eviden gradul de
dotare cu tehnic de calcul, ponderea acesteia n sistemul informaional, gradul ei de utilizare i
oportunitatea folosirii tehnicii existente n noul sistem. Se poate analiza gradul de flexibilitate al
tehnicii de calcul i msura n care aceasta este compatibil cu exigenele actuale i previzibile
ale sistemului. Se pot face evaluri privind gradul de uzur fizic sau moral a sistemului de
calcul.
Evaluarea critic a personalului are rolul de a determina gradul de utilizare al timpului
de lucru i gradul de ncrcare pe fiecare compartiment i post de lucru. Se poate analiza dac
structura personalului pe profesii i niveluri de pregtire este n concordan cu exigenele
impuse de specificul sistemului informaional. Se pot face aprecieri asupra gradului de
perfecionare profesional a personalului.
Concret, se poate determina numrul total de personal implicat n funcionarea sistemului
informaional i fondul de timp maxim disponibil alocat, exprimat n ore-munc, numrul total
de documente sau informaii vehiculate n sistem raportate la numrul total de personal,
ponderea fondului de timp maxim disponibil alocat personalului ce lucreaz n sistemul
informaional n totalul fondului de timp de la nivelul agentului economic, productivitatea
muncii pe persoan, timpul mediu pentru completarea unui document, ponderea salariailor care
lucreaz n sistemul informaional n totalul salariailor i dinamica acestor indicatori.
Evaluarea costului de funcionare a sistemului informaional presupune punerea n
relief a msurii pentru reducerea cheltuielilor cu funcionarea sistemului informaional. Este
indicat precizarea efectelor negative care apar datorit lipsei din sistem a unor informaii i
estimarea lor valoric. Se pot calcula urmtorii indicatori cu privire la costul sistemului
informaional: cheltuieli cu informaiile strict necesare; cheltuieli cu informaiile suplimentare;
cheltuieli necesare pentru utilizarea a "n" informaii; cheltuieli cu informaiile la 1000 de lei
volum de activitate; costul mediu de utilizare pe un document .

Elaborarea variantelor de realizare a noului sistem. Presupune parcurgerea
urmtoarelor activiti:
I) stabilirea funciilor, cerinelor i restriciilor noului sistem;
II) definirea soluiei globale de principiu pentru prelucrarea automat a datelor;
II) evaluarea fiecrei variante de realizare.
131
I) Stabilirea funciilor, cerinelor i restriciilor noului sistem se bazeaz pe evaluarea
critic a sistemului existent i pe cerinele beneficiarului.
Stabilirea funciilor noului sistem presupune delimitarea ariei de cuprindere a principalelor
activiti pe care le va acoperi noul sistem, legtura cu aplicaiile informatice n exploatare sau
prevzute a se realiza n viitor.
Subsistemele, aplicaiile informatice care se pot fi proiectate i realizate ntr-un sistem
economic sunt:
1. Subsistemul pentru activitatea de planificare tehnico-economic:
- elaborarea planului anual: stabilirea variantelor de plan, calculul indicatorilor
tehnico-economici, alegerea variantei optime. Se elaboreaz studii de prognoz
privind cerinele pieei, se ntocmesc mai multe variante urmrind valorificarea
potenialului productiv existent i crearea resurselor necesare pentru realizarea lor.
- defalcarea planului pe trimestre, luni, subuniti care se face n funcie de nivelul
resurselor, termenele contractuale i prioritile beneficiarului. Se recalculeaz
valorile indicatorilor economico-financiari.
- urmrirea i analiza realizrii planului. Se centralizeaz pe baza rapoartelor de
producie realizrile i se semnaleaz abaterile, se calculeaz indicatorii economici
i se semnaleaz abaterile.
2. Subsistemul pentru pregtirea tehnic a produciei:
- elaborarea i actualizarea nomenclatoarelor de produse pe baza informaiilor din
documentaia constructiv a produselor;
- elaborarea i actualizarea fiierelor tehnologice pe baza precizrilor din
documentaia tehnologic pe fiecare produs;
- calculul consumului specific de manoper pe baza documentaiei specifice, pe
meserii, utilaje, diferite niveluri de agregare a produselor;
- calculul loturilor optime i ciclurilor de fabricaie pe baza documentaiei tehnice;
- calculul consumurilor specifice de materii prime, materiale, SDV;
- urmrirea i analiza ncadrrii n normele de consum;
- urmrirea i analiza planului privind realizarea produselor noi.
3. Subsistemul de programare, lansare i urmrire a produciei de baz:
- calculul necesarului de fabricat pe o perioad pe baza planului de producie i a
nomenclatoarelor de produse;
- calculul fondului de timp al utilajelor pe baza indicatorilor privind starea utilajelor
i planul de reparaii;
- elaborarea programelor de fabricaie trimestriale i lunare n funcie de termenele
de livrare, disponibilul de capaciti, fora de munc i resursele materiale;
- programarea operativ a produciei, detalierea sarcinilor din programul de fabricaie
la nivel de decad, zi, schimb, pe ateliere, grupuri de maini pentru stabilirea unor
loturi optime de fabricaie;
- lansarea manoperei care presupune calculul i centralizarea consumului de timp
necesar executrii operaiilor pentru producie i emiterea bonurilor de manoper;
- lansarea materialelor, calculul necesarului de materiale, emiterea bonurilor de
consum sau a fielor limit de consum;
- controlul calitii produciei, urmrirea i analiza realizrii produciei.
4. Subsistemul pentru aprovizionarea tehnico-material:
- calculul normativelor de materii prime i materiale;
- planul de aprovizionare pe baza planului de producie i a normelor de consum;
- calculul necesarului pentru aprovizionat cu defalcarea pe trimestre i luni pe baza
planului de aprovizionare i a stocului existent la nceputul perioadei;
- lansarea i urmrirea comenzilor de aprovizionare;
- urmrirea gradului de acoperire a necesarului de aprovizionat;
- analiza i urmrirea realizrii activitii de aprovizionare.
132
5. Subsistemul pentru activitatea de desfacere:
- elaborarea de studii de previziune privind cerinele pieei;
- evidena i analiza comenzilor primite de la beneficiari;
- urmrirea gradului de acoperire a planului de producie cu comenzi i contracte;
- ntocmirea planului anual de livrare;
- urmrirea derulrii contractelor cu beneficiarii;
- urmrirea i analiza privind activitatea de desfacere.
6. Subsistemul pentru gestiunea valorilor materiale:
- gestiunea stocului de materii prime i materiale;
- gestiunea stocului de produse finite;
- gestiunea stocului de semifabricate proprii;
- urmrirea i analiza stocurilor supranormative i a celor cu micare lent.
7. Subsistemul pentru activitatea de personal:
- elaborarea planului forei de munc, calculul fondului de salarii pe baza planului de
producie, a normelor tehnologice;
- evidena i structura personalului: elaborarea situaiei privind existentul i prezena
la lucru a personalului, fluctuaia personalului;
- calculul salariilor;
- analiza i raportarea forei de munc.
8. Subsistemul pentru activitatea financiar-contabil:
- elaborarea bugetului de venituri i cheltuieli;
- evidena mijloacelor fixe: urmrirea pe locuri de folosin, calculul i includerea pe
costuri a amortizrii, urmrirea uzurii fizice i morale;
- contabilitatea valorilor materiale;
- contabilitatea salariilor: ntocmirea formelor de plat: lista de avans chenzinal,
tatul de salarii, indemnizaii pentru concediul de odihn, plile n contul
asigurrilor sociale;
- calculaia costurilor: nregistrarea corect i la timp pe locuri de folosin i obiecte
de calculaie a cheltuielilor de producie, calculul costurilor unitare pe produs,
analiza costurilor de producie.
- contabilitatea general cu: evidena mijloacelor bneti i a mprumuturilor,
debitori, creditori, decontrile cu furnizorii, cu beneficiarii, cu bugetul de stat, cu
asigurrile sociale, veniturile i rezultatele financiare; ntocmirea balanei de
verificare i a situaiilor de raportare; ntocmirea bilanurilor i anexelor sale.
9. Subsistemul pentru activiti auxiliare sau specifice:
- activitatea de ntreinere i reparaii utilaje;
- activitatea de realizare a pieselor de schimb;
- activitatea de transport.
Restriciile viitorului sistem reprezint condiii impuse proiectantului de ctre beneficiar
sau cadru legal. Ele pot fi:
- de natur legislativ: proiectantul trebuie s cunoasc actele normative ce
reglementeaz activitatea n sistemul obiect i s in seama de prevederile acestora
n realizarea noului sistem;
- de natur organizatoric: nu exist specialiti n informatic i pn la formarea lor
se apeleaz la o unitate specializat;
- de natur tehnic: viitorul sistem nu se poate realiza dect cu o configuraie de
calcul i cu un soft de baz;
- cu caracter general: proiectul trebuie terminat la o anumit dat i cu un anumit
cost.
II) Definirea unor soluii globale de principiu pentru prelucrarea automat a datelor
are n vedere obiectivele stabilite anterior prin definirea mai multor soluii de prelucrare
automat n noul sistem. Pentru fiecare variant se stabilesc numrul activitilor i gradul de
133
informatizare a acestora, delimitndu-se operaiile ce se efectueaz automat de cele care se vor
efectua manual. Se vor preciza atribuiile preluate de sistemul informatic n raport cu cele ce vor
rmne pe seama compartimentelor funcionale. Avndu-se n vedere aceste opiuni cu caracter
funcional se studiaz soluiile tehnice de principiu pentru:
a) Posibilitile financiare ale agentului economic de a dispune de configuraia de calcul
necesar. Echipamentul poate fi propriu sau nchiriat;
b) Felul calculatoarelor: mari, medii, mini, micro i modul lor de folosire. Interconectarea
ntr-o reea, chiar eterogen, cu regim de exploatare distribuit local sau la distan, cu staii de
lucru bazate pe calculatoare personale are avantajul creterii numrului de utilizatori, exploatrii
intensive a capacitii de prelucrare i satisfacerii n timp real a cerinelor utilizatorilor, dar este
mai costisitoare;
c) Tipul sistemului de operare i softului de baz minim pentru funcionarea sistemului;
d) Felul produselor-program ce vor fi folosite: pot fi produse-program specifice sau
generalizate. Prima soluie are avantajul posibilitii de informatizare a problemelor complexe
specifice fiecrui beneficiar, dar are dezavantajul c necesit un personal strict specializat. A
doua variant scurteaz durata de realizare i costul este relativ sczut, dar are dezavantajul
limitrii informatizrii la facilitile oferite de produsul-program i este puin flexibil;
e) Tipul suporturilor tehnice de date folosite n noul sistem i modalitatea concret de
introducere a datelor n sistemul de calcul i obinerea rezultatelor. Soluia cea mai eficient de
introducere a datelor este preluarea direct de la terminal. Afiarea rezultatelor se poate face la
imprimant pentru situaiile de ieire ce vor servi ca documente justificative, dar cu costuri mari
i un timp mare de obinere a rezultatelor, sau se poate face la videoterminal;
f) Modul de organizare a datelor:
- n fiiere independente: se realizeaz uor, redundan mare a datelor, limitarea
ieirilor la datele stocate n fiiere, dependena fizic i logic a programelor de
aplicaie fa de modul de descriere a datelor;
- n baze de date gestionate de un sistem de gestiune a bazelor de date;
- n baze de date distribuite local sau la distan care ofer faciliti superioare n
actualizarea i exploatarea datelor, dar cu eforturi mai mari;
- n baze de cunotine care prezint avantaj din punct de vedere a posibilitilor de
prelucrare i dezavantaj din punct de vedere al modului de realizare i al costurilor
mari.
g) Tipul de prelucrare a datelor: pe loturi, interactiv, centralizat fr teleprelucrare i
centralizat cu teleprelucrare distribuit. Prelucrarea pe loturi este avantajoas pentru prelucrri
multiple efectuate o singur dat la sfritul unei perioade de gestiune, dar prezint dezavantajul
lipsei de operativitate a informaiilor. Prelucrarea interactiv are avantajul realizrii unor sisteme
informatice dinamice, asigur obinerea de informaii n timp real, dar n anumite sisteme de
calcul nu folosesc intensiv capacitatea de prelucrare. Prelucrarea centralizat fr teleprelucrare
asigur exercitarea unui bun control al prelucrrii, o bun securitate privind accesul la date, dar
influeneaz negativ timpul de rspuns al sistemului. Prelucrarea centralizat cu teleprelucrare
este cea mai avantajoas, dar necesit costuri mari de realizare.
III) Evaluarea fiecrei variante de realizare completeaz definirea funcionalitii
fiecrei variante cu o serie de informaii referitoare la cheltuielile ocazionate i efectele
economice scontate. Aceast comparare va permite beneficiarului s selecteze varianta cea mai
eficient. Evaluarea costurilor va urmri, att cheltuielile prevzute pentru proiectarea i
realizarea sistemului informatic, ct i pe cele necesare exploatrii curente a acestuia.
La prezentarea efectelor economice se vor avea n vedere, att efectele economice
cuantificabile, ct i efectele economice necuantificabile.
Evaluarea termenelor de realizare are n vedere precizarea intervalelor i termenelor de
proiectare a noului sistem, precum i a momentelor de achiziionare a sistemelor de calcul
necesare. De asemenea, aceast evaluare trebuie s precizeze termenele i intervalele de pregtire
134
profesional a personalului din posturile de lucru ce vor fi implicate n noul sistem, ct i a
personalului din unitatea proprie de informatic.
Conducerea unitii beneficiare evalueaz i selecteaz varianta cea mai convenabil prin
luarea n considerare a tuturor variantelor, prin consultarea unor specialiti n analiza i
realizarea de sisteme informatice sau (dac este posibil) prin analiza unor soluii de informatizare
alese de uniti similare.


4.4. PROIECTAREA GENERAL A SISTEMELOR INFORMATICE

4.4.1. Obiective i activiti specifice proiectrii generale

Proiectarea general are ca obiectiv elaborarea concepiei logice a sistemului informatic,
definirea acestuia din punct de vedere structural i funcional. Aceasta presupune stabilirea
componentelor sistemului informatic, a ieirilor, a bazei informaionale de intrare, a
documentelor pe care sunt consemnate datele de intrare, a legturilor dintre ele i a
funcionalitii sistemului astfel nct toate elementele sale s formeze un ntreg, s se articuleze
ca un tot unitar.
Structura general a sistemului informatic cuprinde un ansamblu de intrri, prelucrri i
ieiri definite n funcie de obiectivele noului sistem.
I. Intrrile sistemului informatic cuprind :
- baza de date
- micrile (tranzaciile).
Baza de date ca noiune general reprezint colecii de date operaionale, memorate i
utilizate n comun de ctre componentele sistemului informatic.
Tranzaciile sunt reprezentate de datele care reflect modificri i devin componente ale
bazei de date n urma clasificrii, validrii, nregistrrii i prelucrrii lor.
n cadrul unui sistem informatic exist dou categorii de tranzacii:
- tranzacii externe;
- tranzacii interne.
Tranzaciile externe redau fenomenele i procesele economice, inclusiv modificrile
produse n activitatea agentului economic, ca de exemplu: aprovizionarea cu un material, livrarea
unui produs, ncasarea unei facturi, modificarea preului unui produs etc.
Tranzaciile interne apar n momentul obinerii unui rezultat, fiind destinate actualizrii
bazelor de date. De exemplu: totalul valorii facturilor primite de la un furnizor care actualizeaz
la o anumit perioad soldul furnizorului respectiv; totalul vnzrilor dintr-un produs ntr-o zi
care actualizeaz stocul produsului respectiv etc.
Tranzaciile externe provin din exteriorul sistemului de calcul i sunt furnizate prin
proceduri de introducere a datelor din sistem, iar tranzaciile interne sunt asigurate exclusiv n
cadrul sistemului de calcul prin proceduri de actualizare i exploatare a coleciilor de date create
anterior.
II. Prelucrrile sistemului informatic sunt asigurate prin execuia unui ansamblu de
programe care se subdivid n: programe pentru actualizarea bazelor de date i programe pentru
obinerea rezultatelor i a situaiilor de ieire proiectate.
Deci sistemele informatice funcioneaz, la prima vedere, n dou cicluri:
- actualizarea bazelor de date cnd se valideaz i se introduc tranzaciile;
- obinerea situaiilor de ieire solicitate.
Prelucrrile sistemului informatic acioneaz asupra coleciilor de date care sunt
constituite ntr-un nucleu informaional ce conine mulimea atributelor necesare obinerii
informaiilor solicitate. Nucleul de informaii urmeaz a fi structurat n entiti informaionale al
cror ansamblu delimiteaz baza informaional a sistemului informatic.
Baza informaional este format din ansamblul entitilor informaionale i atributelor
135
componente ale acestora ce descriu dinamica fenomenelor i proceselor economice la un agent
economic pe o perioad de timp.
Procedurile de creare, actualizare, exploatare, listare i coleciile de date organizate n
fiiere sau baze de date formeaz nucleul sistemului informatic.
III. Ieirile sistemului informatic reprezint rezultatul prelucrrii coleciilor de date i se
vor concretiza n situaii de ieire solicitate de beneficiar sau n colecii de date: fiiere sau baze
de date actualizate ce vor fi transmise altor sisteme sau aplicaii informatice.
Proiectarea general se deruleaz n mai multe faze:
- stabilirea obiectivelor pe care le va acoperi viitorul sistem;
- definitivarea coninutului informaional al ieirilor conform cu obiectivele stabilite;
- determinarea bazei informaionale necesare obinerii ieirilor proiectate;
- formalizarea atributelor de intrare i a elementelor structurale ale sistemului
informatic prin codificare;
- proiectarea documentelor de intrare;
- proiectarea structural i funcional a noului sistem;
- elaborarea documentaiei proiectrii generale.
Deoarece asigur definirea conceptual a sistemului informatic, proiectarea general este
independent fa de soluiile tehnice impuse de tipul calculatoarelor electronice, software-ului
utilizat i modul de gestiune a bazelor de date.
Proiectarea general se realizeaz n mai multe variante avnd n vedere aria de
cuprindere a noului sistem, complexitatea obiectivelor, gradul de flexibilitate ce se cere noului
sistem. n abordarea proiectrii generale se poate pleca de la ieiri la intrri, de la intrri la ieiri
sau se poate realiza o variant mixt.
n varianta ieiri - intrri se pleac de la obiectivele sistemului informatic i situaiile de
ieire unde se concretizeaz acestea.
Analiznd modul de obinere a fiecrei informaii se determin baza informaional de
intrare, apoi se realizeaz celelalte faze ale proiectrii.
Ordinea de parcurgere a fazelor este:
- stabilirea obiectivelor;
- proiectarea ieirilor;
- proiectarea bazei informaionale de intrare;
- codificarea;
- proiectarea documentelor de intrare;
- proiectarea structural i funcional;
- elaborarea documentaiei.
Varianta intrri - ieiri poate avea la ieire numai atributele existente n baza
informaional de intrare sau indicatorii ce se pot calcula din atribute.
Aceast variant se recomand n cazul realizrii unor sisteme informatice mari i
mijlocii caracterizate prin complexitatea obiectivelor i a ieirilor informaionale solicitate.
Dup stabilirea obiectivelor se inventariaz documentele de intrare care circul n
sistemul agentului economic pentru determinarea bazei informaionale de intrare.
Ordinea de parcurgere a fazelor este;
- definirea obiectivelor;
- inventariere atributelor de intrare i a legturilor dintre acestea pe baza documentelor
de intrare folosite;
- proiectarea bazei informaionale de intrare;
- codificarea;
- proiectarea documentelor de intrare;
- proiectarea ieirilor sistemului informatic;
- proiectarea structural i funcional;
- elaborarea documentaiei.
Avantajul acestei variante este flexibilitatea bazei informaionale de intrare n condiiile
136
modificrii cerinelor informaionale.
Dezavantajul este dat de baza informaional de intrare care este supradimensionat, ceea
ce determin un timp mare de realizare, costuri ridicate i creterea complexitii prelucrrilor
din sistemul informatic.
Varianta mixt pornete prin stabilirea obiectivelor noului sistem i a unei variante
iniiale a bazei informaionale de intrare, apoi avndu-se n vedere posibilitile de prelucrare se
determin baza informaional de ieire, iar n funcie de solicitrile beneficiarului se proiecteaz
ieirile necesare n prezent i n perspectiv i pe baza lor se proiecteaz varianta final a bazei
informaionale de intrare.
Ordinea de parcurgere a fazelor este:
- definirea obiectivelor;
- proiectarea iniial a bazei informaionale de intrare;
- codificarea;
- proiectarea documentelor de intrare;
- proiectarea ieirilor sistemului informatic;
- reproiectarea bazei informaionale de intrare;
- proiectarea structural i funcional;
- elaborarea documentaiei.


4.4.2. Proiectarea ieirilor sistemului informatic

Realizarea practic a obiectivelor oricrui sistem informatic se concretizeaz prin
satisfacerea cerinelor informaionale ale sistemului de conducere din organismul economic pe
care acesta este grefat, respectiv prin furnizarea ieirilor.
Ieirile sistemului informatic pot fi privite din trei puncte de vedere:
- structural;
- funcional;
- tipologic.
Din punct de vedere structural ieirile sistemului informatic reprezint a treia component
din triada ce caracterizeaz structura oricrui tip de sistem, respectiv INTRRI - PRELUCRRI
- IEIRI.
Din punct de vedere funcional ieirile sistemului informatic concretizeaz obiectivele
generale i specifice ale sistemului.
Din punct de vedere tipologic ieirile sistemului informatic pot fi realizate sub form de:
- liste (rapoarte sau situaii) de ieire care cuprind indicatori ai proceselor, strilor i
rezultatelor activitii economice;
- grafice, care redau ntr-o form sinoptic starea i evoluia indicatorilor economici;
- ieiri ctre alte sisteme informatice sub forma unor colecii organizate de date (fiiere
sau baze de date); acestea pot fi transmise indirect (off-line) prin intermediul
suporturilor tehnice de date (disc magnetic, band magnetic, etc.) sau direct (on-line)
prin mijloace de teletransmisie.
ntr-un sistem informatic economic listele ce grupeaz indicatori economici constituie
ponderea situaiilor de ieire, dar se constat, n ultimul timp, o cretere a ponderi ieirilor sub
form grafic, proces ce se va amplifica pe msura implicrii crescnde a sistemelor informatice
n procesul decizional.
n proiectarea situaiilor de ieire se va ine seama de urmtoarele aspecte:
a) destinaia situaiei i momentul cnd se estimeaz c se poate obine, nivelul de detaliere a
informaiei i anume: informaii mai analitice la nivelurile inferioare ale conducerii i informaii
de sintez la nivelul superior;
b) existena n raport a tuturor informaiilor necesare beneficiarului pe segmentul stabilit;
c) aceeai informaie s nu apar n mod inutil n mai multe situaii, mai ales dac este vorba de o
137
informaie ce se obine n urma unor prelucrri mai complexe.
O situaie de ieire trebuie s ndeplineasc, n general, urmtoarele condiii:
- s se refere la unul din obiectivele sistemului;
- s acopere integral domeniul la care se refer;
- s fie ct mai concis, s elimine detaliile ce nu sunt necesare;
- s fie prezentat ntr-o form simplificat i inteligibil;
- s apar la timp;
- informaiile pe care le conine s fie corelate cu informaiile din celelalte situaii.
Coninutul i forma situaiilor de ieire se stabilesc de ctre colectivul de proiectare
mpreun cu beneficiarul sistemului care va viza nominal macheta fiecrei situaii de ieire.
Situaiile de ieire dintr-un sistem informaional economic pot fi clasificate dup
urmtoarele criterii:
a) specificul funciilor generale ale agentului economic;
b) destinaie;
c) gradul de sintetizare a indicatorilor;
d) momentul generrii;
e) intervalul de referin;
f) modul de obinere.
a) Dup specificul funciilor generale ale agentului economic urmrit n funcie de
natura activitii de baz situaiile de ieire se pot grupa n grupe omogene corespunztoare
funciilor agentului economic:
- situaii de ieire pentru activitatea de producie;
- situaii de ieire pentru activitatea comercial;
- situaii de ieire pentru activitatea financiar-contabil;
- situaii de ieire pentru activitatea de personal.
b) Dup destinaie situaiile de ieire pot fi:
- situaii de ieire destinate altor sisteme;
- situaii de ieire destinate sistemului propriu.
Situaiile de ieire destinate altor sisteme (ageni economici sau organisme de stat) au ca
scop furnizarea de informaii specifice cooperrii n realizarea activitilor proprii i de
informare a organismelor de stat. Acestea sunt stabilite prin acte normative sau prin nelegeri
ntre uniti, motiv pentru care structura lor este obligatorie pentru proiectant. n aceast
categorie se includ rapoartele statistice ale principalilor indicatori economico-financiari, drile de
seam, situaiile operative ntre uniti referitoare la stadiul relaiilor contractuale, etc. Tot aici se
includ i documentele primare generate prin prelucrare automat a datelor (factura fiscal, avizul
de nsoire a mrfii etc.) care circul i n exteriorul sistemului propriu.
Situaiile de ieire destinate sistemului propriu al agentului economic cuprind informaii
necesare att compartimentelor funcionale, ct i organelor de conducere ale uniti. De
exemplu: Situaia realizrii produciei, Situaia livrrilor pe beneficiari, Situaia facturilor emise
i ncasate, etc.
c) Din punct de vedere al gradului de sintetizare a indicatorilor avem:
- situaii de ieire ce conin informaii cu caracter sintetic;
- situaii de ieire ce conin informaii cu caracter analitic.
Situaiile de ieire ce conin informaii cu caracter sintetic servesc pentru conducerea de
ansamblu a agentului economic i cuprind indicatori globali de urmrire i control cum ar fi :
profitul, cifra de afaceri, productivitatea muncii, consumurile, producia marf etc.
Situaii de ieire ce conin informaii cu caracter analitic descriu n detaliu elementele
patrimoniale ale agentului economic, operaiile economice legate de acestea i sunt destinate
compartimentelor funcionale pentru realizare unor lucrri curente. De exemplu: Fia de urmrire
a aprovizionrii, Situaia materialelor fr micare, Graficul de livrare, Situaia realizrii produc
n ziua de .. , etc.
d) Momentul generrii asigur obinerea de situaii cu caracter:
138
- operativ;
- periodic;
- aleator.
Situaiile de ieire cu caracter operativ sunt elaborate la perioade mai mici (schimb, zi,
semidecad, decad,etc.) i conin informaii operative cu un grad redus de prelucrare necesare
conducerii prin excepie. De exemplu: Situaia realizrii produciei n ziua de .., Analiza
realizrii planului de desfacere n ziua de ..., etc.
Situaiile de ieire cu caracter periodic se elaboreaz la intervale mai mari de timp (lunar,
trimestrial, anual) i conin informaii sintetice ce caracterizeaz evoluia fenomenelor i
proceselor economice. Sunt destinate anumitor factori de decizie, compartimentelor funcionale
sau altor sisteme i se caracterizeaz prin termene fixe de elaborare. De exemplu: Situaia
facturilor emise i ncasate pe luna ... , Balana analitic a materialelor pe luna... , Balana
sintetic pe luna ..., etc.
Situaiile de ieire cu caracter aleator sunt obinute cu frecvene i la termene
nedeterminate i conin informaii sintetice sau analitice ce reflect aspecte pozitive sau negative
din activitatea agentului economic, fiind destinate, de regul, conducerii de pe treptele superioare
(director, consiliu de administraie, etc.) De exemplu: Situaia stocurilor ce nu au micare de "n"
zile, Situaia facturilor nencasate de "n" zile, etc.
e) Dup intervalul de referin situaiile de ieire se pot structura n trei categorii:
- de stare;
- statistice;
- previzionale.
Situaiile de ieire cu caracter de stare conin informaii ce evideniaz nivelul i
disponibilul de resurse la un moment dat, reflectnd elemente de patrimoniu ale agentului
economic cum ar fi: stocuri de materiale i produse, facturi n sold, nivelul veniturilor, etc.
Situaiile de ieire cu caracter statistic grupeaz informaii pe mai multe perioade de
gestiune pentru a stabili tendinele evolutive ale fenomenelor i proceselor economice n vederea
formulrii unor aprecieri de ansamblu. Din aceast categorie fac parte situaiile transmise
Comisiei Naionale de Statistic, organelor Ministerului Finanelor sau altor organisme publice.
Situaiile de ieire cu caracter previzional redau informaii ce reflect tendinele fenomenelor i
proceselor economice n scopul stabilirii obiectivelor viitoare ale agentului economic.
f) Dup modul de obinere situaiile de ieire sunt:
- situaii de ieire obinute la imprimant;
- situaii de ieire obinute la videoterminal.
Situaii de ieire obinute la imprimant se folosesc de regul n cazul n care cadrul
legislativ prevede utilizarea lor ca documente justificative ce se vor arhiva dup consultare. De
exemplu: Statele de salarii, Jurnalul privind vnzrile, Situaia centralizatoare a intrrilor de
materiale, etc.
Situaii de ieire obinute la videoterminal sunt de regul situaii de urmrire operativ a
unor indicatori economici i se folosesc n toate cazurile n care cadrul legislativ nu prevede
utilizarea lor ca documente justificative.
n definirea coninutului i modului de obinere a situaiilor de ieire proiectantul va ine
seama de cerinele beneficiarului dar va avea n vedere i performanele i limitele sistemelor
electronice de calcul i ale mediului de programare cu care lucreaz.
La definitivarea fiecrei situaii de ieire trebuie s se precizeze urmtoarele elemente:
- antetul situaiei, care precizeaz date de identificare a unitii (subunitii)
beneficiare, data i eventual codul situaiei;
- titlul situaiei, care red ntr-o form sintetic coninutul informaional al acesteia i
perioada de referin;
- capul de tabel, respectiv prezentarea indicatorilor din fiecare coloan urmrindu-se
gruparea logic a acestora : indicatori informativi ( de exemplu cod, denumire),
139
indicatori de grupare (de exemplu unitate de msur, pre) i indicatori cantitativ-
valorici;
- natura i lungimea maxim a fiecrui indicator;
- benzile de total;
- numrul de exemplare;
- destinaia fiecrui exemplar;
- periodicitatea i termenele de obinere;
- dispozitivul periferic de obinere.


4.4.3. Proiectarea bazei informaionale de intrare

Proiectarea bazei informaionale de intrare nseamn determinarea complet i corect a
mulimii atributelor de intrare necesare i suficiente pentru obinerea ieirilor sistemului
informatic i gruparea acestora ntr-un ansamblu omogen de entiti n vederea construirii n
proiectarea de detaliu a fiierelor sau a bazelor de date.
Proiectarea bazei informaionale de intrare are dou subfaze:
a) determinarea coninutului bazei informaionale de intrare i a algoritmilor folosii;
b) structurarea bazei informaionale n entiti.
a) Determinarea coninutului bazei informaionale de intrare.
Pentru a stabili necesarul atributelor de intrare trebuie examinat modul n care are loc
obinerea informaiilor cuprinse n situaiile de ieire proiectate sau n documentele inventariate
n sistem (n funcie de varianta de lucru aleas n proiectarea general).
Din acest punct de vedere se disting dou categorii de informaii:
- informaii ce se obin n urma aplicrii unui algoritm de calcul (de exemplu: stocul
unui material, soldul unui cont, numrul de zile restan la plata unei facturi, etc.)
- informaii obinute prin simpla transferare a unor valori similare aflate la intrare (de
exemplu: codul unui produs, denumirea unui produs, numele unei persoane, etc.)
Informaiile din prima categorie trebuie descompuse pe baza algoritmului de calcul n
operanzi primari ai acestora. Apoi acetia mpreun cu informaiile preluate (transferate) din a
doua categorie reprezint elementele necesare obinerii informaiilor solicitate.
Deci, ansamblul atributelor de intrare este reprezentat de totalitatea informailor obinute
prin preluare i a operanzilor primari dup reducerea elementelor comune.
Se poate defini urmtorul procedeu de determinare a bazei informaionale de intrare:
- se inventariaz cmp cu cmp informaiile cuprinse n situaiile de ieire proiectate;
- dac informaiile rezult dintr-un calcul se identific algoritmul, apoi operanzii
primari se introduc n baza informaional de intrare dac nu au fost deja inclui;
- dac informaia este transferat se include n baza informaional de intrare dac nu a
fost inclus deja.
Consistena i relevana bazei informaionale de intrare sunt dependente de acurateea
algoritmilor n coresponden cu specificul sistemului obiect.
Ansamblul atributelor de intrare va fi apoi analizat i structurat n entiti, iar algoritmii
de calcul vor fi descrii n procedurile de exploatare. Algoritmii determinai se pot exprima ca
expresii algebrice, liste de aciuni condiionale, tabele de decizii.
b) Structurarea bazei informaionale de intrare n entiti.
Cea de a doua subfaz presupune separarea ansamblului atributelor de intrare n grupe
omogene i stabilirea legturilor dintre acestea. Pentru aceasta se rezolv urmtoarele probleme:
- se analizeaz baza informaional de intrare determinat anterior;
- se grupeaz atributele n entiti.
Analiza bazei informaionale de intrare are scopul de a determina modul de participare
a datelor la procesul de prelucrare automat.
Pentru a efectua aceast analiz se au n vedere elementele funcionale indivizibile ale
140
unui sistem informatic, respectiv entitile.
Entitatea poate fi privit ca un aspect al existenei delimitat ca ntindere, coninut i sens
i desemneaz un element conceptual sau material indivizibil din punct de vedere funcional. Ea
este deci o component structural-funcional elementar a sistemului care are o existen bine
determinat i reprezint o individualitate. De exemplu: entitatea personal, entitatea materiale,
entitatea costuri, etc.
Entitatea este caracterizat printr-o mulime de atribute preluate din nucleul informaional
n urma aplicrii unor criterii de structurare. De exemplu entitatea personal are ca atribute:
numele persoanei, prenumele persoanei, sexul, data naterii, etc.
Pentru a realiza analiza corect a bazei informaionale de intrare este necesar distincia
clar ntre atribut i valoarea pe care o poate avea. De exemplu NUME este un atribut (un nume
de dat, o caracteristic) a entitii PERSONAL iar Popa, Sandu, Radu, etc. sunt valori pe care le
ia atributul respectiv. Din perspectiva proiectrii i realizrii unui sistem informatic intereseaz
identificarea atributului i nu a valorilor concrete pe care acesta le poate lua.
Valoarea informaional a unei entiti cuprinde trei aspecte:
- caracteristici determinante specifice care identific entitatea i o individualizeaz n
ansamblul sistemului;
- nivelul sau starea entitii la un moment dat;
- transformrile sau schimbrile care intervin datorit funciilor sistemului i determin
trecerea de la o stare la alta.
Poziia unui atribut n raport cu o entitate i confer acestuia un mod specific de
comportare i de aici rezult trei feluri de atribute: cu caracter permanent, variabil i de stare.
Atributele permanente rmn neschimbate o perioad mai mare de timp, se preiau n
sistem o singur dat i se actualizeaz la intervale mai mari de timp. Ele intr n componena
entitilor permanente. De exemplu: marca, nume, sex, etc. sunt atribute permanente ale entitii
de personal.
Atributele variabile se caracterizeaz prin aceea c valoarea lor variaz de la o prelucrare
la alta reflectnd fenomene i procese economice ce s-au desfurat de la prelucrarea precedent.
Ele sunt introduse n sistem la fiecare prelucrare i intr n componena entitilor variabile. De
exemplu: timpul lucrat, producia realizat de o persoan, indicele individual de acord, etc. sunt
atribute variabile ale entitii de personal.
Atributele de stare caracterizeaz nivelul unui element la un moment dat i reprezint
rezultatul unei prelucrri. Ele sunt stocate n baza informaional de unde se preiau periodic, se
prelucreaz i se nregistreaz la noua valoare. Ele nu reflect fenomene i procese economice ce
au avut loc ntre dou prelucrri, deci sunt diferite de atributele variabile, dar nu au nici o valoare
constant, ci ea se schimb la fiecare prelucrare i, deci, nu sunt nici atribute permanente. Ele se
introduc n entiti permanente, iar cnd sunt mai numeroase se constituie n entiti de stare. De
exemplu: vrsta, numrul de copii, suma ctigurilor de la nceputul anului, etc. sunt atribute de
stare ale entitii de personal.
Pe baza acestei abordri poate fi definit modelul conceptual de prelucrare pe calculator la
fiecare ciclu astfel:
- se actualizeaz atributele permanente cu eventualele modificri intervenite;
- se introduc n sistem valorile atributelor variabile prin preluarea din documente
justificative a datelor ce reflect operaii economice efectuate de la prelucrarea
anterioar;
- se actualizeaz atributele de stare pe baza valorii iniiale i a micrilor reflectate de
atributele variabile, se calculeaz starea final pentru fiecare atribut de stare;
- se asociaz i se prelucreaz atributele permanente, variabile i de stare pentru
obinerea situaiilor de ieire proiectate.
Gruparea atributelor n entiti are la baz analiza efectuat anterior i const n
separarea ansamblului unic de date n grupuri omogene n funcie de tipul atributelor, de aici
rezult c i entitile sunt permanente, variabile i de stare.
141
Relaiile dintre entiti pot fi:
- atributele din entiti permanente se actualizeaz pe baza tranzaciilor externe ce
reflect modificri n structura i componena acestora;
- entitile variabile se creeaz la fiecare prelucrare pe baza tranzaciilor externe ce
reflect operaiile economice;
- entitile de stare se actualizeaz pe baza tranzaciilor interne.
Gruparea datelor n entiti permanente se face n funcie de urmtoarele criterii:
- atribute de identificare;
- frecvena de utilizare i actualizare;
- accesul la date.
Primul criteriu impune gruparea n aceeai entitate a tuturor atributelor ce au un element
de identificare comun. De exemplu salariul, numrul de copii, data naterii, adresa se pot grupa
ntr-o singur entitate avnd comun elementul de identificare marca sau numele.
Al doilea criteriu determin gruparea n aceeai entitate a atributelor care au aceeai
frecven de utilizare i actualizare. De exemplu sporul de noapte, sporul antier, sporul pentru
condiii deosebite se pot grupa ntr-o alt entitate dect cea anterioar (dei se refer la aceeai
persoan) datorit criteriului precizat.
Al treilea criteriu se refer la gruparea n aceeai entitate a atributelor pentru care sunt
formulate cerine deosebite legate de consultarea bazelor de date i are importan deosebit n
sistemele interactive la care este necesar s se asigure un timp de rspuns ct mai redus.
Gruparea datelor n entiti variabile se face avndu-se n vedere posibilitatea gruprii sub
un identificator comun i n funcie de omogenitatea datelor din punct de vedere al locului i
momentului prelurii lor. Aceasta impune gruparea n aceeai entitate a tuturor atributelor ce se
regsesc pe acelai document de micare.
n cazul n care numrul de documente este relativ mare, iar ponderea lor este inegal n
sistem se poate apela la gruparea atributelor n funcie de operaiile economice pe care le
reflect. De exemplu ieirile de produse se reflect n mai multe documente: factura fiscal,
avizul de nsoire a mrfii, lista de inventariere, etc. n msura n care ieirile prin vnzare au
ponderea cea mai mare se poate apela la gruparea atributelor ce reflect toate ieirile ntr-o
singur entitate, codificndu-se tipurile de ieiri.
Gruparea atributelor n entiti de stare se face n funcie de aceleai criterii ca i cele
avute n vedere la entitile permanente. De regul, numrul atributelor de stare este mai mic i
soluia cea mai avantajoas este aceea a gruprii lor n entitile permanente la care se refer,
obinndu-se astfel entiti cu un grad mai ridicat de integrare. De exemplu atributele stoc i data
ultimei micri pot fi nregistrate n entitatea permanent produs care va oferi astfel o imagine
mai complet asupra unui produs la un moment dat.
Constituirea entitilor n cadrul bazei informaionale de intrare poate fi privit ca o
operaie de separare a ansamblului unic de date n mai multe grupe omogene. Aceste grupe ar
trebui, la prima vedere, s constituie submulimi disjuncte pentru a evita prelurile repetate. Dar,
n cursul prelucrrii, va fi necesar reconstituirea parial a ansamblului iniial de atribute,
respectiv cuplarea a dou sau mai multe entiti . Pentru aceasta entitile ce se vor cupla trebuie
s aib atribute comune pentru a permite realizarea asocierilor necesare.
Atributele prezente simultan n dou sau mai multe entiti se numesc atribute de
legtur. Ansamblul atributelor de legtur dintre entiti se determin pe baza asocierilor pe
care le impun informaiile ce vor trebui obinute n situaiile de ieire i algoritmii de calcul.
Trebuie menionat c nu toate atributele ce se pot gsi simultan n mai multe baze de date
pot constitui atribute de legtur. Pentru aceasta atributul respectiv trebuie s constituie
identificator pentru cel puin una din entitile asociate. De exemplu pentru obinerea unei situaii
de ieire utilizm entitile cu structura de mai jos:
- entitatea produs cu atributele: cod produs, denumire, unitate de msur, pre;
- entitatea micri cu atributele: cod produs, pre, cantitate.
Atributul pre, dei este prezent n ambele entiti, nu poate servi drept atribut de legtur
142
deoarece nu identific n mod unic nici una din entitile ce cupleaz. De aceea se va folosi ca
atribut de legtur codul produsului.


4.4.4. Proiectarea codurilor

O cerin de baz a sistemelor informatice este aceea ca elementele din sistem s fie
riguros definite, ordonate i clasificate prin codificare.
Codificarea reprezint o activitate cu implicaii mari n prelucrarea automat a datelor
regsindu-se sub dou aspecte :
- pe de o parte, ca o codificare intern a datelor n calculatorul electronic;
- pe de alt parte, ca o codificare extern, ceea ce permite introducerea n prelucrare a
unor date ct mai mpachetate, mai formalizate.
Prin codificare nelegem generarea unor grupuri de simboluri, denumite coduri i
repartizarea acestora valorilor concrete pe care le iau elementele diferitelor mulimi (n cazul
unui sistem informatic se codific att atribute din baza de date ct i elementele structurale i
funcionale ale sistemului)
Rezultatul activitii de codificare este concretizat ntr-un sistem de coduri.
Prin cod se nelege o combinaie de simboluri asociate unui ansamblu de date. ntre
mulimea simbolurilor ce urmeaz a fi codificate i mulimea codurilor asociate se stabilete o
coresponden biunivoc.
Totalitatea combinaiilor distincte, posibile de realizat din simbolurile ce compun un cod
reprezint capacitatea unui sistem de coduri.
Un cod trebuie s aib o capacitate acoperitoare pentru toate situaiile posibile cu
condiia pstrrii unicitii codului.
Capacitate unui sistem de coduri numeric se determin cu formula:
C = b
n
- 1
unde : C = capacitatea codului
b = baza sistemului de numeraie utilizat
n = numrul de poziii numerice din cadrul codului
Capacitatea unui sistem de coduri alfanumeric se determin cu formula:
C= 24
a
* b
n

unde : C = capacitatea codului
a = numrul de poziii alfabetice din cadrul codului
b = baza sistemului de numeraie utilizat
n= numrul de poziii numerice din cadrul codului
Numrul de simboluri elementare dintr-un cod poart denumirea de lungime a secvenei de cod
(lungimea codului).
Lungimea codului trebuie s fie minim pentru a reduce timpul de transmisie i preluare a
datelor pe suporii tehnici de date, pentru a reduce timpul de prelucrare etc.
n acelai timp, lungimea codului trebuie s-i asigure i o capacitate corespunztoare.
Aceasta se poate estima cu relaia: L>= log
K
N
unde: L = lungimea codului
N = numrul de elemente ce se codific
K = numrul de simboluri utilizate n construirea codului
Forma final a codului cu precizarea clar a numrului de poziii utilizate, natura
acestora, cifra de control i algoritmul de calcul al acesteia reprezint formatul codului.
n proiectarea unui sistem de coduri trebuie s avem n vedere dou aspecte importante i
anume:
- influena tipului i structurii codului asupra performanelor operaiilor de prelucrare
automat a datelor din sistemul informatic;
143
- implicaiile utilizrii codurilor n operaiile de culegere i preluare a datelor i de
interpretare a rezultatelor finale de ctre utilizatorii neinformaticieni.
Avnd n vedere aceste considerente, se impune ca n proiectarea unui sistem de coduri s
se respecte o serie de cerine:
1. Unicitate. Fiecrui element din mulimea codificat i se atribuie un cod unic, aceast
cerin trebuind s fie asigurat la nivelul ntregului sistem informatic.
2. Stabilitate. Caracteristica codificat trebuie s rmn neschimbat o perioad ct mai
mare de timp.
3. Elasticitate. S permit inserri i extensii ale nomenclatoarelor de coduri n vederea
includerii de noi elemente.
4. Conciziune. S se utilizeze un numr ct mai mic de simboluri n construirea unui
cod.
5. Claritate. S permit realizarea cu uurin a operaiunilor de codificare-decodificare.
6. Semnificaie. S permit, pe ct posibil, sugerarea caracteristicilor codificate i s
genereze interes pentru a facilita utilizarea codurilor.
7. Codul s fie operaional. S permit prelucrarea automat a datelor i efectuarea cu
uurin a operaiilor de sortare, indexare, scindare, interclasare etc.
Un sistem de coduri are urmtoarele funcii:
a) Funcia de caracterizare, care asigur exprimarea ntr-o form concis, unic i
stabil n timp, a coninutului semantic al fiecrui element codificat prin intermediul codului
asociat acestuia. n mod concret funcia de caracterizare permite utilizarea cu prioritate a codului
n locul denumirii integrale a elementului codificat.
b) Funcia de identificare, care ofer posibilitatea regsirii mai rapide a elementelor
prin intermediul codurilor asociate lor dect prin folosirea complet a semanticii acestora.
Aceast funcie creeaz posibilitatea ulterioar de selectare a anumitor caracteristici prin
intermediul crora se vor identifica n mod unic valori folosind conceptul de cheie de acces.
c) Funcia de control, care presupune existena unei chei de control (format din unul
sau mai multe caractere) pe baza creia folosind metode i algoritmi specifici s se poat verifica
integral corectitudinea simbolurilor care intr n structura codului. De regul, aceast cheie de
control se plaseaz n ultima parte a codului i este separat de acesta printr-o linie de unire.
d) Funcia de manipulare a elementelor codificate, care faciliteaz introducerea n
memorie a acestora, reducerea timpului de prelucrare, inclusiv uurina folosirii codului de ctre
personalul din compartimentele funcionale implicate n funcionarea sistemului informatic.

Tipuri de coduri. Diversitatea i complexitatea coleciilor de date, specificul operaiilor
de regsire, sortare, indexare etc. au condus la apariia unei palete variate de coduri, ce se pot
grupa dup mai multe criterii .
I). Dup natura caracterelor utilizate:
1. Coduri numerice, n care simbolurile utilizate n construirea codului sunt cifrele de la 0
la 9. De exemplu codificnd seciile din facultate: 11 pentru Management; 12 pentru
Contabilitate; 13 pentru Informatic etc.
2. Coduri alfabetice, n care simbolurile utilizate n construirea codului sunt literele
alfabetului. De exemplu : MIZ pentru Management, cursuri de zi; CIS pentru Cibernetic,
informatic i statistic etc.
3. Coduri alfanumerice, n care simbolurile utilizate sunt cifrele, literele i toate
caracterele speciale cuprinse n codul ASCI.
II. Dup lungimea secvenei de cod exist:
1. Coduri cu lungime fix, n care toate elementele unei mulimi sunt codificate cu acelai
numr de caractere.
2. Coduri cu lungime variabil, n care lungimea secvenei de cod poate fi diferit pentru
elemente diferite din aceeai mulime.
III. Dup semnificaia codului sunt:
144
1. Coduri semnificative. Aceste coduri semnific coninutul informaional al elementelor
pe care le reprezint. De exemplu: lect - semnific valoarea lector, conf - semnific valoarea
confereniar, stud - semnific student etc.
2. Coduri nesemnificative. Aceste coduri nu semnific coninutul informaional al
elementelor pe care le reprezint. Ele sunt combinaii de simboluri dup anumite criterii i se
atribuie elementelor fr a avea o semnificaie. De exemplu: 01 - pentru lector, 02 - pentru
confereniar etc.
IV. Dup modul de ntocmire a nomenclatoarelor de coduri exist:
1. Coduri atribuite manual;
2. Coduri atribuite automat.
V. Din punct de vedere al utilizatorului se pot folosi:
1. Coduri accesibile utilizatorului;
2. Coduri ascunse utilizatorului.
VI. Dup structura codului exist:
1. Coduri elementare;
2. Coduri complexe.
Codurile elementare au rolul de a identifica un element din cadrul unei singure mulimi
de elemente. Ele pot fi:
- coduri secveniale,
- coduri secveniale cu formare de grupe,
- coduri abreviate.
Codurile secveniale se construiesc prin atribuirea n ordine cresctoare a unor simboluri
numerice sau alfanumerice elementelor din mulimea ce urmeaz a fi codificat, pe msur ce
aceste elemente apar n sistem. Ele pot avea lungim fix sau variabil. n cazul codurilor cu
lungime fix se adaug zerouri nesemnificative n faa irurilor de caractere atribuite.
Codurile secveniale au avantajul conciziunii, dar nu sunt elastice i nu pot fi utilizate
eficient n gruparea datelor.
Codurile secveniale cu formare de grupe. Reprezint o dezvoltare a codurilor
secveniale, n sensul c se prevede rezervarea unor grupe de coduri pentru grupe de elemente,
iar n cadrul grupelor elementele sunt codificate secvenial.
Separarea mulimii elementelor de codificat pe grupe sau subgrupe se face pe baza unor
caracteristici comune tuturor elementelor ce aparin grupei sau subgrupei respective.
Acest tip de coduri este elastic, servind i necesitilor de grupare i ordonare a datelor.
Coduri abreviate. Sunt coduri alfabetice, de lungime fix sau variabil care se constituie
prin prescurtare sau prin preluarea unor iniiale.
Cele obinute prin prescurtare poart denumirea de mnemonice.
Cele obinute prin preluarea unor iniiale poart denumirea de acronime.
Codurile complexe. Se folosesc pentru elementele ce pot s aparin mai multor mulimi
distincte care pot fi folosite n comun pentru prelucrri viitoare. Aceste coduri sunt astfel
construite nct s reflecte apartenena multipl. El pot fi:
- coduri ierarhizate,
- coduri juxtapuse,
- coduri combinate.
Codurile ierarhizate se folosesc atunci cnd ntre caracteristicile ce urmeaz a fi
simbolizate (codificate) sunt stabilite relaii de subordonare.
Codurile juxtapuse (partajate) se construiesc prin concatenarea codurilor atribuite
caracteristicilor individuale cu semnificaii distincte.
Codurile combinate surprind n structura lor relaiile logice existente ntre diferite
caracteristici ale elementelor de codificat. Ele pot fi matriciale sau binare.
Codurile matriciale se folosesc n cazul n care elementele de codificat pot fi caracterizate
n funcie de dou nsuiri, codul atribuit reprezentndu-le cumulativ pe amndou.
145
Codurile binare se folosesc pentru a reflecta n mod sugestiv i simplu prezena sau
absena mai multor nsuiri ce caracterizeaz simultan elementele unei mulimi de date. n acest
sens, nsuirile respective se codific prin puteri succesive ale cifrei doi, fiecare poziie putnd
lua valoarea 0 sau 1 n funcie de prezena sau absena nsuirii respective.
VII. Dup modul de preluare n sistemul de calcul, codurile pot fi:
1. Coduri preluate manual (prin tastare de la terminal);
2. Coduri preluate automat. Ele sunt introduse n sistem prin utilizarea unor
echipamente periferice speciale precum: echipamente pentru citirea documentelor
scrise cu cerneal magnetic, scannere, camere video i alte echipamente multimedia.
VIII. Dup modul n care trateaz erorile provenite n urma utilizrii unui sistem de
coduri ntlnim:
1. Coduri care nu detecteaz erorile de manipulare;
2. Coduri autodetectoare de erori;
3. Coduri autocorectoare de erori.

Activitile parcurse n elaborarea unui sistem de coduri sunt:
1. analiza elementelor ce urmeaz a fi codificate;
2. precizarea i uniformizarea terminologiilor;
3. stabilirea caracteristicilor i a relaiilor dintre elementele de codificat;
4. alegerea tipurilor de coduri;
5. estimarea capacitii, lungimii i formatului codurilor;
6. determinarea cifrei de control corespunztoare fiecrui cod i asocierea ei codului
respectiv;
7. atribuirea codurilor elementelor de codificat, respectiv crearea nomenclatoarelor de
coduri;
8. ntreinerea nomenclatoarelor de coduri.
O problem deosebit care se ridic n legtur cu codificarea datelor este acea a
verificrii corectitudinii codului n procesele de culegere, transmitere i prelucrare a
datelor.
Cu ocazia manipulrii codului, apar posibiliti ca acesta s fie modificat, erorile astfel
generate avnd consecine negative asupra corectitudinii informaiilor obinute i asupra
funcionrii sistemului informatic n ansamblu.
Pe parcursul exploatrii sistemului informatic pot s apar erori datorate:
- transpunerii greite pe documentul justificativ sau pe elementul pe care codul l
identific;
- prelurii incorecte (de pe documentele justificative de exemplu) n sistemul de calcul.
S e pune deci problema de a utiliza metode ce pot prevenii sau depista erorile n codificare
i n utilizarea codurilor. n acest sens, o tehnic des utilizat este cea a cheii (cifrei) de control.


4.5. PROIECTAREA DE DETALIU

4.5.1. Caracteristicile generale ale proiectrii de detaliu

Obiectivul fundamental al proiectrii de detaliu const n realizarea cerinelor funcionale
definite n proiectarea general, prin transformarea modelului conceptual ntr-un model tehnic,
operaional. n acest scop se alege soluia optim de gestiune a datelor, bazat pe principiul
utilizrii fiierelor sau a bazelor de date i se proiecteaz structurile de date, inclusiv prelucrrile
specifice la nivelul subsistemelor (sau al sistemului informatic n ansamblu) i prelucrrile
specifice de la nivelul procedurilor.
146
Proiectarea de detaliu are un caracter preponderent tehnic, iar activitile desfurate sunt
influenate direct de soluia de gestiune a datelor aleas, de caracteristicile sistemului electronic
de calcul, de sistemul de operare, precum i de mediul de programare ce va fi utilizat.
n realizarea practic a proiectrii de detaliu a sistemului informatic se parcurg urmtoarele
faze: proiectarea fiierelor; stabilirea ordinii de prelucrare a fiierelor; determinarea procedurilor;
proiectarea procedurilor.


4.5.2. Proiectarea fiierelor

Urmrete determinarea celei mai adecvate structuri de date pentru entitile bazei
informaionale anterior stabilite, n vederea optimizrii obinerii ieirilor proiectate. Pentru
aceasta trebuie realizate urmtoarele activiti:
- definitivarea dicionarului de date i a clasificrii fiierelor de baz,
- proiectarea structurii nregistrrilor,
- alegerea modului de organizare a fiierelor de baz i a suporturilor de memorie extern,
- definirea msurilor de protecie i securitate.


4.5.3. Stabilirea ordinii de prelucrare a fiierelor de baz

Ordinea de prelucrare a fiierelor de baz este determinat de restriciile de integritate
dintre fiiere, determinate ca reguli sau condiii formulate n scopul meninerii coerenei datelor
n timpul operaiunilor de prelucrare.
Aceste restricii sunt evideniate prin subordonarea dintre fiiere, care impun ca valoarea
unuia sau mai multor cmpuri dintr-un fiier s se regseasc n calitate de cheie primar sau
extern pentru alt fiier.
Pentru a exemplifica, s considerm fiierul PRODUS (un nomenclator ce conine date
permanente i de stare) i MICRI (un fiier cu date variabile ce conine intrrile i ieirile de
produse). Fiecare produs ce se gsete n fiierul MICRI trebuie sa aib un corespondent n
fiierul PRODUS, cmpul COD_PROD fiind n acelai timp cheie primar pentru fiierul
PRODUS i cheie extern pentru fiierul MICRI.
Restriciile de integritate dintre fiiere determin ordinea de prelucrare a lor, astfel nct
crearea i actualizarea unui fiier s se fac numai dup ce s-a efectuat actualizarea tuturor
fiierelor de care acesta depinde. Regula este c se actualizeaz n primul rnd fiierele cu date
permanente (nomenclatoarele) i apoi fiierele variabile. n acest context fiierul PRODUS
trebuie actualizat naintea prelucrrii fiierului MICRI, pentru a putea reflecta i micrile
referitoare la produsele noi.
Restriciile de integritate dintre fiiere pot fi privite n sens static i n sens dinamic.
n sens static acestea reflect, dup cum am vzut, modul de subordonare a prelucrrilor
unui fiier n raport cu altul, ceea ce condiioneaz n mod direct ordinea de prelucrare.
Restriciile de integritate dintre fiiere, abordate n sens dinamic exprim reguli sau
corelaii existente nainte sau pe parcursul prelucrrii acestora i sunt, n general, dictate de
particularitile sistemului obiect. De exemplu, n cadrul operaiilor privind micrile de produse
vor fi prelucrate mai nti intrrile i apoi ieirile, pentru a evita apariia de stocuri intermediare
negative (anomalie din punct de vedere economic).
Deci ntr-o aplicaie informatic economic ordinea de apelare a procedurilor trebuie s fie
urmtoarea: proceduri de actualizare a fiierelor permanente; proceduri de actualizare a fiierelor
variabile; proceduri de actualizare a datelor (fiierelor) de stare; proceduri de obinere a ieirilor.



147
4.5.4. Determinarea procedurilor

ntr-un sistem informatic economic procedura poate fi definit ca o secven de operaii
repetitive executate fr ntreruperi externe de la acelai post de lucru, care transform un anumit
ansamblu de intrri n anumite ieiri, dup reguli bine definite.
Pentru fiecare procedur va trebui s specificm urmtoarele elemente: funcia procedurii;
intrrile n procedur; ieirile din procedur; logica intern de prelucrare; interfeele cu alte
proceduri.
Funcia procedurii indic natura prelucrrilor sale asupra fiierelor, existnd mai multe
tipuri: proceduri pentru dirijarea altor proceduri (aa numitele proceduri de comand); proceduri
pentru introducerea i validarea datelor; proceduri pentru actualizarea fiierelor; proceduri pentru
exploatarea fiierelor i obinerea ieirilor; proceduri pentru reorganizarea fiierelor de baz;
proceduri pentru protecia i securitatea fiierelor de baz.
Intrrile n proceduri sunt constituite din parametri de apel i date de intrare din fiierele de
baz. Fiecare tip de intrare trebuie descris, n documentaie, n forma standard, respectiv cu
specificatorul complet de fiier.
Ieirile din proceduri sunt constituite din fiierele create sau situaiile de ieire obinute i
trebuie descrise, ca i intrrile, cu specificatorul complet de fiier.
Logica intern de prelucrare indic modul concret de transformare a intrrilor n ieiri
(validri, conversii, actualizri, ordonri, calcule etc.). Ea se poate prezenta n proiect cu orice
metod de descriere a algoritmilor, respectiv: scheme logice, tabele de decizii, limbaj pseudocod
etc.
Interfeele dintre proceduri sunt constituite din ansambluri de date (fiiere) create intr-o
procedur la momentul "t" care pot constitui intrri pentru aceeai procedur la momentul "t+1"
sau pentru o alt procedura la momentul "t" sau "t+1".
Determinarea procedurilor se face n funcie de anumite criterii dintre care menionm:
tipologia i natura prelucrrilor din subsistem (actualizri, exploatri etc.);
frecvena i termenele de realizare a prelucrrilor fiierelor de baz sau a obinerii
situaiilor de ieire;
natura i specificul intrrilor i ieirilor din subsistem;
ordinea de prelucrare a fiierelor de baz;
necesitatea asigurrii unor proceduri de dirijare;
asigurarea unor interfee optime intre proceduri etc.
Este indicat ca n proiectarea procedurilor s se foloseasc metoda top-down, pornindu-se
de la cele dou funcii principale pe care trebuie s le asigure un sistem informatic economic,
respectiv actualizarea fiierelor de baz i obinerea ieirilor proiectate.


4.5.5. Proiectarea procedurilor

Are ca obiective definirea tuturor elementelor tehnice necesare elaborrii programelor,
inclusiv redarea, testarea i corectarea programelor propriu-zise.
Proiectarea de detaliu a procedurilor (a programelor de aplicaie) cuprinde:
proiectarea datelor specifice procedurilor;
proiectarea prelucrrilor specifice procedurilor.
1. Proiectarea datelor specifice procedurilor. Datele necesare procedurilor sunt
concretizate n fiierele de baz ale sistemului proiectat sau n fiierele intermediare impuse de
necesitatea detalierii tehnice a realizrii funciei complexe a fiecrei proceduri.
Proiectarea datelor specifice procedurilor se refer la:
a) intrrile n proceduri;
b) ieirile din proceduri;
c) fiierele intermediare.
148
a) Proiectarea intrrilor specifice procedurilor are n vedere datele de intrare necesare
constituirii fiierelor de baz precum i dialogul procedurii cu utilizatorul, n cazul sistemelor
interactive.
Datele de intrare se preiau din documentele de intrare al cror format a fost definitivat
integral n proiectarea generala.
Dialogul cu utilizatorul se realizeaz n urmtoarele forme:
- prin secvene de ntrebri i rspunsuri dirijate de modulele procedurii;
- prin afiarea pe ecran a unei liste de funcii sau opiuni de prelucrare din care
utilizatorul o selecteaz pe cea dorit (aa numita tehnic a meniurilor).
b) Proiectarea ieirilor specifice procedurilor se refer la listele (situaiile de ieire)
solicitate de beneficiar i rezultatele controlului fiierelor de baz.
Elementele necesare proiectrii ieirilor au fost definitivate n cadrul proiectrii generale,
urmnd ca n proiectarea de detaliu s se stabileasc modul de obinere a lor, prin programe
precizate, precum i modul de dispunere n pagin sau pe monitor.
Datele care formeaz coninutul listelor trebuie afiate n aa fel nct s fie ct mai uor de
consultat, evitnd repetarea datelor comune. Aranjarea n pagin a situaiilor de ieire trebuie s
ia n considerare restriciile impuse de suportul utilizat, respectiv lungimea maxim a rndului i
numrul de rnduri pe pagin sau pe ecran.
O soluie eficient de obinere a situaiilor de ieire o reprezint utilizarea generatoarelor
de rapoarte. Un generator de rapoarte este o component specializat a unui mediu de
programare care creeaz rezultatele destinate afirii sau imprimrii pe baza simplei lor descrieri,
fr eforturi de programare.
c) Proiectarea fiierelor intermediare se refer la coleciile tampon de date, diferite de cele
din fiierele de baz ale sistemului, utilizate n prelucrare. Ele pot fi:
- fiiere de interfa, ce asigur comunicarea ntre proceduri i au structuri determinate
de setul de date transmise de la o procedur la alta;
- fiiere tampon, ce asigur realizarea anumitor faze ale prelucrrii, cum ar fi: sortrile,
indexrile, asocierile etc.
2. Proiectarea prelucrrilor specifice procedurilor. Se refer la:
a) determinarea modulelor de prelucrare;
b) introducerea i validarea datelor;
c) prelucrarea fiierelor;
d) obinerea situaiilor de ieire.
a) Determinarea modulelor de prelucrare urmrete descompunerea funciei complexe de
prelucrare a procedurii n funcii elementare care s asigure definirea i executarea succesiv a
intrrilor prelucrrilor i ieirilor specifice procedurilor.
Modulul asigur anumite prelucrri omogene, are un nume unic i este reprezentat de o
secven finit de instruciuni sau comenzi de prelucrare.
Proiectarea procedurilor dup metoda programrii modulare const n descompunerea
procedurilor n module interconectate n conformitate cu o ierarhie bine precizat. Tehnica
modularizrii trebuie utilizat, att la nivelul proiectrii i realizrii sistemelor informatice, ct i
la nivelul fiecrei proceduri n parte. Ea presupune identificarea funciilor elementare ale
procedurii printr-o analiz de sus n jos (top-down) i realizarea legturilor de structura dintre
module.
n cadrul unei proceduri se pot distinge mai multe tipuri de module:
module de dirijare (module de tip monitor) care coordoneaz la nivelul procedurii
aciunea altor module; un modul este de tip monitor dac n structura lui exist cel puin o
operaie de lansare n execuie a altui modul; un modul monitor poate s conin numai
operaii de lansare n execuie a modulelor de nivel imediat inferior, sau uneori i operaii
care se regsesc ca atare n algoritmul de prelucrare al procedurii respective;
module de prelucrare (module operaionale sau module funcii) care execut operaii de
prelucrare conform algoritmului precizat;
149
module comune folosite de mai multe module de nivel superior sau chiar de proceduri
diferite;
module nefuncionale care pot s cuprind descrierea centralizat a datelor, comentarii
etc.
b) Introducerea i validarea datelor asigur transpunerea datelor din documentele de
intrare anterior proiectate pe un suport tehnic de date i validarea acestora.
Validarea are rolul de a controla datele de intrare pe baza unui set de reguli predeterminate,
prin intermediul unor operaii de control efectuate de programe sau module de validare.
Operaiile de control pot avea caracter sintactic cnd se verific forma, sau semantic cnd se
verific fondul.
Operaiile de control sintactic pot s asigure verificarea tipului datelor, a lungimii acestora,
pot s controleze cheile de control pentru codurile autodetectoare i autocorectoare de erori etc.
Operaiile de control semantic pot fi:
generale, cnd urmresc depistarea unor valori incompatibile (de exemplu: luna 13,
ziua 32 etc.);
de gestiune, cnd urmresc depistarea datelor care nu respect reguli sau restricii
specifice sistemului obiect (de exemplu, n cazul aplicaiilor economice: verificarea valorii
i duratei de funcionare pentru ca un obiect sa fie nregistrat ca mijloc fix, controlul
stocurilor etc.).
Controlul semantic mai poate fi:
local cnd acioneaz la nivelul nregistrrii (de exemplu: verificarea prezenei datelor
strict necesare intr-o nregistrare; verificarea valorii cmpurilor (16>=vrsta_salariat<=65);
verificarea compatibilitii ntre valorile a dou sau mai multe cmpuri (vrsta i vechimea
n munca, vrsta i numrul de copii etc.)
global, cnd acioneaz la nivelul fiierului (de exemplu: verificarea unicitii cheilor
primare; verificarea numrului de nregistrri etc.).
Operaiile de validare pot fi incluse n proceduri distincte sau pot constitui module n
diferite proceduri.
c) Prelucrarea fiierelor grupeaz urmtoarele operaii:
generarea: crearea structurii fiierului;
iniializarea fiierului: ncrcarea cu date n momentul implementrii;
actualizarea fiierului: inerea la zi a fiierului n raport cu schimbrile din sistemul
obiect; pot fi actualizri simple (interactive, cu date introduse de la terminal ) sau
complexe (prin prelucrarea datelor nregistrate n alte fiiere)
exploatarea (consultarea) fiierului pentru obinerea ieirilor proiectate;
reorganizarea fiierului prin modificarea structurii.
d) Obinerea situaiilor de ieire presupune realizarea succesiv a operaiilor:
constituirea fiierelor tampon (de interogare) cu datele necesare obinerii situaiei;
ordonarea fiierului tampon;
generarea situaiei (definirea structurii sale intr-un program sau cu generatorul de
rapoarte);
obinerea efectiv a situaiei.


4.6. IMPLEMENTAREA SISTEMELOR INFORMATICE

Implementarea finalizeaz activitatea de realizare a sistemelor informatice. n cadrul ei se
testeaz, se asambleaz, se verific i se asimileaz de ctre beneficiar toate soluiile stabilite n
etapele anterioare i se valideaz rezultatele obinute.
Obiective ale etapei de implementare sunt: experimentarea sistemului proiectat; finisarea
noului sistem; punerea n funciune; recepia sistemului informatic.
150
Principalele grupe de activiti ce trebuie realizate n etapa de implementare sunt:
asigurarea condiiilor de punere n funciune;
funcionarea experimental i punerea n funciune a sistemului proiectat;
definitivarea documentaiei sistemului informatic;
recepionarea i omologarea noului sistem.


4.6.1. Asigurarea condiiilor de punere n funciune

Implementarea sistemului informatic proiectat depinde n mod hotrtor de felul n care
beneficiarul asigur condiiile de punere n funciune. Aceasta presupune n principal
urmtoarele activiti: difuzarea instruciunilor de executare a procedurilor manuale i automate;
instruirea personalului utilizator; asigurarea condiiilor organizatorice necesare; asigurarea
resurselor hard; asigurarea fondului informaional.
a) Difuzarea instruciunilor de executare a procedurilor manuale i automate. Aceste
instruciuni se pot grupa n instruciuni pentru beneficiar (personalul de specialitate - economitii
din compartimentele funcionale n sistemele economice - care va beneficia de rezultatele
implementrii) i instruciuni pentru unitatea (colectivul) de informatic ce va asigura
exploatarea noului sistem.
Instruciunile pentru beneficiar cuprind: prezentarea succint a aplicaiei i a fluxurilor
informaionale i decizionale; prezentarea noilor documente proiectate i a instruciunilor de
completare, verificare, avizare, pregtire pentru - prelucrare, i dac este cazul, i a procedurilor
de preluare pe suporii tehnici de date; prezentarea situaiilor de ieire, a modului de folosire i
interpretare a acestora .
Instruciunile pentru unitatea de informatic se refer la: modalitile de prezentare i
recepie a documentelor primare i a situaiilor cu rezultatele finale; modaliti de pregtire i
verificare a purttorilor tehnici de date precum i de corectare a erorilor aferente; modaliti de
operare pe parcursul fluxului de prelucrare i de intervenie n cazul unor incidente ce pot s
apar pe parcursul executrii programelor.
b) Instruirea personalului utilizator grupeaz o serie de activiti precum: iniierea n
utilizarea tehnologiilor informatice (sau actualizarea cunotinelor informatice); nsuirea
corect de ctre fiecare persoan implicat n funcionarea noului sistem a sarcinilor ce i revin,
att pe parcursul etapei de implementare, ct i n exploatarea curent; pregtirea psihologic a
personalului unitii beneficiare pentru recepionarea corect a efectelor pe care le va aduce cu
sine sistemul informatic.
c) Asigurarea condiiilor organizatorice necesare se refer n primul rnd la transpunerea n
practic a modificrilor organizatorice preconizate n etapa de proiectare general, la lansarea
efectiv a documentelor proiectate i la instituirea noilor fluxuri informaionale. De asemenea,
se va constitui nucleul de informaticieni ce va exploata noul sistem i se vor planifica riguros
toate activitile specifice etapei de implementare.
d) Asigurarea resurselor hard se poate efectua n trei moduri:
- prin achiziionarea tehnicii de calcul necesare, atunci cnd capacitatea de prelucrare poate
fi acoperit cu lucrri;
- prin perfectarea accesului la o unitate prestatoare de servicii informatice pentru un anumit
numr de ore-calculator, atunci cnd volumul lucrrilor este mic;
- printr-o soluie mixt, care presupune rezolvarea unor probleme, de un volum mai mic, n
cadrul unitii, iar pentru problemele mai complexe s se apeleze la capacitatea unei uniti de
informatic cu o dotare corespunztoare, lucrndu-se eventual n regim de teleprelucrare.
De o deosebit importan sunt i: asigurarea softului de baz necesar; asigurarea
materialelor consumabile; asigurarea unui spaiu corespunztor desfurrii activitii
colectivului de informatic, care s permit realizarea unor lucrri de calitate, dar i pstrarea
integritii i confidenialitii fondului de date manipulat.
151
e) Asigurarea fondului informaional. Presupune pregtirea datelor reale i ncrcarea
fiierelor sau bazelor de date n vederea testrii i punerii n funciune a noului sistem, pregtire
ce se face prin: constituirea fiierelor sau bazelor de date, prin culegerea fondului informaional
necesar i stocarea acestuia pe purttori tehnici de date (pentru aceasta vor fi necesare i o serie
de activiti pentru colectarea, ordonarea i codificarea datelor); preluarea parial sau integral
a datelor dintr-o serie de fiiere deja existente, cu ajutorul unor programe de conversie, dac
efortul depus corelat cu timpul necesar i cu efectele obinute justific aceast operaie.


4.6.2. Funcionarea experimental i punerea n funciune a sistemului proiectat

Dac n unitatea beneficiar exist deja un sistem informatic sau dac implementarea
noului sistem se ealoneaz mult n timp pe componente funcionale, mai nti se execut
procedurile de conversie (pentru fiiere, programe, proceduri) din vechiul n noul sistem.
Responsabilitatea pentru punerea n funciune a unui sistem informatic revine: conducerii
unitii beneficiare, proiectantului sistemului informatic i colectivului de informatic care preia
sarcina prelucrrii datelor n noul sistem.
Punerea n funciune a unui sistem informatic se face n funcie de condiiile concrete din
sistemul economic. Din acest punct de vedere se pot ntlni mai multe situaii:
- situaia punerii n funciune a unui sistem informatic n cazul unui sistem
informaional nou, odat cu nfiinarea unei noi societi comerciale sau a unei
activiti noi etc.
- situaia punerii n funciune a unui sistem informatic pentru perfecionarea unui
sistem informaional existent;
- situaii de lansri n exploatare n funcie de modul de asigurare atehnicii de calcul
necesare (proprie; nchiriat; proprie i nchiriat);
- situaii de punere n funciune difereniate de complexitatea sistemului informatic,
de sfera lui de cuprindere, de particularitile agentului economi i de dispersarea
lui n teritoriu (sunt evidente diferenierile ce exist n punerea n funciune a unui
sistem informatic la o societate comercial concentrat teritorial, fa de una
dispersat teritorial (unde organizarea fluxurilor informaionale ridic probleme
deosebite).
Se pot folosi mai multe strategii de implementare a unui sistem informatic, n funcie de
numrul i ordinea subsistemelor care se testeaz i de comparrile ce se fac cu vechiul sistem.
n funcie de ordinea de testare a subsistemelor componente implementarea poate fi:
- simultan, cnd toate subsistemele se testeaz odat, fr acordarea de prioriti;
- n serie, care presupune testarea pe baz de prioritate a subsistemelor, de obicei
testndu-se mai nti subsistemele cu frecvena cea mai mare.
n funcie de compararea noului sistem cu vechiul sistem implementarea poate fi realizat
n mai multe variante, dintre care enumerm:
- implementarea direct cu date curente, care presupune renunarea la vechiul
sistem n vederea reducerii termenului i a minimizrii cheltuielilor de
implementare;
- implementarea paralel, care se face cu date curente sau anterioare, dar o perioad
noul sistem funcioneaz n paralel cu cel vechi;
- implementarea pilotat, care presupune lansarea numai a anumitor subsisteme (de
exemplu a celor cu frecven maxim) folosind date din perioadele anterioare i
date curente i efectund comparri cu vechiul sistem.
De o deosebit importan este alegerea momentului punerii n funciune a unui sistem
informatic care trebuie s corespund cu nceputul unei perioade semnificative din activitatea
organismului economic n care acesta se integreaz: nceputul unui an calendaristic, introducerea
152
unei noi forme de organizare, lansarea n producie a unei noi tehnologii, nceputul unei noi
activiti etc.


4.6.3. Documentaia final a sistemelor informatice

n timpul implementrii unui sistem informatic pot s apar modificri (structurale i
funcionale) care trebuie operate i n documentaia elaborat pentru a evita dificultile n
exploatarea curent i ntreinerea ulterioar. Documentaia final a unui sistem informatic se
concretizeaz n ntocmirea urmtoarelor lucrri: manualul de prezentare; manualul de utilizare;
manualul de exploatare (operare).
Manualul de prezentare. Cuprinde concepia general a sistemului i se adreseaz
conducerii unitii beneficiare. Un manual de prezentare conine n principal urmtoarele:
- elemente de identificare: pagina de titlu i semnturi; cuprinsul; baza elaborrii;
introducerea etc;
- obiectivele, performanele i limitele noului sistem;
- categorii de probleme abordate i domeniul de aplicare;
- schema funcional a sistemului informatic;
- locul sistemului n ansamblul sistemului informaional al agentului economic
(diagrama de relaii);
- prezentarea ieirilor: tipuri de ieiri i modul de obinere; lista ieirilor; exemple
de ieiri semnificative;
- prezentarea intrrilor: tipul de intrri i moduri de completare; lista intrrilor;
- structura datelor: soluia adoptat pentru organizarea i gestiunea datelor; schema
de structur general a bazei de date i a legturilor ntre fiiere;
- schema general a fluxurilor informaionale n noul sistem;
- resurse necesare exploatrii sistemului informatic: configuraii de calcul, resurse
umane, resurse financiare, alte resurse materiale auxiliare etc;
- condiii de implementare;
- elemente de evaluare a sistemului informatic.
Manualul de utilizare. Este ntocmit pentru fiecare subsistem n parte i se adreseaz
personalului implicat n utilizarea noului sistem la unitatea beneficiar. Instruciunile de utilizare
se elaboreaz pe categorii de utilizatori (compartimente, persoane), iar gruparea pe aceste
categorii se face de realizatorii sistemului informatic mpreun cu conducerea unitii
beneficiare. n principiu, un asemenea manual cuprinde:
- elemente de identificare: pagina de titlu i semnturi; cuprinsul; baza elaborrii;
introducerea etc;
- proceduri manuale de codificare a datelor de intrare: structura codurilor pentru
fiecare mulime de date; graficul de implementare a codificrii, modul de
ntreinere i responsabiliti; liste de coduri i cifre de control; legtura cu alte
sisteme de codificare, la nivel naional i internaional;
- proceduri manuale de colectare i transmitere a datelor de intrare: prezentarea
documentelor de intrare, a instruciunilor de completare, aprobare i verificare (se
va anexa i cte un exemplar din fiecare document completat cu date); instruciuni
de stocare, arhivare, termene de pstrare, difuzare, distrugere; instruciuni de
exploatare a procedurilor destinate prelurii n sistemul de calcul a datelor de pe
documentele de intrare de ctre utilizator; proceduri de control i corecie a
datelor de intrare;
- proceduri de utilizare i interpretare a ieirilor: lista ieirilor i prezentarea unui
exemplu din fiecare situaie de ieire; instruciuni de interpretare i verificare;
fluxuri de circulaie a rapoartelor de ieire, responsabiliti, periodicitate, termene;
modul de difuzare, arhivare, perioada de pstrare;
153
- proceduri speciale de conversie (valabile numai n etapa de implementare): lista
procedurilor manuale i automate de conversie; descrierea fiecrei proceduri.
Manualul de exploatare (operare). Cuprinde informaii cu privire la exploatarea efectiv
a sistemului proiectat prin intermediul sistemului de calcul i se adreseaz personalului din
unitatea de informatic. Are n componen urmtoarele piese:
- elemente de identificare: pagina de titlu i semnturi; cuprinsul; baza elaborrii;
introducerea etc;
- lista procedurilor i graficul de exploatare a acestora;
- descrierea procedurilor de preluare, corectare, validare, stocare i transmitere a
datelor de intrare;
- descrierea tuturor procedurilor automate;
- descrierea procedurilor de operare la calculator: operaii pregtitoare pentru
efectuarea lucrrii; moduri de intervenie n caz de incident; lista mesajelor
aprute pe parcursul operrii i modul de aciune n fiecare caz; timpul de
execuie;
- proceduri de control i transmitere a ieirilor: controlul formal i de fond al
situaiilor de ieire; modul de corectare a erorilor i de reluare a execuiei;
termene de predare la utilizator, evidena i responsabilitile pentru aceste
predri.


4.7. EVALUAREA SISTEMELOR INFORMATICE

Teoria i practica economic propun, n mod tradiional, aprecierea oportunitii i
utilitii sistemelor informatice prin prisma eficienei economice.
Analiza preliminar, n faza de stabilire a necesitii realizrii unui nou sistem, a
resurselor ce vor trebui angajate, corelat cu cea a efectelor previzibile, precum i urmrirea
modului n care se cheltuiesc resursele, n concordan cu obiectivele realizate, este fr ndoial,
ca n cazul oricrei investiii, un lucru necesar dar nu suficient.
Avnd n vedere aceste considerente, trebuie s acceptm ideea c evaluarea unui sistem
informatic economic trebuie fcut prin prisma eficienei economice, dar mai ales prin prisma
modului n care sistemul informatic i realizeaz obiectivele, prin prisma calitii.


4.7.1. Eficiena economic a sistemelor informatice

Eficiena unui sistem informatic poate fi calculat prin compararea efectelor cu valoarea
resurselor alocate pentru construirea i funcionarea sa, dar, pn n prezent, nu s-a ajuns la un
punct de vedere comun cu privire la metodele de cuantificare.
Determinarea resurselor consumate pentru proiectarea, realizarea i implementarea unui
sistem informatic se poate face prin cumularea cheltuielilor n funcie de etapele de proiectare
parcurse i categoriile de cheltuieli implicate.
n general, cheltuielile efectuate cu un sistem informatic pot fi grupate n dou categorii:
a) cheltuieli de realizare, n care sunt cuprinse cheltuielile cu echipamentul, costul
proiectului de realizare a sistemului informatic, costul amenajrilor auxiliare, cheltuieli cu
pregtirea personalului etc.
b) cheltuieli de ntreinere exploatare, n care intr costul utilizrii calculatorului
dac acesta este nchiriat, salariile personalului care va exploata sistemul informatic, costul
energiei electrice consumate, al hrtiei de imprimant, discurilor flexibile, costul pieselor de
schimb, costul abonamentului de ntreinerea periodic etc.
Dac din punct de vedere al elementelor de cost problemele sunt relativ clare,
cuantificarea efectelor economice este mai dificil. Efectele economice obinute prin
154
introducerea unui sistem informatic pot fi grupate n dou categorii i anume:
a) efecte directe, din cadrul sistemului informaional cum ar fi cele rezultate din
reducerea de personal, economia de formulare, rechizite etc.
b) efecte indirecte, din afara sistemului informaional, i anume cele rezultate din
rezolvarea problemelor pe ansamblul unitii economice.
Acest mod de abordare a efectelor economice a dus chiar la separarea eficienei
economice a sistemelor informatice n eficien economic direct i eficien indirect.
Teoria i practica economic recomand o serie de indicatori folosii n evaluarea
eficienei unui sistem informatic att n faza de proiectare ct i n faza de analiz. Aceti
indicatori pot fi grupai n dou categorii i anume:
a) Indicatori ai efectelor economice ce se concretizeaz n rezultate directe i indirecte
aprute n activitatea curent a unitii beneficiare (ca de exemplu: sporul de producie; sporul
de profit; economia de personal; reducerea cheltuielilor etc. - toi calculai avnd n vedere
nivelurile nregistrate nainte i dup introducerea sistemului informatic);
b) Indicatorii sintetici, care cuantific eficiena economic obinut prin introducerea
sistemului informatic ca o investiie a unitii economice beneficiare. Principalii indicatori n
acest sens sunt:
1. Coeficientul eficienei economice, care se poate calcula pentru fiecare subsistem
informatic (k
efj
) sau pentru sistemul informatic n ansamblu, se determin cu relaia:
RJ
BJ
efj
C
E
k =
n care:
E
BJ
- efectele obinute ca urmare a funcionrii sistemului (subsistemului J);
C
RJ
- cheltuieli de realizare a sistemului (subsistemului J).
2. Termenul de recuperare a cheltuielilor totale cu realizarea unui subsistem informatic
(T
rj
) sau a sistemului informatic n ansamblu, care se exprim n ani i se determin astfel:
(ani)
1
BJ
RJ
efj
rj
E
C
k
T = =
3. Coeficientul eficienei comparate (k
ecomp
), calculat astfel:
1 2
1 2
R R
B B
ecomp
C C
E E
k

=
n care:
E
B2
, E
B1
- efectele obinute n varianta de sistem informatic care presupune investiie
suplimentar, respectiv n varianta cu care se compar;
C
R2
, C
R1
- cheltuielile cu realizarea variantei de sistem informatic care necesit investiii
suplimentare, respectiv cheltuielile cu realizarea variantei cu care se compar.
4. Termenul de recuperare a investiiei suplimentare (T
rs
), exprimat n ani, care se
determin cu relaia:
1 2
1 2 1
B B
R R
ecomp
rs
E E
C C
k
T

= = (ani)


4.7.2. Managementul calitii sistemelor informatice

n aprecierea calitii unui sistem informatic trebuie pornit de la realitatea evident c
sistemul este construit pentru client. Premisa de baz a calitii sistemului informatic este aceea
c ea trebuie abordat sistemic, ncepnd cu fundamentarea deciziei de realizare a unui nou
sistem, continund cu organizarea i conducerea realizrii sistemului, cu implementarea acestuia,
pentru ca n final s putem aprecia calitativ funcionarea efectiv a sistemului informatic.
Calitatea unui sistem informatic se poate privi din dou puncte de vedere:
- pe de o parte, din punctul de vedere al utilizatorilor sistemului (aspectul funcional);
155
- pe de alt parte, din punctul de vedere al celor ce au realizat sistemul (aspectul
tehnic).
Din punct de vedere funcional, ceea ce pare tehnic raional i corect poate s fie
nefolositor utilizatorului.
Aspectul tehnic pornete de la premisa c, date fiind condiiile dintr-o economie
concurenial, realizatorul unui sistem informatic trebuie s aleag cele mai noi, cele mai
performante soluii.
Absolutizarea unuia sau altuia dintre cele dou aspecte poate s creeze serioase greuti n
exploatarea sistemului informatic. Trebuie avut n vedere c sistemele informatice economice
sunt create de oamenii pentru a fi utilizate n organizaii de ctre oameni.
n literatura de specialitate se remarc existena a dou concepii cu privire la calitate:
- una orientat tehnic ctre producie, care cerceteaz existena unor abateri ale
caracteristicilor produsului realizat fa de nivelurile prevzute n documentaia tehnic ntocmit
nainte de nceperea realizrii produsului;
- una orientat funcional ctre utilizator, care consider calitatea ca fiind aptitudinea unui
produs sau a unui serviciu de a satisface nevoile utilizatorului.
Problema calitii materialelor (echipamentelor) utilizate este o problem clasic de management
al calitii industriale, n timp ce problema elementelor logice este specific domeniului. Norma
ISO 9126 a enunat ase caracteristici care permit descrierea calitii unui sistem informatic:
- Capacitatea funcional care cerceteaz dac funciile pe care sistemul le realizeaz
corespund nevoilor explicite sau implicite. Ea este descompus n cerinele: operabilitate,
conformitate cu regulamentele, respect fa de norme etc.
- Facilitatea n utilizare este definit n raport cu ansamblul utilizatorilor poteniali i se
refer la efortul depus pentru a utiliza sistemul. Poate fi descompus n faciliti de
comprehensiune, de iniiere, de exploatare etc.
- Fiabilitatea este capacitatea sistemului de a-i menine, n condiiile specifice
utilizatorului, parametrii de performane pe toat perioada de exploatare stabilit i se
descompune n: maturitate, toleran la erori, posibiliti de recuperare etc.
- Randamentul (eficiena cerceteaz raportul ntre serviciile oferite de sistem (efectele
sistemului) i resursele utilizate ntr-un cadru dat.
- Mentenabilitatea care se refer la eforturile necesare pentru a menine i dezvolta
sistemul, respectiv la posibilitile de a aduce corecii sau ameliorri funcionale ulterioare, de a
efectua schimbri organizaionale sau de documentaie etc. Este descompus n: faciliti de
analiz, modularitate, stabilitate, facilitai de testare etc.
- Portabilitatea definit ca fiind capacitatea sistemului informatic de a fi transferat pe un
mediu tehnologic diferit din punct de vedere fizic sau logic. Aceast caracteristic este
descompus n faciliti de instalare i faciliti de adaptare.
Pentru perfecionarea sistemelor informatice, pe lng aprecierile fcute de specialiti n
urma unei analize temeinice este nevoie i de un sistem de indicatori care s permit estimarea
calitii. Pentru aceasta, se pot avea n vedere urmtorii indicatori:
- numrul de erori detectate n faza de implementare;
- numrul de erori detectate n exploatare;
- media gravitii erorilor detectate
- intervalul mediu de timp necesar pentru remedierea unei erori:
- timpul mediu de acces la informaii
- continuitatea n funcionare
- numrul informaiilor eronate rezultate din sistem,
- numrul cererilor clienilor pentru care sistemul nu a fost capabil s dea un rspuns,
- timpul mediu necesar utilizatorilor pentru a nva s lucreze cu sistemul,
- numrul comenzilor pe care utilizatorul trebuie s le rein etc.


156
CAP.5. PROGRAMARE N INTERNET


5.1. INTERNET I WEB. ARHITECTURI DE SISTEME DISTRIBUITE

5.1.1. Noiuni generale

Cea mai rspndit reea public este Internet-ul. Internet-ul poate fi descris ca un sistem
deschis, adica un sistem a carei arhitectura nu este secreta (producatorii sai i-au facut publica
structura suficient de detaliat astfel ncat alti dezvoltatori sa-i poata interfata la el propriile
produse). Cteva exemple de sisteme deschise sunt: sistemul de operare UNIX i utilitarele
asociate, protocoalele retelei Internet. Putem considera ca sistemele deschise au inspirat de
asemenea tehnologiile bazate pe Java i XML. Exemple de sisteme proprietare sunt: sistemele
Microsoft Windows i Mac OS cu utilitarele aferente.
Internet-ul are o arhitectur multinivel, inspirat de modelul de referin ISO/OSI.
n 1990 Tim Berners Lee a creat World Wide Web (WWW, WEB sau W3). Acesta a
propus:
O metod de a atasa nume simbolice calculatoarelor din Internet
O metod de reprezenta documentele cu legaturi simbolice ntre ele (HTML)
Conceptele de server WEB pentru stocarea acestor documente i navigator (engl.browser)
pentru afisarea acestor documente.
Internet-ul este o rtea de sub-reele. Sub-reelele comunic ntre ele printr-un nod special
numit gateway.
Protocoale ale retelei Internet:
Telnet protocol ce permite accesul la distanta la un calculator conectat la Internet, cu
conditia ca utilizatorul sa aiba drept de acces la calculatorul respectiv
FTP i TFTP protocoale de transfer de fisiere ntre calculatoare
SMTP protocol pentru transferul postei electronice ntre calculatoare
Kerberos protocol pentru transferul confidential de date ntre calculatoare
SNMP protocol pentru monitorizarea i administrarea retelelor de calculatoare
DNS protocolul care permite denumirea simbolica a calculatoarelor conectate la Internet
NFS colectie de protocoale care permite accesul transparent la fisierele i directoarele dintr-
o retea de calculatoare
TCP protocol orientat pe conexiune ce permite transferul sigur i fiabil al datelor ntre
procesele aplicatiilor ce ruleaza pe calculatoare conectate la Internet
UDP protocol neorientat pe conexiune cu funcie oarecum similara cu TCP, doar ca nu
garanteaza transferul sigur al datelor
IP protocol ce asigura transferul pachetelor ntre calculatoarele conectate la Internet
ICMP protocolul de transfer a informaiilor de comanda i eroare ntre componentele retelei
ARP i RARP protocoale ce asigura corespondenta directa i inversa ntre adresele hardware
i adresele Internet ale calculatoarelor conectate la Internet
157

Adresarea n Internet
Principala funcie a Internet-ului este schimbul de date ntre calculatoare. Pentru aceasta,
fiecare calculator din Internet are asignata o adresa IP.
Versiunea cea mai raspindita la ora actuala a protocolului IP este IPv4. n IPv4 adresa
unui calculator este un sir de 32 de biti. Acest sir se reprezinta sub forma unui 4-uplu format din
4 octeti, separati prin cate un punct. Exemplu: 151.23.40.3. Exista i versiunea IPv6 care
foloseste 128 de biti. Multimea de adrese IP este impartita n 5 clase:
Clasa A, 0 adresa retea (7) adresa calculator (24)
Clasa B, 10 adresa retea (14) adresa calculator (16)
Clasa C, 110 adresa retea (21) adresa calculator (8)
Clasa D, 1110 adresa multicast (28)
Clasa E
Adresa 127.0.0.1 se mai numete i adres de loopback. Datele trimise aici se ntorc
napoi la sursa. Aceasta este util pentru testarea aplicatiilor de retea folosind un singur
calculator.
Adresele IP sunt dificil de memorat n format numeric, de aceea s-a introdus o metoda de
a le atasa nume simbolice prin sistemul de numire a domeniilor (engl.domain name system
DNS). DNS reprezint o modalitate de a denumi simbolic calculatoarele dintr-o retea bazata pe
TCP/IP (Internet) folosind o schema de denumire ierarhica. Fiecare sufix dintr-un nume se
numeste domeniu. Determinarea adresei IP pornind de la nume se face prin interogarea unui
server de nume (engl.name server). DNS reprezint multimea tuturor acestor servere.

Clieni i servere
Un server este un calculator (program n executie) din cadrul unei retele care furnizeaza
servicii altor calculatoare (programe n executie) din cadrul retelei. Un client este un calculator
(program n executie) dintr-o retea care beneficiaza de serviciile unui calculator (sau program)
server.
n Internet, comunicarea ntre un client (program) i un server (program) se face folosind
suita de protocoale TCP/IP. Aceasta se bazeaza pe notiunile de port i soclu (engl.socket). Un
port reprezint un canal abstract prin care un calculator (program care ruleaza pe calculator)
poate comunica cu exteriorul. Un port este identificat printr-un numar. Porturile care aparin
intervalului 01023 sunt rezervate pentru servicii speciale. Cateva dintre acestea sunt:
Port 7: ECHO
Port 21: FTP
Port 23: Telnet
Port 80: HTTP
Port 25: SMTP
Port 110 :POP3
Port 150 :SQL-NET
Un soclu este o pereche formata dintr-o adresa de IP i un port. Un soclu abstractizeaza
notiunea de canal de comunicatie ntr-o retea bazata pe TCP/IP, usurand astfel programarea.

Tipuri de servere
Servere de fisiere. Furnizeaza fisiere la cererea clientului; spre exemplu un depozit de
documente (engl.document repository).
Servere de baze de date. Stocheaza colectii mari de date structurate sub forma unor baze de
date; furnizeaza servicii de interogare a acestora folosind SQL.
Servere de groupware. Groupware = un sistem care permite unui grup de participanti sa
lucreze impreuna ntr-un mediu partajat.
158
Servere WWW. Sunt servere de fisiere care conin componentele unui site din WWW.
Accesul la ele se face printr-un program client special numit navigator.
Servere de posta electronica. Permit receptia, stoarea i trimiterea de mesaje prin posta
electronica.
Servere de obiecte. Stocheaza obiecte i permit programelor client sa trimita mesaje acestor
obiecte.
Servere de imprimare. Furnizeaza clientilor servicii de imprimare.
Servere de aplicatii. Sunt servere dedicate uneia sau mai multor aplicatii particulare i conin
programele dedicate aplicatiei respective.

5.1.2. World Wide Web

WWW este un sistem hipermedia distribuit. Se bazeaza pe un model de structurare a
documentelor care foloseste trei concepte:
Multimedia se refera la integrarea mai multor tipuri de media n cadrul aceluiasi model
de document: text, grafica, imagine, video, etc.
Hiperdocument se refera la crearea de legaturi ntre documente, folosind un mecanism
propriu modelului de document.
Documente distribuite se refera la documente care conin legaturi la documente stocate
pe alte calculatoare din cadrul unei retele.
Se spune ca WWW foloseste un model de documente hipermedia distribuite. Termenul
de hipermedia nglobeaza conceptele de multimedia i hiperdocument.
Fiecare autor care creeaza o resursa informaionala (engl.informaion resource) n WWW
o considera ca fiind un document separat. nsa putem considera ca, la nivel global, multimea
tuturor resurselor informaionale din WWW formeaza un unic document hipermedia distribuit.
Din acest punct de vedere, termenul de resursa informaionala este mai potrivit decat cel de
document. Exista trei nivele de distribuire a resurselor informaionale n WWW: acelasi fisier,
fisiere separate pe acelasi calculator, calculatoare diferite.
Desi WWW a aparut n 1990, conceptele de baza au ramas aceleasi pana astazi: URL
(denumirea unui document), HTTP (regasirea unui document) i HTML (descrierea coninutului
unui document).
Arhitectura WWW este o arhitectura client/server tipica i anume:
Un server WWW are sarcina de a gestiona o multime de documente din cadrul WWW.
Aceste documente se numesc i pagini WWW.
Un client generic de WWW este un program care emite cereri ctre un server WWW
pentru accesarea paginilor WWW gestionate de acel server. Exemple de clienti sunt:
Un navigator WWW care permite regasirea i afisarea paginilor WWW n scopul
vizualizarii coninutului lor de ctre un agent uman.
Un program de tip softbot care localizeaza diverse pagini WWW n scopul crearii unui
index. Indexul poate fi utilizat ulterior de un motor de cautare.
Conceptele pe care se bazeaza tehnologia WWW sunt:
Schema de denumire a resurselor (engl.uniform resource locator) URL
Protocolul de transfer al documentelor (engl.hypertext transfer protocol) HTTP
Limbajul de specificare a coninutului paginilor WWW (engl.hypertext markup language)
HTML
Pentru identificarea resurselor n WWW se foloseste un URL (engl.Uniform Resource
Locator). Un URL este un identificator simbolic al resursei i este compus din doua parti:
Schema, care indica modalitatea folosita pentru denumirea resurselor. Spre exemplu,
schema poate fi numele unui proocol: ftp, http, etc
Partea specifica schemei, care indica cum se adreseaza resursa n cadrul schemei
respective
159
Sintaxa URL este schema : parte-specifica-schemei. Partea specifica schemei are
sintaxa // [utilizator [: parola] @ ] gazda [ : port] / cale
utilizator i parola sunt optionale i se aplica doar cu schemele care au sens (de exemplu
ftp).
gazda indica numele calculatorului pe care se afla resursa, sau adresa de IP a acestuia.
port reprezinta numarul portului pe care se face conexiunea. Este optional, deoarece acest
numar este predefinit pentru serviciile standard. Pentru HTTP portul predefinit este 80.
cale reprezinta calea de acces la resursa n cadrul calculatorului specificat. n general este
o cale fizica existenta n sistemul de fisiere de pe calculatorul gazda.
Exemple de aplicatii WWW:
Furnizarea de adrese de email anonime pentru trimiterea de spam. Termenul de spam se refera
la trimiterea de mesaje de email cu anunuturi unor receptori ce nu au solicitat primirea
mesajelor respective. Spam-ul este detestat de toti utilizatorii de Internet.
Site-uri de verificare automata a validitatii/actualitatii unor legaturi WWW.
Site-uri de arhivare pentru stocarea sigura de fisiere.
Site-uri care furnizeaza adrese de email gratuite. Sunt utile pentru utilizatorii mobili.
Motoare de cautare (eng.search engines). Cautarea se face ntr-o baza de date uriasa care
conine informaii despre documentele din WWW, organizate sub forma unui index.
Specificarea cautarii se face printr-o interogare (engl.query). Baza de date este construita cu
ajutorul unui program special numit spider (un client special de HTTP) care navigheaza
automat pe WWW i stocheaza n indexul local informaiile relvante gasite. Spamdexing este
o tehnica folosita de unele site-uri pentru a fi gasite ca relevante la cautarea unor cuvinte cheie
raspandite.
Grupuri de utilizatori interesati de un subiect comun newsgroup i mailing list.
Aplicatii de comert electronic

5.1.3. Protocolul HTTP

HTTP este protocolul de comunicare ntre clientii i serverele WWW. El specifica
cererile care pot fi adresate de clienti i raspunsurile care pot fi generate de servere. Specificatia
conine structura i formatul (sintaxa) acestora.
Cererile i raspunsurile HTTP se mai numesc i mesaje. Un mesaj este un sir de caractere
ce conine: linia de start (engl.start line), zero sau mai multe campuri antet (engl.message
header field) i optional un camp corp (engl.message body field).
Antetele unui mesaj pot fi: antete generale (engl.general header) se refera la mesaj, nu la
entitatea transmisa; antete de entitate (engl.entity header) se refera la entitatea transmisa sau
referita; antete raspuns (engl.response header) serverul comunica clientului informaii care nu
au fost incluse in linia de start.
Cereri Linia de start se numeste linie de cerere (engl.request line) i are structura:
metoda spatiu url_resursa spatiu versiune_http sfarsit_linie
Raspunsuri Linia de start se numeste linie de stare (engl.status line).
Referitor la sintaxa formala a unei cereri HTTP, trebuie precizate urmatoarele:
HTTP 1.0 este descris la nivel informaiv n documentul RFC 1945.
HTTP 1.1 este descris n propunerea de standard RFC 2068.
O cerere HTTP are structura urmatoare ([...] specifica un element optional i * specifica 0
sau mai multe repetitii ale unui element):
cerere =
160
linie-de-cerere
(antet-general | antet-cerere | antet-entitate)*
sfarsit-de-linie
[corp-mesaj]
linie-de-cerere = metoda spatiu uri spatiu versiune-http sfarsit-de-linie
metoda =OPTIONS | GET | HEAD | POST | PUT | DELETE |
TRACE | CONNECT | metoda-extensie
uri = * | uri-absolut | cale-absoluta

Un raspuns HTTP are structura urmatoare:

raspuns =
linie-de-stare
(antet-general | antet-raspuns | antet-entitate)*
sfarsit-de-linie
[corp-mesaj]
linie-de-stare = versiune-http spatiu cod-stare spatiu fraza-motiv sfarsit-de-linie
cod-stare = cod-succes | redirectare |
eroare-client | eroare-server | ...
cod-succes = ok | creat | acceptat | ...
ok = 200
creat = 201
acceptat = 202
redirectare = mutat-permanent | mutat-temporar | ...
mutat-permanent = 301
mutat-temporar = 302
eroare-client = cerere-gresita | neautorizat | plata-necesara | interzis |
resursa-inexistenta | metoda-nepermisa | ...
cerere-gresita = 400
neautorizat = 401
plata-necesara = 402
interzis = 403
resursa-inexistenta = 404
metoda-nepermisa = 405
eroare-server = eroare-interna | nu-este-implementata | ...
eroare-interna = 500
nu-este-implementata = 501
161
Cookies

HTTP este un protocol fara stare (engl.stateless). Acest lucru nseamna ca HTTP nu
dispune de un mecanism propriu care sa permita unui server WWW sa poata pastra informaii
despre starea utilizatorului. Termenul de cookie se refera la mecanismul prin care o aplicatie
WWW pe partea de server poate stoca i regasi informaii pe partea de client. El permite
adaugarea adaugarea unei stari a conexiunii stocata la client. Serverul specifica clientului ca vrea
sa stocheze un cookie prin antetul Set-Cookie, n maniera urmatoare:
Set-Cookie: Nume=Valoare
Ulterior, clientul va include cookie-ul ntr-un antet al unei cereri sub forma:
Cookie: Nume=Valoare
Suplimentar, antetul Set-Cookie mai poate conine urmatoarele informaii:
domain: specifica domeniul n care se aplica cookie-ul
expires: specifica data de expirare a cookie-ului
path: specifica URL-urile la care clientul va returna cookie-ul n cererea HTTP
secure: specifica faptul ca cookie-ul va fi returnat de client numai dac conexiunea este
sigura.
Ex: Set-Cookie: Credit=111; secure; expires=Thursday, 07-Dec-2000, 10:00:00 GMT;
domains=.comp-craiova.ro; path=/
Relativ la trimiterea de date ctre un server WWW, trebuie precizat ca :
Paginile de WWW pot fi statice i dinamice. Paginile statice sunt stocate explicit pe server i
returnate clientilor ca raspuns la cereri GET. Paginile dinamice sunt generate dinamic de
server, nefiind stocate explicit. Este posibil ca aceste pagini sa fie configurate pe baza unor
date trimise de la client ctre server. Astfel de date pot fi de exemplu criterii de cautare ntr-o
baza de date, paginile generate dinamic fiind n acest caz rapoartele rezultate n urma cautarii.
Exista doua metode de a transmite date de la client la server:
Folosind metoda GET, datele sunt atasate URL-ului sub forma unor perechi variabila-
valoare. n acest caz URL-ul reprezinta un program aflat pe server i datele sunt transmise
acestui program n mediul sau de executie (engl.environment). La URL se adauga un sir de
forma:
?nume
1
=valoare
1
&nume
2
=valoare
2
& &nume
n
=valoare
n
Un este codificat prin + i un caracter special printr-un cod hexa precedat de %. Ex.
?cale=%2Fweb%2 semnifica valoarea /web/ pentru variabila cale.
Folosind metoda POST, datele sunt atasate n corpul cererii, spre deosebire de cazul
anterior, unde sunt atasate URL-ului, n antet. Ele sunt transmise programului prin intrarea
standard.
Serverul preia datele de la programul invocat prin iesirea standard i le trimite apoi clientului.
Aceasta tehnica de a extinde funcionalitatea unui server WWW pentru generarea dinamica de
pagini se numeste Common Gateway Interface (CGI).





162
Middleware

Middleware este un term destul de vag ce se refera n general la toate nivelurile software
intermediare care sprijina comunicatia dintre un client i un server.
Un middleware furnizeaza un set standard de interfete pentru o colectie de resurse
distribuite disparate, eterogene i proprietare. Astfel dezvoltatorii isi vor interfata aplicatiile cu
partea de middleware n loc de interfetele de nivel coborat ale resurselor proprietare. Un exemplu
de middleware este software-ul care interfateaza un program navigator de sistemul WWW.
O tehnologie foarte raspandita este middleware-ul orientat pe mesaje MOM
(engl.message-oriented middleware). MOM gestioneaza tranzactiile dintre un client i un server
prin intermediul unor cozi care stocheaza mesajele transmise ntre clienti i serveri.
Un exemplu de MOM este WebSphere MQ dezvoltat de IBM (fost MQSeries).
WebSphere MQ gestioneaza transferul de mesaje ntre clienti i serveri i stie sa prelucreze patru
tipuri de mesaje: datagrame mesaje unidirectionale, mesaje de cerere, mesaje de raspuns i
mesaje de raportare. WebSphere MQ este un lider n domeniul platformelor middleware pentru
integrarea aplicatiilor de e-business.

5.1.4. Arhitecturi multistrat (engl.tiered architectures)

O aplicatie distribuita este compusa dintr-o multime de programe care ruleaza pe mai
multe calculatoare conectate n retea. O schita a acestor programe impreuna cu calculatoarele
(engl.hosts) pe care ruleaza, responsabilitatile lor i protocoalele prin care comunica se numeste
arhitectura distribuita.
O clasificare a arhitecturilor distribuite se bazeaza pe conceptul de strat (engl.tier). Un
strat poate fi un calculator (nsa putem avea aplicatii distribuite virtual care ruleaza pe un acelasi
calculator) sau o partitie logica de prelucrare din cadrul aplicatiei. De obicei un strat corespunde
unui client sau server.
Avantaj: paradigmele de codificare sunt diferite de la strat la strat astfel ca straturi
diferite cer ndemanari de programare diferite
Partitionarea logica a unei aplicatii distribuite trebuie sa aiba n vedere cel putin
urmatoarele trei elemente:
Logica de prezentare
Logica problemei (engl.business logic)
Logica datelor, responsabila cu persistenta datelor, controlul accesului concurent,
corectitudinea tranzactiilor, etc
Avantaj: straturile permit separarea elementelor enumerate mai sus

Clasificarea arhitecturilor multistrat:
1 strat (engl.one tier)
Este simpla deoarece nu exista conectare n retea
Performante bune, deoarece nu exista comunicatii n retea
Sistemul este autoconinut
Nu exista posibilitatea accesului de servicii la distanta
Arhitectura monolitica, deci potential de cod spaghetti
2 straturi (engl.two tiers)
Straturi: client i server de WWW, arhitectura oarecum simpla
Separa logicii de prezentare de logica problemei
Potential mic pentru partajarea resurselor, o problema n comertul electronic
3 straturi (engl.three tiers)
Straturi: client, server de WWW, server de baze de date
Separa logica de prezentare, logica problemei i logica datelor
Necesita expertiza n plus, maparea obiectual-relational este destul de dificila
163
4 straturi (engl.four tiers)
Straturi: client, server WWW, server de aplicatii, server de baze de date
Flexibilitate ridicata, practic poate realiza orice
Nivel de expertiza foarte nalt, curba de nvatare mare, cost foarte ridicat, poate fi
ineficienta datorita generalitatii
Partea dintre logica de prezentare (client) i logica datelor (baza de date) se mai
numeste i strat intermediar (engl.middle layer). El conine printre altele obiectele
problemei (engl.business objects), ce corespund entitatilor din domeniul problemei
Putem avea i arhitecturi cu n > 4 straturi (engl.n-tiers). Cu cat numarul de straturi este
mai mare, cu atat performantele pot sa scada, implementarea este mai dificila i cere expertiza
mai mare, complexitatea sistemului este mai mare, costul total al sistemului creste. n consecinta,
stabilirea numarului de straturi trebuie facuta cu grija, n funcie de cerintele reale ale aplicatiei.
Cel mai adesea o arhitectura n 3 straturi este suficienta. Serverele de aplicatii sunt n general
foarte scumpe i curba de nvatare este foarte lenta.

5.1.5. Paradigme de programare distribuita

1. Modelul transferului de mesaje:
Se bazeaza pe ideea de protocol. Acesta poate fi gandit ca un limbaj ce ntruchipeaza funciile
cerute de un client i pe care le furnizeaza un server.
Protocoalele se impart n:
Protocoale fixe, al caror vocabular este fixat i incapsulat n codul serverului i clientului.
Protocoale adaptive, care se pot schimba la momentul executiei
Un exemplu de protocol fix este cel pentru comunicarea cu un server de nume:
Partea de client: CAUTA Nume, STERGE Nume, ADAUGA Nume, Resursa, MODIFICA
Nume, Resursa
Partea de server: RESURSA Detalii, STERGE OK, ADAUGA OK, MODIFICA OK,
EROARE Cod
O metoda de a implementa protocoalele adaptive este folosirea obiectelor serializabile.
Acestea sunt obiecte care pot fi transferate n retea sub forma de date. Un astfel de obiect
poate conine funcionalitatea unei noi comenzi din cadrul protocolului.
n cadrul acestui model clientii i serverii comunica prin transfer de mesaje de-a lungul unor
canale de comunicatie. Corespunde oarecum cu structura retelei n care ruleaza clientii i
serverii. Scopul acestui model este de a abstractiza detaliile de nivel coborat i de a face astfel
programarea aplicatiilor mai usoara.
Se preteaza n urmatoarele situatii:
Cerintele de comunicare sunt foarte simple
Sunt necesare performante foarte bune; acest model este cel mai eficient dintre modele
discutate; plata pentru aceasta eficienta este cresterea complexitatii programarii
Exemplu: HTTP, protocolul de comunicare cu un server de WWW
Exista doua clase:
Transfer sincron de mesaje: entiatea A trimite un mesaj ctre entitatea B, n timp ce
entitatea B prelucreaza mesajul, entitatea A se opreste i asteapta un raspuns, dup ce
entitatea B raspunde entitatea A isi coninua activitatea
Transfer asincron de mesaje: entiatea A trimite un mesaj ctre entitatea B, in timp ce
entitatea B prelucreaza mesajul, entitatea A isi coninua activitatea, cand entiatea B
raspunde, entitatea A poate prelua mesajul.
2. Modelul obiectelor distribuite:
Se numeste obiect distribuit un obiect rezident pe un calculator care poate fi invocat de
obiecte rezidente pe alte calculatoare astfel ncat, dpdv al programatorului, obiectele sa para a
164
fi situate pe un acelasi calculator (adica toate detaliile de comunicare sa fie ascunse
programatorului).
Tehnologia obiectelor distribuite presupune urmatoarele:
Interceptarea apelurilor ctre obiecte
Localizarea obiectelor
Comunicarea mesajelor i parametrilor ctre aceste obiecte
Optional, returnarea eventualelor rezultate i transmiterea lor obiectului apelant
Avantaj: obiectele distribuite corespund 100% modelului orientat pe obiect i din acest motiv
trecerea de la proiectare la implementare este usoara
Dezavantaj: performantele tehnologiilor de obiecte distribuite sunt inferioare tehnologiilor de
transfer de mesaje
Exemple
CORBA, propus de OMG
Apelul metodelor la distanta (engl.Remote Method Invocation) Java RMI
DCOM, propus de Microsoft

3. Modelul evenimentelor:
Acest model presupune asocierea unor portiuni de cod cu anumite evenimente. Codul va fi
executat automat la declansarea evenimentelor respective.
Acest model de programare este foarte raspandit n programarea interfetelor grafice.
Dezvoltarea unei astfel de interfete presupune urmatoarele:
Controale grafice, spre exemplu butoane, sunt plasate ntr-un container de tip fereastra
principala, numita i cadru (engl.frame)
Fereastra cadru implementeaza o interfata prin intermediul careia va fi invocata la
declansarea unor evenimente. Codul de tratare a evenimentelor va fi amplasat n metodele
ce implementeaza aceasta interfata.
Fereastra cadru se nregistreaza la controalele grafice ca obiect ascultator (engl.listener),
ceea ce semnifica faptul ca este interesata de a fi informata la declansarea anumitor
evenimente.
La declansarea unui eveniment, controlul grafic informeaza toate obiectele ascultator
nregistrate la el.

Magistrala de obiecte:
Modelul evenimentelor este folosit i n arhitecturile de tip magistrala de obiecte (engl.object
bus)
ntr-o magistrala de obiecte, serverele imping datele ctre clienti, din acest motiv folosindu-se
i terminologia push tehnology. Spre deosebire de aceasta, n obiectele distribuite clientii
extrag datele de la serveri, folosindu-se terminologia pull technology.
n magistrala de obiecte, transmitatorul este server i ascultatorii sunt clienti.
Arhitectura magistrala de obiecte este utila n aplicatiile n care evenimentele se declanseaza
n timp real iar multimea de ascultatori se poate schimba dinamic. Exemple:
Furnizarea de date despre piata de capital institutiilor financiare interesate
Teleconferinte sau aplicatii conversationale (engl.chat room), unde mesajele ntre
participanti se transmit n timp real
Aplicatii multimedia distribuite de tip video la cerere (engl.video on demand), unde un
mare volum de date trebuie transmis n timp real abonatilor
Exista doua mari clase de arhitecturi de tip magistrala de obiecte:
Arhitectura butuc i spite (engl.hub and spoke)
Magistrala cu multitransmisie (engl.multicast bus architecture)
165
Arhitectura butuc i spite:
Transmitatorul trimite date ctre dispecer (butuc), iar acesta le distribuie ascultatorilor
nregistrati. Poate exista cate un dispecer pe canal sau un singur dispecer pentru toate canalele.
Avantaje: usor de implementat folosind socket-ui sau RMI, contabilizarea poate fi centralizata
la dispecer
Dezavantaje: se genereaza un volum mare de trafic comparativ cu magistralele cu
multitransimise, fiabilitate scazuta deoarece totul depinde de dispecer
















Magistrala cu multitransmisie:
Tehnica multitransmisiei permite transferul unui singur mesaj de la transmitator ctre mai
multi receptori.
Mesajul este transmis pe o magistrala, de unde este preluat de toti ascultatorii interesati;
ascultatorii sunt activati printr-un eveniment care ii informeaza ca mesajul este disponibil pe
magistrala.
Un exemplu este iBus de la SoftWired Ltd care poate fi gandita ca un fel de implementare
software a protocolului Ethernet. Astfel mesajele vor fi preluate numai de destinatarii
interesati; dac mesajul nu este necesar este pur i simplu ignorat i lasat sa treaca urmatorului
destinatar conectat la magistrala.
4.Modelul tuplelor:

A fost folosit n limbajul de programare de nivel nalt Linda, dezvoltat de cercetatorii
americani Nicolas Carriero and David Gelerntner n 1980. Acesta a fost raspandit doar n
mediul academic. Firma Sun s-a inspirat din el in 1990 pentru a dezvolta tehnologia
JavaSpaces ca parte a proiectului JINI. JINI este o arhitectura deschisa pentru interconectarea
n retea a unei multimi de servicii implementate soft sau hard i care poate fi reconfigurabila
dinamic, iar JavaSpaces este modelul de programare distribuita folosit n JINI.
In JavaSpaces procesele comunica prin intermediul unor zone partajate numite spatii
(engl.spaces). Clientii pot accesa aceste spatii prin 3 operatii:
write, pentru adaugarea unui nou obiect la un spatiu
take, pentru citirea unui obiect i eliminarea sa dintr-un spatiu
read, pentru crearea unei copii a unui obiect dintr-un spatiu
Spatiile sunt containere de obiecte cu urmatoarele proprietati:
Sunt partajate i pot fi accesate concurent
Sunt persistente
Transmitator
Dispecer
Ascultatori
166
Sunt asociative adica obiectele sunt localizate prin regasire asociativa Tranzactiile pe
aceste spatii sunt sigure
Spatiile permit schimbul de coninut executabil


5.2. PROGRAMARE PE PARTE DE CLIENT

Termenul de programare pe partea de client (engl.client side programming) se refera la
executarea de programe la client n scopul cresterii gradului de interactivitate al paginilor
WWW. Programele destinate a fi executate la client se pot transmite de la server ctre client fie
n format sursa, fie n format obiect.
Termenul de programare pe partea de server (engl.server-side programming) se refera la
executarea de programe la server n scopul de a genera date i/sau rapoarte care sunt trimise
clientului sau mai general, pentru extinderea funcionalitatii unui server de WWW. Datele i
rapoartele sunt trimise clientului de obicei n format HTML.


5.2.1. Limbajul HTML

Limbajul HTML reprezint Lingua franca pentru publicarea de hipertext n pagini
WWW. HTML este inspirat din SGML - un limbaj de meta-marcare (engl.meta-markup). n
esenta, acesta permite definirea de noi tipuri de documente printr-o definitie de tip de document
DTD. Unui tip ii corespunde un limbaj de marcare specific (ex. HTML), ce descrie coninutul i
structura unui document. Un document scris ntr-un limbaj de marcare conine:
Date = coninutul propriu-zis al documentului.
Marcaje = informaii referitoare la structura documentului. Se numesc i metadate.
Versiunea 4.0 defineste 3 tipuri de documente HTML:
Documente tranzitionale: acest tip se va folosi doar pentru verificarea documentelor
HTML, n nici un caz pentru generarea de noi documente. Astfel, elemente ca
BASEFONT, FONT, CENTER, S, STRIKE sau U sunt doar parte a documentelor
tranzitionale, folosite pentru formatare.
Documente stricte: acest tip nu include elementele prezente n documentele tranzitionale
pentru compatibilitate cu versiunile anterioare de HTML.
Documente tip colectii de pagini

Tipul de document se defineste printr-o definitie de tip (concept preluat din SGML).
Definitia de tip se specifica optional la nceputul unui document HTML astfel:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
http://www.w3c.org/TR/REC-html40/strict.dtd

Structura unui document HTML

Un document HTML conine date i marcaje (engl.tag). Marcajele conin informaia de
formatare, iar datele reprezinta coninutul efectiv al documentului. Marcajele sunt interpretate de
ctre programul navigator, ele determinand modul n care vor fi afisate datele. Marcajele pot fi:
marcaje de nceput (engl.start tag) i marcaje de sfarsit (engl.end tag).
167
Un marcaj de nceput poate conine optional atribute cu valori i se scrie astfel:
<marcaj atribut = valoare atribut = valoare >
Ex: <img src= logo.gif alt=home page >
Un marcaj de sfarsit se scrie astfel:
</marcaj>
Ex: </img>
Teoretic, marcajele trebuie nchise corect, exact ca parantezele dintr-o expresie
matematica. n practica nsa, deseori, marcajele de sfarsit se omit, ambiguitatile fiind rezolvate
prin metode ad-hoc de programul navigator. n principiu, un document HTML conine un antet
(engl.header) i un corp (engl.body) ntre marcajele <html> i </html>. html se numeste i
element radacina al documentului.
Elementele din corpul unui document HTML se clasifica n:
Elemente de nivel bloc (engl.block-level). Ex: P, H, UL, OL, PRE, TABLE, FORM
Elemente incluse (engl.inline). Ex: I, B, U, EM, STRONG, A, IMG
Diferenta ntre ele se bazeaza pe trei coordonate: coninut, formatare i directionalitate. Relativ la
coninut, trebuie menionate urmtoarele aspecte:
Un element de nivel bloc poate conine atat elemente incluse cat i elemente de nivel bloc.
Un element inclus poate conine numai elemente incluse i date.
Aceasta distinctie sugereaza ca elementele de nivel bloc pot crea structuri mai bogate decat
elementele incluse.
n privina formatrii, trebuie s se in cont c:
Elementele de nivel bloc sunt formatate ntotdeauna ncepand cu o linie noua, n timp ce
elementele incluse nu.
Elementele incluse pot fi despartite pe mai multe linii (la fel cum textul unui paragraf se
desparte n linii), n timp ce elementele de nivel bloc nu.
Directionalitatea se refera la directia n care este scris textul i se respect regula
urmtoare:
Elementele de nivel bloc mostenesc directionalitatea de la elementul cuprinzator, n timp
ce elementele incluse nu.
Un exemplu de document HTML este urmatorul :

<HTML>
<HEAD>
<TITLE> Un exemplu simplu de pagina WWW </TITLE>
</HEAD>
<BODY>
<H1> Amelia Badica despre HTML </H1>
Un document HTML conine:
<UL>
<LI> marcaje - marcajele pot fi:</LI>
<UL>
<LI>marcaje de inceput</LI>
<LI>marcaje de sfarsit</LI>
</UL>
<LI> date </LI>
</UL>
168
i este compus din:
<UL>
<LI> un antet </LI>
<LI> un corp </LI>
</UL>
</BODY>
</HTML>
Formatarea textului n HTML
Textul HTML poate fi simplu sau structurat.
Textul simplu este format din paragrafe (p), separate de linii libere (br) sau titluri
(engl.headings, h1, h2,, h6). Textul poate avea stiluri (ex. bold b, italic i, etc), fonturi (font,
basefont)
Textul structurat cuprinde liste i tabele.
- Listele sunt: liste neordonate (ul, li) cu elementele indicate cu simboluri nenumerice
(engl.bullet), liste ordonate (ol, li) cu elementele numerotate, i liste de definitii (dl, dd) cu
simbolurile elementelor definite de utilizator.
- Tabelele (table) permit structurarea textului n linii i coloane. n principiu un tabel
conine unul sau mai multe corpuri de tabel (engl.table body, tbody). Un corp de tabel
conine una sau mai multe linii (engl.row, tr). O linie este formata din celule. Acestea pot fi
celule antet (engl.header cell, th) sau celule de date (engl.data cell, td).
Pentru tabele exista i alte elemente i atribute optionale care specifica titlul tabelului
(caption), alinierea celulelor (align), stilul conturului (border), formatarea textului n celule, etc.
Spre exemplu stilul (grosimea) conturului se specifica astfel: <table border=1>.
Legaturi HTML
Legturile HTML se bazeaza pe folosirea de ancore (engl.anchor) cu ajutorul
elementului a. Exista doua tipuri de ancore: ancore sursa i ancore destinatie.
Ancorele sursa au forma
<a href=url>text</a>
i reprezinta originea unei legaturi. url reprezinta resursa destinatie a legaturii. text este textul
afisat in zona sensibila a legaturii.
Ancorele destinatie au forma
<a name=nume></a>
i reprezinta destinatia unei legaturi. Numele unei ancore destinatie poate fi specificat intr-o
ancora sursa prin #nume pe post de url. Ancorele destinatie se pot specifica i cu atributul id in
cadrul elementului referit, in acest caz numai fiind nevoie sa se foloseasca elementul a.
Documente HTML multifereastra
HTML 4.0 permite definirea de colectii de pagini (engl.frameset) pentru integrarea unei
multimi de documente intr-o aceeasi fereastra principala. Fiecare document va fi vizualizat intr-o
portiune a ferestrei principale.
Pentru definirea structurii multifereastra se foloseste un document HTML special numit
tipar (engl.frameset document) ce conine marcajele speciale frameset, frame i noframes
(optional). Celelalte documente ale colectiei sunt documente HTML obisnuite (engl.frame
document).
Documentul tipar specifica documentele care se incarca in fiecare fereastra. Dac aceste
169
documente conin legaturi spre alte documente, in cadrul acestor legaturi se poate specifica
fereastra destinatie prin atributul target. Numele ferestrelor se specifica cu atributul name in
marcajul frame.
Specificarea dimensiunii ferestrelor in documentul tipar se face cu atributele rows i cols.
Pentru fiecare fereastra se indica fie dimensiunea absoluta (numar), fie procentul din spatiul total
(procent) fie dimensiunea relativa (numar i *).
Se pot insera direct ferestre in cadrul unui document HTML obisnuit folosind marcajul
iframe. Ele se numesc i ferestre incluse (engl.inline frame).

Imagini in documentele HTML
Cele mai raspandite formate de imagini intalnite in WWW sunt Graphics Interchange
Format GIF, Joint Photographic Experts Group JPEG i Portable Network Graphics PNG.
Ele se folosesc pentru stocarea imaginilor in forma compresata. De remarcat ca HTML nu
specifica tipul de format al imaginilor. Acesta este tratat exclusiv de programul navigator,
imaginile fiind dpdv al HTML doar date externe.
Pentru includerea imaginilor in paginile WWW se foloseste marcajul IMG. Atributele:
SRC pentru specificarea fisierului care conine imaginea, ALIGN (cu valorile left, right, top,
middle sau bottom) pentru specificarea tipului de aliniere, ALT pentru specificarea unei descrieri
textuale a imaginii, BORDER pentru specificarea grosimii marginii imaginii, HEIGHT i
WIDTH pentru specificarea inaltimii i largimii imaginii in numar de pixeli, etc.
Exemplu:
<IMG SRC="sunset.jpg" HEIGHT="300" WIDTH="400" ALT="Apus"/>
Pentru crearea de legaturi intre imagini sau portiuni de imagini i actiuni sau resurse se
folosesc hartile de imagini (engl.image map). Actiunile sunt portiuni de cod scripting iar
resursele se specifica prin URL. Hartile de imagini se pot rezolva la server sau la client.
Rezolvarea presupune gasirea resursei sau actiunii corespunzatoare imaginii sau portiunii de
imagine care a fost selectata. Asocierea unei imagini cu o harta se face cu atributul USEMAP
pentru rezolvarea la client i cu atributul ISMAP pentru rezolvarea la server.

Formulare HTML i comunicare HTTP
Interactiunea dintre CGI i formularele HTML se face astfel:
Formularele (engl.form) furnizeaza paginilor WWW suport pentru interactivitate. Ele se
specifica cu elementul form. Acesta accepta atribute ca: action pentru a indica programul de
prelucrare a datelor formularului, method pentru specificarea metodei HTTP folosita pentru
transferul datelor ctre server (GET sau POST), target pentru a specifica fereastra care conine
formularul, etc.
In interiorul elementului form se introduc elemente pentru descrierea controalelor de
interactivitate. Acestea pot fi:
input, un element general cu tipul descris prin atributul type. Acesta poate fi: text pentru o
caseta de editare, password pentru o caseta de editare a unei parole, checkbox pentru o
caseta de validare, radio pentru un buton de selectie exclusiva (engl.radio button), submit
pentru un buton de trimitere a datelor ctre server, etc.
select, pentru definirea unui meniu. Optiunile meniului se descriu cu elementele option i
optgroup. Meniul poate fi cu selectie simpla sau multipla (multiple)
textarea, pentru definirea unei camp de editare multilinie.
Pentru vizualizarea datelor trimise ctre server se va implementa formularul folosind metoda
GET i se va vizualiza URL-ul generat in campul de adresa al navigatorului WWW.

170
5.2.2. Tehnologii DynamicHTML

Termenul de programare pe partea de client (engl.client side programming) se refera la
executarea de programe la client in scopul cresterii gradului de interactivitate al paginilor
WWW. Programele destinate a fi executate la client se pot transmite de la server ctre client fie
in format sursa, fie in format obiect.
Termenul de programare pe partea de server (engl.server-side programming) se refera la
executarea de programe la server in scopul de a genera date i/sau rapoarte care sunt trimise
clientului sau mai general, pentru extinderea funcionalitatii unui server de WWW. Datele i
rapoartele sunt trimise clientului de obicei in format HTML.
Termenul Dynamic HTML DHTML nu se refera la o anumita versiune sau facilitate a
HTML. El desemneaza acele facilitati din diversele variante sau extensii ale HTML care ajuta la
crearea de coninut dinamic.
Cele mai populare elemente ale DHTML sunt:
Foile de stil (engl.Cascading Style Sheets - CSS).
Scripting-ul la client (elementul SCRIPT). Un exemplu este JavaScript. Se refera la
incorporarea in cadrul unei pagini a unor programe in format sursa. Ele vor fi executate la
client.
Obiectele (elementul OBJECT). Se refera la incorporarea in cadrul unei pagini a unor
programe in format obiect. Ele vor fi executate la client.
Modelul obiectelor document (engl.Document Object Model DOM). Acesta este liantul
dintre elementele anterioare i limbajul de marcare HTML sau XML.
Eventuale mecanisme particulare specifice programului navigator.
Se recomanda separarea prezentarii (margini, culori, fonturi) de coninutul i structura
documentului (antet, pagini, paragrafe, titluri, sectiuni). Pentru aceasta se pot folosi foi de stil
(engl.Cascading Style Sheets CSS).
Prezentarea unui document este in general determinata de mai multi factori:
Intentiile proiectantului paginii
Reguli generale pe care trebuie sa le urmeze proiectantul
Preferintele utilizatorului
Limitarile cauzate de terminalul pe care se vizualizeaza prezentarea
Din acest motiv apare necesitatea utilizarii mai multor foi de stil cascadarea foilor de stil
(CSS). CSS specifica stilul de prezentare al unui document HTML. Exista trei modalitati de a
mixa CSS i HTML: i) in cadrul unui element HTML; ii) in antetul unui document HTML; iii)
intr-un fisier separat:
Specificarea stilului intr-un element individual se face cu atributul STYLE:

<HTML>
<HEAD>
<TITLE>
Specificarea stilului in cadrul unui element HTML
</TITLE>
</HEAD>
<BODY>
<P STYLE = "font-size: 20pt">Text</P>
<P STYLE = "font-size: 20pt; color: #0000FF">Text</P>
</BODY>
</HTML>

Specificarea stilului in antet se face cu elementul STYLE:

171
<HTML>
<HEAD>
<TITLE>Specificarea stilului in antet
</TITLE>
<STYLE TYPE = "text/css">
EM { background-color: #8000FF; color: white }
H1 { font-family: Arial, sans-serif }
P { font-size: 18pt }
.blue { color: blue }
</STYLE>
</HEAD>
<BODY>
<H1 CLASS = "blue">Un antet</H1>
<P>Un paragraf</P>
<H1>Alt antet</H1>
<P CLASS = "blue">Alt <EM>paragraf</EM></P>
</BODY>
</HTML>

Foaie de stil intr-un fisier separat:

EM { background-color: #8000FF; color: white }
H1 { font-family: Arial,
sans-serif }
P { font-size: 18pt }
.blue { color: blue }

O foaie de stil pastrata intr-un fisier separat se leaga la un document HTML folosind
elementul LINK.

<HTML>
<HEAD>
<TITLE>
Importul unei foi de stil
<LINK REL="stylesheet"
TYPE="text/css"
HREF="css3.css"/>
</TITLE>
</HEAD>
<BODY>
<H1 CLASS = "blue">Un antet</H1>
<P>Un paragraf</P>
<H1>Alt antet</H1>
<P CLASS =
"blue">Alt<EM>paragraf</EM></P>
</BODY>
</HTML>

172
Reguli, selectori i declaratii
O foaie de stil este constituit dintr-o multime de reguli care se aplica unui document
HTML in scopul generarii unei prezentari a documentului.
O regula de stil conine o parte de conditii (stanga) numita i selector i o parte de actiuni
(dreapta) numita i declaratie. Exemplu: P {color:green}, unde:
P este un selector
{color:green} este o declaratie. O declaratie poate conine mai multe asignari
color:green este o asignare
color este o proprietate
green este o valoare
Stilul unui document este o multime de asignari de valori unor variabile numite
proprietati. O proprietate exprima o calitate sau caracteristica pe care o poate avea un element al
unui document HTML.
Asignarea de valori proprietatilor se bazeaza pe mecanismul de mostenire cu suprascriere
(engl.overriding inheritance).
Un document HTML este structurat sub forma unui arbore de elemente carora li se
asociaza proprietati cu valori. O pereche proprietate valoare se transmite prin mostenire de la
nivelurile superioare in arbore ctre frunze. La intalnirea unei noi valori pentru aceiasi
proprietate, noua valoare o va suprascrie pe cea veche, fiind considerata mai specifica.
Selectorii regulilor pot fi: tipurile elementelor, atributele elementelor (elementele CLASS
i ID au fost introduse pentru a fi folosite cu CSS), contextul elementelor, respectiv informaii
externe documentului. Pentru detalii se va consulta specificatia CSS1 (CSS de nivel 1).

Motenirea i rezolvarea conflictelor n DHTML

In general unui document i se aplica mai multe foi de stil:
Foaia de stil specifica documentului
Foaia de stil implicita a programului navigator. Ideal, navigatorul ar trebui sa permita
setarea foii de stil implicite in funcie de preferintele utilizatorului, intr-un mod
independent de navigator
O eventuala foaie de stil externa, specifica tipului de document
In cazul in care mai multe reguli sunt aplicabile unui element, selectia regulii aplicabile se
face pe baza unei strategii de rezolvare a conflictelor. Conflictele sunt de doua tipuri:
Conflicte in cadrul aceleiasi foi de stil
Conflicte intre regulile unor foi de stil diferite
Rezolvarea conflictelor se face astfel:
Se determina toate regulile aplicabile din toate foile de stil.
Se ordoneaza regulile selectate de pasul anterior astfel incat regulile marcate ca
importante au prioritate.
Se ordoneaza regulile selectate de pasul anterior in funcie de originea foii de stil:
navigator, utilizator, proiectant (de la proiectant au precedenta maxima). Dup acest pas
vor ramne doar reguli din aceeasi foaie de stil.
Se ordoneaza regulile selectate de pasul anterior in funcie de specificitate. O regula este
cu atat mai specifica cu cat selectorul ei exprima o conditie mai complexa.
Se ordoneaza regulile selectate de pasul anterior in funcie de ordinea in care au fost
specificate. Regulile ce apar mai tarziu in document au o prioritate mai mare. Regulile
importate din foi de stil externe se considera aflate inainte oricaror reguli prezente
explicit in foaia de stil.
173
Cateva exemple de reguli in foile de stil sunt :
Selector bazat pe tipul elementelor:
H1 {color: blue}
H1, H2: {color: blue}
Selector bazat pe clasa (atributul CLASS) elementelor:
.IMPORTANT {color: red}
Selector bazat pe ID-ul elementelor:
#COPYRIGHT {font-size: small}
Selector contextual:
LI P {margin-top: 0mm}
TABLE .SMALL P {font-size: small}
Selectori bazati pe informaii externe documentului
A:LINK {color: green}
A:ACTIVE {color: red}
A:VISITED {color: blue}
P.INITIAL:FIRST-LETTER {font-size: 200%; float: left}
P.INITIAL:FIRST-LINE {text-transform: uppercase}
Combinarea tipurilor de selectori
TABLE P.INITIAL:FIRST-LETTER {font-size: 200%; float: left}
Proprietatile din cadrul declaratiilor pot fi:
Referitoare la fonturi
Referitoare la spatiere
Referitoare la imagini
Referitoare la culori i fundaluri
5.2.3. Miniaplicatii Java

O miniaplicatie (engl.applet) Java este un program Java care ruleaza sub controlul unui
program client de navigare WWW. Miniaplicatia este transferata de la server ctre client sub
forma de cod obiect (class sau jar).
Conditia ca o miniaplicatie sa poata fi executata pe calculatorul clientului este ca
programul de navigare sa dispuna de un subprogram de interpretare a codului binar al masinii
virtuale Java. Un astfel de program navigator se numeste Java-enabled.
Restrictii:
i) o miniaplicatie nu se poate atinge (in citire sau scriere) de discul calculatorului
client pe care ruleaza; din acest motiv se spune metaforic ca ruleaza inside the
sandbox;
ii) ii) lansarea in executie a unei miniaplicatii poate dura deoarece descarcarea
fisiereleor class i apoi incarcarea lor sub controlul programului client de
navigare poate consuma un timp semnificativ de mare.
174
O miniaplicatie se include intr-o pagina WWW cu elementele APPLET sau OBJECT.
Initial s-a folosit elementul APPLET, deoarece singurele programe executabile care se puteau
include in paginile WWW sub forma de cod obiect erau miniaplicatiile Java. Exemplu:
<APPLET CODE="Miniaplicatie" CODEBASE="." WIDTH="300" HEIGHT="200">
</APPLET>
Ulterior s-a introdus elementul OBJECT pentru a se permite includerea i a altor aplicatii
sub forma de cod obiect in paginile WWW. Exemplu:
<OBJECT WIDTH="500" HEIGHT="300"> <PARAM NAME="code" VALUE=
"Miniaplicatie"/>
<PARAM NAME="codebase" VALUE ="."/>
</OBJECT>
Construirea unei miniaplicatii Java presupune urmatoarele:
O miniaplicatie Java este o aplicatie grafica care foloseste bibliotecile Java pentru
construirea de intrft grafice AWT sau Swing.
O miniaplicatie nu are constructor deoarece este creata de programul de navigare sub
controlul caruia ruleaza. Ea se construieste prin extinderea clasei Applet din AWT sau
JApplet din Swing i redefinirea urmatoarelor metode (cel putin init() trebuie redefinita):
init(), se executa o singura data la incarcarea miniplicatiei.
start(), se executa dup init() i ori de cate ori este reafisata pagina care conine
miniaplicatia
stop(), se executa cand pagina ce conine miniaplicatia nu mai este afisata i imediat
inainte de destroy()
destroy(), se executa cand miniaplicatia se inchide i trebuie descarcata din memorie
Operatiile din cadrul redefinirii metodei init() sunt asemenatoare cu cele din cadrul unui
constructor al unei aplicatii grafice obisnuite. Spre exemplu, aici se initializeaza
controalele grafice membre ale interfetei miniaplicatiei i se adauga la miniaplicatie. Din
acest motiv orice miniaplicatie poate fi rulata i ca o aplicatie obisnuita dac se defineste
o metoda main() in care se creeaza un obiect miniaplicatie i apoi se executa operatiile
din init().
Interfete grafice in Java
Se spune ca AWT (java.awt) este de categorie grea (engl.heavyweight), iar Swing
(javax.swing) este de categorie usoara (engl.lightweight). AWT se bazeaza pe obiectele grafice
ale platformei gazda in timp ce Swing redeseneaza toate controalele grafice. Astfel AWT este
mai rapida, dar dependenta de platforma (la aspect) in timp ce Swing este mai lenta, dar
independenta de platforma.
O interfata grafica este compusa din componente. Componentele pot fi amplasate in
containere, care sunt la randul lor componente. Astfel se pot construi interfete grafice complexe.
Modelul de programare folosit la programarea interfetelor grafice se numeste programare
orientata pe evenimente (engl.event-driven programming). Componentele genereaza evenimente
la actiunile utilizatorului. La componente se inregistreaza niste obiecte speciale numite obiecte
ascultator (engl.listener) interesate sa primeasca aceste evenimente.
Obiectele ascultator primesc evenimentele sub forma unor apeluri de metode. Din acest
motiv ele trebuie sa implementeze anumite interfete astfel incat sa permita aceste apeluri. Aceste
interfete sunt subclase ale clasei de baza EventListener.
175
In momentul in care un obiect ascultator receptioneaza un eveniment, in apelul
corespunzator evenimentului se transmit i informaii referitoare la obiectul grafic care a
transmis evenimentul.

5.2.4. Programare la client folosind scripting

Prin limbaj de scripting se intelege un limbaj de programare interpretat. Solutia de
interpretare permite transmiterea programelor in cod sursa, cu conditia existentei la destinatie a
unui interpretor pentru executia lor. Exemple de limbaje de scripting: dBase, Visual Basic, Perl,
Unix shell, Python, Tcl, Ruby, etc. Un program scris intr-un limbaj de scripting se numeste
script.
In WWW, scripting-ul se foloseste atat la client cat i la server. Executia unui script la
server poate produce coninut ce este transmis prin HTTP clientului (de exemplu prin CGI).
Executia unui script la client produce coninut dinamic. Scripting-ul la client este parte a
tehnologiei Dynamic HTML DHTML.
Deosebirea esentiala dintre un limbaj de programare compilat i un limbaj de scripting
interpretat este momentul legarii (engl.binding) - momentul in care devin cunoscute atributele
unei variabile. La limbajele compilate momentul legarii este cel al traducerii, iar la cele
interpretate este cel al executiei. Amanarea legarii atributelor conduce la flexibilitate a executiei
in dauna eficientei.
JavaScript este un limbaj de scripting orientat pe obiect inventat de Netscape. Spre
deosebire de limbajele orientate pe obiect bazate pe clase, cum sunt C++ i Java, JavaScript este
un limbaj orientat pe obiect bazat pe prototipuri.
JavaScript este un limbaj extensibil. Exista o componenta de baza, numita Core
JavaScript, care conine elementele de baza ale limbajului (cuvinte cheie, operatori, enunturi,
structuri de control, modelul obiectual) i o multime de obiecte de baza (ex.Array, Date, Math).
La ea se pot adauga extensii sub forma unor obiecte suplimentare. Exemple sunt Client-side
JavaScript care conine in plus obiecte pentru controlul programului navigator i DOM i Server-
side JavaScript care conine obiecte suport pentru partea de server (de ex. pentru comunicarea cu
o baza de date relationala). In coninuare prin JavaScript vom subintelege partea client a
JavaScript.
Navigatoarele WWW interpreteaza scripturile JavaScript din paginile HTML. Ele citesc
pagina, interpreteaza marcajele i o afiseaza, executand in acelasi timp scripturile JavaScript pe
masura intalnirii lor in cadrul paginii. Rezultatul acestui proces de interpretare/executie este
vizualizat de utilizator in fereastra navigatorului.
Intre JavaScript i Java exista i asemanari i deosebiri fundamentale. Asemanarile se
refera la sintaxa enunturilor i a structurilor de control. Deosebirile: Java are legare la compilare
(engl.statically typed), este puternic tipizat (engl.strongly-typed) i foloseste un model obiectual
bazat pe clase. JavaScript are legare la executie (engl.dynamically typed), este mult mai
permisiv in ceea ce priveste declaratiile (engl.loosely-typed) i foloseste un model obiectual
bazat pe prototipuri.
Utilizarea JavaScript intr-o pagina HTML presupune folosirea elementului SCRIPT:
<SCRIPT> Enunturi JavaScript... </SCRIPT>
Specificarea limbajului i versiunii de scripting se fac cu atributul LANGUAGE:
<SCRIPT LANGUAGE="JavaScript1.3">
Specificarea codului JavaScript se poate face direct in elementul SCRIPT:
<HTML>
<HEAD>
<SCRIPT LANGUAGE ="JavaScript1.3">
<!-- Ascunde scriptul pentru navigatoarele ce nu stiu Javascript.
document.write("Salut !");
// Sfarsitul scriptului. -->
176
</SCRIPT>
</HEAD>
</HTML>

Specificarea codului JavaScript se poate face i intr-un fisier/URL separat:
<HTML>
<HEAD>
<SCRIPT SRC="js1.js"></SCRIPT>
</HEAD>
</HTML>

Utilizarea entitatilor JavaScript permite specificarea de expresii JavaScript ca valori ale
atributelor elementelor HTML (nu merge la IE !?). O entitate JavaScript are sintaxa &{expresie
JavaScript}; Un exemplu de folosire:
<SCRIPT LANGUAGE="JavaScript">
var lungime = 25;
</SCRIPT>
<HR WIDTH="&{lungime*2};%" ALIGN="left"/>

Sirurile de caractere in cadrul unui literal JavaScript se pun intre apostroafe (merge i \"
in IE):
document.writeln("<HR ALIGN='left' WIDTH=" + lungime*2 + "%>")

Aplicatiile JavaScript sunt orientate pe evenimente (engl.event-driven). Un eveniment
este de obicei rezultatul unei actiuni a utilizatorului. Un script poate reactiona la evenimente prin
intermediul unui secvente de cod de tratare a evenimentului (engl.event handler). Un event
handler este o secventa de cod JavaScript, de obicei un apel de funcie JavaScript.
Dac un eveniment se aplica unui element HTML, atunci se poate specifica un event
handler in cadrul elementului. Evenimentul se aplica obiectului JavaScript creat de element.
<element onEveniment="cod JavaScript">

Exemplu:

<HEAD>
<SCRIPT>
funcion calcul(f) {
f.rez.value = eval(f.expr.value)
}
</SCRIPT>
</HEAD>
<BODY>
<FORM>
Introduceti o expresie:
<INPUT TYPE="text" NAME="expr" SIZE=15/>
<INPUT TYPE="button" VALUE="Calculeaza" onClick="calcul(this.form)"/><BR/>
Rezultat:
<INPUT TYPE="text" NAME="rez" SIZE=15/>
</FORM>
</BODY>

177
Obiectul this desemneaza obiectul buton, iar this.form formularul care conine butonul.
Funcia calcul() primeste ca argument un formular, preia expresia de calculat din campul expr, o
evalueaza cu eval() i depune rezultatul in campul rez. Evenimentul tratat este Click pe buton.
Core JavaScript
Variabilele se declara la initializare sau optional cu var. Pot fi globale sau locale (definite
in corpul unei funcii). Cele locale se declara obligatoriu cu var.
Exista tipuri primitive i tipuri compuse. Tipurile primitive sunt: numerele (intregi i
reali), valorile logice, sirurile de caractere, valoarea null i valoarea undefined. Tipurile compuse
sunt vectorii i obiectele.
Pentru specificarea constantelor (numite i valori) se folosesc literali. Exista literali
pentru specificarea numerelor (2, 3.14), valorilor logice (true i false), vectorilor ([1,2,3,aaa])
i obiectelor ({camp_1:a,camp_2:3}).
Structurile de control sunt cele din Java: secventierea, if-else, switch, for, while, do-
while, label, break i coninue. Exista in plus structurile pentru manipularea obiectelor: for-in i
with. Comentariile sunt ca in Java.
Caramizile de baza ale JavaScript sunt funciile. Ele se declara astfel:
function nume(argumente) { corpul funciei }
Funciile pot intoarce optional o valoare cu return i pot fi recursive. Argumentele
funciilor sunt disponibile din vectorul arguments. Exista o multime de funcii predefinite (vezi
documentatia de la Netscape).
Funciile i variabilele globale pot fi referite i din alte ferestre dac se prefixeaza cu
numele ferestrei in care au fost definite.
Relativ la modelul obiectual din JavaScript, se mentioneaza urmatoarele aspecte:
Construirea unui obiect presupune:
Initializarea cu un literal:
nume = {prop
1
:val
1
, prop
2
:value
2
, ..., prop
n
:val
n
};
Definirea unei funcii constructor:
funcion TipObiect(argumente) {
this.prop
1
= val
1
;

}
obiect = new TipObiect(argumente);
Proprietatile unui obiect se pot accesa cu obiect.prop sau cu obiect["prop"].
Obiecte JavaScript predefinite: Array, Boolean, Date, Funcion, Math, Number, RegExp,
String.
Ierarhii de obiecte in JavaScript: dac se doreste crearea unui obiect care mosteneste de
la un alt obiect se seteaza valoarea prototype a sa la obiectul de la care se mosteneste.
Notiunea de clasa de baza din limbajele bazate pe clase a fost inlocuita cu notiunea de
obiect prototip.
Concluzii:
Pe cat posibil incercati sa separati partea de coninut de partea de prezentare din pagini. Pentru
aceasta identificati intai unitatile de coninut pe care trebuie sa le conina pagina i abia apoi
puneti-va problema modului de prezentare al acestora.
Aveti in vedere ca descarcarea unor programe in cod obiect i rularea lor in programul
navigator poate duce la incetinirea incarcarii paginii.
Folositi scriptingul la client numai atunci cand este absolut necesar. Scriptingul nu face sa
creasca dependenta paginilor pe care le scrieti de programul navigator.
Atunci cand doriti sa creati pagini complexe i folosirea scriptingului la client este absolut
178
necesara, incercati sa identificati cu clientul dumneavoastra navigatoarele carora le sunt
adresate paginile. Un pas important va fi apoi testarea navigatorului inainte de afisarea
paginilor sau a anumitor parti specifice din pagini.


5.3. PROGRAMARE PE PARTEA DE SERVER
5.3.1. Servere WWW
Un server WWW este un program cu rol de server care este capabil sa raspunda la cereri
HTTP. Modul de funcionare al unui server WWW este foarte important pentru infrastructura i
aplicatiile WWW, desi in acelasi timp este ascuns utilizatorilor uzuali ai WWW. Probleme
importante referitoare la serverele WWW sunt:
Performanta
Configurarea i administrarea
Extensia i programarea
Un exemplu de server WWW foarte folosit i disponibil liber in domeniul public este
Apache. Un sondaj din 1998 a aratat ca 51.9% din toate serverele active de WWW erau servere
Apache.
Relativ la performantele serverelor WWW, trebuie precizate urmtoarele aspecte:
La nivelul anului 1999 se mentioneaza in literatura doua suite (pachete de programe) standard
(engl.benchmark) pentru testarea performantelor serverelor WWW:
WebStone, dezvoltata de Silicon Graphics, Inc. SGI
SPECweb96, dezvoltata de Standard Performance Evaluation Corporation SPEC
WebStone este o suita configurabila de teste de performanta, destinata a fi utilizata de
administratorii WWW. Configurabilitatea este utila pentru a proiecta teste specifice pentru
diverse sabloane de acces la servere.
SPECweb96 este o suita fixa de teste de performanta. Sabloanele de test au fost obinute
analizand cele mai frecvente moduri de utilizare ale serverelor WWW.
Optiunile de configurare ale unui server WWW se refera in general la:
Modul in care se va executa serverul pe masina care il gazduieste.
Dac serverul deserveste mai multe masini gazda i in caz afirmativ modul in care
realizeaza acest lucru. Dac serverul deserveste mai multe masini gazda atunci acestea se
numesc gazde virtuale (engl.virtual host).
Modul de lucru: server de origine sau proxy.
Executia serverelor WWW poate fi de dou tipuri:
Executie la cerere
Este o metoda veche. Presupune existenta unui superserver care asculta toate cererile i
pentru fiecare in parte activeaza i executa serverul corespunzator. In UNIX acest
superserver se numeste inetd. Aceasta metoda are marele dezavantaj ca necesita prea multe
resurse sistem de fiecare data cand se incarca serverul in memorie i se creaza procesul
aferent.
Executie permanenta
Serverul este pornit manual de utilizator sau automat la pornirea sistemului i se executa in
permanenta. Dup pornire serverul asculta cererile HTTP pe portul pe care a fost
configurat. Pornirea manuala este recomandata intr-un mediu de dezvoltare a unei aplicatii
WWW. Pornirea automata este recomandata dup ce aplicatia WWW a fost instalata
(engl.deployed).
Serverul poate fi pornit de la linia de comanda sau instalat ca serviciu al sistemului de
operare.
179

5.3.2. Gazde virtuale

Un server WWW poate deservi una sau mai multe masini gazda. In al doilea caz masinile
gazda deservite se numesc gazde virtuale. Gazdele virtuale usureaza activitatea de administrare a
serverului deoarece: exista o singura instanta a serverului, exista o singura configuratie a
serverului, se monitorizeaza executia unui singur server. Exista doua tipuri de gazde virtuale:
gazde virtuale IP i gazde virtuale non-IP.
Gazdele virtuale IP:
Fiecare gazda virtuala este o gazda IP avand o adresa de IP distincta care apare ca intrare
in DNS.
Se asigneaza toate adresele de IP ale gazdelor virtuale deservite masinii pe care ruleaza
serverul WWW.
Metoda este simpla dar are doua dezavantaje: i) este nevoie de o adresa de IP distincta
pentru fiecare gazda virtuala; ii) asignarea mai multor adrese de IP unei singure masini
poate crea probleme retelei.
Gazdele virtuale non-IP:
Se bazeaza pe un suport special oferit de protocolul HTTP. Acest suport pentru deservirea
gazdelor virtuale non-IP este disponibil numai in HTTP/1.1.
HTTP/1.1 a introdus in cadrul unei cereri HTTP antetul special HOST. Acest camp antet
este obligatoriu. El conine numele gazdei careia ii este adresata cererea.
Configurarea gazdelor virtuale deservite se face analog cu cazul anterior. Singura diferenta
este ca intrarile DNS ale gazdelor virtuale vor conine acum aceeasi adresa de IP.
Metoda are doua avantaje: i) este nevoie de o singura adresa de IP pentru deservirea
tuturor gazdelor virtuale; ii) crearea unei noi gazde virtuale non-IP se poate face mai usor
decat in cazul gazdelor virtuale IP. Metoda are un mare dezavantaj: se poate aplica numai
pentru versiunile HTTP ulterioare HTTP/1.1.
Serverele WWW pot fi:
Servere de origine
Majoritatea serverelor de WWW sunt configurate ca servere de origine. In acest caz cererile
HTTP sunt tratate local de server.
O problema importanta este localizarea resurselor, cu alte cuvinte maparea URL-ului intr-o
adresa a unei resurse din cadrul sistemului local de fisiere. Resursele sunt de doua tipuri:
statice (stocate fizic) i dinamice (generate de programe externe).
Spatiul WWW al unui utilizator specific se refera in URL prin caracterul ~ urmat de numele
utilizatorului. Spatiul WWW al utilizatorilor se poate organiza in doua moduri:
Crearea unui spatiu WWW central pentru toti utilizatorii. Unui utilizator ii va revni un
director in acest spatiu: webhome/name/.
Crearea unui director special pentru fiecare utilizator in cadrul directorului personal:
/home/name/WWW/.
Servere proxy
Un server proxy accepta cereri pentru resurse i fie le rezolva din memoria cache locala, fie
prin inaintarea cererii ctre serverul de origine.
Un server proxy actioneaza astfel ca un intermediar intre client i serverul de origine. Scopul
intermedierii pote fi filtrarea cererilor sau trecerea de la un protocol nesigur la un protocol
sigur, de exemplu HTTPS.

180
5.3.3. Tehnologiile SSI i CGI

SSI (engl.Server Side Include) este o tehnologie ce permite includerea de informaii intr-
o pagina WWW inainte de trimiterea paginii la client.
O pagina care foloseste SSI conine instructiuni speciale. Aceste instructiuni sunt
interpretate de server ori de cate ori pagina este ceruta de un client. Instructiunile pot specifica:
includerea unor documente in pagina curenta (de exemplu un header sau un footer), a datei
curente, a valorii unui contor de acces, etc.
Avantajul SSI fata de CGI este ca este o tehnologie mult mai simpla i ca nu implica
apelul nici unui program extern.
Nu exista un standard de SSI i de aceea fiecare server are o sintaxa i funcionalitate
proprie pentru SSI. Pentru serverul Apache instructiunile SSI sunt de forma unor comentarii
HTML/XML cu structura urmatoare:
<!-- #element atribut
1
=valoare
1
atribut
2
=valoare
2
... -->
Un exemplu este urmatorul:
<!--#include virtual="/header.html" -->
Serverul Apache permite folosirea i a unor facilitati SSI avansate desemnate prin
acronimul XSSI. Un exemplu este posibilitatea definirii unui flux de control ca in programarea
procedurala prin comenzile if, elif, else i endif.
Aplicatiile de comert electronic au o parte semnificativa pe partea de server. Pentru a
descrie aceasta parte se foloseste frecvent termenul de aplicatie WWW = extensia dinamica a
unui server WWW. Aplicatiile WWW sunt in general de doua tipuri:
Aplicatii orientate pe prezentare. Conin pagini WWW interactive i sunt capabile sa
genereze coninut dinamic ca raspuns la cererile clientilor.
Aplicatii orientate pe serviciu. Implementeaza un punct terminal pentru un serviciu
WWW. Serviciu WWW = un serviciu oferit de o aplicatie altor aplicatii, prin intermediul
platformei WWW.

Aplicatiile WWW conin componente WWW. Componentele WWW sunt caramizile pe
baza carora se poate extinde dinamic funcionalitatea unui server WWW. In tehnologia Java,
componentele WWW sunt miniservere sau pagini JSP.
Componentele WWW sunt suportate de serviciile unei platforme speciale de executie
numita container WWW. Containerul furnizeaza servicii ca: dispecerizarea cererilor, securitate,
concurenta, gestiunea ciclului de viata, etc.
O aplicatie WWW consta in general din: componente WWW, fisiere de resurse statice i
clase/biblioteci de ajutor (engl.helper).
Funcionalitatea standard oferita de un server WWW este insuficienta pentru
programarea aplicatiilor de comert electronic. O aplicatie de comert electronic are o arhitectura
multistrat, numarul de straturi fiind de obicei minim 3: client, server WWW, server de baze de
date. Pe langa serverul WWW mai exista obiectele din domeniul problemei (engl.business
objects). Impreuna ele formeaza stratul intermediar al unei arhitecturi tipice pentru o aplicatie de
comert electronic. In consecinta se pune problema extinderii funcionalitatii unui server de
WWW. O varianta este folosirea interfetei CGI, insa ea prezinta o serie de dezavantaje:
Pentru fiecare cerere HTTP trebuie startat un proces separat.
Interfata dintre serverul WWW i scriptul CGI este nesatisfacatoare.
O abordare eleganta o constituie o solutie Java pentru extinderea funcionalitatii unui
server WWW, i anume miniserverele Java (engl.Java servlet). Aceasta solutie are urmatoarele
avantaje:
Portabilitate
181
Miniserverele sunt rezidente i starea este persistenta intre cereri succesive
Beneficierea de avantajele tehnologiei Java: orientare pe obiect, modelul de securitate
Java, integrarea relativ usoara cu tehnologii ca RMI i CORBA

CGI (engl.Common Gateway Interface) defineste o interfata pentru comunicarea dintre
un server de informaii (cum este cazul unui server WWW) i un program de aplicatie.
CGI este o interfata independenta de limbaj. Este posibil sa se implementeze o aplicatie
CGI (numita i script CGI) in orice limbaj care suporta comunicarea standard intre procese prin
intermediul intrarii i iesirii standard i a variabilelor de mediu. Pentru scripturile CGI se
foloseste deseori unul dintre limbajele: Perl, Python sau Tcl. Se pot folosi insa i limbaje gen
C/C++.
Procesul de comunicare decurge astfel:
Dup primirea cererii HTTP i inaintea pornirii scriptului CGI, serverul initializeaza o
multime de variabile de mediu (engl.environment variables). Aceste variabile vor fi
mostenite de procesul corespunzator lansarii scriptului CGI. Existe variabile independente
de cerere i variabile dependente de cerere. Pe langa aceste variabile de mediu, dac
protocolul este HTTP, se creeaza cate o variabila de mediu ce incepe cu prefixul HTTP
pentru fiecare linie din antetul cererii (de exemplu HTTP_ACCEPT).
Dac cererea conine informaii aditionale dup antetul cererii, atunci informaia este
trimisa scripului CGI la intrarea standard. Se trimite un numar de octeti egal cu valoarea
variabilei de mediu CONTENT_LENGTH.
Scriptul genereaza datele de iesire la iesirea standard. Pentru generarea raspunsului ctre
client, serverul fie interpreteaza i prelucreaza aceste date, fie le inainteaza nealterate. El
indica acest acest lucru serverului prin antete speciale.

Funcionarea miniserverelor Java presupune urmatorii pasi:
Un program client emite o cerere HTTP ctre un server WWW.
Serverul interpreteaza cererea i executa o secventa de program careia ii transmite
parametrii cererii.
Programul apelat interpreteaza parametrii cererii i executa o portiune de cod care
genereaza dinamic o pagina HTML.

Prelucrarile executate de miniserver pot duce la:
Generarea unei pagini WWW statice.
Generarea unei pagini WWW modificata prin inserarea unui coninut dinamic.
Configurarea unei pagini WWW pe baza parametrilor cererii HTTP. Parametrii sunt
preluati de la utilizator printr-un formular HTML.
In general miniserverele sunt potrivite pentru aplicatiile orientate pe serviciu sau pentru
controlul aplicatiilor orientate pe prezentare.
5.3.4. Miniservere Java

La fel ca i o miniaplicatie, un miniserver nu conine o funcie main(). El va fi invocat de
ctre containerul de miniserveri la receptionarea unei cereri HTTP de ctre serverul WWW.
Pentru aceasta un miniserver trebuie sa implementeze o interfata javax.servlet.HttpServlet
Dezvoltarea unui minserver presupune extinderea clasei javax.servlet.HttpServlet i
redefinerea metodelor sale. Interfata cuprinde metodele service(), init() i destroy().
La executarea unei cereri ctre un miniserver au loc urmatoarele: i) dac miniserverul nu
exista atunci containerul de miniserveri incarca clasa corespunzatoare miniserverului, creaza o
instanta a acestei clase i apeleaza metoda init(); ii) se apeleaza metoda service(). In funcie de
tipul cererii, ea va apela o metoda doYYY() unde YYY identifica cererea HTTP, de exemplu
182
doGet() sau doPost().
Cand containerul trebuie sa descarce miniserverul din memorie el va apela metoda
destroy().
Metodele init() i destroy() se refera la ciclul de viata al miniserverului (la fel ca la
miniaplicatii). Aceste operatii se executa mult mai rar decat service().
Prelucrarile din cadrul unui miniserver se fac astfel:
In cadrul metodelor init() i destroy() se implementeaza acele prelucrari care asigura
persistenta informaiei stocate de miniserver.
In metodele service() sau doYYY() se implementeaza prelucrarile legate de tratarea
cererilor primite de la client. Acestea presupun de obicei urmatoarele:
Setarea tipului coninutului in obiectul raspuns HTTP, de tip
javax.servlet.http.HttpServletResponse:
raspuns.setContentType("text/html");
Obinerea unui flux de iesire la nivel de octet (OutputStream obinut din raspuns cu
getOutputStream()) sau la nivel de caracter (PrintWriter obinut din raspuns cu
getWriter()):
PrintWriter iesire = raspuns.getWriter();
Obinerea valorilor parametrilor cererii setati de client in formularul HTML, din obiectul
cerere de tip javax.servlet.http.HttpServletResponse, cu getParameter(). Dac numele
parametrilor este necunoscut atunci se poate obine lista numelor parametrilor cu
getParameterNames().
Construirea raspunsului prin scrierea in fluxul de iesire a unor enunturi HTML.
Pentru aflarea de informaii de configurare se foloseste metoda getServletConfig() care
intoarce un obiect SevletConfig. Din el se pot extrage parametrii de initializare ai
miniserverului cu getInitParameter() i getInitParameterNames().
Obiecte partajate:
Componentele WWW in general i miniserverele in particular folosesc de obicei i alte
obiecte pentru a-i indeplini sarcinile. Astfel: i) pot folosi obiecte private; ii) pot folosi obiecte
publice atribute ale unui domeniu standard; iii) pot accesa baze de date; iv) pot accesa alte
resurse WWW.
Componentele WWW cooperante pot partaja informaii sub forma unor obiecte definite ca
atribute ale unui domeniu standard: context WWW (aplicatie), sesiune, cerere HTTP i
respectiv pagina JSP.
Pentru reprezentarea acestor patru domenii, in pachetul javax.servlet sunt definite patru clase:
ServletContext, HttpSession, ServletRequest i JspContext.
Accesul la aceste obiecte se face prin metode de tip [get|set]Attribute.
Fire multiple in miniservere:
Containerul de miniserveri utilizeaza fire de executie separate pentru tratarea cererilor. Pentru
aceasta containerul are o rezerva (engl.pool) de fire de executie. Fiecarei cereri i se aloca un
fir.
Deoarece este teoretic posibil sa se execute cereri simultane pentru un acelasi miniserver, se
pune problema gestionarii corecte a resurselor miniserverului ce sunt partajate de aceste cereri
multiple. Resursele partajate pot fi: atribute ale domeniilor standard, variabile membre ale
clasei miniserverului, fisiere, baze de date, conexiuni de retea, etc.
Din acest motiv controlul accesului la resursele partajate se va realiza folosind tehnici de
sincronizare.
183
Variante:
Cea mai simpla solutie este ca metoda service() sa se implementeze cu synchornized.
Dac insa sectiunea critica din cadrul acestei funcii se executa conditionat, atunci este mai
eficient sa se foloseasca synchronized doar pentru portiunea de cod corespunzatoare acelei
sectiuni critice.
Se poate crea o clasa pentru accesul la resursa partajata, metodele de acces fiind declarate
synchronized.
Gestiunea sesiunii de lucru:
O problema majora a HTTP este ca nu permite pastrarea starii comunicarii dintre un
client i un server WWW. Pentru a inlatura aceasta problema s-au propus diverse metode:
Folosirea campurilor ascunse. Aceasta metoda presupune transmiterea repetata de la
server ctre client i apoi de la client ctre server a istoricului interactiunii sub forma unei
multimi de campuri ascunse intr-un formular HTML.Un exemplu de camp ascuns este
<INPUT TYPE="hidden" name="ascuns1" value="element1">. De fiecare data cand
utilizatorul selecteaza un nou element serverul primeste o pereche nume-valoare de forma
element_selectat="", dup care serverul creaza un nou camp ascuns pentru acest element
i il paseaza in formularul raspuns, etc
Rescrierea URL-ului. Aceasta metoda consta in adaugarea de informaii suplimentare la un
URL pentru a identifica in mod unic o sesiune.
Folosirea autentificarii HTTP. Aceasta metoda presupune identificarea i autentificarea
utilizatorului la primul sau acces asupra serverului. Ulterior serverul va identifica
utilizatorul din antetele HTTP.
Folosirea cookie-urilor.Un cookie este o informaie pe care un server WWW o poate stoca
pe calculatorul unui client. Ulterior, aceasta informaie va fi trimisa serverului la fiecare
cerere a clientului. Serverul poate folosi aceasta informaie pentru gestiunea sesiunii.
Gestiunea sesiunii de lucru folosind miniservere:
Un cookie se creaza i se adauga la raspunsul HTTP inaintea setarii tipului coninutului.
Cookie c = new Cookie("element_selectat", "carte1");
raspuns.addCookie(c);
Serverul va determina ce cookie-uri exista in cererea HTTP cu getCookies().
O sesiune consta in una sau mai multe cereri HTTP ctre un server WWW de-alungul
unei perioade de timp.
Implementarea unei sesiuni foloseste clasa HttpSession. Un obiect sesiune este pastrat pe
server i el stocheaza informaiiile despre un client de-alungul unei sesiuni a clientului
respectiv.
Clasa HttpSession foloseste clasa Cookie pentru stocarea identificatoului sesiunii la client
sub forma unui cookie. Sesiunea este pastrata un interval maxim de timp intre doua cereri
succesive ale clientului.
Informaia se pastreaza in obiectul sesiune sub forma unor perechi variabila-valoare.
Pentru accesul la aceste perechi se folosesc metodele setAttribute(), removeAttribute(),
getAttribute(), getAttributeNames();
Dezvoltarea unei aplicatii care foloseste miniservere presupune urmtoarele:
Se compileaza sursele java pentru a obine fisierele class.
Se creaza un subdirector in directorul webpps. Acest subdirector conine pagina radacina
a aplicatiei i se numeste context.
Se creaza un subdirector WEB-INF care va conine:
un fisier de configurare a aplicatiei web,xml
184
un subdirector classes unde se depun fisierele class, pe subdirectoare corespunzatoare
structurii de pachete a programului java
Apelul miniserverului se poate face direct, dintr-un formular sau dintr-o legatura. In toate
cazurile se va specifica un URL de forma:
URLGazda/context/servlet/fisier_class
Un exemplu este:
http://localhost/Miniserver1/servlet/Miniserver1
Un miniserver poate fi repornit fie prin repornirea containerului de miniservere, fie doar
prin repornirea lui individuala.

JSP (engl.Java Server Pages) este o tehnologie pentru generarea de pagini dinamice
bazata pe ideea mixarii de cod Java cu cod HTML in paginile WWW. Este recomandata pentru
aplicatiile WWW orientate pe prezentare.
O alta tehnologie de pagini dinamice foarte folosita la ora actuala este PHP. PHP este un
limbaj de scripting pentru partea de server, inspirat din C. Codul PHP poate fi incorporat in
paginile WWW.
JSP funcioneaza peste o arhitectura de miniservere. La incarcarea unui JSP, se genereaza
automat codul java pentru miniserverul corespunzator i apoi acesta este compilat i incarcat in
containerul de miniserveri. Acest proces se repeta ori de cate ori codul JSP este modificat.
Elemente de baza ale JSP:
In JSP se pot referi niste obiecte predefinite: HttpServletRequest request,
HttpServletResponse response, jsp.PageContext pageContext, http.HttpSession session,
ServletContext application, jsp.JspWriter out, ServerConfig config, java.lang.Object
page.
Exista trei tipuri de elemente de scripting in JSP:
Expresii de forma <%= expresie %>
Miniscripturi (engl.scriptlet) de forma <% cod Java %>
Declaratii de forma <%! Cod %>
Expresiile se utilizeaza pentru a insera valori direct in pagina generata. De exemplu:
Current time: <%= new java.util.Date() %>
Miniscripturile reprezinta un cod Java mai complex decat niste expresii simple.
<% String queryData = request.getQueryString();
out.println(Date GET: + queryData); %>
Declaratiile permit inserarea de metode sau campuri in codul java al corpului clasei
miniserver, in afara metodei _jspService().
<%! private int jj =10; %>

5.4. SERVERE DE BAZE DE DATE

Bazele de date relationale bazate pe SQL sunt cele mai raspandite sisteme comerciale de
baze de date. Prin baza de date relationala vom intelege o multime de relatii (tabele) accesate
prin limbajul de specializat SQL.
Un tabel sau relatie poate fi gandit ca o reprezentare bidimensionala a unei colectii de
date, structurata sub forma unei multimi de linii i coloane. O linie corespunde unei inregistrari
i o coloana corespunde unui camp. Fiecare camp are un nume i un tip. Dac un camp conine o
valoare unica atunci el se numeste cheie primara (engl.primary key). Se pot crea legaturi intre
185
relatii prin stocarea cheilor primare ale unei relatii intr-o alta relatie sub forma de chei externe
(engl.foreign key).
SQL (engl.Structured Query Language) este un limbaj pentru definirea, interogarea i
actualizarea bazelor de date relationale. Cateva comenzi SQL foarte folosite sunt select, insert,
delete, update, commit, rollback, grant i revoke.
Comenzile commit i rollback sunt utile pentru lucrul cu tranzactii. O tranzactie este o
secventa de operatii de acces la o baza de date, secventa ce are proprietatea de atomicitate. Acest
lucru inseamna ca fie secventa nu se executa, fie trebuie executata in totalitate pentru pastrarea
consistentei datelor.
O baza de date care lucreaza in regim tranzactional se poate afla in doua stari:
starea de autovalidare (engl.autocommit), caz in care orice cerere de actualizare
declanseaza automat modificarea coninutului bazei de date.
starea de validare manuala (engl.manual commit), caz in care modificarea coninutului
bazei de date are loc atunci cand se executa comanda commit. Pana la executarea acestei
comenzi, starea bazei de date dinaintea tranzactiei poate fi refacuta cu comanda rollback.
Comenzile grant i revoke permit administratorilor de sistem sa creeze utilizatori i sa le
dea respectiv ia drepturi pe urmatoarele patru nivele:
Nivel global: drepturile globale se aplica la toate bazele de date de pe un anumit server
Nivelul baza de date: drepturile alocate la acest nivel se aplica tuturor relatiilor unei baze
de date.
Nivelul relatie: drepturile alocate la acest nivel se aplica tuturor coloanelor unei relatii.
Nivelul coloana: dreptuile la acest nivel se aplica individual, coloanelor unei relatii.
Funciile unui server de baze de date sunt :
Interpretarea cererilor SQL primite de la clienti, executia lor i returnarea rezultatelor.
Optimizarea interogarilor. O interogare SQL se poate executa in mai multe moduri,
diferentele intre timpii de raspuns corespunzatori fiecarui mod putand fi mari. Un server va
analiza cererea SQL, va examina modul de stocare a relatiilor i va produce intr-un timp
rezonabil un plan de executie cat mai eficient.
Prevenirea erorilor datorate unui acces concurent la date.
Detectarea i inlaturarea situatiilor de interblocaj.
Administrarea accesului controlat la date din motive de securitate.
Administrarea operatiilor de arhivare/restaurare a bazei de date. Restaurarea bazei de date in
cazul unor caderi ale sistemului se realizeaza prin gestiunea unui jurnal (engl.log) al tuturor
tranzactiilor executate.

JDBC este o interfata de programare i o infrastructura pentru accesul la o baza de date
relationala. JDBC isi propune sa standardizeze mecanismul de conectare, de trimitere a cererilor,
de lucru cu tranzactii, cat i de reprezentare a rezultatelor unei cereri. Programatorul este insa
liber a foloseasca ce dialect SQL doreste, in funcie de serverul de baze de date cu care lucreaza.
JDBC propune o solutie multinivel:
La nivelul cel mai de sus, o aplicatie Java executa cereri SQL prin intermediul unei
interfete de programare definita in pachetul java.sql. Acest pchet nu conine altceva decat
definitiile unor interfete Java. Implementarile acestor interfete sunt furnizate separat pentru
diversele sisteme de baze de date.
Aplicatia acceseaza baza de date prin intermediul unui program special numit JDBC driver
manger.
Acest program gestioneaza programele specifice de control (engl.driver) pentru fiecare
sistem de baze de date in parte. Un program de control implementeaza interfata
java.sql.Driver.
Principalele interfete definite in pachetul java.sql sunt:
Driver. Acesta este interfata asociata cu programul de control. Ficare program de control
186
va furniza o clasa care implementeaza aceasta interfata. O astfel de clasa pentru MySQL
este com.mysql.jdbc.Driver, iar pentru o punte JDBC-ODBC este
sun.jdbc.odbc.JdbcOdbcDriver.
DriverManager. Aceasta clasa gestioneaza programele de control disponibile pentru
conectarea la diverse baze de date.
Statement. Este o clasa utila pentru crearea i executarea de cereri SQL.
PreparedStatement. Este o subclasa a clasei Statement utila pentru crearea de enunturi SQL
parametrizate i care sa poata fi executate eficient.
CallableStatement. Este o subclasa a clasei Statement utila pentru executarea de proceduri
stocate.
ResultSet. Se utilizeaza pentru reprezentarea multimii de rezultate obinute in urma
executiei unei interogari SQL.
ResultSetMetaData i DatabaseMetaData. Sunt clase pentru reprezentarea metadatelor
referitoare la o multime de rezultate respectiv la o baza de date. Exemple de metadate sunt:
numele atributelor unei relatii, tipurile atributelor unei relatii, diverse caracteristici ale
sistemului de baze de date (standardul SQL, dac suporta sau nu proceduri stocate, etc.)

Pasii de prelucrare la folosirea JDBC sunt urmatorii:
i) Incarcarea programului de control specific serverului de baze de date. Clasa incarcata conine
membrii statici ce creaza o instanta a programului de control i il inregistreaza la gestionarul
programelor de control.
Class.forName(com.mysql.jdbc.Driver);
ii) Definirea URL-ului conexiunii.
String dbUrl = "jdbc:mysql://127.0.0.1/magazin";
String utilizator = "";
String parola = "";
iii) Stabilirea conexiunii.
Connection c = DriverManager.getConnection(dbUrl, utilizator,parola);
iv) Crearea unui obiect pentru reprezentarea unei cereri SQL.
Statement s = c.createStatement();
v) Executarea cererii SQL.
ResultSet r = s.executeQuery("select isbn,prim_autor,titlu from Carte;");
vi) Prelucrarea rezultatelor.
while(r.next()) {
System.out.println(
r.getString(isbn") + ", "
+ r.getString("prim_autor")
+ ": " + r.getString(titlu") );
}
vii) Inchiderea conexiunii.
c.close();

Pentru tratarea erorilor in operatii SQL, JDBC furnizeaza clasa SQLException.
Se recomanda ca parametrii unei conexiuni sa fie indicati cu ajutorul unui fisier de proprietati:
driver=sun.jdbc.odbc.JdbcOdbcDriver
url=jdbc:odbc:carte
utilizator=admin
parola=admin
Dac o anumita interogare SQL se executa de un numar repetat de ori, atunci este mai
eficient sa se foloseasca un enunt pregatit (engl.prepared statement). In esenta un enunt pregatit
este o interogare compilata i optimizata pentru fi executata mai eficient.
187
Un enunt pregatit este in acelasi timp i un sablon de interogare. Un astfel de sablon
conine niste parametri specificati prin semnul intrebarii. Valoarea acestor parametri se
completeaza inaintea executiei interogarii.

String sablon= "update Angajat set salariu=? where id=?";
PreparedStatement cerere =
conexiune.preparedStatement(sablon);
float[] salarii_noi = getSalariiNoi();
int[] id_angajati = getIdAngajati();
for (int i=0;i< id_angajati.length;i++) {
cerere.setFloat(1,salarii_noi[i]);
cerere.setInt(2,id_angajati[i]);
cerere.execute();
}
Metadatele sunt date pentru descrierea altor date. JDBC conine un numar de clase utile
pentru extragerea de metadate referitoare la baze de date, multimi de raspunsuri, tabele,
programe de control, etc.
Metadatele sunt utile in urmatoarele situatii:
Pentru a testa dac sistemul de baza de date are anumite facilitati, a caror lipsa ar putea
produce erori. O astfel de facilitate este spre exemplu disponibilitatea procedurilor stocate.
Dac nu se cunoaste structura bazei de date.

Tipuri de metadate:
Metadate referitoare la baza de date. Se obin cu ajutorul clasei DatabaseMetaData. Aceste
metadate includ: numele programului de control, versiunea programului de control,
verificarea disponibilitatii standardului SQL2, verificarea disponibilitatii unor facilitati
specifice ale SQL, etc.
Metadate referitoare la multimea de rezultate. Se obin cu ajutorul clasei ResultSet. Aceste
metadate includ: numarul de atribute din multimea de rezultate, numele atributelor, numl
relatiei din care s-au obinut atributele, tipurile acestor atribute, etc.

Metadatele pot fi folosite pentru implementarea unor programe utilitare. Un exemplu ar
putea fi un program utilitar pentru executarea unei interogari generale i salvarea rezultatelor
impreuna cu diverse informaii referitoare la baza de date.
Intr-o aplicatie de comert electronic se inglobeaza obligatoriu o baza de date. De
asemenea, o astfel de aplicatie va conine i un nivel de obiecte din omeniul problemei
(engl.business objects). Se pune problema maparii acestor obiecte in relatii ale modelului
relational. Pentru aceasta se creaza cate o clasa corespunzatoare ficarei relatii a bazei de date,
cate o variabila membru pentru ficare atribut al acestei relatii i metode corespunzatoare de acces
la aceste variabile membru.
Codul metodelor de acces va folosi cereri SQL pentru acces la atributele corespunzatore
din baza de date.
Deschiderea unei conexiuni la o baza de date este un proces consumator de timp. El poate
dura mult mai mult decat executarea unei cereri. Din acest motiv se pune problema refolosirii
conexiunilor in aplicatiile care se conecteaza de un numar repetat de ori la o baza de date. Se
foloseste o clasa speciala numita rezerva de conexiuni (engl.connection pool). Aceasta clasa
ruleaza pe un fir separat i are urmatoarele responsabilitati:
Prealocarea conexiunilor pe constructorul clasei. Constructorul mai primeste un numar
maxim de conexiuni, un numar initial de conexiuni i un indicator dac rezerva sa astepte
sau nu cand se cere o conexiune i nu exista nici una libera.
Gestiunea conexiunilor disponibile. Dac se cere o conexiune i exista o conexiune libera,
atunci ea este alocata i trecuta in lista conexiunilor ocupate.
188
Alocarea de noi conexiuni. Dac se cere o conexiune, nu exista nici una libera i nu s-a
atins numarul maxim de conexiuni, atunci se creaza o noua conexiune pe un fir separat.
Dac insa s-a atins limita maxima, se asteapta sau nu in funcie de indicatorul setat in
constructor.
Asteptarea pentru eliberarea unei conexiuni.
Inchiderea conexiunilor.

Intr-o aplicatie cu miniservere, rezerva de conexiuni poate fi alocata unui singur miniserver
sau se poate partaja intre mai multe miniservere.


5.5. LIMBAJUL DE METAMARCARE XML

XML este un acronim pentru eXtensible Markup Language limbaj extensibil de
marcare. XML este un limbaj de meta-marcare - un limbaj pentru definirea limbajelor de
marcare. Limbaj de marcare (engl.markup language) = un limbaj pentru descrirea formei unui
document (cum trebuie interpretat coninutul documentului). Un limbaj de marcare defineste un
tip de document. Un document scris intr-un limbaj de marcare este compus din date i marcaje.
Marcajele sunt acele informaii care indica utilizatorului cum trebuie interpretat coninutul
documentului (datele propriu-zise).
Exista diverse tipuri de marcaje:
Stilistice: indica stilul de prezentare a documentului: I, U, B, FONT, etc.
Structurale: indica cum este structurat documentul: HEAD, BODY, P, H, etc
Semantice: indica semnificatia coninutului documentului: TITLE, META, etc.
Un limbaj de marcare creat cu XML se numeste i aplicatie XML (ex. XHTML).
Utilizarea XML confer urmtoarele avantaje:
Faciliteaza interoperabilitatea datelor intre aplicatii.
Ofera o alternativa la raspandirea formatelor proprietare.
Atat datele cat i marcajele sunt stocate sub forma de text, fapt ce permite manevrarea i
editarea usoara, practic cu orice editor de texte.
Fiind un limbaj de meta-marcare, este configurabil.
Poate fi citit i interpretat relativ usor de un agent uman.
Este standardizat, ceea ce inseamna ca este relativ unanim cunoscut i acceptat.
Este liber in sensul ca specifcatia este disponibila liber, este independent de platforma i
este bine sustinut de unelte software disponbile liber.

Tipuri de aplicatii care folosesc XML sunt:
Interactiunea cu doua sau mai multe surse de date, reprezentate in formate diferite =
integrarea datelor (engl.data integration) disponibile de la aplicatii diferite putand rula pe
platforme diferite
Transferarea unei parti a prelucrarilor asupra datelor pe calculatoarele client in arhitecturile
client-server
Furnizarea de vederi diferite asupra acelorasi date
Agenti pentru colectarea de informaii

Documente XML bine-formate

Cerinta de a fi bine-format (engl.well-formed) este o constrangere de baza impusa
documentelor XML. Un document XML bine-format trebuie sa respecte regulile de sintaxa
incluse in specificatia XML 1.0, adica:
189
Documentul conine unul sau mai multe elemente. Un element - un nod al unui arbore.
Exista un singur element - radacina - care conine in interiorul sau celelalte elemente;
Fiecare element, exceptand radacina, trebuie incuibat corect in cadrul unui element
cuprinzator numit parintele sau.
Un document XML conine date i marcaje. Datele sunt reprezentate sub forma unor
secvente de caractere (engl.character data). Marcajele indica structura documentului (sunt
metadate). Ele includ:
Marcajele de inceput i sfarsit ale elementelor;
Marcajele elementelor vide;
Comentariile;
Referintele la entitati;
Delimitatorii sectiunilor CDATA;
Definitiile de tip de document (engl.Document Type Definition DTD);
Instructiunile de prelucrare.
Un document XML se compune din trei parti:
Declaratie; indica faptul ca avem un document XML.
Prolog (antet) - poate fi vid. Conine o definitie de tip sau o referinta la definitia de tip.
Elementul radacina, care conine in interiorul sau toate celelalte elemente.
Un exemplu l constituie arborii binari n XML:
<?xml version="1.0" standalone="yes"
encoding="UTF-8" ?>
<! Un arbore binar reprezentat n XML -->
<ARBBIN>
<INFO>a</INFO>
<ARBBIN>
<INFO>b</INFO>
<ARBBIN/>
<ARBBIN>
<INFO>d</INFO>
<ARBBIN/>
<ARBBIN/>
</ARBBIN>
</ARBBIN>
<ARBBIN>
<INFO>c</INFO>
<ARBBIN>
<INFO>e</INFO>
<ARBBIN/>
<ARBBIN/>
</ARBBIN>
<ARBBIN/>
</ARBBIN>
</ARBBIN>

Prima linie din programul prezentat este declaratia de document XML. Textul inclus
ntre <!- i --> este un comentariu. Elementul de baza pentru structurarea unui document este
elementul. Un element este inclus ntre un marcaj de nceput i un marcaj de sfarit.
<ARBBIN> este un marcaj de nceput i </ARBBIN> este un marcaj de sfarit.
Primul marcaj <ARBBIN> ncepe elementul radacina al documentului.
<ARBBIN/> este un marcaj vid i este echivalent cu <ARBBIN></ARBBIN>. Indica un
element vid. Elementul <ARBBIN>a</ARBBIN> conine textul a n interiorul sau.
190

Elemente XML cu atribute:
Informaia din cadrul unui nod al arborelui se poate reprezenta ca valoare a unui atribut.
...
<ARBBIN>
<INFO info="b" />
<ARBBIN/>
<ARBBIN>
<INFO info="d" />
<ARBBIN/>
<ARBBIN/>
</ARBBIN>
</ARBBIN>
...
Un element poate avea mai mult decat un atribut.
<INFO cheie="10" info="b" />

Documente XML valide

Validitatea este o constrangere aditionala care poate fi impusa documentelor XML. Ea se
bazeaza pe ideea de tip de document mostenita din SGML.
Un document XML se numeste valid dac este bine format i dac exista o definitie de tip
de document DTD cu care documentul este consistent. Se spune ca documentul este o instanta
a acestei definitii de tip.
Adaugand o DTD documentului XML care conine un arbore binar se obine:

<?xml version="1.0" standalone="yes" ?>
<! Un arbore binar reprezentat n XML -->
<!DOCTYPE ARBBIN [
<!ELEMENT ARBBIN (INFO,ARBBIN,ARBBIN)? >
<!ELEMENT INFO (#PCDATA) >
]>
<ARBBIN> ...

n acest caz, DTD-ul este coninut n cadrul aceluiasi fisier cu documentul XML. DTD-ul
este inclus ntre marcajele <!DOCTYPE ARBBIN [ ]>. Marcajul de start al DTD-ului indica
elementul radacina al documentului.
DTD-ul conine o declaratie pentru fiecare element al documentului.
Fiecare declaratie de element specifica numele elementului i un model al coninutului sau.
DTD-ul poate fi plasat ntr-un fisier separat. Dac presupunem ca DTD-ul este plasat n fisierul
arbbin.dtd, atunci va trebui sa schimbam doar specificatia DTD-ului din documentul XML:
<!DOCTYPE ARBBIN SYSTEM "arbbin.dtd">

Fisierul arbbin.dtd va conine doar declaratiile elementelor:

<!ELEMENT ARBBIN (INFO,ARBBIN,ARBBIN)? >
<!ELEMENT INFO (#PCDATA)>

Dac informaia dintr-un nod se reprezinta ca valoare a atributului info al elementului INFO
atunci DTD-ul este:
191

<!ELEMENT ARBBIN (INFO,ARBBIN,ARBBIN)? >
<!ELEMENT INFO EMPTY>
<!ATTLIST INFO
info CDATA #REQUIRED>

Definitii de tip de document

O definitie de tip de document specifica:
Elementul radacina al documentului
Numele, atributele i modelul de coninut al fiecarui element din document:
<!ELEMENT nume_element model_de_coninut >
Modelul de coninut al unui element se specifica cu !ELEMENT i poate fi:
Vid, specificat prin EMPTY
Text, specificat prin #PCDATA
Alte elemente structurate n secventa (,), optionale (?), alternative (|) sau repetitive (*
i +)
Atributele se specifica pentru fiecare element n parte cu !ATTLIST incluzand numele
atributului, tipul valorii sale i setarea valorii implicite:
<!ATTLIST nume_element
nume_atribut tip_atribut setare_valoare_implicita
...
nume_atribut tip_atribut setare_valoare_implicita >

Tipuri de atribute pot fi: enumerare, CDATA, etc. Setari de valoare implicita pot fi:
#IMPLIED, #REQUIRED, #FIXED, etc.

Entiti, iruri de caractere neanalizate, spatii de nume

Orice procesor de XML trebuie sa distinga ntre date i marcaje. Pentru a putea desemna
caracterele < > ' i " ca date trebuie sa folosim entitatile predefinite &lt; &gt; &apos; i &quot;.
Pentru & se foloseste entitatea predefinita &amp;.
Caracterele speciale UNICODE pot fi referite &#codZecimal; sau &#xcodHexazecimal;.
Astfel se specifica prin &#169; sau &#xA9;.
Pentru a indica faptul ca un sir de caractere trebuie sa nu fie analizat de procesorul
documentului XML se foloseste o sectiune CDATA:
<INFO><![CDATA[Text ntr-un element <INFO>]]></INFO>
Entitatile parametrice sunt asemanatoare cu macroinstructiunile i sunt utile pentru
organizarea unui DTD.
<!ENTITY % nume "lista_nume">
Numele de elemente i atribute dintr-un document XML pot defini un vocabular partajat
destinat reutilizarii n cadrul unor aplicatii multiple. Pentru evitarea coliziunilor de nume ntre
astfel de vocabulare partajate se folosesc spatiile de nume (engl.namespaces).

Limbaje formale i analizoare sintactice

XML este un metalimbaj formal pentru definirea de limbaje formale specifice. Limbaj
formal = o multime de secvente de simboluri (enunturi, fraze) construite pe baza unei multimi de
reguli de formare numita sintaxa limbajului i interpretate potrivit unui anumit nteles numit
192
semantica limbajului.
Pentru analiza i prelucrarea enunturilor unui limbaj formal (a documentelor XML n
particular) este necesar un program special numit procesor de limbaj. O componenta de baza a
unui procesor de limbaj este analizorul sintactic (engl.parser). Un analizor sintactic pentru un
limbaj formal L primeste la intrare o multime de enunturi i ndeplineste urmatoarele funcii:
Decide dac enunturile verifica sintaxa limbajului L.
Dac nu, indica cat mai precis posibil ce reguli sunt ncalcate i unde anume.
Dac da, produce o reprezentare structurata intermediara a enunturilor astfel ncat ele sa
poata fi ulterior interpretate i prelucrate conform semanticii lui L.
Un programator de aplicatii va fi interesat n primul rand cum poate integra un procesor de
limbaj n cadrul unei aplicatii. n cazul XML el se va confrunta cu problema integrarii
analizoarelor sintactice de XML. n general exista doua modalitati prin care un analizor sintactic
poate comunica rezultatele analizei celorlalte componente ale aplicatiei: i) prin evenimente
analizor sintactic bazat pe evenimente (engl.event-driven parser); ii) prin construirea explicita a
unei structuri intermediare care sa descrie complet enunturile analizate translator.
Analiza i prelucrarea documentelor XML folosind Java se face astfel:
Un analizor sintactic de XML poate fi i) cu validare (engl.validating parser), caz n care el
verifica consistenta documentului XML cu un DTD sau ii) fara validare (engl.non-validating
parser), caz n care el verifica doar dac documentul XML este bine-format.
Exista o standardizare a interfetelor de programare (engl.Application Programming Interface
API) pe care trebuie sa le implementeze un analizor sintactic de XML astfel ncat el sa poata
fi integrat cat mai usor i portabil n cadrul unei aplicatii. n prezent exista doua API standard:
Simple API for XML SAX, un standard de-facto existent n doua versiuni SAX1 i
SAX2. Defineste o multime de interfete pentru un analizor sintactic bazat pe evenimente
(engl.event-driven parser). SAX a fost definita ntai pentru Java, dar s-au definit ulterior
versiuni similare i pentru alte limbaje (C++);
Document Object Model DOM, un standard W3C pentru un analizor sintactic care
traduce un document XML ntr-o structura de date abstracta de tip arbore numita DOM.
DOM se doreste a fi o specificatie independenta de limbaj, fiind valabila i pentru
limbajele de scripting (JavaScript)
Se folosete pachetul XML for Java de la IBM (XML4J). El se bazeaza pe proiectul
xml.apache.org din cadrul Apache Software Foundation, n speta pachetul Xerces.

Standardul SAX
SAX este un standard de facto pentru o interfata de programare a unui mecanism de
analiza sintactica bazat pe evenimente a documentelor XML. Un programator de aplicatii va
putea folosi orice biblioteca de programe de analiza sintactica conforma cu standardul SAX,
fiind suficient sa cunoasca doar aceasta interfata standard.
Termenul bazat pe evenimente se refera la folosirea unor funcii call-back. Aceste funcii
trebuie furnizate de programatorul de aplicatii i ele trateaza o serie de evenimente de interes
primite de la analizorul sintactic. Un analizor sintactic conform cu SAX va trebui sa
implementeze interfata SAX. Funciile call-back sunt implementate de obiecte speciale de tratare
a evenimentelor (engl.handler). Un astfel de obiect trebuie sa implementeze niste interfete
standard. O biblioteca conforma cu SAX va trebui sa conina partea de interfete standard SAX i
o implementare particulara a acestor interfete. O astfel de bibliotca este Xerces.
O interfa SAX conine trei parti:
Partea de baza org.xml.sax. Aici se definesc interfetele standard ale obiectelor de tratare a
evenimentelor SAX.
193
ContentHandler evenimente referitoare la coninut
DTDHandler evenimente referitoare la DTD
ErrorHandler evenimente de eroare
EntityResolver evenimente de tratare a entitatilor
XMLReader interfata unui analizor sintactic XML orientat pe evenimente
Attributes interfata pentru o lista de atribute XML
Partea de clase de ajutor org.xml.sax.helpers. Aici se definesc niste implementari implicite
pentru interfetele SAX.
DefaultHandler implementare implicita a tuturor celor 4 interfete pentru tratarea
evenimentelor SAX.
AttributesImpl implementare implicita pt o lista de atribute XML
...
Partea de extensii org.xml.sax.ext.

Folosirea SAX presupune parcurgerea urmatorilor pasi:
Furnizarea de implementari pentru obiectele de tratare a evenimentelor SAX. O metoda
comoda este extinderea implementarii implicite din clasa DefaultHandler. Aceasta clasa
furnizeaza implementari implicite pentru toate cele 4 interfete standard SAX. n cadrul
acestei implmentari se vor redefini doar metodele care sunt necesare.
Se creeaza o clasa pentru reprezentarea unui analizor sintactic. Pentru aceasta este util sa
se utilizeze o biblioteca care sa dispuna deja de o astfel de implementare. Spre exemplu,
pachetul Xerces dispune de clasa SAXParser.
n programul principal se realizeaza urmatoarele prelucrari:
Se creaza un obiect de tratare a evenimentelor SAX..
Se creaza un obiect pentru reprezentarea unui analizor sintactic.
Se nregistreaza obiectul de tratare a evenimentelor la analizorul sintactic.
Se executa funcia de analiza sintactica a obiectului analizor.
n funciile de tratare a evenimentelor de analiza sintactica se realizeaza toate prelucrarile
necesare din cadrul aplicatiei respective. Spre exemplu, se pot folosi aceste evenimente
pentru extragerea informaiilor relevante pentru aplicatie din cadrul documentului XML i
reprezentarea lor sub forma unei structuri intermediare. Aceasta structura se poate prelucra
ulterior.
Interfaa DOM
DOM (nivelul 2) este o platforma i o interfata independenta de limbaj ce permite
programelor i scripturilor sa acceseze i sa actualizeze dinamic coninutul i structura
documentelor XML.
Pachetul de baza org.w3c.dom poate fi gandit ca o specificatie a unui tip abstract de date
pentru reprezentarea unui document XML sub forma unui arbore. Principalele interfete definite
n acest pachet sunt urmatoarele:
Node este tipul primar al unui nod dintr-un arbore DOM
NodeList reprezinta o colectie ordonata de noduri
Element reprezinta un element al unui document XML Extinde tipul Node.
NamedNodeMap reprezinta o colectie de noduri ce pot fi accesate prin nume (de
exemplu nodurile atribut unui element XML).
Document reprezinta nodul document al unui arbore DOM. Extinde tipul Node.
Attr reprezinta un nod atribut al unui element XML. Extinde tipul Node.
Text
Comment
Entity
ProcessingInstruction
194
...

La fel ca i pentru SAX, folosirea DOM presupune existenta unei biblioteci care sa
implementeze interfetele DOM. O astfel de biblioteca este pachetul Xerces.
Folosirea DOM presupune parcurgerea urmatorilor pasi:
Implementarea unui modul de prelucrare a informaiei dintr-un document XML reprezentat
sub forma unui arbore DOM.
n programul principal se realizeaza urmatoarele prelucrari:
Construirea unui obiect pentru reprezentarea unui analizor sintactic conform cu DOM.
Pachetul Xerces furnizeaza pentru aceasta clasa DOMParser.
Se executa funcia de analiza sintactica a obiectului analizor.
Se extrage obiectul document i se prelucreaza.
DOMParser parser = new DOMParser();
parser.parse( ... );
Document doc = parser.getDocument();
Element root = doc.getDocumentElement();
...
Limbajele XSL i XSLT
XSL (Extensible Stylesheet Language) este un limbaj de prelucrare a documentelor
XML. XSL este o aplicatie XML.
XSL are doua componente relativ distincte:
Limbajul de transformare XSLT. XSLT permite trasformarea unui document XML ntr-un
alt document XML sau document text. XSLT 1.0 este o recomandare W3C din 16
Noiembrie 1999. XSLT foloseste limbajul XPath pentru adresarea diverselor parti din
arborele unui document XML.
Limbajul de formatare XML-FO. XML-FO permite descrierea formatului de prezentare a
unui document XML prin furnizarea unui vocabular de formatare.

Pentru reprezentarea unui document XML sunt necesari n general doi pasi:
Transformarea documentului XML initial ntr-un document XML care foloseste
vocabularul XML-FO. Acest pas poate optional sa realizeze i o filtrare a coninutului
documentului initial.
Formatarea documentului XML-FO rezultat, cu ajutorul unui program special de
formatare, adica transformarea sa ntr-un format specific de prezentare/ afisare/
vizualizare. Exemple de astfel de formate sunt PDF, Postscript i RTF.
n WWW se poate folosi XSLT pentru a transforma un document XML ntr-un document
XHTML sau WML. Transformarea poate avea loc fie la server, fie la client.
Transformari XSL
XSLT este un limbaj de transformare a unui document XML ntr-un alt format. Formatul
de iesire poate fi tot XML (de exemplu XHTML sau WML) sau alt format text.
Pentru producerea unei transformari este nevoie de trei elemente:
Sursa transformarii, documentul XML de intrare
Specificatia transformarii, un document XSLT
Motorul transformarii, un program numit procesor XSLT. Acest program aplica
specificatia XSLT a transformarii, sursei transformarii.
Concepte de baza XSLT:
Documentul XML furnizat ca intrare a unei transformari XSLT este de forma unui arbore.
XSLT modeleaza un document sub forma de arbore, similar cu XPath. XPath este un limbaj
195
de expresii pentru adresarea unei parti dintr-un document XML.
XPath i XSLT recunosc 7 tipuri de noduri ale arborelui unui document XML de intrare: i)
Radacina documentului: este nodul de start al oricarui document; ii) Element: reprezinta un
element al sursei XML. iii) Text: reprezinta un coninut text dintr-un element al sursei XML.
iv) Atribut: reprezinta un atribut al unui element din sursa XML; v) Spatiu de nume: vi)
Comentariu: vii) Instructiune de prelucrare: reprezinta textul unei instructiuni de prelucrare
din sursa XML.
Pe multimea nodurilor unui document este definita o relatie de ordonare liniara numita
ordinea documentului. In esenta aceasta ordine exprima urmatoarele: i) nodul radacina este
primul; ii) nodurile element apar naintea copiilor lor; iii) atributele i spatiile de nume
asociate unui element apar naintea copiilor elementului respectiv; iv) spatiile de nume
asociate unui element apar naintea atributelor elementului respectiv.v) ordinea relativa a
spatiilor de nume i a atributelor unui element este dependenta de implementare.
Pentru fiecare nod se defineste o valoare a nodului. De exemplu, pentru nodul radacina
valoarea se obine concatenand coninutul tuturor nodurilor descendente de tip text.
Modelul de prelucrare folosit de XSLT este urmtorul:
O transformare XSLT descrie o multime de reguli pentru transformarea unui arbore de intrare
ntr-un arbore de iesire. O regula conine o parte de conditii, numita sablon (engl.pattern) i
un tipar (engl.template). Sablonul este identificat cu nodurile arborelui sursa. n cazul unei
identificari (engl.matching), tiparul este instantiat i astfel el genereaza o parte din arborele
documentului de iesire.
Prelucrarea unui arbore sursa se bazeaza pe parcurgerea recursiva a arborilor:
Prelucrarea de baza este aplicarea regulilor unei multimi de noduri din arborele sursa.
Procesul ncepe prin aplicarea regulilor listei de noduri formata doar din nodul radacina.
Se obine un arbore de iesire prin aplicarea regulilor unui singur nod din arborele sursa. n
cazul aplicarii regulilor unei liste de noduri, portiunea care rezulta din arborele de iesire se
obine prin concatenarea arborilor obinuti prin aplicarea regulilor fiecarui nod din lista.
Aplicarea regulilor unui nod presupune determinarea nodurilor din subarborele sau carora
li se poate aplica cel putin o regula, potrivit ordinii documentului. Dac pentru nodul
selectat se pot aplica mai multe reguli, pentru a determina regula aplicabila se foloseste o
strategie de rezolvare a conflictelor bazata pe specificitate. Regula cu partea de conditii
este cea mai specifica va fi selectata. Nodul caruia i se aplica regulile devine nodul curent,
iar lista de noduri din care a facut parte cand fost selectat este lista nodurilor curente.
Un tipar poate conine instructiuni pentru selectarea altor noduri carora li se vor aplica
regulile de transformare. Dac lista acestor noduri este nevida, atunci procesul de aplicare
a regulilor coninua recursiv pentru aceasta lista pana cand nu se mai selecteaza noduri noi
pentru prelucrare.
abloane n XSL
Un document XSLT conine reguli de transformare. O regula de transformare are sintaxa
urmatoare:
<xsl:template match="sablon">
tipar
</xsl:template>

Specificarea sablonului se face cu atributul match i se aplic urmtoarele reguli:
Identificarea nodului radacina al documentului se face cu sablonul /.
Identificarea unui element se face cu un sablon identic cu numele elementului.
Identificarea unui element arbitrar se face cu sablonul *.
Identificarea elementelor copil ale unui anumit element se face utilizand un sablon de
196
forma parinte/copil. Mai general, se poate folosi un ablon de forma e
1
/e
2
//e
n
. El
identifica elementele e
n
care au un lant de stramosi de forma e
1
, e
2
, , e
n-1
. Oricare dintre
e
i
poate fi *. Un ablon de forma /e
1
/e
2
//e
n
identifica un lant de stramosi ce incepe din
radacina.
Identificarea elementelor descendent ale unui anumit element se face cu un sablon de
forma stramos//descendent.
Identificarea unui atribut se face cu un ablon de forma @atribut. Identificarea unui nod
text, comentariu sau instructiune de prelucrare se face cu sabloane de forma text(),
comment() respectiv processing_instruction().
Identificarea dup unul din mai multe sabloane posibile se face cu un sablon de forma s
1
|
s
2
| ... | s
n
.
abloane cu teste:
Pe un nod se pot face teste suplimentare adugnd la un ablon un test de forma [conditie].
Identificarea unui element cu un atribut se face cu un ablon de forma: element[@atribut].
Identificarea unui element cu un atribut cu o anumit valoare se face cu un ablon de forma
element[@atribut="valoare"].
Identificarea unui element e prin poziia sa n lista nodurilor frate care sunt elemente e se
face cu un ablon de forma element[pozitie] sau element[position()=pozitie].
Testele se pot ncuiba. De exemplu element[copil[@atribut]] identific un element care are
un element copil cu un anumit atribut.
ntr-un test se poate folosi i operatorul not. De exemplu, ablonul e[not last()] identifica
toate elementele e care nu sunt ultimele n lista nodurilor frate care sunt elemente e.
Testele pe un nod se pot combina cu caile de noduri pentru a construi abloane complexe.
De exemplu, e[@a="valoare"]//e
2
identific elementele e
2
care sunt descendente ale unor
elemente e
1
cu atributul a cu valoarea v.

Un exemplu de transformare trivial ce poate fi aplicat oricrui document XML, cu acelai
rezultat, generarea textului Ceva banal, este urmtorul:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform
version="1.0">
<xsl:template match="/">
Ceva banal.
</xsl:template>
</xsl:stylesheet>
xsl:value-of determina valoarea unui nod. Nodul se specifica cu atributul select, relativ la
nodul curent.
xsl:apply-templates determina aplicarea recursiva a regulilor de transformare unor noduri
selectate cu atributul select, relativ la nodul curent identificat.
Cel mai simplu exemplu este regula implicita pentru nodul radacina, respectiv pentru fiecare
element din documentul sursa:
<xsl:template match="/ | *">
<xsl:apply-templates/>
</xsl:template>
Aceast regul are ca efect aplicarea regulilor copiilor nodului radacina i copiilor tuturor
nodurilor element.
xsl:value-of se va folosi direct doar n contexte n care este evident nodul a carui valoare
va fi selectata. n cazul n care pot fi selectate mai multe noduri, numai valoarea primului dintre
ele va fi generata.
n cazul n care trebuie generate valorile nodurilor selectate, exista doua solutii:
197
Generarea unui apel recursiv folosind xsl:apply-templates.
<xsl:template match="parinte">
<xsl:apply-templates select="copil"/>
</xsl:template>
<xsl:template match="copil">
<xsl:value-of select="."/>
</xsl:template>
Folosirea xsl:for-each realizand astfel prelucrarea explicita a fiecarui nod selectat.
<xsl:template match="parinte">
<xsl:for-each select="copil">
<xsl:value-of select="."/>
</xsl:for-each>
</xsl:template>

Expresii XPath
xsl:apply-templates, xsl:value-of i xsl:for-each folosesc atributul select pentru selectarea
unei multimi noduri ce fac obiectul unor prelucrari. Atributul select apare de asemenea i n
xsl:copy-of, xsl:variable, xsl:param i xsl:sort.
Valoarea atributului select este o expresie XPath. abloanele de identificare a nodurilor
sunt o submultime a multimii expresiilor XPath.
O expresie XPath este de unul din urmatoarele 4 tipuri: multime de noduri, logic, numar, sir de
caractere.
O expresie care selecteaz o multime de noduri se numeste expresie cale (engl.location
path). O cale este compusa dintr-un numar de pasi (engl.location step). Un pas are un nod
context. Fiecare subcale selecteaza o multime de noduri relativ la un nod context. Fiecare nod din
aceasta multime este nod context pentru pasul urmator.
Un pas se compune din 3 componente:
O axa ce specifica relatia dintre nodurile selectate de pas i nodul context.
Un identificator de nod care specifica tipul i numele nodurilor selectate
Zero sau mai multe predicate care pot filtra suplimentar multimea de noduri selectate.





198
BIBLIOGRAFIE


Baze de date
1. Codd, E.F., The Relational Model for Database Management, Addison-Wesley, 1990
2. Date, C.J., An Introduction to Database Systems, Addison-Wesley, Boston, 2004
3. Dolliner, R., Baze de Date i Gestiunea Tranzaciilor, Editura Albastr, Cluj, 1997
4. Forta, B., SQL pentru nceptori, (SAMS) Teora, 2002 (traducere Daniel Cihodaru,
dup ediia din 1999)
5. Fotache, M., Proiectarea bazelor de date. Normalizare i postnormalizare. Implementri
SQL i Oracle, Ed. Polirom, Iai, 2005
6. Ionescu, F., Baze de Date Relaionale i Aplicaii, Editura Tehnic, Bucureti, 2004
7. Oppel, A., SQL fr mistere, Ed. Rosetti Educational, Bucureti, 2006
8. Peterson, J., Baze de date pentru nceptori, Ed. All, 2003
9. Welling, L., Thomson, L., Dezvoltarea aplicaiilor cu PHP i MySQL, Teora, Bucureti,
2005
10. *** Sistemul de gestiune SQL Server, http://www.microsoft.com/sql
11. *** Sistemul de gestiune MySQL , http://www.mysql.com

Programare orientat obiect i structuri de date
12. C. Bologa, Algoritmi i structuri de date, Editura RISOPRINT, Cluj-Napoca, 2005
13. A. Carabineanu, Structuri de date, Editura Matrixrom, 2006
14. V. Creu, Structuri de date i algoritmi, Editura Orizonturi universitare, Timioara, 2000
15. J. Knuth, Arta programrii calculatoarelor, Editura Teora, 1999
16. I. Ignat, C.L.Ignat, Structuri de date si algoritmi , ed. Albastra, Cluj, 2007
17. I. Ivan, M. Popa, P. Pocatilu, (coordonatori), Structuri de date. Tipologii de structuri de
date, Editura ASE, 2009
18. G. Soava, Programare orientat obiect, Teorie i aplicaii, Ed. Universitaria, Craiova,
2010
19. F. Wempen, Visual Studio 9, Editura Teora, Bucureti, 2007

Sisteme de operare
20. Acostchioaie D., Administrarea i configurarea sistemelor Linux, ediia a II-a, Ed.
Polirom, Iai, 2003
21. Acostchioaie D., Buraga S.,Utilizare Linux. Noiuni de baz i practic, Ed. Polirom,
Iai, 2004
22. Cristea V., .a., UNIX, Ed. Teora, Bucureti, 1993
23. Ignat I., .a., Sistemul de operare UNIX. Gestionarea fiierelor., Ed. MicroInformatica,
Cluj-Napoca, 1992
24. Ignat I., Kacso A. , UNIX Gestiunea proceselor, Ed. Albastr, Cluj-Napoca, 1995
25. Pilat F., UNIX, Ed. Teora, Bucureti, 1992
26. Tanenbaum A. S., Modern Operating Systems, Prentice Hall, 2001
27. Wielsch M., Le grand livre de UNIX, Editions MicroApplication, Paris, 1994
28. *****, http://www.redhat.com
29. *****, http://metalab.unc.edu/pub/Linux/docs

Proiectarea sistemelor informatice
30. Zaharie, D., Rosca, I., Proiectarea obiectuala a sistemelor informatice, Dual Tech,
Bucuresti, 2002
31. Oprea, D., Analiza si proiectarea sistemelor informationale economice, Editura
Polirom, Bucuresti, 1999
199
32. Lungu, I., Sabau, Gh. s.a., Sisteme informatice - Analiza, proiectare si implementare,
Editura Economica, Bucuresti, 2003
33. Stanciu V., Proiectarea sistemelor informatice de gestiune, Ed. Cison, Bucureti 2000
34. C. J. Date, An Introduction to Database Systems, 8th Edition, published by
PearsonEducation, Inc. Adison Wesley Higher Education, 2004

Programare Internet
35. T. Anghel, Programarea in PHP. Ghid practic, Editura Polirom, 2005
36. F. M. Boian, R. F. Boian, Tehnologii fundamentale Java pentru aplicatii Web, Editura
Albastra, 2009
37. S.C.Buraga, Proiectarea siturilor Web. Design si functionalitate, Editura Polirom, 2006
38. S.Buraga, Programarea in Web 2.0, Editura Polirom, 2007
39. S. Buraga, Tehnologii XML, Editura Polirom, 2006
40. S. C. Buraga , Tehnologii Web, Editura MATRIX ROM, Bucureti, 2001
41. Coulouris, G., Dollimore, J, Kindberg, T, Distributed Systems. Concepts and Design
(3rd ed.), Pearson Education, 2001
42. L.Sngeorzan, C. L. Aldea, Tehnologii internet, Ed. Univ. Transilvania, 2003
43. Ceri , Stefano et al, Designing Data-Intensive Web Applications, Morgan Kaufmann,
2002
44. S Tudor, V. Huanu, Crearea si programarea paginilor WEB, ed. L&S SOFT, 2006