MODEL FIZIC SI MODEL CONCEPTUAL

Modelarea datelor este doar prima parte a procesului de construire al bazei de date.
Modelul conceptual: Modeleaz nevoile informaionale ale afacerii; Se numete Entity Relationship Model; Este prezentat printr-o diagram numit Entity Relationship Diagram.

Etape in procesul de dezvoltare a bazelor de date

formularea cerinelor informaionale ale afacerii; desenare model conceptual; proiectare baza de date pornind de la modelul conceptual (entitaile devin tabele, atributele devin nume de coloane care corespund unor tipuri de date, se stabilesc proprietile speciale ale unor coloane); constructie baza de date (modelul fizic) prin executarea unor instructiuni SQL.
EXEMPLU

PRINCIPII DE BAZA ALE MODELARII

S cuprind toate datele necesare. Datele sa fie pstrate o singur dat. S nu cuprind informaii ce se obin din date deja cuprinse in model. Orice dat s fie aezat n locul cel mai logic i mai potrivit.

ENTITATI SI INSTANTE
Entitate = ceva semnificativ pentru afacere, referitor la
care trebuie s cunoatem date.

Este un substantiv singular. Entitile au instane. Entitile au atribute.

O instan este o valoare dat entitii. Exemplu: Entitatea FRUCT are instane: cireasa, nuca, pepene, mr, portocal.

Atributul
proprietate a unei entiti sau un detaliu referitor la acesta. Descrie, cuantific, calific, clasific sau specific o entitate. Are un tip care poate fi un numr, un ir de caractere, o dat calendaristic, o imagine, etc. Exemplu: Entitatea FRUCT poate avea atributele: nume, tip, regiune, data_culesului. In acest caz o instanta poate fi: portocal, citrice, Grecia, 10-July-2007.

Atribute mandatorii sau optionale

Unele atribute trebuie neaprat s aib valoare. Acestea se numesc MANDATORII. Exemplu: In afaceri, numele este o informaie absolut necesar.

Alte atribute pot avea informaie necompletat, nul. Acestea se numesc OPIONALE. Exemplu: n multe cazuri numrul de telefon fix este o informaie ce poate lipsi dac apare numrul de telefon mobil.

LEGATURA(relationship)
Reprezint ceva semnificativ pentru afacere; Exprim care sunt relaiile ntre dou entiti (sau ntre una i aceeai entitate); Se citete n ambele sensuri; Are opionalitate; Are o cardinalitate.

Optionalitatea unei relatii

Relaiile pot fi: - mandatorii - opionale. Exemplu: Pentru a stabili opionalitatea relaiei dintre entitile ANGAJAT si JOB se pun urmtoarele ntrebri: 1. Trebuie ca fiecare angajat s aib un job? 2. Trebuie ca fiecare job s fie acordat unui angajat?

Cardinalitatea unei legaturi

Determin gradul unei legaturi. Se determin prin rspunsul la ntrebarea: Cte? Cti? Exemplu: Cte job-uri poate ndeplini un angajat? Unul, sau mai multe? Cti angajai pot lucra la un job? Doar unul? Sau mai muli?

Exemple de legaturi
Each EMPLOYEE must hold one and only one JOB Each JOB may be held by one or more EMPLOYEEs

Each PRODUCT must be classified by one and only one PRODUCT TYPE Each PRODUCT TYPE may classify one or more PRODUCTs

CONVENII ALE ERD-ului

Entitile sunt reprezentate prin dreptunghiuri cu colurile rotunjite, n care este nscris numele entitii la singular, cu litere mari. Atributele sunt afiate sub numele entitii, cu litere mici. Se pun in fa semnele:

* pentru atribut mandatoriu

o pentru atribut opional # pentru identificator unic.

 Relaiile sunt trasate cu linie:

- continu, pentru relaie mandatorie; - ntrerupt, pentru relaie optional.

Relaiile se termin:
- ntr-o linie, pentru cardinalitate 1; - n trei liniue (picior de cioar), pentru mai multe.

DESENAREA RELAIILOR SI CITIREA LOR IN LIMBAJ ERD-ish

DIAGRAME MATRICIALE
Sunt o alternativ la reprezentarea prin ERD. Sunt folosite atunci cnd avem foarte multe relaii, pentru a ne asigura c nu am uitat vreuna. Diagramele matriciale nu arat opionalitatea i cardinalitatea.

DOCUMENTAREA UNUI ERD

Cheia ce permite verificarea acurateii i completitudinii modelului este identificarea i documentarea regulilor afacerii. Nu toate regulile pot fi reprezentate n diagram. Unele vor fi implementate mai trziu, prin programare. Ele trebuie incluse n documentaia modelului.

Regulile structurale indic:

tipurile de informaii care se vor memora; relaiile dintre aceste informaii. Aproape toate regulile structurale pot fi reprezentate n diagram.

Regulile procedurale descriu procesele din cadrul activitii.

In general, regulile procedurale nu pot fi reprezentate n diagram, i deci trebuie incluse n documentaie. Acestea indic adesea succesiunea n timp a unor evenimente.

TRANSFERABILITATEA RELATIILOR
O relaie este netransferabil dac nu poate fi mutat la alt instan. Exemplu de relaie transferabil :

Un student poate fi mutat n alt grup

Exemplu de relaie netransferabil: O poezie este scris de un autor i nu poate fi transferat altui autor.

TIPURI DE RELATII
Relaia (1:M) One to Many Este relaia cea mai frecvent intlnit.

Relaia (1:1) One to One n practic se ntlnesc doar cteva tipuri de relaie 1:1

Relaia (M:M) Many to Many

Este o relaie foarte ntlnit n prima faz a modelrii. Se recomand rezolvarea acestor relaii n alt mod deoarece nu poate fi implementat n aceast form.

Exemplu pentru etapele crerii unei baze de date

1. Se prezint necesitile informaionale ale afacerii:

2. Se creaz modelul conceptual:

3. Pornind de la modelul conceptual se stabilesc:

- numele tabelelor - numele coloanelor din fiecare tabel, tipul acestora i dup caz proprietatea: PK (primary key), FK(foreign key), Null sau Unique

4. Prin instruciuni SQL se creaz baza de date proiectat anterior.

REVENIRE

Baze de date relaionale

O baz de date relaional se prezint sub forma unei colecii de tabele bidimensionale, corespunznd entitilor din diagram. Legaturile dintre entiti se regsesc n legaturi ntre tabele.

Baze de date relaionale

Cheia primar este o coloan sau un set de coloane care identific n mod unic fiecare nregistrare (rnd al tabelului). Fiecare tabel trebuie s aib o cheie primar, aceasta este unic i (nici o parte a sa) nu poate fi nul. Pot exista mai muli candidai la rolul de cheie primar (chei unice).

Baze de date relaionale

Cheia strin este o coloan sau un set de coloane care se refer la o cheie primar a aceluiai tabel sau a altuia. Ea se folosete pentru a implementa relaiile ntre entiti.

Baze de date relaionale

Regulile (constrngerile) de integritate a datelor definesc starea relaional corect pentru o baz de date. Ele asigur c utilizatorul poate efectua doar acele operaii care las baza de date ntr-o stare consistent.

Baze de date relaionale

Interogrile SQL permit accesarea bazei de date n mod eficient.

Maparea: de la ERD la tabele

Maparea este procesul prin care modelul conceptual (diagrama) este transformat n model fizic (baza de date relaional).

Maparea: de la ERD la tabele

Terminologia se va modifica i ea corespunztor: Entitatea devine tabel. Instana devine linie (rnd). Atributul devine coloan. Identificatorul unic primar devine cheie primar. Identificatorul unic secundar devine cheie unic. Relaia se transform ntr-o coloan cheie strin i o constrngere de cheie strin.

Maparea: de la ERD la tabele

Numele tabelului este format din pluralul numelui entitii, iar prescurtarea se face ca regul din primele litere ale primelor dou silabe (sau primele dou litere ale numelui - n cazul numelor monosilabice, sau primele litere ale primelor dou cuvinte n cazul mai multor cuvinte) i din ultima liter a numelui. Tipul cheii fiecrei coloane va fi pk pentru cheie primar, uk pentru cheie unic, fk pentru cheie strin sau blank dac acea coloan nu face parte din nici o cheie. Opionalitatea coloanei se marcheaz cu * pentru cele obligatorii i cu o pentru cele opionale.

Maparea: de la ERD la tabele

Exist i anumite restricii n folosirea notaiilor. Numele tabelelor i coloanelor: Trebuie s nceap cu o liter Pot conine maxim 30 caractere alfanumerice Nu pot conine caractere speciale (cu excepia lui $, # i _) Trebuie s fie unice Trebuie evitate cuvintele rezervate Oracle, dintre care amintim: NUMBER, SEQUENCE, ORDER, VALUES, LEVEL, TYPE.

Maparea relaiilor
O relaie creeaz una sau mai multe coloane foreign-key n tabelul dinspre partea cu mai multe a relaiei. Se folosesc prescurtrile numelui tabelului pentru coloana foreign-key. Coloana foreign-key este obligatorie sau opional, depinznd de tipul relaiei.

Maparea relaiilor
Maparea respect opionalitatea pentru relaii 1:M doar la captul M. La captul 1 relaia nu poate fi forat prin DDL s fie obligatorie (nu putem impune ca o formaie s aib cel puin un muzician). Este necesar programare procedural pentru realizarea acestui deziderat.

Maparea relaiilor
Nontransferabilitatea unei relaii nseamn c datele din coloana foreign-key a tabelului nu se pot modifica. Constrngerile foreign-key nu pot asigura acest lucru, fiind necesar programare procedural suplimentar.

Maparea relaiilor
Relaiile barate se mapeaz cu ajutorul unei coloane foreign-key column la captul M, ca orice relaie M:1. n acest caz, coloana foreign-key joac dublu rol, fiind i parte a cheii primare.

Maparea relaiilor
Relaiile barate n cascad se mapeaz asemntor, dar numele coloanelor se limiteaz de regul la 2 tabele distan.

Maparea relaiilor
Relaiile M-M se rezolv printr-un tabel de intersecie ce conine dou coloane foreignkey ce se refer la cheile primare din tabelele iniiale.

Maparea relaiilor
La maparea unei relaii 1:1 se creeaz o coloan foreign key care este i unique key n tabelul din captul obligatoriu al relaiei. La relaiile opionale la ambele capete, coloana se creeaz n funcie de regulile afacerii. La relaiile obligatorii la ambele capete, trebuie scris cod suplimentar.

Maparea relaiilor
Entitatea cu arc va deveni un tabel ce conine coloane foreign key de la tabelele din captul 1 al relaiei. Chiar dac relaia cu arc este obligatorie la captul M, coloanele foreign key rezultate trebuie s fie opionale (excluzndu-se mutual). Trebuie scris cod suplimentar pentru a asigura una din valori nenul, de exemplu:
CHECK (pse_id is not null AND phe_id is null) OR (pse_id is null AND phe_id is not null)

Dac relaia ar fi opional la ambele capete, ar trebui adugat:

OR (pse_id is null AND phe_id is null)