Realizarea conceptuala a unei aplicatii informatice in Access

Realizarea conceptuala a unei aplicatii informatice in Access

Pentru exemplificarea si intelegerea operatiilor de lucru in Access, se va folosi un studiu de caz practic.

Se alege activitatea unui service auto. Managementul firmei doreste realizarea unei aplicatii informatice de gestiune a activitatilor desfasurate.

1. Prezentarea problemei

Se doreste realizarea unei aplicatii cu baze de date in vederea informatizarii activitatii unui service auto.

Obiectivele aplicatiei:

asigurarea evidentei clientilor

evidenta autovehiculelor reparate

evidenta reparatiilor efectuate in firma

evidenta sumelor incasate

Angajatii firmei sunt ingineri, mecanici auto, lacatusi si electricieni. Pentru fiecare angajat se cunosc numele, adresa si numarul de telefon.

Clientii sunt persoane fizice sau juridice care solicita reparatii sau revizii pentru autovehiculele avute in proprietate. In momentul primei prezentari, fiecarui client i se retin datele personale (nume, adresa, telefon, cont bancar, numarul si seria buletinului de identitate sau pasaportului). Pentru persoanele juridice trebuie retinut si codul fiscal.

Pentru fiecare autovehicul adus la reparat se vor inregistra numarul de inmatriculare, seria motorului, seria caroseriei, marca si modelul.

Firma are un nomenclator de operatii, in care figureaza denumirile tuturor operatiilor ce se pot executa in cadrul activitatii de service si numarul conventional de ore normate pentru fiecare operatie.

Pentru realizarea efectiva a reparatiilor, firma dispune de un nomenclator de piese de schimb ce contine denumirile pieselor si subansamblelor disponibile, unitatile lor de masura, stocurile disponibile si preturile pentru fiecare.

In momentul executarii reparatiei, se intocmeste fisa de reparatii, in care sunt consemnate numarul si data reparatiei, operatiile efectuate, piesele inlocuite si observatii.

Unele dintre operatiile efectuate necesita interventia unui singur mecanic sau a unei echipe. Pentru realizarea statelor de plata trebuie asigurata evidenta orelor lucrate de fiecare salariat in parte.

Accesul la formularele si rapoartele aplicatiei se va realiza prin meniul de optiuni ce are definite trei optiuni:

Formulare

Rapoarte

Iesire (parasirea aplicatiei)

Se vor anula toate posibilitatile utilizatorului de a accesa accidental obiectele bazei de date (din meniul Tools, optiunea Startup. Se stabileste meniul aplicatiei si titlul acesteia.

La deschiderea aplicatiei, se va afisa doar meniul propriu, meniul Access si fereastra bazei de date fiind dezactivate prin optiunile Allow Full Menus si Display Database Window.

Schema de acces la aplicatie este prezentata in figura urmatoare:

Fig.10.3 Fereastra StartUp

Pentru entitatile Mecanici, Operatii, Piese de schimb, se vor crea formulare (Form) individuale cu butoane de deplasare intre inregistrari, la prima si ultima inregistrare.

Pentru entitatile Proprietari si Autovehicule se va realiza un formular combinat: macheta de proprietari este principala, iar pentru autovehicule se va realiza un subformular, plasat in interiorul formularului principal. Acest tip de formular are avantaje prractice. Astfel, la introducerea unui nou proprietar, apar pe ecran si campurile specifice autovehiculului detinut, care pot fi completate in aceeiasi macheta. Suplimentar, se elimina incidentul de a introduce datele unui autovehicul, pentru care nu s-au adaugat in baza de date valorile corespunzatoare proprietarului ei si invers. Daca se modifica continutul unor campuri si se cunoaste proprietarul unei masini, acesta poate fi gasit rapid si retinut cu toate autovehiculele lui.

Realizarea conceptuala a aplicatiei cu ajutorul SGBD Access

Pornind de la enuntul aplicatiei si de la solicitarile precizate, rezolvarea in Access presupune:

crearea bazei de date in care se vor afla obiectele aplicatiei;

crearea obiectelor solicitate expres prin enunt, dar si a altora noi, pe care proiectantul le considera necesare si oportune; in aceasta etapa consideram ca se vor realiza doar descrierile de structura ale obiectelor;

definirea relatiilor (legaturilor) intre tabele inaintea introducerii datelor primare, in vederea asigurarii integritatii entitatilor si a celei referentiale;

incarcarea tabelelor cu date primare;

realizarea interogarilor solicitate, care contin selectii de inregistrari dupa diverse criterii (simple si compuse), ordonarea datelor crescator sau descrescator functie de continutul unuia sau a mai multor campuri, campuri calculate conform unui algoritm, indicatori sintetici calculati etc;

realizarea videoformatelor necesare introducerii, actualizarii sau vizualizarii datelor din tabele si/sau interogari; formularele proiectate vor fi simple, pentru majoritatea tabelelor din aoplicatie, dar si compuse (ex. formularul principal Proprietari si subformularul Autovehicule inclus in el);

obtinerea listelor finale (Report)

realizarea macrocomenzilor necesare definirii si functionarii interfetei prietenoase intre utilizator si aplicatie. Aceasta interfata se prezinta sub forma unui meniu personalizat al lucrarii.

2.1. Modelul conceptual al datelor

In urma analizei problemei rezulta urmatoarele entitati (colectii de date): Proprietari, Autovehicule, PieseSchimb, Angajati, Operatii, FiseReparatii, OperatiiFacturate, InlocuiriPiese.

Corespondentele existente:

Proprietari - Autovehicule

Un proprietar poate avea una sau mai multe masini

Autovehicule - FiseReparatii

Un autovehicul poate avea una sau mai multe fise de reparatii

PieseSchimb - Inlocuiripiese

O piesa de schimb poate sa fie folosita la mai multe operatii de inlocuire

FiseReparatii - InlocuiriPiese

Pe o fisa de reparatii pot apare una sau mai multe piese inlocuite

Angajati - OperatiiFacturate

Un angajat poate participa la mai multe operatii facturate

OperatiiFacturate - Operatii

O anumita operatie poate fi facturata de mai multe ori, pentru mai multe autovehicule

FiseReparatii - OperatiiFacturate

Aceeasi reparatie poate fi facuta si facturata de mai multe ori.

Fiecare entitate va face obiectul unui tabel Access

2.2. Modelul relational al datelor

Pentru fiecare entitate definim campurile care o caracterizeaza si stabilim cheia primara (campul sau grupul de campuri prin ale caror valori o inregistrare de date devine unica). In exemplul abordat, campurile cheie primara sunt subliniate.

Proprietari (CodProprietar,  DenumireClient, Adresa, Telefon, SeriaBI, NrBI, CodFiscal, ContBancar)

Autovehicule (NrIdentificare, NrInmatriculare, SerieMotor, SerieCaroserie, Marca, Model, CodProprietar)

Angajati (CodAngajat, NumeAngajat, Functia, Adresa, Telefon, SalariuBaza)

PieseSchimb (CodPiesa, DenumirePiesa, UM, StocActual, PretPiesa)

Operatii (CodOperatie, DenumireOperatie, OreNormate)

OperatiiFacturate (NrReparatie, CodOperatie, CodAngajat)

FiseReparatii (NrReparatie, DataReparatie, Observatii, NrIdentificare, TarifOraManopera)

InlocuiriPiese (NrReparatie, CodPiesa, Cantitate)

In figura 5.5 este prezentata baza de date Access (modelul fizic) a aplicatiei enuntate, prin transformarea modelului relational.

Fig. 10.4 Fereastra relatiilor intre tabele

Ceilalti pasi referitori la realizarea obiectelor aplicatiei vor fi explicati in detaliu si exemplificati in Access pe parcursul prezentarii activitatilor intreprinse.

Lucrarea de verificare nr. 2

Realizati modelul conceptual al aplicatiei "Evidenta cartilor din biblioteca Universitatii Romano-Americane", precum si modelul relational al datelor