Post on 25-Sep-2015
description
UNIVERSITATEA LUCIAN BLAGA DIN SIBIU FACULTATEA DE TIINE ECONOMICE SPECIALIZAREA EXPERTIZ CONTABIL I AUDIT
Utilizarea sistemelor informatice-economice
.
Prof.coord: Masterand:Sibiu, 2014 Prezentarea societatii ArtmarkLicitaia de obiecte de art (sau de colecie) este organizat de Artmark (Galeriile Artmark srl) i condus de unul sau mai muli reprezentani ai Artmark (licitator/licitatori).
Artmark public n prealabil licitaiei un catalog al obiectelor de art (sau de colecie) supuse licitaiei att n cadrul paginii sale de web (www.artmark.ro), ct i n form tiprit. n cadrul licitaiei se vor vinde numai obiecte de art enumerate i descrise n rezumat n cuprinsul catalogului. Descrierile i ilustraiile obiectelor sunt indicative, nu exhaustive i reprezint o opinie a experilor i specialitilor Artmark cu privire la obiectele de art supuse licitaiei.
Toate obiectele ce se vor vinde vor fi expuse n vederea vizitrii/inspectrii n cadrul expoziiilor ce preced vnzarea prin licitaie. Cumprtorii vor avea oportunitatea de a se lmuri cu privire la condiia, coninutul i conformitatea cu meniunile din catalogul de licitaie ale obiectelor supuse licitaiei, att n cadrul expoziiei, ct i n cadrul licitaiei, astfel nct s i formeze o convingere proprie cu privire la calitile/imperfeciunile obiectului.
Durata, programul i locaia expoziiilor obiectelor ce se vor licita se va face cunoscut public n prealabil, prin pagina de web a Artmark, n catalogul de licitaie, precum i prin alte ci de publicitate. Cataloagele de licitaie se pot procura de la sediul Artmark, din locul expoziiei, din locul unde se organizeaz licitaia, precum i prin pot.
Capitolul 1. Modelarea conceptual a datelor1.1. Sistemul informaional
n lucrarea Analiza i proiectarea sistemelor informaionale economice, economistul Oprea Dumitru definete sistemul informaional ca fiind totalitatea resurselor de capital i a resurselor umane de care dispune ntreprinderea, investite n vederea colectrii i prelucrrii datelor necesare pentru prelucrarea datelor n vederea elaborrii informaiilor solicitate de nivelurile decizionale ale conducerii i controlului activitii ntreprinderii.
Principalele componente ale unui sistem informaional sunt: datele (totalitatea informaiilor prelucrate n cadrul ntreprinderii), informaiile (date suplimentare furnizate receptorului), fluxurile informaionale (totalitatea datelor i informaiilor care circul ntre dou posturi de lucru), circuitele informaionale (legturile dintre verigile ntreprinderii), procedurile informaionale (metodele i tehnicile de prezentare a datelor i informaiilor care asigur interfaa cu calculatorul), mijloacele de prelucrare i transmitere a informaiilor.
Tipologia sistemelor informaionale:
a) Sistemul informaional de procesare a datelor
Sistemul informaional de procesare a datelor reprezint un sistem de procesare a datelor cu ajutorul cruia sunt nregistrate calendaristic activitile zilnice, rutiniere, luate n calcul de ctre managementul unei ntreprinderi. Acest sistem informaional este folosit n ntreprinderile n care sarcinile de lucru sunt bine stabilite i se repet zilnic n acelai format. Informaiile oferite de acest sistem sunt colectate i utilizate de fiecare nivel operaional.
Sistemul informaional de procesare a datelor este folosit cu precdere pentru a monitoriza fluxurile comerciale cu furnizorii i clienii. n acest mod, sunt salvate n computer documente standardizate care sunt trimise n momentul derulrii tranzaciilor, avnd n vedere efectuarea de operaiuni standardizate.
b) Sistemul pentru automatizarea muncii de birou
Cu ajutorul acestui sistem informatic se ine evidena documentelor i mesajelor la nivel managerial. Avem de-a face astfel cu sistemul de procesare al textelor cu ajutorul cruia se efectueaz editarea, crearea i imprimarea documentelor de tip text. Un alt sistem des utilizat de ctre managementul ntreprinderii este sistemul de pot electronic cu ajutorul cruia se pot trimite cu uurin mesaje text, documente tipizate, poze, brouri, note de informare.
Tot n vederea uurrii muncii de birou se pot folosi mesageria vocal, comunicarea de grup pe cale electronic, calendarul electronic, notificri i reminder-uri electronice, memorie principal i secundar la calculator i telefon, teleconferine, videoconferine, fax, groupware.
Sistemul de automatizare a muncii de birou contribuie la creterea productivitii muncii, facilitnd accesul rapid la informaii, contribuind la grbirea contactrii potenialilor clieni, nlesnind comunicarea ntre diferii ageni economici la istane mari.
c) Sistemul informaional de management
Sistemul informaional de management reprezint un sistem informatic cu ajutorul cruia sunt generate rapoarte zilnice. Este utilizat cu precdere la nivel managerial. El permite accesul la unele rapoarte cotidiene, sau la rapoarte din decadele anterioare i sunt folosite pentru realizarea unor analize i previziuni. Se consult documentaia n vederea elaborrii unor strategii i tactici operaionale. Sistemul informaional de management permite compararea diferitelor tipuri de documente din diferite perioade, ajutnd la luarea unor decizii, planificarea i controlul unor activiti n vederea sporirii gradului de eficien al firmei.
n cazul ntreprinderilor mijlocii i mari, acest sistem informaional este utilizat i de managerii de la niveluri inferioare, genernd rapoarte cu privire la costuri, ncasri i pli, calitate, relaiile cu furnizorii i clienii.
d) Sisteme de fundamentare a deciziilor
Sistemul de fundamentare a deciziilor este utilizat la nivel managerial, aa cum i spune i numele, pentru fundamentarea deciziilor care nu au o structur bine determinat. Sunt utilizate pentru analizarea unor operaiuni, a unor procedee i nu n vederea lurii unor decizii ferme. Cu ajutorul acestui sistem de pot realiza ns analize amnunite, examinri ale unor procese complexe. Se faciliteaz comunicarea utilizatorului cu programele computerelor care controleaz i gestioneaz sistemul. De asemenea crete viteza de acces la date de la computerul care controleaz datele, ceea ce grbete procesul de analizare a datelor i formularea unor concluzii.
De asemenea, se poate apela la sistemul-expert, care este un bun sistem computerizat care ofer consultana computerizat a unui expert n vederea rezolvrii anumitor tipuri de probleme. Sistemul-expert se bazeaz pe inteligena artificial. Acest sistem este nc n stadiul de perfecionare. e) Sisteme suport ale managementului superior
Sistemul n cauz contribuie la derularea procesului decizional la nivel superior. El este utilizat cu precdere de ntreprinderile mari, care desfoar activiti pe mai multe niveluri ierarhice. El are n vedere proceduri generale de calcul, utilizarea de analize i interpretri grafice, diagrame, scheme logice, telecomunicaii. El permite accesul instantaneu la date i rezolvarea unor probleme pe cale interactiv. nglobeaz mai multe modele analitice. Sistemele suport ale managementului superior permit accesul la informaii de pe toate nivelurile ierarhice i soluionarea situaiilor speciale de la fiecare nivel. Ele copiaz modelul de lucru uman al unui manager.
Corelarea sistemelor informaionale cu sistemele informatice
Unul din componentele de baz ale sistemului informaional modern este dat de sistemul informatic. Deci, sistemul informaional nglobeaz sistemul informatic. Creterea rolului tehnologiei i automatizarea procesului de acces, prelucrare i transmitere a informaiilor determin creterea ponderii sistemului informatic n cadrul sistemului informaional.
Sistemul informatic reprezint acea component a sistemului informaional care faciliteaz utilizarea informaiilor intermediate de un calculator. Componentele de baz ale unui sistem informatic sunt: baza informaional, baza tehnic, sistemul de programe, baza tiinific i metodologic, utilizatorul uman, cadrul organizatoric. Sistemul de programe se refer la totalitatea programelor folosite pentru funcionarea sistemului informatic, n vederea atingerii scopurilor pentru care a fost conceput. Exist o gam variat de programe, de la cele care fac s ruleze componentele hardware, la cele de analiz i procesare a datelor. Tot aici se includ i software-urile aplicative (programe de contabilitate, programe de proiectare, programe de gestiune, etc).
Baza informaional cuprinde bazele de date care compun sistemul, fluxurile informaionale din cadrul sistemului, precum i nomenclaturile de coduri.
Baza tiinific i metodologic cuprinde algoritmi, formule, modele i tehnici de realizare a sistemelor informatice. Componentele sistemului informatic conin dou tipuri de elemente: elemente hardware i elemente software. Echipamentele hardware cuprind: calculatorul i echipamentele periferice (tastatur, cititor de cod de bare, scanner, imprimant,dispozitive de recunoatere vocal). Componentele software se refer la programele care fac utilizabile componentele hardware.
Bazele de date n Access
O baz de date poate fi definit ca o colecie de date elementare sau structurate care are menirea de a rspunde unui ansamblu integrat de subiecte, datele fiind organizate ntr-o form util care compun baza de informaii sau fundamentul pentru procedeul de identificare a informaiilor, de apreciere i de formulare a deciziilor.
Bazele de date se prezint sub forma unui tabel care cuprinde un ansamblu de informaii aranjate pe linii (care poart denumirea de nregistrri) i coloane (care poart denumirea de cmpuri sau rubrici). Avnd n vedere aceste consideraii, putem afirma c structura tabelar se preteaz perfect pentru crearea i stocarea unei baze de date. 1.2. Modelul Entitate-Asociere
O entitate este un lucru, obiect, persoan sau eveniment care are semnificaie pentru afacerea modelat, despre care trebuie s colectm i s memorm date. O entitate poate fi un lucru real, tangibil precum o cldire, o persoan, poate fi o activitate precum o programare sau o operaie, sau poate fi o noiune abstract.
O entitate este de fapt o clasa de obiecte i pentru orice entitate exist mai multe instane ale sale. Prin instana unei entiti nelegem un singur element, bine individualizat, unic, din mulimea elementelor care formeaz entitatea respectiv.
Entitatea are o structur de sine stttoare, caracterizat printr-o serie de proprieti proprii. n cadrul unei baze de date nu pot exista dou sau mai multe entiti cu acelai nume. Fiecare entitate are un singur nume i nu mai multe.
Tipurile de entiti definesc totalitatea entitilor care prezint aceleai caracteristici.
n cazul nostru avem urmtoarele tipuri de entiti:
clientul: este persoana fizica care dorete s i se presteze un anumit serviciu, i n baza incheierii unui contract. Atribute: cod_client, nume_cl, prenume_cl, adresa_cl, cont_cl, telefon_cl, cod_contract. societatea organizatoare: este entitatea contactat de ctre client pentru a organiza evenimentul i care desemneaz ctigtorul acesteia. Atribute: cod_tranzactie, obiect_contract, valoare. anunul de participare: este emis de ctre societatea organizatoare pentru a face public obiectul licitaiei. Atribute: cod_anunt, obiect_anunt, data_publicare, data_expirare, data_licitatie, moneda. condiiile de participare: condiiile care trebuie ndeplinite pentru a participa la licitaie. Atribute: cod_formular_inscriere, modalitate_participare, nr_ordine, data_nasterii, garantie.
participanii: persoane fizice care ndeplinesc condiiile de participare impuse de societatea organizatoare i care aplic la anunul de participare. Acetia au urmtoarele atribute: cod_participant, nume, prenume, adresa, cont, email.
licitatie: elementul n funcie de care se incheie contractul si care odata incheiat desemneaz ctigtorul. Atribute: cod_licitatie, nume_licitator.Clientul contacteaz o societate organizatoare care organizeaza licitatia. Aceasta emite un anun de participare la care aplic participanii care ndeplinesc condiiile de participare i care nu pot fi acelai cu clientul.
Tip entitate
Atribute
Realizri ale atributelor
Entitatea
Atributele entitiiCaracteristici atributeReguli
Clientcod_client
nume_cl
prenume_cl
adresa_cl
cont_cl
telefon_cl
cod_contractntreg lung, Numeric
Text 20
Text 20
Text 50
Text 50
Text 50
Text 10Cheie primar-0000
"RO"99LLLL9999999999999999"+40-"00\-000000#
Societatea organizatoarecod_tranzactie
obiect_contract
valoare
cod_anunt
cod_clientntreg lung, N
Text 30
ntreg lung, N
ntreg lung, Nntreg lung, NCheie primar
>=500
0000
Anunt participarecod_anunt
obiect_anunt
data_publicare
data_expirare
data_licitatie
moneda
cod_tranzactientreg lung, N
Text 50
Date/Time
Date /Time
Date /Time
Text 3
ntreg lung, NCheie primar
data_licitatie data_publicare>LLL
Conditii participarecod_formular_inscriere
modalitate_participare
nr_ordine
data_nasterii
garantie
cod_participantText 10
Text 50
ntreg lung, N
Date/Time
ntreg lung, N
ntreg lung, NCheie primar
personal or telefon or oferta scrisa or oferta online
=500
Participanticod_participant
nume
prenume
adresa (judet, loc, str)
cont
cod_anuntntreg lung, N
Text 20
Text 20
Text 50
Text 50
Hyperlink
ntreg lung, N Cheie primar
"RO"99LLLL9999999999999999
Licitatiecod_licitatie
nume_licitator
cod_tranzactie
cod_participantAutonumber
Text 20
ntreg lung, N
ntreg lung, NCheie primar
Atributul reprezint o caracteristic a unei entitti. Un atribut posed un nume i pentru fiecare instan a entitii poate lua o valoare dintr-o mulime fixate de valori, numit domeniul de valori ale atributului. Fiecare atribut prezint un domeniu (o muline de valori admise). Atributele pot cuprinde date simple (iruri de caractere, numere reale realizrile lor nu pot fi descompuse), sau pot face referire la obiecte complexe (realizrile lor pot fi descompuse n obiecte simple).
n funcie de complexitatea lor, avem atribute simple nu se mai pot descompune (exemplu: pre, cod_client, nume, prenume, cod_formular_inscriere, nr_ordine) i atribute decompozabile se pot descompune (exemplu: data_publicare, data_expirare, data_licitatie, adresa).
n funcie de realizrile pe care le pot efectua atributele, ntlnim: atribute obligatorii (obligatoriu trebuie s prezinte o realizare, neputnd nregistra valoare nulidentificatorii n tabele), atribute opionale (exist posibilitatea ca aceste atribute s nu prezinte nici o realizare n cadrul entitii, ca de exemplu: telefon, fax, email), atribute monovaloare (atributele nregistreaz o singur valoare n cadrul entitii; ex: cod_client, cod_licitatie, nr_ordine), atribute multivaloare (atribute care prezint mai multe valori n cadrul entitii: telefon, email).n cadrul lumii reale putem ntlni obiecte simple ale realitii. Pentru aceste obiecte simple se poate asocia cte o entitate n cazul modelrii conceptuale a datelor. n cazul nostru putem preciza, clientul care apeleaza pentru prestarea unui serviciu. Avem astfel n cazul tipului de entitate Client, entitatea (clientul) Moldovan Marius. n cadrul entitilor care prezint obiecte compuse, acestea pot fi descompuse n obiecte simple.
Exemplu: Tipuri de entitati
Obiect compus
Obiectele compuse sunt descompuse n obiecte simple. ntre acestea exist legtur. Obiectul compus este:
Conditii participare: descompus n Conditii participare (elemente de identificare a alegerilor pentru desemnarea participantilor licitatiei ) i Garantii (identificarea garantiilor solicitate) -caracteristici multivaloare (Garantie)Prezentarea identificatorilor n cadrul setului de atribute ale entitailorDenumire entitateDenumire identificator
clientcod_client
societatea organizatoarecod_tranzactie
anunt participarecod_anunt
conditii participarecod_formular_inscriere
participanticod_participant
licitatie
Fiecare tip de entitate prezint un identificator. Identificatorul reprezint un atribut sau un grup de atribute cu ajutorul crora se recunoate fiecare entitate.
Entitatea Client, este identificat prin cod client, deoarece fiecare client se difereniaz de celalalt (este necesar a se cunoate crui client i se presteaza serviciul).
Entitatea Societatea organizatoare, este identificat prin cod tranzactie, deoarece fiecare tranzactie incheiata se difereniaz de celelalte.
Entitatea Anunt participare are identificator cod anunt. Fiecare anunt publicat se distinge de celelalte prin codul de identificare al anuntului.
Entitatea Conditii participare are ca identificator cod formular inscriere prin care se arat fiecare formular de inregistrare aferent participantului care se inscrie la licitatie.
Entitatea Participanti are ca identificator cod participant, prin care fiecare participant este recunoscut i difereniat de ceilalti.Entitatea Licitatie are ca identificator cod licitatie prin care fiecare criteriu se diferenteaza de celelalte licitatii care au avut loc.
Asocierea dintre entiti arat legtura care se stabilete ntre acestea n cadrul bazei de date. n cadrul asocierilor n Access putem vorbi de cardinaliti. Cardinalitile nu au structur independent, de sine stttoare.
Numrul de elemente din cadrul unei entiti care este implicat ntr-o asociere se numete cardinalitatea asocierii fa de entitatea respectiv. Cardinalitatea este de tipul (x,y), unde prima coordonat arat numrul minim de realizri care se pot efectua n cadrul asocierii, iar cea de-a doua coordonat arat numrul maxim de realizri care pot aprea n cadrul asocierii.
Cardinalitatea cu valoare 0 prezint realizri de entiti care nu fac parte din asocierea celor dou (sau mai multe) entiti.
Cardinalitatea cu valoare 1 prezint realizri de entiti care particip la o singur asociere a entitii.
Cardinalitatea cu valoare n - prezint realizri de entiti care particip la mai multe asocieri de entiti.
Tipuri de asocieri:
Societatea organizatoare (1,n) Licitatie (1,1) 1,n societatea organizeaza 1 licitatie sau n licitatii
1,1 fiecare licitatie apartine (este organizata) de o societate organizatoare
Client (1,1) Societatea organizatoare (1,n) 1,1 clientul contacteaza o societate organizatorica
1,n societatea este contactata de unul sau mai multi clienti
Participanti (1,n) Conditii participare (0,n) 1,n participantii indeplinesc o conditie de participare sau n conditii
0,n conditiile de participare sunt indeplinite de 0 participanti sau de n participanti
Anunt participare (0,n) Participanti (0,n) 0,n anuntul este aplicat de 0 participanti sau de n participanti
0,n participantii aplica la 0 anunturi de participare sau la n anunturi de participare
Putem identifica mai multe tipuri de asocieri realizate ntre tipurile de entiti existente. Astfel avem: asocieri reflexive (adic ciclice, n jurul aceluiai tip de entitate), asocieri binare (ntre dou tipuri de asocieri diferite) i asocieri complexe (ntre mai multe tipuri de entiti diferite). De exemplu, ntre tipul de entitate Client i tipul de entitate Societatea organizatoare se realizeaz asocierea contacteaza.n cadrul proiectrii bazei noastre de date au fost folosite asocieri (relationships) ntre mulimile de entiti, utiliznd asocieri binare.Restricii de integritate
Dup modelarea bazei de date la nivel structural (definirea entitilor, atributelor lor i a relaiilor dintre ele), urmeaz nivelul operaional al modelrii:
- stabilirea tipurilor de operaii care se pot efectua asupra datelor stocate (sortare, cutare, vizualizare, adugare, tergere, modificare etc.);
- verificarea respectrii regulilor de integritate (ceea ce va asigura corectitudinea i consistena datelor).Restricii de integritate definesc condiiile pe care trebuie s le satisfac datele din baza de date astfel nct acestea s corespund realitii economice la care se refer. Restriciile de integritate fac referire la:
Valorile pe care le pot lua atributele entitii i asocierii
Valoarea identificatorilor entitii
Rolurile jucate de entiti n asocierile la care particip
Asocierile stabilite ntre entiti
Exist mai multe tipuri de restricii de integritate i anume: restricii de domeniu, restricii structurale, restricii de integritate de roluri, restricii de integritate de asocieri.
De asemenea, restriciile de integritate pot fi statice (se verific ntotdeauna, indiferent de evoluia datelor din baza de date) i restricii dinamice (se modific n raport cu evoluia n timp a datelor).
Resticii de domeniu
Restriciile de domeniu se refer la valorile pe care le iau datele, indiferent de componenta de timp. Exemple: codul clientului de identificare trebuie s fie format ntotdeauna din 4 cifre
valoarea contractului >=500
data expirare data licitatie
moneda trebuie s fie exprimat conform standardelor internationale de tipul ROL, USD, EUR, etc.
modalitatea de participare poate fi personal sau telefon sau oferta scrisa sau oferta onlineRestricii structurale
fiecare entitate trebuie s fie identificat fr echivoc, se presupune c identificatorul entitii ia valori unice diferite de NULL.
fiecare entitate este identificat printr-un identificator unic care prezint proprietatea Indexed Yes (No Duplicates).
Restricii de integritate de roluri
Restricii de incluziune de roluri
Dac o entitate E1 joac rolul r1n asocierea A1, atunci va trebui s joace i rolul r2 n asocierea A2. r1
r2. Ex: Societatea trebuie sa fie prima data contactata, pentru a putea fi emitenta.
Restricii de integritate de asocieriAceste restricii impun condiii care acioneaz asupra tuturor rolurilor dintr-o asociere; cu alte cuvinte, este vizat asocierea i toate entitile participante i nu numai participarea unei anumite entiti, ca n cazul anterior. Restricia de incluziune de asocieri
Asocierea A1 stabilit ntre dou entiti va determina existena unei alte asocieri A2 n cadrul modelului Entitate-Asociere.
Exemplu: doar participanii care ndeplinesc condiiile de participare pot aplica la anuntul de participare. Tipul de asociere aplic este determinat de existena tipului de asociere indeplinete (participantul nu poate aplica la anuntul de participare dac nu a indeplinit criteriile de participare).
Restricia de excluziune de asocieri
Asocierile aparinnd tipului de asociere A1 exclud asocierile aparinnd tipului A2.Exemplu: persoana (clientul) care contacteaz societatea organizatoare nu poate s aplice si la anunul de participare in acelasi timp. Restricia de egalitate de asocieri
Asocierile aparinnd tipului A1 determin existena asocierilor aparinnd tipului A2 i invers.
MODELUL EA
1.3. Dependene funcionale O dependenta functionala evidentiaza raporturile de determinare stabilite intre atributele unei entitati .Un exemplu de dependenta functionala completa ce poate fi intalnita:
Ex: Dependena nume_cl, prenume_cl ( adresa_cl este total deoarece eliminnd pe oricare dintre atributele din stnga nu mai avem o dependen: Panta Andreea locuieste in Sibiu, Sibiu, Calugareni 10 , iar Bucur Andreea locuieste in Sibiu, Sibiu, Frunzei 1; dac nlturm atributul Nume_cl vom avea: Andreea i pentru Calugareni 10 i pentru Frunzei 1.
Un exemplu de dependenta functionala partiala ce poate fi intalnita:
Ex: cod_formular_inscriere, nr_ordine ( cod_participant este o dependen funcional parial, practic fiecare act completat identificat prin cod_formular_inscriere aparine unui singur participant, respectiv un nr de ordine aparine de asemenea unui singur participant. Dac eliminm fie cod_formular_inscriere sau nr_ordine dependena se menine.
MATRICEA SIMPLIFICAT A DEPENDENELOR FUNCIONALE
Determinani
Atribute18111723281+88+17
1. cod_client1
2. nume_cl1
3. prenume_cl1
4. adresa_cl1
5. cont_cl1
6. telefon_cl1
7. cod_contract1
8. cod_tranzactie11
9. obiect_contract11
10. valoare1
11. cod_anunt11
12. obiect_anunt1
13. data_publicare1
14. data_expirare1
15. data_licitatie1
16. moneda1
17. cod_participant11
18. nume1
19. prenume1
20. adresa1
21. cont1
22. email1
23. cod_formular_inscriere11
24. modalitate_participare1
25. nr_ordine1
26. data_nasterii1
27. garantie1
28. cod_licitatie111
29. nume_licitator1
30. pret_castigator1
Determinani
Atribute1234567891011121314151617181920212223242526272829301+88+17
1. cod_client1
2. nume_cl11
3. prenume_cl11
4. adresa_cl11
5. cont_cl11
6. telefon_cl11
7.cod_contract11
8. cod_tranzactie11
9. obiect_contract111
10.valoare11
11.cod_anunt11
12. obiect_anunt11
13. data_publicare11
14. data_expirare11
15. data_licitatie11
16. moneda11
17. cod_participant11
18. nume11
19. prenume11
20. adresa11
21. cont11
22. email11
23. cod_formular_inscriere11
24. modalitate_participare11
25. nr_ordine11
26. data_nasterii11
27. garantie11
28. cod_licitatie111
29. nume_licitator11
30.pret_castigator11
MATRICEA COMPLET A DEPENDENELOR FUNCIONALE
Reguli
I ) de verificare a MCD
a) regula de unicitate a numelor entitatilor- se respecta (numele entitatilor din modelul Licitatii sunt diferite: Clienti, Societatea organizatoare, Anunt participare, Participanti, Conditii participare, Licitatie)
b) regula unicitatii atributelor : ex. Atributele cod_client, nume_cl definesc entitatea Client si numai pe ea, atribute precum cod_licitatie si nume_licitator definesc entitatea Licitatie etc.
c) regula proprietatilor si determinantului unei entitati precizeaza ca un atribut (ex. cod_contract) este determinat de mai multi determinanti (ex. cod_client si cod_tranzactie)
d) regula atributelor derivabile: se recomanda evitarea lor in cadrul MCD, se justifica doar daca au relevanta si frecventa in utilizare.
e) regula atributelor decompozabile : in cadrul licitatiilor pot fi folosite atribute decompozabile (ex. adresa ) deoarece prelucrarea lor nu presupune descompunerea pe elemente componente;
f) regula minimizarii identificatorilor : ex. cod_client, cod_anunt, cod_participant, cod_licitatie.
II) de normalizare a MCD
Regula nr. 1 (FN1): Fiecare entitate trebuie s prezinte un identificator prezentnd realizri unice, nenule. Exemplu: Entitatea Client, identificator cod_client;
Entitatea Participanti, identificator cod_participant; Regula nr. 2 (FN2): Toate atributele entitii, altele dect identificatorul, trebuie s fie n dependen funcional complet i direct cu identificatorul entitii. Exemplu: Entitatea Client, identificator cod_formular_inscriere, atribute cu dependena funcional nume, prenume.Regula nr. 3 (FN3): Toate atributele unei asocieri trebuie s depind complet de dentificatorul asocierii (identificatorii entitilor participante la asociere) iar fiecare atribut trebuie s depind de ntregul identificator i nu de o parte a acestuia. Exemplu: La nivelul entitatii Conditii participare nu are rost sa stocam un alt camp numit varsta, deoarece avem data_nasterii.
Capitolul 2. Modelarea conceptual a prelucrrilorRolul modelrii conceptuale a prelucrrilor
Modelul conceptual al prelucrrilor prezint succesiunea n timp a operaiilor de cutare la care este supus modelul conceptual al datelor, i anume:
- ce trebuie fcut la nivel conceptual
- cine, cnd i unde se realizeaz aceste prelucrri (conceptual organizaional);
- cum se vor realize ele n mod concret (conceptual fizic);
- are drept scop s descrie coninutul (ce operaii? Ce rezultate?) i dinamica (derularea n timp) a unei prelucrri ntr-o manier independent de utilizare a mijloacelor utilizate.Modelul conceptual al prelucrrilor este modelul "eveniment-rezultat" al metodei Merise, ce propune n discuie procedurile (elementele) abordate de MCD formulnd pentru fiecare element ntrebri de forma:
- acest element este in dispensabil i ce se ntmpl daca l suprimm;
- exist posibilitatea de a-l suprima (se acord atenie i normelor juridice i reglemantrilor legale);- ct cost meninerea acestui elemet n procedur sau ce avantaje se obin din meninerea lui.
Modelul conceptual al prelucrrilor, vede ntreaga prelucrare ca o succesiune ordonat si logic de proceduri nlnuite, toate n concordan strict cu legislaia n vigoare.
Conceptul de prelucrare reprezint:
partea dinamic a sistemului informaional;
materializarea sub form de aciuni a regulilor de gestiune specifice activitii ntreprinderii;Concepte n cadrul bazei de date abordate dup Modelul Prelucrrii Conceptuale a Datelor (MCP)Formalismul modelelor de prelucrare se bazeaz pe realizarea unei diagrame simplificate care s ilustreze fenomenul analizat.
Astfel, evenimentul declanator va fi reprezentat printr-o eclips. Operaia va fi reprezentat grafic printr-un dreptunghi, evenimentul emis la fel printr-o eclips, iar sincronizarea printr-un dreptunghi orientat ctre operaie.Etapa I. Definirea domeniului investigat
depunerea cererii si a formularului pentru licitatie
intocmirea dosarului de licitatie
realizarea licitatiei
Participanti:a) CLIENTUL: contacteaz autoritatea organizatoare n vederea stabilirii detaliilor referitoare la organizarea licitaiei prin intermediul cererii de organizare a licitaiei, punnd la dispoziia acesteia informaiile de baz cu privire la obiectul licitaiei i condiiile de realizare a acesteia prin intermediul formularului de ofert.
b) SOCIETATEA ORGANIZATOARE: preia cererea i formularul, ntocmete dosarul de licitaie, analizeaz condiiile, stabilete criteriile de participare, emite anunul de participare, preia ofertele si realizeaza licitatia.Evenimentul
Evenimentul declanator
Evenimentul declanator desemneaz un fapt a crui apariie declaneaz o reacie n cadrul organizaiei; apariia unui eveniment va antrena derularea de activiti, de operaii, reprezentnd motorul unei aciuni, al unei operaii.
Elementul declanator trebuie s fie independent de aspectele organizatorice i tehnologice care in de firm.
n cadrul aplicaiei noastre, elementul declanator este reprezentat de sosirea unei comenzi de la un client. Este un element de natur extern, care nu este determinat de operaiunile care au loc n firm. A satisface aceast cerere nseamn a o transforma ntr-o livrare de produse.Tipul evenimentului
Tipul evenimentului reprezint un concept generic ce descrie toate apariiile evenimentelor de aceeai natur. Capacitatea sistemului de a percepe aceste apariii este exprimat prin doi parametrii: capacitatea evenimentului (indic numrul maxim de apariii ale acestui tip de eveniment care pot fi percepute de sistem prin convenie vom presupune c aceasta ia valori de pn la infinit, altfel am spune c sistemul nu are capacitate s opereze livrarea comenzilor dect restricionat pentru un anumit numr de comenzi) i frecvena evenimentului (indic legea de manifestare a acestor apariii).
Exist o serie de convenii de reprezentare a tipurilor de evenimente permind delimitarea celor externe de cele interne, intermediare i rezultat;
Pentru a avea un eveniment trebuie s coexiste anumite condiii:
- s se ntmple ceva (n afara sau n interiorul ntreprinderii)
- acest ceva trebuie sa fie perceput de sistem (care trebuie s fie dotat cu mijloace capabile s l perceap)
- ntreprinderea s fie interesat, vznd n el un posibil eveniment declanator al activitii sale.
Evenimentul emis (rezultatul)
Evenimentul emis se refer la produsul executrii unei operaii. Ooperaie produce unul sau mai multe rezultate. Descompunerea unei operaii n mai multe operaii distincte implic apariia unor rezultate intermediare. Un eveniment emis poate fi n acelai timp un eveniment declanator pentru o alt operaie (sau alte operaii). De aceea se i utilizeaz acelai formalism.
n cadrul Modelrii Conceptuale a Prelucrrilor, trebuie s se in cont de cteva reguli:
descompunerea unei operaii n mai multe operaii distincte implic apariia unor rezultate intermediare
un eveniment emis poate fi n acelai timp un eveniment declanator pentru o alt operaie sau alte operaii
toate operaiile trebuie s aib un rezultat obinerea unuia sau mai multor rezultate poate fi condiionat de ndeplinirea unor condiii
Etapa II. Stabilirea evenimentelor identificate
E1: depunerea cererii i a formularului.
E2: verificarea cererii i a formularului.E3: depunerea si verificarea documentelor care fac dovada dobandirii.E4: cerere acceptat.
E5: cerere respins.
E6: notificare client.
E7: clientul este nregistrat n baza de date
E8: client nou ( nenregistrat n baza de date)
E9: client nou nregistrat n baza de date
E10: ntocmirea dosarului de licitaie.
E11: stabilirea criteriilor de participare.
E12: emiterea anunului de participare.E13: realizarea licitatiei.Etapa III. ntocmirea tabloului evenimente- rezultate;NR. CRT.EVENIMENTE DECLANATOAREACIUNI EXECUTATEEVENIMENTE REZULTATE
1. Depunerea cererii i a formularului.Preluarea cererii i a formularului.Verificarea cererii i a formularului.
2. Verificarea cererii i a formularului.Analiza informaiilor cuprinse n cerere i n formular.Cerere acceptat sau cerere respins.
3. Cerere acceptat.Verificarea existenei clientului n baza de dateClient nousau client nregistratnbaza de date
4. Client nounregistrare client n baza de dateClient nou nregistrat
5. Client existent n baza de date sau client nou nregistratSemnarea contractului n vederea sustinerii licitaiei.ntocmirea dosarului de licitaie.
6. ntocmirea dosarului de licitaie.Analiza informaiilor cuprinse n dosar.Stabilirea criteriilor de participare.
7. Stabilirea criteriilor de participare.Introducerea n baza de date.Emiterea anunului de participare.
8. Emiterea anunului de participare.Preluarea ofertelor.Realizarea licitaiei.
Operaia
Operaia reprezint o secven continu de aciuni elementare productoare de evenimente care se execut nentrerupt din momentul declanrii ei de ctre unul sau mai multe evenimente.
Etapa IV. Identificarea operatiilor
OP1: Preluarea cererii i a formularului.
OP2: Analiza informaiilor cuprinse n cerere i n formular.OP3: Verificarea existenei clientului n baza de date.OP4: Abandonarea procedurii.OP5: nregistrare client n baza de date.OP6: Semnarea contractului n vederea sustinerii licitaiei.
OP7: Analiza informaiilor cuprinse n dosar.
OP8: Introducere n baza de date.
OP9: Preluarea ofertelor i realizarea licitaiei.
Etapa V. Identificarea sincronizrilor
Sincronizrile prezente la nivelului MCD sunt reprezentate de operatorii logici i/sau.
Exemplu: Cerere acceptat sau cerere respins
Client nou sau client nregistrat n baza de dateEtapa VI. Identificarea regulilor de emisie
Regula de emisie este dat printr-o propoziie logic care dac se dovedete adevrat va determina producerea unui anumit eveniment. Regula de emisie reprezint expresia condiiilor referitoare la contextul n care se va bderula operaia.Cele dou reguli de baz care trebuie luate n considerare n construirea modelului conceptual al prelucrrilor sunt:
Regula 1
O operaie este o succesiune nentrerupt de prelucrri.
Orice intervenie a unui actor extern care conduce la o ntrerupere, determin o decupare a operaiei.
Regula 2
n interiorul unei operaii nu se admite producerea unui rezultat intermediar care s condiioneze derularea operaiilor procesului (operaia trebuie s fie omogen n raport cu evenimentele pe care le genereaz).OP 2 Clientul va putea primi aprobarea prin cererea si formularul depus doar n cazul n care acesta respecta cerintele Regulamentului de participare la licitatie. Clientul depune cererea si formularul, iar departamentele societatii proceseaz cererea i verific acuratetea informatiilor. n cazul n care regula de emisie este ndeplinit, se vor continua procedurile obisnuite.
OP 3 Se verific dac clientul care dorete prestarea serviciului este nregistrat sau nu n baza de date. n cazul n care acesta nu este nregistrat n baza de date, se va efectua nregistrarea lui.
OP 2Analiza informaiilor cuprinse n cerere i n formular
Se verific acuratetea informatiilor cuprinse in cerere si formular
Dosar corectDosar gresit
OP 3Verificare existen client
Se verific existena clientului n baza de date
ExistNu exist
Tabel 7. Reguli de emisie
OperaieReguli de emisie
Operaia 2R2,1 Se verifica acuratetea informatiilor din cerere si formular
Operaia 3R3,1 Clientul este nregistrat n baza de date a societii
Etapa VII. Elaborarea modelului conceptual al prelucrrilor
ORGANIZAREA
OP 1Preluarea cererii i a formularului
Preluarea cererii i a formularului in legatura cu serviciul ce se doreste a fi prestat
OP 4Abandonarea procedurii
Abandonarea procedurii deoarece informatiile nu sunt corecte
OP 3Verificare existen client
Verificarea existenei clientului n baza de date
NOT OKOK
OP 5nregistrare client nou
nregistrarea noului client n baza de date
OP 6Semnarea conveniei n vederea continurii
Semnarea conveniei n vederea continurii licitatiei
OP 7Analiza informaiilor cuprinse n dosar
Analiza informaiilor cuprinse n dosar in vederea stabilirii criteriilor de eligibilitate
OP 8Introducere n baza de date
Introducere n baza de date a criteriilor de eligibilitate
OP 9Preluarea ofertelor
Preluarea ofertelor de la participanti
Capitolul 3. Modelarea logica a datelor
Baza de date reprezint un model al lumii reale i nu poate reprezenta decat un numr limitat de caracteristici ale ei necesare n unele aplicaii. Orict de perfecionat ar fi modelul utilizat, exist aplicaii care se pot concepe astfel nct s nu poat fi satisfcute de baza de date. Deci apar interpretri subiective ale lumii reale reflectate n baza de date.
Trecerea de la Modelul Conceptual al Datelor la Modelul Logic al Datelor presupune respectarea unor reguli:
Regula 1 Fiecare tip de entitate se transform ntr-un tabel, primind ca denumire a coloanelor numele atributelor din care este format acel tip de entitate, iar identificatorul tipului de entitate se va transforma n cheia primar a tabelului respectiv. Un tabel este perceput ca o asociere ntre mai multe atribute care caracterizeaz acelai tip de entitateRegula 2 n cazul n care dou tipuri de entiti prezint pentru o asociere cardinalitatea (1,1), n mod normal fiecare entitate poate primi drept cheie extern, cheia primar a celeilalte entitai. n realitate se ine cont de ordinea de apariie a fiecrui tip de entitate. Cheile externe se simbolizeaz n MLD prin subliniere cu o linie punctat.Regula 3 n cazul n care dou tipuri de entitate au o asociere de tipul (1,n), cheia primar a tabelei care prezint la asociere cardinalitatea (1,n) va deveni cheie extern n tabela care prezint la asociere cardinalitatea (1,1).Regula 4 n cazul n care dou entiti prezint o asociere de tipul (n,m), asocierea n sine se transform ntr-o tabel avnd obligatoriu drept chei externe cheile primare ale celor dou tabele.Modelul relaionalRelaia Relaiile se prezint sub form tabelar, cu linii i coloane. Modelul relaional mai poart i denumirea de tabel.
Relatii intre tabele
Tuplul n cazul tabelelor, tuplul reprezint una din liniile tabelei. Este dat de nregistrrile din tabel.
Tabela Clienti
Domeniul
Domeniul reprezint un set de valori pe care le poate lua un atribut. Spre exemplu, atributul Jude din tabela Clienti poate lua mai multe valori: Sibiu, Bucureti, etc.
Atributul
Atributul reprezint o submulime a unui domeniu creia i s-a dat un nume. Numele exprim rolul sau semnificaiaatribuit elementelor domeniului respectiv. Atributul reprezint capul de tabel. Atributul reprezint o caracteristic n cadrul unui domeniu, fiecrei caracteristici fiindu-i asociat o coloan n cadrul relaiei. Att atributele, ct i valorile pe care le iau atributele corespund caracteristicilor din lumea real.
Atributul
Cheia primar
Cheia primar reprezint cmpul sau grupul de cmpuri care ia valori unice i nenule care are rolul de identificator al nregistrrilor unui tabel. Fiecare tabel trebuie s aib o cheie primar. Realizrile cheii primare permit identificarea unic a unui tuplu din tabel.
Cheia primara Fiecare tabel va conine n mod obligatoriu o cheie primar. Acest atribut, cunoscut sub denumirea de primary key are rol de identificare unic a nregistrrii. n situaia n care utilizatorul nu a setat cheia primar, aceasta va fi realizat automat de ctre program prin atribuirea tipului AutoNumber unui cmp nou creat. Cheia primar este un index. Pentru vizualizarea indecilor dintr-o tabel, se activeaz opiunea Indexes din meniul View.
n cmpul Index Name apare menionat c este vorba de o cheie primar (primary key), n cmpul Field Name sunt menionat ecmpurile care joac rol de cheie primar, iar n Sort Order, nregistrrile apar ntotdeauna ascendent.
Proprietatea Primary opiunea Yes arat c resectivul index constituie o cheie primar.
Proprietatea Unique opiunea Yes arat c indexul poatelua o valoare unic
Proprietatea Ignore Nulls opiunea No deoarece cheia primar nu poate lua valori nule
Cheia extern
Cheia extern joac rol de cheie primar ntr-unul sau mai multe tabele. Ea nu este definit explicit de program ca fiind cheie extern. Cheia extern se folosete pentru legarea unui tabel cu un alt tabel (n care respectivul atribut joac rol de cheie primar). Valorile associate cheii externe vor fi nule sau duplicate ale cheii primare.
Cheia externantre legtura dintre tabelul cu cheia primar i tabelul cu cheia extern se realizeaz o restricie de integritate referenial (adic, cele dou tabele sunt legate printr-un cmp comun, astfel nct valorile atributului cu rol de cheie extern se regsesc n domeniul cheii primare).
Cheia candidat
Cheia candidat reprezint un cmp, altul dect cheia primar care ndeplinete condiiile necesare pentru a deveni cheie primar. Prin realizrile lor, cheile candidat pot identifica un tuplu. Din cadrul cheilor candidat se va alege cheia primar.
n exemplul nostru putem nominaliza pe post de cheie candidat urmtoarele atribute:
Tabela Clienti: NumeClient
Tabela Participanti: NumeParticipant
Conditii de participare: NrOrdineSchema unei relaii: Schema unei relaii reprezint lista atributelor unui tabel mpreun cu domeniile pe care le cuprinde. Gradul unei relaii
Gradul unei relaii este dat de numrul de atribute (coloane) ale relaiei.
Cardinalitatea relaiei
Cardinalitatea relaiei este dat de numrul de tupluri (linii) din cadrul tabelei.
Tabela Anunt participare Schema relaiei: Anunt participare (cod_anunt, obiect_anunt, data_publicare, data_expirare, data_licitatie, moneda, cod_tranzactie)
Cheia primar: cod_anunt Gradul relaiei: 7 Cardinalitatea relaiei: 11
Reguli de trecere de la modelul EA la schema bazei de date relaionale
Regula 1
Fiecrui tip de entitate din cadrul modelului Entitate-Asociere i este asociat schema unei relaii format din toate atributele tipului de entitate. Identificatorul tipului de entitate devine cheia primar a relaiei.
Regula 2
dac ntr-o asociere binar A fiecare dintre entiti prezint pentru cuplul entitate-asociere cardinalitatea (0,1) sau (1,1) se adaug n schema relaiei R1 corespunznd entitii E1 cheia primar a celeilalte relaii, R2 corespunztoare entitii E2 participante la asociere;
cheia extern va trebui s respecte restricia de integritate referenial.Regula 3
Dac ntr-o asociere de dou entiti, doar una dintre entiti (E1) prezint cardinalitatea (0,1) sau (1,1), se adaug n schema relaiei R1 ce corespunde entitii E1 cheia primar a relaiei R2 care corespunde celei de a doua entiti (E2) din cadrul asocierii.
Trecerea cheii relaiei R2 n schema relaiei R1 (aici va juca rol de cheie extern) este determinat de rolul dominant al rimei relaii (R1) asupra celei de-a doua relaii (R2).
Regula 4
n cazul n care ntr-o asocier ede dou entiti, cardinalitile sunt doar de tip (0,n) i (1,n), se va defini o a treia relaie care va cuprinde cheile primare ale celor dou entiti.
Capitolul 4. Crearea bazei de dateDeschiderea bazei de date
Se va urma urmtoarea cale: Start Microsoft Office Micresoft Office Access
Pornirea aplicaiei Microsoft AccessCrearea bazei de dateSe va alege opiunea Blank Database. Numele bazei de date se va nscrie n colul din stnga, jos i se va procesa butonul Create.
Crearea tabelelor
Din meniu se va alege opiunea Create Table, dup care se introduc cmpurile.
Tabela Anunt participareIntroducerea restriciilor (Validation Rule), formatarea tabelului, introducerea Input Mask, setarea cheii primare (Primary key)
Proprietile tabelelor
Crearea legturilor dintre tabelele bazei de date
Din meniu opiunea Database Tools Design, sau Table Relationships, prin tragere cu mouse-ul (tehnica drig-drag).
Legturile dintre tabeleRealizarea interogrilor
Din meniu opiunea Create Query Design
InterogriLa rubrica Table se va alege tabelul n care se va crea interogarea;
La rubrica Field se va alege cmpul/cmpurile asupa crora se va realiza interogarea;
La rubrica Sort se va preciza dac sortarea se va realiza dup criteriul ascendent sau descendent;
La rubrica Criteria se va preciza criteriul dup care se realizeaz interogarea.
Crearea formularelor
Crearea rapoartelor
Raport Access
Unde:
1. cod_ois2. den_unitate
3. dir_executiv
4. manager_relatii
5. interior_ub
6. cod_solicitare
7. tip_solicitare
8. den_client
9. suc_balanta
10. doc_atasate
11. comentarii_initiator
12. SIP
13. nume
14. prenume
15. telefon
16. functie
17. sal_brut
18. user
19. parola
20. CIC
21. adresa
22. telefon
23. tip_client
24. data_infiintare
25. nr_registru26. tip_registru
27. cod_CAEN
28. adresa_email
29. cod_indicator
30. cap_social
31. marime
32. garantare
33. nr_angajati
34. CA
35. nr_puncte
36. cod_cont
37. cont_contabil
38. valuta
39. den_cont
40. cod_IBAN
41. CIC_PF
42. nume
43. prenume
44. telefon
45. adresa
46. tip_semnatura
Diagrama dependenelor funcionaleorganizeaza
1,n
1,1
emite
contacteaza
1,n
SOCIETATEA ORGANIZATOARE
cod_tranzactie
obiect_contract
valoare
ANUNT PARTICIPARE
cod_anunt
obiect_anunt
data_publicare
data_expirare
data_licitatie
moneda
1,1
CLIENT
cod_client
nume_cl
prenume_cl
adresa_cl
cont_cl
telefon_cl
cod_contract
#
I
ANGAJATI
SIP
Cod_solicitare
Nume
Prenume
Telefon
Functie
Sal_brut
User
Parola
Garantii cerute
Nr_doc
Tip_document
Suma
Conditii participare
Cod_formular_inscriere
Modalitate_paticipare
Nr_ordine
Data_nasterii
Garantie
Criterii de eligibilitate
Cod_formular_inscriere
Modalitate_participare
Nr_ordine
Data_nasterii
CLIENT
cod_client
nume_cl
prenume_cl
judet_cl
localitatea_cl adresa
strada_cl
cont_cl
telefon_cl
cod_contract
4111
Moldovan
Marius
Sibiu
Sibiu
Bihorului5
RO65BTRL8973890284930475
+40-74-7549919
moldovan01
concureaza
pret_castigator
0,n
0,n
1,1
aplica
indeplinesc
1,1
1,n
stabileste
0,n
1,n
0,n
0,n
PARTICIPANTI
cod_participant
nume
prenume
adresa
cont
CONDITII PARTICIPARE
cod_formular_inscriere
modalitate_participare
nr_ordine
data_nasterii
garantie
1,n
priveste
0,n
1,1
LICITATIE
cod_licitatie
nume_licitator
Abandonare
procedur
Continuare procedur
Introducere client
Se trece la etapa urmtoare
E1
E3
E2
E2 i E3
OP2
Analiza informaiilor cuprinse n cerere i formular
DOSAR NTOCMIT CORECT (Se verifica completitudinea si continutul informatiilor din cerere si formular)
OK
NOT OK
E5
E4
E6
E8
E7
E9
E7 sau E9
E10
E11
E12
E13
CLIENT
cod_client
nume
prenume
adresa
cont
telefon
cod_contract
Client (cod_client, nume, prenume, adresa, cont, telefon, cod_contract)
Societatea organizatoare (cod_tranzactie, obiect_contract, valoare)
SOCIETATEA ORGANIZATOARE
cod_tranzactie
obiect_contract
valoare
ANUNT PARTICIPARE
cod_anunt
obiect_anunt
data_publicare
data_expirare
data_licitatie
moneda
Anunt participare (cod_anunt, obiect_anunt, data_publicare, data_expirare, data_licitatie, moneda )
Participanti (cod_participant, nume, prenume, adresa, cont, email)
PARTICIPANTI
cod_participant
nume
prenume
adresa
cont
CONDITII PARTICIPARE
cod_formular_inscriere
modalitate_participare
nr_ordine
data_nasterii
garantie
Conditii participare (cod_formular_inscriere, modalitate_participare, nr_ordine, data_nasterii, garantie)
LICITATIE
cod_licitatie
nume_licitator
Licitatie ( cod_licitatie, nume_licitator)
PretCastigator (cod_licitatie, cod_participant, pret)
PretCastigator
cod_licitatie
cod_participant
pret
SOCIETATEA ORGANIZATOARE
cod_tranzactie
obiect_contract
valoare
CLIENT
cod_client
nume
prenume
adresa
cont
telefon
cod_contract
1,n
1,1
contacteaza
Client (cod_client, nume, prenume, adresa, cont, telefon, cod_contract, cod_tranzactie)
Societatea organizatorica (cod_tranzactie, obiect_contract, valoare)
cod_client cheie extern n tabela Societatea organizatoare, cheie primar n tabela Client
SOCIETATEA ORGANIZATOARE
cod_tranzactie
obiect_contract
valoare
ANUNT PARTICIPARE
cod_anunt
obiect_anunt
data_publicare
data_expirare
data_licitatie
moneda
1,1
1,n
emite
Societatea organizatorica (cod_tranzactie, obiect_contract, valoare)
Anunt participare (cod_anunt, obiect_anunt, data_publicare, data_expirare, data_licitatie, moneda, cod_tranzactie)
CONDITII PARTICIPARE
cod_formular_inscriere
modalitate_participare
nr_ordine
data_nasterii
garantie
SOCIETATEA ORGANIZATOARE
cod_tranzactie
obiect_contract
valoare
stabileste
1,1
1,n
Societatea organizatorica (cod_tranzactie, obiect_contract, valoare)
Conditii participare (cod_formular_inscriere, modalitate_participare, nr_ordine, data_nasterii, garantie, cod_tranzactie)
CONDITII PARTICIPARE
cod_formular_inscriere
modalitate_participare
nr_ordine
data_nasterii
garantie
PARTICIPANTI
cod_participant
nume
prenume
adresa
cont
0,n
1,n
indeplinesc
Conditii participare (cod_formular_inscriere, modalitate_participare, nr_ordine, data_nasterii, garantie)
Participanti (cod_participant, nume, prenume, adresa, cont, email)
Indeplinesc (cod_participant, cod_formular_inscriere)
Crearea bazei de date
Formular Access
Mihescu Liviu, Tehnologia informaiei i fundamentarea deciziilor de firm, Ed.Universitii Lucian Blaga, Sibiu, 2009, pag.36-38