Modelarea bazelor de date utilizand ORM

Se stie ca un sistem informational cuprinde totalitatea resurselor care permit colectarea, administrarea, controlul si propagarea informatiilor in intreaga organizatie. Atunci cand prelucrarea se efectueaza prin intermediul calculatoarelor, acest sistem va cuprinde urmatoarele componente:

baza de date;

elementele software ale bazei de date;

software de aplicatie;

elementele hardware ale calculatorului;

personalul care utilizeaza si dezvolta sistemul.

Dintre acestea baza de date constituie componenta fundamentala a sistemului informational, iar dezvoltarea si utilizarea sa trebuie privite din perspectiva cerintelor mai largi ale organizatiei. Prin urmare, ciclul de viata al unui sistem informational al unei organizatii este inerent legat de ciclul de viata al sistemului de baze de date care il sustine, si de asemenea, ciclul de viata al aplicatiei de tip baza de date este inerent legat de ciclul de viata al sistemului informational. Ciclul de viata al unui sistem informational implica existenta mai multor faze:

studiu de fezabilitate;

analiza cerintelor;

proiectarea conceptuala a datelor si operatiilor;

proiectarea logica;

proiectarea externa;

realizarea de prototipuri;

proiectarea interna si implementarea;

testarea si validarea;

intretinerea (mentenanta),

iar etapele principale ale ciclului de viata ale unei aplicatii de tip baza de date sunt [BD-Teora]:

planificarea bazei de date;

definirea sistemului;

colectarea si analiza cerintelor;

proiectarea bazei de date

alegerea sistemului SGBD (optional);

proiectarea aplicatiei;

realizarea prototipului (optional);

implementarea;

conversia si implementarea datelor;

intretinerea operationala.

Etapa de proiectare a bazei de date reprezinta procesul de realizare a unui proiect pentru o baza de date, care va trata toate operatiile si obiectivele organizatiei. Calitatea unei aplicatii de baze de date depinde de proiectarea sa.

In proiectarea unui sistem de baze de date se pot utiliza mai multe strategii de abordare dintre care cele mai cunoscute sunt:

proiectare de jos in sus (bottom-up sau ascendenta), care incepe prin definirea atributelor, a asociatiilor dintre atribute, si in final gruparea acestora in entitati. Un astfel de tip de abordare este reprezentat de procesul de normalizare.

proiectare de sus in jos (top-down sau descendenta), aceasta strategie este indicata in proiectarea unor aplicatii de tip baze de date complexe. Acesta incepe cu realizarea unor modele de date, care contin cateva entitati si relatii de nivel inalt, dupa care se aplica rafinari succesive de sus in jos, pentru a identifica entitatile, relatiile si atributele asociate de nivel jos. Acest tip de abordarea este specific modelului Entitate - Relatie.

De asemenea, toate metodologiile utilizate in etapa de proiectare (numita si etapa de modelare) a bazelor de date cuprind trei etape principale, si anume:

proiectarea conceptuala (elaborarea modelului conceptual) - reprezinta procesul de construire a unui model al informatiilor utilizate in cadrul unei organizatii, independent de toate consideratiile fizice. Aceasta faza este complet independenta de detaliile de implementare (elementele software ale SGBD-ului, programe de aplicatii, limbaje de programare, platforma hardware, etc.)

proiectarea logica (elaborarea modelului logic) - reprezinta procesul de construire a unui model al informatiilor utilizate in cadrul unei organizatii, bazat pe un anumit model de date, dar independent de un anumit SGBD si de alte consideratii fizice

proiectarea fizica (elaborarea modelului fizic) - reprezinta procesul de realizare a unei descrieri a implementarii bazei de date intr-o capacitate de stocare secundara; descrie structurile de stocare si metodele de acces utilizate pentru realizarea unui acces eficient la date. Modelul rezultat in urma acestei etape este cel care sta la baza materializarii bazei de date propriu-zise.

In Microsoft Visio for Enterprise Architects putem utiliza o diagrama de tip ORM (Object Role Modeling) pentru a elabora modelul conceptual al unei baze de date. Modelul rezultat este independent de platforma pe care se va implementa baza de date rezultata.

1. Ce este ORM

ORM (Object Role Modeling) reprezinta o descriere generala a bazei de date, utilizand simboluri intuitive pentru obiecte si atribute si care verbalizeaza (exprima) relatiile dintre acestea, utilizand o gama larga de constrangeri care surprinde si forteaza regulile de business.

De asemenea, ORM este un mod de abordare conceptual de un nivel inalt, utilizat pentru modelarea datelor care descriu domeniul aplicatiei utilizand in acest scop simboluri intuitive si un limbaj natural pe care atat utilizatorii cat si proiectantii bazei de date le poate intelege. Fiecare tip de element al faptului care are loc intre tipuri de obiecte este verbalizat si afisat intr-o diagrama de schema conceptuala. In acelasi timp, ORM permite folosirea unui set extins de constrangeri pentru a reflecta regulile de afaceri (business rules), precum si incorporarea unor exemple pentru verificarea proiectului.

Procedura de proiectare a schemei conceptuale ORM se caracterizeaza prin analiza si proiectarea datelor. Schema conceptuala specifica structura informationala a aplicatiei prin intermediul tipurilor de fapte. Un model sursa ORM poate fi folosit in loc de, sau inaintea unui alt model de proiectarea a bazei de date.

Primele versiuni ale ORM au fost dezvoltate in Europa la mijlocul anilor 1970 (de exemplu, modelarea relatiilor binare, Natural Language Information Analysis Method - NIAM, Natural Language Modeling - NLM, Format Object-Role Modeling Language - FORML).

Utilizarea ORM permite:

proiectarea conceptuala a bazei de date folosind fapte si exemple descrise intr-un limbaj natural

construirea automata a modelelor logice si fizice ale bazei de date pe baza faptelor exprimate intr-un limbaj natural

modelul bazei de date este creat intr-un limbaj care poate fi inteles de utilizatorii non-tehnici.

Dintre caracteristicile mai importante ORM enumeram:

este usor de inteles - exprima fapte si reguli in limba engleza si / sau alte grafice intuitive

este fiabil - valideaza regulile folosind limba engleza si mostre de date

este expresiv - surprinde in mod grafic multe reguli de business si mai complexe

este stabil - minimizeaza impactul modificarilor asupra modelului si interogarilor.

Unul din instrumentele care permit utilizarea ORM-ului in modelarea bazelor de date este Microsoft Visio for Enterprise Architects (sau Microsoft Visual Studio Enterprise Architect). Prin intermediul acestuia se poate:

crea un nou model sursa ORM

adauga tipuri de propozitii, de constrangeri interne si obligatorii, precum si exemple utilizand Editorul de Fapte

aduce tipurile de fapte in fereastra de desenare din editorul Business Rules si salvarea modelului

transpune modelul ORM intr-un model logic la bazei de date prin crearea unui proiect model al bazei de date, adaugand modelul sursa ORM, si apoi construirea modelului logic

genera modelul fizic al bazei de date din modelul logic prin selectarea SGBD-ului tinta si generarea unui scrip DLL

marca un tip obiect drept obiect independent, obiectivarea unei asociatii, verbalizarea, etc.

Principalele elementele de baza constructive utilizate in ORM sunt: tipuri obiect si relatiile.

Tipurile obiect care pot fi utilzate sunt:

entitate (entity)

valoare (value)

obiect extern (external)

Tipurile valoare si entitate sunt numite si tipuri obiect lexicale, respectiv nelexicale.

De asemenea, in ORM, relatiile dintre tipurile obiect entitate (numite si fapte), si relatiile dintre tipurile obiect entitate si tipurile obiect valoare (numite si referinte) sunt reprezentate prin predicate care contin unul sau mai multe roluri.

Deci, tipurile de propozitii care pot fi scrise utilizand Editorul de Fapte sunt:

tipuri de fapte (fact types)

tipuri de referinta (reference types)

Predicatele sunt reprezentate grafic ca o secventa de una sau mai multe casete de roluri. Sablonul de desen (stencil) pentru diagrame ORM din Microsoft Visio include cinci forme (shape) de predicate (Unary, Binary, Vertical Binary, Ternary, si Quaternary care vor avea un numar diferit de casute de roluri (una, doua, etc.). Forma de predicat utilizata depinde de numarul de roluri.

Generarea unui model sursa ORM

Pentru generarea unui model sursa ORM un proiectant are la dispozitie alegerea uneia dintre urmatoarele posibilitati:

crearea unui model nou pornind de la zero

utilizarea unui model drept punct de plecare utilizand reverse engineering

importul si redefinirea unui model existent.

O reprezentare ORM poate deveni destul de complexa daca baza de date va avea un numar mare de entitati, de aceea se poate utiliza mai multe modele ORM sursa pentru o singura baza de date. Fiecare dintre aceste modele va descrie o parte din baza de date.

Astfel, proiectantul are la dispozitie optiuni de editare a proprietatilor obiectelor si rolurilor, de configurare a regulilor de business, a constrangerilor si verbelor continute in predicate. Astfel un model ORM permite reprezentarea obiectelor si a rolurilor intr-un mod intuitiv si relativ usor de inteles pentru persoanele non-tehnice.

Pentru a exprima regulile de business intr-un model ORM, un fapt este exprimat ca un tip de obiect si un predicat. Fereastra Editorul de Fapte este reprezentata in Figura 1.

Figura 1 Editorul de Fapte utilizat pentru introducerea regulilor de business

Dupa cum se observa, Editorul de Fapte are mai multe pagini (Fact, Object, Examples, Constraints, si Advanced), fiecare din acestea avand un anumit rol in introducerea regulilor de business care se doresc a fi modelate.

Pagina FACT. In Figura 1 este ilustrat modul in care este introdus un tip de fapt, care face parte dintr-o regula de business, si care este exprimat de propozitia "Fabrici(Cod_fabrica) are Den_fabrica", in care tipurile de obiecte este Fabrici si Den_fabrica, iar relatiile dintre obiecte sunt exprimate prin predicatul "are". Propozitia care exprima regula de business este introdusa folosind pagina Fact. Rolul acestei pagini este de a permite introducerea tipurilor de fapte care exprima regulile de business ce se doresc a fi modelate.

Pagina Object. Pagina Object permite clasificarea tipurilor de obiecte care apar in Editorul de Fapte in urmatoarele tipuri:

entitate (entity)

valoare (value)

obiect extern (external)

In cazul unui tip entitate cu o schema de identificare simpla (Figura 2), acestuia i se poate adauga modul de referinta la acea entitate (de exemplu, Cod_fabrica pentru obiectul de tip entitate Fabrici).

Figura 2 Alegerea tipului de obiect si a modului de identificare pentru un obiect de tip entitate

3. Constrangeri

Dupa introducerea tuturor tipurilor de fapte, care descriu regulile de business pentru care se doreste modelarea datelor, pasul urmatorul consta in introducerea constrangerilor asupra fiecarui tip de fapt introdus.

Constrangerile provin din raspunsurile la intrebarile puse intr-un limbaj natural, si ele sunt utilizate pentru a surprinde intelesurile suplimentare in interiorul, si intre tipurile de fapte existente in modelul conceptual.

Aceste constrangeri trebuiesc gandite ca niste reguli care vor fi aplicate tipurilor de fapte din modelul conceptual cu scopul de a restrictiona datele care vor putea fi folosite in baza de date. Dupa aplicarea constrangerilor asupra tipurilor de fapte, acestea pot fi analizate si validate prin introducerea unor exemple de date prin intermediul Editorului de Fapte.

In functie de numarul de predicate care intra in alcatuirea constrangerii, acestea se clasifica in urmatoarele doua tipuri:

constrangeri interne - caz in care constrangerea este aplicata asupra unui singur predicat (in acest caz constrangerea actioneaza asupra unui singur tip de fapt)

constrangeri externe - caz in care constrangerea este aplicata la doua sau mai multe predicate (in aceasta situatie constrangerea este aplicata la cel putin doua tipuri de fapte, care au acelasi tip de obiect).

Intr-un model ORM pot fi utilizate urmatoarele tipuri de constrangeri:

Constrangeri de unicitate:

a    interne

b    externe

c    primare

Constrangeri obligatorii:

a    simple

b    disjunctive

Constrangeri circulare:

a    aciclice

b    asimetrice

c    antisimetrice

d    intranzitive

e    nereflexive

f     simetrice

Constrangeri comparare de multimi

a    submultimi

b    de egalitate

c    de excludere

Alte tipuri de constrangeri

a    de frecventa

b    index

c    de valoare

Pentru declararea constrangerilor se pot utiliza mai multe metode. Astfel prin intermediul paginii Constraints, a Editorului de Fapte se pot introduce constrangeri de tip intern cum ar fi:

constrangeri de unicitate interna (internal uniqueness)

constrangeri obligatorii simple (simple mandatory)

constrangeri de frecventa interne (internal frequency)

constrangeri circulare (ring)

dar nu se pot introduce constrangeri (care vor fi introduse prin alte metode), cum ar fi:

constrangeri comparare de multimi (set-comparation constraints), de exemplu o constrangere de excludere intre doua roluri ale aceluiasi predicat

constrangeri externe (external constraints)

constrangeri de valoare (value constraints), de exemplu restrictionarea valorilor unui atribut (atributul CodSex nu poate lua decat valorile ).

Constrangerile implicite care pot fi declarate prin intermediul Editorului de Fapte sunt:

constrangeri de unicitate interne simple - simple internal uniqueness

constrangeri obligatorii simple - simple mandatory.

Simbolurile utilizate pentru vizualizarea constrangerilor, precum si exprimarea acestora sunt afisate automat pentru a se putea vedea rezultatul operatiei executate.

De exemplu, pentru declararea unei constrangeri la un tip de fapt introdus, se va alege din Editorul de fapte pagina de declarare a constrangerilor, Constraints. Implicit suprafata acestei ferestre reprezinta o combinatie a unei constrangeri de unicitate interne si a unei constrangeri obligatorie simpla.

Figura 3 Adaugarea unei constrangeri prin intermediul Editorului de Fapte

In continuare vor fi prezentate cele mai utilizate tipuri de constrangeri.

1. Constrangeri de unicitate (uniqueness constraints)

Intr-un model conceptual cele mai utilizate constrangeri sunt cele de unicitate. Constrangerile de unicitate sunt utilizate pentru a indica ca un rol al unui predicat (combinatii de roluri) nu poate contine valori duplicate (valoarea acestuia trebuie sa fie unica).

O constrangere de unicitate interna (cunoscuta si drept o "constrangere de unicitate in cadrul predicatului" - intrapredicate uniqueness constraint) este aplicata asupra unuia sau mai multor roluri intr-un tip de fapt dat, atunci cand se doreste ca fiecare instanta a datelor din interiorul rolului, sau combinatia de roluri, sa fie unica.

O constrangere de unicitate externa (cunoscuta si sub denumirea de "constrangere de unicitate intre predicate" interpredicate uniqueness constraint) este utilizata in cazul in care combinatia dintre doua sau mai multe roluri, care partajeaza acelasi tip de obiect, este unica, sau altfel spus ea este aplicata la doua sau mai multe roluri care fac parte din tipuri de fapte diferite, dar care au in comun (folosesc) acelasi tip de obiect. In momentul in care modelul conceptual este transpus intr-un model logic, pentru aceste roluri care sunt incluse intr-o constrangere de unicitate externa, se va crea un index unic.

O constrangere de unicitate primara (cunoscuta si drept "constrangere de referinta primara", 'primary reference constraint') reprezinta o constrangere de unicitate care este desemnata drept referinta primara in cazul in care un tip de obiect este identificat prin doua sau mai multe constrangeri de unicitate. Se va utiliza o constrangere de unicitate primara in cazul in care se doreste sa se indice faptul ca un tip de obiect este primordial identificat prin rolul (rolurile) cuprins(e) prin aceasta constrangere de unicitate.

Cele doua tipuri de constrangeri de unicitate primare sunt:

constrangere de unicitate primara interna

constrangere de unicitate primara externa

Constrangeri obligatorii (mandatory constraints)

In cazul in care un rol dintr-un predicat este obligatoriu, fiecare membru din populatia tipului de obiect curent trebuie sa indeplineasca obligatoriu rolul respectiv. Un rol obligatoriu indica faptul ca nu sunt permise valori null pentru relatia data.

Cele doua tipuri de constrangeri obligatorii sunt:

constrangere obligatorie simpla (simple mandatory). Pentru a arata ca fiecare instanta a populatiei unui tip de obiect trebuie sa indeplineasca un rol particular, se va aplica o constrangere obligatorie pentru acel rol.

constrangere obligatorie disjunctiva (disjunctive mandatory sau inclusive or). Daca doua sau mai multe roluri din tipuri de fapte diferite sunt conectate catre acelasi tip de obiect obligatoriu, aceasta inseamna ca disjunctia rolurilor este obligatorie. Cu alte cuvinte, fiecare instanta din populatia tipului de obiect la care sunt conectate rolurile din constrangere trebuie sa indeplineasca cel putin unul din rolurile din constrangere.

3. Constrangeri comparare de multimi (set-comparison constraints)

Daca doua roluri sunt indeplinite de acelasi tip de obiect, sau tipurile de obiecte atasate rolurilor partajeaza un supertip comun, se spune despre acele tipuri ca sunt compatibile, si de aceea in anumite situatii este important ca populatiile lor sa poata fi comparate. Acelasi lucru este adevarat si pentru secvente de rol (lista ordonata a rolurilor).

Pentru aceasta se va utilizati o constrangere comparare de multimi pentru a restrictiona (a limita, a restrange) domeniul populatiei unei secvente de rol legata de populatia unei alte secvente de rol.

Pentru baze de date, numai trei operatori de comparare de multimi sunt relevanti:

submultime (subset)

egalitate (equality)

excludere mutuala (mutual exclusion)

care vor forma cele trei tipuri de constrangeri de comparare de multimi.

4. Constrangeri de egalitate (equality constraints)

O constrangere de egalitate leaga doua roluri intr-o relatie conditionala, si ea arata ca populatia primei secvente de rol trebuie sa fie intotdeauna egala cu populatia oricarei alte secvente de rol implicata in constrangere, si invers.

Acest tip de constrangere se va utiliza atunci cand doua sau mai multe secvente de rol sunt indeplinite de acelasi tip de obiect si toate rolurile sunt optionale. Rolurile pot face parte din acelasi tip de fapt sau din tipuri de fapte diferite.

5. Constrangeri de excludere (exclusion constraints)

O constrangere de excludere elimina posibilitatea ca o instanta a unui rol, care nu este obligatoriu, sa fie indeplinit in acelasi timp cu o instanta a unui alt rol, care de asemenea nu este obligatoriu. Aceasta inseamna ca, populatia primei secvente de rol nu poate exista in populatia celeilalte secvente de rol, sau altfel spus populatiile celor doua secvente de rol trebuie sa fie intotdeauna disjuncte (excludere obligatorie, excludere reciproca).

O constrangere de excludere se va utiliza in cazul in care doua sau mai multe secvente de rol sunt indeplinite de acelasi tip de obiect. Secventele de rol pot fi din acelasi tip de fapt sau din tipuri de fapte diferite.

6. Constrangeri de frecventa (frequency constraints)

O constrangere de frecventa este utilizata in cazul in care se doreste restrictionarea (limitarea) numarul de inregistrari care pot exista in populatia unui rol, sau a unei combinatii de roluri.

Constrangerile de frecventa pot fi specificate astfel:

un intreg (o valoare specifica), de exemplu valoarea 2, ceea ce semnifica faptul ca fiecare instanta a rolului respectiv are loc de exact 2 ori

un domeniu de valori limitat (de exemplu, .10), are semnificatia ca fiecare instanta a rolului respectiv se poate repeta de 2, 3, 4,.., respectiv 10 ori

un domeniu de valori nelimitat (de exemplu, >=5), caz in care fiecare instanta a rolului se poate repeta de un numar nelimitat de ori, dar valoarea initiala este de 5

7. Constrangeri index

O constrangere index reprezinta o adnotare utilizata in scopul de a imbunatati performantele intr-o baza de date fizica, si nu este o constrangere adevarata. In momentul in care se concepe un model logic bazat pe un model conceptual, o constrangere index este transpusa intr-un index care nu este unic intr-o tabela.

O astfel de constrangere se poate aplica asupra unuia sau mai multor roluri din unul sau mai multe predicate, atata timp cat toate predicatele implicate in construirea indexului au in comun (partajeaza) un singur tip de obiect.

8. Constrangeri de valoare (value)

Constrangerea de valoare este folosita pentru a defini multimea valorilor disponibile pentru un tip de obiect valoare. Astfel, se pot defini valori specifice sau, in cazul tipurilor de obiecte numerice, un domeniu al valorilor.

4. Adaugarea de exemple la tipurile de fapte

Pentru fiecare tip de fapt este indicat sa se includa si exemple. Pentru adaugarea de exemple la un tip de fapt existent in Editorul de Fapte, se va selecta pagina Examples unde se vor putea introduce cat mai multe exemple pentru ilustrarea tipului de fapt ales, si in special pentru testarea constrangerilor enuntate. In acest fel se va putea efectua verificarea corectitudini constrangerilor impuse.

Figura 4 Adaugarea de exemple la tipul de fapt introdus

Pentru verificarea corectitudinii constrangerilor impuse din exemplele existente, sau pentru verificarea inconsistentelor dintre date si constrangeri se va apasa butonul Analyze.

Pentru afisarea grafica a tipurilor de fapte introduse cu ajutorul Editorului de fapte, instrumentul pune la dispozitie mai multe modalitati. Astfel, din editorul Business Rules, pagina Fact Types se vor selecta toate tipurile de fapte pentru care se doreste reprezentarea grafica.

Optiunea Show Relationships este foarte utilizata in desenarea schemei si atunci cand se utilizeaza reverse engineering.

Figura 5 Selectarea si aducerea tipurilor de fapte in fereastra Drawing

5. Transpunerea unui model ORM intr-un model logic al bazei de date

Transpunerea unui model sursa ORM intr-un model logic al bazei de date presupune adaugarea modelului ORM la proiectul bazei de date ce se doreste a fi implementata si apoi construirea acestuia. Pentru aceasta se vor parcurge urmatoarele etape:

crearea unui nou proiect

adaugarea modelului sursa ORM in lista proiectului modelului bazei de date

transpunerea modelului sursa ORM intr-un model logic prin generarea proiectului

"tragerea" tabelelor rezultate in urma transpunerii modelului sursa ORM pe diagrama pentru vizualizarea diagramei logice

Modelul logic al bazei de date porneste de la o diagrama ORM elaborata anterior si stabileste o corespondenta a obiectelor si atributelor din modelul conceptual ORM la un set de entitati si relatii, testand gradul de normalizare si permitand ajustarea acestuia. Acest model este independent de platforma pe care va fi implementata baza de date. Pentru a se transpune un model sursa ORM intr-un model logic al bazei de date va trebui mai intai sa se adauge acel model ORM la proiectul bazei de date.

Daca se doreste crearea unui model logic al bazei de date fara a avea un punct de pornire (cum ar fi un model ORM), se poate utiliza sablonul de desen Entity Relationship.

Pentru construirea modelul logic se va alege optiunea: Database | Project | Build, comanda in urma careia se va crea automat schema relationala. Lista tuturor entitatilor care rezulta in urma construirii modelului logic va apare in fereastra Tables and Views (Figura 6).

In cazul in care modelul sursa ORM contine erori (predicate in conflict, relatii subclasa superclasa lipsa, etc.) Microsoft Visio for Enterprise Architects nu va genera modelul logic al bazei de date, indicand erorile care nu permit generarea modelului. Erorile vor apare in fereastra Output. Exemple de astfel de erori ce pot apare in urma construirii modelului logic:

Starting Build

C:LICENTAMLD_IMPVSD : Updating existing database model project.

C:LicentaMCD_impvsd : Merging Source Model.

C:LicentaMCD_impvsd : error C2006: '(null)' Predicate has no uniqueness constraint.

Build failed - 1 error(s) 0 warning(s)

Build failed - 1 error(s) 0 warning(s)

Figura 6 Generarea entitatilor dintr-un model ORM

Pentru a vizualiza schemele entitatilor rezultate in urma transpunerii modelului sursa ORM intr-un model logic al bazei de date se va utiliza proprietatea drag&drop. Se vor selecta numai acele entitati, sau toate, pentru care se doreste vizualizarea modelului logic, dupa care ele vor fi aduse pe foaia de lucru. Dupa efectuarea acestei operatii se va putea vedea modelul logic care va cuprinde: toate entitatilor (numele, atributele fiecarei entitati, precum si relatiile existente intre ele).

Figura 7 Generarea entitati Personal

Fiecare tabela are propriul sau nume afisat in antet (de exemplu, Personal), dupa care urmeaza lista coloanelor. Cheile primare sunt afisate subliniat si marcate cu "PK" (Primary Keys), si apar la inceputul listei coloanelor (deci inaintea celorlalte coloane). Coloanele obligatorii (not null) sunt afisate boldate. Coloanele care sunt chei straine sunt marcate cu "FKn" (Foreingn Keys), unde n reprezinta numarul cheii straine din (cu o) tabela. Abrevierea "Un" reprezinta o constrangere de unicitate, unde n reprezinta numarul constrangerii de unicitate din cadrul tabelei.

Reprezentarea din cadrul modelului logic (ca si in cel fizic, de altfel) este o reprezentare ERD, folosind implicit notatia relationala.

In acest exemplul din Figura 7, numele tabelei si ale coloanelor sunt cele generate in mod implicit din modelul sursa ORM (conceptual). In practica se pot atribui alte denumiri pentru tabele, sau pentru coloane, si de asemenea se pot modifica tipurile de date implicite care au fost desemnate de sistem pentru fiecare coloana a tabelei.

La acest nivel, modelul contine atributele grupate pe entitati, relatiile definite intre aceste entitati, indecsi si cheile definite la nivelul fiecarei entitati, etc. Se pot efectua modificari in cadrul acestui model, pana cand se va considera ca s-a atins varianta optima.

Daca se doreste ajustarea modelului logic al bazei de date, prin redenumirea sau mutarea coloanelor, se va selecta tabela pentru care se doreste efectuarea acestor modificari si apoi se va deschide formularul Database Properties. In acest formular se alege categoria Columns, si se selecteaza coloana dorita a fi modificata. Daca se doreste mutarea coloanei mai sus, se va utiliza butonul Move Up, iar in caz contrar, butonul Move Down.

Pentru a se putea efectua modificari asupra tipului coloanei (char, smallint, real, etc.) va trebui sa se bifeze butonul Physical data type.

Daca in modelul logic s-au efectuat modificari, si se doreste salvarea acestora si in modelul sursa ORM, se va deschide o fereastra de dialog in care utilizatorul este intrebat daca doreste migrarea tuturor modificarilor efectuate in modelul logic catre modelul (sau modelele) sursa care au stat la baza modelului logic. In general nu este recomandat sa se salveze modificarile facute si in modelul sursa ORM datorita faptului ca acesta poate fi utilizat si in alte proiecte ale unor baze de date.

6. Generarea schemei fizice a bazei de date

Un model sursa ORM nu poate fi transpus direct intr-o baza de date fizica. Pentru a genera o baza de date care are la baza un model sursa ORM mai intai acest model trebuie adaugat la un proiect; urmatorul pas consta in construirea modelului logic, care va putea fi utilizat apoi pentru a genera, sau a actualiza o baza de data fizica.

Reamintim ca atunci cand se adauga un model sursa ORM la un proiect, si apoi se construieste modelul logic, se efectueaza urmatoarele operatii:

un proiect nou este creat care va contine modelul sursa ORM

elementele modelului sursa ORM sunt transpuse in obiecte logice echivalente din modelul proiectului

proiectul este afisat in fereastra Tables andViews.

Dupa construirea modelului logic, se poate efectua una, sau ambele operatii care urmeaza:

se poate genera o schema a bazei de date

se pot efectua modificari in modelul logic, iar apoi aceste modificari pot fi rescrise in modelul sursa ORM.

Avand la baza un model logic al bazei de date se poate construi modelul fizic al acesteia.

Pentru a genera schema interna pentru un sistem de gestiune a bazei de date se va utiliza optiunea Database | Generate.

Generarea modelului fizic si a bazei de date este exemplificata in capitolul cu aplicatia