Sisteme de Gestiune a Bazelor de Date

Cuprins

Introducere 3

Structura lucrării 3

Capitolul 1 – Sisteme de gestiune a bazelor de date 4

1.1. Definiții 4

1.1.1. Definiție baza de date 4

1.1.2. Definiție SGBD 4

1.2. Clasificări ale SGBD 4

1.3. Caracteristici ale SGBD 5

1.4. Tipuri de relații dintre entități. Normalizarea unei baze de date 6

1.4.1. Relații între entități 6

1.4.2. Normalizarea unei baze de date 7

Capitolul 2 – Microsoft Access 9

2.1. Prezentare pe scurt 9

2.2. Limbajul SQL – Structured Query Language 9

2.3. Componentele unei baze de date Microsoft Access 10

2.4. Realizarea tabelelor în Access 13

Capitolul 3 – Proiectarea și realizarea aplicației 15

3.1. Funcționalitățile aplicației 15

3.2. Actorii software 15

3.3 Dezvoltarea bazei de date – ciclul de viață 16

3.3.1. Colectarea și analizarea cerințelor 16

3.3.2. Definirea sistemului 17

3.3.3. Planificarea bazei de date 19

3.3.4. Restricții de integritate 20

3.3.5. Analiza bazei de date – Modelul conceptual 21

3.3.6. Diagrama Entitate-Asociere (ERD – Entity Relationship Diagram) 22

3.3.7. Proiectarea bazei de date – Modelul logic 26

3.3.8. Implementarea bazei de date – Modelul fizic 28

3.3. Structura tabelelor 31

3.4. Schema bazei de date 34

3.5. Exemple de date din tabele 35

3.6. Interogări 39

3.6.1. Folosirea interogărilor SQL în cadrul aplicației 39

3.6.2. Limbajul de manipulare a datelor 39

3.6.3. Extragerea informațiilor din bazele de date 40

3.7. Implementarea 47

4. Manual de utilizare a aplicației 48

4.1. Forma principală și design-ul 48

4.2. Introducerea datelor cu ajutorul formularelor 48

4.3. Afișarea datelor cu ajutorul rapoartelor 53

Concluzii 58

Bibliografie 59

Introducere

Această lucrare are la bază o aplicație pentru gestiunea unui hotel. Aplicația este realizată în Access și se urmărește realizarea unei baze de date care să conțină datele personale ale turistului ce urmează să se cazeze în hotel și detalii despre camerele și serviciile oferite.

Bazele de date le-am studiat în semestrul al doilea al ultimului an de facultate și am fost foarte atrasă de această materie. De aceea am și ales să fac lucrarea de licență în acest domeniu. Tema a fost gândită cu speranța că într-o bună zi voi deține un hotel și, în acest scop, m-am documentat în legătura cu munca recepționerului și managementul unui hotel. De asemenea am dorit să îmi îmbunatățesc și din cunoștințele acumulate pe parcursul cursurilor.

Structura lucrării

Lucrarea este structurată pe 4 părți. Astfel, în partea introductivă am vorbit despre prezentarea generală a bazelor de date, definiția, caracteristicile și sistemul de generare al acesteia, despre tipul de relații și normalizarea al bazelor de date.

Cel de-al doilea capitol conține generalități despre aplicația Microsoft Access.

Al treilea capitol, Proiectarea și realizarea bazei de date, conține detaliile necesare pe care le-am folosit pentru realizarea bazei de date pe care mi-am propus-o. Astfel, am descris și am exemplificat fiecare pas pe care l-am făcut în finalizarea acesteia.

În ultimul capitol, pentru înțelegerea completă a funcționalității bazei de date, am introdus un manual de utilizare.

La sfărșitul lucrării am scris cateva concluzii obținute în urma realizării acestei aplicații, precum și referințele bibliografice.

Capitolul 1 – Sisteme de gestiune a bazelor de date

1.1. Definiții

1.1.1. Definiție baza de date

Baza de date reprezintã un ansamblu de date organizate coerent, structurate cu o redundanța minimã, accesibile cât mai multor utilizatori în același timp. Datele sunt informații codificate la nivelul sistemului de calcul cum ar fi texte, numere, imagini, sunete, date calendaristice, reprezentate prin semnale. 1

Modelul algebric fundamental de organizare este Modelul Relațional al Datelor (MRD), care are la bază algebra relațională elaborată de Edgar Codd în anul 1970. În funcție de modul de organizare a informațiilor, se cunosc cîteva modele de baze de date: ierarhic, rețea, arborescent etc.

1.1.2. Definiție SGBD

Bazele de date sunt prelucrate de un sistem specializat denumit Sistem de Gestiune a Bazelor de Date (SGBD) – Database Management System – DBMS.

Un sistem de gestiune a bazelor de date este un mediu de dezvoltare care oferă instrumentele de lucru cu bazele de date.

1.2. Clasificări ale SGBD

În funcție de modul de organizare a informațiilor, se cunosc câteva modele de sisteme de gestiune a bazelor de date: ierarhic, rețea, arborescent.

1. Modelul ierarhic. Cu ajutorul modelului conceptual ierarhic, schema bazei de date poate fi reprezentată sub forma unui arbore în care nodurile exprimă colecții de date, iar ramurile reflectă relațiile de asociere între înregistrările colecțiilor de date superioare și inferioare. Accesul la înregistrările colecțiilor de date inferioare se face prin traversarea arborelui, adică se parcurg toate colecțiile aflate în subordonare ierarhică dintre colecția – rădăcină și colecția cercetată. Unui element superior îi pot corespunde unul sau mai multe elemente inferioare, iar unui element inferior îi corespunde un singur element superior.

2. Modelul rețea. Modelul rețea se aseamănă cu cel ierarhic, diferența constînd în aceea că unui element inferior îi pot corespunde unul sau mai multe elemente superioare.

3. Modelul relațional. Modelul relațional este în prezent cel mai răspîndit model de baze de date. Acest model are o singură structură de date: relația sau tabelul. O bază de date relațională este un ansamblu de relații (tabele) grupate în jurul unui subiect bine definit. Deci, o relație poate fi redată printr-un tabel, în care fiecare rînd reprezintă o înregistrare diferită, iar fiecare coloană un atribut. Coloanele tabelului sunt identificate prin nume diferite și reprezintă cîmpurile (atributele, caracteristicile) modelului conceptual. În fiecare coloană datele trebuie să fie de același tip. Căutarea în acest model de BD se face secvențial toate articolele și comparînd criteriile de căutare. Articolele ce satisfac conditiei căutării se selectează și pot fi afișate.

1.3. Caracteristici ale SGBD

Serviciile pe care le oferă un sistem de gestiune a bazelor de date sunt:

De prelucrare a bazelor de date:

definirea bazelor de date

manipularea datelor cum ar fi integrarea bazelor de date, introducerea datelor, modificarea datelor și ștergerea acestora

extragerea datelor și prelucrarea datelor

De calitate:

persistența datelor

integritatea datelor

consistența datelor

controlul datelor se ocupă cu gestiunea utilizatorilor, drepturile utilizatorilor și siguranța prelucrărilor adică cu gestiunea tranzacțiilor

1.4. Tipuri de relații dintre entități. Normalizarea unei baze de date

1.4.1. Relații între entități

Relațiile sunt expresii verbale care indică asocierile, legaturile logice care se formează între entități. De regulă entitățile sunt substantive, iar relațiile sunt verbe și se deduc din documentația beneficiarului. 2

Relațiile pot fi:

obligatorii – orice înregistrare a entității trebuie să fie legată de una sau mai multe înregistrări ale celeilalte entități

opționale – orice înregistrare a entității ar putea să fie legată de una sau mai multe înregistrări ale celeilalte entități

Convenții pentru reprezentarea unei relații

Relația dintre două entități se reprezintă printr-un segment care le uneste. Acesta poate fi desenată:

cu linie continuă – daca relața este obligatorie pentru entitatea respectivă

cu linie punctată -dacă relația este opțională pentru acea entitate

Numele relației este un verb sau o expresie verbală și se scrie deasupra liniei care desemnează relația din stânga și sub linie pentru entitatea din stânga

Capătul segmentului care reprezintă relația poate fi:

simplu-o unică înregistrare a entității respective este conectată cu altă entitate

cu trei picioruse -mai multe inregistrări ale entității respective sunt în relație cu cealaltă entitate (numite și “picioare de cioară”)

Orice relație este caracterizată de:

Numele relației

Opționalitatea relației

Cardinalitatea relației este numărul de instanțe ale entității din partea dreaptă care pot intra în relație cu o instanță din partea stângă (unul și numai unul sau unul sau mai mulți).

Între două entități pot exista următoarele tipuri de relații:

Relație 1:1 obligatorie la ambele capete

Relație 1:1 opțională la ambele capete

Relație 1:1 opțională la stânga, obligatorie la dreapta

Relație 1:1 obligatorie la stânga, opțională la dreapta

Relație M:1 opțională la stanga, obligatorie la dreapta

Relație M:1 obligatorie la stânga, opțională la dreapta

Relație M:M obligatorie la ambele capete

Relație M:M opțională la ambele capete

1.4.2. Normalizarea unei baze de date

Când se proiectează o bază de date, scopul principal este de a reprezenta cât mai corecte informațiile și să diminuăm cât mai mult posibilitatea de a ajunge la informații eronate. Pentru a ajunge la această performanță, trebuie să folosim normalizarea.

Normalizarea este proiectul logic al bazei de date. Obiectivul principal al unui proiect este dezvoltarea schemelor relaționale corecte. Astfel trebuie urmărit:

evitarea datelor repetate;

evitarea anomaliilor de editare;

asigurarea reprezentării relațiilor dintre atribute;

facilitarea verificării actualizărilor care nu trebuie să forțeze omogenitatea bazei de date.

Normalizarea este un proces de micșorare a redundanțelor și creștere a stabilității baze de date. Existența redundanțelor dintr-o bază de date produce diferite efecte defavorabile:

pierderea de spațiu;

scăderea costurilor;

apariția inconsistențelor;

îngreunarea reprezentării datelor.

Normalizarea presupune determinarea locului în care trebuie plasate anumite date în cadrul tabelelor bazei de date, stabilind totodată relațiile dintre acestea. Prin cuvântul “normă” se înțelege respectarea unui standard și reprezintă setul de condiții impuse și cunoscute sub denumirea de forme normale. Pentru a respecta aceste reguli trebuie identificate condițiile care trebuie respectate în scopul evitării încălcării integrității datelor impunându-se în acest scop descompunerea relațiilor. Denormalizarea este procesul invers, opus normalizării efectuat cu scopul îmbunătățirii performanțelor bazei de date.

Normalizarea este, cu alte cuvinte, un proces de descompunere a unui tabel în două sau mai multe tabele cu scopul eliminării redundanțelor care generează anomalii de actualizare. În timpul procesului de normalizare, structura tabelelor se testează cu ajutorul formelor normale care impun regulile de descompunere.

O formă normală este, cu alte cuvinte, un set specific de reguli ce pot fi utilizate în scopul testării structurii unui tabel pentru a obține asigurarea că structura respectivă nu pune probleme la introducerea sau extragerea datelor.

Capitolul 2 – Microsoft Access

2.1. Prezentare pe scurt

Microsoft Access este aplicația de management al bazelor de date pusã la dispoziție de compania Microsoft în pachetul Office. Access permite sã stocãm și sã administrãm volume mari de date, organizate în unitãți numite înregistrãri. Interfața grafică ușor de manevrat și de înțeles este una din plusurile ale acestui program. 3

2.2. Limbajul SQL – Structured Query Language

Limbajul SQL este un limbaj neprocedural standard care accesează și manipulează bazele de date. Microsoft Access este unul dintre programele de baze de date relaționale care utilizează SQL pentru a lucra cu datele.

SQL utilizează un standard internațional recunoscut de autoritățile de standardizare precum ISO și ANSI.

Putem utiliza SQL pentru a descrie seturi de date care ne pot ajuta să răspundem la întrebări. Utilizând acest limbaj trebuie să ne asigurăm că sintaxa folosită este și cea corectă.

Sintaxa este setul de reguli prin care sunt combinate corect elementele unui limbaj care se bazează pe sintaxa limbii engleze și utilizează multe dintre elementele sintaxei Visual Basic for APPlications (VBA).

Acest limbaj conține comenzi grupate în 3 sublimbaje precum:

Data Manipulation Language (DML) ce conține comenzi pentru interogare, introducere, modificare și ștergere a datelor.

Data Definition Language (DDL) ce conține comenzi pentru crearea bazei de date.

Data Control Language (DCL) ce conține comenzile pentru controlul datelor.

2.3. Componentele unei baze de date Microsoft Access

Sistemele de gestiune a bazelor de date sunt alcătuite dintr-o serie de module ce îndeplinesc diverse funcționalități. Anumite funcționalități sunt îndeplinite împreună cu sistemul de operare pe care este folosit sistemul respectiv. Principalele componente ale unui sisteme de gestiune al bazelor de date sunt: 4

Administratorul de fișiere gestionează alocarea spațiului pe disc precum și structurile de date utilizate la reprezentarea datelor pe disc. Acesta transmite cererea către metoda de acces corespunzătoare care fie citește datele din buffer-ul sistemului, fie le scrie în acesta.

Administratorul bazei de date acceptă interogările și examinează schemele externe și conceptuale pentru a determina ce înregistrări sunt necesare pentru a satisface o anumită cerere, după care apelează administratorul de fișiere pentru a efectua cererea.

Procesorul de interogare transformă interogările într-o serie de instrucțiuni de nivel jos adresate administratorului de baze de date.

Figura – Componentele bazei de date

Preprocesorul DML convertește instrucțiunile DML dintr-un program aplicație în apeluri de funcții standard ale limbajului gazdă și interacționează cu procesorul de interogare pentru a genera codul corespunzător.

Compilatorul DDL transformă instrucțiunile DDL într-un set de tabele ce conțin meta-datele. Tabelele sunt stocate în catalogul sistemului.

Administratorul de catalog gestionează accesul și întreținerea catalogului sistem. Catalogul sistemului este accesat de majoritatea componentelor sistemului de gestiune al bazei de date.

Una dintre cele mai importante funcții din cadrul sistemului de gestiune al bazelor de date o are administratorul bazei de date. Acesta păstrează interfața cu programele aplicație și interogările lansate de utilizatori.

Figura – Componentele administratorului bazei de date

Administratorul bazei de date – are una dintre cele mai importante funcții în cadrul unui SGBD. Principalele componente ale lui sunt prezentate mai sus. Aceste componente sunt:

Procesorul de interogare este folosit pentru a ușura și simplifica accesul la date. Acesta conține Evaluatorul de interogare care rulează fiecare interogare pe plan.

– Administratorul de date este folosit pentru a minimiza resursele necesare transferului de date dintre memoria internă și cea externă. Administratorul de date este un program care oferă o interfață între datele înmagazinate în baza de date și interogările formulate prin intermediul aplicațiilor. Conține următoarele componente:

– Controlul de autorizare care verifică dacă utilizatorul are dreptul de a efectua operația cerută.

Administratorul de fișiere.

Administratorul de buffer care răspunde de transferul datelor dintre memoria principală și dispozitivele de stocare secundare.

Administratorul de tranzacții este folosit pentru a controla atomicitatea și concurența tranzacțiilor în scopul păstrării consistenței și durabilității bazei de date. O tranzacție este o colecție de operații aplicate bazei de date care sunt efectuate toate deodată sub forma unei singure unități logice. Această componentă este alcătuită din administratorii de:

tranzacții.

blocare.

reconstituire – care garantează că baza de date rămâne într-o bună după ce a apărut o eroare. Este direct responsabil de refacerea sau anularea unei tranzacții.

2.4. Realizarea tabelelor în Access

Un tabel conține date despre un anumit subiect, cum ar fi turiști sau camere. Fiecare înregistrare dintr-un tabel conține informații despre un element, cum ar fi un anumit turist. O înregistrare este compusă din câmpuri precum numele, adresa, numărul de telefon al turistului, etc. O înregistrare este denumită în mod obișnuit rând, iar un câmp este denumit coloană. 5

Baza de date poate conține mai multe tabele, fiecare cu informații referitoare la un anumit subiect. Fiecare tabel poate conține mai multe câmpuri de diferite tipuri, inclusiv text, numere, date și imagini.

Următoarea listă afișează exemple obișnuite de tabele.

Un tabel Turiști care listează turiștii ce urmează să se cazeze și datele lor.

Un catalog de servicii pe care le oferă hotelul, inclusiv prețurile acestora.

Un tabel Camere și unul Tipuri_camere ce listtează numărul camerelor și tipul acestora.

Capitolul 3 – Proiectarea și realizarea aplicației

3.1. Funcționalitățile aplicației

Aplicația este proiectată să ofere mai multe funcționalități, cum ar fi:

– Introducere, modificare, ștergere și afișare date despre turiști

– Gestiune camere hotel

– Clasificare camere pe categorii (tipuri)

– Înregistrare comenzi de închiriere camere

– Gestiune servicii (introducere, modificare, ștergere, afișare)

– Înregistrare comenzi servicii

– Gestionare date de localizare a clienților prin tabele de orașe și țări

3.2. Actorii software

Pentru înțelegerea și definirea unui sistem, interacțiunea dintre sistem și utilizator este unul dintre importantele aspecte în înțelegerea și definirea cerințelor acestuia, pas important în construirea sistemului. 6

Actorii sunt reprezentați de utilizatori sau de entități care pot interacționa cu sistemul. Aceste entități pot fi o persoană, un program, o aplicație.

Rolurile principale apărute în cadrul sistemului aplicației realizate le dețin turistul, administratorul și recepționerul

Administratorul este cel care stă în spatele sistemului. Acesta gestionează toate datele care stau la baza funcționalității sistemului. Astfel, el se află în drepturi depline de a modifica date atât legate de funcționalitatea sistemului cât și date legate de informațiile presistente ale sistemului.

Turistul este cel care vine și solicită cazare la hotel sau este cel care poate face o rezervare sau poate contacta administratorul sau recepționerul. Pe durata sejurului, acesta de asemenea poate dispune de serviciile oferite de hotel, contra cost.

Recepționerul este cel care deține drepturi comune cu cele ale administratorului. Recepționerul poate modifica sau adăuga anumite date, informații, poate anula o cazare sau o rezervare, poate marca o rezervare ca fiind achitată, poate realiza el însuși rezervări.

3.3 Dezvoltarea bazei de date – ciclul de viață

Ciclul de viață al unei baze de date este setul de pași, tehnici, metode și instrumente utilizate pentru transpunerea modelului de date într-un model fizic. 7

3.3.1. Colectarea și analizarea cerințelor

Faza de analiză a cerințelor implică examinarea domeniului de interes ce urmează a fi modelat, intervievarea beneficiarului bazei de date, obținerea de informații despre sisteme asemănătoare, analiza cerințelor de dezvoltare viitoare și obținerea de informații despre întregul domeniu luat în ansamblu.

Colectarea și analiza este o etapă extrem de importantă în proiectarea unei baze de date efectuate pentru a:

dezvolta și înțelege sistemul ce urmează a fi creat;

dezvolta și înțelege domeniul de interes ce urmează a fi modelat;

construi un sistem nou;

reevalua un proces;

instrui utilizatorii și managerii;

comunica modul de funcționare a sistemului;

evalua controlul.

Managerii, proiectanții și consultanții folosesc o serie de tehnici de creare a diagramelor și graficelor. Unele dintre cele mai folosite sunt:

Diagrame de conținut – prezintă în mod simplificat felul în care un proces intră în legătură cu entități aflate în afara procesului.

Diagrame logice de flux de date – prezintă reprezentarea logică a procesului. Sunt descrieri abstracte care nu specifică nici cine efectuează o anumită activitate și nici locul în care se află anumite elemente. Dacă subprocesul nu este elementar, acesta poate fi descompus sau partiționat. Astfel de diagrame se modifică foarte rar.

Diagrame fizice de flux de date – prezintă atributele fizice ale procesului. Nu prezintă atributele logice ale procesului. Ele se pot modifica relativ des și nu pot fi descompuse.

Schema logică a sistemului – prezintă prelucrarea informațiilor (intrări, ieșiri, înmagazinarea datelor, activități, fluxuri logice) și procesele operaționale (entități, fluxuri fizice, operații). Aceasta este cea mai veche tehnică.

Diagrama entitate-relație.

3.3.2. Definirea sistemului

Definirea sistemului reprezintă identificarea scopului și a limitelor bazei de date. Sunt prezentate cele mai multe dintre vederile utilizatorilor. 8

În scopul ușurării utilizării trebuie să se definească:

care este utilizatorul final care efectuează tranzacții și pune întrebări;

ce tip de interfață grafică se utilizează:

grafică;

tip SQL;

formulare;

utilizează meniuri;

generatoare de rapoarte;

viewurile utilizate;

analiză a activităților;

resursele folosite:

software

hardware;

umane;

alte baze de date;

procese;

metode și tehnici de refacere și arhivare:

refacerea se efectuează în timp ce funcționează sistemului;

dimensionarea back-up-ului;

strategia de stocare și arhivare;

aspectele legate de securitatea sistemului:

folosirea de parole;

permisiuni.

Etapele proiectării

Proiectarea unei baze de date este un proces ce implică dezvoltarea și rafinarea structurii unei baze de date pe baza cerințelor date de către beneficiarul bazei de date și a cerințelor extrase pe baza analizei domeniului de modelat.

Principalul obiectiv urmărit la proiectare este asigurarea integrității, consistenței și preciziei tuturor datelor. Dacă proiectul unei baze de date nu este corect, atunci este foarte dificil a se extrage informațiile dorite, fiind probabilă obținerea de date eronate. În scopul obținerii unui proiect corect al unei baze de date trebuie avute în vedere câteva obiective, cum ar fi următoarele:

baza de date trebuie să păstreze datele minime necesare obținerii de informații descrise în faza de analiză a cerințelor precum și orice interogare ce poate fi pusă la un moment dat de către utilizator;

tabelele trebuie să fie construite corect și eficient; fiecare tabel din baza de date reprezentând o singură entitate și fiind compus din câmpuri distincte, păstrând o redundanță minimă a datelor, fiecare înregistrare dintr-un tabel putând fi identificată cu ajutorul unei valori unice;

integritatea datelor se impune la nivel de tabel, câmp, relație; aceste nivele de integritate ajută la garantarea faptului că structurile de date împreună cu valorile acestora sunt valide și precise în orice moment;

baza de date trebuie să suporte regulile specifice domeniului pe care îl modelează; datele trebuie să ofere informație validă și precisă, având tot timpul înțeles;

la proiectarea bazelor de date trebuie să se prevadă dezvoltările viitoare; structura bazei de date trebuie să fie ușor de modificat sau extins odată cu modificarea cerințelor impuse.

Este dificil de realizat toate aceste obiective permanent, dar un proiect corect al unei baze de date trebuie să aibă în vedere obținerea cât mai rapidă a rezultatelor. Aplicarea tehnicilor de proiectare conduce la obținerea următoarelor beneficii:

structura bazei de date este ușor de modificat și gestionat deoarece modificările efectuate asupra unui câmp sau tabel nu afectează alte câmpuri sau tabele ale bazei de date;

datele sunt ușor de editat deoarece modificarea valorii unui câmp dintr-un tabel nu afectează valorile altor câmpuri din același sau alte tabele ale bazei de date; mai mult decât atât, o proiectare corectă a unei baze de date va duce la păstrarea unei redundanțe minime a datelor;

informațiile sunt ușor de extras deoarece se pot crea cu ușurință interogări dacă tabelele sunt corect alcătuite iar relațiile sunt stabilite în mod corespunzător;

aplicațiile create de utilizator sunt ușor de proiectat și gestionat.

3.3.3. Planificarea bazei de date

Planificarea bazei de date este controlul activităților ce permit realizarea efectivă și eficientă a etapelor de proiectare a unei baze de date. În acest scop se realizează următoarea documentație:

identificarea scopului bazei de date;

obiectivele bazei de date (identificarea fiecărei activități individuale ce trebuie suportată de baza de date);

Proiectarea bazei de date cuprinde următoarele trei etape:

proiectarea conceptuală a bazei de date;

proiectarea logică a bazei de date;

proiectarea fizică a bazei de date.

Cele mai des întâlnite tehnici de creare a diagramelor și graficelor sunt:

Diagrame de conținut – prezintă în mod simplificat felul în care un proces intră în legătură cu entități aflate în afara procesului.

Diagrame logice de flux de date – prezintă reprezentarea logică a procesului. Sunt descrieri abstracte care nu specifică nici cine efectuează o anumită activitate și nici locul în care se află anumite elemente. Dacă subprocesul nu este elementar, acesta poate fi descompus sau partiționat. Astfel de diagrame se modifică foarte rar.

Diagrame fizice de flux de date – prezintă atributele fizice ale procesului. Nu prezintă atributele logice ale procesului. Ele se pot modifica relativ des și nu pot fi descompuse.

Schema logică a sistemului – prezintă prelucrarea informațiilor (intrări, ieșiri, înmagazinarea datelor, activități, fluxuri logice) și procesele operaționale (entități, fluxuri fizice, operații). Aceasta este cea mai veche tehnică.

Diagrama Entitate-Asociere / Relație (ERD – Entity Relationship Diagram)

Colectarea și analiza este o etapă extrem de importantă în proiectarea unei baze de date efectuate pentru a:

dezvolta și înțelege sistemul ce urmează a fi creat;

dezvolta și înțelege domeniul de interes ce urmează a fi modelat;

construi un sistem nou;

reevalua un proces;

instrui utilizatorii și managerii;

comunica modul de funcționare a sistemului;

evalua controlul.

3.3.4. Restricții de integritate

Restricțiile de integritate definesc condiții pe care trebuie să le satisfacă datele din baza de date, pentru a fi considerate corecte, coerente în raport cu lumea reală la care se referă. Restricțiile de integritate este principalul mod de integrare a semanticii datelor în cadrul modelului relațional al datelor, mecanismele de definire și verificare a acestor restricții reprezentând principalele instrumente pentru controlul semantic al datelor. Există două tipuri de restricții, și anume restricții structurale care sunt inerente modelării datelor și restricții de funcționare (comportament) care sunt specifice unei anumite baze de date. Restricțiile structurale sunt de patru tipuri: de cheie, de referință, de entitate și de dependență între date, din care primele trei, constituie mulțimea minimală de restricții de integritate pe care trebuie să le respecte un SGBD relațional. Aceste restricții sunt definite în raport de noțiunea de cheie a unei relații.

Cheia este o mulțime minimală de atribute ale căror valori identifică în mod unic un tuplu într-o relație.

Fiecare relație are cel puțin o cheie. Cheia primară este utilizată pentru a identifica în mod unic o instanță particular a unei entități. Aceasta poate fi reprezentată de unul sau mai multe attribute. Trebuie sa fie unică în domeniul său, valorile sale neschimbăndu-se niciodată.Dacă există mai multe chei primare posibile, ele se numesc chei candidat. Una din cheile candidat va fi aleasă de administratorul bazei de date pentru a identifica efectiv tupluri și ea va primi numele de cheie primară. Cheia primară nu poate fi reactualizată. Restul cheilor vor purta numele de chei alternative sau alternate.

Atributele care reprezintă cheia primară pot fi subliniate sau urmate de semnul în schema relației respective. Un grup de atribute din cadrul unei relații care conține o cheie a relației se numește supercheie.

Restricții de funcționare

Prețul standard al camerei trebuie să fie pozitiv.

Prețul pe zi al unei camera comandate trebuie să fie pozitiv

Data de rezervare a unei camere trebuie să fie înaintea sau cel mult în aceeași zi cu data de

sosire.

Data de plecare trebuie să fie după data de sosire.

Discountul trebuie sa fie pozitiv sau 0.

Prețul standard al unei servicii trebuie să fie pozitiv.

CNP-ul trebuie sa aibe 13 cifre.

Data de rezervare a unui serviciu trebuie să fie înaintea sau cel mult în aceeași zi cu data

serviciului.

Cantitatea trebuie să fie pozitivă.

3.3.5. Analiza bazei de date – Modelul conceptual

Modelul conceptual utilizează o serie de noțiuni, cum ar fi entitate, relație și atribut, pentru a descrie modul în care este recepționată de către utilizator funcționalitatea ce urmează a fi implementată în cadrul unei baze de date a unei aplicații. 9

Faza de analiză a cerințelor implică examinarea domeniului de interes ce urmează a fi modelat, intervievarea administratorului bazei de date, obținerea de informații despre sisteme asemănătoare, analiza cerințelor de dezvoltare viitoare și obținerea de informații despre întregul domeniu luat în ansamblu.

Modelul conceptual al aplicației este:

3.3.6. Diagrama Entitate-Asociere (ERD – Entity Relationship Diagram)

Modelul Entitate-Asociere este un instrument pentru analiza acelor aspecte semantice ale unei aplicații, care sunt independente de evenimente. Modelul Entitate-Asociere reduce redundanța datelor.

Diagrama Entitate-Asociere furnizează o metodă eficientă pentru vizualizarea legăturilor între entități, pentru o aplicație dată. Acest instrument s-a dovedit util pentru a face tranziția de la descrierea unei aplicații la o schemă formală a bazei de date. Modelul Entitate-Asociere este astfel realizat fără a fi necesară atenția asupra proiectării fizice a bazei de date. Diagramele Entitate-Asociere sunt ulterior transformate într-o schemă conceptuală în unul din modelele în care baza de date se va implementa efectiv.

Mai jos este elaborată diagrama cu entitățile și atributele fiecareia. Entitățile sunt Turiști, Rezervări, Camere, Tipuri camere, Servicii, Comenzi servicii, Orașe, Țări, iar atributele sunt enumerate în schemă.

În continuare sunt prezentate definițiile unor termeni de bază utilizați pentru descrierea conceptelor importante ale modelului Entitate-Asociere

Entitate – o entitate este un obiect concret sau abstract care poate fi clar

delimitat în mediu.

Instanța de entitate – O instanță de entitate este o apariție

particulară a unei entități.

Tip de entitate – Un grup de entități similare poartă numele de clasă de entități sau tip de entitate. O clasă de entități are proprietăți comune.

Atribute Atributele descriu proprietățile entităților și relațiilor și pot fi:

Simple (scalare) – sunt cele mai mici unități semantice de date, atomice (fără structură internă);

Compuse – sunt grupuri de atribute privite unitar;

Multievaluate (liste) – sunt valori multiple;

Calculat (cu valoare calculată) – folosesc alte atribute și se generează în urma interogărilor;

Domeniile sunt mulțimile de definiție ale atributelor:

Mulțimi precizate de valori scalare de același tip

Mulțimi de valori posibile

Asocierea entităților este un raport care există între entități reprezentate de verbe, dar nu orice verb din asociere. Între 2 entități pot exista mai multe asocieri, dar nu cu același verb. Caracteristica esențială a asocierii o reprezintă relația.

Relația este o legătură între două clase de entitate. Gradul unei relații indică numărul de entități implicate în relație. Cardinalitatea unei relații indică numărul de din clasa de entități E1 care poate sau trebuie asociată cu instanțe din clasa de entități E2.

Tipuri de relații :

Relația UNU-LA-UNU – Pentru fiecare entitate dintr-o clasă există cel mult o entitate asociată în cealaltă clasă.

Relația UNU-LA-MULȚI – O entitate din clasa E2 este asociată cu zero sau mai multe entități din clasa E1, dar fiecărei entități din E1 I se asociază cel mult o entitate în E2.

Relația MULȚI-LA MULȚI – Nu există restricții asupra numărului de entități dintr-o clasă ce pot fi asociate cu o entitate din cealaltă clasă.

Opționalitatea relației este proprietate a celor două părți ale unei relații dintre entitățile E1 și E2, care exprimă câte dintre instanțele entității E1 pot sau trebuie să se asocieze instanțelor entității E2 și reciproc.

Să considerăm entitățile TURIST și CAMERĂ, care intervin în gestionarea datelor

hotelului. Numele acestei relații este rezervarea. Pentru a stabili opționalitatea relației trebuie să răspundem la următoarea întrebare: Un turist poate rezerva mai multe camera? Se poate ca un turist să nu poată rezerva nici o cameră? Dacă acceptăm că toți turiștii trebuie să rezerve cel puțin o cameră, relația este obligatorie sau mandatorie și vom spune:

Un turist trebuie să rezerve o cameră.

Cardinaliatea relației este dată de numărul de instanțe ale entității din partea dreaptă a relației care pot intra în relație cu o instanță a entității din partea stăngă a relației. Adică va trebui să răspundem la întrebări de genul: Câte camere poate rezerva un turist? Răspunsul este: “Un turist poate rezerva mai multe camera.”

Relația Turist – Cameră este o relație de tipul “1 la M”. Un turist poate rezerva mai multe camere.

Relația Cameră – Turist este o relație de tipul “1 la M”. O cameră poate fi rezervată de mai mulți turiști în perioade diferite (care nu se suprapun).

Aceleași etape le-am parcurs și pentru restul entităților și raspunsurile finale sunt următoarele:

Entitățile TURIST- SERVICII

Relația Turist – Servicii este o relație de tipul ”1 la M”. Un turist poate dispune de mai multe servicii.

Relația Servicii – Turist este o relație de tipul “1 la M”. Un serviciu poate fi comandat de mai mulți turiști.

Entitățile TURIST-ORAȘE

Relația Turist – Orașe este o relație de tipul “1 la 1”. Un turist poate proveni dintr-un singur oraș

Relația Orașe – Turist. Este o relație de tipul “1 la M”. Într-un oraș pot locui mai mulți turiști.

Entitățile TIP CAMERĂ- CAMERĂ

Relația Tip cameră – Cameră. Este o relatie de tipul “1 la M”. Un tip de cameră poate fi atribuit mai multor camere.

Relația Cameră- Tip cameră. Este o relatie de tipul “1 la 1”. O cameră poate fi de un singur tip.

Entitățile ȚARĂ – ORAȘE

Relația Țară – Orașe. Este o relație de tipul “1 la M”.. O țară conține mai multe orașe.

Relația Orașe- Țări. Este o relație de tipul “1 la M”. Un oraș aparține unei singure țări

3.3.7. Proiectarea bazei de date – Modelul logic

Proiectarea logică este procesul de constituire a unui model al informațiilor folosit la modelarea unui domeniu de interes bazat pe un anumit model specific de date (de exemplu, modelul relațional), dar independent de orice alte considerații fizice. 10

Proiectarea logică a bazei de date ajută în continuare la definirea și achiziționarea cerințelor. Proiectarea logică a bazei de date presupune descrierea fiecărui element de informație și a relațiilor dintre aceste elemente de informație. Un model logic poate determina dacă proiectul conține toate informațiile ce trebuie să fie extrase și reflectă relațiile necesare care se pun în concordanță cu regulile domeniului de interes. Modelul logic al bazei de date descrie dimensiunea, forma sistemelor necesare bazei de date și arată necesitățile informaționale și operaționale ale domeniului de interes.

Fleming von Halle, în lucrarea “Handbook of Relational Database Design”, propune următorii pași ce trebuie urmați pentru crearea unui model logic:

definirea tabelelor în funcție de cerințele specifice domeniului pe care îl modelează (așa cum s-a stabilit în modelul conceptual);

determinarea relațiilor dintre tabele;

determinarea conținutului (coloanelor) fiecărui tabel;

normalizarea tabelelor până, la cel puțin, forma normală trei;

determinarea cheilor primare;

determinarea valorilor specifice fiecărei coloane.

Având toate informațiile prezentate anterior, am realizat schema următoare ce conține entitățile, relațiile împreună cu opționalitatea acestora.

Se cazează/rezervă camere

1 1

M 1

1 Oferă M 1 Camerele sunt 1

de mai multe tipuri

1 M

M

Rezervă

1 M

M 1

1 Locuiește M 1 1

M 1 M 1

Un tabel relațional este o colecție de rânduri, în care fiecare rând are aceleași coloane. Se recomandă acordarea numelor tabelelor conform regulilor stabilite, ținându-se cont de normele de abreviere și de sinonime.

Figura 2. Crearea modelului logic (D – date; R – reguli)

O coloană relațională este o dată din cadrul unui tabel. Numele unei coloane trebuie să fie unic în cadrul tabelului și poate fi identic cu atributul pe care îl reprezintă.

Pasul Definirea regulilor entității este împărțit în pași mai mici prin care este posibil să se stabilească reguli ale entităților, a relațiilor dintre ele, precum și a atributelor lor.

Oferirea de suport pentru relațiile regulilor de domeniu înseamnă păstrarea celor mai apropiate legături dintre cheile primare și cele externe, ceea ce este cunoscut sub denumirea de integritate referențială.

Ultimul pas, Definirea regulilor atributelor se referă la inserarea și actualizarea operațiilor, cum ar fi:

introducerea de constrângeri opționale sau obligatorii (sunt permise valorile NULL);

domeniul de valori, sau valorile discrete;

valorile implicite;

constrângerea de unicitate a atributelor.

După încheierea definițiilor tabelelor este obligatorie reluarea discuțiilor cu beneficiarul bazei de date pentru a revedea întreaga activitate desfășurată.

Pe parcursul desfășurării acestor discuții:

trebuie să se obțină asigurarea că în baza de date sunt reprezentate cele mai importante entități;

trebuie să se obțină asigurarea că denumirile tabelelor și descrierile acestora sunt potrivite și ușor de înțeles;

trebuie să se obțină asigurarea că denumirile câmpurilor sunt potrivite și ușor de înțeles;

trebuie să se facă verificarea că toate câmpurile aparțin tabelelor corespunzătoare.

3.3.8. Implementarea bazei de date – Modelul fizic

Proiectarea fizică este procesul de descriere a implementării bazei de date pe mediile secundare de stocare. Sunt descrise structurile de stocare și metodele de acces utilizate pentru a obține un acces eficient la date. 11

Proiectul fizic al bazei de date efectuează și o rafinare a modelului logic; acesta transpune modelul logic într-un sistem relațional de gestiune a bazelor de date. În această fază este obligatorie examinarea modului în care utilizatorul accesează baza de date. Se recomandă separarea modelului logic de modelul fizic astfel încât modificările să poată fi documentate în conformitate cu modelul fizic pentru a corespunde constrângerilor. În acest fel, modelul logic rămâne independent de tehnologie, ținând cont doar de cerințele specifice domeniului pe care îl modelează.

Acest pas din cadrul procesului de proiectare implică determinarea următoarelor categorii de informații:

datele folosite în mod curent;

coloanele ce urmează a fi indexate pentru a obține un acces mai rapid la date;

spațiul necesar precum și cel prevăzut pentru creșterea dimensiunilor bazei de date;

dacă denormalizarea bazei de date va duce la creșterea performanțelor acesteia;

cereri de funcționalitate:

procesarea secvențială a tuplurilor;

tuplurile ce îndeplinesc o anumită condiție impusă prin intermediul unei valori;

tuplurile inserate sau eliminate;

obiective de performanță:

evitarea pierderii inutile de spațiu;

primirea într-un timp cât mai scurt a răspunsului.

O bază de date relațională constă din două părți importante:

dicționarul de date care descrie datele;

fișierele de date ce conțin datele fizice.

Fleming von Halle, în lucrarea sa “Handbook of Relational Database Design”, propune pașii necesari creării modelului fizic, așa cum se poate observa din figura de mai jos:

D – date; P – proces

O structură de stocare este o implementare a tabelelor și coloanelor în cadrul unui sistem specific de gestiune a bazelor de date. Opțiunile tipice de implementare presupun luarea unor decizii referitoare la:

transformarea tabelelor în fișiere;

spațiul liber;

transferul tabelelor în bazele de date;

blocări;

ordinea coloanelor.

Aceste considerații pot diferi considerabil de la un sistem de gestiune a bazelor de date la altul. Pasul Analizarea evenimentelor existente în baza de date este împărțit în șapte subpași, după cum urmează:

revizuirea evenimentelor înlănțuite prin modelul logic;

alcătuirea unei liste de priorități a evenimentelor pentru a înțelege importanța acestora;

identificarea regulilor care se aplică celor mai importante evenimente;

identificarea criteriilor de căutare pe baza cărora se accesează tabelul, în cazul fiecărui eveniment sau tabel accesat;

identificarea cerințelor de sortare pe baza cărora se accesează tabelul, în cazul fiecărui eveniment sau tabel accesat;

identificarea coloanelor destinație pe baza cărora se accesează tabelul, în cazul fiecărui eveniment sau tabel accesat;

estimarea numărului de rânduri căutate raportate la numărul total de rânduri din tabel pe baza cărora se accesează tabelul, în cazul fiecărui eveniment sau tabel accesat;

O cale de acces este o procedură logică pe baza căreia un sistem de gestiune a bazelor de date poate selecta anumite rânduri, poate obține coloanele cerute, prelucrând acele coloane și rânduri în maniera corespunzătoare.

Opțiunile de reglare invizibilă sunt acele opțiuni care sunt transparente utilizatorilor și programatorilor. În cele mai multe sisteme de gestiune a bazelor de date opțiunile invizibile pe care le poate regla proiectantul se referă la scanări, ordinea rândurilor în tabele, indexarea coloanelor.

O structură vizibilă de date este acea structură palpabilă utilizatorilor sau programatorilor. Reglarea unei structuri vizibile de date constă din modificarea structurii datelor astfel încât acestea s-ar putea să nu mai corespundă modelului logic. Cele mai obișnuite modalități de reglare a structurilor vizibile de date sunt:

stocarea coloanelor ce sunt copii exacte ale altor coloane;

stocarea coloanelor cu ajutorul cărora se efectuează calcule pe baza unei formule;

stocarea coloanelor ce se obțin prin deducție (cu ajutorul unei reguli).

3.3. Structura tabelelor

Baza de date a aplicației are următoarele tabele:

Camere

Comenzi camere

Comenzi servicii

Orașe

Servicii

Țări

Tipuri camere

Turiști

Crearea tabelului CAMERE se face prin definirea următoarelor câmpuri:

Această tabelă are ca și cheie primară coloana Nr, numărul camerei, care trebuie să fie unic. El nu este Autonumber, pentru a permite administratorului să introducă numărul real al camerei.

Tabela Comenzi camere conține următoarele câmpuri:

Această tabelă are coloana Id ca și cheie primară de identificare unică a fiecărui rând. Ca logică există și combinația Nr_camera + Id_turist + Data_sosire ca și cheie primară, întrucât un turist nu poate închiria aceeași cameră în aceeași zi.

Tabela Rezervări cuprinde:

Această tabelă are ca și cheie primară coloana Id_comanda_serviciu de identificare unică a fiecărui rând și combinația id_turist + id_serviciu + data_serviciu, întrucât un turist nu poate comanda același serviciu în aceeași zi, acastă situație fiind rezolvată cu ajutorul câmpului de cantitate.

Tabela Orașe:

Această tabelă are ca și cheie primară coloana id_oras. Câmpul id_tara este cheie externă și face legătura cu tabela de țări.

Tabela Servicii:

Această tabelă are ca și cheie primară coloana id_serviciu.

Tabela Țări:

Această tabelă are ca și cheie primară coloana id_tara.

Tabela Tipuri camere:

Această tabelă are ca și cheie primară coloana id_tip_camera.

Tabela Turiști:

Această tabelă are ca și cheie primară coloana id_turist. Câmpul id_oras este cheie externă și face legătura cu tabela de orașe.

3.4. Schema bazei de date

În urma analizei efectuate s-a proiectat baza de date cu următoarea structură:

3.5. Exemple de date din tabele

În următoarele rândurisunt prezentate exemple de câteva date aflate în fiecare tabel din baza de date a hotelului.

Tabela Camere

Tabela Comenzi camere

Tabela Comenzi servicii

Tabela Orașe

Tabela Servicii

Tabela Turiști

Tabela Țări

Tabela Tipuri camere

3.6. Interogări

3.6.1. Folosirea interogărilor SQL în cadrul aplicației

SQL este un limbaj de interogare extrem de performant, datorită avantajului oferit de prelucrarea pe seturi de înregistrări. Totuși, el nu poate oferi procedurile necesare efectuării unei serii de activități și acțiuni, cum ar fi: crearea de interfețe grafice prietenoase, crearea și imprimarea de rapoarte, interacțiuni cu alți utilizatori, transferul datelor între baza de date și aplicații. Din acest motiv este necesară folosirea unui limbaj de programare din generația a treia care să realizeze conexiunea cu baza de date și să efectueze sarcini dintre cele arătate anterior. 12

Componenta dinamică SQL permite crearea și folosirea de interogări SQL care să se modifice în timpul rulării aplicațiilor.

3.6.2. Limbajul de manipulare a datelor

Asigură un set de procedee ce permit operații de bază pentru manipularea datelor din baza de date. Limbajul de manipulare a datelor asigură o colecție de operatori ce pot fi aplicați pentru a valida instanțele tipurilor de date în cadrul schemei și de a crea, modifica sau extrage astfel de instanțe. Cu ajutorul acestor operatori se pot efectua următoarele operații:

Regăsirea datelor din baza de date (operație principală).

Inserarea de date noi în baza de date.

Modificarea datelor existente.

Ștergerea de date din baza de date.

Există două tipuri de limbaje de manipulare a datelor:

Limbaje de manipulare a datelor procedurale (specific modelelor rețea și ierarhic)

care permit utilizatorului să comunice sistemului ce date sunt necesare și cum pot fi ele exact regăsite. Aceste limbaje prelucrează informația înregistrare cu înregistrare.

Limbaje de manipulare a datelor neprocedurale (specifice modelului relațional) care

permit utilizatorului să comunice sistemului ce date sunt necesare fără a specifica cum se regăsesc datele. Aceste limbaje prelucrează informația pe seturi de înregistrări și au următoarele caracteristici:

conferă o mai mare independență de date;

cresc viteza de prelucrare a informației;

Exemple de astfel de limbaje ce aparțin generației a patra sunt:

limbajul SQL;

generatoare de formulare;

generatoare de rapoarte;

generatoare grafice;

generatoare de aplicații.

3.6.3. Extragerea informațiilor din bazele de date

Limbajul de manipulare a datelor permite extragerea datelor dintr-o bază de date. Structura de bază a unei expresii SQL constă din folosirea clauzelor SELECT, FROM și WHERE.

SELECT este o clauză ce utilizează o listă a atributelor ce urmează a fi prezentate utilizatorului și care corespunde operației de proiecție din algebra relațională.

FROM este o clauză ce corespunde produsului cartezian din algebra relațională și în care se introduc relațiile din care urmează a fi extrase atributele ce apar în clauza SELECT.

WHERE este o clauză ce corespunde predicatului de selecție din algebra relațională.

În mod obișnuit o interogare se prezintă sub forma:

SELECT A1;A2; : : :;An FROM r1; r2; : : :; rm WHERE P

În care fiecare AI reprezintă un atribut, fiecare ri reprezintă o relație, iar P este un predicat, ceea ce este echivalent expresiei:

A1;A2;:::;An (_P (r1 _ r2 _ : : :_rm))

Dacă se omite clauza WHERE, predicatul P are valoarea True. Lista atributelor poate fi înlocuită printr-un caracter * pentru a le alege pe toate. Prin intermediul SQL se alcătuiește produsul cartezian pe baza relațiilor precizate, se poate efectua o selecție cu ajutorul unui predicat, după care se poate face o proiecție pe anumite atribute. Rezultatul unei interogări SQL este tot o relație și, în mod implicit, înregistrările duplicat nu sunt eliminate. În lista de selecție se pot afla și operații aritmetice.

Clauza WHERE

Predicatele pot avea orice grad de complexitate și pot implica:

conexiuni logice de tip “and”, “or”, sau “not”;

expresii aritmetice ce conțin constante sau valori ale tuplurilor;

operatorul “between” folosit pentru definirea domeniilor de valori ale variabilelor.

Clauza FROM

Clauza FROM în sine, definește un produs cartezian calculat pe baza relațiilor care sunt specificate în cadrul acesteia. SQL nu oferă echivalentul joncțiunii naturale, dar aceasta poate fi exprimată cu ajutorul unui produs cartezian urmate de operațiile de selecție și proiecție. Variabilele, care în SQL sunt reprezentate de tuplurile relațiilor, se definesc în clauza FROM, putând fi folosite în cadrul expresiilor.

În urma acestora, voi da ca și exemple interogările aflate în baza de date hotel. Pentru început, legat de tabela Camere avem următoarea interogare:

SELECT Nr, Etaj, Nume_tip_Camera FROM Camere INNER JOIN Tipuri_camere ON camere.id_tip_camera=Tipuri_camere.id_tip_camera ORDER BY Nr;

Această interogare afișează din tabela Camere cuplată cu tabela Tipuri_camere, numărul, etajul și tipul camerei.

Următoarea interogare din baza de date este legată de tabela Comenzi_servicii.

SELECT comenzi_servicii.id_comanda_serviciu, turisti.nume, turisti.prenume, servicii.nume_serviciu, servicii.pret_standard, comenzi_servicii.data_rezervare, comenzi_servicii.data_serviciu, comenzi_servicii.pret, comenzi_servicii.cantitate

FROM (turisti INNER JOIN comenzi_servicii ON turisti.id_turist = comenzi_servicii.id_turist) INNER JOIN servicii ON comenzi_servicii.id_serviciu = servicii.id_serviciu;

Această interogare afișează numele, prenumele turistului și serviciul cerut din cadrul hotelului. Datele sunt luate din tabela Turiști reunită cu tabela Comenzi_servicii. De asemenea, interogarea mai afișează prețului standard al fiecărui service cerut, data rezervării serviciului și data în care a fost oferit serviciul și, desigur, cantitatea și prețul total.

Interogarea din baza de date legată de tabela Orașe afișează prin reuniunea cu tabela Țări, fiecare oraș cărei țari îi aparține.

SELECT Orase.Id_oras, Orase.Nume_oras, Tari.Nume_tara

FROM Tari INNER JOIN Orase ON Tari.Id_tara=Orase.Id_tara;

Interogarea qRezervari

Interogarea legată de tabela Rezervări stochează datele fiecărui turist care face o rezervare sau care urmează să se cazeze. Astfel, ceea ce ne oferă următoarea interogare este numele și prenumele turistului, numărul de telefon și numărul de persoane care se vor caza. De asemenea mai avem aici și date despre data rezervării, ziua sosirii și ziua plecării, prețul pe zi al camerei comandate, discountul oferit de hotel acestuia și totalul zilelor de sejur așezate în ordinea crescătoare după numărul camerei.

SELECT Id, Nr_camera, [Rezervari].id_turist, nume, prenume, telefon, numar_persoane, data_sosire, data_plecare, data_rezervare, pret_zi, discount, DateDiff("d",data_sosire,data_plecare) AS zile_sejur

FROM Rezervari INNER JOIN turisti ON [Rezervari].id_turist=turisti.id_turist

ORDER BY Nr_camera;

Interogarea qRezervari_total plata

SELECT id_turist, nume, prenume, SUM(zile_sejur) AS total_zile_sejur, SUM(zile_sejur*pret_zi) AS total_pret_sejur

FROM qRezervari GROUP BY id_turist, nume, prenume ORDER BY nume, prenume;

Este legată de tabela Rezervări afișează numele și prenumele turistului, numărul total de zile în care a fost cazat la hotel și totalul de plată pe acest număr de zile

.

Interogarea Qservicii

Afișează numele serviciilor oferite de hotel și prețul standard al acestora. Pentru aceasta s-au extras datele din tabela Servicii și s-a folosit următoarea instrucțiune:

SELECT nume_serviciu, pret_standard FROM servicii;

Interogarea qTuristi

Pentru a avea și o evidență a datelor despre turiștii ce se vor caza în hotel, am făcut o interogare care extrage date din tabela Turiști și din tabela Orașe, care să îmi afișeze numele și prenumele acestora, CNP-ul, nr. de telefon, email-ul, adresa, tipul actului cu care s-a legitimate și numărul acestuia, și desigur, orașul de proveniență. Am vrut ca datele personale ale turiștilor sa fie așezate în ordine crescătoare după nume pentru a ușura munca recepționerului. Pentru aceasta am scris următoarea instrucțiune:

SELECT Id_turist, Nume, Prenume, CNP, Telefon, Email, Adresa, Nume_oras, Tip_act, Serie, Numar FROM Turisti INNER JOIN Orase ON Turisti.Id_oras=Orase.Id_oras

ORDER BY nume, prenume;

Interogarea următoare legată tot de Turiști imi arată totalul zilelor de sejur al acestora, pretul pe zi afișat în funcție de camera pe care au comandat-o și discountul făcut de hotel acestuia din diferite motive. De asemenea afișează numele și prenumele turistului, numărul de telefon, numărul de persoane cazate, data sosirii și data plecării și desigur, și data rezervării. Pentru aceasta s-a folosit următoarea instrucțiune:

SELECT Id, Nr_camera, [Rezervari].id_turist, nume, prenume, telefon, numar_persoane, data_sosire, data_plecare, data_rezervare, pret_zi, discount, DateDiff("d",data_sosire,data_plecare) AS zile_sejur FROM Rezervari RIGHT JOIN turisti ON [Rezervari].id_turist=turisti.id_turist ORDER BY Nr_camera;

3.7. Implementarea

Implementarea reprezintă realizarea fizică a bazei de date și a aplicațiilor care folosesc baza de date. Implementarea bazei de date se poate face folosind:

limbajul de definire a datelor existent în cadrul sistemului de gestiune a bazelor de date;

o interfață grafică cu utilizatorul.

Instrucțiunile limbajului de definire a datelor crează structura bazei de date și fișierele bazei de date. Programele aplicație sunt implementate cu ajutorul limbajului de manipulare a datelor și, posibil, cu ajutorul unui limbaj gazdă de programare cu ajutorul căruia se creează ecrane, meniuri, formulare și rapoarte pe de o parte, iar pe de altă parte se introduc elementele de control a securității și integrității datelor.

Aplicația a fost realizată folosind facilitățile oferite Microsoft Access de creare a tabelelor, interogărilor, formelor și rapoartelor. Așa cum se știe, Access crează un singur fișier conținând toate aceste component pentru o bază de date. Prin urmare, în situația actual, implementarea este reprezentată de copierea acestui fișier pe unitatea de lucru a beneficiarului și stabilirea drepturilor de acces ale acestuia.

4. Manual de utilizare a aplicației

4.1. Forma principală și design-ul

Interfața grafică de care va dispune recepționerul hotelului arată în felul următor:

Butoanele aflate pe partea stângă apelează comenzi de introducere a datelor, iar butoanele din partea dreaptă evidențiază rapoarte necesare în administrarea datelor.

4.2. Introducerea datelor cu ajutorul formularelor

Formularele sunt denumite "ecrane de introducere de date". Ele reprezintă interfața pe care o utilizăm pentru a lucra cu date și conțin deseori butoane de comandă care efectuează diverse comenzi. Majoritatea utilizatorilor apelează la formulare pentru vizualizarea, introducerea și editarea datelor din tabele.

Formularele oferă un format ușor de folosit pentru lucrul cu date și se pot adăuga elemente funcționale, cum ar fi butoanele de comandă.

Formularele permit, de asemenea, să se controleze modul în care utilizatorii interacționează cu datele din baza de date. De exemplu, avem posibilitatea să creăm un formular care afișează numai anumite câmpuri și permite efectuarea numai a anumitor operațiuni. Astfel, se protejează datele și se asigură faptul că aceastea sunt introduse corect.

Formularul Comenzi de servicii

În formularul Comenzi servicii, utilizatorul, atunci când un serviciu este cerut de către un turist, poate introduce în baza de date noua comandă, prețul, cantitatea și data în care a fost cerută. În rubrica Id turist, butonul combo box ne afișează toate datele turiștilor, iar butonul combo box din rubric Id serviciu, ne afișează toate serviciile oferite de hotel.

Formularul Date camera

Acest formular ne permite să intorducem date legate de fiecare cameră și să fcem modificări în legătura cu tipul acesteia, prețul sau adăugarea sau eliminarea de facilități incluse.

Formularul Date despre turiști

În cazul în care dorim să introducem cu ușurința date despre fiecare turist în parte, dorim să modificăm, aceste formular este foarte eficient, deoarece ușurează munca utilizatorului și protejează restul datelelor.

Formularul Orașe turiști

Acest formular ajută la adăugarea de orașe în cazul în care unul din orașele prezente deja în baza de date cu coincide cu orașul noului client.

Formularul Rezervări

Formularul Rezervări este bine structurat astfel încât să se poată efectua cu ușurință o nouă rezervare a unei camere din hotel.

Formularul Țări turiști

Asemeni formularului Orașe turiști, putem introduce de la tastatură o nouă țară care nu se află prezenta în baza de date.

Formularul Tipurile de camera

În acest formular, în cazul în care în hotel s-au făcut modificări în legătură cu tipul camerelor, putem schimba cu ușurință numele tipului de cameră, ca de exmplu camera Single o putem modifica ca fiind camera Dublă.

4.3. Afișarea datelor cu ajutorul rapoartelor

Rapoartele se utilizează pentru sintetizarea și prezentarea datelor din tabele. Un raport răspunde de obicei unei anumite întrebări. Fiecare raport poate fi formatat pentru a prezenta informațiile în cel mai lizibil mod posibil.

Un raport poate fi executat oricând și va reflecta întotdeauna datele curente din baza de date. Rapoartele sunt formatate în general pentru a fi imprimate, dar pot fi vizualizate și pe ecran, pot fi exportate în alt program sau trimise ca mesaj de poștă electronică.

Raportul Camere

Primul raport este legat de numărul total de camera și răspunde la întrebarea: “Câte camere se află în total în acest hotel?” Drept răspuns avem urmatorul formular afișat:

Raportul Orașe

Cel de-al doilea raport realizat este legat de numărul total de orașe de unde provin clienții hotelului și răspunde la întrebarea: “Din câte orașe provin clinții acestui hotel?”. Răspunsul este “8”.

Raportul Țări

Cel de-al treilea raport este asemănător celui de mai sus, dar de această dată doresc să îmi afișeze totalul țarilor de unde provin turiștii. Acest raport răspunde la întrebarea: „Din câte țări diferite provin turiștii cazați în aceste hotel?”. Răspunsul este „7 țări.”

Raportul Comenzi de servicii

Următorul raport scoate rapid un calcul al tuturor serviciilor de care au dispus turiștii, afișând astfel prețul total al acestora. Acest raport răspunde la întrebarea: „Câți bani s-au încasat în total în urma tuturor serviciilor de care au dispus turiștii noștrii?”

Raportul Comenzi camere

Un alt raport aflat în aplicația mea l-am gândit în așa fel încât să îmi afișeze totalul discounturilor, oferite din diferite motive, de care au dispus turiștii la închirierea camerelor. Așaddar, acest raport răspunde la întrebarea: „Care este totalul de preț al discounturilor de care au dispus clienții acestui hotel?”

Raportul Servicii

În cazul în care unul din turiști dorește să dipună de toate serviciile oferite de hotel, următorul tabel este tocmai bun pentru a evidenția totalul prețurilor acestor servicii. Următorul raport răspunde la întrebarea: „Cât costă în total toate serviciile oferite de hotel?” Răspunsul este 899 €.

Raportul Turiști

Afișează numărul total de turiști cazați la hotel. Raportul gândit răspunde la întrebarea: „Câți turiști sunt cazați în total în hotel?” Raspunsul este 16.

Concluzii

Dezvoltarea turismului este de o importanță crucială pentru dezvoltarea economiei pe baza potențialului ei intern, iar o dezvoltare accentuată duce la o gestionare mai greoaie a datelor. Pentru a evita aceasta, aplicația actuală și-a atins toate obiectivele propuse la proiectare. Modul de utilizare este intuitiv, ușor de învățat, iar utilizatorii au posibilitate de a vedea toate camerele din aplicație. Facilitățile sunt grupate, în stânga butoanele de introducere de date, în dreapta cele de afișare a acestora. La rândul lui, administratorul poate gestiona toate informațiile din site – poate introduce camere, servicii, orașe noi, țări, le poate interconecta.

Aplicația este destinată utilizatorilor care doresc sa rezerve camere sau care doresc să tranzacționeze anumite servicii. Aspectul aplicației este unul plăcut, subliniind specificul scopul vizat, adică turismul, având imagini din toată lumea pe forma principală.

Pentru viitor, se au în vedere mai multe îmbunătățiri, cum ar fi rapoarte cu noile legi aparute, modificate sau abrogate legate de acest domeniu, implementarea unui modul de cautare sau implementarea aplicației în mai multe limbi de circulație internațională (engleză, franceză, germană etc.)

Desigur, exista multiple posibilități pentru dezvoltarea ulterioară. Prin intermediul Google API se poate realiza calcularea distanțelor intre două sau mai multe puncte de pe hartă. O altă posibilă facilitate este aceea de a prezenta evenimentele din oraș sau zonă. Și nu în ultimul rând, se poate realiza o versiune mobilă pentru dispozitivele mobile, tablete, iPad-uri și altele.

Ca o concluzie finală, aplicația oferă facilități de care orice organizație modernă nu poate să nu beneficieze.

Bibliografie

1. Gunderloy Mike, Microsoft Access Pentru Incepatori, Editura All, București, Anul 2007

2. Aurelia Pãtrașcu, Ana Tãnãsescu și Dorel Dușmãnescu, Baze de date MS Access Teorie și Aplicații, Editura Universitatii Petrol-Gaze din Ploiesti, Anul 2006

3. Adriana Ilioasa, Curs Microsoft Acces 2003, București, Anul 2009

4. Traian Surcel, Radu Marsanu, Paul Pocatilu – Tehnologii Web și Baze de Date, Editura ASE, București, 2006

5. Alexandru Teodorescu, – Baze de date, Editura Albastra, București, 2007

6. Felicia Ionescu – Baze de Date Relaționale și Aplicații, Editura Tehnică, București, 2004

7. Alison Balter – Invata singur Microsoft Access 2003 în 24 de ore, Editura Niculescu, București

8. Popescu, I., Modelarea bazelor de date – Editura Tehnica, București, 2001

9. M. Gorunescu, F. Gorunescu, A. Prodan, – Excel, Access și Pagini Web, Editura Albastra, București, 2006

10. Ioan Despi, Gheorghe Petrov, Reisz Robert, Teoria Generală a Bazelor de Date, Editura Mirton, Timisora, 2002

11. Note de curs – Baze de Date – lector univ. dr. Carstea Claudia, Universitatea "George Baritiu" din Brașov, 2007

12. Adrian Trașcă, Georgeta Manafu – Bazele programării – Editura Arves, Craiova, 2006