MINISTERUL EDUCATIEI SI CERCETARII
COLEGIUL NATIONAL
ION MINULESCU
SLATINA,2011

CUPRINS

I) Scenariu

II) ERD

1)Entitati si attribute

2)Diagrama initiala

3)Depistarea greselilor si corectarea lor

4)Discutarea relatiilor

5)Rezolvarea relatiilor many-to-many

6)Diagrama finala

III) Bibliografie

I)Scenariu

Traim intr-o lume moderna in care oamenii au nevoie de mijloace de transport pentru deplasa diferite marfuri in diferite locatii. In acest moment intervine firma de transporturi care la cererea clientului, pune la dispozitie diferite mjloace de transport. Mereu am fost curios sa aflu cum functioneaza o astfel de firma si ce presupune lucrul intr-o astfel de firma, din momentul primirii unei cereri pana in stadiul final. Din punctul de vedere al clientului lucrurile stau relative simplu. El doreste sa transporte diferite materiale intr-o anumita locatie. Hotarat fiind de ceea ce isi doreste apeleaza la serviciile unei firme de constructii care din momentul primirii cererii se ii pune la dispozitie un mijloc de transport care se potriveste cererii acestuia. In schimb, din punctul de vedere al firmei de transporturi lucrurile stau altfel. Din momentul primirii cererii angajatii firmei se pun pe treaba si lucreaza intens pentru a intocmi un proiect care sa corespunda dorintelor clientului.

II)ERD

Entitati si attribute

ENTITATEATRIBUTEPUNCT FIRMA PROIECTAREcod, nume, adresaORAScod_postal, numeDEPARTAMENTcod_depANGAJATcnp,nume,prenume, adresa, e-mailSALARIUluna,nr_ore_lucrate, sal_baza, comisionTRANSPORTnr_inregistr, numeCOST TRANSPORTdata, pret, curs_valutarBENEFICIARnume, adresaMIJLOC TRANSPORTcod_mijlocMARFAcod_marfaDOCUMENTAREcod_doc

SUBENTITATIATRIBUTE SECRETARIAT SOFERI- INTRETINERE- INFORMATICA- EDITARE- PERSOANA_FIZICA cnp PERS_JURIDICA cnp

este

este

este

este

primeste

ajunge

apartine

are

realizeaza

este

contine

apartine

apartine

primeste

lucreaza

are

apartine

are

PUNCT FIRMA

TRANSPORTURI

#cod

*nume

*adresa

ORAS

#cod_postal

*nume

DEPARTAMENT

#cod_dep

SECRETARIAT

SOFERI

INTRETINERE

INFORMATICAAA

EDITARE

ANGAJAT

#CNP

*nume

*prenume

*data_nasterii

*adresa

e-mail

SALARIU

#luna

*nr_ore_lucrate

*sal_baza

comision

TRANSPORT

#nr_inregistr

*nume

MIJLOC TRANSPORT

#cod_mijloc

MARFA

#cod_marfa

DOCUMENTARE

#cod_doc

COST_TRANSPORT

#data

*pret

*curs_valutar

BENEFICIAR

*nume

*adresa

PERS_FIZICA

#CNP

PERS_JURIDICA

#CNP

2)Diagrama Initiala

3) Depistarea greselilor si corectarea lor

Normalizarea este o tehnica de proiectare a bazelor de date prin care se elimina( sau se evita) anumite anomalii si inconsistente ale datelor. O baza de date bine proiectata nu permite ca datele sa fie redundante, adica aceeasi informatie sa se gaseasca in locuri diferite sau sa se memorize in baza de date informatii care se pot deduce pe baza altor informatii memorate in baza de date.

Anomaliile care pot sa apara la o baza de date nenormalizata sunt urmatoarele:

-anomalii la actualizarea datelor;

-anomalii de inserare;

-anomalii de stergere.

Conceptul de normalizare a bazelor de date a fost pentru prima data introdus de catre Edgar Frank Codd.

Edgar Codd a definit primele trei forme normale 1NF, 2NF si 3NF.

Prima forma normala(1NF)

O entitate se gaseste in prima forma normala daca si numai daca:

-nu exista attribute cu valori multiple;

-nu exista attribute sau grupuri de attribute care se repeat.

Cu alte cuvinte, toate atributele trebuie sa fie atomice, adica sa contina o singura informatie.

Daca un atribut are valori multiple sau un grup de attribute se repeat, atunci trebuie sa create o entitate suplimentara pe care o legati de entitatea originala printr-o relatie 1:m . In noua entitate vor fi introduce atributele sau grupurile de attribute care se repeat.

A doua forma normala (2NF)

O entitate se gaseste in a doua forma normala daca si numai daca:

-se gaseste in prima forma normala;

-orice atribut care nu face parte din UID ( Unique Identifier) va depinde de intregul UID, nu doar de o parte a acestuia.

Se observa ca data_nasterii si adresa sunt doua attribute care depind doar de cod_angajat, nu de intregul UID care este combinatia dintre atributele cod_dep si cod_angajat. Aceasta situatie se rezolva prin crearea unei noi entitati ANGAJAT pe care o legam de entitatea DEPARTAMENT printr-o relatie 1:m.

O situatie mai speeciala este in cazul relatiilor barate, cand trebuie tinut seama ca UID-ul unei entitati este compus din attribute din entitatea respectiva, plus un atribut sau mai multe provenite din relatia barata.

DEPARTAMENT

#cod_dep

#cod_angajat

*data_nasterii

*adresa

A treia forma normala (3NF)

O entitate se gaseste in a treia forma normala daca si numai daca:

-se gaseste in a doua forma normala;

-nici un atribut care nu este parte a UID-ului nu depinde de un alt atribut non-UID.

Cu alte cuvinte nu se accepta dependente tranzitive, adica un atribut sa depinda de UID in mod indirect.

ANGAJAT

#CNP

*nume

*prenume

*data_nasterii

*adresa

DEPARTAMENT

#cod_dep

4) Discutarea relatiilor

ORAS - PUNCT FIRMA TRANSPORTURI : relatie one-to-many

Un ORAS poate contine una sau mai multe FIRME DE TRANSPORTURI.

O FIRMA DE TRANSPORTURI apartine unui ORAS.

ORAS

#cod_postal

*nume

PUNCT FIRMA

TRANSP

#cod

*nume

*adresa

PUNCT FIRMA TRANSPORTURI DEPARTAMENT : relatie one-to-many
O FIRMA DE TRANSPORTURI unu sau mai multe DEPARTAMENTE.
Un DEPARTAMENT apartine unei FIRME DE TRANSPORTURI

PUNCT FIRMA

TRANSPORTURI

#cod

*nume

*adresa

DEPARTAMENT

#cod_dep

SECRETARIAT

SOFERI

INTRETINERE

INFORMATICA

EDITARE

DEPARTAMENT ANGAJAT : relatie one-to-many

Un DEPARTAMENT are unul sau mai multi ANGAJATI.

Un ANGAJAT lucreaza intr-un anumit DEPARTAMENT.

DEPARTAMENT

#cod_dep

SECRETARIAT

SOFERI

INTRETINERE

INFORMATICA

EDITARE

ANGAJAT

#cnp

*nume

*prenume

*data_nasterii

*adresa

e-mail

ANGAJAT - SALARIU : relatie one-to-many
Un ANGAJAT primeste unul sau mai multe SALARII.
Un SALARIU apartine unui ANGAJAT.

SALARIU

#luna

*nr_ore_lucrate

*sal_baza

comision

ANGAJAT

#cnp

*nume

*prenume

*data_nasterii

*adresa

e-mail

ANGAJAT TRANSPORT : relatie one-to-many
Un ANGAJAT realizeaza unul sau mai multe TRANSPORTURI.
UN TRANSPORT este realizata de un ANGAJAT.

ANGAJAT

#cnp

*nume

*prenume

*data_nasterii

*adresa

e-mail

TRANSPORT

#nr_inregistr

*nume

TRANSPORT MIJLOC TRANSPORT

TRANSPORT MARFA relatie de tip arc

TRANSPORT DOCUMENTARE

UN TRANSPORT este fie MIJLOC DE TRANSPORT, fie MARFA, fie DOCUMENTARE.

UN MIJLOC reprezinta unul sau mai multe TRANSPORTURI.

O MARFA reprezinta una sau mai multe TRANSPORTURI.

O DOCUMENTARE reprezinta una sau mai multe TRANSPORTURI.

TRANSPORT

#nr_inregistr

*nume

MIJLOC DE TRANS

#cod_mijloc

MARFA

#cod_marfa

DOCUMENTARE

#cod_doc

TRANSPORT COST TRANSPORT : relatie one-to-many
UN TRANSPORT are una sau mai multe COSTURI.
COSTUL apartine unui TRANSPORT.

TRANSPORT

# nr_inregistr

*nume

COST_TRANSP

#data

*pret

*curs_valutar

TRANSPORT BENEFICIAR : relatie many-to-many

Unul sau mai multe TRANSPORTURI ajung la un BENEFICIAR.

Unul sau mai multi BENEFICIARI primesc un TRANSPORT.

TRANSPORT

#nr_inregistr

*nume

BENEFICIAR

*nume

*adresa

PERS_FIZICA

#cnp

PERS_JURIDICA

#cnp

5) Rezolvarea relatiilor many-to-many

Relatiile many-to-many pot aparea intr-o prima faza a proiectarii bazei de date, insa ele nu au voie sa apara in schema finala.

Rezolvarea unei relatii many-to-many consta in introducerea unei noi entitati numita entitate de intersectie , pe care o legam de entitatile originale prin cate o relatie one-to-many.

Pasul 1:

-se gaseste entitatea de intersectie-pt cazul nostru, vom introduce entitatea EVIDENTA_TRANSPORT

Pasul 2: se creaza noile relatii
optionalitatea - relatiile care pleaca din entitatea de intersectie sunt intotdeauna obligatorii in aceasta parte. In partea dinspre entitatile originale, relatiile vor pastra optionalitatea relatiilor initiale.
cardinalitatea- ambele relatii sunt de tip one-to-many, iar partea cu many va fi intotdeauna inspre entitatea de intersectie.
numele noilor relatii

ajunge

primeste

apartine

are

TRANSPORT

#nr_inregistr

*nume

BENEFICIAR

*nume

*adresa

PERS_FIZICA

#cnp

PERS_JURIDICA

#cnp

EVIDENTA_TRANSPORT

Pasul 3: -adaugarea de attribute in cadrul entitatii daca acestea exista

Pasul 4: -stabilirea identificatorului unic pentru entitatea de intersectie; daca entitatea de intersectie nu are un identificator unic propriu, atunci acesta se poate forma din identificatorii unici ai entitatilor initiale,

la care putem adauga attribute ale entitatii de intersectie.

primeste

apartine

ajunge

are

TRANSPORT

#nr_inregistr

*nume

BENEFICIAR

*nume

*adresa

PERS_FIZICA

#cnp

PERS_JURIDICA

#cnp

EVIDENTA_TRANSPORT

#data inceput

#data sfarsit

Faptul ca identificatorul unic (UID) al unei entitati preia identificatorul unic din alta entitate cu care este legata este reprezentat graphic prin bararea relatiei respective,
inspre entitatea care preia UID-ul celeilalte entitati

are

ajunge

apartine

primeste

TRANSPORT

#nr_inregistr

*nume

BENEFICIAR

*nume

*adresa

PERS_FIZICA

#cnp

PERS_JURIDICA

#cnp

EVIDENTA_TRANS

#data_inceput

#data_sf

este

este

este

este

tinuta

are

apartine

tine

ajunge

primeste

reiese

genereaza

apartine

are

contine

apartine

primeste

obtinut

lucreaza

are

apartine

are

PUNCT FIRMA

TRANSPORTURI

#cod

*nume

*adresa

ORAS

#cod_postal

*nume

DEPARTAMENT

#cod_dep

SECRETARIAT

SOFERI

INTRETINERE

INFORMATICA

EDITARE

ANGAJAT

#CNP

*nume

*prenume

*adresa

e-mail

SALARIU

# luna

*nr_ore_lucrate

*sal_baza

comision

EVID_TRANSPORT

#data_inceput

#data_sf

FACTURA

*sume_plata

#data

TRANSPORT

#nr_inregistr

*nume

MARFA

#cod_marfa

MIJLOC TRANS

#cod_mijloc

DOCUMENTARE

#cod_doc

COST_TRANSPORT

#data

*pret

*curs_valutar

BENEFICIAR

#nume

*adresa

PERS_FIZICA

#CNP

PERS_JURIDICA

#CNP

6) Diagrama finala

III) Bibliografie

- Manual de Informatica Intensiv pentru clasa a XII-a

( Autori: Vlad Tudor Hutanu si Carmen Popescu)

- site-ul Oracle Academy: https://academy.oracle.com