Proiectarea unei baze de date reprezinta procesul pe care îl parcurgeti în vederea pregatirii crearii fizice a unei baze de date Oracle. Etapele acestui proces includ identificarea operatiunilor comerciale pe care le va gestiona baza de date, precum si crearea proiectului 121d323b fizic al bazei de date. în acest capitol sunt trecute în revista etapele necesare proiectarii unei baze de date.
Proiectarea corespunzatoare a bazei de date este vitala pentru buna functionare a bazei de date si a oricarei aplicatii care utilizeaza baza de date.' în lipsa unei proiectari corecte a bazei de date, aceasta poate prezenta urmatoarele deficiente:
Integritatea datelor este compromisa deoarece restrictiile de integritate nu pot fi proiectate sau implementate corect
Datele devin redundante, iar aplicatiile individuale se aglomereaza în încercarea de a asigura sincronizarea datelor
Performantele sunt afectate deoarece este posibil ca pentru finalizarea unei instructiuni select sa fie necesare interogari suplimentare
Pentru a crea o baza de date Oracle este necesara parcurgerea urmatoarelor etape:
Crearea unui model al activitatii companiei
Crearea unui model al datelor
Crearea unui proiect de baza de date
Crearea definitiei unui tabel
Crearea unui tabel relational
Crearea unui model al afacerii
Aceasta prima etapa presupune strângerea de informatii despre activitatea companiei si procesele aferente pe care le va sustine baza de date Oracle. Scopul dumneavoastra este sa stabiliti daca modul curent de derulare a activitatii companiei prezinta neajunsuri si daca exista posibilitati de îmbunatatire sau de extindere a activitatii. Pentru a dobândi o buna cunoastere a activitatii companiei si a proceselor aferente, veti întreprinde urmatoarele:
Veti lua interviuri urmatoarelor persoane:
a) Managerilor si supervizorilor activitatilor companiei.
b) Potentialilor utilizatori finali.
c) Potentialilor beneficiari finali. Acestia sunt persoanele care s-ar putea sa nu utilizeze direct noua baza de date, însa urmeaza sa primeasca informatii si sa beneficieze de existenta bazei de date.
Descoperiti obiectivul declarat al activitatii. Este întotdeauna util sa cunoasteti scopurile activitatii unei companii astfel încât baza de date si aplicatia dumneavoastra sa fie concepute în vederea deservirii acestora.
Colaborati cu utilizatorii si supervizorii pentru a defini obiectivul aplicatiei. Este obligatoriu sa definiti pretentiile companiei referitoare la ceea ce urmeaza sa faca baza de date si aplicatia.
Analizati specificatiile de sistem curente.
Identificati viitoarele specificatii de sistem pentru baza de date.
În acest moment, veti fi în posesia unor cantitati mari de date cum ar fi formulare, manuale, rapoarte, însemnari si multe alte tipuri de informatii. Este necesar sa întelegeti toate aceste informatii si sa le ordonati înainte de a trece la etapa urmatoare.
Dupa ce ati strâns informatiile precedente, trebuie sa construiti un model sau o reprezentare grafica a necesitatilor si regulilor companiei. De exemplu, sa presupunem ca ati aflat urmatoarele informatii despre activitatea companiei în timpul interviurilor anterioare:
Compania are nevoie sa stie ce agent de vânzari deserveste fiecare client.
De asemenea, trebuie sa cunoasca numele si telefonul clientului
Vor sa aiba posibilitatea de a gasi rapid informatii despre un anumit client
O tehnica de modelare verificata pentru reprezentarea grafica a activitatilor companiilor este modelul ERD (Entity Relationship Diagram-diagrama relatiei dintre entitati). Acest model este format din trei componente:
Entitate - Un element relevant în legatura cu care sunt necesare informatii
Atribut - Ceva care descrie sau expliciteaza o entitate
Relatie - O asociere între doua entitati
Numai elementele relevante pentru activitatea companiei devin entitati. Orice descrieri ale unei entitati devin atributele acesteia. Informatiile pe care le-ati obtinut privitor la activitatea companiei trebuie sa descrie relatiile între entitati.
Ducând acest exemplu mai departe, vom crea o diagrama ERD simpla. Consultati Figura 3.1 pentru un exemplu de diagrama a relatiilor dintre entitati.
Figura 3.1.
|
O diagrama
simpla a |
Informatii obtinute în prima etapa |
|
|
Dupa ce ati creat diagrama ERD initiala, analizati-o împreuna cu responsabilii de compartimente pentru a va asigura ca ea este corecta si a o îmbunatati daca este cazul.
Printre avantajele utilizarii diagramei ERD se numara urmatoarele:
Diagrama ERD documenteaza cerintele informationale ale companiei într-un format clar si precis
Aceasta abordare grafica a modelarii o face usor de înteles
Simplitatea modelului îl face usor de utilizat
Acum când diagrama ERD este completa, acest model, împreuna cu informatiile referitoare la activitatea companiei culese în Etapa l, poate fi utilizat pentru crearea unui proiect de baza de date. Figura 3.2 Ilustreaza modul în care diagrama ERD poate fi convertita în schema unei instante a unei baze de date standard.
|
Figura 3.2 Conversia diagramei ERD în schema instantei. |
|
Schema instantei este compusa din rânduri care definesc caracteristicile critice ale bazei de date. Entitatile din diagrama ERD devin tabele; atributele devin coloane ale acestor tabele; iar relatiile devin chei externe.
Dupa finalizarea acestei scheme, analizati-o din nou cu responsabilii de compartimente pentru a va asigura ca este completa si corecta.
În Oracle, pentru crearea tabelelor fizice, este folosita instructiunea SQL create table. Multimea acestor tabele, împreuna cu consideratiile privind securitatea, reprezinta fundamentul bazei de date relationale.
Figura 3.3 ilustreaza cât de usor poate fi modelata instructiunea create table pornind de la tabelul schemei de instanta.
|
Figura 3.3 Utilizarea schemei de instanta ca baza pentru instructiunea create. |
|
Capitolul 5, "Tabele", furnizeaza informatii suplimentare în legatura cu crearea tabelelor.
Acum este momentul pentru a crea tabelul. Crearea unui tabel se realizeaza prin definirea numelui tabelului, precum si a numelor coloanelor tabelului si a descrierii acestora folosind o instructiune SQL. Urmatoarea instructiune creeaza tabelul prezentat în figurile anterioare:
create table client vânzari
(id number(7), nume varchar2(30)
constraint s_client_nume_nn not nuli, tel varchar2(12) rep_vanzari_nr_marca number(7), constraint s_client_pk_id primary key (id));
Odata ce aceasta instructiune a fost lansata prin intermediul programelor SQL*PLUS sau SQL*DBÂ, tabelul exista fizic în baza de date relationala Oracle.
O relatie este o asociere bi-directionala între doua entitati. Exemplele anterioare au tratat relatii simple, în lumea reala, relatiile tind sa fie ceva mai complexe.
Intre entitati pot exista urmatoarele tipuri de relatii:
|
una-la-una |
Aceasta este cea mai simplista relatie posibila. |
|
(one-to-one) |
Oricarei aparitii (valori) a primei entitati îi corespunde o singura valoare a celei de-a doua. Un exemplu îl poate constitui un angajat care are un numar de marca unic. |
|
una-la-mai multe |
în aceasta relatie, pentru fiecare valoare entitate exista |
|
(one-to-many) |
mai multe entitati corespunzatoare. Un exemplu îl reprezinta o companie careia îi apartin mai multi angajati. |
|
mai multe-la-una |
Mai multor entitati le corespunde o singura entitate. |
|
(many-to-one) |
Un exemplu îl reprezinta mai multi angajati apartinând unei singure companii. |
|
mai multe-la-mai |
Mai multe entitati sunt asociate cu mai multe entitati. |
|
multe (many-to-many) |
Un exemplu l-ar putea constitui relatia dintre angajati si deprinderi. Un angajat poate avea mai multe deprinderi, iar o deprindere poate fi comuna mai multor angajati. |
|
sau zero |
Acesta este un calificator care poate fi aplicat oricareia dintre relatiile precedente. Daca este aplicat relatiei una-la-mai multe, aceasta devine una-la-zero sau mai multe. Aceasta înseamna ca un angajat poate avea mai multe deprinderi sau nici o deprindere. |
|
Figura 3.4 Moduri de reprezentare a relatiilor în diagrama ERD. |
|
Normalizarea este procesul prin care eliminati problemele legate de redundanta datelor în proiectul bazei de date si construiti un model de date care sustine diverse cerinte functionale si structuri alternative ale bazei de date.
Normalizarea este un proces ordonat în care aplicati urmatoarele trei reguli referitoare la date:
Toate atributele trebuie specificate o singura data. Aceasta este forma l normala. Aceasta înseamna ca atributele nu trebuie sa se repete. De exemplu, ce-ati zice de o entitate client definita în felul urmator?
client
id
data primului contact
locul primului contact
rezultatul primului contact
data celui de-al doilea contact
locul celui de-al doilea contact
rezultatul celui de-al doilea contact
data celui de-al treilea contact
locul celui de-al treilea contact
rezultatul celui de-al treilea contact
Data, locul si rezultatul sunt repetate si de aceea nu sunt considerate ca fiind specificate o singura data. Pentru â normaliza acest tabel, transformati entitatea prin crearea unei entitati suplimentare numita contact, având b relatie de mai multe-la-una cu clientul. Atributele data, loc si rezultat vor apartine entitatii contact, iar ID va apartine entitatii client. 'Acest proces elimina valorile repetate.
Un atribut trebuie sa depinda în întregime de identificatorul (ID) unic al entitatii pe care o descrie. Aceasta este forma normala 2. Mutati atributele într-un tabel în care depind exclusiv de o cheie principala. Nu utilizati tabele în care atributele sa nu depinda exclusiv de o singura cheie.
Pentru a fi în forma normala 3, o relatie trebuie sa fie în forma normala 2, iar atributele ID nu trebuie sa depinda tranzitiv de cheia primara.
Atunci când normalizarea este completa, fiecare tabel trebuie sa posede o singura cheie primara, iar datele din tabel trebuie sa depinda exclusiv de cheia primara a tabelului.
Proiectarea bazei de date presupune parcurgerea mai multor etape pentru a^colecta, a analiza si a modela informatiile referitoare la activitatea companiei, în acest capitol, au fost prezentate etapele necesare analizarii si modelarii datelor.
Proiectarea judicioasa a bazei de date este necesara deoarece în lipsa ei performantele ar avea de suferit, integritatea datelor ar fi în pericol, iar baza dumneavoastra de date ar deveni prea mare datorita acumularii de date duplicate.
însusirea artei de a proiecta o baza de date presupune acumularea unei experiente îndelungate. Cu toate acestea, parcurgând etapele prezentate în acest capitol, puteti construi o baza de date solida si bine conceputa.
|
