Prezentarea
produsului
Oracle Designer este un instrument de dezvoltare a aplicatiilor utilizat de catre analistii de sistem. Nu este un instrument pentru managementul proiectelor dar unele din facilitatile lui fac aceasta activitate mai simpla. Organizarea unitara si arborescenta a componentelor permite realizarea si modificarea rapida a sistemelor informatice, oferind in acelasi timp o imagine clara a interdependentelor dintre componente si a implicatiilor pe care le are o anumita modificare in cadrul aplicatiei.
Oracle Designer este integrat cu Oracle Developer/2000 si utilizeaza o configuratie client/server. Pe server exista un depozit central (Repository, un set de tabele si alte obiecte stocate in doua spatii tabel distincte ale bazei de date Oracle.) si o interfata API (Application Programmatic Interface) care consta din pachete PL/SQL si subprograme ce permit utilizatorilor sa manipuleze datele din Repository pentru a asigura integritatea datelor.
Repository stocheaza toate obiectele si informatiile necesare pentru proiectarea, modelarea si generarea bazelor de date si ale aplicatiilor cu baze de date. Pentru a exploata la maxim avantajele lucrului in echipa, informatiile din depozitul de date pot fi gestionate si controlate utilizind instrumentul Repository Management. Acesta permite realizarea urmatoarelor activitati:
· Instalarea sau actualizarea depozitului de date utilizind Repository Administration Utility (RAU). Se utilizeaza pentru a crea si gestiona Repository si pentru a controla accesul la el.
· Crearea si stocarea definitiilor obiectelor in Repository utilizind Repository Object Navigator (RON). Exista un administrator propriu pentru Oracle Designer numit Repos_Owner care foloseste acest instrument pentru a controla accesul la aplicatii.
· Crearea si prezentarea asocierilor intre obiecte utilizind Matrix Diagrammer (de exemplu matricea de corespondenta entitati functii utilizata si in metodologia SSADM-Structure System Analysis and Design Methodology).
· Afisarea informatiilor despre continutul depozitului de date utilizind Repository Reports. Se genereaza peste 100 de rapoarte folosind datele din Repository.
Pe client exista un set de instrumente (toolkit) ce consta dintr-o serie de diagrame, navigatoare, transformatoare, generatoare si utilitare ce ofera suport pentru fiecare etapa din proiectare a sistemelor informatice .
Pentru etapa de analiza a sistemelor informatice Oracle Designer pune la dispozitia analistilor urmatoarele instrumente:
· Pentru analiza statica (modelarea datelor) diagrama entitate asociere (Entity Relationship Diagrammer);
· Pentru analiza dinamica si functionala (modelul prelucrarii datelor) : diagrama de procese (Process Modeller), diagrama ierarhiei de functii (Function Hierarchy Diagrammer) si diagramele de flux de datelor (Dataflow Diagrammer);
Pentru etapa de proiectare a sistemelor informatice:
· Instrumente de transformare (Database Design Transformer, Application Design Transformer) care convertesc elementele obtinute cu instrumentele de analiza in elemente ale proiectarii (de exemplu definitiile entitatilor in definii de tabele, modelul entitate-asociere in schema conceptuala a bazei de date);
Pentru etapa de elaborare a programelor:
· Instrumente pentru generarea obiectelor bazei de date si a modulelor aplicatiei (Design Editor).
Oracle Designer ofera si un instrument de proiectare orientat obiect (Oracle Designer Object Extensions). Se poate utiliza limbajul standard de modelare orientat obiect UML (Unified Modeling Language). Se creeaza un model tip ( type model sau type diagram) ce contine tipuri de obiecte, atributele obiectelor, relatiile intre obiecte. Acest model se utilizeaza pentru a proiecta baza de date. Se creeaza un model server (server model sau server diagram) care poate fi modificat şi imbunatatit. Se poate genera baza de date fie folosind modelul tip (pentru sistemele informatice mici) sau modelul server care permite analistilor un control mai mare al etapei de proiectare. Oracle Designer Object Extensions include un generator C++ cu care se poate genera cod C++ ce permite accesul la obiectele din baza de date. Aceasta facilitate permite tranzitia de la sistemele relationale la cele orientat obiect si acces C++ la sistemele relationale.
Metodologia de proiectare a sistemelor informatice folosita de Oracle Designer este o metodologie proprie Oracle numita Custom Development Method (CDM) ce utilizeaza ca tehnici : diagramele de flux a datelor, tehnica entitate-asociere, matricile de corespondenta, etc.
Oracle Designer permite definirea si generarea urmatoarelor tipuri de baze de date :
· Oracle 8, 7.3, 7.2, 7.1, 7.0
· Personal Oracle Lite
· DB2
· Microsoft SQL Server
si a urmatoarelor tipuri de aplicatii:
· Videoformate si librarii pentru Developer/2000
· Aplicatii Visual Basic
· Aplicatii Web
· Fisiere MS Help care pot fi accesate de aplicatii construite cu Visual Basic si Form Builder.
O aplicatie construita cu Oracle Designer (application system) este o colectie de elemente corelate (definitii de functii, entitati, tabele) stocate in Repository. Fiecare aplicatie are setul propriu de utilizatori si privilegii ale utilizatorilor. O aplicatie poate folosi aceleasi definitii cu alte aplicatii.
Studiul si analiza sistemului existent are ca obiectiv principal stabilirea cerintelor informationale ale conducerii in vederea realizarii unui sistem informatic. Activitatile din cadrul acestei etape includ studiul sistemului existent, analiza si evaluarea sistemului existent si definirea directiilor de perfectionare ale actualului sistem. In Studiul sistemului existent consta in : definirea caracteristicilor generale ale sistemului economic, studiul activitatilor de baza desfasurate in sistem, studiul sistemului de conducere şi studiul sistemului informational.
In urma investigarii sistemului existent se obtin o serie de informatii. Evaluarea acestora se realizeaza prin activitatea de analiza. Aceasta se realizeaza sub trei aspecte:
· Analiza structurala evidentiaza modul de structurare a datelor si legaturilor dintre ele. In urma acestei analize se obtine modelul structural (static) al sistemului existent (modelul datelor).
· Analiza functionala evidentiaza modul de asigurare a cerintelor informationale respectiv a transformarilor de date (a tranzitiilor) din cadrul sistemului prin care sunt satisfacute cerintele informationale asociate domeniului economic (fluxul prelucrarilor din cadrul sistemului prin care intrarile sunt transformate in iesiri). Cea mai utilizata tehnica este diagrama de flux a datelor. Conform acestei tehnici se delimiteaza aria de cuprindere a sistemului informatic existent (granitele sistemului), se identifica sursele de date, modul de circulatie si prelucrare a lor si apoi rezultatele obtinute. Rezulta modelul functional (modelul prelucrarii datelor).
· Analiza dinamica evidentiaza comportamentul elementelor sistemului la anumite evenimente. Una din tehnicile utilizate este diagrama stare-tranzitie.
Modelarea proceselor este o tehnica de analiza ce identifica modul cum se desfasoara o activitate (afacere). Modelele de proces (diagramele de flux a proceselor) reprezinta un flux de activitati dintr-o organizatie si :
· furnizeaza o descriere naturala a modului cum se desfasoara activitatea modelata;
· descrie secventa de etape si inregistreaza evenimentele care rezulta sau initiaza aceste etape;
· stabileste cerintele informationale.
Daca sistemul informatic existent pe care-l descriem cu ajutorul modelului de procese este complex, va fi dificil sa se realizeze de la inceput un model detaliat. Pentru a putea descrie in detaliu sistemele complexe, metodologiile structurate (de exemplu SSADM, CDM etc) propun o abordare top-down, respectiv o descompunere functionala a sistemului care este realizata prin rafinarea succesiva a proceselor pina la nivel de proces atomic.
Primul nivel (nivelul 0 ) il constituie diagrama contextuala care defineste granitele intre sistemul analizat si mediu. Descompunerea modelului proceselor se poate considera terminata atunci cind se obtin procese atomice. In metodologia SSADM, asemanatoare cu cea folosita de Oracle Designer se considera ca un proces atomic este un proces care are o singura intrare si 1 sau mai multe iesiri sau o singura iesire si 1 sau mai multe intrari.
Conceptele de baza folosite in modelarea prelucrarii datelor sunt procesele si functiile, care sunt foarte similare iar in Repository sunt stocate ca acelasi tip de obiect.
· Procesele sunt etichetate cu text (verb) ce sugereaza modul de transformare a datelor. Se poate preciza si locatia (compartimentul/persoana) procesului.
· Functiile sistemului se refera la un set de procese (prelucrari) care din punct de vedere al utilizatorului se executa impreuna, in mod continuu de la inceput pina la sfarsit. Majoritatea functiilor sunt asociate optiunilor din meniul aplicatiei dar exista si functii care se executa off-line (ce nu apar explicit in meniu). Functiile sunt identificate in diagrama ierarhiei de functii (Function Hierarchy Diagrammer), fiecare proces atomic fiind alocat cel putin unei functii.
Elementele componente ale unui model de procese sunt:
· Unitatea organizationala (organization unit) este partea responsabila cu activitatea (procesul). Toate procesele dintr-un model apartin unei unitati organizationale. Deci unitatea organizationala reprezinta agentul caruia ii apartine activitatea modelata. Poate fi intreaga organizatie, o unitate functionala (departament), un rol (angajat), o entitate externa pentru o organizatie (client, furnizor). O unitate organizationala se poate descompune in subdiviziuni sau roluri, cunoscute ca child organization unit (unitate organizationala copil).
Suprafata orizontala asociata cu o unitate organizationala se numeste swim lane sau agent channel. Daca nu se cunoaste ce agent se ocupa cu o activitate se foloseste Unspecified Swim lane. Exemplu de unitati organizationale : Contabilitate, Vanzari, Expeditie, Director, Agent, etc.
· Procesul atomic (process step) reprezinta o sarcina, o activitate sau o functie care apare la un moment dat in procesul modelat. O diagrama reprezinta un singur proces numit proces de baza (base proces). Procesele atomice sunt reprezentate in suprafata corespunzatoare unitatii organizationale (swim lane). In figura 5.1. sunt prezentate tipuri de procese.
· Evenimentele initiaza un proces/flux (trigger) sau rezulta de la un proces/flux (outcome). Un trigger apare intotdeauna inaintea procesului atomic cu care este asociat, un outcome (rezultat) apare intotdeauna dupa procesul atomic (figura 5.2).
· Fluxul de date (flow) este constituit din datele transmise intre doua procese. Fluxul de date este etichetat printr-un substantiv ce sugereaza informatia sau pachetul de informatii transmise. Fluxurile sunt folosite in principal pentru a arata ordinea in care procesele atomice sunt executate.
· Stoc de date (store) reprezinta colectiile, depozitele informationale sau materiale folosite in cadrul procesului modelat.
Instrumentul Process Modeller are trei moduri de vizualizare :
· Symbol
Nu exista nici o distinctie intre tipurile de proces, toate apar rectangulare.
· Enhance symbol
Procesele atomice apar diferite dupa tipul lor.
· Icon
Procesele atomice apar ca o icoana (se poate selecta o icoana din fereastra de dialog Edit process, optiunea Multimedia)
Modelarea proceselor cuprinde urmatoarele etape:
· Identificarea unitatilor organizationale;
· Identificarea proceselor atomice pentru fiecare unitate organizationala. Se poate specifica tipul procesului atomic;
· Identificarea triggerilor si a rezultatelor;
· Crearea fluxurilor de date;
· Validarea modelului de catre utilizatori.
Modelul se poate modifica. Se pot adauga noi obiecte sau se pot sterge. Stergerea unui obiect dintr-un model se poate face in doua moduri:
· Cut sterge reprezentarea obiectului din diagrama dar definitia lui ramine in Repository
· Delete from repository sterge reprezentarea obiectului din diagrama si definitia din Repository
SINTEZA:
· Se conecteaza la Designer/2000.
Fiecare utilizator are un cont si o parola. Pentru a crea o aplicatie utilizatorul trebuie sa aiba drepturi de manager.
· Se creeaza o aplicatie (de exemplu Aplicatie) si se apasa butonul Create apoi OK.
Etapa 2. Crearea unui
model de procese
2.1 Crearea unei diagrame la nivel inalt (nivelul 0 sau diagrama contextuala)
· Click pe instrumentul Process modeller.
· Se creeaza o noua diagrama prin selectarea optiunii File/New din meniul principal.
· Se poate utiliza un proces radacina existent sau se creeaza un nou proces radacina prin selectarea optiunii Create New Root Process.
· Se tasteaza definitia scurta a procesului radacina in fereastra de dialog Create Process Step (de exemplu Desfacere) si un nume scurt pentru procesul radacina in cimpul Label (de exemplu DESF).
2.2 Crearea unei unitati organizationale
· Click pe butonul Organization unit din bara de butoane (toolbar) (de exemplu Magazin, Livrari).
· Click in unitatea organizationala nespecificata (acolo unde scrie Unspecified).
· Se tasteaza numele unitatii organizationale si numele scurt, apoi se apasa butonul OK. Pentru a crea o unitate organizationala copil click in unitatea organizationala parinte si nu in zona Unspecified. Copilul este pozitionat sub parinte.
2.3 Crearea unui proces atomic (pas de proces)
· Click pe butonul Process din bara de butoane.
· Click in suprafata unde se pozitioneaza procesul
· Se introduce o definitie scurta in fereastra de dialog Create Process Step si o eticheta ( de exemplu Vinzare in magazin propriu si eticheta Vinzare).
· Se specifica tipul procesului daca este necesar si apoi se apasa butonul OK.
2.4 Crearea unui flux
· Click pe butonul de flux.
· Click pe procesul de unde incepe fluxul.
· Se trage pina la procesul unde se termina fluxul.
· Se introduce numele fluxului in fereastra de dialog Create Flow. Fluxul nu trebuie sa aiba obligatoriu un nume.
2.5 Descompunerea diagramei nivel 0 (rafinarea modelului de procese)
· Se selecteaza procesul care se va descompune.
· Se alege optiunea File/Open Down. Oracle Designer deschide o noua diagrama pentru procesul selectat. Se pot crea sau include elementele necesare pentru a modela procesul respectiv in detaliu.
2.6 Utilizarea unei unitati organizationale existente
· Se selecteaza optiunea Edit/Include si se alege unitatea organizationala din lista, pe care dorim sa o includem in diagrama.
2.7 Crearea unui trigger
· Click pe butonul Create trigger.
· Click pe procesul cu care este asociat triggerul.
· Se introduce numele triggerului.
2.8 Crearea unui eveniment rezultat
· Click pe butonul Create Outcome.
· Click pe procesul cu care este asociat evenimentul rezultat.
· Se introduce numele evenimentului rezultat.
2.9 Marirea suprafetei (swim lane)
· Se selecteaza unitatea organizationala care este asociata cu suprafata pe care dorim sa o marim.
· Se tine apasata tasta SHIFT si se apasa tasta Down Arrow pina cind suprafata ajunge la dimensiunea dorita.
2.10 Imbunatatirea diagramei
· Pentru a schimba culoarea unei unitati organizationale se selecteaza unitatea si se alege butonul Change Fill Color pentru a selecta culoarea dorita.
· Pentru a utiliza aceleasi culoare pentru suprafata, cu mouse-ul pe suprafata, click pe butonul dreapta al mouse-ului. Se alege din meniu optiunea Customize Graphics. Se verifica boxul Use Organization Fill Color si apoi se selecteaza butonul Save sau OK
Analiza structurala are ca obiectiv evidentierea componentelor (obiectelor) din cadrul sistemului pentru care urmeaza sa se colecteze si sa se memoreze date in cadrul bazei de date precum si evidentierea legaturilor dintre aceste componente.
Se cunosc mai multe tehnici de analiza structurala dar cea mai cunoscuta si mai folosita (in cazul sistemelor tranzactionale) este tehnica entitate asociere propusa de Chen in 1976.
Modelarea entitate asociere este o tehnica de proiectare logica ce cauta sa elimine redundanta datelor. Astfel tranzactiile devin foarte simple si deterministe. Se pot face o serie de observatii daca privim un model entitate asociere:
· Modelul este foarte simetric. Toate entitatile arata la fel. Nu se poate stabili care entitate este mai importanta sau care este mai mare.
· Modelele complexe (la nivel de intreprindere) sunt greu de urmarit si greu de inteles de catre utilizatorii finali.
· Eficientizarea procesului tranzactional a adus la crearea unor baze de date ce nu pot fi interogate sau sunt foarte greu de interogat. Modelul entitate asociere pentru intreprindere are sute de entitati logice si de legaturi intre acestea. Fiecare din aceste entitati, in general, apare ca o tabela, la proiectarea unei baze de date relationale. Nu se poate interoga cu usurinta un astfel de model.
· Nu modeleaza real activitatea ci mai exact relatiile micro intre elementele componente.
· Modelul este foarte variabil ca structura si vulnerabil la modificarile cerintelor utilizatorilor.
· Este un model bottom-up.
· Ofera suport optim pentru sistemele informatice tranzactionale.
· Vizualizeaza datele pe o singura dimensiune.
· Modificarea modelului presupune si modificarea aplicatiei.
· Elimina redundanta.
Etapele tehnicii
entitate asociere sunt:
1. Identificarea componentelor (entitatilor) din cadrul sistemului economic existent.
Elementele de baza ale diagramei entitate asociere sunt: entitatile, relatiile si atributele.
Entitatea este un obiect concret sau abstract important in activitatea modelata, reprezentat prin propietatile sale. De exemplu pentru activitatea de desfacere dintr-o firma putem pune in evidenta urmatoarele entitati :Comenzi, Clienti, Facturi, Furnizori, Livrari, Produse. Fiecare entitate prezinta mai multe instante (realizari). De exemplu organizatia are mai multi clienti, mai multi furnizori. Clientul Metro este o instanta a entitatii Clienti. In modelarea entitate asociere fiecare entitate are un nume (un substantiv ce reprezinta semnificatia acelei entitati). Criteriul dupa care se alege numele unei entitati depinde de caracteristicile si scopul entitatii.
2.
Identificarea
asocierilor dintre entitati si calificarea acestora.
In cadrul sistemului analizat, entitatile nu apar decat rareori izolate, intre ele se stabilesc legaturi (asocieri). De exemplu intre entitatile Comenzi si Clienti exista o asociere, in sensul ca clientii emit comenzi. O relatie semnifica asocierea intre doua entitati si se exprima prin numele relatiei (o comanda este pentru un client sau un client este initiatorul unei comenzi), gradul unei relatii (numarul maxim de instante ale unei entitati ce pot corespunde la o instanta a entitatii asociata) si obligativitatea participarii entitatilor la asociere (numarul minim de instante ale unei entitati ce corespunde la o instanta a entitatii asociate).
De exemplu fiecare comanda trebuie sa fie pentru un client si numai unul si fiecare client poate fi initiatorul uneia sau mai multor comenzi.(figura 5.3).
Semnificatia asocierii este exprimata printr-un verb (de exemplu “apartine”, “are”) plasat la capetele asocierii.
Tipul asocierii se exprima cu ajutorul cardinalitatii care exprima numarul minim si numarul maxim de realizari (instante) ale unei entitati care pot fi asociate cu o realizare (instanta) a entitatii asociate. Maximul cardinalitatii semnifica gradul asocierii.
Dupa gradul de asociere, asocierile pot fi de tip: (1:1), (1:m), (m:n) (figura 4).
Intr-un model entitate asociere normalizat, orice asociere (m:n) este inlocuita cu o entitate de legatura ce transforma asocierea (m:n) in doua asocieri (1:m).
Dupa obligativitaea participarii entitatilor la
asociere, asocierile se clasifica in asocieri partiale (reprezentate prin
linie intrerupta si exprimate prin verbul “poate fi”) si asocieri totale
(reprezentate prin linie continua si exprimate prin verbul “trebuie sa fie”).
De exemplu in figura 3 fiecare comanda trebuie sa fie (must be) emisa de un
client si numai unul iar fiecare client poate (may be) emite una sau mai
multe comenzi.
Asocierile partiale apar atunci cind nu exista obligativitatea participarii la aceasta asociere a tuturor entitatilor vizate ci numai a unora dintre ele sau a nici uneia. Obligativitatea participarii entitatilor la asociere este reflectata de catre minimele cardinalitatii. Valoarea zero a uneia dintre minime exprima lipsa de obligativitate a participarii partenerului la aceasta asociere. Asocierile totale apar atunci cind este obligatorie participarea tuturor entitatilor la asociere (minimele cardinalitatii are valori >0).
Dupa numarul de entitati participante la asociere, asocierile pot fi:
· Asocieri binare reprezinta asocieri intre doua entitati distincte.
· Asocieri recursive reprezinta asocieri ale entitatilor cu ele insele. De exemplu asocierea intre persoane prin casatorie este recursiva de tip 1:1 si partiala .
· Asocieri complexe reprezinta asocieri intre mai mult de doua entitati distincte.
3. Identificarea atributelor aferente
entitatilor si asocierilor dintre entitati
Atributele descriu caracteristicile, propietatile componentelor sistemului economic analizat. Prin intermediul atributelor se pot descrie nu numai entitatile ci si asocierile intre entitati. De exemplu cod_produs, descriere, unitate_de_masura, pret_unitar , stoc sunt atribute ale entitatii Produse. Numele unui atribut trebuie sa fie unic pentru o entitate si semnificativ. De exemplu nu se pot defini atributele data1 si data2. Trebuie precizat clar ce inseamna fiecare atribut (de exemplu data livrarii sau data incheierii comenzii).
Exista mai multe tipuri de atribute:
· Atribut simplu este un atribut care nu este nici compus si nici calculat. Valorile sale sunt atomice (de exemplu stoc).
· Atribut compus constituit din cel putin doua atribute simple (de exemplu adresa)
· Atribut calculat (derivat) este un atribut a carui valoare este calculata pe baza valorilor altor atribute (de exemplu valoare=cantitate*pret)
Un atributul poate fi :
- optional (o) daca nu cere intotdeauna o valoare (accepta valori nule).
- obligatoriu (*) daca o valoare trebuie specificata pentru atribut (nu accepta valori nule). Atributele care formeaza identificatorul unic al unei entitati trebuie sa fie obligatorii.
In concluzie pentru fiecare atribut se va specifica : numele, daca este optional/obligatoriu, formatul de data, lungimea maxima.
Un alt concept folosit in modelarea entitate asociere este domeniu. Un domeniu consta din toate valorile posibile ce sunt permise pentru un atribut. Formatul sau tipul de data (intreg, caracter, etc) ofera o definitie clara a domeniului. Definirea domeniului este importanta pentru proiectarea bazei de date.
De asemenea un domeniu este un set de reguli de validare, propietati si valori ce se aplica la un grup de atribute:
- Domeniu ce asigura consistenta datelor (de exemplu format = char, max att length = 80).
- Domeniu ce specifica valori (zilele dintr-o saptamina, unitatile de masura)(de exemplu tip produs: pager, telefon celular; starea comenzii: livrata, partial livrata, anulata).
Dupa definirea unui domeniu, acesta se poate asocia la mai multe atribute.
4.
Stabilirea
atributelor de identificare a entitatilor
Un atribut de identificare (cheie) reprezinta un atribut care se caracterizeaza prin unicitatea valorii sale pentru fiecare instanta a entitatii (de exemplu cod_produs pentru entitatea Produse)
Este necesar sa se examineze mai intii potentialitatea fiecarui atribut de a se constitui drept cheie. Un atribut cheie satisface o serie de cerinte:
· Ofera o identificare unica a realizarilor de entitate;
· Poseda o semnificatie;
· Este usor de utilizat;
· Este scurt (de cele mai multe ori, atributul de identificare al entitatii apare si in alte entitati, drept cheie externa). Pe de alta parte, indecsii pentru accesul direct la date se construiesc cel mai adesea pe atributele cheie, cheile lungi determina scaderea eficientei accesului la date.
Selectarea unuia dintre candidatii cheie drept atribut de identificare a entitatii se realizeaza astfel:
· Se determina atributele care potential pot constitui atribute de identificare a entitatii, care respecta cerintele de mai sus si care se numesc candidati cheie. Daca nu exista astfel de atribute se introduce un nou atribut (grup de atribute) drept candidat cheie.
· Daca exista un singur candidat cheie, se va selecta acesta drept cheie.
· Daca exista mai multi candidati cheie, se selecteaza unul tinind cont de urmatoarele observatii:
- se prefera atributele ale caror valori sunt mai putin volatile;
- se prefera atributele ale caror valori sunt mai scurte.
Pentru fiecare entitate se stabileste atributul de identificare unic (UID) care apare precedat de (#) (figura 5).
Dificultatea realizarii unei corecte analize structurale provine in primul rind din faptul ca asocierile dintre entitati poseda propietatea de tranzitivitate, ceea ce face ca intre entitati sa se manifeste nu numai legaturi directe ci si legaturi indirecte (figura 6)
Intre entitatile Firma si Compartiment respectiv intre Compartiment si Angajati exista asocieri directe. Intre entitatile Firma si Angajati exista si o legatura indirecta. Uneori se prefera evidentierea legaturii intre Firme si Angajati si sub forma unei asocieri directe care este redundanta atunci cind pentru asigurarea unei corecte legaturi intre Firme si Angajati nu este suficienta asocierea indirecta.
Nu se recomanda includerea de legaturi redundante in modelul entitate asociere intrucit se complica modelul. De exemplu asocierea dintre entitatile Firma si Angajati poate fi asigurata prin intermediul asocierilor dintre Firma si Compartiment si Compartiment si Angajati (figura 6.a). Aceste asocieri permit determinarea angajatilor unei anumite firme precum si firma in care lucreaza un anumit angajat.
Exista totusi situatii in care asocierea directa intre doua entitati nu este redundanta. Aceste situatii apar atunci cind asocierile directe nu sunt plasate intr-o succesiune sau nu sunt definite intr-un mod care sa permita functionarea corespunzatoare a asocierii indirecte (figura 6.b). Nu se pot determina angajatii care lucreaza intr-un anumit compartiment sau compartimentul de care apartine un angajat numai prin asocierile directe dintre Compartiment si Firma, Firma si Angajati.
Exemplu prezentat evidentiaza importanta unei corecte inlantuiri a asocierilor directe dintre entitati care sa duca la obtinerea unor asocieri indirecte posibil de utilizat in mod eficient si care sa permita simplificarea modelului entitate asociere prin reducerea numarului de asocieri evidentiate explicit.
O alta dificultate care apare in identificarea si calificarea asocierilor dintre entitati consta in posibilitatea caracterizarii aceleasi asocieri in mai multe moduri. De exemplu asocierea dintre entitatile Angajati si Copii poate fi o asociere partiala de tip (m:n) (un copil trebuie sa aiba unul sau mai multi parinti si un angajat poate avea 0 sau mai multi copii) sau o asociere partiala de tip (2:m) ( un copil trebuie sa aiba minim un parinte si maxim doi, un angajat poate avea 0 copii sau mai multi).
SINTEZA:
· Click pe icoana Entity Relationship Diagrammer.
· Se creeaza o noua diagrama prin selectarea optiunii File/New din meniul principal.
3.1 Crearea unei entitati
· Click pe butonul Entity.
· Click pe diagrama.
· Se introduce numele entitatii, numele scurt si numele la plural in fereastra de dialog Create Entity. Se selecteaza OK.
3.2 Crearea unei relatii
· Se alege tipul relatiei.
· Click pe entitatea din stinga relatiei, apoi pe entitatea asociata.
· Se introduce numele (From name si To name) in fereastra de dialog Create relationship .
Etapa 4 Rafinarea diagramei entitate asociere
Rafinarea diagramei presupune crearea domeniilor, atributelor, valorilor permise si a identificatorilor unici. Pentru domenii se defineste formatul, lungimea maxima a atributelor si valorile permise.
Se pot crea si modifica atributele entitatilor din diagrama folosind fereastra de dialog Edit Entity. Optiunea Atributes permite crearea, vizualizarea si modificarea mai multor atribute la un moment dat iar optiunea AttDetail afiseaza detalii despre un singur atribut (se foloseste cind dorim sa vizualizam propietatile unui atribut).
4.1 Definirea unui domeniu
· Se alege optiunea Edit/Domains din meniul principal.
· Se foloseste optiunea Definition pentru a specifica numele domeniului.
· Se foloseste optiunea Definition sau Detail pentru a specifica formatul si lungimea maxima.
· Se foloseste optiunea Values pentru a specifica valorile pentru domeniu si semnificatia lor.
De exemplu :
Entitatea Client contine date despre clientii firmei si are urmatoarele atribute:
· Cod client (#), n(7)
· Denumire client (*), varchar2(25)
· Adresa (*), varchar2(55)
· Telefon (*), n(10)
· Cod fiscal (*), n(10)
· Cont bancar (*), n(15)
· Banca (*), varchar2(25)
Entitatea Comanda contine date din antetul comenzii :
· Nr comanda (#), n(7)
· stare(*), varchar2(1)
· data emiterii (*), d
Entitatea Rindcomanda contine informatii despre fiecare produs din
comanda:
· cantitatea comandata (*), n(5)
· termen livrare (*), d
Entitatea Produs contine date despre produsele fabricate in societate:
· cod produs (#) , n(5)
· denumire produs (*), varchar2(25)
· unitate de masura (*), c(3)
· pret unitar (*), n(9)
· stoc (*), n(5)
Domenii:
· stare comanda (livrata-l, nelivrata-n,partial livrata-p, anulata-o),
Lungime maxima (maxlength) =1
tip data (data type) : varchar2
valori (values): L,N,P,O
· Tip de unitate de masura
maxlength=3
datatype varchar2
values : Buc, Kg, m
4.2 Adaugarea atributelor la o entitate
· Dublu click pe entitatea, din diagrama, pentru care se creeaza atribute.
· Click pe optiunea Attribute din fereastra de dialog Edit Entity.
· Pentru fiecare atribut ce nu are un domeniu, se specifica numele, formatul si lungimea maxima.
· Pentru fiecare atribut ce are un domeniu se specifica numele. Apoi se selecteaza domeniul din lista asociata cu propietatea Domain.
· Pentru a specifica ca un atribut este cheie primara a entitatii :
-
Se trece pe (off) propietatea Optional.
-
Se trece pe (on) propietatea Primary.
· Se salveaza diagrama selectind optiunea File/Save din meniul principal (de exemplu ERD1)