|
|
|
Analiza sistemului de realizat in Oracle Designer
Etapa de analiza are ca scop definirea cerintelor pentru noul sistem. Aceasta presupune atat identificarea cerintelor functionale, cat si definirea necesarului de date. De obicei, cerintele sunt specificate prin intermediul modelelor. De obicei, tehnicile folosite depind de metoda selectata pentru realizarea sistemului. Metoda oficiala Oracle este Custom Development Method, iar tehnicile recomandate de aceasta pentru etapa de analiza sunt:
Culegerea de informatii
Modelarea asocierilor intre entitati
Modelarea proceselor
Modelarea functiilor
Modelarea evenimentelor
Diagramele tip matrice
Modelul proceselor, numit si diagrama de flux a proceselor, reprezinta fluxul activitatilor din cadrul unei organizatii. Componentele de baza ale unui model de procese sunt:
unitatile organizatorice,
procesul atomic,
evenimentele,
fluxurile, depozitele
1 Diagrama proceselor
Diagrama proceselor pentru clinica Medcor este prezentata mai jos:
Fig. 1 Diagrama proceselor - Gestiunea Clinicii Medicale
Fig. 2 Diagrama proceselor - Gestiunea Cererilor
Fig. 3 Diagrama proceselor - Gestiunea Ofertelor
Fig. 4 - Diagrama proceselor -Gestiunea Contractelor
"Clinica Medicala" din diagramele prezentate anterior reprezinta unitatea organizatorica , adica este partea sau agentul care realizeaza sau caruia ii apartine activitatea reprezentata de un proces.
Un proces (in diagrama Gestiunea contarctelor reprezentat de "Stabilire servicii prestate de clinica","Stabilire oferte" etc. )este un grup de actiuni realizate asupra datelor, astfel incat acestea sunt distribuite, transformate sau stocate..
Un flux este folosit in principal pentru a arata ordinea in care au loc procesele(reprezentat de sageti in diagrama);
Evenimentul care declanseaza un proces sau un flux se numeste trigger, si va aparea intotdeauna inaintea (in stanga) procesului respectiv(ex. In diagama prezenata anterior:trigger-ul"semestru nou");
Depozitul (in diagrama prezenatta anterior:"Date firme', "Profile Firma", etc)reprezinta o colectie de informatii sau materiale. Un depozit are de obicei unul sau mai multe fluxuri de intrare si de obicei cel putin unul de iesire, altfel acesta pare sa nu fie folosit.
La fel ca diagrama de procese, diagrama de flux de date e o reprezentare grafica orientata pe procese a sistemului de aplicatie. Aceasta descrie modul de circulatie a datelor intre entitati externe, procese si stocuri de date.
Componentele unei diagrame de flux de date sunt:
Exista o corespondenta intre obiectele din diagrama de flux de date si diagrama de procese:
Mai jos prezentate diagramele de flux de date corespunzatoare:
Fig. 5 - DFD -Gestiunea Clinicii Medicale
Fig. 6 - DFD - Gestiunea Cererilor
Fig. 7 - DFD - Gestiunea ofertelor
Modelarea datelor este un aspect important in intelegerea cerintelor sistemului. In acest scop Oracle Designer foloseste instrumentul Entity-Relationship Diagrammer (invocat prin selectarea iconitei corespunzatoare), cu ajutorul caruia este introdus modelul entitatilor in depozitul de date. Modelarea entitate-asociere este o tehnica de proiectare logica care urmareste eliminarea redundantei datelor.
Componentele de baza ale unei diagrame entitate-asociere sunt:
O entitate reprezinta un element semnificativ, real sau imaginar, despre care sunt necesare informatii. Se creeaza dand click pe butonul Create Entity din bara de instrumente, apoi pe spatiul diagramei. Se va completa numele entitatii, un nume scurt si o forma de plural (care altfel este generata automat, prin adaugarea terminatiei '-s').
O asociere este o cale semnificativa in care doua lucruri de acelasi fel sau diferite pot fi asociate. O relatie reprezinta o asociere intre doua entitati. La fiecare capat al relatiei, aceasta are un nume care permite intelegerea cu usurinta a relatiei respective.
Gradul relatiei arata cate instante pot exista la un capat al relatiei pentru fiecare instanta de la capatul celalalt (una si doar una/ una sau mai multe). Optionalitatea relatiei arata numarul minim de instante care pot exista la un capat al relatiei pentru fiecare instanta de la celalalt capat. O linie punctata semnifica o relatie optionala, iar o linie continua semnifica o relatie obligatorie la capatul respectiv.
Crearea unei relatii presupune existenta celor doua entitati pe care le asociaza. Se va da click pe unul dintre cele noua butoane care corespunde tipului dorit de relatie, click pe prima entitate si apoi click pe a doua entitate. Se vor completa numele pentru capetele relatiei: From Name se refera la prima entitate selectata, To Name se refera la a doua entitate.
Un atribut este o informatie care realizeaza o calificare, identificarea, clasificare, cuantificare sau exprima starea unei entitati. Crearea si editarea atributelor se realizeaza din fereastra de dialog Edit Entity care se deshide daca se da dublu click pe entitatea respectiva.
Fiecare atribut este caracterizat prin nume, tip, dimensiune si optionalitate. Numele unui atribut trebuie sa fie unic pentru o entitate. Atributul poate fi obligatoriu sau optional, implicit el fiind optional; el trebuie sa aiba un anumit format sau tip. Toate atributele cu exceptia celor de tip data calendaristica trebuie sa aiba o lungime maxima, pentru cele de tip numeric fiind posibila si precizarea numarului de zecimale.
Fig. 9 - Diagrama entitate-asociere
Complementara modelarii proceselor, modelarea functiilor este o parte importanta pentru specificarea cerintelor sistemului. Instrumentul folosit in acest scop se numeste Function Hierarchy Diagrammer, invocat prin selectarea iconitei corespunzatoare din Oracle Designer. Atat un proces atomic, cat si o functie reprezinta activitati realizate de intreprindere, asadar doua perspective diferite asupra aceluiasi obiect. Oracle Designer nu face diferenta intre acestea, procesele atomice create cu Process Modeler fiind memorate in depozitul de date ca functii. Pe baza acestora, Process Modeler creeaza automat o ierarhie de functii implicita.
Diagrama ierarhiei de functii reprezinta cerintele functionale ale sistemului si gruparea acestora. Aceasta sta la baza proiectarii aplicatiei si e folosita pentru a delimita ceea ce va fi automatizat.
Functiile pot fi de mai multe tipuri:
Diagrama Gestiunea Clinicii Medicale contine :
functia root : Gestiunea Clinicii Medicale;
functiile intermediare :
Gestiune cereri
Gestiune oferte
Gestiune contracte
Fig. 12 - Gestiunea Clinicii Medicale
Fig. 13 - Gestiunea ofertelor
Fig. 14 -Gestiunea cererilor
Matricea CRUD este folosita pentru a realiza o verificare a concordantei intre modelul datelor si cel al functiilor. Fiecare entitate are un ciclu de viata: creare, consultare, actualizare, stergere sau arhivare. Matricea pune in evidenta efectul functiei asupra entitatii, dar poate fi folosita si pentru adaugarea sau amendarea utilizarii acestora. Instrumentul folosit pentru construirea matricii se numeste Matrix Diagrammer.
Analiza matricei CRUD poate sa puna in evidenta doua situatii nedorite:
-Entitati care sunt utilizate, dar nu au fost create. In acest caz trebuie determinata functia care realizeaza crearea entitatii respective si modificata utilizarea corespunzatoare prin adaugarea actiunii Create la intersectia dintre functia si entitatea in cauza. In cazul in care este necesara creearea unei noi functii pentru crearea entitatii analizate, se va modifica diagrama de procese si diagrama ierarhiei de functii pentru a reflecta modificarea operata.
-Entitati care au fost create, dar nu sunt utilizate. Analizandu-se entitatea respectiva se va decide daca ea este utila sau nu, iar daca raspunsul e negativ, ea va fi eliminata din sistem (inclusiv din diagrama entitate-asociere).
Inainte de a se face trecerea la faza de proiectare trebuie verificate calitatea, acuratetea si completitudinea modelelor dezvoltate in faza de analiza.
"Statement of Requirement " este rezultatul cel mai important obtinut in faza de analiza, asupra caruia trebuie sa cada de acord manageri superiori inainte de trecerea la faza de proiectare. In acest scop au fost dezvoltate modelele prezentate pana acum: modelul proceselor, modelul datelor si modelul functiilor.
Modelul de date si de functii trebuie sa fie complementare: modelul datelor trebuie sa contina datele necesare functiilor si functionalitatea trebuie sa existe pentru a crea si intretine datele. Pentru a avea confirmarea acestei concordante se foloseste instrumentul Matrix Diagrammer.
Verificarea calitatii datelor are in vedere urmatoarele aspecte:
Toate entitatile trebuie sa aiba definit un set complet de atribute.
Fiecare entitate trebuie sa participe in cel putin o relatie.
Fiecare instanta a unei entitati trebuie sa poata fi identificata in mod unic. Daca nu se specifica un atribut de identificare, la invocarea instrumentului Database Transformer se poate crea o cheie surogat.
Fiecare entitate trebuie sa aiba o descriere, astfel incat sa se inteleaga ce reprezinta entitatea respectiva.
Fiecare entitate trebuie sa fie folosita de cel putin o functie.
Pentru fiecare atribut trebuie specificate cel putin formatul, lungimea si optionalitatea.
Fiecare relatie trebuie sa fie valida si sa aiba clar specificate gradul si optionalitatea.
Diagrama entitate-asociere este o reprezentare conceptuala, independenta a informatiilor necesare aplicatiei, dar entitatile nu pot fi implementate direct intr-o baza de date. Inainte de generarea bazei de date acest model trebuie transformat in schema conceptuala a bazei de date. In acest scop este folosit instrumentul Database Design Transformer in urma aplicarii caruia se obtin o serie de definitii care trebuie implementate pentru a crea o baza de date.
Principalele componente ale modelului rezultat in urma transformarii sunt definitiile tabelelor, care reprezinta unitatile de depozitare a datelor intr-o baza de date relationala. Ele contin definitiile coloanelor. Fiecare definitie de coloana este alcatuita din tipul de date corespunzator (VARCHAR, NUMBER, DATE etc), optionalitatea, eventual domeniul asociat. Regulile de transformare a entitatilor in tabele sunt simple si pot fi automatizate.
Transformarea entitatilor
-Fiecare entitate se transforma intr-o tabela in modelul conceptual. Pluralul numelui entitatii devine numele tabelei, de exemplu pentru entitatea COMANDA se va crea tabela COMENZI.
-Fiecare atribut devine o coloana in modelul conceptual. Numele atributului devine numele coloanei, iar proprietatile atributului sunt transferate coloanei. Astfel, atributele obligatory devin coloane cu restrictia NOT NULL, iar un atribut tip Video devine coloana tip Long Raw.
Atat in cazul atributelor, cat si al entitatilor, daca numele contin spatii, acestea sunt inlocuite cu caracterul "_ underscore).
Atributul de identificare al entitatii devine cheia primara a tabelei, iar restrictia asociata va avea numele <nume scurt entitate>_PK.
-Fiecare relatie se transforma in doua obiecte:
- coloana cheie externa care corespunde cheii primare a tabelei la care se refera. Aceasta va mosteni tipul si dimensiunea de la cheia la care se refera. Optionalitatea coloanei este in functie de tipul relatiei: obligatorie sau optionala. Numele acestei coloane se obtine astfel: <nume scurt entitate>_<nume coloana>.
- o restrictie de cheie externa care este asociata coloanei cheie externa, al carei nume va fi: <nume scurt entitate de la>_<nume scurt entitate la>_FK.
Asemanatoare cu diagrama entitate-asociere, modelul server contine tabelele si legaturile lor pe baza cheilor externe. Cheile externe apar sub forma de asocieri unu la multi intre tabele, iar daca cheia externa este obligatorie, asocierea e simbolizata prin linie continua, daca este optionala, prin linie punctata.
Elementele incluse intr-o astfel de diagrama sunt: tabele, coloanele tabelelor cu optionalitate si format, cheile primare si externe.
Fig. 24 - Modelul server - Tabele, Atribute, Chei, Indecsi
In momentul incheierii proiectarii logice trebuie definite urmatoarele tipuri de obiecte:
Fig. 26 - Modelul server - View, Cluster, Trigger
View-uri
1. Pentru pachetele de servicii ce contin servicii de consultare ;
2. Pentru contracte cu clienti din Bucuresti ;
Cluster-ul Cereri_Contracte
- optimizare nivel fizic ( se salveaza o singura data caraterele comune);
Triggeri
1. Trigger Actualizare pret pe view-ul Servicii_Consultare_V
La modificarea pretului din view se genereaza modificarea pretului din tabelele Servicii, respectiv Pachete_Servicii.
BEGIN
if updating ('SERV_PRET') then
update SERVICII
set PRET =:new.SERV_PRET
where SERV_ID_SERV=:old.SERV_ID_SERV;
update PACHETE_SERVICII
set PRET = PRET + (:new.SERV_PRET-:old.SERV_PRET)
where PACHET_ID_PACHET=:old.PACHET_ID_PACHET;
END IF;
END;
2. Trigger Generare_id_client pe tabela Clienti
Asigura unicitatea codului id_client folosind valorile generate de secventa client_id_seq.
BEGIN
SELECT CLIENT_ID_SEQ.nextval INTO :new.ID_CLIENT FROM dual;
END;
1. Oracle Help
2. Militaru Gh. - "Sisteme Informatice pentru management", Editura All, 2003
