MODEL FIZIC SI MODEL CONCEPTUAL

Modelarea datelor este doar prima parte a procesului de construire al bazei de date.
Modelul conceptual: Modelează nevoile informaţionale ale afacerii; Se numeşte “Entity Relationship Model”; Este prezentat printr-o diagramă numită “Entity Relationship Diagram”.

-

Etape in procesul de dezvoltare a bazelor de date
• formularea cerinţelor informaţionale ale afacerii; • desenare model conceptual; • proiectare baza de date pornind de la modelul conceptual (entitaţile devin tabele, atributele devin nume de coloane care corespund unor tipuri de date, se stabilesc proprietăţile 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 păstrate o singură dată. • Să nu cuprindă informaţii ce se obţin din date deja cuprinse in model. • Orice dată să fie aşezată în locul cel mai logic şi mai potrivit.

ENTITATI SI INSTANTE
Entitate = ceva semnificativ pentru afacere, referitor la
care trebuie să cunoaştem date.

Este un substantiv singular. Entităţile au instanţe. Entităţile au atribute.

O instanţă este o valoare dată entităţii. Exemplu: Entitatea FRUCT are instanţe: cireasa, nuca, pepene, măr, portocală.

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

Exemplu: În multe cazuri numărul de telefon fix este o informaţie ce poate lipsi dacă apare numărul de telefon mobil. Acestea se numesc MANDATORII. Alte atribute pot avea informaţie necompletată.Atribute mandatorii sau optionale Unele atribute trebuie neapărat să aibă valoare. Exemplu: In afaceri. . numele este o informaţie absolut necesară. nulă. Acestea se numesc OPŢIONALE.

• Are o cardinalitate. • Are opţionalitate. . • Se citeşte în ambele sensuri.LEGATURA(relationship) • Reprezintă ceva semnificativ pentru afacere. • Exprimă care sunt relaţiile între două entităţi (sau între una şi aceeaşi entitate).

opţionale.Optionalitatea unei relatii • Relaţiile pot fi: . Exemplu: Pentru a stabili opţionalitatea relaţiei dintre entităţile ANGAJAT si JOB se pun următoarele întrebări: 1. Trebuie ca fiecare angajat să aibă un job? 2.mandatorii . Trebuie ca fiecare job să fie acordat unui angajat? .

Se determină prin răspunsul la întrebarea: Câte? Câti? Exemplu: Câte job-uri poate îndeplini un angajat? Unul.Cardinalitatea unei legaturi Determină gradul unei legaturi. sau mai multe? Câti angajaţi pot lucra la un job? Doar unul? Sau mai mulţi? .

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 .

. în care este înscris numele entităţii la singular.CONVENŢII ALE ERD-ului • Entităţile sunt reprezentate prin dreptunghiuri cu colţurile rotunjite. • Atributele sunt afişate sub numele entităţii. cu litere mici. cu litere mari. Se pun in faţă semnele: * pentru atribut mandatoriu o pentru atribut opţional # pentru identificator unic.

pentru cardinalitate 1. .într-o linie. . pentru relaţie mandatorie. • Relaţiile se termină: .continuă. . pentru “mai multe”. pentru relaţie optională.în trei liniuţe (picior de cioară).întreruptă.• Relaţiile sunt trasate cu linie: .

DESENAREA RELAŢIILOR SI CITIREA LOR IN LIMBAJ ERD-ish .

pentru a ne asigura că nu am uitat vreuna.DIAGRAME MATRICIALE Sunt o alternativă la reprezentarea prin ERD. Diagramele matriciale nu arată opţionalitatea şi cardinalitatea. . Sunt folosite atunci când avem foarte multe relaţii.

Regulile structurale indică: • tipurile de informaţii care se vor memora. Regulile procedurale descriu procesele din cadrul activităţii. Ele trebuie incluse în documentaţia modelului. regulile procedurale nu pot fi reprezentate în diagramă. Acestea indică adesea succesiunea în timp a unor evenimente. şi deci trebuie incluse în documentaţie.DOCUMENTAREA UNUI ERD Cheia ce permite verificarea acurateţii şi completitudinii modelului este identificarea şi documentarea regulilor afacerii. In general. Aproape toate regulile structurale pot fi reprezentate în diagramă. Unele vor fi implementate mai târziu. prin programare. • relaţiile dintre aceste informaţii. Nu toate regulile pot fi reprezentate în diagramă. .

Exemplu de relaţie transferabilă : Un student poate fi mutat în altă grupă Exemplu de relaţie netransferabilă: O poezie este scrisă de un autor şi nu poate fi transferată altui autor. .TRANSFERABILITATEA RELATIILOR O relaţie este netransferabilă dacă nu poate fi mutată la altă instanţă.

.TIPURI DE RELATII Relaţia (1:M) One to Many Este relaţia cea mai frecvent intâlnită.

Relaţia (1:1) One to One În practică se întâlnesc doar câteva tipuri de relaţie 1:1 .

Se recomandă rezolvarea acestor relaţii în alt mod deoarece nu poate fi implementată în această formă. .Relaţia (M:M) Many to Many Este o relaţie foarte întâlnită în prima fază a modelării.

Se prezintă necesităţile informaţionale ale afacerii: .Exemplu pentru etapele creării unei baze de date 1.

Se crează modelul conceptual: .2.

FK(foreign key). tipul acestora şi după caz proprietatea: PK (primary key).3.numele tabelelor . Pornind de la modelul conceptual se stabilesc: .numele coloanelor din fiecare tabel. Null sau Unique .

REVENIRE .4. Prin instrucţiuni SQL se crează baza de date proiectată anterior.

corespunzând entităţilor din diagramă. .Baze de date relaţionale • O bază de date relaţională se prezintă sub forma unei colecţii de tabele bidimensionale. • Legaturile dintre entităţi se regăsesc în legaturi între tabele.

aceasta este unică şi (nici o parte a sa) nu poate fi nulă.Baze de date relaţionale • Cheia primară este o coloană sau un set de coloane care identifică în mod unic fiecare înregistrare (rând al tabelului). • Pot exista mai mulţi candidaţi la rolul de cheie primară (chei unice). . • Fiecare tabel trebuie să aibă o cheie primară.

. • Ea se foloseşte pentru a implementa relaţiile între entităţi.Baze de date relaţionale • Cheia străină este o coloană sau un set de coloane care se referă la o cheie primară a aceluiaşi tabel sau a altuia.

• Ele asigură că utilizatorul poate efectua doar acele operaţii care lasă baza de date într-o stare consistentă. .Baze de date relaţionale • Regulile (constrângerile) de integritate a datelor definesc starea relaţională corectă pentru o bază de date.

Baze de date relaţionale • Interogările 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 relaţională).

• Identificatorul unic secundar devine cheie unică. . • Identificatorul unic primar devine cheie primară. • Relaţia se transformă într-o coloană cheie străină şi o constrângere de cheie străină. • Instanţa devine linie (rând).Maparea: de la ERD la tabele • Terminologia se va modifica şi ea corespunzător: • Entitatea devine tabel. • Atributul devine coloană.

Opţionalitatea coloanei se marchează cu “*” pentru cele obligatorii şi cu “o” pentru cele opţionale. “uk” pentru cheie unică. “fk” pentru cheie străină sau blank dacă acea coloană nu face parte din nici o cheie.Maparea: de la ERD la tabele • Numele tabelului este format din pluralul numelui entităţii. • • . iar prescurtarea se face ca regulă din primele litere ale primelor două silabe (sau primele două litere ale numelui . sau primele litere ale primelor două cuvinte – în cazul mai multor cuvinte) şi din ultima literă a numelui. Tipul cheii fiecărei coloane va fi “pk” pentru cheie primară.în cazul numelor monosilabice.

• Numele tabelelor şi coloanelor: – Trebuie să înceapă cu o literă – Pot conţine maxim 30 caractere alfanumerice – Nu pot conţine caractere speciale (cu excepţia lui “$”. ORDER. . “#” şi “_”) – Trebuie să fie unice – Trebuie evitate cuvintele rezervate Oracle. LEVEL. SEQUENCE.Maparea: de la ERD la tabele • Există şi anumite restricţii în folosirea notaţiilor. TYPE. VALUES. dintre care amintim: NUMBER.

• Coloana foreign-key este obligatorie sau opţională. • Se folosesc prescurtările numelui tabelului pentru coloana foreign-key.Maparea relaţiilor • O relaţie creează una sau mai multe coloane foreign-key în tabelul dinspre partea cu mai multe a relaţiei. . depinzând de tipul relaţiei.

Este necesară programare procedurală pentru realizarea acestui deziderat. . • La capătul 1 relaţia nu poate fi forţată prin DDL să fie obligatorie (nu putem impune ca o formaţie să aibă cel puţin un muzician).Maparea relaţiilor • Maparea respectă opţionalitatea pentru relaţii 1:M doar la capătul M.

.Maparea relaţiilor • Nontransferabilitatea unei relaţii înseamnă că datele din coloana foreign-key a tabelului nu se pot modifica. • Constrângerile foreign-key nu pot asigura acest lucru. fiind necesară programare procedurală suplimentară.

coloana foreign-key joacă dublu rol. ca orice relaţie M:1.Maparea relaţiilor • Relaţiile barate se mapează cu ajutorul unei coloane foreign-key column la capătul M. • În acest caz. fiind şi parte a cheii primare. .

dar numele coloanelor se limitează de regulă la 2 tabele distanţă. .Maparea relaţiilor • Relaţiile barate în cascadă se mapează asemănător.

.Maparea relaţiilor • Relaţiile M-M se rezolvă printr-un tabel de intersecţie ce conţine două coloane foreignkey ce se referă la cheile primare din tabelele iniţiale.

• La relaţiile opţionale la ambele capete. . trebuie scris cod suplimentar.Maparea relaţiilor • La maparea unei relaţii 1:1 se creează o coloană foreign key care este şi unique key în tabelul din capătul obligatoriu al relaţiei. coloana se creează în funcţie de regulile afacerii. • La relaţiile obligatorii la ambele capete.

ar trebui adăugat: – OR (pse_id is null AND phe_id is null) . • Chiar dacă relaţia cu arc este obligatorie la capătul M.Maparea relaţiilor • Entitatea cu arc va deveni un tabel ce conţine coloane foreign key de la tabelele din capătul 1 al relaţiei. • Trebuie scris cod suplimentar pentru a asigura una din valori nenulă. coloanele foreign key rezultate trebuie să fie opţionale (excluzându-se mutual). 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ă relaţia ar fi opţională la ambele capete.

Sign up to vote on this title
UsefulNot useful