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 165Modelarea 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

SISTEM OPERAAND
(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:

PRODUS

CLIENT

LIVRARE

PRODUS

LICHIDITATI

BANCI

INTREPRINDER
E

VIRAMENT

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

PROCEDURI
AUTOMATE

Situatii

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

INTRARI
(Tranzacii
externe)

Act. B.D.
-stocare
-control
-aducere
zi

BD

Consultare
-cautare
-calcule

IESIRI externe

Situatii

PRELUCRARI
INTRARI
EXTERNE

IESIRI
EXTERNE
Act. BD

Consultare
BD

FACTURI

COMENZI
SUB-SISTEMUL FACTURARE

IESIRI
EXTERNE
EXTRAS DE CONT

BALANA CLIENI
ALTE INFORMAII

INTRARI
EXTERNE
Consultare

BD

Act.

SUB-SISTEMUL
CONTABILITATEA CLIEN}ILOR

NREGISTRAREA
CLIENILOR

PRELUCRARI
INTRARI
EXTERNE

SUB-SISTEMUL
FACTURARE
Act.

IESIRI
EXTERNE

Consultare

BD

Extras de cont
Consultare
Balana clieni
IESIRI
EXTERNE

Act.

SUB-SISTEMUL
CONTABILITATEA
CLIENTILOR

INTRARI
EXTERNE

Ciclul de via al unui sistem informatic -cuprinde perioadele:

Schema director
1.

CONCEPEREA

Studiul detaliat
Studiul prealabil (Evaluare)

2.

REALIZAREA

Studiul tehnic
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;

Exemple: SADT (Structured Analysis

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

F1

F11

F111

F12

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

O1

O3

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

Realizri
ale entitatii
Entitatea

Vasilescu
Maria
Ionescu
Marian
15/3/65
720000
ANGAJAT
Nume
Prenume
Data nasterii
Salariul lunar

Valori (realizri) ale

atributelor

Atribute

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 nonredondanei)
2. un atribut poate avea numai valori elementare.

PERSOANA
Nume
Prenume

Exemplu incorect: deoarece "prenume

copii" poate avea mai multe valori pentru
o anumit persoan.

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.

ANGAJAT
Nume
Prenume
Data nasterii
Salariul lunar

Identificator

ANGAJAT
Marc
Nume
Prenume
Data na[terii
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
ANGAJAT
Marc
Nume
Prenume
Data na[terii
Salariul lunar

1,1

Cardinalitate
minimal maximal

NCADRAT -LA

Data ncadrrii

0,n

COMPARTIMENT
Cod compartiment
Den compartiment

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
Marc
Nume
Prenume
Data na[terii
Salariul lunar

1,1

NCADRAT-LA

0,n

Data ncadrrii

0,1

CONDUCE

COMPARTIMENT
Cod compartiment

1,1

Den compartiment

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
0,1

Nr matricol
Nume
Prenume
Data na[terii

Sot

Sotie

CSTORIT-CU
Data cstoriei

Rol
Colectie: PERSOAN
Dimensiune : 2

0,1

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:
CLIENT

0,n

Emite

1,1

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.

CLIENT

0,n

Emite

1, 1

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
permanent de date.
CARTE
Cota
Titlu
autor
poseda

1,n
Exista

existent

1,1
EXEMPLAR
Nr exemplar
An_editie
Nr_pagini

imprumutat
O,n

imprumuta
Imprumuta
Data imprumut

O,n
restituit

Restituie
Data restituirii

O,n

O,n
restituie

CITITOR
Marca
Nume
Prenume
Adresa
Limita_impr
Termen_livrare

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
studenti

Nr de carti
imprumutate
2

cadre didactice

doctoranzi

-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
Cod material
Denumire mat

1,1

Material
stocat

Stocaj

1,1

STOC
Stocinitial
stoccurent

Stare stoc

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
Cod client
Den_client

0,n

Emite

1,1

COMANDA
Nr _comanda
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
Cod client
Den_client

0,n

Emite

1,1

COMANDA
Nr _comanda
Data_com

 cardinalitatea maximala n: valoarea lui n poate fi

precizata.
Ex:
PRODUS
Cod produs
Den_produs

1,6

Linie
comanda

1,n

COMANDA
Nr _comanda
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

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
0,n

CLIENT

depusa CEREREDEPUNERE
1,1 CREDIT
0,1 analizata
I
APROBARE
1,1

0,n
beneficiaza

aprobat

1,1
CREDIT
ACORDARE
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

ACORDARE

0,n

acordat
0,n

CREDIT

CLIENT
0,n
constituie-garantie

GARANTARE

0,n

garanteaza

GARANTIE

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

0,1
APARTAMENT

PROPRIETATEPRIVATA

proprietar-p
0,n

PERSOANA

0,1
apartine-soc

PROPRIETATESOCIETATE

0,n
SOCIETATE
proprietar-s

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
PROD-COMANDAT
Nr cda
Data cda
Cant-comandata
1,n
0,n executata
LIVR-CDA

bazata-pe
1,1
LIVRARE
1,n
Nr DLAE
livreaza
Data livr

comandat
0,n

PROD-LIVRAT

Cant-livrata

0,n
livrat

PRODUS
Cod produs
Den produs
Pret

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
0,n

CLIENT
cumparator

vandut-prin
1,1

#
0,n
CUMPARA

1,1

TRANZACTIEIMOBILIARA
cumparat-prin

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
existent

1,1

0,n

EXEMPLAR
Nr exemplar
An editie
0,n

CITITOR
0,n

Nr legitimatie
Nume
imprumutat
imprumuta
Prenume
=
Data nasterii
Adresa
Categorie
restituie
restituit
0,n Limita impr
Termen penaliz
RESTITUIRE
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
Marc
1,1
Nume
Prenume
lucreaza-la
Data na[terii
Salariul lunar

LUCREAZA
Data ncadrrii

0,n
loc-munca

COMPARTIMEN
T
Cod compartiment
Den compartiment

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
Marc
Nume
Prenume
Data na[terii
Salariul lunar

1,1
lucreaza-la

LUCREAZA
Data ncadrrii

0,n
a-lucrat-la

A-LUCRAT
Data incepere

COMPARTIMEN
0,n
T
loc-munca Cod compartiment
0,n Denumire comp
compartiment
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

1,1

LUCREAZA

Data
Marc
lucreaza-la
Nume
ncadrrii
Prenume
0,n
Data na[terii
Salariul lunar
A-LUCRAT
a-lucrat-la

COMPARTIMEN
T
loc-munca Cod compart.
0,n Den compart
0,n

loc-muncaanterior
data incepere

0,n
DATA

Data calend

ANGAJAT
Marc
Nume
Prenume
Data na[terii
Salariul
lunar
0,n
ISTORICANGAJAT

1,1
lucreaza-la

LUCREAZ
AData ncadrrii

COMPARTIMEN
0,n
T
loc-munca Cod compartiment
Den compartiment

0,n
ISTORIC-LM
1,1

Data incepere
Data terminare

1,1

ISTORICCOMPARTI
M

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
Meserie
Calificare

INGINER
Specialitate

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
1,1
este-un
MUNCITOR
Meserie
Calificare

0,1
este-un
1,1
INGINER
Specialitate

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 dintro 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, totalexclusiv, 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.

sau

Ex: O ntreprindere fabrica si livreaza produse finite si

subansamble. O cantitate unitara dintr-un anumit produs
subansamblu se fabrica din alte subansamble si/sau materii
prime, n cantitati bine precizate.

STRUCTURAFABRICATIE
Cantitate nec

compus-din

component-in
ARTICOL
0,n

Cod articol
Den articol
Tip articol
UM

0,n

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
PRODUS-F 0,n

0,n

este-un
SUBANS
0,n

Cant-s-p
0,n

Cant-m-s

0,n

0,n
Cant-sb-sb

Cant-m-p

0,n

este-un
MATERIAL

0,n

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
1,1

Nr bun
Adresa
Suprafata

proprietate-a

APART-BL

CASA-VILA

Etaj

Supr curte
Supr gradina
Tip incalzire

Nr camere
Nr etaje bloc

DE-VANZARE
Pret solicitat

Chirie lunara
Avans minimal
Durata minima

Stare
vandut

CLIENT
Nr client
Nume client
Adresa client
No telefon

0,1

SE-VINDE
ob-vanza

DE-INCHIRIAT

1,1

proprietar

VANZARE

SOLICITANT

OFERTANT

Nr tranzactie
Data vanzare

0,n

cumparator

vanzator

act-cumparare
CUMPARA
1,1
act-vanzare

#
1,1

1,n

VINDE
0,n

POSEDA

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
Nr matricol
Nume
Prenume

1,n
sustine

EXAMEN
Data examen

0,n

DISCIPLINA

Cod discipl
cursant Nume discipl

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
Data imprumut

EXEMPLAR
Nr exemplar
An editie

CITITOR
0,n

Nr legitimatie
Nume
imprumuta
Prenume
=
Data nasterii
Adresa
restituit
restituie
Categorie
RESTITUIRE
0,n
0,n Limita impr
Termen penaliz
Data restituire
0,n
imprumutat

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

0,n

0,n

IMPR-EXEMPL

restituit
RESTITUIRE

1,n

Data restituire

CITITOR
Nr legitimatie

1,n

cuprinde
restituie
IMPRUMUT
Data imprumut 1,1

Nume
IMPR-CITITOR

facut-de

0,n

imprumuta

Data nasterii
Categorie
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.

COMANDA
PROD-COMANDAT
1,n
Nr comanda
Cantitate comandata
Data comanda
1,1
1,1

0,n

PRODUS
Cod produs
Den produs
UM

0,1

0,n
FACTURA
Nr factura
Data factura

0,n
PROD-FACTURAT

1,n

Cantitate facturata
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
Nr comanda
Data comanda

1,n

CUPRINDE

PROD-C-DAT

1,1

Cant comandata
0,1
CORESPUNDE

1,1
SE-REFERA-LA

0,n
0,n
FACTURA
Nr factura
Data factura

PRODUS
1,n

PROD-FACTURAT
Cantitate facturata
Pret unitar

Cod produs
0,n Den produs
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

Popescu Ioan

Moxa 1

50000

Ionescu Adrian

Moxa 2

70000

Popa George

Moxa 2

70000

Ilie Dan

Agronomie

TAXA CAMIN

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_lucrare Nr_ore

Den-lucrare

ANGAJAT

0,n
Nr_marca
Nume-angajat

Nr_marca

Nume-angajat

Obiectiv-constr

EXECUTA
Nr_ore

LUCRARE
0,n

Nr_lucrare
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
Nr inventar
Val intrare

1,1

APARTINE

CATEG-UTILAJ
1,n

Tip utilaj
Durata funct
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
Nr op interventie 0,n
Den op interventie
Tarif orar

Nr op interventie

REPARATIE
Durata normata
Durata efectiva

UTILAJ
0,n

Nr inventar
Val intrare

Durata normata

INTERVENTIE
Nr op interventie 0,n
Den op interventie
Durata normata
Tarif orar

REPARATIE
Durata efectiva

UTILAJ
0,n

Nr inventar
Val intrare

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

Ca si n cazul modelului conceptual al
datelor, formalismul modelelor de prelucrare se
bazeaza pe construirea unei diagrame avnd trei
elemente de baza:
a) evenimentul declansator, reprezentat
grafic printr-o elipsa, de la care pleaca o sageata
de legatura pentru simplificare, daca este necesar,
elipsa poate fi omisa
b) operatia, reprezentata grafic printr-un
dreptunghi ;
c) rezultatul (evenimentul emis),
reprezentat tot printr-o elipsa
d) sincronizarea, reprezentata grafic
printr-un triunghi orientat catre operatie.

Cerere de
credit

Operatia
Reguli de emisiune

Credit
acordat

A si B

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

Denumire
cod
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
emisiune 1

Regula de
emisiune 2

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

t1
Sincronizare
inactiva

Sincronizare
in asteptare

Sfarsit operatie

t2

t3
Sincronizare
activa (operatie
declansata)

Timp

Sincronizare
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

procedura de acordare a unui
credit.
Utiliznd formalismul de mai
sus vom defini modelul din
figura 1.
Schema din figura din dreapta
constituie un model conceptual
al prelucrarilor tipic; el descrie
ceea ce se face, fara a preciza
nici cine face si nici cu ce
instrument.

OP 1

Instruire formala

c1

c2

Scrisoare
de refuz

c3

Dosar
deschiz

OP 2

Informatii
suplimentare

Analiza
solvabilitatii

c4

c5

Credit
refuzat

Credit
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
1. Sosirea
comenzii de la
client
2. Existenta unui
mijloc de transport
disponibil
3. Sfrsitul zilei
1.Acceptarea
comenzii
2.Decizie de
livrare
3. Sfrsitul
activitatii de
livrare
4. Comanda n
asteptare

Actiuni induse
Rezultate
Controleaza identitatea Comanda acceptata
si pretul
sau nu
Efectueaza livrarea

Livrare efectuata

Examineaza comenzile
n asteptare
Consultarea stocurilor
de produse
Pregatirea livrarii

Comanda de
fabricatie
Comanda livrabila
sau nu
Marfa gata de
plecare
Livrare expediata
Factura

Expedierea marfii si
pregatirea facturii

Examinarea
Comanda de
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, eliminnduse operatiile de tip organizational sau tehnic.

Sosirea comenzii
de la client
OP1 Controleaza
identitate si
pret
Nu

Da

Comanda
acceptata

Comanda
refuzata

Op 2

Examineaza stoc

Sufucuent
Comanda
livrabila

Insufucuent

Comanda in
asteptare

Sfarsitul zilei
a

Pregatirea
OP 3 livrarii

A si B

Livrare
pregatita

Mijloc
de transport
c

OP 4 Facturare

OP 6

Examineaza
comenzi
in asteprtare

C si d

Comanda de
fabricatie

OP 5 Expediaza marfa
Factur
a

Catre alt
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

OP 5

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

Nume eveniment
Nr max de
aparitii

Termen
limita

Descrierea detaliata a
blocului corespunzator
operatiei examinarea
comenzilor n asteptare
este prezentata n
continuare :

Comanda
in asteptare
20

1 zi

Sfarsitul
zilei

b
a si b

OP 6

Examinarea
comenzilor in
asteptare

Cerere de
fabricatie
30

1 zi

Aceasta maniera de abordare aduce

complemente asupra restrictiilor de
timp si volum.
Schema poate fi completata cu
descrierea continutului operatiei,
dar de aceasta data sub forma de
fisa a operatiei, al carei continut
este prezentat n continuare:

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.

Realitate

prel1

MED1

prel2

MED2

modelare MCD

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

e3

e2

e4

BLD

E1

E2

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

Ex: MCD

PRODUS

CLIENT

Cod produs
Den produs
UM
Pret vnz

CodClient
DenClient
AdresaClient
CodFiscal
Stare

0,n

0,n
TRANSMITE

PRODUS-C-DAT
Cantitate c-data
1,1

COMANDA
Nr comanda
Data c-da

1,n

-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

PRODUS

CLIENT

Cod produs
Den produs
UM
Pret vnz

CodClient
DenClient
AdresaClient
CodFiscal
Stare

0,n

0,n
TRANSMITE

PRODUS-C-DAT
Cantitate c-data
COMANDA
1,1

Nr comanda
Data c-da

1,n

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
Nr comanda
Data comanda

CUPRINDE

1,n

PROD-C-DAT

1,1

Cant comandata
0,1
CORESPUNDE

1,1
SE-REFERA-LA

0,n
0,n
FACTURA
Nr factura
Data factura

PRODUS
1,n

PROD-FACTURAT
Cantitate facturata
Pret unitar

0,n

Cod produs
Den produs
UM

2.5.2. Modelul relational

Domeniu: o multime de elemente de tip similar.
Exemple:

NUME

ZILE

ORARE

Ionescu
Mateescu
Vasilescu
Popescu
Bunescu
Costescu
Dumitrescu

luni
marti
miercuri
joi
vineri
smbata
duminica

Bucuresti
Timisoara
Arad
Paris
Barcelona
Madrid
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
Bucuresti
Paris

Arad
Barcelona
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
125 Popescu Vasile
128 Popescu Adriana
336 Costea
417 Ionescu

Cardinalitate

Ion
Maria

DATA NAST
22/10/68
17/5/65
8/12/63
30/4/64
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.

Ae11
Ae12
...

_,n

ASOC
A1

_,n

ASOC( Ae11 ,Ae21 ,A1)

E1( Ae11 ,Ae12, ...)

E2( Ae21 ,Ae22, ...)

Ae21
Ae22
...

Ex 1:
STUDENT
Nr matricol
Nume
Prenume

EXAMEN
DISCIPLINA
0,n
Data examen
Cod discipl
sustine
Nota
cursant Nume discipl
1,n

STUDENT(Nr matricol, Nume, Prenume)

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

Ex : 2
STRUCTURAFABRICATIE
Cantitate nec
compus-din

component-in
ARTICOL
0,n

Cod articol
Den articol
Tip articol
UM

0,n

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

_,1

ASOC

_,n

A1

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

E2( Ae21 ,Ae22,...)

E2
Ae21
Ae22
...

Ex 1

ANGAJAT
LUCREAZA
Marc
1,1
Nume
Prenume
lucreaza-la Data ncadrrii
Data nasterii
Salariul lunar

COMPARTIMENT
0,n
Cod compartiment
loc-munca Den compartiment

COMPARTIMENT(Cod compartiment, Den compartiment)

ANGAJAT(Marca,Nume, Prenume, Data nasterii, Salariul lunar,
Cod compartiment*, Data ncadrarii)

Ex 2

0,n

FILIATIE

tata

1,1

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

Subtip

0,1

0,1

Subtip
1,1
Subtip

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

proprietate
1,1

BUN-IMOBILIAR
Nr bun
Adresa
Suprafata

POSEDA

proprietar

1,n

CLIENT

#
DE-VANZARE

DE-INCHIRIAT

Pret solicitat
Stare

Chirie lunara
Avans minimal
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 .