PROIECTAREA SISTEMELOR

INFORMATICE
DE GESTIUNE

Prof.univ dr. Rosca I. Ioan
Academia de Studii Economice - Bucuresti
Facultatea de Contabilitate i Informatica de Gestiune
Prof.univ dr. Zaharie Dorin
2006-2007
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)
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)
Slide 105-135. Concepte de baza
Slide 136-146. Validarea modelelor
Slide 147-164. Modelarea Logica a Datelor (MLD)
Slide 154-164. Trecerea de la MCD la MLD
Slide 165- Modelarea Logica a Prelucrarilor (MLP)

CUPRINS
I . PROIECTAREA SISTEMICA
1. CONCEPTE DE BAZA ALE PROI ECTARI I
SI STEMELOR I NFORMATI CE

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)
I E
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)

CLIENT
LIVRARE
BANCI
INTREPRINDERE
PRODUS
LICHIDITATI
VIRAMENT PRODUS
Exemplu:
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
Doc.
primare
PROCEDURI
AUTOMATE
Baze de
date
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
Act. B.D.
-stocare
-control
-aducere zi
Tranzacii interne
Consultare
-cautare
-calcule
BD
INTRARI
(Tranzacii
externe)
IESIRI externe
Situatii
Act. BD

SUB-SISTEMUL FACTURARE
Consultare

BD
INTRARI
EXTERNE
IESIRI
EXTERNE
COMENZI
FACTURI
Act.

SUB-SISTEMUL
CONTABILITATEA CLIEN}ILOR
Consultare

BD
IESIRI
EXTERNE
INTRARI
EXTERNE
EXTRAS DE CONT
BALANA CLIENI
ALTE INFORMAII
NREGISTRAREA
CLIENILOR
PRELUCRARI
INTRARI
EXTERNE
Balana clieni
Act.

SUB-SISTEMUL
CONTABILITATEA
CLIENTILOR
Consultare

BD
INTRARI
EXTERNE
Consultare

Act.

SUB-SISTEMUL
FACTURARE
IESIRI
EXTERNE
Extras de cont
PRELUCRARI
IESIRI
EXTERNE
- Dezvoltarea de noi
versiuni
CONCEPEREA
- Studiul prealabil (Evaluare)
1.
REALIZAREA
- Studiul tehnic
2.
- Realizarea procedurilor
automate
UTILIZAREA
- Implementarea
3.
- Exploatarea efectiv
- Meninerea n funciune
- Schema director
- Studiul detaliat
Ciclul de via al unui sistem informatic -cuprinde perioadele:
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
F11 F12
F111 F112 F121 F122 F123
Exemple: SADT (Structured Analysis
and Design Technique), JSD (Jackson
System Development), Yourdon.


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.


- 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;
Metode orientate obiect (obiectuale)


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.


O1
O2
O3
O4
O5
O6
O7
Exemple: OOD (Booch), OMT (Rumbaugh),
OOA/OOD (Coad), OOM (Rochfeld).

2. METODE SI STEMI CE DE PROI ECTARE
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
Nume
Prenume
Data nasterii
Numele entitatii
Atributele entitatii
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.

Prenume
Data nasterii
Salariul lunar
ANGAJAT
Nume
Ionescu
Marian
15/3/65
720000
Vasilescu
Maria
Entitatea
Realizri
ale entitatii
Atribute
Valori (realizri) ale
atributelor
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 s a s 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
Nume
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).

Exemplu incorect: deoarece "prenume
copii" poate avea mai multe valori pentru
o anumit persoan.


n reprezentarea grafic, identificatorul entitii se subliniaz.

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

ANGAJAT
Nume
Prenume
Data na[terii
Salariul lunar
Marc
COMPARTIMENT
Cod compartiment
Den compartiment
NCADRAT-LA
Data ncadrrii
1,1 0,n
Asociere
Nume asociere
Atribut al asocierii
Cardinalitate
minimal maximal
Colectie: ANGAJAT, COMPARTIMENT
Dimensiune: 2 (asociere binar)
ntre realizrile acelorai entiti pot exista mai multe asocieri
diferite, cu semantic i cardinaliti distincte.

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.

ANGAJAT
Nume
Prenume
Data na[terii
Salariul lunar
Marc
COMPARTIMENT
Cod compartiment
Den compartiment
NCADRAT-LA
Data ncadrrii
CONDUCE
1,1 0,n
0,1 1,1
0,1
0,1
Sot Sotie
CSTORIT-CU
Data cstoriei
Rol
PERSOAN
Nume
Prenume
Nr matricol
Data na[terii
Colectie: PERSOAN
Dimensiune : 2
Exemplu:
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:


1. Cardinalitatea minimal 0 : pot exista realizri ale entitii care
nu narticip la nici o realizare a
asocierii;
Ex:
CLIENT COMENZI Emite
0,n 1,1
Un client poate exista chiar daca nu a emis nici o coamnda
Cardinalitatrea:
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 minimale
3. Cardinalitatea maximal 1: legtura este modificabil sau nu
dac nu, legtura poate fi notat prin
sgeat.

Ex:
CLIENT COMAND
Emite
1, 0,n 1
4. Cardinalitatea maximal n: valoarea lui n poate fi precizat.

Cardinalitatile maximale:
O comanda nu-i poate schimba ulterior clentul.
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
EXEMPLAR
Nr exemplar
An_editie
Nr_pagini
CITITOR
Marca
Nume
Prenume
Adresa
Limita_impr
Termen_livrare
Exista
Imprumuta
Data imprumut
Restituie
Data restituirii
O,n
O,n
O,n
O,n
poseda
existent
1,n
1,1
imprumuta
restituie restituit
imprumutat
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
Altele
Doctorand Studenti
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:

C continutul unui singur atribut al unei entitati sau asocieri;
ex: Categorie = sstudenti, cadre didactice, doctoranzi, diversi}
C corelatii ntre valorile mai multor atribute ale aceleiasi entitati
sau asocieri;
ex: pentru Categorie = "studenti", Limita impr = 3, ...
C corelatii ntre atributele mai multor entitati sau asocieri diferite;
ex: pentru acelasi exemplar si acelasi cititor, Data restituire > Data
mprumut;
C 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.

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.

MATERIAL
Cod material
Denumire mat
Stocaj
STOC
Stocinitial
stoccurent
Material
stocat
Stare stoc
1,1 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:

C cardinalitatea minimala 0 : pot exista entitati care nu
participa la nici o asociere.

CLIENT
Cod client
Den_client
Emite
COMANDA
Nr _comanda
Data_com
0,n 1,1
C 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.

C cardinalitatea maximala 1: legatura este modificabila sau nu ? Daca
nu, legatura poate fi notata prin sageata.

Ex:

CLIENT
Cod client
Den_client
Emite
COMANDA
Nr _comanda
Data_com
0,n 1,1
C cardinalitatea maximala n: valoarea lui n poate fi
precizata.

Ex:

PRODUS
Cod produs
Den_produs
Linie
comanda
COMANDA
Nr _comanda
Data_com
1,6 1,n
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:
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.

R1 R2
I
CLIENT
0,n
0,n
I
depune
DEPUNERE
beneficiaza
ACORDARE
CREDIT
1,1
acordat
1,1
CERERE-
CREDIT
depusa
APROBARE
0,1
1,1
I
analizata
aprobat
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.

CREDIT
CLIENT
GARANTARE
0,n
0,n
beneficiar
constituie-garantie
ACORDARE
=
GARANTIE
acordat
garanteaza
0,n
0,n
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).

APARTAMENT
0,1
0,n
0,n
proprietar-p
proprietar-s
PROPRIETATE- PERSOANA
SOCIETATE PROPRIETATE-
0,1
#
PRIVATA
SOCIETATE
apartine-pers
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 LI VR-CDA; pentru ca restrictia
de incluziune mentionata sa fie valida, cardinalitatea rolului
bazata-pe trebuie sa fie 1,1.

PROD-COMANDAT
Cant-comandata
PROD-LIVRAT
Cant-livrata
COMANDA
Nr cda
Data cda
PRODUS
Cod produs
Den produs
Pret
LIVRARE
Nr DLAE
Data livr
LIVR-CDA
I
1,n 0,n
0,n
1,1
1,n 0,n
decuprin
comandat
livrat
livreaza
executata
bazata-pe
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).

CLIENT
TRANZACTIE-
VINDE
CUMPARA
#
0,n
0,n
1,1
1,1
IMOBILIARA
vandut-prin
cumparat-prin
vanzator
cumparator
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.

EXEMPLAR
Nr exemplar
An editie
CARTE
Titlu
Autor
Cota
EXISTA
IMPRUMUT
Data imprumut
RESTITUIRE
Data restituire
1,n
1,1
0,n
0,n
0,n
0,n
imprumutat
restituit
imprumuta
restituie
existent
poseda
CITITOR
Nr legitimatie
Nume
Prenume
Adresa
Categorie
Data nasterii
Termen penaliz
Limita impr
=
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
Nume
Prenume
Data na[terii
Salariul lunar
Marc
COMPARTIMEN
T
Cod compartiment
Den compartiment
LUCREAZA
Data ncadrrii
1,1 0,n
lucreaza-la loc-munca
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
Nume
Prenume
Data na[terii
Salariul lunar
Marc
COMPARTIMEN
T
Cod compartiment
Denumire comp
compartiment
LUCREAZA
Data ncadrrii
1,1 0,n
lucreaza-la loc-munca
A-LUCRAT
Data incepere
0,n 0,n
a-lucrat-la 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 ISTORI C-L-M
se face prin atributul propriu Data incepere si prin rolurile entitatilor
ANGAJ AT si COMPARTI MENT.

ANGAJAT
Nume
Prenume
Data na[terii
Salariul lunar
Marc
COMPARTIMEN
T
Cod compart.
Den compart
LUCREAZA
Data
ncadrrii
1,1 0,n
lucreaza-la loc-munca
A-LUCRAT
data incepere
0,n 0,n
a-lucrat-la loc-munca-
anterior
DATA
0,n
Data calend
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).

ANGAJAT
Nume
Prenume
Data na[terii
Salariul
lunar
Marc
COMPARTIMEN
T
Cod compartiment
Den compartiment
LUCREAZ
A
Data ncadrrii
1,1 0,n
lucreaza-la loc-munca
ISTORIC-LM
Data incepere
Data terminare
0,n
1,1
0,n
1,1
ISTORIC-
ISTORIC-
ANGAJAT
COMPARTI
M
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.


ANGAJAT
Marca
Nume
Prenume
Data nasterii
...
MUNCITOR
Meserie
Calificare
INGINER
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
1,1
0,1 0,1
1,1 este-un este-un
Aceasta notatie echivaleaza cu existenta unor asocieri
SUBTI P, n care cardinalitatea subtipurilor este 1,1, iar a tipului
(superclasei) este 0,1.


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.

ARTICOL
Cod articol
Den articol
Tip articol
UM
STRUCTURA-
FABRICATIE
Cantitate nec
0,n 0,n
compus-din component-in
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 ARTI COL
factorizeaza proprietatile comune).

ARTICOL
Cod articol
Den articol
Tip articol
UM
PRODUS-F SUBANS MATERIAL 0,n 0,n
0,n 0,n 0,n 0,n
0,n 0,n
#
este-un este-un este-un
Cant-s-p
Cant-sb-sb
Cant-m-p
Cant-m-s
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.

SOLICITANT
POSEDA
proprietar
BUN-IMOBILIAR
Nr bun
Adresa
Suprafata
Nr camere
Etaj
APART-BL
Nr etaje bloc
CASA-VILA
Supr curte
Supr gradina
Tip incalzire
#
Pret solicitat
Stare
DE-VANZARE
Chirie lunara
Avans minimal
DE-INCHIRIAT
Durata minima
#
CLIENT
Nr client
Nume client
Adresa client
No telefon
OFERTANT
SE-VINDE
proprietate-a 1,1
1,n
VANZARE
Nr tranzactie
Data vanzare
CUMPARA
VINDE
1,1
1,1 0,n
0,n
1,1
0,1
vanzator
cumparator
vandut
ob-vanza
act-vanzare
act-cumparare
#
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
Data examen
1,n 0,n
sustine cursant
Nr matricol
Nume
Prenume
Nume discipl
Cod 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.


EXEMPLAR
Nr exemplar
An editie
IMPRUMUT
Data imprumut
RESTITUIRE
Data restituire
0,n
0,n
0,n
0,n
imprumutat
restituit
imprumuta
restituie
CITITOR
Nr legitimatie
Nume
Prenume
Adresa
Categorie
Data nasterii
Termen penaliz
Limita impr
=
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
IMPR-EXEMPL
0,n
0,n
0,n
imprumutat restituit
imprumuta
restituie
CITITOR
Nr legitimatie
Nume
Categorie
Data nasterii
Limita impr
Data imprumut
IMPRUMUT
1,1
1,n
IMPR-CITITOR
RESTITUIRE
Data restituire
1,n
cuprinde
facut-de
=
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
Nr comanda
Data comanda
PROD-COMANDAT
Cantitate comandata
PRODUS
Cod produs
Den produs
UM
1,n 0,n
FACTURA
Nr factura
Data factura
PROD-FACTURAT
Cantitate facturata
0,n
1,n
0,n
Pret unitar
1,1 1,1
0,1
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
PRODUS
Cod produs
Den produs
UM
FACTURA
Nr factura
Data factura
PROD-FACTURAT
Cantitate facturata
Pret unitar
PROD-C-DAT
Cant comandata
1,n 1,1
1,1
0,n
0,n 1,n
0,1
0,n
CUPRINDE
SE-REFERA-LA
CORESPUNDE
2.2.5.1. Dependente functionale

A. Dependente functionale simple.

ntre doua atribute A si B exista o dependenta functionala
notata
AB
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 furnizorPret aprovizionare

O dependenta functionala X Y este elementara daca pentru
orice X strict inclus n X, dependenta functionala XY nu este
verificata.

b. Dependente functionale multivaloare


ntre doua atribute A si B exista o dependenta functionala
multivaloare, notata:
AB
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:
XX.
Ex: Cod client Cod client

Dezvoltarea:
Daca XY atunci X,ZY.
Ex: Cod client Den client
Cod client, Localitate Den client

Tranzitivitatea:
Daca XY si YZ atunci XZ.
Ex: Cod client Localitate, Localitate Judet
Cod client Judet


Aditivitatea:
Daca XY si XZ atunci XY,Z.
Ex: Cod client Den client, Cod client Adresa client
Cod client Den client, Adresa client

Proiectia:
Daca XY,Z atunci XY si XZ.
Ex: Cod client Den client, Adresa client
Cod client Den client,
Cod client Adresa client

Pseudo-tranzitivitatea:
Daca XY si W,YZ atunci X,WZ.
Ex: Marca persoana Loc munca, Loc munca, Functie
Indemnizatie conducere
Marca persoana, Functie Indemnizatie conducere

>
O Dependentele functionale reprezinta RI .
O I dentificatorul unei entitati este un atribut sau un
grup de atribute fata de care toate celelate atribute
depind functional.
O Dependentele functionale pot exista si ntre
entitati si asocieri.
O 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
ANGAJAT
Nr_marca
Nume-angajat Nr_ore
EXECUTA
LUCRARE
Nr_lucrare
Den-lucrare
Obiectiv-constr
0,n 0,n
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.

Nr inventar
Val intrare
Durata funct
Putere nominala
Tip utilaj
UTILAJE
Tip utilaj Durata funct, Putere nominala
Nr inventar Tip utilaj, Val intrare, Durata funct, Putere nominala
Nr inventar
Val intrare
UTILAJ
Durata funct
Putere nominala
Tip utilaj
CATEG-UTILAJ
APARTINE
1,1 1,n
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.

Nr inventar
Val intrare
UTILAJ
Tarif orar
Nr op interventie
INTERVENTIE
0,n 0,n
REPARATIE
Durata efectiva
Durata normata Den op interventie
Nr op interventie Durata normata
Nr inventar
Val intrare
UTILAJ
Tarif orar
Nr op interventie
INTERVENTIE
0,n 0,n
REPARATIE
Durata efectiva
Durata normata
Den op interventie
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).

cod
operatie
Denumire
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
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 O
i
si daca a, b, c sunt aparitii corespunzatoare
evenimentelor E1, E2 sI respectiv E3, atunci sincronizarea :

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

indica faptul ca operatia O
i
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
Sincronizare
inactiva
Sincronizare
in asteptare
Sincronizare
activa (operatie
declansata)
Sincronizare
inactiva
Timp
t1 t2 t3
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



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.

Cerere
de credit
Instruire formala OP 1
c1 c2 c3
Scrisoare
de refuz
Dosar
deschiz
Informatii
suplimentare
OP 2
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. I dentificarea 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. I dentificarea 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.

Evenimente Actiuni induse Rezultate
1 1. . S So os si ir re ea a
c co om me en nz zi ii i d de e l la a
c cl li ie en nt t
C Co on nt tr ro ol le ea az za a i id de en nt ti it ta at te ea a
s si i p pr re et tu ul l
C Co om ma an nd da a a ac cc ce ep pt ta at ta a
s sa au u n nu u
2 2. . E Ex xi is st te en nt ta a u un nu ui i
m mi ij jl lo oc c d de e t tr ra an ns sp po or rt t
d di is sp po on ni ib bi il l
E Ef fe ec ct tu ue ea az za a l li iv vr ra ar re ea a L Li iv vr ra ar re e e ef fe ec ct tu ua at ta a
3 3. . S Sf f r rs si it tu ul l z zi il le ei i E Ex xa am mi in ne ea az za a c co om me en nz zi il le e
n n a as st te ep pt ta ar re e
C Co om ma an nd da a d de e
f fa ab br ri ic ca at ti ie e
1 1. .A Ac cc ce ep pt ta ar re ea a
c co om me en nz zi ii i
C Co on ns su ul lt ta ar re ea a s st to oc cu ur ri il lo or r
d de e p pr ro od du us se e
C Co om ma an nd da a l li iv vr ra ab bi il la a
s sa au u n nu u
2 2. .D De ec ci iz zi ie e d de e
l li iv vr ra ar re e
P Pr re eg ga at ti ir re ea a l li iv vr ra ar ri ii i M Ma ar rf fa a g ga at ta a d de e
p pl le ec ca ar re e
3 3. . S Sf f r rs si it tu ul l
a ac ct ti iv vi it ta at ti ii i d de e
l li iv vr ra ar re e
E Ex xp pe ed di ie er re ea a m ma ar rf fi ii i s si i
p pr re eg ga at ti ir re ea a f fa ac ct tu ur ri ii i
L Li iv vr ra ar re e e ex xp pe ed di ia at ta a
F Fa ac ct tu ur ra a
4 4. . C Co om ma an nd da a n n
a as st te ep pt ta ar re e
E Ex xa am mi in na ar re ea a
c co om me en nz zi il lo or r n n a as st te ep pt ta ar re e
C Co om ma an nd da a d de e
f fa ab br ri ic ca at ti ie e
Etapa 3. Tabloul evenimente -rezultate.

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.

OP1
Catre alt
proces
Factur
a
Livrare
efectuata
Sosirea comenzii
de la client
Controleaza
identitate si
pret
Nu Da
Comanda
refuzata
Comanda
acceptata
Op 2 Examineaza stoc
Sufucuent
Insufucuent
Comanda
livrabila
Comanda in
asteptare
Sfarsitul zilei
OP 3
Pregatirea
livrarii
a b
Livrare
pregatita
Mijloc
de transport
OP 6
Examineaza
comenzi
in asteprtare
c
d
C si d
OP 4
Facturare
OP 5 Expediaza marfa
Comanda de
fabricatie
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
OP 5
Efectueaza
livrarea
Livrare
efectuata
A si b
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
blocului corespunzator
operatiei examinarea
comenzilor n asteptare
este prezentata n
continuare :

Nume eveniment
Nr max de
aparitii
Termen
limita
Comanda
in asteptare
20 1 zi
Sfarsitul
zilei
a
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.

MCD
MED1
MED2
prel1
prel2
Realitate
modelare
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
CLIENT
CodClient
AdresaClient
Cod fiscal
Stare
1,n
1,1
CORESP
actualizare: acceptare comanda de la client

CUPRINDE
COMANDA
Nr comanda
Data c-da
Adresa-livr
Val-totala
Den client
LINIE-COMANDA
Cod produs
Den produs
UM
Pret vnz
Cantitate c-data
Valoare
1,n
1,1
2.4.2. Principiul validarii modelelor

Fiecare model extern trebuie sa fie deductibil din MCD

Model extern
Model conceptual
calcul echivalenta
Ex: MCD
COMANDA
Nr comanda
Data c-da
CLIENT
CodClient
DenClient
AdresaClient
CodFiscal
Stare
PRODUS
Cod produs
Den produs
UM
Pret vnz
PRODUS-C-DAT
Cantitate c-data
TRANSMITE
0,n
1,1
0,n
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

COMANDA
Nr comanda
Data c-da
CLIENT
CodClient
DenClient
AdresaClient
CodFiscal
Stare
PRODUS
Cod produs
Den produs
UM
Pret vnz
PRODUS-C-DAT
Cantitate c-data
TRANSMITE
0,n
1,1
0,n
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
PRODUS
Cod produs
Den produs
UM
FACTURA
Nr factura
Data factura
PROD-FACTURAT
Cantitate facturata
Pret unitar
PROD-C-DAT
Cant comandata
1,n 1,1
1,1
0,n
0,n 1,n
0,1
0,n
CUPRINDE
SE-REFERA-LA
CORESPUNDE
2.5.2. Modelul relational

Domeniu: o multime de elemente de tip similar.
Exemple:
NUME ZILE ORARE

I onescu 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 = {(a
1
,a
2
,..,a
n
):(a
1
e A
1
, a
2
e A
2
, ...a
n
e A
n
) . P(a
1
,a
2
,...a
n
) = adevarat}
unde A
1
,A
2
...A
n
sunt domenii.

Ex 1: A
1
: domeniul compozitorilor; A
2
: domeniul simfoniilor;
P(a
1
,a
2
) = "a
1
est autorul simfoniei a
2
".
P(Beethoven,Eroica)=adevarat;
P(Vivaldi,Simfonia fantastica)=fals.
Ex 2:
personal(MARCA,NUME,PRENUME,DATA-NASTERII)
daca (m,n,p,d) e 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).
MARCA NUME DATA NAST
125 Popescu Vasile 22/10/68
128 Adriana Popescu 17/5/65
336 Costea Ion 8/12/63
417 Ionescu Maria 30/4/64
Grad
Cardinalitate Tuplu
Atribute
PRENUME
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, ...)
Ae11
Ae12
...
E1
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
...
Ae21
Ae22
...
A1
_,n _,n
ASOC
ASOC(
Ae11 ,Ae21 ,A1)
E1( Ae11 ,Ae12, ...)
E2( Ae21 ,Ae22, ...)
Ex 1:

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

DISCIPLINA(Cod disciplina, Nume disciplina)

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

Ex : 2
ARTICOL
Cod articol
Den articol
Tip articol
UM
STRUCTURA-
FABRICATIE
Cantitate nec
0,n 0,n
compus-din component-in
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.
Ae11
Ae12
...
Ae21
Ae22
...
A1
_,1 _,n
ASOC
E1( Ae11 , Ae12,...,Ae21,A1)
E2( Ae21 ,Ae22,...)
E1 E2
ANGAJAT
Nume
Prenume
Data nasterii
Salariul lunar
Marc
COMPARTIMENT
Cod compartiment
Den compartiment
LUCREAZA
Data ncadrrii
1,1 0,n
lucreaza-la loc-munca
Ex 1
COMPARTIMENT(Cod compartiment, Den compartiment)

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


FILIATIE
tata copil
0,n
1,1
PERSOAN
Nume
Prenume
Data nasterii
Cod persoan
Sex
Ex 2
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
Subtip Subtip
Entitate
Subtip Subtip
1,1
1,1
0,1
0,1

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.

POSEDA
proprietar
BUN-IMOBILIAR
Nr bun
Adresa
Suprafata
Pret solicitat
Stare
DE-VANZARE
Chirie lunara
Avans minimal
DE-INCHIRIAT
Durata minima
#
CLIENT
Nr client
Nume client
Adresa client
No telefon
proprietate
1,1
1,n
BUN-DE-VANZARE( , Adresa, Suprafata, Pret solicitat, Stare, Nr Client) Nr bun
BUN-DE-INCHIRIAT( , Adresa, Suprafata, Nr bun
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 .