DATABASE DESIGN

16
DATABASE DESIGN RECAPITULARE

description

DATABASE DESIGN. RECAPITULARE. BAZA DE DATE. Este o colectie organizata (ansamblu de date organizate dupa anumite criterii) de date persistente , pastrata pe suport extern avand posibilitatea accesarii datelor memorate. - PowerPoint PPT Presentation

Transcript of DATABASE DESIGN

Page 1: DATABASE DESIGN

DATABASE DESIGN

RECAPITULARE

Page 2: DATABASE DESIGN

BAZA DE DATE

Este o colectie organizata (ansamblu de date organizate dupa anumite criterii) de date persistente, pastrata pe suport extern avand posibilitatea accesarii datelor memorate.

Pentru a intretine o baza de date se foloseste un sistem de gestionare al bazelor de date(SGBD).Acesta este un pachet de programe, care in concordanta cu conceptele si structurile unui model suporta memorarea si regasirea datelor.

Datele sunt elemente semnificative culese din lumea reala pe baza de observatii si numaratori. Datele pot fi: numere, caractere, imagini, sunete, etc stocate, accesate si transmise utilizand calculatorul

Datele pastrate in baze de date pot fi prelucrate, selectate, combinate, sintetizate. In urma acestor procese obtinem informatii.

Page 3: DATABASE DESIGN

MODEL DE DATE

Un model de date este rezultatul procesului de identificare si organizare a informatiilor necesare pentru modelarea unei situatii concrete din viata reala.

Modelul de date mentioneaza ce informatii trebuie retinute in baza de date si care sunt relatiile dintre ele. El se concretizeaza in diagrama entitate-relatie (entity-relationship diagram) sau pe scurt ERD.

Modelul de date reprezentat in ERD se numeste model conceptual si presupune descrierea structurii si a legaturilor dintre acestea pentru intreaga baza de date.

Modelul fizic al unui obiect include informatii detaliate (cum ar fi volumul, lungimea, greutatea) si este rezultatul concret la care ajungem in urma procesului de modelare.

Page 4: DATABASE DESIGN

DIAGRAMA ENTITATE-RELATIE ERD

ERD-ul modeleaza folosind simboluri grafice si tinand cont de anumite reguli, entitatile care trebuie retinute in baza de date si relatiile dintre acestea.

Entitatea este o data semnificativa care trebuie reprezentata in baza de date. Poate fi un obiect, un fenomen, un concept distinct despre care trebuie sa pastram informatii. Numele unei entitati este un substantiv, luat la singular.

Fiecarei entitati ii este asociat un set de caracteristici sau atribute.Un atribut este o proprietate ce descrie un anumit aspect al obiectului ce se inregistreaza in baza de date.

Atribut obligatoriu (mandatorii) –atributele care au obligatoriu o valoare(NOT NULL)

Atribut optional- pot ramane necompletate in bazele de date(pot avea valoarea NULL)

Page 5: DATABASE DESIGN

DIAGRAMA ENTITATE-RELATIE ERD

Fiecare atribut are un anumit tip cum ar fi:

• numeric

• sir de caractere

• date calendaristice, etc.

Tipul unui atribut precizeaza domeniul de valori si operatiile permise cu data respectiva. O inregistrare (instanta) din baza de date are doar cate o singura valoare pentru fiecare atribut.

Identificator unic (UID)- atribut sau combinatie de atribute folosite pentru a identifica in mod unic o instanta(inregistrare.) Pot fi:

- simplu format dintr-un singur atribut

- compus format dintr-o combinatie de doua sau mai multe atribute

Page 6: DATABASE DESIGN

DIAGRAMA ENTITATE-RELATIE ERD

Relatiile sunt expresii verbale care indica asocierile, legaturile logice care se formeaza intre entitati. De regula entitatile sunt substantive iar relatiile sunt verbe si se deduc din documentatia beneficiarului.

Relatiile pot fi:

- obligatorii – orice inregistrare a entitatii trebuie sa fie legata de una sau mai multe inregistrari ale celeilalte entitati

- optionale - orice inregistrare a entitatii ar putea sa fie legata de una sau mai multe inregistrari ale celeilalte entitati

Exemplu: Daca consideram entitatile LOC si CALATOR intre ele exista relatiile:

“Un loc poate fi ocupat de un calator” – este o relatie optionala

“Un calator trebuie sa ocupe un loc” - este o relatie obligatorie

Page 7: DATABASE DESIGN

DIAGRAMA ENTITATE-RELATIE ERD

Conventii pentru reprezentarea unei relatii.

Relatia dintre doua entitati se reprezinta printr-un segment care le uneste. Acesta poate fi desenat:

- cu linie continua – daca relatia este obligatorie pentru entitatea respectiva

- cu linie punctata -daca relatia este optionala pentru acea entitate

Numele relatiei este un verb sau o expresie verbala si se scrie deasupra liniei care desemneaza relatia din stanga si sub linie pentru entitatea din dreapta

Capatul segmentului care reprezinta relatia poate fi:

- simplu-o unica inregistrare a entitatii respective este conectata cu alta entitate

- cu trei picioruse -mai multe inregistrari ale entitatii respective sunt in relatie cu cealalta entitate

Page 8: DATABASE DESIGN

Citirea unei diagrame ERD intre entitatea A si entitatea B se va citi astfel:

FiecareNumele entitatii AOptionalitatea(trebuie/poate)Numele relatiei (scris deasupra/sub liniei)Cardinalitatea (unul si numai unul/unul sau mai multi)Numele entitatii B

Tinand cont ca o relatie are doua capete vom citi mai intai diagrama de la stanga la dreapta si apoi de la dreapta la stanga

DIAGRAMA ENTITATE-RELATIE ERD

Entitatea A Entitatea BNume relatie A

Nume relatie B

Page 9: DATABASE DESIGN

DIAGRAMA ENTITATE-RELATIE ERD

Exemplu: Vom considera entitatile JUCATOR si GOL prin intermediul carora vrem sa memoram golurile marcate in timpul unui meci de fotbal

sa marcheze

Este marcat

JUCATOR#id*nume*post

GOL#id_meci*minut○observatii

Citirea diagramei se face astfel:

“Fiecare jucator poate sa marcheze unul sau mai multe goluri” “Fiecare gol trebuie sa fie marcat de un singur jucator”

Page 10: DATABASE DESIGN

DIAGRAMA ENTITATE-RELATIE ERDIntre doua entitati pot exista urmatoarele tipuri de relatii:

Relatie 1:1 obligatorie la ambele capete

Relatie 1:1 optionala la ambele capete

Relatie 1:1 optionala la stanga, obligatorie la dreapta

Relatie 1:1 obligatorie la stanga, optionala la dreapta

Relatie M:1 optionala la stanga, obligatorie la dreapta

Relatie 1:M obligatorie la stanga, optionala la dreapta

Relatie M:M obligatorie la ambele capete

Relatie M:M optionala la ambele capete

Page 11: DATABASE DESIGN

DIAGRAMA ENTITATE-RELATIE ERD

Daca o inregistrare dintr-o entitate care se afla intr-o relatie cu o inregistrare din alta entitate poate fi relationata cu o alta intregistrare din cea de-a doua atunci spunem ca relatia este transferabila, altfel spunem ca este nontransferabila. Acest lucru se reprezinta in diagrama printr-un romb.

sa marcheze

Este marcat

JUCATOR#id*nume*post

GOL#id_meci*minut○observatii

Entitatile JUCATOR si GOL sunt in relatie 1:M si ea nu e transferabila pentru entitatea GOL(un gol este marcat in mod unic de un jucator si el nu poate fi atribuit apoi altui jucator).

Page 12: DATABASE DESIGN

DIAGRAMA ENTITATE-RELATIE ERDO relatie in care mai multor inregistrari ale unei entitati ii corespund una su mai multe inregistrari ale altei entitati este de tip mai-multi-la-mai-multi M:M. Rezolvarea relatiei de acest tip presupune introducerea intre cele doua entitati a unei noi entitati numita entitate de intersectie. Aceasta preia atribute din entitatile initiale dar poate avea si entitati proprii.Exemplu: Consideram entitatile ABONAT si REVISTA intre care exista o relatie de tip M:M

sa se aboneze

distribuita

ABONAT#id_abonat*nume*prenume*adresa

REVISTA#id_revista*nume*pret*numar aparitii

Page 13: DATABASE DESIGN

DIAGRAMA ENTITATE-RELATIE ERD

sa se aboneze distribita

ABONAT#id_abonat*nume*prenume*adresa

REVISTA#id_revista*nume*pret*numar aparitii

ABONAMENT#id_abonat#id_revista*data

pentru pentru

Pentru rezolvare vom considera entitatea de intersectie ABONAMENT care preia identificatorul unic de la REVISTA(id_revista) si identificatorul unic de la ABONAT(id_abonat). Pentru a marca faptul ca aceasta entitate a fost nou introdusa si ca unicul identificator este realizat din atribute impreuna cu relatia atunci se foloseste relatia barata.

Page 14: DATABASE DESIGN

CREAREA TABELELORComanda SQL pentru crearea tabelelor este CREATE TABLE. O forma generala simplificata a acestei comenzi este:

CREATE TABLE nume_tabel (nume_coloana1 tip_coloana1(dimensiune1),

nume_coloana2 tip_coloana2(dimensiune2),…);

Tabelele se pot crea si folosind modul visual.

Pentru a folosi corect comanda trebuie cunoscute cateva restrictii Oracle referitoare la numele tabelelor si ale atributelor:

- sa nu depaseasca 30 de caractere

- sa inceapa cu o litera

- poate contine litere mari, litere mici, cifre si caracterele: _,$ si #

- trebuie sa fie diferit de orice cuvat rezervat Oracle

- sa nu fie duplicat al numelui unui alt obiect al aceluiasi user

Page 15: DATABASE DESIGN

POPULAREA TABELELOR

Tabelele pot fi populate cu date folosind comanda INSERT. Prin intermediul ei pot fi adaugate noi inregistrari in tabela. Formatul general este:

INSERT INTO nume_tabela (coloana1, coloana2,….coloana_n)

VALUES(val1, val2,…, val_n);

Observatii:

- Nu este obligatoriu ca lista coloanelor sa cuprinda toate atributele tabelului, pot fi omise atributele pentru care nu se doreste inserarea de valori in noua inregistrare. Nu este permis sa lipseasca atributele marcate NOT NULL.

- Lista de valori trebuie sa corespunda litei de atribute ca numar, pozitie si tip

Page 16: DATABASE DESIGN

INTEROGARI

Procesul de extragere de informatii din baza de date se numeste interogare, iar formularea unei interogari inseamna construirea si lansarea unei comenzi SELECT. O interogare poate avea ca scop extragerea de informatii din una sau mai multe tabele. Daca se doreste interogarea mai multor tabele atunci ele trebuiesc legate prin clauze JOIN.

Forma generala:

SELECT coloana1 AS “alias1”, coloana 2 AS “alias2”,… FROM nume_tabela

WHERE conditie

GROUP BY conditie

HAVING conditie

ORDER BY conditie

Pentru a afisa toate coloanele tabelei se poate inlocui lista coloanelor cu caracterul *