Pub.ro



Tema

de casa

SO

Proiectarea

unei baze de date folosind sistemul

MySql WorkBench

Masterand:

Matei Theodor

Cuprins:

INTRODUCERE: 4

I. Proiectarea Bazei de date 4

II. Colectarea si analiza cerintelor 6

2 .1 Proiectarea conceptual a bazelor de date 7

2.2 Proiectarea schemei conceptuale de nivel înalt 7

III. Proiectarea asocierilor 11

3.1 Asocierea binară N:1 11

3.2 Asocierea binară M:N 11

IV. Proiectarea tranzacţiilor 12

V. Prezentare Mysql Workbench

1.Introducere

2.Instalare

3.Configurare

4.Realizarea tabelelor si a relatiilor dintre ele

VI.Concluzii

INTRODUCERE:

Sistemele de baze de date sunt o componentă esenţială a vieţii de zi cu zi în societatea modernă.In cursul unei zile, majoritatea persoanelor desfasoara activitati care implica interacţiunea cu o baza de date: depunerea sau extragerea unor sume de bani din banca, rezervarea biletelor de tren sau avion, cautarea unei referinte într-o biblioteca computerizata, cumpararea unor produse etc.

Bazele de date pot avea dimensiuni (numar de inregistrari) extrem de variate, de la cateva zeci de înregistrari (de exemplu, baza de date pentru o agenda cu numere de telefon) sau pot ajunge la zeci de milioane de inregistrari (de exemplu, baza de date de plata pentru plata taxelor si a impozitelor).

In sensul cel mai larg, o baza de date (database) este o colectie de date corelate din punct de vedere logic, care reflectă un anumit aspect al lumii reale şi este destinată unui anumit grup de utilizatori. În acest sens, bazele de date pot fi create şi menţinute manual (de exemplu, fişele de evidenţă a cărţilor dintr-o bibliotecă, aşa cum erau folosite cu ani în urmă) sau computerizat, aşa cum este majoritatea bazelor de date folosite în momentul de faţă. O definiţie într-un sens mai restrâns a unei baze de date este următoarea:

O bază de date (database) este o colecţie de date creată şi menţinută computerizat, care permite operaţii de introducere, ştergere, actualizare şi interogare a datelor.

I. Proiectarea Bazei de date

Dezvoltarea sistemelor de baze de date comportă mai multe etape, care pot fi prezentate succint astfel:

1.1. Analiza şi definirea sistemului: definirea scopului sistemului de baze de date, a utilizatorilor şi a aplicaţiilor acestuia.

1.2. Proiectarea sistemului: în această etapă se realizează proiectul logic şi proiectul fizic al sistemului, pentru un anumit SGBD ales.

1.3. Implementarea: este etapa în care se scriu definiţiile obiectelor bazei de date (tabele, vederi, etc.) şi se implementează aplicaţiile software.

1.4.Incarcarea(sau conversia) datelor : popularea bazei de date,fie prin incarcarea directa a datelor,fie prin conversia unor date existente sub diferite alte forme.

1.5.Conversia aplicatiilor:toate aplicatiile software existente in sistemele informatice precedente ale organizatiei se convertesc in noul sistem.

1.6. Testarea şi validarea: noul sistem de baze de date este testat şi validat cât mai riguros posibil.

1.7.Operarea:sistemul de baze de date este pus la dispozitia utilizatorilor sai cu toate aplicatiile realizate in cadrul sistemului informatic al organizatiei.

1.8.Monitorizarea si intretinerea: pe tot parcursul etapei de operare sistemul de baze de date trebuie sa fie in mod permanent monitorizat si intretinut pentru a sigura consistenta si securitatea datelor si pentru a permite atat cresterea continutului de date cat si dezvoltarea de noi aplicatii software.Pot fi necesare la anumite intervale de timp,revizii si reorganizari ale sistemului de baze de date.

În general, se consideră că etapa de proiectare a unei baze de date se pot diviza, la rândul ei,

în mai multe faze :

a. Proiectarea conceptuală a bazei de date.

b. Alegerea unui SGBD.

c.Proiectarea logică a bazei de date.

d. Proiectarea fizică a bazei de date.

În mod tipic, dezvoltarea unei baze de date constă din desfăşurarea a două categorii de activităţi paralele, aşa cum se poate vedea în figura de mai jos:

Prima categorie de activităţi se referă la proiectarea structurii şi a conţinutului bazei de date, iar cea de-a doua categorie se referă la proiectarea modului de prelucrare a datelor. Aceste două categorii de activităţi sunt strâns corelate: toate prelucrările care se efectuează în tranzacţii depind de structura datelor memorate, iar proiectarea fizică a bazei de date depinde de prelucrările necesare în tranzacţii.

Cele şase faze de proiectare şi implementare enumerate mai sus nu se desfăşoară strict într-o singură secvenţă.În multe cazuri este necesară modificarea proiectului dintr-o fază iniţială într-una din fazele ulterioare, pentru a se obţine rezultatele dorite. Aceste bucle de reacţie între faze (sau în interiorul unei faze) sunt, în general frecvente în cursul proiectării unei baze de date, dar nu au mai fost reprezentate în figura de mai sus, pentru a nu complica diagrama respectivă.

Fazele cele mai importanate de proiectare a unei baze de date sunt fazele 2,4 si 5.Faza 1 in care se colecteaza informatiile despre cerintele de utilizare a bazei de date si faza 6,de implementare a datelor si a tranzactiilor pot sa nu fie considerate ca parte a procesului de proiectere a bazei de date ,ci ca parte de a ciclui de viata a sistemului din care face parte baza de date.Faza 3 de alegere a sistemului de gestiune a bazei de date este mai putin o faza de proiectare ci mai curand o faza de decizie,in care factorii economici au pondere la fel de importanta ca si factorii tehnici.

II. Colectarea si analiza cerintelor

Inainte de a se proiecta efectiv o bază de date, este necesar să se cunoască ce rezultate se aşteaptă utilizatorii potenţiali să obţină de la baza de date respectivă şi ce informaţii primare sunt disponibile pentru aceasta. De asemenea, este necesar să se cunoască ce aplicaţii se vor efectua (aplicaţii de gestiune a stocurilor, aplicaţii contabile, aplicaţii de urmărire a consumurilor, aplicaţii de salarizare, etc.).

In general,in acesta faza de colectare si analiza a cerintelor se desfasoara urmatoarele activitati:

• Identificarea grupurilor de utilizatori potentiali si a aplicatiilor.De regula,persoana cea mai avizata din cadrul fiecarui grup de utilizatori este cooptata ca participant in activitatile ulterioare de colectare si analiza a cerintelor.

• Revederea documentatiei existente privind aplicatiile dorite.In afara de documentatiile aplicatiilor dorite se studiaza si alte documentatii(diagramele de organizare a intreprinderii,formularele existente de introducere a datelor,rapoartele utilizate in controlul activitatii respective,etc.)pentru a se decide daca aceste aspect influenteaza cerintele bazei de date.

• Analiza mediului de operare si cerintelor de prelucrare a datelor.

Aceasta activitate include analiza fluxului de informatii in cadrul sistemului ,precum si analiza tipurilor de tranzactii si a frecventei de lansare a acestora.Deosebit de importanta este si stabilirea volumului si frecventei datelor actualizate precum si a volumului datelor returnate de interogari si a frecventei acestora.

• Chestionare si interviuri.Se colecteaza raspunsuri scrise de la utilizatorii potentiali la diferite seturi de intrebari si se organizeaza interviuri cu persoanele care reprezinte diferitele grupuri de utilizatori.In felul acesta,proiectantii pot intelege care sunt prioritatile de proiectare a bazei de date,importanta diferitelor aplicatii si performantele dorite de la acestea.

Toate aceste activităţi oferă informaţii slab structurate, în general în limbaj natural, pe baza cărora se pot construi diagrame, tabele, grafice, etc., manual sau folosind diferite instrumente software de proiectare. Această fază este puternic consumatoare de timp, dar este crucială pentru succesul sistemului informatic.

2 .1 Proiectarea conceptual a bazelor de date

Faza de proiectare conceptuală a bazelor de date implică două activităţi paralele: proiectarea schemei conceptuale şi a schemelor externe ale bazei de date şi proiectarea tranzacţiilor.

2.2 Proiectarea schemei conceptuale de nivel înalt

Deşi nu este obligatoriu, această fază se poate menţine independentă de SGBD şi produce un model de date de nivel înalt, care va fi implementat după transpunerea lui într-un model de date specific. Chiar dacă proiectanţii pot porni direct cu scheme conceptuale specifice unui anumit SGBD (care se mai numesc şi scheme logice), este totuşi recomandabil să se realizeze mai întâi schema conceptuală de nivel înalt independentă de SGBD, deoarece o astfel de schema conceptuală este o descriere stabilă şi inavuabilă a bazei de date, iar alegerea unui SGBD şi deciziile ulterioare de proiectare se pot schimba fără ca aceasta să se schimbe.

Pentru proiectarea schemei conceptuale se identifică elementele esenţiale ale acesteia: tipurile de entităţi şi atributele lor precum şi asocierile dintre aceste tipuri. Se pot defini, dacă este necesar, subtipuri, prin specializări ale tipurilor de bază, sau supertipuri, prin generalizări ale tipurilor deja definite. Acest proiect conceptual de nivel înalt este realizat pe baza cerinţelor definite în prima etapă de proiectare şi se reprezintă, în general printr-o diagramă Entitate-Asociere (extinsă).

Există mai multe aspecte privind modul de abordare a proiectării conceptuale. Un prim aspect se referă la modul de proiectare a schemei conceptuale a bazei de date: proiectare prin integrarea cerinţelor şi proiectare prin integrarea schemelor externe.

În proiectarea prin integrarea cerinţelor (care se mai numeşte şi proiectare centralizată) se realizează mai întâi integrarea (combinarea) tuturor cerinţelor de proiectare într-un singur set de cerinţe, pe baza căruia se proiectează schema conceptuală a bazei de date. Din această schema conceptuală (unică) proiectată se deduc schemele externe (vederile) corespunzătoare diferitelor grupuri de utilizatori şi aplicaţii.

În proiectarea prin integrarea vederilor (schemelor) externe se proiectează câte o schemă corespunzătoare fiecărui grup de utilizatori şi aplicaţii, pe baza cerinţelor acestora, după care se combină aceste scheme într-o singură schemă conceptuală globală, pentru întreaga bază de date.

Fiind dat un set de cerinţe, pentru un singur utilizator sau pentru mai mulţi utilizatori ai bazei de date, proiectarea schemei conceptuale care să satisfacă aceste cerinţe se poate aborda într-o varietate de strategii, dintre care cele mai relevante sunt proiectarea ascendentă (bottom-up) şi proiectarea descendentă (top-down).

În proiectare ascendentă a bazelor de date se porneşte de la o schemă conceptuală universală care conţine toate atributele, care sunt apoi grupate pentru a forma tipuri de entităţi şi asocierile dintre acestea. Proiectul poate fi rafinat prin grupări ulterioare şi creare de supertipuri şi subtipuri ale tipurilor existente.

În proiectarea descendentă a bazelor de date se porneşte de la o schemă conceptuală dezvoltată în modelul Entitate-Asociere (extins) în care sunt cuprinse aspectele de bază (tipuri de entităţi şi asocieri ale acestora). Dezvoltarea şi rafinarea acestui model se face prin adăugarea de noi atribute şi constrângeri, crearea unor subtipuri (prin specializare) şi asocierea acestora cu tipurile de bază.

Aşadar, în această fază de proiectare se obţine schema conceptuală de nivel înalt a bazei de date, care este independentă de orice model de date specific (ierarhic, reţea, relaţional, etc.), şi de orice sistem de gestiune care poate fi folosit pentru realizarea bazei de date.

3.SCHEMA CONCEPTUALA DE NIVEL ÎNALT A BAZEI DE DATE

Entităţi.

Tipurile de entităţi puternice (normale) care se pot defini pentru modelarea activitătii unei agentii sunt urmatoarele:

ANGAJAT(Nume,Prenume,Parola,Ghiseu)

PERSOANE(Nume,Prenume,Serie_buletin,Numar_Buletin,CNP)

RUTA(Nr_Km,Nr_bilete_rezervate,Clasa)

TRONSON_Aerian(Data_plecare,Ora_Plecare,Data_sosire,Ora_sosire,Locuri_ramase,Sursa,Destinatie,Vehicul)

TRONSON_Tren(Data_plecare,Ora_Plecare,Data_sosire,Ora_sosire,Locuri_ramase,Sursa,Destinatie,Vehicul)

TRONSON_Autocar(Data_plecare,Ora_Plecare,Data_sosire,Ora_sosire,Locuri_ramase,Sursa,Destinatie,Vehicul)

Aeroporturi(Oras,Aeroporturi)

Gari(Oras,Gari)

Autogari(Oras,Autogari)

Vehicul(Vehicul,Nr_locuri)

Tara(Tari)

Asocieri.

Asocierile dintre mulţimile de entităţi se stabilesc în funcţie de modul în care se desfăşoară activitatea modelată. De exemplu, dacă agentia respectivă activitatea este organizată pe mai multe birouri(ghisee) şi fiecare angajat lucrează într-unul (şi numai unul) din birouri,si se ocupa de cate o rezervare la un anumit moment(nu realizeaza mai multe rezervari concomitent) atunci între mulţimile de entităţi ANGAJAT-REZERVARI există o asociere 1:N.

Asocierea PERSOANE-REZERVARI este o asociere M:N dacă se consideră că opersoana poate sa faca mai multe rezervari si o rezervare poate sa contina mai multe persoane .

O ruta este compusa din mai multe tronsoane şi fiecare tronson poate fi inclus în mai multe, rute; deci asocierea RUTA-TRONSON este este M:N.

O mulţime de entităţi slabe se află, de regulă, în asociere N:1 cu mulţimea de entităţi puternice de care depinde. In exemplul dat, între mulţimea AEROPORTURI şi mulţimea de entităţi ORAS există o asociere N:1.

III. Proiectarea asocierilor

3.1 Asocierea binară N:1

Asocierea binară N:1 dintre două mulţimi de entităţi puternice din diagrama E-A se realizează în modelul relaţional prin intermediul unei chei străine în prima relaţie (cea cu multiplicitatea N a asocierii) care referă cheia primară (sau o cheie candidată) din relaţia referită (cea cu multiplicitatea 1 a asocierii). De exemplu,asocierea N:1 între relaţiile AEROPORTURI - ORAS se realizează prin cheia străină IdOras adăugată relaţiei AEROPORTURI, care referă cheia primară cu acelaşi nume a relaţiei ORAS.

Astfel de atribute (pentru definirea cheilor străine) nu există în modelul E-A şi ele trebuie să fie adăugate în modelul relaţional pentru definirea asocierii N:1, aşa cum în modelul ierarhic pentru o astfel de asociere se adaugă link-uri (pointeri) între noduri. Asocierea binară N:1 poate apare şi ca asociere între o relaţie corespunzătoare unei mulţimi de entităţi slabe şi relaţia corespunzătoare mulţimii de entităţi puternice de care aceasta depinde, aşa cum a fost prezentată mai sus.

3.2 Asocierea binară M:N

Asocierea binară M:N dintre două mulţimi de entităţi din diagrama E-A se realizează în modelul relaţional prin intermediul unei noi relaţii, numită relaţie de asociere. Această nouă relaţie se află în asociere M:1, respectiv N:1 cu fiecare din cele două relaţii date prin intermediul a două chei străine care referă cheile primare (sau cheile candidate) din relaţiile date.

De exemplu, pentru a reprezenta asocierea M:N dintre relaţiile RUTA-TRONSON_AERIAN se adaugă o nouă relaţie numită RUTA2, care conţine cheile străine IdTronson şi IdRuta, ce referă cheile primare din relaţiile TRONSON_AERIAN, respectiv RUTA.

O relaţie de asociere poate să conţină şi alte atribute în afara cheilor străine, atribute care caracterizează asocierea dintre relaţiile date. Cheia primară a unei relaţii de asociere binară poate fi o cheie artificială sau poate fi compusă din cheile străine, eventual împreună cu alte atribute ale relaţiei.

Asocierea M:N dintre relaţiile PERSOANE-REZERVARI se realizează prin introducerea relaţiei de asociere PERS, care conţine două chei străine, IdPersoane1 şi IdPersoane2, care referă cheile primare IdPersoane si IdRezervari.

Schema conceptuală a unei baze de date relaţionale poate fi dezvoltată independent de un anumit SGBD, urmând ca ulterior să se adauge diferite trăsături specifice SGBD-ului folosit. De obicei însă, fiecare SGBD pune la dispoziţie un număr de instrumente mai mult sau mai puţin „prietenoase” de proiectare a relaţiilor şi a asocierilor, astfel încât în mod frecvent, proiectul conceptual se dezvoltă de la început în cadrul sistemului SGBD în care se va realiza baza de date. De exemplu, Microsoft Access oferă o interfaţă vizuală de proiectare a relaţiilor şi a asocierilor deosebit de uşor de utilizat. La fel, sistemele SQL Server sau Oracle 10g oferă instrumente grafice pentru proiectarea vizuală a relaţiilor.

IV. Proiectarea tranzacţiilor

Atunci când se proiectează o bază de date, se cunosc în mare parte şi ce tipuri de aplicaţii se vor executa. Un aspect important în proiectarea bazelor de date este specificarea caracteristicilor funcţionale ale acestor aplicaţii cât mai devreme în cursul procesului de proiectare, astfel încât schema bazei de date să includă toate informaţiile necesare cu privire la aceste aplicaţii. În plus, cunoaşterea importanţei relative a diferitelor tranzacţii executate de aplicaţiile bazei de date, precum şi a frecvenţei de invocare a acestora, permite luarea unor decizii în etapa de proiectare fizică a bazei de date.

Una din tehnicile cele mai obisnuite de specificare a tranzactiilor la nivel conceptual si independent de sistemul de de gestiune este de identifica intrarile si iesirile lor su comportarea functional.Tranzactiile sunt grupate in trei categorii:tranzactii de interogare,trnzactii de actualizare si tranzactii mixte,care executa atat interogari cat si actualizari.

Pentru dezvoltarea ulterioara ulterioara in bune conditii a proiectului unui sitem de baze de date,atat proiectarea schemei conceptual

După implementarea sistemului de baze de date vor mai fi identificate şi implementate noi tranzacţii. Totuşi, cele mai importante tranzacţii sunt cel mai adesea cunoscute înainte de implementarea sistemului. Dacă operaţiile de acces la baza de date ale unei tranzacţii sunt numai operaţii de citire, acea tranzacţie se numeşte tranzacţie de citire (read-only transaction) şi controlul concurenţei unor astfel de tranzacţii este mult mai simplu.

In cele ce urmează se va studia cazul general, al tranzacţiilor de citire şi scriere (read-write transactions) care efectuează atât regăsiri de date (prin operaţii de citire) cât şi actualizări (prin operaţii de scriere), şi care necesită tehnici de control al concurenţei mult mai complexe.Operaţiile efectuate de o tranzacţie şi înregistrate de administratorul de refacere (recovery manager), pentru a asigura cele patru proprietăţi importante ale tranzacţiilor (ACID), sunt următoarele:

1. begin: această operaţie marchează începutul execuţiei unei tranzacţii.

2. read sau write: sunt operaţii de citire sau scriere a articolelor în baza de date, executate în cadrul unei tranzacţii.

3. end: această operaţie marchează terminarea operaţiilor de scriere sau citire din baza de date, ceea ce înseamnă că tranzacţia se poate termina; totuşi, este posibil să fie necesare unele operaţii de verificare înainte de validarea (commit) tranzacţiei.

4. commit: această operaţie semnalează terminarea cu succes a tranzacţiei, validarea tuturor modificărilor efectuate în baza de date şi vizibilitatea modificărilor efectuate pentru alte tranzacţii; din acest moment, modificările efectuate nu mai pot fi anulate, nici pierdute printr-o defectare ulterioară a sistemului (bineînţeles, dacă mecanismul de refacere al SGBD-ului funcţionează corect).

5. rollback (sau abort): această operaţie semnalează faptul că tranzacţia a fost abandonată şi că orice efect pe care tranzacţia l-a avut asupra bazei de date trebuie să fie anulat (printr-o “rulare înapoi” a operaţiilor).

6. undo: această operaţie este similară operaţiei rollback, dar se aplică unei singure operaţii, nu unei întregi tranzacţii.

7. redo: această operaţie specifică faptul că unele operaţii ale unei tranzacţii trebuie să fie executate din nou pentru a se putea valida întreaga tranzacţie.

Ultimele două operaţii sunt necesare numai în anumite tehnici de refacere.

În figura de mai jos este reprezentată diagrama de stare a unei tranzacţii folosind limbajul UML, unde fiecare stare are o denumire şi fiecare operaţie provoacă o anumită tranziţie între stări.

În starea ACTIVA se ajunge ca urmare a lansării unei tranzacţii prin operaţia begin, iar execuţia corectă a operaţiilor read sau write nu modifică această stare. Atunci când o tranzacţie se termină, ea trece în starea PARTIAL VALIDATA în care se efectuează operaţii de verificare impuse de tehnicile (protocoalele) de control al concurenţei şi de refacere. Dacă ambele verificări sunt îndeplinite cu succes, atunci tranzacţia este validată (prin execuţia unei operaţii commit) şi trecută în starea VALIDATA; dacă una sau ambele condiţii nu sunt îndeplinite, tranzacţia este trecută în starea ABANDONATĂ prin execuţia operaţiei abort. Starea TERMINATĂ este consecinţa imediată a atingerii uneia din stările VALIDATĂ sau ABANDONATĂ şi nu necesită nici o altă operaţie pentru efectuarea acestei tranziţii.În cursul stării ACTIVĂ, orice tranzacţie poate fi abandonată (şi trecută în starea ABANDONATĂ prin execuţia unei operaţii abort), dacă diferite verificări efectuate nu sunt îndeplinite.

[pic]

Pentru refacerea bazei de date în condiţiile în care unele tranzacţii sunt abandonate sau în care pot apărea defecte de funcţionare, sistemul SGBD menţine un fişier jurnal, în care memorează operaţiile efectuate de tranzacţii. Fişierul jurnal este memorat pe disc şi nu este afectat de diferite erori de execuţie, cu excepţia unei defectări catastrofice a discului. În plus, fişierul jurnal este salvat periodic pe un suport auxiliar (bandă magnetică), ca o măsură de prevedere pentru astfel de defecte catastrofice.

În fişierul jurnal (log file) se înregistrează operaţiile efectuate de fiecare tranzacţie, identificată printr-un identificator unic (T) generat de sistem.Prima înregistrare referitoare la o tranzacţie cu identificatorul T este înregistrarea de start a tranzacţiei: [begin,T]. La fiecare operaţie write(X) executată de o tranzacţie T, în fişierul jurnal se memorează o înregistrare de tipul [write,T,X,vechea_valoare,noua_valoare], dacă pentru refacerea datelor se folosesc operaţii undo, sau o înregistrare de tipul [write,T,X,noua_ valoare], dacă se folosesc operaţii redo. Sistemele care nu evită abandonarea în cascadă a tranzacţiilor înregistrează în fişierul jurnal şi operaţiile de citire read(X), printr-o înregistrare de tipul [read,T,X,valoare].

Pentru fiecare tranzacţie T, în fişierul jurnal se mai memorează starea de terminare: validată (printr-o înregistrare [commit,T] ) sau anulată (printr-o înregistrare[rollback,T]). După executarea validării şi înregistrarea ei în fişierul jurnal, efectul tranzacţiei este permanent memorat în baza de date.

Dacă sistemul se defectează, la reluarea execuţiei după îndepărtarea defectului, sistemul SGBD va aduce baza de date într-o stare consistentă prin examinarea fişierului jurnal. Dat fiind că fişierul jurnal conţine o înregistrare pentru fiecare operaţie de scriere care a modificat valoarea unui articol al bazei de date, este posibil de a anula efectul tuturor operaţiilor de scriere efectuate de o tranzacţie care a fost lansată dar nu a fost validată, parcurgând înapoi fişierul jurnal şi înlocuind valoarea existentă a articolului modificat cu vechea valoare, memorată în fişierul jurnal. În cazul abandonării în cascadă, trebuie să fie abandonate şi tranzacţiile care au citit valori modificate de tranzacţiile abandonate.

-----------------------

Implemantarea tranzactiilor

(dependente de SGBD)

Instructiuni de descriere a datelor (LDD)

(dependete de SGBD)

Proiectarea schemei interne

(dependent de SGBD)

Faza 6:

Implementare

Faza 5:

Proiectare fizica

Proiectarea schemei conceptual si a schemelor externe(dependente de SGBD)

Faza 4:

Proiectare logica

Faza 3:

Alegerea unui SGBD

Proiectarea tranzacţiilor (independente de SGBD)

Proiectarea schemei conceptuale şi a schemelor externe (independente de SGBD)

Faza 2:

Proiectare conceptuală

Cerinţele de prelucrare

Cerinţele de date

Faza 1:

Colectarea şi analiza cerinţelor

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download