Elaborarea Bazei de Date Client Server a Centrului de Instruire a Personalului Pentru Transporturi Internationale
INTRODUCERE
Prin creșterea vitezei de calcul, prin creșterea capacității de memorare a datelor, prin adăugarea unor noi componente perfotmante de intrare-ieșire, prin dezvoltarea unor limbaje de programare, s-a ajuns la prelucrarea intr-un timp scurt a unei mari cantități de informații. Organizarea și gestionarea acestor informații se face la nivelul bazelor de date.
O bază de date conține toate informațiile necesare despre obiectele ce intervin într-o mulțime de aplicații, relațiile logice între aceste informații și tehnicile de prelucrare corespunzătoare. În bazele de date are loc o integrare a datelor, în sensul că mai multe fișiere sunt privite în ansamblu, eliminându-se pe cât posibil informațiile redondante. De asemenea, se permite accesul simultan la aceleași date, situate în același loc sau distribuite spațial, a mai multor persoane de pregătiri diferite, fiecare cu stilul personal de lucru.
Sistemul de programe care permite construirea unor baze de date, întroducerea informațiilor în bazele de date și dezvoltarea de aplicații privind bazele de date se numește sistem de gestiune a bazelor de date (SGBD). Un SGBD dă posibilitatea utilizatorului să aibă acces la date folosind un limbaj de nivel înalt, apropiat de modul obișnuit de exprimare, pentru a obține informații, utilizatorul făcând abstracție de algoritmii aplicați pentru selecționarea datelor implicate și a modului de memorare a lor. SGBD-ul este o interfață între utilizatori și sistemul de operare.
Orce SGBD conține, printre alte componente, un limbaj de descriere a datelor (LDD) care permite descrierea structurii unei baze de date, a fiecărei componente a ei, a relațiilor dintre componente, a drepturilor de acces ale utilizatorilor la baza de date, a restricțiilor în reprezentarea informațiilor și alte elemente asemănătoare. LDD este utilizat atât pentru proiectarea bazelor de date, cât și pentru redefinirea lor. O altă componentă foarte importantă a unui SGBD este limbajul de cereri (LC) sau limbajul de prelucrare a datelor (LPD), ce permite operații asupra datelor aflate în baza de date, cum ar fi: încărcarea bazei de date, inserarea unui nou element, ștergerea unui element, modificarea unui element, căutarea unor elemente, realizarea a diferite statistici asupra datelor și alte asemenea operații.
Pentru a ușura munca administratorului de sistem, un SGBD conține o serie de componente ce permit încărcarea (crearea unei versiuni inițiale a bazei de date plecând de la unul sau mai multe fișiere), salvarea și reîncărcarea (efectuarea de copii periodice și posibilitatea refacerii bazei de date plecând de la aceste copii), reorganizarea (rearanjarea datelor pentru a obține performanțe superioare), statistici, analize și altele.
1. PROIECTAREA BAZELOR DE DATE CLIENT-SERVER
1.1 Arhitectura unei baze de date
O bază de date poate fi privită din mai multe puncte de vedere cum sunt:
Punctul de vedere al utilizatorilor, care lucrează cu anumite părți componente ale bazei de date numite vederi. Vederile sunt descrise prin subscheme în sublimbaje ale limbajului de descriere a datelor (SLDD). De asemenea, utilizatorii pot să primească răspunsuri la diferite cereri formulate prin intermediul limbajului de prelucrare a datelor ce sunt specifice structurilor virtuale date de vederi.
Punctul de vedere al administratorului bazei de date, care integrează toate vederile referitoare la baza da date într-un singur model numit schemă conceptuală. Schema conceptuală constituie nivelul logic al bazei de date.
Punctul de vadere al implementatorului bazei de date; de cele mai multe ori, el coincide cu administratorul bazei de date, care privește baza de date ca pe o colecție de fișiere memorate pe diferite medii externe, cum sunt benzile și discurile magnetice. Aceasta constituie nivelul fizic al bazei de date fiind de fapt singurul nivel existent efectiv.
Fiecare dintre cele trei nivele constituie subnivele. De exemplu, utilizatorii pot fi utilizatori obișnuiți, fără cunoștințe de programare, sau programatori de aplicații, organizarea vederilor corespunzătoare lor fiind diferită. La fel, nivelul fizic poate să conțină un subnivel logic, în care contează semnificația diferitelor câmpuri din înregistrările fișierelor și structurile de date asociate, și un subnivel fizic, în care esențial este numai modul de oranizare și gestionare a blocurilor pe memoria externă.
Primele două nivele sunt descrise prin planuri ce constau în enumerarea tipurilor de entități ce apar în baza de date, relațiile între aceste tipuri de entități și modul de trecere de la noțiunile acestui nivel la nivelul imediat următor. În mod curent, aceste planuri se numesc scheme externe, subsecheme conceptuale au vederi pentru primul nivel și scheme conceptuale pentru al doilea nivel. Descrierile la nivel fizic sunt făcute prin scheme interne sau scheme fizice.
1.2 Scheme externe
Informațiile care apar în scheme externe pot fi luate ca atare din nivelele logic și fizic sau pot fi deduse din aceste informații pe baza unor calcule. Alte informații ce pot să apară în vederi și care, de obicei, nu sunt prevăzute în schemele conceptuale, privesc numărul de elemente ce apar într-o mulțime, media valorilor unei mulțimi de elemente numerice și alte informații assemănătoare.
Vederile sunt definite prin intermediul unui sublimbaj de definire a datelor (SLDD) care, de cele mai multe ori, este inclus în LDD sau este foarte apropiat ca structură de LDD. Există sisteme de baze de date care permit mai multe SLDD în acelaș timp, fiecare utilizator alegându-și modul propriu de descriere a datelor. Informațiile ce se obțin din baza de date pot fi apoi prelucrate prin proceduri scrise în anumite limbaje de programare.
Pentru utilizatorul obișnuit, modul de definire a vederilor este transparent, el putând să obțină sau să modifice informțiile dorite prin intermediul unor comenzi cu structură dată, folosind forme predefinite pe care le completează sau utilizând un sistem de meniuri.
În reprezentarea intuitivă a vederilor intervin noțiunile de entitate, relație, atribut, cheie, funcționalitate, diagramă și altele.
Noțiunea de entitate nu se poate defini formal, fiind o noțiune primară. Mai multe elemente de acelaș tip formează o entitate. O problemă foarte importantă în definirea vederilor este fixarea entitățior asociate ei, adică a claselor de obiecte cu care se operează în vederea respectivă.
Fiecare entitate este descrisă de o mulțime de proprietăți esențiale numite atribute, care, pentru diferitele elemente ale entității, pot să primească valori din anumite mulțimi numite domeniul atributului respectiv. De obicei, domeniile sunt submulțimi ale mulțimii numerelor reale, ale mulțimii numerelor întregi sau ale mulțimii șirurilor de caractere. Alegerea atributelor asociate entităților este o altă problemă foarte importantă în definirea vederilor.
Un atribut sau o mulțime de atribute pentru care valorile asociate determină în mod unic orce element al entității respective se numește cheie. De obicei, orce entitate admite cel puțin o cheie, deci implicit se consideră că toate elementele unei entități sunt distincte. În cazurile în care există elemente care să aibă aceleași valori pentru toate atributele, se ia drept cheie un atribut supimentar reprezentat de numărul asociat elementului în entitatea respectivă, care definește în mod unic elementul.
Informațiile privind structura unei vederi sunt sintetizate grafic într-o diagramă entitate-relație, care pune în evidiență entitățile ce intervin reprezentate prin dreptunghiuri, atributele asociate lor reprezentate prin elipse și diferitele relații ce se stabilesc între entități reprezentete prin săgeți (cu vârf dublu către entitatea pentru care pot apărea mai multe elemente în relație cu un element din cealălaltă entitate).
1.3 Scheme conceptuale
Schema conceptuală a bazei de date combină subschemele vederilor ce privesc o anumită aplicație într-un model unitar. Modul de descriere și de reprezentare este același cu modul de descriere și de reprezentare al vederilor. Deci și în schema conceptuală intervin noțiunile de entitate, relație, cheie, diagramă entitate-relație și altele.
În combinarea vederilor se ține seama de posibilitatea identificării unor entități, de transformarea unor relații, de completarea unor informații și de modul de reconstituire a informațiilor la nivelul vederilor. În plus, trebuie să se țină seama și de modelul de baze de date ales pentru cazul particular dat.
O schemă conceptuală trebuie să se bazeze pe un model teoretic și să fie simplă, adică să fie ușor de înțeles și de prelucrat. Câteva principii ce se aplică în acest sens sunt: numărul elementelor ce o constituie să nu fie prea mare, diferitele concepte folsite să se separe clar, să se păstreze simetriile, să se țină sub control redondanțele.
1.4 Scheme interne
Schemele interne descriu diferite fișiere utilizate pentu memorarea informațiilor bazei de date și modul de operare cu ele. Traducerea schemelor conceptuale în scheme interne se face de obicei automat de către SGBD. Pe lângă stabilirea diferitelor tipuri de înregistrări utilizate în reprezentarea fizică a datelor, se specifică existența indecșilor asociați unor fișiere, semnificația câmpurilor înregistrărilor, ordinea de apariție a înregistrărilor și modul de acces.
1.5 Introducere în proiectarea batelor de date
Proiectarea bazelor de date presupune fixarea structurii bazei de date și a metodelor de prelucrare a datelor, spre deosebire de utilizarea bazei de date, care privește mai mult informațiile stocate în baza de date la un moment dat. Dacă, în mod obișnuit, baza de date își schimbă frecvent conțunutul, structura ei rămâne nemodificată pe lungi perioade de timp.
Prin proiectare se determină un model semantic, care să reflecte cât mai fidel lumea reală, construit astfel:
Se identifică o mulțime de concepte semantice (entități, tipuri de entități, proprietăți ale entităților, identificatorii entităților, relații între entități și altele) ce dau informații despre lumea reală.
Se asociază obiecte simbolice formale prin care sunt reprezentate conceptele semantice.
Se definesc reguli de integritate formale ce se aplică obiectellor simbolice.
Se definește o mulțime de operatori formali ce pot să transforme obiectele formale.
Un model de etapizare a construirii unei baze de date ar putea fi următorul:
Studiul de fezabilitate, ce constă în cercetarea sistemelor operative deja existente, stabilirea unor alternative cu evaluarea costurilor, a avantajelor și dezavantajelor fiecărei alternative în parte.
Cercetarea sistemului prin determinarea diferitelor detalii ale sistemului prizent (tipuri de date, dimensiuni, condiții excepție) folosind metode de interogare, chestionare, exemplificări și observații directe aplicate în sistemul deja existent.
Analiza sistemului prin determinarea cauzelor diferitelor evenimente și a adoptării diferitelor metode, eventualele alternative posibile și justificarea lor.
Proiectarea sistemului prin determinarea celui mai bun model de reprezenare și prelucrare a dateor, de asigurare a securității și integrității.
Dezvoltarea sistemului prin stabilirea detaliilor asociate dateor prevăzute a fi luate în considerație, a relațiilor dintre ele și a modului de reprizentare fizică.
Impementarea sistemului prin proiectarea, scrierea și testarea programelor, antrenarea utilizatorilor, alcătuirea documentației, crearea și încărcarea fișierior.
Revizuire și intreținere prin probe de lucru ale noului sistem, efectuarea unor eventuale modificări, adăugarea de noi componente și urmărirea procesului de prelucrare a datelor.
În proiectarea bazelor de date se ține seama de independența datelor pe diferite nivele. De exemplu, reprezentarea fizică a datelor se poate schimba în timp pentru a obține performanțe superioare din punct de vedere al timpului de răspuns și al spațiului ocupat, fără ca aceasta să afecteze modul de reprezentare a datelor în schema consă reflecte cât mai fidel lumea reală, construit astfel:
Se identifică o mulțime de concepte semantice (entități, tipuri de entități, proprietăți ale entităților, identificatorii entităților, relații între entități și altele) ce dau informații despre lumea reală.
Se asociază obiecte simbolice formale prin care sunt reprezentate conceptele semantice.
Se definesc reguli de integritate formale ce se aplică obiectellor simbolice.
Se definește o mulțime de operatori formali ce pot să transforme obiectele formale.
Un model de etapizare a construirii unei baze de date ar putea fi următorul:
Studiul de fezabilitate, ce constă în cercetarea sistemelor operative deja existente, stabilirea unor alternative cu evaluarea costurilor, a avantajelor și dezavantajelor fiecărei alternative în parte.
Cercetarea sistemului prin determinarea diferitelor detalii ale sistemului prizent (tipuri de date, dimensiuni, condiții excepție) folosind metode de interogare, chestionare, exemplificări și observații directe aplicate în sistemul deja existent.
Analiza sistemului prin determinarea cauzelor diferitelor evenimente și a adoptării diferitelor metode, eventualele alternative posibile și justificarea lor.
Proiectarea sistemului prin determinarea celui mai bun model de reprezenare și prelucrare a dateor, de asigurare a securității și integrității.
Dezvoltarea sistemului prin stabilirea detaliilor asociate dateor prevăzute a fi luate în considerație, a relațiilor dintre ele și a modului de reprizentare fizică.
Impementarea sistemului prin proiectarea, scrierea și testarea programelor, antrenarea utilizatorilor, alcătuirea documentației, crearea și încărcarea fișierior.
Revizuire și intreținere prin probe de lucru ale noului sistem, efectuarea unor eventuale modificări, adăugarea de noi componente și urmărirea procesului de prelucrare a datelor.
În proiectarea bazelor de date se ține seama de independența datelor pe diferite nivele. De exemplu, reprezentarea fizică a datelor se poate schimba în timp pentru a obține performanțe superioare din punct de vedere al timpului de răspuns și al spațiului ocupat, fără ca aceasta să afecteze modul de reprezentare a datelor în schema conceptuală. Această independență se numește independență fizică a datelor. De asemenea, între vederi și schema conceptuală există o independență numită independență logică a datelor. În timpul exestenței unei baze de date pot apărea modificări în schema conceptuală prin adăugarea unor noi entități sau prin adăugarea de noi atribute unor entități existente. Vederile care nu fac referiri la câmpurile modificate rămân neschimbate, fiind rescrise numai aplicațiile pentru care s-au modificat unele atribute, sau pot fi construite vederi noi fără a fi necesară redefinirea schemei conceptuale asociate bazei de date.
Proiectarea unei baze de date privește în primul rând nivelul logic și mai puțin pe cel fizic. Proiectarea se poate face plecând de la modelul relațional care permitwe o tehnoogie de proiectare și apoi se poate transforma rezultatul proiectării în oricare dintre modele, prin adaptările corespunzătoare.
Modelarea bazelor de date este un proces de definire amănunțită, precisă, pas cu pas, a tuturor elementelor ce permit o documentare completă privind cererile de informații. În această procedură se foosesc metode specifice de reprezentare a obiectelor. La proiectarea bazelor de date trebuie să funcționeze o comunicare efectivă între cel care proiectează baze de date și cei care o implementează, cei care o untilizează pentru a găsi și a valida soluțiile alese la proiectare. De cele mai multe ori, foosirea schemelor este mai sugestivă decât folosirea unor texte explicative.
Proiectarea urmărește obținerea unor baze de date care să întrunească următoarele calități:
Corectitudine: reprezintarea cât mai fidelă în baza de date a modului obișnuit de lucru cu datele în sistemul real.
Consistență: informațiile corespunzătoare obiectelor cu care se lucrează în baza de date (nume, definire, relații, documentare etc.) să nu conțină contradicții.
Distribuire: informațiile să poată fi utilizate de aplicații multiple și se poată fi accesate de mai mulți utilizatori aflați în diferite locuri, utilizând medii de calcul diverse și acoperind un număr mare de cereri posibile.
Flexibilitate: facilități de adăugare de componente care să reflecte cereri noi de informații, care să înbunătățească performanțele sau să adapteze datele pentru eventualele schimbări din lumea reală.
Criteriile de clasificare pentru determinarea modeluui logic de date optim corespunzător unei baze de date sunt:
Validare structurală: reflectarea consistentăa modului de utilizare a informațiilor în lumea reală.
Simplitate: ușurința înțelegerii structurillor chiar de către utilizatori fără o pregătire specială.
Neredondanță: eliminarea pe cât posibil, a reprezentării de mai multe ori a aceleași informații sau a informațiilor ce se pot deduce logic din altele.
Distribuire: un model general aplicabil mai multor domenii, fără caracteristici specifice unor aplicații sau tehnologii particulare.
Extensibilitate: posibilitatea de a dezvolta noi componente cu efecte minime asupra bazei de date existente.
Integritate: consecința în modul de utilizare și întreținere ale valorilor din informații.
2. MODELUL LOGIC AL DATELOR
2.1 Modelarea logică a datelor
Cea mai mare importantă parte din procesul construirii unei baze de date o constituie studiul sistemului ce urmează să fie reflectat în baza de date. Stabilirea informațiilor relevante pentru sistem și a relațiilor dintre ele este un lucru esențial pentru etapele următoare.
Baza de date este un model al lumii reale și nu poate reprezenta decât un număr limitat de caracteristici ale ei necesare în unele aplicații. Oricât de perfecționat ar fi modelul utilizat, există aplicații care se pot concepe astfel încât să nu poată fi satisfăcute de baza de date. Deci apar inerpretări subiective ale lumii reale reflectate în baza de date.
Pentru a construi o bază de date corespunzătoare unui sistem real dat, se face mai întâi o apreciere generală a sistemului. În această apreciere se includ informații privind structura sistemului – elementele esențiale ale acestuia care sunt cuprinse într-o schiță preliminară. Schița cuprinde, printre alte informații, și modul în care sistemul este văzut de diferitele persoane implicate în sistemul respectiv. Se creează un model informațional în care sunt cuprinse principalele funcțiuni și fluxul de informații din sistem. Sistemul trebuie privit unitar și nu ca o alăturare a componentelor sale. În baza de date, multe părți sunt folosite în comun de diferitele componente ale sistemului.
Modelul utilizat frecvent în acest caz se numește modelul entitate-relație (E-R) descris de Chen în 1976 și perfecționat ulterior. Acest model are drept obiecte semantice următoarele:
Entitatea, definită ca un lucru ce poate fi unic identificabil. Se pot deosebi entități obișnuite (regular entities) și entități speciale (weak entities), a căror existență este dependentă de existența altor entități.
Proprietatea sau atributul ce definește o latură a entității sau relației, care poate lua valori într-un domeniu asociat. Proprietățile pot să fie simple sau compuse, chei (să identifice unic entitatea respectivă), univaloare sau multivaloare (grup repetitiv), de bază sau derivată, pot fi omise (proprietate necunoscută sau neapreciabilă) și așa mai departe.
Relația ce definește o asociere între entități. Numărul de entități ce apar într-o relație se numește gradul sau aritatea relației. O entitate E poate să participe la relația R total (prin toate elementele lui E) sau parțial. Relațiile pot fi tipul 1-la-1, 1-la-mai-mulți (mai-mulți-la-1) sau mai-mulți-la-mai-mulți.
Subtipul unei entități este un tip de intetate ce formează o submuțime a entității respective, de obicei cu proprietăți suplimentare. Tipul de entitate de care aparține un subtip se numește supertip. Pentru fiecare entitate în parte se poate stabili un tip ierarhic prin subordonările de formă subtip și supertip.
Modelul logic al bazei de date este reprezentat grafic prin diagrame, entitate-relație. În aceste diagrame, entitățile sunt reprezentate sub formă de dreptunghiuri ce conțin numele entității respective. Pentru entitățile speciale, linia ce înconjoară dreptunghiul este dublă. Proprietățile sunt reprezentate prin elipse ce conțin numele proprietății respective, unite cu linii de entitățile la care sunt asuciate. Elipsa se desenează punctat dacă proprietatea este derivată și dublat dacă este multivaloare. Proprietățile compuse au atașate componentele llor reprezentate tot sub forma de elipse. Cheile sunt subliniate. Relațiile sunt reprezentate în formă de romburi etichetate cu numele tipului relației respective. Rombu se dublează dacă realția indică legătura între o entitate specială și entitatea de care depinde ea. Relația este unită prin linii cu entitățile ce apar în ea, etichetate cu „one” sau „many”, după caz. Linia se dublează dacă participarea în relație a entității este totală. Orice subtip Y a lui X se marchează cu o linie de la Y la X pe care se pune semnul de incliziune de mulțimi (a lui Y în X).
Un alt model utilizat în proiectarea llogică a datelor este modelul relațional extins (extended relational model sau, pe scurt, RM/T) introdus de Codd. În acest model nu se face distincție între entități și relații. Entitățile sunt clasificate în trei tipuri: entități nucleu (existență independentă), entități caracteristice (ce descriu proprietăți ale altor entități) și entități asociative (ce descriu asocieri între diferite entități). În sistemul RM/T, atât cheile primare, cât și cheile străine se consideră surogate, combinații ce determină unic un sistem informația respectivă pe toată durata existenței ei. Baza de date conține câte o E-relație pentru fiecare tip de entitate, acestea fiind relații unare ce conțin surogatele entităților din tipul de entitate asociat. Tipurile de proprietăți ale unui tip de entitate dat sunt reprezentate printr-o mulțime de P-relații.
Sistemul RM/T conține o serie de reguli de integritate și anume: regula integrității entității (cheile nu pot să conțină valoarea null), regula integrității referențiae (necesitatea existenții elementului referit printr-o cheie străină nenulă), regula integrității E-relațiilor (pentru E-relații sunt permise inserări și ștergeri dar nu modificări), integritatea proprietăților (o proprietate nu poate exista în baza de date dacă nu există și entitatea pe care o descrie), integritatea caracteristicelor (o entitate caracteristică nu poate exista în baza de date fără existența entității pe care o descrie), integritatea asocierii (o entitate asociativă nu poate exista în baza de date decât dacă există și entitățile asociate cu ea), integritatea desemnărilor (o desemnare se poate folosi numai pentru elemente existente) și integritatea subtipului (un subtip există numai în prezența supertipului său).
Metodologia proiectării folosind sistemul RM/T cuprinde următorii pași: determinarea entităților nucleu, determinarea entităților asociative, determinarea desemnărilor, determinarea entităților caracteristice, determinarea proprietăților și determinarea supertipurilor și subtipurilor.
2.2 Vederile utilizatorilor
Fiecare aplicație presupune utilizarea unei părți din baza de date, folosind informațiile într-un mod determinat. Această parte de informație se numește vedere. O bază de date poate să aibă una sau mai multe vederi. Fiecărei vederi îi corespunde un grup de utilizatori. Pentru un grup particular să definesc tipurile de cereri de informații și modul de determinare a datelor din baza de date care formează răspunsuri la aceste cereri.
Un pas important în proiectarea unei baze de date corespunzătoare uni sistem este determinarea vederilor și claselor de utilizatori asociate lor. Acestea se stabilesc, de obicei prin colaborarea persoanelor cu responsabilități în sistem.
Utilizarea vederilor permite independența logică a datelor, în sensul că informațiile și programele utilizatorilor nu sunt dependente de structura logică a bazei de date, și se poate modifica în timp prin extindere sau restructurare.
Extinderea se poate face fie prin adăugarea de noi atribute la relațiile existente în baza de date, fie prin adăugarea unor relații noi. Restructurarea presupune rearanjarea diferitelor atribute în noi relații. Vederile permit ca aceleași date să fie privite în mod diferit de diferiți utilizatori. Ele determină simplificarea modului de percepere a utilizatorilor prin ignorarea informațiilor care nu sunt importante pentru aplicația respectivă. Importantă este și asigurarea automată a securității datelor la care utillizatorii nu au acces.
2.3 Cnstruirea unei vederi utilizator
Se stabilesc persoanele de la care urmează să fie obținute informațiile prevind vederea respectivă, ordinea în care urmează să fie intervievați, subiectele ce urmează să fie descutate și întrebările esențiale ce trebuie puse. Se urmărește obținerea unor informații relevante pentru sistemul respectiv, concise, corecte și actuale. Vederile trebuie să fie adaptabile în sensul de a putea fi schimbate în funcție de necesitățile utilizatorului. Astfel trebuie să permită adăugarea de noi componente, eliminarea unor caracteristici definirea altor metode de reprezentare externă etc.
Având o structură generală a aplicației cunoscând persoanele ce utilizează acea parte de sistem și informațiile de care au ele nevoie, se poate construi un model de informații pentru vederea respectivă. Plecând de la o schiță grafică având principalele lemente pe baza discuțiilor avute și a observării sistemului existent se precizează detaliile și se fac corecturile necesare. Se stabilesc, de asemenea, fluxurile de resurse, diferitel legături cu exteriorul interfeței (interfețe) și limitările existente.
Pentru construirea vederilor se pot aplica diferite strategii cum sunt, de exemplu, cele ce urmează:
Metoda elementelor componente (Oganisation Ceart approach) prin care se definesc, pe rând, fiecare din elementele componente ale vederii.
Integrarea ulterioară (Integration Later) prin punerea de acord a informațiilor comune diferitelor componente.
Metoda de sus în jos (Top Down approach) în care detaliile sunt precizate pe nivele succesive.
Metoda coecției de date (The Data Collection approach) în care se face o achiziție de date ce urmează să fie analizate în momentul întroducerii în baza de date, reținându-se numai datele utile.
Metoda bazei de date (The Data Base approach) în care datele sunt achiziționate sub forma de reprezentare din baza de date.
2.4 Integrarea vederilor utilizatorilor
O ultima etapă în proiectarea logică o reprezintă integrarea vederilor utilizatorilor prin care se obține modelul de date logic al bazei de date. Această fază cuprinde subfazele de cobminare a vederilor utillizator, integrarea cu modelele existente de date și analizele privind stabilitatea și posibilitatea dezvoltării ulterioare.
Cobminarea vederilor utilizator presupune punerea de acord a diferitelor funcții definite în vederi și a diferitelor grupuri de utilizatori cu identificarea noțiunilor și relațiilor comune, eventual purtând nume diferite, a valorilor derivate, a constrângerilor de reprezentare a regulelor de acces la date etc. Pentru părțile comune unor vederi trebuie rezolvate probleme legate de conflicte, de posibile inconsistențe și de stbilire a unor relații noi de legătură între vederi pentru a obține modelul logic de date compus.
Integrarea cu metodele existente de date presupune examinarea raportului dintre modelul logic rezultat în raport cu modelele dezvoltate în alte scopuri. Se pot detecta zone comune și une inconsistențe în raport cu alte modele, care permit sau nu modificarea pentru a rezolva aceste probeme.
Analiza privind stabilitatea și posibillitățile de dezvoltatre constă în considerarea schimbărilor viitoare care pot să afecteze baza de date. Pentru schimbările semnificative, inevitabile sau probabile se prevăd elemente incorporate în modelul logic sau, cel puțin, se face o documentare ce permite realizarea cu mai multă ușurință a unor schimbări ulterioare. Scopul este de a asigura o perioadă cât mai mare de stabililtate a modelului logic, perioada în care corectitudinea și utillitatea bazei de date se mențin la diferite schimbări în schemele conceptuale, dar fără să fie afectat modelul logic.
2.5 Descrierea bazelor de date de tip relațional
Pentru transformarea unei diagrame de tip entitate-relație, prin care se descrie modelul logic al bazei de date un model relațional de baze de date, se aplică următoarele reguli:
Fiecărei entități i se asociază o relație de bază având drept cheie principală cheia entității. Entităților speciale li se asociază și chei străine pentru a arata dependența de alte entități.
Fiecărei relații de tip mai-mulți-la-mai-mulți îi corespunde o relație de bază având câte o chie străină pentru fiecare din entitățile legate prin această relație. Cheia primară este constituită din reuniunea tuturor cheilor străine.
Fiecărei relației de tipul mai-mulți-la-unul i se asociază o cheie străină în prima entitate cu referință la cea de-a doua entitate. Relațiile unu-la-unu se tratează asemănător.
Proprietăților li se asociază atribute în relațiile de bază corespunzătoare. Pentru proprietățile multevaloare se crează noi relații ce sunt legate prin chei străne de relația în care apare proprietatea multevaloare.
Pentru subtipuri se reprezintă în relațiile asociate numai proprietățile ce nu se pot aplica supratipului din care aparțin.
Modelele de tip RM/T se transformă în modelul relațional astfel:
Fiecărei entități nucleu i se asociază o relație de bază având câte o cheie primară.
Fiecărei entități asociative i se asociază o relație de bază având câte o cheie străină pentru fiecare din entitățile ce intervin în asociere.
Desemnările sunt reprezentate prin chei străine.
Fiecărei entități caracteristice i se asociază o relație de bază cu cheie străină pentru entitatea caracterizată.
Proprietățile sunt repartizate ca atribute ale relațiilor respective.
Subtipurile și supratipurile sunt indicate prin chei străine.
2.6 Implementarea modelului relațional
Modelul relațional este ușor de tradus la nivel fizic. Relațiile de bază sunt implementate prin fișiere cu înregistrări de lungime fixată, fiecărui tuplu îi corespunde o înregistrare și fiecărui atribut îi corespunde un câmp în înregistrare.
De cele mai multe ori, forma de reprezentare este cea cu fișiere indexat secvențiale, cu index pentru câmpurile ce corespund cheii principale.
3. UTILIZAREA SQL ÎN APLICAȚII CLIENT-SERVER
3.1 Întroducere în SQL
SQL (Structured Query Language) este unul din limbajele relaționale de cereri care formează nucleul multor sisteme de gestiune a bazelor de date. Se poate spune că SQL este o perfecționare a limbajului SQUARE, eliminând utilizarea indicilor ce preced sau succed numele unei relații prin utilizarea unor cuvinte cheie. În mai 1986 a fost recunoscută de ANSI standardizarea limbajului SQL.
Într.o primă variantă, SQL s-a numit SEQUEL. El a fost definit prima oară de Chamberlin și alți cercetători de la IBM Research Laboratory din San Jose, California, în 1974, și a fost folosit în prototipul System R și apoi în DB2pentru mediu MVS, SQL/DS pentru medii VM și VSE, OS/2 Extended Edition DataBase Manager pentru mediu OS/2 extins, SQL/400 pentru mediu OS/400 și multe alte sisteme de operare și sisteme de calcul.
Majoritatea instrucțiuneleor din SQL sunt executabile, ele putând fi interpretate și executate imediat în mod interactiv sau putând fi incluse în diferite aplicații scrise în limbaje de programare cum sunt APL, BASIC, C, COBOL, FORTRAN, PL/I, Assebmler și altele (Embedded SQL), wxwcutânduse în momentul rulării programului respectiv. Între cee două moduri de utilizare sunt mici deosebiri, cum ar fi prefixarea instrucțiunilor executabile SQL din programe cu EXEC SQL și definirea unor variabile de transfer de informații prin INTO: variabilă, ce permit comunicarea între programe și sistemul de gestiune a bazelor de date.
3.2 SQL inerpretabil
Aplicația din SQUARE de forma:
A1,A2,…,AmRB1,B2,…,Bm(1b1,2b2,…,mbm)
se exprimă în SQL prin succesiunea de comenzi următoare:
SELECT A1,A2,…,An
FROM R
WHERE B11b1 AND B22b2 AND … AND Bmmbm
După WHERE poate să apară o formulă care cuprinde atribute ale relațiilor ce urmează după FROM și constantele legate între ele prin operații și comparații aritmetice, operatori booleeni (NOT; AND sau OR) operatori cu mulțimi (UNION, INTERSECT și MINUS) sau de apartenență la mulțimi (X IN S sau, echivalent, S CONTAINS X, X NOT IN S sau S DOES NOT CONTAIN X, cu X element sau muțime și S mulțime). Unele relații ce apar în condiția de după WHERE pot fi obținute, la rândul lor printr-o construcție SELECT-FROM-WHERE. Forma generală a instrucțiunii de căutare SELECT este:
SELECT [ DISTINCT ] elemente
FROM table
[ WHERE conditie ]
[GROUP BZ câmpuri [ HAVING condiție ] ]
[ ORDER BY câmpuri ];
În acest llimbaj, la proiecția nu sunt eliminate duplicatele. Pentru a elimena duplicatele se pune după SELECT opțiunea DISTINCT. Drept elemente pot să apară valori selectate sau expresii construite cu aceste valori, iar dacă sunt considerate toate câmpurile tablourilor, atunci se pune caracterul „*” după SELECT în locul listei elementelor selectate. Condiția de după WHERE poate să conțină operatori de comparație =, <>, >, >=, < și <=, operatori booleeni AND, OR și NOT, eventua cu paranteze pentru schimbarea ordinii de avauare. Pentru câmpurile indicate în scopul ordonării se poate specifica dacă trebuie să apară crescător prin ASC (ordinea impicită) sau descrescător prin DESC. Câmpurile se pot indica atât prin nume, cât și prin numărul ce indică poziția lor în tabel. Este permisă folosirea funcțiilor agregate COUNT, SUM, AVG, MAX și MIN, care se pot aplica relațiilor unare având ca rezultat numărul, suma, media, cel mai mare și, respectiv, cel mai mic element, din cele cărora li se aplicat funcția respectivă, cu eliminarea duplicatelor dacă funcția este precedată de DISTINCT. Funcțiile agregate se pot aplica unor grupe de elemente indicate prin GROUP BY și eventual selectate prin condiția din HAVING.
În condițiile din instrucțiunea SELECT pot fi utilizate și construcții de forma:
câmp LIKE cuvânt
câmp NOT LIKE cuvânt
câmp IS NULL
câmp IS NOT NULL
unde câmp este de tip cuvânt și cuvânt poate se conține caracterul „_”, care înlocuiește orce caracter, sau „%”, care înlocuiește orce cuvânt, orce alt caracter fiind luat ca atare. Rezultatul este o valoare de adevăr, după cum câmp conține o valoare de caractere ce se conformează modului de alcătuire din cuvânt sau nu, respectiv conține sau nu valoarea null. Se pot folosi, de asemenea, IN sau NOT IN pentru a indica apartenența sau neapartenența la o mulțime, EXISTS sau NOT EXISTS pentru a verifica existența sai inexistența unui element într-o mulțime și se poate aăplica UNION între două selecții pentru a realiza reuniunea celor două relații ce rezultă în urma operațiilor de selecție.
Se pot atribui nume unor tupluri ale unor relații folosite ca variabile libere ce por fi utilizate în celelalte părți componente ale cererii. De exemplu:
SELECT … FROM R T WHERE …
dă numele T unui tuplu al relației R, acest nume putând fi folosit după SELECT sau după WHERE, T.A semnificând valoarea componentei A a tuplului T.
Dacă după FROM apare o istă de relații R1,R2,…,Rn, se consideră toate combinațiile de tupluri t1,t2,…,tn cu ti din Ri și, pentru acele combinații ce îndeplinesc condițiile ce urmează după WHERE, se include la ieșire lista componentelor specificate după SELECT. Apariția unei steluțe după SELECT indică selectarea tuuturor atributelor ce apar în tuplurile implicate ulterior și lipsa lui WHERE indică o condiție mereu adevarată, deci sunt selectate toate tuplurile relațiilor implicate.
Pentru a demonstra completitudinea limbajulșui SQL, vom arăta cum se pot exprima acelea cinci operații de bază din algebra relațională din acest limbaj.
Reuniunea relațiilor R și S se exprimă astfel:
(SELECT *
FROM R)
UNION
(SELECT *
FROM S)
Diferența relațiilor R și S se exprimă la fel ca reuniunea înlocuind cuvântul UNION cu MINUS:
(SELECT *
FROM R)
MINUS
(SELECT *
FROM S)
Produsul cartezian al relațiilor R și S se exprimă prin:
SELECT *
FROM R,S
Proiecția lui R după atributele A1,A2,…,Ak se exprimă cu :
SELECT UNIQUE A1,A2,…,Ak
FROM R
Selecția din relația R cu condiția F se exprimă cu succesiunea de comenzi următoare:
SELECT *
FROM R
WHERE F
Se poate atribui un nume R relației rezultate ca o cerere precedând această cerere cu o comandă de tipul:
ASSIGN TO R: selecție
Definirea unei relații se face cu instrucțiunea CREATE TABLE, în care se specifică numele tabelului care se crează, numele și tipurile de date ale atributelor sale, câmpurile care sunt componente ale cheiei primare și ale unor chei străine împreună cu corespondentele lor, având forma generală următoare:
CREATE TABLE tabel
(definire_câmp [,definire_câmp]…
[,PRIMARY KEY (câmpuri)]
[,FOREIGN KEY (câmp) REFERANCES tabel
[,FOREIGN KEY (câmp) REFERANCES tabel ]…] );
unde definire_câmp este de forma:
câmp tip_date [NOT NULL]
și tip_date poate fi INTEGER pentru întreg pe un cuvânt, SMALLINT pentru un întreg pe un semicuvânt, DECIMAL(p,q) pentru număr zecimal cu precizie de p cifre și semn și având punctul zecimal la q cifre din dreapta, FLOAT(p) pentru număr real cu p cifre binare precizie, CHARACTER(n) pentru cuvinte din n octeți, VARCHAR(n) pentru cuvinte de cel mult n octeți, GRAPHIC(n) pentru cuvinte cu n caractere de câte 16 biți VARGRAPHICS(n) pentru cuvinte de cel mult n caractere de câte 16 biți, DATE pentru exprimarea datei sub forma aaaallzz, TIME pentru exprimarea orei sub forma oommss, TIMESTAMP pentru exprimarea microsecunde a unei combinații de dată și oră. Pot fi utilizate și prescurtări de tip INT, DEC sau CHAR pentru INTEGER, DECIMAL și, respectiv, CHARACTER. Câmpurile specificate NOT NULL trebuie să conțină o valloare definită din domeniul indicat, isr celelalte câmpuri pot să nu fie definite sau să nu se aplice pentru tuplul respectiv.
Instrucțiunea CREATE TABLE produce la nuvel fizic fițiere ce corespund tabelelor definite și care inițial sunt vide. Definirea unor tabele vituale utilizate ca vederi se face printr-o instrucțiune analogică CREATE VIEW, iar crearea unui index pentru un tabel dat se face prin CREATE INDEX. Instrucțiunele DROP TABLE, DROP VIEW și DROP INDEX sunt folosite pentru eliminarea unor elemente din baza de date de tip tabel, vedere și, respectiv index. Indecșii sunt creați și eliminați de administratorul de sistem și sunt utilizați automat în cererile utilizatărilor.
Forma generală a instrucțiunilor precedente este:
CREATE VIEW vedere [(coloană [, coloană ] … )]
AS subcerere
[ WITH CHECK OPTION ];
CREATE [ UNIQUE ] INDEX index
ON tabel ( camp [ ordine ] [, camp [ ordine ] ] …) [ CLUSTER ];
DROP TABLE tabel;
DROP VIEW vedere;
DROP INDEX index;
în care WITH CHECK OPTION indică verificarea condițiilor de definirea vederii în momentul executării operațiilor UPDATE și INSERT, UNIQUE specifiaă necesitatea de a avea un singur tuplu în tabel pentru valorile câmpurilor specificate în index, ordine poate fi ASC pentru crescător (în mod implicit) sau DESC pentru descrescător, ordinea considerqată fiind cea lexicografică, iar CLUSTER presupune gruparea tuplurilor după adresele date de index, putând să apară în cel mult un index pentru fiecare tabel în parte. Eliminarea unui tabel produce eliminarea automată a tuturor vederilor în care este el implicat.
Într-un tabel se poate adăuga un nou câmp la dreapta prin utillizarea instrucțiunii ALTER TABLE, având forma generală:
ALTER TABLE tabel ADD câmp tip_date;
Sistemul adaugă automat valoarea Null pentru tuplurile deja existente în tabel și permite folosirea unor valori corespunzătoare pentru tuplurile adăugate sau modificate.
Instrucțiunile de prelucrare a datelor din SQL sunt:
SELECT, UPDATE (pentru reactualizări), DELETE (pentru eliminări de tupluri) și INSERT (pentru adăugarea de noi tupluri). Ele se aplică unei mulțimi de înregistrări. Ultimele trei instrucțiuni au următoaree forme generale:
UPDATE tabel
SET câmp = expresie [, camp = expresie ] …
[ WHERE condiție ];
DELETE
FROM tabel
[ WHERE condiție ];
INSERT
INTO tabel [( camp [, câmp ] …)]
VALUE ( valoare [, valoare ] …);
Sau
INSERT
INTO tabel [( câmp [, camp ] … )]
Subcondiție;
3.3 SQL programabil
În cazul utilizării comenzilor SQL în programele scrise în diferite limbaje de programare, se aplică reguli suplimentare cum sunt următoarele:
Toate instrucțiunile executabile din SQL interpretabil pot fi utilizate și în SQL programabil.
Instrucțiunile SQL sunt precedate de EXEC SQL și sunt urmate de un simbol special de terminare (de exemplu ’;’).
O instrucțiune executabilă SQL poate să apară oriunde poate apărea o instrucțiune executabilă din limbajul gazdă.
În instrucțiunile SQL pot fi incluse referințe la variabile din programul gazdă precedate de ‘:’ pentru a le deosebi de numele SQL.
Tabelele utilizate trebuie declarate în program prin instrucțiuni DECLARE TABLE specifice limbajului.
După executarea unei instrucțiuni SQL se introduce în program informație într-o arie de comunicație SQL (SQLCA) care, printre altele, are indicatorul SQLCODE ce conține valoarea zero dacă instrucțiunea s-a efectuat corect; o valoare pozitivă indică o atenționare după execuție și o valoare negativă indică o eroare și o execuție incompletă. Instrucțiunea EXEC SQL INCLUDE SQLCA include aria de comunicare SQL în program.
Trebuie să existe concordanță între tipul variabilelor din program și tipul datelor din baza de date implicate de ele.
În program pot exista variabile cu nume ce reprezintă și nume de coloane în baza de date .
Pentru efectuarea operațiilor din SQL programabil se folosește de cele mai mute ori un cursor. Se pot efectua fără cursor instrucțiunile SELECT singular (cu selectarea unui singur tuplu), UPDATE (fără forma CURRENT), DELETE (fără forma CURRENT) și INSERT.
Pentru selectarea mai multor tupluri, se declară mai întâi un cursor printr-o construcție de forma:
EXEC SQL DECLARE cursor CURSOR
FOR instrucțiune-selectare
[ FOR UPDATE OF coloană [, coloană ] … ]
[ ORDER BY coloană [, coloană ] … ];
care este o instrucțiune declarativă (neexecutabilă). Se poate folosi ORDER BY numai în absența lui FOR UPDATE pentru a indica ordinea în care sunt considerate tuplurile. Într-un program pot să apară mai multe instrucțiuni de acest tip. Pentru a utiliza un cursor, el trebuie mai întâi activat prin instrucțiunea:
EXEC SQL OPEN cursor;
Se selectează pe rând câte un tuplu prin instrucțiunea:
EXEC SQL FETCH cursor INTO țintă [, țintă ] … ;
Unde țintă este de forma :variabiă [:variabilă] și dă numele variabilei ce primește valoarea corespunzătoare câmpului din tuplul selectat. Dacă nu mai sunt tupluri de selectat, se face SQLCODE = +100 și nu se mai întorc alte date. Dezactivarea cursorului se face printr-o construcție de forma:
EXEC SQL CLOSE cursor;
Valorile variabilelor ce apar în definirea cursoruui sunt luate în considerare numai la activarea cursorului, fiind neoperante schimbărie lor ulterioare ce apar înainte de o nouă reactivare a cursorului.
Cursorul mai poate fi utillizat și în formele CURRENT ale instrucțiunilor UPDATE și DELETE, având respectiv formele:
EXEC SQL UPDATE tabel
SET câmp =expresie[, câmp = expresie] …
WHERE CURRENT OF cursor;
EXEC SQL DELETE
FROM tabel
WHERE CURRENT OF cursor;
care se aplică tuplului indicat de cursor. Aceste operații nu se pot aplica dacă, la definirea cursorului, în SELECT apare UNION sau ORDER BY sau el definește o vedere ce nu se poate modifica. Dacă se fac modificări, la definirea cursorului implicat se trec în FOR UPDATE toate câmpurile ce suhnt modificate cu UPDATE.
Testarea condițiilor de operare a instrucțiunilor cu cursor se poate face și prin instrucțiunea:
EXEC SQL WHENEVER condiție acțiune;
unde condiție poate fi NOT FOUND (adevărat pentru SQLCODE = 100), SQL-WARNING (adevărat pentru SQLCODE > 0 și SQLCODE <>100) sau SQLERROR (adevărat pentru SQLCODE < 0) și acțiunea poate să fie CONTINUE sau o instrucțiune GO TO.
Modificările devin efective numai după executarea unei comenzi COMMIT ce est efăcută automat (la execuție corectă) sau prin program și pot fi anulate prin comanda ROLLBACK automat (la apariția unor erori) sau prin program.
Se pot executa interactiv programe SQL folosind comenzile PREPARE pentru precompilare și EXECUTE pentru execuție.
3.4 Securitatea în SQL
Problema securității în SQL se rezolvă prin mecanismul vederilor, prin care diferiții utilizatori au acces numai la anumite informații, restul informațiilor rămânând invizibile pentru ei, și prin sistemul de autorizări, care permite utilizatorilor ceau anumite drepturi să poată să transmită sau să anuleze aceste drepturi și pentru alți utilizatori . Sstemul prevede structuri ce memorează constrângerile de autorizare comunicate de utilizatori, face verificările lor la efectuarea fiecărei cereri și are un modul de verificare și identificare a utilizatorilor.
La definirea vederilor prin CREATE VIEW, se poate lilmita accesul numai la tabelele al căror proprietar este utilizatorul respectiv, folosind o condiție de selecție cu cuvântul cheie USER, prin care se dă identificatorul utilizatorului, de tipu următor:
WHERE CREATOR = USER
Orice operație din baza de date se face numai pe baza unei autorizări pentru acea operație. Inițial, sistemul acordă toate drepturile de operare pentru administratorul sistemului (SYSADM) și nu acordă nici un drept de operare celorlalți utilizatori. Apoi drepturile de operare sunt transmise prin intermediul instrucțiunii GRANT sau sunt revocate prin instrucțiunea REVOKE.
Instrucțiunea GRANT este de forma următoare:
GRANT operații [ (atribute) ] ON TABLE tabele
TO utilizatori [WITH GRANT OPTION];
unde operații este o submulțime a mulțimii {SELECT, UPDATE, DELETE, INSERT, ALTER, INDEX} (ultimele două se aplică numai la tabele de bază, permițând adăugarea unei noi coloane și, respectiv, construirea unui index pentru tabelul respectiv) indicând operațiile autorizate (dacă sunt permise toate, se pune ALL), atribute este o listă a atributelor cărora li se aplică operațiile respective, tabele dă lista tabelelor de bază și vederilor implicate în operații, utilizatori dă lista identificatorilor celor ce au drepturile respective (cuvântu cheie PUBLIC se folosește pentru a indica toți utilizatorii sistemului), WITH GRANT OPTION permite transmiterea în cascadă a acordării unor drepturi și a revocării lor.
Instrucțiunea REVOKE este de forma următoare:
REVOKE oprații ON TABLE tabele FROM utilizatori;
cu operații, tabele și uilizatori ca mai sus, doar că de această dată se referă la revocarea unor operații.
Revocarea unor autoruzări se poate face de către persoana care a dat autorizarea respectivă și presupune invalidarea tuturor aplicațiilor care utilizează operațiile revocate.
3.5 Bazele comenzii SELECT
Cea mai populară comandă SQL este comanda SELECT. Ea este folosită pentru selectarea unui anumit număr de inregistrări din baza de date, pentru vizualizare sau în vederea prelucrării ulterioare.
Dar să vedem cum funcționează această comandă. Într-o bază de date relațională, informațiile sunt stocate în tabele. De exemplu, o tabelă ar putea conține seria buletinului, numele, adresa și telefonul angajaților unei firme:
Tab. 1
Acum, să presupunem că vrem să vedem adresa fiecărui angajat. Vom folosi comanda SELECT în felul următor:
SELECT Prenumele, Numele, Adresa, Oras, Telefon
FROM AdreseAngajați;
Rezultatul interogării este următorul:
Tab. 2
Iată ce am făcut: am cerut să fie afișate toate înregisrările din tabela AdreseAngajați, mai exact am cerut cooanele numite Prenume, Nume, Adresa, Oraș, și Telefon. De remarcat faptul că numele de tabele și de coloane nu conțin spații, ele trebuind să fie scrise într-un singur cuvânt, și că întreaga declarație se încheie cu punct-virgulă (;). Forma generală a comenzii SELECT, care alege toate rândurile (înregistrările) dintr-o tabelă, este:
SELECT Coloana1, Coloana2, …
FROM Tabel1;
Pentru a obține toate coloanele fără să mai fie nevoie să scriem numele fiecăruia dintre ele putem folosi:
SELECT *
FROM Table1;
Înainte de a ula orice comandă SQL, trebuie să ne conectăm la baza de date. Fiecare sistem de gestiune a bazelor de date și fiecare Software pentru baze de date are propria sa metodă de conectare la bazele de date și de rulare a comenzilor SQL. Înainte de a începe utilizarea propriu-zisă a limbajului SQL, trebuie să aflăm care este această metodă.
3.6 Selectarea condiționată
Pentru a studia în continuare comanda SELECT, să luăm un nou exemplu:
Tab. 3
De asemenea, trebuie să vedem care sunt operatorii logici care pot fi folosiți în SQL. Ei sunt în număr de șase, și anume:
Tab. 4
Clausa WHERE este utilizată pentru a indica faptul că doar anumite rânduri din tabel vor fi afișate, în funcție de criteriile descrise cu ajutorul acestei clause. Vom înțelegi mai ușor dacă vom urmări câteva exemple.
Dacă dorim să vedem identificătorii celor cu salarii mai mari de 5000000, vom folosi comanda:
SELECT IDANGAJAT
FROM STATISTIANGAJATI
WHERE SALARIU >=5000000;
ceea ce urmează după WHERE, și anume SALARIU >=5000000, se numește criteriu sau condiție. Aici ea a fost aplicată unei vallori numerice, dar se poate folosi, în același mod, și pentru coloane de text:
SELECT IDANGAJAT
FROM STATISTICANGAJATE
WHERE FUNCȚIE=”Manager”;
Această comandă afișează identificatorii tuturor managerilor. În general, atunci când este vorba de coloane de text, e bine să limităm la operatorii egal (=) și diferit (!=). De asemenea orice text care face parte din declarație este delimitat de apostrofuri (’).
3.7 Condiții compuse
Operatorul AND combină două sau mai multe condiții, și afișează o înregistrare doar dacă datele sale satisfac toate condițiile enumerate. De exemplu, pentru a afișa toți angajații care câștigă peste 4000000, utilizăm:
SELECT IDANGAJAT
FROM STATISTICIANGAJATI
WHERE SALARIU > 4000000 AND FUNCTIE = „Angajat”;
Operatorul OR combină două sau mai multe condiții, și afșează o înregistrare dacă oricare dintre condiții este adevărată. Pentru a vedea care sunt persoanele cu salariile mai mici de 4000000 sau care au beneficii mai mici decât 1000000, folosim următoarea interogare:
SELECT IDANGAJAT
FROM STATISTICIANGAJATE
WHERE SALARIU < 4000000 OR BENEFICIU < 1000000;
Operatorii AND și OR pot fi combinați, ca în exemplul următor:
SELECT IDANGAJAT
FROM STATISTICIANGAJATI
WHERE FUNCȚIE = „Manager” AND SALARIU > 6000000 OR
BENEFICIU > 12000000;
Întâi, SQL va găsi înregistrările pentru care salariul este mai mare decât 6000000 sau beneficiile sunt mai mari decât 1200000. Apoi, din această nouă serie de înregistrări, SQL le va elege pe celea care îndeplinesc condiția ca în coloana Funcție să exeste valoarea „Manager”. În consecință SQL afișează doar această ultimă serie de înregistrări, întrucât operatorul AND forțează îndeplinirea tuturor condițiilor specificate de clausa WHERE. Remarcăm, de asemenea, că operațiunea OR este efectuată prima.
Pentru a efectua operațiunile AND înaintea celor OR, de exemplu, pentru a vedea lista Managerilor sau a oricărui angajat cu salariu mare ( > 5000000 ) și beneficii consistente ( > 1000000 ), indiferent de poziția sa, trebuie să folosim parantezele:
SELECT IDANGAJAT
FROM STATISTICIANGAJATE
WHERE FUNCTIE = „Manager” OR (SALARIU > 5000000
AND BENEFICIU > 1000000 );
3.8 Reuniuni (JOINS)
În acestă secțiune vom discuta doar despre reuniunile interioare (innerjoins) și despre echireuniuni (equijoins), întrucât ele sunt cele mai frecvent întâlnite. O proiectare inteligentă a unei baze de date presupune că fiecare tabelă conține informații doar despre un singur articol, iar informații mai detaliate se pot regăsi într-o bază de date relațională, prin folosirea unor tabele adeționale, utilizând reuniunile.
Pentru început, să privim următoarele tabele:
Tab. 5
Tab. 6
Tab. 7
3.9 Chei
O cheie primară este o coloană sau un set de coloane care identifică, într-un mod unic, celelalte date dintr-o anumită înregistrare. De exemplu, în tabela Colectionari coloana IDColectionari identifică în mod unic rândul din care face parte. Aceasta înseamnă două lucruri: nu există două rânduri cu același IDColectionari și, dacă doi cumpărători au același nume și prenume, coloana IDColectionar ne garantează că ei nu vor fi confundați, deoarece acest identificator unic este cel care va fi folosit în cadrul bazei de date pentru evedența cumpărătorilor, și nu numele propriu-zise.
O cheie externă este o coloană a unei tabele, care funcționează pe post de cheie primară pentru o altă tabelă, ceea ce înseamnă că datele aparținând unei coloane care este cheie externă trebuie să aibă un corespondent într-o altă tabelă, unde acea coloană este chie primară. În jargonul bazeor de date această corespondență poartă numele de integritate referențială. De exemplu, în tabela obiecte, atât IDCumpărător, cât și IDVanzator sunt chei externe, aceste coloane reprezentând cheia primară a tabelei Colectionari (anume IDColectionar). În consecință, acești identificatori permit referirea la vanzatori și cumparatori fără a fi necesară menționarea numelor complete ale acestora, rezultând astfel o mare economie de spațiu.
3.10 Realizarea unei reuniuni
Scopul acestor chei este acela de a putea lega datele din mai multe tabele, fără să fie necesară repetarea redundantă a acestor date în fiecare tabelă. În aceasta constă puterea bazelor de date relaționale. De exemplu, putem afla numele persoanelor care a cumpărat scaune fără să trebuiească să menționăm numele complet al cumpărătorului în tabela Obiecte. Putem afla numele acestuia făcând legătura cu numele din tabela Colectionari, prin intermediul coloanei IDColaectionar, care stabilește relația dintre cele două tabele. Pentru a afla numele celor care au cumpărat scaune, folosim următoarea interogare:
SELECT NUMECOLECTIONAR, PRENUMECOLECTIONAR
FROM COLECTIONARI, OBIECTE
WHERE IDCUMPARATOR = IDCOLECTIONAR
AND OBIECT = „Scaun”;
Ambele tabele implicate în relație sunt enumerate după clausa FROM. În clausa WHERE, remarcăm mai întâi că prin condiția OBIECT = „Scaun”, se restricționează doar înregistrările acelora care au cumpărat, în acest exemplu scaune. În al doilea rând, remarcăm modul în care coloanele de identificare sunt legate între cele două tabele, prin utilizarea condiției IDCUMPARATOR = IDCOLECTIONAR. Doar dacă acești identificatori corespund în cele două tabele, iar obiectul cumpărat este un scaun, abea atunci vor fi afișate numele din tabela Colectionari. Deoarece condiția de reunire a celor două tabele (IDCUMPARATOR = IDCOLECTIONAR) conține semnul egal, această reuniune se numește echireuniune. Rezultatul acestei interogări conține două nume: Popescu Andrei și Luca Paul.
Uneori, la apelarea unei reuniuni, se folosește notarea cu punct. Ea se referă la precizarea, înaintea numelor de coloane a numelor tabelelor, pentru a se evita ambiguitatea. De exemplu:
SELECT COLECTIONARI.NUMECOCTIONAR,
COLECTIONARI.PRENUMECOLACTIONAR
FROM COLACTIONARI, OBIECTE
WHERE OBIECTE.IDCUMPARATOR = COLECTIONARI.IDCOLECTIOANAR
AND OBIECTE.OBIECT = „Scaun”;
Întrucât aici numele coloanelor din cele două tabele diferă, acest luru nu este necesar. El devine, însă, obligatoriu, atunci când există coloane cu același nume în tabele diferite.
3.11 DISTINCT și eliminarea duplicateor
Să presupunem că dorim să afișăm identificatorii și numele doar pentru acele persoane care au vândut ceva. În mod evident, vom dori o listă în care fiecare vânzător este menționat o singură dată și nu ne interesează câte produse a vândut fiecare, ci doar faptul că respectiva persoană a vândut cel puțin un produs. Aceasta înseamnă că va trebui să indicăm limbajului SQL faptu că trebuie să elimine rândurile dublate și să afișeze fiecare persoană o singură dată. Pentru aceasta, se folosește parametrul DISTINCT. Mai întâi, vom avea nevoie de o echireuniune între tabele Obiecte și Colectionari, pentru a afla numele și prenumele vânzatorilor. Apoi, va trebui să eliminăm aparițiile repetate ale identificatorului IDVanzator, iar pentru aceasta von utiliza DISTINCT pe coloana pe care apar aceste repetiții.
Pentru a mai complica puțin situația, vom dori, de asemenea, să afișăm această listă în ordine alfabetică a numelor. Pentru aceasta vom include și clausa ORDER BY:
SELECT DISTINCT IDVANZATOR, NUMECOLECTIONAR, PRENUMECOLECTIONAR
FROM OBIECTE, COLECTIONARI
WHERE IDVANZATOR = IDCOLECTIONAR
ORDER BY NUME, PRENUME, IDCOLECTIONAR
În acest exemplu, întrucât fiecare persoană a avut cel puțin un produs, vom obține o listă a tuturor vânzărolor, ordonată alfabetic.
Pentru referințe ulterioare, această reuniune face parte din categoria referințelor interioare (InnerJoin).
4. DIVERSE COMENZI SQL
4.1 Funcții agregate
Vom menționa aici cele mai importante cinci funcții agregate din limbajul SQL:
SUM, AVG, MAX, MIN și COUNT. Ele se numesc funcții agregate pentru că analizează rezutatu unei interogări, în loc să afișeze toate rândurie.
SUM() calculează suma tuturor valorilor selectate de interogare, de pe coloana specificată, cu condiția să fie o coloană nzmerică.
AVG() calculează media de pe o coloană.
MAX() calculează valoarea maximă de pe o coloană.
MIN() calculează valoarea minimă de pe o coloană.
COUNT(*) indică numărul îregistrărilor care indeplinesc o anumită condiție.
Luând ca exemple tabelele de la începutul paragrafului, analizăm următoarele trei exemple:
SELECT SUM(SALARIU), AVG(SALARIU)
FROM STATISTICIANGAJATI;
Această interogare afișează totalul salariilor din tabelă, precum și salariul mediu.
SELECT MIN(BENEFICIUL)
FROM STATISTICIANGAJATI
WHERE FUNCTIE = „Manager”;
Această interogare va indica cea mai mică valoare a beneficiilor managerilor, și anume 1250000.
SELECT COUNT(*)
FROM STATISTICIANGAJATI
WHERE FUNCTIE = „Angajat”;
Această interogare afișează număru angajaților firmei.
4.2 Tabele temporare
În SQL putem să creăm, pentru ulurarea lucrului, tabele temporare. O astfel de tabelă presupune că rezultatele unei interogări alcătuiesc o nouă tabelă, care poate fi folosită în operațiunile ulterioare, numele acesteia putând fi specificat în clausa FROM. Atunci când accesăm o tabelă temporară, este executată interogarea care a fost definită la crearea acestei tabele, iar rezultatele acestei interogări funcționează la fel ca orice altă tabelă a bazei de date. De exemplu, creăm o tabelă temporară cu următoarea comandă:
CREATE VIEW OBIECTTEMP AS
SELECT OBIECTSOLICITAT FROM COMENZI;
Apoi, scriem o interogare care folosrște această tabelă temporară ca pe orice altă tabelă, anume o tabelă care conține, conform definiției anterioare, lista obiectelor solicitate din tabela Comenzi.
SELECT IDVANZATOR
FROM OBIECTE, OBIECTTEMP
WHERE OBIECTSOLICITAT = OBIECT;
Această interogare afișează coloanele IDVANZATOR din tabela Obiecte, acolo unde obiectul corespunzător apare și în tabela temporară Antview, care conține prin definiție toate obiectele solocitate din tabela Comenzi. Tabele temporare sunt utilizate pentru a restricționa accesul într-o bază de date sau, în cazul nostru, pentru a simplifica o interogare mai complexă.
4.3 Crearea de noi tabele
Evident, oricare dintre tabelele folosite în exemplele de până acum trebuie să fie create înainte de a efectua operații asupra lor. Iată cum se crează, de eemplu, tabela Comenzi.
CREATE TABLE COMENZI
(IDCOLECTIONAR INTEGER NOT NULL,
OBIECTSOLICITAT CHAR (40) NOT NULL);
Această declarație stabilește denumirea tabelei și indică DBMS-ului caracteristicile fiecărei coloane din tabelă. De remarcat că acest exemplu utilizează tupluri de date generice, iar aceste tupluri de date pot varia, în funcție de DBMS-ul utillizat. Câteva tipuri de date generice sunt:
Char(x) – O coloană de caractere (șir de caractere), unde x este un număr reprezintând numărul maxim permis de caractere (lungimea maximă a șirului).
Integer – O coloană de numere întregi, pozitive sau negative.
Decimal(x,y) – O coloană de valori zecimale, unde x este numărul total de cifre al numerilor de pe o coloană, iar y este număru maxim de cifre existente după virgulă. De exemplu, numărul maxim definit ca (4,2) este 99.99.
Date – O coloană de date calendaristice, în formatul specific fiecărui DBMS.
Logical – O coloană cafre poate conține doar două valori: TRUE sau FALSE.
O ultimă observație: NOT NULL înseamnă că respectiva coloană trebuie să conțină o valoare pe fiecare rând. Dacă se folosește NULL, înseamnă că acea coloană poate avea și rânduri goale.
4.4 Modificarea structurii tabelelor
Iată cum se poate adăuga o coloană în tabela Obiecte, pentru a permite întroducerea prețului pentru un anumit obiect:
ALTER TABLE OBIECTE ADD (PRET DECIMAL(8,2) NULL);
4.5 Adăugarea datelor
Pentru a insera un rând într-o tabelă, procedăm în felulș următor.
INSERT INTO OBIECTE VALUES (21,01, „Carpeta”, 200.00);
Această comandă inserează date într-o tabelă, sub forma unui nou rând coloană cu cooană, în ordinea predefinitîă la crearea tabelei. Putem, de asemenea, să omitem întroducerea unei anumite coloane. De exemplu, să întroducem un rând pe care coloana prețului să rămînă goală:
INSERT INTO OBIECTE (IDCUMPARATOR, IDVANZATOR, OBIECT)
VALUES (01,21,”Carpeta”);
4.6 Ștergerea datelor
Iată cum se poate șterge această ultimă înreegistrare introdusă în baza de date:
DELETE FROM OBIECTE
WHERE OBIECT = „Carpeta”;
În acest exemplu, dacă mai exeistă și alt rând care se conțină obiectul „Carpeta”, acest rând va șters la rândul lui. Comanda DELETE șterge toate înregistrările care îndeplinesc condițiile specificate de clausa WHERE.
4.7 Modificarea dtelor
Acum să încercăm să modificăm prețul unui obiect, de exemplu al scaunelor vândute de un anumit colecționar:
UPDATE OBIECTE SET PRET = 500.00
WHERE OBIECT = „Scaun” AND IDVANZATOR =15;
Această comandă ajustează prețul tuturor scaunelor la 500.00. după cum se vede, se pot folosi mai multe condiții, folosin operatorii logici cunoscuți (este valabil și pentru comanda DELETE). De asemenea, pot fi modificate mai multe coloane odată, despărțind toate atribuirile de după SET prin virgule.
4.8 Indecși
Indecșii permit DBMS-urilor să acceseze mai repede informațiile. Sistemul de gestionare al bazei de date va crea o structură internă de date (numită index), care va avea ca efect o selecție mai rapidă a înregistrărilor, atunci când această selecție se bazează pe o coloană indexată. Indexul indică sistemului unde se află un anumit rând în cadrul tabelei, atunci când se cunoaște o valoare dintr-o coloană indexată (la fel cum indexul unei cărți indică la ce pagină se găsește un anumit cuvânt). Să creăm acum un index pentru IDCOLECTIONAR din tabela Colectionari:
CREATE INDEX OID_IDX ON COLECTIONARI
(IDCOLECTIONAR);
Acum, să creăm un index și pentru numele persoanelor:
CREATE INDEX NAME_IDX ON COLECTIONARI
(NUMECOLECTIONAR, PRENUMECOLECTIONAR);
pentru a șterge un index, se folosește comanda DROP:
DROP INDEX OID_IDX;
Apropo, comanda Drop se poate folosi și pentru a șterge o tabelă (aceasta implică pierderea tuturor datelor din tabela respectivă).
În al doilea exemplu de creare a indicșilor indixarea se face după două coloane. Uneori, această operație poate avea, rezultate neplăcute.
Unele DBMS-uri nu forțează crearea unei chei primare; cu alte cuvinte, unicitatea unei anumite coloane nu este automat obligatorie. În consecință, de exemplu, dacă încercăm să introducem în tabela Colectionari un nou rând cu valoarea 02 pe coloana IDCOLECTIONAR, s-ar putea ca unele sisteme să ne permită acest lucru, deși nu ar trebui, dat fiind faptul că respectiva coloană este unică în tabel (valorie de pe rând trebuie să fie diferite). O soluție pentru a evita acest lucru este să creăm un index pentru acea coloană (sau oricare coloană dorim să fie cheie primară), pentru a forța sistemul să interzică duplicarea valorilor de pe acea coloană:
CREATE UNIQUE INDEX OID_IDX ON COLECTIONARI
(IDCO;LECTIONAR);
4.9 GROUP BY și HAVING
Rolul clausei GROUP BY este să asocieze o funcție agregată (în special COUNT, atunci când vrem să numărăm rândurile din fiecare grup) cu un grup de rânduri. Întâi, se presupunem că tabela Obiecte are coloana de prețuri, și că fiecare rând conține o valoare pe acea coloană. Dacă dorim să vedem cel mai scump obiect cumpărat de fiecare colecționar, va trebui să indicăm limbajului SQL că trebuie să grupeze achizițiile fiecărui cumpărător, și să ne afișeze prețul maxim pentru fiecare dintre aceștea:
SELECT IDCUMPARATOR, MAX(PRET)
FROM OBIECTE
GROUP BY IDCUMPARATOR;
Dacă, în plus, dorim să vedem acest preț maxim doar în cazurile în care tranzacția este de peste $1000, va trebui să introducem și clausa HAVING, pentru a stabili condiția de selecție a fiecărui grup:
SELECT IDCUMPARATOR, MAX(PRET)
FROM OBIECTE
GROUP BY IDCUMPARATOR
HAVING PRET >1000;
4.10 Subinterogări
O funcție utilă a subinterogărilor se referă la utilizarea operatorilor logici pentru a permite condiției WHERE să includă rezultatul unei comenzi SELECT. În primul exemplu, vom afișa lista colecționarilor care au cumpărat un obiect scump (adică prețul unui obiect este cu cel puțin $100 mai mare decât valoarea medie a tuturor tranzacțiilor):
SELECT IDCOLECTIONAR
FROM OBIECTE
WHERE PRET >(SELECT AVG(PRET) + 100
FROM OBIECTE);
Subinterogarea calculează prețul mediu plus $100 și, utilizând această valoare, va fi afișat IDCOLECTIONAR pentru fiecare obiect al cărui preț depășește valoarea calculată anterior. Este de preferat chiar să folosim DISTINCT IDCOLECTIONAR, pentru a elimina duplicatele.
Acum, să afișăm numele furnizorilor doar dacă ei au cumpărat un obiect:
SELECT NUMECOLECTIONAR
FROM COLECTIONARI
WHERE IDCOLECTIONAR =
(SELECT DISTINCT IDCUMPARATOR
FROM OBIECTE);
Subinterogarea returnează o listă a cumpărătorilor, iar un nume din Colectionari este afișat doar dacă identificatorul său apare în llista genetrată de subinterogare (numită uneori și listă de candidați).
Ca să dăm și un exemplu de modificare a datelor, să presupunem că persoana care a cumpărat biblioteca are prenumele scris greșit în baza de date și vrem să îl modificăm.
Vom executa comanda:
UPDATE COLECTIONARI
SET PREUMECOLECTIONAR = „John”
WHERE IDCOLECTIONAR =
(SELECT IDCUMPARATOR
FROM OBIECTE
WHERE OBIECT = „Biblioteca”);
Întâi, subinterogarea va găsi identificatorul IDCUMPARATOR al persoanei care a cumpărat biblioteca, iar apoi interogarea principală va modifica prenumele său.
4.11 EXISTS și ALL
EXISTS folosește sbinterogarea ca pe o condiție, iar această condiție este adevărată dacă rezultatul comenzii SELECT conține cel puțin o înregistrare, și este falsă dacă rezultastu este nul (nu conține nici un rând). De exemplu, dacă dorinm să aflăm lista tuturor colecționarilor, doar în cazu în care s-au efectuat tranzacții cu scaune, folosim comanda:
SELECT PRENUMECOLECTIONAR, NUMECOLECTIONAR
FROM COLECTIONARI
WHERE EXISTS
(SELECT *
FROM OBIECTE
WHERE OBIECT = „Scaun”);
Dacă există un scaun în coloana Obiecte, subinterogarea va returna unul sau mai multe rânduri, astfel clausa EXISTS devenind adevărată, iar limbajul SQL va afișa lista colecționarilor. Dacă nu s-a tranzacționat nici un scaun, interogarea principală nu va returna nici ea nici un rând.
EXISTS nu este utilizat prea frecvent, la fel cum nu este nici ALL, întrucât toate interogările cu ALL pot fi efectuate și în alte modalități (uneori chiar mai simple). Dar să vedem, totuși, un exemplu:
SELECT IDCUMPARATOR, OBIECT
FROM OBIECTE
WHERE PRET >= ALL
(SELECT PRET
FROM OBIECTE);
Rezultatu afișat va fi produsul cel mai scump (sau produsele, dacă există produse cu același preț) și cumpărătorul său. Subinterogarea returnează lista prețurilor din tabela Obiecte, iar interogarea principală va parcurge fiecare obiect din tabela Obiecte și, dacă prețul său este mai mare sau egal decât toate prețurile din listă, îl va afișa, indicându-ne astfel produsul cel mai scump. Motivul pentru care trebuie folosit operatorul „>=” este că cel mai scump produs din listă este egal cu el însuși.
4.12 Uniuni (UNION) și reuniuni exterioare
Se întâmplă uneori să dorim să vedem rezultatele mai multor interogări laolaltă, combinându-le rezultatul, iar pentru asta trebuie să folosim UNION. De exemplu, pentru a combina rezultatele a două interogări care afișează, pe de-o parte, identificatorii tuturor cumpărătorilor și pe de altă parte pe toți cei care au plasat o comandă, procedăm în felul următor:
SELECT IDCUMPARATOR
FROM COLECTIONARI
UNION
SELECT IDCOLECTIONAR
FROM COMENZI;
De remarcat că limbajul SQL impune ca listele (coloanele) solicitate de comanda SELECT să corespundă din punct de vedere al tipului de date. În cazul de față, IDCUMPARATOR și IDCOLECTIONAR sunt de același tip (întregi). De asemenea, când execută o uniune, SQL va elimina în mod automat duplicatele, dacă se invocă clausa DISTINCT.
Reuniunea exterioară este folosită atunci când o interogare este combinată cu niște rânduri care nu sunt incluse în rezultatul acesteia, și este utilă mai ales atunci când sunt adăugate comentarii de tip text. Să ne uităm întâi la interogarea:
SELECT IDCOLECTIONAR, „apare în Comenzi și Obiecte”
FROM COMENZI, OBIECTE
UNION
SELECT IDCUMPARATOR, „apare doar în Obiecte”
FROM OBIECTE
WHERE IDCUMPARATOR NOT IN
(SELECT IDCOLECTIONAR
FROM COMENZI);
Prima reuniune listează pe acei coecționari care apar în ambele tabele, adaugând și un text explicativ pe fiecare rând. UNION combină această listă cu următoarea. A doua listă este generată întâi prin selectarea celor care nu se află în tabela Comenzi, astfel obținundu-se lista celor care au fost excluși din prima reuniune. Apoi, este scanat fiecare rând din tabela Obiecte și, dacă identificatorul cumpărătorului nu se află pe lista de excluziune, va fi afișat îm,preună cu un tet explicativ. Ar putea exista și moduri mai simple de a produce acest rezultat, dar sunt mai deficil de generat scurtele notițe explicative.
Acest concept este uti în situațiile în care o cheie primară este legată de o cheie externă, dar valoarea acestei chei, pentru unele chei primare corespunzătoare, este nulă. De exemplu, într-o tabelă, cheia primară este un agent de vânzări, iar în altă tabelă cheia primară este clientul, cu agentul de vânzări menționat pe același rând (și fiind, deci, cheie externă). Totuși, dacă un agent de vânzări nu are nici un client, numele acestuia nu va apărea în tabela cumpărătorilor. Reuniunea exterioară este necesară aici pentru a afișa toți agenții de vânzări, împreună cu cumpărătorii lor, atunci când agentul are un cumpărător; în plus vrem să apară și numele celorlalți agenți, chiar dacă nu au cumpărărtori, dar numele lorapare în tabela agenților de vânzări.
5. INTRODUCERE ÎN TEHNOLOGIA CLIENT-SERVER
5.1 Baze de date client-server
Arhitectura file-server nu este eficientă din două considerente:
La executarea cererii către baza de date, stocată pe mașina file-server, dar întradevăr cererea se execută la copia de date locală pe mașina clientului. De aceea înainte de executarea cererii datele din copia locală în întregime se înnoiesc din baza de date reală. Astfel, dacă tabelul bazei de date constă din 10000 de înregistrări, dar pentru executarea cererii trebuie numai 10 înregistrări, totuși clientului i se transmit toate 10000 de înregistrări. În așa fel, nu trebuie să fie prea mulți utilizatori și cereri de la ei, ca să nu fie supraîncărcată rețeaua, care influințează la funcționarea rețelei.
Integritatea bazei de date se asigură de programele client. Asta este sursa de erori, încălcând integritatea fizică și logică a datelor, întrucît diferiți clienți pot să efectueze controlul integrității datelor diferit, sau în general să nu-l efectueze. Cu mult e mai efectiv să derijezi baza de date de pe un loc unic și cu legi unice. De aceea securitatea la lucrul cu arhitectura file-server nu este înaltă și totdeauna este prezent elementulnedeterminării. În astfel de arhitectură este greu de asigurat securitatea datelor și protecția lor: tebelele se păstrează pe server în formă de fișiere simple, de aceia, oricine, care are acces la dosarele serverului de rețea, unde se păstrează baza de date, poate să modifice tabelele, să le copie, să le schimbe s.a..
În arhitectura client-server între BDE și baza de date apare un modul nou – serverul bazei de date.
Clientul formează cererea către server în limbajul cererilor SQL (Structured Query Language – limbajul structurat de cereri), care prezintă standartul pentru bazele de date relaționale. Serverul-SQL asigură intrpretarea cererii, executarea ei, formarea rezultatului și transmiterea lui către client. Astfel resursele calculatorului clientului nu participă la executarea cererii: calculatorul client numai transmite cererea către serverul bazei de date și primește rezultatul, după care îl interpretează în forma necesară și îl prezintă utilizatorului. Așa cum aplicației client i se transmite rezultatul îndeplinirii cererii, pe rețea se transmite numai acele date, care întradevăr sînt necesare clientului. Ca rezultat se micșorează supraîncărcarea rețelei. În afară de aceasta, SQL – server, optimizează cererea primită în așa fel ca el să executat într-un timp minim, dacă aceasta este posibil. Toate acestea măresc rapiditatea funcționării sistemului și micșorează timpul de așteptare a rezultatului cererii
5.2 Arhitectura Client-Server
Lucrul efectiv într-un oficiu modern nu este posibil fără folosirea de către colaboratori a bazei de date comune. Baza de date comună se obține la instalarea ei în rețeaua locală a întreprinderii pe o stație specială (numită server) și accesul concomitent la ea a clienților întreprinderii.
SGBD-urile construite cu arhitectura client-server se caracterizează prin transferul proceselor de calcul la serverul bazei de date (serverul – SQL) și eliberarea maximă a clientului de procesele de calcul, și de asemenea mărirea securității datelor – atât de răufăcători, cât și de erori. Ca și la arhitectura file-server, baza de date în acest caz se plasează pe stația server în rețea, dar aplicația client este lipsită de posibilitatea accesului direct la baza de date. Accesul la baza de date se dirijează de către un program special – numit serverul bazei de date (serverul – SQL). Interacționarea severului bazei de date cu aplicația client se realizează cu ajutorul cererilor-SQL , care sunt formate și transmise de către client la server. Serverul, prmind cererea, o execută și întoarce rezultatul clientului. În aplicația client în general se efectuază inerpretarea datelor primite de la server, realizarea interfeței utilizator, și realizarea unor reguli-bussines.
Pentru realizarea arhitecturei client-server se folosesc așa numitele servere industriale cum ar fi InterBase, Oracle, Informix, Sybase SQL Server, DB2, MS SQL Server.
5.3 InterBase SQL Server și componentele lui principale
InterBase SQL Server este destinat pentru păstrarea și prelucrarea informațiilor voluminoase în condiții de lucru cu baza de date concometent a mai mlutor aplicații client. Mărimea sistemului informațional este divers de la un sistemul de nivelul unui grup de utilizatori până la nivelul unei intreprinderi mari.
Pentru redarea integrității bazei de date definim:
relațiile de supunere între tabelele bazei de date pe calea definirii cheii primare (PRIMARY) la tabelele părinte și cheile secundare (FOREIGN) la tabelele copil;
limitările valorilor atributelor (CONSTRAINT); condițiile limitărilor pot fi diferite de la cererea satisfacerii valorilor întroduse pe un diapazon definit sau corespunderea unor relații necesare cu una sau mai multe înregistrări din altă tabelă (sau a mai multor tabele) a bazei de date;
trighere (TRIGGER) sunt niște subprograme, executate automat de către server până și (sau) după evenimentul modificării înregistrării în tabelele bazei de date;
generatoare (GENERATOR) sunt destinate pentru crearea și folosirea valorilor unice a câmpurilor.
Pentru mărirea vitezei de lucru a aplicației client cu baza de date pot fi definite proceduri stocate (STORED PROCEDURE) care reprezintă subprograme ce primesc și întorc parametri și capabile să execute cereri către baza de date. Proceduile stocate se scriu într-un limbaj algoritmic special. În ele se programează cererile consecutive des repetabile către baza de date. Textul procedurii se păstrează pe server în formă compilată.
Avantajele folosirii procedurilor stocate sunt următoarele:
decade necesitatea controlului sintactic a fiecărei cereri și compilarea ei până la executare, ce mărește viteza de executare a cererei;
decade necesitatea realizării ceririlor în aplicația client, care se definesc în corpul procedurii stocate;
se mărește viteza de prelucrarea tranzacțiilor, astfel încât în locul transmiterii unei cereri SQL lungi pe rețea se transmite un apel relativ scurt către procedura stocate.
6. DESCRIEREA BAZEI DE DATE CLIENT-SERVER ȘI A TEHNOLOGIEI DE TRANSFER A DATELOR ÎNTR-O REȚEA LOCALĂ.
6.1 Necesitățile de creare a unei Baze de Date Client-Server la o întreprindere.
În ultimul timp tot mai multe întreprinderi se orientează spre computerizare ca un nou mediu de prezentare, stocare și recepționare a informației. Spre deosebire de întreprinderile obișnuite, întreprinderile computerizate se evidențiază prin următoarele caracteristici:
Automatizarea fluxului de informații în cadrul întreprinderii.
Reducerea timpului de efectuare a anumitor lucrări de evidență, informare, prelucrare și căutare a informației.
Micșorarea cheltuielelor pentru salariile angajaților care efectuau aceste lucrări.
Astfel de întreprinderi, nu pot să lucreze efectiv fără o rețea de calculatoare și soft-uri pentru automatizarea lucrărilor în cadrul întreprinderii din motive organizatorice (lipsa numărului de cadre instruite pe loc, mobilitatea necesară a personalului) sau din motive de natură a operațiunilor efectuate pentru obținerea venitului. În acest caz e absolut necesară utilizarea unor aplicații de transfer a datelor în cadrul unei întreprinderii.
6.2 Cerințele Bazei de Date Client-Server proiectate în cadrul întreprinderii.
Pentru a face față fluxului crescând de informație, o întreprindere trebuie să folosească la maxim posibilităție de transfer a datelor prin intermediul rețelei locale de calculatoare existentă.
O scurtă analiză a necesităților și posibilităților unei întreprinderi cu privire la utilizarea unei baze de date Client-Server într-o rețea locală de calculatoare:
Necesitatea de organizare a fluxului informațional de intrare intr-o întreprindere;
Necesitatea de stocare a datelor referitoare la clienții întreprinderii;
Necesitatea de organizare a fluxului informațional dintre departamente;
Necesitatea de coordonare a fluxului informațional personal în cadrul întreprinderii;
Necesitatea de organizare a fluxului informațional pentru lucrătorii întreprinderii.
Din aceste necesități ale întreprinderii, se deduc principalele cerințe către baza de date Client-Server a întreprinderii.
Tab. 8
Cerințele către baza de date Client-Server a Centrului de Instruire a Personalului pentru Transporturi Inernaționale.
7. DESCRIEREA BAZEI DE DATE CLIENT-SERVER A CENTRULUI DE INSTRUIRE A PERSONALULUI PENTRU TRANSPORTURI INTERNAȚIONALE
7.1 Scurtă prezentare a proiectului
Proiectul elaborat reprezintă o bază de date Client-Server, care duce evidența personalului la Centrul de Instruire a Personaului pentru Transporturi Internaționale. Și constă dintr-o aplicație Client și o colecție de date, care se amplasează pe o stație din rețea. Ca server al bazei de date se folește serverul InterBase SQL Server. Baza de date, reprezintă un fișier mare, în care se conțin toate datele, procedurile, indecșii, generatoarele, trigherile referitoare la baza de date. Aplicația Client folosește tehnologia InterBase Express pentru transferul de date de la Server la Client și invers. Această tehnologie, este cea mai rapidă tehnolodie de transfer a datelor într-o rețea locală de calculatoare, deoarece nu folosește administratorul bazei de date (BDE Administrator), dar face direct legătura cu serverul.
Tehnologia InterBase Express (IBX) permite crearea unei aplicații client simplificată și minimizarea transferului de date prin rețea deoarece putem folosi proceduri stocate în fișierul bazei de date, trighere, indecși, tranzacții, ș.a. care efectuază operații cu datele pe stația server și prin rețea se transmit numai datele cerute de utilizator. Acesta ne permite să folosim ca stații client calculatoare mai puțin performante deoarece toate operațiile de calcul se efectuază pe stația server. Tehnologia IBX nu folosește BDE Administrator și este cea mai rapidă tehnologie de transfer a datelor într-o rețea locală de calculatoare. Ea nu necesită schimbarea frecventă a versiunilor aplicației client deoarece modificând serverul, nu duce la modificarea aplicației client.
7.2 Funcționarea Aplicației Client
Aplicația Client rulează pe orice stație din rețea și accesează baza de date de pe stația server folosind tehnologia IBX. Pentru efectuarea legăturii cu baza de date se folosește numele de identificare a stației pe care este plasat serverul și parola utilizatorului. La modificarea unor date de către utilizator, către server se transmit numai datele modificate dar nu și textul procedurilor de modificare deoarece ele sunt stocate și executate de către serverul InterBase.
7.3 Funcțiile aplicației
Aplicația are următoarele funcții:
Întroducerea clienților întreprinderii în baza de date.
Întroducerea întreprinderilor în baza de date.
Întroducerea județelor și oraselor în baza de date.
Întroducerea cursurilor planificate pe viitor în baza de date.
Căutarea clienților în baza de date.
Căutarea întreprinderilor în baza de date.
Căutarea județelor și oraselor în baza de date.
Căutarea cursurilor în baza de date.
Modificarea clienților în baza de date.
Modificarea întreprinderilor în baza de date.
Modificarea județelor și oraselor în baza de date.
Modificarea cursurilor în baza de date.
Ștergerea clienților în baza de date.
Ștergerea întreprinderilor în baza de date.
Ștergerea județelor și oraselor în baza de date.
Ștergerea cursurilor în baza de date.
Crearea rapoartelor referitoare la clienți.
Tipărirea rapoartelor.
7.4 Cum lucrează programul
Utilizatorul de la orice stație din rețea rulează aplicația client. Aplicația client face legătură cu baza de date și cere utilizatorului să întroducă numele și parola. Forma de întroducere a parolei este prezentată mai jos:
Fig. 1 Forma pentru întroducerea numelui și parolei utilizatorului.
7.5 Descrierea meniurilor și ferestrelor
Fereastra principală a aplicației client care apare după întroducerea numelui utilizatorului și a parolei este următoarea:
Fig. 2 Forma și meniul principal al aplicației.
După cum vedem meniul de bază cunține următoarle opțiuni:
Adăugare; Modificare; Ștergere; Tipar; Help
La listarea „Adăugare” vom obține următoarele comenzi:
Ancheta
Intreprinderi de transport
Grupa de studiu
Județe
Orașe
Exit
La alegerea opțiunei „Ancheta” vom obține fereastra unde se întroduc datele despre fiecare client:
Fig. 3 Forma de întroducere a anchetelor.
La alegerea opțiunei „Întreprinderi de transport” va apărea următoarea fereastră unde se întroduc datele despre fiecare întreprindere de transport:
Fig. 4 Forma de întroducere a întreprinderelor.
La alegerea opțiunei „Grupa de Studiu” va apărea următoare fereastră unde se întroduce datele despre următoarea grupă de studiu care va avea loc:
Fig. 5 Forma de întroducere a grupelor de studiu.
La alegerea opțiunei „Județe” va apărea fereastra în care se va întroduce județele.
La alegerea opțiunei „Orașe” va apărea fereastra în care se va întroduce orașele.
La listarea „Modificare” vom obține următoarele comenzi:
Anchete
Grupe
Județe
Orașe
Întreprinderi
La alegerea opțiunei „Anchete” va apărea următoarea fereastră unde se va face modificări asupra datelor despre fiecare client:
Fig. 6 Forma de căutare și modificare a datelor despre anchete.
La alegerea opțiunei „Grupe” va apărea o fereastră unde se va face modificări asupra datelor despre fiecare grupă:
Fig. 7 Forma de modificare a datelor despre grupele de studiu.
La alegerea opțiunei „Intreprinderi” va apărea următoare fereastră unde se va face modificări asupra datelor despre fiecare întreprindere:
Fig. 8 Forma de modificare a datelor despre întreprinderi.
La alegerea opțiunei „Județe” va apărea fereastra unde se va face modificări asupra datelor despre fiecare județ:
La alegerea opțiunei „Orașe” va apărea fereastra unde se va face modificări asupra datelor despre fiecare oraș:
La listarea „Ștergere” vom obține următoarele comenzi:
Anchete
Grupe
Județe
Orașe
Întreprinderi
La listarea „Tipărire” vom obține comanda: Legitimații.
În rezultat va apărea fereastra:
Fig. 9 Forma de scoatere la tipar a legitimațiilor.
8. PARTEA ECONOMICĂ A PROIECTULUI
8.1 Planificarea rețea pentru elaborarea “Bazei de Date Client-Server a Centrului de Instruire a Personalului pentru Transporturi Inernaționale”
Proiectele tehnologice contemporane sunt caracterizate de următoarele particularități:
tehnica nouă utilizată este foarte complexă și este construită utilizând ultimele elaborări științifice.
accelerării vitezei de elaborare a proiectelor.
proiectele referitoare la complexele tehnicii de calcul și softului sunt supuse uzurii morale foarte rapide.
necesitatea proiectării de sistemă la elaborarea softului și sistemelor tehnice.
Toate acestea au dus la necesitatea de creare a noi metode de planificare. Una din aceste metode prezintă modelarea procesului de elaborare, adică prezentarea legăturilor și caracteristicilor lucrărilor în procesul elaborării proiectului.
Metodele tradiționale de planificare presupun utilizarea celor mai simple modele de construirea a diagramelor de tip consecutive și ciclice.
Dar în asemenea diagrame nu este posibil de a prezenta legăturile dintre niște lucrări, de unde rezultă imposibilitatea de a afla cât de importantă este lucrarea dată pentru executarea scopului final. Pot apărea diferite întârzieri în timp, ce apar pe porțiuni de interconectare a lucrărilor, care sunt complicat de prezentat în diagrame. De obicei, în procesul dirijării se culege informația despre lucrările efectuate și aproape nu se culege și nu se prezintă informația referitor la prognoza finisării lucrărilor viitoare, de aceia este imposibil de a prognoza rezultatele diferitor variante de soluționare la modificările planului inițial de lucru. Este de asemenea complicat de a reflecta și dinamica lucrărilor, de a corecta toată diagrama în legătură cu schimbarea termenilor de efectuare a unei lucrări, ce este necesar de a efectua ca să nu schimbăm termenul de efectuare a întregului complex de lucrări.
Aceasta este doar o parte mică din neajunsurile metodelor utilizate în prezent pentru planificarea și prezentarea grafică a planurilor de pregătire a producerii. Aceste neajunsuri în mare pare sunt excluse de către sistemele de planificare și dirijare în rețea utilizate în prezent.
Sistemele de planificare și gestiune în rețea prezintă un complex de metode grafice și de calcul, metode de control și de organizare, care asigură modelarea, analiza și reconstruirea dinamică a planului de executare a proiectelor complexe.
Sistemele de planificare și gestiune în rețea este o metodă cibernetică creată pentru gestiunea cu sisteme dinamice complexe cu scopul asigurării condiției de optim pentru careva indicatori. Așa indicatori, în dependență de condițiile concrete, pot fi:
timpul minim pentru elaborarea întregului complex de lucrări;
costul minim al elaborării proiectului;
economia maximală a resurselor.
Particularitățile sistemului de planificare și gestiune în rețea în general sunt următoarele:
se realizează metoda proiectării de sistem la rezolvarea problemelor de organizare a gestiunii proceselor;
se utilizează modelul informațional-dinamic special (graful-rețea) pentru descrierea matematico-logică a procesului și calculul automat (conform algoritmului) a parametrilor acestui proces (durata, costul, forțele de muncă, etc.);
se utilizează sisteme de calcul pentru prelucrarea datelor operative pentru calculul indicatorilor și primirea rapoartelor analitice și statistice necesare.
Documentul de bază în sistemul de planificare și gestiune în rețea este graful-rețea (modelul rețea), care prezintă modelul informațional-dinamic, în care sunt prezentate legăturile și rezultatele tuturor lucrărilor, necesare pentru atingerea scopului final.
Tab. 9
Graful-rețea
(continuarea) Tab. 9
(continuarea) Tab. 9
(continuarea) Tab. 9
(continuarea) Tab. 9
(continuarea) Tab. 9
Tab. 10
Calculele parametrilor grafului-rețea.
(continuare) Tab. 10
Vezi anexa 6.
Tab. 11
Componența grupului de lucru.
8.2 Evaluarea economică a “ Bazei de Date Client-Server a Centrului de Instruire a Personalului pentru Transporturi Inernaționale”
Tab. 12
Executarea lucrărilor de către lucrători.
(continuare) Tab. 12
Pentru salariu remunerat de bază sau cheltuit
Sb = 2580,00 + 2490,00 + 1770,00 = 4640,00 lei.
Salariu auxiliar (25%)
Sa = 4640,00 0,25 = 1160,00 lei.
Defalcări în Fondul Social (31%)
Cfs = (4640,00 + 1160,00) 0,31 = 1798,00 lei.
Cheltuielile totale pentru achitarea salariului
Ct = 5800,00+ 1798,00 = 7598,00 lei
Tab. 13
Evenimentele care necesită timp de lucru cu calculatorul.
(continuare) Tab. 13
(continuare) Tab. 13
Să calculăm cheltuielile de energie electrică. Un calculator personal obișnuit nu are o putere mai mare de 200 W.
200 332 = 66400 W = 66,4W h
La momentul actual un kW h costă 0,67 lei, deci cheltuielile vor fi:
66,4 0,67 = 44,488 lei
Tab. 14
Costul materialelor utilizate
Deoarece procurarea hardului și a softului în domeniul Tehnologiilor Informaționale este considerată ivenstiție de capital, v-om amortiza aceste cheltuieli
[S/(A*365)]*Z
unde: S – suma ce trebuie de amortizat;
A – perioada de amortizare în ani;
Z – perioada proiectului în zile.
[25000/(2*365)]*15 = 513,698 lei
Tab. 15
Cheltuielile pentru procurarea softului necesar.
De asemenea s-a procurat literatură tehnică în valoare de 340,50 lei și rechizite de birou în valoare de 85,5 lei.
Tab 16
Cheltuielile prețului de cost și prețului de livrare al “ Bazei de Date Client-Server a Centrului de Instruire a Personalului pentru Transporturi Inernaționale”
8.3 Determinarea eficacității economice a proiectului
Tab. 17
Estimarea prețului unei copii a programului
(continuare) Tab. 17
Avind date despre cost, eficiența economică poate fi calculată după următoarea formulă:
Eanual=(Pc-Sn)*N-Ken*(Ic+Ipr)
Unde:
Eanual-efectul economic anual;
Pc-prețul unei copii;
Sn-sinecostul unei copii;
N –numărul de copii realizate pe an;
Ken-coeficientul de normare a investițiilor capitale (=0,35);
Ic-investiții capitale;
Ipr-investișii de proiectare;
Vom considera că numărul de copii a programului pa an se va lua 50, iar investițiile capitale sînt estimateca fiind egale cu zero. Astfel obținem:
Eanual=(103998,125-47271,875)*1-0,35*(0+37817,5)= 56726,25 – 13236,125=69962,375
Un alt coeficient important în aprecierea eficacității economice este coeficientul eficienții investițiilor (sau timpul de recuperare a investițiilor):
Trec=(Ic+Ipr)/Eanual=(0+37817,5)/ 69962,3751=0,54
Calculăm coeficientul eficientii economice – Kec
Kec=1/Trec=1/0,54=1,85
Estimarea eficienței economice presupune compararea rezultatelor calculate cu cele normative. Investirea mijloacelor într-un careva proiect se recunosc efective în cazul cînd avem relația:
Kec≥Ken
Comparînd rezultatele obținute cu cele normative obținem:
(Kec=1,85)>(Ken=0,35).
Din aceste comparații vedem că investițiile pentru proiectare și producere sînt economic argumentate.
9. PROTECȚIA MUNCII
Munca prezintă o activitate a omului, care este orientată pentru a satisface cerințele materiale și spirituale ale societății. În procesul de muncă, omul interacționează cu mijloacele de producție, cu mediul de producție și obiectele muncii. Prin urmare, el este supus acțiunilor a unui număr mare de factori de diferită natură, care se manifestă sub diferite forme și acționează în diferit mod, iar ca drept urmare se înrăutățește starea sănătății omului și scade capacitatea de muncă.
Pentru a evita toate aceste urmări ne dorite sunt necesare unele măsuri pentru securitatea muncii. Securitatea muncii – prezintă starea condițiilor de muncă, unde sunt excluși sau reduși la minim acțiunile factorilor dăunători și periculoși. De studierea și analiza condițiilor de muncă se ocupă știința care se numește PROTECȚIA MUNCII și a MEDIULUI AMBIANT.
Protecția muncii – prezintă un set de acte legislative, social-economice, organizatorice, tehnice, igienice și măsuri medico-profilactice, ce asigură securitatea sănătății păstrează capacitatea de muncă a omului în procesul de muncă. De aceea odată cu dezvoltarea PTȘ cresc și cerințele față de PM. Toate tehnologiile noi ne dau un avantaj în producția de mărfuri însă ele nu reduc din problemele PM, deoarece toți factorii periculoși și dăunători își schimbă natura sa mecanismul acțiunii asupra organismului uman. Trebuie de menționat că odată cu dezvoltarea PTȘ a crescut ponderea factorilor psihofiziologici.
După cum s-a menționat mai sus factorii de producție, după caracterul urmărilor care pot avea lor, se împart în două grupe factori periculoși ăi factori dăunători. Factorii se numesc periculoși, dacă în urma acțiunii asupra omului în anumite condiții pot duce la traume saula înrăutățirea bruscă a stării sănătății omului. Factorii care ducla înrăutățirea stării sănătății omului sau la scăderea capacității de muncă sunt numiți factori dăunători. În dependență de nivelul și durata de acțiune factorii dăunători pot deveni periculoși.
După natura acțiunii asupra organismului uman factorii periculoși și dăunători se împart în patru grupe: fizici, chimici, biologici și psihofiziologici.
Către grupa de factori periculoși și dăunători de origine fizică aparțin următorii factori:
factori ce caracterizează utilajul și tehnologia;
factori ce caracterizează mediul de producție.
În acest mod protecția muncii este un sistem de acte legislative, social-economice, tehnice ce îndestulează condițiile favorabile și sănătoase de muncă.
Funcțiile a operatorului și programatorului sunt caracterizate, de obicei, de inexistența sau existența în cantități mici a diferitor substanțe dăunătoare. În același timp sunt cerute cerințe ridicate pentru posibilitățile psihofiziologice a operatorului la indicii economici a locului de muncă și elementele lui, organele de dirijare.
Condițiile de muncă a programatorului-operator sunt legate cu încordări vizuale, fapt căruia sunt cerute cerințe față de iluminarea de producere, la conținutul ei spectral, și de asemenea la condițiile ergonomice a locului de muncă.
9.1 Calculul iluminării artificiale
O mare importanța pentru asigurarea capacității înalte de muncă și bunei dispoziții are iluminarea optimală a locului de lucru. Iluminatul poate fi natural și artificial. Alegerea tipului de iluminat trebuie să fie bazată pe cunoașterea avantajelor și a neajunsurilor diferitor sisteme de iluminat. Conform СНиП II-4-79 vom putea efectua proiectarea iluminatului artificial folosim metoda coeficientului de randament:
unde:
F – fluxul de iluminare a unei lămpi, lm;
En – iluminarea minimală normată, lx;
Sp – aria podelei, m2;
Z – coeficientul iluminării ne uniforme;
K – coeficientul de rezervă, ține cont de poluarea și învechirea becurilor;
N – numărul de instalații de iluminat;
n – numărul becurilor la o instalație;
r – coeficientul de randament a instalației de iluminat, se găsește în dependență de indiciul de încăpere.
Conform caracteristicii lucrului vizual ce este de categoria II cu un contrast mediu având caracteristica fonului deschis. Coeficientul iluminării ne uniforme pentru lămpi fluorescente este egal cu 0,9. Indiciul de încăpere se calcula astfel:
unde:
A, B – lungimea și lățimea încăperii, m;
Hl – înălțimea instalației de iluminare până la suprafața de lucru.
Valorile parametrilor folosiți sunt incluse în tabelul următor:
Tab. 18
Calculăm indicele de încăpere:
Conform indicelui de încăpere determinăm coeficientul de randament a instalației de iluminat. Pentru i= 1, randamentul instalației de iluminat r =0,66 pentru lampa fluoriscentă LDC. Cunoscând toți parametrii necesari putem calcula F1:
Fluxul de iluminare a unei lămpi ne permite alegerea lămpii în corespundere cu rezultatele obținute. Vom alege lampa fluoriscentă de tipul LDC40 cu tensiunea de alimentare de 220V și o putere de 40W. Puterea totală a tuturor lămpilor fluoriscente va fi egală cu 640W.
CONCLUZII
Crearea bazelor de date Client-Server in cadrul unei întreprinderi a devenit o necesitate stringentă, datorită creșterii volumului de informație și necesitatea de prelucrare mai rapidă a informației.
Necesitatea de accesare de catre mai mulți angajați a informației necesare pentru prelucrare este frecventă în orce întreprindere. O bază de date Client-Server proiectată în cadrul unei întreprinderi duce la rezolvarea acestei probleme și la minimizarea cheltuielelor de timp la accesarea informatiei necesare și a numărului de angejați care efectuau acest lucru până acum înlocuidui cu unu sau câțiva angajați mai calificați în domeniului dat.
Neajunsul folosirii acestei metode de automatizare a fluxsului de informații într-o întreprindere este că trebue de instruit fiecare angajat cu sustemul dat și cu noțiuni fundamentale ale calculatorului.
Acest produs actual este pe cale de implimentare implimentat în rețeaua Centrului de Instruire a Personalului pentru Transporturi Internaționale, și aduce un mare aport și un ajutor în automatizarea informației în cadrul întreprinderii.
BIBLIOGRAFIE
Octavian Bâscă „Baze de date” 1997 – Editura „BIC ALL S.A.” București.
Vitalie Cotelea „Baze de Date Relaționale: proiectare logică” Editura ASEM Chișinău 1997.
Шумаков П.В., Фаронов В.В.,”Delphi 5 руксводство разработчика баз данных” Москва Издательство «Нолидж» 2000.
ANEXA 1
Listingul programului
unit ClientM;
procedure TDM.IBDSJudeteAfterInsert(DataSet: TDataSet);
begin DM.IBSPCodJud.ExecProc;
DM.IBDSJudete.FieldByName('CodJud').Value:=
DM.IBSPCodJud.ParamByName('NR').Value; end;
procedure TDM.IBDSOraseAfterInsert(DataSet: TDataSet);
begin DM.IBSPCodOras.ExecProc;
DM.IBDSOrase.FieldByName('CodOras').Value:=
DM.IBSPCodOras.ParamByName('NR').Value; end;
procedure TDM.IBDatabase1BeforeConnect(Sender: TObject);
begin wite.Show; end;
procedure TDM.IBDatabase1AfterConnect(Sender: TObject);
begin Wite.Hide; end; end.
unit ClientU;
uses ClientM, Unit2, Unit3, Unit4, Unit5, Unit6, Unit8, Unit9, Unit12, Unit13, Unit14, Unit15, Unit16, Unit17, Unit18, Unit19;
procedure TMain.Exit1Click(Sender: TObject);
begin Main.Close; end;
procedure TMain.IntreprinderideTransport1Click(Sender: TObject);
begin Intr.Show; end;
procedure TMain.Judete1Click(Sender: TObject);
begin Judete.show; end;
procedure TMain.Orase1Click(Sender: TObject);
begin Orase.Show; end;
procedure TMain.Add1Click(Sender: TObject);
begin Ancheta.Show; end;
procedure TMain.GrupedeStudiu1Click(Sender: TObject);
begin GrDeStud.Show; end;
procedure TMain.Legitimatii1Click(Sender: TObject);
begin Tiparire.show; end;
procedure TMain.Anchete1Click(Sender: TObject);
begin FindAncheta.Show; end;
procedure TMain.Grupe2Click(Sender: TObject);
begin ModGrupe.Show; end;
procedure TMain.Judete2Click(Sender: TObject);
begin ModJudete.Show; end;
procedure TMain.Orase2Click(Sender: TObject);
begin ModOrase.Show; end;
procedure TMain.N3Click(Sender: TObject);
begin Intreprinderi.Show; end;
procedure TMain.Anchete2Click(Sender: TObject);
begin DelAnchete.Show; end;
procedure TMain.Judete3Click(Sender: TObject);
begin DelJudete.Show; end;
procedure TMain.Orase3Click(Sender: TObject);
begin DelOrase.Show; end;
procedure TMain.Grupe1Click(Sender: TObject);
begin DelGrupe.Show; end;
procedure TMain.Intreprinderi1Click(Sender: TObject);
begin DelInteprinderi.Show; end; end.
unit Unit10;
uses ClientM, Unit9, Unit11;
procedure TRaport1.QuickRep1AfterPreview(Sender: TObject);
begin Tiparire.Show; end;
procedure TRaport1.QuickRep1StartPage(Sender: TCustomQuickRep);
var Year, Month, Day, Hour, Min, Sec, MSec: Word;
MyDate: TDateTime;
Begin with DM.IBQLocateCurs do begin First;
DM.IBDSGrDeStud.Locate('ID_GR',FieldByName('ID_GR').Value,[loCaseInsensitive]);
DecodeDate(DM.IBDSGrDeStud.FieldByName('SFIRS_PERIOD').Value, Year, Month, Day); Year:=Year+3; MyDate := EncodeDate(Year, Month, Day);
if not eof then begin
QRLabel245.Caption:=FieldByName('ID_Cursant').Value;
QRLabel242.Caption:=FieldByName('Numele').Value;
QRLabel243.Caption:=FieldByName('Prenumele').Value;
QRLabel5.Caption:=FormatDateTime('dd,mm,yyyy',DM.IBDSGrDeStud.FieldByName('SFIRS_PERIOD').Value);
QRLabel6.Caption:=FormatDateTime('dd,mm,yyyy',MyDate);
Next; end; end; end; end.
unit Unit11;
uses Unit9, ClientM;
procedure TRaport.QuickRep1AfterPreview(Sender: TObject);
begin Tiparire.show; end;
procedure TRaport.QuickRep1StartPage(Sender: TCustomQuickRep);
var Year, Month, Day, Hour, Min, Sec, MSec: Word;
MyDate: TDateTime;
Begin with DM.IBQLocateCurs do begin First;
DM.IBDSGrDeStud.Locate('ID_GR',FieldByName('ID_GR').Value,[loCaseInsensitive]);
DecodeDate(DM.IBDSGrDeStud.FieldByName('SFIRS_PERIOD').Value, Year, Month, Day); Year:=Year+3; MyDate := EncodeDate(Year, Month, Day);
if not eof then begin
Raport.QRLabel245.Caption:=FieldByName('ID_Cursant').Value;
Raport.QRLabel242.Caption:=FieldByName('Numele').Value;
Raport.QRLabel243.Caption:=FieldByName('Prenumele').Value;
Raport.QRLabel5.Caption:=FormatDateTime('dd,mm,yyyy',DM.IBDSGrDeStud.FieldByName('SFIRS_PERIOD').Value);
Raport.QRLabel6.Caption:=FormatDateTime('dd,mm,yyyy',MyDate);
Next;end; if not eof then begin
Raport.QRLabel34.Caption:=FieldByName('ID_Cursant').Value;
Raport.QRLabel38.Caption:=FieldByName('Numele').Value;
Raport.QRLabel41.Caption:=FieldByName('Prenumele').Value;
Raport.QRLabel86.Caption:=FormatDateTime('dd,mm,yyyy',DM.IBDSGrDeStud.FieldByName('SFIRS_PERIOD').Value);
Raport.QRLabel53.Caption:=FormatDateTime('dd,mm,yyyy',MyDate);
Next;end; if not eof then
begin Raport.QRLabel63.Caption:=FieldByName('ID_Cursant').Value;
Raport.QRLabel67.Caption:=FieldByName('Numele').Value;
Raport.QRLabel70.Caption:=FieldByName('Prenumele').Value;
Raport.QRLabel48.Caption:=FormatDateTime('dd,mm,yyyy',DM.IBDSGrDeStud.FieldByName('SFIRS_PERIOD').Value);
Raport.QRLabel82.Caption:=FormatDateTime('dd,mm,yyyy',MyDate);
Next;end; if not eof then
begin Raport.QRLabel94.Caption:=FieldByName('ID_Cursant').Value;
Raport.QRLabel98.Caption:=FieldByName('Numele').Value;
Raport.QRLabel101.Caption:=FieldByName('Prenumele').Value;
Raport.QRLabel108.Caption:=FormatDateTime('dd,mm,yyyy',DM.IBDSGrDeStud.FieldByName('SFIRS_PERIOD').Value);
Raport.QRLabel113.Caption:=FormatDateTime('dd,mm,yyyy',MyDate);
Next;end; if not eof then
begin Raport.QRLabel123.Caption:=FieldByName('ID_Cursant').Value;
Raport.QRLabel127.Caption:=FieldByName('Numele').Value;
Raport.QRLabel130.Caption:=FieldByName('Prenumele').Value;
Raport.QRLabel138.Caption:=FormatDateTime('dd,mm,yyyy',DM.IBDSGrDeStud.FieldByName('SFIRS_PERIOD').Value);
Raport.QRLabel142.Caption:=FormatDateTime('dd,mm,yyyy',MyDate);
Nxt;end; if not eof then
begin Raport.QRLabel152.Caption:=FieldByName('ID_Cursant').Value;
Raport.QRLabel156.Caption:=FieldByName('Numele').Value;
Raport.QRLabel159.Caption:=FieldByName('Prenumele').Value;
Raport.QRLabel174.Caption:=FormatDateTime('dd,mm,yyyy',DM.IBDSGrDeStud.FieldByName('SFIRS_PERIOD').Value);
Raport.QRLabel171.Caption:=FormatDateTime('dd,mm,yyyy',MyDate);
Next;end; end; end; end.
unit Unit12;
uses ClientM;
procedure TModGrupe.Button1Click(Sender: TObject);
begin with DM.ibqmodDenGr do begin Close; UnPrepare;
ParamByName('DEN_CURS').Value:=Edit2.Text;
ParamByName('GR_NR').Value:=Edit1.Text;
ParamByName('Incep_period').Value:=DateTimePicker1.DateTime;
Prepare; Open; end; end;
procedure TModGrupe.Button2Click(Sender: TObject);
begin try Dm.IBQModDenGr.Post;
Dm.IBTransaction5.Commit; Except ShowMessage('Eroare');
Dm.IBTransaction5.Rollback; end; Dm.IBQModDenGr.Open; end; end.
unit Unit13;
uses ClientM;
procedure TModJudete.Button1Click(Sender: TObject);
begin with Dm.IBQModJudete do begin Close;
UnPrepare; ParamByName('DenJud').Value:=Edit1.Text; Prepare; Open; end; end;
procedure TModJudete.Button2Click(Sender: TObject);
begin try Dm.IBQModJudete.Post;
DM.IBTransaction1.Commit; Except ShowMessage('Eroare');
DM.IBTransaction1.Rollback; end; Dm.IBQModJudete.Open; end; end.
unit Unit14;
uses ClientM;
procedure TModOrase.Button1Click(Sender: TObject);
begin with DM.IBQModOrase do begin Close;
UnPrepare; ParamByName('DenOras').Value:=Edit1.Text; Prepare; Open; end; end;
procedure TModOrase.Button2Click(Sender: TObject);
begin try DM.IBQModOrase.Post;
DM.IBTransaction2.Commit; Except ShowMessage('Eroare');
Dm.IBTransaction2.Rollback; end; DM.IBQModOrase.Open; end; end.
unit Unit15;
uses ClientM;
procedure TIntreprinderi.Button1Click(Sender: TObject);
begin try With DM.IBQModIntreprinderi do Begin Close; UnPrepare;
ParamByName('DenIntr').Value:=Edit1.Text; ParamByName('DenJud').Value:=Edit2.Text;
ParamByName('DenOras').Value:=Edit3.Text; Prepare; Open;end;
Except ShowMessage('Eroare'); end; DM.IBDSJudete.Open; DM.IBDSOrase.Open; end;
procedure TIntreprinderi.Button2Click(Sender: TObject);
begin try DM.IBQModIntreprinderi.Post; DM.IBQModIntreprinderi.Close;
Except ShowMessage('Eroare'); end; DM.IBQModIntreprinderi.Open; end;
procedure TIntreprinderi.DBEdit4Exit(Sender: TObject);
begin if DBEdit4.Text='' then DBEdit4.Text:=' '; end;
procedure TIntreprinderi.DBEdit6Exit(Sender: TObject);
begin If DBEdit6.Text='' then DBEdit6.Text:=' '; end;
procedure TIntreprinderi.DBEdit6Enter(Sender: TObject);
begin If DBEdit6.Text=' ' then DBEdit6.Text:=''; end;
procedure TIntreprinderi.DBEdit5Exit(Sender: TObject);
begin If DBEdit5.Text='' then DBEdit5.Text:=' '; end;
procedure TIntreprinderi.DBEdit5Enter(Sender: TObject);
begin If DBEdit5.Text=' ' then DBEdit5.Text:=''; end;
procedure TIntreprinderi.DBEdit4Enter(Sender: TObject);
begin if DBEdit4.Text=' ' then DBEdit4.Text:=''; end; end.
unit Unit16;
uses ClientM;
procedure TDelAnchete.Edit1Change(Sender: TObject);
begin DM.IBQDelAnchete.Locate('Numele',Edit1.Text,[loPartialKey]); end;
procedure TDelAnchete.Edit2Change(Sender: TObject);
begin DM.IBQDelAnchete.Locate('Prenumele',Edit2.Text,[loPartialKey]); end;
procedure TDelAnchete.Edit3Change(Sender: TObject);
begin DM.IBQDelAnchete.Locate('Patronimicul',Edit3.Text,[loPartialKey]); end;
procedure TDelAnchete.Edit4Change(Sender: TObject);
begin DM.IBQDelAnchete.Locate('Nr_Pass',Edit4.Text,[loPartialKey]); end;
procedure TDelAnchete.FormActivate(Sender: TObject);
begin DM.IBQDelAnchete.Close; DM.IBQDelAnchete.Open; end; end.
unit Unit17;
uses ClientM;
procedure TDelJudete.FormActivate(Sender: TObject);
begin DM.IBQDelJudete.Close; DM.IBQDelJudete.Open; end; end.
unit Unit18;
uses ClientM;
procedure TDelOrase.FormActivate(Sender: TObject);
begin DM.IBQDelOrase.Close; DM.IBQDelOrase.Open; end; end.
unit Unit19;
uses ClientM;
procedure TDelGrupe.Edit1Change(Sender: TObject);
begin DM.IBQDelGrupe.Locate('GR_NR',Edit1.Text,[loPartialKey]); end;
procedure TDelGrupe.Edit2Change(Sender: TObject);
begin DM.IBQDelGrupe.Locate('Den_Curs',Edit2.Text,[loPartialKey]); end;
procedure TDelGrupe.FormActivate(Sender: TObject);
begin DM.IBQDelGrupe.Close; DM.IBQDelGrupe.Open; end; end.
unit Unit20;
uses ClientM;
procedure TDelInteprinderi.Edit1Change(Sender: TObject);
begin DM.IBQDelIntreprinderi.Locate('DenIntr',Edit1.Text,[loPartialKey]); end;
procedure TDelInteprinderi.FormActivate(Sender: TObject);
begin DM.IBQDelIntreprinderi.Close; DM.IBQDelIntreprinderi.Open; end; end.
unit Unit3;
uses ClientM;
procedure TJudete.BitBtn3Click(Sender: TObject);
begin Judete.Hide; end;
procedure TJudete.BitBtn2Click(Sender: TObject);
begin try DM.IBDSJudete.Insert;
DM.IBDSJudete.FieldByName('DenJud').Value:=Edit1.Text;
DM.IBDSJudete.Post; DM.IBTransaction1.Commit;
Except ShowMessage('Eroare!');
DM.IBTransaction1.Rollback; end; DM.IBDSJudete.Open; Edit1.Clear; end; end.
unit Unit4;
uses ClientM;
procedure TOrase.BitBtn3Click(Sender: TObject);
begin Orase.Hide; end;
procedure TOrase.BitBtn2Click(Sender: TObject);
begin try
DM.IBDSOrase.Insert DM.IBDSOrase.FieldByName('DenOras').Value:=Edit1.Text;
DM.IBDSOrase.Post; DM.IBTransaction2.Commit; except
ShowMessage('Eroare!'); DM.IBTransaction2.Rollback; end; DM.IBDSOrase.Open; Edit1.Clear; end; end.
unit Unit5;
uses ClientM, Unit7;
procedure TAncheta.BitBtn2Click(Sender: TObject);
begin try with DM.IBDSAncheta.QInsert do begin
DM.IBDSAncheta.close; DM.IBDSCursanti.Close; DM.IBSPCodAncheta.ExecProc;
Params.ByName('CodAncheta').Value:=
DM.IBSPCodAncheta.ParamByName('NR').Value; DM.IBSPIDCursanti.ExecProc;
DM.IBDSCursanti.QInsert.Params.ByName('Id_Cursant').Value:=
DM.IBSPIDCursanti.ParamByName('NR').Value;
DM.IBDSCursanti.QInsert.Params.ByName('Cod_Ancheta').Value:=
DM.IBSPCodAncheta.ParamByName('NR').Value;
Params.ByName('Numele').Value:=Edit1.Text;
Params.ByName('Prenumele').Value:=Edit2.Text;
Params.ByName('Patronimicul').Value:=Edit7.Text;
Params.ByName('Data_Nast').Value:=DateTimePicker1.DateTime;
Params.ByName('Nr_Pass').Value:=Edit3.Text;
Params.ByName('Categoria').Value:=Edit4.Text;
Params.ByName('Nr_Permis').Value:=Edit6.Text;
Params.ByName('Vech_Munca').Value:=StrToInt(Edit5.Text);
DM.IBDSIntrDeTrans.Locate('DenIntr',ComboBox1.Text,[loCaseInsensitive]);
Params.ByName('CodIntr').Value:=DM.IBDSIntrDeTrans.FieldByName('CodIntr').Value;
DM.IBDSJudete.Locate('DenJud',ComboBox2.Text,[loCaseInsensitive]);
Params.ByName('CodJud').Value:=DM.IBDSJudete.FieldByName('CodJud').Value;
DM.IBDSOrase.Locate('DenOras',ComboBox3.Text,[loCaseInsensitive]);
Params.ByName('CodOras').Value:=DM.IBDSOrase.FieldByName('CodOras').Valu;
Params.ByName('Comuna').Value:=Edit9.Text;
Params.ByName('Strada').Value:=Edit10.Text;
Params.ByName('Telefon').Value:=Edit11.Text;
DM.IBDSGrDeStud.Locate('GR_NR',ComboBox4.Text,[loCaseInsensitive]);
DM.IBDSCursanti.QInsert.Params.ByName('ID_GR').Value:=DM.IBDSGrDeStud.FieldByName('ID_GR').Value; DM.IBDSCursanti.QInsert.Params.ByName('Reciclare').Value:=0;
DM.IBDSCursanti.QInsert.Prepare; DM.IBDSCursanti.QInsert.ExecQuery;
Prepare; ExecQuery; end; except ShowMessage('Eroare la Salvare');
end; DM.IBDSAncheta.Open; DM.IBDSCursanti.Open; end;
procedure TAncheta.ComboBox2DropDown(Sender: TObject);
begin
with DM.IBDSJudete do begin First; ComboBox2.Items.Clear; while not eof do
begin ComboBox2.Items.Add(FieldByName('DenJud').Value); Next; end; end; end;
procedure TAncheta.ComboBox3DropDown(Sender: TObject);
begin
with DM.IBDSOrase do Begin First; ComboBox3.Items.Clear; while not eof do
begin ComboBox3.Items.Add(FieldByName('DenOras').Value); Next; end; end; end;
procedure TAncheta.ComboBox4DropDown(Sender: TObject);
var tmp1,tmp2,tmp3:string[30];
begin with DM.IBDSGrDeStud do Begin First; ComboBox4.Items.Clear;
while not eof do begin if FieldByName('INCEP_PERIOD').value>=Date then
ComboBox4.Items.Add(FieldByName('GR_NR').Value); Next; end; end; end;
procedure TAncheta.ComboBox1DropDown(Sender: TObject);
begin with DM.IBDSIntrDeTrans do
Begin Open; First; ComboBox1.Items.Clear; while not eof do
begin ComboBox1.Items.Add(FieldByName('DenIntr').Value); Next; end; end; end;
procedure TAncheta.FormActivate(Sender: TObject);
begin DM.IBDSJudete.Open; DM.IBDSOrase.Open; DM.IBDSGrDeStud.open; end; end.
unit Unit6;
uses ClientM;
procedure TGrDeStud.BitBtn3Click(Sender: TObject);
begin GrDeStud.Hide; end;
procedure TGrDeStud.BitBtn2Click(Sender: TObject);
begin
try with DM.IBDSGrDeStud do begin Close; DM.IBSPGenGrDeStud.ExecProc;
QInsert.Params.ByName('ID_GR').Value:=
DM.IBSPGenGrDeStud.ParamByName('NR').Value;
QInsert.Params.ByName('GR_NR').Value:=Edit1.Text;
QInsert.Params.ByName('Incep_Period').Value:=DateTimePicker1.DateTime;
QInsert.Params.ByName('Sfirs_Period').Value:=DateTimePicker2.DateTime;
QInsert.Params.ByName('DEN_CURS').Value:=Edit2.Text;
QInsert.Prepare; QInsert.ExecQuery; end;
except ShowMessage('Eroare'); end; DM.IBDSGrDeStud.Open; Edit1.Clear; Edit2.Clear; end; end.
unit Unit7;
uses ClientM, ClientU;
procedure TCursanti.FormActivate(Sender: TObject);
begin
DM.IBDSIntrDeTrans.Locate('CodIntr',DM.IBDSAncheta.FieldByName('CodIntr').Value,[loCaseInsensitive]);
Label14.Caption:=DM.IBDSIntrDeTrans.FieldByName('DenIntr').Value;
DM.IBDSJudete.Locate('CodJud',DM.IBDSAncheta.FieldByName('CodJud').Value,[loCaseInsensitive]);
Label15.Caption:=DM.IBDSJudete.FieldByName('DenJud').Value;
Try DM.IBDSOrase.Locate('CodOras',DM.IBDSAncheta.FieldByName('CodOras').Value,[loCaseInsensitive]);
Label16.Caption:=DM.IBDSOrase.FieldByName('DenOras').Value;
Except Label16.Caption:=''; end; end;
procedure TCursanti.BitBtn1Click(Sender: TObject);
begin try with DM.IBDSCursanti do begin close; DM.IBSPIDCursanti.ExecProc;
QInsert.Params.ByName('ID_CURSANT').Value:=
DM.IBSPIDCursanti.ParamByName('NR').Value;
QInsert.Params.ByName('Cod_Ancheta').Value:=
DM.IBDSAncheta.FieldByName('CodAncheta').Value;
QInsert.Params.ByName('Reciclare').Value:=0;
DM.IBDSGrDeStud.Locate('GR_NR',ComboBox1.Text,[loCaseInsensitive]);
QInsert.Params.ByName('ID_GR').Value:=DM.IBDSGrDeStud.FieldByName('ID_GR').Value;
QInsert.Prepare; QInsert.ExecQuery; Open; end;
except ShowMessage('Eroare'); end; end;
procedure TCursanti.ComboBox1DropDown(Sender: TObject);
begin with DM.IBDSGrDeStud do Begin First; ComboBox1.Items.Clear;
while not eof do begin if FieldByName('INCEP_PERIOD').value>=Date then
ComboBox1.Items.Add(FieldByName('GR_NR').Value);
Next; end; end; end; end.
unit Unit8;
uses ClientM, Unit7;
procedure TFindAncheta.Button1Click(Sender: TObject);
var Numele:String[20];
Prenumele:String[20];
Nr_Pass:String[20];
Begin DM.IBDSAncheta.Open; DM.IBDSIntrDeTrans.Open; Numele:=Edit1.Text; Prenumele:=Edit2.Text; Nr_Pass:=Edit3.Text;
if RadioGroup1.Items[RadioGroup1.ItemIndex] = 'Nume єi Prenume' then begin if not DM.IBDSAncheta.Locate('Numele;Prenumele',VarArrayOf([Numele,Prenumele]),[loPartialKey])
Then begin DM.IBDSAncheta.Close;
DM.IBDSIntrDeTrans.Close; end; end;
if RadioGroup1.Items[RadioGroup1.ItemIndex] = 'Nr. Paєaport' then
begin if not DM.IBDSAncheta.Locate('Nr_Pass',Nr_Pass,[loCaseInsensitive])
Then begin DM.IBDSAncheta.Close;
DM.IBDSIntrDeTrans.Close; end; end; end;
procedure TFindAncheta.BitBtn1Click(Sender: TObject);
begin try
if DBEdit8.Text='' then DBEdit8.Text:=' ';
if DBEdit9.Text='' then DBEdit9.Text:=' ';
if DBEdit10.Text='' then DBEdit10.Text:=' ';
DM.IBDSAncheta.ApplyUpdates;
Except ShowMessage('Eroare la Salvare!');
DM.IBDSAncheta.CancelUpdates; end; end;
procedure TFindAncheta.BitBtn2Click(Sender: TObject);
begin Cursanti.show; end;
procedure TFindAncheta.DBEdit8Click(Sender: TObject);
begin if DBEdit8.Text=' ' then DBEdit8.Text:=''; end;
procedure TFindAncheta.DBEdit9Click(Sender: TObject);
begin if DBEdit9.Text=' ' then DBEdit9.Text:=''; end;
procedure TFindAncheta.DBEdit10Click(Sender: TObject);
begin if DBEdit10.Text=' ' then DBEdit10.Text:=''; end; end.
unit Unit9;
uses ClientM, Unit10, Unit11;
procedure TTiparire.ComboBox1DropDown(Sender: TObject);
begin with DM.IBDSGrDeStud do
Begin Open; First; ComboBox1.Items.Clear;
while not eof do
begin ComboBox1.Items.Add(FieldByName('GR_NR').Value);
Next; end; end; end;
procedure TTiparire.BitBtn1Click(Sender: TObject);
var i:integer;
begin with Dm.IBQLocateCurs do
begin Open;First;i:=0;
While not eof do begin inc(i); Next; end;
if i>=6 then begin Tiparire.Hide; Raport.QuickRep1.Preview;
end else ShowMessage('Tipariti cate un exemplar.');
end;end;
procedure TTiparire.ComboBox1Change(Sender: TObject);
begin With DM.IBQLocateCurs do
Begin close; UnPrepare;
ParamByName('GR_NR').Value:=ComboBox1.Text;
Prepare; Open; end; end;
procedure TTiparire.BitBtn2Click(Sender: TObject);
begin Tiparire.Hide;
Raport1.QuickRep1.Preview;
end; end.
ANEXA 2
Structura bazei de date
ANEXA 3
Schema interacțiunii aplicației client cu serverul bazei de date
ANEXA 4
Schema funcțională a bazei de date
ANEXA 5
Schema funcțională a aplicației client
ANEXA 6
Graful-rețea pentru proiectarea “Bazei de Date Client-Server a Centrului de Instruire a Personalului pentru Transporturi Inernaționale”.
=== SCHEMA_FUNCTIONALA ===
Schema funcțională a aplicației client
=== STRUCTURA_BD ===
Stuctura bazei de date
=== XILZ ===
Compararea arhitecturelor Client-Server.
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Elaborarea Bazei de Date Client Server a Centrului de Instruire a Personalului Pentru Transporturi Internationale (ID: 148783)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.