MODELUL CONCEPTUAL DE DATE

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 12/5/2018 Managementul Proiectelor Software

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 12/5/2018 Managementul Proiectelor Software

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 12/5/2018 Managementul Proiectelor Software

Notaţii E-R Simboluri de bază Gradul relaţiilor Entitate Relaţie Cheie primară Atribut Atribut cu valori multiple Unară Binară Ternară 12/5/2018 Managementul Proiectelor Software

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 12/5/2018 Managementul Proiectelor Software

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 12/5/2018 Managementul Proiectelor Software

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) 12/5/2018 Managementul Proiectelor Software

Atribute şi cheie primară - reprezentare E-R 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 STUDENT NUMĂR MATRICOL NUME ADRESĂ TELEFON ANGAJAT MARCĂ NUME ADRESĂ CALIFICARE 12/5/2018 Managementul Proiectelor Software

1. Relaţii relaţie asociere între instanţe ale uneia sau mai multor tipuri de entităţi care prezintă interes pentru problema studiată Relaţie în notaţia E-R Relaţie cu atribut STUDENT Urmează CURS STUDENT Urmează CURS DATA EXAMINĂRII 12/5/2018 Managementul Proiectelor Software

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ă cu ANGAJAT Conduce 0:1 0:M 12/5/2018 Managementul Proiectelor Software

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 12/5/2018 Managementul Proiectelor Software

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 12/5/2018 Managementul Proiectelor Software

Relaţie ternară 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 FURNIZOR MAGAZIE Expediază MATERIAL CANTITATE 12/5/2018 Managementul Proiectelor Software

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) 12/5/2018 Managementul Proiectelor Software

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 12/5/2018 Managementul Proiectelor Software

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 TITLU CARTE NUMĂR INVENTAR EXEMPLAR înregistrată sub formă de 12/5/2018 Managementul Proiectelor Software

(2) modelarea atributelor cu valori multiple (atribute repetitive) (a) un singur atribut (b) un grup de atribute (a) un singur atribut cu valori multiple ANGAJAT MARCĂ NUME ADRESĂ CALIFICARE ANGAJAT MARCĂ NUME ADRESĂ Are CALIFICARE COD CALIFICARE 12/5/2018 Managementul Proiectelor Software

(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Ă DATĂ EXAMEN NOTĂ DISCI-PLINĂ EXAMENE SUSTINUTE Are 12/5/2018 Managementul Proiectelor Software

(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 12/5/2018 Managementul Proiectelor Software

(3) modelarea datelor dependente de timp - time-stamping COD PRODUS PREŢ DATĂ APLICARE COD PRODUS ISTORIE PREŢURI DATĂ APLICARE PREŢ Are 12/5/2018 Managementul Proiectelor Software

Managementul Proiectelor Software
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 12/5/2018 Managementul Proiectelor Software

3. Generalizarea (cont) Subtipuri şi supertipuri de entităţi NUME ADRESĂ DATA ANGAJĂRII ANGAJAT MARCĂ DE PROBĂ SALARIAT CONSULTANT SALAR ORAR LUNAR ZILNIC SPOR VECHIME NUMĂR CONTRACT ISA 12/5/2018 Managementul Proiectelor Software

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 12/5/2018 Managementul Proiectelor Software

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Ă) 12/5/2018 Managementul Proiectelor Software

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) 12/5/2018 Managementul Proiectelor Software

3. Generalizarea (cont) Modelarea datelor folosind moştenirea - exemplu Modelul obiect - diagramă 12/5/2018 Managementul Proiectelor Software

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 12/5/2018 Managementul Proiectelor Software

3. Generalizarea (cont) Subtipuri exclusive şi non-exhaustive INSECTĂ ISA MUSCĂ ŢÂNŢAR ALBINĂ 12/5/2018 Managementul Proiectelor Software

3. Generalizarea (cont) Subtipuri non-exclusive şi non-exhaustive INSECTĂ ISA ALBINĂ ALBINĂ LUCRĂTOARE MATCĂ TRÂNTOR 12/5/2018 Managementul Proiectelor Software

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 12/5/2018 Managementul Proiectelor Software

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Ă 12/5/2018 Managementul Proiectelor Software

Domenii - exemple: modelul conceptual de date Domeniul problemei: Evidenţa notelor studenţilor NUMĂR MATRICOL NOTĂ DATĂ STUDENT EXAMEN DISCIPLINĂ susţine NUME CONTRACT DE STUDII are SEMESTRU 12/5/2018 Managementul Proiectelor Software

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 12/5/2018 Managementul Proiectelor Software

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ă. 12/5/2018 Managementul Proiectelor Software

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 12/5/2018 Managementul Proiectelor Software

Implementarea regulilor domeniului problemei (a) în procedurile de prelucrare (b) în depozitul SGBD-ului (c) în obiectele specifice domeniului problemei (business objects) 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 12/5/2018 Managementul Proiectelor Software

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) 12/5/2018 Managementul Proiectelor Software

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 12/5/2018 Managementul Proiectelor Software

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 12/5/2018 Managementul Proiectelor Software

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 E-R: entităţi, relaţii, atribute, subtipuri, cardinalităţi şi grade model obiect: definiţii complete de clase 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 12/5/2018 Managementul Proiectelor Software

6. Exemplu de modelare E-R
Sursa:F.R.McFadden, J.A.Hoffer, Modern Database Management, 4nd ed, Benjamin/Cummings 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. 12/5/2018 Managementul Proiectelor Software

6. Exemplu de modelare E-R (cont)
2.1. Entitatea CLIENT CLIENT NUME ADRESĂ TELEFON SUMĂ MAXIMĂ 12/5/2018 Managementul Proiectelor Software

2.2. Entităţile PROPRIETATE MARINĂ şi PROPRIETATE MONTANĂ 12/5/2018 Managementul Proiectelor Software

PROPRIETATE STRADĂ ORAŞ, JUDET, COD NR. CAMERE CHIRIE UZUALĂ ISA PROPRIETATE MARINĂ PROPRIETATE MONTANĂ DISTANŢĂ PLAJĂ SCHI 12/5/2018 Managementul Proiectelor Software

2. Entitatea CONTRACT DE ÎNCHIRIERE CONTRACT DE ÎNCHIRIERE STRADĂ ORAŞ JUDEŢ COD DATĂ ÎNCEPUT DATĂ SFÂRŞIT CHIRIE SĂPT. NUME CLIENT 12/5/2018 Managementul Proiectelor Software

Regulile domeniului problemei - operaţii de declanşare 12/5/2018 Managementul Proiectelor Software

4. Diagrama E-R CLIENT NUME ADRESĂ TELEFON SUMĂ MAXIMĂ CONTRACT DE ÎNCHIRIERE STRADĂ ORAŞ JUDEŢ COD DATĂ ÎNCEPUT DATĂ SFÂRŞIT CHIRIE SĂPT NUME CLIENT PROPRIETATE ORAŞ, JUDET, COD NR. CAMERE CHIRIE UZUALĂ ISA PROPRIETATE MARINĂ PROPRIETATE MONTANĂ DISTANŢĂ PLAJĂ SCHI Sem-nează Este închiriată prin 12/5/2018 Managementul Proiectelor Software

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. 12/5/2018 Managementul Proiectelor Software

MODELUL CONCEPTUAL DE DATE

Similar presentations

Presentation on theme: "MODELUL CONCEPTUAL DE DATE"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

MODELUL CONCEPTUAL DE DATE

Similar presentations

Presentation on theme: "MODELUL CONCEPTUAL DE DATE"— Presentation transcript:

Similar presentations

About project

Feedback