Generarea schemei baze de date

Generarea schemei baze de date

Obiecte persistente

        Etapa de proiectare a unui sistem informatic presupune si determinarea obiectelor persistente, adica a acelor obiect ce se vor pastra intre doua executii ale unei aplicatii.  Determinarea acestor obiecte se realizeaza pe baza diagramei de clase, dupa care ele sunt translatate intr-un model relational ce va sta la baza proiectarii bazei de date. Cea mai simpla si usoara metoda de translatare a claselor in tabele ale unei baze de date este asocierea 1:1 a claselor cu tabele. Aceasta metoda nu este insa recomandata deoarece pot aparea urmatoarele probleme:
            - prea multe tabele: in general din modelele OO pot rezulta, prin aceasta metoda, mai multe tabele decat este necesar
            - prea multe operatii de conectare (join): multe tabele -> mai multe operatii de join SQL pentru regasirea datelor (v. relatiile de 1:1)
            - tabele ignorate: relatiile de asociere n:m se implementeaza prin intermediul unei tabele de legatura (curs-studenti). Clasele asociere reduc aceste probleme dar ele sunt in putine cazuri modelate.
            -tratarea necorespunzatoare a mostenirii
            - de-normalizarea datelor: duplicarea acelorasi date in mai multe tabele (apare in special din cauza claselor care modeleaza necesitati unice de raportare).

        Inainte de a transforma clasele in entitati relationate trebuie sa raspundem la intrebarea daca necesita sa fie persistenta sau nu? In Rational Rose pentru fiecare clasa se permite specificarea (in tab-ul Detail) daca o clasa este persistenta sau temporara.

Se considera urmatoarea diagrama de clase:

In vederea generarii schemei bazei de date relationale trebuie realizata o diagrama intermediara Entity Relationship Model. In acest scop, diagrama de clase trebuie analizata si revizuita pentru a fi compatibila cu abordarea relationala.

Reguli de transformare:

        Inainte de a transforma clasele in entitati relationate trebuie sa raspundem la intrebarea daca necesita sa fie persistenta sau nu? In Rational Rose pentru fiecare clasa se permite specificarea (in tab-ul Detail) daca o clasa este persistenta sau temporara.

1. Transformarea asocierilor simple:

- asocieri 1:1 -> doua tabele (daca este asociere 1 - 0..1) sau o tabela cand este 1:1

- asocieri 1:n -> doua tabele. Cheia unei tabele (1) este cheie straina pentru tabela corespunzatoare lui n.

- asocieri m:n. Doua tabele plus o tabela de legatura (tabela de intersectie). Cheia tabelei de legatura poate fi un surogat, sau poate fi compusa din cheile principale ale celorlalte doua tabele (ex. salariat - patron)

2. Transformarea relatiei de mostenire:

        Exista trei variante de transformare in tabele a unei perechi super-clasa / sub-clasa:

A. Se creaza cate o tabela pentru fiecare clasa si un view SQL pentru fiecare pereche superclasa/subclasa

B. Se creaza o singura tabela (corespunzatoare superclasei) si se de-normalizeaza toate coloanele de inf. din subclase in tabela superclasei. Implica modificari ale tabelei pentru urmatoarele subclasari, si contine spatii 'moarte' -> poate afecta performanta accesului la date. Se mai adauga un camp (si eventual o tabela) special care precizeaza tipul unei inregistrari memorate in tabela.

C. Se creaza cate o tabela pentru fiecare subclasa si se de-normalizeaza atributele superclasei in fiecare subclasa. Daca se modifica superclasa, trebuie sa se modifice toate subclasele.

        In cazul in care numarul inregistrarilor este limitat in super-clasa si sub-clase atunci prima varianta este cea mai potrivita (performanta nu este grav afectata iar flexibilitatea este maxima). Daca numarul atributelor in super-clasa este mic in comparatie cu sub-clasa atunci varianta 3 este una acceptabila. In fine, in cazul in care cantitatea de date din subclase este mica atunci varianta 2 reprezinta o solutie de compromis acceptabila deoarece performanta de acces la date este cea mai buna insa cu un potential redus de flexibilitate.

3. Transformarea agregarii si compunerii:

       - in general, se transforma relatii standard intre tabele;
       - relatiile de agregare se implementeaza in tabele separate fara stergere in cascada. De obicei in aceste cazuri se formeaza multe relatii 1:1;
       - relatiile de compunere sunt implementate aproape intotdeauna ca o singura tabela. Atunci cand se alege varianta cu mai multe tabele, atunci trebuie implementata optinea de stergere in cascada.

        Asocierile reflexive se transforma in relatii recursive. Acestea sunt dificil de intretinut, mai ales in cazul asocierilor bidirectionale care au asociate constrangeri de integritate.

        Cheile asociate tabelelor pot fi naturale sau surogat, generate de automat de catre sistemul de gestiune al bazelor de date. Avantaje pentru a doua abordare:
            - toate cheile din BD sunt de acelasi tip - viteza in join-uri si consistenta;
            - join-uri limitate la un singur camp (in locul unei chei compuse);
            -necesarul de stocare este redus.

Dezavantajele folosirii Rational Rose pentru generarea de tabele din diagramele de clase:

• daca anumite atribute nu se genereaza (din cauza unor erori), atunci trebuie facuta adaugarea manual;
• nu se genereaza tabele de intersectie pentru asocieri n:m (doar daca este o clasa asociere);
• pentru doua clase A si B aflate intr-o asociere 1:n bidirectionala se genereaza 2 relatii distincte intre tabelele corespunzatoare claselor A si B
• nu suporta atribute tranzitorii (calcule, etc). Ele vor fi generate in tabele.

Ca urmare, se vor crea urmatoarele tipuri de obiecte (Tools/Oracle8/Object Type Creation Wizard):cate un obiect tip <<Relational Table>> pentru Persoana, Profesor, Student si cheile primare asociate

• cate un obiect tip <<Relational View>> pentru perechile Persoana-Profesor si Persoana-Student
• un obiect tip <<Relational Table>> pentru Curs optional, care va contine o cheie externa pentru legatura cu Profesori
• un obiect tip <<Relational Table>> pentru a descompune relatia m:n dintre Curs optional - Studenti (multi la multi) in doua relatii una la multi. Tabela de legatura se va numi CursStudent si va avea doua chei externe pentru legatura cu Studenti si Curs optional

Diagrama intermediara obtinuta va arata astfel:

Pe baza sa se va genera schema bazei de date intr-un fisier DDL cu extensia .sql,     meniul Tools/Oracle8/Schema Generation, care poate fi executata ulterior.

CREATE TABLE RAMONA.PERSOANE (

CNP FLOAT NOT NULL UNIQUE,

NUME VARCHAR2(30) NOT NULL,

ADRESA VARCHAR(50) NOT NULL,

STARECIV CHAR(10) NOT NULL,

SEX CHAR(1) NOT NULL,

DATANASTERII DATE,

CONSTRAINT CNPIDX PRIMARY KEY (CNP));

COMMENT ON TABLE RAMONA.PERSOANE IS 'tabela ce trebuie generata - parinte';

CREATE TABLE RAMONA.PROFESORI (

NORMA INT,

CATEDRA VARCHAR(30),

SALARIU FLOAT(10),

GRADDIDACTIC VARCHAR(20),

BIROU INT,

CNP INT NOT NULL UNIQUE,

CONSTRAINT NRLEGIDX PRIMARY KEY (CNP));

COMMENT ON TABLE RAMONA.PROFESORI IS 'tabela profesori - copil';

CREATE TABLE RAMONA.STUDENT (

CNP INT NOT NULL UNIQUE,

SERIE CHAR(1) NOT NULL,

AN INT NOT NULL,

GRUPA INT NOT NULL,

MEDIE FLOAT,

BURSA FLOAT,

TAXA CHAR(2) NOT NULL,

CONSTRAINT NRIDX PRIMARY KEY (CNP));

COMMENT ON TABLE RAMONA.STUDENT IS 'tabela student - copil';

CREATE OR REPLACE VIEW RAMONA.VPROFESOR (CNP, NUME, ADRESA, STARECIV, SEX, DATANASTERII, NORMA, CATEDRA, SALARIU, GRADDIDACTIC, BIROU) AS

SELECT PERSOANE.CNP, PERSOANE.NUME, PERSOANE.ADRESA, PERSOANE.STARECIV, PERSOANE.SEX, PERSOANE.DATANASTERII, PROFESORI.NORMA, PROFESORI.CATEDRA, PROFESORI.SALARIU, PROFESORI.GRADDIDACTIC, PROFESORI.BIROU

FROM RAMONA.PERSOANE, RAMONA.PROFESORI

WHERE student.CNP=persoana.cnp;

COMMENT ON TABLE RAMONA.VPROFESOR IS 'view pentru mostenire profesor- persoana';

CREATE TABLE RAMONA.CURSOPTIONAL (

DENUMIRE VARCHAR(30) NOT NULL,

CODCURS VARCHAR(5) NOT NULL UNIQUE,

DURATA INT,

LOCATIE VARCHAR(30),

NRLOCURI INT NOT NULL,

NRCREDITE INT NOT NULL,

CNP INT,

CONSTRAINT CODIDX PRIMARY KEY (CODCURS),

CONSTRAINT PROFFK FOREIGN KEY(CNP) REFERENCES RAMONA.PROFESORI(CNP));

COMMENT ON TABLE RAMONA.CURSOPTIONAL IS 'tabela';

CREATE TABLE RAMONA.CURSSTUDENT (

NR INT NOT NULL UNIQUE,

CODCURS VARCHAR(5),

CNP INT,

CONSTRAINT NRIDX PRIMARY KEY (NR),

CONSTRAINT CURS FOREIGN KEY(CODCURS) REFERENCES RAMONA.CURSOPTIONAL(CODCURS),

CONSTRAINT STUD FOREIGN KEY(CNP) REFERENCES RAMONA.STUDENT(CNP));

COMMENT ON TABLE RAMONA.CURSSTUDENT IS 'tabela de legatura pentru a transforma relatia m:n dintre curs si student';

CREATE    INDEX RAMONA.CODURIIDX ON RAMONA.CURSSTUDENT (CODCURS, CNP);

CREATE OR REPLACE VIEW RAMONA.VSTUDENT (CNP, NUME, ADRESA, STARECIV, SEX, DATANASTERII, SERIE, AN, GRUPA, BURSA) AS

SELECT PERSOANE.CNP, PERSOANE.NUME, PERSOANE.ADRESA, PERSOANE.STARECIV, PERSOANE.SEX, PERSOANE.DATANASTERII, STUDENT.SERIE, STUDENT.AN, STUDENT.GRUPA, STUDENT.BURSA

FROM RAMONA.PERSOANE, RAMONA.STUDENT

WHERE STUDENT.CNP=PERSOANA.CNP;

COMMENT ON TABLE RAMONA.VSTUDENT IS 'view pt legat stud persoana';