Realizarea Evidentei Cartilor Intr O Biblioteca Folosind O Baza de Date

Realizarea evidentei cartilor intr-o biblioteca folosind o baza de date

INTRODUCERE

Activitatea umană desfășurată în indiferent care domeniu presupune folosirea unei cantități mai mici sau mai mari de informație. Această informație este manevrată prin intermediul datelor păstrate pe diverși suporți de memorie externă.

Prelucrarea datelor a devenit astăzi o activitate cu pondere mare în activitatea curentă a societății moderne. Apariția calculatorului electronic a permis reducerea timpului de prelucrare a datelor și creșterea calității lucrărilor datorită eliminării erorilor generate de oboseala sau neatenția operatorilor umani.

La ora actuală calculatorul a devenit o unealtă folosită practic în toate domenile de activitate, fie direct în procesul executat fie ca un ajutor care preia toate sarcinile auxiliare domeniului de activitate respectiv.

La nivelul întregi activități social-economice putem menționa o serie de domenii de utilizare ale calculatorului, după cum urmează:

proiectare asistată și lucrări tehnico-inginerești;

supravegherea și controlul proceselor tehnologice;

planificarea și pregătirea fabricației;

conducerea și asistarea deciziei;

cercetarea științifică;

activitățile de birou și administrative – birotică;

învățământ și instruirea personalului;

documentare și servicii de informare;

prelucrarea informațiilor tehnico-științifice;

poștă electronică;

afaceri, comerț electronic etc.

Domeniile enumerate mai sus reprezintă doar o parte din posibilitățile de folosire a calculatorului, acestea fiind într-o continuă diversificare.

Pentru a putea fi utilizat, un calculator are nevoie de programe care să îi specifice acțiunile care trebuiesc executate și modul de realizare al acestora. Aceste programe sau pachete de programe ( numite și aplicații informatice ) formează componenta software a unui sistem de calcul. Diversitatea domeniilor de utilizare a calculatorului a impus necesitatea dezvoltării de aplicații informatice specifice fiecărui domeniu în parte. Au apărut astfel programe pentru editare de text, pentru gestiunea datelor, pentru desenare, pentru calcule științifice etc.

SISTEM INFORMATIC

Informațiile sunt stocate și manevrate prin intermediul datelor (fapte, noțiuni, instrucțiuni reprezentate sub o formă adecvată comunicării, interpretării sau prelucrării).

Complexitatea activităților umane a condus la necesitatea manevrării unei cantități ridicate de informații, pentru care volumul datelor este foarte mare. Modul în care circulă informațiile în cadrul unei unități economice sau de alt profil formează sistemul informațional al acestei unități. Acest sistem este format din date, informații, procese de prelucrare a informațiilor, procese de prelucrare a datelor și echipamente fizice.

Într-un sistem informațional clasic, cei care prelucrează datele și informațiile sunt oamenii. Aceasta face ca, în cazul unui volum mare de date, să fie necesar un număr foarte mare de oameni sau un timp îndelungat pentru prelucrarea lor. Totodată crește riscul apariției erorilor de prelucrare, cu consecințe mai mari sau mai mici.

Apariția și dezvoltarea calculatoarelor electronice au permis crearea de aplicații care să realizeze prelucrarea datelor cu viteze mai mari decât operatorul uman.

Aplicațiile informatice folosite în cadrul unei unități formează sistemul informatic al unității.

Sistemul informatic poate fi definit în diferite moduri: prin scop, prin elementele care îl compun sau sub forma unor combinații scop, elemente, interconexiuni dintre elemente. Una din cele mai generale definiții este cea de sistem de colectare, memorare, prelucrare și distribuire de informații, care utilizează unul sau mai multe calculatoare electronice.

Scopul principal al unui sistem informatic este de a servi cerințele informaționale ale omului și/sau de a reduce la minim intervenția și efortul uman în desfășurarea unor procese (de concepție, de instruire, de decizie, de evidență și gestiune etc.). Orice sistem informatic, din orice domeniu de activitate, este parte dintr-un sistem mai larg, sistemul obiect. Informațiile stocate și prelucrate de sistemul informatic sunt, direct sau indirect, bazate pe observațiile făcute asupra sistemului obiect, aceste informații putând fi utilizate pentru comanda și controlul sistemului obiect respectiv.

Oamenii din sistemul obiect au diferite roluri in raport cu sistemul informatic:

consumatorii de informații (denumiți și utilizatori finali);

furnizorii de date/informații;

operatori ai sistemului;

administratori care întrețin și mențin sistemul în funcțiune etc.

Fiecărui sistem informatic i se asociază un sistem de prelucrare automată a datelor (SPAD), în care informațiile sunt reprezentate prin date stocate pe diferiți suporți de memorie, iar procesele de prelucrare a informațiilor sunt concretizate prin procese de prelucrare a datelor executate de diferite echipamente de calcul și de oameni.

Figura 1. Structura unui Sistem Informatic

Astfel, sistemul informatic poate fi văzut ca un ansamblu de oameni, informații, procese de prelucrare a informațiilor, date, procese de prelucrare a datelor și echipamente fizice.

După cum se observă din figura 1, sistemul informatic poate fi abordat din două puncte de vedere:

modelul extern sau arhitectura funcțională, orientată către utilizator, constituit din informații și procese de prelucrare a informațiilor;

modelul intern sau structura fizică, orientată către mașină (calculator), constituită din date, procese de prelucrare a datelor și echipamentele fizice.

Este clar că primul îl determină pe al doilea, fapt pentru care, primul pas în conceperea unui sistem informatic, îl constituie definitivarea modelului extern al acestuia.

Pe baza arhitecturii funcționale generale a sistemului informatic se poate stabili structura fizică (modelul intern) al acestuia, respectiv echipamentele utilizate, structurile de date și suporții de memorie, modurile de exploatare, programele necesare, personalul de exploatare și întreținere a sistemului etc. În multe situații echipamentele deja existente în dotare constituie o restricție în stabilirea structurii fizice a sistemului informatic.

Din punct de vedere fizic, un sistem informatic este format din următoarele componente:

echipamente (hardware); cuprind unul sau mai multe calculatoare, lucrând independent sau integrate într-o rețea împreună cu echipamentele periferice necesare (imprimantă, scanner etc.);

programe (software); care se pot diferenția în:

programe de bază (sistem de operare și utilitare);

programe pentru exploatarea colecțiilor de date (Sisteme pentru Gestiunea Bazelor de Date);

programe dedicate, realizate pentru satisfacerea cerințelor specifice unui sistem informatic corect;

colecții de date; compuse din fișierele care conțin datele introduse, stocate, manipulate și întreținute în cadrul sistemului informatic, fișiere stocate pe suporți fizici de memorie (discuri magnetice, benzi magnetice, discuri optice etc.);

proceduri manuale; acestea se concretizează într-o documentație scrisă (manualele sistemului informatic) și care conține instrucțiuni pentru:

utilizarea sistemului de către utilizatorii neinformaticieni;

exploatarea sistemului;

întreținerea sistemului, de către utilizatori și personalul de specialitate informatică;

personalul care exploatează și menține sistemul în funcțiune; format din operatori calculator, personalul de pregătire al datelor, analiști și programatori, administratorii sistemului etc.

Un alt aspect important al structurii fizice a sistemului informatic este determinat de modul în care se face stocarea si prelucrarea informațiilor. Din acest punct de vedere, sistemele informatice se împart în:

sisteme informatice centralizate; în care toate informațiile sunt stocate și prelucrate pe un singur calculator;

sisteme informatice distribuite, în care stocarea și prelucrarea informațiilor este împărțită între mai multe calculatoare legate între ele. Aceste sisteme informatice au de regulă următoarele caracteristici:

prelucrări distribuite;

comunicații distribuite;

baze de date distribuite.

Utilizarea unui sistem informatic este în mare parte dependentă de utilizarea ieșirilor oferite utilizatorului uman. Aceasta deoarece, din punctul de vedere al utilizatorului neinformatician, sistemul informatic poate fi considerat o “cutie neagră” căreia îi furnizează intrări pentru a primi ieșiri.

Ieșirile unui sistem informatic pot fi de exemplu:

documente de tranzacție; care pot avea rol de informare, descriind sau confirmând fapta ca o acțiune a avut sau va avea loc, sau rol de acțiune, declanșând o nouă acțiune sau dând instrucțiuni referitoare la executarea acesteia.

rapoarte predefinite – sunt ieșiri prefixate din punct de vedere al formei și conținutului cât și al momentului/ frecvenței de producere; se referă de regula la una din următoarele situații:

descrierea unei stări sau condiții la termen prestabilit;

lista unor evenimente produse într-un interval de timp specificat.

răspunsuri la intrebări predefinite – sunt în general ieșiri limitate ca volum, cu caracter punctual, care permit selectarea unor informații din fișiere/bază de date după atributele acestora.

rapoarte și răspunsuri la întrebări și cereri “ad-hoc” – apar la intervale de timp diferite, ca o cerere expresă a utilizatorului, cerere care nu a putut fi specificată la proiectarea sistemului. Aceste situații se pot soluționa în diferite maniere, în funcție de facilitățile prevăzute de proiectantul sistemului (echipamente utilizate și sisteme de programare implementate):

prin utilizarea facilităților de lucru în sistemul convențional (interactiv) oferite de sistemul de gestiune a bazei de date;

prin utilizarea unor programe specializate pentru generarea de rapoarte;

prin proiectarea și scrierea unor programe noi necesare regăsirii și editării informațiilor solicitate;

soluții mixte.

Pentru a obține toate aceste ieșiri, un sistem informatic are nevoie de una sau mai multe baze de date în care să fie stocate datele, fie că sunt introduse de către operatori, fie că sunt generate prin prelucrarea datelor introduse anterior.

BAZE DE DATE

Metodele si tehnicile de organizare a datelor au evoluat în cadrul procesului de perfecționare a sistemelor informatice, fiind determinate de :

creșterea continuă a complexității activităților, care a condus la creșterea volumului de inormații generate și prelucrate ;

creșterea ritmului de dezvoltare a societății, care a determinat ca dimensiunea timpului de răspuns a sistemelor infomatice la cererile de informații să devina unul din criteriile de apreciere a gradului de organizare a datelor și, respectiv, a eficienței sistemelor informatice;

evoluția mijloacelor de culegere, transmitere și prelucrare a datelor.

Prima etapă a fost organizarea datelor în “fișiere pe aplicații” când proiectanții sistemelor informatice gestionau în mod izolat fișiere, în vederea rezolvării problemelor particulare ale unui departament.

A doua etapă se caracterizează prin separarea nivelului logic de cel fizic de organizare a datelor, utilizându-se fișiere organizate indexat sau aleator.

Cerințele complexe impuse sistemelor informatice moderne au creat necesitatea ca mai mulți utilizatori să aibă acces la aceeași colecție de date. Folosirea metodelor clasice cu fișiere conduce la o creștere a redundanței datelor și o creștere a timpului de răspuns. În aceste condiții au aparut fișiere integrate sau sisteme de fișiere (etapa a treia).

Trecerea la utilizarea fișierelor integrate nu a rezolvat problema independenței programelor de aplicații de modul de organizare a datelor. Soluția s-a obținut prin detașarea din programul de aplicații a descrierii fișierelor și a legăturilor dintre ele. Se ajunge astfel la primele baze de date (etapa a patra, care marchează un salt calitativ în organizarea datelor).

O bază de date este astfel formată din:

baza de date propriu-zisă – o colecție de date aflate în interdependență, împreună cu descrierea lor;

un sistem de gestiune a bazei de date (SGBD) – care este un set de programe și proceduri specializate, destinate gestiunii și prelucrării complexe a datelor din baza de date;

un set de proceduri manuale și automate – specifice domeniului pentru care se organizează baza de date, precum și reglementările administrative destinate bunei funcționări a întregului sistem.

O bază de date este deci o colecție de date creată pentru a satisface mai mulți utilizatori, asigurând o redundanță minimă și controlată a datelor și o independență a programelor față de date.

Avantajele organizării datelor în baze de date sunt următoarele:

Independența datelor memorate – asigurată de separarea nivelului de descriere a datelor de nivelul de utilizare a lor; astfel asigurându-se și integritatea programelor de aplicație la schimbările ce au loc în baza de date;

Nivelul redus de redundanță – în acest mod redundanța devine un fenomen controlabil;

Securitatea datelor – se pot aplica restricții în ceea ce privește accesul neautorizat la date în vederea extragerii sau distrugerii unor date cu caracter confidențial ;

Integritatea datelor – posibilitatea asigurarării corectitudinii datelor în orice moment al funcționării sistemului ;

Facilități de utilizare a datelor fără ca utilizatorii să fie nevoiți să cunoască în întregime structura bazei de date;

Accesarea bazei de date din diferite noduri ale rețelei de către utilizatori diferiți;

Existență unui număr ridicat de pachete de gestiune care permit gestionarea unor date foarte complexe în condiții de eficiență maximă, asigurând în plus utilizatorilor programatori instrumentele necesare concepției programelor lor, dar și utilizatorilor neinformaticeni o interfață “prietenoasă”.

Crearea și utilizarea unei baze de date presupune existența unui model de date. Un model de date poate fi definit dacă se cunosc următoarele elemente: structura modelului (entități caracterizate prin: câmp, grup, înregistrare și asocieri existente între acestea), operatori (citire, memorare, modificare etc) și restricțiile care se impun pentru menținerea corectitudinii datelor.

Modelele de date, după modul de structurare a datelor, pot fi: modele ierarhice sau arborescente, modele rețea, modele relaționale, modele orientate pe obiect etc.

Un model care a cunoscut o răspândire foarte mare datorită avantajelor pe care le prezintă este modelul relațional al datelor.

Ideea bazelor de date relaționale a fost lansata de D.F.Childs care a subliniat faptul ca orice structura de date poate fi reprezentata prin una sau mai multe tabele de date, în cadrul cărora este necesar să existe și informații de legătură. Bazele modelului de date relațional au fost puse de catre Codd E. în 1970.

Componentele modelului relațional sunt: structura relațională a datelor (ansamblu de relații prin care se reprezintă datele și legăturile dintre ele), operatorii modelului relațional și restricțiile de integritate ale modelului relațional.

Domeniul este un ansamblu de valori caracterizat printr-un nume; se poate defini explicit prin enumerarea tuturor valorilor lui sau implicit prin precizarea proprietăților pe care le are domeniul respectiv.

Se numește produs cartezian al mulțimilor D1,D2,…,Dn finite și nu neaparat distincte, mulțimea tuplurilor (v1,v2,…,v n) , unde v1,v2,…,v n aparțin respectiv mulțimilor D1,D2,…,Dn .

Relația este un subansamblu al produsului cartezian al mai multor domenii, caracterizat de un nume și care conține tupluri cu o anumită semnificație (tuplul reprezintă exprimarea generală a unei mulțimi).

Exemplu: D1*D2*…*Dn <v1,v2,…,v n>

D1*D2*D3 <v1,v2,…,v3> <”Maria”,F,45>

<”Vasile”,B,47>

Atributul reprezintă unitatea fundamentală a unei baze de date relaționale și se mai numeste câmp. Este dată de coloana unei tabele de date și se caracterizeaza printr-un nume; sunt elemente individuale de informație și se folosesc pentru a crește flexibilitatea datelor.

Fiecare coloană din tabelul de mai sus definește un câmp distinct. Pe toate liniile, informațiile din aceeași coloană au aceeași semnificație. De exemplu, numele unei persoane este un câmp, varsta este alt câmp, iar sexul este al treilea. Dacă se dorește stocarea unor informații suplimentare, fiecare informație individuală constituie un câmp. Pentru fiecare persoană înregistrată în tabel există mai multe câmpuri care o individualizează. Luate împreună, aceste câmpuri definesc o înregistrare. În general înregistrările se prezintă sub formă de linii .

Tabelul descrie o grupare de un nivel mai înalt decât o înregistrare, cuprinzănd o colecție de înregistrări. Presupunând că avem un tabel asemănător care conține informații despre o categorie de persoane alese după un anumit criteriu, aceste două tabele au un element comun – numele persoanei .

Combinația acestor două tabele și a relației dintre ele constituie un exemplu simplu de bază de date relațională .

Schema unei relații este compusă din numele relației urmat de lista atributelor și domeniile asociate fiecărui atribut .

Relație ( A: D1 , A: D2 , … ,A: Dn )

Persoana ( Nume:D1,Sex: D2,Varsta: D3)

Schema unei relații se mai numeste și intensia relației și reprezintă o expresie a proprietăților comune și invariante ale tuplurilor care compun relația, rămânând neschimbată atât timp cât este folosita relația. Extensia unei relații poartă numele de relație de bază și este ansamblul tuplurilor care compun la un moment dat relația (mulțimea înregistrărilor existente la un moment dat într-un tabel ), fiind stocată fizic în spațiul asociat bazei de date.

Spre deosebire de modelele ierarhice și în rețea, modelul relațional prezintă o serie de avantaje:

Asigură un grad sporit de independență a programelor de aplicație față de modul de reprezentare internă a datelor.

Furnizarea unor metode și tehnici eficiente de control a redundanței datelor. Modelul relațional, prin tehnica normalizării relațiilor, permite definirea unei structuri conceptuale optime a datelor.

Oferă facilități multiple de definire și manipulare a datelor. Modelul relațional oferă posibilitatea utilizării unor limbaje procedurale, bazate pe algebra relatională.

Ameliorarea integrității și confidențialității datelor. Modelul relațional realizează acest lucru prin mecanisme flexibile și eficace de specificare și utilizare a restricțiilor de integritate și a relațiilor virtuale.

Din această cauză, aplicația dezvoltată va folosi baze de date relaționale.

PREZENTAREA PROBLEMEI

Problema care trebuie rezolvată în continuare constă în realizarea unei evidențe electronice a cărților dintr-o bibliotecă pentru a se putea cunoaște cu precizie, în orice moment, starea fiecărei cărți precum și alte informații despre fondul de carte existent în bibliotecă.

O carte este caracterizată de o serie de informații privind conținutul acesteia și se poate afla în raft sau poate să fie împrumutată de către un cititor. Deoarece se întâmplă ca mulți cititori să uite să înapoieze cărțile la timp, aplicația va trebui să semnaleze, la cererea bibliotecarului, toți cititorii care au depășit termenul la care trebuiau să înapoieze cărțile.

Totodată, aplicația trebuie să permită introducerea în baza de date de noi informații privind cărțile noi achiziționate și cititorii noi înregistrați, ștergerea de date pentru cărțile casate, căutarea unui anumit titlu sau a aunui anumit autor precum și localizarea unei cărți în orice moment.

ANALIZA SISTEMULUI INFORMATIC

Analiza sistemului informatic are ca scop elaborarea unuia sau mai multor modele ale acestui sistem, modele care să permită ulterior elaborarea structurii bazei de date. Această analiză presupune următoarele etape:

analiza componentelor sistemului și a legăturilor dintre acestea, activitate cunoscută sub numele de analiză statică sau structurală;

analiza stărilor sistemului și a tranzițiilor posibile între aceste stări în raport cu anumite evenimente (analiza dinamică), în urma căreia se obține modelul dinamic;

analiza cerințelor informaționale, respectiv a transformărilor de date din cadrul sistemului (analiza funcțională), ce are ca rezultat modelul funcțional;

integrarea modelelor sistemului informatic în scopul corelării lor.

ANALIZA STRUCTURALĂ

Are ca obiectiv evidențierea componentelor din cadrul sistemului, pentru care urmează să se colecteze date în cadrul bazei de date, precum și evidențierea legăturilor dintre componente.

Pentru construirea modelului structural trebuiesc parcurse următoarele etape:

identificarea componentelor din cadrul sistemului informatic;

identificarea asocierilor dintre entități și calificarea lor;

identificarea atributelor aferente entităților și asocierilor lor;

stabilirea atributelor de identificare a entităților.

Legăturile între entități pot fi de mai multe tipuri și anume:

După cardinalitatea asocierii avem, în funcție de gradul asocierii, respectiv după obligativitatea participării la asociere:

de tipul ‘unu la unu’, aceasta însemnând că cel puțin o realizare a fiecărei entități trebuie să participe la asociere;

de tipul ‘unu la mulți’, caz în care o realizare a unei entități revine la celelalte entități;

de tipul ‘mulți la mulți’;

asocieri parțiale, fără obligativitatea entităților;

asocieri totale sau complete, în care cel puțin o realizare a unei entități să participe la asociere.

După numărul de entități care participă la asociere vom avea:

asocieri binare, între două entități,

asocieri recursive, ale entităților cu ele înseși,

asocieri complexe.

Pentru problema prezentată se pot identifica două entități care se află în legătură una cu alta, și anume: entitatea CARTE și entitatea CITITOR.

Diagrama structurală, corespunzătoare celor două entități și a legăturii dintre ele, este prezentată în figura următoare.

Figura 2. Diagrama structurală

Legătura dintre cele două entități este de tipul “unu la unu” de la entitatea CARTE la entitatea CITITOR, și de tipul “unu la mulți” de la entitatea CITITOR la entitatea CARTE. Aceasta înseamnă ca o carte se poate afla la un singur cititor, la un moment precizat, iar un cititor poate să împrumute mai multe cărți simultan.

Entitățile identificate sunt caracterizate fiecare de o serie de atribute.

Atributele exprimă caracteristici, proprietăți ale componentelor sistemului informatic analizat sau ale asocierilor dintre componente.

Atributele pot fi de mai multe feluri:

Compus (bloc) – care este format din cel puțin două alte atribute.

Calculat (dedus) – reprezentând un atribut a cărui valoare nu este cunoscută direct, ci se calculează pe baza valorilor altor atribute.

Simplu – ale cărui valori nu pot fi descompuse în elemente componente.

Repetitiv multivaloare – care la un moment dat apare sub forma unei liste.

De identificare (cheie) – se caracterizează prin unicitatea valorii sale pentru fiecare instanță a entității căreia îi aparține. Atributele de identificare au un rol aparte în organizarea și manipularea informațiilor din baza de date. Stabilirea atributelor de identificare pentru entitățile din cadrul sistemului informatic analizat necesită examinarea mai întâi a capacității fiecarui atribut de a se constitui drept atribut de identificare (cheie).

Un atribut poate fi de identificare dacă îndeplinește o serie de cerințe:

oferă o identificare unică a realizărilor de entitate;

poseda o semnificație clară;

este usor de utilizat;

este scurt.

Pentru aceeași entitate pot exista mai multe atribute care pot servi drept atribute de identificare, adică pot exista mai multe chei candidate.

Selectarea unuia dintre candidații cheie drept atribut de identificare a entității se realizeaza astfel:

se determină atributele care potențial pot constitui atribute de identificare a entității, deci care respectă cerințele menționate anterior și care poartă numele de candidați cheie. Dacă nu exista astfel de atribute se introduce un atribut nou drept candidat cheie.

daca există un singur candidat cheie, se va selecta acesta drept atribut de identificare a entitatii;

daca exista mai multi candidati cheie se selectează unul astfel încât:

– se preferă atributele ale căror valori sunt mai puțin volatile,

– se preferă atributele ale căror valori sunt mai scurte.

În continuare sunt prezentate entitățile din diagrama structurală împreună cu atributele fiecăreia.

Figura 3. Atributele entității CARTE

Figura 4. Atributele entității CITITOR

Ca atribut de identificare pentru entitatea CARTE se alege atributul COD CARTE care corespunde codului de clasificare bibliofilă. Pentru entitatea CITITOR, atributul de identificare este atributul NUME. Pentru a ușura manevrarea ulterioară a informațiilor se preferă introducerea unui atribut nou, COD CITITOR, care va fii mai scurt decât atributul NUME și mai ușor de manevrat.

ANALIZA DINAMICĂ

Analiza dinamică are drept scop explicarea comportamentului elementelor componente ale sistemului informatic analizat.

În urma acestei analize se obține modelul dinamic al sistemului analizat.

Construirea modelului dinamic presupune următoarele etape :

identificarea stărilor în care se pot afla componentele sistemului;

identificarea evenimentelor care determină trecerea unei componente dintr-o stare în alta;

stabilirea succesiunii (fluxului) de evenimente și construirea unei diagrame care să reflecte tranzițiile de stare pentru componentele sistemului (diagrama de flux a evenimentelor).

Figura 5. Diagrama de flux a evenimentelor, corespunzătoare stărilor

celor două entități

La realizarea diagramei de flux a evenimentelor este necesar să se țină cont de restricțiile dinamice ale sistemului care servesc la identificarea tranzițiilor admisibile între două stări.

În figura 5 sunt prezentate stările în care se pot afla cele două entități care compun sistemul.

Tranzițiile entităților sistemului dintr-o stare în alta influențează tranzacțiile (transferurile de date) care au loc în interiorul sistemului, iar acestea la rândul lor influențează modul de realizare a aplicațiilor software destinate sistemului.

ANALIZA FUNCȚIONALĂ

Analiza funcțională are drept scop determinarea transformărilor de date care se produc în cadrul sistemului informatic analizat în scopul satisfacerii cerințelor informaționale aferente acestuia. Transformările de date se vor reprezenta sub forma unei diagrame de flux a prelucrărilor, în care nodurile reflectă procesele de prelucrare informațională, iar arcele reflectă fluxurile informaționale.

În cadrul analizei funcționale, accentul se deplasează de la realitatea analizată către cerințele informaționale ale utilizatorilor, cerințe a căror satisfacere constituie obiectivul realizării bazei de date.

Construirea modelului funcțional presupune parcurgerea următoarelor etape:

identificarea datelor de intrare și a datelor de ieșire din sistem;

construirea diagramelor de flux, prin care sunt reflectate legăturile procedurale dintre intrări și ieșiri;

identificarea restricțiilor;

precizarea criteriilor de optimizare.

Datele de intrare pentru problema analizată sunt următoarele:

datele care descriu atributele entității CARTE, în cazul adăugării de noi cărți la fondul de carte al bibliotecii;

datele care descriu atributele entității CITITOR, pentru cazul înscrierii unui nou cititor;

codul cărții, codul cititorului, data la care a fost împrumutată cartea și data la care trebuie restituită aceasta, pentru tranzacțiile curente specifice operațiilor zilnice de împrumut-restituire de cărți;

titlul cărții, respectiv numele autorului, pentru operațiile de căutare pe titluri sau autori.

Datele de ieșire sunt reprezentate de:

lista cititorilor care au depășit termenul de restituire a cărților;

lista cărților existente în bibliotecă;

lista cărților cu un anumit titlu care există în bibliotecă, specificându-se starea acestora (dacă există): la raft sau împrumutată persoanei X;

lista cărților aparținând unui anumit autor care există în dotarea bibliotecii, împreună cu starea lor.

Prelucrările de date care trebuiesc efectuate constau în următoarele acțiuni:

adăugarea de noi cărți în baza de date;

adăugarea unui nou cititor în baza de date;

adăugarea datelor necesare pentru a înregistra un împrumut;

ștergerea datelor privind împrumutul la restituirea în bune condiții a cărților;

căutarea și afișarea stării cărților având un anumit titlu sau aparținând unui anumit autor;

extragerea de rapoarte privind numărul cititorilor care au depășit termenul și lista cărților din bibliotecă.

Diagramele de flux a prelucrărilor sunt prezentate în figurile următoare.

Figura 6. Diagrame de flux a prelucrărilor

Figura 7. Diagrame de flux a prelucrărilor

În final cele trei modele ale sistemului vor fi integrate pentru se obține o reprezentare completă a sistemului analizat.

INTEGRAREA MODELELOR SISTEMULUI INFORMATIC ANALIZAT

Analiza sistemului informatic se finalizează prin integrarea modelelor structural, dinamic și a celui funcțional.

Modelul structural și cel dinamic sunt obținute prin investigarea sistemului real, a proprietăților intrinseci, statice și dinamice ale componentelor acestui sistem, proprietăți care sunt independente de aplicațiile care operează asupra lor.

Modelul funcțional este rezultatul analizei cerințelor informaționale ale utilizatorilor, mai precis a tranzacțiilor prin care pot fi satisfăcute aceste cerințe.

Perspectiva diferita din care este realizata analiza explica de ce rezultatele obtinute pot sa difere fiind necesara o coordonare, deci o integrare a lor.

În cadrul etapei de integrare a modelelor sistemului se stabilește în ce măsură modelul structural și cel dinamic satisfac necesitățile diferitelor aplicații, verificându-se complitudinea (existența elementelor informaționale solicitate) și consistența lor (în ce măsură componentele modelelor sunt necesare și suficiente în raport cu procesele de prelucrare). Se verifică dacă relațiile dintre componentele sistemului sunt stabilite în mod corespunzator, pentru a face posibilă regăsirea informațiilor din mai multe entități. Se determină, de asemenea, dacă legăturile dintre entități asigură coerența informațiilor, posibilitatea efectuării de actualizări concomitente asupra datelor redundante.

Se urmăreăte ca toate elementele informaționale participante la diferitele tranzacții să fie asignate ca atribute ale diferitelor entități.

Pe baza acestei analize integrate se efectuează adăugările și/sau corelările necesare între modelele sistemului.

În final se ajunge ca modelul dinamic și cel structural să nu mai fie complet independente de aplicații, iar modelul funcțional să nu mai fie orientat exclusiv pe aplicații.

PROIECTAREA STRUCTURII BAZEI DE DATE

Modelele obținute în urma analizei sistemului informațional sunt modele ale datelor despre sistem. O caracteristică esențiala a acestor modele este faptul că sunt independente de instrumentul, respectiv SGBD-ul prin intermediul căruia devin operaționale.

Etapa de analiză a sistemului informatic este important să se realizeze independent de un SGBD specificat. Orientarea pe conceptele proprii unui anumit SGBD prezintă numeroase dezavantaje cum sunt:

schimbarea SGBD-ului impune reproiectarea bazei de date;

conceptele tehnice ale SGBD-ului pot influența negativ activitatea de analiză și modelare, prin restricții impuse de acesta, care pot descuraja sau încuraja anumite reprezentări;

fixând ca punct de plecare facilitățile unui SGBD, utilizatorul neinformatician, care nu stăpânește acest SGBD, nu își poate exprima cerințele în deplină cunoștință de cauză.

Trecerea la proiectarea structurii bazei de date impune luarea în considerare a SGBD-ului cu ajutorul caruia va fi implementată și exploatată baza de date. Aceasta deoarece baza de date reprezintă un model al datelor exprimat cu ajutorul conceptelor specifice unui anumit SGBD, ceea ce face proiectarea structurii bazei de date să reprezinte transpunerea modelelor conceptuale în termenii unui model al datelor suportat de un anumit tip de SGBD.

Etapele de proiectare a structurii bazei de date constau în următoarele activități:

alegerea SGBD-ului care va fi utilizat pentru implementarea si exploatarea bazei de date;

proiectarea schemei conceptuale a bazei de date;

proiectarea schemei externe a bazei de date.

ALEGEREA SISTEMULUI DE GESTIUNE A BAZEI DE DATE

Alegerea unui SGBD presupune realizarea următoarelor activități:

Stabilirea cerințelor utilizatorilor, sub aspectul:

tipurilor de aplicații dorite,

timpului de răspuns,

confidențialității datelor,

securității datelor,

ușurinței de utilizare.

Stabilirea cerințelor de ordin tehnic privind realizarea bazei de date, cum sunt:

portabilitatea SGBD-ului, adica posibilitatea folosirii SGBD-ului pe diferite sisteme de calcul;

portabilitatea colecțiilor de date și a programelor. Aceasta înseamnă că datele pregătite cu ajutorul unui calculator să poată fi transferate direct pe alt tip de calculator, împreună cu programele aferente, fără alte operații auxiliare;

facilitățile de încărcare, exploatare și întreținere a bazei de date care trebuiesc asigurate.

Stabilirea cerințelor de ordin economic, privind:

încadrarea în bugetul alocat pentru realizarea bazei de date;

timpul necesar pentru pregătirea utilizatorilor și trecerea la exploatarea curentă a bazei de date.

Ierarhizarea cerințelor de la punctele anterioare, în funcție de importanța acordată fiecărei cerințe în parte.

Analiza comparativă a SGBD-urilor disponibile și/sau posibil de achiziționat, în funcție de caracteristicile pe care le prezintă aceste SGBD-uri.

Stabilirea corespondenței între cerințele formulate la punctele 1-3 și caracteristicile diferitelor SGBD-uri analizate, pentru a determina măsura în care diferite SGBD-uri analizate permit satisfacerea cerințelor formulate.

Alegerea propriu-zisă a SGBD-ului care va fi folosit la realizarea bazei de date.

Aplicația care trebuie realizată presupune manevrarea unui volum mediu de date, ce pot fi reprezentate și manevrate comod folosind un model de date relațional. Din această cauză se va alege un SGBD relațional care să posede și un limbaj comod pentru dezvoltarea de aplicații.

SGBD-urile relaționale utilizate astăzi în România pentru baze de date de mică anvergură sunt următoarele: Microsoft FoxPro (versiunile sub DOS sau VisualFoxPro sub Windows), MS-Acces, Paradox ș.a. Pe lângă aceste SGBD-uri se mai pot dezvolta aplicații de baze de date și în mediile de programare vizuale (Visual C++, Borland C++ Builder, Borland Delphi, Visual Basic).

Ținând cont de cele prezentate mai sus se alege, pentru realizarea aplicației, SGBD-ul Visual FoxPro, care lucrează sub Windows95 și este eficient pentru baze de date de dimensiuni mici și medii.

PROIECTAREA SCHEMEI CONCEPTUALE

Proiectarea schemei conceptuale a bazei de date presupune următoarele activități:

Stabilirea colecȚiilor de date și definirea detaliată a conținutului acestora. La stabilirea acestora se pleacă de la entitățile identificate în etapa de analiză a sistemului. Fiecărei entități îi corespunde, de obicei, o colecție de date în cadrul schemei conceptuale. În aceste colecții vor figura atributele specifice entităților plus eventual o serie de atribute pentru exprimarea legăturilor cu celelalte componente ale sistemului real, atribute cunoscute sub numele de chei externe. Deoarece nu întotdeauna există o corespondență strictă între entitățile din modelele semantice și colecțiile de date din schema conceptuală a bazei de date și din considerente de ameliorare a lucrului pe aceste colecții de date se poate decide “spargerea” unei entități în două sau mai multe colecții de date. Acest lucru duce la o creștere a flexibilității de operare cu colecțiile de date respective. “Spargerea” unei entități în două sau mai multe colecții de date se realizează ținând seama de cerințele informaționale ale sistemului și de durata de existență a datelor în cadrul sistemului. Astfel, datele care sunt solicitate mai des de către utilizatori, cele care se modifică la intervale reduse de timp sau cele care, deși nu se modifica prea des, sunt solicitate frecvent de către programe pentru a genera alte date (prin calcul sau în alt mod), pot constitui colecții separate de date pentru a reduce timpul necesar regăsirii informațiilor căutate. Cu toate acestea, îmbunătățirea performanțelor în manipularea entităților nu presupune obligatoriu mărirea numărului colecțiilor de date folosite în cadrul schemei conceptuale. Aceasta deoarece nu se poate admite o creștere nelimitată a numărului de colecții de date lucru care determină creșterea dificultăților de localizare și accesare a datelor. Legăturile între un numar mare de colecții de date impune și creșterea redundanței datelor în cadrul bazei de date și deci o utilizare ineficientă a suportului de memorare.

determinarea legaturilor dintre colectiile de date și a modului de reprezentare a acestora în cadrul schemei conceptuale se realizează, în principiu pe baza legăturilor dintre entitățile identificate în cadrul etapei de analiză a sistemului și a cerințelor informaționale. Este necesar să se determine, de asemenea și legăturile dintre colecțiile care nu au corespondent direct în entitățile care compun sistemul, dar care la rândul lor se află în asociere, unele cu altele. Modul de reprezentare a legăturilor dintre colecțiile de date depinde de modelul datelor suportate de SGBD. Astfel, modelul ierarhic și cel rețea utilizează pointeri (adrese legatură) pentru înlănțuirea datelor în cadrul colecțiilor. Modelul relațional reprezintă legăturile dintre colecțiile de date (relații) cu ajutorul cheilor externe sau cu ajutorul unor colecții de date distincte. Această reprezentare uniformă a datelor și a asocierilor între date prin intermediul relațiilor constituie o caracteristică a modelului relațional, care conferă acestuia o mare simplitate și flexibilitate.

testarea schemei CONCEPTUALE obȚinute presupune verificarea completitudinii și consistenței schemei conceptuale, adică determinarea gradului în care schema conține elementele informaționale necesare satisfacerii cerințelor informaționale ale diferiților utilizatori și măsura în care legăturile stabilite între aceste elemente informaționale reflectă raporturile naturale dintre componentele sistemului real. De asemenea, prin testarea schemei conceptuale trebuie să se verifice dacă redundanța datelor este la un nivel minim și poate fi controlată. Testarea schemei conceptuale permite identificarea unor eventuale erori de proiectare care fac necesară revizuirea schemei. În acest caz se va relua etapa de proiectare a structurii bazei de date, și, uneori, și etapa de analiză a sistemului și a cerințelor informaționale.

descrierea schemei conceptuale în limbajul de descriere a datelor de care dispune SGBD-ul și încărcarea acestei descrieri în baza de date.

Descrierea schemei conceptuale a bazei de date se realizează în limbajul de descriere a datelor de care dispune SGBD-ul folosit. Rezultatul acestei descrieri îl constituie proiectul bazei de date sau schema bazei de date.

Compilatorul limbajului de descriere a datelor permite aducerea schemei bazei de date in forma la care aceasta poate fi memorata in baza de date.

La realizarea acestor activitati sunt utilizate, în principal modelul structural și cel dinamic al sistemului analizat.

Pentru aplicația noastră, colecțiile de date care definesc cele două entități ale sistemului vor fi sparte pentru o mai bună utilizare a datelor și a programelor. Astfel, se va separa într-o colecție diferită de date lista cărților împrumutate. Spre deosebire de informațiile despre cărțile existente în bibliotecă sau cele despre cititorii înscriși, informațiile privind persoanele care au împrumutat cărți sunt mai dinamice, se modifică la întervale de timp mult mai mici decât celelalte informații. În acest caz este de preferat să spargem colecția de date CITITOR în două colecții distincte. De asemenea, se va “sparge” și colecția de date CARTE în două colecții distincte, în care una va cuprinde informații privind genul stilistic de care aparține cartea (beletristică, poezie etc.).

Colecțiile de date care se vor folosi de către aplicație sunt următoarele:

CARTI

CODCARTE NUMERIC 7

TITLU CARACTER 40

CODGEN CARACTER 3

AUTOR CARACTER 25

ANAP NUMERIC 4

EDITURA CARACTER 20

CITITOR

CODCITITOR NUMERIC 5

NUME CARACTER 40

ADRESA CARACTER 40

TELEFON CARACTER 10

SERIEBI CARACTER 2

NRBI CARACTER 6

GENURI

CODGEN CARACTER 3

DENUMIRE CARACTER 16

IMPRUMUT

CODCARTE NUMERIC 7

CODCITITOR NUMERIC 5

DATAIN DATA

DATARET DATA

PROIECTAREA SCHEMEI EXTERNE

Schema externă a bazei de date reprezintă forma sub care apare schema conceptuală pentru un utilizator oarecare. Programele de aplicație operează asupra schemei conceptuale prin intermediul schemei externe, având acces doar la acele elemente care sunt incluse în schema externă.

În general, elementele care compun schema externă sunt similare celor care compun schema conceptuală, depinzând totuși de tipul de SGBD utilizat.

În cazul aplicației de față, schema externă cuprinde structura rapoartelor care trebuiesc întocmite de către programe prin selectarea informațiilor corespunzătoare.

Raportul privind situația cititorilor care au depășit termenul de restituire a cărților va cuprinde următoarele elemente: Număr curent, Nume cititor și Numărul de zile cu care a depășit termenul de restituire.

Lista cărților existente în bibliotecă va cuprinde: Titlul cărții, Autorul, Editura, Anul apariției.

Rezultatul căutării unui anumit titlu va conține următoarele date: Codul cărții, Starea acesteia (LA RAFT / IMPRUMUTATĂ) sau un mesaj specific, atunci când cartea căutată nu există în dotarea bibliotecii.

PROIECTAREA APLICAȚIEI

Această etapă a realizării aplicației presupune efectuarea următoarelor activități :

identificarea datelor de intrare și iesire;

identificarea acțiunilor;

proiectarea structurii aplicației;

proiectarea procedurilor;

proiectarea ferestrelor de introducere a datelor

proiectarea rapoartelor;

implementarea aplicației;

testarea și depanarea aplicației.

Acțiunile programului se pot identifica din schema funcțională și constau în următoarele:

introducere date pentru înregistrarea unei cărți noi;

modificare date privind anumite cărți;

ștergerea informațiilor privind o anumită carte dacă aceasta nu mai există în bibliotecă;

introducere date privind împrumutul unor cărți;

căutare cititori care au depășit termenul de restituire;

introducere date personale pentru înscrierea unui nou cititor;

afișare date cititori;

modificare date personale ale cititorilor;

ștergerea unui cititor din baza de date;

listare cărți existente în bibliotecă , sortate după autor;

listare cărți existente în bibliotecă, sortate după gen;

căutare și afișare cărți existente după titlu;

căutare și afișare cărți existente după autor.

Fiecare din aceste activități va fi implementată prin intermediul unei proceduri apelate dintr-un modul principal care permite utilizatorului să aleagă acțiunea dorită dintr-un meniu bară cu următoarele opțiuni principale: Carti, Cititori, Imprumut, Genuri și Ieșire. Pentru fiecare din primele patru opțiuni vom avea câte un submeniu de tipul pop-up care va conține comenzile din categoria respectivă.

Carti

Adaugare titluri noi

Modificare date carti existente

Listare titluri dupa gen

Listare titluri dupa autor

Căutare titlu

Căutare autor

Stergeri titluri

Cititori

Adaugare cititori

Listare cititori

Modificare date cititori

Stergere cititori

Imprumut

Imprumut

Restituire

Listare restantieri

Listare imprumuturi

Iesire

Procedurile care implementează acțiunile programului sunt prezentate în anexă, împreună cu comentariile necesare. Alături de codul programului sunt anexate și câteva din ferestrele de lucru ale programului și un rezultat al executării acestuia.

ANEXE

CAROLINA_APP.PRG

* This file is a generated, framework-enabling component

* created by APPBUILDER

* (c) Microsoft Corporation

#INCLUDE [..\CAROLINA_APP.H]

IF TYPE([APP_GLOBAL.Class]) = "C" AND ;

UPPER(APP_GLOBAL.Class) == UPPER(APP_CLASSNAME)

MESSAGEBOX(APP_ALREADY_RUNNING_LOC,48, ;

APP_GLOBAL.cCaption )

IF VARTYPE(APP_GLOBAL.oFrame) = "O"

APP_GLOBAL.oFrame.Show()

ENDIF

RETURN

ENDIF

RELEASE APP_GLOBAL

PUBLIC APP_GLOBAL

LOCAL lcLastSetTalk, llAppRan, lnSeconds, loSplash

LOCAL ARRAY laCheck[1]

lcLastSetTalk=SET("TALK")

loSplash = .NULL.

SET TALK OFF

#IFDEF APP_SPLASHCLASS

IF NOT EMPTY(APP_SPLASHCLASS)

loSplash = NEWOBJECT(APP_SPLASHCLASS, APP_SPLASHCLASSLIB)

IF VARTYPE(loSplash) = "O"

lnSeconds = SECONDS()

loSplash.Show()

ENDIF

ENDIF

#ENDIF

APP_GLOBAL = NEWOBJECT(APP_CLASSNAME, APP_CLASSLIB)

IF VARTYPE(APP_GLOBAL) = "O" ;

AND ACLASS(laCheck,APP_GLOBAL) > 0 AND ;

ASCAN(laCheck,UPPER(APP_SUPERCLASS)) > 0

APP_GLOBAL.cReference =[APP_GLOBAL]

APP_GLOBAL.cFormMediatorName = APP_MEDIATOR_NAME

#IFDEF APP_CD

APP_CD

#ENDIF

#IFDEF APP_PATH

APP_PATH

#ENDIF

#IFDEF APP_INITIALIZE

APP_INITIALIZE

#ENDIF

IF VARTYPE(loSplash) = "O"

IF SECONDS() < lnSeconds + APP_SPLASHDELAY

=INKEY(APP_SPLASHDELAY-(SECONDS()-lnSeconds),"MH")

ENDIF

loSplash.Release()

loSplash = .NULL.

ENDIF

RELEASE laCheck, loSplash, lnSeconds

IF NOT APP_GLOBAL.Show()

IF TYPE([APP_GLOBAL.Name]) = "C"

MESSAGEBOX(APP_CANNOT_RUN_LOC,16, ;

APP_GLOBAL.cCaption )

APP_GLOBAL.Release()

ELSE

MESSAGEBOX(APP_CANNOT_RUN_LOC,16)

ENDIF

ELSE

llAppRan = .T.

ENDIF

IF TYPE([APP_GLOBAL.lReadEvents]) = "L"

IF APP_GLOBAL.lReadEvents

* the Release() method was not used

* but we've somehow gotten out of READ EVENTS…

APP_GLOBAL.Release()

ENDIF

ELSE

RELEASE APP_GLOBAL

ENDIF

ELSE

MESSAGEBOX(APP_WRONG_SUPERCLASS_LOC,16)

RELEASE APP_GLOBAL

ENDIF

IF lcLastSetTalk=="ON"

SET TALK ON

ELSE

SET TALK OFF

ENDIF

IF TYPE([APP_GLOBAL]) = "O"

* non-read events app

RETURN APP_GLOBAL

ELSE

RETURN llAppRan

ENDIF

SetObjRf.PRG – Set Object Referece.

* Copyright (c) 1997 Microsoft Corp.

* 1 Microsoft Way

* Redmond, WA 98052

* Description:

* Set an object reference to a specified property based on a specified class.

* Return new instance of specified class if name is an empty string.

LPARAMETERS toObject,tcName,tvClass,tvClassLibrary

LOCAL lcName,lcClass,lcClassLibrary,oObject,lnCount

LOCAL lnObjectRefIndex,lnObjectRefCount,oExistingObject

IF TYPE("toObject")#"O" OR ISNULL(toObject)

RETURN .NULL.

ENDIF

lcName=IIF(TYPE("tcName")=="C",ALLTRIM(tcName),LOWER(SYS(2015)))

oExistingObject=.NULL.

oObject=.NULL.

lcClassLibrary=""

DO CASE

CASE TYPE("tvClass")=="O"

oObject=tvClass

lcClass=LOWER(oObject.Class)

lcClassLibrary=LOWER(oObject.ClassLibrary)

IF NOT ISNULL(oExistingObject) AND LOWER(oExistingObject.Class)==lcClass AND ;

LOWER(oExistingObject.ClassLibrary)==lcClassLibrary

toObject.vResult=oExistingObject

RETURN toObject.vResult

ENDIF

CASE EMPTY(tvClass)

oObject=toObject

lcClass=LOWER(oObject.Class)

lcClassLibrary=LOWER(oObject.ClassLibrary)

IF NOT ISNULL(oExistingObject) AND LOWER(oExistingObject.Class)==lcClass AND ;

LOWER(oExistingObject.ClassLibrary)==lcClassLibrary

toObject.vResult=oExistingObject

RETURN toObject.vResult

ENDIF

OTHERWISE

lcClass=LOWER(ALLTRIM(tvClass))

DO CASE

CASE TYPE("tvClassLibrary")=="O"

lcClassLibrary=LOWER(tvClassLibrary.ClassLibrary)

CASE TYPE("tvClassLibrary")=="C"

IF EMPTY(tvClassLibrary)

lcClassLibrary=LOWER(toObject.ClassLibrary)

ELSE

lcClassLibrary=LOWER(ALLTRIM(tvClassLibrary))

IF EMPTY(JUSTEXT(lcClassLibrary))

lcClassLibrary=LOWER(FORCEEXT(lcClassLibrary,"vcx"))

ENDIF

llClassLib=(JUSTEXT(lcClassLibrary)=="vcx")

IF NOT "\"$lcClassLibrary

lcClassLibrary=LOWER(FORCEPATH(lcClassLibrary,JUSTPATH(toObject.ClassLibrary)))

IF NOT FILE(lcClassLibrary) AND VERSION(2)#0

lcClassLibrary=LOWER(FORCEPATH(lcClassLibrary,HOME()+"ffc\"))

IF NOT FILE(lcClassLibrary)

lcClassLibrary=LOWER(FULLPATH(JUSTFNAME(lcClassLibrary)))

ENDIF

ENDIF

ENDIF

IF NOT FILE(lcClassLibrary)

toObject.vResult=.NULL.

RETURN toObject.vResult

ENDIF

ENDIF

OTHERWISE

lcClassLibrary=""

ENDCASE

IF NOT ISNULL(oExistingObject) AND LOWER(oExistingObject.Class)==lcClass AND ;

LOWER(oExistingObject.ClassLibrary)==lcClassLibrary

toObject.vResult=oExistingObject

RETURN toObject.vResult

ENDIF

oObject=NEWOBJECT(lcClass,lcClassLibrary)

IF TYPE("oObject")#"O" OR ISNULL(oObject)

toObject.vResult=.NULL.

RETURN toObject.vResult

ENDIF

ENDCASE

DO CASE

CASE EMPTY(lcName)

toObject.vResult=oObject

RETURN toObject.vResult

OTHERWISE

IF NOT toObject.AddProperty(lcName,oObject)

oObject=.NULL.

ENDIF

ENDCASE

IF ISNULL(oObject)

toObject.vResult=.NULL.

RETURN toObject.vResult

ENDIF

IF PEMSTATUS(oObject,"oHost",5)

oObject.oHost=toObject.oHost

ELSE

oObject.AddProperty("oHost",toObject.oHost)

ENDIF

IF EMPTY(lcClassLibrary)

lcClassLibrary=LOWER(oObject.ClassLibrary)

ENDIF

lnObjectRefCount=toObject.nObjectRefCount

lnObjectRefIndex=lnObjectRefCount+1

FOR lnCount = 1 TO lnObjectRefCount

IF toObject.aObjectRefs[lnCount,1]==LOWER(lcName)

lnObjectRefIndex=lnCount

EXIT

ENDIF

ENDFOR

IF lnObjectRefIndex>lnObjectRefCount

DIMENSION toObject.aObjectRefs[lnObjectRefIndex,3]

ENDIF

toObject.aObjectRefs[lnObjectRefIndex,1]=LOWER(lcName)

toObject.aObjectRefs[lnObjectRefIndex,2]=lcClass

toObject.aObjectRefs[lnObjectRefIndex,3]=lcClassLibrary

toObject.vResult=oObject

RETURN toObject.vResult

procedure meniu

* Defineste meniul principal al aplicatiei si toate

* submeniurile

define menu principal bar at line 0

set escape on

DEFINE PAD Carti of principal prompt '<Carti' color;

scheme 3 key alt+C,''

DEFINE PAD Cititori of principal prompt 'Ci<titori';

color scheme 3 key alt+T,''

DEFINE PAD Inchirieri of principal prompt;

'<Inchirieri' color scheme 3 key alt+I,''

DEFINE PAD Gen of principal prompt '<Genuri' color;

scheme 3 key alt+G,''

DEFINE PAD exit of principal prompt 'Iesire' color;

scheme 3 key alt+X,''

ON PAD carti of principal activate popup p_carti

ON PAD cititori of principal activate popup p_cititori

ON PAD inchirieri of principal activate popup p_inchirieri

ON PAD gen of principal activate popup p_genuri

ON selection PAD exit of principal return to master

DEFINE POPUP p_carti margin relative shadow color scheme 4

DEFINE BAR 1 of p_carti prompt '<Introducere titluri noi';

KEY CTRL+I,'^I'

DEFINE BAR 2 of p_carti prompt 'Afisare dupa <gen';

KEY CTRL+G,'^G'

DEFINE BAR 3 of p_carti prompt 'Afisare dupa <autor';

KEY CTRL+A,'^A'

DEFINE BAR 4 of p_carti prompt ‘Cautare dupa <titlu’;

KEY CTRL+T,’^T’

DEFINE BAR 5 OF p_carti prompt ‘Cautare du<pa autor’;

KEY CTRL+P,’^P’

DEFINE BAR 6 of p_carti prompt '<Modificare titlu';

KEY CTRL+M,'^M'

DEFINE BAR 7 of p_carti prompt '<Stergere titlu' KEY CTRL+S,'^S'

DEFINE POPUP p_cititori margin relative shadow color scheme 4

DEFINE BAR 1 of p_cititori prompt 'A<fisare cititori';

KEY CTRL+F,'^F'

DEFINE BAR 2 of p_cititori prompt 'A<daugare cititori';

KEY CTRL+D,'^D'

DEFINE BAR 3 of p_cititori prompt 'M<odificari cititori';

KEY CTRL+O,'^O'

DEFINE BAR 4 of p_cititori prompt 'S<terger cititori' KEY; CTRL+T,'^T'

DEFINE POPUP p_inchirieri margin relative shadow color scheme 4

DEFINE BAR 1 of p-inchirieri prompt 'Im<prumut 'KEY CTRL+P,'^P'

DEFINE BAR 2 of p_inchirieri prompt '<Restituiri'KEY CTRL+R,'^R'

DEFINE BAR 3 of p_inchirieri prompt 'Afisar<e restantieri';

KEY CTRL+E,'^E'

DEFINE BAR 4 of p_inchirieri prompt 'Afisare imp<rumut';

KEY CTRL+R,'^R'

DEFINE POPUP p_genuri margin relative shadow color;

scheme 4

DEFINE BAR 1 of p_genuri prompt 'Adaugari noi genuri'

DEFINE BAR 2 of p_genuri prompt 'Modificari genuri'

DEFINE BAR 3 of p_genuri prompt 'Afisare genuri'

DEFINE BAR 4 of p_genuri prompt 'Stergere genuri'

ON selection POPUP carti do proc_carti in proc

ON selection POPUP cititori do proc_cititori in proc

ON selection POPUP inchirieri do proc_inchirieri in proc

ON selection POPUP genuri do proc_genuri in proc

do while .t.

ACTIVATE MENU principal

enddo

procedure proc_carti

* Apeleaza procedura corespunzatoare barei selectate din

* submeniul Carti

if bar()=1

do carti1

else

if bar()=2

do carti2

else

if bar()=3

do carti3

else

if bar()=4

do carti4

else

do carti5

ENDIF

ENDIF

ENDIF

ENDIF

return

procedure proc_cititori

* Apeleaza procedura corespunzatoare barei selectate din

* submeniul Cititori

if bar()=1

do cititori1

else

if bar()=2

do cititori2

else

if bar()=3

do cititori3

else

do cititori4

ENDIF

ENDIF

ENDIF

return

procedure proc_genuri

* Apeleaza procedura corespunzatoare barei selectate din

* submeniul Genuri

if bar()=1

do gen1

else

if bar()=2

do gen2

else

if bar()=3

do gen3

else

do gen4

ENDIF

ENDIF

ENDIF

return

procedure proc_inchirieri

* Apeleaza procedura corespunzatoare barei selectate din

* submeniul Imprumut

if bar()=1

do imprum1

else

if bar()=2

do imprum2

else

if bar()=3

do imprum3

else

do imprum4

ENDIF

ENDIF

ENDIF

return

procedure fer

* Defineste fereastra de alegere a unui gen literar, o

* activeaza si atribuie valoarea campului selectat

* variabilei “gen”

define window w2 from 5,40 to 20,55 in screen ;

color scheme 4 title 'Alegere gen' double close float

activate window w2

use genuri

browse fields codgen

gen=codgen

use carti

deactivate window w2

return

function gaseste

* Cauta o carte in baza de date si intoarce TRUE sau FALSE

* daca aceasta exista sau nu in B.D.

parameters cc

use carti

scan

if codcarte=cc

return .f.

endif

endscan

return .t.

procedure carti1

* Permite adaugarea informatiilor pentru inregistrarea

* unei carti noi

set color to r+/b

define window w1 from 2,2 to 9,58 in screen ;

color scheme 4 title 'Adaugarea de noi carti' double;

close float

activate window w1

use carti.dbf

go bottom

@ 1,1 say 'cod carte:' get cc default 0 picture '999999'; color scheme 2 valid gaseste(cc) error 'acest cod de; carte mai este folosit!'

@ 1,20 say 'anul:' get an default 0 picture '9999' color;

scheme 2 valid (an>=1900) and (an<2100) error;

'ati gresit anul!'

@ 2,1 say 'titlu carte:' get t default ' ' size 1,40;

color scheme 2

@ 3,1 say 'nume autor:' get a default ' ' size 1,25;

color scheme 2

@ 4,1 say 'editura:' get e default ' ' size 1,20 color; scheme 2

read

do fer

use carti

append blank

replace codgen with gen

use carti

go bottom

replace codcarte with cc;

titlu with upper(alltrim(t));

autor with upper(alltrim(a))

replace anap with an, editura with upper(alltrim(e))

clear

deactivate window w1

set color to

return

function existag

* Determina daca un anumit gen este in baza de date sau nu

parameters ccg

use genuri

scan

if codgen=upper(alltrim(ccg))

return .T.

endif

endscan

return .F.

procedure carti2

* Afisare carti existente de un anumit gen literar

set color to r+/b

use carti

go bottom

do fer

use carti

browse for codgen=upper(alltrim(gen)) noedit

set color to

return

procedure fer1

* Defineste fereastra pentru selectarea autorului

define window w2 from 5,40 to 20,85 in screen ;

color scheme 4 title 'Alegere autor' double close float

activate window w2

use carti

index on autor to au ascending unique

browse fields autor

auto=autor

deactivate window w2

return

procedure carti3

*Afiseaza toate cartile din biblioteca ce au acelasi autor

set color to r+/b

use carti

do fer1

use carti

browse for autor=upper(alltrim(auto)) noedit

set color to

return

procedure carti4

* Indexeaza cartile existente in ordine alfabetica dupa

* numele autorului

use carti

index on autor to au ascending

browse

return

procedure carti5

* Sterge o inregistrare corespunzatoare unei carti ce nu

* mai exista in biblioteca

use carti

browse

x1=recno()

delete for recno()=x1

pack

return

procedure gen4

* Sterge un gen literar care nu exista in baza de date

use genuri

browse

x2=recno()

delete for recno()=x2

pack

return

procedure gen2

* Indexeaza genurile in ordine alfabetica

use genuri

index on codgen to ge ascending

browse

return

procedure gen3

* Afiseaya genurile literare existente in biblioteca

set color to r+/b

use genuri

browse noedit

set color to

return

function gasestegen

* Stabileste daca un anumit gen literar se gaseste in baza

* de date

parameters cg

use genuri

scan

if upper(alltrim(cg))=codgen

return .f.

endif

endscan

return .t.

procedure gen1

* Defineste si activeaza ferestra de dialog pentru

* adaugarea de noi genuri in baza de date

set color to r+/b

define window w1 from 2,2 to 7,38 in screen ;

color scheme 4 title 'Adaugarea de noi genuri' double; close float

activate window w1

use genuri.dbf

go bottom

@ 1,1 say 'cod gen:' get cg default ' ' size 1,3 color; scheme 2 valid gasestegen(cg) error 'acest cod de gen mai; este folosit!'

@ 2,1 say 'denumire gen:' get t default ' ' size 1,15; color scheme 2

read

use genuri

go bottom

append blank

replace codgen with upper(cg),denumire with upper(t)

clear

deactivate window w1

set color to

return

procedure fer2

* Afiseaza lista cititorilor inregistrati

* in ordine alfabetica

define window w2 from 5,40 to 20,85 in screen ;

color scheme 4 title 'Alegere autor' double close float

activate window w2

use cititor

index on nume to nu ascending unique

browse fields nume

num=nume

deactivate window w2

return

procedure cititori1

* Afiseaza cititorii cu acelasi nume de familie

set color to r+/b

use cititor

do fer2

use cititor

&&browse for nume=upper(alltrim(num)) noedit

set color to

return

function gasestecit

* Determina daca un cititor este inregistrat sau nu

* in baza de date

parameters cc

use cititor

scan

if codcititor=cc

return .f.

endif

endscan

return .t.

procedure cititori2

* Defineste fereastra de dialog pentru adaugarea unui nou

* cititor in baza de date

set color to r+/b

define window w1 from 2,2 to 9,58 in screen color;

scheme 4 title 'Adaugarea unui nou cititor' double close; float

activate window w1

use cititor.dbf

go bottom

@ 1,1 say 'cod cititor:' get cc default 0 picture '9999'; color scheme 2 valid gasestecit(cc) error 'acest cod de; cititor mai este folosit!'

@ 1,20 say 'telefon:' get t default ' ' size 1,10 color; scheme 2

@ 2,1 say 'nume cititor:' get n default ' ' size 1,40; color scheme 2

@ 3,1 say 'adresa cititor:' get a default ' ' size 1,40; color scheme 2

@ 4,1 say 'serie buletin:' get sb default ' ' size 1,2; color scheme 2

@ 4,34 say 'numar buletin:' get nb default 0 picture; '999999' color scheme 2 valid nb>0 error 'ati introdus; seria buletinului negativa!'

read

append blank

replace codcititor with cc;

ume with upper(alltrim(n));

adresa with upper(alltrim(a))

replace telefon with alltrim(t);

seriebi with upper(alltrim(sb));

nrbi with nb

clear

deactivate window w1

set color to

return

procedure cititori3

* Afiseaza cititorii inregistrati in baza de date,

* ordonati in ordine alfabetica

use cititor

index on nume to nu ascending

browse

return

procedure cititori4

* Sterge un cititor din baza de date

use cititor

browse

x1=recno()

delete for recno()=x1

pack

return

function exista

* Verifica inregistrarea unei carti in baza de date

parameters cca

use carti

i=0

scan

if codcarte=cca

i=1

endif

endscan

if i=0

return .f.

else

use inchirieri

scan

if codcarte=cca

return .f.

endif

endscan

endif

return .t.

function existacit

* Verifica inregistrarea unui cititor in baza de date

parameters cci

use cititor

i=0

scan

if codcititor=cci

i=i+1

endif

endscan

if i=0

return .f.

else

use inchirieri

p=0

scan

if codcititor=cci

p=p+1

endif

endscan

if p>2

return .f.

endif

endif

return .t.

function trei

* Verifica daca un cititor a imprumutatat mai mult de

* trei carti

parameters xx

use inchirieri

p=0

scan

if codcititor=xx

p=p+1

endif

endscan

if p>3

use

return .t.

else

use

return .f.

endif

procedure f1

* Afiseaza toti cititorii care au mai mult de trei carti

* imprumutate

define window w2 from 5,40 to 20,85 in screen ;

color scheme 4 title 'Alegere autor' double close float

activate window w2

use cititor

index on nume to nu ascending unique

browse for trei(codcititor) fields nume

cod=codcititor

deactivate window w2

return

procedure f2

* Afiseaza cartile ordinate dupa titlu si autor

define window w2 from 5,10 to 20,85 in screen ;

color scheme 4 title 'Alegere carte' double close float

activate window w2

use carti

index on autor to au ascending

browse fields titlu,autor

codc=codcarte

deactivate window w2

return

procedure imprum1

* Defineste si activeaza fereastra pentru inregistrarea

* unui nou imprumut

set color to r+/b

define window w1 from 2,2 to 7,65 in screen color scheme; 4 title 'Imprumutarea unor carti' double close float

activate window w1

use inchirieri.dbf

go bottom

@ 1,1 say 'cod carte:' get cca default 0 picture '999999';

color scheme 2 valid exista(cca) error 'nu exista o carte; cu acest cod sau cartea este inchiriata!'

@ 1,20 say 'cod cititor' get cci default 0 picture '9999';

color scheme 2 valid existacit(cci) error 'nu exista; cititor cu acest cod sau are 3 carti imprumutate!'

@ 2,1 say 'data inchirierii:' get di default ' ' size; 1,10 color scheme 2

@ 2,30 say 'data returnarii:' get dr default ' ' size; 1,10 color scheme 2 valid ctod(dr)-ctod(di)<=15 error; 'perioada este prea mare !'

read

use inchirieri

go bottom

append blank

replace codcititor with cci;

codcarte with cca;

datain with ctod(di)

replace dataret with ctod(dr)

clear

deactivate window w1

set color to

return

function exista1

* Verifica daca o carte este inchiriata sau nu

parameters cca

use inchirieri

scan

if codcarte=cca

return .t.

endif

endscan

return .f.

procedure imprum2

* Defineste si activeaza fereastra pentru inregistrarea

* returnarii unei carti in baza de date

set color to r+/b

define window w1 from 2,2 to 5,50 in screen ;

color scheme 4 title 'Returnarea unor carti' double close float

activate window w1

use inchirieri.dbf

go bottom

@ 1,1 say 'cod carte:' get cca default 0 picture '999999' color scheme 2;

valid exista1(cca) error 'cartea nu este inchiriata!'

read

delete for codcarte=cca

pack

clear

deactivate window w1

set color to

return

function rest

* Verifica daca un anumit cititor a restituit cartea

parameters n,nu

for i=1 to n

if lista[i]=nu

return .t.

endif

next

return .f.

procedure imprum3

* Cauta cititorii restantieri, datele gasite le pune

* in variabila “lista” si afiseaza lista acestora

use inchirieri

n=0

scan

if dataret<date()

n=n+1

lista[n]=codcititor

endif

endscan

use cititor

browse for rest(n,codcititor) noedit

x=recno()

return

procedure imprum4

* Afiseaza lista cartilor imprumutate

use inchirieri

n=0

scan

n=n+1

lista[n]=codcititor

endscan

use cititor

browse for rest(n,codcititor) noedit

return

Similar Posts