UNIVERSITATEA ,,LUCIAN BLAGA”

FACULTATEA DE ŞTIINŢE ECONOMICE

SIBIU
MASTER B8: Expertiză contabilă şi audit

UTILIZAREA SISTEMELOR INFORMATICE

Proiect la PRAXIS MARDENT

PROFESOR :
Conf. Univ. Dr. Marian Cristescu

MASTERAND:
Cîndroi Ionelia-Silvana
Anul I

Sibiu
-2015-
 CAPITOLUL 1 – MODELAREA CONCEPTUALĂ A
DATELOR

În cadrul acestui proiect am dorit să elaborez o MCD(modelare conceptual a datelor)

pentru sistemul informatic privind pacienţii unui cabinet stomatologic numit Praxis Mardent din
Hunedoara.

1.1Modelul Entitate-Asociere (EA)

Pentru definirea modelului conceptual al datelor se apelează la modele intermediare care

sunt folosite ca suport al unei metodologii de proiectare. Un model conceptual este un ansamblu
de concept şi reguli de combinare a acestor concepte permiţând reprezentarea realităţii
circumscrise domeniului supus informatizării.
Modelele utilizate se numesc modele semantice şi au drept obiectiv ca prin conceptele
oferite să permită reprezentarea lumii reale.

Concepte de bază ale modelului EA:

1) Entitatea:
 reprezintă un obiect al realităţii modelate caracterizat printr-o existenţă proprie, cu o
identitate proprie (care-l face identificabil în raport cu celelalte obiecte de acelaşi tip)
şi o mulţime de caracteristici care exprimă proprietăţile acestuia.
Următoarele tipuri de entităţi aparţin domeniului de studiu ales şi anume gestiunea pacienţilor
unui cabinet stomatologic:

Serv_
Pacienţ Programăr Tratament
Medici stomato Bon
i i e
 2) Atributul
 defineşte o proprietate distinctă a unei entităţi. Fiecare atribut prezintă un
domeniu,adică o mulţime de valori admise. Într-o entitate se regăsesc realizări
corespunzătoare caracteristicilor definitorii pentru tipul de entitate.

Atributele pot fi clasificate în funcţie de mai multe criterii:

a) După complexitate atributele sunt:

 elementare (simple) ale căror realizări nu pot fi descompuse (exemplu: unitate

monetară, preţ unitar,număr matricol al studentului, marca angajatului, etc).
 decompozabile (complexe) ale căror realizări sunt decompozabile (ex: data
calendaristică – se poate descompune în zi, lună, an; adresa - se poate descompune în
stradă, număr, codul de clasificare al unui mijloc fix, etc).

b) După obligativitate pe care le pot prezenta atributele pot fi:

 obligatorii (trebuie să prezinte obligatoriu o realizare, ceea ce corespunde sintagmei
NOT NULL –orice realizare).
 opţionale ( sunt atribute care pot să nu prezinte nici o valoare (realizare) în cadrul unei
entităţi (de exemplu atributele: telefon, fax, e-mail - nu toate persoanele au telefon, fax,
adresă e-mail).

c) După realizările pe care le pot prezenta atributele pot fi:

 monovaloare: atribute care prezintă o singură valoare în cadrul unei entităţi (exemplu:
nume student, nr. matricol, data naşterii, codul numeric personal etc).
 multivaloare: atribute care prezintă mai multe realizări în cadrul aceleiaşi entităţi (de
exemplu, în tipul de entitate ANGAJAT, entitatea Popescu Marius poate prezenta pentru
atributul STUDII mai multe valori: Facultatea de Mecanică, Facultatea de Finanţe
Asigurări Bănci şi Burse de Valori).
Enitiate Atribute După După realizări După
complexitate obligativitate
 Id_progr Elementar Monovaloare Obligatoriu
Nr_bon Elementar Monovaloare Obligatoriu
BON Data_bon Decompozabil Monovaloare Obilatoriu
Suma Elementar Monovaloare Obligatoriu
Tip_plată Elementar Monovaloare Opţional
Id_medic Elementar Monovaloare Obligatoriu
Nume_med Elementar Monovaloare Obligatoriu
Prenume_med Elementar Monovaloare Obligatoriu
Sex_med Elementar Monovaloare Opţional
MEDIC Data_nast Decompozabil Monovaloare Opţional
Data_ang Decompozabil Monovaloare Opţional
Studii Elementar Monovaloare Optional
Zile_lucrat Elementar Monovaloare Obligatoriu
Ora_incep_progr Decompozabil Monovaloare Obligatoriu
Ora_sf_progr Decompozabil Monovaloare Obligatoriu
Nr_tel_m Elementar Multivaloare Optional
Id_pacient Elementar Monovaloare Obligatoriu
Id_medic Elementar Monovaloare Obligatoriu
Nume_pac Elementar Monovaloare Obligatoriu
Prenume_pac Elementar Monovaloare Obligatoriu
PACIENŢI Sex_pac Elementar Monovaloare Opţional
Data_nast_pac Decompozabil Monovaloare Opţional
Judet Elementar Monovaloare Opţional
CNP Elementar Monovaloare Opţional
Localitate Elementar Monovaloare Opţional
Nr_tel_p Elementar Multivaloare Obligatoriu
Info_cabinet Elementar Monovaloare Optional
PROGRAMĂRI Id_progr Elementar Monovaloare Obligatoriu
Id_pacient Elementar Monovaloare Obligatoriu
Data_contact Decompozabil Monovaloare Opţional
Tip_contact Elementar Monovaloare Optional
Data_progr Decompozabil Monovaloare Obligatoriu
Ora_progr Decompozabil Monovaloare Obligatoriu
Prog_medic Elementar Monovaloare Obligatoriu
Id_serv Elementar Monovaloare Obligatoriu
Den_serv Elementar Monovaloare Obligatoriu
SERV_STOMATO Tip_serv Elementar Monovaloare Optional
Pret Elementar Monovaloare Obligatoriu
UM Elementar Monovaloare Obligatoriu
Id_progr Elementar Monovaloare Obligatoriu
TRATAMENTE Id_serv Elementar Monovaloare Obligatoriu
Data_tratam Decompozabil Monovaloare Obligatoriu

Obiecte simple –sunt cele care le corespunde în modelul conceptual al datelor câte un tip de
entitate:
 De exemplu, pacienţilor unui cabinet stomatologic, deoarece sunt definiţi prin aceleaşi
caracteristici (nume_p, prenume_p, CNP etc.), le va corespunde în modelul EA un singur tip de
entitate, numărul de realizări ale acestuia (entităţi) fiind egal cu numărul clienţilor.
Obiectele compozite se caracterizează prin faptul că ele conţin una sau mai multe caracteristici
multivaloare (cărora în modelul EA le vor corespunde atribute multivaloare).
PROGRAMARI

Id_progr
Data_contact
Data_progr
Ora_progr
Id_serv
Denumire
Tip_serv
Pret

Programari

Id_progr
Data_contact
Obiect compus

Data_progr 
Ora_progr

Tipuri de entităţi
Serv_stomato
 Id_serv
Denumire
Tip_serv
Pret

Fiecare tip de entitate prezintă un IDENTIFICATOR reprezentat de un atribut sau un grup

de atribute al cărui rol este de a permite identificarea în mod unic, fără echivoc, a entităţilor.
Pentru acest proiect identificatorii sunt prezenţati în tabelul de mai jos:

Entitate Identificator

BON Id_progr
MEDICI Id_medic
PACIENTI Id_pacient
PROGRAMARI Id_progr
SERV_STOMATO Id_serv

TRATAMENTE Id_progr şi Id_serv

3 )Asocierea şi cardinalitatea
Asocierea dintre entitati exprima legatura stabilita dintre acestea si rolul pe care il joaca fiecare
entitate participanta la legatura.
Tipul de asociere se defineste ca ansamblul legaturilor, prezentand aceeasi semnificatie, dintre
entitatile apartinand la doua sau mai multe tipuri de entitati.
Cardinalitatea cuplului entitate – asociere reprezinta cuplul de valori intregi (x,y) astfel incat :
• X(cardinalitatea minimala) exprima numarul minim de realizari ale legaturii (asocierii)
existand pentru o entitate.
• Y (cardinalitatea maximala) reprezinta numarul maxim de aparitii ale corespondentei putand
exista pentru o entitate.
Valorile uzuale pentru exprimarea cardinalitatii sunt: 0,1; 1,1; 0,n; 1,n.

A.
Cardinalităţi

1,n
1, n
MEDICI PACIENTI
Id_medic Id_pacient
Nume_med Nume_pac
Prenume_med Tratează Prenume_pac
Sex_med Sex_pac

Îngrijitor Tratat

Roluri

 Orice medic trebuie să trateze minim un pacient dar pot fi medici care pot să trateze mai
mulţi pacienţi. Un pacient poate fi tratat de minim unu sau mai multi medici.

Cardinalităţi
B.

1, n 1, n
Pacienti Serv_stomato
Id_pacient Id_serv
Nume_pac Den_serv
Informat
Prenume_pac Tip_serv
Sex_pac Pret

Informat Aflat
 C.

Cardinalităţi

1, 1 1, 1
PROGRAMARI BON_FISCAL
Id_progr Id_progr
Data_contact Nr_bon
Data_progr Se achită Data_bon
Ora_progr Suma

Asteapta Primit

Roluri

 După fiecare programare se achită un singur bon fiscal în urma programari si

tratamentului aplicat. Un singur bon fiscal este primit după fiecare programare în parte.

D.
Cardinalităţi

0, n 1, n
SERV_STOMATO TRATAMENTE
Id_serv Id_progr
Denumire Id_serv
Tip_serv Inclus Data_tratam
Pret

Cuprinde Include

Roluri
  Pot exista servicii stomatologice care să nu fie incluse în programa de tratament sau se
poate să fie unele suplimentare . Un tratament trebuie să cuprindă cel putin un serviciu
însă pot exista mai multe servicii stomatologice în cadrul unui tratament.

TIPURI DE ASOCIERI
Dupa numarul de tipuri de entitati participante asocierea poate fi:
1. Unară (reflexivă)
2. Binară
3. Complexă

Asocierea complexă reprezintă legăturile stabilite între realizarile mai multor tipuri de
entităţi.
1, n
Exemplu : 1, n

Pacienţi Tratament

Află

1, n Implică
1, n
Beneficiază
Serv_stomato

Restricţiile de integritate:
 definesc cerinţele pe care datele trebuie să le respecte pentru a fi corecte şi coerente în
raport cu realitatea pe care o reflectă.
Restricţiile de integritate reprezintă o modalitate de integrare a semanticii datelor în mod indirect
în modelul entitate asociere pe care astfel îl îmbogăţesc.
Restricţiile de integritate privesc:
 valorile pe care le pot lua atributele entităţilor şi asocierilor;
 valorile identificatorilor entităţilor;
 rolurile jucate de entităţi în asocierile la care participă;
 asocierile stabilite între entităţi.

Mai jos sunt prezentate restrictiile de domeniu din cadrul acestui proiect:
Entitate Atribut Restricţie

BON Suma [Suma]>0

 UM "RON"
Data_bon ("Data_bon")="Data_progr"
Sex_m "M" Or "F"

Zile_lucrat "L - V"

MEDICI Data_ang_m ("Data_ang_m")>"Data_n_m"

Ora_sf_progr ("Ora_sf_progr")>"Ora_incep_progr"
Nr_tel_m !9999-999-999

PACIENTI Sex_p "M" Or "F"

Nr_tel_p !9999-999-999

Data_progr ("Data_progr")>"Data_contact"
PROGRAMARI
Ora_progr ("Ora_progr")>"Ora_incep_progr" And
("Ora_progr")<"Ora_sf_progr"
Pret [Pret] Between 15 And 600
SERV_STOMATO
UM "RON"

TRATAMENTE Data_tratam ("Data_tratam")="Data_progr"

Restricţii structurale

Entitate Identificator Valoare unica

BON Id_progr NOT NULL
MEDICI Id_medic NOT NULL
PACIENTI Id_pacient NOT NULL
PROGRAMARI Id_progr NOT NULL
SERV_STOMATO Id_serv NOT NULL
TRATAMENTE Id_progr, Id_serv NOT NULL

Restricţii de integritate de roluri

În definirea asocierii am subliniat faptul ca aceasta exprima legatura stabilita intre entitati
diferite, fiecare dintre acestea jucand un anumit rol. Plecand de la rolurile jucate de entitati in
cadrul asocierilor putem defini o serie de restrictii de integritate si anume de: egalitate,
incluziune si excluziune de roluri.

Restricţia de incluziune de roluri

Restrictia de incluziune de roluri statueaza faptul ca, daca o entitate E1 care joaca rolul r1 in
asocierea A1 va trebui sa joace si rolul r2 in asocierea A2. Rezulta ca rolul r1 include rolul
r2.

PACIENTI TRATAMENT
1, n Urmează 1, n
 Id_pacient Id_progr
Nume Id_serv
Prenume Data_tratam
Sex

1, Implică
n
Plăteşte

BON SERV_STOMATO
1,1
Id_progr Id_serv
Nr_bon Den_serv
Data_bon Tip_serv
Achită
Suma Pret
I
Rezultă

Restricţia de egalitate de roluri.

Egalitatea de roluri presupune că restricţia de incluziune între roluri sa fie reciprocă.

1, n 1, n
PACIENTI PROGRAMARI
Id_pacient Id_progr
Nume_pac Data_contact
Prenume_pac Face Data_progr
Sex_pac Ora_progr
Efectuată
1,
n

=
Se aplică
Aplic

1,
n
at

TRATAMENTE
Id_serv
Data_tratam

Restrictia de excluziune de roluri

Excluziunea de roluri specifica faptul ca un rol r1 jucat de o entitate E1 in asocierea A1 exclude

existenta rolului r2 jucat in asocierea A2.

1, n 1, n
Pacienti Tratament
Tratat
Urmează
Id_pacient Id_progr
Nume_pac Id_serv
Prenume_pac Data_tratam
Sex_pac

# 1, n
1, n
Recomandă

Medic

Restrictii de integritate de asocieri

Restrictia de incluziune de asocieri

Restrictia de incluziune exprima faptul ca asocierea A1 stabilita intre doua entitati va
determina existenta unei alte asocieri A2 in cadrul modelului EA.
 Medici Pacienti
1, n
Id_medic Id_pacient
Nume_med Consultă Nume_pac
Prenume_med Prenume_pac
Sex _med Sex_pac

1, n
Recomandat Primesc
I
Tratament
Id_progr
Id_serv
Data_tratam

Serv_stomato 1, n
Id_serv
Den_serv
Tip_serv
Pret

1,n

Urmează

Restrictia de excluziune de asocieri

Restrictia de excluziune de asocieri exprima faptul ca asocierile apartinand tipului de asociere
A1 exclud asocierile apartinand tipului A2.

Primito
r
Primeşte
0,n

1,1

Pacienţi Tratament
Id_pacient Id_progr
Nume_pac Id_serv
Prenume_pac Data_tratam
Sex_pac
 1,n
Plătitor

1,1

Achită Serv_stomato
Id_serv
Den_serv
Tip_serv
Pret

Restrictia de egalitate de asocieri

Restrictia de egalitate de asocieri exprima faptul ca asocierile apartinand tipului A1 determina
existenta asocierilor apartinand tipului A2 si invers.

1, n 1, n
PACIENTI PROGRAMARI
Id_pacient Id_progr
Nume_pac Data_progr
Prenume_pac Fac Ora_progr
Sex_pac
1, n

= Se stabileşte
1, n

TRATAMENTE
Id_progr
Id_serv
Data_tratam

Dependenţe funcţionale

Tipuri de dependenţe funcţionale

Conceptul de dependenţă funcţională (DF) este fundamental în analiza structurii datelor. Studiul
dependenţelor funcţionale stabilite între atribute ne permite obţinerea unei reprezentări
formalizate a structurii de date.
Dependenţele funcţionale evidenţiază raporturile de determinare stabilite între atributele unei
entităţi.
O dependenţă funcţională pune în relaţie două atribute: determinantul şi determinatul.

Determinant Determinat

Exemple de dependenţe funcţionale:

DETERMINAN DETERMINAT
T
Id_bon Număr
Id_medic Nume
Id_pacient CNP
Id_progr Data
Id_tratament Tratament
Id_serv Denumire

Matricea dependenţelor funcţionale

Matricea dependenţelor funcţionale poate fi realizată în două variante:
o matricea simplificată
o matricea completă
Matricea simplificată reprezintă un tablou în care coloanele cuprind determinanţii
dependenţelor funcţionale iar fiecare linie un atribut aparţinând mulţimii atributelor supuse
modelării.
Matricea completă reprezintă un tablou asemănător matricii simplificate cu singura
deosebire că numărul de coloane este egal cu numărul liniilor, cu alte cuvinte antet de coloană va
fi orice atribut (regăsit şi ca antet de linie) şi nu doar atributele (grupurile de atribute) cu rol de
determinant într-o dependenţă funcţională.

Matricea simplificată a dependenţelor funcţionale

Determinanţi

Atribute 1 7 23 34 41 46

1. Id_progr 1
2.Nr_bon 1
3.Data_bon 1
4. Sumă 1
5.UM 1
6.Tip plată 1
7.Id_medic 1
8.Nume_med 1
9.Prenume_med 1
10.Sex_med 1
11.Data_nast 1
12.Data_ang 1
13.CNP 1
14.Strada 1
15.Numar 1
16.Oras 1
17.Judet 1
18.Studii 1
19.Zile_lucrate 1
20.Ora_incep_prog 1
21.Ora_sf_prog 1
22.Nr_tel 1
23.Id_pacient 1
24.Id_medic 1
25.Nume_pac 1
26.Prenume_pac 1
27.Sex_pac 1
28.Data_nast_pac 1
29.Judet 1
30.CNP 1
31.Localitate 1
32.Nr_tel_pac 1
33.Info_cabinet 1
34.Id_progr 1
35.Id_pacient 1
36.Data_contact 1
37.Tip_contact 1
38.Data_prog 1
39.Ora_progr 1
40.Prog_medic 1
41.Id_serv 1
42.Den_serv 1
43.Tip_serv 1
44.Pret 1
45.Um 1
46.Id_progr 1
47.Id_serv 1
48.Data_tratam 1
 Reguli de verificare şi normalizare a MCD

Reguli de verificare a MCD:

 Regula de unicitate a numelor

Ex: Entitate = MEDICI, atribut = Nume_med
Entitate = PACIENTI, atribut = nume_pac etc.
 Regula unicităţii atributelor
Ex: Atribute precum Nume_pac, Sex_pac, Nr_tel_pac definesc doar entitatea PACIENTI.
 Regula minimizăriii identificatorilor
Ex: sunt doar 6 identificatori.
 Regula valorii NULL
Ex: toate atributele cu rol de identificatori au realizări.
Reguli de normalizare a MCD:
 Fiecare entitate prezinta un identificator prezentând valori unice, nenule (FN1)
Ex: Entitatea Pacienţi – identificatorul Id_pacient etc.
 Toate atributele entităţii, altele decât identificatorul, trebuie să fie în dependenţă
funcţională completă şi directă cu identificatorul entităţii (FN2)
Ex: atributele Id-serv, denumire_serv,tip_serv,preţ– dependenţă funcţională completă şi
directă faţă de identificatorul Id_serv.
 Toate atributele unei asocieri trebuie sa depinda complet de identificatorul asocierii, iar
fiecare atribut trebuie sa depinda de intregul identificator si nu doar de o parte a acestuia
(FN3).
Ex: atributele Id_prog, nr_bon, data_bon,suma,tip_plata – dependenţă funcţională
completă faţă de identificatorul Id_progr.

CAPITOLUL 2 – MODELAREA CONCEPTUALĂ A

PRELUCRĂRILOR

Rolul modelarii conceptuale a prelucrarilor

Conceptul de prelucrare reprezintă:

* partea dinamică a sistemului informaţional
* materializarea sub formă de acţiuni a regulilor de gestiune specifice activităţii
întreprinderii

Modelul conceptual al prelucrărilor

* este o reprezentare schematică a activităţii specifice unui domeniu din cadrul
întreprinderii independentă de particularităţile organizatorice şi mijloacele concrete
de realizare
 * răspunde la întrebarea “Ce prelucrări se realizează ?”
* permite reprezentarea înlănţuirii operaţiilor cu precizarea condiţiilor necesare pentru
declanşarea acestora si consecinţele derulării operaţiilor respective.

În cadrul MCP se impune respectarea cerinţelor determinate de regulile de gestiune, impunând

următoarele aspecte:
* dacă unele operaţii s-au realizat, înseamnă ca alte activităţi urmează să se execute
* unele operaţii trebuie executate înaintea altora
* unele operaţii nu pot fi executate decât dacă alte operaţii au fost deja realizate;
* unele operaţii pot fi declanşate în timp ce altele sunt în curs de desfăşurare;
* un obiect al realităţii supus unei operaţii (transformări) îşi schimbă starea.

În concluzie, MCP permite:

* precizarea evenimentelor declanşatoare ale operaţiilor (prelucrărilor)
* precizarea înlănţuirii operaţiilor al căror conţinut îl descrie succint fără detalii
referitoare la: modul de execuţie a operaţiilor (manual sau automat), particularităţi
organizatorice sau repere temporale;
* prezentarea rezultatelor generate în urma executării operaţiilor.

MCP nu trebuie să conţină aspecte referitoare la:

* locul, momentul sau persoanele implicate în prelucrări;
* modul concret de realizare a operaţiilor.

Acţiunea 1: Definirea domeniului investigat.

Realizarea de programări pe baza cărora pacientilor li se va stabili o consultaţie după
care li se va prescrie un tratament.
Principalii actori implicaţi:
Pacientul :
- solicită o programare;
- va primi o consultaţie;
- i se va prescrie un tratament.
- va achita contravaloarea serviciului medical.
Medicul:
- primeste solicitarea pacientului;
- stabileste tratamentul adecvat;
- execută pacientului un serviciu stomatologic;
- încaseaza banii ca urmare a serviciului medical oferit.
 solicită o programare
va stabili o dată pentru consultaţie

va primi un tratament corespunzător

Pacienţi

Medic
va beneficia de unu sau mai multe servicii stomatologice

va primi un bon fiscal ca urmare a plăţii serviciului prestat

de către medic

Acţiunea a-2-a :Evenimente identificate

E1: Solicitare programare
E2: Solicitare acceptată
E3: Pacient înregistrat în baza de date
E4: Pacient nou
E5: Pacient nou înregistrat
E6: Identificare tratament
E7: Aplicare serviciu stomatologic
E8: Plata consultatie
E9: Eliberare bon

Acţiunea a-3-a: Întocmirea tabloului evenimente-rezultate

Nr EVENIMENTE ACŢIUNI EXECUTATE EVENIMENTE

crt DECLANŞATOARE REZULTATE

1 Solicitare programare Verificare disponibilitate Solicitare acceptată

2 Solicitare acceptată
3 Pacient nou
4 Pacient existent în BD sau
Pacient nou înregistrat
5 Tratament aplicat
Verificarea existenţei Pacient nou
pacientului în baza de date Sau
Pacient existent în baza de
date
Înregistrare pacient în baza de Pacient nou înregistrat
date
Tratarea pacientului Tratament aplicat
Prezentare servicii Servicii prezentate

6 Efectuare servicii Solicitare plată Plată efectuată

 stomatologice
7 Plată efectuată Scoatere bon Bon emis

Acţiunea a 4-a: Identificarea operaţiilor

OP1 = Verificare disponibilitate
OP2 = Verificare existenţă pacient in baza de date
OP3 = Înregistrare pacient nou
OP4 = Tratament pacient
OP5 = Servicii propuse
OP6 = Solicitare plata
OP7 = Eliberare bon

Acţiunea a 5-a: Identificarea sincronizărilor

Sincronizările ce apar în cadrul MCP au fost deja marcate în cadrul etapei a treia,
„Întocmirea tabloului evenimente-rezultate”.

Acţiunea a 6-a:Identificarea regulilor de emisie

OPERAŢIE

REGULI DE EMISIE

Operaţia 2 R2,1 – Pacientul există în BD

Operaţia 4 R4 – Pacientul este tratat

Operaţia 7 R7,5 – Suma de plata > 0

Acţiunea a 7-a : Elaborarea MCA

E1

OP1 Verificare disponibilitate consultaţie

Verificare dacă consultaţia a fost programată

E2
OP2 Verificare existenţă pacient
Verificarea existenţei pacientului în baza de date
OK NOT OK

E4
E3

OP3 Înregistrare pacient nou

Înregistrare pacient nou în BD

E5
E3 sau E5

OP4 Tratare pacient

Determinare tratament pacient

OP5 Servicii propuse

Prestare servicii

E6

OP6 Solicitare plată

E7
Plata efectuată

E8

OP7 Eliberare bon

 Bon emis

CAPITOLUL 3 – MODELAREA LOGICĂ A DATELOR

Modelul relaţional:

Cheile primare:

Chei primare

Id_medic
Id_pacient
Id_progr
Id_serv

Modelarea fizică:
 INTEROGĂRI

1) Să se selecteze toate programările făcute de pacienţi:

SELECT: Id_pacient, Nume_pac, Prenume_pac, Data contact, Data_progr, Progr_medic
FROM PROGRAMĂRI and PACIENŢI
Sort Ascending
 2) Afişarea doar a pacienţilor de sex feminin:

SELECT Id_pacient, Nume_pac, Prenume_pac, Sex_pac, Localitatea

FROM PACIENTI;
Criteria ( sex ) ”f”

3) Afişarea doar a plăţiilor efectuate cu cardul.

SELECT Id_progr, Nr_bon, Data_bon, Tip_plată, Suma
Criteria (Tip_plată) ”card”

FORMULARE
RAPOARTE
FACTURIS (PROGRAM DE EVIDENŢĂ CONTABILĂ )
Configurare informaţii firmă

Factură emisă:

’’ Clienţi’’4111= % 248 lei

704 ’’ Venituri din servicii prestate’’ 200
4427’’TVA colectată’’ 48
Incasare client

5311 ‘’ Casa în lei’’=704 ‘’Venituri din servicii prestate’’ 248 lei

Generare chitanţă

4111’’ Clienţi’’=% 248 lei

704’’ Venituri din servicii prestate’’ 200
4427’’ TVA colectată’’ 48
Incasare client

5311’’ Casa în lei’’ =704’’ Venituri din servicii prestate’’ 248 lei

Facturi furnizori

- Achizitionarea de periuţe electrice şi aţă dentară:

% = 401’’ Furnizori’’ 389 lei

302’’ Materiale consumabile’’ 322

4426 ’’ TVA deductibilă’’ 67
Plata furnizori

401 ’’Furnizori’’ =5311’’ Casa în lei’’ 389 lei

Introducere NIR
Balanţa stocuri

Vânzări produse
Stoc

Evidenţă furnizori

Fişă furnizor
Registru de casă