Modelarea BD Cu Visio Studenti

Gabriela Vrlan
Modelarea bazelor de date.

UML, ORM.
Universitatea Dunrea de Jos

Galai 2007
Modelarea bazelor de date
Cuprins
Cuprins........................................................................................................... 1
4. Proiectarea bazelor de date utiliznd regulile de afaceri...........2
4.1. Puin teorie............................................................................................................ 2
4.2. Object Role Modeling........................................................................................... 4
4.3. Proiectarea unui model surs ORM....................................................................5
5. Generarea unui model surs ORM....................................................12

5.1. Introducerea regulilor de afaceri....................................................................13
5.2. Adugarea de exemple la tipurile de fapte...................................................17
5.3. Salvarea unui model............................................................................................. 18
5.4. Afiarea tipurilor de fapte n fereastra Drawing......................................19
6. Constrngeri ORM...............................................................................21
6.1. Tipuri de constrngeri ORM..............................................................................21

6.2. Constrngeri de unicitate (uniqueness constraints)...................................24
6.2.1. Constrngeri de unicitate interne (internal uniqueness)....................25
6.2.2. Constrngeri de unicitate externe (external uniqueness).................25
6.2.3. Constrngeri de unicitate primare (primary uniqueness)..................27
6.3. Constrngeri obligatorii (mandatory constraints).......................................28
6.4. Constrngeri circulare (ring constraints)......................................................29
6.5. Constrngeri comparare de mulimi (set-comparison constraints).........40
6.5.1. Constrngeri de tip submulime (subset constraints)........................40
6.5.2. Constrngeri de egalitate (equality constraints)................................45
6.5.3. Constrngeri de excludere (exclusion constraints)............................46
6.6. Alte tipuri de constrngeri...............................................................................48
6.6.1. Constrngeri de frecven (frequency constraints)...........................48
7.6.2. Constrngeri index......................................................................................52
7.6.3. Constrngeri de valoare (value)...............................................................54
7.6.4. Constrngeri disjunctive de excludere (exclusive-or constraint)...55
8. Transpunerea unui model ORM ntr-un model logic al bazei de date
57
8.1. Crearea unui proiect nou....................................................................................57

8.2. Adugarea modelului surs ORM n lista proiectului...................................58
8.3. Transpunerea modelului surs ORM ntr-un model logic............................59
8.4. Vizualizarea diagramei logice............................................................................61
8.5. Alte operaii care se pot efectua asupra modelului conceptual i logic.66
8.6. Verbalizarea.......................................................................................................... 71
9. Generarea schemei fizice a bazei de date....................................74
9.1. Despre constrngeri i modul n care acestea sunt transpuse n tabelele bazei de date 95
Anexe........................................................................................................ 100
Anexa nr.1 Raportul constrngerilor.....................................................................100
Anexa nr.2 Reportul faptelor..................................................................................118
Anexa nr.3 Rapotul tipurilor de obiecte..............................................................133
Anexa nr.4 Raportul tabelelor.................................................................................151
Anexa nr.5 Raport statistic.....................................................................................181
Cuprins
4. Proiectarea bazelor de date

utiliznd regulile de afaceri
Avuia cea mai important pentru o organizaie o reprezint informaia. Fr existena informaiilor o
organizaie nu ar mai putea exista, iar pentru a supraveui aceste informaii trebuie utilizate corect,
pentru a se putea obine rezultate care s conduc la alegerea celei mai bune soluii pentru
prosperitatea acesteia. Pentru ca acest lucru s fie posibil de realizat, aceste informaii trebuie stocate,
triate (filtrate) i analizate n funcie de necesitile aprute ntr-un anumit moment dat. Cea mai bun
alegerea pentru ca aceste informaii s fie coerente, i s nu fie pierdute, sau distruse, n mod
intenionat sau nu, este stocarea acestora n diverse baze de date.
De reinut este citatul lui Alvin Tofler , iar informaia acumulat, o parte a avuiei naionale.
Cnd un administrator de baze de date este ntrebat ce instrument CASE (Computer Aided Software
Engineering) folosete n proiectarea, implementarea i analiza bazelor de date, unii vor rspunde
Oracle Designer, alii CA ERWin/ERX sau Embarcadero ERStudio, iar alii vor opta pentru Rational
Rose i lista poate continua. Desigur, opiunile de alegere a unui anumit instrument sunt dictate, n
general, de preferine de natur subiectiv cunoaterea respectivului instrument fiind decisiv n
alegerea produsului [Raicu, 2001].
4.1. Puin teorie

nainte de a ncepe prezentarea modalitilor prin care se poate realiza proiectarea unei baze de date
utiliznd metodologia ORM (pentru exemplificare s-a ales produsul Microsoft Visio for
Enterprise Architects) vom trecem n revist anumite noiuni, concepte etc. care sunt necesare
pentru o mai bun nelegere a acestei metodologii.
Se tie c un sistem informaional cuprinde totalitatea resurselor care permit colectarea, administrarea,
controlul i propagarea informaiilor ntr-o organizaie. Atunci cnd prelucrarea datelor se efectueaz
prin intermediul calculatoarelor, acest sistem va cuprinde urmtoarele componente:
baza de date;
elementele software ale bazei de date;
software de aplicaie;
elementele hardware ale calculatorului;
personalul care utilizeaz i dezvolt sistemul.

Dintre aceste componente baza de date constituie componenta fundamental a sistemului
informaional, iar dezvoltarea i utilizarea sa trebuie privite din perspectiva cerinelor mai largi ale
organizaiei. Prin urmare, ciclul de via al unui sistem informaional aferent unei organizaii este
inerent legat de ciclul de via al sistemului de baze de date care l susine, i de asemenea, ciclul de
via al aplicaiei de tip baz de date este inerent legat de ciclul de via al sistemului informaional.
Ciclul de via al unui sistem informaional implic existena mai multor faze:
studiu de fezabilitate;
analiza cerinelor;
proiectarea conceptual a datelor i operaiilor;
proiectarea logic;
proiectarea extern;
realizarea de prototipuri;
Proiectarea bazelor de date utiliznd regulile de afaceri
proiectarea intern i implementarea;

testarea i validarea;
ntreinerea (mentenana);
iar etapele principale ale ciclului de via ale unei aplicaii de tip baz de date sunt [Conn & alt, 2001]:
planificarea bazei de date;
definirea sistemului;
colectarea i analiza cerinelor;
proiectarea bazei de date;
alegerea sistemului SGBD (opional);
proiectarea aplicaiei;
realizarea prototipului (opional);
implementarea;
conversia i implementarea datelor;
ntreinerea operaional.
Etapa de proiectare a bazei de date reprezint procesul de realizare a unui proiect pentru o baz de
date, care va trata toate operaiile i obiectivele organizaiei. Calitatea unei aplicaii de baze de date
depinde de proiectarea sa.
Scopurile etapei de proiectare a bazei de date sunt:
reprezentarea datelor i a relaiilor dintre ele, necesare tuturor domeniilor de aplicaie i

grupurilor de utilizatori principali;
furnizarea unui model de date care s accepte efectuarea oricrei tranzacii necesare asupra
datelor;
specificarea unui proiect minimal, structurat n mod adecvat pentru realizarea cerinelor
stabilite privind performanele sistemului, cum ar fi timpul de rspuns.
n proiectarea unui sistem de baze de date se pot utiliza mai multe strategii de abordare dintre care
cele mai cunoscute sunt:
Proiectare de jos n sus (bottom-up sau ascendent), care ncepe prin definirea
atributelor, a asociaiilor dintre atribute, i n final gruparea acestora n entiti. Un astfel de

tip de abordare este reprezentat de procesul de normalizare. Normalizarea implic
identificarea atributelor necesare i plasarea lor n tabele normalizate, bazate pe dependenele
funcionale dintre atribute. Acest tip de proiectare a unui sistem de baze de date este indicat n
proiectarea unor baze de date simple, cu un numr relativ mic de atribute.
Proiectare de sus n jos (top-down sau descendent), este indicat n proiectarea unor
aplicaii de tip baze de date complexe. Aceasta ncepe cu realizarea unor modele de date, care
conin cteva entiti i relaii de nivel nalt, dup care se aplic rafinri succesive de sus n
jos, pentru a identifica entitile, relaiile i atributele asociate de nivel jos. Acest tip de
abordarea este specific modelului Entitate - Relaie, care ncepe cu identificarea entitilor i
relaiilor dintre ele care prezint interes pentru organizaie.
De asemenea, toate metodologiile utilizate n etapa de proiectare (numit i etapa de modelare) a

bazelor de date cuprind trei etape principale, i anume:
Proiectarea conceptual (elaborarea modelului conceptual) reprezint procesul de
construire a unui model al informaiilor utilizate n cadrul unei organizaii, independent de

toate consideraiile fizice. Aceast faz este complet independent de detaliile de
implementare (elementele software ale SGBD-ului, programe de aplicaii, limbaje de
programare, platforma hardware etc.).
Proiectarea logic (elaborarea modelului logic) reprezint procesul de construire a unui
model al informaiilor utilizate n cadrul unei organizaii, bazat pe un anumit model de date,
dar independent de un anumit SGBD i de alte consideraii fizice.
Proiectarea fizic (elaborarea modelului fizic) reprezint procesul de realizare a unei
descrieri a implementrii bazei de date ntr-o capacitate de stocare secundar; descrie

structurile de stocare i metodele de acces utilizate pentru realizarea unui acces eficient la
date. Modelul rezultat n urma acestei etape este cel care st la baza materializrii bazei de
date propriu-zise.
Proiectarea bazei de date se poate realiza n dou moduri:
pornind de la o baz de date existent, utiliznd procedeul reverse engineering (proiectare

invers);
pornind de la zero, elabornd pe rnd cele trei modele enumerate mai sus, utiliznd procedeul
forward engineering (proiectare direct).
4.2. Object Role Modeling

Diagramele de tip ORM (Object Role Modeling) vor fi executate cu ajutorul produsului Microsoft
Visio for Enterprise Architects, astfel se vor elabora modelele conceptuale ale bazelor de date.
Modelul rezultat este independent de platforma pe care se va implementa baza de date rezultat.
ORM reprezint o descriere general a bazei de date, utiliznd simboluri intuitive pentru obiecte i
atribute i care verbalizeaz (exprim) relaiile dintre acestea, utiliznd o gam larg de constrngeri
care surprinde i foreaz regulile de afaceri [Raicu, 2001].
De asemenea, ORM este un mod de abordare conceptual de un nivel nalt, folosit pentru modelarea
datelor care descrie domeniul aplicaiei (lumea este vzut n termeni ai obiectelor, i a rolurilor pe
care aceste obiecte le ndeplinesc) utiliznd n acest scop simboluri intuitive i un limbaj natural pe
care att utilizatorii ct i proiectanii bazei de date le poate nelege. Fiecare tip de element al faptului
care are loc ntre tipuri de obiecte este verbalizat i afiat ntr-o diagram de schem conceptual. n
acelai timp, ORM permite folosirea unui set extins de constrngeri pentru a surprinde regulile de
afaceri (business rules), precum i ncorporarea unor exemple pentru verificarea corectitudinii
tipurilor de fapte introduse n proiect.
Procedura de proiectare a schemei conceptuale ORM se caracterizeaz prin analiza i proiectarea
datelor. Schema conceptual specific structura informaional a aplicaiei prin intermediul tipurilor
de fapte. Un model surs ORM poate fi folosit n loc de, sau naintea unui alt model de proiectarea a
bazei de date.
Versiunile timpurii ale ORM-ului au fost dezvoltate n Europa la mijlocul anilor 1970 (de exemplu,
modelarea relaiilor binare, NIAM Natural Language Information Analysis Method, NLM
Natural Language Modeling, FORML Format Object-Role Modeling Language).
ORM permite:
Proiectarea conceptual a bazei de date folosind fapte i exemple descrise ntr-un limbaj
natural.
Construirea automat a modelelor logice i fizice ale bazei de date pe baza faptelor exprimate
ntr-un limbaj natural.
Modelul bazei de date este creat ntr-un limbaj care poate fi neles de utilizatorii non-tehnici.
Dintre caracteristicile mai importante ORM se enumer:
este uor de neles exprim fapte i reguli n limba englez i / sau alte grafice intuitive;
este fiabil valideaz regulile folosind limba englez i mostre de date;
este expresiv surprinde n mod grafic multe reguli de afaceri i mai complexe;
este stabil minimizeaz impactul modificrilor asupra modelului i interogrilor.

4.3. Proiectarea unui model surs ORM

Pentru nceput se va face o scurt trecere n revist a posibilitilor pe care un proiectant le are la
dispoziie pentru generarea unui model surs ORM.
1. Crearea unui nou model pornind de la zero:
1. Din meniul File se alege opiunea New, apoi Database, i click pe ORM Source Model.
2. Din meniul Database, se alege Options, i apoi click pe Document. n cutia de dialog ORM
Document Options, se vor alege opiunile pentru modelul ORM.
3. Crearea faptelor alegnd una din urmtoarele variante:
conectarea tipurilor de obiecte i predicatelor cu conectori de rol;
definirea faptelor utiliznd Editorul de Fapte (Fact Editor).
4. Alegerea tipurilor de entiti care pot fi combinate, i notarea (observarea) oricrei deduceri
aritmetice.
5. Adugarea constrngerilor de unicitate, a constrngerilor obligatorii, i verificarea pentru
deduceri logice.
6. Adugarea unor valori, a constrngerilor comparare de mulimi, sau a constrngerilor subtip.
7. Adugarea altor constrngeri.
Deoarece aceast modalitate de creare a unui model surs ORM va face obiectul crii nu se insist
acum asupra pailor care trebuie parcuri.
2. Utilizarea unui model drept punct de plecare utiliznd reverse engineering
Dac se dorete utilizarea unei baze de date existente, atunci va trebui s se importe schema acesteia.
Pentru a efectua acest lucru se vor executa urmtorii pai:
1. Din meniul File, se alege opiunea New, apoi Database, i click pe ORM Source Model.
2. Din meniul Database, click pe opiunea Reverse Engineer...
Fig. 4.1. Setarea opiunilor pentru utilizarea

schemei unei baze de date existente
3.
Pe primul ecran Reverse Engineer Wizard (figura 4.1.), se vor executa urmtoarele operaii:
Se va specifica tipul bazei de date, Visio avnd instalate mai multe driver-e pentru diverse
motoare de baze de date precum: SQL Server, Oracle, Access etc. Deci se va selecta
driver-ul bazei de date Microsoft Visio pentru SGBD-ul ales. Dac driver-ul nu exist,
aceast operaie poate fi efectuat acum prin selectarea butonului Setup... (se asociaz un
driver ODBC).
Dup ce s-a selectat driver-ul trebuie specificat sursa bazei de date pentru care se dorete
4.
5.
efectuarea acestei operaii. Dac nu exist deja creat o surs de date pentru baza de date
existent, se execut aceast operaie acum prin selectarea butonului New.... n momentul
n care se creeaz o nou surs, numele su este adugat n lista Data Sources.
Dac toate setrile au fost fcute conform necesitilor impuse, se apas butonul Next.
n continuare se urmresc instruciunile din urmtoarele cutii de dialog.

De exemplu, trebuie specificai parametrii de securitate ai conexiunii. Astfel, prin intermediul
cutiei de dialog Connect Data Source, se cere numele utilizatorului i parola de acces la
baza de date, dup care se acioneaz butonul OK. Dac exist mai multe baze de date pentru
sursa de date selectat pe ecran va apare o fereastr prin intermediul creia utilizatorul are
posibilitatea de a alege baza de date dorit (figura 4.2., n cazul n care baza de date este
Access, n caz contrar apare fereastra din figura 4.3.), dac nu se trece la pasul urmtor.
Fig. 4.2. Alegerea sursei de date

6.
n continuare se precizeaz tipurile de informaii care se doresc a fi extrase (importate) din

baza de date (tabele, view-uri, proceduri stocate, trigger-e, indeci etc.), dup care se d click
pe butonul Next. Trebuie precizat c nu toate opiunile sunt disponibile, acestea depinznd de
facilitile oferite de baza de date (Access, SQL etc.).
Fig. 4.3. Selectarea tipurilor de informaii

ce se doresc a fi extrase din baza de date surs
7.
8.
Se selecteaz tabelele (eventual i view-urile, dac exist) care se doresc a fi extrase, sau
click pe Select All pentru a le extrage pe toate, i apoi click pe Next (figura 4.4.).
Dac s-a selectat opiunea Stored Procedures, trebuie selectate procedurile care se doresc a
fi extrase, sau click pe Select All, i apoi click pe Next. n cazul de fa nu exist proceduri
stocate (figura 4.5).
9.
Este indicat s se revizuiasc setrile de import (informaiile selectate), i apoi se acioneaz

butonul Finish. Odat apsat acest buton sunt importate toate informaiile selectate (figura
4.6.).
Fig. 4.4. Selectarea tabeleleor necesare proiectrii noi baze de date
Fig. 4.5. Selectarea procedurilor stocate
Fig. 4.6. Verificarea informaiilor setate

10. n acest moment vor fi extrase informaiile selectate i vor fi afiate informaii referitoare la
procesul de extragere a acestora n pagina Output, a tipurilor de fapte n pagina Business
Rules etc.
Fig. 4.7. n pagina Output vor fi afiate informaiilor

referitoare la procesul de extragere
Astfel, informaiile afiate sunt:
Reverse engineering from database 'AdventureWorks' on server 'ELA-HOME-PC'...
Extracting columns of table 'AWBuildVersion'.
Extracting columns of table 'DatabaseLog'.
Extracting columns of table 'ErrorLog'.
Extracting columns of table 'Department'.
Extracting columns of table 'Employee'.
Extracting columns of table 'EmployeeAddress'.
Extracting columns of table 'EmployeeDepartmentHistory'.
Extracting columns of table 'EmployeePayHistory'.
Extracting columns of table 'JobCandidate'.
Extracting columns of table 'Shift'.
Extracting columns of table 'Address'.
..........
Extracting columns of table 'StoreContact'.
Extracting check of table 'AWBuildVersion'.
Extracting check of table 'DatabaseLog'.
Extracting check of table 'ErrorLog'.
Extracting check of table 'HumanResources.Department'.
Extracting check of table 'HumanResources.Employee'.
Extracting check of table 'HumanResources.EmployeeAddress'.
..........
Extracting check of table 'Sales.StoreContact'.
Extracting primary key of table 'AWBuildVersion'.
Extracting primary key of table 'DatabaseLog'.
Extracting primary key of table 'ErrorLog'.
Extracting primary key of table 'HumanResources.Department'.
Extracting primary key of table 'HumanResources.Employee'.
Extracting primary key of table 'HumanResources.EmployeeAddress'.
..........
Extracting primary key of table 'Sales.StoreContact'.
Extracting indexes of table 'AWBuildVersion'.

Extracting indexes of table 'DatabaseLog'.
Extracting indexes of table 'ErrorLog'.
Extracting indexes of table 'HumanResources.Department'.
Extracting indexes of table 'HumanResources.Employee'.
Extracting indexes of table 'HumanResources.EmployeeAddress'.
..........
Extracting indexes of table 'Sales.StoreContact'.
Extracting foreign keys of table 'AWBuildVersion'.
Extracting foreign keys of table 'DatabaseLog'.
Extracting foreign keys of table 'ErrorLog'.
Extracting foreign keys of table 'HumanResources.Department'.
Extracting foreign keys of table 'HumanResources.Employee'.
Extracting foreign keys of table 'HumanResources.EmployeeAddress'.
..........
Extracting foreign keys of table 'HumanResources.EmployeePayHistory'.
Extracting foreign keys of table 'Sales.StoreContact'.
Extracting triggers of table 'AWBuildVersion'.
Extracting triggers of table 'DatabaseLog'.
Extracting triggers of table 'ErrorLog'.
Extracting triggers of table 'HumanResources.Department'.
Extracting triggers of table 'HumanResources.Employee'.
Extracting triggers of table 'HumanResources.EmployeeAddress'.
..........
Extracting triggers of table 'Sales.StoreContact'.
Extracting columns of view 'vEmployee'.
Extracting columns of view 'vEmployeeDepartment'.
Extracting columns of view 'vEmployeeDepartmentHistory'.
Extracting columns of view 'vJobCandidate'.
..........
Extracting columns of view 'vStoreWithDemographics'.
Extracting code 'ufnGetContactInformation'.
Extracting code 'ufnGetProductListPrice'.
Visio is checking the reverse engineered model ...
..........
Fixing up the diagram ...
-----------------------------------------------User defined Datatypes reverse engineered : 6; Time taken (in secs) : 0.04
Tables reverse engineered : 70; Time taken (in secs) : 52.21
Check Clauses Reverse Engineered : 0; Time Taken (in secs) : 11.14
Primary Keys reverse engineered : 70; Time taken (in secs) : 0.78
Foreign Keys reverse engineered : 92; Time taken (in secs) : 18.47
Indexes reverse engineered : 89; Time taken (in secs) : 9.66
Triggers reverse engineered : 1; Time taken (in secs): 1.86
Views Reverse Engineered : 17; Time Taken (in secs) : 0.04
Procedures reverse engineered : 2; Time taken (in secs): 6.43
Total elapsed time(in secs): 556.22
11. Toate informaiile referitoare la tipurile de fapte i tipurile de obiecte sunt afiate n fereastra
Business Rules. Se poate crea o diagram conceptual a datelor alese prin tragerea faptelor
din fereastra Business Rules n pagina Drawing.
Fig. 4.8. Tragerea unui tip de fapt pentru vizualizarea acestuia

12. Dup tragerea tipurilor de obiecte din fereastra Business Rules pe diagram, pentru
vizualizarea relaiilor se apas butonul drept al mouse-ului pe tipul de obiect i apoi click pe
Show Relationships.
Fig. 4.9. Alegerea opiunii pentru vizualizarea tuturor relaiilor

tipului de obiect entitate CreditCard
Fig. 4.10. Afiarea tuturor relaiilor

tipului de obiect entitate CreditCard
3. Importul i redefinirea unui model existent
1.
2.
3.
4.
5.
Din meniul File, se alege opiunea New, apoi Database, i click pe ORM Source Model.
n meniul Database, se alege opiunea Import/Export, i apoi click pe Import
VisioModeler .IMO file.
Se tasteaz folder-ul i numele fiierului pentru modelul care se dorete a fi important, sau
click pe butonul Browse pentru a localiza fiierul model, i apoi click pe Open.
Click OK n cutia de dialog Import.
Visio import fiierul i afieaz modul de procesare n fereastra Output.
10
Fig. 4.11. Afiarea rezultatelor

6.
n fereastra Business Rules, se selecteaz tipurile de faptele care se doresc a fi vizualizate, i

apoi se trag n pagina Drawing.
Fig. 4.12. Afiarea unor tipuri de fapte

Odat pornit proiectarea unui model surs ORM, ncepe adevrata munc de rafinare (mbuntire) a
acestuia. De exemplu, se pot edita fapte i constrngeri n model, i se pot aduga unele noi. Pentru
mbuntirea modelului surs ORM, se urmeaz aceeai pai utilizai pentru a crea un model surs
ORM pornind de la zero.
n momentul n care se consider c modelul surs ORM este satisfctor pentru problema supus
analizei, acesta poate fi adugat la un proiect nou sau la unul existent.
11
5. Generarea unui model surs ORM

n capitolul precedent s-au artat modalitile n care se poate utiliza acest produs pentru generarea
unui model surs ORM. n continuare se va prezenta prima modalitate de generare a unui model ORM
pornind de la zero, deci neavnd nici o informaie modelat cu ajutorul calculatorului.
Pentru a genera un nou model ORM se va selecta: Database | ORM Source Model.
Fig. 5.1. Alegerea unui model ORM Source Model (US units)
Exist dou variante i anume ORM Source Model i ORM Source Model (US units). Diferena
dintre cele dou variante se refer la dimensiunea paginii i unitatea de msur utilizat. Deci, pentru
prima variant se va utiliza formatul A4 i sistemul metric, iar pentru a doua variant se va utiliza
formatul Letter i unitatea de msur inches. Dup alegerea tipului de model ORM pe ecran apare
fereastra din figura 5.2.
Fig. 5.2. Fereastra iniial pentru proiectarea unui model ORM

Generarea modelului surs ORM
12
Aceast fereastr va avea o pagin de instrumente ORM (ORM stencil), o fereastr pentru desenarea
modelului (Drawing window), i o suprafa pentru afiarea editorului Business Rules i a Database
Properties, celelalte ferestre necesare elaborrii modelului pot fi deschise ulterior n funcie de
necesiti.
O reprezentare ORM poate deveni destul de complex dac baza de date va avea un numr mare de
entiti, de aceea se pot utiliza mai multe modele ORM surs pentru o singur baz de date. Fiecare
dintre aceste modele va descrie o parte din baza de date. [Raicu, 2001]
Exist la dispoziia utilizatorului opiuni de editare a proprietilor obiectelor i rolurilor, de
configurare a regulilor de afaceri, a constrngerilor i rolurilor coninute n predicate.
Astfel un model ORM permite reprezentarea obiectelor i a rolurilor ntr-un mod intuitiv i relativ uor
de neles i pentru persoanele care nu au cunotine n acest domeniu.
Un termen destul de utilizat pe parcursul acestei cri este cel de universul discursului (UD) prin care
se nelege un model de date extern pentru reprezentarea vederii fiecrui utilizator asupra organizaiei
(problemei supus analizei).
5.1. Introducerea regulilor de afaceri

Se pot aduga tipuri de propoziii la un model ORM prin aducerea formelor Object Type i Predicate
din fereastra Stencil n fereastra Drawing. O alt alternativ, care va fi explicat n continuare, este
utilizarea Editorului de Fapte (Fact Editor). Acesta se gsete n pagina Business Rules. Pentru a
activa Editorul de Fapte exist mai multe modaliti:
Dublu clic pe rndul pentru care se dorete executarea operaiei, sau pentru adugarea unui
nou fapt dublu clic pe ultimul rnd din Editorul de Fapte.
Se apas tasta F2.
Se alege Database | View | Fact Editor.

nainte de a trece la modalitatea n care se pot scrie regulile de afaceri necesare aplicaiei, este
necesar cunoaterea unor concepte utilizate, cum ar fi:
Modelul este alctuit din tipurile de obiecte i relaiile care exist ntre ele. Tipurile de obiecte sunt
de trei feluri: entiti, valori i externe. Deci vor exista: tip obiect entitate, tip obiect valoare i tip
obiect extern, pentru care se va utiliza obiect entitate, obiect valoare i obiect extern. Relaiile sunt
exprimate prin intermediul predicatelor (cte unul pentru fiecare rol, deci pot exista unul sau mai
multe).
Pentru a exprima o regul de afaceri se utilizeaz tipuri de propoziii, care sunt editate prin
intermediul Editorului de Fapte. Tipurile de propoziii sunt:
Tipuri de fapte (fact types). Prin intermediul acestui tip de propoziie sunt identificate
relaiile care se stabilesc ntre unul sau mai multe tipuri de obiecte entitate (sau tipuri de
obiecte entitate i tipuri de obiecte valoare) existente n cadrul unei reguli de afaceri.
Tipuri de referin (reference types). Prin intermediul acestui tip de propoziie sunt
identificate relaiile care se stabilesc ntre unul sau mai multe tipuri de obiecte entitate i
tipuri de obiecte valoare existente n cadrul unei reguli de afaceri.
Pentru a exprima regulile de afaceri ntr-un model ORM, un fapt este descris (exprimat) printr-un tip
de obiect i un predicat.
Fereastra Editorul de Fapte este reprezentat n figura 5.3.
13
Dup cum se observ, Editorul de Fapte are mai multe pagini (Fact, Object, Examples, Constraints,
i Advanced), fiecare din acestea avnd un anumit rol n introducerea regulilor de afaceri care se
doresc a fi modelate prin intermediul unui model ORM.
Fig. 5.3. Editorul de Fapte utilizat pentru introducerea

regulilor de afaceri
Pagina FACT n figura 5.3. este ilustrat modul n care este introdus un tip de fapt, care face parte
dintr-o regul de afaceri, i care este exprimat de propoziia Factura este intocmita pe baza
Contract, n care tipurile de obiecte sunt Factura i Contract, iar relaiile dintre obiecte sunt
exprimate prin predicatul este intocmita pe baza. Propoziia care exprim regula de afaceri este
introdus folosind pagina Fact. Rolul acestei pagini este de a permite introducerea tipurilor de fapte
care exprim regulile de afaceri ce se doresc a fi modelate. Alte exemple de tipuri de fapte care pot fi
introduse:
[Factura] are [Serie_Fact]

[Factura] este emisa la [Data_Fact]
Pagina Object Pagina Object permite clasificarea tipurilor de obiecte care apar n Editorul de
Fapte n urmtoarele tipuri:
entitate (entity);
valoare (value);
obiect extern (external).
Fig. 5.4. Utilizarea tipului obiect de tip entitate

n cazul unui obiect entitate cu o schem de identificare simpl (figura 5.5.), acestuia i se poate aduga
modul de referin la acea entitate (de exemplu, Nr_Fact pentru obiectul entitate Factura i Nr_Contr
pentru obiectul entitate Contract).
14
Fig. 5.5. Declararea modului de identificare

pentru un obiect entitate
Dup efectuarea acestei operaii pagina Fact va avea aspectul din figura urmtoare.
Fig. 5.6. Identificarea obiectelor entitate

Pentru introducerea tipurilor de fapte se pot utiliza dou stiluri de introducere a acestora, i anume:
Freeform i Guided. Astfel, n figura 5.3. este utilizat stilul Guided, iar relaia stabilit ntre cele
dou obiecte entitate, Factura i Contract, este o relaie binar. Se poate scrie o relaie binar
(binary relationship), utiliznd att o citire direct (nainte) (de exemplu, Factura este intocmita pe
baza Contract) ct i o citire invers (de exemplu, Contract sta la baza intocmirii Factura). Dac
este necesar, operanzii (numrul de argumente) din relaie pot fi modificai prin alegerea unei setri
diferite pentru stilul Guided. Alternativele sunt: Unary, Ternary i Quaternary.
Alt stil de declarare a tipurilor de fapte este Freeform care permite introducerea acestora mult mai
rapid prin utilizarea unei sintaxe formale. Pentru alegerea stilului Freeform exist urmtoarele
opiuni:
Selectarea butonului radio Freeform, din pagina Fact a Editorului de Fapte.
Dac se dorete declararea stilul Freeform drept stil implicit pentru modelele ORM:
Database | Options | Modeling i se alege Fact Editor.
Indiferent de limbajul utilizat pentru declararea obiectelor este indicat s se nceap numele obiectului
cu liter mare, presupunnd c acesta este format dintr-un singur cuvnt (de exemplu, Factura,
Furnizor, Nr_Fact, Cod_Unic etc.).
n cazul n care pentru definirea obiectului se utilizeaz mai multe cuvinte separate prin spaiu este
indicat utilizarea parantezelor ptrate (de exmplu, [Factura], [Data_Fact], [Val_marfa]).
15
De exemplu, fereastra pentru alegerea stilului implicit Freeform pentru Editorul de Fapte este
ilustrat n figura 5.7.
Fig. 5.7. Declararea tipului Freeform drept stil

implicit pentru Editorul de Fapte
Astfel dup alegerea stilului Freeform pagina Fact va avea urmtorul aspect.
Fig. 5.8. Utilizarea stilului Freeform

pentru Editorul de Fapte
Se observ c prin utilizarea acestui stil, modul de identificare (referin) apare n interiorul
parantezelor rotunde dup numele obiectului. Dac exist i o citire n sens invers se va utiliza un slash
(/) pentru a separa cele dou tipuri de citiri (direct i invers). Dac pentru un obiect entitate a fost
definit o schem de referin aceasta nu mai este necesar s fie repetat pentru celelalte tipuri de fapte
care vor fi definite mai trziu. Spre deosebire de obiectele entitate, obiectele valoare (de exemplu,
Data_Fact, Nr_Fact, Cod_Unic etc.) nu au o schem de referin deoarece instanele lor sunt
constante literale (ir de caractere sau numere utilizate pentru a numi sau exprima entiti), deci ele se
autoidentific. n modul Freeform, obiectul valoare este indicat prin adugarea de paranteze ().
Dup introducerea tuturor tipurilor de fapte (se utilizeaz butonul Apply dup fiecare tip de fapt
introdus, i dup ultimul se apas butonul Ok din Editorul de Fapte) n pagina Fact Types apar toate
tipurile de fapte introduse i care pot fi modificate prin simpla selectare a faptului dorit a fi modificat
(figura 5.9.). n cazul selectrii unui tip de fapt apare butonul Edit..., care va permite editarea tipului
de fapt ales pentru a putea fi modificat, sau pentru a i se putea aduga i celelalte caracteristici:
constrngeri etc.
16
Fig. 5.9. Tipurile de fapte sunt listate n pagina Business Rules,

i pot fi editate
Dup introducerea tipurilor de fapte este indicat s se introduc constrngerile corespunztoare
tipurilor de fapte respective i care exprim restriciile impuse asupra regulilor de afaceri ce se doresc
a fi modelate. Tipurile cele mai utilizate, precum i modalitatea de folosire a acestora sunt explicate
ntr-un capitol separat.
5.2. Adugarea de exemple la

tipurile de fapte
Pentru fiecare tip de fapt este indicat s se includ exemple. Pentru adugarea de exemple la un tip de
fapt existent n Editorul de Fapte, se va selecta pagina Examples unde se vor putea introduce ct mai
multe exemple pentru ilustrarea tipului de fapt ales, i n special pentru verificarea corectitudini
constrngerilor impuse n cadrul tipului de fapt.
De exemplu, figura 5.10. ilustreaz trei instane de fapte pentru tipul de fapt Factura(Nr_Fact) este
emisa la Data_Fact. Astfel facturile FX 123 i FX 23555 sunt emise la aceeai dat, i anume
21.02.2004, iar factura FB 1888 este emis n 22.02.2004. Deci fiecare factur este emis la o singur
dat (prima coloana are o valoare unic), dar la aceeai dat pot fi emise mai multe facturi.
Fig. 5.10. Adugarea de exemple la un tip de fapt

Pentru verificarea corectitudinii constrngerilor impuse din exemplele existente, sau pentru verificarea
inconsistenelor dintre date i constrngeri se va apsa butonul Analyze.... n cazul n care nu exist
nici o eroare pe ecran va apare o fereastr de tipul artat n figura 5.11.
17
Fig. 5.11. Exemplele introduse nu au erori

Se introduce urmtoarea instan: Factura FX 123 este emis la data 22.02.2004. Atunci cnd se apas
butonul Analyze..., pe ecran va apare o fereastr de genul artat de figura 5.12. Eroarea a aprut
deoarece aceeai factur nu poate fi emis dect la o singura dat.
Fig. 5.12. Erorile semnalate n cazul introducerii unei

instane care nu respect constrngerile impuse
5.3. Salvarea unui model

Pentru a salva un model din meniul File se alege opiunea Save (File | Save). Extensia unui model este
.vsd (Visio Document).
Fig. 5.13. Salvarea unui model ORM
18
5.4. Afiarea tipurilor de fapte

n fereastra Drawing
Pentru afiarea grafic a tipurilor de fapte introduse cu ajutorul Editorului de Fapte, instrumentul
pune la dispoziie mai multe modaliti. Astfel, din editorul Business Rules, pagina Fact Types se vor
selecta toate tipurile de fapte pentru care se dorete reprezentarea grafic. Pentru a selecta un numr de
tipuri de fapte continue, dup ce se selecteaz primul tip de fapt se apas tasta Shift, pn se alege
ultimul tip de fapt, iar apoi se trag tipurile de fapte selectate n fereastra Drawing. n acest moment va
apare modelul care a fost descris ntr-un limbaj natural (figura 5.14.).
Fig. 5.14. Selectarea i aducerea tipurilor de fapte

n fereastra Drawing
O alt alternativ: se deschide pagina Object Types din editorul Business Rules. Din aceast pagin
se trage unul sau mai multe tipuri de obiecte (acele obiecte pentru care se dorete reprezentarea grafic
a modelului) n fereastra Drawing (figura 5.15.). n continuare pentru a evidenia relaiile care exist
ntre un obiect i celelalte obiecte, se selecteaz obiectul i se va utiliza opiunea Show Relationships
din meniul de tip popup care apare atunci cnd se apas butonul drept al mouse-ului (figura 5.16.). n
acest moment n fereastra Drawing sunt evideniate toate relaiile care au fost descrise ntr-un limbaj
natural utiliznd Editorul de Fapte (figura 5.17.).
Fig. 5.15. Utilizarea celei de-a doua alternative
19
Opiunea Show Relationships este foarte utilizat n proiectarea schemei i n special atunci cnd se
utilizeaz procedeul reverse engineering.
Fig. 5.16. Utilizarea opiunii Show Relationships
Fig. 5.17. Evidenierea relaiilor existente ntre obiecte
20
6. Constrngeri ORM
Reamintim c n ORM principale elementele ale unui model sunt: tipurile de obiecte i relaiile.
De asemenea, n ORM, relaiile dintre obiectele entitate (numite i tipuri de fapte), i relaiile dintre
obiectele entitate i obiectele valoare (numite i tipuri de referin) sunt reprezentate prin predicate
care conin unul sau mai multe roluri.
Predicatele sunt reprezentate grafic ca o secven de una sau mai multe casete de roluri. ablonul de
desen (stencil) pentru diagrame ORM din Microsoft Visio include cinci forme (shape) de predicate
(Unary, Binary, Vertical Binary, Ternary, i Quaternary), care vor avea un numr diferit de csue
de roluri (una, dou etc.). Forma de predicat utilizat depinde de numrul de roluri.
Relaiile binare indic o relaie ntre dou obiecte, i sunt cele mai utilizate. n general, forma de
predicat Binary este utilizat pentru a indica o relaie a rolurilor ntre un obiect entitate i un obiect
valoare.
Fig. 6.1. Relaia dintre un obiect entitate

i un obiect valoare
iar forma de predicat Ternary se va utiliza pentru a indica relaii care implic existena a trei obiecte
entitate .a.m.d.
Fig. 6.2. Relaia ternar ntre trei tipuri de obiecte entitate

Dup introducerea tuturor tipurilor de fapte, care descriu regulile de afaceri pentru care se dorete
modelarea datelor, pasul urmtorul const n introducerea constrngerilor asupra fiecrui tip de fapt
introdus, sau a mai multor tipuri de fapte.
Constrngerile provin din rspunsurile la ntrebrile puse ntr-un limbaj natural, i ele sunt utilizate
pentru a surprinde (capta) nelesurile suplimentare n interiorul i ntre tipurile de fapte existente n
modelul conceptual.
Aceste constrngeri trebuie gndite ca nite reguli care vor fi aplicate tipurilor de fapte din modelul
conceptual cu scopul de a restriciona datele care vor putea fi folosite n baza de date. Dup aplicarea
constrngerilor asupra tipurilor de fapte, acestea pot fi analizate i validate prin introducerea unor
exemple de date prin intermediul Editorului de Fapte.
6.1. Tipuri de constrngeri ORM

n funcie de numrul de predicate care intr n alctuirea constrngerii, acestea se clasific n
urmtoarele dou tipuri:
1. Constrngeri interne caz n care constrngerea este aplicat asupra unui singur predicat (n
acest caz constrngerea acioneaz asupra unui singur tip de fapt).
Constrngeri ORM
21
2.
Constrngeri externe caz n care constrngerea este aplicat la dou sau mai multe
predicate (n aceast situaie constrngerea este aplicat la cel puin dou tipuri de fapte, care
partajeaz acelai tip de obiect).
ntr-un model ORM pot fi utilizate urmtoarele tipuri de constrngeri:
1. Constrngeri de unicitate:
a. interne
b. externe
c. primare
2. Constrngeri obligatorii:
a. simple
b. disjunctive
3. Constrngeri circulare:
a. aciclice
b. asimetrice
c. antisimetrice
d. intranzitive
e. nereflexive
f. simetrice
4. Constrngeri comparare de mulimi:
a. submulime
b. de egalitate
c. de excludere
5. Alte tipuri de constrngeri:
a. de frecven
b. index
c. de valoare
Pentru declararea constrngerilor se pot utiliza mai multe metode. Astfel prin intermediul paginii
Constraints, a Editorului de Fapte se pot introduce constrngeri de tip intern cum ar fi:
Constrngeri de unicitate intern (internal uniqueness).
Constrngeri obligatorii simple (simple mandatory).
Constrngeri de frecven interne (internal frequency).
Constrngeri circulare (ring).

dar nu se pot introduce constrngeri (care vor fi introduse prin alte metode), cum ar fi:
Constrngeri comparare de mulimi ( set-comparation constraints), de exemplu o

constrngere de excludere ntre dou roluri ale aceluiai predicat.
Constrngeri externe (external constraints).
Constrngeri de valoare (value constraints), de exemplu restricionarea valorilor unui atribut

(atributul CodSex nu poate lua dect valorile {M, F}.
Constrngerile implicite care pot fi declarate prin intermediul Editorului de Fapte sunt:
Constrngeri de unicitate interne simple simple internal uniqueness.
Constrngeri obligatorii simple simple mandatory.

Simbolurile utilizate pentru vizualizarea constrngerilor, precum i exprimarea acestora sunt afiate
automat pentru a se putea vedea rezultatul operaiei executate.
De exemplu, pentru declararea unei constrngeri la un tip de fapt introdus, se va alege din Editorul de
Fapte pagina de declarare a constrngerilor, Constraints. Implicit suprafaa acestei ferestre reprezint
o combinaie a unei constrngeri de unicitate interne i a unei constrngeri obligatorie simpl.
Constrngeri ORM
22
Fig. 6.3. Adugarea unei constrngeri

prin intermediul Editorului de Fapte
De exemplu, la ntrebarea Each Factura este emisa la haw many Data_Fact? se va alege varianta
Exactly One care are semnificaia de cel puin unul (constrngere obligatorie) i cel mult unul
(constrngere de unicitate).
Dac nu se dorete utilizarea implicit a acestor tipuri de constrngeri (de unicitate i obligativitate), se
va utiliza fereastra de dialog Database Modeling Preferences, n care se va deselecta opiunea Use
combined uniqueness and mandatory (UM) quentions for binary facts (permite utilizarea
constrngerilor combinate de unicitate i obligativitate), care poate fi vizualizat prin Database |
Options | Modeling.(figura 6.4).
Dup adugarea constrngerii, pagina Constraints va avea aspectul din figura 6.5.
Fig. 6.4. Selectarea opiunii permite

folosirea celor dou tipuri de constrngeri
Constrngeri ORM
23
Fig. 6.5. Introducerea constrngerii

n continuare vor fi explicate cele mai utilizate tipuri de constrngeri care pot fi utilizate n cadrul unul
model surs (conceptual) ORM.
6.2. Constrngeri de unicitate

(uniqueness constraints)
ntr-un model conceptual cele mai utilizate constrngeri sunt cele de unicitate. Constrngerile de
unicitate sunt utilizate pentru a indica c un rol dintr-un predicat, sau mai multe roluri dintr-o
combinaii de predicate nu poate conine valori duplicate (valoarea acestuia trebuie s fie unic), sau
altfel spus constrngerile de unicitate specific faptul c valorile trebuie s fie unice i c obiectul nu
este opional.
Din punct de vedere grafic, o constrngere de unicitate este reprezentat de o sgeat cu capete duble,
plasat deasupra, sau dedesubtul csuelor de rol pe formele predicatului (Binary, Vertical Binary,
Ternary, i Quaternary). Constrngerile de unicitate sunt de dou tipuri:
A Constrngere de unicitate intern
(internal uniqueness constraint)
B Constrngere de unicitate extern

(external uniqueness constraint)
Fig. 6.6. Tipuri de constrngeri de unicitate

De exemplu, n figura 6.7., A reprezint o constrngere de unicitate intern, care indic faptul c
fiecare factur (obiectul entitate Factura) poate avea cel mult o serie (obiectul valoare Serie_Fact),
iar B reprezint o constrngere obligatorie, care indic faptul c fiecare factur trebuie obligatoriu s
aib o serie.
Fig. 6.7. Constrngere de unicitate (A) i obligatorie (B)

Astfel, dac tipul de fapt este binar (exist o relaie binar ntre cele dou obiecte) vor exista
urmtoarele opiuni:
Constrngeri ORM
24
zero or one, se va crea o constrngere de unicitate intern;

zero or more, nu se va crea nici o constrngere de unicitate;
exactly one, se va crea o constrngere obligatorie i de unicitate intern;
one or more, se creeaz o constrngere obligatorie.
Pentru tipurile de fapte: Ternary sau Quaternary vor exista urmtoarele opiuni:
Check all role combinations wich are unique (toggle using space bar) , se va alege (din
mulimea combinaiilor posibile, i care sunt afiate pe ecran) combinaia de date care se
dorete a avea o valoare unic, i apoi se va apsa bara de spaiu pentru a se atribui aceast
valoare;
Make Primary, se va specifica dac combinaie datelor va fi declarat drept cheie primar.
6.2.1. Constrngeri de unicitate interne

(internal uniqueness)
O constrngere de unicitate intern (cunoscut i drept o constrngere de unicitate n cadrul
predicatului intrapredicate uniqueness constraint) este utilizat asupra unuia sau mai multor
roluri (ale unui predicat) ntr-un tip de fapt dat, atunci cnd se dorete ca fiecare instan a datelor din
interiorul rolului, sau combinaia de roluri, s fie unic.
Fig. 6.8. Declararea unei constrngeri de unicitate intern

Aceast constrngere de unicitate intern semnific faptul c fiecare instan a obiectului entitate
Persoana este unic n populaia obiectului entitate Localitate (fiecare persoan nu poate avea adresa
dect ntr-o singur localitate) i c mai multe instane ale obiectului entitate Persoana pot face parte
din aceeai instan a obiectului entitate Localitate (n aceeai localitate pot avea adresa mai multe
persoane). Fiecare instan a obiectului Persoana este unic n populaia acestui tip de fapt.
De asemenea, o constrngere de unicitate intern se poate aplica tuturor rolurilor dintr-un tip de fapt,
ceea ce nseamn c fiecare instan a tipului de fapt complet este unic.
O constrngere de unicitate poate fi aplicat oricrui tip de fapt binar, ternar, cvaternat, sau n-ternar.
Fiecare constrngere de unicitate trebuie s fie aplicat pe cel puin n-1 roluri, unde n este numrul
rolurilor din cadrul predicatului care descrie tipul de fapt.
6.2.2. Constrngeri de unicitate externe

(external uniqueness)
Acest tip de constrngere (numit i constrngere de unicitate ntre predicate - interpredicate
uniqueness constraint) este utilizat n cazul n care combinaia dintre dou sau mai multe roluri, care
partajeaz acelai obiect, este unic, sau altfel spus ea este aplicat la dou sau mai multe roluri care
fac parte din tipuri de fapte diferite, dar care partajeaz acelai obiect. n momentul n care modelul
conceptual este transpus ntr-un model logic, pentru aceste roluri care sunt incluse ntr-o constrngere
de unicitate extern, se va crea un index unic. O astfel de constrngere se va utiliza n cazul n care se
dorete stabilirea unei metode alternative pentru identificarea unic a obiectului.
Constrngeri ORM
25
Fig. 6.9. Alegerea opiunii Add Constraints...,

utilizat pentru declararea celorlalte tipuri de constrngeri
n general constrngerile externe, numite i constrngeri bazate pe rol role-based constraint, sunt
declarate prin selectarea predicatelor relevante din fereastra Drawing, apoi se va utiliza fereastra de
dialog Add Constraint (aceasta poate fi activat fie prin Database | Add Constraint, sau prin
activarea meniului de tip popup, din care se va selecta opiunea Add Constraints...) pentru a se
aduga constrngerea dorit.
De exemplu, s presupunem c aplicaia pe care dorim s o implementm va ine evidena tuturor
abonailor unei firme de servicii Internet. Fiecare abonat are un act de identitate unic, care este
identificat prin seria i numrul acestuia.
Pentru a se specifica acest lucru ntr-un model surs ORM, se va utiliza o constrngere de unicitate
extern asupra rolurilor jucate de obiectele valoare Seria_Act_Identitate i Nr_Act_Identitate.
Fig. 6.10. Declararea unei constrngeri de unicitate externe

Reprezentarea grafic a constrngeri declarate mai sus este:
Fig. 6.11. Reprezentarea grafic a unei

constrngeri de unicitate extern
Constrngeri ORM
26
6.2.3. Constrngeri de unicitate primare

(primary uniqueness)
O constrngere de unicitate primar (cunoscut i drept constrngere de referin primar primary
reference constraint) reprezint o constrngere de unicitate care este desemnat drept referin
primar n cazul n care un obiect este identificat prin dou sau mai multe constrngeri de unicitate. Se
va utiliza o constrngere de unicitate primar n cazul n care se dorete s se indice faptul c un obiect
este identificat prin rolul (rolurile) cuprins(e) prin aceast constrngere de unicitate. Constrngerea de
unicitate primar este utilizat pentru de terminarea modalitii n care se aplic constrngerea de
unicitate intern i obligatorie la tipul de fapt, sau la tipurile de fapte respective. i aceste tipuri de
constrngeri sunt de dou tipuri:
A Constrngere de unicitate primar
intern (primary internal uniqueness
constraint)
B Constrngere de unicitate primar

extern (primary external uniqueness
constraint)
Fig. 6.12. Constrngeri de unicitate primare

Constrngerile de unicitate primare interne (notate pe diagram cu litera P) sunt declarate
utiliznd Editorul de Fapte.

Constrngerile de unicitate primare externe, se declar utiliznd cutia de dialog Add Constraint.
Dup apariia ferestrei Add Constraint, se va alege tipul constrngerii Uniqueness, se va bifa csua
Primary, pentru a indica c aceast constrngere furnizeaz schema de referin primar pentru
obiectul entitate, i apoi se vor selecta predicatele relevante pentru constrngere. Dac constrngerea
de unicitate extern nu este utilizat pentru a declara o referin primar, atunci nu se va bifa csua
Primary.
De exemplu, obiectul entitate Act_Aditional poate fi identificat n mod unic prin numrul actului
adiional (obiectul valoare Nr_Act_Aditional), i numrul contractului cruia i aparine (obiectul
entitate Contract(Nr_Contr)). Putem desemna drept referin primar pentru obiectul Act_Aditional
concatenarea valorilor celor dou obiecte.
Fig. 6.13. Declararea unei constrngeri de unicitate externe primare

Constrngeri ORM
27
Dac se va apsa butonul Ok, atunci fereastra de dialog se va nchide i constrngerea va apare n
fereastra Drawing. Dac se dorete aplicarea i altor constrngeri asupra unuia sau mai multor din
aceste predicate, se va apsa butonul Apply.
Fig. 6.14. Reprezentarea grafic a unei constrngeri

de unicitate externe primare
6.3. Constrngeri obligatorii

(mandatory constraints)
n cazul n care un rol dintr-un predicat este obligatoriu, fiecare instan din populaia obiectului curent
trebuie s ndeplineasc obligatoriu rolul respectiv. Atunci cnd se va executa transpunerea ntr-o baz
de date a modelului, fiecare instan a obiectului va trebui s aib obligatoriu o valoare, deci nu vor fi
permise valori null pentru relaia dat.
Constrngerile obligatorii i de unicitate sunt aplicate n mod automat atunci cnd se creeaz un nou
tip de fapt. Exprimarea (verbalizarea) celor dou tipuri de constrngeri corespunztoare tipurilor de
fapte din figura 6.14. este:
Constrngeri de unicitate:
Each Act_Aditional apartine unui at most one Contract.
Each Act_Aditional este identificat partial de at most one Nr_Act_Aditional.
Constrngeri obligatorii:
Each Act_Aditional apartine unui some Contract.
Each Act_Aditional este identificat partial de some Nr_Act_Aditional.
Constngere obligatorie simpl (simple madatory)
Pentru a arta c fiecare instan a populaiei unui obiect trebuie s ndeplineasc un rol particular, se
va aplica o constrngere obligatorie pentru acel rol.
Fig. 6.15. Constrngeri obligatorii simple

De exemplu, regula de afaceri Fiecare factur trebuie s fie identificat prin seria facturii se
poate exprima prin tipul de fapt Factura are Serie_Fact, iar pentru a impune regula c fiecare
obiect entitate Factura trebuie s aib un obiect valoare Serie_Fact, va trebui s aplicm o
constrngere obligatorie simpl intern, de exemplu:
Constrngeri ORM
28
Fig. 6.16. Reprezentarea grafic a unei

constrngeri obligatorie simple intern
Constngere obligatorie disjunctiv (disjunctive madatory)
Se spune c disjuncia rolurilor este obligatorie dac dou sau mai multe roluri din tipuri de fapte
diferite sunt partajate obligatoriu de acelai obiect. Cu alte cuvinte, fiecare instan din populaia
obiectului la care sunt conectate rolurile din constrngere trebuie s ndeplineasc cel puin unul din
rolurile din constrngere (cel puin unul din rolurile din constrngere trebuie s se ndeplineasc)
Acest tip de constrngere se mai numete i constrngere disjunctiv de includere (inclusive or).
Notaia (reprezentarea grafic) a disjunciei rolurilor este ilustrat n figura urmtoare.
Fig. 6.17. Constrngere obligatorie disjunctiv

De exemplu, pentru a impune regula de afaceri Fiecare factur trebuie s aib o valoare n lei, sau
o valoare n dolari, sau pe amndou se va aplica asupra celor dou roluri o constrngere obligatorie
disjunctiv.
Presupunnd c avem dou tipuri de fapte Factura are Val_Fact_Lei i Factura are
Val_Fact_Dolari aceast constrngere se va introduce prin intermediul ferestrei Add Constraint,
unde pentru tipul constrngerii se va alege varianta Mandatory. Reprezentarea grafic a acestei
constrngeri este ilustrat n figura de mai jos.
Fig. 6.18. Constrngere obligatorie disjunctiv
6.4. Constrngeri circulare

(ring constraints)
Pentru a explica necesitatea acestor constrngeri, precum i modul n care ele sunt utilizate vom ncepe
cu un exemplu. Astfel, pentru tipul de fapt Persoana este parinte pt. Persoana cele dou roluri ale
predicatului este parinte pt. sunt ndeplinite de acelai obiect entitate, Persoana. Astfel tipul de fapt
de mai sus necesit aplicarea unei constrngeri suplimentare, numit constrngere circular.
Constrngeri ORM
29
Fig. 6.19. Asociaia este parinte pt. reprezint

un tip de fapt circular
Constrngerea circular specific faptul c o pereche de roluri sunt conectate la acelai obiect.
Deoarece parcursul tipului de fapt pleac de la obiect prin rolurile pereche i se ntoarce la acelai
obiect se formeaz un cerc, i din acest motiv, se spune c avem un tip de fapt circular. Acest lucru
este valabil i n situaia n care rolurile sunt ndeplinite de subtipuri care au un acelai supertip.
Deoarece amndou roluri sunt ndeplinite de acelai obiect, este important s existe posibilitatea
comparrii instanelor populaiilor lor, iar despre cele dou roluri se spune c sunt compatibile. Din
acest motiv, n practic cele mai multe tipuri de fapte circulare necesit constrngeri suplimentare
pentru a arta modul n care instanele rolurilor sale pot fi legate din punct de vedere logic. Astfel de
constrngeri sunt numite constrngeri circulare.
Reprezentarea grafic a unei constrngeri circulare se face prin plasarea unui cerc deasupra rolurilor,
. Pentru fiecare tip de constrngere circular se va aduga o abreviere format din dou litere lng
simbol pentru a indica tipul constrngeri circulare. Astfel, constrngerea circular care se poate aplica
tipului de fapt de mai sus este numit constrngere circular nereflexiv (irreflexive), i ea este
indicat prin simbolul (abrevierea) ir alturi de cele dou roluri implicate n constrngere, dup
cum se observ n figura 6.20.
Fig. 6.20. Constrngere circular nereflexiv

Pentru adugarea unei constrngeri circulare, prima dat se va selecta predicatul cu rolurile aferente
asupra cruia se dorete impunerea unei constrngeri circulare; apoi se va apela fereastra de dialog
Add Constraint. Primul pas const n alegerea tipului de constrngere circular (se va selecta tipul
Ring, din lista derulant Constraint type). n continuare se vor selecta cele dou roluri ale predicatului
(figura 6.21.).
Se observ c dup selectarea celor dou roluri, apare fereastra de dialog Ring Constraint Properties.
Alegerea tipului constrngerii circulare se poate face fie prin selectarea din lista derulant Ring Type a
tipului, sau prin poziionarea cursorului pe elipsa care marcheaz constrngerea circular care se
dorete a fi aplicat rolurilor (figura 6.22.).
Constrngeri ORM
30
Fig. 6.21. Adugarea unei constrngeri circulare

utiliznd fereastra de dialog Add Constraint
Fig. 6.22. Alegerea tipului constrngerii circulare nereflexive

Dup apsarea butonului OK, n fereastra de dialog Add Constraint constrngerea este verbalizat,
dup cum se observ n figura 6.23.
Fig. 6.23. Verbalizarea constrngerii circulare nereflexive

O constrngere circular poate fi aplicat numai unei perechi de roluri din cadrul unui predicat, unde
rolurile sunt ndeplinite de acelai obiect (sau unul compatibil). Rolurile pereche pot face parte dintrun predicat binar sau dintr-un predicat cu mai multe roluri.
S spunem c R este predicatul relaiei care include cele dou roluri pereche, r1 i r2.
Pentru fiecare stare a bazei de date, mulimea (populaia) ( r1, r2), notat cu pop(r1, r2),
este un set al perechilor ordonate, i deci, a tipului R. [Halpin5] Se va utiliza notaia
xRy pentru a defini diferite proprieti ale relaiei cum ar fi reflexivitatea, simetria i
tranzitivitatea. De asemenea, se va utiliza iff pentru dac i numai dac, ~
Constrngeri ORM
31
pentru nu, & pentru i iar pentru implic pentru a defini cele ase tipuri de constngeri
circulare.
De asemenea, se va utiliza pentru exemplificare un model de date extern (acest model este utilizat n
special pentru a reprezenta vederea fiecrui utilizator) format din obiectul entitate Persoana. Vom
spune c relaia R este:
1.
Reflexiv, iff xRx for each x in pop(r 1) U pop(r2), dac i numai relaia xRx exist pentru
fiecare x din cele dou populaii ale relaiei. Exemple de astfel de relaii reflexive:
(egalitatea), (mai mic sau egal), (implic) etc. Dac o relaie este reflexiv peste
populaia ntregului model de date extern se spune c este total reflexiv (deci pentru toate
valorile x exit relaia xRx). Aceat proprietate a unei relaii este ilustrat n figura 6.24. Este
aplicabil asupra mulimii formate din reuniunea populaiilor celor dou roluri. Pentru
ilustrarea acestei proprieti tipul de fapt a fost populat cu exemplele din figur.
Fig. 6.24. Relaia de reflexivitate

2.
Tranzitiv, iff for all x, y, z, xRy & yRz xRz, dac i numai dac pentru toate perechile de
date x, y, z ntre care exist relaia xRy i yRz implic i existena relaiei xRz. De menionat
faptul c n aceast situaie valorile x, y, z nu sunt necesar distincte (poate fi aceeai valoare).
Fig. 6.25. Relaie tranzitiv

Cele ase tipuri de constrngeri circulare sunt:
1. Simetric (symmetric ring), are simbolul Osym, iff for all x, y, xRy yRx, dac i numai
dac pentru toate perechile de date ( x, y) (ale celor dou roluri din cadrul unui predicat), ntre
care exist relaia xRy implic i existena relaiei yRx. Simetria este utilizat de cele mai
multe ori pentru derivaie.
Valorile x i y nu trebuie s fie neaprat distincte. Dac relaia este ndeplinit ntr-o direcie,
atunci ea este ndeplinit i n cealalt direcie.
Constrngeri ORM
32
Fig. 6.26. Constrngere circular simetric

2.
Nereflexiv (irreflexive ring), are simbolul ir, iff for all x, ~ xRx, respectiv, dac i
numai dac pentru toate datele x implic neexistena relaiei xRx.
Deci, o constrngere circular nereflexiv interzice ca o instan a unui obiect s

ndeplineasc dou roluri n aceeai instan a unei relaii. De exemplu, o persoan nu poate fi
propriul su printe (ilustrat n figura 6.27. prin constrngerea circular nereflexiv). De
asemenea, fiecare persoan nu poate s aib dect exact 2 prini (ilustrat n figura 6.27. prin
constrngerea de frecven 2). Relaia de paternitate este nereflexiv dar nu este o relaie
exclusiv. Astfel, Ana este printe pentru Rodica, dar n acelai timp este copil pentru
Cosmin.
Fig. 6.27. Constrngere circular nereflexiv

3.
Asimetric (asymmetric ring), are simbolul Oas, iff for all x, y, xRy ~ yRx. Deci o
relaie este asimetric dac i numai dac pentru toate perechile de date ( x, y), ntre care
exist relaia xRy implic neexistena relaiei yRx, Presupunnd c avem perechile de date ( x,
y), i o relaie ntre acestea R, atunci se va utiliza o constrngere circular asimetric dac i
numai dac pentru toate perechile de date ( x, y), ntre care exist relaia xRy nu va exista
niciodat relaia yRx, sau altfel spus dac exist combinaia de date ( x, y), niciodat nu va
putea exista combinaia de date (y, x).
De exemplu, obiectul entitate Persoana poate s ndeplineasc dou roluri de parinte i de
copil, dar la un moment dat nu poate ndeplini dect un singur rol, ori printe ori copil, deci
niciodat nu va putea fi propriul su printe, sau copil.

Orice relaie care este asimetric trebuie s fie nereflexiv. Deci, o constrngere circular
asimetric implic existena unei constrngeri nereflexive, i din acest motiv n figura 6.28.
constrngerea circular nereflexiv este omis.
Relaia de paternitate este asimetric, respectiv, nereflexiv, deci afirmaia fcut la
nereflexivitate este valabil i pentru relaia de asimetrie.
Constrngeri ORM
33
Orice constrngerea asimetric este o constrngere nereflexiv, dar afirmaia reciproc nu

este adevrat, deci nu toate constrngerile nereflexive sunt i asimetrice, ci numai unele. De
asemenea, o constrngere asimetric este i antisimetric. Rezult c o constrngere
asimetric se afl la intersecia celor dou tipuri de constrngeri (nereflexive i antisimetrice),
sau altfel spus (figura 6.29):
O
as = Oans ir
Fig. 6.28. Constrngere circular asimetric
Fig. 6.29. Constrngere circular asimetric

este antisimetric i nereflexiv
Fig. 6.30. Constrngere circular asimetric aplicat unui subtip

4.
Antisimetric (antisymmetric ring), are simbolul Oans, iff for all x, y, x y & xRy ~
yRx. Deci o relaie este antisimetric dac i numai dac pentru toate perechile de date ( x, y),
ntre care exist relaia x y & xRy implic neexistena relaiei yRx.
Presupunnd c avem perechile de date x i y, i o relaie ntre acestea R, atunci se va utiliza o
constrngere circular antisimetric dac i numai dac pentru toate perechile de date ( x, y),
unde x este diferit de y, i ntre care exist relaia xRy (va putea exista i relaia xRx) nu va
putea exista niciodat relaia yRx.
De exemplu, pentru tipul de fapt Persoana este profesor Persoana, se va putea aplica o
constrngere circular antisimetric.

Constrngeri ORM
34
Dup cum s-a enunat mai sus, ntre constrngerile circulare nereflexive, asimetrice i
antisimetrice exist urmtoarea relaie: as reprezint combinaia dintre ans i ir.
Fig. 6.31. Constrngere circular antisimetric

5.
Intranzitiv (intransitive ring), are simbolul Oit, iff for all x, y, z, xRy & yRz ~ xRz.
Deci, dac i numai dac pentru toate perechile de date x, y, z, ntre care exist relaia xRy &
zRy implic neexistena relaiei xRz.
Deci, se va utiliza o constrngere circular intranzitiv n cazul n care dac exist o

combinaie de date (x, y) i (y, z), niciodat nu va putea exista combinaia de date (x, z), iar
valorile x, y, z nu trebuie s fie obligatoriu distincte.
Fig. 6.32. Constrngere circular intranzitiv

6.
Aciclic (acyclic ring), are simbolul Oac, i este cea mai dificil constrngere care se poate
impune unei relaii, iff for all x, y, z, xRy & yRz ~zRx. Prin utilizarea tipului de relaie o
dat sau de mai multe ori nu sunt permise cicluri. Deci, dac i numai dac pentru toate
perechile de date x, y, z, ntre care exist relaia xRy & yRz implic neexistena relaiei zRx.
Pentru a specifica faptul c ntr-o relaie nu sunt permise bucle (reveniri) ntre populaiile
celor dou roluri se va aplica asupra acesteia o constrngere circular aciclic. Aceast
constrngere se poate aplica numai n cazul n care dac pentru toate valorile x, y, z (x y i
x z) din populaiile celor dou roluri ntre care exist relaiile xRy i yRz nu implic i
existena relaieie zRx (deci nu va exista o combinaie de date (z, x)).
De exemplu, pentru obiectul entitate Persoana presupunem c avem mulimea de valori
(Maria, Ana, Cosmin, Iulia, Maria, Ana etc.). Pentru a exemplifica faptul c Maria este
printe pentru Ana, Ana este printe pentru Cosmin, Cosmin este printe pentru Maria, va
trebui s se utilizeze o astfel de constrngere. Dac nu este impus aceast constrngere ar
rezulta c Maria este propria strbunic.
Constrngeri ORM
35
Fig. 6.33. Constrngere circular aciclic

Acestea sunt cele mai importante constrngeri circulare care pot fi utilizate ntr-un model ORM.
nainte de a trece n revist legturile care exist ntre aceste constrngeri circulare se mai fac
urmtoarele precizri.
n cazul tipurilor de fapte asupra crora sunt impuse constrngeri circulare, este indicat s se utilizeze
nume de roluri pentru a avea un control mai bun asupra numelor coloanelor care sunt generate pentru
modelul logic al bazei de date.
De exemplu, pentru a aduga numele de rol centrala pentru al doilea rol al tipului de fapt Firma
face parte din Firma, se va selecta tipul de fapt, se va deschide fereastra Database Properties, i
apoi se va alege suprafaa de fereastr Readings, unde se va introduce numele celui de-al doilea rol
(figura 6.34.).
Fig. 6.34. Adugarea numelui centrala

pentru al doilea rol a tipului de fapt Firma face parte din Firma
Numele rolului nu apare pe diagram, dar acesta se poate aduga manual prin utilizarea unui csue de
text. Dac se dorete aceasta, este
indicat ca numele rolului s fie
inclus ntre paranteze ptrate pentru
a-l putea distinge de alte nume
(figura 6.35.).
Constrngeri ORM
36
Fig. 6.35. Adugarea manual a

numelor rolurilor
ntre aceste constrngeri circulare exist relaii care pot fi utilizate pentru impunerea celei mai
relevante constrngeri circulare asupra perechilor de roluri din cadrul unui predicat al unui tip de fapt.
Astfel, dac o relaie este simetric i tranzitiv atunci ea este i reflexiv; o relaie care este reflexiv,
simetric i tranzitiv este o relaie de echivalen; asimetria i intranzivitatea fiecare implic
nereflexivitatea; excluderea implic asimetria. O relaie funcional nereflexiv trebuie s fie
intranzitiv. Relaiile negative: nereflexivitatea i asimetria implic neexistena sigur a unor alte
tipuri de fapte. Din figurile urmtoare se pot observa relaiile care exist ntre aceste constrngeri.
Astfel o constrngere simetric simpl include o parte din constrngerea nereflexiv ( ir) i
intranzitiv (Oit).
Fig. 6.36. Constrngere simetric

O constrngere nereflexiv include constrngerile de tip intranzitive ( Oit), aciclice (Oac) i o parte din
constrngerile simetrice (Osym) i antisimetrice (Oans).
Fig. 6.37. Constrngere nereflexiv

O constrngere asimetric, dup cum s-a mai explicat, se afl la intersecia dintre constrngerea
antisimetric (Oans) i nereflexiv (ir).
Constrngeri ORM
37
Fig. 6.38. Constrngere asimetric

O constrngere antisimetric simpl include constrngerea asimetric ( Oas), aciclic (Oac), o parte din
constrngerea nereflexiv (ir) i intranzitiv (it).
Fig. 6.39. Constrngere antisimetric

O constrngere intranzitiv implic nereflexivitatea, iar cea simpl este inclus n totalitate n cea
nereflexiv (ir), o parte din cea simetric ( Osym), antisimteric (Oans), aciclic (Oac) i asimetric
(Oas)
Fig. 6.40. Constrngere intranzitiv
Fig. 6.41. Constrngere aciclic

De asemenea, ntr-un model surs ORM este posibil ca asupra aceluiai predicat s fie aplicate mai
multe constrngeri circulare. n acest caz constrngere este o constrngere circular compus, indicat
prin existena parantezelor care conin cele dou constrngeri circulare. Nu este permis orice
combinaie ntre constrngeri. Astfel combinaiile permise sunt dintre urmtoarele constrngeri:
aciclice i intranzitive, asimetrice i intranzitive, intranzitive i simetrice i nereflexive i simetrice.
Constrngeri ORM
38
De exemplu, tipului de fapt Persoana este parinte / este copil pentru Parinte i se poate aplica att
o constrngere circular asimetric ( as), ct i una intransitiv ( it), deci constrngerea circular
compus (as, it).
Fig. 6.42. Aplicarea unei constrngeri circulare compuse

Constrngerea circular compus (as, it) va fi transpus ntr-o singur procedur stocat. Pentru
acele SGBD-uri care nu suport procedurile stocate (cum ar fi de exemplu, Microsoft Access),
procedurile stocate sunt tratate drept comentarii, care pot fi utilizate pentru aplicarea constrngerilor
folosind ci alternative.
Un alt exemplu de aplicare a constrngerilor circulare compuse: se dorete exemplificarea cuvintelor
sinonime. Deci vom avea obiectul entitate Cuvant supra crui va trebui s se impun dou tipuri de
constrngeri circulare: nereflexiv i simetric, respectiv ( ir, sym).
Fig. 6.43. Constrngerea circular compus

nereflexivitatea i simetria
Dac ntr-o relaie nereflexiv exist un rol funcional, atunci ea este i intranzitiv, deci: ir & rol
funcional implic it.
Un alt exemplu de aplicare a constrngerilor circulare compuse: se ia tipul de fapt Persoana este
parinte pt. Persoana. Pentru ca s se surprind toate restriciile referitoare la printe, copil, nepot,
bunic asupra acestui tip de fapt va trebui s se impun dou tipuri de constrngeri circulare: aciclic i
intranzitiv, respectiv (ac, it).
Constrngeri ORM
39
Fig. 6.44. Constrngerea circular compus

aciclic i intranzitiv
6.5. Constrngeri comparare de mulimi

(set-comparison constraints)
Dac dou roluri sunt ndeplinite de acelai obiect, sau obiectele ataate rolurilor partajeaz un
supertip comun, se spune despre acele tipuri c sunt compatibile, i de aceea n anumite situaii este
important ca populaiile lor s poat fi comparate. Acelai lucru este adevrat i pentru secvene de rol
(lista ordonat a rolurilor).
Pentru aceasta se va utilizai o constrngere comparare de mulimi pentru a restriciona (a limita, a
restrnge) domeniul populaiei unei secvene de rol legat de populaia unei alte secvene de rol.
Pentru aplicaiile de baze de date, sunt relevani numai trei operatori de comparare de mulimi:
Submulime (subset).
Egalitate (equality).
Excludere mutual (mutual exclusion).

care vor forma cele trei tipuri de constrngeri de comparare de mulimi.
6.5.1. Constrngeri de tip submulime

(subset constraints)
O constrngere de tip submulime de la o secven de rol surs ctre o secven de rol destinaie
semnific c populaia (mulimi ale instanei) secvenei de rol surs trebuie ntotdeauna s fie o
submulime a populaiei secvenei de rol destinaie. Constrngerea este afiat grafic ca un contur
circular conectat de o sgeat punctat pornind de la rolul surs la rolul destinaie. n VEA simbolul de
submulime circumscrise este artat explicit (mereu). Aceasta clasific nelesul notaiei constrngerii,
suportnd cazurile rare n care rolul surs i rolul destinaie aparin aceleai asociaii, i permite
utilizarea liniei punctate n interiorul altor constrngeri directe (de exemplu, ), pentru care o notaie
de constrngere grafic poate fi adugat mai trziu.
A Constrngere submulime intern

ConstrngeriBORM
40
Constrngere
submulime extern
Fig. 6.45. Constrngeri submulime interne (A) i externe (B)

Se va utiliza o constrngere de tip submulime n cazul n care dou secvene de rol sunt ndeplinite de
acelai obiect i toate rolurile sunt opionale. n funcie de apartenena secvenelor de rol la tipurile de
fapte, vor exista dou tipuri de constrngeri, i anume:
Constrngeri de tip submulime interne (internal subset constraint), caz n care

secvenele de rol aparin aceluiai tip de fapt.
Constrngeri de tip submulime externe (external subset constraint), caz n care

secvenele de rol fac parte din tipuri de fapte diferite.
De exemplu, dac ntr-o aplicaie este necesar s se urmreasc data de lansare i data de terminare a
proiectelor, se vor utiliza urmtoarele tipurile de fapte:
Proiect(Nr) ncepe pe Data(dmy)

Proiect(Nr) se termin pe Data(dmy)
Regula de business exprimat prin cele dou tipuri de fapte este: Un proiect nu poate avea o dat de
terminare atta timp ct el nu are o dat de lansare n execuie . Se creeaz astfel o relaie de
submulime ntre rolurile ndeplinite de obiectul entitate, Proiect, n cele dou tipuri de fapte.
O constrngere submulime intern se va utiliza n situaia n care se dorete s se impun condiia
ca un obiect s reprezinte o submulime a unui alt obiect cu care intr ntr-o relaie prin intermediul
unui singur tip de fapt.
Astfel dac exist obiectul entitate Angajat pentru a evidenia c obiectul entitate Manager reprezint
o submulime a tipului Angajat, se va utiliza o astfel de constrngere.
Pentru a aduga o astfel de constrngere de tip submulime, mai nti se va introduce tipul de fapt
Manager(CNP) este Angajat(CNP) (de exemplu, prin adugarea acestora n editorul Business Rules
i apoi tragerea acestora n fereastra Drawing). Apoi se vor selecta predicatul i se va activa meniul de
tip popup, din care se va alege opiunea Add Constraints....
Din cutia de dialog Add Constraint se va alege din lista de opiuni cu eticheta Constraint type,
valoarea Subset. Urmtorul pas const n selectarea rolului surs pentru constrngere (notat 1 n
figura 6.46.A, i care reprezint o submulime a rolului destinaie), urmat de alegerea rolului destinaie
(notat cu 2 n figur), i automat va apare i verbalizarea acesteia n partea de jos a cutiei de dialog.
Constrngeri ORM
41
Fig. 6.46. Constrngere submulime intern

Constrngerile submulime externe se pot aplica asupra:
Unui singur rol din tipurile de fapte implicate n constrngere.

Unei perechi de roluri din tipurile de fapte implicate n constrngere.
n cazul unei constrngeri submulime externe cel mai simplu caz este al unei secvene de rol unic.
n figura nr. 6.47.b. constrngerea de submulime care exist ntre cele dou roluri unice are
urmtoarea semnificaie: mulimea angajailor care au i un al doilea nume trebuie s fie o submulime
a setului de angajai care au primul nume.
Dup introducerea celor dou tipuri de fapte, se vor selecta predicatele relevante i se va activa meniul
de tip popup, din care se va alege opiunea Add Constraints....Din cutia de dialog Add Constraint se
va alege din lista de opiuni cu eticheta Constraint type, valoarea Subset. Urmtorul pas const n
selectarea rolului surs pentru constrngere (notat 1 n figura 6.47.a, i care reprezint o submulime a
rolului destinaie), urmat de alegerea rolului destinaie (notat cu 2 n figur). Dac operaie se termin
cu succes, atunci cutia de dialog va arta ca n figura nr. 6.47.a, iar constrngerea va fi n mod automat
verbalizat n josul cutiei de dialog. Dac nu se mai dorete adugarea altor constrngeri se va apsa
butonul OK, n caz contrar se va apsa butonul Apply, pentru adugarea altor constrngeri. Dup
aplicarea constrngerii vizualizarea ei va fi cea ilustrat n figura 6.47.b.
Fig. 6.47. Alegerea tipului de constrngere submulime ntre dou roluri unice,
selectarea rolului surs (1) i a rolului destinaie (2)
Not: Se observ utilizarea liniuei n predicatele are primul- i are al doilea-. Aceasta unete
adjectivele primul i al doilea la obiectul valoare Nume n momentul n care constrngerea pe
aceste predicate este verbalizat, astfel nct cuvinte cheie precum some (nite) sunt inserate naintea
Constrngeri ORM
42
adjectivului n loc de dup el (figura 6.47.). n cazul n care nu este utilizat liniua n cadrul
predicatelor cuvntul some va fi inserat dup adjective.
A doua situaie ntlnit pentru o constrngere de tip submulime extern este o constrngere
submulime dintre perechi de roluri, caz n care fiecare secven de rol ndeplinete dou roluri. De
exemplu, pentru ca o persoan s prezideze un comitet ea trebuie s fie membr a acelui comitet.
Aceast constrngere nseamn c perechile de populaie Persoana -> Comitet care instaniaz
asocierea de predicate trebuie s fie o submulime a populaiei dintr-o asociere de membru.
Fig. 6.48.
primului tip de
constrngerilor
de unicitate i
Adugarea
fapt, i a
obligativitate
n continuare
cel de-al doilea
se va introduce
tip de fapt.
Constrngeri ORM
43
Fig. 6.49. Introducerea celui de-al doilea tip de fapt,

i a constrngerilor aferente
Pentru a aduga constrngerea de tip submulime extern, n cutia de dialog Add Constraints..., se va
selecta opiunea Subset n cmpul cu eticheta Constraint Type. Dac fiecare constrngere este
indeplinit de mai multe roluri, se va incrementa indicatorul Number of roles at each la valoarea
dorit. Implicit, numrul rolurilor ataat unei constrngeri este 1. Deoarece fiecare sfrit al acestei
constrngeri are dou roluri, se va modifica aceast valoare la 2.
n continuare se va selecta rolul surs din perechea de roluri selectat, i apoi rolul destinaie,
ordonnd mai nti rolurile n interiorul fiecrei perechi de roluri pentru a arta corespondena cu
rolurile din cealalt pereche. n funcie de rolul selectat ele vor fi numerotate: 1.1, 1.2, 2.1., .a.m.d. n
ordinea seleciei. Prima parte a fiecrui numr semnific secvena de rol, i a doua parte arat poziia
n interiorul acestei secvene. Constrngerea este automat verbalizat n partea de jos a ferestrei. Dup
apsarea butonului Ok constrngerea este acceptat i va fi adugat diagramei (figura 6.50.b).
Constrngeri ORM
44
Fig. 6.50. Adugarea constrngerii submulime ntre perechi de roluri
6.5.2. Constrngeri de egalitate

(equality constraints)
O constrngere de egalitate unete dou roluri ntr-o relaie condiional (dac i numai dac), i ea
semnific faptul c populaia primei secvene de rol trebuie s fie ntotdeauna egal cu populaia
oricrei alte secvene de rol implicat n constrngere, i invers. Rolurile pot face parte din acelai tip
de fapt sau din tipuri de fapte diferite, caz n care cele dou roluri sunt ndeplinite de acelai obiect.
Cele dou rolurile sunt opionale sau obligatorii.
Pentru a aduga o astfel de constrngere ntr-un model se vor aduga tipurile de fapte, pentru a cror
secvene de roluri se dorete aplicarea unei constrngeri de egalitate (prin intermediul Editorului de
Fapte, sau folosind formele din partea stencil). Dac s-a utilizat Editorul de Fapte pentru exprimarea
tipurilor de fapte, pentru a fi vizualizat reprezentarea grafic a modelului se vor trage cele dou tipuri
de fapte n fereastra Drawing; n caz contrar se va trece la pasul urmtor. Se vor selecta cele dou
predicate relevante (secvenele de rol) i se va alege opiunea Add Constraints..., din popup meniul
aferent. n cutia de dialog Add Constraint se va selecta pentru cmpul cu eticheta Constraint Type
valoarea Equality, apoi se vor selecta secvenele de rol.
A Constrngere de egalitate intern

B Constrngere de egalitate extern
Fig. 6.51. Tipuri de constrngeri de egalitate

Constrngeri ORM
45
De exemplu, dac avem urmtoarele dou tipuri de fapte: Aviz_Expeditie contine Produse i
Factura (Nr_Fact) contine Produse, acestea vor exprima urmtoarea regul de business Numrul
de produse din avizul de expediie trebuie s fie egal cu numrul de produse din factura
aferenta.
Dup cum se observ din figura 6.52.a, fiecare rol are dou secvene (pentru exemplul dat, s-a ales
numai o secven de rol). De fapt, ordinea secvenelor de rol ntr-o constrngere de egalitate nu este
important, deoarece egalitatea este simetric (spre deosebire de submulime). Verbalizarea
(exprimarea) constrngerii este redat n seciunea de jos a ferestrei de dialog. Constrngerile de
egalitate ntre mai multe secvene de rol pot fi adugate ntr-un mod similar cu cele pentru
constrngerile de tip submulime.
Exprimarea grafic a acestei constrngeri este ilustrat n figura 6.52.b.
Fig. 6.52. Adugarea unei constrngeri de egalitate

ntre dou roluri
6.5.3. Constrngeri de excludere

(exclusion constraints)
O constrngere de excludere este utilizat n situaia n care cele dou roluri care fac parte din
constrngere nu pot fi ndeplinite n acelai timp de obiectul la care este conectat. Aceasta semnific
faptul c, populaia primei secvene de rol nu poate exista n populaia celeilalte secvene de rol, sau
altfel spus populaiile celor dou secvene de rol trebuie s fie ntotdeauna disjuncte (excludere
obligatorie, excludere reciproc). Despre cele dou populaii ale celor dou roluri se spune c sunt
exclusiv mutuale, iar intersecia lor va fi mulimea nul.
Constrngeri ORM
46
O constrngere de excludere se va utiliza n cazul n care dou sau mai multe secvene de rol sunt
ndeplinite de acelai obiect i rolurile sunt opionale, i la un moment dat numai un rol este ndeplinit.
Secvenele de rol pot fi din acelai tip de fapt sau din tipuri de fapte diferite.
A Constrngere de excludere intern
B Constrngere de excludere extern
Fig. 6.53. Tipuri de constrngeri de excludere

Ca i n cazul constrngerilor de tip submulime, i constrngerile de excludere pot fi aplicate unei
perechi de roluri, sau unui singur rol din cadrul predicatului. Pentru a exemplifica o constrngere de
excludere aplicabil unei perechi de roluri se vor scrie dou tipuri de fapte pentru urmtoarea
regul de afaceri: Aceeai factur nu poate fi emis i recepionat de acelai ter . Cele dou
tipuri de fapte sunt: Factura este emisa de Tert i Factura este receptionata de Tert . n
fereastra Add Constraint se va selecta valoarea Exclusion, pentru aplicarea constrngerii, se va
incrementa numrul de roluri aferent fiecrui tip de fapt la doi ( Number of roles at each), iar apoi se
vor selecta perechile de rol, figura 6.54.a.
Reprezentarea grafic a unei astfel de constrngeri este ilustrat n figura 6.54.b.
Fig. 6.54. Constrngere de excludere pereche

Alt tip de constrngere de excludere este constrngerea de excludere simpl, caz n care ea este
aplicat numai unui singur rol din cele dou secvene de roluri selectate. Pentru a ilustra o
constrngere de excludere simpl se vor dou tipuri de fapte: Persoana este membru Comitet i
Persoana nu este membru Comitet, aferente urmtoarei reguli de afaceri: Aceeai persoan la un
moment poate face / sau nu dintr-un comitet . Aceast regul de business este exprimat printr-o
constrngere de excludere simpl.
Constrngeri ORM
47
Fig. 6.55. Adugarea unei constrngeri de excludere simpl

Contrngerea de excludere implic asimetria i deci nereflexivitatea. Pentru exemplificare se va scrie
tipul de fapt: Persoana feste sotul / este sotia Persoana. Deci, as ir.
Fig. 6.56. Constrngere de excludere

aplicat unui singur tip de fapt
6.6. Alte tipuri de constrngeri

6.6.1. Constrngeri de frecven
(frequency constraints)
O constrngere de frecven este utilizat n cazul n care se dorete restricionarea (limitarea) numrul
de nregistrri care pot exista n populaia unui rol, sau a unei combinaii de roluri.
Constrngerile de frecven pot fi specificate (n funcie de valoarea pe care o poate lua numrul de
repetri a rolului) astfel:
Un ntreg (o valoare specific), de exemplu valoarea 2, ceea ce semnific faptul c o instan a

rolului respectiv se poate repeta exact de 2 ori.
Un domeniu de valori limitat (de exemplu, 2..10), are semnificaia c fiecare instan a rolului
respectiv se poate repeta de 2, 3, 4,.., respectiv 10 ori.
Un domeniu de valori nelimitat (de exemplu, >=5), caz n care fiecare instan a rolului se
poate repeta de un numr nelimitat de ori, dar valoarea iniial este de 5.
Constrngeri ORM
48
Exist urmtoarele tipuri de constrngeri de frecven: interne i externe.

A Constrngere de frecven intern
(internal frequency constraint)
B Constrngere de frecven extern

(external frequency constraint)
Fig. 6.57. Constrngeri de frecven

Se va exemplifica prima posibilitate de aplicare a unei constrngeri de frecven. Presupunem c
exist o constrngere de unicitate care se aplic tipul de fapt Persoana sustine un Examen in
Data.
Fig. 6.58. Crearea unei constrngeri de unicitate pentru trei roluri

Dac o persoan se poate nscrie la un examen de cel mult 2 ori, se va crea o constrngere de frecven
extern <=2 pe perechea de roluri jucat de tipul de obiect entitate Persoana i tipul de obiect
entitate Examen. Modalitatea de declarare a unei astfel de constrngere este ilustrat n figura 7.59.
Se observ c se va atribui aceeai valoare pentru csuele de editare cu etichetele Minimum (1 or) i
Maximum (blank=no), iar figura 7.60. ilustreaz reprezentarea grafic a constrngerii impuse.
Fig. 7.59. Crearea unei constrngeri externe de frecven cu o valoare
Constrngeri ORM
49
Fig. 7.60. Reprezentarea grafic a unei constrngeri

de frecven externe cu o valoare unic
Un alt exemplu se refer la modalitatea de declarare a unei constrngeri de frecven pe un domeniu
nelimitat. Considerm urmtoarea regul de business: Fiecare persoan face parte din cel mult
o grup, iar fiecare grup conine cel puin 10 persoane pentru a se putea susine un
examen. Constrngerea de frecven >=10 alturi de rolul ndeplinit de tipul de obiect entitate
Grupa(Nr_grupa) va avea semnificaia urmtoare: ntr-o grup de examinare numrul minin de
persoane este de 10.
Fig. 7.61. Reprezentarea grafic a unei constrngeri de frecven

externe pe un domeniu nelimitat de valori
n situaia cnd se utilizeaz acest tip de constrngere de frecven, n linia de editare Maximum
(blank=no) se va terge valoarea existent (deci nu va exista o limit superioar).
Fig. 7.62. Declararea unei constrngeri de frecven

pentru un domeniu nelimitat de valori
Ultimul caz de utilizare a unei constrngeri de frecven este cazul n care aceast constrngere are
valori ntr-un domeniu limitat de valori. Se va lua exemplul de mai sus n care se restricioneaz
numrul de persoane dintr-o grup la valori cuprinse n domeniul 10..25. n acest caz fereastra de
dialog Add Constraint va fi:
Constrngeri ORM
50
Fig. 7.63. Declararea unei constrngeri de frecven

pe un domeniu de valori
Iar reprezentarea grafic a constrngerii este:
Fig. 7.64. Reprezentarea grafic a constrngerii

Dac se reunesc tipurile de fapte ntr-un singur model, se va obine:
Fig. 7.65. Reprezentarea mai multor

tipuri constrngeri de frecven
Dac acest model conceptual va fi transpus ntr-un model logic, se va obine o schem cu dou tabele,
care iniial va avea forma din figura 7.66.
Fig. 7.66. Transpunerea unui model surs ORM

ntr-un model logic
Constrngerile de frecven exist n model dar nu sunt afiate n diagram. Dac se va genera
fiierul .DDL pentru aceast schem, constrngerile de frecven vor apare codificate drept proceduri
stocate. n funcie de SGBD-ul care va fi utilizat se poate decide dac se vor pstra aceste proceduri
Constrngeri ORM
51
stocate (pentru a fi rulate), sau ele vor fi translatate n trigger-e. Astfel, pentru acele SGBD care nu
suport proceduri stocate (de exemplu, Microsoft Access), procedurile stocate vor fi tratate drept
comentarii, care pot fi folosite pentru gsirea unei ci alternative de impunere a constrngerilor
respective.
Dac dorim se dorete modificarea numelor atributelor fiecrei tabele, aceasta se poate executa uor
rezultnd urmtoarea schem:
Fig. 7.67. Modificarea caracteristicilor tabelelor

Dac n model s-a efectuat o modificare, n momentul n care se salveaz utilizatorul este ntrebat dac
dorete salvarea acestor modificri i n fiierul surs care a stat la baza lui.
Fig. 7.68. Orice modificare n modelul logic

poate fi transmis i modelului surs care a stat la baza lui
7.6.2. Constrngeri index

O constrngere index reprezint o adnotare utilizat n scopul de a mbunti performanele
ntr-o baz de date fizic, i nu este o constrngere adevrat. n momentul n care se concepe
un model logic bazat pe un model conceptual, o constrngere index este transpus ntr-un
index care nu este unic ntr-o tabel.
O astfel de constrngere se poate aplica asupra unuia sau mai multor roluri din unul sau mai
multe predicate, atta timp ct toate predicatele implicate n construirea indexului partajeaz
un singur tip de obiect.
A Constrngere index intern

(internal index constraint)
B Constrngere index extern

(external index constraint)
Constrngeri ORM
52
Fig. 7.69. Tipuri de constrngeri index

n cazul n care o constrngere index este aplicat asupra mai multor roluri, va fi generat un
index care nu este unic pentru combinaia coloanelor tabelei n care sunt transpuse rolurile
respective.
Presupunem c avem urmtoarele tipuri de fapte:
Persoana locuieste la Adresa

Persoana are Prenume
Persoana are Nume
Dac se dorete cutarea unei persoane pe baza combinaiei dintre numele i prenumele su,
atunci se va aplica o constrngere index pentru perechile de roluri ndeplinite de tipurile de
obiect valoare Prenume i Nume, care va determina crearea unui index non-unic pentru
coloanele cu acelai nume.
Fig. 7.70. Aplicarea constrngerii index pentru Nume i Prenume

Dac se dorete determinarea unei persoane n funcie de adres, atunci se poate crea o
constrngere index pentru tipul de obiect valoare Adresa. n final reprezentarea grafic a
modelului va fi cel din figura 7.71.
Fig. 7.71. Reprezentarea constrngerilor index
Constrngeri ORM
53
7.6.3. Constrngeri de valoare (value)

Constrngerea de valoare este folosit pentru a defini mulimea valorilor disponibile pentru un
tip de obiect valoare. Astfel, se pot defini valori specifice sau, n cazul tipurilor de obiecte
numerice, un domeniu al valorilor.
Pentru adugarea unei constrngeri de valoare la un tip de obiect valoare se va executa un
click, sau un dublu click, pe tipul de obiect dorit aflat n fereastra Drawing; n acest moment
va fi selectat pagina Database Properties, unde se va selecta categoria Value. Aici se vor
introduce valori relevante i / sau domeniul de valori pe care l poate avea tipul de obiect
selectat. Valorile care se doresc a fi atribuite tipului de obiect valoare vor fi introduse pe rnd
n cmpul cu eticheta Value. Dup acionarea butonului Add acestea vor fi introduse n
domeniul tipului respectiv (figura 7.72).
Numrul implicit de valori care vor fi afiate pe ecran este de 5. Pentru a modifica aceast
valoare implicit pentru un anumit tip de obiect se va proceda n modul urmtor: se va selecta
tipul de obiect pentru care se dorete modificarea valorii implicite, se va activa meniul de tip
popup corespunztor, apoi se va alege opiunea Shape | Custom Properties... i se va atribui
noua valoare dorit (figura 7.73.).
Fig. 7.72. Adugarea unei constrngeri de tip valoare

Dac numrul setat este mai mic dect numrul de valori care sunt atribuite tipului de obiect,
atunci la lista de valori afiat n fereastra Drawing, va fi adugat o elips de genul ,
pentru a indica c nu sunt afiate toate valorile posibile pe care le poate lua constrngerea
respectiv. Indiferent de ct de multe valori sunt afiate pe diagram, toate valorile care vor fi
introduse vor fi incluse n fiierul .DDL, iar cnd baza de date este construit, nici o alt
valoare nu va putea fi introdus n aceast coloan, creia i s-a impus aceast constrngere de
valoare.
Constrngeri ORM
54
Fig. 7.73. Valoarea implicit pentru numrul de valori

ce pot fi afiate n cazul unei constrngeri de tip valoare
De exemplu, dac numrul a fost setat la doi, modul de afiare va fi urmtorul:
Fig. 7.74. Afiarea constrngerii de tip valoare
7.6.4. Constrngeri disjunctive de excludere

(exclusive-or constraint)
ntr-un model ORM, o constrngere disjunctiv de excludere ( exclusive-or constraint)
reprezint o combinaie dintre o constrngere:
obligatorie disjunctiv (inclusive-or constraint sau disjunctive mandatory
constraint);
de excludere (exclusion constraint).
Adugarea unei astfel de constrngeri se face n modul urmtor: se adaug dou tipuri de
fapte, se aduc cele dou tipuri de fapte n fereastra Drawing, se vor selecta predicatele
relevante pentru aplicarea constrngerii i se va deschide cutia de dialog Add Constraint.
Prima dat se va alege constrngerea obligatorie, Mandatory (figura 7.76.), iar apoi se va
alege constrngerea de excludere, valoarea Exclusion pentru aceleai roluri (figura 7.77.).
Fig. 7.75. Constrngerea disjunctiv de excludere
Fig. 7.76. Adugarea constrngerii

obligatorii
Constrngeri ORM
55
Fig. 7.77. Adugarea constrngerii exclusive
Dac se dorete vizualizarea separat a celor dou constrngeri, se va executa click dreapta cu
mouse-ul pe reprezentarea grafic a constrngerii ilustrat n figura 7.75., i se va alege
opiunea Split X / OR constraint (figura 7.78.). Constrngerile vor fi afiate separat i se va
putea lucra cu fiecare constrngere separat.
Fig. 7.78. Alegerea opiunii Split X / OR constraint

Imaginea grafic a constrngerii va fi cea din figura 7.77.
Fig. 7.79. Constrngerea disjunctiv de excludere
Constrngeri ORM
56
8. Transpunerea unui model ORM ntr-un

model logic al bazei de date
Transpunerea unui model surs ORM ntr-un model logic al bazei de date presupune
adugarea modelului ORM la proiectul bazei de date ce se dorete a fi implementat i apoi
construirea acestuia. Pentru aceasta se vor parcurge urmtoarele etape:
1.
2.
3.
4.
Crearea unui nou proiect.

Adugarea modelului surs ORM n lista proiectului modelului bazei de date.
Transpunerea modelului surs ORM ntr-un model logic prin generarea proiectului.
Tragerea tabelelor rezultate n urma transpunerii modelului surs ORM pe diagram
pentru vizualizarea diagramei logice.
8.1. Crearea unui proiect nou

Modelul logic al bazei de date pornete de la o diagram ORM elaborat anterior i stabilete
o coresponden a tipurilor de obiecte entitate i tipurilor de obiect valoare din modelul
conceptual ORM la un set de entiti i relaii, testnd gradul de normalizare i permind
ajustarea acestuia. Acest model este independent de platforma pe care va fi implementat baza
de date. Pentru a se transpune un model surs ORM ntr-un model logic al bazei de date va
trebui mai nti s se adauge acel model ORM la proiectul bazei de date.
Paii care se execut sunt:
1.
2.
Din bara de meniuri se va alege File | New | Database | Database Model Diagram
(US units), sau Database Model Diagram, care va determina apariia pe ecran a
ferestre din figura 8.1.
n continuare se va alege opiunea Database | View | Project pentru a se deschide
fereastra Project, unde sunt evideniate toate modelele care fac parte din proiectul
bazei de date (figura 8.2.).
Modelului logic al bazei de date
57
Fig. 8.1. Fereastra de proiectare a modelului logic al bazei de date
Fig. 8.2. Deschiderea ferestrei Project

3.
Pentru a salva proiectul se va alege File | Save sau Save As....
Dac se dorete crearea unui model logic al bazei de date fr a avea un punct de pornire
(cum ar fi un model ORM), se poate utiliza ablonul de desen Entity Relationship.
8.2. Adugarea modelului surs ORM

n lista proiectului
Urmtorul pas care trebuie executat este adugarea unui model surs ORM la un proiect al
unei baze de date. Pentru aceasta ase vor executa urmtorii pai:
1.
Se va deschide un fiier proiect existent, sau se va crea unul nou, urmrind paii din
subcapitolul 8.1.
2. Pentru adugarea unui model la proiectul bazei de date se va executa una din
urmtoarele operaii:
Pentru a se utiliza un model surs ORM se va alege opiunea Database | Project |
Add Existing Document...
n fereastra Project, se va executa click dreapta pe Project, i din popup meniul
care apare se va alege Add Existing Document....
3. Fereastra de dialog Add Document to Project, care va apare pe ecran, permite
indicarea folder-ului n care se afl modelul surs ORM (Look in:), dup care se va
selecta numele fiierului care se dorete s fie adugat n proiectul bazei de date.
Not Se poate aduga un fiier model surs ER sau ORM (fiiere cu extensia .vsd)
sau alte documente ale altui tip de fiier care se dorete a fi asocia cu proiectul.
4. Pentru deschiderea modelului se va apsa butonul Open.
58
n final fereastra Project va conine toate modelele care au fost incluse. n figura 8.3. aceast
fereastr cuprinde un singur model surs, i anume MC_Servicii_Internet1.vsd.
Fig. 8.3. Includerea unui model surs ORM

ntr-un proiect al bazei de date
8.3. Transpunerea modelului surs ORM

ntr-un model logic
Pentru construirea modelul logic se va alege opiunea: Database | Project | Build..., comand
n urma creia se va crea automat schema relaional. Lista tuturor entitilor care rezult n
urma construirii modelului logic va apare n fereastra Tables and Views (figura 8.4.).
n cazul n care modelul surs ORM conine erori (predicate n conflict, relaii subclas
superclas lips etc.) Microsoft Visio for Enterprise Architects nu va genera modelul logic
al bazei de date, indicnd erorile care nu permit generarea modelului. Erorile vor apare n
fereastra Output. Exemple de astfel de erori ce pot apare n urma construirii modelului logic
sunt artate n continuare.
59
Fig. 8.4. Transpunerea modelului surs ORM

ntr-o schem relaional
Exemplul nr.1: erorile care sunt semnalate se datoreaz faptului c nu au fost declarate cheile
primare ale obiectelor i nu au fost declarate corect obiectele i valorile.
Starting Build...
C:\LUCRARI\VISIO.NET\FURNIZORIER.VSD : Updating existing database model project.
C:\Lucrari\...\furnizori.vsd : Merging Source Model.
C:\LUCRARI\...\FURNIZORIER.VSD : error C2003: 'CodFiscFurn' : Object type has no primary reference scheme.
C:\LUCRARI\...\FURNIZORIER.VSD : error C2003: 'DataEmit' : Object type has no primary reference scheme.
C:\LUCRARI\...\FURNIZORIER.VSD : error C2003: 'Factura' : Object type has no primary reference scheme.
C:\LUCRARI\...\FURNIZORIER.VSD : error C2003: 'Furnizor' : Object type has no primary reference scheme.
C:\LUCRARI\...\FURNIZORIER.VSD : error C2003: 'NrFact' : Object type has no primary reference scheme.
C:\LUCRARI\...\FURNIZORIER.VSD : error C2003: 'ValTotala' : Object type has no primary reference scheme.
Build failed - 7 error(s) 0 warning(s)
Exemplul nr.2: este cazul n care nu exist erori grave, dar exist cteva erori de avertizare.
Starting Build...
C:\LUCRARI\VISIO.NET\FURNIZORIER.VSD : Updating existing database model project.
C:\Lucrari\...\furnizori.vsd : Merging Source Model.
C:\Lucrari\...\furnizori.vsd : warning C1007: 'CodFiscFurn' : Value object type playing mandatory role not recommended.
C:\Lucrari\...\furnizori.vsd : warning C1007: 'NrFact' : Value object type playing mandatory role not recommended.
C:\LUCRARI\VISIO.NET\FURNIZORIER.VSD : Starting Mapping ...
C:\LUCRARI\VISIO.NET\FURNIZORIER.VSD : Tables(1) Columns(6) Logical Keys(2) Foreign Keys(0)
0 error(s), and 2 warning(s).
Exemplul nr.3: nu exist nici un fel de erori.

Starting Build...
C:\LUCRARI\ORM_VISIO.NET\MODELE\LOGIC.VSD : Updating existing database model project.
C:\Lucrari\...\FACTURI.vsd : Merging Source Model.
C:\LUCRARI\ORM_VISIO.NET\MODELE\LOGIC.VSD : Starting Mapping ...
C:\LUCRARI\ORM_VISIO.NET\MODELE\LOGIC.VSD : Tables(4) Columns(23) Logical Keys(9) Foreign Keys(4)
sau
Starting Build...
C:\LUCRARI\ORM_VISIO.NET\MODELE\LOGIC.VSD : Updating existing database model project.
C:\Lucrari\...\FACTURI.vsd : Merging Source Model.
C:\LUCRARI\ORM_VISIO.NET\MODELE\LOGIC.VSD : Starting Mapping ...
C:\LUCRARI\ORM_VISIO.NET\MODELE\LOGIC.VSD : Tables(4) Columns(23) Logical Keys(9) Foreign Keys(4)
sau
Starting Build...
C:\LUCRARI\ORM_VISIO.NET\MODELE\LOGIC_O.VSD : Updating existing database model project.
C:\Lucrari\...\FACTURI_0.vsd : Merging Source Model.
C:\Lucrari\...\FACTURI_0.vsd : warning C1007: 'NrFact' : Value object type playing mandatory role not recommended.
C:\LUCRARI\ORM_VISIO.NET\MODELE\LOGIC_O.VSD : Starting Mapping ...
C:\LUCRARI\ORM_VISIO.NET\MODELE\LOGIC_O.VSD : Tables(4) Columns(25) Logical Keys(10) Foreign Keys(4)
60
8.4. Vizualizarea diagramei logice

Pentru a vizualiza schemele entitilor rezultate n urma transpunerii modelului surs ORM
ntr-un model logic al bazei de date se va utiliza proprietatea drag&drop. Se vor selecta numai
acele entiti, sau toate, pentru care se dorete vizualizarea modelului logic, apoi vor fi aduse
pe foaia de lucru. Dup efectuarea acestei operaii se va putea vedea modelul logic care va
cuprinde: toate entitilor (numele, atributele fiecrei entiti, precum i relaiile existente ntre
ele).
Fig. 8.5. Transpunerea schemei relaionale dintr-un

model surs ORM, utiliznd notaia relaional
Fiecare tabel are propriul su nume afiat n antet (de exemplu, Factura), dup care urmeaz
lista coloanelor. Cheile primare sunt afiate subliniat i marcate cu PK (Primary Keys), i
apar la nceputul listei coloanelor (deci naintea tuturor celorlalte coloane). Coloanele
obligatorii (not null) sunt afiate boldate. Coloanele care sunt chei strine sunt marcate cu
FKn (Foreingn Keys), unde n reprezint numrul cheii strine din (cu o) tabel. Abrevierea
Un reprezint o constrngere de unicitate, unde n reprezint numrul constrngerii de
unicitate din cadrul tabelei.
Reprezentarea din cadrul modelului logic (ca i n cel fizic, de altfel) este o reprezentare
ERD (Entity Relationship Diagrams), folosind implicit notaia relaional.
Astfel, urmtoarele imagini ilustraz transpunerea din modelul conceptual (modelul surs
ORM) al anumitor tipuri de obiecte entitate n modelul logic corespunztor.
61
Fig. 8.6. Modelul conceptual, logic, pentru Factura

n aceste exemple, numele tabelelor i al coloanelor sunt cele generate n mod implicit din
modelul surs ORM (conceptual). n practic se pot atribui alte denumiri pentru tabele, sau
pentru coloane, i de asemenea se pot modifica tipurile de date implicite care au fost
desemnate de sistem pentru fiecare coloan a tabelei.
Referitor la tipurile de date este recomandat ca acestea s fie setate atunci cnd se elaboreaz
modelul ORM, unde tipurile de obiecte corespund cu domeniile conceptuale. Astfel, tipurile
de date corecte sunt apoi n mod automat propagate ctre toate atributele care au la baz
aceste domenii de valori.
62
Fig. 8.7. Modelul conceptual, logic, pentru Incasari
Fig. 8.8. Modelul conceptual, logic, pentru Cont_Email
Fig. 8.9. Modelul conceptual, logic, pentru Ter

n afara reprezentrii ERD (este notaia implicit), pentru modelul logic se mai poate utiliza i
un alt mod de reprezentare, respectiv reprezentarea ISEF1X. Pentru a modifica modul de
reprezentare implicit al modelului logic se va utiliza opiunea: Database | Options |
Document care va determina apariia urmtoarei ferestre, de unde se poate modifica setarea
implicit.
63
Fig. 8.10. Setarea alegerii modului de reprezentare

Dac n loc de notaia relaional se va alege notaia IDEF1X n pagina General, iar n pagina
Relationship se va bifa opiunea Crows feet reprezentarea va fi cea din figura 8.11.
Fig.
8.11.
Utilizarea notaiei IDEF1X
Dac se dorete vizualizarea proprietilor bazei de date se va utiliza pagina Database

Properties. Sunt disponibile opiunile de editare a proprietilor entitilor i relaiilor, opiuni
de unde se vor putea modifica caracteristicile fiecrei entiti, atribut sau relaie.
n acest moment tipurile de date ale atributelor (cmpurilor) sunt date portabile, independente
de platform. La acest nivel, modelul conine atributele grupate pe entiti, relaiile definite
ntre aceste entiti, indeci i cheile definite la nivelul fiecrei entiti etc. Se pot efectua
modificri n cadrul acestui model, pn cnd se va considera c s-a atins varianta optim.
n momentul n care s-a atins varianta optim (din punct de vedere al proiectantului i al
modelului n acel moment) se va alege Database | Project | Update Source Models... pentru
actualizarea modificrilor efectuate n modelul logic i n modelul (sau modelele, dac avem
mai multe) conceptual(e) din care a fost generat acesta, fapt care asigur corelarea celor dou
modele. i n aceast etap Microsoft Visio va efectua verificarea corectitudinii modelelor.
n cazul existenei unei erori, actualizarea nu va fi efectuat.
64
Fig. 8.12. Pagina Database Properties permite modificarea

caracteristicilor coloanelor tabelei selectate
Dac se dorete ajustarea modelului logic al bazei de date, prin redenumirea sau mutarea
coloanelor, se va selecta tabela pentru care se dorete efectuarea acestor modificri i apoi se
va deschide formularul Database Properties. n acest formular se alege categoria Columns,
i se selecteaz coloana dorit a fi modificat. Dac se dorete mutarea coloanei mai sus, se va
utiliza butonul Move Up, iar n caz contrar, butonul Move Down.
Pentru a se putea efectua modificri asupra tipului de date pe care l poate lua (char, smallint,
real etc.) va trebui s se bifeze butonul Physical data type.
Dac n modelul logic s-au efectuat modificri, i se dorete salvarea acestora i n modelul
surs ORM, se va deschide o fereastr de dialog n care utilizatorul este ntrebat dac dorete
migrarea tuturor modificrilor efectuate n modelul logic ctre modelul (sau modelele) surs
care au stat la baza modelului logic.
Fig. 8.13. Posibilitatea de migrare a modificrilor

ctre modelul conceptual
Este de preferat alegerea butonului No, dac modelul (modelele) surs ORM care a stat la
baza modelului logic, va fi utilizat i n dezvoltarea altor proiecte.
65
8.5. Alte operaii care se pot efectua

asupra modelului conceptual i logic
Dup adugarea unui model la proiectul bazei de date se mai pot efectua urmtoarele operaii:
mbuntirea modelului logic n cadrul proiectului i migrarea oricrei modificri

napoi ctre modelul surs.
Se poate utiliza Generate Wizard pentru a crea o schem a bazei de date.
Se poate genera o nou baz de date direct dac SGBD-ul ales suport acest lucru.
Dac SGBD-ul ales nu suport crearea direct a bazei de date, va trebui utilizat un
script DDL pentru a crea baza de date fizic.
Not nainte de a utiliza Generate Wizard, va trebui s se construiasc proiectul
astfel nct acesta s cuprind cele mai recente modificri din modelul surs ORM.
Dac se utilizeaz reverse engineering (se pornete de la o baz de date existent), se

poate utiliza Refresh Model Wizard pentru a actualiza modelul pe baza modificrilor.
n plus, se poate utiliza Update Database Wizard pentru a actualiza baza de date
fizic pe baza modificrilor efectuate n model.
Not nainte de a utiliza Generate Wizard, va trebui s se construiasc proiectul
astfel nct acesta s cuprind cele mai recente modificri din modelul surs ORM.
Pentru a avea informaii n orice moment despre stadiul construirii proiectului se poate utiliza,
New Report Wizard pentru a genera diferite rapoarte. Aceste rapoarte au rolul de a
documenta etapa de proiectare sau de a comunica informaii despre baza de date ctre client.
Pentru a lansa wizard-ul, se va utiliza opiunea Database | Report.... Aceste rapoarte se pot
genera att n etapa elaborrii modelului conceptual (modelul surs ORM) ct i n faza de
proiectare a modelului conceptual.
Fig. 8.14. Tipuri de rapoarte care pot fi generate

n faza de proiectare a modelului ORM (A), sau a modelului logic (B)
Rapoartele care pot fi editate se refer la: constrngeri, tipurile de fapte, tipurile de obiecte,
supertipuri, informaii referitoare la tabel etc.
66
Dup alegerea raportului care se dorete a fi generat, n figura 8.14. s-a ales generarea
raportului referitor la constrngerile impuse, se va apsa butonul Next, care va determina
apariia pe ecran a urmtoarei ferestre.
Fig. 8.15. Generarea rapoartelor

Raportul generat va cuprinde informaii referitoare la toate constrngerile care au fost aplicate
tipurilor de fapte n modelul surs ORM. De asemenea, wizard-ul permite setarea modului de
afiare a acestor rapoarte, precum i posibiliti multiple de afiare a acestor rapoarte:
imprimare, export ctre un fiier .rtf etc.
raportului
Fig. 8.16. Alegerea opiunilor de filtrare pentru obinerea

referitor la constrngeri
67
Fig. 8.17. Pagina pentru setarea atributelor

ce se doresc a fi incluse n raport
Fig. 8.18. Pagina Sort/group

Celelalte dou pagini permit setarea modului n care se vor obine rapoartele, respectiv
informaiile care vor fi coninute n header-ul raportului, precum i setarea paginii.
Pentru obinerea raportului s-a ales varianta Export to RTF..., iar fiierul, numit
Anexa1_Constrangeri.rtf poate fi consultat n Anexa nr.1.
Fig. 8.19.
rapoarte
Setarea header-ului pentru
68
Fig. 8.20. Setarea paginii pentru rapoarte

Celelalte rapoarte pot fi obinute prin alegerea aceleiai opiuni de meniu. De exemplu, dac
se dorete obinerea raportului referitor la tipurile de fapte utilizate de modelul surs ORM, se
va alege varianta a doua, dup cum se observ din figura 8.21.
Fig. 8.21. Obinerea raportului referitor la tipurile de fapte

cuprinse n modelul surs ORM
Din figura urmtoare se observ c aspectul paginilor, i chiar numrul acestora nu este
identic pentru fiecare raport care se dorete a fi obinut. Astfel aspectul primei pagini este
ilustrat n figura 8.22.
69
Fig. 8.22. Alegerea tipurilor de fapte care

se doresc a fi incluse n raport
Pentru obinerea raportului s-a ales varianta Export to RTF..., iar fiierul, numit
Anexa2_Fapte.rtf poate fi consultat n Anexa nr.2.
Un ultim raport prezentat este cel al obiectelor care sunt utilizate de modelul surs ORM.
Fig. 8.23. Alegerea raportului referitor la tipurile de obiecte

utilizate n modelul surs ORM
Fig. 8.24. Alegerea tipurilor de obiecte care se doresc

a fi evideniate n raport
Raportul obinut, denumit Anexa3_Obiecte.rtf poate fi consultat n Anexa nr.3.
Un alt raport care este indicat a fi obinut este cel referitor la tabelele care alctuisc baza de
date.
70
Fig. 8.25. Obinerea raportului referitor la tabelele care

vor fi incluse n modelul bazei de date
Raportul obinut, denumit Anexa4_Tabele.rtf poate fi consultat n Anexa nr.4, iar tabelul
referitor la statistica modelului este n Anexa nr.5.
8.6. Verbalizarea
Pn acum s-a explicat modalitatea n care se poate utiliza ORM (Microsoft Visio for
Enterprise Architects) pentru modelarea bazelor de date, i anume:
Modalitate de creare a unui nou model surs ORM.

Adugarea tipurilor de propoziii, a constrngerilor interne i obligatorii, precum i
exemple utiliznd Editorul de Fapte.
Tragerea tipurilor de fapte n fereastra de desenare din editorul Business Rules i
salvarea modelului.
Transpunerea modelului ORM ntr-un model logic la bazei de date prin crearea unui
proiect model al bazei de date, adugnd modelul surs ORM, i apoi construirea
modelului logic.
Modalitatea de generare a modelului fizic al bazei de date din modelul logic prin
selectarea SGBD int i generarea unui scrip .DLL.
n continuare se va exemplifica modalitatea de utilizare a verbalizrii (exprimrii), marcarea

unui tip obiect drept obiect independent, obiectivarea unei asociaii, etc.
Att modelul surs ORM ct i modelul logic al bazei de date prezint facilitatea de
verbalizare (exprimare) automat a oricrei pri din modelul selectat, i care va include
eventualele exemple care au fost introdus n model. Aceast caracteristic este foarte
important pentru nelegerea modelului i de ctre persoanele care nu au cunotine n
domeniul bazelor de date sau nu lucreaz n domeniul IT. Pentru a ilustra aceast
caracteristic, se va utiliza modelul surs ORM Employee, care este inclus n exemplele
furnizate de produsul Microsoft Visio for Enterprise Architects.
71
Pentru a deschide acest model se va utiliza opiunea: File | New | Browse Sample
Drawings apoi se va selecta folder-ul Database i fiierul exemplu surs ORM Employee,
dup care se va apsa butonul Open pentru a deschide acest model (figurile 8.26. i 8.27.).
Fig. 8.26. Alegerea folder-ului unde se afl

modelul surs ORM
Fig. 8.27. Alegerea modelului surs ORM
Modelul este alctuit din trei pagini numite:

Employee, Project, i Room. n mod
implicit n partea de jos a ferestrei Drawing vor apare numai ferestrele Database Properties
i Bussiness Rules.
Fig. 8.28. Modelul surs Employee

Pentru apelarea ferestrei Verbalizer, se va alege din meniul principal: Database | View |
Verbalizer. n acest moment fereastra nu va conine nici o informaie, deoarece nu a fost
selectat nici un element din modelul deschis.
Dac se dorete verbalizarea pentru un anumit element al modelului (o constrngere, un tip de
obiect, un tip de fapt etc), se va selecta respectivul element. n acest moment n fereastra
72
Verbalizer va apare verbalizarea (exprimarea) elementului selectat (figura 8.29.). n cazul

prezentat a fost selectat o constrngere de unicitate primar extern.
Fig. 8.29. Verbalizarea unei constrngeri de unicitate

primar extern
Dac se dorete verbalizarea pentru mai multe

elemente ale modelului, se va apsa butonul drept al
mouse-ului i se va trage n diagonal peste elementele respective. Toate aspectele modelului
din interiorul suprafeei selectate vor fi verbalizate (exprimate) (inclusiv exemplele de fapte
dac acestea au fost adugate, figura 8.30.). Fereastra va rmne deschis pn n momentul
n care se dorete nchiderea acesteia.
Fig. 8.30. Verbalizarea mai multor tipuri de fapte din modelul ORM
73
9. Generarea schemei fizice a bazei de date

Un model surs ORM nu poate fi transpus direct ntr-o baz de date fizic. Pentru a genera o
baz de date care are la baz un model surs ORM mai nti acest model trebuie adugat la un
proiect; urmtorul pas const n construirea modelului logic, care va putea fi utilizat apoi
pentru a genera, sau a actualiza o baz de dat fizic.
Reamintim c atunci cnd se adaug un model surs ORM la un proiect, i apoi se
construiete modelul logic, se efectueaz urmtoarele operaii:
Un proiect nou este creat care va conine modelul surs ORM.

Elementele modelului surs ORM sunt transpuse n obiecte logice echivalente din
modelul proiectului.
Proiectul este afiat n fereastra Tables andViews.
Fig. 9.1. Afiarea elementelor proiectului n fereastra

Tables andViews
Dup construirea modelului logic, se poate efectua una, sau ambele operaii care urmeaz:
Se poate genera o schem a bazei de date.

Se pot efectua modificri n modelul logic, iar apoi aceste modificri pot fi rescrise n
modelul surs ORM.
Referitor la modul n care se poate dezvolta un proiect, se pot face urmtoarele observaii:
Modelul logic care se proiecteaz poate fi baza de pornire a unui nou proiect, sau se
poate aduga unui proiect deja existent.
nainte de a dezvolta un nou proiect, este indicat s se verifice corectitudinea modelul
surs ORM prin intermediul opiunii Database | Model Error Check. Atunci cnd se
dezvolt un proiect, este indicat s se verifice corectitudinea modelul surs, analiznd
toate tipurile de erori care pot s apar.
Dup construirea proiectului, tabelele i relaiile dintre ele se pot aduce n pagina
Drawing, dup care acestea se pot modifica n funcie de cerinele proiectului.
Avnd la baz un model logic al bazei de date se poate construi modelul fizic al acesteia.
Modelul fizic al bazei de date
74
Pentru a genera schema intern pentru un sistem de gestiune a bazei de date se va utiliza
opiunea Database | Generate....
Fig. 9.2. Alegerea opiunii de generare a modelului fizic

al bazei de date
Pentru generarea modelului fizic (schema) a unei baze de date se poate utiliza Generate
Wizard. Prin intermediul ferestrei (figura 9.3.) se poate genera o nou baz de date direct
dac SGBD-ul ales suport acest lucru (se va bifa csua Generate new database). Dac
SGBD-ul ales nu suport crearea direct a bazei de date, va trebui utilizat un script .DDL
pentru a crea baza de date fizic.
Not nainte de a utiliza Generate Wizard, va trebui s se construiasc proiectul astfel nct
acesta s cuprind cele mai recente modificri din modelul surs ORM.
Soluia cea mai bun pentru generarea modelului fizic este de a se accepta setarea implicit, i
anume aceea de generare a fiierului .DDL. Este opiunea cea mai bun de ales, deoarece
script-ul .DDL generat poate fi utilizat mai departe n interiorul SGBD-ului ales. Ceilali pai
care trebuie urmai se refer la: alegerea driver-ului (de exemplu, Microsoft Access,
Microsoft SQL Server 2000 etc.); introducerea unui nume pentru baza de date (de
exemplu, TestePA), acceptarea setrilor implicite, i dac se dorete se poate vizualiza scriptul .DDL, care va fi salvat ca un fiier text.
Fig. 9.3. Generarea unei noi baze de

date
75
Fig. 9.4. Alegerea driver-ului i numelui bazei de date
Pasul urmtor const n afiarea tabelelor care vor fi create.
Fig. 9.5. Tabelele care vor face parte din baza de date creat
Fig. 9.6.- Generarea bazei de date fizice
Fig. 9.7.
unui script
Exist posibilitatea generrii

.DDL
76
Fig. 9.8. Posibilitatea migrrii modificrilor efectuate

ctre modelul surs
n urma acestei operaii n pagina Output vor apare toate mesajele referitoare la ncheierea cu
succes / insucces a acestei operaii.
Started generating the database
create table "Act_Ad_Serviciu"("Nr_Act_Aditional" char(10) not null, "Nr_Contr" char(10) not
null, "Cod_Serv" char(10) not null, "Cant_serv" smallint not null) ON 'PRIMARY'
alter table "Act_Ad_Serviciu" add constraint "Act_Ad_Serviciu_PK" primary key clustered
("Nr_Act_Aditional", "Nr_Contr", "Cod_Serv")
create table "Tip_conectivitate" ("Cod_Serv" char(10) not null, "Tip_con" char(20) not null) ON
'PRIMARY'
alter table "Tip_conectivitate" add constraint "Tip_conectivitate_PK" primary key clustered
("Cod_Serv", "Tip_con")
create table "Persoana"("Id_Pers" char(13) not null, "Nume" char(30) not null, "Adresa" char(30)
not null, "Telefon" char(13) null, "Mobil" char(13) null, "Tip_Persoana" char(20) not null constraint
"PersoanaTip_Persoana_Chk" check ("Tip_Persoana" in ('PF','PJ')) , "Abrev_Loc" char(2) not
null, "Casuta_postala" bit not null, "Abrev_Jud" char(2) not null) ON 'PRIMARY'
alter table "Persoana" add constraint Persoana_MR check (("Telefon" is not null) or ("Mobil" is
not null))
alter table "Persoana" add constraint "Persoana_PK" primary key clustered ("Id_Pers")
create table "Contract" ("Nr_Contr" char(10) not null, "Cod_Unic" char(13) not null, "CNP"
char(13) not null, "Tip_Contr" char(20) not null constraint "ContractTip_Contr_Chk" check
("Tip_Contr" in ('AgentEconomic','AgentVanzari','PersoanaJuridica','PersoanaFizica','Dealer')),
"Data_Contr" datetime not null, "Cod_Serv" char(10) not null) ON 'PRIMARY'
alter table "Contract" add constraint "Contract_PK" primary key clustered ("Nr_Contr")
create table "Cont_Bancar" ("Banca_Nume" char(15) not null constraint
"Cont_BancarBanca_Nume_Chk" check ("Banca_Nume" in
('BRD','BancPost','BCR','BancaIonTiriac','RaiffeisenBank')), "Nr_Cont_Bancar" char(20) not
null, "Cod_Unic" char(13) not null) ON 'PRIMARY'
alter table "Cont_Bancar" add constraint "Cont_Bancar_PK" primary key clustered
("Banca_Nume", "Nr_Cont_Bancar")
create table "Consum"("Cont_User" char(10) not null, "Ora_Conectare" datetime not null,
"Data_Consum" datetime not null, "Ora_Deconectare" datetime not null, "Trafic_Intrare"
numeric(10,0) not null, "Trafic_Iesire" numeric(10,0) not null, "Durata_Conectare" datetime not
null, "Trafic_Total" numeric(10,0) not null) ON 'PRIMARY'
77

alter table "Consum" add constraint "Consum_PK" primary key clustered ("Cont_User",
"Ora_Conectare", "Data_Consum")
create table "Serviciu"("Cod_Serv" char(10) not null, "Timp_acces" char(10) not null, "Trafic"
char(10) not null constraint "ServiciuTrafic_Chk" check ("Trafic" in ('MB','GB','Nelimitat')),
"Val_Serviciu" numeric(10,0) not null, "Mediu_Transmisie" char(20) not null, "Tarif_Conectare"
numeric(10,0) null) ON 'PRIMARY'
alter table "Serviciu" add constraint "Serviciu_PK" primary key clustered ("Cod_Serv")
create table "Act_Aditional"("Nr_Act_Aditional" char(10) not null, "Nr_Contr" char(10) not null,
"Data_Act_Ad" datetime not null) ON 'PRIMARY'
alter table "Act_Aditional" add constraint "Act_Aditional_PK" primary key clustered
("Nr_Act_Aditional", "Nr_Contr")
create table "Cont_Email"("Cont_User" char(10) not null, "Parola_User" char(10) not null,
"Cod_Unic" char(13) null, "CNP" char(13) null) ON 'PRIMARY'
alter table "Cont_Email" add constraint Cont_Email_excl check(("Cod_Unic" is null) or ("CNP" is
null))
alter table "Cont_Email" add constraint "Cont_Email_PK" primary key clustered("Cont_User")
create table "Localitate_Judet"("Abrev_Loc" char(2) not null, "Abrev_Jud" char(2) not null) ON
'PRIMARY'
alter table "Localitate_Judet" add constraint "Localitate_Judet_PK" primary key
clustered("Abrev_Loc", "Abrev_Jud")
create table "Localitate"("Denumire_Loc" char(20) not null, "Abrev_Loc" char(2) not null) ON
'PRIMARY'
alter table "Localitate" add constraint "Localitate_PK" primary key clustered("Abrev_Loc")
create table "Judet"("Abrev_Jud" char(2) not null, "Denumire_Jud" char(20) not null) ON
'PRIMARY'
alter table "Judet" add constraint "Judet_PK" primary key clustered("Abrev_Jud")
create table "Incasari"("Nr_Fact" char(10) not null, "Tip_Document" char(15) not null constraint
"IncasariTip_Document_Chk" check("Tip_Document" in ('OrdinPlata','Chitanta','FillaCEC')),
"Cod_Unic" char(13) null, "CNP" char(13) null, "Nr_Doc_Incasare" char(10) not null,
"Data_Incasarii" datetime not null, "Val_Incasare_Lei" numeric(10,0) null, "Val_Incasare_Dolari"
numeric(10,0) null) ON 'PRIMARY'
alter table "Incasari" add constraint Incasari_MR check(("Val_Incasare_Lei" is not null) or
("Val_Incasare_Dolari" is not null))
alter table "Incasari" add constraint "Incasari_PK" primary key clustered("Nr_Fact",
"Tip_Document")
create table "Factura"("Nr_Fact" char(10) not null, "Nr_Contr" char(10) not null, "Data_Fact"
datetime not null, "Serie_Fact" char(2) not null, "Val_Fact_Lei" numeric(10,0) null,
"Val_Fact_Dolari" numeric(10,0) null) ON 'PRIMARY'
alter table "Factura" add constraint Factura_MR check(("Val_Fact_Dolari" is not null) or
("Val_Fact_Lei" is not null))
alter table "Factura" add constraint "Factura_PK" primary key clustered("Nr_Fact")
create table "Agent"("Id_Pers" char(13) not null, "Nr_Reg_Comert" char(12) not null,
"Fax_Agent" char(13) not null, "Cod_Unic" char(13) not null) ON 'PRIMARY'
alter table "Agent" add constraint "Agent_PK" primary key clustered("Cod_Unic")
78

create table "Abonat"("Id_Pers" char(13) not null, "Prenume_Abonat" char(20) not null,
"Tip_Act_Identitate" char(20) not null constraint "AbonatTip_Act_Identitate_Chk" check
("Tip_Act_Identitate" in ('BI','CI')) , "Seria_Act_Identitate" char(2) not null,
"Nr_Act_Identitate" numeric(10,0) not null, "Emis_Politia" char(20) not null, "CNP" char(13) not
null) ON 'PRIMARY'
alter table "Abonat" add constraint "Abonat_PK" primary key clustered("CNP")
create index "Contract_IDX1" on "Contract"("Data_Contr") ON 'PRIMARY'
create index "Contract_IDX2" on "Contract"("Tip_Contr") ON 'PRIMARY'
alter table "Cont_Email" add constraint "Cont_Email_UC1" unique ("Parola_User")
create index "Localitate_IDX1" on "Localitate"("Denumire_Loc") ON 'PRIMARY'
alter table "Judet" add constraint "Judet_UC1" unique ("Denumire_Jud")
create index "Factura_IDX1" on "Factura"("Data_Fact") ON 'PRIMARY'
alter table "Agent" add constraint "Agent_UC1" unique ("Nr_Reg_Comert")
alter table "Agent" add constraint "Agent_UC2" unique ("Fax_Agent")
alter table "Agent" add constraint "Agent_UC3" unique ("Id_Pers")
create unique index "Abonat_AK1" on "Abonat" ("Nr_Act_Identitate", "Seria_Act_Identitate")
ON 'PRIMARY'
alter table "Abonat" add constraint "Abonat_UC2" unique ("Id_Pers")
create index "Abonat_IDX3" on "Abonat"("Prenume_Abonat") ON 'PRIMARY'
alter table "Act_Ad_Serviciu" add constraint "Act_Aditional_Act_Ad_Serviciu_FK1" foreign
key ("Nr_Act_Aditional", "Nr_Contr") references "Act_Aditional"("Nr_Act_Aditional",
"Nr_Contr") on update no action on delete no action
alter table "Act_Ad_Serviciu" add constraint "Serviciu_Act_Ad_Serviciu_FK1" foreign key
("Cod_Serv") references "Serviciu"("Cod_Serv") on update no action on delete no action
alter table "Tip_conectivitate" add constraint "Serviciu_Tip_conectivitate_FK1" foreign key
("Cod_Serv") references "Serviciu"("Cod_Serv") on update no action on delete no action
alter table "Persoana" add constraint "Localitate_Persoana_FK1" foreign key ("Abrev_Loc")
references "Localitate"("Abrev_Loc") on update no action on delete no action
alter table "Persoana" add constraint "Judet_Persoana_FK1" foreign key ("Abrev_Jud")
references "Judet"("Abrev_Jud") on update no action on delete no action
alter table "Contract" add constraint "Serviciu_Contract_FK1" foreign key ("Cod_Serv")
references "Serviciu"("Cod_Serv") on update no action on delete no action
alter table "Contract" add constraint "Agent_Contract_FK1" foreign key ("Cod_Unic")
references "Agent"("Cod_Unic") on update no action on delete no action
alter table "Contract" add constraint "Abonat_Contract_FK1" foreign key ("CNP") references
"Abonat"("CNP") on update no action on delete no action
alter table "Cont_Bancar" add constraint "Agent_Cont_Bancar_FK1" foreign key ("Cod_Unic")
alter table "Consum" add constraint "Cont_Email_Consum_FK1" foreign key ("Cont_User")
references "Cont_Email"("Cont_User") on update no action on delete no action
alter table "Act_Aditional" add constraint "Contract_Act_Aditional_FK1" foreign key
("Nr_Contr") references "Contract"("Nr_Contr") on update no action on delete no action
alter table "Cont_Email" add constraint "Agent_Cont_Email_FK1" foreign key ("Cod_Unic")
79

alter table "Cont_Email" add constraint "Abonat_Cont_Email_FK1" foreign key ("CNP")
references "Abonat"("CNP") on update no action on delete no action
alter table "Localitate_Judet" add constraint "Judet_Localitate_Judet_FK1" foreign key
("Abrev_Jud") references "Judet"("Abrev_Jud") on update no action on delete no action
alter table "Localitate_Judet" add constraint "Localitate_Localitate_Judet_FK1" foreign key
("Abrev_Loc") references "Localitate"("Abrev_Loc") on update no action on delete no action
alter table "Incasari" add constraint "Factura_Incasari_FK1" foreign key ("Nr_Fact")
references "Factura"("Nr_Fact") on update no action on delete no action
alter table "Incasari" add constraint "Abonat_Incasari_FK1" foreign key ("CNP") references
"Abonat"("CNP") on update no action on delete no action
alter table "Incasari" add constraint "Agent_Incasari_FK1" foreign key ("Cod_Unic") references
"Agent"("Cod_Unic") on update no action on delete no action
alter table "Factura" add constraint "Contract_Factura_FK1" foreign key ("Nr_Contr")
references "Contract"("Nr_Contr") on update no action on delete no action
alter table "Agent" add constraint "Persoana_Agent_FK1" foreign key ("Id_Pers") references
"Persoana"("Id_Pers") on update no action on delete no action
alter table "Abonat" add constraint "Persoana_Abonat_FK1" foreign key ("Id_Pers") references
"Persoana"("Id_Pers") on update no action on delete no action
Creating code
Completed generating the database.
Refetching code definition updated or generated to the database.
Refetching code Incasari_excl1 definition.
Refetching check definition for table Cont_Bancar.
Refetching check definition for table Incasari.
Refetching check definition for table Contract.
Refetching check definition for table Cont_Email.
Refetching check definition for table Serviciu.
Refetching check definition for table Persoana.
Refetching check definition for table Abonat.
Refetching check definition for table Factura.
Extracting/Refetching extended attribute for table 'Act_Ad_Serviciu'.
Extracting/Refetching extended attribute for key
'Act_Ad_Serviciu.Act_Aditional_Act_Ad_Serviciu_FK1'.
'Act_Ad_Serviciu.Serviciu_Act_Ad_Serviciu_FK1'.
Extracting/Refetching extended attribute for table 'Tip_conectivitate'.
'Tip_conectivitate.Serviciu_Tip_conectivitate_FK1'.
Extracting/Refetching extended attribute for table 'Persoana'.
Extracting/Refetching extended attribute for key 'Persoana.Localitate_Persoana_FK1'.
Extracting/Refetching extended attribute for key 'Persoana.Judet_Persoana_FK1'.
Extracting/Refetching extended attribute for table 'Contract'.
Extracting/Refetching extended attribute for key 'Contract.Contract_IDX1'.
Extracting/Refetching extended attribute for key 'Contract.Contract_IDX2'.
Extracting/Refetching extended attribute for key 'Contract.Serviciu_Contract_FK1'.
80

Extracting/Refetching extended attribute for key 'Contract.Agent_Contract_FK1'.
Extracting/Refetching extended attribute for key 'Contract.Abonat_Contract_FK1'.
Extracting/Refetching extended attribute for table 'Cont_Bancar'.
Extracting/Refetching extended attribute for key 'Cont_Bancar.Agent_Cont_Bancar_FK1'.
Extracting/Refetching extended attribute for table 'Consum'.
Extracting/Refetching extended attribute for key 'Consum.Cont_Email_Consum_FK1'.
Extracting/Refetching extended attribute for table 'Serviciu'.
Extracting/Refetching extended attribute for table 'Act_Aditional'.
Extracting/Refetching extended attribute for key 'Act_Aditional.Contract_Act_Aditional_FK1'.
Extracting/Refetching extended attribute for table 'Cont_Email'.
Extracting/Refetching extended attribute for key 'Cont_Email.Cont_Email_UC1'.
Extracting/Refetching extended attribute for key 'Cont_Email.Agent_Cont_Email_FK1'.
Extracting/Refetching extended attribute for key 'Cont_Email.Abonat_Cont_Email_FK1'.
Extracting/Refetching extended attribute for table 'Localitate_Judet'.
'Localitate_Judet.Judet_Localitate_Judet_FK1'.
'Localitate_Judet.Localitate_Localitate_Judet_FK1'.
Extracting/Refetching extended attribute for table 'Localitate'.
Extracting/Refetching extended attribute for key 'Localitate.Localitate_IDX1'.
Extracting/Refetching extended attribute for table 'Judet'.
Extracting/Refetching extended attribute for key 'Judet.Judet_UC1'.
Extracting/Refetching extended attribute for table 'Incasari'.
Extracting/Refetching extended attribute for key 'Incasari.Factura_Incasari_FK1'.
Extracting/Refetching extended attribute for key 'Incasari.Abonat_Incasari_FK1'.
Extracting/Refetching extended attribute for key 'Incasari.Agent_Incasari_FK1'.
Extracting/Refetching extended attribute for table 'Factura'.
Extracting/Refetching extended attribute for key 'Factura.Factura_IDX1'.
Extracting/Refetching extended attribute for key 'Factura.Contract_Factura_FK1'.
Extracting/Refetching extended attribute for table 'Agent'.
Extracting/Refetching extended attribute for key 'Agent.Agent_UC1'.
Extracting/Refetching extended attribute for key 'Agent.Persoana_Agent_FK1'.
Extracting/Refetching extended attribute for table 'Abonat'.
Extracting/Refetching extended attribute for key 'Abonat.Abonat_AK1'.
Extracting/Refetching extended attribute for key 'Abonat.Abonat_UC2'.
Extracting/Refetching extended attribute for key 'Abonat.Abonat_IDX3'.
Extracting/Refetching extended attribute for key 'Abonat.Persoana_Abonat_FK1'.
Fiierul .DDL generat este:
81

/* This SQL DDL script was generated by Microsoft Visual Studio (Release Date: LOCAL
BUILD). */
/*
/*
/*
/*
/*
/*
/*
Driver Used: Microsoft Visual Studio - Microsoft SQL Server Driver. */

Document: C:\ORM\ORM-Curs\Curs_ORM_PA\Capitole\ML_Servicii_Internet1BD.vsd. */
Time Created: 1 November 2004 12:36. */
Operation: From Visio Update Database Wizard. */
Connected data source: Teste */
Connected server: VEGA */
Connected database: TestePA */
/* Create new table "dbo"."Act_Ad_Serviciu". */

/* "dbo"."Act_Ad_Serviciu": Act_Aditional prevede prestarea Serviciu in Cant_serv */
/* "Nr_Act_Aditional": Role one (Act_Aditional) of fact: {Act_Aditional} prevede prestarea
Serviciu in Cant_serv. */
/* "Nr_Contr": Role one (Act_Aditional) of fact: {Act_Aditional} prevede prestarea Serviciu in
Cant_serv. */
/* Role one (Contract) of fact: {Contract} poate avea Act_Aditional. */
/* Role two (Nr_Contr) of fact: Contract is identified by {Nr_Contr}. */
/* "Cod_Serv": Role two (Serviciu) of fact: Act_Aditional prevede prestarea {Serviciu} in
Cant_serv. */
/* "Cant_serv": Role three (Cant_serv) of fact: Act_Aditional prevede prestarea Serviciu in
{Cant_serv}. */
create table "dbo"."Act_Ad_Serviciu" (
"Nr_Act_Aditional" char(10) not null,
"Nr_Contr" char(10) not null,
"Cod_Serv" char(10) not null,
"Cant_serv" smallint not null)
go
alter table "dbo"."Act_Ad_Serviciu"
add constraint "Act_Ad_Serviciu_PK" primary key ("Nr_Act_Aditional", "Nr_Contr",
"Cod_Serv")
go
/* Create new table "dbo"."Tip_conectivitate". */
/* "dbo"."Tip_conectivitate": Serviciu are TIP_CONECTIVITATE1 */
/*
"Cod_Serv": Serviciu are TIP_CONECTIVITATE1 */
/*
"Tip_con": Serviciu are TIP_CONECTIVITATE1 */
create table "dbo"."Tip_conectivitate" (
"Tip_con" char(20) not null)
go
alter table "dbo"."Tip_conectivitate"
add constraint "Tip_conectivitate_PK" primary key ("Cod_Serv", "Tip_con")
82

go
/* Create new table "dbo"."Persoana". */
/* "dbo"."Persoana": fiecare Persoana care are Tip_Persoana='Persoana fizica' este Abonat */
/* fiecare Persoana care are Tip_Persoana='Persoana juridica' este Agent */
/* "Id_Pers": fiecare Persoana care are Tip_Persoana='Persoana fizica' este Abonat */
/* "Nume": Persoana are Nume */
/* "Adresa": Persoana are Adresa */
/* "Telefon": Persoana are Telefon */
/* "Mobil": Persoana are Mobil */
/* "Tip_Persoana": Persoana este Tip_Persoana */
/* "Abrev_Loc": Persoana are adresa in Localitate */
/* "Casuta_postala": fiecare Persoana care are Tip_Persoana='Persoana fizica' este Abonat */
/* "Abrev_Jud": Persoana are adresa in Judet */
create table "dbo"."Persoana" (
"Id_Pers" char(13) not null,
"Nume" char(30) not null,
"Adresa" char(30) not null,
"Telefon" char(13) null,
"Mobil" char(13) null,
"Tip_Persoana" char(20) not null constraint "PersoanaTip_Persoana_Chk" check
("Tip_Persoana" in ('PF','PJ')),
"Abrev_Loc" char(2) not null,
"Casuta_postala" bit not null,
"Abrev_Jud" char(2) not null)
go
/* Create table level checks for table Persoana. */
alter table "dbo"."Persoana" add constraint Persoana_MR check (("Telefon" is not null) or
("Mobil" is not null))
go
alter table "dbo"."Persoana"
add constraint "Persoana_PK" primary key ("Id_Pers")
go
/* Create new table "dbo"."Contract". */
/* "dbo"."Contract": Table of Contract */
/*
"Nr_Contr": Contract is identified by Nr_Contr */
/*
"Cod_Unic": Agent intocmeste Contract */
/*
"CNP": Abonat incheie Contract */
/*
"Tip_Contr": Contract este de tipul Tip_Contr */
/*
"Data_Contr": Contract este ncheiat la Data_Contr */
83

/*
"Cod_Serv": Serviciu poate apartine unui Contract */
create table "dbo"."Contract" (
"Cod_Unic" char(13) not null,
"CNP" char(13) not null,
"Tip_Contr" char(20) not null constraint "ContractTip_Contr_Chk" check ("Tip_Contr"
in ('AgentEconomic','AgentVanzari','PersoanaJuridica','PersoanaFizica','Dealer')),
"Data_Contr" datetime not null,
"Cod_Serv" char(10) not null)
go
alter table "dbo"."Contract"
add constraint "Contract_PK" primary key ("Nr_Contr")
go
/* Create new table "dbo"."Cont_Bancar". */
/* "dbo"."Cont_Bancar": Table of Cont_Bancar */
/*
"Banca_Nume": Cont_Bancar este deschis la Banca_Nume */
/*
"Nr_Cont_Bancar": Cont_Bancar are Nr_Cont_Bancar */
/*
"Cod_Unic": Agent utilizeaza Cont_Bancar */
create table "dbo"."Cont_Bancar" (
"Banca_Nume" char(15) not null constraint "Cont_BancarBanca_Nume_Chk" check
("Banca_Nume" in ('BRD','BancPost','BCR','BancaIonTiriac','RaiffeisenBank')),
"Nr_Cont_Bancar" char(20) not null,
"Cod_Unic" char(13) not null)
go
alter table "dbo"."Cont_Bancar"
add constraint "Cont_Bancar_PK" primary key ("Banca_Nume", "Nr_Cont_Bancar")
go
/* Create new table "dbo"."Consum". */
/* "dbo"."Consum": Table of Consum */
/*
"Cont_User": Consum este identificat partial Cont_Email */
/*
Role two (Cont_Email) of fact: Consum este identificat partial {Cont_Email}. */
/*
Role two (Cont_User) of fact: Cont_Email is identified by {Cont_User}. */
/*
"Ora_Conectare": Consum contine Ora_Conectare */
/*
"Data_Consum": Consum se efectueaza la Data_Consum */
/*
"Ora_Deconectare": Consum contine Ora_Deconectare */
/*
"Trafic_Intrare": Consum are Trafic_Intrare */
/*
"Trafic_Iesire": Consum are Trafic_Iesire */
/*
"Durata_Conectare": Consum are Durata_Conectare ***/
/*
"Trafic_Total": Consum are Trafic_Total ***/
create table "dbo"."Consum" (
"Cont_User" char(10) not null,
84

"Ora_Conectare" datetime not null,
"Data_Consum" datetime not null,
"Ora_Deconectare" datetime not null,
"Trafic_Intrare" numeric(10,0) not null,
"Trafic_Iesire" numeric(10,0) not null,
"Durata_Conectare" datetime not null,
"Trafic_Total" numeric(10,0) not null)
go
alter table "dbo"."Consum"
add constraint "Consum_PK" primary key ("Cont_User", "Ora_Conectare",
"Data_Consum")
go
/* Create new table "dbo"."Serviciu". */
/* "dbo"."Serviciu": Table of Serviciu */
/*
"Cod_Serv": Cod_Serv identifies Serviciu */
/*
"Timp_acces": Serviciu se caracterizeaza prin Timp_acces */
/*
"Trafic": Serviciu se caracterizeaza prin Trafic */
/*
"Val_Serviciu": Serviciu are Val_Serviciu */
/*
"Mediu_Transmisie": Serviciu se efectueaza printr-un Mediu_Transmisie */
/*
"Tarif_Conectare": Serviciu poate avea Tarif_Conectare */
create table "dbo"."Serviciu" (
"Timp_acces" char(10) not null,
"Trafic" char(10) not null constraint "ServiciuTrafic_Chk" check ("Trafic" in
('MB','GB','Nelimitat')),
"Val_Serviciu" numeric(10,0) not null,
"Mediu_Transmisie" char(20) not null,
"Tarif_Conectare" numeric(10,0) null)
go
alter table "dbo"."Serviciu"
add constraint "Serviciu_PK" primary key ("Cod_Serv")
go
/* Create new table "dbo"."Act_Aditional". */
/* "dbo"."Act_Aditional": Table of Act_Aditional */
/*
"Nr_Act_Aditional": Act_Aditional este identificat partial de Nr_Act_Aditional */
/*
"Nr_Contr": Contract poate avea Act_Aditional */
/*
Role one (Contract) of fact: {Contract} poate avea Act_Aditional. */
/*
Role two (Nr_Contr) of fact: Contract is identified by {Nr_Contr}. */
/*
"Data_Act_Ad": Act_Aditional este intocmit la Data_Act_Ad */
create table "dbo"."Act_Aditional" (
"Nr_Act_Aditional" char(10) not null,
85

"Data_Act_Ad" datetime not null)
go
alter table "dbo"."Act_Aditional"
add constraint "Act_Aditional_PK" primary key ("Nr_Act_Aditional", "Nr_Contr")
go
/* Create new table "dbo"."Cont_Email". */
/* "dbo"."Cont_Email": Table of Cont_Email */
/*
"Cont_User": Cont_User identifies Cont_Email */
/*
"Parola_User": Cont_Email are Parola_User */
/*
"Cod_Unic": Agent poate detine Cont_Email */
/*
"CNP": Abonat poate detine Cont_Email */
create table "dbo"."Cont_Email" (
"Cont_User" char(10) not null,
"Parola_User" char(10) not null,
"Cod_Unic" char(13) null,
"CNP" char(13) null)
go
/* Create table level checks for table Cont_Email. */
alter table "dbo"."Cont_Email" add constraint Cont_Email_excl check (("Cod_Unic" is null) or
("CNP" is null))
go
alter table "dbo"."Cont_Email"
add constraint "Cont_Email_PK" primary key ("Cont_User")
go
/* Create new table "dbo"."Localitate_Judet". */
/* "dbo"."Localitate_Judet": Localitate face parte din Judet */
/*
"Abrev_Loc": Localitate face parte din Judet */
/*
"Abrev_Jud": Localitate face parte din Judet */
create table "dbo"."Localitate_Judet" (
"Abrev_Loc" char(2) not null,
"Abrev_Jud" char(2) not null)
go
alter table "dbo"."Localitate_Judet"
add constraint "Localitate_Judet_PK" primary key ("Abrev_Loc", "Abrev_Jud")
go
86

/* Create new table "dbo"."Localitate". */
/* "dbo"."Localitate": Table of Localitate */
/*
"Denumire_Loc": Localitate are Denumire_Loc */
/*
"Abrev_Loc": Localitate is identified by Abrev_Loc */
create table "dbo"."Localitate" (
"Denumire_Loc" char(20) not null,
"Abrev_Loc" char(2) not null)
go
alter table "dbo"."Localitate"
add constraint "Localitate_PK" primary key ("Abrev_Loc")
go
/* Create new table "dbo"."Judet". */
/* "dbo"."Judet" : Table of Judet */
/*
"Abrev_Jud": Abrev_Jud identifies Judet */
/*
"Denumire_Jud": Judet are Denumire_Jud */
create table "dbo"."Judet" (
"Abrev_Jud" char(2) not null,
"Denumire_Jud" char(20) not null)
go
alter table "dbo"."Judet"
add constraint "Judet_PK" primary key ("Abrev_Jud")
go
/* Create new table "dbo"."Incasari". */
/* "dbo"."Incasari" : Table of Incasari */
/*
"Nr_Fact se efectueaza pe baza Factura */": Incasari
/*
Role two (Factura) of fact: Incasari se efectueaza pe baza {Factura}. */
/*
Role two (Nr_Fact) of fact: Factura is identified by {Nr_Fact}. */
/*
"Tip_Document": Incasari se face pe baza Tip_Document */
/*
"Cod_Unic": Agent plateste Incasari */
/*
"CNP": Abonat plateste Incasari */
/*
"Nr_Doc_Incasare": Incasari are Nr_Document_Incasare */
/*
"Data_Incasarii": Incasari se efectueaza la Data_Incasarii */
/*
"Val_Incasare_Lei": Incasari are o Val_Incasare_Lei */
/*
"Val_Incasare_Dolari": Incasari are o Val_Incasare_Dolari ***/
create table "dbo"."Incasari" (
"Nr_Fact" char(10) not null,
"Tip_Document" char(15) not null constraint "IncasariTip_Document_Chk" check
("Tip_Document" in ('OrdinPlata','Chitanta','FillaCEC')) ,
"CNP" char(13) null,
87

"Nr_Doc_Incasare" char(10) not null,
"Data_Incasarii" datetime not null,
"Val_Incasare_Lei" numeric(10,0) null,
"Val_Incasare_Dolari" numeric(10,0) null)
go
/* Create table level checks for table Incasari. */
alter table "dbo"."Incasari" add constraint Incasari_MR check (("Val_Incasare_Lei" is not null)
or ("Val_Incasare_Dolari" is not null))
go
alter table "dbo"."Incasari"
add constraint "Incasari_PK" primary key ("Nr_Fact", "Tip_Document")
go
/* Create new table "dbo"."Factura". */
/* "dbo"."Factura" : Table of Factura */
/*
"Nr_Fact": Nr_Fact identifies Factura */
/*
"Nr_Contr": Factura este intocmita pe baza Contract pe baza */
/*
"Data_Fact": Factura este emisa la Data_Fact */
/*
"Serie_Fact": Factura are Serie_Fact */
/*
"Val_Fact_Lei": Factura are Val_Fact_Lei ***/
/*
"Val_Fact_Dolari": Factura are Val_Fact_Dolari */
create table "dbo"."Factura" (
"Data_Fact" datetime not null,
"Serie_Fact" char(2) not null,
"Val_Fact_Lei" numeric(10,0) null,
"Val_Fact_Dolari" numeric(10,0) null)
go
/* Create table level checks for table Factura. */
alter table "dbo"."Factura" add constraint Factura_MR check (("Val_Fact_Dolari" is not null) or
go
alter table "dbo"."Factura"
add constraint "Factura_PK" primary key ("Nr_Fact")
go
/* Create new table "dbo"."Agent". */
/* "dbo"."Agent": Table of Agent */
88

/*
"Id_Pers": fiecare Persoana care are Tip_Persoana='Persoana fizica' este Abonat */
/*
fiecare Persoana care are Tip_Persoana='Persoana juridica' este Agent */
/*
"Nr_Reg_Comert": Agent este inregistrat cu Nr_Reg_Comert */
/*
"Fax_Agent": Agent are Fax_Agent */
/*
"Cod_Unic": Agent is identified by Cod_Unic */
create table "dbo"."Agent" (
"Nr_Reg_Comert" char(12) not null,
"Fax_Agent" char(13) not null,
"Cod_Unic" char(13) not null)
go
alter table "dbo"."Agent"
add constraint "Agent_PK" primary key ("Cod_Unic")
go
/* Create new table "dbo"."Abonat". */
/* "dbo"."Abonat" : Table of Abonat */
/*
"Id_Pers": fiecare Persoana care are Tip_Persoana='Persoana fizica' este Abonat */
/*
fiecare Persoana care are Tip_Persoana='Persoana juridica' este Agent */
/*
"Prenume_Abonat": Abonat are Prenume_Abona */
/*
"Tip_Act_Identitate": Abonat are Tip_Act_Identitate */
/*
"Seria_Act_Identitate": Abonat are act identitate cu Seria_Act_Identitate */
/*
"Nr_Act_Identitate": Abonat are act identitate cu Nr_Act_Identitate */
/*
"Emis_Politia": Abonat are act identitate emis de Emis_Politia */
/*
"CNP": Abonat is identified by CNP */
create table "dbo"."Abonat" (
"Prenume_Abonat" char(20) not null,
"Tip_Act_Identitate" char(20) not null constraint "AbonatTip_Act_Identitate_Chk"
check ("Tip_Act_Identitate" in ('BI','CI')),
"Seria_Act_Identitate" char(2) not null,
"Nr_Act_Identitate" numeric(10,0) not null,
"Emis_Politia" char(20) not null,
"CNP" char(13) not null)
go
alter table "dbo"."Abonat"
add constraint "Abonat_PK" primary key ("CNP")
go
/* Add the remaining keys, constraints and indexes for the table "dbo"."Contract". */
create index "Contract_IDX1" on "dbo"."Contract" ("Data_Contr")
go
89

create index "Contract_IDX2" on "dbo"."Contract" ("Tip_Contr")
go
/* Add the remaining keys, constraints and indexes for the table "dbo"."Cont_Email". */
alter table "dbo"."Cont_Email" add constraint "Cont_Email_UC1" unique ("Parola_User")
go
/* Add the remaining keys, constraints and indexes for the table "dbo"."Localitate". */
create index "Localitate_IDX1" on "dbo"."Localitate" ("Denumire_Loc")
go
/* Add the remaining keys, constraints and indexes for the table "dbo"."Judet". */
alter table "dbo"."Judet" add constraint "Judet_UC1" unique ("Denumire_Jud")
go
/* Add the remaining keys, constraints and indexes for the table "dbo"."Factura". */
create index "Factura_IDX1" on "dbo"."Factura" ("Data_Fact")
go
/* Add the remaining keys, constraints and indexes for the table "dbo"."Agent". */
alter table "dbo"."Agent" add constraint "Agent_UC1" unique ("Nr_Reg_Comert")
go
alter table "dbo"."Agent" add constraint "Agent_UC2" unique ("Fax_Agent")
go
alter table "dbo"."Agent" add constraint "Agent_UC3" unique ("Id_Pers")
go
/* Add the remaining keys, constraints and indexes for the table "dbo"."Abonat". */
create unique index "Abonat_AK1" on "dbo"."Abonat" ("Nr_Act_Identitate",
"Seria_Act_Identitate")
go
alter table "dbo"."Abonat" add constraint "Abonat_UC2" unique ("Id_Pers")
go
90

create index "Abonat_IDX3" on "dbo"."Abonat" ("Prenume_Abonat")
go
/* Add foreign key constraints to table "dbo"."Act_Ad_Serviciu". */
add constraint "Act_Aditional_Act_Ad_Serviciu_FK1" foreign key
("Nr_Act_Aditional", "Nr_Contr")
references "dbo"."Act_Aditional" ("Nr_Act_Aditional", "Nr_Contr") on update no
action on delete no action
go
add constraint "Serviciu_Act_Ad_Serviciu_FK1" foreign key ("Cod_Serv")
references "dbo"."Serviciu" ("Cod_Serv") on update no action on delete no action
go
/* Add foreign key constraints to table "dbo"."Tip_conectivitate". */
alter table "dbo"."Tip_conectivitate"
add constraint "Serviciu_Tip_conectivitate_FK1" foreign key ("Cod_Serv")
go
/* Add foreign key constraints to table "dbo"."Persoana". */
add constraint "Localitate_Persoana_FK1" foreign key ("Abrev_Loc")
references "dbo"."Localitate" ("Abrev_Loc") on update no action on delete no action
go
add constraint "Judet_Persoana_FK1" foreign key ("Abrev_Jud")
references "dbo"."Judet" ("Abrev_Jud") on update no action on delete no action
go
/* Add foreign key constraints to table "dbo"."Contract". */
add constraint "Serviciu_Contract_FK1" foreign key ("Cod_Serv")
go
add constraint "Agent_Contract_FK1" foreign key ("Cod_Unic")
references "dbo"."Agent" ("Cod_Unic") on update no action on delete no action
91

go
add constraint "Abonat_Contract_FK1" foreign key ("CNP")
references "dbo"."Abonat" ("CNP") on update no action on delete no action
go
/* Add foreign key constraints to table "dbo"."Cont_Bancar". */
alter table "dbo"."Cont_Bancar"
add constraint "Agent_Cont_Bancar_FK1" foreign key ("Cod_Unic")
go
/* Add foreign key constraints to table "dbo"."Consum". */
alter table "dbo"."Consum"
add constraint "Cont_Email_Consum_FK1" foreign key ("Cont_User")
references "dbo"."Cont_Email" ("Cont_User") on update no action on delete no action
go
/* Add foreign key constraints to table "dbo"."Act_Aditional". */
alter table "dbo"."Act_Aditional"
add constraint "Contract_Act_Aditional_FK1" foreign key ("Nr_Contr")
references "dbo"."Contract" ("Nr_Contr") on update no action on delete no action
go
/* Add foreign key constraints to table "dbo"."Cont_Email". */
add constraint "Agent_Cont_Email_FK1" foreign key ("Cod_Unic")
go
add constraint "Abonat_Cont_Email_FK1" foreign key ("CNP")
go
/* Add foreign key constraints to table "dbo"."Localitate_Judet". */
add constraint "Judet_Localitate_Judet_FK1" foreign key ("Abrev_Jud")
references "dbo"."Judet" ("Abrev_Jud") on update no action on delete no action
go
92

add constraint "Localitate_Localitate_Judet_FK1" foreign key ("Abrev_Loc")
references "dbo"."Localitate" ("Abrev_Loc") on update no action on delete no action
go
/* Add foreign key constraints to table "dbo"."Incasari". */
add constraint "Factura_Incasari_FK1" foreign key ("Nr_Fact")
references "dbo"."Factura" ("Nr_Fact") on update no action on delete no action
go
add constraint "Abonat_Incasari_FK1" foreign key ( "CNP")
go
add constraint "Agent_Incasari_FK1" foreign key ("Cod_Unic")
go
/* Add foreign key constraints to table "dbo"."Factura". */
alter table "dbo"."Factura"
add constraint "Contract_Factura_FK1" foreign key ("Nr_Contr")
references "dbo"."Contract" ("Nr_Contr") on update no action on delete no action
go
/* Add foreign key constraints to table "dbo"."Agent". */
alter table "dbo"."Agent"
add constraint "Persoana_Agent_FK1" foreign key ("Id_Pers")
references "dbo"."Persoana" ("Id_Pers") on update no action on delete no action
go
/* Add foreign key constraints to table "dbo"."Abonat". */
alter table "dbo"."Abonat"
add constraint "Persoana_Abonat_FK1" foreign key ("Id_Pers")
references "dbo"."Persoana" ("Id_Pers") on update no action on delete no action
go
/* Create procedure/function Incasari_excl1. */
/* /* The constraint: */ */
93

/* /* Assuming a is an instance of Abonat or Agent then */ */
/* /*
For each a, at most one of the following holds: */ */
/* /*
some Incasari poate fi efectuata de la Abonat a; */ */
/* /*
some Incasari poate fi efectuata de la Agent a. */ */
/* /* is enforced by the following DDL. */ */
Create Procedure Incasari_excl1 as
/* Microsoft Visual Studio generated procedure code. */
if (
not exists (select * from "dbo"."Incasari" T0, "dbo"."Incasari" T1
where T0."CNP" = T1."Cod_Unic")
)
return 1
else
return 2
/* End Incasari_excl1 */
go
/* This is the end of the Microsoft Visual Studio generated SQL DDL script. */
Pentru a afla date referitoare la structura tabelelor care au fost generate se poate selecta pagina
Verbalizer, n care se va selecta tabela pentru care se doresc aceste informaii.
Table Persoana is composed of nine columns.
Column Id_Pers char(13) is required.
Column Nume char(30) is required.
Column Adresa char(30) is required.
Column Telefon char(13) is optional.
Column Mobil char(13) is optional.
Column Tip_Persoana char(20) is required.
Column Abrev_Loc char(2) is required.
Column Casuta_postala bit is required.
Column Abrev_Jud char(2) is required.
Primary key: Id_Pers.
Table Persoana is the target of two foreign key relationships with tables Agent and
Abonat.
Table Persoana is the source for two foreign key relationships with tables Localitate
and Judet.
Notes: fiecare Persoana care are Tip_Persoana='Persoana fizica' este Abonat
fiecare Persoana care are Tip_Persoana='Persoana juridica' este Agent.
Table Incasari is composed of eight columns.
Column Nr_Fact char(10) is required.
Column Tip_Document char(15) is required.
Column Cod_Unic char(13) is optional.
Column CNP char(13) is optional.
Column Nr_Doc_Incasare char(10) is required.
Column Data_Incasarii datetime is required.
Column Val_Incasare_Lei numeric(10;0) is optional.
94

Column Val_Incasare_Dolari numeric(10;0) is optional.
Primary key: (Nr_Fact; Tip_Document).
Table Incasari is the source for three foreign key relationships with tables Factura,
Abonat and Agent.
Notes: Table of Incasari.
Table Contract is composed of six columns, two non-unique indexes.
Column Nr_Contr char(10) is required.
Column Cod_Unic char(13) is required.
Column CNP char(13) is required.
Column Tip_Contr char(20) is required.
Column Data_Contr datetime is required.
Column Cod_Serv char(10) is required.
Primary key: Nr_Contr.
Table Contract is the target of two foreign key relationships with tables Act_Aditional
and Factura.
Table Contract is the source for three foreign key relationships with tables Serviciu,
Agent and Abonat.
Non-unique indexes
1: Non-unique index 'Contract_IDX1' on column Data_Contr is ascending
2: Non-unique index 'Contract_IDX2' on column Tip_Contr is ascending
Notes: Table of Contract.
9.1. Despre constrngeri i modul

n care acestea sunt transpuse n
tabelele bazei de date
Pn n momentul de fa s-a artat modul n care este proiectat o schem conceptual ORM,
cum aceasta este transpus ntr-o schem logic a bazei de date, precum i necesitatea
generrii script-ului .DDL pentru schema fizic a bazei de date. Transpunerea diferitelor
constrngeri, care sunt declarate prin intermediul modelului surs ORM, n cadrul tabelelor
dintr-o baz de date joac un rol deosebit de important. De aceea n continuare se vor
exemplifica anumite constrngeri, care au fost declarate n modelul surs ORM, i care a stat
la baza generrii modelului logic i apoi a modelului fizic, i modul n care acestea sunt
transpuse n tabelele respective, precum i modul n care acestea pot fi optimizate. Vom utiliza
pentru nceput modelul surs ORM (figura nr. 9.9.A) care transpus ntr-un model logic arat
ca n figura nr.9.9.B.
95
Fig. 9.9. Transpunerea modelului ORM

n modelul logic pentru tabela Incasari i Factura
Dup cum s-a mai artat notaia PK indic cheile primare, FKn indic cheile strine, i
notaia Un indic constrngeri de unicitate. Dac s-a ales SQL Server 2000, i s-a generat
script-ul .DDL pentru aceast schem, acesta va arat astfel.
create table "Incasari" (
"Tip_Document" char(15) not null constraint "IncasariTip_Document_Chk" check
("Tip_Document" in ('OrdinPlata','Chitanta','FillaCEC')),
"CNP" char(13) null,
"Nr_Doc_Incasare" char(10) not null,
"Data_Incasarii" datetime not null,
"Val_Incasare_Lei" numeric(10,0) null,
"Val_Incasare_Dolari" numeric(10,0) null) ON 'PRIMARY'
/* Create table level checks for table Incasari. */
alter table "Incasari" add constraint Incasari_MR check ( ("Val_Incasare_Lei" is not null) or
("Val_Incasare_Dolari" is not null))
alter table "Incasari"
add constraint "Incasari_PK" primary key clustered ("Nr_Fact", "Tip_Document")
create table "Factura" (
"Data_Fact" datetime not null,
"Serie_Fact" char(2) not null,
"Val_Fact_Lei" numeric(10,0) null,
"Val_Fact_Dolari" numeric(10,0) null) ON 'PRIMARY'
96

/* Create table level checks for table Factura. */
alter table "Factura" add constraint Factura_MR check ( ("Val_Fact_Dolari" is not null) or
alter table "Factura"
add constraint "Factura_PK" primary key clustered ("Nr_Fact")
add constraint "Factura_Incasari_FK1" foreign key ("Nr_Fact")
references "Factura" ("Nr_Fact") on update no action on delete no action
add constraint "Abonat_Incasari_FK1" foreign key ("CNP")
references "Abonat" ("CNP") on update no action on delete no action
add constraint "Agent_Incasari_FK1" foreign key ("Cod_Unic")
references "Agent" ("Cod_Unic") on update no action on delete no action
alter table "Factura"
add constraint "Contract_Factura_FK1" foreign key ("Nr_Contr")
references "Contract" ("Nr_Contr") on update no action on delete no action alter table
"Factura"
De remarcat c toate tipurile de date au fost modificate (tipul implicit este char(10)). Modul n
care se pot modifica tipurile datelor se va explica ntr-un subcapitol separat. Vom ncepe cu
acele constrngeri care se refer la indeci. n timp ce indeci mresc viteza de acces la
informaiile stocate ntr-o baz de date, ei pot de asemenea s duc la ncetinirea procesului de
actualizare a acesteia, deoarece actualizrile se efectueaz i asupra indecilor.
SQL Server, ca i alte SGBD-uri, creeaz n mod automat un index unic pentru cheia primar,
ceea ce furnizeaz o cale eficient pentru aplicarea constrngerilor de unicitate. Pe
deasupra, coloane care sunt chei primare sunt deseori utilizate n operaii de sortare i
asociere, deci necesit un acces eficient. n timp ce declaraiile de cheie primar ntr-un
script .DDL determin crearea automat a indecilor pentru ei (de exemplu, SQL Server), nu
este necesar declararea explicit a indecilor pentru coloanele chei primare (notate cu PK).
Coloanele care au notaia Un reprezint coloane care au valori unice i obligatorii (asupra
lor au fost impuse constrngeri de unicitate), i prin urmare reprezint chei alternative pentru
o tabel. Script-ul .DDL include o astfel de declaraie prin care se adaug o constrngere de
unicitate pentru acea coloan.
Dup cum se observ din figura 9.10.B, coloana Seria_Act_Identitate este obligatorie i
are o valoare unic, i prin urmare furnizeaz o cheie alternativ pentru tabela Abonat. Scriptul .DDL care este generat va include o declaraie i va aduga o constrngere de unicitate
(Abonat_AK1_UC1) pentru aceast coloan. SQL Server creeaz automat indeci unici pe
coloanele pentru care au fost declarate constrngeri de unicitate. De aici rezult c nu este
necesar declararea explicit a unui index unic pentru aceast coloan. Cu toate acestea
97
instrumentul include suplimentar o comand de creare a indexului unic pentru aceast

coloan.
Fig. 9.10. Transpunerea modelului ORM

n modelul logic pentru tabela Abonat
create unique index "Abonat_AK1" on "Abonat" ("Are Seria_Act_Identitate")
alter table "Abonat" add constraint "Abonat_AK1_UC1" unique ("Are Seria_Act_Identitate")
Acelai lucru este valabil i pentru coloana Nr_Act_Identitate.

create unique index "Abonat_AK1" on "Abonat"(" Nr_Act_Identitate ")
alter table "Abonat" add constraint "Abonat_AK1_UC1" unique("Are Nr_Act_Identitate")
Pentru ca acest lucru s nu se repete n script-ul .DDL generat se vor executa urmtoarele
operaii. Se va selecta tabela Abonat i se va deschide fereastra Database Properties. Aici se
va selecta categoria Indexes, se va deschide lista derulant Index Type, i se va alege
opiunea Unique constraint only (n loc de opiunea implicit Unique index with
constraint on top), dup cum se observ din figura 9.11.
Fig. 9.11. - Alegerea implementrii unicitii

cu o constrngere unic declarativ
98
Aceeai operaie va fi efectuat pentru toate tabelele din modelul logic. Dup efectuarea
acestor modificri se va efectua salvarea i migrarea acestora ctre modelul surs ORM. Dac
se va genera din nou script-ul .DDL se va observa c unicitatea pentru coloanele asupra crora
s-au efectuat modificrile respective, va fi introdus prin intermediul unei constrngeri de
unicitate, "Nume tabela_UC1" fr alt clauz suplimentar de index unic.
Pentru un exemplu complet se va utiliza modelul logic din figura 9.2., sau din figura 8.5. din
cadrul capitolului referitor la generarea modelul logic al bazei de date.
Se tie c indecii aparin nivelului fizic. Cu toate acestea, este posibil ca indecii s fie
specificai direct n modelul surs ORM. Aceasta permite controlarea procesul de transpunere
prin comentarea (adnotarea) modelului conceptual cu detalii de implementare. Modalitatea de
declarare a unei constrngeri index a fost explicat n subcapitolul 7.6.2.
S presupunem c se dorete la un moment dat s se tie despre un serviciu din cte contracte
i din cte acte adiionale face parte (precum i alte detalii despre serviciul respectiv: valoare,
caracteristici etc.) cunoscndu-se codul serviciului. Pentru a face acest lucru n mod eficient
va trebui s se declare un index pe rolul ndeplinit de Serviciu(Cod_Serv) n modelul surs
ORM.
99
Anexe
Anexa nr.1 Raportul constrngerilor
ML_Servicii_Internet1
Constraint kind: Uniqueness
Record:
1
Constraint type: Uniqueness
ID: 458
Verbalization: Each Consum este identificat partial at most one Cont_Email.
Notes:
Statistics:
One relationship, one role
Defined over:
Record:
2
ID: 540
Verbalization: Each Serviciu se caracterizeaza prin at most one Timp_acces.
Notes:
Statistics:
Defined over:
Record:
3
ID: 469
Verbalization: For each Fax_Agent f, at most one Agent are Fax_Agent f.
Notes:
Statistics:
Defined over: Agent are
Record:
4
ID: 538
Verbalization: Each Serviciu se caracterizeaza prin at most one Trafic.
Notes:
Statistics:
Defined over:
Record:
5
ID: 395
Verbalization: Each Act_Aditional apartine unui at most one Contract.
Notes:
Statistics:
Defined over: Contract poate avea
Record:
6
ID: 536
Verbalization: Each Serviciu are at most one Val_Serviciu.
Notes:
Statistics:
Defined over:
Record:
7
ID: 397
Anexe
100

Verbalization:
Notes:
Statistics:
Defined over:
Each Contract este intocmit de at most one Agent.

Record:
8
Constraint type: Primary uniqueness
ID: 399
Verbalization: For each Banca b and Nr_Cont_Bancar n
there is at most one Cont_Bancar that
este deschis la Banca b and are Nr_Cont_Bancar n.
Cont_Bancar is primarily identified by this unique combination.
Notes:
Statistics:
Two relationships, two total roles
Defined over:
Cont_Bancar este deschis la
Cont_Bancar are
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
9
Uniqueness
533
Each Serviciu se efectueaza at most one printrun Mediu_Transmisie.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
10
Uniqueness
532
Each Serviciu poate avea at most one Tarif_Conectare.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
11
Uniqueness
467
Each Contract prevede prestarea unui at most one Serviciu.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
12
Uniqueness
530
Each Contract este de tipul at most one Tip_Contr.
Record:
Constraint type:
ID:
Verbalization:
13
Uniqueness
391
It is possible that some Serviciu are more than one Tip_conectivitate and
that more than one Serviciu are some Tip_conectivitate.
Notes:
Statistics:
Defined over:
One relationship, two total roles
Record:
Constraint type:
ID:
Verbalization:
14
Uniqueness
528
Each Contract este ncheiat la at most one Data_Contr.
Anexe
101

Notes:
Statistics:
Defined over:
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
15
Uniqueness
400
Each Cont_Bancar are at most one Nr_Cont_Bancar.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
16
Uniqueness
526
Each Factura este emisa la at most one Data_Fact.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
17
Uniqueness
473
Each Cont_Email are at most one Parola_User.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
19
Uniqueness
520
Each Factura are at most one Val_Fact_Lei.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
20
Uniqueness
519
Each Factura are at most one Val_Fact_Dolari.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
21
Uniqueness
411
Each Persoana are adresa in at most one Judet.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
22
Uniqueness
517
Each Incasari are at most one Nr_Document_Incasare.

18
Uniqueness
524
Each Factura are at most one Serie_Fact.
Anexe
102

Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
23
Uniqueness
417
Each Persoana este at most one Tip_Persoana.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
24
Uniqueness
515
Each Incasari se efectueaza la at most one Data_Incasarii.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
25
Uniqueness
514
Each Incasari are o at most one Val_Incasare_Lei.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
26
Uniqueness
513
Each Incasari are o at most one Val_Incasare_Dolari.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
27
Uniqueness
404
Each Cont_Bancar este utilizat de at most one Agent.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
28
Uniqueness
511
Each Incasari se face pe baza at most one Tip_Document.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
29
Uniqueness
402
Each Cont_Bancar este deschis la at most one Banca.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
30
Uniqueness
421
Each Persoana are at most one Telefon.
Record:
31

Agent utilizeaza
Anexe
103

Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
Uniqueness
508
Each Incasari se efectueaza pe baza at most one Factura.
Record:
Constraint type:
ID:
Verbalization:
32
Primary uniqueness
507
For each Factura f and Tip_Document t
there is at most one Incasari that
se efectueaza pe baza Factura f and se face pe baza Tip_Document t.
Incasari is primarily identified by this unique combination.
Notes:
Statistics:
Defined over:
Incasari se efectueaza pe baza
Incasari se face pe baza
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
33
Uniqueness
420
For each Mobil m, at most one Persoana are Mobil m.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
34
Uniqueness
505
For each Nr_Reg_Comert n, at most one Agent este inregistrat cu Nr_Reg_Comert n.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
35
Uniqueness
504
Each Agent este inregistrat cu at most one Nr_Reg_Comert.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
36
Uniqueness
503
Each Agent are at most one Fax_Agent.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
37
Uniqueness
422
For each Telefon t, at most one Persoana are Telefon t.
Record:
Constraint type:
ID:
38
Primary uniqueness
394

Persoana are

Agent este inregistrat cu

Persoana are
Anexe
104

Verbalization:
Notes:
Statistics:
For each Contract c and Nr_Act_Aditional n

there is at most one Act_Aditional that
Contract c poate avea some Act_Aditional
some Act_Aditional este identificat partial de Nr_Act_Aditional n.
Act_Aditional is primarily identified by the above combination.
Defined over:
Act_Aditional este identificat partial de
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
39
Uniqueness
500
Each Abonat are at most one Tip_Act_Identitate.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
40
Uniqueness
425
Each Persoana are at most one Nume.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
41
Uniqueness
498
Each Abonat are act identitate cu at most one Seria_Act_Identitate.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
42
Uniqueness
423
Each Persoana are at most one Adresa.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
43
Uniqueness
496
Each Abonat are act identitate cu at most one Nr_Act_Identitate.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
44
Uniqueness
419
Each Persoana are at most one Mobil.
Record:
Constraint type:
ID:
Verbalization:
45
Uniqueness
494
Each Abonat are act identitate emis de at most one Emis_Politia.
Anexe
105

Notes:
Statistics:
Defined over:
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:

46
Uniqueness
493
For each Nr_Act_Identitate n and Seria_Act_Identitate s
there is at most one Abonat that
are act identitate cu Nr_Act_Identitate n and are act identitate cu Seria_Act_Identitate s.
Defined over:
Abonat are act identitate cu
Abonat are act identitate cu
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
47
Uniqueness
492
Each Abonat are at most one Prenume_Abonat.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
49
Uniqueness
490
Each Act_Aditional este identificat partial de at most one Nr_Act_Aditional.
Record:
Constraint type:
ID:
Verbalization:
50
Primary uniqueness
437
*Given any Act_Aditional and Serviciu
that Act_Aditional prevede prestarea that Serviciu in at most one Cant_serv.
Notes:
Statistics:
Defined over:

48
Uniqueness
428
Each Cont_Email poate apartine at most one Abonat.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
51
Uniqueness
488
Each Localitate are at most one Denumire_Loc.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
52
Uniqueness
392
Each Contract este incheiat at most one Abonat.

Abonat incheie
Anexe
106

Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
53
Uniqueness
429
Each Cont_Email poate apartine at most one Agent.
Record:
Constraint type:
ID:
Verbalization:
54
Uniqueness
485
It is possible that some Localitate face parte din more than one Judet and
that more than one Localitate face parte din some Judet.
Notes:
Statistics:
Defined over:
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:

55
Primary uniqueness
440
For each Cont_Email c, Ora_Conectare o and Data_Consum d
there is at most one Consum that
este identificat partial Cont_Email c and contine Ora_Conectare o and se efectueaza la
Data_Consum d.
Consum is primarily identified by this unique combination.
Three relationships, three total roles
Defined over:
Consum este identificat partial
Consum contine
Consum se efectueaza la
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
56
Uniqueness
483
For each Denumire_Jud d, at most one Judet are Denumire_Jud d.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
57
Uniqueness
482
Each Judet are at most one Denumire_Jud.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
58
Uniqueness
385
Each Factura este intocmita pe baza at most one Contract pe baza.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
59
Uniqueness
389
Each Incasari poate fi efectuata de la at most one Agent.

Judet are
Anexe
107

Defined over:
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
60
Uniqueness
390
Each Incasari poate fi efectuata de la at most one Abonat.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
61
Uniqueness
446
Each Consum are at most one Durata_Conectare.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
62
Uniqueness
474
For each Parola_User p, at most one Cont_Email are Parola_User p.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
63
Uniqueness
414
Each Persoana are adresa in at most one Localitate.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
64
Uniqueness
442
Each Act_Aditional este intocmit la at most one Data_Act_Ad.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
65
Uniqueness
452
Each Consum contine at most one Ora_Deconectare.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
66
Uniqueness
450
Each Consum are at most one Trafic_Intrare.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
67
Uniqueness
448
Each Consum are at most one Trafic_Iesire.

Cont_Email are
Anexe
108

Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
68
Uniqueness
444
Each Consum are at most one Trafic_Total.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
69
Uniqueness
456
Each Consum se efectueaza la at most one Data_Consum.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
70
Uniqueness
454
Each Consum contine at most one Ora_Conectare.
Constraint kind: Mandatory (simple)

Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
71
Mandatory (simple)
455
Each Consum contine some Ora_Conectare.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
72
Mandatory (simple)
484
Each Judet are some Denumire_Jud.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
73
Mandatory (simple)
453
Each Consum contine some Ora_Deconectare.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
74
Mandatory (simple)
475
Each Cont_Email are some Parola_User.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
75
Mandatory (simple)
491
Each Act_Aditional este identificat partial de some Nr_Act_Aditional.
Anexe
109

Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
76
Mandatory (simple)
451
Each Consum are some Trafic_Intrare.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
77
Mandatory (simple)
489
Each Localitate are some Denumire_Loc.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
78
Mandatory (simple)
449
Each Consum are some Trafic_Iesire.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
79
Mandatory (simple)
487
Each Localitate face parte din some Judet.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
80
Mandatory (simple)
447
Each Consum are some Durata_Conectare.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
81
Mandatory (simple)
486
For each Judet j, some Localitate face parte din Judet j.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
82
Mandatory (simple)
445
Each Consum are some Trafic_Total.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
83
Mandatory (simple)
495
Each Abonat are act identitate emis de some Emis_Politia.
Record:
Constraint type:
84
Mandatory (simple)

Localitate face parte din
Anexe
110

ID:
Verbalization:
Notes:
Statistics:
Defined over:
443
Each Act_Aditional este intocmit la some Data_Act_Ad.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
85
Mandatory (simple)
516
Each Incasari se efectueaza la some Data_Incasarii.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
87
Mandatory (simple)
501
Each Abonat are some Tip_Act_Identitate.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
88
Mandatory (simple)
439
Each Act_Aditional prevede prestarea some Serviciu in some Cant_serv.
Record:
Constraint type:
ID:
Verbalization:
89
Mandatory (simple)
438
For each Serviciu s,
some Act_Aditional prevede prestarea Serviciu s in some Cant_serv.
Notes:
Statistics:
Defined over:

86
Mandatory (simple)
441
Each Agent are some Fax_Agent.

Act_Aditional prevede prestarea
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
90
Mandatory (simple)
499
Each Abonat are act identitate cu some Seria_Act_Identitate.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
91
Disjunctive mandatory
436
Each Incasari are o some Val_Incasare_Lei or are o some Val_Incasare_Dolari.
Defined over:
Record:
92
Anexe
111

Constraint type:
ID:
Verbalization:
Notes:
Statistics:
435
Each Factura are some Val_Fact_Dolari or are some Val_Fact_Lei.
Defined over:
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
93
Mandatory (simple)
497
Each Abonat are act identitate cu some Nr_Act_Identitate.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
94
Mandatory (simple)
430
Each Serviciu poate apartine unui some Contract.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
95
Mandatory (simple)
539
Each Serviciu se caracterizeaza prin some Trafic.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
96
Mandatory (simple)
506
Each Agent este inregistrat cu some Nr_Reg_Comert.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
97
Mandatory (simple)
527
Each Factura este emisa la some Data_Fact.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
98
Mandatory (simple)
426
Each Persoana are some Nume.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
99
Mandatory (simple)
502
Each Abonat are some Prenume_Abonat.

Contract prevede prestarea unui
Anexe
112

Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
100
Mandatory (simple)
424
Each Persoana are some Adresa.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
101
Mandatory (simple)
541
Each Serviciu se caracterizeaza prin some Timp_acces.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
102
Mandatory (simple)
512
Each Incasari se face pe baza some Tip_Document.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
103
Mandatory (simple)
509
For each Factura f, some Incasari se efectueaza pe baza Factura f.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
104
Mandatory (simple)
510
Each Incasari se efectueaza pe baza some Factura.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
105
Mandatory (simple)
518
Each Incasari are some Nr_Document_Incasare.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
106
Mandatory (simple)
418
Each Persoana este some Tip_Persoana.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
107
Mandatory (simple)
525
Each Factura are some Serie_Fact.
Record:
108

Incasari se efectueaza pe baza
Anexe
113

Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
Mandatory (simple)
416
Each Persoana are adresa in some Localitate.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
109
Mandatory (simple)
415
For each Localitate l, some Persoana are adresa in Localitate l.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
110
Mandatory (simple)
534
Each Serviciu se efectueaza some printrun Mediu_Transmisie.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
111
Mandatory (simple)
413
Each Persoana are adresa in some Judet.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
112
Mandatory (simple)
412
For each Judet j, some Persoana are adresa in Judet j.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
113
Mandatory (simple)
531
Each Contract este de tipul some Tip_Contr.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
114
410
Each Persoana are some Telefon or are some Mobil.

Persoana are adresa in

Persoana are adresa in
Defined over:
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
115
Mandatory (simple)
406
Each Agent utilizeaza some Cont_Bancar.
Anexe
114

Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
116
Mandatory (simple)
405
Each Cont_Bancar este utilizat de some Agent.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
117
Mandatory (simple)
529
Each Contract este ncheiat la some Data_Contr.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
118
Mandatory (simple)
403
Each Cont_Bancar este deschis la some Banca.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
119
Mandatory (simple)
459
Each Consum este identificat partial some Cont_Email.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
120
Mandatory (simple)
401
Each Cont_Bancar are some Nr_Cont_Bancar.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
121
Mandatory (simple)
535
Each Serviciu are some Tip_conectivitate.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
122
Mandatory (simple)
537
Each Serviciu are some Val_Serviciu.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
123
Mandatory (simple)
398
Each Contract este intocmit de some Agent.
Record:
124

Agent utilizeaza
Anexe
115

Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
Mandatory (simple)
468
Each Contract prevede prestarea unui some Serviciu.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
125
Mandatory (simple)
396
Each Act_Aditional apartine unui some Contract.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
126
Mandatory (simple)
457
Each Consum se efectueaza la some Data_Consum.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
127
Mandatory (simple)
393
Each Contract este incheiat some Abonat.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
128
Mandatory (simple)
386
For each Contract c, some Factura este intocmita pe baza Contract c pe baza.
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
129
Mandatory (simple)
387
Each Factura este intocmita pe baza some Contract pe baza.

Contract poate avea

Abonat incheie

Factura este intocmita pe baza
Constraint kind: Index

Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
130
Index
476
A non-unique index will be created over the curly-bracketed role of Denumire_Loc in the fact type:
Localitate are
Localitate are
131
Index
460
A non-unique index will be created over the curly-bracketed role of Prenume_Abonat in the fact
type:
Abonat are
Anexe
116

Defined over:
Abonat are
Record:
Constraint type:
ID:
Verbalization:
132
Index
434
A non-unique index will be created over the curly-bracketed role of Data_Fact in the fact type:
Factura este emisa la
Notes:
Statistics:
Defined over:
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
Defined over:

133
Index
477
A non-unique index will be created over the curly-bracketed role of Tip_Contr in the fact type:
Contract este de tipul
134
Index
478
A non-unique index will be created over the curly-bracketed role of Data_Contr in the fact type:
Contract este ncheiat la
Constraint kind: Exclusion

Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
135
Exclusion
427
No Cont_Email that poate apartine some Agent poate apartine some Abonat.
Two relationships, two sequences of one role
Defined over:
Record:
Constraint type:
ID:
Verbalization:
Notes:
Statistics:
136
Exclusion
388
Assuming a is an instance of Abonat or Agent then
For each a, at most one of the following holds:
some Incasari poate fi efectuata de la Abonat a;
some Incasari poate fi efectuata de la Agent a.
Two relationships, two sequences of one role
Defined over:
Incasari poate fi efectuata de la
Incasari poate fi efectuata de la
Anexe
117
Anexa nr.2 Reportul faptelor

Facts with arity: 1
Record:
Pers oana
(Id_Pers)
poate avea casuta pos tala
1
147
Persoana poate avea casuta postala
Does not result in a composite type
1
None
None
None
ID:
Fact:
Mapping option:
Fact arity:
External rules:
External constraints:
Examples:
Facts with arity: 2

2
Serviciu
(Cod_Serv)
Record:
Val_Serviciu
are
2
360
Serviciu are Val_Serviciu
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
2
1: Each Serviciu are some Val_Serviciu.
2: Each Serviciu are at most one Val_Serviciu.
None
None
None
External rules:
Examples:
2
Serviciu
(Cod_Serv)
1
Tip_conectivitate
Record:
are
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:
External rules:
3
356
Serviciu are Tip_conectivitate
2
2
1: Each Serviciu are some Tip_conectivitate.
2: It is possible that some Serviciu are more than one Tip_conectivitate and
that more than one Serviciu are some Tip_conectivitate.
None
None
Anexe
118

Examples:
None
2
Serv iciu
(Cod _Serv )
Record:
1
Mediu_ Tran smisie
se efectueaza printr-u n
4
352
Serviciu se efectueaza printrun Mediu_Transmisie
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
2
1: Each Serviciu se efectueaza some printrun Mediu_Transmisie.
2: Each Serviciu se efectueaza at most one printrun Mediu_Transmisie.
None
None
None
External rules:
Examples:
2
1
Serviciu
(Cod_Serv)
Record:
Trafic
se caracterizeaza prin
5
364
Serviciu se caracterizeaza prin Trafic
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
2
1: Each Serviciu se caracterizeaza prin some Trafic.
2: Each Serviciu se caracterizeaza prin at most one Trafic.
None
None
None
External rules:
Examples:
1
Record:
Serviciu
(Cod_Serv)
Tarif_Conectare
poate avea
6
348
Serviciu poate avea Tarif_Conectare
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
1
1: Each Serviciu poate avea at most one Tarif_Conectare.
None
None
None
External rules:
Examples:
2
Contract
(Nr_Contr)
Record:
Tip_Contr
este de tipul
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
7
344
Contract este de tipul Tip_Contr
2
Anexe
119

Constraints:
3
1: Each Contract este de tipul some Tip_Contr.
2: Each Contract este de tipul at most one Tip_Contr.
3: A non-unique index will be created over the curly-bracketed role of Tip_Contr in the fact
type:
None
None
None
External rules:
Examples:
2
Contract
(Nr_Contr)
Record:
Data_Contr
este ncheiat la
8
340
Contract este ncheiat la Data_Contr
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
3
1: Each Contract este ncheiat la some Data_Contr.
2: Each Contract este ncheiat la at most one Data_Contr.
3: A non-unique index will be created over the curly-bracketed role of Data_Contr in the fact
type:
None
None
None
External rules:
Examples:
2
Factura
(Nr_Fact)
Record:
1
Data_Fact
este emisa la
9
336
Factura este emisa la Data_Fact
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
3
1: Each Factura este emisa la some Data_Fact.
2: Each Factura este emisa la at most one Data_Fact.
3: A non-unique index will be created over the curly-bracketed role of Data_Fact in the fact
type:
None
None
None
External rules:
Examples:
2
Factura
(Nr_Fact)
Record: 10
ID:
332
Fact: Factura are
Serie_Fact
Serie_Fact
are
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
2
Anexe
120

1: Each Factura are some Serie_Fact.
2: Each Factura are at most one Serie_Fact.
None
None
None
External rules:
Examples:
1
Factura
(Nr_Fact)
Record:
Val_Fact_Lei
are
11
324
Factura are Val_Fact_Lei **
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
1
1: Each Factura are at most one Val_Fact_Lei.
1
External rules:
1: Each Factura are some Val_Fact_Dolari or are some Val_Fact_Lei.

None
Val_Fact_lei=Val_Fact_Dolari*31500
Examples:
Derived(**) by rule:
1
Factura
(Nr_Fact)
Val_Fact_Dolari
Record:
are
12
320
Factura are Val_Fact_Dolari
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
1
1: Each Factura are at most one Val_Fact_Dolari.
1
External rules:
1: Each Factura are some Val_Fact_Dolari or are some Val_Fact_Lei.

None
Examples:
2
1
Incasari
Tip_Document
se face pe baza
13
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:
External rules:
316
Incasari se face pe baza Tip_Document
2
2
1: Each Incasari se face pe baza some Tip_Document.
2: Each Incasari se face pe baza at most one Tip_Document.
1
1: For each Factura f and Tip_Document t
Anexe
121
Record:

Examples:
None
2
1
Incasari
Nr_Document_Incasare
Record:
are
14
312
Incasari are Nr_Document_Incasare
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
2
1: Each Incasari are some Nr_Document_Incasare.
2: Each Incasari are at most one Nr_Document_Incasare.
None
None
None
External rules:
Examples:
2
Record:
1
Incasari
Data_Incasarii
se efectueaza la
15
308
Incasari se efectueaza la Data_Incasarii
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
2
1: Each Incasari se efectueaza la some Data_Incasarii.
2: Each Incasari se efectueaza la at most one Data_Incasarii.
None
None
None
External rules:
Examples:
1
Incasari
Val_Incasare_Lei
Record:
are o
16
304
Incasari are o Val_Incasare_Lei
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
1
1: Each Incasari are o at most one Val_Incasare_Lei.
1
External rules:
1: Each Incasari are o some Val_Incasare_Lei or are o some Val_Incasare_Dolari.

None
Examples:
1
Record:
Incasari
Val_Incasare_Dolari
are o
17
ID:
300
Anexe
122

Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:
Incasari are o Val_Incasare_Dolari **

2
1
1: Each Incasari are o at most one Val_Incasare_Dolari.
1
External rules:
1: Each Incasari are o some Val_Incasare_Lei or are o some Val_Incasare_Dolari.

None
Val_Incasare_Dolari=Val_Incasare_Lei/31500
Examples:
3
1
Incasari
Factura
(Nr_Fact)
Record:
se efectueaza pe baza
18
296
Incasari se efectueaza pe baza Factura
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
3
1: Each Incasari se efectueaza pe baza some Factura.
2: For each Factura f, some Incasari se efectueaza pe baza Factura f.
3: Each Incasari se efectueaza pe baza at most one Factura.
1
External rules:
1: For each Factura f and Tip_Document t

None
Examples:
3
Record:
2
Agent
(Cod_Unic)
1
Nr_Reg_Comert
este inregistrat cu
19
292
Agent este inregistrat cu Nr_Reg_Comert
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
3
1: Each Agent este inregistrat cu some Nr_Reg_Comert.
2: For each Nr_Reg_Comert n, at most one Agent este inregistrat cu Nr_Reg_Comert n.
3: Each Agent este inregistrat cu at most one Nr_Reg_Comert.
None
None
None
External rules:
Examples:
Record:
2
Agent
(Cod_Unic)
1
Fax_Agent
are
Anexe
123

20
288
Agent are Fax_Agent
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
3
1: Each Agent are some Fax_Agent.
2: For each Fax_Agent f, at most one Agent are Fax_Agent f.
3: Each Agent are at most one Fax_Agent.
None
None
None
External rules:
Examples:
2
Abonat
(CNP)
1
Prenume_Abonat
Record:
are
21
284
Abonat are Prenume_Abonat
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
3
1: Each Abonat are some Prenume_Abonat.
2: Each Abonat are at most one Prenume_Abonat.
3: A non-unique index will be created over the curly-bracketed role of Prenume_Abonat in
the fact type:
Abonat are
None
None
None
External rules:
Examples:
2
Abonat
(CNP)
1
Tip_Act_Identitate
Record:
are
22
280
Abonat are Tip_Act_Identitate
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
2
1: Each Abonat are some Tip_Act_Identitate.
2: Each Abonat are at most one Tip_Act_Identitate.
None
None
None
External rules:
Examples:
2
Abonat
(CNP)
1
Seria_Act_Identitate
are act identitate cu
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:
23
276
Abonat are act identitate cu Seria_Act_Identitate
2
2
1: Each Abonat are act identitate cu some Seria_Act_Identitate.
Anexe
124
Record:

2: Each Abonat are act identitate cu at most one Seria_Act_Identitate.
1
External rules:
1: For each Nr_Act_Identitate n and Seria_Act_Identitate s

are act identitate cu Nr_Act_Identitate n and are act identitate cu Seria_Act_Identitate
s.
None
Examples:
2
Abonat
(CNP)
1
Nr_Act_Identitate
Record:
are act identitate cu
24
272
Abonat are act identitate cu Nr_Act_Identitate
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
2
1: Each Abonat are act identitate cu some Nr_Act_Identitate.
2: Each Abonat are act identitate cu at most one Nr_Act_Identitate.
1
External rules:
1: For each Nr_Act_Identitate n and Seria_Act_Identitate s

are act identitate cu Nr_Act_Identitate n and are act identitate cu Seria_Act_Identitate
s.
None
Examples:
2
Abonat
(CNP)
Record:
1
Emis_Politia
are act identitate emis de
25
268
Abonat are act identitate emis de Emis_Politia
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
2
1: Each Abonat are act identitate emis de some Emis_Politia.
2: Each Abonat are act identitate emis de at most one Emis_Politia.
None
None
None
External rules:
Examples:
2
1
Act_Aditional
Nr_Act_Aditional
Record:
este identificat partial de
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:
External rules:
26
264
Act_Aditional este identificat partial de Nr_Act_Aditional
2
2
1: Each Act_Aditional este identificat partial de some Nr_Act_Aditional.
2: Each Act_Aditional este identificat partial de at most one Nr_Act_Aditional.
1
Anexe
125

1: For each Contract c and Nr_Act_Aditional n
None
Examples:
2
Localitate
(Abrev_Loc)
Record:
1
Denumire_Loc
are
27
260
Localitate are Denumire_Loc
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
3
1: Each Localitate are some Denumire_Loc.
2: Each Localitate are at most one Denumire_Loc.
3: A non-unique index will be created over the curly-bracketed role of Denumire_Loc in the
fact type:
Localitate are
None
None
None
External rules:
Examples:
3
1
Localitate
(Abrev_Loc)
Judet
(Abrev_Jud)
Record:
face parte din
28
256
Localitate face parte din Judet
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
3
1: Each Localitate face parte din some Judet.
2: For each Judet j, some Localitate face parte din Judet j.
3: It is possible that some Localitate face parte din more than one Judet and
that more than one Localitate face parte din some Judet.
None
None
None
External rules:
Examples:
3
2
Judet
(Abrev_Jud)
Record:
Denumire_Jud
are
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:
29
252
Judet are Denumire_Jud
2
3
1: Each Judet are some Denumire_Jud.
Anexe
126

2: For each Denumire_Jud d, at most one Judet are Denumire_Jud d.
3: Each Judet are at most one Denumire_Jud.
None
None
None
External rules:
Examples:
3
Record:
2
1
Cont_Email
(Cont_User)
Parola_User
are
30
244
Cont_Email are Parola_User
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
3
1: Each Cont_Email are some Parola_User.
2: For each Parola_User p, at most one Cont_Email are Parola_User p.
3: Each Cont_Email are at most one Parola_User.
None
None
None
External rules:
Examples:
2
1
Serviciu
(Cod_Serv)
Timp_acces
Record:
se caracterizeaza prin
31
368
Serviciu se caracterizeaza prin Timp_acces
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
2
1: Each Serviciu se caracterizeaza prin some Timp_acces.
2: Each Serviciu se caracterizeaza prin at most one Timp_acces.
None
None
None
External rules:
Examples:
2
Record:
Cont_Email
(Cont_User)
Consum
este identificat partial
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:
External rules:
Examples:
32
224
Consum este identificat partial Cont_Email
2
2
1: Each Consum este identificat partial some Cont_Email.
2: Each Consum este identificat partial at most one Cont_Email.
1
1: For each Cont_Email c, Ora_Conectare o and Data_Consum d
este identificat partial Cont_Email c and contine Ora_Conectare o and se efectueaza
la Data_Consum d.
None
Anexe
127

2
Record:
1
Consum
Data_Consum
se efectueaza la
33
220
Consum se efectueaza la Data_Consum
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
2
1: Each Consum se efectueaza la some Data_Consum.
2: Each Consum se efectueaza la at most one Data_Consum.
1
External rules:

la Data_Consum d.
None
Examples:
Record:
1
Consum
Ora_Conectare
contine
34
216
Consum contine Ora_Conectare
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
2
1: Each Consum contine some Ora_Conectare.
2: Each Consum contine at most one Ora_Conectare.
1
External rules:

la Data_Consum d.
None
Examples:
2
1
Consum
Ora_Deconectare
contine
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:
External rules:
35
212
Consum contine Ora_Deconectare
2
2
1: Each Consum contine some Ora_Deconectare.
2: Each Consum contine at most one Ora_Deconectare.
None
Anexe
128
Record:

Examples:
None
None
2
1
Consum
Record:
Trafic_Intrare
are
36
208
Consum are Trafic_Intrare
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
2
1: Each Consum are some Trafic_Intrare.
2: Each Consum are at most one Trafic_Intrare.
None
None
None
External rules:
Examples:
2
1
Consum
Record:
Trafic_Iesire
are
37
204
Consum are Trafic_Iesire
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
2
1: Each Consum are some Trafic_Iesire.
2: Each Consum are at most one Trafic_Iesire.
None
None
None
External rules:
Examples:
2
1
Consum
Record:
Durata_Conectare
are
38
200
Consum are Durata_Conectare **
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
2
1: Each Consum are some Durata_Conectare.
2: Each Consum are at most one Durata_Conectare.
None
None
None
Ora_Deconectare-Ora_Conectare
External rules:
Examples:
Record:
1
Consum
Trafic_Total
are
Anexe
129

39
196
Consum are Trafic_Total **
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
2
1: Each Consum are some Trafic_Total.
2: Each Consum are at most one Trafic_Total.
None
None
None
Trafic_Intrare+Trafic_Iesire
External rules:
Examples:
2
1
Act_Aditional
Record:
Data_Act_Ad
este intocmit la
40
192
Act_Aditional este intocmit la Data_Act_Ad
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
2
1: Each Act_Aditional este intocmit la some Data_Act_Ad.
2: Each Act_Aditional este intocmit la at most one Data_Act_Ad.
None
None
None
External rules:
Examples:
1
Cont_Email
(Cont_User)
Record:
Agent
(Cod_Unic)
poate apartine / poate detine
41
188
Cont_Email poate apartine Agent
Agent poate detine Cont_Email
2
1
1: Each Cont_Email poate apartine at most one Agent.
1
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:
External rules:
1: No Cont_Email that poate apartine some Agent poate apartine some Abonat.
None
Examples:
3
Contract
(Nr_Contr)
Serviciu
(Cod_Serv)
prevede prestarea unui / poate apartine unui
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:
External rules:
42
236
Contract prevede prestarea unui Serviciu
Serviciu poate apartine unui Contract
2
3
1: Each Contract prevede prestarea unui some Serviciu.
2: Each Serviciu poate apartine unui some Contract.
3: Each Contract prevede prestarea unui at most one Serviciu.
None
None
Anexe
130
Record:

Examples:
None
1
Cont_Email
(Cont_User)
Abonat
(CNP)
Record:
po ate apartine / poate detine
43
175
Cont_Email poate apartine Abonat
Abonat poate detine Cont_Email
2
1
1: Each Cont_Email poate apartine at most one Abonat.
1
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:
External rules:
1: No Cont_Email that poate apartine some Agent poate apartine some Abonat.
None
Examples:
2
Persoana
(Id_Pers)
Record:
Nume
are
44
171
Persoana are Nume
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
2
1: Each Persoana are some Nume.
2: Each Persoana are at most one Nume.
None
None
None
External rules:
Examples:
2
Persoana
(Id_Pers)
Record:
Adresa
are
45
167
Persoana are Adresa
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
2
1: Each Persoana are some Adresa.
2: Each Persoana are at most one Adresa.
None
None
None
External rules:
Examples:
2
1
Record:
Persoana
(Id_Pers)
Telefon
are
ID:
Fact:
Inverse fact:
Mapping option:
46
163
Persoana are Telefon
Anexe
131

Fact arity:
Constraints:
2
2
1: For each Telefon t, at most one Persoana are Telefon t.
2: Each Persoana are at most one Telefon.
1
External rules:
1: Each Persoana are some Telefon or are some Mobil.

None
Examples:
Record:
1
Persoana
(Id_Pers)
Mobil
are
47
159
Persoana are Mobil
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
2
1: For each Mobil m, at most one Persoana are Mobil m.
2: Each Persoana are at most one Mobil.
1
External rules:
1: Each Persoana are some Telefon or are some Mobil.

None
Examples:
2
Persoana
(Id_Pers)
Record:
Tip_Persoana
este
48
155
Persoana este Tip_Persoana
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
2
1: Each Persoana este some Tip_Persoana.
2: Each Persoana este at most one Tip_Persoana.
None
None
None
External rules:
Examples:
3
Persoana
(Id_Pers)
Record:
Localitate
(Abrev_Loc)
are adresa in
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:
External rules:
49
151
Persoana are adresa in Localitate
2
3
1: Each Persoana are adresa in some Localitate.
2: For each Localitate l, some Persoana are adresa in Localitate l.
3: Each Persoana are adresa in at most one Localitate.
None
Anexe
132

Examples:
None
None
2
Con tract
(Nr_ Con tr)
Agent
(Co d_ Un ic)
Record:
este in tocmit d e / in tocmeste
50
124
Contract este intocmit de Agent
Agent intocmeste Contract
2
2
1: Each Contract este intocmit de some Agent.
2: Each Contract este intocmit de at most one Agent.
None
None
None
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:
External rules:
Examples:
3
Persoana
(Id_Pers)
Record:
Judet
(Abrev_Jud)
are adresa in
51
144
Persoana are adresa in Judet
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
3
1: Each Persoana are adresa in some Judet.
2: For each Judet j, some Persoana are adresa in Judet j.
3: Each Persoana are adresa in at most one Judet.
None
None
None
External rules:
Examples:
3
Agen t
(Cod _ Un ic)
2
Con t_ Ban car
u tilizeaza / este utilizat d e
Record:
52
136
Agent utilizeaza Cont_Bancar
Cont_Bancar este utilizat de Agent
2
3
1: Each Agent utilizeaza some Cont_Bancar.
2: Each Cont_Bancar este utilizat de some Agent.
3: Each Cont_Bancar este utilizat de at most one Agent.
None
None
None
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:
External rules:
Examples:
2
1
Record:
Banca
(Nume)
Cont_Bancar
este deschis la
ID:
Fact:
53
132
Cont_Bancar este deschis la Banca
Anexe
133

Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
2
1: Each Cont_Bancar este deschis la some Banca.
2: Each Cont_Bancar este deschis la at most one Banca.
1
External rules:
1: For each Banca b and Nr_Cont_Bancar n

None
Examples:
2
1
Cont_Bancar
Nr_Cont_Bancar
Record:
are
54
128
Cont_Bancar are Nr_Cont_Bancar
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
2
1: Each Cont_Bancar are some Nr_Cont_Bancar.
2: Each Cont_Bancar are at most one Nr_Cont_Bancar.
1
External rules:
1: For each Banca b and Nr_Cont_Bancar n

None
Examples:
2
Con tract
(Nr_ Contr)
Act_ Adition al
po ate avea / apartine u nui
Inverse fact:
Mapping option:
Fact arity:
Constraints:
Record: 55
ID:
120
Fact:
Contract poate
avea Act_Aditional
Act_Aditional apartine unui Contract

2
2
1: Each Act_Aditional apartine unui some Contract.
2: Each Act_Aditional apartine unui at most one Contract.
1
External rules:
1: For each Contract c and Nr_Act_Aditional n

None
Examples:
2
Abonat
(CNP)
Record:
Contract
(Nr_Contr)
incheie / este incheiat
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
56
116
Abonat incheie Contract
Contract este incheiat Abonat
2
Anexe
134

Constraints:
2
1: Each Contract este incheiat some Abonat.
2: Each Contract este incheiat at most one Abonat.
None
None
None
External rules:
Examples:
3
Factura
(Nr_Fact)
Contract
(Nr_Contr)
Record:
...este intocmita pe baza...pe baza
57
112
Factura este intocmita pe baza Contract pe baza
ID:
Fact:
Inverse fact:
Mapping option:
Fact arity:
Constraints:

2
3
1: Each Factura este intocmita pe baza some Contract pe baza.
2: For each Contract c, some Factura este intocmita pe baza Contract c pe baza.
3: Each Factura este intocmita pe baza at most one Contract pe baza.
None
None
None
External rules:
Examples:
1
Abonat
(CNP)
Incasari
poate fi efectuata de la / plateste
Inverse fact:
Mapping option:
Fact arity:
Constraints:
Record: 58
ID:
108
Fact:
Incasari poate
fi efectuata de la Abonat
Abonat plateste Incasari

2
1
1: Each Incasari poate fi efectuata de la at most one Abonat.
1
External rules:
1: Assuming a is an instance of Abonat or Agent then

None
Examples:
1
Agent
(Cod_Unic)
Incasari
poate fi efectuata de la / plateste
Inverse fact:
Mapping option:
Fact arity:
Constraints:
Record: 59
ID:
104
Fact:
Incasari poate
fi efectuata de la Agent
Agent plateste Incasari

2
1
1: Each Incasari poate fi efectuata de la at most one Agent.
1
External rules:
1: Assuming a is an instance of Abonat or Agent then

None
Examples:
3
1
Act_Aditional
Cant_serv
...prevede prestarea...in...
2
Serviciu
(Cod_Serv)
Anexe
135
Facts
with arity: 3
Record:
ID:
Fact:
Mapping option:
Fact arity:
Constraints:
External rules:
Examples:
60
184
Act_Aditional prevede prestarea Serviciu in Cant_serv
3
3
1: Each Act_Aditional prevede prestarea some Serviciu in some Cant_serv.
2: For each Serviciu s,
some Act_Aditional prevede prestarea Serviciu s in some Cant_serv.
3: *Given any Act_Aditional and Serviciu
that Act_Aditional prevede prestarea that Serviciu in at most one
Cant_serv.
None
None
None
Anexe
136
Anexa nr.3 Rapotul tipurilor de obiecte

Objects of type Entity
1Abonat
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Microsoft SQL Server data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
15
Entity
No
No
SBCS Char(13)
char(13)
No
Neutral
8
Cont_Email poate apartine Abonat / Abonat poate detine Cont_Email
Incasari poate fi efectuata de la Abonat / Abonat plateste Incasari
Abonat incheie Contract / Contract este incheiat Abonat
Entity-specific attributes
Reference scheme:
Every Abonat is identified by one distinct CNP.
Subtype-specific attributes
Subtype definition:
Supertypes:
Primary supertype:
Subtype mapping:
fiecare Abonat este o Persoana care are Tip_Persoana='PF'

Abonat is a subtype of Persoana* / Persoana* is a supertype of
Abonat.
Abonat is a subtype of Persoana* / Persoana* is a supertype of
Abonat.
Map to separate table
Act_Aditional
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
18
Entity
No
No
SBCS Char(10)
char(10)
No
Neutral
4
Contract poate avea Act_Aditional / Act_Aditional apartine unui
Contract
Anexe
137

Reference scheme:
Act_Aditional is primarily identified by the constraint:

For each Contract c and Nr_Act_Aditional n
some Act_Aditional este identificat partial de
Nr_Act_Aditional n.
Agent
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
20
Entity
No
No
SBCS Char(13)
char(13)
No
Neutral
6
Agent utilizeaza Cont_Bancar / Cont_Bancar este utilizat de Agent
Incasari poate fi efectuata de la Agent / Agent plateste Incasari
Cont_Email poate apartine Agent / Agent poate detine Cont_Email
Contract este intocmit de Agent / Agent intocmeste Contract
Agent are Fax_Agent
Reference scheme:
Every Agent is identified by one distinct Cod_Unic.
Subtype definition:
Supertypes:
Primary supertype:
Subtype mapping:
fiecare Agent este o Persoana care are Tip_Persoana='PJ'

Agent is a subtype of Persoana* / Persoana* is a supertype of Agent.
Agent is a subtype of Persoana* / Persoana* is a supertype of Agent.
Map to separate table
Banca
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
21
Entity
No
The possible values of 'Nume' are: 'BCR', 'BRD', 'BancPost',
'BancaIonTiriac', 'RaiffeisenBank'.
No
SBCS Char(30)
char(30)
No
Neutral
1
Reference scheme:
Every Banca is identified by one distinct Nume.
Consum
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
26
Entity
No
Anexe
138

Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
No
SBCS Char(10)
char(10)
No
Neutral
8
Reference scheme:
Consum is primarily identified by the constraint:

For each Cont_Email c, Ora_Conectare o and Data_Consum
d
este identificat partial Cont_Email c and contine
Ora_Conectare o and se efectueaza la Data_Consum d.
Cont_Bancar
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
27
Entity
No
No
SBCS Char(10)
char(10)
No
Neutral
3
Agent utilizeaza Cont_Bancar / Cont_Bancar este utilizat de Agent
Reference scheme:
Cont_Bancar is primarily identified by the constraint:

For each Banca b and Nr_Cont_Bancar n
Cont_Email
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
28
Entity
No
No
SBCS Char(10)
char(10)
No
Neutral
4
Cont_Email poate apartine Abonat / Abonat poate detine Cont_Email
Anexe
139

Cont_Email poate apartine Agent / Agent poate detine Cont_Email
Reference scheme:
Every Cont_Email is identified by one distinct Cont_User.
Contract
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
30
Entity
No
No
SBCS Char(10)
char(10)
No
Neutral
7
Contract prevede prestarea unui Serviciu / Serviciu poate apartine unui
Contract
Abonat incheie Contract / Contract este incheiat Abonat
Contract poate avea Act_Aditional / Act_Aditional apartine unui
Contract
Contract este intocmit de Agent / Agent intocmeste Contract
Reference scheme:
Every Contract is identified by one distinct Nr_Contr.
Factura
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
40
Entity
No
No
SBCS Char(10)
char(10)
No
Neutral
6
Factura are Serie_Fact
Reference scheme:
10
Every Factura is identified by one distinct Nr_Fact.
Incasari
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
43
Entity
No
Anexe
140

Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
No
SBCS Char(10)
char(10)
No
Neutral
8
Incasari poate fi efectuata de la Abonat / Abonat plateste Incasari
Incasari poate fi efectuata de la Agent / Agent plateste Incasari
Reference scheme:
11
Incasari is primarily identified by the constraint:

For each Factura f and Tip_Document t
se efectueaza pe baza Factura f and se face pe baza
Tip_Document t.
Judet
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
44
Entity
No
No
SBCS Char(2)
char(2)
No
Neutral
3
Reference scheme:
12
Every Judet is identified by one distinct Abrev_Jud.
Localitate
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
45
Entity
No
No
SBCS Char(2)
char(2)
No
Neutral
3
Reference scheme:
13
Every Localitate is identified by one distinct Abrev_Loc.
Persoana
Anexe
141

General attributes
ID:
Object kind:
Notes:
60
Entity
fiecare Persoana care are Tip_Persoana='Persoana fizica' este Abonat
fiecare Persoana care are Tip_Persoana='Persoana juridica' este Agent
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
No
No
SBCS Char(13)
char(13)
No
Neutral
8
Persoana are Mobil
Persoana are Nume
Persoana are Adresa
Persoana poate avea casuta postala
Reference scheme:
Every Persoana is identified by one distinct Id_Pers.
Subtypes:
14
Each Abonat is a Persoana but not every Persoana is necessarily an

Abonat.
Each Agent is a Persoana but not every Persoana is necessarily an
Agent.
Serviciu
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
64
Entity
No
No
SBCS Char(10)
char(10)
No
Neutral
8
Contract prevede prestarea unui Serviciu / Serviciu poate apartine unui
Contract
Reference scheme:
Every Serviciu is identified by one distinct Cod_Serv.
Objects of type Value

15
Adresa
General attributes
ID:
Object kind:
19
Value
Anexe
142

Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
16
No
No
SBCS Char(30)
char(30)
No
Neutral
1
Persoana are Adresa
Cant_serv
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
17
22
Value
No
No
Small Signed Number
smallint
No
Neutral
1
Data_Act_Ad
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
18
31
Value
No
No
Large Date & Time
datetime
No
Neutral
1
Data_Consum
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
19
32
Value
No
No
Large Date & Time
datetime
No
Neutral
1
Data_Contr
Anexe
143

General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
20
33
Value
No
No
Large Date & Time
datetime
No
Neutral
1
Data_Fact
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
21
34
Value
No
No
Large Date & Time
datetime
No
Neutral
1
Data_Incasarii
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
22
35
Value
No
No
Large Date & Time
datetime
No
Neutral
1
Denumire_Jud
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
36
Value
No
No
SBCS Char(20)
char(20)
No
Neutral
1
Anexe
144

Referencing facts:
23
Denumire_Loc
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
24
37
Value
No
No
SBCS Char(20)
char(20)
No
Neutral
1
Durata_Conectare
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
25
38
Value
No
No
Large Date & Time
datetime
No
Neutral
1
Emis_Politia
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
26
39
Value
No
No
SBCS Char(20)
char(20)
No
Neutral
1
Fax_Agent
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
41
Value
No
No
SBCS Char(13)
char(13)
Anexe
145

Personal pronoun:
Gender:
Fact count:
Referencing facts:
27
No
Neutral
1
Agent are Fax_Agent
Mediu_Transmisie
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
28
46
Value
No
No
SBCS Char(20)
char(20)
No
Neutral
1
Mobil
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
29
47
Value
No
No
SBCS Char(13)
char(13)
No
Neutral
1
Persoana are Mobil
Nr_Act_Aditional
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
30
48
Value
No
No
SBCS Char(10)
char(10)
No
Neutral
1
Nr_Act_Identitate
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
49
Value
No
No
Anexe
146

Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
31

Small Decimal(10;0)
numeric(10;0)
No
Neutral
1
Nr_Cont_Bancar
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
32
50
Value
No
No
SBCS Char(20)
char(20)
No
Neutral
1
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
33
52
Value
No
No
SBCS Char(10)
char(10)
No
Neutral
1
Nr_Reg_Comert
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
34
54
Value
No
No
SBCS Char(12)
char(12)
No
Neutral
1
Nume
General attributes
ID:
Object kind:
Notes:
Name space:
56
Value
Anexe
147

Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
35
No
No
SBCS Char(30)
char(30)
No
Neutral
1
Persoana are Nume
Ora_Conectare
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
36
57
Value
No
No
Large Date & Time
datetime
No
Neutral
1
Ora_Deconectare
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
37
58
Value
No
No
Large Date & Time
datetime
No
Neutral
1
Parola_User
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
38
59
Value
No
No
SBCS Char(10)
char(10)
No
Neutral
1
Prenume_Abonat
Anexe
148

General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
39
61
Value
No
No
SBCS Char(20)
char(20)
No
Neutral
1
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
40
62
Value
No
No
SBCS Char(2)
char(2)
No
Neutral
1
Serie_Fact
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
41
63
Value
No
No
SBCS Char(2)
char(2)
No
Neutral
1
Factura are Serie_Fact
Tarif_Conectare
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
65
Value
No
No
Small Decimal(10;0)
numeric(10;0)
No
Neutral
1
Anexe
149

Referencing facts:
42
Telefon
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
43
66
Value
No
No
SBCS Char(13)
char(13)
No
Neutral
1
Timp_acces
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
44
67
Value
No
No
SBCS Char(10)
char(10)
No
Neutral
1
Tip_Act_Identitate
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
45
68
Value
No
The possible values of 'Tip_Act_Identitate' are: 'BI', 'CI'.
No
SBCS Char(20)
char(20)
No
Neutral
1
Tip_conectivitate
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
69
Value
No
No
SBCS Char(20)
Anexe
150

Personal pronoun:
Gender:
Fact count:
Referencing facts:
46
char(20)
No
Neutral
1
Tip_Contr
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
47
70
Value
No
The possible values of 'Tip_Contr' are: 'AgentEconomic',
'AgentVanzari', 'PersoanaJuridica', 'PersoanaFizica', 'Dealer'.
No
SBCS Char(20)
char(20)
No
Neutral
1
Tip_Document
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
48
71
Value
No
The possible values of 'Tip_Document' are: 'OrdinPlata', 'Chitanta',
'FillaCEC'.
No
SBCS Char(15)
char(15)
No
Neutral
1
Tip_Persoana
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
49
72
Value
No
The possible values of 'Tip_Persoana' are: 'PF', 'PJ'.
No
SBCS Char(20)
char(20)
No
Neutral
1
Trafic
General attributes
ID:
Object kind:
Notes:
Name space:
73
Value
Anexe
151

Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
50
No
The possible values of 'Trafic' are: 'MB', 'GB', 'Nelimitat'.
No
SBCS Char(10)
char(10)
No
Neutral
1
Trafic_Iesire
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
51
74
Value
No
No
Small Decimal(10;0)
numeric(10;0)
No
Neutral
1
Trafic_Intrare
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
52
75
Value
No
No
Small Decimal(10;0)
numeric(10;0)
No
Neutral
1
Trafic_Total
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
53
76
Value
No
No
Small Decimal(10;0)
numeric(10;0)
No
Neutral
1
Val_Fact_Dolari
General attributes
ID:
77
Anexe
152

Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
54
Value
No
No
Small Decimal(10;0)
numeric(10;0)
No
Neutral
1
Val_Fact_Lei
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
55
78
Value
No
No
Small Decimal(10;0)
numeric(10;0)
No
Neutral
1
Val_Incasare_Dolari
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
56
79
Value
No
No
Small Decimal(10;0)
numeric(10;0)
No
Neutral
1
Val_Incasare_Lei
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
80
Value
No
No
Small Decimal(10;0)
numeric(10;0)
No
Neutral
1
Anexe
153
57
Val_Serviciu
General attributes
ID:
Object kind:
Notes:
Name space:
Independent:
Value/Range:
Numeric:
Mapping option:
Portable data type:
Personal pronoun:
Gender:
Fact count:
Referencing facts:
81
Value
No
No
Small Decimal(10;0)
numeric(10;0)
No
Neutral
1
Anexe
154
Anexa nr.4 Raportul tabelelor

Database summary
Target DBMS:
Number of tables:
Number of views:
Number of columns:
Number of indexes:
Number of foreign keys:
Last build date:
Microsoft SQL Server

16
0
76
14
21
03.11.2004
Tables
Act_Aditional prevede
prestarea Serviciu Cant_serv
Persoana
Columns
4
Indexes
0
Foreign keys
2
2
9
0
2
1
2
Contract
Cont_Bancar
Consum
Serviciu
Act_Aditional
Cont_Email
Localitate
Judet
Incasari
Factura
Agent
Abonat
6
3
8
6
3
4
2
2
2
8
6
4
7
2
0
0
0
0
1
0
1
1
0
1
3
3
3
1
1
0
1
2
2
0
0
3
1
1
1
Abonat
Record:
Physical name:
Conceptual name:
ID:
Owner:
Target DB name:
Independent:
Number of columns:
Number of indexes:
1
Abonat
Abonat
588
Yes
7
3
1
Anexe
155
Notes
fiecare
Persoana care
are
Tip_Persoana='
Persoana fizica'
este Abonat
fiecare
Persoana care
are
Tip_Persoana='
Persoana
juridica' este
Agent

Primary key:
Codes:
Type:
CNP
0
Table
Columns
Data type
Are Prenume_Abonat (I1)

Are Tip_Act_Identitate
char(20)
char(20)
Allow
NULLs
Not allowed
Not allowed
Are act identitate cu Seria_Act_Identitate

(U1)
Are act identitate cu Nr_Act_Identitate (U1)
char(2)
Not allowed
numeric(10;0
)
char(20)
char(13)
char(13)
Not allowed
Are act identitate emis de Emis_Politia

CNP
Id_Pers (FK,U2)
Indexes
Abonat_AK1 (U1)
Abonat_UC2 (U2)
Abonat_IDX3 (I1)
Foreign keys
Persoana_Abonat_FK1
Abonat_Contract_FK1
Abonat_Cont_Email_F
K1
Abonat_Incasari_FK1
Columns
Are act identitate cu
Nr_Act_Identitate
Are act identitate cu
Id_Pers
Are Prenume_Abonat
Not allowed
Not allowed
Not allowed
Sort order
Ascending
Ascending
Ascending
Ascending
Child
Id_Pers
Contract.Abonat incheie CNP
Cont_Email.Poate apartine CNP
Parent
Persoana.Id_Pers
CNP
CNP
Incasari.Poate fi efectuata de la
CNP
CNP
Column details
1. Are Prenume_Abonat (I1)
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Are Prenume_Abonat
Prenume_Abonat
char(20)
Not allowed
2. Are Tip_Act_Identitate
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Value/Range:
Are Tip_Act_Identitate
Tip_Act_Identitate
char(20)
Not allowed
'BI', 'CI'.
3. Are act identitate cu Seria_Act_Identitate (U1)

Physical name:
Are act identitate cu Seria_Act_Identitate
Conceptual name:
Physical data type:
char(2)
Allow NULLs:
Not allowed
4. Are act identitate cu Nr_Act_Identitate (U1)
Physical name:
Are act identitate cu Nr_Act_Identitate
Conceptual name:
Nr_Act_Identitate
Physical data type:
numeric(10;0)
Allow NULLs:
Not allowed
5. Are act identitate emis de Emis_Politia
Physical name:
Are act identitate emis de Emis_Politia
Conceptual name:
Emis_Politia
Physical data type:
char(20)
Allow NULLs:
Not allowed
Anexe
156
Value/
Range
'BI',
'CI'.

6. CNP
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
7. Id_Pers (FK,U2)
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Notes:
Index details
Abonat_AK1
Column(s):
Unique:
Verbalization:
Abonat_UC2
Column(s):
Unique:
Verbalization:
Abonat_IDX3
Column(s):
Unique:
Verbalization:
CNP
CNP
char(13)
Not allowed
Id_Pers
Id_Pers
char(13)
Not allowed
Are act identitate cu Nr_Act_Identitate (Asc)

Are act identitate cu Seria_Act_Identitate (Asc)
Yes
Unique index 'Abonat_AK1' on columns( Are act identitate cu Nr_Act_Identitate
ascending, Are act identitate cu Seria_Act_Identitate ascending ).
Id_Pers (Asc)
Yes
Unique index 'Abonat_UC2' on column Id_Pers is ascending
Are Prenume_Abonat (Asc)
No
Non-unique index 'Abonat_IDX3' on column Are Prenume_Abonat is ascending
Foreign key details (child)

Persoana_Abonat_FK1
Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Ref. Integrity on update:
Ref. Integrity on delete:
Verbalization:
Child
Parent
Id_Pers
Persoana.Id_Pers
Non-Identifying
One -to- Zero-or-One
Not allowed
is a
is a
No action
No action
Relationship Persoana_Abonat_FK1: Persoana.Id_Pers is a Abonat.Id_Pers.
Persoana_Abonat_FK1 is a non identifying relationship.
Cardinality: one to zero-or-one.
Foreign key details (parent)

Abonat_Contract_FK1
Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Contract.Abonat incheie CNP
CNP
Non-Identifying
One -to- Zero-or-More
Not allowed
Abonat incheie
este incheiat
No action
No action
Relationship Abonat_Contract_FK1: Abonat.CNP Abonat incheie
Contract.Abonat incheie CNP.
Abonat_Contract_FK1 is a non identifying relationship.
Cardinality: one to zero-or-more.
Abonat_Cont_Email_FK1
Definition:
Child
Parent
Anexe
157

Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Cont_Email.Poate apartine CNP

CNP
Non-Identifying
Zero-or-One -to- Zero-or-More
Allowed
Abonat poate detine
poate apartine
No action
No action
Relationship Abonat_Cont_Email_FK1: Abonat.CNP Abonat poate detine
Cont_Email.Poate apartine CNP.
Abonat_Cont_Email_FK1 is a non identifying relationship.
Cardinality: zero-or-one to zero-or-more.
Abonat_Incasari_FK1
Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Incasari.Poate fi efectuata de la CNP CNP
Non-Identifying
Allowed
Abonat plateste
poate fi efectuata de la
No action
No action
Relationship Abonat_Incasari_FK1: Abonat.CNP Abonat plateste Incasari.Poate
fi efectuata de la CNP.
Abonat_Incasari_FK1 is a non identifying relationship.
Act_Aditional
Record:
Physical name:
Conceptual name:
ID:
Owner:
Target DB name:
Independent:
Number of columns:
Number of indexes:
Primary key:
Codes:
Type:
2
Act_Aditional
Act_Aditional
633
No
3
0
1
1. Este identificat partial de Nr_Act_Aditional
2. Contract Nr_Contr
0
Table
Columns
Este identificat partial de
Nr_Act_Aditional
Contract Nr_Contr (FK)
Este intocmit la Data_Act_Ad
Data type
char(10)
Allow NULLs
Not allowed
char(10)
datetime
Not allowed
Not allowed
Foreign keys
Contract_Act_Aditional_FK1
Child
Contract Nr_Contr
Act_Aditional_Act_Aditional prevede
prestarea Serviciu Cant_serv_FK1

Serviciu Cant_serv.Este
identificat partial de
Nr_Act_Aditional
Serviciu Cant_serv.Contract
Nr_Contr
Column details
Anexe
158
Value/Range
Parent
Contract.Co
ntract
Nr_Contr
Este
identificat
partial de
Nr_Act_Adi
tional
Contract
Nr_Contr

Physical name:
Este identificat partial de Nr_Act_Aditional
Conceptual name:
Nr_Act_Aditional
Physical data type:
char(10)
Allow NULLs:
Not allowed
2. Contract Nr_Contr (FK)
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Contract Nr_Contr
Nr_Contr
char(10)
Not allowed
3. Este intocmit la Data_Act_Ad

Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Este intocmit la Data_Act_Ad

Data_Act_Ad
datetime
Not allowed

Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Contract Nr_Contr
Contract.Contract Nr_Contr
Identifying
Not allowed
poate avea
apartine unui
No action
No action
Relationship Contract_Act_Aditional_FK1: Contract.Contract Nr_Contr poate
avea Act_Aditional.Contract Nr_Contr.
Contract_Act_Aditional_FK1 is an identifying relationship.

Act_Aditional_Act_Aditional prevede prestarea Serviciu Cant_serv_FK1
Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Act_Aditional prevede prestarea Serviciu Cant_serv.Este identificat partial de
Nr_Act_Aditional
Nr_Act_Aditional
Act_Aditional prevede prestarea Serviciu Cant_serv.Contract Nr_Contr
Contract Nr_Contr
Identifying
One -to- One-or-More
Not allowed
has
is of
No action
No action
Relationship Act_Aditional_Act_Aditional prevede prestarea Serviciu
Cant_serv_FK1: Act_Aditional.[ Este identificat partial de Nr_Act_Aditional;
Contract Nr_Contr ] has Act_Aditional prevede prestarea Serviciu Cant_serv.
[ Este identificat partial de Nr_Act_Aditional; Contract Nr_Contr ].
Act_Aditional_Act_Aditional prevede prestarea Serviciu Cant_serv_FK1 is an
identifying relationship.
Cardinality: one to one-or-more.
Act_Aditional prevede prestarea Serviciu Cant_serv

Record:
Physical name:
Conceptual name:
ID:
3
692
Anexe
159

Owner:
Target DB name:
Independent:
Number of columns:
Number of indexes:
Primary key:
Codes:
Type:
Columns
Nr_Act_Aditional (FK)
Contract Nr_Contr (FK)
Serviciu Cod_Serv (FK)
Cant_serv
No
4
0
2
3. Serviciu Cod_Serv
0
Table
Data type
char(10)
Allow NULLs
Not allowed
char(10)
char(10)
smallint
Not allowed
Not allowed
Not allowed
Foreign keys
Act_Aditional_Act_Aditional prevede
prestarea Serviciu Cant_serv_FK1
Child
Este identificat
partial de
Nr_Act_Aditional
Contract Nr_Contr
Serviciu_Act_Aditional prevede prestarea

Serviciu Cant_serv_FK1
Serviciu Cod_Serv
Value/Range
Parent
Act_Aditional.Est
e identificat
partial de
Nr_Act_Aditional
Act_Aditional.Co
ntract Nr_Contr
Serviciu.Serviciu
Cod_Serv
Column details
1. Este identificat partial de Nr_Act_Aditional (FK)
Physical name:
Este identificat partial de Nr_Act_Aditional
Conceptual name:
Nr_Act_Aditional
Physical data type:
char(10)
Allow NULLs:
Not allowed
2. Contract Nr_Contr (FK)
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Contract Nr_Contr
Nr_Contr
char(10)
Not allowed
3. Serviciu Cod_Serv (FK)

Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Serviciu Cod_Serv
Cod_Serv
char(10)
Not allowed
4. Cant_serv
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Cant_serv
Cant_serv
smallint
Not allowed

Act_Aditional_Act_Aditional prevede prestarea Serviciu Cant_serv_FK1
Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Child
Parent
Este identificat partial de Nr_Act_Aditional Act_Aditional.Este identificat
partial de Nr_Act_Aditional
Contract Nr_Contr
Act_Aditional.Contract Nr_Contr
Identifying
Not allowed
has
is of
Anexe
160

Verbalization:
No action
No action
Relationship Act_Aditional_Act_Aditional prevede prestarea Serviciu
Cant_serv_FK1: Act_Aditional.[ Este identificat partial de Nr_Act_Aditional;
Contract Nr_Contr ] has Act_Aditional prevede prestarea Serviciu Cant_serv.
[ Este identificat partial de Nr_Act_Aditional; Contract Nr_Contr ].
Act_Aditional_Act_Aditional prevede prestarea Serviciu Cant_serv_FK1 is an
Serviciu_Act_Aditional prevede prestarea Serviciu Cant_serv_FK1

Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Serviciu Cod_Serv
Serviciu.Serviciu Cod_Serv
Identifying
Not allowed
has
is of
No action
No action
Relationship Serviciu_Act_Aditional prevede prestarea Serviciu
Cant_serv_FK1: Serviciu.Serviciu Cod_Serv has Act_Aditional prevede
prestarea Serviciu Cant_serv.Serviciu Cod_Serv.
Serviciu_Act_Aditional prevede prestarea Serviciu Cant_serv_FK1 is an
Agent
Record:
Physical name:
Conceptual name:
ID:
Owner:
Target DB name:
Independent:
Number of columns:
Number of indexes:
Primary key:
Codes:
Type:
Columns
Este inregistrat cu
Nr_Reg_Comert (U1)
Are Fax_Agent (U2)
Cod_Unic
Id_Pers (FK,U3)
Indexes
Agent_AK1 (U1)
Agent_AK2 (U2)
Agent_UC3 (U3)
Foreign keys
Persoana_Agent_FK1
Agent_Contract_FK1
Agent_Cont_Bancar_FK1
Agent_Cont_Email_FK1
4
Agent
Agent
595
Yes
4
3
1
Cod_Unic
0
Table
Data type
char(12)
Allow NULLs
Not allowed
char(13)
char(13)
char(13)
Not allowed
Not allowed
Not allowed
Columns
Este inregistrat cu
Nr_Reg_Comert
Are Fax_Agent
Id_Pers
Sort order
Ascending
Ascending
Ascending
Child
Id_Pers
Contract.Este intocmit de
Cod_Unic
Cont_Bancar.Agent utilizeaza
Cod_Unic
Cont_Email.Poate apartine
Cod_Unic
Anexe
Value/Range
161
Parent
Persoana.Id_Pers
Cod_Unic
Cod_Unic
Cod_Unic

Agent_Incasari_FK1
Incasari.Poate fi efectuata de la
Cod_Unic
Cod_Unic
Column details
1. Este inregistrat cu Nr_Reg_Comert (U1)
Physical name:
Este inregistrat cu Nr_Reg_Comert
Conceptual name:
Nr_Reg_Comert
Physical data type:
char(12)
Allow NULLs:
Not allowed
2. Are Fax_Agent (U2)
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Are Fax_Agent
Fax_Agent
char(13)
Not allowed
3. Cod_Unic
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Cod_Unic
Cod_Unic
char(13)
Not allowed
4. Id_Pers (FK,U3)
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Notes:
Index details
Agent_AK1
Column(s):
Unique:
Verbalization:
Agent_AK2
Column(s):
Unique:
Verbalization:
Agent_UC3
Column(s):
Unique:
Verbalization:
Id_Pers
Id_Pers
char(13)
Not allowed
Este inregistrat cu Nr_Reg_Comert (Asc)

Yes
Unique index 'Agent_AK1' on column Este inregistrat cu Nr_Reg_Comert is
ascending
Are Fax_Agent (Asc)
Yes
Unique index 'Agent_AK2' on column Are Fax_Agent is ascending
Id_Pers (Asc)
Yes
Unique index 'Agent_UC3' on column Id_Pers is ascending

Persoana_Agent_FK1
Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Id_Pers
Persoana.Id_Pers
Non-Identifying
Not allowed
is a
is a
No action
No action
Relationship Persoana_Agent_FK1: Persoana.Id_Pers is a Agent.Id_Pers.
Persoana_Agent_FK1 is a non identifying relationship.

Agent_Contract_FK1
Definition:
Child
Contract.Este intocmit de Cod_Unic
Anexe
162
Parent
Cod_Unic

Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Non-Identifying
Not allowed
Agent intocmeste
este intocmit de
No action
No action
Relationship Agent_Contract_FK1: Agent.Cod_Unic Agent intocmeste
Contract.Este intocmit de Cod_Unic.
Agent_Contract_FK1 is a non identifying relationship.
Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Cont_Bancar.Agent utilizeaza Cod_Unic
Cod_Unic
Non-Identifying
Not allowed
Agent utilizeaza
este utilizat de
No action
No action
Relationship Agent_Cont_Bancar_FK1: Agent.Cod_Unic Agent utilizeaza
Cont_Bancar.Agent utilizeaza Cod_Unic.
Agent_Cont_Bancar_FK1 is a non identifying relationship.
Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Cont_Email.Poate apartine Cod_Unic Cod_Unic
Non-Identifying
Allowed
Agent poate detine
poate apartine
No action
No action
Relationship Agent_Cont_Email_FK1: Agent.Cod_Unic Agent poate detine
Cont_Email.Poate apartine Cod_Unic.
Agent_Cont_Email_FK1 is a non identifying relationship.
Agent_Incasari_FK1
Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Incasari.Poate fi efectuata de la Cod_Unic Cod_Unic
Non-Identifying
Allowed
Agent plateste
No action
No action
Relationship Agent_Incasari_FK1: Agent.Cod_Unic Agent plateste
Incasari.Poate fi efectuata de la Cod_Unic.
Agent_Incasari_FK1 is a non identifying relationship.
Consum
Record:
Physical name:
Conceptual name:
ID:
Owner:
Target DB name:
5
Consum
Consum
666
Anexe
163

Independent:
Number of columns:
Number of indexes:
Primary key:
Codes:
Type:
No
8
0
1
1. Cont_Email Cont_User
2. Contine Ora_Conectare
3. Se efectueaza la Data_Consum
0
Table
Columns
Cont_Email Cont_User (FK)
Contine Ora_Conectare
Se efectueaza la Data_Consum
Contine Ora_Deconectare
Are Trafic_Intrare
Are Trafic_Iesire
Are Durata_Conectare
Are Trafic_Total
Foreign keys
Cont_Email_Consum_FK1
Data type
char(10)
datetime
datetime
datetime
numeric(10;0)
numeric(10;0)
datetime
numeric(10;0)
Child
Cont_Email Cont_User
Column details
1. Cont_Email Cont_User (FK)
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Cont_User
char(10)
Not allowed
2. Contine Ora_Conectare
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Contine Ora_Conectare
Ora_Conectare
datetime
Not allowed
3. Se efectueaza la Data_Consum
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Se efectueaza la Data_Consum
Data_Consum
datetime
Not allowed
4. Contine Ora_Deconectare
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Contine Ora_Deconectare
Ora_Deconectare
datetime
Not allowed
5. Are Trafic_Intrare
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Are Trafic_Intrare
Trafic_Intrare
numeric(10;0)
Not allowed
6. Are Trafic_Iesire
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Are Trafic_Iesire
Trafic_Iesire
numeric(10;0)
Not allowed
7. Are Durata_Conectare
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Are Durata_Conectare
Durata_Conectare
datetime
Not allowed
Anexe
164
Allow NULLs
Not allowed
Not allowed
Not allowed
Not allowed
Not allowed
Not allowed
Not allowed
Not allowed
Value/Range
Parent
Cont_Email.Cont_Ema
il Cont_User

8. Are Trafic_Total
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Are Trafic_Total
Trafic_Total
numeric(10;0)
Not allowed

Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Cont_Email.Cont_Email Cont_User
Identifying
Not allowed
has
No action
No action
Relationship Cont_Email_Consum_FK1: Cont_Email.Cont_Email Cont_User
has Consum.Cont_Email Cont_User.
Cont_Email_Consum_FK1 is an identifying relationship.
Cont_Bancar
Record:
Physical name:
Conceptual name:
ID:
Owner:
Target DB name:
Independent:
Number of columns:
Number of indexes:
Primary key:
Codes:
Type:
6
Cont_Bancar
Cont_Bancar
670
Yes
3
0
1
1. Banca Nume
2. Are Nr_Cont_Bancar
0
Table
Columns
Banca Nume
Data type
char(30)
Allow NULLs
Not allowed
Are Nr_Cont_Bancar
Agent utilizeaza Cod_Unic (FK)
char(20)
char(13)
Not allowed
Not allowed
Foreign keys
Child
Agent utilizeaza Cod_Unic
Value/Range
'BCR', 'BRD',
'BancPost',
'BancaIonTiriac',
'RaiffeisenBank'.
Parent
Agent.Cod_Unic
Column details
1. Banca Nume
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Value/Range:
Banca Nume
Nume
char(30)
Not allowed
'BCR', 'BRD', 'BancPost', 'BancaIonTiriac', 'RaiffeisenBank'.
2. Are Nr_Cont_Bancar
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Are Nr_Cont_Bancar
Nr_Cont_Bancar
char(20)
Not allowed
Anexe
165

3. Agent utilizeaza Cod_Unic (FK)
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:

Cod_Unic
char(13)
Not allowed

Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Agent.Cod_Unic
Non-Identifying
Not allowed
Agent utilizeaza
este utilizat de
No action
No action
Relationship Agent_Cont_Bancar_FK1: Agent.Cod_Unic Agent utilizeaza
Cont_Bancar.Agent utilizeaza Cod_Unic.
Agent_Cont_Bancar_FK1 is a non identifying relationship.
Cont_Email
Record:
Physical name:
Conceptual name:
ID:
Owner:
Target DB name:
Independent:
Number of columns:
Number of indexes:
Primary key:
Codes:
Type:
7
Cont_Email
Cont_Email
628
Yes
4
1
2
1
Table
Columns
Are Parola_User (U1)
Poate apartine Cod_Unic (FK)
Poate apartine CNP (FK)
Indexes
Cont_Email_AK1 (U1)
Foreign keys
Data type
char(10)
char(10)
char(13)
char(13)
Allow NULLs
Not allowed
Not allowed
Allowed
Allowed
Columns
Are Parola_User
Child
Poate apartine Cod_Unic
Poate apartine CNP
Consum.Cont_Email Cont_User
Column details
1. Cont_Email Cont_User
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Cont_User
char(10)
Not allowed
2. Are Parola_User (U1)

Physical name:
Are Parola_User
Anexe
166
Value/Range
Sort order
Ascending
Parent
Agent.Cod_Unic
Abonat.CNP
Cont_Email
Cont_User

Conceptual name:
Physical data type:
Allow NULLs:
Parola_User
char(10)
Not allowed
3. Poate apartine Cod_Unic (FK)

Physical name:
Conceptual name:
Physical data type:
Allow NULLs:

Cod_Unic
char(13)
Allowed
4. Poate apartine CNP (FK)

Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Poate apartine CNP

CNP
char(13)
Allowed
Code details
1. Cont_Email_excl
Notes:
/* The constraint:
/
/* No Cont_Email that poate apartine some Agent poate apartine some Abonat.
*/
/* is enforced by the following DDL.
*/
Type:
Code body:
Check clause
("Poate apartine Cod_Unic" is null) or ("Poate apartine CNP" is null)
Index details
Cont_Email_AK1
Column(s):
Unique:
Verbalization:
Are Parola_User (Asc)

Yes
Unique index 'Cont_Email_AK1' on column Are Parola_User is ascending

Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Agent.Cod_Unic
Non-Identifying
Allowed
Agent poate detine
poate apartine
No action
No action
Relationship Agent_Cont_Email_FK1: Agent.Cod_Unic Agent poate detine
Cont_Email.Poate apartine Cod_Unic.
Agent_Cont_Email_FK1 is a non identifying relationship.
Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Poate apartine CNP
Abonat.CNP
Non-Identifying
Allowed
Abonat poate detine
poate apartine
No action
No action
Relationship Abonat_Cont_Email_FK1: Abonat.CNP Abonat poate detine
Cont_Email.Poate apartine CNP.
Abonat_Cont_Email_FK1 is a non identifying relationship.

Anexe
167

Definition:
Child
Consum.Cont_Email Cont_User
Parent
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Identifying
Not allowed
has
No action
No action
Relationship Cont_Email_Consum_FK1: Cont_Email.Cont_Email Cont_User
has Consum.Cont_Email Cont_User.
Cont_Email_Consum_FK1 is an identifying relationship.
Contract
Record:
Physical name:
Conceptual name:
ID:
Owner:
Target DB name:
Independent:
Number of columns:
Number of indexes:
Primary key:
Codes:
Type:
8
Contract
Contract
671
Yes
6
2
3
Contract Nr_Contr
0
Table
Columns
Contract Nr_Contr
Este de tipul Tip_Contr (I2)
Data type
char(10)
char(20)
Allow NULLs
Not allowed
Not allowed
Este ncheiat la Data_Contr (I1)

Prevede prestarea unui Serviciu
Cod_Serv (FK)
Este intocmit de Cod_Unic (FK)
Abonat incheie CNP (FK)
datetime
char(10)
Not allowed
Not allowed
char(13)
char(13)
Not allowed
Not allowed
Value/Range
'AgentEconomi
c',
'AgentVanzari',
'PersoanaJuridi
ca',
'PersoanaFizica'
, 'Dealer'.
Indexes
Contract_IDX1 (I1)
Contract_IDX2 (I2)
Columns
Este ncheiat la Data_Contr
Este de tipul Tip_Contr
Sort order
Ascending
Ascending
Foreign keys
Serviciu_Contract_FK1
Child
Prevede prestarea unui Serviciu
Cod_Serv
Este intocmit de Cod_Unic
Abonat incheie CNP
Parent
Serviciu.Serviciu
Cod_Serv
Agent.Cod_Unic
Abonat.CNP
Contract Nr_Contr
Factura.Este intocmita pe baza

Contract pe baza Nr_Contr
Contract Nr_Contr
Agent_Contract_FK1
Abonat_Contract_FK1
Contract_Act_Aditional_FK
1
Contract_Factura_FK1
Column details
Physical name:
Contract Nr_Contr
Anexe
168

Conceptual name:
Physical data type:
Allow NULLs:
Nr_Contr
char(10)
Not allowed
2. Este de tipul Tip_Contr (I2)

Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Value/Range:
Este de tipul Tip_Contr

Tip_Contr
char(20)
Not allowed
'AgentEconomic', 'AgentVanzari', 'PersoanaJuridica', 'PersoanaFizica', 'Dealer'.
3. Este ncheiat la Data_Contr (I1)

Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Este ncheiat la Data_Contr

Data_Contr
datetime
Not allowed
4. Prevede prestarea unui Serviciu Cod_Serv (FK)

Physical name:
Prevede prestarea unui Serviciu Cod_Serv
Conceptual name:
Cod_Serv
Physical data type:
char(10)
Allow NULLs:
Not allowed
5. Este intocmit de Cod_Unic (FK)
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:

Cod_Unic
char(13)
Not allowed
6. Abonat incheie CNP (FK)

Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Abonat incheie CNP

CNP
char(13)
Not allowed
Index details
Contract_IDX1
Column(s):
Unique:
Verbalization:
Contract_IDX2
Column(s):
Unique:
Verbalization:
Este ncheiat la Data_Contr (Asc)

No
Non-unique index 'Contract_IDX1' on column Este ncheiat la Data_Contr is
ascending
Este de tipul Tip_Contr (Asc)
No
Non-unique index 'Contract_IDX2' on column Este de tipul Tip_Contr is
ascending

Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Prevede prestarea unui Serviciu Cod_Serv Serviciu.Serviciu Cod_Serv
Non-Identifying
Not allowed
poate apartine unui
prevede prestarea unui
No action
No action
Relationship Serviciu_Contract_FK1: Serviciu.Serviciu Cod_Serv poate apartine
unui Contract.Prevede prestarea unui Serviciu Cod_Serv.
Serviciu_Contract_FK1 is a non identifying relationship.
Agent_Contract_FK1
Definition:
Child
Parent
Anexe
169

Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:

Agent.Cod_Unic
Non-Identifying
Not allowed
Agent intocmeste
este intocmit de
No action
No action
Relationship Agent_Contract_FK1: Agent.Cod_Unic Agent intocmeste
Contract.Este intocmit de Cod_Unic.
Agent_Contract_FK1 is a non identifying relationship.
Abonat_Contract_FK1
Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Abonat incheie CNP
Abonat.CNP
Non-Identifying
Not allowed
Abonat incheie
este incheiat
No action
No action
Relationship Abonat_Contract_FK1: Abonat.CNP Abonat incheie
Contract.Abonat incheie CNP.
Abonat_Contract_FK1 is a non identifying relationship.

Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Contract Nr_Contr
Identifying
Not allowed
poate avea
apartine unui
No action
No action
Relationship Contract_Act_Aditional_FK1: Contract.Contract Nr_Contr poate
avea Act_Aditional.Contract Nr_Contr.
Contract_Act_Aditional_FK1 is an identifying relationship.
Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Factura.Este intocmita pe baza Contract pe baza Nr_Contr
Contract
Nr_Contr
Non-Identifying
Not allowed
has
No action
No action
Relationship Contract_Factura_FK1: Contract.Contract Nr_Contr has
Factura.Este intocmita pe baza Contract pe baza Nr_Contr.
Contract_Factura_FK1 is a non identifying relationship.
Factura
Record:
Physical name:
9
Factura
Anexe
170

Conceptual name:
ID:
Owner:
Target DB name:
Independent:
Number of columns:
Number of indexes:
Primary key:
Codes:
Type:
Factura
602
Yes
6
1
1
Factura Nr_Fact
1
Table
Columns
Factura Nr_Fact
Este emisa la Data_Fact (I1)
Are Serie_Fact
Are Val_Fact_Lei
Are Val_Fact_Dolari
Este intocmita pe baza Contract pe
baza Nr_Contr (FK)
Data type
char(10)
datetime
char(2)
numeric(10;0)
numeric(10;0)
char(10)
Indexes
Factura_IDX1 (I1)
Columns
Este emisa la Data_Fact
Sort order
Ascending
Foreign keys
Child
Este intocmita pe baza Contract
pe baza Nr_Contr
Incasari.Factura Nr_Fact
Parent
Contract.Contract
Nr_Contr
Factura Nr_Fact
Factura_Incasari_FK1
Column details
1. Factura Nr_Fact
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Factura Nr_Fact
Nr_Fact
char(10)
Not allowed
2. Este emisa la Data_Fact (I1)

Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Este emisa la Data_Fact

Data_Fact
datetime
Not allowed
3. Are Serie_Fact
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Are Serie_Fact
Serie_Fact
char(2)
Not allowed
4. Are Val_Fact_Lei
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Are Val_Fact_Lei
Val_Fact_Lei
numeric(10;0)
Allowed
5. Are Val_Fact_Dolari
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Are Val_Fact_Dolari
Val_Fact_Dolari
numeric(10;0)
Allowed
Allow NULLs
Not allowed
Not allowed
Not allowed
Allowed
Allowed
Not allowed
Value/Range
6. Este intocmita pe baza Contract pe baza Nr_Contr (FK)

Physical name:
Este intocmita pe baza Contract pe baza Nr_Contr
Conceptual name:
Nr_Contr
Physical data type:
char(10)
Allow NULLs:
Not allowed
Anexe
171

Code details
1. Factura_MR
Notes:
Type:
Code body:
Index details
Factura_IDX1
Column(s):
Unique:
Verbalization:
/* The constraint:
*/
/* Each Factura are some Val_Fact_Dolari or are some Val_Fact_Lei.
*/
/* is enforced by the following DDL. */
Check clause
("Are Val_Fact_Dolari" is not null) or
("Are Val_Fact_Lei" is not null)
Este emisa la Data_Fact (Asc)

No
Non-unique index 'Factura_IDX1' on column Este emisa la Data_Fact is
ascending

Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Este intocmita pe baza Contract pe baza Nr_Contr
Contract.Contract
Nr_Contr
Non-Identifying
Not allowed
has
No action
No action
Relationship Contract_Factura_FK1: Contract.Contract Nr_Contr has
Factura.Este intocmita pe baza Contract pe baza Nr_Contr.
Contract_Factura_FK1 is a non identifying relationship.

Definition:
Child
Incasari.Factura Nr_Fact
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Identifying
Not allowed
has
No action
No action
Relationship Factura_Incasari_FK1: Factura.Factura Nr_Fact has
Incasari.Factura Nr_Fact.
Factura_Incasari_FK1 is an identifying relationship.
Incasari
Record:
Physical name:
Conceptual name:
ID:
Owner:
Target DB name:
Independent:
Number of columns:
10
Incasari
Incasari
609
No
8
Anexe
172
Parent
Factura Nr_Fact

Number of indexes:
Primary key:
Codes:
Type:
0
3
1. Factura Nr_Fact
2. Se face pe baza Tip_Document
1
Table
Columns
Data type
Factura Nr_Fact (FK)

Se face pe baza Tip_Document
char(10)
char(15)
Allow
NULLs
Not allowed
Not allowed
Are Nr_Document_Incasare
Se efectueaza la Data_Incasarii
Are o Val_Incasare_Lei
Are o Val_Incasare_Dolari
Poate fi efectuata de la CNP (FK)
Poate fi efectuata de la Cod_Unic (FK)
char(10)
datetime
numeric(10;0)
numeric(10;0)
char(13)
char(13)
Not allowed
Not allowed
Allowed
Allowed
Allowed
Allowed
Foreign keys
Child
Factura Nr_Fact
Abonat_Incasari_FK1
Agent_Incasari_FK1
Poate fi efectuata de la CNP

Poate fi efectuata de la Cod_Unic
Column details
1. Factura Nr_Fact (FK)
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Factura Nr_Fact
Nr_Fact
char(10)
Not allowed
2. Se face pe baza Tip_Document

Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Value/Range:
Se face pe baza Tip_Document

Tip_Document
char(15)
Not allowed
'OrdinPlata', 'Chitanta', 'FillaCEC'.
3. Are Nr_Document_Incasare
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Are Nr_Document_Incasare
char(10)
Not allowed
4. Se efectueaza la Data_Incasarii
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Se efectueaza la Data_Incasarii
Data_Incasarii
datetime
Not allowed
5. Are o Val_Incasare_Lei
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Are o Val_Incasare_Lei
Val_Incasare_Lei
numeric(10;0)
Allowed
6. Are o Val_Incasare_Dolari
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Are o Val_Incasare_Dolari
Val_Incasare_Dolari
numeric(10;0)
Allowed
7. Poate fi efectuata de la CNP (FK)
Anexe
173
Value/Range
'OrdinPlata',
'Chitanta',
'FillaCEC'.
Parent
Factura.Factura
Nr_Fact
Abonat.CNP
Agent.Cod_Unic

Physical name:
Conceptual name:
Physical data type:
Allow NULLs:

CNP
char(13)
Allowed
8. Poate fi efectuata de la Cod_Unic (FK)

Physical name:
Conceptual name:
Cod_Unic
Physical data type:
char(13)
Allow NULLs:
Allowed
Code details
1. Incasari_MR
Notes:
Type:
Code body:
/* The constraint:
*/
/* Each Incasari are o some Val_Incasare_Lei or are o some
Val_Incasare_Dolari.
*/
*/
Check clause
("Are o Val_Incasare_Lei" is not null) or
("Are o Val_Incasare_Dolari" is not null)

Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Factura Nr_Fact
Factura.Factura Nr_Fact
Identifying
Not allowed
has
No action
No action
Relationship Factura_Incasari_FK1: Factura.Factura Nr_Fact has
Incasari.Factura Nr_Fact.
Factura_Incasari_FK1 is an identifying relationship.
Abonat_Incasari_FK1
Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Abonat.CNP
Non-Identifying
Allowed
Abonat plateste
No action
No action
Relationship Abonat_Incasari_FK1: Abonat.CNP Abonat plateste Incasari.Poate
fi efectuata de la CNP.
Abonat_Incasari_FK1 is a non identifying relationship.
Agent_Incasari_FK1
Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Agent.Cod_Unic
Non-Identifying
Allowed
Agent plateste
No action
No action
Relationship Agent_Incasari_FK1: Agent.Cod_Unic Agent plateste
Incasari.Poate fi efectuata de la Cod_Unic.
Anexe
174

Agent_Incasari_FK1 is a non identifying relationship.
Judet
Record:
Physical name:
Conceptual name:
ID:
Owner:
Target DB name:
Independent:
Number of columns:
Number of indexes:
Primary key:
Codes:
Type:
11
Judet
Judet
617
Yes
2
1
0
Judet Abrev_Jud
0
Table
Columns
Judet Abrev_Jud
Are Denumire_Jud (U1)
Data type
char(2)
char(20)
Indexes
Judet_AK1 (U1)
Allow NULLs
Not allowed
Not allowed
Columns
Are Denumire_Jud
Foreign keys
Judet_Localitate face parte din
Judet_FK1
Judet_Persoana_FK1
Child
Localitate face parte din
Judet.Judet Abrev_Jud
Persoana.Are adresa Judet
Abrev_Jud
Value/Range
Sort order
Ascending
Parent
Judet Abrev_Jud
Judet Abrev_Jud
Column details
1. Judet Abrev_Jud
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Judet Abrev_Jud
Abrev_Jud
char(2)
Not allowed
2. Are Denumire_Jud (U1)

Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Are Denumire_Jud
Denumire_Jud
char(20)
Not allowed
Index details
Judet_AK1
Column(s):
Unique:
Verbalization:
Are Denumire_Jud (Asc)

Yes
Unique index 'Judet_AK1' on column Are Denumire_Jud is ascending

Judet_Localitate face parte din Judet_FK1
Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Localitate face parte din Judet.Judet Abrev_Jud
Judet Abrev_Jud
Identifying
Not allowed
has
face parte din
No action
No action
Relationship Judet_Localitate face parte din Judet_FK1: Judet.Judet Abrev_Jud
Anexe
175

has Localitate face parte din Judet.Judet Abrev_Jud.
Judet_Localitate face parte din Judet_FK1 is an identifying relationship.
Judet_Persoana_FK1
Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Persoana.Are adresa Judet Abrev_Jud Judet Abrev_Jud
Non-Identifying
Not allowed
has
are adresa in
No action
No action
Relationship Judet_Persoana_FK1: Judet.Judet Abrev_Jud has Persoana.Are
adresa Judet Abrev_Jud.
Judet_Persoana_FK1 is a non identifying relationship.
Localitate
Record:
Physical name:
Conceptual name:
ID:
Owner:
Target DB name:
Independent:
Number of columns:
Number of indexes:
Primary key:
Codes:
Type:
12
Localitate
Localitate
622
Yes
2
1
0
Localitate Abrev_Loc
0
Table
Columns
Are Denumire_Loc (I1)
Data type
char(20)
char(2)
Indexes
Localitate_IDX1 (I1)
Columns
Are Denumire_Loc
Foreign keys
Localitate_Persoana_FK1
Localitate_Localitate face parte din
Judet_FK1
Allow NULLs
Not allowed
Not allowed
Child
Persoana.Are adresa
Localitate face parte
din Judet.Localitate
Abrev_Loc
Column details
1. Are Denumire_Loc (I1)
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Are Denumire_Loc
Denumire_Loc
char(20)
Not allowed
2. Localitate Abrev_Loc
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Abrev_Loc
char(2)
Not allowed
Index details
Localitate_IDX1
Anexe
176
Value/Range
Sort order
Ascending
Parent

Column(s):
Unique:
Verbalization:
Are Denumire_Loc (Asc)

No
Non-unique index 'Localitate_IDX1' on column Are Denumire_Loc is ascending

Definition:
Child
Parent
Persoana.Are adresa Localitate Abrev_Loc Localitate Abrev_Loc
Relationship type:
Non-Identifying
Cardinality:
Allow NULLs:
Not allowed
Verb phrase:
has
Inverse phrase:
are adresa in
No action
No action
Verbalization:
Relationship Localitate_Persoana_FK1: Localitate.Localitate Abrev_Loc has
Persoana.Are adresa Localitate Abrev_Loc.
Localitate_Persoana_FK1 is a non identifying relationship.
Localitate_Localitate face parte din Judet_FK1
Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Verbalization:
Child
Parent
Localitate face parte din Judet.Localitate Abrev_Loc Localitate Abrev_Loc
Identifying
Not allowed
face parte din
No action
No action
Relationship Localitate_Localitate face parte din Judet_FK1:
Localitate.Localitate Abrev_Loc face parte din Localitate face parte din
Judet.Localitate Abrev_Loc.
Localitate_Localitate face parte din Judet_FK1 is an identifying relationship.

Record:
Physical name:
Conceptual name:
ID:
Owner:
Target DB name:
Independent:
Number of columns:
Number of indexes:
Primary key:
Codes:
Type:
13
625
No
2
0
2
1. Localitate Abrev_Loc
2. Judet Abrev_Jud
0
Table
Columns
Localitate Abrev_Loc (FK)
Judet Abrev_Jud (FK)
Foreign keys
Judet_Localitate face parte din
Judet_FK1
Localitate_Localitate face parte din
Judet_FK1
Data type
char(2)
char(2)
Allow NULLs
Not allowed
Not allowed
Child
Judet Abrev_Jud
Column details
1. Localitate Abrev_Loc (FK)
Anexe
177
Value/Range
Parent
Judet.Judet
Abrev_Jud
Localitate.Localita
te Abrev_Loc

Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Abrev_Loc
char(2)
Not allowed
2. Judet Abrev_Jud (FK)

Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Judet Abrev_Jud
Abrev_Jud
char(2)
Not allowed

Judet_Localitate face parte din Judet_FK1
Definition:
Child
Parent
Judet Abrev_Jud
Relationship type:
Identifying
Cardinality:
Allow NULLs:
Not allowed
Verb phrase:
has
Inverse phrase:
face parte din
No action
No action
Verbalization:
Relationship Judet_Localitate face parte din Judet_FK1: Judet.Judet Abrev_Jud
has Localitate face parte din Judet.Judet Abrev_Jud.
Judet_Localitate face parte din Judet_FK1 is an identifying relationship.
Localitate_Localitate face parte din Judet_FK1
Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Verbalization:
Child
Parent
Localitate.Localitate Abrev_Loc
Identifying
Not allowed
face parte din
No action
No action
Relationship Localitate_Localitate face parte din Judet_FK1:
Localitate.Localitate Abrev_Loc face parte din Localitate face parte din
Judet.Localitate Abrev_Loc.
Localitate_Localitate face parte din Judet_FK1 is an identifying relationship.
Persoana
Record:
Physical name:
Conceptual name:
ID:
Notes:
Owner:
Target DB name:
Independent:
Number of columns:
Number of indexes:
Primary key:
Codes:
Type:
Columns
Id_Pers
Are Nume
Are Adresa
14
Persoana
Persoana
679
Yes
9
2
2
Id_Pers
1
Table
Data type
char(13)
char(30)
char(30)
Anexe
178
Allow NULLs
Not allowed
Not allowed
Not allowed
Value/Range

Are Telefon (U1)
Are Mobil (U2)
Este Tip_Persoana
Are adresa Localitate Abrev_Loc
(FK)
Poate avea casuta postala
Are adresa Judet Abrev_Jud (FK)
Indexes
Persoana_UC1 (U1)
Persoana_UC2 (U2)
Foreign keys
Localitate_Persoana_FK
1
Judet_Persoana_FK1
Persoana_Agent_FK1
Persoana_Abonat_FK1
Column details
1. Id_Pers
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Notes:
char(13)
char(13)
char(20)
char(2)
Allowed
Allowed
Not allowed
Not allowed
bit
char(2)
Not allowed
Not allowed
Columns
Are Telefon
Are Mobil
'PF', 'PJ'.
Sort order
Ascending
Ascending
Child
Are adresa Judet Abrev_Jud
Agent.Id_Pers
Abonat.Id_Pers
Parent
Localitate.Localitate
Abrev_Loc
Id_Pers
Id_Pers
Id_Pers
Id_Pers
char(13)
Not allowed
2. Are Nume
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Are Nume
Nume
char(30)
Not allowed
3. Are Adresa
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Are Adresa
Adresa
char(30)
Not allowed
4. Are Telefon (U1)

Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Are Telefon
Telefon
char(13)
Allowed
5. Are Mobil (U2)

Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Are Mobil
Mobil
char(13)
Allowed
6. Este Tip_Persoana
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Value/Range:
Este Tip_Persoana
Tip_Persoana
char(20)
Not allowed
'PF', 'PJ'.
7. Are adresa Localitate Abrev_Loc (FK)

Physical name:
Conceptual name:
Abrev_Loc
Physical data type:
char(2)
Allow NULLs:
Not allowed
Anexe
179

8. Poate avea casuta postala
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Notes:
9. Are adresa Judet Abrev_Jud (FK)
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Code details
1. Persoana_MR
Notes:
Type:
Code body:
Index details
Persoana_UC1
Column(s):
Unique:
Verbalization:
Persoana_UC2
Column(s):
Unique:
Verbalization:

bit
Not allowed
Abrev_Jud
char(2)
Not allowed
/* The constraint:
*/
/* Each Persoana are some Telefon or are some Mobil. */
*/
Check clause
("Are Telefon" is not null) or
("Are Mobil" is not null)
Are Telefon (Asc)

Yes
Unique index 'Persoana_UC1' on column Are Telefon is ascending
Are Mobil (Asc)
Yes
Unique index 'Persoana_UC2' on column Are Mobil is ascending

Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Localitate.Localitate Abrev_Loc
Non-Identifying
Not allowed
has
are adresa in
No action
No action
Relationship Localitate_Persoana_FK1: Localitate.Localitate Abrev_Loc has
Persoana.Are adresa Localitate Abrev_Loc.
Localitate_Persoana_FK1 is a non identifying relationship.
Judet_Persoana_FK1
Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Non-Identifying
Not allowed
has
are adresa in
No action
No action
Relationship Judet_Persoana_FK1: Judet.Judet Abrev_Jud has Persoana.Are
adresa Judet Abrev_Jud.
Judet_Persoana_FK1 is a non identifying relationship.
Anexe
180

Persoana_Agent_FK1
Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Agent.Id_Pers
Id_Pers
Non-Identifying
Not allowed
is a
is a
No action
No action
Relationship Persoana_Agent_FK1: Persoana.Id_Pers is a Agent.Id_Pers.
Persoana_Agent_FK1 is a non identifying relationship.
Persoana_Abonat_FK1
Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:
Child
Parent
Abonat.Id_Pers
Id_Pers
Non-Identifying
Not allowed
is a
is a
No action
No action
Relationship Persoana_Abonat_FK1: Persoana.Id_Pers is a Abonat.Id_Pers.
Persoana_Abonat_FK1 is a non identifying relationship.
Serviciu
Record:
Physical name:
Conceptual name:
ID:
Owner:
Target DB name:
Independent:
Number of columns:
Number of indexes:
Primary key:
Codes:
Type:
15
Serviciu
Serviciu
638
Yes
6
0
0
Serviciu Cod_Serv
0
Table
Columns
Data type
Serviciu Cod_Serv
Se caracterizeaza prin Timp_acces
Se caracterizeaza prin Trafic
char(10)
char(10)
char(10)
Allow
NULLs
Not allowed
Not allowed
Not allowed
Are Val_Serviciu
Se efectueaza printrun
Mediu_Transmisie
Poate avea Tarif_Conectare
numeric(10;0)
char(20)
Not allowed
Not allowed
numeric(10;0)
Allowed
Foreign keys
Serviciu_Act_Aditional prevede prestarea
Serviciu Cant_serv_FK1
Serviciu_Serviciu are Tip_conectivitate_FK1
Anexe
Child
Act_Aditional prevede
prestarea Serviciu
Cant_serv.Serviciu
Cod_Serv
Serviciu are
Tip_conectivitate.Servici
u Cod_Serv
181
Value/Range
'MB', 'GB',
'Nelimitat'.
Parent
Serviciu
Cod_Serv
Serviciu
Cod_Serv

Contract.Prevede
prestarea unui Serviciu
Cod_Serv
Column details
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Serviciu Cod_Serv
Cod_Serv
char(10)
Not allowed
2. Se caracterizeaza prin Timp_acces

Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Se caracterizeaza prin Timp_acces

Timp_acces
char(10)
Not allowed
3. Se caracterizeaza prin Trafic

Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Value/Range:
Se caracterizeaza prin Trafic

Trafic
char(10)
Not allowed
'MB', 'GB', 'Nelimitat'.
4. Are Val_Serviciu
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Are Val_Serviciu
Val_Serviciu
numeric(10;0)
Not allowed
Serviciu
Cod_Serv
5. Se efectueaza printrun Mediu_Transmisie

Physical name:
Se efectueaza printrun Mediu_Transmisie
Conceptual name:
Mediu_Transmisie
Physical data type:
char(20)
Allow NULLs:
Not allowed
6. Poate avea Tarif_Conectare
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Poate avea Tarif_Conectare

Tarif_Conectare
numeric(10;0)
Allowed

Serviciu_Act_Aditional prevede prestarea Serviciu Cant_serv_FK1
Definition:
Child
Parent
Act_Aditional prevede prestarea Serviciu Cant_serv.Serviciu Cod_Serv
Serviciu Cod_Serv
Relationship type:
Identifying
Cardinality:
Allow NULLs:
Not allowed
Verb phrase:
has
Inverse phrase:
is of
No action
No action
Verbalization:
Relationship Serviciu_Act_Aditional prevede prestarea Serviciu
Cant_serv_FK1: Serviciu.Serviciu Cod_Serv has Act_Aditional prevede
prestarea Serviciu Cant_serv.Serviciu Cod_Serv.
Serviciu_Act_Aditional prevede prestarea Serviciu Cant_serv_FK1 is an
Definition:
Relationship type:
Child
Parent
Serviciu are Tip_conectivitate.Serviciu Cod_Serv
Identifying
Anexe
182
Serviciu Cod_Serv

Cardinality:
Allow NULLs:
Verb phrase:
Verbalization:

Not allowed
are
No action
No action
Relationship Serviciu_Serviciu are Tip_conectivitate_FK1: Serviciu.Serviciu
Cod_Serv are Serviciu are Tip_conectivitate.Serviciu Cod_Serv.
Serviciu_Serviciu are Tip_conectivitate_FK1 is an identifying relationship.
Definition:
Child
Parent
Contract.Prevede prestarea unui Serviciu Cod_Serv Serviciu Cod_Serv
Non-Identifying
Not allowed
poate apartine unui
prevede prestarea unui
No action
No action
Relationship Serviciu_Contract_FK1: Serviciu.Serviciu Cod_Serv poate apartine
unui Contract.Prevede prestarea unui Serviciu Cod_Serv.
Serviciu_Contract_FK1 is a non identifying relationship.
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Inverse phrase:
Verbalization:

Record:
Physical name:
Conceptual name:
ID:
Owner:
Target DB name:
Independent:
Number of columns:
Number of indexes:
Primary key:
Codes:
Type:
16
687
No
2
0
1
2. Are Tip_conectivitate
0
Table
Columns
Serviciu Cod_Serv (FK)
Are Tip_conectivitate
Data type
char(10)
char(20)
Foreign keys
Serviciu_Serviciu are
Tip_conectivitate_FK1
Allow NULLs
Not allowed
Not allowed
Child
Serviciu Cod_Serv
Column details
1. Serviciu Cod_Serv (FK)
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Serviciu Cod_Serv
Cod_Serv
char(10)
Not allowed
2. Are Tip_conectivitate
Physical name:
Conceptual name:
Physical data type:
Allow NULLs:
Are Tip_conectivitate
Tip_conectivitate
char(20)
Not allowed

Anexe
183
Value/Range
Parent
Serviciu.Serviciu
Cod_Serv

Definition:
Relationship type:
Cardinality:
Allow NULLs:
Verb phrase:
Verbalization:
Child
Parent
Serviciu Cod_Serv
Serviciu.Serviciu Cod_Serv
Identifying
Not allowed
are
No action
No action
Relationship Serviciu_Serviciu are Tip_conectivitate_FK1: Serviciu.Serviciu
Cod_Serv are Serviciu are Tip_conectivitate.Serviciu Cod_Serv.
Serviciu_Serviciu are Tip_conectivitate_FK1 is an identifying relationship.
Anexe
184
Anexa nr.5 Raport statistic
Type:
Author:
Comments:
Last modified by:
Revision number: 2.2
03.11.2004
03.11.2004
0
Date created:
Date last modified:
Date last printed:
Number of pages:
Total number of tables:
Total number of columns:
Nulls not allowed:
Nulls allowed:
16
76
Total number of foreign keys:
21
Total number of indexes:

Alternate keys:
Non-unique indexes:
14
Total number of object types:

Value object types:
External object types:
Entities
w/Ref. Mode:
Nested:
Other:
53
Subtypes:
Independent object types:
2
0
Total number of facts:

Unary facts:
Binary facts:
Ternary facts:
Quaternary facts:
Other facts (Arity >4):
External facts:
Nested facts:
62
Total number of constraints:

Uniqueness (Internal):
Uniqueness (External):
Mandatory (Single):
Mandatory (Disjunctive):
Equality:
Subset:
Frequency:
Exclusion:
Ring:
Index (Internal):
Index (External):
142
65
11
9
5
43
0
10
0
0
1
60
1
0
0
0
0
69
5
58
3
0
0
0
2
0
0
5
Bibliografie
185

Modelarea BD Cu Visio Studenti

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Modelarea BD Cu Visio Studenti

Încărcat de

Drepturi de autor:

Formate disponibile

Gabriela Vrlan

Modelarea bazelor de date.

Universitatea Dunrea de Jos

Modelarea bazelor de date

5. Generarea unui model surs ORM....................................................12

6.1. Tipuri de constrngeri ORM..............................................................................21

8. Transpunerea unui model ORM ntr-un model logic al bazei de date

8.1. Crearea unui proiect nou....................................................................................57

9. Generarea schemei fizice a bazei de date....................................74

Modelarea bazelor de date

4. Proiectarea bazelor de date

4.1. Puin teorie

elementele software ale bazei de date;

elementele hardware ale calculatorului;

personalul care utilizeaz i dezvolt sistemul.

proiectarea conceptual a datelor i operaiilor;

Modelarea bazelor de date

proiectarea intern i implementarea;

planificarea bazei de date;

colectarea i analiza cerinelor;

proiectarea bazei de date;

alegerea sistemului SGBD (opional);

realizarea prototipului (opional);

conversia i implementarea datelor;

reprezentarea datelor i a relaiilor dintre ele, necesare tuturor domeniilor de aplicaie i

atributelor, a asociaiilor dintre atribute, i n final gruparea acestora n entiti. Un astfel de

De asemenea, toate metodologiile utilizate n etapa de proiectare (numit i etapa de modelare) a

Proiectarea conceptual (elaborarea modelului conceptual) reprezint procesul de

construire a unui model al informaiilor utilizate n cadrul unei organizaii, independent de

Modelarea bazelor de date

Proiectarea fizic (elaborarea modelului fizic) reprezint procesul de realizare a unei

descrieri a implementrii bazei de date ntr-o capacitate de stocare secundar; descrie

pornind de la o baz de date existent, utiliznd procedeul reverse engineering (proiectare

4.2. Object Role Modeling

este fiabil valideaz regulile folosind limba englez i mostre de date;

este stabil minimizeaz impactul modificrilor asupra modelului i interogrilor.

Modelarea bazelor de date

4.3. Proiectarea unui model surs ORM

Fig. 4.1. Setarea opiunilor pentru utilizarea

Modelarea bazelor de date

n continuare se urmresc instruciunile din urmtoarele cutii de dialog.

Fig. 4.2. Alegerea sursei de date

n continuare se precizeaz tipurile de informaii care se doresc a fi extrase (importate) din

Fig. 4.3. Selectarea tipurilor de informaii

Proiectarea bazelor de date utiliznd regulile de afaceri

Modelarea bazelor de date

Este indicat s se revizuiasc setrile de import (informaiile selectate), i apoi se acioneaz

Fig. 4.4. Selectarea tabeleleor necesare proiectrii noi baze de date

Fig. 4.5. Selectarea procedurilor stocate

Fig. 4.6. Verificarea informaiilor setate

Modelarea bazelor de date

Fig. 4.7. n pagina Output vor fi afiate informaiilor

Modelarea bazelor de date

Modelarea bazelor de date

Fig. 4.8. Tragerea unui tip de fapt pentru vizualizarea acestuia

Fig. 4.9. Alegerea opiunii pentru vizualizarea tuturor relaiilor

Fig. 4.10. Afiarea tuturor relaiilor

Proiectarea bazelor de date utiliznd regulile de afaceri

Modelarea bazelor de date

Fig. 4.11. Afiarea rezultatelor

n fereastra Business Rules, se selecteaz tipurile de faptele care se doresc a fi vizualizate, i

Fig. 4.12. Afiarea unor tipuri de fapte

Proiectarea bazelor de date utiliznd regulile de afaceri

Modelarea bazelor de date