MODELUL CONCEPTUAL DE DATE

1. Modelul entitate-relaţie
2. Modelarea conceptuală a datelor folosind
modelul E-R
3. Generalizarea
4. Regulile specifice domeniului problemei (business
rules)
5. Paşi în modelarea datelor
6. Exemplu de modelare E-R

5/19/2019 Managementul Proiectelor Software 1

 1. Modelul entitate-relaţie
Model conceptual (semantic)
– surprinde cunoştinţele esenţiale referitoare la un domeniu de
aplicaţie, aşa cum sunt ele percepute de analist
– a fost introdus în metodologiile structurate de analiză şi
proiectare
– operează numai asupra domeniului problemei
– nevoia unor definiţii riguroase a construcţiilor folosite
Model conceptual de date
– obiective
• identificarea şi definirea elementelor din domeniul
problemei pentru care trebuie memorate date
• identificarea şi definirea relaţiilor dintre acestea

5/19/2019 Managementul Proiectelor Software 2

 1. Modelul entitate-relaţie (cont)
Modelul entitate-relaţie (Entity-Relationship Model, E-R)
P.P. Chen, The entity-relationship model: toward a unified view of data, ACM
Transactions on Database Systems 1(1976), No.1, 9-36
• reprezentare detaliată şi structurată a datelor din domeniul
problemei
• construcţii folosite (concepte, termeni)
– (1) entitate
– (2) relaţie
– (3) atribut
• se reprezintă grafic prin diagrama entitate-relaţie (diagrama E-R,
Entity-Relationship Diagram)
– foloseşte notaţiile E-R

5/19/2019 Managementul Proiectelor Software 3

 1. Modelul entitate-relaţie (cont)
Notaţii E-R

Simboluri de bază

Entitate Relaţie Cheie primară Atribut Atribut cu valori multiple

Gradul relaţiilor

Unară Binară Ternară

5/19/2019 Managementul Proiectelor Software 4

 1. Modelul entitate-relaţie (cont)
1.1. Entităţi
• persoane, locuri, obiecte, evenimente, concepte din mediul
utilizatorului pentru care organizaţia doreşte să deţină date
• exemple:
 persoană; ANGAJAT, STUDENT, PACIENT
 loc: STAT, REGIUNE, ŢARĂ
 obiect: MAŞINĂ, CLĂDIRE, AUTOMOBIL
 eveniment: VÂNZARE, ÎNREGISTRARE, SCHIMBARE
 concept: CONT BANCAR, CURS UNIVERSITAR, CENTRU DE PRELUCRARE
 tip de entitate (clasă de entitate)
 grupează toate entităţile care au proprietăţi sau caracteristici comune
 se exprimă printr-un substantiv la singular (scris cu majuscule)
 instanţă de entitate (realizare a entităţii)
 apariţie singulară a entităţii

5/19/2019 Managementul Proiectelor Software 5

 1. Modelul entitate-relaţie (cont)
1.2. Atribute
• atribut
– proprietate sau caracteristică a unui tip de entitate care prezintă interes
– este memorată în fiecare instanţă a tipului de entitate respective
– toate instanţele unui tip de entitate E au aceleaşi atribute
– valorile unui atribut diferă de la o instanţă a lui E la alta
– exemple de tipuri de entităţi şi atribute:
 STUDENT: NUMĂR MATRICOL, NUME, ADRESĂ, NUMĂR TELEFON
 ANGAJAT: MARCĂ, NUME, ADRESĂ, CALIFICARE
 ŢARĂ: DENUMIRE, CONTINENT, SUPRAFAŢĂ, POPULAŢIE
 AUTOMOBIL: NUMĂR ÎNMATRICULARE, CULOARE, GREUTATE, PUTERE
 VÂNZARE: DATA, CINE VINDE, CUI VINDE, VALOARE
 CURS UNIVERSITAR: DENUMIRE, SPECIALIZARE, SEMESTRU, PROFESOR, NUMĂR
ORE PE SĂPTĂMÂNĂ, FORMĂ DE EXAMINARE

5/19/2019 Managementul Proiectelor Software 6

 1. Modelul entitate-relaţie (cont)
Clasificarea atributelor unui tip de entitate
– atribut cheie: identifică o instanţă a entităţii
• cheie simplă - un singur atribut
• cheie compusă - un grup de atribute
– atribut non-cheie
Tipuri de atribute cheie
– cheie candidat: identifică unic o instanţă a entităţii
• o entitate poate avea mai multe chei candidat
– cheie primară: cheia candidat ca identificator pentru tipul de entitate
• atributele ce formează cheia primară sunt subliniate în diagrama E-R
– cheie surogat: atribut artificial pe post de cheie primară
Stabilirea cheii primare CP a unei entităţi E (Bruce, 1992)
– (i) cheia candidat a lui E care nu-şi modifică valoarea pe toată durata de
viaţă a oricărei instanţe
– (ii) pentru orice instanţă a lui E, atributele lui CP au valori valide şi non-nule
– (iii) dacă CP are prea multe atribute, se înlocuieşte cu o cheie surogat
– (iv) nu folosi chei “inteligente” (clasificare, localizare, structurare)

5/19/2019 Managementul Proiectelor Software 7

 1. Modelul entitate-relaţie (cont)
NUMĂR NUME ADRESĂ NUMĂR
MATRICOL TELEFON

STUDENT

Atribute şi cheie primară - reprezentare E-R

MARCĂ NUME ADRESĂ CALIFICARE

ANGAJAT

ANGAJAT

Atribute cu valori multiple

Atribut cu o singură valoare: o instanţă are o valoare pentru el

Atribut cu valori multiple (repetitiv): o instanţă are mai multe valori pentru el

5/19/2019 Managementul Proiectelor Software 8

 1. Modelul entitate-relaţie (cont)
1. Relaţii
• relaţie
– asociere între instanţe ale uneia sau mai multor tipuri de entităţi care
prezintă interes pentru problema studiată

STUDENT Urmează CURS

Relaţie în notaţia E-R

DATA
EXAMINĂRII

STUDENT Urmează CURS

Relaţie cu atribut

5/19/2019 Managementul Proiectelor Software 9

 1. Modelul entitate-relaţie (cont)
Gradul unei relaţii
– numărul de tipuri de entităţi care participă în relaţie
– clasificarea relaţiilor după gradul lor:
• unare sau recursive (de gradul 1)
• binare (de gradul 2)
• ternare (de gradul 3)
Cardinalitatea unei relaţii
– de la entitatea A la entitatea B: numărul de instanţe ale entităţii B asociate
unei instanţe a entităţii A
– de la entitatea B la entitatea A: numărul de instanţe ale entităţii A asociate
unei instanţe a entităţii B
Relaţii unare

PERSOANĂ Căsătorită ANGAJAT Conduce

cu

0:1 0:M

5/19/2019 Managementul Proiectelor Software 10

 1. Modelul entitate-relaţie (cont)
Relaţii binare (stânga spre dreapta)

ANGAJAT Are atribuit LOC DE PARCARE

1:1
PLAN DE
ÎNVĂŢĂMÂNT Conţine SEMESTRU

1:M

STUDENT Urmează CURS

M:N

5/19/2019 Managementul Proiectelor Software 11

 1. Modelul entitate-relaţie (cont)
Relaţii binare (dreapta spre stânga)

ANGAJAT Este atribuit LOC DE PARCARE

1:1
PLAN DE
ÎNVĂŢĂMÂNT Este conţinut în SEMESTRU

1:M

STUDENT Este urmat de CURS

M:N

5/19/2019 Managementul Proiectelor Software 12

 1. Modelul entitate-relaţie (cont)
Relaţie ternară

MATERIAL

FURNIZOR Expediază MAGAZIE

CANTITATE

Exprimarea cardinalităţii m:M se pune la capătul B pentru relaţia de la A la B

– m - cardinalitate minimă: numărul minim de instanţe ale lui B asociate unei instanţe a lui A
– M - cardinalitate maximă : numărul maxim de instanţe ale lui B asociate unei instanţe a lui A
– m = 0 - relaţie opţională
– m > 0 - relaţie obligatorie
– m = M - se specifică numai unul dintre ele

5/19/2019 Managementul Proiectelor Software 13

 1. Modelul entitate-relaţie (cont)
Exprimarea cardinalităţii în diagramele E-R

Cardinalitate obligatorie 1

Cardinalitate M (multiplă: 1, 2, ..., M)

Cardinalitate opţională 0 sau 1

Cardinalitate opţională 0 sau M

(0, 1, 2, ..., M)

5/19/2019 Managementul Proiectelor Software 14

 2. Modelarea conceptuală a datelor
folosind modelul E-R
(1) modelarea entităţilor şi relaţiilor
– entitate părinte
– entitate dependentă (slabă)
(2) modelarea atributelor cu valori multiple
– se transformă în entităţi noi
(3) modelarea datelor dependente de timp
– atribute ce se modifică în timp

5/19/2019 Managementul Proiectelor Software 15

 2. Modelarea conceptuală a datelor
folosind modelul E-R (cont)
(1) entitate părinte şi entitate dependentă
– entitate părinte
– entitate dependentă (slabă)
• o instanţă a ei nu poate exista dacă nu există instanţa corespunzătoare a entităţii
părinte
• regulă: cheia primară a entităţii părinte este prima componentă a cheii primare a
entităţii slabe

COTĂ TITLU COTĂ NUMĂR

CARTE CARTE CARTE INVENTAR

CARTE înregistrată sub EXEMPLAR

formă de

5/19/2019 Managementul Proiectelor Software 16

 2. Modelarea conceptuală a datelor
folosind modelul E-R (cont)
(2) modelarea atributelor cu valori multiple (atribute repetitive)
– (a) un singur atribut
– (b) un grup de atribute
(a) un singur atribut cu valori multiple

MARCĂ NUME ADRESĂ

CALIFICARE

ANGAJAT

MARCĂ NUME ADRESĂ COD

CALIFICARE

ANGAJAT Are CALIFICARE

5/19/2019 Managementul Proiectelor Software 17

 2. Modelarea conceptuală a datelor
folosind modelul E-R (cont)
(2) modelarea atributelor cu valori multiple (atribute repetitive)
(b) un grup de atribute cu valori multiple (grup de atribute repetitive)
NUMĂR NUME AN STUDIU
MATRICOL

STUDENT

DISCIPLINĂ DATĂ NOTĂ

EXAMEN

NUMĂR NUME AN STUDIU DISCI- DATĂ NOTĂ

MATRICOL PLINĂ EXAME
N

EXAMENE
Are NUMĂR
STUDENT SUSTINUTE
MATRICOL

5/19/2019 Managementul Proiectelor Software 18

 2. Modelarea conceptuală a datelor
folosind modelul E-R (cont)
(3) modelarea datelor dependente de timp
atribute care se modifică constant (imuabil) în timp
– valori relative: caracterizează atributul la un anumit moment de timp
• funcţia de modificare este liniară în raport cu timpul
• exemple: vîrstă, vechime la locul de muncă
– se înlocuiesc cu valori absolute: nu se modifică în timp
• exemple: data naşterii, data angajării
atribute care se modifică în timp (neperiodic)
– funcţia (legea) de modificare este neprecizată
– exemple
• salariul
• preţul de vânzare
• dobânda la credite sau depozite
• cursul valutar
– sunt de obicei grupuri de atribute repetitive
– durată de valabilitate - moment de timp - time stamp

5/19/2019 Managementul Proiectelor Software 19

 2. Modelarea conceptuală a datelor
folosind modelul E-R (cont)
(3) modelarea datelor dependente de timp - time-stamping

COD PREŢ DATĂ

PRODUS APLICARE

PRODUS

COD DATĂ PREŢ

PRODUS APLICARE

ISTORIE
PRODUS COD
Are PREŢURI
PRODUS

5/19/2019 Managementul Proiectelor Software 20

 3. Generalizarea
Tehnici de gestionare a complexităţii
– descompunerea
– clasificarea
• generalizarea
– atributele comune ale mai multor tipuri de entităţi (date) formează tipuri
mai generale
• specializarea, derivarea
– un tip mai general (supertip) este folosit pentru a obţine tipuri mai
particulare, specializate (subtip)
– SUBTIP ISA SUPERTIP
Exemplu: trei tipuri de entităţi
– Angajaţi de probă: MARCĂ ANGAJAT, NUME, ADRESĂ, DATA ANGAJĂRII,
SALARIUL ORAR
– Angajaţi salariaţi: MARCĂ ANGAJAT, NUME, ADRESĂ, DATA ANGAJĂRII,
SALARIUL LUNAR, SPOR VECHIME
– Consultanţi cu contract: MARCĂ ANGAJAT, NUME, ADRESĂ, DATA ANGAJĂRII,
NUMĂRUL CONTRACTULUI, SALARIUL ZILNIC

5/19/2019 Managementul Proiectelor Software 21

 3. Generalizarea (cont)
Subtipuri şi supertipuri de entităţi
NUME ADRESĂ

MARCĂ ANGAJAT DATA

ANGAJAT ANGAJĂRII

ISA ISA ISA

ANGAJAT ANGAJAT CONSULTANT

DE PROBĂ SALARIAT

MARCĂ SALAR MARCĂ SALAR MARCĂ SALAR

ANGAJAT ORAR ANGAJAT LUNAR ANGAJAT ZILNIC

SPOR NUMĂR
VECHIME CONTRACT

5/19/2019 Managementul Proiectelor Software 22

 3. Generalizarea (cont)
Moştenirea
– relaţie între tipuri de entităţi (clase de obiecte)
– clasă de bază (generalizare), clasă derivată (specializare)
– notaţie: clasă derivată --> clasă de bază (părinte)
– simplă, multiplă
– ierarhie de moştenire: arbore (graf) de moştenire
Modelarea datelor folosind moştenirea
• 0. Identifică tipurile de entităţi din domeniul problemei
• A. Identifică atributele comune ale entităţilor şi grupează-le într-un
supertip de entitate (generalizare)
• B. Exprimă entităţile iniţiale ca specializări ale supertipului obţinut
• C. Reia paşii A şi B pentru rezultatul obţinut

5/19/2019 Managementul Proiectelor Software 23

 3. Generalizarea (cont)
Modelarea datelor folosind moştenirea - exemplu
Domeniul problemei: Evidenţa personalului
0. S-au identificat următoarele tipuri de entităţi
• 1. ANGAJAT PERMANENT (MARCĂ ANGAJAT, NUME, DATA NAŞTERII, DEPARTAMENT, TELEFON, COD
NUMERIC PERSONAL)
• 2. ANGAJAT TEMPORAR (NUME, DATA NAŞTERII, TELEFON, COD NUMERIC PERSONAL, NUMĂR LUNI)
• MANAGER (MARCĂ ANGAJAT, FUNCŢIE, DEPARTAMENT, NUME, ADRESĂ, TELEFON, DATA NAŞTERII,
COD NUMERIC PERSONAL)
A. Atribute comune: NUME, DATA NAŞTERII, TELEFON, COD NUMERIC PERSONAL. Rezultă tipul de
entitate general PERSOANĂ (NUME, DATA NAŞTERII, TELEFON, COD NUMERIC PERSONAL).
B. Exprimă entităţile iniţiale folosind noua entitate:
• ANGAJAT PERMANENT ISA PERSOANĂ (MARCĂ ANGAJAT, DEPARTAMENT)
• ANGAJAT TEMPORAR ISA PERSOANĂ (NUMĂR LUNI)
• MANAGER ISA PERSOANĂ (MARCĂ ANGAJAT, FUNCŢIE, DEPARTAMENT, ADRESĂ)

5/19/2019 Managementul Proiectelor Software 24

 3. Generalizarea (cont)
Modelarea datelor folosind moştenirea - exemplu
A. Atribute comune pentru entităţile ANGAJAT PERMANENT şi MANAGER: (MARCĂ ANGAJAT,
DEPARTAMENT) - formează deja entitatea ANGAJAT PERMANENT

B. Exprimă MANAGER ca specializare a lui ANGAJAT PERMANENT:

• MANAGER ISA ANGAJAT PERMANENT (FUNCŢIE, ADRESĂ)

C. Rezultat final
• PERSOANA (NUME, DATA NAŞTERII, TELEFON, COD NUMERIC PERSONAL)

• ANGAJAT PERMANENT ISA PERSOANĂ (MARCĂ ANGAJAT, DEPARTAMENT)

• ANGAJAT TEMPORAR ISA PERSOANĂ (NUMAR LUNI)

• MANAGER ISA ANGAJAT PERMANENT (FUNCŢIE, ADRESĂ)

5/19/2019 Managementul Proiectelor Software 25

 3. Generalizarea (cont)
Modelarea datelor folosind moştenirea - exemplu
Modelul obiect - diagramă

PERSOANA
Nume
Data nasterii
Telefon
Cod numeric personal

ANGAJATTEMPORAR ANGAJAT
Numar luni Marca angajat
Departament

MANAGER
Functie
Adresa

5/19/2019 Managementul Proiectelor Software 26

 3. Generalizarea (cont)
Tipuri şi subtipuri de entităţi
• exclusive: fiecare instanţă a unui supertip este instanţă a unui
subtip (şi numai a unuia)
• exhaustive: subtipurile enumerate reprezintă toate subtipurile
posibile ale supertipului
– supertipul nu poate avea instanţe proprii
• non-exclusive: o instanţă a supertipului poate fi concomitent
instanţă a mai multor subtipuri.
• non-exhaustive: nu s-au definit decât o parte dintre subtipurile
posibile ale supertipului; celelalte subtipuri se includ (deocamdată)
sub umbrela supertipului
– supertipul poate avea instanţe proprii

5/19/2019 Managementul Proiectelor Software 27

 3. Generalizarea (cont)
Subtipuri exclusive şi non-exhaustive

INSECTĂ

ISA ISA ISA ISA

MUSCĂ ŢÂNŢAR ALBINĂ

5/19/2019 Managementul Proiectelor Software 28

 3. Generalizarea (cont)
Subtipuri non-exclusive şi non-exhaustive

INSECTĂ

ISA ISA ISA ISA ISA

ALBINĂ ALBINĂ TRÂNTOR MATCĂ

LUCRĂTOARE

5/19/2019 Managementul Proiectelor Software 29

 4. Reguli specifice domeniului
problemei (business rules)
Definiţie
– specificaţii care păstrează integritatea modelului
conceptual de date
Se referă la (exprimă prin)
 integritatea entităţii: fiecare instanţă a tipului de entitate
trebuie să aibă un identificator unic (sau valoare a cheii
primare) non nul(ă)
 integritatea referenţială: reguli privind relaţiile dintre tipurile de
entităţi; descrise la proiectul logic
 domenii: specificări ale atributelor
 operaţii de declanşare (triggers): reguli pentru protecţia
validităţii valorilor atributelor

5/19/2019 Managementul Proiectelor Software 30

 4. Reguli specifice domeniului
problemei (business rules) (cont)
Domenii
– specificări sistematice ale atributelor
– identificate printr-un nume
– specificarea conţine
• semnificaţia atributului
• tipul de date
• lungimea de reprezentare
• formatul de reprezentare
• domeniul valorilor permise
• unicitatea valorii?
• valoare nulă?
Exemple uzuale de domenii generale
– DATĂ CALENDARISTICĂ
– COD NUMERIC PERSONAL
– NUMĂR TELEFON
– ADRESĂ

5/19/2019 Managementul Proiectelor Software 31

 4. Reguli specifice domeniului
problemei (business rules) (cont)
Domenii - exemple: modelul conceptual de date
Domeniul problemei: Evidenţa notelor studenţilor

NUMĂR CONTRACT DISCIPLINĂ NOTĂ

MATRICOL are DE STUDII

DATĂ

SEMESTRU

NUME STUDENT
susţine EXAMEN DISCIPLINĂ

5/19/2019 Managementul Proiectelor Software 32

 4. Reguli specifice domeniului
problemei (business rules) (cont)
Domenii - exemple
Nume: NUMĂR MATRICOL
Semnificaţie: Numărul de înregistrare a studentului în registrul matricol
Tip de date: String
Format: nnnn
Unicitate: trebuie să fie unic
Null: trebuie să fie nenul

Nume: CODIFICARE DISCIPLINĂ

Semnificaţie: Identifică unic o disciplină din planul de învăţământ al unei specializări
Tip de date: String
Format: FSasnn unde:
F - codul facultăţii (literă, vezi codificarea facultăţilor la nivel de universitate)
S - codul specializării (literă, vezi codificarea specializărilor dintr-o facultate)
a - anul de studii (număr, între 1 şi numărul de ani de studii pentru specializare)
s - semestrul din an (1, 2)
nn - număr de ordine (00-99)
Unicitate: pentru FSas nn trebuie să fie unic
Null: trebuie să fie nenul

5/19/2019 Managementul Proiectelor Software 33

 4. Reguli specifice domeniului
problemei (business rules) (cont)
Operaţii de declanşare (triggers)
– aserţiuni sau reguli care guvernează validitatea operaţiilor de
manipulare a datelor:
• adăugarea (inserarea) de noi instanţe a entităţii
• actualizarea (modificarea) de instanţe ale entităţii
• ştergerea de instanţe ale entităţii
– se referă la
• atributele unei singure entităţi
• atributele mai multor entităţi din model
– specificarea conţine
• regula utilizator (user rule)
– o propoziţie concisă ce exprimă regula din domeniul problemei care este
întărită prin operaţia de declanşare
• evenimentul
– operaţia de manipulare a datelor (adăugare/inserare, modificare sau
ştergere) care iniţiază operaţia de declanşare
• numele entităţii ale cărei instanţe sunt accesate şi/sau modificate
• condiţia care provoacă declanşarea operaţiei
• acţiunea care se efectuează când operaţia se declanşează.

5/19/2019 Managementul Proiectelor Software 34

 4. Reguli specifice domeniului
problemei (business rules) (cont)
Operaţii de declanşare (triggering operations) - exemplu

Regulă utilizator: Un student poate să susţină examene doar la

disciplinele din contractul său de studii.
Eveniment: Inserare
Nume entitate: EXAMEN
Condiţie: EXAMEN.DISCIPLINĂ nu este în [CONTRACT DE
STUDII].DISCIPLINĂ pentru acelaşi STUDENT
Acţiune: Respinge tranzacţia de inserare

5/19/2019 Managementul Proiectelor Software 35

 4. Reguli specifice domeniului
problemei (business rules) (cont)
Implementarea regulilor domeniului problemei
• (a) în procedurile de prelucrare
• (b) în depozitul SGBD-ului
• (c) în obiectele specifice domeniului problemei (business objects)

(a) în procedurile de prelucrare

– aplicaţii clasice (SGBD clasice, SGF)
– se foloseşte limbajul de programare (de manipulare a datelor)
– programatorul de aplicaţie face totul
– dezavantaje
• redundanţă
• întreţinere greoaie
– modificarea unei reguli afectează mai multe proceduri
– modificări consistente?
» Am modificat în toate locurile?
• policalificarea programatorului de aplicaţie - costuri

5/19/2019 Managementul Proiectelor Software 36

 4. Reguli specifice domeniului
problemei (business rules) (cont)
Implementarea regulilor domeniului problemei
(b) în depozitul SGBD-ului (repository)
– SGBD moderne (2 tier client-server)
• server de date
– definiţii, prelucrări
• client
– prezentare
– depozitul de definiţii al SGBD-ului va conţine şi specificări pentru
• domenii
• restricţii de integritate referenţială
• operaţii de declanşare
– se folosesc limbajele de descriere, manipulare, interogare
– este în sarcina administratorului bazei de date
– avantaje
• separarea responsabilităţilor
– administratorul bazei de date: întreţine modelul de date
– programatorul de aplicaţie: scrie cod pentru prelucrările specifice
• aplicarea consistentă a regulilor domeniului problemei pentru BD
• costuri de întreţinere reduse
• erori mai puţine
– dezavantaje
• încărcarea serverului şi a reţelei de comunicaţie
• portabilitate redusă (toate regulile sunt dependente de SGBD-ul ales)

5/19/2019 Managementul Proiectelor Software 37

 4. Reguli specifice domeniului
problemei (business rules) (cont)
Implementarea regulilor domeniului problemei
(c) în obiectele specifice domeniului problemei
– SGBD moderne (3- sau n-tier client-server)
• server de date
– memorare + regăsire date
• nivel intermediar middle tier(s) - servere de componente (aplicaţii)
– logica aplicaţiei (business logic) se exprimă prin obiectele domeniului problemei
– intermediar între server şi client
• client
– prezentare, interfaţă
– nivelul intermediar conţine şi implementarea regulilor domeniului
problemei, înglobată în obiectele domeniului problemei
• se folosesc limbaje de programare generale, independente de serverul de date
sau de client
• este în sarcina programatorului de componente
– avantaje
• separarea responsabilităţilor este şi mai strictă
– administratorul bazei de date: întreţine modelul de date
– programatorul de componente: implementează logica aplicaţiei
– programatorul de aplicaţie: scrie cod pentru aplicaţiile client
• decongestionarea serverului de date
• portabilitate multiplatformă
• costuri de întreţinere reduse
• erori mai puţine

5/19/2019 Managementul Proiectelor Software 38

 5. Paşi în modelarea datelor
Modelarea datelor - puncte de vedere
(a) aria de cuprindere a modelului
– model de date al organizaţiei
– model de date al unei arii de activitate a organizaţiei
– model de date al unei aplicaţii
(b) nivelul de abstractizare a modelului
– model conceptual de date
• foloseşte numai elemente din domeniul problemei
– model logic de date
• foloseşte şi elemente din domeniul soluţiei
– model fizic de date
• foloseşte numai elemente din domeniul soluţiei
• dependent de arhitectura hard şi soft
(c) etapa din ciclul de dezvoltare în care se elaborează modelul
– ingineria de sistem- modele conceptuale
• modelul de date al organizaţiei
• modelul de date al ariei de activitate
– analiză - modele conceptuale
• modelul de date al contextului aplicaţiei
• modelul conceptual de date al aplicaţiei
– proiectare
• logică - modelul logic de date al aplicaţiei
• fizică - modelul fizic de date al aplicaţiei

5/19/2019 Managementul Proiectelor Software 39

 5. Paşi în modelarea datelor (cont)
Modelul de date al organizaţiei
– sinonim: model subiect
– conţine entităţile principale pentru care conducerea are nevoie de
informaţie
– modalităţi de exprimare
• E-R: entităţi, relaţii (fără atribute, cardinalităţi şi grade)
• model obiect (relaţii între clase, fără câmpuri şi metode)
– este întreţinut de administratorul BD a organizaţiei
Modelul de date al ariei de activitate
– arie de activitate: grup de activităţi înrudite
– conţine toate entităţile specifice ariei de activitate din modelul de date al
organizaţiei
– modalităţi de exprimare
• E-R: entităţi, relaţii, atribute, subtipuri, cardinalităţi şi grade
• model obiect: definiţii complete de clase
– este întreţinut de administratorul BD a organizaţiei
Modelul de date al contextului aplicaţiei
– în etapa de recunoaştere a problemei
– conţine toate entităţile din modelul ariei de activitate în care se încadrează
problema de rezolvat care sunt afectate de aplicaţie
– permite identificarea
• entităţilor proprii aplicaţiei
• entităţilor externe folosite de aplicaţie

5/19/2019 Managementul Proiectelor Software 40

 6. Exemplu de modelare E-R
Sursa:F.R.McFadden, J.A.Hoffer, Modern Database Management, 4nd ed, Benjamin/Cummings 1994
1. Descrierea problemei
Vacanţe la Munte şi la Mare (VMM) este o firmă de turism care are
în proprietate şi închiriază cabane de vacanţă în toată ţara. Există
două tipuri majore de proprietăţi: montane şi marine. Majoritatea
închirierilor se fac pe durata unei săptămâni (unitatea de închiriere
este săptămâna).
Se cere să se realizeze o aplicaţie pentru planificarea închirierii
proprietăţilor VMM.
2. Definirea entităţilor şi atributelor acestora
Modelarea conceptuală a datelor porneşte de la patru documente
folosite în sistemul de evidenţă manuală: Client, Contract de
închiriere, Proprietate marină şi Proprietate montană. Fiecare
document va considerat ca entitate şi va fi modelat separat.

5/19/2019 Managementul Proiectelor Software 41

 6. Exemplu de modelare E-R (cont)
2.1. Entitatea CLIENT
CLIENT
NUME ADRESĂ TELEFON SUMA
MAXIMĂ
Petre Ionescu Soporului 15, 3400 Cluj-Napoca 064-145321 200.000
Georgiana Duţu Mărului 21, 1900 Timişoara 056-234543 250.000
Romeo Tudor Fraţii Buzeşti 3/20, 75112 01- 8989891 300.000
Bucureşti
a) Documentul CLIENT

NUME ADRESĂ TELEFON SUMĂ MAXIMĂ

CLIENT

5/19/2019 Managementul Proiectelor Software 42

 6. Exemplu de modelare E-R (cont)
2.2. Entităţile PROPRIETATE MARINĂ şi PROPRIETATE MONTANĂ

PROPRIETATE MARINĂ
STRADA ORAS JUDEŢ COD NUMĂR CHIRIE DISTANŢĂ
CAMERE UZUALĂ PLAJĂ
Valului 12 Mamaia, CT, 1200 3 200.000 2
Tomis 25 Mangalia, CT, 1230 4 300.000 1/2
PROPRIETATE MONTANĂ
STRADA ORAS JUDEŢ COD NUMĂR CHIRIE SCHI
CAMERE UZUALĂ
Bradului 1 Sinaia, PH, 2200 3 150.000 C
Stibinei 2 Borşa, MM, 4230 4 250.000 C, F

(a) Documentele PROPRIETATE MARINĂ şi PROPRIETATE MONTANĂ

5/19/2019 Managementul Proiectelor Software 43

 6. Exemplu de modelare E-R (cont)
ORAŞ, JUDET, NR. CHIRIE UZUALĂ
STRADĂ COD CAMERE

PROPRIETATE

ISA ISA

PROPRIETATE PROPRIETATE
MARINĂ MONTANĂ

DISTANŢĂ SCHI
STRADĂ PLAJĂ STRADĂ

ORAŞ, JUDET, ORAŞ, JUDET,

COD COD

5/19/2019 Managementul Proiectelor Software 44

 6. Exemplu de modelare E-R (cont)
2. Entitatea CONTRACT DE ÎNCHIRIERE
CONTRACT DE ÎNCHIRIERE
Nume: Gheorghe Duţu Data: 12/01/98
Strada: Bradului 1
Oraş-Judeţ-Cod: Sinaia, PH, 2200
Din data de: 15/01/98
Până la data de: 29/01/98
Chiria săptămânală: 150.000

(a) Documentul CONTRACT DE ÎNCHIRIERE

ORAŞ JUDEŢ DATĂ DATĂ

STRADĂ
COD ÎNCEPUT SFÂRŞIT

CONTRACT
DE ÎNCHIRIERE

CHIRIE SĂPT. NUME CLIENT

5/19/2019 Managementul Proiectelor Software 45

 6. Exemplu de modelare E-R (cont)
Regulile domeniului problemei - operaţii de declanşare
Regulă utilizator: O DATĂ DE SFÂRŞIT pentru un CONTRACT DE ÎNCHIRIERE
trebuie să fie ulterioară DATEI DE ÎNCEPUT
Eveniment: Adăugare (inserare)
Numele entităţii: CONTRACT DE ÎNCHIRIERE
Condiţie DATĂ DE SFÂRŞIT < DATĂ DE ÎNCEPUT pentru un
CONTRACT DE ÎNCHIRIERE
Acţiune Se respinge inserarea tranzacţiei
(a) Restricţie fundamentală de integritate

Regulă utilizator: Nu se ia în considerare un CONTRACT DE ÎNCHIRIERE până când

nu există o înregistrare a CLIENTului pentru a semna contractul
Eveniment: Adăugare (inserare)
Numele entităţii: CONTRACT DE ÎNCHIRIERE
Condiţia NUME CLIENT din CONTRACT DE ÎNCHIRIERE nu există ca
instanţă de CLIENT
Acţiune: Se respinge inserarea tranzacţiei
(b) Restricţie de integritate referenţială

5/19/2019 Managementul Proiectelor Software 46

 6. Exemplu de modelare E-R (cont)
Regulile domeniului problemei - operaţii de declanşare

Regulă utilizator: Nu se ia în considerare un CONTRACT DE ÎNCHIRIERE pentru o

PROPRIETATE dacă intervalul de închiriere din contract se
suprapune cu cel dintr-un alt CONTRACT DE ÎNCHIRIERE pentru
aceeaşi proprietate
Eveniment: Adăugare (inserare)
Numele entităţii: CONTRACT DE ÎNCHIRIERE
Condiţia DATĂ DE ÎNCEPUT pentru un CONTRACT DE ÎNCHIRIERE nou
este între DATĂ DE ÎNCEPUT şi DATĂ DE SFÂRŞIT pentru un
CONTRACT DE ÎNCHIRIERE existent pentru aceeaşi proprietate
Acţiune: Se respinge inserarea tranzacţiei
(c) Restricţie de suprapunere

5/19/2019 Managementul Proiectelor Software 47

 6. Exemplu de modelare E-R (cont)
4. Diagrama E-R
ORAŞ, JUDET, NR. CHIRIE
NUME ADRES TELEFON SUMĂ MAXIMĂ STRAD COD CAMERE UZUALĂ
Ă Ă

CLIENT PROPRIETATE

Este
închiriată
Sem- prin ISA ISA
nează

ORAŞ JUDEŢ DATĂ DATĂ

STRAD COD ÎNCEPUT SFÂRŞIT PROPRIETATE PROPRIETATE
Ă MARINĂ MONTANĂ

DISTANŢĂ
STRAD PLAJĂ STRAD SCHI
CONTRACT
Ă Ă
DE ÎNCHIRIERE
ORAŞ, JUDET, ORAŞ, JUDET,
COD COD

CHIRIE NUME
SĂPT CLIENT

5/19/2019 Managementul Proiectelor Software 48

 6. Exemplu de modelare E-R (cont)
Explicarea diagramei E-R
1. Există o relaţie ISA între PROPRIETATE MARINĂ şi PROPRIETATE, ca
şi între PROPRIETATE MONTANĂ şi PROPRIETATE.
2. Există o relaţie numită Semnează între CLIENT şi CONTRACT DE
ÎNCHIRIERE. Cardinalitatea acesteia este opţională 0-M de la
CLIENT la CONTRACT DE ÎNCHIRIERE şi obligatorie de la CONTRACT
DE ÎNCHIRIERE la CLIENT. Prin urmare nu poate exista un contract
de închiriere semnat şi fără chiriaş valid.
Există o relaţie numită Este închiriată prin între PROPRIETATE şi
CONTRACT DE ÎNCHIRIERE. Cardinalităţile sunt la fel ca şi pentru
relaţia Semnează şi pentru aceleaşi motive.

5/19/2019 Managementul Proiectelor Software 49