Date. Informaii.

Cunotine

Date- material brut: simboluri, numere,cuvinte, poze,fara un

inteles, fara relatii cu alte date. Se obin in urma unor
experiente , sondaje

Informatii: se obtin prin prelucrarea datelor si gasirea relatiilor dintre

acestea. Datele prin prelucrare devin informatii. Se prezint sub
forma de statistici, diagrame, rapoarte.
Cunotine sunt colecii de date i informaii acumulate de-a lungul
timpului. Ele pot fi folosite n luarea de decizii.
baz de date este:
-un set de date centralizat i structurat stocat pe un
computer
-permite prelucrarea datelor: gsire, adugare,
tergere,modificare
-permite transformarea datelor n informaii
-este coordonat deun administrator ( DBA )
Modelul conceptual
reprezint primul pas n realizarea unei BD
Cuprinde
- analiza datelor i realizarea unei scheme conceptuale a
acestora
-se analizeaz natura i modul de utilizare a datelor.
- se identific datele care vor trebui procesate i memorate
-se mpart datele n grupuri logice
-se identific relaiile care exist ntre grupuri.
Informaiile se reprezint intr-o form convenional.
Reprezentarea este diagrama entiti -relaii numit i
harta relaiilor sau ERD (entity relationship diagram )
 Etapele procesului de dezvoltare al bazelor de date :

Strategie capturarea informatiilor necesare, conform regulilor afacerii, etapa

din care va rezulta modelul conceptual
Analiza - maparea relatiilor dintre entitati. Modelul conceptual E, A, R i
identificatorii unici vor fi transformai n obiecte ale bazei de date
relaionale
Design - modelul conceptual va fi transformat ntr-un design relaional al
viitoarei baze de date
Build construcia BD cu ajutorului SGBD SQL, folosind DDL, DML, DCL
(limbajele de definire, manipulare, control si administrare a BD), astfel
inct BD sa devin operaional.( se transform n modelul fizic)
MODELUL CONCEPTUAL
- modeleaz nevoile funcionale i informaionale ale afacerii
- se bazeaz pe nevoile curente dar poate reflecta nevoile viitoare
- este numit i Modelul Entitate Relaii (Entity Relationship Model)
Scopul Modelarii Relatiilor dintre Enitati:
- s captureze toate informaiile necesare
- orice informaie s apar o singur dat
- s modeleze numai informaiile care nu sunt derivabile din alte informaii
deja modelate
- s plaseze informaiile n locurile logice, fiecare la locul ei
 Entiti , instane, atribute i identificatori

ENTITATE este obiectul pentru care se stocheaz date.

ENTITATE definete o clas de obiecte
- este ceva semnificativ (important) pentru afacere, despre care
trebuie cunoscute date
- este un nume pentru lucruri pe care le poi lista
- entitile sunt substantive la singular
Entitatile pot fi :
- tangibile : (ex. PERSON OR PRODUCT)
- non-tangibile : (ex. SKILL LEVEL - nivelul de performan)
- un eveniment : (ex. CONCERT)
Entitile au instane(ex. entitatea FRUIT are instanele : portocale, mere,
lmi i atribute (nume, culoare, pre)
Instana este un obiect din clasa de obiecte a entiti.
atributele sunt informaii despre instan
 ATRIBUTE

- este de asemenea ceva semnificativ pentru afacere

- este o proprietate a entitii cu o singur valoare
- este o informaie 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)

Atributele pot fi: volatile au valori care se schimba constant: vrsta

nonvolatile care nu se schimba
Se prefera cele nonvolatile. Ex. se alege data naterii nu vrsta
Identificatori unici UID

Identificatori unici UID atributele care definesc n mod unic instana

Atributul poate fi obligatoriu sau opional

Atribut obligatoriu are pentru fiecare instan o valoare (ex. numele
trebuie cunoscut).
Atribut opional se poate ca la anumite instane s lipseasc valoarea
acelui atribut (ex adresa e-mail pote lipsi)
UID: artificial - acela care nu-i trece prin minte n mod
natural, dar va fi creat n scopul de a identifica o anumit
instan din sistem
simplu - format dintr-un singur atribut
compus o combinaie de atribute; sau o combinaie dintre un
atribut + relaie
 Relaii ntre entiti

Relaia este o legtur, o conexiune ntre entiti i are o

semnificaie pentru afacerea modelat.
Orice relaie este bidirecional, leag dou entiti sau o
entitate cu ea nsi.
Relaia este caracterizat de elementele:
Numele releiei
Opionalitatea relaiei: obligatorii sau opionale
Gradul(cardinalitatea) relaiei este o proprietate a fiecrui
capt de relatie dintre X i Y , care stabilete ci de X sunt
n relaie cu ci de Y.
Un model conceptual bun poate fi utilizat,indiferent de tipul bazei de
date (BD- ierarhice, relaionale, de tip reea... (implementation free))
cele patru scopuri ale modelrii ERD

S cuprind toate informaiile cerute

Informaia s apar o singur dat
S nu modeleze informaii care se pot deduce din cele deja
modelate
Sa cuprind informaia n locul ateptat
 Relaia

- reprezint ceva semnificativ pentru afacere

- arat cum se refer entitile unele la altele n mod reciproc
- exist ntotdeauna ntre dou entiti (sau intre o singur entitate de dou ori - relaie
recursiva- definit prin ea nsi)
ntotdeauna are dou perspective- are nume la ambele capete ( entitile se scriu cu
litere mari i relaiile cu litere mici, italic)
Ex. EMPLOYEEs hold JOBs, JOBs are holded by EMPLOYEEs
PRODUCTs are classified by a PRODUCT TYPE, PRODUCT TYPE classifies a
PRODUCT
- sunt obligatorii (mandatory) sau opionale
Convenii de desenare entiti

Entitatea se reprezint prin softbox (are colurile rotunjite)

Nume entitii se scrie n softbox i este totdeauna la singular,scris cu
majuscule
numele entitii trebuie s fie unic n cadrul unei baze de date i s descrie
formal entitatea
- cnd se denumete entitatea, trebuie s fim ateni la omonime (se scriu la
fel dar nseamn altceva)
- se vor evita cuvintele rezervate ( entity, attribute)
- atenie s nu se transfere numele entitii n numele relaiei. De Ex. A guest
may be a guest of
 ATRIBUTE

Se scriu sub numele entitii:

Obligatorii se marcheaz cu *
Opional se marcheaz cu 0
Identificator unic se marcheaz cu #
 RELAIE

Linii care conecteaz entiti

Linii continui sau punctate
Linii terminate cu un singur deget
sau trei (picior de cioar)

are trei aspecte:

- NUME (un verb, lng entitate )
-OPIONALITATE (lng entitate) MUST BE / MAY BE( trebuie ___ / poate - - - - - )
-GRAD (cardinalitate) (lng entitatea opus)/ How many?(una i numai una _____ linie
simpl, una sau mai multe (picior de cioar)
 PAII CARE TREBUIE URMAI PENTRU TRASAREA UNEI ERD

Examineaz substantivele
Pstreaz numai informaiile care te intereseaz conform regulilor i
nevoilor afacerii
Stabilete 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 fiecrei
instane?)
Descriei fiecare E adugnd atributele necesare, trasnd softbox-ul
pentru fiecare E
Identificai relaiile i trasai diagrama.
MODELAREA SUBTIPURILOR I SUPERTIPURILOR
Uneori o entitate trebuie imparit n subtipuri. Aceasta este necesar
atunci cnd un grup de instane are proprieti speciale:anumite atribute i
relaii. Entitatea se numete supertip iar fiecare grup subtip.

Un subtip:
-motenete toate atributele supertipului
-motenete toate relaiile supertipului
-pot avea atribute i relaii proprii
-se deseneaz in interiorul supertipului
- Nu exista niciodat singur
-poate avea propriile subtipuri-este numit i subentitate
ANIMAL SUPERTYPE
EX:
EXAM is a supertype of QUIZ,
MIDTERM, and FINAL.

Subtipurile au atribute
comune care se listeaz la
nivel de supertip.

Subtipurile motenesc toate

atributele i relaiile entitaii
supertip

EXAM SUPERTYPE
Un supertip are cel puin doua subtipuri.
Fiecare instan a supertpului este o instan a unui subtip.
Fiecare instan a supertipului aparine doar unui subtip.

n modelul conceptual este bine

s se includ subtipul OTHER pt
a putea include toate instanele
supertipului
RULES:
Mutually Exclusive: orice
instan aparine doar unui singur
subtip, adic un produs nu poate fi
simultan att carte ct i revist.

ANALOGIE:
Se obine de fapt o partiie a
mulimii instanelor supertipului.
 Ex.1

Atributele supertipului VEHICLE pot fi # numr de nmatriculare, * anul fabricaiei. n plus, apar ca atribute adiionale
(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 nclca 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 (numr de nmatriculare)
fiecare are propriile atribute
exist mai mult dect un subtip
sunt exhaustive(complete/ care epuizeaza un subiect) fiecare vehicul poate fi plasat n acest model
sunt reciproc exclusive o main nu e barc, o barc nu e camion. Fiecare vehicul se potrivete ntr-un singur subtip.
i inc ceva important: se observ c exist subtip al unui subtip. Subtipurile se pot imbrica (cuibri- nested) pe oricte
nivele dar rar la o adncime mai mare de 3, deoarece e greu de implementat la nivel fizic
 REGULILE AFACERILOR
Dou tipuri de reguli: structurale i procedurale

STRUCTURAL RULES: reguli structurale arat tipul informaiei care a fost

prelucrat arat i cum elementele informaiei interrelaioneaz
- cteodat le numim constrngeri
- 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 informaii sunt reinute.
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 fcut acest curs)
 Identificarea relaiilor:
5 pai pt stabilirea relaiilor:
Exist o relaientre entiti
Alegi un nume pt relaie
Detrmini opionalitatea
Determinarea cardinalitii
Detrminarea transferabilitii

TRANSFERABILITATEA UNEI RELAII

stabilete dac unei instane a primei entiti poate s i se
asocieze o unic instan a celeilalte entiti. Dac da,
spunem c relaia 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 fcut o comanda aceasta nu
poate fi deasociat de acesta.
A Nontransferable relationship is represented with the
diamond on the relationship.
-Ex. n relaia dintre grupa sanguin i persoan. Fiecare persoan trebuie s
aib o singur grup sanguin. Partea cu TREBUIE S a relaiei nu este
transferabil. Persoanei nu i se poate schimba grupa sanguin.
-Ex. relaia dintre persoan i ora. Fiecare persoan trebuie sa se fi nscut
intr-un ora. i n acest exemplu partea cu TREBUIE a relaiei nu este
transferabil. O persoan nu poate s-i schimbe oraul natal. Deseori
informaiile istorice sunt modelate pe baza relaiilor nontransferabile.
Nontransferabilitatea => valoarea campului AUTHOR_ID din tabela POEMS
nu se poate modifica.
Diamond-ul apare intotdeauna pe partea cu MANY iar optionalitate
MUST BE!!!
 TIPUL RELAIILOR. GRAD. CARDINALITATE

Relaie RAR mandatory la ambele capete

Each PERSON Must be the result of One and only one BIRDTH
Each BIRDTH Must results in One and only one PERSON
Relaie COMUN(UZUAL) opional 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
Relaie COMUN(UZUAL) mandatory la un capt i opional la
cellalt capt (folosit pentru modelarea rolurilor)
Each PATIENT Must be identifiate by One and only one PERSONE
Each PERSON May become One and only one PATIENT
 1:M cele mai des ntlnite
Relaie 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
Relaie COMUN(UZUALE), opional la ambele capete
Each WAREHOUSE (DEPOZIT) May store One or more PRODUCT
Each PRODUCT may be strored in One and onlz one WAREHOUSE
Relaie COMUN(UZUALE), opional la captul cu ONE i mandatory la captul 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:M
Relaie RAR mandatory la ambele capete
Each POINT Must belong to One or more LINE
Each LINE Must contain one or more POINT
Relaii COMUNE (UZUALE)
-Opional la ambele capete
Each CLUB may be joined by One ore more STUDENT
Each STUDENT may join One or more CLUB
-Mandatory la un capt, opional la cellat capt
Each MESSAGE Must be received by One or more USER
Each User may receive One or more MESSAGE
RELATII REDUNDANTE
Relaia care
poate fi
determinat din
relaiile existente
n ex din stnga
relaia PERSOAN
_AR se poate
determina din
alte doua relaii
care trebulie
terse din model.
TRY IT / SOLVE IT
TRY IT / SOLVE IT
 S5 L3 REZOLVAREA RELAIILOR M:M

Relaiile many- to-many pot aprea n prima faz a proiectrii bazei de date dar
nu pot aprea n schema final.
Fie relaia student curs: dac dorim s introducem atributul nota in entitatea
STUDENT nu se tie la ce materie este acea not, pentru c unei instane a
entitii STUDENT i corespund mai multe instane ale entitii CURS. Invers
dac ncercm s memorm nota n entitatea CURS, nu vom tii la ce student
aparine nota.

CURS
STUDENT # id
# id urmeaz * denumire
* nume * durata
urmat de
*prenume *nr_credite
* adresa

Ex. Each STUDENT May be enroled in One or more COURSEs

Each COURSE May be taken by One or more STUDENTs
 Se introduce o entitate de intersecie pe care o legm cu
entitile actuale prin relaii one to one
STUDENT CURS
# id are # id
* nume * denumire
urmat de
*prenume * durata

pentru

pentr
* adresa *nr_credite

u
INSCRIERE
# data_inscrierii

data_finalizarii
nota
Crearea noilor relaii:
Opionalitatea relaiile care pleac din entitatea de intersecie sunt ntodeauna obligatorii n
aceast parte. n partea dinspre entitile originale, relaiile vor pstra opionalitatea relaiilor
iniiale.
cardinalitatea ambelor relaii sunt de tip one to many, iar partea cu many va fi ntodeauna spre
entitatea de intersecie
Numele noilor relaii

Adugarea de atribute la entitatea de intersecie

Stabilirea identificatorului unic pentru entitatea de intersecie( faptul c identificatorul unic al

unei entiti preia identificatorul unic din alt entitate cu care este legat se repreyint prin
bararea relaiei nspre entitatea care preia UID-ul celeilalt entiti
 De ce rezolvm relaiile M:M (Why?)
Nu se pot implementa
pot ascunde un atribut
crend a treia entitate, numit entitate intersecie, se creaz
loc pentru acest atribut
Cum rezolvm relaiile M:M ( How?)
crem entitatea de intersecie
crem relaii noi
denumim noile relaii
adugm atribute entitii de intersecie
crem UID pentru entitatea de intersecie
 Atribute: Entitate de intersectie
- data inscrierii
- data completarii
- grad

Noile relaii i pstrez opionalitatea la capetele entitilor

iniiale. n ceea ce privete cardinalitate, aceste noi relaii
sunt amndou de tipul M:1. Dac s-a dezvoltat o nou
relaie de M:M, acesta trebuie din nou rezolvat
 Relaie care ascunde un atribut

. -Fiecare PARTNER poate lucra la

unul sau mai multe EVENT
-Fiecare EVENTpoate fi un job
pentru unul sau mai muli
PARTNER
-Cnd un an EVENT PLANNER, un
DJ, sau PROJECT MANAGER
lucreaz la un EVENT dorim s
nregistrm tipul jobului.
Care entitate are acest
atribut?

Which entity would the attribute

"status" belong to?
 Rezolvarea relaiilor M:M

se introduce o
entitate de interseie
JOB ASSIGNMENT cu
atributul status
Relaiile M:M au
devenit
doua 1:M
Cine este UID pentru
entitate de interseie ?
Barred Relationships

. UID pt entitatea de
intersecie provine din
relaiile iniiale i se
reprezint prin bare.
Relaiile se numesc
barate
SOLVING MANY-TO-MANY

1. Se pastreaza opionalitatea
relaiilor 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

2. De obicei relaiile dinspre

entitatea de intersecie sunt
barate, asta insemnnd c un
ORDER ITEM este unic identificat
prin id-ul ORDER-ului mpreun
cu ID-ul PRODUCT-ului.
(nu are ID propriu)

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 entitilor originale
sunt compuse.
TRY IT / SOLVE IT
TRY IT / SOLVE IT
 S5 L4

Pt a valida un ERD se face o analiz CRUD:

prescurtare de la create, retrieve, update, delete.
Sunt patru operaii permise pt DB i trebuie verificat
dc toate se pot efectua i sunt specificate de regulile
afacerii.
OPERAIA CREATE cuvintele cheie sunt INPUT, ENTER,
LOAD,IMPORT, RECORD,CREATE
Trebuie ca model DB sa permit toate aceste operaii

OPERAIA retrive cuvintele cheie: VIEW,

REPORT,BRING UP, PRINT, FIND,READ,
LOOK UP.
Toate comenzile sunt pt. a gsi
informaiile din DB
UPDATE cuvinte cheie: CHANGE, MODIFY, ALTER,
UPDAT pt. a modifica informaii care sunt deja in DB.

DELETE cuvinte cheie: DISCARD, REMOVE,

TRASH, PURGE, DELETE. pt. a terge
informaii care sunt deja in DB.