MODELUL CONCEPTUAL DE DATE 1 Modelul entitaterelaie 2

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 11/28/2020 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 11/28/2020 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 11/28/2020 Managementul Proiectelor Software 3

1. Modelul entitate-relaţie (cont) Notaţii E-R Simboluri de bază Entitate Relaţie Cheie primară Atribut cu valori multiple Gradul relaţiilor Unară 11/28/2020 Binară Managementul Proiectelor Software Ternară 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 11/28/2020 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: · · · 11/28/2020 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 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) 11/28/2020 Managementul Proiectelor Software 7

1. Modelul entitate-relaţie (cont) NUMĂR MATRICOL NUME ADRESĂ NUMĂR TELEFON STUDENT Atribute şi cheie primară - reprezentare E-R MARCĂ ANGAJAT NUME ADRESĂ CALIFICARE 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 11/28/2020 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 11/28/2020 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Ă 0: 1 11/28/2020 Căsătorită cu ANGAJAT Conduce 0: M 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 11/28/2020 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 11/28/2020 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 11/28/2020 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) 11/28/2020 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 11/28/2020 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Ă CARTE 11/28/2020 TITLU CARTE COTĂ CARTE înregistrată sub formă de Managementul Proiectelor Software NUMĂR INVENTAR EXEMPLAR 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 ANGAJAT 11/28/2020 COD CALIFICARE ADRESĂ Managementul Proiectelor Software Are CALIFICARE 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 MATRICOL NUME AN STUDIU STUDENT DISCIPLINĂ NUMĂR MATRICOL DATĂ EXAMEN NUME STUDENT 11/28/2020 NOTĂ AN STUDIU DISCIPLINĂ Are Managementul Proiectelor Software EXAMENE SUSTINUTE DATĂ EXAME N NOTĂ NUMĂR MATRICOL 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 11/28/2020 Managementul Proiectelor Software 19

2. Modelarea conceptuală a datelor folosind modelul E-R (cont) (3) modelarea datelor dependente de timp - time-stamping PREŢ COD PRODUS DATĂ APLICARE PRODUS COD PRODUS 11/28/2020 DATĂ APLICARE Are PREŢ ISTORIE PREŢURI Managementul Proiectelor Software COD PRODUS 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 11/28/2020 Managementul Proiectelor Software 21

3. Generalizarea (cont) Subtipuri şi supertipuri de entităţi NUME MARCĂ ANGAJAT ISA ANGAJAT DE PROBĂ SALAR ORAR DATA ANGAJĂRII ANGAJAT ISA MARCĂ ANGAJAT ADRESĂ ISA ANGAJAT SALARIAT MARCĂ ANGAJAT CONSULTANT SALAR LUNAR SPOR VECHIME 11/28/2020 Managementul Proiectelor Software MARCĂ ANGAJAT SALAR ZILNIC NUMĂR CONTRACT 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 11/28/2020 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Ă) 11/28/2020 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Ă) 11/28/2020 Managementul Proiectelor Software 25

3. Generalizarea (cont) Modelarea datelor folosind moştenirea - exemplu Modelul obiect - diagramă 11/28/2020 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 11/28/2020 Managementul Proiectelor Software 27

3. Generalizarea (cont) Subtipuri exclusive şi non-exhaustive INSECTĂ ISA ISA MUSCĂ Ţ NŢAR ALBINĂ 11/28/2020 Managementul Proiectelor Software ISA 28

3. Generalizarea (cont) Subtipuri non-exclusive şi non-exhaustive INSECTĂ ISA ISA ALBINĂ LUCRĂTOARE TR NTOR MATCĂ 11/28/2020 Managementul Proiectelor Software ISA 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 11/28/2020 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Ă 11/28/2020 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 MATRICOL are CONTRACT DE STUDII DISCIPLINĂ NOTĂ DATĂ SEMESTRU NUME 11/28/2020 STUDENT susţine Managementul Proiectelor Software EXAMEN DISCIPLINĂ 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 11/28/2020 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ă. 11/28/2020 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 11/28/2020 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 11/28/2020 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) 11/28/2020 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ă • • 11/28/2020 – 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 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 11/28/2020 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 11/28/2020 Managementul Proiectelor Software 40

6. Exemplu de modelare E-R Sursa: F. R. Mc. Fadden, J. A. Hoffer, Modern Database Management, 4 nd ed, Benjamin/Cummings 1994 1. Descrierea problemei Vacanţe la Munte şi la Mare (VMM) este o firmă de turism care î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. 11/28/2020 Managementul Proiectelor Software 41

6. Exemplu de modelare E-R (cont) 2. 1. Entitatea CLIENT NUME ADRESĂ TELEFON SUMĂ MAXIMĂ CLIENT 11/28/2020 Managementul Proiectelor Software 42

6. Exemplu de modelare E-R (cont) 2. 2. Entităţile PROPRIETATE MARINĂ şi PROPRIETATE MONTANĂ 11/28/2020 Managementul Proiectelor Software 43

6. Exemplu de modelare E-R (cont) ORAŞ, JUDET, COD STRADĂ NR. CAMERE CHIRIE UZUALĂ PROPRIETATE STRADĂ ISA PROPRIETATE MARINĂ PROPRIETATE MONTANĂ DISTANŢĂ PLAJĂ ORAŞ, JUDET, COD 11/28/2020 SCHI STRADĂ ORAŞ, JUDET, COD Managementul Proiectelor Software 44

6. Exemplu de modelare E-R (cont) 2. Entitatea CONTRACT DE ÎNCHIRIERE STRADĂ ORAŞ JUDEŢ COD DATĂ ÎNCEPUT DATĂ SF RŞIT CONTRACT DE ÎNCHIRIERE CHIRIE SĂPT. 11/28/2020 NUME CLIENT Managementul Proiectelor Software 45

6. Exemplu de modelare E-R (cont) Regulile domeniului problemei - operaţii de declanşare 11/28/2020 Managementul Proiectelor Software 46

6. Exemplu de modelare E-R (cont) Regulile domeniului problemei - operaţii de declanşare 11/28/2020 Managementul Proiectelor Software 47

6. Exemplu de modelare E-R (cont) 4. Diagrama E-R NUME TELEFON ADRES Ă SUMĂ MAXIMĂ ORAŞ, JUDET, COD STRAD Ă Este închiriată prin Semnează ORAŞ JUDEŢ COD DATĂ ÎNCEPUT DATĂ SF RŞIT ISA PROPRIETATE MARINĂ PROPRIETATE MONTANĂ DISTANŢĂ PLAJĂ STRAD Ă CONTRACT DE ÎNCHIRIERE ORAŞ, JUDET, COD CHIRIE SĂPT 11/28/2020 CHIRIE UZUALĂ PROPRIETATE CLIENT STRAD Ă NR. CAMERE SCHI STRAD Ă ORAŞ, JUDET, COD NUME CLIENT 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. 11/28/2020 Managementul Proiectelor Software 49