Cuprins
- 1. DESCRIEREA BAZEI DE DATE 3
- 2. SCHEMA CONCEPTUALĂ 3
- 3. OPERAŢII DDL 6
- 3.1 CREAREA TABELELOR 6
- 3.2 ACTUALIZAREA STRUCTURII TABELELOR 7
- 4. ADĂUGARE DE ÎNREGISTRĂRI 9
- 4.1 ADĂUGARE DE ÎNREGISTRĂRI ÎN ABONAMENTE 9
- 4.2 ADĂUGARE DE ÎNREGISTRĂRI PENTRU CLIENŢI 10
- 4.3 ADĂUGARE DE ÎNREGISTRĂRI ÎN CONTRACTE 11
- 4.4 ADĂUGARE DE ÎNREGISTRĂRI ÎN SITUAŢIILE FINANCIARE ALE LUNII DECEMBRIE 11
- 4.5 ADĂUGARE DE ÎNREGISTRĂRI ÎN ÎNCASĂRI 12
- 5. MODIFICAREA DATELOR 13
- 6. EXEMPLE DE INTEROGĂRI VARIATE 15
- 7. GESTIONAREA ALTOR OBIECTE ALE BAZEI DE DATE 18
- 7.1 TABELE VIRTUALE 18
- 7.2 INDECSI 18
- 7.3 SINONIME 18
- 7.4 SECVENTE 19
- 8. REALIZAREA UNUI FORMULAR SI A UNUI RAPORT IN FOXPRO 19
- BIBLIOGRAFIE 21
Extras din proiect
1. Descrierea bazei de date
Presupunând activitatea de gestiune a abonamentelor de voce oferite de o firmă de telecomunicaţii creăm o bază de date ce are scopul de a evidenţia pentru fiecare client abonamentul sau abonamentele alese, plăţile efectuate şi situaţia financiară.
Am considerat că un abonament este achiziţionat de clienţi prin intermediul unui contract, iar un contract trebuie să corespundă unui singur abonament. Un client poate încheia unul sau mai multe contracte, iar un contract trebuie să fie încheiat de un singur client. Întrucât un client poate avea mai multe contracte, legatura dintre clienţi şi situaţiile financiare nu va fi 1:1. Astfel, un client are una sau mai multe situaţii financiare care corespund unui singur client. Desigur, un client poate avea una sau mai multe încasări, iar încasările trebuie să corespundă unui singur client.
2. Schema conceptuală
Detalii privind câmpurile fiecărei tabele şi restricţiile de integritate sunt ilustrate în figurile 2.1-2.5.
În figura 2.1 este reprezentată schema conceptuală şi sunt evidenţiate cheile primare şi externe.
În figura 2.2 apar restricţiile de integritate ale tabelei tmo_abonamente:
Figura 2.3 arată restricţiile tabelei tmo_clienti:
Întrucât tabela tmo_contracte nu are alte restricţii de integritate în afara celor din schema conceptuală nu am evidenţiat acest fapt într-o figură. Restricţiile asupra tabelei tmo_sitf sunt ilustrate în figura 2.4:
Pentru tabela tmo_incasari s-au stabilit următoarele restricţii ilustrare în figura 2.5:
În continuare sunt notate scripturile pentru efectuarea operaţiilor de creare de tabele şi adăugare de înregistrări.
3. Operaţii DDL
3.1 Crearea tabelelor
CREATE TABLE tmo_abonamente (cod_ab NUMBER(5) PRIMARY KEY, denum VARCHAR2(40) NOT NULL, min_retea NUMBER(5), min_nationale NUMBER(4), min_internationale NUMBER(4), sms_retea NUMBER(4), sms_nationale NUMBER(4), trafic_net VARCHAR2(10), cost_euro NUMBER(6,2) NOT NULL);
CREATE TABLE tmo_clienti (cod_client NUMBER(10), nume VARCHAR2(30) NOT NULL, prenume VARCHAR2(30), nr_tel VARCHAR2(10) NOT NULL, cnp NUMBER(13), localit VARCHAR2(25), str VARCHAR2 (25), bl VARCHAR2(5), ap NUMBER(3), jud VARCHAR2(20), email VARCHAR2(40), CONSTRAINT pk_client PRIMARY KEY (cod_client), CONSTRAINT u_cnp UNIQUE(cnp), CONSTRAINT ck_email CHECK(email like '%@%.%'));
CREATE TABLE tmo_contracte (cod_contr NUMBER(10) PRIMARY KEY, data_semnarii DATE default sysdate, cod_abonam NUMBER(5) REFERENCES tmo_abonamente (cod_ab), cod_abonat NUMBER(10) REFERENCES tmo_clienti (cod_client));
CREATE TABLE tmo_sitfinanciare (cod_sit NUMBER(10), zi_fact NUMBER(2), zi_scad NUMBER(2) NOT NULL, sold_ron NUMBER (9,3), cod_abonat NUMBER(10), CONSTRAINT pk_sit PRIMARY KEY(cod_sit), CONSTRAINT fk_abonat1 FOREIGN KEY (cod_abonat) REFERENCES tmo_clienti(cod_client), CONSTRAINT ck_zf CHECK(zi_fact BETWEEN 1 AND 28), CONSTRAINT ck_zs CHECK(zi_scad BETWEEN 1 AND 28));
Preview document
Conținut arhivă zip
- Gestiunea Abonamentelor de Voce - Proiect Oracle.doc