I. CONCEPTE ALE BAZELOR DE DATE RELAIONALE 1.1 Definiii 1.2 Niveluri de abstractizare a datelor 1.

3 Componente ale bazelor de date relaionale 1.4 Proiectarea bazelor de date relaionale. Etape. Normalizarea bazelor de date 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 - dotabase 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 urmtoarele: 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.
1

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.2 Niveluri de abstractizare a datelor

ntr-un sistem informatic ce utilizeaz baze de date, 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 (fig. 1.1).

Nivelul fizic (intern)

Structura datelor este descris foarte detaliat, fiind accesibil numai 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 bazei de date se concretizeaz n schema intern.

Nivelul conceptual (global)

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 de date 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 bazei de date se concretizeaz n schema conceptual.
N iv e l e x te rn N iv e l c o n c e p tu a l N iv e l in te rn

G ru p 1

G ru p n

S c h e m a c o n c e p tu a la S c h e m a in te rn a

M e d iu l d e sto c a re

Fig. 1.1 Niveluri de abstractizare a datelor

2

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. Dac la nivelul 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 ce atribuii au. Simplificarea interaciunii utilizatori baz de date, precum i creterea securitii bazei de date sunt deziderate ale unui nivel superior de abstractizare, care este nivelul extern. Astfel, structura bazei de date se prezint sub diferite machete, referite uneori i ca subscheme, scheme externe sau imagini (view-uri), n funcie de nevoile fiecrui utilizator sau grup de utilizatori. Observaii: Este important aceast organizare pe trei niveluri pentru c explic conceptul de independen a datelor, prin posibilitatea de modificare a sistemului bazei de date la orice nivel fr a avea influen la nivelele superioare. Independena datelor se poate defini n dou moduri, ce sunt aferente nivelelor conceptual i intern. Prin independena logic se nelege capacitatea schimbrii schemei conceptuale, fr a atrage dup sine schimbri in schema extern sau n programele de aplicaii. Este posibil schimbarea schemei conceptuale prin expandarea bazei de date ca urmare a adugrii de noi tipuri de nregistrri sau a datelor nsi, sau prin reducerea bazei de date ca urmare a reducerii nregistrrilor. Independena fizic este reprezentat prin capacitatea de schimbare a schemei interne fr schimbarea schemei conceptuale sau externe. Schimbarea schemei conceptuale poate surveni ca urmare a reorganizrii fizice a unor fiiere, prin crearea de noi structuri de acces menite s asigure accesul eficient la date. Accesul utilizatorului la informaiile din baza de date este posibil numai prin intermediul sistemului de gestiune a bazei de date (SGBD).

1.3 Componente ale bazelor de date relaionale

1. Tabele 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. 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
3

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). 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.
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

Fig. 1.2 Diagrama ERD a bazei de date pentru magazinul de produse video (prezentare parial) 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.

Relaie de tip 1 la 1

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.

a)

b)
Relaie de tip 1 la m (a) i m la 1 (b)

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.

Relaie de tip m la m

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'sfoot) - 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.
5

Toate relaiile din fig. 1.2 sunt obligatorii n partea unu" i opionale n partea mai 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. 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
6

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 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.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, 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
8

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; 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
9

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. 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.

10

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. Scopul procesului de normalizare este de a elimina aceste probleme (anomalii) din proiectul bazei de date. Acestea sunt: - Anomalia de inserare - Anomalia de tergere - Anomalia de actualizare 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. 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. Anomalia de actualizare Anomalia de actualizare se refer la o situaie n care actualizarea unei singure valori necesit actualizarea mai multor rnduri. 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
11

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. 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. 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
12

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 s nlocuii 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 paii 2 i 4. 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. 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. n esen, amestecm 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 (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. 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. 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)
13

este, de fapt, dependent tranzitiv de celelalte dou atribute.

II. SISTEME INFORMATICE INTEGRATE 2.1. Definiii

n condiiile actuale ale globalizrii afacerilor, mediul organizaional al unei firme trebuie s se adapteze cerinelor concureniale ale pieei. Creterea economic a unei firme depinde n mod esenial de abilitatea ei de a actualiza i integra, personaliza i extinde aplicaiile informatice, ntr-un mod flexibil i rapid, oferind tuturor utilizatorilor acces instantaneu, interactiv i consistent la modelul su de date. De asemenea, pentru asigurarea eficienei activitii lor, firmele trebuie s standardizeze gestiunea proceselor economice. Se afirm c integrarea complet este un obiectiv major al gestiunii resurselor informaionale, care devin din ce n ce mai complexe i mai numeroase i de aceea este necesar s se realizeze i s se implementeze sisteme informatice integrate. n cele ce urmeaz vom prezenta cteva accepiuni ale acestui concept. O prim accepiune a noiunii de sistem informatic integrat este dat n Hotrrea de Guvern nr. 841/1997, unde prin sistem informatic integrat se nelege un sistem informatic care ndeplinete urmtoarele condiii: utilizeaz o baz de date unic; are n componen programe informatice, care cuprind activitile tuturor compartimentelor funcionale ale firmei, conform organigramei acesteia; exist un plan de securitate al sistemului informatic, care cuprinde msuri tehnice i organizatorice corespunztoare. Pentru realizarea acestor obiective, se deruleaz diverse proiecte de integrare informaional. Derularea unui asemenea proiect nu este o activitate deloc simpl, ci reprezint o adevrat provocare tehnologic, att pentru proiectani, ct i pentru firme. De-a lungul existenei sale, o firm achiziioneaz sau dezvolt prin fore proprii mai multe aplicaii informatice, menite s-i satisfac cerinele, legate de diversificarea ori extinderea activitilor sale. Fiecare dintre aceste aplicaii rspunde unei probleme concrete sau acoper un anumit proces economic, fr s in seama de lanul de procese sau de legturile cu celelalte aplicaii informatice implementate n respectiva firm. n faza de nceput a informatizrii activitilor, mai ales din considerente de ordin financiar, firmele decid n general s achiziioneze sau s dezvolte prin fore proprii o serie de aplicaii informatice pentru activitile de contabilitate, apoi pentru cele financiare, de salarizare a personalului, aprovizionri etc., fr nici o legtur ntre aceste aplicaii. n etapa a II-a se ncearc construirea unor legturi ntre aceste aplicaii, legturi concretizate n interfee personalizate, care i propun realizarea integrrii ntre dou sau mai multe aplicaii. Fiecare dintre aplicaii folosete n continuare baza sa de date proprie, ceea ce nseamn redundan (aceleai date) i surs de inconsisten (datele comune trebuie actualizate separat, ceea ce nseamn eforturi suplimentare i posibilitatea apariiei unor neconcordane). ntr-o etap urmtoare a procesului de integrare s-a trecut la implementarea pachetelor ERP (Enterprise Ressource Planning). Aprute n anii 90, ele au devenit o prezen obinuit n marile corporaii i n companiile multinaionale. A doua jumtate a ultimului deceniu din secolul 20 a
14

nsemnat deschiderea aplicaiilor de tip ERP pentru segmentul ntreprinderilor mici i mijlocii. n perioada actual, succesul implementrii pachetelor ERP n IMM-uri depinde i de msura n care ele permit integrarea altor categorii de sisteme, cum ar fi cele privind soluiile de tip Customer Relationship Management (CRM), SupplyChain Management (SCM), Business Intelligence (BI), precum i cele specifice utilizrii Internet-ului. Un alt factor mobilizator n procesul extinderii sistemelor integrate l-a reprezentat creterea fr precedent a activitilor de comer i colaborare electronic (e-commerce i e-business). Definiia i evoluia integrrii Integrarea este o activitate ce reunete oameni, echipamente, programe, dar i practici manageriale. Integrarea aplicaiilor este o abordare strategic de a lega mai multe sisteme informatice, la nivel de informaii i servicii, astfel nct sistemele sunt capabile s fac interschimb de informaie i s asigure o funcionare a proceselor n timp real . Integrarea aplicaiilor software n cadrul unei ntreprinderi sau ntre mai multe ntreprinderi care colaboreaz este un subiect de mare actualitate. Integrarea aplicaiilor software de ntreprindere permite coordonarea i sincronizarea mai multor aplicaii eterogene, att n interiorul (integrarea aplicaiilor la nivel de companie), ct i n afara ntreprinderilor (integrarea aplicaiilor Business-toBusiness - B2B). Denumit n limbajul de specialitate EAI (Enterprise Application Integration), integrarea aplicaiilor la nivel de companie reprezint, de fapt, noul stil de lucru n domeniul software. ntreprinderile au din ce n ce mai puini informaticieni care concep i scriu aplicaii i din ce n ce mai muli care integreaz aplicaii. Entitatea ce trebuie integrat nu mai este un obiect sau o component software, ci este o aplicaie software. Prin EAI, sistemele informatice ale ntreprinderilor se muleaz din ce n ce mai bine pe structura procesului de afaceri. Complexitatea problemelor legate de infrastructura informatic crete i mai mult n cazul unei ntreprinderi virtuale, format din module (secii, departamente, birouri etc.), cu funcionalitate extrem de divers i grad de dispersie geografic orict de mare. Granularitatea modulelor se poate situa pe o scar foarte cuprinztoare, depinznd n mare msur, att de specificul domeniului de activitate, ct i de posibilitile de organizare ale ntreprinderii respective. n contextul actual n care informaia este privit ca o resurs strategic a ntreprinderii, a crescut foarte mult importana integrrii sistemelor informatice care s faciliteze utilizarea n comun a datelor i micarea lor n cadrul ntreprinderii. La nivelul anului 1999 s-a estimat c peste o treime din bugetul din industria IT a avut ca destinaie proiectarea, realizarea i ntreinerea unor soluii de integrare a sistemelor informatice. Dar, cele mai multe dintre aceste soluii au optat pentru varianta de integrare punct la punct, i s-au dovedit a fi mari consumatoare de resurse. Dezvoltarea unei strategii eficiente de integrare a sistemelor informatice la nivelul ntreprinderii este una dintre cele mai complexe probleme ntmpinate de managerii IT. Complexitatea acestei probleme rezid n principal din faptul c cele mai multe dintre aplicaii au fost dezvoltate fr a se urmri o arhitectur a sistemelor informatice sau o strategie de dezvoltare a acestora. nceputul integrrii n domeniul IT poate fi considerat momentul apariiei circuitului integrat n 1959, care a reunit alte descoperiri cum ar fi: tranzistorii, rezistenele i capacitorii pe un singur chip de silicon. n 1965 Gordon Moore, unul din fondatorii Intel prezicea c numrul de tranzistori pe un microchip se va dubla la fiecare 18 luni. Aceast lege, nc este surprinztor de adevrat i acum, la peste 40 de ani de la formularea ei. Acesta poate fi motivul pentru care avem nevoie de integrare:
15

pentru a ne descurca n condiiile unei complexiti crescute. Principiile managementului complexitii sunt: descompunea n pri mai mici i mai uor de manipulat, construirea unei interfee standard pentru ca aceste pri s comunice i apoi dezvoltarea unei structuri ierarhice unde informaia este din ce n ce mai abstractizat odat ce urcm n ierarhie. Termenul de middleware a aprut la sfritul anilor 80 pentru a descrie un software de management al reelelor, dar a fost larg folosit ncepnd cu 1995. Middleware-ul a evoluat ntr-un set de reguli i capabiliti, care facilitau construirea de aplicaii distribuite. Acest termen a fost legat de bazele de date relaionale i desemna o integrare bazat pe mesaje. Informatizarea, dezvoltarea economic global, specifice nceputului de secol XXI, au accentuat tendina de organizare a sistemelor informaionale n modele din ce n ce mai complexe. Prin integrare crete precum am artat complexitatea, dar i calitatea, pentru c reuniunea sistemelor presupune adugarea de componente evolutive i emergente. Dac organizarea duce la integrare i integrarea duce la complexitate, aceasta din urm determin la rndul ei diversificarea. Din punct de vedere al diversitii, integrarea este efectul evoluiei ciclice i progresive a unui mix de tehnologii i este sprijinit de performanele i de expertiza profesionitilor. Integrarea aplicaiilor poate lua mai multe forme: integrarea intern a aplicaiilor integrarea aplicaiilor la nivel de companie; integrarea extern a aplicaiilor integrarea aplicaiilor Business-to-Business. Cele dou tipuri de integrri au multe elemente comune. De exemplu, ntotdeauna vor exista: o transformare de tehnologie care va face diferena ntre semantica aplicaiilor, tehnologia de router prin care se va asigura c informaia ajunge la destinaia corect i reguli de procesare pentru a defini comportamentul de integrare. Strategia IT este necesar s fie cunoscut de toi factorii care influeneaz deciziile de integrare a proceselor economice cum ar fi configurarea proceselor economice, frontierele acestora i locul n care schimbarea este cel mai probabil a se produce. nelegerea scopurilor economice, cum ar fi strategiile de fuzionare i de achiziie sau cost i creterea eficienei, apare ca o cheie fundamental. Trebuie stabilit o perspectiv comun intern i extern a nucleului economic, de informaie i de procese, pentru a nelege relaiile i interfeele ntre unitile economice, sau a partenerilor comerciali. Trebuie stabilite problemele proprietii pentru aplicaii, componente, infrastructura integratoare, interfeele externe etc. i acestea pot fi unele dintre cele mai dificile sarcini i pot traversa actualele frontiere organizaionale i responsabilitatea acestora. O tendin n evoluia integrrii sistemelor este trecerea de la integrarea bazat pe informaie la integrarea bazat pe servicii. Integrarea bazat pe informaii ofer un mecanism ieftin de a integra aplicaii deoarece, n cele mai multe cazuri, nu este nevoie ca aplicaia s fie modificat. Cu toate c, acest tip de integrare ofer o soluie funcional pentru multe domenii ale problematicii de integrare a aplicaiilor, integrarea bazat pe servicii ofer mai mult valoare pe termen lung. Definiia i rolul sistemelor informatice integrate Def. Sistemele informatice integrate desemneaz sisteme complete, cu procese de afaceri, practici manageriale, interaciuni organizaionale, transformri structurale i management al cunotinelor. Un sistem de aplicaii integrat trebuie s reprezinte soluia pentru orice instituie care necesit
16

un sistem informatic modern, indiferent dac acesta automatizeaz procesele interne din cadrul organizaiei, relaiile cu clienii sau pe cele cu furnizorii i partenerii. Adoptarea unor aplicaii disparate pentru diferite activiti ale fluxului de afaceri, poate reprezenta o soluie bun pentru moment, dar care poate genera mari probleme legate de fragmentarea informaiei i dezvoltarea ulterioar a sistemelor, prin ncercarea de a integra soluii ulterioare. Productorii de software care ofer aplicaii ce ruleaz pe multiple surse de date sau care nu acoper toate sectoarele fluxurilor de afaceri, nu furnizeaz pachete de soluii integrate, ci mai degrab colecii separate de aplicaii, bune s rezolve problemele cerute de sisteme disparate, dar care nu reuesc s funcioneze mpreun. Principala problem a falselor pachete de aplicaii este fragmentarea informaiei, generat de sisteme disparate. Consolidarea informaiilor venite de la un mare numr de surse este laborioas i costisitoare. O alt mare problem este automatizarea incomplet, care nu acoper toate procesele afacerii, rezultnd sisteme discontinue, ce ofer funciuni analitice doar la nivel departamental, incapabile s asigure o viziune unitar asupra organizaiei. n aceste condiii, managerul instituiei nu are la dispoziie dect piese dintr-un puzzle, care rareori se mbin. Pentru a face saltul calitativ de la aciuni punctuale la procese de afacere, organizaiile trebuie s adopte soluii integrate i colaborative, care s se adapteze strategiilor de distribuie i care s includ i funcionaliti de suport decizional. Un adevrat pachet integrat are aplicaiile proiectate de la nceput pentru a lucra mpreun: acestea partajeaz acelai model de informaii i informatizeaz procesele de business la nivelul ntregii organizaii. Principalele avantaje pe care o suit de aplicaii integrate trebuie s le ofere beneficiarilor sunt: reducerea costurilor pe termen lung; creterea eficienei operaionale; returnarea rapid a investiiilor n IT; migrarea mai rapid la modele de e-business Pentru a nelege rolul jucat de un sistem informatic integrat n funcionarea unei organizaii, este necesar s se porneasc de la modelul general de organizare a unei afaceri, corespunztor majoritii ntreprinderilor de producie, comer, servicii sau a unora din sectorul financiar-bancar. Conform acestui model, orice ntreprindere este constituit din urmtoarele zone: a. Zona Back Office Din punct de vedere informatic, aceast zon se caracterizeaz prin: Importana fundamental a bazei de date, care poate fi situat centralizat pe un singur server sau poate fi repartizat fizic pe mai multe servere; Particularitile aplicaiilor utilizate: o parte important dintre acestea reprezint programe pentru tratarea n bloc a datelor (de exemplu, tratarea n bloc a tuturor tranzaciilor unei zile de lucru). O alt parte a aplicaiilor realizeaz gestiunea tranzaciilor i au ca scop tratarea simultan a unor cereri din partea unui numr mare de utilizatori; Importana critic a prelucrrilor realizate, de care depinde ntreaga activitate a ntreprinderii; Centralizarea pe un numr redus de servere pe care ruleaz sisteme de operare dedicate. Cea mai apreciat calitate a unui sistem de Back Office o reprezint coerena i integritatea datelor. De asemenea, disponibilitatea continu a sistemului i continuitatea serviciilor (chiar i n caz
17

de cderi sau defeciuni) sunt caracteristici eseniale ale oricrei aplicaii Back Office. n cazul ntreprinderilor moderne, aplicaiile Back Office garanteaz nsi funcionarea ntreprinderii, de aceea se impune existena unui sistem de nalt securitate a datelor, att la nivel fizic, ct i la nivelul drepturilor de acces. b. Zona Front Office Aplicaiile Front Office sunt acele produse pe care ntreprinderea le ofer clienilor astfel nct s asigure servicii rapide. Principalele cerine la care trebuie s rspund o aplicaie Front Office sunt: Gestiunea relaiilor cu clienii (Customer Relationship Management, CRM) cuprinde instrumente de administrare a clienilor (consultarea dosarelor clienilor, culegerea de informaii referitoare la operaiile efectuate de clieni pentru a le trimite spre procesare aplicaiilor Back Office), precum i instrumente de asistare a clienilor (evaluarea n funcie de o serie de criterii, asisten n configurarea cererii i alte forme de asistare interactiv a clienilor). Evaluarea clienilor dup o serie de criterii (scoring) permite stabilirea gradului n care un client sau un proiect poate satisface sau nu condiiile prevzute (de exemplu, pentru acordarea unui credit). Aplicaiile de asisten n configurarea cererii au ca scop propunerea, pe baza catalogului furnizorului i a rspunsurilor la un set de ntrebri, variantele de ofert cele mai adecvate la cererile exprimate de client; Gestiunea agenilor de vnzri are ca scop gestiunea agenilor de vnzri sub mai multe aspecte: cota din vnzrile totale, performanele, realizarea cifrei de afaceri individuale i colective, obinerea rezultatelor consolidate etc; Gestiunea clienilor face parte din aplicaiile Front Office puse la dispoziia centrelor de asisten din teritoriu i utilizeaz tehnologii de integrare cu reeaua telefonic; Instrumente de asistare a deciziei reprezint o consecin a prezenei celorlalte tipuri de aplicaii menionate la nivelul fiecrei agenii sau centru de vnzri. Sunt avute n vedere instrumente de cutare i extragere de date, precum i aplicaii SIAD (Sistem Interactiv de Asistare a Deciziei); Gestiunea reelei de agenii este un complement al aplicaiilor Back Office aprut datorit numrului mare de agenii i centre de vnzri ale ntreprinderilor mari, mai ales multinaionale. Aceast reea poate cuprinde sucursale proprii, concesionari sau ali ageni comerciali. n ultima vreme, acestor dou zone ale ntreprinderii li s-au mai adugat altele dou: c. Zona Middle Office Este o zon greu de definit la nivel fizic, care a primit n timp dou accepiuni diferite: ntr-o prim accepiune, aceasta reprezint zona de Back Office prezent n cadrul fiecrei agenii sau centru de vnzri, zona situat fizic n Front Office, dar ndeplinete funcii de Back Office; n a doua accepiune, aceasta reprezint componentele intermediare ale ntreprinderii, cu rol de interfa ntre Front Office i Back Office, pentru gestiunea reelei i transmiterea datelor ctre aplicaiile centrale (aflate n Back Office). Din punct de vedere informatic, aplicaiile de tip Middle Office sunt cele care alimenteaz componentele menionate anterior. n condiiile dezvoltrii unei arhitecturi client-server pe trei nivele (server central, servere agenie i staii de lucru), componentele Middle Office ale sistemelor informatice se pot gsi att pe serverele de agenie, ct i pe serverul central. d. Zona Web Office Procesarea tranzaciilor generate de serviciile la distan s-a realizat mult vreme separat de
18

restul sistemului informatic. n prezent, tehnologia World Wide Web a introdus o nou dimensiune a ntreprinderii, numit generic Web Office, care completeaz Front Office i Back Office i d posibilitatea conectrii la sistemul informatic al ntreprinderii din orice punct de pe glob. Prin Web Office se integreaz mai multe tipuri de aplicaii: Aplicaii interne ale ntreprinderii destinate exclusiv personalului din ntreprindere, accesul din afar fiind oprit n general prin aplicaii de tip firewall. Aceste aplicaii pot furniza servicii multiple: coordonarea i gestiunea proiectelor, mesagerie intern, agend de grup, diverse tipuri de urmrire la distan a activitii, videoconferin, etc. Se folosesc tehnologii intranet care presupun utilizarea tehnologiilor internet mpreun cu produse de securitate care s protejeze domeniul i s blocheze accesul neautorizat din interior sau din afar; Aplicaii accesibile partenerilor destinate partenerilor n sens larg (furnizori, clieni, reseller-i, consultani etc.) utilizeaz servere extranet i ofer servicii echivalente cu aplicaiile interne, dar destinate utilizatorilor externi ai ntreprinderii; Aplicaii accesibile publicului larg asigur accesul public la serviciile ntreprinderii, serverele internet realiznd o extindere a activitii ntreprinderii spre staiile de lucru ale partenerilor prin intermediul cataloagelor on-line cu imagini ale produselor, plilor securizate prin carte de credit sau portofel electronic etc. Nivelul de securitate al componentelor intranet, extranet i intranet este diferit, dar nu trebuie neglijat pentru nici una dintre aceste trei zone. Este de dorit s se asigure protecia datelor de consultat i s se identifice n orice moment persoanele care navigheaz. Acest lucru poate fi realizat prin oferta de abonamente pentru accesul la informaii, abonamente care pot fi gratuite sau nu, n funcie de serviciile oferite. Sistemele informatice de gestiune sunt definite n literatura de specialitate urmrindu-se dou abordri: a) plecnd de la informaie i de la suportul acesteia; b) plecnd de la funcia pe care sistemul informatic de gestiune trebuie s o realizeze. n primul caz, sistemele informatice de gestiune reprezint ansamblul informaiilor utilizate n cadrul firmei, a mijloacelor i procedurilor de identificare, culegere, stocare i prelucrare a informaiilor. n cea de a doua abordare a definirii sistemelor informatice de gestiune se pornete de la scopul acestora i anume oferirea informaiei solicitate de utilizator n forma dorit i la momentul oportun n vederea fundamentrii deciziilor. Def: Sistemul informatic de gestiune asigur obinerea i furnizarea informaiei solicitate de utilizator, folosind mijloacele TI, pentru fundamentarea deciziilor privind un anumit domeniu din cadrul firmei. Sistemele informatice de gestiune (SIG) presupun definirea: domeniilor de gestiune, datelor, modelelor, regulilor de gestiune. Domeniile de gestiune corespund fiecreia dintre activitile omogene desfurate n cadrul firmei - cercetare-dezvoltare, comercial, de producie, de personal, financiar-contabil cu luarea n considerare a interaciunilor dintre ele. Mai mult, abordarea acestor domenii se realizeaz ntr-o viziune ierarhic conducnd la identificarea urmtoarelor nivele: o Tranzacional n cadrul cruia se efectueaz operaii elementare;
19

o Operaional unde se desfoar operaii curente, deciziile luate la acest nivel sunt curente, de rutin; o Tactic corespunznd activitilor de control i deciziilor pe termen scurt; o Strategic caracteristic deciziilor pe termen lung i/sau care angajeaz global firma. Datele reprezint materia prim a oricrui sistem de gestiune. Sunt avute n vedere toate datele vehiculate i prelucrate indiferent de natura lor, caracterul lor formal sau informal sau de suporturile pe care se afl. Modelele de gestiune regrupeaz procedurile proprii unui domeniu. Putem exemplifica prin modelul: Contabil, specific domeniului financiar-contabil; Tehnologiei de fabricaie specific domeniului produciei; De vnzri specific domeniului comercial. Regulile de gestiune permit prelucrarea datelor i utilizarea informaiilor n conformitate cu obiectivele sistemului. n cadrul unei firme cu activitate de producie i/sau comercial pot fi identificate urmtoarele reguli de gestiune: - aprovizionarea se realizeaz cnd stocul efectiv scade sub stocul normat; - evaluarea materialelor se realizeaz conform metodei FIFO; - o materie prim se stocheaz n una sau mai multe gestiuni; - pentru produsele de calitatea a doua preul se reduce cu 5% etc. n cazul unei bnci, pentru sistemul informatic privind operaiunile de cont curent pot fi precizate urmtoarele reguli de gestiune: - soldul minim 1000 RON ; - plile se efectueaz n limita soldului; - dobnzile calculate pentru conturile la vedere sunt 11% pe an; - pot fi nregistrate maxim dou persoane cu drept de semntur. Prin noiunea de domeniu ajungem la conceptul de subsistem informatic de gestiune determinat pe criterii funcionale, pe care se grefeaz celelalte dou concepte: modelul de gestiune i regulile de gestiune. Sistemele informatice de gestiune actuale sunt sisteme integrate. Ele se caracterizeaz prin aplicarea principiului introducerii unice a datelor i prelucrrii multiple a acestora n concordan cu nevoile informaionale specifice fiecrui utilizator. De exemplu, sistemul informatic integrat al contabilitii se caracterizeaz printr-o introducere unic a datelor, preluate din documentele primare care actualizeaz o baz de date unic a contabilitii care va fi ulterior exploatat pentru asigurarea, att a lucrrilor specifice contabilitii financiare, ct i a celor specifice contabilitii de gestiune, rspunzndu-se astfel cerinelor de prelucrare ale tuturor utilizatorilor. Sistemele informatice din lumea real sunt de fapt combinaii integrate a mai multor tipuri de sisteme informatice. Acestea sunt sisteme informatice bazate pe computere care combin activitile desfurate de mai multe tipuri de sisteme informatice. Cele mai multe sisteme informatice sunt elaborate pentru a produce informaii i pentru a sprijini luarea deciziilor la diferite niveluri ale managementului, dar i pentru inerea de diverse evidene i prelucrare a tranzaciilor.

20

2.2 ERP definiie, arhitectur, funcii

Un ERP, considerat expresia cea mai fidel a interdependenei dintre economic i tehnologia informaional, reprezint o infrastructur software, multi-modular ce ofer suport de gestiune i coordonare a diferitelor structuri i procese din companie, n vederea realizrii obiectivelor de afaceri1. Scopul ERP sistem de gestiune integrat a proceselor de afaceri este realizarea unei mai bune comunicri n companie, mbuntirea cooperrii i interaciunii dintre diferite departamente precum cele de planificare a produciei, achiziii, producie, vnzri i relaii cu clienii. Pe scurt, un sistem informatic de gestiune a companiei de tip ERP reprezint planificarea celor 4 factori determinani pentru o afacere de succes: factorul uman, financiar, tehnic i de resurse (cei 4 M - Man, Money, Machines i Materials)2. Davenport T.H., specialist de renume n domeniile de management i sisteme informaionale pentru afaceri propune ca definiie pentru ERP: un pachet care promite integrarea complet a tuturor informaiilor din cadrul unei organizaii [..]3(figura 1.5.).

Fig. 1.5 Schema conceptual a unui sistem ERP ERP integreaz toate procesele economice: producie, distribuie, contabilitate, financiar, personal, stocuri, service i mentenan, logistic, gestiune de proiecte, oferind accesabilitate, vizibilitate i consisten informaional n ntreaga organizaie. ERP nseamn integrarea tuturor aplicaiilor ntr-o soluie global, acoperind toate procesele intercorelate ce concretizeaz activitatea organizaiei, eliminnd graniele dintre departamente i delimitrile funcionale, ca i pe cele ale organizaiei cu mediul i oferind posibiliti de lucru multiutilizator, multiscop i multispaiu. Def. Un sistem de tip ERP reprezint o soluie software complex, bazat pe arhitectura clientserver ale crei elemente sunt integrate ntr-o platform comun, pentru gestionarea resurselor companiei, prelucrarea tranzaciilor i facilitarea integrrii tuturor proceselor necesare n cadrul unei afaceri, centralizndu-le, facilitnd mprtirea datelor i eliminnd redundana. Fiecare pachet ERP ofer funcionaliti diferite pentru industrii diferite.
1 2

Doina Fotache, Luminia Hurbean Soluii informatice integrate pentru gestiunea afacerilor-ERP-Cap. 1, pag 10 http://www.cio.com/research/erp/ 3 Doina Fotache, Luminia Hurbean Soluii informatice integrate pentru gestiunea afacerilor-ERP-Cap. 1, pag. 18 21

Provocarea principal const n integrarea tuturor proceselor economice i optimizarea resurselor disponibile. Sistemele ERP actuale realizeaz integrarea tuturor funciilor de conducere ale unei companii, plecnd de la: planificare; asigurarea stocului de materii prime i materiale; definirea tehnologiilor; coordonarea proceselor de producie; gestiunea financiar-contabil, a resurselor umane, a stocurilor de produse finite; dezvoltarea i meninerea relaiilor cu clienii i partenerii de afaceri. Un astfel de sistem permite factorilor de decizie realizarea unor analize complete asupra ndeplinirii planului de afaceri. Prin opiunile de simulare a activitilor i prin caracterul flexibil i dinamic al aplicaiilor se pot realiza: planuri de previziune; evaluri i predefiniri ale tendinelor de evoluie ale industriei din care face parte compania; analize calitative; integrarea cu noile tehnologii e-business; comunicare on-line. La implementare, sistemele ERP includ o serie de caracteristici de baz. Sunt instalate pe un sistem de gestiune a bazelor de date. Platformele de baze de date folosite n general sunt: Oracle, DB2, nformix, Microsoft SQL Server, SQL Base, PostgreSQL, Sybase, etc. Baza de date necesit o setare iniial conform proceselor organizaiei i trebuie s asigure acces direct la informaii n timp real (avantajul bazelor de date unice) pentru toi membrii organizaiei. Odat terminat instalarea, utilizatorii introduc datele, informaiile fiind transferate prin intermediul proceselor la alte module. n final, sistemele ERP includ instrumente de raportare periodice sau realizate ad-hoc. Aplicaiile ERP sunt realizate cu ajutorul instrumentelor CASE, care simplific munca programatorilor, prelund regulile i genernd automat codul surs. Avantajele sunt: reducerea timpului de dezvoltare i obinerea unui produs de calitate, prin minimizarea erorilor. n plus, utilizarea instrumentelor CASE sprijin consistena aplicaiilor i standardizarea sub aspect funcional. Sub o form simplificat am putea defini ERP-ul prin prisma a doua proprieti fundamentale: funcionalitatea i integrarea. Cele dou pri se intercondiioneaz reciproc. Integrarea asigur conectivitatea ntre fluxurile de procese economice funcionale. Ea poate fi gndit ca o tehnic de comunicare. Cteva modaliti obinuite prin care comunicarea are loc, prin i pentru integrare, sunt: codul surs, reele locale i extinse de calculatoare, internet, e-mail, workflow, instrumente de configurare automat, protocoale, baze de date. Putem spune c integrarea este realizat prin comunicare, iar comunicarea este realizat prin integrare. Partea funcional a unui sistem ERP asigur fluxurile de procese economice din cadrul fiecrei funciuni. Astfel, n cadrul unei suite ERP se regsesc de la cteva, pn la zeci de module funcionale (contabilitate general, debitori, salarii, stocuri, aprovizionare, planificarea produciei, logistic, comenzi i vnzare)4.

Doina Fotache, Luminia Hurbean Soluii informatice integrate pentru gestiunea afacerilor-ERP -Capitolul 1, pag.22. 22

Arhitectura unui sistem ERP Sistemul aplicaiilor de ntreprindere se implementeaz pe o arhitectura de tip client-server care creeaz premisele unui mediu de prelucrare descentralizat. Modelul de arhitectur implementat de ctre sistemele ERP este cel cu trei straturi, ilustrat n figura 1.6. Caracterizarea funciunilor celor trei niveluri ale arhitecturii: Nivelul prezentare const n interfaa grafic utilizator sau programul de navigare (browser) pentru accesarea funciilor sistemului. Nivelul aplicaie cuprinde regulile afacerii, logica i funciunile sistemului, programele care asigur transferul datelor de / la serverele de baze de date. Nivelul bazei de date asigur gestiunea datelor organizaiei, inclusiv a metadatelor; cel mai adesea se regsete aici un SGBD relaional dintre cele standardizate industrial, care include i modulul SQL. Platformele de baze de date folosite n general sunt: Oracle, DB2, Informix, Microsoft SQL Server, SQL Base, PostgreSQL, Sybase, etc. Aceast structurare logic permite ca interfaa sistemului ERP s ruleze pe calculatorul utilizatorului, prelucrarea s se realizeze pe nivelul de mijloc al serverelor de aplicaii, iar sistemele de baze de date s funcioneze pe al treilea strat, al serverelor specializate.

Fig. 1.6 Arhitectura cu trei straturi a unui sistem ERP Componentele principale ale unui sistem ERP Nomenclatoare (fiiere de baz) de clieni, furnizori, personal, sub forma unor fiiere care reunesc toate datele de descriere a acestora i interfaeaz cu oricare modul care se servete de aceste date; Contabilitate general numit i componenta financiar-contabil pentru c asigur conducerea evidenei contabile i gestiunea financiar. Funcionalitile vizeaz: automatizarea nregistrrii informaiilor financiar-contabile preluate din documentele primare, cu preluarea automat a datelor din alte aplicaii ale sistemului ERP i realizarea evidenei contabile complete, la nivel sintetic i analitic. De cele mai multe ori componenta acoper doar cerinele contabilitii financiare, asigurnd n primul rnd obinerea documentelor contabile de sintez cerute de legislaia n vigoare i poate fi completat printr-o component de analiz, tip tablou de bord, care ofer informaii privind performanele firmei;
23

ncasri-pli. Aceast component poate aprea sub forma a dou module: Debitori i Creditori, care gestioneaz i nregistreaz creanele i datoriile ntreprinderii; Salarizare. Component legat adesea de cea de resurse umane, avnd ca obiect calculul i evidena salariilor. Sunt automatizate calculul taxelor, al contribuiei la bugetul statului i asigurrilor sociale; Resurse umane. Componenta care sprijin crearea unei politici de personal, susinnd activitile de recrutare i selecie a personalului; Imobilizri. Gestioneaz mijloacele fixe, dar i obiectele de inventar sau activele necorporale. Gestiunea acoper ntreaga durat de utilizare a activului i se poate afla n orice moment care este starea acestuia i operaiile efectuate asupra lui (intrare, modernizare, modificare, reevaluare, scoatere din funciune, casare). Ofer multiple posibiliti de calcul i nregistrare a amortizrii (liniar, degresiv, accelerat). Deosebit de utile sunt rapoartele generate, impuse de legislaia n vigoare sau necesare conducerii; Planificare-producie. Planificarea vizeaz executantul, termenul, articole de realizat, costul programat i detaliile tehnice; Urmrire producie (uneori livrat ntr-o singur component mpreun cu Planificarea) nregistreaz preluarea notelor de predare i a rapoartelor de lucru, analizeaz i compar comenzile lansate, ofer rapoarte cumulate ori detaliate ale produciei, pe faze sau pe produse/lucrri, ca i rapoarte de costuri; Gestiune date tehnice - stocheaz definiiile i caracteristicile tehnice ale produselor i tehnologiilor de fabricaie; Planificare necesar de materiale - determin automat cantitile necesare, pe baza datelor despre procesul de fabricaie i a planului de producie aprobat; Planificare i urmrire consumuri i costuri ntocmete bonurile de consum i preia datele despre consumuri de la magazii, centralizeaz aceste date pentru calculul costurilor, genereaz rapoarte detaliate sau centralizate cu privire la consumurile planificate si realizate; Managementul proiectelor - are ca obiect proiectele de investiii, activitile interne sau lucrrile efectuate de teri: planificarea (bugetarea), finanarea i urmrirea executrii acestora; Stocuri - Gestiunea cantitativ i calitativ a stocurilor i generarea automat a documentelor contabile; Gestiunea depozitelor (inclus adesea n modulul de Stocuri) - definete din punct de vedere organizatoric unitile de stocare: tipurile de inventar i subinventar, depozite, magazii, locaii, modul de localizare al stocurilor; Aprovizionare (Furnizori) - Componenta dep ete atribuiile unei aplicaii de gestiune, fiind un instrument de optimizare a aprovizionrii, care poate determina realizarea de economii. Modulul Aprovizionare se leag de componenta Stocuri. Vnzri - gestioneaz activitile specifice procesului de vnzare; ntreinerea echipamentelor (mentenana) - rezolv Gestiunea tehnic i de utilizare a echipamentelor, permite planificarea resurselor i costul lucrrilor. Foarte important este istoricul activitilor de ntreinere i reparaii; Transport (Logistica) - permite planificarea i gestionarea activitilor logistice din procesele de vnzare i distribuie; Service/Servicii - urmrete garaniile i serviciile postvnzare;
24

Analiza (Business Intelligence) - Modulul preia datele din baza de date, realizeaz diferite analize i furnizeaz informaiile n forma dorit de utilizator. Cele mai puternice opiuni sunt analizele multi-dimensionale (OLAP), simulrile, scenariile i prognozele; Soluii specifice fiecrei industrii Generatorul de rapoarte - utilizatorii obin rapoartele dorite n cadrul fiecrui modul funcional folosind datele din baza de date a sistemului ERP. Este unanim acceptat ideea c, dei tehnologia este esenial n realizarea unui ERP, definiia acestuia trebuie s reliefeze ariile funcionale bazate pe activitile principale ale unei firme, cum sunt: contabilitatea, producia, vnzarea, aprovizionarea, stocurile, personalul etc. Alte definiii consider sistemele ERP ca fiind o soluie soft, o metod sau un pachet de aplicaii, astfel: soluie software complet i atotcuprinztoare pentru o ntreprindere; metod pentru planificarea eficient i controlul tuturor resurselor necesare pentru prelucrarea, realizarea, expedierea i contabilizarea comenzilor clienilor, n firmele de producie, desfacere ori servicii (American Production and Inventory Control Society) un pachet de aplicaii care permite integrarea complet a tuturor informaiilor din cadrul unei organizaii. Sintetiznd aceste definiii, putem desprinde urmtoarea concluzie, unanim acceptat de cei citai sistemele ERP constau din module software, care acoper toate ariile funcionale ale unei firme: marketing-ul i vnzrile, service-ul, proiectarea i dezvoltarea de produse, producia i controlul stocurilor, aprovizionarea, distribuia, resursele umane, finanele i contabilitatea, precum i serviciile informatice. n procesul de abordare structuraltehnologic a sistemelor ERP, am considerat important, pentru nceput, prezentarea ctorva dintre caracteristicile funcionale ale unui astfel de sistem. Examinnd aceast arhitectur, putem remarca cteva dintre caracteristicile funcionale ale unui astfel de sistem, i anume: ofer informaiile necesare conducerii firmei prin intermediul bazei de date, unde se stocheaz tranzaciile zilnice; asigur prelucrarea corespunztoare a datelor, pe baza unor programe adecvate; permite utilizarea n comun a datelor din baza de date, de ctre toate modulele care folosesc aceste date; permite realizarea fiecrui tip de prelucrare (culegere date, stocare, actualizare, interogare), n mod separat; asigur principiul integrrii sistemului, prin intermediul bazei de date unice; permit accesul la date n timp real; ofer suport multivalut i multilingv; sunt adaptate specificului activitilor organizaiilor (activiti n diferite ramuri industriale, servicii, comer, bnci, sntate etc.); permit realizarea unor adaptri fr intervenia programatorilor. Modulele de aplicaii sunt grupate n subsisteme (suite) cum sunt: financiar, producie, distribuie etc.

25

Avantajele utilizrii ERP A. Analiza din punct de vedere al funcionalitilor oferite Dup cum precizeaz autorul Daniel E. O'Leary n lucrarea Enterprise Resource Planning Systems, principalele avantaje ale folosirii unui ERP n cadrul unei companii sunt: Informaia este introdus n sistem o singur dat ntr-o baz de date foarte complex; Oblig la folosirea celor mai bune practici din industrie; Permite personalizri; Funcioneaz pe o structur fiabil de fiiere; Furnizeaz funcionaliti pentru interaciunea cu alte module; Furnizeaz instrumente pentru interogri i rapoarte ad-hoc. Sistemele ERP furnizeaz informaii pentru conducere i analize pentru organizaii, iar cele 5 beneficii majore ale sistemelor ERP sunt: informaii on-line/n timp real pentru toate ariile funcionale ale unei organizaii; standardizarea datelor i acuratee la nivel de ntreprindere; aplicaiile includ cele mai bune practici din industria respectiv; eficiena pe care o nregistreaz compania; analizele i rapoartele ce pot fi folosite la planificri pe termen lung. Exist cinci motive majore pentru care companiile doresc s preia ERP-ul5: 1. Integrarea informaiilor financiare n timp ce CEO-ul ncearc s neleag performana global a companiei, poate gsi diferite versiuni ale realitii. Departamentul Financiar are un set de valori reprezentnd venitul, departamentul Vnzri un cu totul altul i alte diferite departamente pot avea fiecare o versiune diferit despre propria contribuie la venitul total al companiei. ERP-ul creeaz o singur versiune a realitii pe care nimeni nu o poate contesta pentru c fiecare folosete acelai sistem. 2. Integrarea informaiilor corespunztoare comenzii clientului Sistemul EPR poate deveni locul unde comanda clientului este nregistrat, trimis de CSR (Customer Service Representative) la departamentul financiar i comercial, genernd emiterea unei facturi corespunztoare care va ajunge n final la CSR. Avnd aceast informaie ntr-un singur sistem, n loc s o caui n diferite alte sisteme care nu pot comunica unul cu altul, companiile pot ine evidena i stadiul unei comenzi mult mai uor, putnd coordona producia, inventarul i direcionarea informaiei ctre mai multe departamente n acelai timp. 3. Standardizarea i eficientizarea procesului de producie. Companiile de producie gsesc de multe ori c diferite departamente ale companiei ajung la rezultate asemntoare folosind diferite sisteme computerizate i metode. Sistemele ERP implic un sistem care conine metode standardizate pentru automatizarea unora dintre paii efectuai n procesul de producie. Standardizarea acestor procese i folosirea unui singur sistem integrat poate reduce timp ineficient, mri productivitatea i reducerea erorii umane. 4. Reducerea inventarului. ERP-ul ajut ca desfurarea unui proces de producie s se fac mult mai uor. Acest lucru poate duce la diminuarea inventarului corespunztor personalului folosit n procesul de producie (inventar al muncii n proces), i poate ajuta utilizatorii sistemului s planifice mai bine ndeplinirea
5

http://www.cio.com/research/erp/edit/erpbasics.html#erp_abc 26

comenzilor, reducnd inventarul bunurilor care au trecut prin ntreg stadiul produciei, aflndu-se n cadrul stocurilor existente. Pentru a mbunti cu adevrat flexibilitatea reelei de aprovizionare i distribuire, este nevoie de un software reea, iar ERP-ul ajut la acest lucru. 1. Standardizarea informaiilor din departamentul de Resurse Umane Mai ales n afacerile cu diferite departamente, Resurse Umane poate sa nu aib o metod simpl pentru gsirea angajailor i pentru a comunica cu ei despre servicii i beneficii. Sistemul ERP poate mbunti acest lucru. Producia este cel mai important proces n lanul valorii ntr-o ntreprindere productoare, iar calitatea i competitivitatea pe pia a produselor rezultate din procesul de producie este esenial. Pentru ndeplinirea acestor deziderate este esenial eficiena sistemului informatic de gestiune a activitii. Numai implementarea unei soluii informatice perfect modelate pe specificul activitilor unei ntreprinderi productoare poate asigura premisele competitivitii acesteia. Avantajul cel mai important al unui sistem informatic integrat (ERP) const n gestionarea n mod unic a tuturor categoriilor de date i a informaiilor specifice beneficiarului. B. Analiza din punct de vedere al costurilor i riscurilor implicate Foarte muli beneficiari se plng de depirea bugetelor iniiale aprobate pentru achiziionarea soluiei ERP. Dac implementarea are loc fr ntrzieri care s presupun alocarea de noi resurse umane i materiale, atunci, de cele mai multe ori, putem vorbi despre costuri ascunse (hidden fees) . Sorin Dimofte (SIVECO Romnia) este de prere c apariia acestor hidden fees este cauzat de lipsa concordanei dintre poziia de la negociere i cea din timpul implementrii. Cu alte cuvinte, la negociere, cerinele clientului sunt minime cu scopul scderii preului de achiziie, ns n timpul implementrii solicitrile sunt maxime, n discordan cu negocierea iniial. Ca atare, vom vorbi i despre costuri de analiz a afacerii respective, despre costurile de personalizare a aplicaiei, despre licena modulelor, despre cerinele tehnice ale aplicaiei (licene de utilizatori, investiii n hardware) i despre ntreinerea acesteia (armonizarea cu legislaia local, suport tehnic, update-uri). Toate aceste costuri alctuiesc TCO (Total Cost of Ownership), care nu ar trebui s fie ascuns de ctre furnizorii de ERP, ci, din contr, ar trebui expus nc de la primele discuii. n al doilea rnd, este vorba de costul licenelor, respectiv al serviciilor de configurare impuse de software-ul adiional (reea, baz de date etc.) pe care furnizorul de ERP nu le declar din prima pentru c el consider c nu fac parte din costul ERP. Nu sunt declarate nici necesitile de upgrade al hardware-ului necesar pentru a rula soluia, fa de care furnizorul consider c echipamentele nu sunt problema lui. n al treilea rnd, pe parcursul implementrii, odat cu nelegerea mai adnc a aplicaiei beneficiarului, i se reveleaz alte rezolvri sau necesiti care atrag costuri suplimentare. Astfel, soluiile ERP cost ntre 400.000 euro i 300 milioane euro (conform unui studiu Meta Group), n funcie de: mrimea firmei; specificul de activitate; gradul de dispersare geografic; infrastructura tehnologic ERP este scump pentru orice tip de afacere. Investiiile sunt de multe ori adevrate bombe cu ceas pentru bugetele companiilor. Totui, firmele care au implementat pachete Enterprise Resource Planning (ERP) trebuie s recunoasc faptul c unele cheltuieli sunt supraevaluate, n timp ce altele sunt subestimate.
27

Principalii devoratori de buget n implementarea pachetelor ERP sunt : Training-ul Training-ul este o component neglijat n procesul de implementare, att ca etap, ct i la nivel bugetar. Astfel, costurile sunt subestimate cel mai adesea pentru c se pierde din vedere faptul c majoritatea angajailor au de nvat un nou set de procese i nu doar o noua interfa software. Integrarea i testarea Testarea compatibilitii pachetelor ERP cu alte programe software este o alt cheltuial de care nu se prea ine seama n procesul de implementare. O companie standard de producie poate avea aplicaii add-on pentru partea de logistic, taxe, planificarea produciei i codurile de bare. Dac la toat aceast list se adaug i customizarea funciilor de baz din pachetul ERP, costurile de integrare, testare i mentenan a sistemului vor arunca n aer bugetul. n ceea ce privete training-ul, testarea integrrii ERP trebuie fcut din perspectiva procesului. Conversia datelor Transferul datelor, de tipul informaiilor referitoare la clieni i furnizori, sau la designul produsului, de pe vechile sisteme pe cele ERP, este o operaiune costisitoare. Dei puini CEO sunt dispui s admit c multe din datele existente n sistemele primite motenire nu sunt foarte importante. Companiile neag de multe ori redundana datelor pe care le dein, cel puin pn n momentul n care trebuie s le fac transferul n noile setri client/server necesare pachetelor ERP. i din nou companiile subestimeaz costurile, de aceast dat pe cele necesare transferului. Analiza datelor De multe ori datele din sistemele ERP trebuie combinate cu datele din sistemele externe pentru a putea permite realizarea de analize. Utilizatorii care efectueaz analize n mod curent ar trebui s aib n vedere n bugetul alocat implementrii ERP-ului i depozitul de date, dar i efortul necesar pentru al pune pe picioare. Utilizatorii sunt pui n dificultate n acest moment: reactualizarea zilnic a tuturor datelor ERP dintr-un imens depozit de date, dintr-o corporaie este dificil, iar sistemele ERP nu ajut prea mult la identificarea acelor date care s-au modificat de la zi la zi, fcnd actualizri selective. O soluie costisitoare este "custom programming". Consultani ad infinitum Pentru a evita notele de plat kilometrice ctre consultani, companiile trebuie s identifice clar obiectivele ctre care partenerii de consultan trebuie s i orienteze pe angajai. Activitatea consultanilor trebuie s poat fi evaluat, iar pentru aceasta este necesar s le fie stabilit un "plafon" n activitatea lor: de exemplu, un numr de angajai s poat trece cu brio un test de project management. Specialitii Cei mai muli analiti susin c succesul unui sistem ERP depinde de echipa care lucreaz la implementarea lui. Software-ul este prea complex i schimbrile din zona de business prea dramatice pentru a lsa un astfel de proiect pe mna unor amatori. Vestea proast este c, la finalul proiectului, companiile trebuie s fie pregtite s nlocuiasc muli dintre specialiti. Echipele de implementare o poveste fr de sfrit Multe companii tind s trateze implementrile de ERP ca pe orice alt proiect software. Odat ce programul software a fost instalat, gndesc ei, echipa va fi dizolvat i fiecare i va relua postul iniial cu tot cu atribuiile ce ii revin. Dup o implementare de sistem ERP ns, membrul echipei nu se poate rentoarce la vechile atribuiuni pentru c este mult prea valoros pentru companie - ajunge s tie mai multe lucruri despre procesul de vnzri i de producie chiar dect agentul de vnzri, respectiv agentul de producie nsui. Companiile nu i prea pot permite s trimit pe vechile posturi
28

participanii la proiect, ntruct exist multe lucruri de fcut dup instalarea ERP-ului. Doar crearea de rapoarte pentru a extrage informaii din noul sistem ERP ine echipa ocupat cel puin un an de zile. Din pcate, puine companii au n vedere etapa post-instalrii i chiar i mai puine o prevd n planificarea bugetar prealabil implementrii. n ateptarea beneficiilor n managementul de proiecte software tradiionale, companiile se ateapt s vad rezultatele imediat ce instalarea aplicaiei s-a ncheiat, lucru imposibil n cazul ERP. Majoritatea sistemelor ERP i relev eficiena dup o perioad mai ndelungat de la implementare, iar echipa de proiect la rndul su nu primete recompensa dect dup amortizarea investiiei. Depresia Post-ERP Conform unui studiu efectuat de o firma de consultan, una din patru companii intervievate a suferit o scdere a performanei dup implementarea sistemului ERP. Motivul este acela c totul funcioneaz i arat altfel dect pn atunci, iar cnd angajaii nu tiu exact cu ce lucreaz se panicheaz, acest lucru afectnd ntregul business. C. Factorii de risc n privina riscurilor, se ntmpl adesea ca bugetele alocate i/sau termenele prevzute s fie cu mult depite unii analiti apreciaz c aproximativ jumtate din proiectele ERP nu reuesc s ating obiectivele propuse. Cazuri celebre precum Boeing, Panasonic sau Siemens ilustreaz eecul proiectelor, n sensul ratrii obiectivelor propuse ori depirii nepermise a bugetelor. n majoritatea cazurilor publicate eecul implementrii unui pachet de aplicaii integrate s-a datorat problemelor organizaionale. ntr-un top al motivelor se regsesc: tratarea ERP ca pe un sistem software; lipsa implicrii managerilor executivi (top-manageri); concentrarea eforturilor pe instalarea software-ului i pe nvarea acestuia; ateptri nerealiste n privina duratei de implementare; utilizarea sistemelor ERP pentru colectarea, prelucrarea datelor i obinerea informaiilor; neimplicare i neacceptare din partea utilizatorilor; implementri realizate de consultani i specialiti externi; lipsa pregtirii psihologice corespunztoare a utilizatorilor; comunicare defectuoas ntre membrii echipelor de proiect; proiectul nu a fost pregtit corespunztor ori resursele necesare dezvoltrii sale au fost insuficiente. Avnd n vedere costurile destul de mari pe care le implic achiziionarea unui ERP, era firesc s ntrebm ce riscuri presupune investiia ntr-o asemenea soluie. Extrem de interesant este punctul de vedere al furnizorilor, aproape toi considernd c riscurile vin din partea clientului i nu din partea companiilor care se ocup de implementare. SAP este de prere, de exemplu, c principalul risc ine de necunoaterea domeniului i de neglijarea anumitor criterii de alegere a soluiei ERP. Muli manageri urmresc, exclusiv, preul de achiziie fr s in seama de ali factori. De aceea exist riscul de a alege o soluie nepotrivit necesitilor companiei, o soluie care nu poate susine, pe termen lung, creterea afacerii, o soluie insuficient testat care poate genera probleme de stabilitate, funcionalitate sau extindere.

29

Primul pas pentru o implementare de succes este alegerea unei soluii performante, apropiat de specificul de activitate al clientului astfel nct nivelul de configurare s fie minim, o soluie care s fie confirmat de referine pe piaa romneasc. Printr-o comunicare adecvat ntre cele dou echipe de proiect, problemele legate de implementare pot fi evitate. Pe lng situaiile n care managementul companiei client nu susine proiectul sau efii de compartimente nu se implic suficient n implementarea i utilizarea soluiei sau personalul nu cunoate i nu nelege necesitatea i beneficiile trecerii de la aplicaiile individuale la soluiile integrate, au fost identificate i o serie de puncte critice care apar pe parcursul implementrii unei soluii ERP: n primul rnd nu se acord suficient atenie procesului de analiz a nevoilor, adevratele necesiti aprnd mult mai trziu, pe parcursul implementrii; n al doilea rnd, se ateapt ca verificarea rezultatelor s se fac de ctre implementator, ceea ce este complet greit, fiecare utilizator final trebuie s verifice rezultatele activitii de care rspunde; nu n ultimul rnd, tergiversarea renunrii la aplicaiile vechi, dei nu este indicat s se lucreze n paralel mai mult de dou luni de zile, clienii continu aceast practic pn la jumtate de an. Deosebit de important este faptul c euarea unei implementri nu nseamn numai pierderea investiiei materiale n soluia ERP. Efectele negative se resimt n deteriorarea relaiei cu clienii, cu angajaii sau n pierderea cotei de pia i de imagine. De aceea se recomand alegerea unui partener cu experien, capabil s prevad i s combat aceste riscuri. Reticena clientului la sugestiile furnizorului de ERP constituie un risc deloc de neglijat. Se presupune c o companie serioas deine un background solid pentru a putea propune practici eficiente de afaceri i modaliti de mbuntire a mediului de lucru. ns, n condiiile n care clientul nu este deschis la propunerile furnizorului, exist riscul ca practicile greoaie utilizate pn n acel moment s se perpetueze n noul sistem, sczndu-i valoarea. Dac echipa care realizeaz implementarea nu nelege sau nu are capacitatea de a rspunde necesitilor clientului, soarta ERP-ului achiziionat poate fi un eec. n condiiile actuale ale economiei de pia concureniale, meninerea i ntrirea poziiei economice a unei societi comerciale, indiferent de mrimea acesteia, este imposibil fr informatizarea activitii sale. Prin urmare, este imperios necesar ca ntreprinderea s-i conceap i s realizeze sau s-i achiziioneze un sistem informatic, cu ajutorul cruia s-i gestioneze evidena zilnic i s ofere managerului sprijin pentru fundamentarea deciziilor strategice i tactice, care s-i conduc activitatea i s-i consolideze poziia pe pia i eficiena sa economic. Spre deosebire de preocuprile similare cu 10-15 ani n urm, dinamica vieii economice impune astzi ca firmele s foloseasc sisteme informatice integrate, care s informatizeze toate compartimentele funcionale ale firmei. Aceast tendin a aprut ca o reacie fireasc la noile provocri ale tehnologiilor informatice moderne, ntr-un moment n care se constat accentuarea fenomenului de globalizare a economiei i de amplificare a concurenei ntre diferite firme. Chiar i ntreprinderile mici i mijlocii (IMM), antrenate n procesul de modernizare a ntregii lor activiti, nu pot rmne nici ele nepstoare la aceste provocri majore ale tehnologiilor informatice actuale bazate, fie pe implementarea unor sisteme informatice, fie pe suportul unor sisteme distribuite. n acest context, aplicarea noilor tehnologii informatice va trebui s asigure identificarea de

30

noi resurse, gestionarea corect i eficient a patrimoniului firmei, n scopul obinerii unei eficiene ridicate. Analiznd tabelul 1.1, se poate concluziona la prima vedere c folosirea sistemelor ERP se justific pentru organizaii de dimensiune medie/mare i mare (n special datorit consumului mare de timp i a costurilor). O analiz mai atent scoate ns n eviden avantajele competitive eseniale: informaia de calitate, dimensiunea colaborativ i deschiderea spre e-business, care le fac absolut necesare n cadrul unei economii moderne. Tabelul 1.1 Dezavantaj Mod de combatere/diminuare Proiecte consumatoare de timp Implicarea activ a managementului, obinerea consensului i acceptului general; Costuri mari Dificil i nerecomandat ; Dependena de furnizor Analiz atent a celor dou alternative: furnizor unic, sau mai muli furnizori, prima nsemnnd implicarea furnizorului pe termen lung, a doua oferind ansa alegerii soluiilor best of breed; Complexitate Selectarea doar a modulelor care sunt absolut necesare; Necesitatea extinderii i dezvoltrii Poate fi eliminat, dar va reduce potenialul ulterioare a sistemului sistemului, care va deveni la un moment dat ineficient. Grile 1. a) b) c) d) e) 2. a) b) c) d) e) 3. a) b) c) d) e) Serviciile pentru organizarea i ntreinerea bazei de date includ: funcii pentru salvarea i refacerea bazei de date n caz de eroare funcii pentru normalizarea bazei de date mecanisme de securitate pentru mpiedicarea accesului neautorizat funcii pentru formatarea textului servicii web. Componentele bazelor de date relaionale pot fi: relaii de tip 1 la 1 interogri ale bazei de date fiiere de index rapoarte cu datele din baza de date reguli specificate pentru obiectele bazei de date sub form de restricii. Restricia de unicitate ntr-o baz de date asigur: folosirea valorilor nule mpiedic folosirea valorilor nule validarea valorilor unei coloane valori unice pe o coloan sau un set de coloane ale tabelului o relaie ntre dou tabele.
31

4. a) b) c) d) 5. a) b) c) d) e) 6. a) b) c) d) e) 7. a) b) c) d) e)

Funciile vizualizrilor sunt: stocheaz datele n baza de date ascund coloanele pe care utilizatorul nu e nevoie s le vad ocup mai puin spaiu n baza de date container optimizeaz timpul de rspuns al bazei de date. Optimizarea structurii bazei de date urmrete: proiectarea procedurilor tehnologice de prelucrare a bazei de date analiza cerinelor informaionale i definitivarea datelor analiza semantic a datelor scderea redundanei datelor eliminarea anomaliilor de actualizare. Care sunt nivelurile de abstractizare a datelor: fizic, conceptual, extern intern, global, extern baze de date, vederi, rapoarte tabele libere, tabele nglobate n baze de date, vederi formulare, grid-uri, rapoarte. Cte forme poate lua integrarea aplicaiilor: integrarea intern i cea extern integrarea bazelor de date, a datelor i a bazei informaionale integrarea business-to-consumer i business-to-government integrarea aplicaiilor la nivel de companie i a aplicaiilor Business-to-Business integrarea contabilitii i a gestiunii firmei.

8. Orice ntreprindere este constituit din mai multe zone din punct de vedere al modelului general de organizare a unei afaceri: a) zona de rezerv i zona de producie b) zona back office, front office, middle office i web office c) zona de gestiune, de contabilitate, de producie i de desfacere d) zona financiar i zona material e) zona executiv, zona informaional i zona productiv. 9. a) b) c) d) e) Care este scopul unui ERP ntr-o companie: realizarea unei mai bune comunicri ntre diferitele compartimente ale companiei diminuarea factorului uman ca o presiune salarial gsirea unor soluii mai bune n ceea ce privete producia companiei cheltuieli financiare mai mari ale companiei venituri financiare mai mari ale companiei.

10. Modelul de arhitectur implementat de ctre sistemele ERP este cel cu trei straturi, care sunt acestea: a) Nivelul conceptual, global, fizic
32

b) c) d) e)

Nivelul prezentare, aplicaie, al bazei de date Nivelul de baze de date, formulare i rapoarte Nivelul ERP, CRM i Business-to-Business Nivelulde gestiune, al contabilitii i de producie

R[spunsuri
1 a,c; 2 a,e; 3 d; 4 b; 5 d,e; 6 a,b; 7 a,d; 8 b; 9 a; 10 b.

33