ACADEMIA ORACLE
BUCURESTI
MAI 2007
INSTRUCTOR: Sanda Popescu
Bine aţi venit la trainingul Academiei Oracle de
DataBase Design şi DataBase Programming (SQL).
Scopul Institutului este de a aprofunda conceptele şi
secretele modelării BD şi a limbajului SQL.
History of the Database
Orice prelucrare, accesare a unei date, face ca aceasta sa devină
informaţie. Exemple: punctajul obtinut de către un student este o
dată, media aritmetică a punctajelor reprezintă o informaţie
Etapele procesului de dezvoltare al bazelor de date :
Strategie – capturarea informatiilor necesare, conform regulilor afacerii, etapa
din care va rezulta modelul conceptual – Sectiunile 2- 11
Analiza - maparea relatiilor dintre entitati– din modelul conceptual E, A, R şi
identificatorii unici vor fi translatati în obiecte ale bazei de date
relaţionale – Secţiunile 11(PK,FK,UK), 12.
Design - modelul conceptual va fi transformat într-un design relational al
viitoarei baze de date - Sectiune 12
Build – construcţia BD cu ajutorului SGBD – SQL, folosind DDL, DML, DCL
(limbajele de definire, manipulare, control si administrare a BD), astfel
incât BD sa devină operaţională.- modelul fizic- incepând cu
secţiunea 13 din modulul de database-design
E1 - Strategie : Modelul conceptual pentru scenariul prezentat
E2/3 - Analiza/Design
E4- Build - Modelul fizic
Sectiune2- Lectie 1
MODELUL CONCEPTUAL
- modelează nevoile funcţionale şi informaţionale ale afacerii
- se bazează pe nevoile curente dar poate reflecta nevoile viitoare
- este numit şi Modelul Entitate Relaţii (Entity Relationship Model)
Scopul Modelarii Relatiilor dintre Enitati:
- să captureze toate informaţiile necesare
- orice informaţie să apară o singură dată
- să modeleze numai informaţiile care nu sunt derivabile din alte informaţii
deja modelate
- să plaseze informaţiile în locurile logice, fiecare la locul ei
TRY IT / SOLVE IT
ENTITATE
- este ceva semnificativ (important) pentru afacere, despre care
trebuie cunoscute date
- este un nume pentru lucruri pe care le poţi lista
- entităţile sunt substantive la singular
Entitatile pot fi :
- tangibile : Exemplu : PERSON OR PRODUCT
- non-tangibile : SKILL LEVEL ( nivelul de performanta)
- un eveniment : CONCERT
Ele au instanţe: FRUIT: portocale, mere, lămâi şi atribute (nume, culoare,
preţ)
ENTITATI SI INSTANTE
- este de asemenea ceva semnificativ pentru afacere
- este o proprietate a entităţii cu o singură valoare
- este o informaţie specifică care descrie, cuantifică, califică,
clasifică sau specifică o entitate
- este un mic detaliu despre entitate
- are tip (ex. numeric, caracter, data calendaristica, imagine, sunet….
= tipuri de date sau formate)
ATRIBUTE
UID: artificial - acela care nu-ti trece prin minte in mod
natural, dar va fi creat în scopul de a identifica o anumită
instanţă din sistem
simplu - format dintr-un singur atribut
compus – o combinaţie de atribute; sau o combinatie dintre un
atribut + relatie
TRY IT / SOLVE IT
TRY IT / SOLVE IT
TRY IT / SOLVE IT
OPTIONALITY: Not required; left to choice
DATA TYPE: A classification identifying one of various
types of data, stating the possible values for that type, the
operations that can be done on that type, and the way the
values of that type are stored.
ATTRIBUTE: Characteristic, something that describes,
quantifies or specifies an entity.
ENTITY: A named thing or category of things that is
significant to the business and about which data must be
known.
INSTANCE: An occurrence or example
MANDATORY: Required, necessary, imperative.
NONTANGIBILE: Incapable of being perceived by the
senses. Same as intangible.
NULL: A value that is unavailable, unassigned, unknown,
or inapplicable; it is not a zero or space.
OPTIONAL: Not required; left to choice.
TANGIBLE: Perceptible by the senses especially the
sense of touch.
(UNIQUE IDENTIFIER) UID: Any combination of
attributes and/or relationships that serves, in all cases, to
uniquely identify an occurrence of an entity.
VOLATILE: Tending to vary often or widely, highly
changeable.
RELATIONSHIP: A connection or association between objects.
CARDINALITY: A property of an end of a relationship between X and Y, that
describes how many of X is related to Y. Both ends of a relationship must have a
defined cardinality. Same as degree.
DEGREE: A property of an end of a relationship between X and Y, that describes
how many of X is related to Y. Both ends of a relationship must have a defined
degree. Same as cardinality.
OPTIONALITY: Not required; left to choice
Un model conceptual bun poate fi utilizat, indiferent de tipul bazei de
date (BD- ierarhice, relaţionale, de tip reţea.. (implementation free))
- reprezintă ceva semnificativ pentru afacere
- arata cum entităţile se referă unele la altele în mod reciproc
- există întotdeauna între două entităţi (sau intre o singură entitate de două ori -> relatie recursiva-
definita prin ea insasi)
- întotdeauna are două perspective
- are nume la ambele capete ( entităţile se scriu cu litere mari şi relaţiile cu litere mici, italic)
EMPLOYEEs hold JOBs, JOBs are holded by EMPLOYEEs
PRODUCTs are classified by a PRODUCT TYPE, PRODUCT TYPE classifies a PRODUCT
- sunt obligatorii (mandatory) sau opţionale
OBLIGATORIE/ OPŢIONALĂ
Determină gradul unei relaţii
- numele entităţii trebuie să fie unic în cadrul unei baze de date şi să descrie formal entitatea
- când se denumeşte entitatea, trebuie să fim atenţi la omonime (se scriu la fel dar înseamnă altceva
SARE)
- se vor evita cuvintele rezervate ( entity, attribute)
- atenţie să nu se transfere numele entităţii în numele relaţiei. De Ex. A guest may be a guest of
ENTITĂŢI
ATRIBUTE
are trei aspecte: NUME (lângă entitate)
OPŢIONALITATE (lângă entitate) MUST BE / MAY BE
GRAD (lângă entitatea opusă)/ How many?
RELATIE
PASII CARE TB. URMATI PENTRU TRASAREA UNEI ERD- ish
• Examinează substantivele
• Păstrează numai informaţiile care te interesează conform regulilor şi
nevoilor afacerii
• Stabileşte un nume semnificativ pentru fiecare entitate
• Fiecare E are un UID ? In ce fel atributul sau atributele pot servi UID
(care sunt cheile candidate pentru identificarea unica a fiecărei
instanţe?)
• Descrieţi fiecare E adăugând atributele necesare, trasând softbox-ul
pentru fiecare E
• Identificaţi relaţiile şi trasaţi diagrama.
TRY IT / SOLVE IT
TRY IT / SOLVE IT
TRY IT / SOLVE IT
TRY IT / SOLVE IT
TRY IT / SOLVE IT
CONVENTIE:
TRY IT / SOLVE IT
MODELAREA SUBTIPURILOR ŞI
SUPERTIPURILOR
RULES:
- Mutually Exclusive: orice
instanţă aparţine doar unui singur
subtip, adică un produs nu poate fi
simultan atât carte cât şi revistă.
ANALOGIE:
Se obţine de fapt o partiţie a
mulţimii instanţelor supertipului.
Atributele supertipului VEHICLE pot fi # număr de înmatriculare, * anul fabricaţiei. În plus, apar ca atribute adiţionale (auxiliare) modelul şi tipul motorului.
TRUCK are atributele proprii (dimensiunea patului, tipul transmisiei) ş.a.m.d.
BOAT are propriile subtipuri
OTHER de obicei este necesar, pentru a putea face o clasificare mai exactă deoarece pot exista şi alte tipuri de vehicule (biciclete, avioane) şi nu putem încălca una din reguli - exhaustivă, completă- fiecare instanţă a supertipului trebuie să fie instanţă a unui subtip (trebuie să fie încadrat undeva)
Să vedem dacă respectă regulile:
toate au UID comun (număr de înmatriculare)
fiecare are propriile atribute
există mai mult decât un subtip
sunt exhaustive(complete/ care epuizeaza un subiect) fiecare vehicul poate fi plasat în acest model
sunt reciproc exclusive o maşină nu e barcă, o barcă nu e camion. Fiecare vehicul se potriveşte într-un singur subtip.
şi incă ceva important: se observă că există subtip al unui subtip. Subtipurile se pot imbrica (cuibări-nested) pe oricâte nivele dar rar la o adâncime mai mare de 3, deoarece e greu de implementat la nivel fizic
Ex.1
WHEN:
- When a group of instances has
special properties, such as
attributes or relationships that
exist only for that group, or when
there is some functionality that
applies only to the group.
RULES:
- Exhaustive: sunt acoperite toate
cazurile posibile, adica in
exemplul nostru, orice publicatie
este o carte (BOOK), o revista
(MAGAZINE), brosura
promotionala (PROMO
BROCHURE), iar pt. a fi siguri ca
acoperim toate situatiile sau daca
ne gandim ca in viitor vom putea
avea si alte produse s-a inclus si
subtipul OTHER.
Ex.2
TRY IT / SOLVE IT
TRY IT / SOLVE IT
BUSSINESS RULES
Section 4
STRUCTURAL RULES: reguli structurale arată tipul informaţiei care a fost
prelucrată arată şi cum elementele informaţiei interrelaţionează
- câteodată le numim constrângeri
- reguli care se pot deduce de pe ERD
Exemplu: Toti profesorii din şcoală trebuie sa aibă o diplomă de licenţă.
(=>atributul licenţă este obligatoriu!)
Acestea sunt reguli care ne spun ce tip de informaţii sunt reţinute.
PROCEDURAL RULES: gestionează procesele afacerii şi fluxul afacerii
Reguli interne ale firmei care nu pot fi “prinse” in ERD. Pentru a asigura
respectarea acestor reguli se apeleaza la software. Aceste reguli trebuie sa
fie documentate.
Exemplu: Pentru a participa la cursul de Programare elevii trebuie sa fi
parcurs cursul de Algebra. (se va scrie un program care verifică în baza de
date dacă elevul a făcut acest curs)
unele reguli trebuie implementate prin programare
exemple
TRY IT / SOLVE IT
TRY IT / SOLVE IT (continuare slide anterior)
Structural Rules:
A patient is someone who is
admitted to the hospital.
Each room assignment must include
the building number and room
number.
Each room may be occupied by one
or more patients.
A physician must have a valid
license number.
Each drug must be prescribed by a
physician.
Each drug prescribed must have a
label showing label number, dosage,
treatment duration, and expiration
date.
The drug code, name, and cost must
be recorded for all drugs.
Each prescription must have a
number and date. Each physician
may be assigned to more than one
patient. Each patient must have an
assigned physician.
Procedural Rules:
Changes to prescriptions can
be made only by licensed
physicians.
Patients cannot refill
prescriptions without a
physician's signature.
Physicians cannot remove drug
labels.
Patients cannot change hospital
rooms without a physician's
recommendation.
Nurses cannot reassign patients
without physician approval.
Programming Rules:
Drugs costs are billed at
current cost at the time of
patient discharge.
Physician fees may reflect
additional costs associated
with patient complications,
additional patient requests,
etc.
TRY IT / SOLVE IT (continuare slide anterior)
TRANSFERABILITATEA UNEI RELAŢII
stabileşte dacă unei instanţe a primei entităţi poate să i se asocieze o
unică instanţă a celeilalte entităţi. Dacă da, spunem că relaţia este
nontransferabilă, altfel ea este transferabilă.
Ex. un CLIENT (CUSTOMER) este asociat cu o COMANDĂ
(ORDER). COMANDA trebuie întotdeauna asociată cu acel CLIENT.
Odată ce un client a făcut o comanda aceasta nu poate fi deasociată
de acesta.
-Ex. în relaţia dintre grupa sanguină şi persoană. Fiecare persoană trebuie să
aibă o singură grupă sanguină. Partea cu TREBUIE SĂ a relaţiei nu este
transferabilă. Persoanei nu i se poate schimba grupa sanguină.
-Ex. relaţia dintre persoană şi oraş. Fiecare persoană trebuie sa se fi născut
intr-un oraş. Şi în acest exemplu partea cu TREBUIE a relaţiei nu este
transferabilă. O persoană nu poate să-şi schimbe oraşul natal. Deseori
informaţiile istorice sunt modelate pe baza relaţiilor nontransferabile.
TRANSFERABILITY
Section 5
TRANSFERABILITY
Section 5
Nontransferabilitatea => valoarea campului AUTHOR_ID din tabela POEMS
nu se poate modifica.
Diamond-ul apare intotdeauna pe partea cu MANY iar optionalitate
MUST BE!!!
TRY IT / SOLVE IT
TRY IT / SOLVE IT
TRY IT / SOLVE IT
TIPUL RELAŢIILOR. GRAD. CARDINALITATE
Relaţie RARĂ mandatory la ambele capete
Each PERSON Must be the result of One and onlz one BIRDTH
Each BIRDTH Must results in One and only one PERSON
Relaţie COMUNĂ(UZUALĂ) opţională la ambele capete (folosită pentru modelarea
nivelelor într.un proces)
Each DRAFT (CIORNĂ) May become One and only one MESSAGE
Each MESSAGE may begin as One and only one DRAFT
Relaţie COMUNĂ(UZUALĂ) mandatory la un capăt şi opţională la celălalt capăt
(folosită pentru modelarea rolurilor)
Each PATIENT Must be identifiate by One and onlz one PERSONE
Each PERSON May become One and only one PATIENT
1:M cele mai des întâlnite
Relaţie RARĂ, mandatory la ambele capete
Each MOTHER Must give birdth to One or more CHILD
Each CHILD Must be birdth by One and only one MOTHER
Relaţie COMUNĂ(UZUALE), opţională la ambele capete
Each WAREHOUSE (DEPOZIT) May store One or more PRODUCT
Each PRODUCT may be strored in One and onlz one WAREHOUSE
Relaţie COMUNĂ(UZUALE), opţională la capătul cu ONE şi mandatory la capătul cu MANY
Each CUSTOMER may placed One or more ORDER
Each ORDER Must be placed by One and only one CUSTOMER
RELATIILE M:M nu se pot implementa, ele se vor transforma in relatii 1:MRelaţie RARĂ mandatory la ambele capete
Each POINT Must belong to One or more LINE
Each LINE Must contain one or more POINT
Relaţii COMUNE (UZUALE)
Opţională la ambele capete
Each CLUB may be joined by One ore more STUDENT
Each STUDENT may join One or more CLUB
Mandatory la un capăt, opţională la celălat capăt
Each MESSAGE Must be received by One or more USER
Each User may receive One or more MESSAGE
RELATII REDUNDANTE
TRY IT / SOLVE IT
TRY IT / SOLVE IT
REZOLVAREA RELAŢIILOR
M:M
Ex. Each STUDENT May be enroled in One or more COURSEs
Each COURSE May be taken by One or more STUDENTs
De ce rezolvăm relaţiile M:M (Why?)
Nu se pot implementa
pot ascunde un atribut
creând a treia entitate, numită entitate intersecţie, se crează loc pentru acest atribut
Cum rezolvăm relaţiile M:M ( How?)
creăm entitatea de intersecţie
creăm relaţii noi
denumim noile relaţii
adăugăm atribute entităţii de intersecţie
creăm UID pentru entitatea de intersecţie
Atribute: Entitate de intersectie
- data inscrierii
- data completarii
- grad
Noile relaţii îşi păstreză opţionalitatea la capetele entităţilor
iniţiale. În ceea ce priveşte cardinalitate, aceste noi relaţii
sunt amândouă de tipul M:1. Dacă s-a dezvoltat o nouă
relaţie de M:M, acesta trebuie din nou rezolvată
SOLVING MANY-TO-MANY
Section 5
1. Se pastreaza opţionalitatea
relaţiilor originale
Ex: Each ORDER MUST contain
one or more products
Each ORDER MUST contain
one or more order items.
Each PRODUCT MAY appear on
one or more ORDERS.
Each PRODUCT MAY appear
on one or more ORDER ITEMS.
SOLVING MANY-TO-MANY
Section 5
2. De obicei relaţiile dinspre
entitatea de intersecţie sunt
barate, asta insemnând că un
ORDER ITEM este unic identificat
prin id-ul ORDER-ului împreună
cu ID-ul PRODUCT-ului.
Se poate însă decide includerea
unei chei artificiale care să
identifice unic fiecare order item şi
atunci dispar barele…
Aceasta variantă este de preferat
dacă UID-urile entităţilor originale
sunt compuse.
TRY IT / SOLVE IT
TRY IT / SOLVE IT
SECTIUNE 6. LECTIE 1.UIDs artificial, composit Şi secundar
TRY IT / SOLVE IT
TRY IT / SOLVE IT
TRY IT / SOLVE IT
SECTIUNE6/ LECTIE 2
NORMALIZAREA- PRIMA FORMĂ DE NORMALIZARE (1NF)
Ce este normalizarea ?
Tehnică formală de analiză şi optimizare a relaţiilor ce are la bază cheile primare (sau candidate) şi dependenţele funcţionale
O serie de condiţii (forme normale), fiecare fiind din ce în ce mai restrictivă
Formele normale FN1, FN2, FN3 se raportează la dependenţele funcţionale
Formele normale superioare (FN4, FN5) se definesc în raport de alte tipuri de dependenţe(multivaloare, respectiv joncţiune)
- scopul normalizării este să ne asigurăm că datele sunt reţinute într-un singur loc în baza de date, să se asigure integritatea datelor, să se identifice tabelele lipsă, coloanele şi constrângerile din modelul original
De ce normalizam?
Pentru a evita redundanţa (duplicarea valorilor)
Pentru a înlătura anomaliile de actualizare (erori sau inconsistenţe ale structurii bazei de date)
Inserare – nu se poate insera un tuplu pentru că nu dispunem de toate informaţiile necesare;
Ştergere – atunci când se şterge un tuplu se şterge mai multă informaţie decât s-a intenţionat;
Modificare – când dorim să modificăm o valoare şi aceasta apare în sute de rânduri.
Toate valorile asociate atributelor se găsesc la nivel elementar
- din punct de vedere al utilizarii;
- din punct de vedere al obţinerii;
- din punct de vedere al tipurilor de date existente;
Nu exista atribute sau grupuri de atribute repetitive
1 NF - Spune că toate atributele trebuie să aibă o singură valoare. Validăm aceasta prin aceea
că fiecare atribut are o singură valoare pentru fiecare instanţă a entităţii. Asta înseamnă că nici
un atribut nu trebuie să aibă valori care se repetă (se schimbă)
Ex. COURSE cu atributele (#) id, (*) title, (*) instructor, (*) location, (*) student.
Un curs are mai mult decăt un student care participă la acesta, deci acest atribut încalcă prima
formă de normalizare. Ca să rezolvăm asta, STUDENT ar trebui să fie o alta entitate separată,
care să fie în relaţie cu entitatea COURSE. Dacă un curs este ţinut de mai mulţi instructori,
atunci de asemenea este încălcată această 1NF. De asemenea, dacă cursul este ţinut în mai
mult decât o locaţie (sală de curs, amfiteatru, laborator) atunci şi locaţie ar trebui să fie entitate
separată.
Desigur, toate acestea depind şi de regulile afacerii
START
ANLIZA DATELOR
DATELE SE AFLA LA
NIVEL ELEMENTAR
FN1
DF
P
ELIMINA DFP
FN2
DA
DFT
ELIMINA DFT
FN3
DA
STOP
DFP – dependenţă funcţională parţială
DFT – dependenţă funcţională tranzitivă
DESCOMPUNE.
ELIMINA ATRIBUT
NU
First Normal Form
Single-valued attributes
Validate that each attribute has a single value for each occurrence of the entity. No attribute should have repeating values.
CLIENT#* identifier
* date contacted Does the entity CLIENT comply with 1NF?
The attribute date contacted has multiple values, therefore the entity CLIENT is not in 1NF.
First Normal Form Rule: All attributes must be singled-valued.
First Normal Form (cont)
If an attribute has multiple values, create an additional entity and relate it to the original entity with a M:1 relationship.
CLIENT
#* identifier
CONTACT#* date contacted
o location
o result
for
the
subject
of
TRY IT / SOLVE IT
Second Normal Form
Dependency on entire UID
Validate that each attribute is dependent on its entity’s entireunique identifier. Each specific instance of the UID must determine a single instance of each attribute.
Validate that an attribute is not dependent upon only part of its entity’s UID.
COURSE#* code
* name
* duration
* fee
Validate placement of the COURSE entity’s
attributes
In this example, each instance of a course code determines
a specific value for name, duration, and fee ( taxa/plata).
The attributes are properly placed.
Second Normal Form Rule: An attribute must be dependent upon
its entity’s entire unique identifier.
SECTIUNE 6/ LECTIE 3 2NF
Examinăm entitatea PRODUS FURNIZAT. Identificatorul unic este o
combinaţie dintre numărul furnizorului si numărul produsului. Ce ştim
despre atributul nume furnizor? Dacă un furnizor aprovizioneză 5
produse diferite ce se întimplă dacă se schimbă numele furnizorului?
Ar trebui făcute actualizări in 5 locuri. Dacă în unele actualizăm şi în
altele nu? Care va fi valoarea corectă pentru numele furnizorului?
purchase=achizitie
-A două formă de normalizare necesita ca toate atributele entitatii
care nu sunt UID trebuie să fie dependent de întregul identificator
unic.
- Aceasta se aplică, de obicei, la entităţile care au UID composite
sau UID care derivă din relaţie barată.
- nu se admit dependente functionale partiale
- Acelaşi număr de cont poate
exista la bănci diferite, asta
înseamnă că numărul contului
este legat de bancă => relaţie
barată
TRY IT / SOLVE IT
TRY IT / SOLVE IT
TRY IT / SOLVE IT
-Regula pentru 3NF- niciun atribut non UID nu poate să fie dependent de un alt atribut non UID
- 3NF interzice dependenţele tranzitive. O dependenţă tranzitivă există când orice atribut (non
UID) dintr-o entitate depinde de un alt atribut (non UID) din aceeaşi entitate (sunt cel putin 2)
-Ex: Gandeste-te ce informaţie ai dori sa păstrezi pentru colectia ta de CD. Informatia legata de
magazinul de unde ai cumparat CD apartine aceleiasi entitati? Dacă adresa magazinului se
schimbă tu ar trebui să schimbi informaţiile de pe CD-urile care au fost cumparate din acel
magazin?
EMPLOYEE care are ca atribut non UID partner
name şi partner birdth date. Acest exemplu
încalcă a treia formă de normalizare deoarece, deşi
partner name poate fi un atribut al entităţii – lucru
ce rezultă din următoarea regulă a afacerii: fiecare
angajat poate avea un singur partener- data de
naştere a partenerului ar trebui să fie atribut pentru
entitatea PARTNER care ar fi trebuit creată.
TRY IT / SOLVE IT
TRY IT / SOLVE IT
Normalize the Data Model
First Normal Form (1NF)
All Attributes must be single-valued
Second Normal Form (2NF)
An attribute must be dependent upon its entity’s entire unique identifier
Third Normal Form (3NF)
No non-UID attribute can be dependent on another non-UID attribute
A normalized entity-relationship data model automatically translates into
a normalized relational database design!
Normalization is a relational database concept, but its principles
apply to Conceptual Data Modelling.
Observaţie: cele trei forme de normalizare sunt progresive: asta înseamnă că nu poţiavea o bază de date care să fie în a doua formă de normalizare dacă nu e deja înprima formă de normalizare şi de asemenea, nu poate fi în a treia formă denormalizare dacă ni e în prima formă de normalizare şi în a doua formă denormalizare.
Există şi 4NF şi 5NF dar nu vom studia aceasta in cadrul acestui curs.
ETAPELE PENTRU REALIZAREA UNEI ERD:
analiza documentului (scenariului dat)
asociem atributele entităţilor
desenăm entităţile
definim relaţiile dintre entităţi
INFORMAŢII NOI DESPRE UID:
fiecare instanţă trebuie să fie identificată de o valoare unică
folosim simbolul # pentru atributul cu rol de identificator unic
UID trebuie să fie unic şi NOT NULL
În practică, de obicei, unui UID îi este asociat un număr
Unii UID sunt compuşi din mai multe atribute, altele din atribute şi relaţii barate şiunele doar din relaţii barate
CONSTRANGERI ( RESTRICTII)
Unique Identifiers
Arcs
Domains
Various other constraints
SECTIUNE 7/ LECTIE 1/ ARCS
-Orice afacere are restricţii pe fiecare valoare a atributelor şi pe fiecare relaţie
permisă.
-Aceste restrictii sunt cunoscute sub denumirea de CONSTRÂNGERI. Ne putem
referi la un singur atribut al unei entitati sau la relaţiile între entităţi
-Deja stim despre mai multe tipuri de constrângeri, de exemplu: fiecare angajat
trebuie sa lucreze în unul si numai intr-un departament
-un alt tip de constrangere- XOR sau exclusiv
Unique Identifier Examples
JOB
COMPUTER IN NETWORK
TELEPHONE
EMPLOYEE
MAIL LIST
Name
IP Address
Country code,
Area code,
Telephone number
Employee number
Name,
Initials,
Birth Date
Name,
Owner
Unique Identifier
CUSTOMER
# Family Name
o Initials
# Address
o Telephone
Indicates Unique Identifier
ORDER
# Dateresponsible
for
by
Indicates Unique Identifier
Unique Identifiers
part of
contains
USER
# Name
owner of
owned by
MAIL LIST
# Name
ROOM
# No
FLOOR
# No
HOTEL
# Name
Identificăm în mod unic fiecare item din
PLAY LIST ITEM spunând la ce
eveniment a fost cântat. Pentru aceasta
punem o bară pe relaţii care înseamnă că
UID pentru PLAY LIST ITEM este
#id_event + #id_song.
Barele sunt plasate pe linia continuă
pentru că ambele relaţii sunt mandatory
la capătul cu many.
Nu vom găsi niciodată bara pusă pe
linia întreruptă
ARCE un arc este folosit pentru a modela două sau mai multe relaţii ale
aceleiaşi entităţi, care se exclud reciproc
arcele sunt desenate între acele două entităţi conectate între ele şidemonstrează reciproc exclusivitatea
arcele arată că fiecare instanţă a unei entităţi poate avea o singură relaţievalidă dintre relaţiile din arc, la un moment dat
arcele pot fi desenate între două sau mai multe entităţi
arcul este cunoscut şi sub denumirea de arc excusiv. În programarenumim asta XOR (sau exclusiv)
arcele sunt similare supertipurilor şi subtipurilor şi sunt modelate de multeori la fel
diferenţa este că folosim supertipuri / subtipuri când dorim săreprezentăm clasificări sau tipuri ale unor obiecte care au uneleproprietăţi comune şi cand nu au proprietati comune se recomandafolosirea arcelor
-O casă de productie este un spaţiu de publicitate
care poate produce un film, un reportaj sau un
anunt public (publicitate). Poate conţine publicitate
despre una dintre aceste teme. Fiecare punct din
program are caracteristici si atribute proprii.
Reguli:
un arc aparţine întotdeauna unei entităţi
arcele pot include mai mult decât două relaţii
nu toate relaţiile unei entităţi trebuie să fie incluse intr-un arc
o entitate poate avea mai multe arce
un arc trebuie să conţină relaţii de acceaşi opţionalitate (toate relaţiile din arce
trebuie să fie ori mandatory ori optional)
relaţiile într-un arc pot să aibă grade diferite, deşi asta se întâmplă mai rar
Possible Arc Constructs
Some Incorrect Arc Constructs
• Relationships in the arc must be of the same optionality
• Arcs must contain at least two relationships
This arc may be correct, but is quite difficult to implement ...
• The arc “belongs” to one entity
USER
LIST
owned by
ownerof
LIST ITEM
contains
in
Arc or Subtype
USER
LIST
owned by
ownerof
LIST ITEM
contains
in
ADDRESS
referring to
is referred to
referring to
is referred to
referring to
is referred to
Arc and Subtypes
A
QP
2
A
QP
R
1
A
P
CB
Q
3
A CB
QP
R
4 5
A CB
QP
R
Subtypes Hide Relationships in
Arc
Every A
is either a B or a C
Every B is an A
Every C is an A
A
C
B
C
BA
is
is
is
is
• Every A mustbe a B or be a C
• Every B must be an A
• Every C must be an A
TRY IT / SOLVE IT
TRY IT / SOLVE IT
TRY IT / SOLVE IT
SECTIUNE 7/Lectie 2/ relatii ierarhice si recursive
-Deseori rolurile sunt organizate prin
intermediul ierarhiei
-Datele ierarhice sunt foarte
cunoscute
Ex: - organigrama unei intreprinderi
- structura unei cladiri
- arborele genealogic
Ambele modele reprezintă toţi
angajatii unei intreprinderi
- In partea stânga este o structură
ierarhica, în partea dreaptă este o
relatie recursivă
Care credeţi că este mai bună?
Relaţiile ierarhice:
nivele de organizare
reprezintă un lanţ de relaţii de tipul 1:M
Exemplul cu ROOM—SUITE—FLOOR –BUILDING sau
MUNCITOR—MANAGER—DIRECTOR—PREŞEDINTE
Relaţiile recursive:
trebuie să fie opţionale la ambele capete (de exemplu dacă preşedintele companiei trebuie să aibă un manager asta nu are sens, sau, de asemenea, nu orice angajat trebuie să fie managerul cuiva.
Exemplul - EMPLOYEE care poate fi şi manager sau manager care poate fi employee
Exemplul cu COMPONENT care este relaţie recursivă M:M
O componentă a motorului poate avea mai multe instanţe: părţi elementare (şaibe, piuliţe,
şuruburi), subansamble care sunt formate din părţi elementare, ansamble care sunt formate
din subansamble, şi produse finite.
Poate că o componentă este un şurub, dar şase şuruburi formează un ansamblu, deci putem
defini recursiv relaţia Fiecare componentă poate sa aparţina uneia sau mai multor
componente, şi Fiecare componentă este făcută din una sau mai multe componente.
TRY IT / SOLVE IT
TRY IT / SOLVE IT (continuare slide anterior)
TRY IT / SOLVE IT
ISTORICUL DATELOR
O organizatie are nevoie sa pastreze
date despre salariile angajatilor
Suplimentar, organizatia ar dori sa
pastreze informatii despre modificarea
salariilor pe parcursul angajarii
Modelarea initiala
Un magazin care inchiriaza bijuterii,
starurilor de cinema pentru ocazii
diferite cum ar fi ceremonii de
decernare a premiilor (OSCAR) sau
premiere .Acesta ar dori sa păstreze
informaţii privind istoricul inchirierilor.
Care este cardinalitatea ?
Este corectă?
Poate funcţiona fără UID? Nu.
Se justifică să cream unul artificial? Care
să se refere la ce, sau la cine?
Daca îl creăm, poate furniza vreo
informatie singur? Nu, atunci nu putem
decat sa formam un UID composit din cel
artificial+relatia care ne interesează,
pentru care dorim istoricul (Jewelry Piece),
atunci=> relatie barata numai la un capat
TRY IT / SOLVE IT
TRY IT / SOLVE IT (continuare slide anterior)
Hint that the relationship between TAPE and
CUSTOMER has now changed (to a M:M,
which then needs to be resolved).
TRY IT / SOLVE IT
SECTIUNE 10/ MODELAREA ARHIVELOR
Când ai instanţe care se pot modifica în timp se pune problema cum să păstrezi
nişte date într-o arhivă de date (chiria, taxele, numele unei ţări, preţul unui produs)
- fiecare modificare presupune pierderea informaţiei anterioare
- pentru a modela aceste situaţii se folosesc entităţi specifice, cum ar fi entitatea
TIMP ( DAY) sau PREŢ(PRICE)
Ex.: O carte poate fi
imprumutată de la bibliotecă
de mai multe ori, de diferite
persoane, sau de către
aceeaşi persoană. Modelul
poate avea nevoie să
pastreze istoricul
imprumuturilor pentru o carte.
Gândeşte-te la o companie
de furnizare de flori sau un
departament de politie. Ce rol
va juca timpul ?
- Istoricul datelor este deseori utilizat pentru a cauta
evolutia acestora (fiind un mod eficient de a face
afaceri)
-Modelarea timpului in afaceri este de asemenea
utilizat pentru capturarea informatiilor
-Raporturile furnizează informaţii care pot deriva din
alte date. Un raport bun poate furniza informatii
valabile care pot imbunătăţi afacerea în sine.
Entitatea “Achizitii (Cumparari)”.
Vei putea include un atribut
“date” daca vrei sa stii cand ai
cumparat un item (produs). Desi,
daca vrei să identifici evoluţia,
cum ar fi: când cumpără oamenii
un costum, la ce temperatură
poate să-l spele, care sunt
limitele astfel încât să nu se
deprecieze.
