Documente Academic
Documente Profesional
Documente Cultură
Capitolul 1: Cuprins
Capitolul 1: Cuprins
Introducere..
Capitolul 1
Sisteme informatice.
4
5
6
8
9
9
10
11
11
11
13
14
14
15
17
20
20
Capitolul 2
Iniierea i planificarea realizrii unui sistem informatic....
21
21
23
24
24
Capitolul 3
Analiza sistemului existent i definirea cerinelor noului sistem........................
26
26
27
27
28
29
29
31
32
35
36
43
46
47
49
50
50
50
53
53
55
56
60
63
65
65
Capitolul 5
Proiectarea fizic a sistemelor informatice...........................................................
68
68
68
69
70
70
71
81
82
ADENDA.................................................................................................................................
94
BIBLIOGRAFIE......................................................................................................................
83
86
87
89
91
93
96
Introducere .......................................................................................................................................5
Capitolul 1 ........................................................................................................................................8
Sisteme Informatice..........................................................................................................................8
1.1. Sistem, Sistem informaional, Sistem informatic ................................................................................................ 8
1.1.1. Componentele sistemului informatic.......................................................................................................... 11
1.1.2. Clasificarea sistemelor informatice ............................................................................................................ 13
1.1.3. Ciclul de via a unui sistem informatic .................................................................................................... 15
1.1.4. Coninutul bazei informaionale a unei ntreprinderi ................................................................................. 16
1.1.5. Ciclul prelucrrii datelor pentru sistemul informatic ................................................................................. 17
1.1.6. Sisteme informatice de gestiune................................................................................................................. 19
1.2. Metodologii de realizare a sistemelor informatice ............................................................................................ 21
1.2.1. Coninutul metodologiilor de realizare a sistemelor informatice ............................................................... 21
1.2.2. Metode i tehnici de realizare a sistemelor informatice ............................................................................. 22
Capitolul 3 ......................................................................................................................................39
Analiza sistemului existent i definirea cerinelor noului sistem...................................................39
3.1. Studiul sistemului informaional existent.......................................................................................................... 39
3.2. Determinarea cerinelor sistemului ................................................................................................................... 41
3.2.1. Metodele tradiionale utilizate n analiza i determinarea cerinelor sistemului......................................... 42
3.2.2. Metode moderne de analiz i determinare a cerinelor sistemului............................................................ 43
3.3. Structurarea cerinelor sistemului - modelarea logic a datelor i prelucrrilor................................................ 45
3.3.1. Diagramele fluxurilor de date (DFD)......................................................................................................... 45
Tehnica SSADM (Structured Systems Analysis and Design Methodology) pentru construirea DFD................. 46
3.3.2. Descompunerea funcional i rafinarea DFD ........................................................................................... 47
3.3.3. Modelarea sistemului curent ...................................................................................................................... 50
3.3.4. Modelarea logicii proceselor.......................................................................................................................... 53
Reprezentarea logicii proceselor prin engleza structurat.................................................................................... 54
3.4. Modelarea conceptual a datelor (diagramele entitate relaie, DER) ............................................................. 56
3.4.1. Modelul Entitate/Relaie (E/R)................................................................................................................... 59
Capitolul 4 ......................................................................................................................................77
Proiectarea logic a sistemelor informatice ...................................................................................77
4.1. Proiectarea formularelor/formatelor i a rapoartelor ......................................................................................... 77
4.1.1. Proiectarea situaiilor cu rezultate finale (rapoartelor) ............................................................................... 78
4.1.2. Proiectarea codurilor .................................................................................................................................. 82
4.1.3. Proiectarea intrrilor n sistemul informatic............................................................................................... 83
4.2. Proiectarea interfeelor i a dialogurilor............................................................................................................ 86
4.3. Proiectarea logic a bazelor de date .................................................................................................................. 89
4.3.1. Normalizarea relaiilor - Forme normale.................................................................................................... 94
4.3.2. Simplificarea structurii datelor prin normalizare ..................................................................................... 100
4.3.3. Transformarea diagramelor entitate-relaie n relaii................................................................................ 104
Capitolul 5 ....................................................................................................................................108
Proiectarea fizic a sistemelor informatice ..................................................................................108
5.1. Proiectarea fizic a bazelor de date i a fiierelor ........................................................................................... 108
5.1.1. Obiectivele fundamentale ale unei baze de date (BD) sunt:..................................................................... 109
5.1.2. Sistemul de Gestiune a Bazelor de Date (SGBD) .................................................................................... 111
Capitolul 6 ....................................................................................................................................153
Instrumente CASE........................................................................................................................153
6.1. Funciile CASE ............................................................................................................................................... 155
6.2. Trsturi definitorii ale CASE-ului ................................................................................................................. 156
Capitolul 7 ....................................................................................................................................179
Tendine actuale i de perspectiv n evoluia sistemelor informatice.........................................179
7.2.1. Sisteme expert bazate pe reguli................................................................................................................ 186
7.2.2. Sisteme bazate pe reele neuronale (sisteme conexioniste) ...................................................................... 186
7.2.3. Sisteme multi-agent. Definiie, clasificare, arhitecturi. ............................................................................ 187
7.2.4. Sisteme inteligente hibride ....................................................................................................................... 189
Capitolul 8 ....................................................................................................................................193
Studii de caz - Arhitecturi de sisteme informatice .......................................................................193
8.1. Model de date georelaional n cadrul unui sistem informatic geografic distribuit cu aplicaii n domeniul
cadastrului .............................................................................................................................................................. 193
Model de date georelaional n domeniul cadastrului............................................................................................. 194
8.3. Sistem bazat pe cunotine destinat documentrii i cercetrii asistate n genetica vegetal ......................... 214
8.3.1. Organizarea datelor n cadrul sistemului informatic ................................................................................ 215
8.3.2. Arhitectura unui sistem bazat pe cunotine n genetica vegetal ............................................................ 220
8.3.3. Probleme specifice cercetrii ................................................................................................................... 227
8.4. Sistem telematic pentru managementul on-line al zonelor intravilane degradate datorit depozitrii
necontrolate a deeurilor ........................................................................................................................................ 234
8.4.1. Introducere ............................................................................................................................................... 234
8.4.3. Proiectarea bazei de date a sistemului ...................................................................................................... 238
8.4.4. Dezvoltarea unei aplicaii specifice pentru reprezentarea i monitorizarea unor zone intravilane din
judeul Suceava supuse degradrii datorit depozitrii necontrolate a deeurilor. ............................................. 244
[19] Dumitru Oprea, Gabriela Meni, Florin Dumitriu, Analiza sistemelor informaionale, Editura Universitii
Alexandru Ioan Cuza Iai, 2005 ......................................................................................................................... 264
[20] Dumitru Oprea, Florin Dumitriu, Gabriela Meni, Proiectarea sistemelor informaionale, Editura
Universitii Alexandru Ioan Cuza Iai, 2006 .................................................................................................... 264
[21] Dumitru Oprea, Dinu Airinei, Marin Fotache, Sisteme informaionale pentru afaceri, Editura POLIROM Iai,
2002 ....................................................................................................................................................................... 264
Sistem
Procesor de informaii
Informaie
Om
Calculato
Reguli
Fiiere
manual
Reguli i
proceduri
scrise
Fiiere
informatice
Programe i
Structuri de
Subsistem 1
Subsistem 2
Aplicatia 2.1
Subsistem n
Aplicatia 2.k
Program 2.k.1
Program 2.k.s
10
11
Echipamente
Echipamente de calcul : calculatoare, staii grafice, pentru servere de reea,
servere de baze de date, staii de lucru (clieni, utilizatori), UPS-uri;
Echipamente de comunicaie : router-e, hub-uri, modem-uri, switch-uri.
Produse software
Produse software de baz:
Sisteme de operare pentru serverul de reea (UNIX, Windows NT server,
Windows 2000, Novell) i pentru staiile de lucru sau clieni (Windows 95,
Windows 98, Windows NT work station, Windows 2000);
Sisteme de Gestiune a Bazelor de Date (ORACLE, SQL Server Microsoft,
MySQL, ACCESS, FoxPro etc.);
12
aplicaie.
Produse software de aplicaie produse program ce constituie aplicaiile i
subsistemele sistemului informatic.
1.1.2. Clasificarea sistemelor informatice
Sistemele informatice se clasific dup mai multe criterii [1].
1. n funcie de domeniul de utilizare, sistemele informatice pot fi pentru :
conducerea activitilor economico-sociale
conducerea proceselor tehnologice
cercetare tiinific i proiectare tehnologic
activiti speciale.
2. n funcie de elementul supus analizei:
sisteme informatice orientate spre funcii;
sisteme informatice orientate spre proces;
sisteme informatice orientate spre date;
sisteme informatice orientate spre obiecte;
sisteme informatice orientate spre cunotine.
3. Dup modul de organizare a datelor:
sisteme bazate pe fiiere;
sisteme bazate pe tehnica bazelor de date: ierarhice, reea, relaionale, orientateobiect;
sisteme mixte.
4. Dup metoda folosit n analiza i proiectarea sistemelor:
sisteme dezvoltate dup metoda sistemelor;
sisteme dezvoltate dup metoda clasic a ciclului de via;
13
14
15
Analiza i definirea
cerinelor
Proiectarea sistemului
i a software-ului
Implementarea i testarea
unitilor de program
Integrarea i testarea
sistemului
Exploatarea i ntreinerea
sistemului
Fig. 1.3. Etapele ciclului de via a unui sistem informatic n modelul cascad ([10])
1.1.4. Coninutul bazei informaionale a unei ntreprinderi
Pentru o ntreprindere entitile bazei informaionale pot fi grupate dup cum
urmeaz:
-
16
pentru activitatea de personal: evidena personalului, salarizri, dotri socialculturale i gestiunea lor;
17
evenimente;
indexarea datelor pentru a nlesni o uoar regsire a lor;
18
Prelucrarea datelor
Pregtirea datelor
Informaii de ieire
ntreinere fiiere
19
20
Situaia
costurilor pe
comenzi
Consultare 1
Creare
Actualizare
BD
Consultare 2
Balana de
verificare
Registrul jurnal
Cartea mare
21
22
25
Teste rezolvate
1. Care definiie este corect:
a) Un sistem reprezint un ansamblu de elemente (componente) interdependente,
ntre care se stabilete o interaciune dinamic, pe baza unor reguli prestabilite,
cu scopul atingerii unui anumit obiectiv;
b) Un sistem este un ansamblu structurat de elemente intercorelate funcional
pentru automatizarea procesului de obinere a informaiilor i pentru
fundamentarea deciziilor..
Rspuns: a,b
2. Sistemul informaional cuprinde:
a) Ansamblul informaiilor interne i externe, formale sau informale utilizate n
cadrul firmei precum i datele care au stat la baza obinerii lor;
b) Procedurile i tehnicile de obinere(pe baza datelor primare) i de difuzare a
informaiilor;
c) Platforma necesar prelucrrii i disiprii informaiilor;
d) Personalul specializat n culegerea, transmiterea, stocarea i prelucrarea datelor.
Rspuns: a,b,c,d
3. Un sistem informatic este:
a) un sistem destinat conducerii unei organizaii,
b) un sistem utilizator-calculator integrat, care furnizeaz informaii pentru a sprijini
activitile de la nivel operaional i activitile de management ntr-o organizaie,
utiliznd echipamente hardware i produse software, proceduri manuale, o baz de
date i modele matematice pentru analiz, planificare, control i luarea deciziilor,
c) un ansamblu structurat de elemente intercorelate funcional pentru automatizarea
procesului de obinere a informaiilor i pentru fundamentarea deciziilor.
Rspuns: b,c
4. Identificai afirmaia fals:
a) Sistemul informaional este subordonat sistemului de conducere.
26
evenimente;
c) crearea datelor;
d) indexarea datelor pentru a nlesni o uoar regsire a lor;
e) protecia datelor memorate, care cuprinde o mare varietate de proceduri i
tehnici pentru prevenirea distrugerii lor sau a accesului neautorizat.
Rspuns: a,b,d,e
11. Metodologiile de realizare a sistemelor informatice cuprind:
a) reguli de formalizare a datelor;
b) instrumente pentru concepia, realizarea i elaborarea documentaiei;
c) modalitile de administrare a proiectului;
d) instruciuni pentru luarea deciziilor;
e) modalitatea de abordare a sistemelor.
Rspuns: a,b,c,e
12. Reprezint modul unitar sau maniera comun n care analitii de sisteme,
programatorii i alte categorii de persoane implicate realizeaz procesul de analiz a
28
29
30
microanaliza
B. iniierea i
planificarea
proiectului
C. analiza
D. proiectarea
logic
E. proiectarea
fizic
F. implementarea
G. ntreinerea
selecia proiectului.
31
De sus n
jos
Metoda de selecie
a proiectului
Top-managerii
Comitetul de
iniiativ
Departamentul
utilizatorilor
De jos n
sus
Grupul de
dezvoltare
Caracteristicile proiectului
orientare puternic spre strategie;
cele mai mari dimensiuni ale proiectului;
cele mai de durat proiecte.
orientare mixt (a diferiilor reprezentani);
vizeaz schimbrile organizaionale cele mai
mari;
analiz formal a costurilor i avantajelor
proiectelor;
proiecte mai mari i mai riscante.
limitat, neorientat strategic;
realizare mai rapid;
civa utilizatori reprezint niveluri ale
conducerii, precum i funciile ntreprinderii.
integrare n sistemul existent;
puine ntrzieri n realizarea proiectului;
mai puin interesat de analizele cost avantaje.
32
Iniierea proiectului
Din momentul seleciei lui, proiectul trece n faza de iniiere, ceea ce presupune
desfurarea unei activiti laborioase, prestat de un responsabil, cunoscut n practic sub
numele de manager de proiect, care rspunde de [1]:
-
Managerul de proiect trebuie s dea dovad de multe caliti pentru a putea jongla cu
elemente cum sunt:
-
Schimbrile tehnologice;
Contractori i furnizori;
Documentare i comunicare;
diferite. Diagramele Gantt nu indic ordinea activitilor (precedena lor), ci indic data
nceperii i pe cea a finalizrii. Se recomand pentru descrierea proiectelor simple sau a
unor componente ale proiectelor mari, sau a activitilor prestate doar de o singur
persoan, precum i pentru monitorizarea modului n care se efectueaz activitile n
comparaie cu cele planificate (ca dat).
Evidena promovrii vnzrilor (EPV)
Nr.
Crt.
Nume
activitate
1.
Colectarea
cerinelor
Proiectare
ecrane
Proiectare
rapoarte
Proiectare
baze de date
Documentaie
utilizator
Programare
Testare
Instalare
edina de
analiz
2.
3.
4.
5.
6.
7.
8.
9.
Proiect: EPV
Data:
Analist:
Aprilie Mai
2005 2005
Iunie
2005
Iulie
2005
Critic:
n lucru:
Necritic:
Punct de reper:
August Septembrie
2005
2005
Sintez:
Derulat:
b) personalul auxiliar;
d) departamentul utilizatorilor.
Rspuns: a, d
36
38
Capitolul 3
Analiza sistemului existent i definirea cerinelor noului sistem
3.1. Studiul sistemului informaional existent
Prin sistem existent se nelege realitatea obiectiv din organizaia pentru care
urmeaz a se realiza sistemul informatic solicitat printr-o comand numit cererea
beneficiarului.
Analiza sistemului existent i definirea cerinelor noului sistem este prima etap
din ciclul de via al dezvoltrii sistemelor informatice, etap prin care se determin
modul n care funcioneaz sistemul informaional curent i se evalueaz ceea ce ar dori
utilizatorii s realizeze noul sistem. Studiul i analiza sistemului existent are ca obiectiv
principal stabilirea cerinelor informaionale ale conducerii n vederea realizrii unui
sistem informatic.
Studiul sistemului existent cuprinde un grup de activiti care urmresc
cunoaterea performantelor tehnico-funcionale ale sistemului informaional, att n
ansamblul su, ct i pentru elementele de structur ale acestuia, a cerinelor
informaionale ale conducerii, cunoaterea lipsurilor i restriciilor pe care le prezint
sistemul existent fa de aceste cerine. De modul de realizare a acestor activiti depinde
ntregul proces de realizare a sistemului informatic.
Studiul sistemului existent const n [2]:
-
39
resursele existente:
-
capaciti;
norme tehnice;
organizarea conducerii;
40
41
2. Informaii scrise care exist n unitate: misiunea i strategia afacerii, exemplare ale
formularelor, rapoartelor i machetelor de ecrane, manuale ale procedurilor,
descrieri ale posturilor de lucru, manuale de instruire, scheme de sisteme i
documentaia sistemului existent, rapoartele consultanilor;
3. Informaii obinute cu ajutorul calculatorului: rezultate ale sesiunilor JAD, copii
ale fiierelor sesiunilor grupului de sprijinire a sistemului, coninutul depozitelor i
rapoartele existente n CASE, ecrane i rapoarte rezultate din prototipurile
sistemului, .a.
3.2.1. Metodele tradiionale utilizate n analiza i determinarea cerinelor sistemului
Metodele utilizate frecvent n analiza sistemului existent sunt:
-
Interviul;
Chestionarul.
42
43
unul sau mai muli utilizatori sau susintori sunt implicai n sistem;
fiind conceput izolat este puin probabil ca el s fie integrat n sistemul existent;
45
46
47
49
52
desfaceri
Continutul fluxului
CODCLIENT, DENCLIENT,
ADRESAC, CONTC,
BANCA_C, DATAFACTD,
NRFACTD, TOTALFACTD
CODCLIENT, DENCLIENT,
ADRESAC, CONTC, BANCA_C,
NRFACTD, TOTALFACTD
53
54
55
}
CLOSE (FACTURI_DESF, NCASRI, CLIENTI)
3.4. Modelarea conceptual a datelor (diagramele entitate relaie, DER)
n cadrul modelrii conceptuale a datelor se va renuna la abordarea proceselor i
se va trece la abordarea sistemelor prin prisma datelor. La fel ca i n cazul modelrii
proceselor i modelrii logicii proceselor elementele eseniale vor fi diagramele.
James Martin i Carma McClure, atunci cnd reliefeaz importana tehnicilor
structurate prin obiectivele ce i le propun, consider c o parte a acestora au legtur i
cu datele, i anume [1]:
-
utilizarea datelor (obinere de documente, de diverse rapoarte, analize WhatIf, sprijin decizional, diferite cutri de informaii, control i auditare
ntreprindere).
3. DER care s scoat n relief ntreaga baz de date din care noua aplicaie i va extrage
datele. Ct timp mai multe aplicaii pot folosi aceeai baz de date, aceast diagram i
prima evideniaz modul n care noua aplicaie apeleaz la coninutul unor baze de
date mult mai extinse.
4. DER pentru ntreaga baz de date din care aplicaia curent i extrage datele necesare.
Ea este discutat doar pentru sistemele care exist i pentru care se urmrete
mbuntirea.
Metodele de determinare a cerinelor trebuie s fie orientate, prin ntrebrile puse,
prin anchetele efectuate, i asupra datelor, nu numai asupra proceselor i logicii lor. La
nceput, chiar fr utilizarea unei terminologii de specialitate, analistul va fi preocupat de
modul n care va afla ct mai multe informaii despre datele necesare viitorului sistem
pentru a funciona la parametrii proiectai. ntrebrile vor fi astfel formulate nct s se
realizeze o bun nelegere a regulilor dup care vor fi folosite datele n noul sistem, ce
politici vor fi utilizate. Nu trebuie, nc, s se intre n detalii de genul: cnd i cum sunt
prelucrate sau folosite datele, pentru a se realiza modelarea datelor.
Modelarea datelor se realizeaz printr-o combinaie a punctelor de vedere [1].
Un prim punct de vedere, formulat n literatur sub numele de metoda top-down,
va scoate n eviden regulile derulrii activitii firmei, printr-o nelegere foarte clar a
naturii afacerii, i nu se va opri asupra detaliilor privind modul n care ecranele, rapoartele
sau documentele sunt folosite n organizaie.
n afara metodei top-down, informaiile necesare construirii modelului datelor se
pot obine i prin urmrirea documentaiei firmei, ecrane, rapoarte, formulare, din
interiorul sistemului. Acest proces este cunoscut n literatura de specialitate sub numele
de metoda bottom-up.
Elementele rezultate vor figura n diagramele fluxurilor de date prin care vor fi
evideniate datele prelucrate n sistem i de aici va rezulta necesarul de date meninute n
baza de date a sistemului.
58
59
utilizatorului despre care organizaia dorete s pstreze anumite date. Se cuvine precizat
diferena dintre tipurile entitilor (entity types) i cazurile/instanele entitii (entity
instances) [1]. Tipul entitii, cunoscut i sub numele de clasa entitii, este o colecie de
entiti care au proprieti sau caracteristici comune. Referirea general la elementele ce
pot fi catalogate ca entiti se va realiza printr-un substantiv denumit cu litere majuscule,
plasate n interiorul dreptunghiului corespunztor entitii.
O instaniere a entitii sau instan, denumit n continuare, caz al entitii sau
caz, este o manifestare singular a unui tip de entitate. Un tip de entitate se descrie o
singur dat prin modelul datelor, n timp ce mai multe cazuri ale acelui tip de entitate pot
fi reprezentate prin datele stocate n bazele de date. De exemplu, exist o singur entitate
CLIENT, dar ea poate s aib sute sau mii de cazuri/instane ale acestei entiti stocate n
baza de date.
Atribute
Fiecare tip de entitate are un set de atribute asociate lui. Un atribut este o
proprietate sau o caracteristic a unei entiti care prezint interes pentru organizaie. La
rndul lor, i relaiile pot avea propriile lor atribute.
Exemplu de entitate pentru aplicaia DECONTRI i unele dintre atributele
posibile:
CLIENT : CodClient, DenClient, AdresaClient
Ca i numele tipurilor entitilor, numele atributelor sunt substantive scrise cu
majuscule (eventual + minuscule), plasate n interiorul elipselor, legate de entitatea creia
i se asociaz. De multe ori ns, chiar i n cazul folosirii produselor CASE, pentru a nu se
ncrca o diagram entitate-relaie, se evit prezentarea atributelor. Operaiunea se face, n
schimb, n repository, depozitul de informaii despre proiect. Aici orice atribut se descrie
separat, ca orice obiect distinct.
60
62
<nume atribut>
<nume atribut>
<nume atribut>
<atribut1>
<atribut2>
<nume atribut>
Superclasa
Apartenena subclasei la superclas
Subclasa
CodClient
CLIENT
AdresaClient
Relaiile entitilor
O relaie este o asociere ntre cazurile/instanele uneia sau mai multor tipuri de
entiti care prezint interes pentru organizaie. Ele se reprezint printr-un romb ca n
exemplul din figura 3.7.
FURNIZORI
Oferte
PRODUSE
Cardinalitatea relaiilor
Presupunem c exist dou tipuri de entiti, A i B, ntre care exist o linie de
legtur pentru a marca relaia. Cardinalitatea unei relaii este dat de un numr al
cazurilor/instanelor entitii B care pot sau care ar putea s fie asociate cu fiecare caz al
entitii A. Cardinalitatea este sugerat prin 0 (zero), 1, M (multe), cu meniunea c ele
pot avea prezen obligatorie sau opional. Cardinalitatea se poate reprezenta n moduri
diferite, n funcie de notaia folosit. De exemplu, ea poate fi notat cu semne (0, 1, M,
N) sau prin simboluri (linie cu vrf simplu de sgeat pentru 1, linie cu vrf dublu de
sgeat pentru M. Alteori, 1 se reprezint prin linie simpl i M prin vrf de sgeat). n
multe materiale, inclusiv produse CASE, se folosete notaia model-date, cunoscut mai
64
mult sub numele laba-gtei, conform creia cardinalitatea se reprezint prin urmtoarele
simboluri [1]:
obligatoriu 1
opional 0 sau 1
n
NUME CURS
Informatic
Informatic
Informatic
Drept comercial
DATA
PROMOVRII
Iulie 1999
Septembrie 1999
Septembrie 1999
Ianuarie 2000
STUDENT
Promovare
CURS
65
De aici rezult un caz aparte de entitate, numit gerundiv sau compus sau
asociativ care, de fapt, este o relaie folosit de analist n model ca un tip de entitate. n
astfel de cazuri, se folosete un simbol special: dreptunghi cu romb n interior, n care se
scrie numele entitii (fig. 3.9) [1].
Data promovrii
STUDENT
Promovare
CURS
este condus de
conduce
MANAGER
66
implic
ARTICOL VNDUT
face parte din
FURNIZOR
este livrat de
FURNIZOR
este cumprat de la
Figura 3.13. Descrierea relaiilor multiple ntre dou entiti
67
PERSOANA
lucreaz la
PROIECT
este realizat de
VNZARE
coordonator al
raporteaz la
Figura 3.16. Redarea relaiei unei entiti cu ea nsi
68
69
FURNIZORI
Cod produs
Oferte
PRODUSE
70
Cod client
Cod produs
PRODUSE
Vnzri
CLIENTI
Aprovizionare
Cod produs
1
Intrri
Cod Produs+Depozit+Pre
n
PRODUSE
STOCURI
1
Ieiri
Desfacere
Fig. 3.21. Subsistemul Urmrirea stocurilor.
Reprezentarea relaiilor de tip 1-n Intrri, Ieiri, pentru actualizarea stocurilor
Cod produs
Denumire produs
Descriere produs
PRODUSE
Fig. 3.22. Reprezentarea entitii PRODUSE
Cod produs
Cod furnizor
Unitate de msur
Oferte
Fig. 3.23. Reprezentarea relaiei Oferte
71
Localitate
Cod furnizor
Strad
Numr
Adresa furnizor
Denumire furnizor
Oferta
FURNIZORI
Fig. 3.23. Reprezentarea entitii FURNIZORI
Teste rezolvate
1. Studiul sistemului existent const n:
a) studiul activitilor de baz desfurate de sistem;
b) identificarea metodelor si mijloacelor tehnice;
c) definirea caracteristicilor generale ale sistemului;
d) definirea direciilor de perfecionare ale actualului sistem;
e) studiul sistemului de conducere.
Rspuns: a, b, c, e
2. Activitatea de determinare a cerinelor sistemului se concretizeaz n diferite forme ale
informaiilor colectate, cum sunt:
a) copii ale interviurilor;
b) realizarea programului;
c) implementarea sistemului;
d) interpretri ale rspunsurilor la chestionare.
Rspuns: a, d
3. Definirea caracteristicilor generale ale sistemului economic implic:
a) cunoaterea profilului, obiectivelor agentului economic;
b) cunoaterea locului n sfera serviciilor i sfera produciei;
72
73
Rspuns: a
10. Cte entiti externe conine diagrama de context pentru aplicaia Decontri:
a) patru entiti;
b) cinci entiti;
c) nici o entitate.
Rspuns: b
74
75
ntrebri
1. Enumerai metode moderne de analiz i determinarea cerinelor sistemului.
2. Descriei tipurile de legturi care pot exista ntre dou mulimi de entiti.
3. Definii cheia unei relaii.
76
Capitolul 4
Proiectarea logic a sistemelor informatice
Dac n primele etape, au fost identificate i structurate cerinele sistemului, n faza
de proiectare logic se efectueaz deplasarea ateniei de la prezentarea a ceea ce exist i
ce se intenioneaz la descrierea a ceea ce va nsemna noul sistem i cum va funciona.
Prezentarea noului sistem const n prezentarea tuturor intrrilor sistemului, a ieirilor,
precum i a interfeelor i dialogurilor.
4.1. Proiectarea formularelor/formatelor i a rapoartelor
n cadrul etapei de analiz a sistemului informatic, intrrile i ieirile au fost
identificate i prezentate, exprimnd cerinele informaionale la nivelul fiecrui subsistem/
aplicaie informatic. n acel moment nu s-au prezentat toate detaliile privind
formularele/formatele, rapoartele i procesul de modelare a datelor, insistndu-se mai
mult pe identificarea i descrierea lor.
Fiecare format/formular de intrare va fi asociat unui flux al datelor de intrare ntrun proces al DFD, iar rapoartele se pot regsi ntr-un flux al datelor generate de un proces
al DFD.
Un formular/format poate fi un document primar sau o machet de ecran care
conine unele date predefinite, crora li se adaug altele ce urmeaz a fi completate n
rubrici speciale.
Un raport este un document economic n care sunt incluse doar date predefinite,
ceea ce nseamn c poate fi numit i document pasiv, folosit pentru a citi i vizualiza
informaia.
n faza de proiectatre logic se reprezint doar o ciorn a formularelor/formatelor,
rapoartelor sau ecranelor, ele fiind privite doar ca structur i machet, pot fi realizate cu
ajutorul unui editor de texte sau un produs program orientat spre grafic sub forma unui
prototip.
77
antet;
titlu;
date de identificare;
cap de tabel;
totalurile.
frecven;
78
Specificaiile de ieire vor cuprinde, pentru utilizator, macheta situaiei iar pentru
programator macheta situaiei i o serie de indicaii tehnice de realizare.
Pe baza specificaiilor de ieire se trece la proiectarea fizic prin care se alege
suportul informaiilor de ieire, se realizeaz definitivarea formei i formatului de editare
a situaiilor (aezarea n pagina / ecran, spaierea ntre coloane i rnduri, etc.) i se
definitiveaz procedurile de utilizare i interpretare a ieirilor.
Alegerea tipului de suport fizic de ieire (imprimanta, display, disc fix, floppy disc,
banda magnetic etc.) se face n funcie de: timpul de rspuns solicitat, amplasarea
utilizatorului fa de calculator, hard-ul i soft-ul existent, costul suportului, msura n
care rspunde necesitailor de redare a coninutului informaional al situaiei finale.
Cnd se pregtesc ieirile, este bine s se ia n calcul ce se urmrete prin ele, astfel
nct apelarea la categoriile de date de mai sus s se efectueze n cunotin de cauz.
n definitivarea formei i formatului de prezentare a situaiilor finale trebuie s
inem seama de o serie de considerente practice cum ar fi [2]:
-
Restricii tehnice;
Elemente de eficien;
Lizibilitate spaiere;
Respectarea unor cerine ale factorilor de decizie privind macheta situaiei finale
O serie de cerine ale conducerii privind macheta situaiei finale oblig proiectantul
la o anumit structurare i machetare a situaiilor finale. Informaiile se pot mprii n
dou grupe prin prisma sistemelor informatice interne i externe. Informaiile interne
reprezint acele informaii culese, generate sau folosite n interiorul organizaiei.
79
Informaiile externe se refer la cele colectate sau create de la sau pentru parteneri strini
(facturi, rapoarte anuale, etc).
n funcie de informaiile care pot fi vzute din punct de vedere al echipei
manageriale distingem: informaii curente, de atenionare, indicatori de baz, etc.
Restricii tehnice
n proiectarea situaiilor finale intervin o serie de restricii datorate caracteristicilor
i performanelor tehnice ale echipamentelor periferice i anume: numrul maxim de
caractere pe linie; numrul maxim de linii pe pagina / ecran; facilitile de imprimare etc.
Pe pia se afla o gam variat de echipamente de redare a rezultatelor. Exist mai multe
tipuri de imprimante, console i terminale video, ceea ce creeaz posibilitatea unei alegeri
adecvate a perifericelor destinate obinerii diverselor tipuri de situaii finale.
Elemente de eficien
n proiectarea situaiilor finale nu trebuie sa scape ateniei i aspectele de eficient
economic privind: reducerea timpului calculator consumat cu editarea propriu-zisa a
situaiilor; economie de hrtie de imprimant. Abilitatea i experiena proprie a
programatorilor joac n acest sens un rol important.
n vederea optimizrii obinerii situaiilor finale pe imprimant se pot folosi de la
caz la caz, diverse tehnici cum ar fi: editarea mai multor tabele pe aceeai pagin de
imprimant; editarea unei situaii imprimnd fa/verso pe aceeai coal;
Pentru a nu irosi timp cu editarea unor situaii finale voluminoase se recomand
mai nti rularea unor programe scurte care s verifice cheile de control aplicate. Numai
dac aceste chei sunt corecte, eventual verificate i de utilizator, se poate lansa editarea
analitica a situaiilor finale. Programele care editeaz situaii finale voluminoase trebuie
prevzute cu posibilitatea de ntrerupere (respectiv de reluare a editrii n cazul unor
incidente ivite n timpul rulrii) sau editarea lor sub forma unui fiier ASCII sau text pe
hard disc sau floppy disc, urmnd imprimarea ulterioara a acestui fiier, total sau parial.
Lizibilitate spaiere
Parcurgerea unei situaii finale trebuie s fie ct mai uoara, citirea unei situaii
nu trebuie s dea natere la ambiguiti. Este necesar ca situaia sa fie autoexplicativ.
80
Pentru aceasta, antetul va conine informaii i coduri ce vor indica sursa de emitere a
raportului, exprimnd clar, sintetic, coninutul raportului i perioada la care se refer.
Capul de tabel, mpreuna cu titlul i antetul, se afieaz pe urmtoarele pagini
numai dac au intervenit schimbri n cadrul caracteristicilor de grupare fa de prima
pagin, altfel se imprim doar numerotarea coloanelor de tabel.
Informaiile importante pot fi subliniate. Totalurile se separ de informaiile
analitice. Informaiile care se repet pe linii succesive se imprim o singur dat.
Utilizarea formularelor pretiprite
Aceasta implica utilizarea unei hrtii de imprimanta ce cuprinde elemente fixe ale
situaiei finale, cum ar fi antetul, titlul, capul de tabel, textul explicativ etc. Aceasta
conduce la o cretere a vitezei de editare i o diminuare a uzurii imprimantelor, riboanelor
etc. Totodat situaiile obinute sunt mai estetice i sunt uor de parcurs de utilizatori.
Utilizarea monitoarelor sau terminalelor video
Prin intermediul unui soft adecvat, monitoarele sau terminalele video ofer
posibilitatea afirii situaiilor finale, att n regim alfanumeric, ct i n regim grafic,
alegerea modului de lucru fcndu-se prin intermediul unor comenzi sau comutatori.
Ecranul unui terminal video n regim alfanumeric este alctuit din linii i coloane
iar n regim grafic ecranul este privit ca o matrice de puncte denumite pixeli.
Reprezentarea informaiilor de ieire sub forma grafic reprezint un pas nainte
fa de editarea sub forma de text a rapoartelor. Aceast form de afiare se recomand
factorilor de decizie de pe nivelele de conducere superioare, dat fiind gradul de sintetizare
a informaiilor de ieire i volumul redus al rapoartelor.
Pe lng problemele legate de aezarea informaiilor pe ecran, la proiectarea
ecranelor de ieire se iau n considerare i facilitile oferite de monitoare sau terminalele
video i anume: regimul de lucru (defilare ecran, pagina sau linie); regimul de afiare
(normal, mai luminos, cu intermitente, invers video); regimul de semnalizare sonor
(normal, semnal sonor dup afiarea unui cmp etc.).
81
Este indicat a se utiliza, acolo unde este cazul, sistemele de codificare existente la
nivelul economiei naionale (CAEN, SIRUES, SIRUTA, CNP, etc).
83
mai ales pentru necesitile curente ale salariailor societii economice. Nu este
recomandabil s dublm documentele primare, prin proiectarea unor documente destinate
exclusiv prelurii datelor pentru necesitile prelucrrii automate.
Macheta documentului primar trebuie s conin:
-
denumirea documentului;
coduri de identificare,
data documentului;
84
preluarea asistat a unor coduri (ex. utilizare tehnici de tip Lookup wizard n
ACCESS)
85
86
mouse;
joystick;
touch screen atingerea ecranului constituie modalitatea prin care are loc
selecia;
87
Proiectarea dialogurilor
Proiectarea dialogurilor este procesul prin care sunt proiectate toate secvenele
folosite de utilizator pentru a comunica cu un sistem informatic. Rolul proiectantului este
de a selecta cele mai potrivite metode i echipamente, precum i de a prezenta condiiile
n care se pot afia informaiile sau se pot obine de la utilizator.
Pentru a obine rezultate bune trebuie s se in seama de regulile de baz la
conceperea dialogurilor cum ar fi: uniformitate, comenzi scurte, uurina n lucru,
controlul, operaiunea invers (refacerea unui element ters), rezolvarea erorilor, etc.
O modalitate de prezentare a secvenei dialogurilor este cea care apeleaz la
tehnica diagramelor prin care se reprezint meniurile componente ale aplicaiei.
MO1
MENIU_PRINCIPAL
MO2
PO1
ADUGARE
PO2
MODIFICA
PO3
MENIU
INTEROGARE
TERGERE
PROCES
MENIU
PO4
PO5
I_DUP_AN
I DUP NUME
obinerea unui model logic al datelor din care s se poat realiza proiectul bazei
de date fizice funcie de tipul de SGBD utilizat: relaional cel mai utilizat n
prezent, reea, ierarhic, sau orientate-obiect;
Modelarea logic a datelor descrie datele cu ajutorul unei notaii speciale, care
corespunde unui mod de organizare a acestora de ctre un sistem de gestiune a bazelor de
date. Procesul de modelare a datelor este complex. n fiecare etap a ciclului de via se
regsete cte o activitate specific datelor dup cum urmeaz [1]:
-
89
Ecranul Cel mai bun client al produsului X, prin percepia utilizatorului, are
urmtorul format:
Cel mai bun client al produsului
Introducei codul produsului:
P1122
Data de nceput:
10/10/99
Data de sfrit:
31/12/99
---------------- -------- ------COD CLIENT:
1111
NUME CLIENT:
S.C. ALPHA S.R.L.
VOLUM:
1000
Figura 4.3 Model de ecran solicitat de utilizatori [1]
90
91
un set de relaii normalizate. Din analiza diagramei din figura 4.5 se desprind urmtoarele
relaii:
CLIENT(COD_CLIENT, NUME, ADRESA)
PRODUS(COD_PRODUS, DENUMIRE)
FACTURA(NR_FACTURA, NR_COMANDA)
COMANDA(NR_COMANDA, COD_CLIENT)
LINIE_COMANDA(NR_COMANDA, COD_PRODUS, CANTITATE_COMANDATA)
LIVRARE(NR_FACTURA, COD_PRODUS, CANTITATE_LIVRATA)
Pasul al patrulea compar modelul obinut din pasul doi cu cel din pasul trei i
integreaz perspectivele utilizatorilor n vederea obinerii unui model logic final, dup
cum urmeaz:
CLIENT(COD_CLIENT, NUME, ADRESA)
PRODUS(COD_PRODUS, DENUMIRE)
FACTURA(NR_FACTURA, NR_COMANDA, DATA_FACTURA)
COMANDA(NR_COMANDA, COD_CLIENT, DATA_COMANDA)
LINIE_COMANDA(NR_COMANDA, COD_PRODUS, CANTITATE_COMANDATA)
LIVRARE(NR_FACTURA, COD_PRODUS, CANTITATE_LIVRATA)
Rezultatul modelrii logice a datelor l constituie relaiile normalizate rezultate din
cel de-al patrulea pas al procesului. De asemenea, alt rezultat se va concretiza n
actualizarea depozitului (repository) sau a dicionarului proiectului. Diferena major ntre
modelarea conceptual i cea logic este c dup modelarea logic a datelor cerinele
structurate de date se concretizeaz n relaii, i nu n entiti. Din cauza normalizrii nu
este necesar o coresponden unu-la-unu ntre entiti i relaii [1].
92
NUME_CLIENT
COD_CLIENT
ADRESA
NR_FACTURA
CLIENT
FACTURA
Lanseaz
Facturare
CANTITATE_LIV
COMANDA
Livrare
NR_COMANDA
PRODUS
Linie_comand
CANTITATE_
COMANDATA
COD_PRODUS
DENUMIRE
93
94
client, n caz contrar baza de date devine inconsistent (acelai client poate apare la adrese
diferite).
Aceste anomalii pot fi eliminate, dac schema de relaie Prestari_Servicii se
nlocuiete prin urmtoarele dou scheme de relaie:
Clienti(Cod, Nume_client, Adresa)
Servicii(Cod, Serviciu_prestat, Valoare).
Relaia Clienti conine codul, numele i adresa fiecrui client, fr nici un fel de
redundan, iar relaia Servicii conine serviciile prestate pentru fiecare client i valorile
acestor servicii. Un dezavantaj al descompunerii relaiei iniiale n cele dou relaii este
acela c pentru a determina adresa clientului pentru care s-a prestat un anumit serviciu
este necesar efectuarea unei operaii de cuplare a relaiilor Clienti i Servicii.
Se consider o schem de relaie R i A,B dou atribute simple sau compuse ale
schemei de relaie R. Atributul A determin funcional atributul B sau B depinde funcional
de A, dac i numai dac oricrei valori a atributului A i corespunde o singur valoare a
atributului B (se noteaz A->B).
Dependena funcional A->B este total dac nu exist nici un subset C al atributului
A (CcA) astfel nct C->B i este parial n caz contrar.
n relaia Prestari_Servicii, una din dependenele funcionale care poate fi pus n
eviden este Nume_client->Adresa.
Deoarece ntr-o relaie orice cheie identific n mod unic fiecare tupl a relaiei,
deci determin n mod univoc valorile atributelor tuplei, rezult c n orice relaie
atributele sunt dependente funcional fa de cheile acesteia.
Se pot face, pn n acest moment, urmtoarele precizri:
Eliminarea dependenelor funcionale din schemele de relaie i a consecinelor
negative (redundana datelor; anomaliile de adugare, tergere, actualizare) se realizeaz
prin descompunerea schemei date ntr-o colecie de scheme mai simple n care sunt evitate
neajunsurile mai sus menionate. Reconstituirea relaiei iniiale se poate face prin operaia
de cuplare (uniune). Pentru ca descompunerea schemei de relaie s fie echivalent cu
relaia iniial, trebuie s fie ndeplinite condiiile:
95
atribut prim sau neprim nu poate fi dependent funcional fa de un alt atribut dac acesta
nu este sau nu conine o cheie).
Dependene multivalorice
Pentru ilustrarea acestui tip de dependene se ia n considerare urmtoarea schem
de relaie:
Clase(Clasa, Discipline, Elevi)
ce conine clasele dintr-o instituie de nvmnt, iar pentru fiecare clas sunt nregistrate
disciplinele ce se predau i elevii nmatriculai n clasa respectiv. Se poate constata c
relaia Clase poate rezulta prin operaia de cuplare dup atributul Clasa a urmtoarelor
dou relaii:
CD(Clasa, Discipline)
CE(Clasa, Elevi)
n relaia Clase, presupunnd c pentru o clas dat, fiecare elev frecventeaz toate
disciplinele nregistrate pentru acea clas, exist dependenele multivalorice:
Clasa ->> Discipline
Clasa ->> Elevi.
Ca i n cazul dependenelor funcionale, existena dependenelor multivalorice
prezint aceleai neajunsuri privind redundana datelor i anomalii la efectuarea operaiilor
de adugare, actualizare i tergere nregistrri n baza de date.
O relaie R este n a patra form normal dac singurele dependene multivalorice
admise sunt cele determinate de un alt atribut care este o cheie sau care conine o cheie a
relaiei.
ntruct orice dependen funcional este un caz particular de dependen
multivaloric, rezult c orice relaie care se afl n forma normal FN4, se afl i n forma
normal FNBC. Transformarea unei relaii ntr-o colecie de relaii care s se afle n FN4
este similar cu trecerea n FNBC, ns trebuie avut n vedere att eliminarea
dependenelor funcionale ct i a dependenelor multivalorice.
n concluzie, putem afirma c n cazul formelor normale de la FN1 la FN4,
trecerea de la o form normal la alta s-a fcut prin descompunerea unei relaii n altele
97
relaiei, mpreun cu anomaliile pe care acestea le creeaz. n cadrul unei relaii pot exista
dependene de cuplare care nu conduc la redundan n memorarea datelor i nu produc
anomalii la operaiile efectuate asupra nregistrrilor bazei de date (acestea sunt
dependenele de cuplare implicate de o cheie a relaiei).
O relaie este n forma normal cinci (FN5) dac i numai dac toate dependenele
de cuplare existente n relaie sunt implicate de o cheie a acesteia. Relaia SDS se poate
descompune, cu conservarea coninutului de informaie, n cele 3 componente ale sale: SD,
SS i DS care sunt n FN5.
Avnd n vedere similaritatea ce exist ntre definiiile pentru FNBC, FN4 i FN5,
acestea pot fi unificate n urmtoarea definiie [DORO98]:
O relaie R este n FNBC, FN4, FN5 dac i numai dac singurele dependene
funcionale, multivalorice, de cuplare existente sunt cele implicate de o cheie a relaiei R.
n concluzie, prin procesul de normalizare se realizeaz eliminarea din schemele de
relaie a dependenelor (funcionale, multivalorice i de cuplare) cu scopul de a obine o
schem relaional mai bun din punctul de vedere al redundanei datelor i al anomaliilor
ce pot apare la operaiile de adugare, tergere i actualizare nregistrri n baza de date.
Normalizarea unei scheme de relaie R nseamn nlocuirea acesteia cu o mulime de
proiecii R1,...,Rn astfel nct R s fie echivalent cu uniunea proieciilor R1,...,Rn. Dei
normalizarea este o operaie util n proiectarea bazelor de date, aceasta nu ofer
ntotdeauna reete pentru obinerea celor mai bune modele i de aceea este la latitudinea
proiectantului decizia de a aplica sau nu o anumit etap de normalizare dup o analiz
temeinic a avantajelor i dezavantajelor modelului obinut. n unele cazuri
normalizarea complet, pn la FN5, s-ar putea s fie dezavantajoas. Avnd n vedere
constatrile de mai sus se poate afirma c dei normalizarea nu reprezint o soluie
general valabil n orice situaie, totui dac pentru proiectarea bazei de date se
aplic corect o metodologie de proiectare descendent, modelul rezultat va fi de la sine
normalizat. Cercetrile n acest domeniu continu, fiind definite i alte forme normale
printre care FN6 pentru baze de date temporale. O baz de date temporal, pe lng datele
curente, conine i date istorice, iar factorul (atributul) timp are un rol esenial (exemple
99
concludente de astfel de baze de date sunt depozitele de date). Astfel, n proiectarea unei
baze de date temporale trebuie avute n vedere i alte operaii de descompunere a schemelor
de relaie i anume:
-
n proiectarea unei baze de date nu este exclus nici operaia invers normalizrii
numit denormalizare [DATE04], prin care se urmrete nlocuirea unei colecii de
scheme de relaie cu o schem de relaie echivalent n vederea eliminrii necesitii
efecturii unor operaii de cuplare care pot fi costisitoare. Dac n cazul normalizrii
tendina este de a ajunge la nivele ct mai nalte (FN5), pentru denormalizare nu exist
criterii clare putnd fi avute n vedere doar aspecte legate de performanele anumitor
aplicaii.
Un alt principiu care se urmrete n proiectarea unei baze de date este principiul
proiectrii ortogonale conform cruia n cadrul unei baze de date dou scheme de relaie
reale (variabile de relaie de baz) nu trebuie s aib semnificaii suprapuse. n timp ce
prin normalizare se urmrete reducerea redundanei din cadrul unei scheme de relaie,
prin proiectarea ortogonal se urmrete reducerea redundanei dintre schemele de relaie.
4.3.2. Simplificarea structurii datelor prin normalizare
Problema de baz a proiectrii logice a bazelor de date este cum ar trebui
combinate datele elementare pentru a forma relaii(sau tipuri de nregistrri) care s
descrie entitile i relaiile dintre entiti. n limbajul bazelor de date, cuvntul relaie
nseamn un tabel de date, ceea ce duce la concluzia c bazele de date relaionale
(modelul relaional) sunt cldite pe un grup de tabele legate ntre ele [1].
Modelul relaional a fost dezvoltat de ctre Codd. Este un model conceptual de
organizare a datelor, destinat reprezentrii legturilor dintre date. El este bazat pe teoria
matematic a relaiilor i este definit cu o deosebit rigoare matematic [Popescu I.,
1996].
100
n cadrul modelului relaional datele sunt structurate sub forma de relaii (de aici i
denumirea). Cea mai directa i intuitiva modalitate de reprezentare a datelor n cadrul
acestui model este sub forma de tabele. Fiecrei relaii i se poate asocia un tabel care are
attea coloane cte mulimi leag relaia i are attea linii cte tuple conine relaia.
Prezentarea structurii relaionale a datelor impune definirea noiunilor de:
domeniu, relaie, atribut i schem a unei relaii. Conceptele utilizate pentru a descrie
formal, uzual sau fizic elementele de baz ale organizrii datelor sunt prezentate n tabelul
urmtor:
Formal
Uzual
Fizic
Relaie
Tablou
Fiier(tabel)
Tuplu
Linie
nregistrare
Atribut
Coloan
Cmp
Domeniu
Tip de dat
Tip de dat
Definirea domeniului
Un domeniu este o mulime de valori caracterizat printr-un nume. Un domeniu se
poate defini explicit prin enumerarea tuturor valorilor aparinnd acestuia sau definind o
proprietate distinctiv a domeniului valorilor, de cele mai multe ori limita superioar i
limita inferioar [6]. De exemplu:
D1: {F,M}
-definire explicit
-definire implicit
-definire implicit
101
Definirea relaiei
O relaie R pe mulimile D1,D2,,Dn este o submulime a produsului cartezian
D1xD2xxDn, deci o mulime de tupluri [6].
Considernd c nu se cunosc dect dou persoane, relaia R se definete prin
tuplurile care descriu aceste persoane, i anume:
R: {<Maria,F,50>,<Vasile,M,60>}
O relaie poate fi reprezentat printr-un tabel bidimensional n care fiecare linie
corespunde unui tuplu i fiecare coloan corespunde unui domeniu.
R:
D3
D1
D2
Maria
50
Vasile
60
PERS D3
D2
D3
Maria
50
Vasile
Vasile
60
Maria
102
103
Necesitatea normalizrii progresive este dat de faptul c anumite relaii pot genera
o serie de situaii nedorite, aa-numitele anomalii de actualizare, cum sunt: anomalia de
tergere, anomalia de adugare, anomalia de modificare [2].
4.3.3. Transformarea diagramelor entitate-relaie n relaii
Pentru a se putea compara rezultatele obinute n etapa de proiectare logic a
datelor, adic a relaiilor normalizate, cu diagrama entitate-relaie, rezultat al proiectrii
conceptuale, aceasta din urm trebuie s fie convertit n relaii, de asemenea,
normalizate.
ntregul proces se desfoar n patru pai, astfel: [1]
-
Teste rezolvate
1. Afirmaiile urmtoare nu sunt corecte:
a) Fiecare Format/formular de intrare va fi asociat unui flux al datelor de intrare
ntr-un proces al DFD;
b) Un proces al DFD va fi asociat cu o macheta de ecran;
c) Rapoartele se pot regsi ntr-un flux al datelor generate de un proces al DFD.
Rspuns: b
2. Prezentarea informaiile din formulare/formate i rapoarte pot fi oferite:
a) sub form de text;
b) sub form de sfaturi;
c) sub form de grafice;
d) sub form de tabele.
Rspuns: a, c, d
3. Macheta imprimantei cuprinde:
a) antet;
b) titlu;
c) date elementare ce se imprima rnd de rnd;
d) totalurile.
Rspuns: a, b, c, d
4. Detaliile i indicaiile tehnice de realizare a machetei imprimantei se refer la:
a) volumul datelor de ieire;
b) intensitatea datelor;
c) contrast.
Rspuns: a
5. Alegerea tipului de suport fizic de ieire (imprimanta, display, etc.) se face n funcie
de:
a) sursa de energie; b) calitatea datelor; c) costul suportului.
Rspuns: c
6. n definitivarea formei i formatului de prezentare a situaiilor finale trebuie s inem
seama de o serie de considerente practice cum ar fi:
a) Respectarea unor cerine ale factorilor de decizie privind macheta situaiei
finale;
b) Restricii tehnice;
c) Utilizarea formularelor pretiprite;
d) Utilizarea generatoarelor de rapoarte.
105
Rspuns: a, b, c, d
7. Activitile parcurse la realizarea unui sistem de coduri sunt:
a) analiza elementelor care urmeaz a fi codificate;
b) analiza sistemului decizional;
c) uniformizarea datelor de intrare;
d) alegerea tipurilor de coduri.
Rspuns: a, d
8. La proiectarea intrrilor este necesar s se realizeze, n principal urmtoarele activiti:
a)
b)
c)
d)
b) keyboard;
c) mouse.
Rspuns: b, c
b) produselor CASE;
106
107
Capitolul 5
Proiectarea fizic a sistemelor informatice
Proiectarea fizic cunoscut i sub numele de proiectare de detaliu, urmeaz
proiectrii logice ntlnit i sub numele de proiectare general sau proiectare de
ansamblu. n timpul proiectrii logice se prezint o imagine de ansamblu (general) a
sistemului, n timp ce proiectarea fizic nseamn o abordare detaliat a sistemului. Cu
alte cuvinte, n etapa de proiectare logic se acumuleaz informaiile de natur s
sintetizeze cerinele utilizatorilor noului sistem, operaiune prestat de analitii de sistem,
iar n timpul proiectrii fizice se prezint punctele de vedere ale specialitilor, cum ar fi
cei din domeniul bazelor de date, securitii sistemelor, reelelor de calculatoare,
programrii, etc.
Proiectarea fizic implic parcurgerea urmtorilor pai [1]:
1. Proiectarea fizic a bazelor de date i a fiierelor. O astfel de activitate nseamn
descrierea modului n care vor fi stocate datele i cum se va asigura controlul lor
pentru a se oferi o securitate maxim;
2. Proiectarea structurii sistemului i a programelor. Se descriu programele sau modulele
acestora care s fie n strns concordan cu diagramele fluxurilor de date i cu
celelalte piese ale documentaiei realizate n etapele anterioare;
3. Proiectarea strategiilor de prelucrare distribuit. Se vor prezenta modalitile n care
utilizatorul poate s dispun de date i facilitile de prelucrare oferite de reele de
calculatoare.
5.1. Proiectarea fizic a bazelor de date i a fiierelor
Modelul conceptual surprinde structura global de organizare a datelor,
asigurndu-se independena total fa de orice sistem de gestiune a bazelor de date.
Modelul conceptual este prezentat prin intermediul diagramelor entitate-relaie(DER),
motiv pentru care este cunoscut i sub numele de modelul entitate-relaie al datelor. El
scoate n eviden reprezentarea logic, detaliat a entitilor, asocierilor (legturilor) i
108
datelor elementare ale unei organizaii sau ale unei pri din ea. Modelul se realizeaz n
faza de analiz.
Modelul logic al datelor nseamn descrierea datelor n concordan cu modelul de
organizare a acestora de ctre sistemele de gestiune a bazelor de date. n acest material s-a
ales modelul relaional. Conform cu acest model datele sunt reprezentate n baza de date
sub forma tabelelor sau relaiilor create din diagrama entitate-relaie obinut n etapa
anterioar.
O baz de date poate fi definit ca un ansamblu de date elementare sau structurate,
accesibile unei comuniti de utilizatori. Mai concret, la nivel fizic, o baz de date este un
ansamblu de fiiere intercorelate, care conine nucleul de date necesare unui sistem
informatic (aplicaie informatic). Un fiier este un ansamblu de nregistrri fizice,
omogene din punct de vedere al coninutului i al prelucrrii. O nregistrare fizic este
unitatea de transfer ntre memoria intern i cea extern a calculatorului. nregistrarea
fizic este format din una sau mai multe nregistrri logice. O nregistrare logic este
unitatea de prelucrare din punct de vedere al programului utilizator. Aceasta este format
dintr-un ansamblu de cmpuri, care descriu o anumit entitate.
Modul de stocare a datelor pe suportul fizic de memorare este funcie de sistemul
de gestiune a bazelor de date utilizat.
Proiectarea fizic a bazelor de date i a fiierelor i propune s asigure trecerea de
la descrierea logic a datelor la una tehnic, de stocare a datelor. O problem de
importan major n cadrul acestei etape o constituie alegerea Sistemului de Gestiune a
Bazelor de Date adecvat soluionrii optime a problemelor formulate n etapele anterioare
ale realizrii sistemului informatic.
5.1.1. Obiectivele fundamentale ale unei baze de date (BD) sunt:
Centralizarea datelor permite: suprimarea redundanei, asigurarea unicitii
nregistrrii i controlul centralizat (asupra datelor). n prelucrarea clasic n care fiierele
sunt dedicate aplicaiilor, aceleai date apar nregistrate n mai multe fiiere i n formate
109
Securitatea datelor. Baza de date trebuie s fie protejat mpotriva unei distrugeri
logice (anomalie de actualizare) sau fizice. Pentru aceasta exist instrumente care permit:
-
crearea unor puncte de repriz; altfel spus, salvarea din timp n timp a unor
copii coerente ale bazei de date;
controlul accesului la baza de date prin intermediul unui limbaj de control DCL
(Data Control Language) care asigur:
-
mecanism de vizualizare, prin care un utilizator poate vedea acea parte a bazei
de date care l intereseaz.
111
algoritmi de criptare printre care cel mai recent este standardul american de criptare
avansat AES (Advanced Encryption Standard).
5.1.4. Proiectarea securitii bazelor de date i a fiierelor
Securitatea este abordat din mai multe puncte de vedere, dar cea referitoare la
baze de date i la fiiere presupune luarea unor msuri pentru reconstituirea datelor
pierdute sau preluate eronat, precum i pentru accesul neautorizat sau incomodarea pn
la a face imposibil citirea datelor, prin criptare, atunci cnd ele sunt accesate ilegal.
Aadar dou aspecte vor fi relevante: reconstituirea datelor i criptarea lor [1].
Reconstituirea datelor este des asociat cu existena fiierelor de tip back-up, ns
n practic este posibil i reconstituirea fr apelarea la acest tip de fiiere. n vederea
controlrii corectitudinii datelor tranzacionate se apeleaz la fiiere cu rol special, care
conin un istoric, n ordine cronologic, al schimbrilor i accesrilor efectuate asupra
fiierelor sau bazelor de date. Cu ajutorul lor se pot reconstitui fiierele distruse, dar i la
verificarea corectitudinii operaiunilor de actualizare.
Securitatea prin criptografiere se refer la asigurarea transformrii datelor de
comunicat ntr-o form neinteligibil pentru toi ceilali receptori, exceptndu-l pe cel
autorizat. Criptarea a devenit una dintre cele mai puternice modaliti de asigurare a
securitii datelor. Ea poate fi realizat prin sistemul de operare sau prin SGBD, dar i
prin rutine create de ctre specialiti.
n cele ce urmeaz sunt prezentate criteriile avute n vedere n alegerea tipului de
SGBD [2].
a) Portabilitatea SGBD-ului. Prin aceasta nelegem posibilitatea de a utiliza un
SGBD de pe un sistem de calcul pe un altul. Portabilitatea cuprinde dou aspecte i
anume: portabilitatea programelor propriu-zise i portabilitatea datelor. Pentru
realizarea unor programe portabile este necesar ca: programele s conin ct mai
puine elemente legate de echipament. Portabilitatea sistemului de gestiune privit
prin prisma portabilitaii datelor se refer la posibilitatea de a folosi o serie de date
113
utilizate n cadrul unui sistem informatic de ctre un alt sistem informatic, deci
posibilitatea integrrii fiierelor deja existente n cadrul unui alt sistem.
b) Costul sistemului. Acest criteriu trebuie privit prin prisma: timpului de ocupare a
unitii centrale; costului de ntreinere i dezvoltare; resurselor hard imobilizate;
costului de adaptare i trecere pe un nou sistem de calcul; costul documentaiei etc.
c) Facilitile de implementare, ntreinere i exploatare a bazei de date. Acestea sunt
reflectate prin: modalitatea de descriere a datelor; tehnicile de organizare i
regsire a datelor, care s permit un acces ct mai rapid la orice informaie; timpul
ct mai redus pentru actualizare, cutare i rspuns la cererile de informare;
editarea operativ a celor mai variate tipuri de situaii solicitate de ctre utilizator;
posibilitatea de inserie a unor programe de aplicaie, programe de validare de date,
de actualizare, rutine statistice, rutine de sortare, rutine de prezentare grafic a
ieirilor etc.
d) Posibilitatea gestionarii structurilor complexe de date.
e) Multitudinea metodelor de acces. In funcie de cerinele proprii aplicaiei, sistemul
va trebui s suporte interogri sau actualizri n timp real avnd proceduri de tip
conversaional.
f) Protecia i securitatea datelor din baz.
g) Specificul aplicaiei. Este cunoscut faptul c programele sunt orientate pe aplicaii,
cum ar fi: programarea produciei, aprovizionare-desfacere, optimizri, prognoze
etc.
Toate aceste criterii de alegere pot fi corelate cu o serie de factori complementari
cum ar fi: mentenana sistemului, facilitile ce le ofer administratorului bazei de date,
calitatea documentaiei oferite de furnizori, asisten n implementarea sistemului i n
pregtirea utilizatorilor etc. Toi aceti factori alturi de criteriile enunate pot s
influeneze succesul n implementarea SGBD-ului i eficiena economic pe ansamblul
sistemului informatic.
114
2. Calculul relaional prin care interogrile descriu mulimea tuplelor rezultat prin
specificarea unui predicat (condiie) care trebuie satisfcut de aceste tuple.
ncepnd din 1986 limbajul SQL a devenit standard ANSI pentru limbajele de
interogare ale bazelor de date relaionale fiind utilizat att n cadrul unor SGBD-uri
complexe cum ar fi SGBD ORACLE (liderul mondial n domeniul bazelor de date), ct i
n cadrul unor SGBD-uri de complexitate redus cum ar fi cele din familia xBase (Dbase
IV, FoxPro).
Standardul SQL utilizat pn la nceputul anului 2000 este cel realizat n 1992 i
cunoscut sub numele de SQL92 sau SQL2.
Noul standard SQL3 lansat n 1999 are n vedere o serie de extensii fa de SQL2
dup cum urmeaz:
115
faciliti multimedia;
primul atribut conine valorile atributelor relaiei dup care se creaz indexul;
(conform
drepturilor
GRANT/REVOKE).
117
de
acces
specificate
cu
comenzile
Asupra unei vederi se pot efectua aceleai operaii ca i asupra unei relaii cu
deosebirea c vederile nu conin date i c orice modificri efectuate asupra datelor sunt
reflectate i n vederi. Astfel, asupra unei vederi se pot realiza operaiile:
-
Crearea unei vederi se realizeaz cu comanda CREATE VIEW care are sintaxa:
CREATE VIEW <nume vedere> [<lista atribute>]
AS <fraza SELECT> [WITH CHECK OPTION]
Exemplu:
CREATE VIEW StocuriD1(Codp,Denp,Ump,Cant,Pret,Valoare)
AS SELECT Stocuri.Codp, Denp,Ump,Cant,Pret,Cant*Pret FROM
Produse,Stocuri WHERE Produse.codp=Stocuri.Codp AND CodDep = D1
Interogarea vederii se va realiza cu comanda
SELECT * FROM StocuriD1
Utilizarea opiunii WITH CHECK OPTION asigur faptul c nici o tupl nu va fi
adaugat sau actualizat cu instruciunile INSERT, UPDATE, dac nu sunt respectate
condiiile specificate n clauza WHERE a instruciunii SELECT din definiia vederii.
Pentru acordarea sau retragerea drepturilor de acces la baza de date prin
intermediul vizualizrilor se vor folosi comenzi de forma:
GRANT [ALL|SELECT|INSERT|UPDATE|DELETE] ON <nume vedere>
TO <nume utilizator>
sau
REVOKE [ALL|SELECT|INSERT|UPDATE|DELETE] ON <nume vedere>
FROM <nume utilizator>
118
119
Unui utilizator i pot fi acordate mai multe tipuri de autorizri n cadrul unei
singure comenzi GRANT.
Parola stabilit pentru un utilizator poate fi modificat printr-o comand GRANT
ulterioar spre exemplu astfel:
GRANT RESOURCE TO <nume utilizator> IDENTIFIED BY <noua parol>
Unui utilizator cruia i s-a acordat un tip de autorizare i pot fi acordate i alte
tipuri de autorizare prin comenzi GRANT ulterioare.
Retragerea autorizrilor acordate unui utilizator se realizeaz cu comanda:
REVOKE <autorizare,> FROM <nume utilizator>
Nivelul 2 de securitate a datelor
Pentru acordarea respectiv retragerea drepturilor de acces la relaii se utilizeaz
comenzile GRANT respectiv REVOKE cu urmtoarea sintax:
GRANT ALL|<drept de acces>, ON <nume relaie>
TO <nume utilizator>|PUBLIC [WITH GRANT OPTION]
respectiv
REVOKE ALL|<drept de acces>, ON <nume relaie>
FROM <nume utilizator>|PUBLIC
Privilegiile (drepturile de acces) pot fi acordate sau retrase de urmtoarele categorii
de utilizatori:
-
proprietarii relaiilor;
120
Drepturile de acces pot fi acordate asupra ntregii relaii, sau doar asupra anumitor
atribute ale relaiei.
Exemple:
Acordarea tuturor drepturilor de acces
121
122
123
ORCL
124
ORCL
125
operatori de
comparare (=, #,<, >, <=, >=, <>), parantezele ( ) pentru schimbarea ordinii de prioritate a
operaiilor, operatorilor, funcii i alte subinterogri SELECT, pentru construirea de
expresii pe care trebuie s le ndeplineasc tuplele ce constituie rezultatul interogrii.
Predicatul IN permite specificarea unei liste pentru domeniul de cutare pentru un atribut,
iar predicatul BETWEEN permite specificarea unui interval pentru domeniul de cutare a
valorilor unui atribut, fiind echivalent cu o condiie de forma:
<atribut> >= <limita inf. interval> AND <atribut> <= <limita sup. interval>
126
Exemple:
Fie tabela Persoane(Nrcrt,Nume,Prenume, Datan, Sexul, Adresa)
Selectarea tuturor nregistrrilor din tabela Persoane pentru care primele 7
caractere din cmpul Adresa sunt Suceava sau Rdui se realizeaz cu comanda:
SELECT * FROM Persoane WHERE SUBSTR(Adresa,1,7) IN (Suceava,Rdui)
Interogarea de mai sus este echivalent cu interogarea:
SELECT * FROM Persoane WHERE SUBSTR(Adresa,1,7) = Suceava
OR SUBSTR(Adresa,1,7) = Rdui
Selectarea tuturor nregistrrilor din tabela Persoane pentru care data naterii este
cuprins ntre 01/01/72 i 01/01/82 se realizeaz astfel:
SELECT * FROM Persoane WHERE Datan BETWEEN {01/01/72} AND {01/01/82}
Interogarea de mai sus este echivalent cu interogarea:
SELECT * FROM Persoane WHERE Datan >= {01/01/72} AND Datan <= {01/01/82}
Predicatul LIKE permite selecia irurilor de caractere care conin anumite
caractere specificate prin intermediul unei mti definite cu ajutorul unor caractere
speciale (%, _ n dBASE IV, FoxPro, ORACLE, sau *, ? n INFORMIX)
Exemple:
SELECT * FROM Persoane WHERE Nume LIKE %a
(selecteaz toate nregistrrile din tabela Persoane pentru care valorile atributului Nume
se termin cu litera a).
SELECT Nume,Prenume,Datan FROM Persoane WHERE Nume LIKE A%u
(selecteaz valorile atributelor Nume, Prenume, Datan pentru toate nregistrrile din
tabela Persoane pentru care prima liter din Nume este A iar ultima liter este u).
SELECT Nume FROM Persoane WHERE Nume LIKE _o%
(selecteaz valorile atributului Nume pentru toate nregistrrile din tabela Persoane pentru
care prima liter din Nume este orice liter, a doua liter din Nume este litera o i
ncepnd din poziia a treia numele poate conine orice litere.)
127
(selecteaz pentru fiecare grup de nregistrri avnd aceeai valoare n cmpul CodP,
nregistrarea cu preul maxim mai mic dect 150000)
Clauza ORDER BY permite precizarea ordinii de afiare a datelor astfel:
ORDER BY <nume atribut 1> [ASC]|DESC,<nume atribut 2>[ASC]|DESC,
Exemplu:
SELECT * FROM Persoane ORDER BY Datan DESC,Nume
(afieaz toate nregistrrile din tabela Persoane n ordine descresctoare dup data
naterii i n cadrul aceleiai date a naterii cresctor dup Nume)
Clauza UNION permite obinerea rezultatului a dou sau mai multe interogri
printr-o singur instruciune SELECT.
Exemplu:
SELECT CodDep,CodP,Cant FROM Stoc_Prod WHERE CodDep = Dep01
UNION
SELECT CodDep,CodP,Cant FROM Stoc_Prod WHERE Cant >= 100
(selecteaz tuplele (CodDep,CodProd,Cant) din tabela Stoc_Prod pentru toate
nregistrrile
pentru
care
CodDep
Dep01,
la
care
adaug
tuplele
(CodDep,CodProd,Cant) din tabela Stoc_Prod pentru toate nregistrrile pentru care Cant
>= 100).
Pentru a nu se elimina tuplele duplicat trebuie specificat UNION ALL.
Pentru a schimba ordinea de afiare a tuplelor extrase se poate utiliza clauza
ORDER BY aplicat doar relaiei finale i nu asupra fiecrei fraze SELECT.
Regsirea datelor din dou sau mai multe relaii
Interogarea datelor din dou sau mai multe tabele (relaii) presupune existena unor
cmpuri comune pentru realizarea operaiei de cuplare (operatorul JOIN). n fraza
SELECT operaia de cuplare este definit n clauza WHERE sub forma:
<nume tabela1>.<cheie1> = <nume tabela2>.<cheie2>
(unde <cheie1>, <cheie2> reprezint cmpurile ce identific nregistrrile corespondente
n cele dou tabele).
129
instruciuni SELECT
valori pentru condiia de cutare a instruciunii SELECT exterioare care o conine (numit
i outer). O sub-interogare poate returna o singur valoare, sau poate returna mai multe
valori.
n ce privete ordinea de evaluare a interogrilor pot exista :
-
Spre exemplu dac presupunem c n tabela Stocuri unele produse pot apare de
mai multe ori cu preuri diferite i ne intereseaz poziiile cu preul minim, formulm
urmtoarea interogare:
SELECT A.CodP,A.Cant,A.Pret FROM Stocuri A
WHERE A.Pret = (SELECT MIN(B.Pret) FROM Stocuri B WHERE A.CodP = B.CodP)
Sub-interogri simple care returneaz o singur valoare - pot fi utilizate n
interogri imbricate avnd sintaxa:
SELECT <lista atribute> FROM <lista relaii>
WHERE <atribut>
=
<
>
<=
>=
!=
(<sub-interogare>)
[ORDER BY <atribut[ASC]|DESC,]
131
Exemplu:
SELECT CodDep,CodP,Cant FROM Stocuri
WHERE Cant > (SELECT AVG(Cant) FROM Stocuri ) ORDER BY CodDep
(afieaz produsele pentru care exist stocuri peste medie, ordonate pe depozite).
Sub-interogari simple care returneaza mai multe valori pot fi utilizate n interogri
imbricate care utilizeaz n clauza WHERE condiii care genereaz o mulime de valori
folosind unul din predicatele: (NOT)IN, (NOT)ANY, (NOT)ALL, (NOT)EXISTS.
Exemplu:
SELECT * FROM Produse WHERE CodP IN (SELECT CodP FROM Facturi
WHERE Numar IN (SELECT Numar FROM Beneficiari,Comenzi
WHERE Beneficiari.Nume=Ionescu AND Beneficiari.Cod_B=Comenzi.Cod_B))
Predicatul ANY poate fi utilizat n combinaie cu oricare din operatorii <, >, =, <=,
>=, != i permite verificarea dac valoarea unui atribut satisface condiia precizat pentru
orice valoare din lista rezultat din subinterogare.
SELECT CodP FROM Stocuri WHERE Cant > ANY
(SELECT Cant FROM Stocuri WHERE CodDep = D1)
Predicatul ALL returneaz toate tuplele pentru care valorile atributului din clauza
WHERE sunt <, >, <=, >= dect toate valorile generate de interogarea interioar (acest
predicat nu poate fi utilizat cu operatorul = ce ar corespunde cazului banal n care toate
interogrile din list sunt egale).
Exemplu:
SELECT * FROM Stocuri WHERE Cant < ALL
(SELECT Cant FROM Stocuri WHERE CodDep = D1)
Predicatul EXISTS verific dac pentru fiecare tupl a relaiei exist tuple care
satisfac condiia din interogarea interioar (deci EXISTS permite specificarea mai multor
atribute n interogarea interioar). Astfel spre exemplu instruciunea:
SELECT * FROM Produse A WHERE NOT EXISTS
(SELECT * FROM Stocuri B WHERE B.CodP=A.CodP)
va returna o list de produse care nu au nici o nregistrare n Stocuri.
132
Aplicaie practic
Se consider baza de date Furnizori_Clieni_Stocuri care conine urmtoarele
tabele (n ACCESS):
PRODUSE (catalog de produse)
Cmp
Semnificaie
Tip dat
Codp
Cod produs
Number, Integer
Denp
Denumire produs Text
Desp
Descriere produs Hyperlink
STOCURI (stocurile de produse pe depozite)
Cmp
Semnificaie
Tip dat
Codp
Cod produs
Number, Integer
Lookup Wizard
CodDep
Cod depozit
Text
Ump
Unitate de
Lookup Wizard
msur produs
Cant
Cantitate
Number, Integer
Pret
Pre unitar
Number,
LongInteger
FURNIZORI (catalog de furnizori)
Cmp
Semnificaie
Tip dat
Codf
Cod furnizor
Number, Integer
Denf
Denumire
Text
furnizor
Adresaf
Adresa furnizor
Text
CLIENTI (catalog de clieni)
Cmp
Semnificaie
Codc
Cod client
Denc
Denumire client
Adresac
Adresa client
Tip dat
Number, Integer
Text
Text
Dimensiune Observaii
4
Cheie primar
20
Refer document
corespunztor
Dimensiune Observaii
4
Lookup Wizard cu
tabela PRODUSE
2
8
Creare i utilizare
list de valori
4
8
Dimensiune Observaii
4
Cheie primar
30
25
Dimensiune Observaii
4
Cheie primar
30
25
Dimensiune Observaii
4
Lookup Wizard cu
tabela FURNIZORI
4
Lookup Wizard cu
tabela PRODUSE
8
Creare i utilizare
Pret
msur produs
Pre unitar
Datao
Oferta
Data ofertei
Oferta furnizor
list de valori
Number,
LongInteger
Date
Hyperlink
8
8
Refer document
corespunztor
Unitate de
msur produs
Cantitate
Pre unitar
Cant
Pret
Dimensiune Observaii
4
Lookup Wizard cu
tabela CLIENTI
4
Lookup Wizard cu
tabela
PRODU,03SE
8
Creare i utilizare
list de valori
4
8
Lookup Wizard
Number, Integer
Number,
LongInteger
Codf
Furnizori
Denf
Furnizori
Adresaf
Furnizori
Codp
Produse
Denp
Produse
Ump
Oferte
Pret
Oferte
Datao
Oferte
c) Situaia vnzrilor
Cmp
Tabela
Codc
Clienti
Denc
Clienti
Adresac
Clienti
Codp
Produse
Denp
Produse
Ump
Vanzari
134
Cant
Vanzari
Pret
Vanzari
Valoare
Cant*Pret
Datav
Vanzari
Codp
Denp
135
Instruciunile constituie cel mai jos nivel al operaiunilor ce pot fi executate de ctre un
limbaj de programare. Blocurile de instruciuni sunt astfel grupate nct s constituie
anumite structuri executabile de calculator. De modul n care sunt grupate instruciunile
pentru a da natere unor structuri standard ale programelor, de relaiile dintre instruciuni,
de aranjamentul acestora depinde calitatea softului proiectat.
Modulul este o colecie sau o form grupat de instruciuni de programe surs.
Modulele se pot grupa pentru a forma programele.
Programul, n concepia diverilor autori, are semnificaii diferite. El este definit
ca:
-
136
n timp s-au conturat mai multe metode sau tehnici de programare prezentate
sumar n cele ce urmeaz..
Metoda programrii clasice are la baz construirea monolitic a logicii
programului, fr intenii de structurare. Programul este privit n totalitatea lui i analizat
direct la nivelul operaiilor elementare pe care le implic executarea lucrrii care se
elaboreaz .
Programarea modular const n descompunerea programului, chiar din faza de
proiectare, n module uor de ntrebuinat. Fiecare modul este apoi analizat ca un program
distinct i rezolvat ca atare [1].
Metoda programrii structurate const n faptul c ofer o rezolvare standardizat
i structurat, n mod unitar, a programelor, reprezentnd o ridicare a activitii de
programare la nivelul activitii industriale, fundamentat pe o metodologie tiinific.
Programarea structurat este caracteristic dezvoltrii sistemelor pe baza diagramelor
fluxului de date i utilizeaz limbaje structurate. Ea presupune o separare ntre structurile
de date i codul funciilor care le prelucreaz.
Metoda programrii orientate-obiect - const n abordarea natural a lumii reale,
folosind componente modularizate i eliminnd restriciile impuse de mediul de
programare. Se definesc concepte noi de tip, clas, motenire, etc [Udric M., 2000].
137
Un modul este format dintr-un grup de instruciuni care sunt contigue din punct
de vedere fizic i sunt executate ca o unitate distinct;
139
Fiecare element din cele enunate (secvena, selecia, iteraia) care respect
restriciile de mai sus definete un bloc standard i sunt reprezentate n continuare [1].
Structura secvenial (liniar) se prezint astfel:
i1
i2
in
NU
DA
Bloc - 2
Bloc - 1
140
Bloc - 1
Bloc - n
Bloc - 2
Bloc - 1
DA
NU
Structura repetitiv condiionat posterior (de tip DO UNTIL) are forma din figura 5.9.
Bloc - 1
DA
NU
V=Vi
Bloc - 1
V=Vi+R
V>Vf
NU
DA
suficiente pentru a defini structura de control a oricrui program. Din acest motiv, cele
trei structuri de control, enumerate mai sus, sunt numite structuri de control fundamentale
sau structuri de baz.
143
Pe baza unor funciuni identificate sau a altor raiuni de programare, modulele pot
fi divizate n continuare. Scopul acestei structurri funcionale pn la nivel elementar
este de a identifica funciunile sistemului i de a le separa, eventual, n funciuni generale
i cu caracter specific aplicaiei.
Modulele funcionale pot fi descompuse apoi dup criteriul omogenitii, rezultnd
modulele operaionale.
Realizarea modular a produselor program presupune urmtoarele aciuni [2]:
-
144
NOD
o configuraie de reea;
145
nivelul serviciilor.
Sistemul propus trebuie s fie fezabil, din punct de vedere tehnic, i eficient, prin
prisma costurilor prelucrrii automate a datelor i a comunicaiilor din sistem.
Performanele sistemului sunt influenate de mai muli factori, cum ar fi timpul de
rspuns, randamentul, disponibilitatea, sigurana(securitatea sistemului).
La proiectarea sistemelor distribuite trebuie avute n vedere dou componente
majore:
-
Proiectarea nodurilor;
Proiectare subsisteme
de COMUNICAII
Proiectare NODURI
Proiectare
INTERFEE
Figura 5.12. Principalele module de proiectare a sistemelor de prelucrare distribuit a datelor
146
astfel nct s poat folosi n comun toate echipamentele i software-ul din reea. Dintre
toate calculatoarele, exist unul sau unele mai puternice pe care se vor afla aplicaii
folosite n comun de celelalte calculatoare ale reelei. Cea mai utilizat arhitectur este
arhitectura client/server.
Arhitectura client/server
Modelul Client /Server ofer date distribuite, portabilitate ntre platforme i un
acces standardizat la resurse. Termenul de Client /Server provine de la metoda
tradiional de accesare a unui computer central numit server de ctre computere aflate la
distan sau clieni ntr-o infrastructur de reea.
Modelul Client /Server
cereri, acestea fiind ndeplinite de o alt entitate software(serverul) . Clientul este cel care
transmite o cerere severului, acesta o interpreteaz i apoi o efectueaz. Pentru a putea
ndeplini cererea, serverul poate referi o surs de informaie (baze de date), s efectueze
procesri asupra datelor, s controleze periferice sau s efectueze cereri adiionale altor
servere. Un client poate face cereri la multiple servere i un server poate deservi mai muli
clieni.
Cerere
Client
Server
Rezultatul
ndeplinirii cererii
147
arhitectura de tip server de pagini cea mai mare parte a prelucrrilor este
realizat de ctre client. Serverul este responsabil de memoria secundar i
furnizeaz paginile corespunztor cererilor formulate de client;
arhitectura de tip server de baz de date cea mai mare parte din prelucrrile
bazei de date este efectuat de ctre server. Clientul transmite cererea
serverului, primete rezultatele i le transmite aplicaiei. Este modul utilizat
frecvent de ctre sistemele relaionale.
148
n fiecare dintre cele trei cazuri serverul se gsete pe aceeai main ca i baza de
date fizic. Clientul se poate afla pe aceeai main sau pe una diferit. n cazul bazelor
de date distribuite pe mai multe maini, clientul va comunica cu cte un server de pe
fiecare main. De asemenea mai muli clieni pot comunica concomitent cu acelai
server (accesul concurent).
Arhitectura tradiional a sistemelor client-server este o arhitectur pe dou nivele
(etaje), n care la primul nivel (clientul) se realizeaz interfaa cu utilizatorul i logica
principal a aplicaiei, iar la al doilea nivel (serverul) se realizeaz validarea datelor i
accesul la baza de date. Necesitatea rezolvrii unor probleme complexe care presupun
accesul la baza de date a unui numr mare de utilizatori, utilizarea unor platforme hardsoft diferite, precum i integrarea bazelor de date n mediul Web, au impus definirea unei
noi arhitecturi client-server n care sunt definite trei nivele i anume:
-
Un server de aplicaie poate servi mai muli clieni, fiind conectat fizic att la
nivelul client ct i la nivelul server de baze de date. Spre exemplu n mediul Web,
clientul poate fi un browser Web, iar serverul de aplicaie poate fi un server Web.
Teste rezolvate
1. Proiectarea fizic a sistemelor informatice nseamn:
a) o abordare detaliat a sistemului;
b) o abordare de ansamblu a sistemului;
c) o abordare general a sistemului;
Rspuns : a
2. Proiectarea fizic a sistemelor informatice implic:
a) proiectarea fizic a bazelor de date i a fiierelor.
b) proiectarea structurii sistemului i a programelor.
149
150
Rspuns : a
9. Realizarea modular a programelor corespunde principiilor:
a) programrii clasice;
b) programrii structurate;
c) bazelor de cunotine;
Rspuns : b
10. Principalele module de proiectare a sistemelor de prelucrare distribuit a datelor sunt:
a) proiectarea nodurilor;
b) proiectarea diagramelor;
c) proiectarea reelei de comunicaii.
Rspuns : a, c
11. Nu sunt componente de baz ale tehnologiei client/server:
a) clientul;
b) administratorul de sistem;
c) serverul;
d) reeaua care conecteaz clientul la server.
Rspuns : b
12. Care dintre urmtoarele instruciuni nu sunt decizionale ?
a)
b)
c)
d)
e)
151
ntrebri i rspunsuri
1. Enumerai arhitecturile de baz pentru un sistem client-server dup rolul pecare l
au componentele client i server;
Rspuns:
-
152
Capitolul 6
Instrumente CASE
n general, un instrument CASE (Computer Aided Systems/Software Engineering)
este un pachet software care ofer suport n proiectarea i implementarea sistemelor
informatice. Prin integrarea numeroaselor tehnici utilizate n pregtirea proiectrii unui
sistem, incluznd aici dicionarul datelor, fluxul de date, relaiile ntre entiti, un software
de tip CASE poate determina o cretere a gradului de corectitudine cu care se realizeaz
proiectarea unei baze de date.
Altfel spus, termenul CASE se refer la totalitatea instrumentelor i metodelor
destinate ingineriei software asistat de calculator. Aceste produse software asigur suport
n etapa de analiz i de proiectare facilitnd reprezentarea grafic n cadrul acestor etape.
Dei instrumentele CASE sunt numite uneori generic instrumente de modelare
ER ceea ce ar nsemna c pot doar s creeze modelul logic, n realitate un instrument de
tip CASE are mult mai multe faciliti. Un instrument CASE realizeaz n primul rnd
legtura ntre modelul utilizator i modelul logic ce formalizeaz modelul utilizator
folosind un mod de reprezentare comun att acestuia ct i proiectantului bazei de date.
Un instrument de tip CASE nu elimin ns posibilitatea ca modelul final obinut
s fie proiectat greit. n scopul evitrii acestei situaii este necesar o pregtire de durat
a utilizatorului. Dac acesta are experien n lucrul cu instrumente CASE, utilizarea unui
produs nou este facil deoarece toate instrumentele de modelare se bazeaz pe aceleai
principii i au relativ aceleai faciliti. Dac ns utilizatorul este nou n domeniu,
trebuie luat n considerare timpul necesar realizrii unui model i timpul necesar
verificrii acestuia de ctre o persoan cu experien.
Problema CASE-ului (Proiectarea Sistemelor/Programelor asistat de calculator
sau cu Ajutorul Calculatorului Computer Aided Systems/Software Engineering) a
devenit foarte important la mijlocul anilor 1980, cnd hardul sa extins prin seria PCurilor, iar reelele au devenit
153
creterea integrrii;
155
156
descompunerea;
integrarea.
157
n cele ce urmeaz se vor prezenta cteva exemple de CASE folosite de cele mai
utilizate metodologii de analiz i proiectare, respectiv metodologia structurat i cea
orientat pe obiecte.
A) Metodologia structurat
Westmount I-CASE Yourdon ofer suport complet pentru realizarea sistemelor
informatice. Avnd la baza metoda structurat propus de Yourdon, acest instrument
CASE integrat ofer posibilitatea lucrului n echip, posibilitatea de generare i reutilizare
a codului i generarea automat a documentaiei de realizare a sistemului informatic.
Repository este componenta central a arhitecturii Westmount I-CASE Yourdon.
Repository este implementat cu ajutorul unui SGBD relaional: Informix, Ingres sau
Oracle.
Analyst, este componenta ce ofer suport pentru analiza structurat. Metoda este
implementat de Yourdon i De Marco. Westmount I-CASE Yourdon ofer suport pentru
un set extins de instrumente i anume editoare pentru diagrame de flux a datelor,
diagrame entitate asociere, diagrame de structur a datelor editoarele matriciale pentru
matricea listei de evenimente.
Arhitect este componenta ce permite definirea arhitecturii sistemului (proiectarea
de ansamblu).
Designer este componenta ce ofer suport pentru proiectarea de detaliu a
sistemului informatic.
Proiectarea de detaliu a aplicaiei este strns legat de proiectarea bazei de date.
Pentru modelarea datelor se utilizeaz diagrama entitate asociere.
158
159
160
Erwin Data Modeler permite utilizarea modelelor complexe prin mprirea lor n
submodele mai uor de gestionat. Modelele realizate pot fi vizualizate, modificate i
tiprite la imprimant n multiple moduri. RPTwin este o component nglobat n Erwin
care permite realizarea de rapoarte i conine un set de rapoarte predefinite i de asemenea
ofer posibilitatea realizrii unor rapoarte personalizate.
Fereastra principal Erwin Data Modeler este prezentat n figura 6.1.
161
AllFusion Erwin Data Modeler suport trei tipuri de modele pentru proiectarea
bazelor de date:
Logic: Model conceptual (global) care include entiti, relaii i atribute, eseniale
obinerii unui model Entitate Relaie.
Fizic: Model detaliat care implic specificarea tabelelor, atributelor i a tipului de
date asociat.
Logic/Fizic: Un model care nglobeaz att modelul fizic ct i modelul logic.
Pentru a crea un model, se alege opiunea New din meniul File. Fereastra Create
Model este prezentat n figura 6.2.
162
Formatul bazei de date se alege din seciunea Target Database. n figura de mai sus s-a
ales formatul Acces. Noul model va fi denumit implicit Model_n. Pentru a-l redenumi se
execut click dreapta pe numele modelului din fereastra Model Explorer i se alege
opiunea Properties. Redenumirea se realizeaz prin introducerea noului nume n cmpul
Name, figura 6.3.
164
165
automatizat (wizard) ghideaz utilizatorul pentru o preluare mai facil a bazelor de date
deja existente n alte formate i pentru conectarea la diverse surse de baze de date.
Proiectarea unei baze de date cu ajutorul Visio presupune parcurgerea urmtoarelor
etape:
a) Crearea modelului ORM (Object Role Model) care permite crearea unui model
intuitiv al bazei de date (stabilirea entitilor, a atributelor acestora, evidenierea
relaiilor dintre entiti).
b) Generarea automat a modelului logic pe baza modelului ORM
c) Generarea modelului fizic pe baza modelului logic obinut anterior
Interfaa de creare a tabelelor (entitilor) este similar cu aceeai interfa din
programul Microsoft Access cu deosebirea c, n cazul Visio, tabelele pot fi portabile
independent de sistemul de gestionare a bazelor de date.
.
Figura 6.9. Opiunile meniului Database.
Este posibil importul modelelor realizate cu alte instrumente CASE. Ca etap
intermediar ntre generarea modelului logic i generarea modelului fizic este necesar
validarea modelului (Database->Model-> Error Check). n acest caz este posibil
167
apariia unor erori care vor fi afiate n fereastra de afiare a rezultatelor. Cele mai
comune tipuri de erori pot aprea n urmtoarele dou situaii:
-
coloanele cu aceeai denumire din tabele diferite sunt diferite din punct de
vedere al tipului datelor.
Pentru a genera baza de date se selecteaz din meniul Database opiunea Generate.
Se va lansa automat validarea modelului i se poate opta pentru generarea unui script
DDL ce conine comenzile SQL corespunztoare generrii fiecrei tabele i relaii din
baza de date. Este util selectarea opiunii Store current database image in model pentru
ca modificrile ulterioare aduse bazei de date s determine doar o adugare a acestora i
nu crearea de la zero a bazei de date modificate. n final Visio va genera entitile,
indecii i relaiile bazei de date. Rezultatul acestei cod va fi afiat n fereastra de afiare a
rezultatelor. Ca ultim etap, se recomand o verificare a codului respectiv, ntruct pot
aprea erori. Visio 2007 permite salvarea sub form de pagin Web a modelelor realizate.
Diagramele ER se pot salva n diverse formate grafice cu scopul utilizrii ulterioare n
documentaiile diverselor proiecte.
Toad data modeler
Toad Data Modeler export diagramele ER n format HTML, RTF sau n format
imagine (.jpg sau .bmp). Atuurile acestui program sunt urmtoarele:
-
ingineria invers;
168
Pentru a creea un nou model n Toad Data Modeler se alege din meniul File
opiunea New. n continuare se alege formatul bazei de date int, pentru care va fi
generat scriptul SQL. Pentru Access 2000 nu se genereaz script SQL, ns se genereaz
cod VBA (Visual Basic for Applications). Codul surs poate fi executat ca i Modul n
fereastra editorului Visual Basic din Access 2000. Mai nti va trebui creat o baz de
date vid i inserat un modul Visual Basic. n modulul respectiv se copie codul generat de
programul Toad. n continuare, din fereastra editorului Visual Basic se alege opiunea
Reference din meniul Tools i se selecteaz DAO 3.6 libraries for MS Access 2000 i se
lanseaz n execuie modulul din opiunea Run. Din meniul Model, opiunea Insert se
insereaz toate elementele grafice ale modelului: entiti, atribute i diverse tipuri de
relaii. Dac se dorete modificarea tipului unei relaii create n prealabil, se execut click
dreapta pe relaia respectiv i se alege opiunea Edit Relationship. Se va afia fereastra
din figura 6.10.
171
Figura 6.12. Opiunile disponibile pentru crearea unui nou model n ER/Studio
Dup cum se constat din figura 6.12, sunt posibile trei variante de creare a
modelului: crearea unui model nou, posibilitatea de a importa un model din fiiere SQL,
ERX sau dintr-un format extern de descriere a datelor.
Facilitatea inginerie invers utilizeaz conexiunea direct cu o mare varietate de
tipuri de baze de date. Odat cu accesarea acestei opiuni se lanseaz un wizard care va
afia o list cu tipurile de baze de date compatibile i care vor fi ulterior transformate n
modele logice sau fizice. Obiectele asupra crora se poate aplica procesul inginerie
invers sunt: tabelele i vederile, tabelele definite de utilizator, procedurile i funciile
memorate. Se detecteaz de asemenea automat integritatea n cazul n care nu este
declarat explicit n baza de date. ER/Studio va mpri elementele capturate dintr-o baz
de date n dou categorii, corespunztoare modelului logic i modelului fizic. Prin
vizualizarea modelului logic, utilizatorul poate vizualiza proprietile asociate unei tabele,
cum ar fi atributele, relaiile i eventualele restricii. Programul nu elimin restriciile
legate de cheia strin declarate explicit ci va semnala o cheie strin prin afiarea
simbolului FK lng aceasta.
ER/Studio permite crearea diagramelor entitate relaie n totalitate pornind de la
zero sau obinerea acestora cu ajutorul facilitii inginerie invers. Produsul scaneaz
bazele de date i ajut utilizatorii n eliminarea redundanelor prin extragerea metadatelor.
172
173
174
codul generat poate reflecta doar eventualele modificri aduse asupra tabelelor;
codul generat este stocat modular astfel nct este posibil modificarea doar a
unui modul i regenerarea modulului modificat.
Teste rezolvate
15. Obiectivul principal al instrumentelor CASE este:
a) Punerea n practic a produselor-program de proiectare i realizare a softului cu
ajutorul calculatorului.
175
176
177
Programmer este mediul de programare care ofer suport pentru generarea codului surs,
compilare, lansare n execuie i testarea aplicaiei. Generatorul de cod genereaz codul
DDL (n SQL) ce definete structura fizic a bazei de date i codul aplicaiei n limbajul C
mbogit cu instruciuni SQL pornind de la specificaiile din schemele de structur.
Docwriter este componenta care permite generarea documentaiei pentru fiecare etap de
realizare a sistemului.
3. Instrumentele CASE orientate-obiect, din punct de vedere al etapelor ciclului de via
al sistemelor, pot fi grupate n instrumente:
Rspuns:
Upper CASE orientat-obiect pentru analiza i proiectarea sistemelor;
Lower CASE orientat-obiect pentru generarea codului-surs al aplicaiilor;
I-CASE orientat-obiect care acoper ntregul ciclu de via.
178
Capitolul 7
Tendine actuale i de perspectiv n evoluia sistemelor informatice
7.1. Concepia sistemic n economie
ncepnd din anii 80, n teoria general a sistemelor apare i se dezvolt o nou
concepie i anume concepia holonic asupra sistemelor. Aproximativ n aceeai perioad
se dezvolt sistemele inteligente, ca structur de baz n domeniul inteligenei artificiale.
Un sistem holonic este [TACU98], [BURA99] un sistem de referin deschis n
cadrul cruia funcioneaz alte sisteme autonome, fiind posibil desprinderea i
ataarea de sisteme autonome att n plan abstract ct i n plan real, iar optimizarea
vizeaz att sistemele componente ct i sistemul de referin. n acest context, dou sau
mai multe sisteme autonome pot fi integrate n baza unor criterii i pentru atingerea unor
obiective, formnd astfel un nou sistem de referin, respectiv sistemul holonic care are
rolul de integrator i care optimizeaz funcionarea i rezultatele obinute de sistemele
ncorporate.
Arhitectura general a unui sistem holonic este reprezentat n figura 7.1
[TACU98], [BURA99].
S1
INPUTS
S2
SI
OUTPUTS
.
.
.
Sn
FEEDBACK
179
180
184
rezolvarea unor probleme complexe n diverse domenii care necesit expertiz uman,
fiind ns restricionat de domenii bine delimitate i ineficient pentru procesri
numerice i gestiunea unor volume mari de date. Cele dou tehnologii la ora actual
distincte, tind s evolueze convergent n cadrul conceptului de sistem informaional
inteligent care presupune elaborarea unui model unificat date-cunotine. n acest sens,
sistemele de baze de date au n vedere exprimarea semanticii n schemele lor
conceptuale i capacitatea de infereniere (baze de date deductive), iar sistemele bazate
pe cunotine tind s rezolve probleme care reclam baze de cunotine (fapte i reguli)
din ce n ce mai mari. Pentru exploatarea maxim a celor dou resurse informaionale,
bazele de date i bazele de cunotine, nu este suficient doar cuplarea sistemelor de
gestiune a bazelor de date cu sistemele expert prin intermediul unor interfee n cadrul
aplicaiilor, fiind necesar proiectarea fiecreia din cele dou componente ca o extensie
natural a celeilalte astfel nct mpreun s conduc la realizarea unui sistem integrat.
n acest sens cercetrile sunt ndreptate n urmtoarele direcii:
dotarea SGBD cu instrumente suplimentare de structurare i manipulare
avnd n vedere semantica datelor (un pas important n aceast direcie l
constituie bazele de date deductive);
dotarea sistemelor expert cu instrumente care s permit accesarea i
manipularea eficient a informaiei stocate n bazele de date;
valorificarea informaiei din bazele i depozitele de date prin tehnici de
analiz multidimensional i data mining.
7.2. Categorii de sisteme inteligente
n realizarea sistemelor inteligente s-au conturat urmtoarele abordri principale:
sisteme expert bazate pe reguli, n care cunotinele sunt reprezentate prin reguli de
producie;
sisteme bazate pe reele neuronale, n care baza de cunotine este creat automat
de un algoritm de nvare plecnd de la o mulime de exemple de nvare, baza de
185
186
187
Sistemele
multi-agent
cognitive
urmresc
simuleze
aspecte
ale
188
189
prelucrarea complex a
informaie;
2. un strat pentru furnizorii (productorii) de informaie definete oferta de informaie;
3. un nou strat aflat ntre primele dou, denumit stratul de mijloc sau stratul
intermediarilor, care s permit conectarea primelor dou straturi prin cele mai
bune
ci sau modaliti.
n cadrul acestui model, agenii au un rol important difereniat pe straturi dup cum
urmeaz:
sarcinile agenilor n cadrul primului strat sunt de a afla ce informaii caut
utilizatorii, dac au anumite preferine n legtur cu informaia de care au
nevoie, etc.;
n cadrul celui de-al doilea strat sarcinile agenilor sunt de a face un inventar al
serviciilor i informaiilor oferite de ctre furnizori, de a ine evidena noilor
informaii adugate n reea, etc.;
agenii din stratul de mijloc au rolul de intermediari informaionali ntre
utilizatorii informaionali (umani sau electronici) i furnizorii de informaii,
sarcina lor fiind de mediere ntre agenii celorlalte dou straturi.
Agenii utilizai ntr-un astfel de model vor trebui concepui n baza unor standarde
general acceptate, astfel nct s rspund i s reacioneze n acelai mod prin utilizarea
unui set standardizat de coduri suficient de flexibil pentru a permite construirea unor
ageni pentru sarcini neateptate sau imprevizibile n prezent.
Referitor la domeniile de utilizare a tehnologiei agenilor n viitor, cercettori n
domeniu cred [DANA02] c agenii autonomi vor deveni n urmtorii 10 ani parte
integrant a celor mai multe sisteme de afaceri. Astfel, cei de la IBM prevd o vast
utilizare a agenilor software n e-commerce: Crem o nou categorie economic (a new
191
192