Documente Academic
Documente Profesional
Documente Cultură
PROIECTAREA
SISTEMELOR
INFORMATICE
CUPRINS
Capitolul 1
Sisteme informatice………………………………………………………………..…….….. 3
Capitolul 2
Iniţierea şi planificarea realizării unui sistem informatic...…………………….…………… 18
Capitolul 3
Analiza sistemului existent şi definirea cerinţelor noului sistem........……………................ 23
Capitolul 4
Proiectarea logică a sistemelor informatice.......................................................................................... 48
Capitolul 5
Proiectarea fizică a sistemelor informatice…………….……….......................................................... 66
Teste 2006............................................................................................................................... 93
Bibliografie.............................................................................................................................. 107
Reguli şi
Sistem Om Fişiere
manual
proceduri
manuale scrise
Programe şi
Sistem Fişiere Structuri de
automatizat Calculator informatice date
Definiţie.
Un sistem informatic este un sistem utilizator-calculator integrat, care furnizează
informaţii pentru a sprijini activităţile de la nivel operaţional şi activităţile de
management într-o organizaţie, utilizând echipamente hardware şi produse software,
proceduri manuale, o bază de date şi modele matematice pentru analiză, planificare,
control şi luarea deciziilor [10].
Elaborarea sistemelor informatice impune modelarea sistemului informaţional al
organizaţiei cu ajutorul unui formalism prin care să poată fi reprezentată cât mai sugestiv
şi fidel realitatea din cadrul sistemului informaţional.
Sistemele informatice complexe pot fi descompuse în subsisteme, care la rândul
lor pot fi descompuse în aplicaţii destinate unor categorii de utilizatori, aplicaţii care la
rândul lor pot fi constituite din unul sau mai multe programe scrise în diverse limbaje de
programare după cum este ilustrat în figura 1.2.
Sistem Informatic
…
Aplicatia 2.1 Aplicatia 2.k
.
Program
… Program 2.k.s
2.k.1
- beneficiarii sistemului.
Cadrul organizatoric este cel specificat în regulamentul de organizare şi funcţionare
(ROF) al unităţii în care va fi utilizat sistemul informatic.
La realizarea şi utilizarea unui sistem informatic trebuie avute în vedere reţele,
echipamente, produse software de bază, produse software de
aplicaţie.
Reţele
după aria de întindere geografică:
- Locale =LAN (Local Area Network) – la nivelul unei organizaţii;
- Metropolitane –MAN (Metropolitan Area Network) – la nivel de oraş, localitate;
- De mare întindere -WAN (World Area Network) (ex. Judeţ, Ţară).
după accesibilitate:
- Internet (reţeaua Web) – o colecţie mondială de reţele interconectate;
- Intranet – un sit Web sau un grup de sit-uri care aparţin unei organizaţii, accesibil numai
pentru membrii acesteia;
- Extranet – o reţea intranet care este parţial accesibilă utilizatorilor externi autorizaţi.
Echipamente
- Echipamente de calcul : calculatoare, staţii grafice, pentru servere de reţea, servere de
baze
de date, staţii de lucru (clienţi, utilizatori), UPS-uri.
- Echipamente de comunicaţie : router-e, hub-uri, modem-uri, switch-uri.
Produse software
Produse software de bază:
- Sisteme de operare pentru serverul de reţea (UNIX, Windows NT server, Windows
2000, Novell) şi pentru staţiile de lucru sau clienţi (Windows 95, Windows 98, Windows
NT work station, Windows 2000);
- Sisteme de Gestiune a Bazelor de Date (ORACLE, SQL Server Microsoft, MySQL,
ACCESS, FoxPro etc.);
- Sisteme GIS (Geographical Information System) – utilizate pentru realizarea
aplicaţiilor din domeniul cadastrului (stocarea şi prelucrarea datelor spaţiale );
- Limbaje (medii) de programare – utilizate pentru realizare software de aplicaţie.
Produse software de aplicaţie – produse program ce constituie aplicaţiile şi
subsistemele sistemului informatic.
Analiza şi
definirea
cerinţelor
Proiectarea
sistemului şi a
software-ului
Implementarea
şi testarea
unităţilor de
program
Integrarea şi
testarea
sistemului
Exploatarea şi
întreţinerea
sistemului
Fig. 1.3. Etapele ciclului de viaţă a unui sistem informatic în modelul cascadă ([10])
Culegerea
datelor
Pregătirea datelor
Prelucrarea datelor
Întreţinere
fişiere
Informaţii de
ieşire
Situaţia
costurilor pe
Consultare 1 comenzi
Documente Actualizare
facturi
ordin de plată
bon de
consum
Balanţa de
Consultare 2 verificare
Registrul jurnal
BD
Casa
Banca
timp. Folosirea eficientă a acestor resurse, în scopul obţinerii unui sistem informatic
performant a impus ordonarea acestui proces complex, într-o succesiune bine stabilită de
etape şi subetape şi utilizarea unor metode şi tehnici adecvate. Acest lucru a dus deci, la
conturarea unor metodologii de realizare a sistemelor informatice.
Între diversele etape de realizare a sistemelor informatice există o legătură
indestructibilă, legătură reflectată şi de faptul că în mod logic şi practic calitatea realizării
unor activităţi din etapele şi fazele precedente influenţează în mod decisiv calitatea
activităţilor din etapa ce îi urmează [2].
Datele sunt surprinse din prisma structurii lor sub formă de atribute şi înseamnă de
fapt, ceea ce are stocat, şi reflectă structura statică [1].
Funcţiile scot în evidenţă în mod limitat ceea ce face sistemul. El poate fi văzut şi
ca un proces, întrucât elementele sistemului despre care se păstrează datele de rigoare
sunt supuse unor transformării funcţionale, prin intermediul proceselor [1].
Comportamentul este invocat pentru a reda o altă modalitate de percepţie a
sistemului, influenţa evenimentele şi proprietăţilor sistemului, şi sugerează dinamica lui
[1].
Metoda descompunerii funcţionale (orientate funcţii) [1].
Dintre autorii remarcabili care au abordat descompunerea funcţională îi enumerăm
pe câţiva cum ar fi DeMarco, Yourdon şi Constantine, Jackson, Page-Jones, Warnier-Orr,
Dahl, Marco&Gowan. Descompunerea funcţională este cea care anunţă apariţia
proiectării structurate şi analizei structurate. Fiecare funcţie este descompusă în
subfuncţii, până se obţin structuri uşor de transpus în instrucţiunile limbajelor de
programare.
Metodele fluxurilor de date (orientate-proces) [1].
Prin această metodă analiştii efectuează reprezentarea lumii reale prin simboluri
care reprezintă fluxul datelor, transformările datelor, stocarea datelor, entităţi externe, etc.
Metoda orientată spre procese are încă un mare grad de asemănare cu descompunerea
funcţională.
Metode orientate spre informaţii (orientate-date) [1]
Două realizări importante în domeniu au dat tonul unei orientări în abordarea
sistemelor: modelarea datelor cu ajutorul diagramelor entitate-relaţie, de către Peter P.
Chen (1976) şi ingineria informaţiei, în viziunea lui James Martin.
Metoda orientată-obiect [1]
Metodele OO constituie o categorie particulară a metodelor de dezvoltare software,
care privesc construirea sistemelor pentru care clasa reprezintă unitatea arhitecturală
fundamentală. Clasa este o grupare logică a obiectelor care au aceeaşi structură şi un
comportament similar.
descompunerea;
performanţe de deplasare, pe orizontală, de la un instrument la altul;
grade diferite de automatizare;
INTEGRAREA.
CASE-ul nu este un proces independent. El constituie un set integrat de
metodologii, care urmăresc realizarea ciclului de viaţă al unui sistem. La sfârşitul fiecărei
faze a ciclului de viaţă, rezultatele obţinute trebuie supuse unei analize şi verificări, iar
utilizatorii trebuie informaţi asupra modului de gestionare a procedurilor de lucru. Ei sunt
cei care trebuie să dea avizul de continuare a parcurgerii fazelor următoare, pe baza a
ceea ce li s-a prezentat. Este, de fapt, un proces de revalidare a conceptelor folosite în
proiectarea sistemului şi a modelului proiectat pe măsura desfăşurării operaţiunilor, din
faza de proiectare până la predarea produsului final. CASE poate sprijini aceste proceduri
prin punerea la dispoziţie a unei documentaţii, critici sau modificări asupra elementelor
din modelul proiectat. Pe acest fond, pot fi făcute evaluări, critici sau modificări asupra
elementelor din modelul proiectat. Rezultatele obţinute în urma proiectării unui anumit
model de sistem constau în documentaţia oferită, care acoperă întregul ciclul de viaţă al
sistemului, cu toate operaţiile şi procedurile pe care le presupune. Datele din
documentaţia modelului sunt, de obicei, înlocuite cu cele reale şi se parcurg paşii de
implementare a sistemului pentru a obţine un model funcţional. În plus, CASE oferă
posibilitatea de a analiza ieşirile obţinute şi de a le modifica pentru a reflectă schimbările
intervenite în sistem, modulele definite şi depozitul de date [1].
A) Metodologia structurată
Westmount I-CASE Yourdon oferă suport complet pentru realizarea sistemelor
informatice. Având la baza metoda structurată propusă de Yourdon, acest instrument
CASE integrat oferă posibilitatea lucrului în echipă, posibilitatea de generare şi reutilizare
a codului şi generarea automată a documentaţiei de realizare a sistemului informatic.
B) Metodologia orientată-obiect
Expresia „pur orientate-obiect" se referă la faptul că pe de o
parte, instrumentele CASE conţin numai elemente specifice abordării
orientate-obiect a sistemelor, iar pe de altă parte la faptul că se
bazează pe metodele şi tehnicile de analiză şi proiectare orientate-
obiect.
Instrumentele CASE orientate-obiect, din punct de vedere al etapelor
ciclului de viaţă al sistemelor, pot fi grupate ca şi cele convenţionale,
astfel:
- Upper CASE orientat-obiect pentru analiza şi proiectarea
sistemelor;
- Lower CASE orientat-obiect pentru generarea codului-sursă al
aplicaţiilor;
- I-CASE orientat-obiect care acoperă întregul ciclu de viaţă.
Deoarece tendinţa se îndreaptă tot mai mult spre tehnologiile
informaţionale orientate-obiect, nici domeniul instrumentelor ce
Designer/2000
Setul de instrumente Designer/2000 este parte integrantă din portofoliul de
instrumente de dezvoltare oferit de Oracle şi reprezintă o soluţie integrată pentru
dezvoltarea de sisteme client/server din generaţia a doua sau de sisteme Intranet bazate
pe Web. Designer/2000 acoperă toate fazele ciclului de dezvoltare a aplicaţiilor
software, pornind de la modelarea sistemului informatic (business modelling) până la
exploatare. Abordarea Designer/2000 bazată pe un Repository permite ca anumite
componente sau toate componentele să fie folosite pentru dezvoltarea rapidă de aplicaţii
scalabile, multi-platformă, distribuite.
Capitolul 2
Iniţierea şi planificarea realizării unui sistem informatic
A.
identificarea
şi selectarea
proiectului microanali
za Fazele ciclului de viaţă
B. iniţierea şi
planificarea al dezvoltării
proiectului sistemului
C. analiza
D. proiectarea
logică
E. proiectarea
fizică
F. implementarea
G. întreţinerea
Iniţierea proiectului
Din momentul selecţiei lui, proiectul trece în faza de iniţiere, ceea ce presupune
desfăşurarea unei activităţi laborioase, prestată de un responsabil, cunoscut în practică
sub numele de manager de proiect, care răspunde de [1]:
Elaborarea unor studii de fezabilitate generală;
Elaborarea planurilor detaliate ale proiectelor;
Găsirea celor mai buni membri ai echipei proiectului.
Managerul de proiect trebuie să dea dovadă de multe calităţi pentru a putea jongla
cu elemente cum sunt:
Schimbările tehnologice;
Ciclul de viaţă al sistemelor;
Contractori şi furnizori;
Managementul resurselor umane;
Metodologie şi instrumente de lucru diferite;
Restricţii de timp şi resurse;
Documentare şi comunicare;
Aşteptările managerilor şi clienţilor.
Activităţile efectuate în faza iniţierii proiectului sunt:
1.stabilirea echipei de iniţiere a proiectului;
2.stabilirea bunelor relaţii cu beneficiarii;
3.stabilirea planului iniţierii proiectului;
4.stabilirea procedurilor manageriale;
5.stabilirea cadrului de desfăşurare a proiectului şi a manualului de operare
al acestuia.
Planificarea proiectului
Planificarea proiectului va cuprinde o evaluare a cerinţelor informaţionale ale
sistemului la nivelul întregii organizaţii.
Planificarea proiectului este procesul prin care are loc definirea clară a activităţilor
şi a eforturilor necesare înfăptuirii lor în cadrul fiecărui proiect.
Tipurile activităţilor executate în cadrul planificării proiectului cuprind [1]:
1.Descrierea ariei de întindere, a variantelor şi fezabilităţii proiectului
2. Descompunerea proiectului în activităţi uşor executabile şi
controlabile
3.Estimarea resurselor şi crearea unui plan al resurselor
4.Realizarea unei prime planificări calendaristice
5.Realizarea unui plan al comunicărilor
6.Determinarea standardelor şi procedurilor proiectului
7.Identificarea şi evaluarea riscului
8. Crearea unui buget preliminar
9.Întocmirea rapoartelor de activitate
10. Definitivarea planului de bază al proiectului
1. Colectarea
cerinţelor
2. Proiectare
ecrane
3. Proiectare
rapoarte
4. Proiectare baze
de date
5. Documentaţie
utilizator
6. Programare
7. Testare
8. Instalare
9. Şedinţa de
analiză
Capitolul 3
Analiza sistemului existent şi definirea cerinţelor noului sistem
Chestionarul poate fi utilizat atât de către analiştii începători, cât şi de către cei
avansaţi, familiarizaţi sau nu cu problemele informaţionale-decizionale ale unităţii. Prin
utilizarea lui dispare “filtrul de informaţii” care este analistul iar cel care furnizează
informaţii are posibilitatea să se concentreze mai bine asupra răspunsurilor. Utilizând
această metodă, participă un număr mare de “furnizori de informaţii”. Limitele
chestionarului constau în faptul că este o metodă de verificare a unor cunoştinţe
prealabile, fapt ce implică cunoaşterea prealabilă a domeniului.
Această metodă necesită timp relativ îndelungat pentru întocmirea chestionarului
precum şi de culegere şi prelucrare a răspunsurilor. Chestionarul nu are o arie largă de
utilizare [2].
flux de date: este constituit din datele transmise între două procese.
Fluxul de date este etichetat printr-un substantiv ce sugerează informaţia sau
pachetul de informaţii transmise.
if (cod!=FACTURI_DESF.codclient)
{ CLIENTI.codclient = cod;
CLIENTI.denclient = den;
CLIENTI.adresac = adr;
CLIENTI.contc = cont;
CLIENTI.banca_c = banca;
CLIENTI.sold = sold;
cod = FACTURI_DESF.codclient;
den = FACTURI_DESF.denclient;
adr = FACTURI_DESF.adresac;
cont = FACTURI_DESF.contc;
banca = FACTURI_DESF.bancac;
}
else
{
READ(ÎNCASĂRI);
vb=0; vb1=0;
while (not eof (ÎNCASĂRI) AND vb=0)
{
if (cod=ÎNCASĂRI.client AND
FACTURI_DESF.nrfactd=ÎNCASĂRI.nrfactd AND
FACTURI_DESF.datafactd =ÎNCASĂRI.datafactd)
{ if (FACTURI_DESF.totalfactd !=ÎNCASĂRI.sumaincasata)
{ sold = sold+ FACTURI_DESF.totalfactd -
ÎNCASĂRI.sumaincasata}
vb1=1;
}
else if (vb1=1) vb=1
READ (ÎNCASĂRI)
}
MOVE FIRST LINE ÎNCASĂRI
READ (FACTURI_DESF)
}
CLOSE (FACTURI_DESF, ÎNCASĂRI, CLIENTI)
La fel putem spune şi despre evenimente. Ele reprezintă asocieri între două sau mai
multe obiecte. Exemplu: CLIENT COMANDĂ PRODUS.
Entităţile conţin în structura lor atributele prin care ele sunt descrise.
O entitate este o persoană, un loc, un obiect, eveniment sau concept din domeniul
de activitate a utilizatorului despre care organizaţia doreşte să păstreze anumite date. Se
cuvine precizată diferenţa dintre tipurile entităţilor (entity types) şi cazurile/instanţele
entităţii (entity instances) [1].
Tipul entităţii, cunoscut şi sub numele de clasa entităţii, este o colecţie de entităţi
care au proprietăţi sau caracteristici comune. Fiecărui tip de entitate i se atribuie un nume.
Cât timp numele reprezintă o clasă sau un set de cazuri, el este singular. Şi încă o
convenţie. Cum referirea generală la elementele ce pot fi catalogate ca entităţi se poate
face prin noţiunea de obiect (deşi sensul lui poate fi altul în contextul analizei şi
proiectării orientate obiect), referirea la acesta se va realiza printr-un substantiv la
singular. Se vor folosi litere majuscule, plasate în interiorul dreptunghiului corespunzător
entităţii.
O instanţiere a entităţii sau instanţă, denumită de noi în continuare, caz al entităţii
sau caz, este o manifestare singulară a unui tip de entitate. Un tip de entitate se descrie o
singură dată prin modelul datelor, în timp ce mai multe cazuri ale acelui tip de entitate pot
fi reprezentate prin datele stocate în bazele de date. De exemplu, există o singură entitate
CLIENT, dar ea poate să aibă sute sau mii de cazuri/instanţe ale acestei entităţi stocate în
baza de date.
Atribute
Fiecare tip de entitate are un set de atribute asociate lui.
Un atribut este o proprietate sau o caracteristică a unei entităţi care prezintă interes
pentru organizaţie. La rândul lor, şi relaţiile pot avea propriile lor atribute.
Exemplu de entitate pentru aplicaţia DECONTĂRI şi unele dintre atributele
posibile:
CLIENT : CodClient, DenClient, AdresaC
Ca şi numele tipurilor entităţilor, numele atributelor sunt substantive scrise cu
majuscule, plasate în interiorul elipselor, legate de entitatea căreia i se asociază. De multe
ori însă, chiar şi în cazul folosirii produselor CASE, pentru a nu se încărca o diagramă
entitate-relaţie, se evită prezentarea atributelor. Operaţiunea se face, în schimb, în
repository, depozitul de informaţii despre proiect. Aici orice atribut se descrie separat, ca
orice obiect distinct.
Unul dintre exemplele anterioare poate fi reprezentat în diagramă conform fig. 3.5.
DenClien
t
CLIENT AdresaC
CodClient
Figura 3.5. Model de reprezentare a atributelor DER
Relaţiile entităţilor
Relaţiile reprezintă legăturile între componentele unei diagrame entitate-relaţie. O
relaţie este o asociere între cazurile/instanţele uneia sau mai multor tipuri de entităţi care
prezintă interes pentru organizaţie. Ele se pot simboliza printr-un romb. De regulă,
relaţiile sunt redate prin verbe.
Cardinalitatea relaţiilor
DATA PROMOVĂRII
DATA PROMOVĂRII
Tipuri de relaţii
Din cele prezentate mai sus, rezultă că între entităţile descrise, luate două câte
două, se pot identifica trei tipuri de relaţii: unu-la-unu, unu-la-multe, multe-la-multe. În
diagrame, descrierea relaţiilor se face de-a lungul liniilor care leagă cele două entităţi.
Simbolul vârf-de-săgeată este cunoscut ca indicator al cardinalităţii (cardinality
indicator).
În cele ce urmează sunt prezentate exemple de tipuri de relaţii [1].
implică ARTICOL
VÂNZARE
face parte din VÂNDUT
oferă
PRODUS FURNIZOR
este cumpărat de la
Figura 3. 12. Descrierea relaţiilor multiple între două entităţi
4. Relaţii opţionale şi obligatorii
Alteori, relaţiile dintre entităţi nu-şi fac simţită prezenţa în toate situaţiile. Chiar
cazul cu studiile la care lucrează diverse persoane este destul de elocvent; o persoană
poate să lucreze la un singur studiu sau la câteva, sau la niciunul şi, invers, un studiu
poate fi efectuat de o persoană, de mai multe sau de nici una. În astfel de situaţii, se
apelează la următoarea formă de reprezentare. (fig. 3.13)
lucrează la
PERSOANA STUDIU
este realizat de
Figura 3.13. Exemplu de relaţie opţională
Cercul suprapus pe latura entităţii indică, de fapt, poziţia 0 (valoarea minimă poate
fi şi zero), conferind relaţiei caracterul opţional.
Un alt aspect se referă la caracterul obligatoriu al relaţiilor. Cu alte cuvinte, o
entitate poate exista fără cealaltă?
Să luăm exemplul vânzărilor. În relaţia 1:M, dintre VÂNZARE şi
ARTICOL_VÂNDUT. Ar fi total eronat ca o entitate să existe fără cealaltă: nu poate fi o
vânzare fără cel puţin un articol vândut şi, invers, un articol nu poate fi vândut fără o
vânzare (operaţiunea nu ar avea sens). Simbolul folosit pt a marca relaţiile obligatorii este
acelaşi cerc, cu deosebirea că este haşurat.
ARTICOL
VÂNZARE
VÂNDUT
Figura 3.14. Exemplu de relaţie obligatorie
coordonator al
ANGAJAT
raportează la
Figura 3.15. Redarea relaţiei unei entităţi cu ea însăşi
PRODUCŢIA
ALTORA
MARFA
PRODUCŢIA
Figura 3.16. Exemplu de diagramă pentru relaţiile alternative
PROPRIE
Citirea diagramei este:
“O marfă se poate asocia sau cu un producător din afară, sau cu producţia unităţii”
“Un producător din afară poate livra mai multe mărfuri”
“O linie proprie de producţie poate livra mai multe mărfuri”
Deşi diagramele entitate-relaţie se cunosc de către mulţi specialişti din lumea bazelor de
date, ele constituie unul din conceptele esenţiale ale analizei şi proiectării
structurate şi, ca atare, provin din acest domeniu [1].
După cum reiese şi din citirea cu atenţie a numelui diagramei, scopul ei este de a
evidenţia entităţile de date (obiectele despre care se solicită păstrarea datelor) şi relaţiile
ce există între ele.
<nume tip
entitate> Apartenenţa atributului <nume atribut>
la tipul de entitate <nume tip entitate>
<nume
atribut>
Superclas
a
Contabilitate şi informatică de gestiune Apartenenţa subclasei la superclasă 53
Subclasa
Problemă rezolvată
m n
Oferte
FURNIZORI PRODUSE
m Vânzări n
PRODUSE VANZARI CLIENTI
PRODUSE STOCURI
1
Contabilitate şi informatică de gestiune Ieşiri n 54
Desfacere
Fig. 3.21. Subsistemul Urmărirea stocurilor.
Reprezentarea relaţiilor de tip 1-n Intrări, Ieşiri, pentru actualizarea stocurilor
Nicolae Morariu
Denumire Descriere
Cod produs
produs produs
PRODUSE
Stradă Număr
Localitate
Oferta
PRODUSE
CAPITOLUL 4
În cadrul acestui capitol este realizată prezentarea noului sistem prin prezentarea
tuturor intrărilor sistemului, a ieşirilor, precum şi a interfeţelor şi dialogurilor. Având în
vedere intrările şi ieşirile sisemului este prezentată proiectarea logică a bazei de date,
activitate prin care se urmăreşte transformarea diagramelor entitate-relaţie în relaţii.
Dacă în primele etape, au fost identificate şi structurate cerinţele sistemului, în faza
de proiectare logică se efectuează deplasarea atenţiei de la prezentarea a ceea ce există şi
ce se intenţionează la descrierea a ceea ce va însemna noul sistem, cum va funcţiona.
Modul de percepere a noului sistem se va reda prin prezentarea tuturor intrărilor
sistemului, a ieşirilor, precum şi a interfeţelor şi dialogurile. Ele se construiesc pe baza a
ceea ce s-a identificat în etapele anterioare, dar ţinându-se cont şi de cerinţele identificate
în timpul desfăşurării activităţilor din etapa de proiectare logică [1].
Toate intrările şi ieşirile sistemului, în faza de proiectare logică, vor fi prezentate ca
fluxuri ale datelor între un proces manual şi altul automat sau între o sursă/ destinaţie şi
un proces automat din diagramele fluxurilor de date. De regulă se poate proiecta câte un
formular sau raport pentru fiecare flux de date dintre utilizator şi sistem.
Documentaţia realizată în cadrul acestei etape constituie proiectul tehnic de
ansamblu al sistemului.
Respectarea unor cerinţe ale factorilor de decizie privind macheta situaţiei finale
O serie de cerinţe ale conducerii privind macheta situaţiei finale obligă proiectantul
la o anumită structurare şi machetare a situaţiilor finale. Informaţiile se pot împărţii în
două grupe prin prisma sistemelor informatice interne şi externe. Informaţiile interne
reprezintă acele informaţii culese, generate sau folosite în interiorul organizaţiei.
Informaţiile externe se referă la cele colectate sau create de la sau pentru parteneri străini
(facturi, rapoarte anuale, etc) [2].
În funcţie de informaţiile care pot fi văzute din punct de vedere al echipei
manageriale distingem: informaţii curente, de atenţionare, indicatori de bază, etc.
Restricţii tehnice
În proiectarea situaţiilor finale intervin o serie de restricţii datorate caracteristicilor
şi performanţelor tehnice ale echipamentelor periferice şi anume: numărul maxim de
caractere pe linie; numărul maxim de linii pe pagina / ecran; facilităţile de imprimare etc.
Pe piaţă se afla o gamă variată de echipamente de redare a rezultatelor. Există mai multe
tipuri de imprimante, console şi terminale video, ceea ce creează posibilitatea unei alegeri
adecvate a perifericelor destinate obţinerii diverselor tipuri de situaţii finale [2].
Elemente de eficienţă
În proiectarea situaţiilor finale nu trebuie sa scape atenţiei şi aspectele de eficientă
economică privind: reducerea timpului calculator consumat cu editarea propriu-zisa a
situaţiilor; economie de hârtie de imprimantă. Abilitatea şi experienţa proprie a
programatorilor joacă în acest sens un rol important.
În vederea optimizării obţinerii situaţiilor finale pe imprimantă se pot folosi de la
caz la caz, diverse tehnici cum ar fi: editarea mai multor tabele pe aceeaşi pagină de
imprimantă; editarea unei situaţii imprimând faţă/verso pe aceeaşi coală;
Pentru a nu irosi timp cu editarea unor situaţii finale voluminoase se recomandă
mai întâi rularea unor programe scurte care să verifice cheile de control aplicate. Numai
dacă aceste chei sunt corecte, eventual verificate şi de utilizator, se poate lansa editarea
analitica a situaţiilor finale. Programele care editează situaţii finale voluminoase trebuie
prevăzute cu posibilitatea de întrerupere (respectiv de reluare a editării în cazul unor
incidente ivite în timpul rulării) sau editarea lor sub forma unui fişier ASCII sau text pe
hard disc sau floppy disc, urmând imprimarea ulterioara a acestui fişier, total sau parţial
[2].
Lizibilitate – spaţiere
Parcurgerea unei situaţii finale trebuie să fie cât mai uşoara, “citirea” unei situaţii
nu trebuie să dea naştere la ambiguităţi. Este necesar ca situaţia sa fie autoexplicativă.
Pentru aceasta, antetul va conţine informaţii şi coduri ce vor indica sursa de emitere a
raportului, exprimând clar, sintetic, conţinutul raportului şi perioada la care se referă.
Capul de tabel, împreuna cu titlul şi antetul, se afişează pe următoarele pagini
numai dacă au intervenit schimbări în cadrul caracteristicilor de grupare faţă de prima
pagină, altfel se imprimă doar numerotarea coloanelor de tabel.
Informaţiile importante pot fi subliniate. Totalurile se separă de informaţiile
analitice. Informaţiile care se repetă pe linii succesive se imprimă o singură dată [2].
Utilizarea formularelor pretipărite
Aceasta implica utilizarea unei hârtii de imprimanta ce cuprinde elemente fixe ale
situaţiei finale, cum ar fi antetul, titlul, capul de tabel, textul explicativ etc. Aceasta
conduce la o creştere a vitezei de editare şi o diminuare a uzurii imprimantelor, riboanelor
etc. Totodată situaţiile obţinute sunt mai estetice şi sunt uşor de parcurs de utilizatori [2].
Utilizarea monitoarelor sau terminalelor video
Prin intermediul unui soft adecvat, monitoarele sau terminalele video oferă
posibilitatea afişării situaţiilor finale, atât în regim alfanumeric, cât şi în regim grafic,
alegerea modului de lucru făcându-se prin intermediul unor comenzi sau comutatori.
Ecranul unui terminal video în regim alfanumeric este alcătuit din linii şi coloane
iar în regim grafic ecranul este privit ca o matrice de puncte denumite “pixeli”.
Reprezentarea informaţiilor de ieşire sub forma grafică reprezintă un pas înainte
faţă de editarea sub forma de text a rapoartelor. Această formă de afişare se recomandă
factorilor de decizie de pe nivelele de conducere superioare, dat fiind gradul de sintetizare
a informaţiilor de ieşire şi volumul redus al rapoartelor.
Pe lângă problemele legate de aşezarea informaţiilor pe ecran, la proiectarea
ecranelor de ieşire se iau în considerare şi facilităţile oferite de monitoare sau terminalele
video şi anume: regimul de lucru (defilare ecran, pagina sau linie); regimul de afişare
(normal, mai luminos, cu intermitente, invers video); regimul de semnalizare sonoră
(normal, semnal sonor după afişarea unui câmp etc.) [2].
Utilizarea generatoarelor de rapoarte ( REPORT WRITER )
Multe limbaje de programare, pachete de programe şi sisteme de gestiune a bazelor
de date dispun de module specializate în editarea de rapoarte, ceea ce conduce la
reducerea considerabila a eforturilor programatorilor. De obicei, aceste generatoare
solicită precizarea titlului, antetului de coloană, conţinutul unui rând de date (de detaliu),
gradele de total şi maniera lor de afişare, la începutul sau la sfârşitul grupului de date, al
paginii sau raportului. De asemenea, se pot selecta dimensiunea unei linii, coloane,
pagini, spaţierea dintre linii, coloane, afişarea datelor privind momentul listării, statistici
etc.
Astfel de module specializate există în pachete de programe pentru gestionarea
bazelor de date cum ar fi: ACCESS, d’BASE, ORACLE, FOXPRO, PARADOX, etc.
4.1).
Figura 4.1. Formularul(macheta) de intrare pentru facturi
În proiectarea formularelor de intrare pot fi utilizate componente specializate în
acest sens din sistemele de gestiune a bazelor de date cum ar fi ACCESS, dBASE,
ORACLE, PARADOX precum şi programe scrise în diverse limbaje de programare.
Metode de interacţiune
Metodele cele mai utilizate sunt [1]:
interacţiunea prin limbaj-comandă (în acest tip de interacţiune utilizatorul transmite
calculatorului comenzile sub forma unui şir de caractere)
interacţiunea prin meniuri(utilizatorul transmite comenzile sale calculatorului prin
intermediul unui sistem de meniuri şi opţiuni de meniu sau folosind scurtături sub
formă de combinaţii de taste).
interacţiunea bazată pe obiecte icons(comunicarea se face prin intermediul desenelor.
Imaginile folosite funcţionează ca butoanele, la apăsarea lor se activează o
anumită funcţie sau comandă)
interacţiunea prin limbaj natural(comenzile se transmit folosind vocea şi
sintetizatoarele de voce pentru redarea rezultatelor)
Proiectarea dialogurilor
Proiectarea dialogurilor este procesul prin care sunt proiectate toate secvenţele
folosite de utilizator pentru a comunica cu un sistem informatic. Rolul proiectantului este
de a selecta cele mai potrivite metode şi echipamente, precum şi de a prezenta condiţiile
în care se pot afişa informaţiile sau se pot obţine de la utilizator.
MO1
MENIU_PRINCIPAL
MO2
PO2 PO1
MENIU_INTERO
GARE
ADĂUGARE ŞTERGERE
PO4 PO3
Pagina 1
COD PRODUS
CANTITĂŢI_DE_LIVRAT
A1111 0
A2222 0
B1111 150
Y9999 100
PRODUS(COD_PRODUS)
COMANDA(NR_COMANDA, DATA_COMANDA)
LINIE_COMANDA(NR_COMANDA, COD_PRODUS,
CANTITATE_COMANDATA)
LIVRARE(COD_PRODUS, NR_FACTURA, CANTITATE_LIVRATA)
FACTURA(NR_FACTURA, DATA_FACTURA)
CLIENT(COD_CLIENT, NUME)
PRODUS(COD_PRODUS)
FACTURA(NR_FACTURA, DATA_FACTURA)
COMANDA(NR_COMANDA, COD_CLIENT, DATA_COMANDA)
LINIE_COMANDA(NR_COMANDA, COD_PRODUS,
CANTITATE_COMANDATA)
LIVRARE(COD_PRODUS, NR_FACTURA, CANTITATE_LIVRATA)
CLIENT FACTURA
Lansează Facturare
CANTITATE_LIV
COMANDA Livrar
NR_COMANDA
e
COD_PRODUS DENUMIRE
CANTITATE_
COMANDATA
Nicolae Morariu
Pasul al patrulea compară modelul obţinut din pasul doi cu cel din pasul trei şi
integrează perspectivele utilizatorilor în vederea obţinerii unui model logic final, după
cum urmează:
CLIENT(COD_CLIENT, NUME, ADRESA)
PRODUS(COD_PRODUS, DENUMIRE)
FACTURA(NR_FACTURA, NR_COMANDA, DATA_FACTURA)
COMANDA(NR_COMANDA, COD_CLIENT, DATA_COMANDA)
LINIE_COMANDA(NR_COMANDA, COD_PRODUS,
CANTITATE_COMANDATA)
LIVRARE(NR_FACTURA, COD_PRODUS, CANTITATE_LIVRATA)
Dependenţe funcţionale
Penru definirea acestui tip de dependenţe se consideră schema de relaţie
Prestari_Servicii (Cod, Nume_client, Adresa, Serviciu_prestat, Valoare)
definită pentru urmărirea serviciilor prestate de o firmă pentru diverşi clienţi.
Atributul Adresa este dependent de atributul Nume_client (presupunând că fiecare client are
o singură adresă, rezultă că fiecare valoare a atributului Nume_client determină în mod
unic valoarea corespunzătoare a atributului Adresa). Analizând schema de relaţie de mai
sus, se constată o redundanţă relativ la atributul Adresa a cărei valoare este repetată pentru
un client pentru fiecare serviciu prestat pentru acest client, ceea ce conduce la apariţia
următoarelor anomalii:
- Anomalia la adăugare:
adresa unui client poate fi preluată numai după ce pentru acesta se prestează cel puţin un
serviciu.
- Anomalia la ştergere:
dacă se şterg toate serviciile prestate pentru un anumit client, se pierde adresa acestui client.
- Anomalia la actualizare:
datorită redundanţei relativ la atributul Adresa, dacă se schimbă adresa unui client este
necesară parcurgerea întregii relaţii pentru a identifica şi actualiza toate apariţiile acestui
client, în caz contrar baza de date devine inconsistentă (acelaşi client poate apare la adrese
diferite).
Aceste anomalii pot fi eliminate, dacă schema de relaţie Prestari_Servicii se
înlocuieşte prin următoarele două scheme de relaţie:
Clienti(Cod, Nume_client,
Adresa)
Servicii(Cod, Serviciu_prestat,
Valoare).
Relaţia Clienti conţine codul, numele şi adresa fiecărui client, fără nici un fel de
redundanţă, iar relaţia Servicii conţine serviciile prestate pentru fiecare client şi valorile
acestor servicii. Un dezavantaj al descompunerii relaţiei iniţiale în cele două relaţii este
acela că pentru a determina adresa clientului pentru care s-a prestat un anumit serviciu
este necesară efectuarea unei operaţii de cuplare a relaţiilor Clienti şi Servicii.
Se consideră o schemă de relaţie R şi A,B două atribute simple sau compuse ale schemei
de relaţie R. Atributul A determină funcţional atributul B sau B depinde funcţional de A,
dacă şi numai dacă oricărei valori a atributului A îi corespunde o singură valoare a
atributului B (se notează A->B).
Dependenţa funcţională A->B este totală dacă nu există nici un subset C al
atributului A (CcA) astfel încât C->B şi este parţială în caz contrar.
În relaţia Prestari_Servicii, una din dependenţele funcţionale care poate fi pusă în
evidenţă este Nume_client->Adresa.
Deoarece într-o relaţie orice cheie identifică în mod unic fiecare tuplă a relaţiei,
deci determină în mod univoc valorile atributelor tuplei, rezultă că în orice relaţie
atributele sunt dependente funcţional faţă de cheile acesteia.
Se pot face, până în acest moment, următoarele precizări:
Eliminarea dependenţelor funcţionale din schemele de relaţie şi a consecinţelor
negative (redundanţa datelor; anomaliile de adăugare, ştergere, actualizare) se realizează
prin descompunerea schemei date într-o colecţie de scheme mai simple în care sunt evitate
neajunsurile mai sus menţionate. Reconstituirea relaţiei iniţiale se poate face prin operaţia
de cuplare (uniune). Pentru ca descompunerea schemei de relaţie să fie echivalentă cu
relaţia iniţială, trebuie să fie îndeplinite condiţiile:
- cuplare fără pierdere de informaţie;
- conservarea dependenţelor (dependenţele funcţionale din relaţia
iniţială trebuie să se regăsească în relaţiile rezultate prin descompunere).
Formele normale sunt scheme de relaţie echivalente obţinute prin descompunerea
unor scheme de relaţie în vederea eliminării redundanţei datelor şi anomaliilor la
adăugare, actualizare, ştergere înregistrări în baza de date. Descompunerile schemelor de
relaţii în scheme de relaţii echivalente având în vedere dependenţele funcţionale conduc
la definirea primelor 4 nivele de forme normale şi anume: prima formă normală (FN1), a
doua formă normală (FN2), a treia formă normală (FN3) şi forma normală Boyce-
Codd (FNBC).
A patra formă normală (FN4) este definită având în vedere dependenţele
multivalorice, iar a cincea formă normală (FN5) este definită având în vedere
dependenţele de cuplare. Începând de la prima formă normală şi până la forma normală FN5
se impun condiţii din ce în ce mai restrictive asupra relaţiilor. Astfel o relaţie aflată pe un
anumit nivel de normalizare (FN5) satisface toate restricţiile cerute de nivele inferioare de
normalizare (FN1, FN2, FN3, FNBC, FN4). În cele ce urmează sunt date definiţiile
formelor normale având în vedere dependenţele funcţionale.
O relaţie R este în prima formă normală (FN1) dacă şi numai dacă toate
atributele sale iau numai valori atomice (nu pot fi descompuse). Spre exemplu, atributul
Adresa ar putea fi considerat un atribut neatomic dacă în cadrul adresei ne-ar interesa
localitatea, strada etc., caz în care trebuie descompus în atribute atomice.
O relaţie R este în a doua formă normală (FN2) dacă este în FN1 şi orice atribut
neprim este total dependent faţă de orice cheie a relaţiei (atributele prime sunt atribute care
fac parte dintr-o cheie a relaţiei şi cele neprime sunt atributele care nu aparţin nici unei chei
a relaţiei).
O relaţie R este în a treia formă normală (FN3) dacă este în FN2 şi nici un atribut
neprim nu este funcţional dependent faţă de un alt atribut neprim al relaţiei.
O relaţie R se află în forma normală Boyce-Codd (FNBC) dacă singurele
dependenţe funcţionale admise sunt cele în care o cheie determină un alt atribut (nici un
atribut prim sau neprim nu poate fi dependent funcţional faţă de un alt atribut dacă acesta
nu este sau nu conţine o cheie).
Dependenţe multivalorice
Pentru ilustrarea acestui tip de dependenţe se ia în considerare următoarea schemă
de relaţie:
Clase(Clasa, Discipline, Elevi)
ce conţine clasele dintr-o instituţie de învăţământ, iar pentru fiecare clasă sunt înregistrate
disciplinele ce se predau şi elevii înmatriculaţi în clasa respectivă. Se poate constata că
relaţia Clase poate rezulta prin operaţia de cuplare după atributul Clasa a următoarelor
două relaţii:
CD(Clasa, Discipline)
CE(Clasa, Elevi)
În relaţia Clase, presupunând că pentru o clasă dată, fiecare elev frecventează toate
disciplinele înregistrate pentru acea clasă, există dependenţele multivalorice:
Clasa ->> Discipline
Clasa ->> Elevi.
Ca şi în cazul dependenţelor funcţionale, existenţa dependenţelor multivalorice prezintă
aceleaşi neajunsuri privind redundanţa datelor şi anomalii la efectuarea operaţiilor de
adăugare, actualizare şi ştergere înregistrări în baza de date.
O relaţie R este în a patra formă normală dacă singurele dependenţe multivalorice
admise sunt cele determinate de un alt atribut care este o cheie sau care conţine o cheie a
relaţiei.
Întrucât orice dependenţă funcţională este un caz particular de dependenţă
multivalorică, rezultă că orice relaţie care se află în forma normală FN4, se află şi în forma
normală FNBC. Transformarea unei relaţii într-o colecţie de relaţii care să se afle în FN4
este similară cu trecerea în FNBC, însă trebuie avută în vedere atât eliminarea
dependenţelor funcţionale cât şi a dependenţelor multivalorice.
În concluzie, putem afirma că în cazul formelor normale de la FN1 la FN4,
trecerea de la o formă normală la alta s-a făcut prin descompunerea unei relaţii în altele
două, urmărindu-se eliminarea dependenţelor funcţionale şi multivalorice. O relaţie aflată în
forma normală FN4 nu mai poate fi descompusă în continuare pe baza acestei metode.
Există situaţii când relaţii aflate în FN4 conţin redundanţe şi prezintă anomalii la operaţiile
de adăugare, ştergere şi actualizare. Aceste anomalii sunt cauzate de existenţa
dependenţelor de cuplare şi pot fi eliminate prin descompunerea relaţiei în 3 sau mai multe
relaţii a căror cuplare are ca rezultat relaţia iniţială.
Dependenţe de cuplare
normalizarea completă, până la FN5, s-ar putea să fie dezavantajoasă. Având în vedere
constatările de mai sus se poate afirma că deşi normalizarea nu reprezintă o soluţie
general valabilă în orice situaţie, totuşi dacă pentru proiectarea bazei de date se
aplică corect o metodologie de proiectare descendentă, modelul rezultat va fi de la sine
normalizat. Cercetările în acest domeniu continuă, fiind definite şi alte forme normale printre
care FN6 pentru baze de date temporale. O bază de date temporală, pe lângă datele curente,
conţine şi date istorice, iar factorul (atributul) timp are un rol esenţial (exemple concludente
de astfel de baze de date sunt depozitele de date). Astfel, în proiectarea unei baze de date
temporale trebuie avute în vedere şi alte operaţii de descompunere a schemelor de relaţie şi
anume:
- descompunerea orizontală – pentru separarea datelor curente de datele
istorice;
- descompunerea verticală – pentru separarea atributelor aceleiaşi entităţi
având în vedere valorile lor raportate la atributul temporal.
În proiectarea unei baze de date nu este exclusă nici operaţia inversă normalizării
numită denormalizare [12], prin care se urmăreşte înlocuirea unei colecţii de scheme de
relaţie cu o schemă de relaţie echivalentă în vederea eliminării necesităţii efectuării unor
operaţii de cuplare care pot fi costisitoare. Dacă în cazul normalizării tendinţa este de a
ajunge la nivele cât mai înalte (FN5), pentru denormalizare nu există criterii clare putând
fi avute în vedere doar aspecte legate de performanţele anumitor aplicaţii.
Un alt principiu care se urmăreşte în proiectarea unei baze de date este principiul
proiectării ortogonale conform căruia în cadrul unei baze de date două scheme de relaţie
reale (variabile de relaţie de bază) nu trebuie să aibă semnificaţii suprapuse. În timp ce
prin normalizare se urmăreşte reducerea redundanţei din cadrul unei scheme de relaţie,
prin proiectarea ortogonală se urmăreşte reducerea redundanţei dintre schemele de relaţie.
Definirea domeniului
Un domeniu este o mulţime de valori caracterizată printr-un nume. Un domeniu se
poate defini explicit prin enumerarea tuturor valorilor aparţinând acestuia sau definind o
proprietate distinctivă a domeniului valorilor, de cele mai multe ori limita superioară şi
limita inferioară [Popescu I, 1996]. De exemplu:
D1: {“F”,”M”} -definire explicită
D2: {x| x∈N, x∈ [0,100]} -definire implicită
D3: {s|s=şir de caractere} -definire implicită
Pentru un ansamblu de domenii D1,D2,…,Dn produsul cartezian al acestora
reprezintă ansamblul tuplurilor (elemente ale unei relaţii) <v1,v2,…,vk> unde vi este un
element care aparţine domeniului Di. De exemplu, tuplurile <“Maria”,”F”,”50” >,<
“Vasile”,”M”,”60”> aparţin produsului cartezian D3xD1xD2.
Definirea relaţiei
O relaţie R pe mulţimile D1,D2,…,Dn este o submulţime a produsului cartezian
D1xD2x…xDn, deci o mulţime de tupluri [Popescu I, 1996].
Considerând că nu se cunosc decât două persoane, relaţia R se defineşte prin
tuplurile care descriu aceste persoane, şi anume:
R: {<“Maria”,”F”,”50”>,<“Vasile”,”M”,”60”>}
O relaţie poate fi reprezentată printr-un tabel bidimensional în care fiecare linie
corespunde unui tuplu şi fiecare coloană corespunde unui domeniu.
R: D3 D1 D2
“Maria” “F” 50
“Vasile” “M” 60
Definirea atributului
În timp ce tuplurile dintr-o relaţie trebuie să fie unice, un domeniu poate apare de
mai multe ori în produsul cartezian pe baza căruia este definită relaţia [Popescu I, 1996].
PERS D3 D1 D2 D3
“Maria” “F” 50 “Vasile”
“Vasile” “M” 60 “Maria”
CAPITOLUL 5
automat de către sistem după fiecare operaţie, fie printr-o comandă explicită dată după o
succesiune de operaţii. Astfel salvarea automată de către sistem a modificărilor este
realizată prin comanda
SET AUTOCOMMIT ON
Dacă iniţial a fost specificată comanda SET AUTOCOMMIT OFF, salvarea modificărilor
efectuate asupra datelor se realizează prin comanda COMMIT, iar abandonarea
modificărilor se realizează prin comanda ROLLBACK.
Blocul de operaţii ce definesc o tranzacţie poate fi delimitat de instrucţiunile :
BEGIN TRANSACTION
END TRANSACTION
Problemă rezolvată
Se lansează în execuţie SQL Plus Oracle sub utilizatorul system (figura 5.1).
În baza de date ORCL sub S.G.B.D. Oracle se crează utilizatorul U1 identificat prin
parola PW1 şi i se acordă privilegiile CONNECT, RESOURCE (figura 5.2).
Se închide sesiunea de lucru SQL Plus a utilizatorului system (cu instrucţiunea EXIT)
şi se deschide o nouă sesiune de lucru SQL Plus pentru utilizatorul U1
(figura 5.3).
Se crează tabela Produse şi se inserează două înregistrări (figura 5.4).
ORCL
ORC
L
[WHERE <condiţie>]
[GROUP BY <lista atribute de grupare>]
[HAVING <condiţie>]
[ORDER BY <atribut1 de ordonare> [ASC]|DESC,…]
[UNION <frază SELECT>]
<lista atribute> este o listă ce conţine nume de atribute (câmpuri) sau expresii
construite utilizând atribute, separate prin caracterul “,” şi care fac parte din relaţiile
(tabele, vederi) enumerate în <lista relaţii> din clauza FROM. Numele fiecărui atribut sau
expresii din <lista atribute> va fi afişat în capul de tabel ce reprezintă rezultatul
interogării, fiecare atribut sau expresie putând primi un alias folosind specificarea AS
<alias>.
Caracterul ‘*’ specifică faptul că se extrag toate atributele tabelei precizate în
clauza FROM.
Clauza DISTINCT precizează faptul că în relaţia rezultat nu pot apărea duplicate
(tuple identice).
Clauza WHERE precizează condiţiile de interogare (condiţii care trebuie să fie
satisfăcute de tuplele interogate, condiţii de cuplare relaţii (JOIN, relaţii între tabele). În
clauza WHERE pot fi utilizaţi operatori logici (AND, NOT, OR), predicate (IN, LIKE,
BETWEEN, EXISTS, ALL, ANY), operatori aritmetici (+, -, **, /, *), operatori de
comparare (=, #,<, >, <=, >=, <>), parantezele ( ) pentru schimbarea ordinii de prioritate a
operaţiilor, operatorilor, funcţii şi alte subinterogări SELECT, pentru construirea de
expresii pe care trebuie să le îndeplinească tuplele ce constituie rezultatul interogării.
Predicatul IN permite specificarea unei liste pentru domeniul de căutare pentru un atribut,
iar predicatul BETWEEN permite specificarea unui interval pentru domeniul de căutare a
valorilor unui atribut, fiind echivalent cu o condiţie de forma:
<atribut> >= <limita inf. interval> AND <atribut> <= <limita sup. interval>
Exemple:
Fie tabela Persoane(Nrcrt,Nume,Prenume, Datan, Sexul, Adresa)
Selectarea tuturor înregistrărilor din tabela Persoane pentru care primele 7 caractere din
câmpul Adresa sunt ‘Suceava’ sau ‘Rădăuţi’ se realizează cu comanda:
SELECT * FROM Persoane
WHERE SUBSTR(Adresa,1,7) IN (‘Suceava’,‘Rădăuţi’)
Interogarea de mai sus este echivalentă cu interogarea:
SELECT * FROM Persoane
WHERE SUBSTR(Adresa,1,7) = ‘Suceava’ OR SUBSTR(Adresa,1,7) =
‘Rădăuţi’
Selectarea tuturor înregistrărilor din tabela Persoane pentru care data naşterii este
cuprinsă între 01/01/72 şi 01/01/82 se realizează astfel:
SELECT * FROM Persoane WHERE Datan BETWEEN {01/01/72} AND
{01/01/82}
Interogarea de mai sus este echivalentă cu interogarea:
SELECT * FROM Persoane WHERE Datan >= {01/01/72} AND Datan <=
{01/01/82}
Predicatul LIKE permite selecţia şirurilor de caractere care conţin anumite caractere
specificate prin intermediul unei măşti definite cu ajutorul unor caractere speciale (%, _
în dBASE IV, FoxPro, ORACLE, sau *, ? în INFORMIX)
Exemple:
SELECT * FROM Persoane WHERE Nume LIKE ‘%a’
(selectează toate înregistrările din tabela Persoane pentru care valorile atributului Nume
se termină cu litera ‘a’).
SELECT Nume,Prenume,Datan FROM Persoane WHERE Nume LIKE ‘A%u’
(selectează valorile atributelor Nume, Prenume, Datan pentru toate înregistrările din
tabela Persoane pentru care prima literă din Nume este ‘A’ iar ultima literă este ‘u’).
SELECT Nume FROM Persoane WHERE Nume LIKE ‘_o%’
(selectează valorile atributului Nume pentru toate înregistrările din tabela Persoane pentru
care prima literă din Nume este orice literă, a doua literă din Nume este litera ‘o’ şi
începând din poziţia a treia numele poate conţine orice litere.)
Predicatele ALL, ANY, EXISTS se utilizează pentru interogări ce conţin subinterogări, în
vederea verificării anumitor condiţii ce trebuie îndeplinite între rezultatele interogării şi
rezultatele subinterogării.
Clauza GROUP BY – realizează gruparea tuplelor unei relaţii pe baza valorilor
unui atribut sau grup de atribute şi generează o singură tuplă pentru fiecare grup de tuple
având aceeaşi valoare pentru atributele care definesc grupul. Atributele care definesc
grupul trebuie obligatoriu să se regăsească în lista atributelor interogate <lista atribute>.
De asemenea asupra unor atribute pot fi aplicate funcţii agregat:
- AVG(<atribut>) – media valorilor atributului specificat ca parametru, pe
grup;
- SUM(<atribut>) – suma valorilor atributului specificat ca parametru, pe grup;
- MAX(<atribut>) – maximum valorilor atributului specificat ca parametru, pe
grup;
- MIN(<atribut>) – minimum valorilor atributului specificat ca parametru, pe
grup;
- COUNT(<atribut>) – numărul înregistrărilor pe grupare după <atribut>.
Observaţie. <atribut> poate fi fie un atribut, fie o expresie definită utilizând atribute ale
tabelei.
Clauza HAVING, opţiune a clauzei GROUP BY, este o formă specială a clauzei
WHERE întrucât se aplică unor grupuri de tuple (şi nu unor tuple) definite de clauza
GROUP BY.
Exemple:
Fie tabela Stocuri(CodDep,CodP,UmP,Cant,Pret)
SELECT CodDep,SUM(Cant*Pret) AS Valoare,COUNT(CodDep) AS Contor
FROM Stocuri GROUP BY CodDep
(Calculează suma produselor Cant*Pret pentru toate tuplele având aceeaşi valoare în
câmpul CodDep şi numărul înregistrărilor din fiecare grup definit de câmpul CodDep şi
afisează rezultatele sub formă de tabel având coloanele CodDep, Valoare, Contor)
Fiecărei tabele i se poate atribui un alias astfel încât fraza de mai sus este echivalentă cu
fraza:
SELECT A.CodP,DenP,UmP,Cant,Pret FROM Produse A,Stocuri B WHERE A.CodP =
B.CodP
În anumite situaţii poate fi necesară corelarea (cuplarea) unei relaţii (tabele) cu ea
însăşi. Spre exemplu dacă presupunem că în tabela Stocuri unele produse pot apare de
mai multe ori cu preţuri diferite şi ne interesează poziţiile cu preţul minim, formulăm
următoarea interogare:
SELECT A.CodP,A.Cant,A.Pret FROM Stocuri A
WHERE A.Pret = (SELECT MIN(B.Pret) FROM Stocuri B WHERE A.CodP =
B.CodP)
Pentru rezolvarea unor astfel de probleme s-au utilizat instrucţiuni SELECT imbricate
care vor fi prezentate în detaliu în cele ce urmează.
Instrucţiuni SELECT imbricate
Limbajul SQL oferă posibilitatea construirii unor interogări complexe prin
includerea în clauza WHERE a unei instrucţiuni SELECT, a altei instrucţiuni SELECT
(numită sub-interogare sau ‘inner’) astfel:
SELECT <lista atribute> FROM <lista relaţii>
WHERE <condiţie> (<sub-interogare>)
La rândul ei sub-interogarea poate conţine în clauza WHERE o altă instrucţiune SELECT
obţinând astfel o interogare complexă constituită din instrucţiuni SELECT imbricate pe
un număr oarecare de nivele. Instrucţiunea SELECT interioară generează valori pentru
condiţia de căutare a instrucţiunii SELECT exterioare care o conţine (numită şi ‘outer’). O
sub-interogare poate returna o singură valoare, sau poate returna mai multe valori.
În ce priveşte ordinea de evaluare a interogărilor pot exista :
- sub-interogări simple - în care interogarea interioară este evaluată prima,
independent de interogarea exterioară, iar rezultatul interogării interioare este utilizat
de interogarea exterioară;
- sub-interogări corelate - în care interogarea exterioară transmite repetat câte o
valoare pentru interogarea interioară, care în baza valorii primite, parcurge tuplele
relaţiei şi transmite interogării exterioare rezultatul obţinut. Astfel de interogări
realizează corelarea unei relaţii cu ea însăşi şi sunt cele mai performante.
Spre exemplu dacă presupunem că în tabela Stocuri unele produse pot apare de mai multe
ori cu preţuri diferite şi ne interesează poziţiile cu preţul minim, formulăm următoarea
interogare:
SELECT A.CodP,A.Cant,A.Pret FROM Stocuri A
WHERE A.Pret = (SELECT MIN(B.Pret) FROM Stocuri B WHERE A.CodP =
B.CodP)
Sub-interogări simple care returnează o singură valoare - pot fi utilizate în
interogări imbricate având sintaxa:
SELECT <lista atribute> FROM <lista relaţii>
WHERE <atribut> =
<
>
<=
>=
!=
(<sub-interogare>)
[ORDER BY <atribut[ASC]|DESC,…]
Exemplu:
SELECT CodDep,CodP,Cant FROM Stocuri
WHERE Cant > (SELECT AVG(Cant) FROM Stocuri ) ORDER BY CodDep
(afişează produsele pentru care există stocuri peste medie, ordonate pe depozite).
Sub-interogari simple care returneaza mai multe valori pot fi utilizate în
interogări imbricată care utilizează în clauza WHERE codiţii care generează o mulţime de
valori folosind unul din predicatele: (NOT)IN, (NOT)ANY, (NOT)ALL, (NOT)EXISTS.
Exemplu:
SELECT * FROM Produse WHERE CodP IN (SELECT CodP FROM Facturi WHERE
Numar IN
(SELECT Numar FROM Beneficiari,ComenziWHERE Beneficiari.Nume=’Ionescu’
AND
Beneficiari.Cod_Beneficiar=Comenzi.Cod_Beneficiar))
Predicatul ANY poate fi utilizat în combinaţie cu oricare din operatorii <, >, =,
<=, >=, != şi permite verificarea dacă valoarea unui atribut satisface condiţia precizată
pentru orice valoare din lista rezultată din subinterogare.
SELECT CodP FROM Stocuri WHERE Cant > ANY
(SELECT Cant FROM Stocuri WHERE CodDep = “D1”)
Predicatul ALL returnează toate tuplele pentru care valorile atributului din clauza
WHERE sunt <, >, <=, >= decât toate valorile generate de interogarea interioară (acest
predicat nu poate fi utilizat cu operatorul = ce ar corespunde cazului banal în care toate
interogările din listă sunt egale).
Exemplu:
SELECT * FROM Stocuri WHERE Cant < ALL
(SELECT Cant FROM Stocuri WHERE CodDep = “D1”)
Predicatul EXISTS verifică dacă pentru fiecare tuplă a relaţiei există tuple care
satisfac condiţia din interogarea interioară (deci EXISTS permite specificarea mai multor
atribute în interogarea interioară).
Astfel spre exemplu instrucţiunea:
SELECT * FROM Produse A WHERE NOT EXISTS
(SELECT * FROM Stocuri B WHERE B.CodP=A.CodP)
va returna o listă de produse care nu au nici o înregistrare în Stocuri.
recomandă evitarea conjuncţiilor din structura numelor, deoarece ele ar sugera necesitatea
folosirii mai multor module [1].
Logica modulului descrie prelucrările care au loc în interiorul acestuia [1].
La nivelul programării, preocuparea este, în esenţă, legată de logica modulului,
algoritmii de prelucrare, redaţi sub diverse forme – scheme logice, pseudocod, tabele de
decizie, arbori de decizie sau combinaţii ale acestora – sunt concepuţi pentru prezentarea
modului de transformare a intrărilor în ieşiri. Paşii algoritmilor se vor transforma în
instrucţiuni ale limbajelor de programare [1].
Interfeţele sunt conexiuni sau cuplaje între module. Interfeţele modulelor sunt
utilizate pentru stabilirea căilor prin care să se transfere controlul de la un modul la altul
[1].
Conexiunile dintre module se înregistrează pe două planuri:
al transferării controlului de la un modul la altul;
al transmiterii datelor de la un modul la altul.
În concluzie, se poate spune că eficienţa proiectelor – soft depinde în mare măsură
de eficienţa cu care se transferă controlul între module, precum şi de metoda folosită
pentru transmiterea datelor între module.
s1
s2
sn
NU DA
C
Bloc - 2 Bloc - 1
Iteraţia sau structura repetitivă defineşte execuţia repetată a unei operaţii sau grup
de operaţii, funcţie de rezultatul evaluării unei condiţii. Evaluarea condiţiei se face fie
înainte, fie după executarea operaţiilor.
Bloc -
1
C
DA
NU
Structura repetitivă condiţionată posterior (de tip DO UNTIL) are forma dinn
figura 5.5.
Bloc - 1
C
DA
NU
V=Vi
Bloc - 1
V=Vi+
R
V>Vf
NU
DA
Legătură/canal
NOD NOD
Sisteme PAD
Proiectare
Proiectare
subsisteme de
NODURI
COMUNICAŢII
Proiectare
INTERFEŢE
Figura 5.8. Principalele module de proiectare a sistemelor de prelucrare distribuită a
datelor [1]
astfel încât să poată folosi în comun toate echipamentele şi software-ul din reţea. Dintre
toate calculatoarele, există unul sau unele mai puternice pe care se vor afla aplicaţii
folosite în comun de celelalte calculatoare ale reţelei. Cea mai utilizată arhitectură este
arhitectura client/server.
Arhitectura client/server
Modelul Client /Server oferă date distribuite, portabilitate între platforme şi un
acces standardizat la resurse. Termenul de Client /Server provine de la metoda
tradiţională de accesare a unui computer central numit server de către computere aflate la
distanţă sau clienţi într-o infrastructură de reţea.
Modelul Client /Server implică o entitate software (clientul) care efectuează cereri,
acestea fiind îndeplinite de o altă entitate software(serverul) . Clientul este cel care
transmite o cerere severului, acesta o interpretează şi apoi o efectuează. Pentru a putea
îndeplini cererea, serverul poate referi o sursă de informaţie (baze de date), să efectueze
procesări asupra datelor, să controleze periferice sau să efectueze cereri adiţionale altor
servere. Un client poate face cereri la multiple servere şi un server poate deservi mai
mulţi clienţi.
calculatoare care rulează un sistem de gestiune a bazelor de date (DBMS), bazat pe SQL;
serverele de aplicaţii – calculatoare server care rulează programe mari de aplicaţii).
Sistemele client-server au apărut ca urmare a descentralizării activităţii din
diverse domenii, ceea ce presupune o repartizare a realizării sarcinilor pe cele două
nivele: client, server. De obicei clienţii reprezintă utilizatorii finali care vor
comunica cu serverul bazei de date în cadrul unei reţele de calculatoare. După rolul
pe care îl are fiecare din componentele client, server, se pot distinge trei arhitecturi
de bază pentru un sistem client-server (Loomis 1992) şi anume:
- arhitectura de tip server de obiecte – în care se distribuie prelucrarea între cele
două componente (server, client). Serverul este responsabil de administrarea
memoriei şi zăvoarelor, efectuarea operaţiilor în memoria secundară, securitatea,
integritatea şi recuperarea bazei de date, executarea procedurilor stocate şi
optimizarea interogărilor. Clientul este responsabil de administrarea tranzacţiilor şi
realizarea interfeţei cu limbajul de programare;
- arhitectura de tip server de pagini – cea mai mare parte a prelucrărilor este
realizată de către client. Serverul este responsabil de memoria secundară şi furnizează
paginile corespunzător cererilor formulate de client;
- arhitectura de tip server de bază de date – cea mai mare parte din prelucrările
bazei de date este efectuată de către server. Clientul transmite cererea serverului,
primeşte rezultatele şi le transmite aplicaţiei. Este modul utilizat frecvent de către
sistemele relaţionale.
În fiecare dintre cele trei cazuri serverul se găseşte pe aceeaşi maşină ca şi baza de
date fizică. Clientul se poate afla pe aceeaşi maşină sau pe una diferită. În cazul
bazelor de date distribuite pe mai multe maşini, clientul va comunica cu câte un
server de pe fiecare maşină. De asemenea mai mulţi clienţi pot comunica
concomitent cu acelaşi server (accesul concurent).
Arhitectura tradiţională a sistemelor client-server este o arhitectură pe două
nivele (etaje), în care la primul nivel (clientul) se realizează interfaţa cu utilizatorul şi
logica principală a aplicaţiei, iar la al doilea nivel (serverul) se realizează validarea
datelor şi accesul la baza de date. Necesitatea rezolvării unor probleme complexe care
presupun accesul la baza de date a unui număr mare de utilizatori, utilizarea unor
platforme hard-soft diferite, precum şi integrarea bazelor de date în mediul Web, au
impus definirea unei noi arhitecturi client-server în care sunt definite trei nivele şi anume:
- nivelul client, la care se realizează interfaţa cu utilizatorul aplicaţiei;
- nivelul server de aplicaţie, la care se realizează logica aplicaţiei şi prelucrării
datelor;
- nivelul server de baze de date, la care se realizează validarea datelor şi accesul
la baza de date.
Un server de aplicaţie poate servi mai mulţi clienţi, fiind conectat fizic atât la nivelul
client cât şi la nivelul server de baze de date. Spre exemplu în mediul Web, clientul poate
fi un browser Web, iar serverul de aplicaţie poate fi un server Web.
Problemă rezolvată
Se consideră baza de date FurnizoriClienţi care conţine următoarele tabele (în
ACCESS):
Câmp Codc Denc Adresac Codp Denp Ump Cant Pret Valoare Datav
Tabel Client Client Clienti Produs Produs Vanzari Vanzari Vanzari Cant*Pre Vanzari
a i i e e t
d) Lista produselor pentru care nu există oferte
Răspuns:
a)
SELECT CodDep, Stocuri.Codp, Denp, Ump, Cant, Pret, Cant*Pret AS Valoare
FROM Stocuri, Produse WHERE Stocuri.Codp = Produse.Codp
b)
SELECT Oferte.Codf, Denf, Adresaf, Oferte.Codp, Denp, Ump, Pret, Datao
FROM Oferte, Produse,Furnizori
WHERE Oferte.Codp = Produse.Codp AND Oferte.Codf = Furizori.Codf
c)
SELECT Vanzari.Codc, Denc, Adresac, Vanzari.Codp, Denp, Ump,Cant, Pret,
Cant*Pret AS Valoare, Datav FROM Vanzari, Produse,Clienti
WHERE Vanzari.Codp = Produse.Codp AND Vanzari.Codc = Clienti.Codc
d)
SELECT * FROM Produse WHERE NOT EXISTS
(SELECT * FROM Oferte WHERE Produse.Codp=Oferte.Codp)
e)
SELECT * FROM Produse WHERE NOT EXISTS
(SELECT * FROM Vanzari WHERE Produse.Codp=Vanzari.Codp
AND Datav BETWEEN Data1 AND Data2)
Teste 2006
Răspuns: a,c,d
3. Un sistem informatic este:
a) un sistem destinat conducerii unei organizaţii:
b) un sistem utilizator-calculator integrat, care furnizează informaţii pentru a sprijini
activităţile de la nivel operaţional şi activităţile de management într-o organizaţie,
utilizând echipamente hardware şi produse software, proceduri manuale, o bază
de date şi
modele matematice pentru analiză, planificare, control şi luarea deciziilor:
c) un ansamblu structurat de elemente intercorelate funcţional pentru automatizarea
procesului de obţinere a informaţiilor şi pentru fundamentarea deciziilor.
Răspuns: b,c
4. Identificaţi afirmaţia falsă:
a) Sistemul informaţional este subordonat sistemului de conducere.
b) Sistemul informaţional face legătura între sistemul condus şi sistemul de
conducere.
c) Sistemul informatic este inclus în sistemul informaţional.
d) Sistemul condus este subordonat sistemului informaţional.
Răspuns: d
5. Sunt componente principale ale unui sistem informatic:
a) Baza informaţională;
b) Manager general;
c) Baza tehnică;
d) Baza ştiinţifică metodologică;
e) Sistemul de programe.
Răspuns: a,c,d,e
6. Obiectivul principal urmărit prin introducerea unui sistem informatic îl constituie:
a) asigurarea conducerii cu informaţii reale şi în timp util necesare fundamentării
şi elaborării operative a deciziilor;
b) asigurarea funcţionării normale si optime a activităţilor;
c) creşterea productivităţii muncii;
d) creşterea profitului;
e) îmbunătăţirea imaginii unităţii economice.
Răspuns: a
7. După domeniul de utilizare, sistemele informatice se clasifică în:
a) Sisteme informatice pentru conducerea activităţilor economico-sociale;
b) Sisteme informatice pentru conducerea proceselor tehnice;
c) Sisteme informatice şi expert;
d) Sisteme informatice pentru activităţi speciale.
Răspuns: a,b,d
8. Sistemele informatice economice pot fi împărţite după modul de organizare a datelor
în:
a) sisteme imagine;
b) sisteme bazate pe tehnica bazelor de date (ierarhice, reţea, relaţionale,
orienatate-obiect);
c) sisteme bazate pe algoritmi fundamentali;
d) sisteme bazate pe fişiere.
Răspuns: b,d
9. Ciclul prelucrării datelor pentru sistemul informatic cuprinde următoarele faze:
a) culegerea datelor;
b) pregătirea datelor;
c) prelucrarea datelor;
d) ştergerea datelor.
Răspuns: a,b,c
10. În faza de întreţinere a fişierelor există mai multe activităţi, dintre care amintim:
a) memorarea(stocarea) datelor în vederea utilizării lor viitoare;
b) actualizarea datelor memorate astfel încât să surprindă cele mai recente
evenimente;
c) crearea datelor;
d) indexarea datelor pentru a înlesni o uşoară regăsire a lor;
e) protecţia datelor memorate, care cuprinde o mare varietate de proceduri şi
tehnici pentru prevenirea distrugerii lor sau a accesului neautorizat.
Răspuns: a,b,d,e
11. Metodologiile de realizare a sistemelor informatice cuprind:
a) reguli de formalizare a datelor;
b) instrumente pentru concepţia, realizarea şi elaborarea documentaţiei;
c) modalităţile de administrare a proiectului;
d) instrucţiuni pentru luarea deciziilor;
e) modalitatea de abordare a sistemelor.
Răspuns: a,b,c,e
12. Reprezintă modul unitar sau manieră comună în care analiştii de sisteme,
programatorii şi alte categorii de persoane implicate realizează procesul de analiza a
sistemului informaţional-decizional existent, proiectarea şi introducerea sistemului
informatic:
a) metodele utilizate în proiectarea sistemelor informatice;
b) procedurile utilizate în proiectarea sistemelor informatice;
Răspuns: a, d
24. Definirea caracteristicilor generale ale sistemului economic implică:
a) cunoaşterea profilului, obiectivelor agentului economic;
b) cunoaşterea locului în sfera serviciilor şi sfera producţiei;
c) cunoaşterea relaţiilor de cooperare cu alţi agenţi economici;
d) cunoaşterea specificului activităţii de bază ( producţie, servicii).
Răspuns: a, b, c, d
25. Studiul sistemului de conducere se referă la identificarea:
a) caracteristicilor rezultate din statutul de funcţionare a societăţii, tipuri de
decizii, modul de luare a deciziilor;
b) principalilor algoritmi, reguli de calcul şi de control;
c) mijloacelor tehnice existente în dotarea unităţii economice;
d) modului de organizare a producţiei.
Răspuns: a
Răspuns: a, d
45. La proiectarea intrărilor este necesar să se realizeze, în principal următoarele
activităţi:
a) alegerea colecţiilor de date;
b) proiectarea machetelor documentelor de intrare;
c) alegerea regulilor de control şi validare a datelor;
d) proiectarea formularelor (videoformatului) de intrare.
Răspuns: b, c, d
46. Macheta documentului de intrare conţine:
a) antetul documentului;
b) diagrama fluxului de date;
c) denumirea documentului.
Răspuns: a, c
a) Relaţia;
b) Atributul;
c) Fişierul;
d) Domeniul;
e) Tuplul.
Răspuns: c
52. Paşii parcurşi în procesul de transformare a diagramelor entitate-relaţie în relaţii sunt:
a) Reprezentarea entităţilor;
b) Reprezentarea legăturilor;
c) Normalizarea relaţiilor.
Răspuns: a, b, c
53. Proiectarea fizică a sistemelor informatice înseamnă:
a) o abordare detaliată a sistemului;
b) o abordare de ansamblu a sistemului;
c) o abordare generală a sistemului;
Răspuns : a
54. Proiectarea fizică a sistemelor informatice implică:
a) proiectarea fizică a bazelor de date şi a fişierelor.
b) proiectarea structurii sistemului şi a programelor.
c) proiectarea documentaţiei sistemului analizat.
d) proiectarea strategiilor de prelucrare distribuită.
Răspuns : a, b, d
55. Proiectarea fizică a bazelor de date şi a fişierelor îşi propune să asigure:
a) trecerea de la descrierea logică a datelor la una tehnică, de stocare a datelor;
b) structura globală de organizare a datelor;
c) descrierea logică a datelor.
Răspuns : a
56. Sunt structuri de control fundamentale în realizarea programelor:
a) structura secvenţială;
b) structură funcţională;
c) structura alternativă;
d) structura organizaţională:
e) structura repetitivă.
Răspuns : a, c, e
57. Structura repetitivă condiţionată anterior este:
a) de tip WHILE-DO;
b) de tip DO UNTIL;
c) de tip DO FOR.
Răspuns : a
58. Nu sunt metode de programare:
a) metoda programării clasice;
b) metoda programării structurate;
c) metoda programării orientate-obiect;
d) metoda programării iterative.
Răspuns : d
59. Un modul are componente de bază:
a) funcţia;
b) schema;
c) logica;
d) interfeţele.
Răspuns : a, c, d
60. Funcţia unui modul constă în:
a) transformarea datelor prin procesul de execuţie a acestuia.
b) descrierea prelucrărilor care au loc în interiorul acestuia.
c) legătura cu alte module.
Răspuns : a
61. Realizarea modulară a programelor corespunde principiilor:
a) programării clasice;
b) programării structurate;
c) bazelor de cunoştinţe;
Răspuns : b
62. Principalele module de proiectare a sistemelor de prelucrare distribuită a datelor sunt:
a) proiectarea nodurilor;
b) proiectarea diagramelor;
c) proiectarea reţelei de comunicaţii.
Răspuns : a, c
63. Nu sunt componente de bază ale tehnologiei client/server:
a) clientul; b) administratorul de sistem;
c) serverul; d) reţeaua care conectează clientul la
server.
RĂSPUNS : B
64. Care dintre următoarele instrucţiuni nu sunt decizionale ?
a) WHILE ... WEND ;
b) IF...END IF;
c) IF...ELSE...END IF;
d) IF...THEN...ELSE IF... ... ...END IF ;
e) SELECT CASE...CASE... ... ...END SELECT.
Răspuns : a
65. Care dintre următoarele instrucţiuni repetitive sunt condiţionate posterior ?
a) FOR...NEXT ;
b) WHILE...WEND ;
c) DO WHILE...LOOP;
d) DO UNTIL...LOOP;
e) DO...LOOP WHILE.
Răspuns : e
66. Modelul conceptual pune în evidenţă:
a) modul de stocare a datelor pe suportul de memorare;
b) reprezentarea logică, detaliată a entităţilor, asocierilor (legăturilor) şi
datelor elementare
ale unei organizaţii;
c) structura globală de organizare a datelor.
Răspuns: b), c)
67. Normalizarea unei relaţii constă în:
a) Descrierea relaţiei în limbajul de descriere a datelor;
b) Identificarea dependenţelor între atributele relaţiei;
c) Descompunerea relaţiei în relaţii echivalente urmărind eliminarea redundanţei datelor
şi
anomaliilor la efectuarea operaţiilor de adaugare, actualizare şi ştergere în baza de
date.
Răspuns: c)
68. Proiectarea fizică a bazei de date are în vedere:
a) modul de stocare a datelor pe suportul de memorare;
b) trecerea de la descrierea logică a datelor la una tehnică, de stocare a datelor;
b) structura globală de organizare a datelor.
Răspuns: a), b)
69. Sistemul de Gestiune a Bazelor de Date este:
a) un sistem de programe care permite definirea, crearea şi întreţinerea bazei de date
precum şi accesul controlat la baza de date;
b) un sistem de programe pentru interogarea bazei de date.
Răspuns: a)
70. Obiectivul principal al instrumentelor CASE este:
a) Punerea în practică a produselor-program de proiectare şi realizare a
softului cu ajutorul calculatorului.
b) Simplificarea activităţilor de proiectare şi realizare a sistemelor/
aplicaţiilor.
c) Aducerea în faţa analistului a problemelor supuse analizei.
d) Folosirea depozitelor modularizate.
Răspuns: a
71. Avantajele sistemelor CASE sunt:
a) exploatarea sistemului;
b) creşterea vitezei de realizare a sistemelor;
c) realizarea succesivă a componentelor unui sistem;
d) simplificarea activităţilor de proiectare şi realizare a sistemelor/aplicaţiilor.
Răspuns: b, c, d
72. Instrumentele CASE se bazează pe:
a) o funcţie fundamentală;
b) două funcţii fundamentale;
c) mai multe funcţii fundamentale.
Răspuns: b
73. Caracteristicile mediilor moderne de tip CASE sunt:
a) integrarea;
b) aranjarea;
c) descompunerea;
d) exploatarea.
Răspuns: a, c
74. Domeniile către care se orientează Upper CASE-ul, sunt:
a) analiza cerinţelor sistemului;
b) proiectarea şi modelarea funcţională şi procedurală;
c) modelarea datelor şi proiectarea bazei de date;
d) generarea codurilor.
Răspuns: a, b, c, d
75. Nu sunt corecte următoarele afirmaţii:
a) CASE reprezintă Proiectarea Sistemelor Asistată de Calculator;
b) Instrumentele CASE implică utilizarea calculatorului ca un mijloc de susţinere
a activităţilor de planificare, definire, proiectare şi realizare a softului.
c) CASE reprezintă Proiectarea Sistemelor cu Ajutorul Calculatorului;
d) CASE reprezintă Componente Asamblate ale Sistemelor Economice.
Răspuns: d
Întrebări
4. Enumeraţi produsele software de bază care pot fi utilizate pentru realizarea unui
sistem informatic.
9. Enumeraţi cele 4 nivele care pot fi identificate în organigrama unei unităţi economice
Productive.
10. Descrieţi tipurile de legături care pot exista între două mulţimi de entităţi.
11. Definiţi cheia unei relaţii.
RĂSPUNS:
- arhitectura de tip server de
obiecte;
- arhitectura de tip server de
pagini;
- arhitectura de tip server de bază
de date.
14. Enumeraţi cele 3 nivele ale noii arhitecturi client-server definite ca urmare a
utilizării a unor platforme hard-soft diferite, precum şi integrării bazelor de date în
mediul Web:
Răspuns:
- nivelul client, la care se realizează interfaţa cu utilizatorul aplicaţiei;
- nivelul server de aplicaţie, la care se realizează logica aplicaţiei şi prelucrării
datelor;
- nivelul server de baze de date, la care se realizează validarea datelor şi accesul
la baza de date.
BIBLIOGRAFIE