Academia de Studii Economice - Bucuresti

Facultatea de Contabilitate i Informatica de Gestiune

Prof.univ dr. Rosca I. Ioan Prof.univ dr. Zaharie Dorin

PROIECTAREA SISTEMELOR
INFORMATICE
DE GESTIUNE

2006-2007
 CUPRINS

I . PROIECTAREA SISTEMICA

Slide 3 22. Concepte de baza ale proiectarii sistemelor informatice:

Slide 3 16. Sistemul informational si sistemul informatic
Slide 17 22. Metode de proiectare sistemice
Slide 23 - 164. Metoda de proiectare sistemica
Slide 23. Modelarea Conceptuala a Datelor (MCD) MCD
Slide 24-33. Concepte de baza
Slide 34-56. Restrictii de integritate
Slide 57-63. Reprezentarea timpului
Slide 64-77. Subtipuri de entitati
Slide 78-86. Reguli referitoare la Modelul Conceptual al Datelor
Slide 87-93. Dependentele functionale
Slide 94-101. Normalizarea
Slide 102-164. Modelarea Conceptuala a Prelucrarilor (MCP)
MCP
Slide 105-135. Concepte de baza
Slide 136-146. Validarea modelelor
Slide 147-164. Modelarea Logica a Datelor (MLD)
MLD
Slide 154-164. Trecerea de la MCD la MLD
Slide 165- Modelarea Logica a Prelucrarilor (MLP)
MLP
 1. CONCEPTE DE BAZA ALE PROIECTARII
SISTEMELOR INFORMATICE

1.1. Sistemul informational

- este un ansamblu de principii, concepte, reguli si tehnici folosite

pentru culegerea, inregistrarea si transmiterea datelor in vederea
prelucrarii, pentru a obtine informatii care stau la baza luarii deciziilor;

Se defineste prin trei ipostaze:

- un continut formal automatizabil;

- un continut neformal, viu, dinamic;
- un continut orientat catre proiectul unui decident.
a) J.L.Le. Moigne vede sistemul informational ca un sistem al
organizatiei legat de SISTEMUL OPERAND (DE EXECUTIE) si
SISTEMUL DE PILOTAJ (DE DECIZIE)

SISTEM DE PILOTAJ

SISTEMUL
INFORMATIONAL

I SISTEM OPERAAND E
(DE EXECUTIE)
b) J. Meles Sistemul informational reprezinta un ansamblu
interconectat a tot ce duce la informarea membrilor unei organizatii:
viziune globala sistemica;
informatia este destinata personalului unui agent economic;
retea complexa de informatii vii, dinamice care intereseaza
indivizii unei intreprinderi.

c) J.C. Emery Sistemul informaional include componente ce execut

funcii bine stabilite: Recunoaterea, Transmiterea, Stocajul,
Compararea, i distribuirea informaiei.
H.C. Lucas Sistemul informaional se refer la totalitatea
procedurilor organizate, nct s permit furnizarea de informaii
necesare lurii deciziilor i/sau controlului organizaiei.
Sistemul informational sub aspect:

static presupune:
- inregistrarea faptelor survenite in baza informationala
- inregistrarea structurilor de date, a regulilor si a restrictiilor
in modelul datelor.
dinamic presupune:
- procesarea informatiilor (aducerea la zi a datelor memorate ) in

baza de date si schimbarea structurilor, regulilor si restrictiilor

modelului de date, restrictiilor modelului de date.

Fluxul informational - alcatuit din:

- parteneri (interventii externe);
- domenii si subdomenii (interventii interne);

Fluxul = schimburi intre participanti (fizici, financiari, informare)

Exemplu:

CLIENT LICHIDITATI
PRODUS

LIVRARE BANCI

PRODUS INTREPRINDER VIRAMENT

E

Mesajul = Fluxul unui ansamblu de

informatii
Exista doua tipuri de mesaje:

a) Un mesaj pleaca de la declansator (generator)

- generatorul declanseaza actiunea;
- emitentul asteapta o reactie din partea receptorului;
- obtinerea de rezultate;

b) Un mesaj care pleaca de la informant

- generarea unei memorizari;
- informarea asupra unei situatii date fara a se astepta un
raspuns imediat;
- miscarea.
Sistemul informatic (Sistem de automatizare a informatiei) este:
-o componenta a sistemului informational in care toate
transformarile (prelucrarile) semnificative ale datelor in
informatii sunt efectuate de calculator;
-necesar sa fie formalizat pentru a fi automatizat :

continutul intrarilor determina iesirile

INTRARI PRELUCRARI IESIRI.

INTRARI PRELUCRARI IESIRI

Baze
de
date
Doc.
primare Situatii
PROCEDURI
AUTOMATE
1. Intrarile (date) - reprezentate de:

Tranzactii externe:
- redau dinamica operatiilor economice;
- provin din exteriorul sistemului electronic de calcul si sunt
realizate
de proceduri automate;
Ex. inregistrarea unei operatii de aprovizionare cu materiale.

Tranzactii interne:
- redau modificarile structurale in cadrul bazei de date;
- sunt asigurate exclusiv in sistemul electronic de calcul prin
proceduri
automate.
Ex. Situatia stocurilor si soldurilor la o anumita data
2. Prelucrarile :

Ansamblu omogen de proceduri automate (creare,

actualizare, exploatare etc.) care actioneaza asupra
bazei de date.

3. Ieirile (informaii)

- rezultatul prelucrrii bazei de date;

- n funcie de forma i coninutul acestora
- indicatori sintetici
- lista / situatii
- grafice
- stocare pe suporturi magnetice
In fluxul sistemului informatic (de la intrare ctre ieire), unele date se
regsesc la ieire in forma iniial, n timp ce altele particip la operaii
de calcul (n funcie de formula de calcul) dnd natere unor parametrii
(informaii) de ieire.

Prelucrari
(Transferari)

Calcule
Sistemul informatic poate fi constituit
din mai multe subsisteme.

PRELUCRARI

Tranzacii interne

Act. B.D.
INTRARI Consultare
-stocare
-cautare
-control BD
(Tranzacii -calcule
-aducere
externe) zi

IESIRI externe

Situatii
 PRELUCRARI
INTRARI
EXTERNE IESIRI
EXTERNE

Act. BD Consultare
BD
FACTURI
COMENZI

SUB-SISTEMUL FACTURARE

INTRARI
IESIRI EXTERNE
EXTERNE
Consultare Act.
BD
EXTRAS DE CONT

NREGISTRAREA
SUB-SISTEMUL CLIENILOR
BALANA CLIENI
CONTABILITATEA CLIEN}ILOR

ALTE INFORMAII
 PRELUCRARI
INTRARI IESIRI
SUB-SISTEMUL
EXTERNE EXTERNE
FACTURARE
Act. Consultare

BD

Extras de cont
Consultare Act.

Balana clieni SUB-SISTEMUL

CONTABILITATEA
CLIENTILOR
IESIRI INTRARI
EXTERNE EXTERNE
Ciclul de via al unui sistem informatic -cuprinde perioadele:

Schema director

1. CONCEPEREA Studiul detaliat

Studiul prealabil (Evaluare)

Studiul tehnic
2. REALIZAREA
Realizarea procedurilor
automate

Implementarea
3. UTILIZAREA Exploatarea efectiv
Meninerea n funciune
Dezvoltarea de noi
 1.2. Metode de proiectare i realizare
a sistemelor informatice.

Evoluie structurabil n trei generaii de metode, determinata de:

1. creterea ariei de utilizare a instrumentului informatic;

2. creterea gradului de complexitate a aplicaiilor i a
cerinelor de integrare;
3. necesitatea diminurii costurilor, creterii productivitii i
reducerii riscurilor de realizare;
4. evoluia structurii i tipologiei aplicaiilor de gestiune: SIG,
SIAD, SE, SIE, birotic, multimedia;
5. influena exercitat de evoluia limbajelor de programamre,
a S.G.B.D., a reelelor de calculatoare, a tehnicilor de
gestiune n timp real etc.
Metode ierarhice
- prima generaie, anii '70
- sistemul informaional/informatic este structurat pe
baza funciilor sale;
- centrate pe analiza funcional: fiecare funcie identificat
se subdivide ierarhic n subfuncii, continund n aceast
manier pn se ajunge la componente suficient de mici
astfel nct acestea s poat fi programate cu uurin;

F1 Exemple: SADT (Structured Analysis

and Design Technique), JSD (Jackson
F11 F12
System Development), Yourdon.

F111 F112 F121 F122 F123

Avantaje:

Simplitate, bun adaptare la definirea cerinelor

utilizatorului;

Dezavantaje:

Concentreaz efortul de analiz asupra funciilor

(de prelucrare) neglijnd coerena datelor (a cror
structur este totui mult mai stabil dect a
prelucrrilor); volatilitatea cerinelor utilizatorilor
(funciilor) face ca aplicaiile s fie ntr-o aproape
continu reconsiderare.
Metode sistemice
- generaia a doua, anii '80;- se bazeaz pe aplicarea teoriei
sistemelor n analiza ntreprinderii;
- sistemul informaional/informatic este abordat sub
dou aspecte complementare: datele i prelucrrile, care
sunt studiate i modelate independent i reunite ct mai
trziu cu putin;
- acord prioritate datelor fa de prelucrri;
- respect cele trei nivele de concepie introduse prin
raportul ANSI/SPARC/X31: extern, conceptual, intern;
- exemple : MERISE, AXIAL, Information Engineering (J.
Martin).

Avantaje: sistemele se axeaz pe conceptul de baz de date, care

ofer mai mult coeren, stabilitate i elimin
redondanele;
Dezavantaje: deficiene n modelarea prelucrrilor, posibilitatea
apariiei de discordane ntre modelele datelor i ale
prelucrrilor.
Metode orientate obiect
(obiectuale)
- generaia a treia, anii '90;- sistemul informaional/informatic
este
perceput ca o structur de obiecte autonome, ce se organizeaz i
coopereaz ntre ele;

- un obiect are un anumit comportament, definit prin ansamblul

operaiilor (serviciilor) pe care le poate efectua; datele i
prelucrrile prin care este implementat acest comportament sunt
ncapsulate (maschate) i sunt inaccesibile celorlalte obiecte;

- fiecare obiect poate participa la compunerea altor obiecte mai

complexe;

- fiecare obiect poate interveni n mai multe funcii sau scenarii

funcionale diferite;
Exemple: OOD (Booch), OMT (Rumbaugh),
OOA/OOD (Coad), OOM (Rochfeld).

O5
O3
O1

O7

O2 O4 O6

Avantaje: permite reutilizarea componentelor de program,

favorizeaz modelarea i utilizarea de obiecte complexe.

Dezavantaje: percepia i reprezentarea monolitic de tipul " totul

este obiect " nu corespunde ntotdeauna realitii
reprezentate.
 2. METODE SISTEMICE DE PROIECTARE

2.1. Nivele de abstractizare i modelare

Modele

Nivele Date Prelucrari

Conceptual Model conceptual MCD Model conceptual MCP

Organizaional Model logic MLD Model organizaional MOP

Fizic Model fizic MFD Model operaional MOpP

2.2. Modelarea conceptual a datelor.
Modelul entitate-asociere.

2.2.1. Concepte de baz

Entitate:
- reprezentarea unui "obiect" concret sau abstract care:
- aparine spaiului problemei de rezolvat (face parte sau
este relevant pentru realitatea observat);
- are o existen de sine stttoare;
- poate fi identificat n raport cu celelalte obiecte de acelai tip.

Exemple: angajat, produs, utilaj, operaie

tehnologic, client, factur

O entitate este reprezentat printr-un ansamblu de atribute.

Atribut:
- caracteristic sau proprietate a unei entiti, semnificativ
pentru spaiul problemei de rezolvat.
Exemplu:

ANGAJAT Numele entitatii

Nume
Prenume Atributele entitatii
Data nasterii

Entitatea este perceput aici ca un tip de obiecte.

Fiecare obiect individual constituie o realizare a
entitii respective.
Atributele au, la rndul lor, aceeai conotaie tipologic,
n sensul c despre orice realizare a unei anumite
entiti se cunosc acelei atribute, dar pentru fiecare
dintre acestea coninutul sau valoarea atributelor
respective difer.
 Vasilescu
Maria
Realizri
ale entitatii Ionescu
Marian Valori (realizri) ale
15/3/65 atributelor
720000
Entitatea ANGAJAT

Nume
Prenume
Data nasterii Atribute
Salariul lunar
Tip de valori: un anumit ansamblu de valori, definite fie printr-o proprietate
fie printr-o enumerare.

Ex:
Stare civil = (necstorit, cstorit, vduv, divorat)
Zile lucrtoare = (luni, mari, miercuri, joi, vineri)
An studii = (a : a ntreg, 1 a 5)

Un atribut poate fi:

- simplu: atunci cnd pentru o entitate sau o asociere poate lua o
singur valoare;
- repetitiv: dac pentru o entitate sau o asociere poate lua mai multe
valori (ex: limbi strine cunoscute)

Reguli privitoare la atribute:

1. fiecare atribut poate apare ntr-o singur entitate (principiul non-
redondanei)
2. un atribut poate avea numai valori elementare.
 PERSOANA Exemplu incorect: deoarece "prenume
copii" poate avea mai multe valori pentru
Nume
o anumit persoan.
Prenume
Prenume copii

Identificatorul entitii: un atribut sau un grup de atribute care

primesc valori unice pentru fiecare
realizare a entitii respective i pot servi
astfel pentru identificarea fr echivoc a
acestora.
Pentru simplitate se recurge frecvent la
coduri care sunt atribute construite
special astfel nct s rspund cerinelor
de identificare (ex: marc salariat) sau la
atribute de tip "numr de ordine" sau
"numr de apariie" (ex: numrul de
inventar al unui mijloc fix).
n reprezentarea grafic, identificatorul entitii se subliniaz.

Identificator
ANGAJAT ANGAJAT
Marc
Nume
Nume
Prenume Prenume
Data nasterii Data na[terii
Salariul lunar
Salariul lunar
Asocierea: reprezentarea legturii sau corespondenei existente ntre dou
sau mai multe realizri de entiti.

O asociere nu are existen de sine stttoare , depinznd de

existena realizrilor de entiti pe care le leag.; n consecin,
nu are identificatori specifici.

O asociere poate avea atribute proprii.

Entitile care particip la o asociere constituie colecia acesteia.

Numrul de entiti care particip la o asociere formeaz
dimensiunea sau gradul acesteia (mai mare sau egal cu
numrul de entiti al coleciei).

Cardinalitatea minimal / maximal exprim modul de participare al

realizrilor fiecrei entiti la asociere ( valori uzuale:0,1;
1,1; 0,n; 1,n ).
Reprezentarea grafic:

Asociere
Nume asociere Cardinalitate
minimal maximal
ANGAJAT COMPARTIMENT
NCADRAT -LA
Marc 1,1 0,n
Nume Data ncadrrii Cod compartiment
Prenume Den compartiment
Data na[terii
Salariul lunar Atribut al asocierii

Colectie: ANGAJAT, COMPARTIMENT

Dimensiune: 2 (asociere binar)
ntre realizrile acelorai entiti pot exista mai multe asocieri
diferite, cu semantic i cardinaliti distincte.

ANGAJAT NCADRAT-LA COMPARTIMENT

1,1 0,n
Marc Data ncadrrii
Nume Cod compartiment
Prenume
Data na[terii 0,1 1,1 Den compartiment
CONDUCE
Salariul lunar

Asociere reflexiv: o asociere care leag realizri diferite ale aceleiai

entiti (colecie = 1). n asemenea cazuri, este
indispensabil specificarea n schem a rolurilor
jucate de entitate.

Rol al entitii: nume care servete pentru a desemna participarea

entitii la o asociere.
Exemplu:

PERSOAN
Nr matricol
Nume 0,1
0,1 Prenume
Data na[terii
Sot Sotie

CSTORIT-CU

Data cstoriei

Rol

Colectie: PERSOAN
Dimensiune : 2
Restricii de integritate:

- reguli suplimentare, nereprezentabile direct n formalismul

EA, care trebuie respectate permanent de date.

Restrictii de integritate structurale:

- inerente conceptelor folosite la modelare:

integritatea entitii: valorile luate de identificatorul entitii
trebuie s fie unice i nenule;
integritatea referenial: pentru orice realizare a unei asocieri
este obligatorie existena realizrile entitilor participante.
cardinalitile:
Cardinalitatrea:
Cardinalitatile minimale

1. Cardinalitatea minimal 0 : pot exista realizri ale entitii care

nu narticip la nici o realizare a
asocierii;
Ex:
0,n 1,1
CLIENT Emite COMENZI

Un client poate exista chiar daca nu a emis nici o coamnda

2. Cardinalitatea minimal 1: toate realizrile entitii trebuie s

participe la o realizare a asocierii.
Ex anterior: Orice comand trebuie s fie emis de un client.
Cardinalitatile maximale:

3. Cardinalitatea maximal 1: legtura este modificabil sau nu

dac nu, legtura poate fi notat prin
sgeat.

Ex: O comanda nu-i poate schimba ulterior clentul.

0,n Emite 1, 1
CLIENT COMAND

4. Cardinalitatea maximal n: valoarea lui n poate fi

precizat.
2.2.2. Restrictii de integritate
Restrictii de integritate: reguli suplimentare, nereprezentabile direct n
formalismul EA, care trebuie respectate
CARTE
permanent de date.
Cota
Titlu
autor

poseda 1,n

Exista

imprumutat
existent imprumuta
1,1
O,n Imprumuta
O,n CITITOR
EXEMPLAR Data imprumut
Marca
Nr exemplar
Nume
An_editie
Prenume
Nr_pagini
Adresa
O,n Restituie Limita_impr
Data restituirii O,n Termen_livrare

restituit restituie
Alaturi de elementele oferite de reprezentarea de mai sus,
corespunzatoare cazului unei biblioteci universitare, mai sunt de luat
n considerare urmatoarele reguli suplimentare (care constituie
restrictii de integritate):
-cele mai vechi carti aflate n posesia bibliotecii sunt din
anul 1910.
-biblioteca grupeaza cititorii n urmatoarele categorii:
studenti, cadre didactice, doctoranzi, diversi (cu vrste
cuprinse ntre 18 si 70 ani).
-drepturile de mprumut ale cititorilor sunt diferentiate
astfel:

Categorie Nr de carti
imprumutate
studenti 2
cadre didactice 6
doctoranzi 5
 -un cititor poate trece de la o categorie la alta (de exemplu, de la
student la doctorand sau cadru didactic) .

-un mprumut este individual, include unul sau mai multe

exemplare din lucrarile care pot fi mprumutate (n limita
drepturilor conferite de categoria cititorului si a numarul
de carti mprumutate anterior si nerestituite nca.) si are o durata
maxima de 20 zile.

-nu pot fi mprumutate mai multe exemplare din aceeasi lucrare de

catre acelasi cititor.

-la restituirea unei carti mprumutate, se nregistreaza data

restituirii si, daca a fost depasit termenul de 20 de zile, se
blocheaza dreptul de mprumut al cititorului respectiv pe o durata
egala cu numarul de zile de ntrziere.
Dupa momentul n care actioneaza, exista doua clase de RI:
statice si dinamice.

R.I. Statice: conditii care trebuie sa se verifice permanent:

Ex:
An editie 1910.

R.I. Dinamice: privesc evolutia n timp a datelor.

Ex:
Categorie cititor poate evolua n felul urmator:

Cadru didactic

Studenti Doctorand

Altele
2.2.2.1. Restrictii de domeniu

RI de domeniu sunt conditii impuse asupra ansamblului de valori

acceptate pentru un atribut n cadrul tipului sau domeniului sau.
Acestea pot viza:

continutul unui singur atribut al unei entitati sau asocieri;

ex: Categorie = sstudenti, cadre didactice, doctoranzi, diversi}
corelatii ntre valorile mai multor atribute ale aceleiasi entitati
sau asocieri;
ex: pentru Categorie = "studenti", Limita impr = 3, ...
corelatii ntre atributele mai multor entitati sau asocieri diferite;
ex: pentru acelasi exemplar si acelasi cititor, Data restituire > Data
mprumut;
corelatii cu valori obtinute pe baza unor operatii de sintetizare
(numarare, nsumare, medie etc) a unui ansamblu de entitati;

ex: pentru un cititor, numarul de asocieri IMPRUMUT fara asocieri

RESTITUIRE corespunzatoare <= Limita impr
 2.2.2.2. Restrictii structurale

RI structurale sunt: restrictii inerente conceptelor folosite la

modelare.

In cadrul restrictiilor structurale amintim: identificarea

entitatilor, identificarea asocierilor, cardinalitatilor

Identificarea entitatilor: valorile luate de identificatorul entitatii

trebuie sa fie unice si nenule.

Cazuri particulare:
a). Un tip de entitate poate fi identificat prin rolul (sau rolurile)
asumate de alte entitati n cadrul unei asocieri la care
participa si acesta.
 MATERIAL 1,1 1,1 STOC
Stocaj
Cod material Stocinitial
Denumire mat stoccurent
Material Stare stoc
stocat

STOC nu are identificator propriu; identificarea se face prin

intermediul rolului Mat-stocat al tipului de entitate MATERIAL .

Identificarea prin rol se poate realiza n urmatoarele conditii:

- asocierea implicata nu trebuie sa fie ciclica;

- cardinalitatea n asociere a tipului de entitate

identificat trebuie sa fie 1,1;

- cardinalitatea n asociere a tipului de entitate

identificator poate fi 0,1 sau 1,1.
Identificarea asocierilor: prin definitie, fiecare asociere este
identificata prin rolurile asumate de
entitatile participante. Prin urmare,
existenta unei asocieri este conditionata de
existenta entitatilor participante.

Cardinalitatile:

cardinalitatea minimala 0 : pot exista entitati care nu

participa la nici o asociere.

CLIENT 0,n 1,1 COMANDA

Emite
Cod client Nr _comanda
Den_client Data_com
 cardinalitatea minimala 1: toate realizarile entitatii trebuie sa
participe la o realizare a asocierii.

Ex anterior: Orice comanda trebuie sa fie emisa de un client.

cardinalitatea maximala 1: legatura este modificabila sau nu ? Daca

nu, legatura poate fi notata prin sageata.

Ex:

CLIENT 0,n 1,1 COMANDA

Emite
Cod client Nr _comanda
Den_client Data_com
 cardinalitatea maximala n: valoarea lui n poate fi
precizata.

Ex:

PRODUS 1,6 1,n COMANDA

Linie
Cod produs comanda Nr _comanda
Den_produs Data_com

O comanda poate specifica maximum 6 produse diferite

 2.2.2.3. Incluziune, excluziune, egalitate de roluri

Unele restrictii de integritate formuleaza reguli referitoare la

rolurile jucate de un tip de entitate n diverse asocieri.

Incluziunea: daca o entitate E joaca un rol r1 ntr-o asociere a1,

atunci trebuie sa joace si rolul r2 ntr-o asociere a2.

Notatia grafica:

R1 I R2

Ex: Un client poate beneficia de un credit numai daca a depus o

cerere pentru acesta: ntre rolurile beneficiaza si depune ale
aceluiasi client exista o restrictie de incluziune.
 depune depusa CERERE-
DEPUNERE
0,n 1,1 CREDIT
0,1 analizata
I
I
CLIENT APROBARE

1,1 aprobat

0,n 1,1
ACORDARE CREDIT
beneficiaza acordat
 Depunerea unei cereri nu implica si acordarea mprumutului
dar acordarea acestuia implica ntotdeauna existenta cererii
corespunzatoare.

Obs. RI de incluziune este redondanta n cazurile n care

cardinalitatea minimala a rolului indus este mai mare de zero
(analizata depusa n exemplul anterior).

Egalitatea: restrictia de incluziune ntre rolurile r1 si r2 ale

entitatii este reciproca.

Notatia grafica:

R1 = R2
Ex: Orice client care este beneficiarului unui credit trebuie sa
constituie o garantie pentru acesta si, reciproc, constituirea
unei garantii de catre un client se face atunci cnd acesta
devine beneficiarul unui credit.

beneficiar acordat
ACORDARE 0,n CREDIT
0,n

=
CLIENT

0,n
0,n
GARANTARE GARANTIE
constituie-garantie
garanteaza
 Excluziunea: rolurile r1 si r2 ale entitatii se exclud reciproc.

Notatia grafica:

R1 # R2

Ex: un apartament nu poate apartine simultan unei persoane

fizice si unei societati (persoane juridice).

apartine-pers proprietar-p
PROPRIETATE- 0,n PERSOANA
PRIVATA

0,1
APARTAMENT #

0,1
0,n
PROPRIETATE- SOCIETATE
SOCIETATE proprietar-s
apartine-soc
 2.2.2.4. Incluziune, excluziune, egalitate de asocieri

Aceste restrictii impun conditii care actioneaza asupra tuturor

rolurilor dintr-o asociere; cu alte cuvinte, este vizata asocierea si toate
entitatile participante si nu numai participare unei anumite entitati, ca n
cazul anterior.

RI de rol

RI de asociere
Incluziune

Ex: Orice produs livrat trebuie sa corespunda unui produs

comandat. n acest caz restrictia implica cele doua asocieri n
totalitate, nu numai anumite roluri.

Obs. Unei comenzi i pot corespunde mai multe livrari diferite,

fapt reflectat prin asocierea LIVR-CDA; pentru ca restrictia
de incluziune mentionata sa fie valida, cardinalitatea rolului
bazata-pe trebuie sa fie 1,1.
COMANDA decuprin comandat PRODUS
PROD-COMANDAT
Nr cda Cod produs
Data cda Cant-comandata
1,n 0,n Den produs
0,n executata Pret

LIVR-CDA I

1,1 bazata-pe
LIVRARE 1,n PROD-LIVRAT 0,n
Nr DLAE Cant-livrata
Data livr livreaza livrat
Excluziune

Ex: n aceeasi tranzactie imobiliara, nu este posibil ca vnzarea si

cumpararea sa fie facute de aceeasi persoana. Aceasta nu
mpiedica nsa ca o persoana sa fie si vnzator si cumparator,
dar n tranzactii diferite (restrictia opereaza asupra asocierii
si nu asupra rolurilor).

vanzator VINDE
vandut-prin
0,n
1,1 TRANZACTIE-
CLIENT
# IMOBILIARA
1,1
0,n
cumparator cumparat-prin
CUMPARA
Egalitatea

Ex: Fiecarui mprumut de catre un cititor al exemplarului unei

carti trebuie sa-i corespunda o restituire si reciproc, fiecarei
restituiri trebuie sa-i corespunda un mprumut.

CARTE
Cota
Titlu
Autor
poseda 1,n
EXISTA
IMPRUMUT
Data imprumut CITITOR
existent 1,1 0,n Nr legitimatie
0,n
imprumutat imprumuta Nume
EXEMPLAR
Prenume
Nr exemplar = Data nasterii
An editie Adresa
restituit restituie Categorie
0,n 0,n Limita impr
RESTITUIRE Termen penaliz
Data restituire
 2.2.3. Reprezentarea timpului

Timpul, cel mai frecvent sub forma datei calendaristice, intervine

n numeroase probleme. Modelarea EA nu poseda formalisme
specifice pentru aspectul temporal. Astfel, reprezentarea este
uniforma att pentru entitati durabile (permanente) cum sunt, spre
exemplu, clientii, produsele, angajatii etc. ct si pentru cele de tip
"eveniment" care au caracterul unei schimbari, modificari, asocieri
produse la un moment dat (comenzi, facturi, plati, ncasari etc).
n privinta reprezentarii evenimentelor nu apar probleme deoarece,
prin definitie, acestea sunt punctuale si au o data (sau un moment) de
producere. Cum n activitatea curenta de gestiune acestea sunt
reflectate n documente carora li se atribuie numere unice ce pot servi
ca identificatori, data apare ca un simplu atribut. Spre exemplu, o
comanda, o factura, o plata vor fi identificate prin numarul
documentului n care sunt consemnate si vor poseda un atribut care
sa specifice data producerii lor (data comenzii, data facturarii, data
platii).
 Asocierile repetitive sau de scurta durata ce apar ntre entitatile
stabile ridica nsa probleme specifice. Sa consideram, spre exemplu,
asocierea care apare ntre un angajat si compartimentul n care
lucreaza. O prima solutie este cea reprezentata n schema de mai jos,
care are nsa dezavantajul de a nu arata dect ultimul loc de munca al
fiecarei persoane. n cazul n care o persoana trece de la un
compartiment la altul (problema fiind similara si la trecerea de la o
functie la alta), asocierea corespunzatoare noului loc de munca o va
nlocui pe cea anterioara, deci vechiul loc de munca va fi "uitat".

ANGAJAT
COMPARTIMEN
Marc LUCREAZA T
Nume 1,1 0,n
Cod compartiment
Data ncadrrii
Prenume lucreaza-la loc-munca
Data na[terii Den compartiment
Salariul lunar
 Ce se ntmpla nsa daca este necesar sa se cunoasca toate locurile
de munca ale unui angajat ?
Introducerea unui nou tip de asociere ntre cele doua entitati
pentru a indica locurile de munca anterioare nu este o solutie valida,
deoarece realizarile acesteia risca sa nu poata fi identificate: nimic nu
mpiedica o persoana sa revina la un loc de munca la care a mai lucrat
cndva (deci aceeasi pereche de valori "Marca, Cod compartiment",
care trebuie sa identifice fiecare asociere, apare de mai multe ori).

ANGAJAT LUCREAZA COMPARTIMEN

1,1 0,n
Marc Data ncadrrii T
Nume lucreaza-la loc-munca Cod compartiment
Prenume 0,n 0,n Denumire comp
Data na[terii
Salariul lunar compartiment
A-LUCRAT
a-lucrat-la Data incepere
loc-munca-anterior
 Doua solutii sunt posibile aici: fie introducerea unui nou tip de
entitate DATA pentru reprezentarea timpului, ceea ce face ca Data
calendaristica sa completeze Marca si Codul compartimentului n
identificare asocierilor, fie transformarea asocierii n entitate, aceasta
avnd semnificatia de istoric al locurilor de munca ocupate de fiecare
persoana. n acest din urma caz, identificarea entitatilor ISTORIC-L-M
se face prin atributul propriu Data incepere si prin rolurile entitatilor
ANGAJAT si COMPARTIMENT.

ANGAJAT LUCREAZA COMPARTIMEN

1,1 0,n
Marc Data T
Nume lucreaza-la loc-munca Cod compart.
ncadrrii
Prenume
0,n 0,n Den compart
Data na[terii
Salariul lunar A-LUCRAT
a-lucrat-la loc-munca-
anterior
0,n data incepere
DATA

Data calend
 ANGAJAT LUCREAZ COMPARTIMEN
1,1 0,n
Marc AData ncadrrii T
Nume lucreaza-la loc-munca Cod compartiment
Prenume Den compartiment
Data na[terii
Salariul
lunar 0,n
0,n
ISTORIC- ISTORIC-LM ISTORIC-
ANGAJAT 1,1 1,1 COMPARTI
Data incepere
M
Data terminare

Solutiile ilustrate prin acest exemplu pot fi generalizate, n sensul ca:

- cea mai avantajoasa solutie consta n plasarea timpului sub forma

de atribute n cadrul entitatilor sau asocierilor corespunzatoare;
- daca acest lucru nu e posibil, fie se introduce o entitate abstracta
pentru reprezentarea timpului fie se transforma asocierea dintre
entitatile durabile ntr-un nou tip de entitate care sa reflecte derularea
relatiilor dintre acestea n timp (istoric).
 Alaturi de gasirea unor modalitati de reprezentare temporala de
genul celor prezentate mai sus, s-au facut propuneri de extensie a
modelului EA care sa ia n considerare n mod explicit problema
timpului. n mod concret, n spatiul unei aplicatii este necesar sa se
poata manipula cu urmatoarele referinte temporale: timpul

ntr-o abordare generala, pot fi identificate urmatoarele

referinte n timp:
- trecut;
- viitor.
O asemenea extensie introduce distinctia dintre "obiectele"
conceptuale (echivalente entitatilor) si temporale. Entitatile sunt aici
obiecte persistente care, odata aparute, nu dispar niciodata.
Obiectele temporale materializeaza rolurile active jucate de un
obiect conceptual n timp. Spre exemplu, o persoana este o entitate.
Pe durata unui anumit numar de ani din viata sa, persoana a fost
elev, dupa care a fost student iar apoi angajat. Aceste stari sunt
reflectate prin entitati temporale destincte.
 Existenta unei entitati este caracterizata numai de momentul
aparitiei sale. Spre deosebire de aceasta, durata de viata a unei
entitati temporale este ntotdeauna un interval nchis la stnga -
momentul de debut al rolului nu poate fi niciodata necunoscut - si
nchis sau deschis la dreapta - existenta acestuia s-a ncheiat si, n
consecinta, se cunoaste momentul terminarii, sau continua.
 2.2.4. Subtipuri de entitati

n numeroase cazuri, n ansamblul entitatile ce apartin unui

anumit tip exista subgrupuri cu o anumita relevanta pentru realitatea
reflectata si care, n consecinta, trebuie reprezentate explicit.
Grupurile de entitati sunt numite subclase ale TE, acesta fiind, la rndul
sau, superclasa acestora.

Spre exemplu, entitatile apartinnd TE ANGAJAT pot fi

grupate n MUNCITOR, TEHNICIAN, INGINER, ECONOMIST etc.
Fiecare entitate a unui asemenea grup este, n acelasi timp, o entitate a
tipului ANGAJAT.

Definirea de subclase se poate face n doua moduri:

-pe baza valorilor unui anumit atribut

-pe baza unor criterii definite de utilizator.
 Prin definirea de subclase se efectueaza specializarea
entitatilor superclasei acestora (TE). Acestea mostenesc toate atributele
superclasei si pot avea atribute proprii specifice, inexistente la nivelul
superclasei.

Spre exemplu, n subclasele MUNCITOR si INGINER ale TE

ANGAJAT dintr-o ntreprindere, alaturi de atributele comune,
aferente oricarui angajat (Marca, Nume, Prenume, Data nasterii, etc),
pentru muncitori pot exista, suplimentar, atributele specifice Meserie si
Nivel calificare iar pentru ingineri, atributul Specialitate.
 Delimitnd subansambluri de entitati ale aceluiasi tip de
entitate, subclasele constituie subtipuri ale acestuia. Reprezentarea
grafica uzuala este:

ANGAJAT
Marca
Nume
Prenume
Data nasterii
...

#
MUNCITOR INGINER

Meserie Specialitate
Calificare
 Aceasta notatie echivaleaza cu existenta unor asocieri
SUBTIP, n care cardinalitatea subtipurilor este 1,1, iar a tipului
(superclasei) este 0,1.

ANGAJAT
Marca
Nume
Prenume
Data nasterii
...
0,1 0,1

1,1 este-un este-un 1,1

MUNCITOR INGINER

Meserie Specialitate
Calificare
 Generalizarea este procesul invers, prin care doua sau mai multe
tipuri de entitati sunt generalizate, pe baza proprietatilor comune, ntr-un nou
tip. n aceasta relatie, TE initiale devin subtipuri ale tipului obtinut prin
generalizare. Spre exemplu, tipurile de entitati ANGAJAT si STUDENT dintr-
o universitate pot fi generalizate prin tipul PERSOANa, care va prelua
atributele comune ale acestora: Nume, Prenume, Data nasterii, Adresa etc.

Maniera n care se procedeaza - prin specializare sau generalizare -

depinde exclusiv de cerintele unei ct mai fidele reprezentari a realitatii.
Specializarea poate fi totala (orice entitate a tipului face parte, obligatoriu,
dintr-un subtip) sau partiala (pot exista entitati care sa nu apartina nici unui
subtip).

n exemplul anterior, specializarea este partiala, deoarece exista si alti

angajati n afara muncitorilor si inginerilor. Aceasta este o restrictie de
integritate specifica, reprezentata grafic prin utilizarea unei linii simple
pentru o specializare partiala si a unie linii duble pentru o specializare totala.
Cum generalizarea se obtine grupnd tipuri de entitati deja existente, nu
poate fi dect totala.
 ntre subtipuri poate exista un raport de excluziune, ceea ce traduce
faptul ca fiecare entitate poate apartine unui singur subtip (ca n exemplul
anterior). Exista nsa si cazuri n care aceeasi entitate poate apartine mai
multor subtipuri diferite (cu alte cuvinte, submultimile entitatilor apartinnd
subclaselor respective nu sunt disjuncte). Aceasta RI este reprezentata grafic
prin intermediul simbolului de excluziune. n cazul n care nu exista
exclusivitate, este foarte probabila existenta unei RI de incluziune, care sa
precizeze conditiile n care are loc "suprapunerea" entitatilor apartinnd
fiecarui subtip.

Presupunnd, spre exemplu, ca STUDENT si CADRU-DIDACTIC

sunt subtipuri ale TE PERSONAL-UNIVERSITATE, se poate formula
urmatoarea restrictie de incluziune: pot fi cadre didactice (preparatori, n
speta) numai studentii de la studii aprofundate.
Cele doua restrictii de integritate sunt total independente. Orice
combinatia ntre ele este posibila: partial-exclusiv, partial-inclusiv, total-
exclusiv, total-inclusiv.
 Introducerea de subtipuri prin specializare/generalizare
prezinta doua avantaje principale:
- factorizeaza proprietatile comune la nivelul tipului
(superclasei);
- face mult mai clara reprezentarea unor tipuri de
asocieri la care participa numai o parte dintre
entitati.
 Ex: O ntreprindere fabrica si livreaza produse finite si
subansamble. O cantitate unitara dintr-un anumit produs
sau subansamblu se fabrica din alte subansamble si/sau materii
prime, n cantitati bine precizate.

STRUCTURA-
FABRICATIE
Cantitate nec

compus-din component-in
ARTICOL
0,n Cod articol 0,n
Den articol
Tip articol
UM
 Un model EA n aceasta forma impune introducerea de restrictii
de integritate de genul:

daca Tip articol este "produs finit" atunci nu poate juca rolul
component-n; daca Tip articol este "materie prima" atunci nu poate
juca rolul compus-din s.a.m.d.
Un model mult mai clar (desi mai voluminos) se poate obtine introducnd
specializarea pe baza continutului atributului Tip articol (TE ARTICOL
factorizeaza proprietatile comune).
 ARTICOL
Cod articol
Den articol
Tip articol
UM

#
este-un este-un este-un
PRODUS-F 0,n 0,n SUBANS 0,n 0,n MATERIAL
Cant-s-p Cant-m-s

0,n 0,n 0,n 0,n

Cant-sb-sb

Cant-m-p
 Un anumit tip de entitate poate face obiectul mai multor specializari
diferite, n masura n care aceasta prezinta semnificatie pentru
reprezentarea problemei modelate.

Ex: O societate de valori imobiliare ofera clientilor sai bunuri

imobiliare (apartamente, case, vile) pentru vnzare sau
nchiriere. Pentru vnzare, se cunosc pretul si starea bunului
(liber, disponibil ulterior). Pentru nchiriere, se cunosc chiria
lunara, durata minima a nchirierii si avansul.

Un bun imobiliar face aici obiectul unei duble specializari, n functie

de tip (apartament la bloc sau casa/vila) si n functie de natura
ofertei facute de proprietarul sau (vnzare sau nchiriere).
 Prima dintre specializari aduce avantajul factorizarii
atributelor comune n TE BUN-IMOBILIAR si plaseaza atributele
specifice n subtipul corespunzator (spre exemplu, Suprafata gradina
exista numai pentru casa sau vila). n absenta acestei specializari, att
atributele specifice numai apartamentelor ct si cele specifice numai
caselor ar fi trebuit sa figureze n TE BUN-IMOBILIAR, desi ele nu pot
avea niciodata valori simultan (un bun imobiliar nu poate fi, n acelasi
timp, si apartament la bloc si casa). Un atribut suplimentar - Tip bun -
ar fi fost necesar pentru a face distinctia adecvata si un set de RI de
domeniu ar fi trebuit sa controleze valorile luate de atribute n funtie de
continutul acestui atribut.

A doua specializare face mai clara tipul de tranzactie la care

poate participa fiecare bun. Asa cum se observa n schema, numai
bunurile oferite spre vnzare pot face obiectul unei vnzari; aici
avantajul nu vine din factorizarea atributelor ci din claritatea (si
simplitatea) reprezentarii. Specializarea elimina nevoia unui atribut
care sa precizeze natura ofertei facute si a RI de rol care sa precizeze ca
numai un bun pentru care natura ofertei este "de vnzare" poate fi
vndut.
 BUN-IMOBILIAR
Nr bun 1,1 proprietate-a
Adresa
Suprafata

# #
APART-BL CASA-VILA DE-VANZARE DE-INCHIRIAT
Etaj Supr curte Pret solicitat Chirie lunara
Supr gradina Avans minimal
Nr camere Tip incalzire Stare
Durata minima
Nr etaje bloc
vandut CLIENT

SE-VINDE 0,1 Nr client

Nume client
Adresa client
ob-vanza No telefon
1,1
proprietar
VANZARE SOLICITANT OFERTANT POSEDA
1,n
Nr tranzactie
Data vanzare 0,n cumparator
vanzator
act-cumparare
CUMPARA
1,1
# VINDE
act-vanzare
1,1 0,n
 Specializarea TE CLIENT aduce avantaje de acelasi tip,
indicnd, de exemplu, ca nu poate fi ofertant dect un client care este
proprietarul unui bun imobiliar (intermediarii sunt exclusi n aceasta
schema). Absenta RI de excluziune dintre cele doua specializari
precizeaza ca aceeasi persoana poate att ofertant ct si solicitant. RI
dintre asocierile CUMPARA si VINDE precizeaza ca, pentru o anumita
vnzare, cumparatorul si vnzatorul trebuie sa fie persoane diferite.
 2.2.5. Reguli referitoare la MCD

Unicitatea numelor.

Regula de unicitate a numelor se aplica tutoror elementelor ce apar

n MCD: TE, TA, atribute, roluri, RI. Prin urmare, se vor elimina
eventualele posibile ambiguitati prin utilizarea de nume complete (ex: Nume
angajat, Nume produs si nu, simplu, Nume, n ideea ca apartenenta acestui
atribut la un tip de entitate sau altul nlatura de la sine ambiguitatea).

Eliminarea omonimelor si sinonimelor.

Atribute derivabile

Atributele derivabile sunt cele ale caror valori se obtin din valorile
altor atribute, de regula prin relatii de calcul (ex: Limita mprumut care
poate fi determinat pe baza continutului atributului Categorie cititor; Valoare
produs comandat care poate fi obtinut nmultind Cantitatea comandata cu
Pretul produsului respectiv).
 n mod normal, aceastea trebuie eliminate din MCD, fiind
redondante. Daca nsa prezinta o semnificatie particulara pentru
problema studiata (facnd, spre exemplu, obiectul unor RI distincte), este
posibila mentinerea lor n schema, nsotite de specificarea relatiilor de
calcul sau derivare sub forma de RI.

Atribute repetitive sau decompozabile

Prezenta acestora poate indica existenta unor structuri care trebuie

reprezentate ca atare. Ex: pentru un student, reprezentarea rezultatelor la
examene constituie un atribut repetitiv si decompozabil care indica
existenta unei asocieri ntre student si disciplinele pentru care trebuie sa
sustina examene.
 STUDENT
Nr matricol
Nume
Prenume
(Nume-discipl,
Data examen,
Nota)

STUDENT DISCIPLINA
EXAMEN
1,n 0,n
Nr matricol Data examen Cod discipl
Nume sustine cursant Nume discipl
Prenume

Aceasta regula nu trebuie aplicata pentru orice atribut repetitiv

sau decompozabil dect n masura n care conduce la evidentierea unor
elemente, entitati sau asocieri semnificative pentru problema
reprezentata. Spre exemplu, descompunerea atributului Adresa n
Localitate, Strada, Numar etc va fi facuta numai daca delimitarea lor
prezinta interes n raport cu perceptia existenta n realitatea modelata.
 Minimalitatea identificatorilor

Aceasta regula prevede ca, n cazul identificatorilor compusi

dinntr-un grup de atribute sau roluri, sa nu existe un subgrup n interiorul
acestora care sa poata ndeplini functia de identificator. Nerespectarea
acestei reguli poate fi usor evidentiata prin examinarea dependentelor
functionale dintre atributele sau rolurile ce compun identificatorul.

Existenta unor atribute ale caror valori devin "nule" pentru

anumite valori luate de alte atribute.
Aceasta situatie semnaleaza, n general, existenta de subtipuri.
 O asociere nu poate exista dect o singura data ntre aceleasi entitati

Ca si entitatile, asocierilor trebuie sa fie identificabile si

identificarea lor se face prin entitatile participante (mai precis, prin
identificatorii acestora). Conditiile impuse identificatorilor: valori
nenule si unice pentru fiecare element, trebuie respectate si n cazul
asocierilor.

Considernd ca ar exista cardinalitati si pentru asociere (nu

numai pentru entitati), acestea ar trebui sa fie ntotdeauna 1,1.
Daca pentru aceleasi entitati apar mai multe asocieri (de acelasi tip),
nseamna ca restrictia de unicitate este ncalcata. Solutia consta, n
acest caz, n transformarea asocierii ntr-o noua entitate.
 IMPRUMUT CITITOR
Data imprumut
0,n 0,n Nr legitimatie
Nume
EXEMPLAR imprumutat imprumuta Prenume
Nr exemplar = Data nasterii
An editie restituit restituie Adresa
Categorie
0,n RESTITUIRE
0,n Limita impr
Data restituire Termen penaliz
 Spre exemplu, fiecare mprumut si fiecare restituire din
schema de mai sus trebuie sa fie unice pentru un anumit exemplar si
un anumit cititor. Daca nsa un cititor mprumuta de mai multe ori
acelasi exemplar, restrictia de unicitate este ncalcata. Rezolvarea
consta n introducerea unui TE IMPRUMUT care sa individualizeze
mprumutul.
EXEMPLAR
Nr exemplar
An editie
imprumutat restituit
0,n 0,n
IMPR-EXEMPL RESTITUIRE
=
Data restituire CITITOR
Nr legitimatie
1,n 1,n
cuprinde restituie Nume
IMPRUMUT Data nasterii
IMPR-CITITOR
Data imprumut 1,1 0,n
Categorie
facut-de imprumuta Limita impr
 Aici, fiecare mprumut este identificat prin atributul Data mprumut
si prin rolul CITITOR:mprumuta. Un mprumut este facut de un singur
cititor si poate cuprinde unul sau mai multe exemplare. Exemplarele
mprumutate pot fi restituite toate o data sau pe rnd.
Aceeasi solutie se impune si n cazul n care participarea anumitor
entitati este optionala, ceea ce face ca o parte din identificatorul asocierii sa
devina nedeterminata (nula). Spre exemplu, produsele comandate de clienti
sunt livrate si facturate.

PRODUS
COMANDA PROD-COMANDAT
1,n 0,n Cod produs
Nr comanda Cantitate comandata Den produs
Data comanda 1,1 1,1 UM
0,1
0,n

0,n
FACTURA PROD-FACTURAT
Nr factura 1,n Cantitate facturata
Data factura Pret unitar
 Cum facturarea nu este facuta n acelasi moment cu formularea
comenzii, cardinalitatea acesteia este 0,1. Rezolvarea consta si aici n
transformarea asocierii n entitate.

COMANDA 1,n CUPRINDE 1,1 PROD-C-DAT

Nr comanda
Data comanda Cant comandata
0,1
1,1

SE-REFERA-LA
CORESPUNDE

0,n

0,n PRODUS
FACTURA PROD-FACTURAT Cod produs
1,n 0,n Den produs
Nr factura Cantitate facturata
Data factura Pret unitar UM
 2.2.5.1. Dependente functionale

A. Dependente functionale simple.

ntre doua atribute A si B exista o dependenta functionala

notata
A B
daca fiecarei valori a lui A i corespunde o singura valoare a lui
B.
Spre exemplu, pentru un angajat se poate defini urmatoarea
dependenta functionala:
Marca Nume
care exprima faptul ca unui angajat (identificat printr-un
numar de marca) i corespunde un singur nume. Relatia
inversa:
Nume Marca
nu este adevarata, deoarece pot exista mai multe persoane cu
acelasi nume dar cu numere de marca diferite.
 Pentru un angajat mai pot fi definite si alte DF:
Marca Prenume
Marca Data nasterii
Marca Functie
Atributul aflat n stnga DF este numit determinant.
Determinantul poate fi compus din unul sau mai multe atribute.

Ex: Pretul unitar de aprovizionare este determinat de felul

materialului si de numele furnizorului, deoarece acelasi
material se poate aproviziona la preturi diferite de la
furnizori diferiti.

Cod material,Cod furnizor Pret aprovizionare

O dependenta functionala X Y este elementara daca pentru

orice X strict inclus n X, dependenta functionala X Y nu este
verificata.
b. Dependente functionale multivaloare

ntre doua atribute A si B exista o dependenta functionala

multivaloare, notata:
A B
daca o valoare a lui A determina un ansamblu de valori al lui B.

Ex: Un anumit zbor al unei companii aeriene se efectueaza n

mai multe zi ale saptamnii (luni, vineri, duminica).

Nr zbor Zi saptamna
 Considernd cazul general al unui TE E n care A,B sunt
atribute/grupuri de atribute apartinnd acestuia iar C = E
-(A B),

A B daca:

- A determina mai multe valori pentru B;

- A determina mai multe valori pentru C;
- B si C sunt independente unul fata de celalalt.
n alti termeni, daca A B atunci A C.

Dependenta functionala este un caz particular al dependentei

functionale multivalore.

Daca A B atunci A B

n contextul modelului EA, DFM corespunde existentei

atributelor repetitive sau multivaloare.
Proprietatile dependentelor functionale:

Reflexivitatea:
X X.
Ex: Cod client Cod client

Dezvoltarea:
Daca X Y atunci X,Z Y.
Ex: Cod client Den client
Cod client, Localitate Den client

Tranzitivitatea:
Daca X Y si Y Z atunci X Z.
Ex: Cod client Localitate, Localitate Judet
Cod client Judet
Aditivitatea:
Daca X Y si X Z atunci X Y,Z.
Ex: Cod client Den client, Cod client Adresa client
Cod client Den client, Adresa client

Proiectia:
Daca X Y,Z atunci X Y si X Z.
Ex: Cod client Den client, Adresa client
Cod client Den client,
Cod client Adresa client

Pseudo-tranzitivitatea:
Daca X Y si W,Y Z atunci X,W Z.
Ex: Marca persoana Loc munca, Loc munca, Functie
Indemnizatie conducere
Marca persoana, Functie Indemnizatie conducere

Dependentele functionale reprezinta RI.
Identificatorul unei entitati este un atribut sau un
grup de atribute fata de care toate celelate atribute
depind functional.
Dependentele functionale pot exista si ntre
entitati si asocieri.
Cardinalitatile 1,1 corespund ntotdeauna unor DF.
2.2.5.2. Normalizarea

Normalizarea este un proces care asigura:

- eliminarea redondantelor fara pierdere de informatie
semnificativa
- eliminarea anomaliilor manifestate n procesul actualizarii.
Anomaliile se pot manifesta n procesul actualizarii n cursul
operatiilor de adaugare, stergere si modificare.

Ex: Fie entitatea CaMINE definita sa retina modul de repartizare

a studentilor n cadrul caminelor:

STUDENT CAMIN TAXA CAMIN

Popescu Ioan Moxa 1 50000
Ionescu Adrian Moxa 2 70000
Popa George Moxa 2 70000
Ilie Dan Agronomie 60000
 anomalie la inserare: introducerea datelor privitoare la un
nou camin, pentru care s-a fixat taxa de cazare, nu se poate
face pna cnd nu este repartizat primul student n acest
camin.
anomalie la stergere: la stergerea informatiei privind
studentul Ionescu Dan se pierde informatia privind taxa de
cazare la caminul Moxa 1.
anomalie la modificare: majorarea taxei pentru studentii din
caminul Moxa 2 va impune modificarea tuturor tuplurilor
implicate, n caz contrar aparnd inconsistente.

Aceasta nseamna ca entitatea CaMINE nu a fost bine

definita siea va trebui supusa procesului de normalizare.

FN1: O entitate este n FN1 daca toate atributele sale

sunt elementare si nerepetitive.
FN2: O entitate este n FN2 daca respecta cerintele FN1
si toate atributele non-identificator sunt
dependente de ntregul identificator.
Ex:
Nr_marca Nr_lucrare Nr_ore Nume-angajat Den-lucrare Obiectiv-constr

FN 2

Nr_marca Nr_lucrare Nr_ore Nr_marca Nume-angajat

Nr_lucrare Den-lucrare Obiectiv-constr

LUCRARE
ANGAJAT EXECUTA
Nr_marca 0,n 0,n Nr_lucrare
Nume-angajat Nr_ore Den-lucrare
Obiectiv-constr
FNBC (BOYCE_CODD ): O entitate este n FNBC daca:
- respecta cerintele FN3;
- nici un atribut ce compune identificatorul nu depinde
functional de un alt atribut.

FN4: O entitate este n FN4 daca:

- respecta cerintele FNBC;
- nu prezinta dependente multivaloare.
Normalizarea entitatilor

Normalizarea are drept scop eliminarea redondantelor si a

anomaliilor de actualizare. Deoarece prin cele mentionate
anterior se elimina o parte dintre cazurile de nerespectare a
conditiilor de normalizare (existenta unui identificator,
eliminarea atributelor repetitive sau compuse), este necesar sa se
asigure o atentie deosebita urmatoarelor doua situatii:

a) existenta de DF tranzitive ntre atribute;

b) existenta de DF partiale ntre atributelor neidentificatoare si
identificator (atunci cnd acesta este compus din mai multe
atribute).
Ex: DF tranzitive existente ntre atributele entitatii UTILAJE
conduc la descompunerea acesteia n doua tipuri de entitati
si la introducerea asocierii corespunzatoare dintre ele.

UTILAJE
Nr inventar
Tip utilaj
Val intrare
Durata funct
Putere nominala

Nr inventar Tip utilaj, Val intrare, Durata funct, Putere nominala

Tip utilaj Durata funct, Putere nominala

UTILAJ CATEG-UTILAJ
APARTINE
Nr inventar 1,1 1,n Tip utilaj
Durata funct
Val intrare Putere nominala
Normalizarea asocierilor

Situatia este similara entitatilor, cu observatia ca pentru

asocieri nu exista identificatori proprii, rolul acestora fiind
ndeplinit de identificatorii entitatilor participante.

Ex:

n schema urmatoare, fiecare asociere REPARA}IE este

identificata prin Nr op interventie si Nr inventar (identificatorii
entitatilor participante). Atributul Durata normata depinde nsa
functional de o parte a cheii (Nr op interventie), ncalcnd astfel
conditiile de normalizare. Solutia corecta consta n plasarea sa n
entitatea INTERVENTIE.
INTERVENTIE UTILAJ
REPARATIE
Nr op interventie 0,n 0,n Nr inventar
Den op interventie Durata normata
Tarif orar Durata efectiva Val intrare

Nr op interventie Durata normata

INTERVENTIE UTILAJ
REPARATIE
Nr op interventie 0,n 0,n Nr inventar
Den op interventie
Durata efectiva Val intrare
Durata normata
Tarif orar
 2.3. Modelarea conceptuala al prelucrarilor.

Modelul conceptual al prelucrarilor prezinta succesiunea in

timp a operatiilor de cautare la care este supus modelul conceptual al
datelor, adica:

- ce trebuie facut la nivel conceptual fara a indica

- cine, cand si unde se realizeaza aceste prelucrari (conceptul
organizational);
- cum se vor realiza ele in mod concret (conceptul fizic);
- are drept scop sa descrie continutul (ce operatii ?, ce
rezultate ?) si dinamica (derularea in timp) unei prelucrari
intr-o maniera independenta de utilizare a mijloacelor
utilizate.
 Modelul conceptual al prelucrarilor este modelul
"eveniment-rezultat" al metodei Merise, ce repune in discutie
procedurile (elementele) abordate de MCD formuland pentru fiecare
element intrebari de forma:

- acest element este indispensabil si ce se intampla daca il

suprimam;
- exista posibilitatea de a-l suprima (atentie la normele
juridice si reglemantarile legale;
- cat costa mentinerea acestui elemet in procedura sau ce
avantaje se obtin din mentinerea lui.

Modelul conceptual al prelucrarilor, vede intreaga

prelucarare ca o succesiune ordonata si logica de proceduri
inlantiute, toate in concordanta stricta cu legislatia in vigoare (este
vorba de un demers tipic de analiza a valorilor).
 Nu se poate trece cu vederea impactul utilizarii
instrumentului informatic (SGBD) asupra MCP. Astfel,
anumite validari pot fi efectuate inca de la culegerea datelor,
in loc sa se constate ulterior ca datele sunt complete sau
eronate, deci anumite operatii din MCP pot fi eliminate.
 2.3.1. Concepte de baza
Cerere de
Ca si n cazul modelului conceptual al credit
datelor, formalismul modelelor de prelucrare se
bazeaza pe construirea unei diagrame avnd trei
elemente de baza:
Operatia
a) evenimentul declansator, reprezentat Reguli de emisiune
grafic printr-o elipsa, de la care pleaca o sageata
de legatura pentru simplificare, daca este necesar,
elipsa poate fi omisa
Credit
b) operatia, reprezentata grafic printr-un acordat
dreptunghi ;
c) rezultatul (evenimentul emis),
reprezentat tot printr-o elipsa
A si B
d) sincronizarea, reprezentata grafic
printr-un triunghi orientat catre operatie.
 Evenimentul declansator

Desemneaza un fapt a carui aparitie declanseaza o reactie n

cadrul organizatiei; aparitia unui eveniment va antrena derularea de
activitati, de operatii, reprezentnd motorul unei actiuni, al unei
operatii ( de ex. sosirea unui document).
Pentru ca MCP sa fie ct mai stabil, el trebuie sa fie
independent de aspectele organizatorice si tehnologice, chiar geografice.
De ex. Sosirea unei comenzi de la un client este un eveniment
declansator, de natura extern. A satisface aceasta cerere nseamna a o
transforma ntr-o livrare de produse. Descrierea continutului
prelucrarilor necesare trebuie sa fie independenta de:

aspectele tehnologice (se utilizeaza calculatorul sau nu ?)

aspectele geografice (comanda este prelucrata la depozit
sau n alta parte ?)
aspecte organizatorice (livrarea este facuta de X la serviciul
comercial sau de Y la magazie ?)
aspecte temporale (livrarea se face dimineata sau seara ?).
Tip eveniment

Este un concept generic descriind toate aparitiile

evenimentelor de aceeasi natura. Capacitatea
sistemului de a percepe aceste aparitii este
exprimata de doi parametri :
capacitatea : indica numarul maxim de aparitii ale acestui
tip de eveniment care pot fi percepute de sistem si
frecventa : indica legea de manifestare a acestor aparitii.

Categorii de evenimente

Un eveniment poate fi :

extern (receptionat din exterior) : primirea unui CEC, a

unui aviz de plata, solicitarea unui credit, etc.

intern (generat de activitatea sistemului ntreprindere) :

pana unei masini, gasirea unei solutii, etc.
Pentru a avea un eveniment trebuie sa coexiste anumite conditii:

- sa se ntmple ceva (n afara sau n interiorul

ntreprinderii)
- acest ceva trebuie sa fie perceput de sistem (care trebuie
sa fie dotat cu mijloace capabile sa l perceapa)
- ntreprinderea sa fie interesata, vaznd n el un posibil
eveniment declansator al activitatii sale.

Operatia

Se numeste operatie orice actiune (sau secventa continua

de actiuni), producatoare de evenimente rezultat, care se executa
fara ntrerupere, ca reactie la un eveniment declansator (sau a mai
multor evenimente declansatoare sincrone). O operatie constituie
un bloc nentrerupt (nu trebuie sa apara rezultate intermediare n
interiorul unei operatii).
 Tip de operatie

O categorie de operatii ce prezinta aceleasi caracteristici.

Un anumit numar de parametri caracteristici permit specificarea
unui anumit tip de operatie:

- desemnarea operatiei nsasi;

- durata exprimata n unitati de timp
- actiunile elementare constitutive
- evenimentele emise si conditiile de emitere.

O operatie se finalizeaza ntotdeauna prin emiterea de

evenimente functie de situatiile identificate pe parcurs si de
conditiile exprimate de aceste situatii (asa-numitele reguli de
emisiune).
 cod Denumire
operatie operatie
Actiune ( Actiuni)
Reguli de emisiune

Rvenimente emise - rezultate

Remarca. O operatie se desfasoara n timp, avnd o

anumita durata. La un moment dat ea
poate fi :

- n asteptarea executiei;
- n curs de executie si
- terminata.
Rezultatul (evenimentul emis) .

Numim rezultat produsul executarii unei operatii.

ntotdeauna trebuie respectata urmatoarea regula: o
operatie produce unul sau mai multe rezultate.
Descompunerea unei operatii n mai multe operatii distincte
implica aparitia unor rezultate intermediare. Un eveniment
emis poate fi n acelasi timp un eveniment declansator
pentru o alta operatie ( sau alte operatii). De aceea se si
utilizeaza acelasi formalism.
Reguli de obtinere a rezultatului

n MCP toate operatiile trebuie sa aiba rezultat. n

anumite cazuri obtinerea unuia sau mai multor rezultate poate fi
supusa ndeplinirii anumitor conditii. n aceasta situatie este
necesar sa fie definite, formulate asa numitele reguli de emisiune
sau reguli de actiune. (vezi fig. de mai sus).
Exemple :
- Relatia date-rezultate este supusa anumitor conditii logice :
daca valoarea facturata este mai mare de 1 milion, atunci se
acorda o remiza de 1o%, daca nu, se acorda un scont de 2%.
- Lansarea unei livrari poate fi diferita daca stocul este
insuficient. n acest caz comanda este plasata n asteptare (nu se
ntocmeste dispozitie de livrare). Conditia stoc suficient
defineste o regula de emisiune a rezultatului cu doua cazuri
diferite (stoc suficint; stoc insuficient).
Reprezentarea regulilor de emisiune

Conform figurii de mai jos, diferitele reguli de emisiune

sunt reprezentate n partea inferioara a dreptunghiului ce
descrie operatia.
Reprezentarea este analoga unei formulari de genul :
Daca regula de emisiune 1
atunci Rezultat A si Rezultat B
altfel (regula de emisiune 2)
Rezultat B si Rezultat C

Operatie
Regula de Regula de
emisiune 1 emisiune 2

A B C
Sincronizarea

n anumite cazuri, declansarea unei operatii poate solicita

producerea simultana a mai multor evenimente. Cu alte cuvinte, o
anumita operatie nu poate avea loc dect daca sunt ndeplinite anumite
conditii privind manifestarea evenimentelor ce concura la declansarea
operatiei respective. Expresia acestor conditii se numeste sincronizare.

Principiul sincronizarii

Sincronizarea exprima sub forma unei propozitii logice faptul

ca operatia poate fi declansata sau nu. Ea se exprima printr-o expresie
booleana ce leaga evenimentele ce declanseaza operatia.
Modul de functionare

Daca E1, E2 si E3 sunt evenimente declansatoare pentru

operatia Oi si daca a, b, c sunt aparitii corespunzatoare
evenimentelor E1, E2 sI respectiv E3, atunci sincronizarea :

a si ( b sau c) , adica a ( b c)

indica faptul ca operatia Oi este declansata daca o aparitie a

evenimentului E1 exista simultan cu una din aparitiile
evenimentelor E2 sau E3.
 Sincronizarea se exprima deci sub forma unei propozitii logice
care trebuie sa respecte anumite reguli, dintre care cele mai importante
sunt:

- conditia trebuie pusa pe evenimentele participative

conjugate si
- trebuie sa existe situatii care permit declansarea.

Conceptul de sincronizare exprima o logica si o dinamica a

prelucrarilor. La un moment dat, propozitia logica poate fi verificata.
Atunci sincronizarea este activa si operatia este declansata. La un alt
moment este posibil ca un singur eveniment declansator sa fie realizat;
n acest caz sincronizarea este n asteptarea realizarii altor evenimente
care sa declanseze operatia. Daca nici un eveniment nu are loc,
sincronizarea este inactiva.
 Evenimentul A Evenimentul B Sfarsit operatie

Timp
t1 t2 t3

Sincronizare Sincronizare
in asteptare activa (operatie Sincronizare
Sincronizare
declansata) inactiva
inactiva

Sincronizarea reprezinta concordanta intre doua sau mai multe

evenimente. Ea face ca evenimentele sa aiba loc simultan, n acelasi timp,
concomitent, sincron.
Nu trebuie uitat faptul ca evenimentele sincronizate, prin
sincronizare, declanseaza o singura operatie. Totodata, pentru ca un
eveniment sa participe la o sincronizare, el trebuie sa fie utilizat n
aceasta declansare.
Exemplu Cerere
de credit

Vom considera ca exemplificare OP 1 Instruire formala

procedura de acordare a unui
credit. c1 c2 c3

Utiliznd formalismul de mai Scrisoare Dosar Informatii

sus vom defini modelul din de refuz deschiz suplimentare
figura 1.

Schema din figura din dreapta

Analiza
constituie un model conceptual OP 2 solvabilitatii
al prelucrarilor tipic; el descrie
ceea ce se face, fara a preciza c4 c5
nici cine face si nici cu ce
instrument. Credit Credit
refuzat acordat
Comentarii la figura 1

O data cu primirea cererii de credit (eveniment) , are loc o

operatie de instruire formala a deschiderii unui dosar de creditare
care se finalizeaza dupa caz (functie de regulile de emisiune care au
valorile c1 si respectiv c2 si c3) printr-un refuz (cerere
nerezolvabila), prin deschiderea efectiva a unui dosar de creditare si
n sfrsit, printr-o cerere de informare suplimentara.
c1 : nu exista plafon de credite
c2 : exista plafon de credite pe termen scurt c3 : exista plafon
de credite pe termen lung

Acest dosar face sistematic obiectul unei operatii de

instruire, care, functie de solvabilitatea clientului (c4 - client
nesolvabil sau C5 - client solvabil) se finalizeaza printr-o respingere
sau acceptare a dosarului.
Notiunea de Proces

Un proces descrie dinamica prelucrarilor

dintr-o activitate determinata. El este format din
operatii executate ca reactie la evenimente si producnd
rezultate.

Un proces este:

- omogen : operatiile si rezultatele concura la o

finalitate comuna.
- limitat : are granite marcate de evenimentele
de origine si de rezultatele
terminale.
 Etapele elaborarii unui proces.

Procesul este MCP ce corespunde unui domeniu de

activitate. El este construit printr-un demers metodologic de
modelare (analiza, abstractizare, conceptie), ce
cuprinde urmatoarele etape:
1. Delimitarea obiectului de activitate
n cadrul acestei etape trebuie precizate granitele
domeniului de care sunt legate activitatile care intereseaza.
2. Identificarea principalelor evenimente.
Aici trebuie revazute principalele evenimente externe si
interne ale procesului; acestea sunt elemente cheie n
realizarea modelului.
3. Construirea tabelului evenimente-rezultate.
Acest tablou permite definirea continutului procesului ,
preciznd pe coloane, evenimentele, actiunile induse si
rezultatele.
4. Identificarea si descrierea operatiilor.
Tabloul evenimente-rezultate, n coloana centrala,
permite deja identificare actiunilor induse de
evenimentele declansatoare. O analiza mai complecta a
contextului permite relevarea regulilor de gestiune,
care sunt adesea elemente ale operatiilor.
5. Reperarea sincronizarilor.
Aparent, mai multe evenimente distincte pot sa
declanseze aceeasi operatie. O data stabilite aceste
elemente se poate construi schema de baza
pentru fiecare operatie. Aceasta schema se numeste
bloc operatie.
6. Precizarea conditiilor de obtinere a rezultatelor.
Se cauta, printre regulile de gestiune, acelea care
definesc conditii de obtinere a rezultatelor. Se
completeaza apoi schema de baza cu elementele
respective.
7. Ordonarea blocurilor-operatie.
Structura generala a procesului decurge din cronologia
evenimentelor. Deci evenimentele trebuie ordonate
cronologic. Acest fapt permite ordonarea diferitelor
blocuri-operatie si legarea lor conform principiului : un
rezultat ( al operatiei n-1) declanseaza operatia urmatoare
(operatia n).
8. Verificarea si validarea modelului.
Se verifica daca:
- orice operatie duce la cel putin un rezultat;
- orice operatie este declansata de cel putin un eveniment;
- toate blocurile sunt legate.
Validarea modelului se face de catre persoanele implicate n
proces. Numai ele pot judeca pertinenta modelului propus.
 Exemplu.

Etapa 1.
Domeniul care ne intereseaza este gestiunea clientilor privind
comenzile pentru produse de panificatie (figura 2). Deci nu vor fi luate n
considerare nici actualizarea stocurilor, nici activitatile contabile, ntruct
nu apartin strict de gestiunea clientilor.

Etapa 2.
Pot fi identificate n principal:
trei evenimente externe :
1. Sosirea unei comenzi de la un client.
2. Existenta unui mijloc de transport disponibil n care sa se
ncarce
marfa.
3. Sfrsitul zilei;
trei evenimente interne:
1. Acceptarea comenzii.
2. Decizia de livrare.
3. Sfrsitul activitatii de livrare.
Etapa 3. Tabloul evenimente -rezultate.

Evenimente Actiuni induse Rezultate

1. Sosirea Controleaza identitatea Comanda acceptata
comenzii de la si pretul sau nu
client
2. Existenta unui Efectueaza livrarea Livrare efectuata
mijloc de transport
disponibil
3. Sfrsitul zilei Examineaza comenzile Comanda de
n asteptare fabricatie
1.Acceptarea Consultarea stocurilor Comanda livrabila
comenzii de produse sau nu
2.Decizie de Pregatirea livrarii Marfa gata de
livrare plecare
3. Sfrsitul Expedierea marfii si Livrare expediata
activitatii de pregatirea facturii Factura
livrare
4. Comanda n Examinarea Comanda de
asteptare comenzilor n asteptare fabricatie
Etapa 4.

Se regasesc 6 operatii si anume:

OP 1 - Controleaza identitate client si pret;

OP 2 -Examineaza stoc
OP 3 - Pregateste livrarea
OP 4 - Factureaza
OP 5 - Expediaza marfa
OP 6 - Examineaza comenzile n asteptare

Obs. Au fost retinute doar aspectele conceptuale, eliminndu-

se operatiile de tip organizational sau tehnic.
 Sosirea comenzii
de la client

OP1 Controleaza
identitate si
pret
Nu Da

Comanda Comanda
refuzata acceptata

Op 2 Examineaza stoc

Sufucuent Insufucuent

Comanda Comanda in Sfarsitul zilei

livrabila asteptare
a b
Pregatirea A si B
OP 3 livrarii

Examineaza
Livrare OP 6
Mijloc comenzi
pregatita de transport in asteprtare
c d
C si d
OP 4 Facturare Comanda de
fabricatie
OP 5 Expediaza marfa
Factur Catre alt
a proces
Livrare
efectuata
Etapa 5

Vom exemplifica lucrul din aceasta etapa doar pentru un

singur bloc operatie, si anume cel corespunzator operatiei 2
(efectueaza livrarea).

Livrare pregatita Mijloc de transport

a
b

A si b

Efectueaza
OP 5 livrarea

Livrare
efectuata
Etapa 6.
Putem avea de ex. urmatoarele reguli de gestiune:
a) daca comanda este acceptata. Aceasta
regula defineste controlul de identitate si pret si
conditioneaza rezultatul (comanda acceptata ,
respectiv refuzata);
b) daca stocul este suficient, regula
asemanatoare referitoare la marimea stocurilor.

Etapa 7.
Schema procesului este prezentata n figura 2.

Etapa 8.
Se constata n figura de mai sus ca sunt ndeplinite
regulile de modelare n sensul ca orice operatie este
declansata de cel putin un eveniment sI fiecare operatie
are cel putin un rezultat (eveniment emis)
Descrierea detaliata a procesului

Schema procesului prezentata n figura 3 permite o

perceptie rapida a ansamblului prelucrarilor. Daca se doreste
nsa o prezentare mai detaliata atunci este recomandat ca
aceasta detaliere sa se faca la nivel de bloc operatie, fara sa mai
urmeze o nlantuire a blocurilor detaliate, ntruct o schema
detaliata a procesului ar fi greu de urmarit, de perceput. n acest
caz se utilizeaza pentru eveniment urmatorul formalism.

Descrierea detaliata a
Nume eveniment blocului corespunzator
operatiei examinarea
Nr max de comenzilor n asteptare
Termen
aparitii este prezentata n
limita
continuare :
Comanda
in asteptare

20 1 zi Sfarsitul
Aceasta maniera de abordare aduce
zilei
complemente asupra restrictiilor de
a b timp si volum.
a si b

Examinarea Schema poate fi completata cu

OP 6
comenzilor in descrierea continutului operatiei,
asteptare dar de aceasta data sub forma de
fisa a operatiei, al carei continut
este prezentat n continuare:
Cerere de
fabricatie

30 1 zi
Descrierea operatiei Denumire: Examinarea comenzilor n asteptare
Numar : 6
Proces : Gestiunea clientilor
________________________________________________________________

Mod de sincronizare

- la sfrsitul zilei (ora 17)

- pentru toate comenzile n asteptare
________________________________________________________________

Descrierea regulilor de gestiune

R1. Pentru fiecare produs:

- daca totalul cerut este mai mic dect cantitatea din stoc
solicitati livrarea;
- daca nu, cereti fabricarea.
R2. Comenzile de fabricatie sunt emise cel mai trziu a doua zi
dupa examinarea comenzilor.
________________________________________________________

Descrierea regulilor de emisiune

R1. Starea cererilor de fabricatie

Astfel de scheme trebuie elaborate pentru fiecare
operatie. Se aplica aici principiul cunoscut al ierarhizarii,
mergnd de la general (schema procesului) catre particular
(descrierea operatiei).
________________________________________________________
 Revenind la reprezentarea grafica de mai sus putem afirma
ca parametri exprimnd dinamica procesului puneau restrictii doar
la nivelul nodurilor si anume:

- la nivelul sincronizarii (propozitia logica, durata limita) si

- la nivelul operatiilor pentru emisiunea de rezultate (reguli
de emisiune care orienteaza fluxurile catre o cale sau alta).

Acesti parametri pot fi completati cu altii plasati pe sagetile

de legatura, n amonte si n aval de operatie. Astfel vom avea ca
parametri suplimentari:

- participarea si durata limita (pe sageata eveniment -->

sincronizare) si
- cardinalitatea (pe arcul operatie --> rezultat)
Participare si durata limita (reglarea n amonte)

Uneori sincronizarea, pentru a fi activata, are nevoie de

existenta unui lot de aparitii ale evenimentului declansator.
Acest numar constituie participarea tipului de eveniment la tipul
de sincronizare. Timpul de activabilitate a acestui lot se numeste
durata limita.

Cardinalitatea evenimentelor (reglarea n aval)

Operatiile emit rezultate (evenimente emise). Uneori

este posibil ca acestea sa fie emise n mai multe exemplare
identice. Numarul de exemplare exprima cardinalitatea tipului
de eveniment rezultat al operatiei.
 2.4. Validarea modelelor

2.4.1. Modelele externe ale datelor

Fiecare prelucrare are propriul/propriile sale modele externe

(subscheme) de date MCD construit prin prisma unei singure
prelucrari. MED se construieste independent de MCD.

prel1 MED1
Realitate modelare MCD

prel2 MED2
 O prelucrare are ME distincte pentru fiecare consultare si
pentru fiecare actualizare. Att pentru consultare ct si pentru
actualizare, ME se construiesc pe baza blocurilor logice de date
corespunzatoare.

Loturi logice de date: fluxurile de date vehiculate de o anumita

prelucare.

Evenimentele care activeaza o sincronizare si care nu constituie o

cerere de consultare constituie un BLD.

Combinatia de evenimente produse printr-o regula de emitere a

rezultatelor constituie un BLD.
 e1 e2 BLD E1 E2

e3 e4 BLD E3 E4

Reguli pentru construirea ME

1) Un ME pentru fiecare consultare sau actulaizare

efectuata de o prelucrare.
2) Fiecare ME se construieste pe baza BLD folosind
formalismul EA.
3) Entitatile din ME pot sa nu aiba identificatori.
4) Atributele, entitatile si asocierile externe pot sa nu
fie atribute, entitati sau asocieri conceptuale.
5) Atributele externe echivalente atributelor
conceptuale trebuie sa aiba acelasi nume.
Ex: modele externe pentru OP1
consultare : verificare identitate client

NUME
DenClient
1,n

CORESP

1,1
CLIENT
CodClient
AdresaClient
Cod fiscal
Stare
actualizare: acceptare comanda de la client

COMANDA
Nr comanda
Data c-da
Den client
Adresa-livr
Val-totala
1,n

CUPRINDE

1,1
LINIE-COMANDA
Cod produs
Den produs
UM
Cantitate c-data
Pret vnz
Valoare
2.4.2. Principiul validarii modelelor

Fiecare model extern trebuie sa fie deductibil din MCD

Model extern

calcul echivalenta

Model conceptual
 CLIENT PRODUS
Ex: MCD
Cod produs
CodClient
Den produs
DenClient UM
AdresaClient Pret vnz
CodFiscal
Stare
0,n
0,n

TRANSMITE PRODUS-C-DAT
Cantitate c-data

COMANDA
1,1 1,n
Nr comanda
Data c-da

-corespondenta directa: Cod produs, Den produs, Cantitate c-data ...

-calcul: Valoare = Cantitate c-data * Pret vnz
Val-totala = Valoare
-echivalenta: Adresa-livr AdresaClient
2.4.3. Reguli de validare n consultare

Atributele externe trebuie sa fie atribute conceptuale.

Daca nu:
- omisiuni se completeaza MCD;
- date calculate se nlocuieste n ME cu atributele
conceptuale necesare calcularii sale; daca acestea nu
apar n totalitate n MCD, se adauga;
- date ce nu trebuie memorate se elimina din ME,
urmnd sa fie tastate direct
 Trebuie sa existe posibilitatea de-a avea acces la date n
structura necesara

Accesul poate fi facut:

- pe baza identificatorului;
- prin parcurgerea entitatilor sau asocierilor, una
cte una se verifica existenta criteriilor de
selectie necesare si se compeleteaza MCD daca
este nevoie.

Daca se fac consultari pentru care criteriul de acces nu

este identificatorul, se adauga n MCD o noua entitate al carei
identificator este acest criteriu de acces si asocierea necesara
pentru consultare (cai de acces impuse de utilizare si nu de DF).

Cardinalitatile asocierilor externe trebuie sa fie incluse n

cardinalitatile asocierilor conceptuale ce le corespund semantic .
2.4.4. Reguli de validare n actualizare

Orice atribut extern trebuie sa serveasca fie la identificarea

elementului conceptual de actualizat fie la obtinerea valorii de
adaugat sau de modificat a unui atribut conceptual:
-se suprima atributele externe care nu servesc nici unuia
din scopurile amintite;
-se adauga cele absente.

Cardinalitatile asocierilor externe trebuie sa fie incluse n

cardinalitatile asocierilor conceptuale ce le corespund semantic.

Orice atribut conceptual trebuie sa poata fi inserat

(modificat sau sters) prin cel putin un model extern. Daca nu, se
adauga modelele externe adecvate.
Ex: entitati si asocieri inserate prin ME acceptare comanda de la client

CLIENT PRODUS
Cod produs
CodClient
Den produs
DenClient UM
AdresaClient Pret vnz
CodFiscal
Stare
0,n
0,n

TRANSMITE
PRODUS-C-DAT
Cantitate c-data

COMANDA
1,1 1,n
Nr comanda
Data c-da

Trebuie adaugate MCP si ME corespunzatoare pentru actualizarea

produselor si clientilor.
 2.5. Modelarea logica a datelor

2.5.1. Cadru general

Trecerea de la MCD, care este un model universal, spre o solutie
informatica se face gradat, lund n considerare un anumit tip de
solutie si apoi, n cadrul tipului respectiv, o solutie direct
implementabila.

Expresia MCD n termenii unui anumit tip de solutie

informatica constituie modelul logic al datelor (MLD).
Deoarece aplicatiile informatice de gestiune se caracterizeaza
prin stocarea si prelucrarea relativ simpla a unor volume mari sau
foarte mari de date, tipurile de solutii luate n considerare vizeaza
modalitatile de gestionare a datelor pe suporturile de memorie
externa.
COMANDA PROD-C-DAT
CUPRINDE
Nr comanda 1,n 1,1
Data comanda Cant comandata
0,1
1,1

SE-REFERA-LA
CORESPUNDE

0,n

0,n PRODUS
FACTURA PROD-FACTURAT Cod produs
1,n 0,n
Den produs
Nr factura Cantitate facturata
UM
Data factura Pret unitar
 2.5.2. Modelul relational

Domeniu: o multime de elemente de tip similar.

Exemple:

NUME ZILE ORARE

Ionescu luni Bucuresti

Mateescu marti Timisoara
Vasilescu miercuri Arad
Popescu joi Paris
Bunescu vineri Barcelona
Costescu smbata Madrid
Dumitrescu duminica Roma
Atribut:
- o submultime a unui domeniu careia i s-a atribuit un
nume. Numele exprima rolul sau semnificatia atribuite elementelor
domeniului respectiv.
Ex:
- pentru domeniul Orase, pot fi definite atributele aeroport
origine, aeroport destinatie, aeroport escala etc.

Aeroport origine Aeroport destinatie Escala

Bucuresti Arad
Bucuresti Barcelona
Paris Bucuresti Timisoara
Relatie: o multime

R = {(a1,a2,..,an):(a1 A1, a2 A2, ...an An) P(a1,a2,...an) = adevarat}

unde A1,A2...An sunt domenii.

Ex 1: A1: domeniul compozitorilor; A2: domeniul simfoniilor;

P(a1,a2) = "a1 est autorul simfoniei a2".
P(Beethoven,Eroica)=adevarat;
P(Vivaldi,Simfonia fantastica)=fals.
Ex 2:
personal(MARCA,NUME,PRENUME,DATA-NASTERII)
daca (m,n,p,d) personal
atunci o persoana cu marca (m), numele (n), prenumele (p) este
nascuta la data (d).

Relatiile se reprezinta grafic sub forma de tabele, n care se disting:

gradul relatiei: numarul de atribute utilizate

cardinalitatea relatiei: numarul de tupluri (linii n tabel).
 Grad
Atribute

MARCA NUME PRENUME DATA NAST

125 Popescu Vasile 22/10/68
128 Popescu Adriana 17/5/65
336 Costea Ion 8/12/63
417 Ionescu Maria 30/4/64

Cardinalitate Tuplu
 Cardinalitatea unei relatii este variabila n timp datorita
operatiilor de actualizare care pot adauga sau sterge tupluri.

Pentru o relatie pot exista 3 tipuri de chei:

cheie primara: cel mai mic ansamblu de
atribute (eventual unul singur) care permite
identificarea fara univoc al fiecarui tuplu al
unei relatii; atributele care compun cheia
primara nu pot avea valori nule.
cheie candidat: o alta posibila cheie primara,
care nu a fost nsa retinuta ca atare.
cheie externa: un ansamblu de atribute (eventual
unul singur) care este cheie primara ntr-o alta
relatie.

Restrictie de integritate referentiala:

daca ntre un atribut A si o cheie primara B exista o RIR
atunci A nu poate lua dect valori care exista si n B. Prin
definitie, cheile externe sunt supuse RIR n raport cu cheile
primare corespunzatoare.
2.5.3. Trecerea de la MCD la MLD relational

a. ENTITATI
Fiecare entitate devine o relatie.
Atributele entitatii devin atribute ale relatiei.
Identificatorul entitatii devine cheia primara a relatiei.

E1
Ae11
Ae12
...

E1( Ae11 ,Ae12, ...)

b. ASOCIERI
b.1 Cazul general

1) Asocierea devine o relatie.

2) Atributele proprii ale asocierii (daca exista) devin atribute ale
relatiei.
3) Cheile primare ale entitatilor participante la asociere devin
chei externe.
4) Identificatorul asocierii devine cheia primara a relatiei.

_,n _,n
Ae11 ASOC Ae21
Ae12 A1 Ae22
... ...

ASOC( Ae11 ,Ae21 ,A1)

E1( Ae11 ,Ae12, ...)

E2( Ae21 ,Ae22, ...)

Ex 1:

STUDENT EXAMEN DISCIPLINA

1,n 0,n
Nr matricol Data examen Cod discipl
Nume sustine Nota cursant Nume discipl
Prenume

STUDENT(Nr matricol, Nume, Prenume)

DISCIPLINA(Cod disciplina, Nume disciplina)

EXAMEN(Nr matricol*, Cod disciplina*, Data examen, Nota)

Ex : 2
STRUCTURA-
FABRICATIE
Cantitate nec

compus-din component-in
ARTICOL
0,n Cod articol 0,n
Den articol
Tip articol
UM

ARTICOL(Cod articol, Den articol, Tip articol, UM)

STRUCT-FABRICATIE(Cod articol compus*, Cod articol

component*, Cantitate necesara)
b.2. Asocieri binare avnd cel putin o cardinalitate maximala 1.

Se adauga la atributele relatiei corespunzatoare entitatii cu

cardinalitatea maximala 1 identificatorul celeilalte entitati
(cheia primara a relatiei corespunzatoare acesteia), care
devine cheie externa.
Daca asocierea are atribute proprii, acestea se adauga la
rndul lor relatiei care reprezinta entitatea cu cardinalitate
maximala 1.

E1 _,1 E2
_,n
ASOC
Ae11 Ae21
Ae12 A1 Ae22
... ...

E1( Ae11 , Ae12,...,Ae21,A1)

E2( Ae21 ,Ae22,...)

Ex 1

ANGAJAT COMPARTIMENT
Marc LUCREAZA
Nume 1,1 0,n Cod compartiment
Prenume lucreaza-la Data ncadrrii loc-munca Den compartiment
Data nasterii
Salariul lunar

COMPARTIMENT(Cod compartiment, Den compartiment)

ANGAJAT(Marca,Nume, Prenume, Data nasterii, Salariul lunar,

Cod compartiment*, Data ncadrarii)
Ex 2
0,n FILIATIE
1,1

tata copil

PERSOAN

Cod persoan
Nume
Prenume
Data nasterii
Sex

PERSOANA(Cod persoana, Nume, Prenume, Data nasterii,

Sex, Cod persoana tata*)
c. SUBTIPURI DE ENTITATI (Generalizarea/specializarea)

c.1. Reprezentarea simpla a legaturilor dintre tip si subtip

Se aplica regulile de la b.2. conform urmatoarei schemei generale:

Entitate Entitate

0,1
0,1

Subtip Subtip
1,1 1,1
Subtip Subtip
c.2. Reprezentarea mostenirii

Reprezentarea mostenirii ca proces de transfer al

proprietatilor generice ale tipului spre subtipuri nu
beneficiaza de o solutie relationala dedicata. Din aceasta
cauza, este necesar sa se recurga la defactorizarea
proprietatilor comune.

a) se favorizeaza specializarea: tipul de entitate

generica dispare iar atributele sunt adagate la
fiecare dintre subtipuri.
 BUN-IMOBILIAR
proprietate
Nr bun
1,1 Adresa
Suprafata
POSEDA
#
DE-VANZARE DE-INCHIRIAT
1,n Chirie lunara
proprietar Pret solicitat
Avans minimal
Stare
CLIENT Durata minima

Nr client
Nume client
Adresa client
No telefon

BUN-DE-VANZARE( Nr bun , Adresa, Suprafata, Pret solicitat, Stare, Nr Client)

BUN-DE-INCHIRIAT( Nr bun , Adresa, Suprafata,

Chirie lunara, Avans minimal, Durata minima, Nr Client)
b) se favorizeaza generalizarea:

tipul de entitate generica preia si atributele specializate care,

n functie de subtipul reprezentat, primesc valori nule.

BUN-IMOBILIAR(Nr bun, Adresa, Suprafata, Pret solicitat,

Stare, Chirie lunara, Avans minimal, Durata minima, Nr client*)
att tipul ct si subtipurile sunt conservate ca atare.

BUN-IMOBILIAR(Nr bun, Adresa, Suprafata, Nr client*)

BUN-DE-VNZARE(Nr bun vnzare, Pret solicitat, Stare)

BUN-DE-NCHIRIAT(Nr bun inchiriat, Chirie lunara, Avans

minimal, Durata minima)

Nr bun vnzare si Nr bun inchiriat trebuie sa respecte

restrictiile de integritate referentiala n raport cu Nr bun.
In constructie .