Modelarea Bazelor de Date Folosind Diagrame E R Si Aplicatii

Modelarea bazelor de date folosind diagrame E-R și aplicații

I CURPRINS

Introducere…………………………………………………………………Pagina 1

Capitolul 1 Concepte fundamentale …………………………………Pagina 2

1.1 Bazele de date……………………………………………………….………..Pagina 2

1.2 Limbajul SQL……………………………………………………… ……….Pagina 3

1. 3 Diagramele ER………………………………………………………. …….Pagina 4

Capitolul 2 Diagramele E-R utilizate in aplicații ………………….Pagina 5

2.1 Nivele Diagramelor ER……………………………………………………….Pagina 5

2.2 Utilizarea E-R si aplicații…………………………………………………….Pagina 7

2.3 Aplicație practica cu bazelor de date si diagrame E-R….. ………..……Pagina 8

Concluzii……………………………………………….……………………..Pagina 14

Bibliografie ………………………………………………………………….Pagina 15

Proiect Analiza sistemelor informaționale

Profesor: Prof.Dr.Georgeta Șoavă

Student: Ghiță Daniel Marian

Universitatea din Craiova

Facultatea de Economie și Administrarea Afacerilor

Specializarea: Informatică Economică Grupa 1

Anul 3

2015

Introducere

In aceasta lucrare va voi prezenta diagramele Entitate Relație, Ce sunt aceste diagrame ?Cum se folosesc,unde ? care este avantajul lor?.

In primul capitol am prezentat conceptele fundamentale elementare, deoarece este inutil sa vorbim despre folosirea diagramelor E-R fără a cunoaște termeni cel de date, baze de date. Am mai prezentat de asemenea un scurt istoric al evoluției bazelor de date. Astfel reamintind termeni invățați pe parcursul anului doi de facultate dar si anului 3.

In capitolul doi am vorbit despre diagramele entitate relațiile, nivelurile acestora care sunt similare cu nivelurile oricărei aplicații, plecându-se de la adunarea de informații pentru elaborarea conceptului. Partea logica, unde abstractizarea este mai redusa, se cunosc atât datele care vor fi manipulate si se implementează o structura logica a acestor date. Partea fizica unde se trece la crearea efectivă a diagramelor.

In subcapitolul 2.2 am prezentat sumar gama de întindere a diagramelor E-R, ce tipuri de aplicații folosesc acest tip de diagrame si implicit baze de date.

In ultimul subcapitol al capitolului 2 am hotărât sa prezint un studiu de caz având in centru o aplicație la care am lucrat pe parcursul stadiului de practica, in care sunt prezentate concret atât etapele de normalizare a bazei de date, cat si nivelurile diagramelor ERD, fiind o aplicație care folosește si manipulează date am început desigur prin a realiza conceptul bazei de date iar apoi după ce baza de date a fost realizata fizic am făcut o scurta descriere a aplicației, aplicație care nu este decât o interfață prietenoasa cu utilizatorul.

Capitolul I Concepte fundamentale

1.1 Bazele de date

1.2 Limbajul SQL

1. 3 Diagramele ER

Bazele de Date

Bazele de Date reprezintă o colecție de date unice cu trăsături comune, gestionate de unul sau mai multe programe de gestiune a bazelor de date, ele putând fi manipulate si prelucrate pentru atingerea unui obiectiv bine stabilit.

Datele reprezintă materiale brute, care nu au fost prelucrate, in scopul obțineri de informații, astfel datele pot fi orice simboluri numerice, imagini, cuvinte care nu au un înțeles de sine stătător.

Bazele de date au evoluat pe parcursul anilor astfel :

La început gestiunea datelor se realiza prin de fișiere clasice, aceasta este etapa in care dispozitivele de calcul funcționau pe benzi magnetice. Gestionarea datelor in aceasta etapa fiind apropiata de gestiunea clasica (îndosariere), benzile magnetice fiind astfel depozitate in condiții destul de similare cu datele care erau pe suport de hârtie.

A doua etapa in evoluția bazelor de date o reprezintă organizarea mixtă în fișiere, astfel datele erau organizate in fișiere clasice dar si in fișiere indexate

A treia etapa o reprezintă organizarea datelor sub forma bazelor de date clasice, sub forma unor fișiere integrate.

A patra etapa o reprezintă sistemele de gestiune a bazelor de date relaționare, astfel datele sunt organizate in tabele, intre date existând o relație clară si bine definita. Tipurile de legături care pot exista intr-o baza de date relaționară sunt :

One to many (unu la mai mulți) unui element dintr-o mulțime a ii corespund mai multe elemente dintr-o mulțime b.

One to one (unul la unu) unui element dintr-o mulțime a ii corespunde un singur element dintr-o mulțime b.

Many to may (mai mulți la mai mulți) mai multor elemente din mulțimea a le corespund doua sau mai multe elemente dintr-o mulțime b.

A cincea etapa in procesul evoluției bazelor de date o constituie bazele de date distribuite, astfel baza de date nu se afla precum in cazul bazelor de date relaționare pe un singur dispozitiv, ea fiind practic distribuita pe mai multe dispozitive aflate de multe ori in zone geografice diferite si la distante mari unele fata de altele.

Limbajul SQL

Limbajul SQL (Structured Query Language) este în prezent, unul din cele mai puternice limbaje structurate pentru interogarea bazelor de date relaționale.

Este un limbaj neprocedural și declarativ, deoarece utilizatorul descrie ce date vrea să obțină, fără a fi nevoie să stabilească modalitățile de a ajunge la datele respective. Nu poate fi considerat un limbaj de programare sau unul de sistem, ci mai degrabă face parte din categoria limbajelor de aplicații, fiind orientat pe mulțimi.

Foarte frecvent, este utilizat în administrarea bazelor de date client/server, aplicația client fiind cea care generează instrucțiunile SQL.

Lansat inițial de IBM. Standardizat prima dată de ANSI, apoi ISO. Actualmente, ISO 92.

Pentru că există o standardizare a limbajului SQL, multe SGBD (Oracle, Access, Sybase) recunosc principalele instrucțiuni ale acestuia.

Caracteristicile adăugate standardului se numesc extensii. De ex, în standard sunt specificate 6 tipuri diferite de date pentru o BD SQL. În multe implementări, această listă este completată cu o diversitate de extensii. Fiecare implementare se numește dialect. Dialectul ACCSES conține unele particularități, fiind conceput mai mult pentru crearea interogărilor de selecție.

Există 3 metode de bază privind implementarea limbajului SQL:

− apelare directă (Direct Invocation): constă în introducerea instrucțiunilor direct de la prompter

− modulară (Modul Language): folosește proceduri apelate de programele aplicație

− încapsulată (Embedded SQL): conține instrucțiuni încapsulate în codul de program

Instrucțiunile SQL pot fi grupate în:

instrucțiuni de definire date, care permit descrierea structurii bazei de date

instrucțiuni de manipulate date: adaugă, modifică si ștergere

instrucțiuni de selecție date, care permit interogarea bazei de date

instrucțiuni de procesare a tranzacțiilor

instrucțiuni de control al cursorului

instrucțiuni privind controlul accesului la date

În limbajul SQL standardizat de ISO nu se folosesc termenii de relație precum: atribut, cuplu, ci tabel, coloană, rând.

1.3 Diagramele E-R sau entitate-relație.

Termenul folosit in limba romana este o traducere mot a mot a englezescului Entity–Relationship, modelul ER se mai poate întâlni si sub denumirea ERD (Entity Relationship Diagram) Diagrama Entitate Relație.

Modelul E-R este un model conceptul de abstractizare a datelor specific bazelor de date relaționare care arata legătura in centru datele sau lucrurile si legăturile intre anumite date (grupate in tabele diferite).

Modelul E-R a fost dezvoltat pentru prima data de Peter Chen si publicat in 1976 intr-un ziar, însa variante ale acestui model au existat si înainte ele fiind reprezentate de subtipurile si super tipurile de date si relațiile comune.

Un model E-R este implementat intr-o baza de date. In cazul bazelor de date relaționare care folosesc tabele pentru stocarea datelor, fiecare rând al tabelului reprezentând o instanță a unei entități. Unele câmpuri din-un tabel pot fi reprezentate de indecși care prin intermediul cărora se face referire la alte tabele, construind astfel o relație specifica bazelor de date relaționare si anume : unu la unu, unu la mai mulți, relațiile de tip mai mulți la mai mulți fiind excluse in totalitate datorita procesului de normalizare a bazei de date.

In cazul existentei unei astfel de relații (mai mulți la mai mulți ) este de dorit spargerea acesteia si transformarea in relații de tip unu la unu sau unu la mai mulți.

Procesul de normalizare reprezintă o etapa formala care folosește cheile primare si interdependenta datelor. Prin procesul de normalizare se elimina redundanta datelor, anomaliile de inserare, ștergere si modificare, si dependentele funcționale.

Capitolul 2 Diagramele E-R si utilizarea acestora in aplicații

2.1 Nivele Diagramelor ER

2.2 Utilizarea E-R si aplicații

2.3 Aplicație privind folosirea bazelor de date si diagramelor E-R

2.1 Nivele Diagramelor ER

Nivele diagramelor ER sunt similare cu cele ale proiectări unei aplicații informatice. Astfel bazele de date însoțesc aplicației din momentul concepției pana in momentul implementări si lansare.

Exista 3 mari niveluri ale diagramelor si anume:

Modelul conceptual

Modelul logic

Modelul fizic

2.1.1 Modelul conceptual al datelor

Modelul conceptual al datelor este cel mai înalt grad al unei diagrame E-R, in acest model se face o abstractizare a datelor si o schema logica a bazei de date, ne fiind folosiți termeni specifici unui limbaj de gestiune a datelor, ci un limbaj general, asemănător limbajului vorbit, asemănător cu pseudocodul din programare.

Scopul modelului conceptual al diagramei entitate relație stabilirea structuri meta datelor, pentru a stabili modelul de date, relațiile intre entități si tipurile de date necesare pentru implementarea bazei de date. Este mai pe scurt o schema logica abstracta de la care se pleca atunci când vrem sa construim o baza de date.

In Modelul conceptual al datelor pot interveni erori datorita următorilor factori:

Subiectivitatea si spiritul de observație al celui care a conceput modelul

Instrumentelor și tehnicicilor de modelare

Metodei de observare folosita.

2.1.2 Modelul logic al datelor

Modelul logic al datelor reprezintă un ansamblu de tehnici și reguli de trecere de la conceptele utilizate de modelul conceptual la conceptele utilizate de Bazele de Date Relaționale – BDR și de limbajele de programare.

Bazele de date relaționale se definesc ca fiind structura de date relațională, modelul de reprezentare abstractă a datelor sub formă de relații; practic, într-o bază de date relațională, datele sunt organizate (reprezentate) sub formă de tabele bidirecționale, între care se stabilesc tipuri de legături predefinite.

Modelul logic conține astfel date mai detaliate decât modelul conceptual, astfel ca relațiile intre entități sunt acum bine definite si detaliate, totuși acest model are câteva puncte comune cu modelul logic conceptual dar si cu modelul fizic, el fiind practic destul un model intermediar intre concepție si aplicare. Trăsătura comuna cu modelul conceptual este ca datele nu sunt prezentate intr-un anumit sistem de gestiune al bazelor de date, totuși acum se cunosc clar câmpurile si relațiile dintre acestea, ce tabele va conține baza de date si de ce tipuri de date este nevoie, fapt care ne apropie de modelul fizic al datelor.

2.1.3 Modelul fizic al datelor

Cunoscându-se tot ce se cere de la o baza de date sau program care folosește sisteme de gestiune a bazelor de date, după ce toți decidenți si-au dat acordul atât asupra modelului conceptual cat si asupra modelului logic are loc realizarea efectivă bazei de date respective.

Astfel se vor crea tabele intr-un sistem de gestiune a bazelor de date ales după criterii bine stabilite, crearea legăturilor intre tabele si astfel aplicația poate va prinde viață.

Diagramele E-R joaca un rol important si in aceasta etapa datorita faptului ca prin intermediul lor se pot crea legăturile intre tabele mai ușor, oferă o imagine de ansamblu asupra întregi baze de date, pot evidenția eventuale greșeli in realizarea bazei de date, greșeli ce pot apărea la crearea legăturilor intre tabele datorita inconcordanței tipului de date folosit la câmpurile de legătura.

De exemplu daca in tabelul Operatori câmpul ID rol care este cheie externa, prin intermediul căreia se face legătura intre tabelele Operatori si Roluri in primul tabel tipul de data folosita ar fi integer (10) iar in al doilea tabel ar fi oricare altul decât integer (10), legătura dintre aceste 2 tabele ar fi imposibila, nefiind legătura rezulta ca deși in modelul logic aceasta exista si permitea unui rol sa aibă mai mulți operatori definiți in practica aceasta relație de legătura nu va exista, datorita unei erori de programare.

Printre criteriile de selectare a unui anumit sistem de gestiune a bazelor de date enumeram :

Costul sistemului de gestiune, anumite Sisteme de gestiune a bazelor de date (sgbd-uri) pot fi gratuite precum mysql sau cu plata (Oracle sql, microsoft sql server ). Costul totuși nu ar trebui sa fie criteriul de selecție primordial.

Volumul de date prelucrate si timpul de răspuns la cere, cu alte cuvinte cate interogări, editări pe secunda poate efectua sistemul de gestiune a bazelor de date. Aplicațiile economice necesita cum de altfel știm toți prelucrarea unui volum mare de date. De exemplu in momentul înregistrării unei facturi primite de la un furnizor se face nota de recepție si constatare de diferențe pe baza facturi aferente, tot in acest timp din nota de recepție si constatare de diferențe se preiau datele pentru fisa de magazie pentru a tine o evidenta analitica a produselor finite, de înregistrează in contabilitate datoria fata de furnizor precum si creșterea stocurilor. Daca in operațiunea anterioara exista timpi morți sau sistemul nu este integrat complet, si înregistrarea in contabilitate se face prin intermediul unui alt program vom avea pierderi datorita faptului ca mai multe persoane vor face aceiași operațiune in sisteme informatice diferite, necesitând astfel timp mai îndelungat si costuri suplimentare cu resursa umana.

Compatibilitatea cu sistemele informatice actuale.

Cunoașterea unui anumit sgbd de către cei care vor realiza baza de date.

Astfel din cele prezentate mai sus rezulta o implicație manageriala de top pentru luarea deciziilor, proiectanți pot propune soluții, pot calcula costuri, însa este de datoria managerului de a alege intre un sistem de gestiune a bazelor de date sau altul, ținând cont de toți acești factori si mulți alți.

2.2 Utilizarea E-R si aplicații

Bazele de date au o gama larga de aplicare, ele putând fi întâlnite atât in aplicații web caz in care sunt manipulate cu ajutorul limbajului php, sau aplicații clasice deseori aparținând de domeniul economic si științific, domeniul bancar, aplicații mobile dar si in jocuri (jocurile PC de ultima generație au ajuns sa folosească datorita complexități gameplay-ului baze de date complexe datorita gestiuni ușoare a tuturor elementelor implicate).

Astfel diagramele entitate relație fiind un element cheie comun al acestor baze de date relaționare folosite de toate categoriile de aplicații menționate mai sus.

Particularitățile domeniului economic care au contribuit la evoluția bazelor de date așa cum le știm noi astăzi, chiar daca spre deosebire de alte domenii avem de a face cu o evoluție destul de lenta, ea este vizibila atunci când vorbim de ERP-uri care au drept țintă corporațiile mari, precum Oracle's E-Business Suite si SAP. Tot ei fiind după cum mulți specialiști considera motivul păstrări bazelor de date relaționare.

2.3 Applicative practică cu baze de date și diagrame E-R

Aceasta aplicatie de agendă telefonică folosește Delphi ca mediu de programare si SQL Server ca suport pentru implementarea bazei de date pe care programul o va utiliza putând sa adauge persoane in agenda, fiecărei persoane corespunzându-i doua sau mai multe numere de telefon. Interacțiunea cu aplicația se face cu ajutorul butoanelor de comanda iar primul formular pe care îl va accesa utilizatorul este cel de login celelalte rămânând ascunse pana ce acesta va introduce un cont de utilizator si o parola existenta in baza de date.

2.3.1. Proiectarea si conceperea bazei de date

Nivelul conceptual

Nivelul fizic

Tabelul Contacte cuprinde următoarele câmpuri:

ID Contact : număr întreg, auto increment, cheie primară, valori nule interzise.

Nume: varchar, valori nule interzise.

Prenume: varchar valori nule interzise.

Tabelul Numere Telefon cuprinde următoarele câmpuri:

ID: număr întreg, auto increment, cheie primară, valori nule interzise.

Număr telefon 1: varchar, valori nule interzise.

Număr telefon 2: varchar, valori nule interzise.

Număr telefon 3: varchar,se permit valorile nule.

ID contact: : număr întreg, cheie externă, prin intermediul căreia se creează legătura tabelului părinte (Contacte) cu tabelul copil (Numere Telefon), având de a face aici cu o legătură de tip one to many, fiecărui contact corespunzându-i 2 sau 3 numere de telefon.

Tabelul Roluri cuprinde următoarele câmpuri:

ID Rol : număr întreg, auto increment, cheie primară, valori nule interzise.

Denumire rol: varchar, valori nule interzise.

Tabelul Operatori cuprinde următoarele câmpuri:

ID Operator: număr întreg, auto increment, cheie primară, valori nule interzise..

User : varchar, valori nule interzise.

Parola : varchar, valori nule interzise.

ID Rol : număr întreg, cheie externă, valori nule interzise. Prin intermediul căreia se creează legătura tabelului părinte (Roluri) cu tabelul copil (Operatori), având de a face aici cu o legătura de tip one to many, fiecare rol putând sa aibă mai mulți operatori.

Tabelul Tip Telefon cuprinde următoarele câmpuri:

ID tip: număr întreg, auto increment, cheie primara, valori nule interzise.

Denumire: varchar, valori nule interzise.

ID: număr întreg, cheie externa prin intermediul căreia se creează legătura intre tabelul părinte (Tip Telefon) si tabelul copil (Numere Telefon), fiecărui număr de telefon corespunzându-i un tip de telefon (fix sau mobil).

2.3.2 Realizarea aplicației în Delphi

Pentru manipularea ușoară a tabelelor din baza de date am creat o aplicație de tip VLC in Delphi XE2.

Aplicație conține un formular principal, un formular de login, un data module si un formular de editare.

Legătura intre baza de date si proiectul in Delphi se realizează prin intermediul unei conexiuni de tip TADOConection, aceasta fiind astfel o punte de legătura intre aplicație si baza de date ’’Agenda’’

. Pentru manipularea datelor din tabele au fost necesare următoarele unelte:

TADODataSet pentru preluarea datelor din tabele.

TDataSource pentru încărcarea datelor din tabel in aplicație, navigarea si editarea datelor

TADOQuery pentru interogări si joncțiuni efectuate in baza de date

Toate aceste conexiuni și unelte au fost plasate pe un formular ascuns utilizatorului de tip Data Module . Acest lucru structurând aplicația si simplificând astfel accesul partea de date și conexiuni in realizarea programului.

Accesul in aplicație se va face prin formularul de login, si in funcție de rolul userul-ui acesta va putea face următoarele operațiuni:

Administrator- adăuga conturi de utilizatori, moderatori si administratori , modifica, denumirea conturilor, parolele etc. intr-un cuvânt poate folosi toate funcțiile din aplicație.

Moderator poate adăuga doar conturi de utilizator, având acces la opțiunile de modificare contacte, adăugare ștergere

Utilizator acesta poate doar sa adauge contacte, tipuri si numere de telefon, partea de operatori adăugare operatori fiind inaccesibila. Daca utilizatorul si parola sunt corecte atunci se va deschide formularul principal.

Formularul principal conține doua griduri care fac parte din clasa TDBGrid.

Primul grid afișează toate câmpurile din tabelul Contacte, datele fiind afișate prin intermediul unei unelte de tip TDataSource care la rândul lui este conectat la o unealta de tip DataModule. Prin intermediul acestor unelte care se afla pe formularul de Data module, aplicația preia câmpurile din tabel, le prelucrează, șterge si stochează prin intermediul butoanelor de comanda si le stochează in baza de date.

Adăugarea datelor in agenda se face prin intermediul butonului de comanda Adăugare la a cărui apelare se va deschide un formular de editare in cu ajutorul a doua casete de text se vor introduce Numele si Prenumele contactului, si o imagine folosind butonul Imagine, adăugarea acesteia se face prin căutarea selectarea din locația inițiala acest lucru realizându-se de un obiect TopenPictureDialog. Imaginea se va salva in fișierul aplicației, preluând id-ul contactului nou introdus. O data introduse datele dorite despre contactul respectiv, se salvează totul apăsând butonul Salvare.

Editarea datelor se face prin intermediul butonului de comanda ‚Editare’ acesta va identifica id-ul contactului care se dorește a fi editat, va deschide formularul de editare, va încărca in casetele de text numele si prenumele, imaginea in caseta de imagine oferindu-i utilizatorului posibilitatea de a o modifica si pe aceasta. O data finalizata editarea se va apăsa butonul de salvare pentru a stoca modificările efectuate in baza de date.

Ștergerea datelor se face cu ajutorul butonului ’’Ștergere’’, acesta va identifica id-ul liniei selectate si va avertiza utilizatorul despre acțiunea care se va produce printr-o caseta de dialog, daca acesta dorește ștergerea este necesara apăsarea butonului OK din caseta de dialog, iar aplicația va deschide o alta fereastra care va afișa un mesaj de confirmare, înregistrarea respectiva fiind ștearsă din baza de date. In cazul apăsări butonului Cancel operațiunea de ștergere va fi abandonată.

Concluzii

In concluzie datorita caracteristicile numeroasa, diagramele entitate relație usureaza atât munca celor care concep un program informatic care folosește baze de date dar si a celor care îl realizează propriu zis.

Datorita faptului ca sunt clare, concise, si relativ destul de ușor de realizat, ele sporesc productivitatea munci unei echipe de programatori dar si analiștilor de sistem.

Aplicații care ar avea nevoie de zeci de pagini pentru a fi descrise in scris sunt mult mai ușor de proiectat cu ajutorul acestor diagrame, deoarece uneori o imagine face cat 1000 de cuvinte.

Astfel cum am văzut pe parcursul acestei lucrări aplicabilitatea lor este imensa, cuprinzând numeroase domenii de aplicabilitate.

Bibliografie

Beginning SQL Server 2008 for Developers: From Novice to Professional 2008

Robin Dewson

Baze de date

Conf.univ. Anca Mehedintu

Lucrare de laborator 1 Analiza sistemelor informaționale –

Prof.dr. Georgeta Șoavă

https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model