Crearea unei baze de date Oracle – Make a Oracle DataBase

January 29, 2025
349 Comments

Conceptele Bazelor de Date Relaţionale

Definirea bazei de date

Prin intermediul calculatoarelor electronice se pot realiza activităţi precum stocare, interogare şi administrare de colecţii de date. Prin intermediul tehnologiilor informaţionale se pot definii tehnici şi metode de oraganizare a colecţiilor de date. Organizarea în fişiere de date şi organizarea în baze de date sunt două din metodele cunoscute. Prin anii 1960 se folosea organizarea datelor în fişiere de date, dar această metodă are şi unele neajunsuri şi limitări din care se poate menţiona urmatoarele:

Datele sunt dependente de program, deci trebuie să se facă descrierea datelor în fiecare program în care sunt utilizate
Există redundanţe ridicate în cadrul colecţiilor de date
Performanţe scăzute în procesarea datelor
Pentru a se limita aceste neajunsuri şi limitări ale datelor organizate în fişiere de date au fost dezvoltate alte metode de organizare a datelor şi anume organizarea datelor în baze de date.

Definiţie: O bază de date este o colecție de informații care este organizată în așa fel încât să poată fi ușor de accesat, gestionat și actualizat.

Diferenţa între metoda de organizare a datelor în fişiere de date şi cea de organizare a datelor în baze de date este că în cea din urmă (organizarea datelor în baze de date) exiată un fişier de descriere generală a bazei, iar în acest fel se poate realiza independenţa programelor faţă de date. Acest fişier care face o descriere generală (globală) a bazei se numeşte dicţionar de date. Ca atare modificarea datelor sau extragerea acestora se face prin intermediul acestui dicţionar de date în care găsim informaţii referitoare la structura datelor.

De multe ori termenul de “bază de date” este înţeles şi utilizat greşit şi se confundă cu softul de baze de date care se utilizează. De fapt softul pentru baze de date se numeşte sistem de gestiune al bazelor de date (SGBD), iar baza de date este containierul (daca putem sa facem o analogie ca să întelegem mai bine diferenta dintre o bază de date şi un SGBD) care conţine informaţiile, iar acest containier este creat şi gestionat prin intermediul SGBD. Nu orice colecţie de date este o bază de date. Proiectarea unei baze de date înseamna să îi stabilim structura, caracteristicile, elementele componente acesteia, precum şi restricţiile care trebuie respectate şi relaţiile dintre ele.

A construi o bază de date înseamnă să introducem datele noastre în baza de date dupa ce am proiectat-o. A administra o bază de date înseamnă să asigurăm accesul utilizatorilor la date în funcţie de drepturile pe care le-am acordat fiecaruia. A interoga o bază de date înseamnă a extrage şi vizualiza acele date care îndeplinesc anumite condiţii dupa care am facut căutarea. După cum spuneam nu orice colecţie de date este o bază de date, de exemplu lista filmelor unui magazin care are ca activitate închirierea de filme clienţilor nu este o bază de date, ci este doar un simplu tabel sau o listă. Deci o bază de date diferă de un simplu tabel şi trebuie să aibă anumite proprietăţi cum ar fi:

Este o colecţie de date coerentă din punct de vedere al logicii
Este proiectată, construită şi administrată având un scop bine determinat
Reprezintă anumite aspecte ale lumii reale
O bază de date poate fi înţeleasă ca o colecţie de fişiere asociate. Modul în care aceste fişiere sunt asociate depinde de modelul utilizat. Primele modele au inclus modelul ierarhic (caz în care fişierele sunt asociate într-un mod părinte / copil, cu fiecare fişier copil având cel mult un fişier părinte), precum şi modelul de reţea ( caz în care fisierele sunt asociate ca proprietari şi membrii, similar cu modelul de reţea, cu excepţia că fiecare fişier membru poate avea mai mult de un proprietar).

Să luăm exemplu următoarele două tabele:

Aceste două tabele sunt legate printr-o relaţie de referinţă, câmpul „COD” din tabelul „Autori” şi câmpul „AUTOR” din tabelul „Lucrări”. Putem vedea cine a scris lucrarea „Linux pentru începatori” urmând relaţia de referintă, din care reiese că autorul este „2” din tabelul „Lucrări” adică Dumitru George din tabelul „Autori”.

O bază de date relaţională este un sistem în care datele sunt stocate în tabele de rânduri (înregistrări) şi coloane (câmpuri). Caracteristica definitorie a unei baze de date relaţională este faptul că un set complet de date este divizat în mai multe tabele (fiecare reprezentând un singur subiect) şi relaţiile pot fi stabilite între aceste tabele prin utilizarea de domenii cheie.

Structured Query Language (SQL) este folosit într-un SGBD pentru a manipula datele din tabele. Există mai multe pachete software de SGBD pe care putem să le alegem. În domeniul comercial, Oracle a fost mult timp cel mai popular SGBD, urmat de IBM DB2 şi Microsoft SQL Server. În domeniul open-source, MySQL şi PostgreSQL sunt cele mai importante SGBD. Microsoft Access este un pachet relativ ieftin, care este cel mai potrivit pentru seturi mici de date.

În 1970, atunci când E.F. Codd a dezvoltat modelul, acesta a fost considerat a fi nepractic, deoarece maşinile din acea perioadă nu puteau face faţă cerinţelor hardware necesare. Desigur, de atunci hardware-ul a făcut progrese uriaşe, astfel încât astăzi chiar şi cele mai modeste PC-uri pot rula sisteme sofisticate de SGBD. Odată cu aceasta a fost dezvoltat şi limbajul SQL. SQL este relativ usor de învăţat şi permite oamenilor să înveţe rapid cum să efectueze interogări pe o bază de date relaţională.

O înţelegere a bazelor de date relaţionale necesită o înţelegere a unora dintre termenii de bază. Datele sunt valorile stocate în baza de date. Ca atare, datele înseamnă foarte puţin. “12345” este un exemplu Informaţiile sunt date care sunt prelucrate pentru a avea un sens. De exemplu, “637500”, este populaţia oraşului Brasov.

O bază de date este o colecţie de tabele. Fiecare tabel conţine înregistrări, care sunt rândurile orizontale din tabel. Acestea sunt, de asemenea, numite tupluri. Fiecare înregistrare conţine câmpuri, care sunt coloanele verticale ale tabelului. Acestea sunt, de asemenea, numite atribute. Câmpurile pot fi de mai multe tipuri diferite. Există mai multe tipuri de date standard, iar fiecare SGBD (sistem de management de baze de date, cum ar fi Oracle sau MySQL) au de asemenea, propriile tipuri specifice de date, dar în general, acestea se încadrează în cel puţin trei tipuri, caracter, numeric şi data.
Domeniul se referă la valorile posibile pentru fiecare câmp. De exemplu, un câmp denumit “gen” poate fi limitat la valorile “masculin” si “feminin”.

Un câmp conţine o valoare „NULL” atunci când câmpul nu conţine nimic, adica o valoare necunoscută de exemplu. Câmpurile pot crea complexităţi în calcule şi au consecinţe pentru exactitatea datelor. Din acest motiv, multe câmpuri sunt în mod special setate să nu conţină valori „NULL”.

O cheie este o modalitate logică de a accesa o înregistrare într-un tabel. De exemplu, într-un tabel numit „AUTORİ”, câmpul „COD” ar putea să ne permită să identificăm unic o înregistrare. O cheie care identifică în mod unic o înregistrare se numeşte cheie primară.

Un index este un mecanism fizic care îmbunătăţeste performanţa unei baze de date. Indexurile sunt adesea confundate cu chei. Cu toate acestea, strict vorbind ei sunt parte a structurii fizice, în timp ce cheile sunt parte a structurii logice. O vizualizare este un tabel virtual alcătuit dintr-un subset de tabele reale (concrete).
O relaţie unu-la-unu (1:1) în cazul în care are loc relaţia, pentru fiecare instanţă a tabelului A, numai o instanţă din tabelul B există, si vice-versa.

O relaţie unu-la-mai-mulţi (1: m) în cazul în care relaţia există, pentru fiecare instanţă a tabelului A, mai multe instanţe a tabelului B există, dar pentru fiecare instanţă din tabelul B, numai o singură instanţă a tabelului A există.

O relaţie mulţi pentru mulţi (m: n) în cazul în care are loc relaţia, pentru fiecare instanţă a tabelului A, există mai multe instante a tabelului B, iar pentru fiecare instanţă a tabelului B, există mai multe instante ale tabelului A.

O relaţie este opţională în cazul în care, pentru fiecare instanţă a tabelului A, pot exista instanţe ale tabelului B

İntegritatea datelor descrie acurateţea, validitatea şi coerenţa datelor. Un exemplu de integritate slabă ar fi în cazul în care numele unui autor este stocat în mod diferit în două locuri diferite.

Normalizarea bazei de date este o tehnică care ne ajută la reducerea apariţiei anomaliilor de date şi slaba integritate a datelor.

Modelul relaţional constă din următoarele:

O colecţie de obiecte sau relaţii
Un set de operatori care acţionează asupra relaţiilor
İntegritate a datelor pentru acurateţe şi consecvenţă
Componente ale modelului relaţional:
Colecţii de obiecte sau relaţii care stochează datele
Un set de operatori care pot acţiona asupra relaţiilor pentru a produce alte relaţii
İntegritatea datelor pentru acurateţe şi consecvenţăO bază de date relaţională este o colecţie de relaţii sau tabele bidimensionale utilizate pentru a stoca informaţii.

De exemplu, putem avea nevoie să stocam informaţii despre toţi angajaţii dintr-o anumită companie. Într-o bază de date relaţională, putem crea mai multe tabele pentru a stoca diferite bucăţi de informaţii despre angajaţi cum ar fi un tabel cu toţi angajaţii, un tabel cu angajaţii dintr-un anumit departament precum şi un tabel cu salariul fiecarui angajat dintr-un anumit departament.

Proprietăţile bazelor de date relaţionale.

O bază de date relatională:
Poate fi accesată şi modificată executând instrucţiuni ale limbajului Structured Query Language (SQL)
Conţine o colecţie de tabele fără indicii fizice
Utilizează un set de operatoriÎn baza de date relaţională, nu e necesar să specificăm calea de acces la tabele, nici nu trebuie să ştim modul în care datele sunt aranjate fizic. Pentru a accesa baza de date, executam pur şi simplu o interogare a limbajului SQL, care este conform American National Standard Institute (ANSI) limbajul standard pentru baze de date relaţionale. Limbajul conţine un set larg de operatori pentru partiţionare şi combinarea relaţiilor. Bazele de date pot fi modificate cu ajutorul declaraţiilor SQL.

Limbajul de interogare structurat SQL ne permite să comunicăm cu serverul şi are urmatoarele avantaje:

Eficienţă
Uşor de învăţat şi folosit
Funcţionalitate completă (SQL ne permite să definim, regăsim şi să manipulăm datele în tabele)Entitate

O entitate poate să fie un obiect din lumea înconjurătoare care are o existenţă fizică, sau mai poate fi un obiect care are o existenţă abstractă, conceptuală. O entitate poate să fie dependentă (slabă) şi în acest caz depinde de alte entităţi, sau independentă adică (tare) şi atunci nu mai depinde de alte entităţi.

Observatii:
Entitaţile sunt tabele în modelele de date relaţionale
Entitaţile se scriu cu litere mari
Sunt substantive, dar nu orice substantiv este o entitate
Prin intermediul cheii primare identificam unic o entitate,cheia primară trebuie să fie unică
Este nevoie de o descriere detaliată a fiecarei entitaţi
Nu putem avea doua entitaţi cu acelaşi nume într-o diagramă, sau să avem nume diferite pentru aceeaşi entitateRelatie

Când proiectam o bază de date, modelăm un sistem care există în lumea reală, acesta descrie mai multe entități care au anumite caracteristici, sau atribute și de asemenea există anumite reguli şi legături între aceste entități. O relație descrie modul în care entitățile sunt legate una de alta. Relațiile pot fi considerate verbe care leagă două sau mai multe substantive.

Există trei tipuri de relații între entitățiile dintr-o bază de date:

Relații unu-la-unu: În acest tip de relație, fiecare instanță a unei entități se referă la o singură instanță a unei alte entități. Deci, există un raport de unu-la-unu one-to-one (1:1).
Relații unu-la-mai-mulți: În acest tip de relație, fiecare instanță a unei entități se referă la una sau mai multe instanțe ale unei alte entități. De exemplu, un autor ar fi scris mai multe cărți, dar anumite cărți au un singur autor. Acesta este cel mai comun tip de relație modelat în baze de date relaționale one-to-many (1:n).
Relații mulți-la-mai-mulți: În acest tip de relație, mai multe instanțe ale unei anumite entitaţi se referă la una sau mai multe instanțe ale unei alte entități. De exemplu, co-autorii ar putea scrie o serie de cărți many-to-many (m:n).
Observatii:
În modelul relaţional, relaţiile devin tabele speciale sau coloane care referă chei primare.
Se face o descriere pentru fiecare relaţie.
Putem avea relaţii diferite cu acelaşi nume în aceeaşi diagramă, dar în acest caz, acestea sunt diferenţiate de entităţile care sunt asociate prin relaţia respectivă
Trebuie să stabilim cardinalitatea pentru fiecare relaţie (maximă şi minimă), adică numărul de înregistrari ce aparţin relaţiei.Atributul

Este o proprietate care descrie o relaţie sau o entitate. De exemplu numele unui film este atribut al entităţii FILM_STOC, iar preţul de închiriere a unui film este un atribut al relaţiei “închiriază” ce leaga entitaţile FILM_STOC şi FILME_INCHIRIATE.

Atributele pot să fie simple (ex. pretul cu care este închiriat un film), compuse (ex. mai multe nr. de telefon a persoanei care a închiriat un film), sau derivate (ex. anul naşterii unei persoane care se obţine scăzând din anul curent vârsta persoanei respective).

Observatii

Trebuie totuşi să facem diferenţa între un atribut care poate să devină coloană într-un model relaţional şi valoarea acestuia care este o valoare în coloană. Fiecarui atribut este necesar să îi atribuim o descriere, iar pentru fiecare atribut trebuie să specificam numele, tipul de date ( integer, float, char, etc) valori posibile pe care le poate lua, valori implicite, constrângeri, tipuri compuse, reguli de validare.

Diagrama E/R – Cardinalitate

Definiţie: Se numeste relaţie între entitaţile E1, E2,…Ek orice submultime a produsului cartezian al mulţimilor elementelor celor k entitaţi, adica mulţimi de elemente de forma (e1, e2,…,ek) unde “ei” este un element din “Ei”, oricare ar fi i = 1,…,k.

Prin intermediul diagramelor entitate relaţie este reprezentat grafic modelul logic al unei baze de date. Diagrama este utilizată des pentru a reprezenta grafic modelul relaţional. După cum îi spune şi numele, modelul E/R se ocupa de entitaţi, proprietaţiile sau atributele ce definesc anumite laturi ale entitaţilor şi legaturile dintre entitaţi.

Etapele realizarii diagramei E/R

Identificam entitaţile
Identificam relaţile dintre entitaţi
Stabilim cardinalităţile
Identificam atributele pentru fiecare entitate
Stabilim cheieleForme normale

Definitie: „Normalizarea este procesul de organizare a datelor în mod eficient într-o bază de date şi are două scopuri, să elimine datele redundante şi să asigure dependenţa datelor dându-le un sens.”

Avantajele normalizarii sunt:
Mai puţin spaţiu de stocare
Actualizări mai rapide
Mai puţină neconcordanţă a datelor
Relaţii clare între date
Mai uşor de adăugat date
Structură mai flexibilă

O parte din definiţia unei baze de date relaţionale include şi conceptul de „Forme Normale”. Fiecare dintre forme sunt concepute pentru a aborda în mod logic probleme potenţiale la care se referă în lucrul cu informaţiile stocate într-o bază de date.
O bază de date se spune că este într-una din formele normale în cazul în care îndeplineşte regulile impuse de acea formă.

Prima formă normală (FN1)

„O relaţie este în FN1 dacă şi numai dacă toate domeniile de bază conţin doar valori scalare, şi fiecare atribut care o compune corespunzandu-i o valoare indivizibilă sau atomică.”

FN1 este adesea numita şi regulă atomică. “Atom” vine de la un cuvânt grecesc care înseamnă, în esenţă, piesa cea mai mică posibilă dintr-un obiect. Într-o bază de date, acest lucru înseamnă că fiecare coloană ar trebui să fie proiectată exclusiv să deţină numai o bucată de informaţie.

Pentru a aduce o relaţie în FN1 putem folosi următorul algoritm:

1. Înlocuim în relaţie atributele compuse cu componentele acestora.
2. Creăm o nouă relaţie pentru fiecare din grupurile repetitive.
3. În fiecare relaţie pe care am creat-o la pasul 2 introducem în schemă cheia primară a relaţiei din care am extras atributul repetitiv.
4. Stabilim cheia primară pentru fiecare relaţie pe care am creat-o la pasul 2 care este alcatuită din cheia pe care am introdus-o la pasul 3, precum şi din alte atribute a noii relaţii.Să luăm în considerare următorul exemplu şi să vedem cum aducem un tabel nenormalizat în prima formă normală (FN1).

 

Tabel 3 Studenti

Tabelul 3 este un tabel nenormalizat. Atributul cheie este “ID_STUD”. İdentificăm grupurile repetitive care sunt de fapt detaliile despre camerele de camin pe care le ocupa studentii, anul şi specializarea.

Structura grupului repetitiv este urmatoarea:
GrupRepetitiv ( NR_CAMIN, ADR_CAMIN, DATA_INTR, DATA_IES, CAMERA, AN, SPECIALIZARE )

Putem vedea ca avem valori multiple la intersecţia anumitor rânduri cu coloane. De exemplu se poate vedea în tabelul 3 ca avem două valori ale atributului “NR_CAMIN” (98,102) care corespund studentului İonescu Gigel. Ca să putem aduce acest tabel în forma de normalizare FN1 trebuie să ne asigurăm că avem o singură valoare la intersecţia dintre fiecare rând şi fiecare coloană. Acest lucru îl facem prin eliminarea grupului repetitiv. Deci eliminam grupul repetitiv plasând într-o relaţie separată datele respective împreună cu o copie a atributului cheie initial “ID_STUD” după care identificăm o cheie primară pentru noua noastră relatie.

Acum cele doua relaţii sunt următoarele:

Relaţia Studenţi (ID_STUD, NUME_STUD)
Relaţia CameraCamin ( ID_STUD, NR_CAMIN, ADR_CAMIN, DATA_INTR, DATA_IES, CAMERA, AN,

SPECIALIZARE)

 

Cele două relaţii sunt acum în FN1 deoarece avem o singură valoare la intersecţia dintre fiecare rând şi fiecare coloană.

O altă modalitate de a elimina grupul repetitiv este să transformăm un rând care conţine mai multe valori ale unui atribut în mai multe randuri care să conţină o singură valoare pentru acel atribut, iar relatia care va rezulta şi pe care am denumit-o CameraCamin va fi in FN1, apoi trebuie să identificam cheile candidat ale relaţiei noastre CameraCamin care sunt de fapt chei compuse şi anume (ID_STUD, NR_CAMIN), (ID_STUD, DATA_INTR), (NR_CAMIN, DATA_INTR). Acum alegem drept cheie primară urmatoarele atribute (ID_STUD, NR_CAMIN)

Relaţia CameraCamin o definim în felul următor:

CameraCamin (ID_STUD, NR_CAMIN, NUME_STUD, ADR_CAMIN, DATA_INTR, DATA_IES, CAMERA, AN, SPECIALIZARE)Această relaţie este în forma FN1 pentru că avem o singură valoare la intersecţia dintre fiecare rând şi coloană, dar totuşi relaţia noastră conţine date care se repetă de mai multe ori şi prin urmare este supusă anomaliilor de reactualizare. Ca să putem elimina această anomalie de reactualizare trebuie să transformam relaţia noastra în forma FN2.

A doua formă normala (FN2)

„O relaţie este în FN2 dacă şi numai dacă este în FN1 şi fiecare atribut care nu este cheie este ireductibil şi depinde de cheia primară.”
Pentru a aduce o relaţie din FN1 în forma FN2 trebuie să eliminăm dependenţele parţiale, iar acest lucru îl facem dacă eliminăm din relaţie atributele care sunt parţial dependente funcţional şi le plasăm într-o altă relaţie.
Să luăm în considerare următorul exemplu :
Analizăm dependenţele funcţionale din relaţia “CameraCamin” care are ca cheie primară atributele (ID_STUD, NR_CAMIN).

ID_STUD, NR_CAMIN -> DATA_INTR, DATA_IES (cheie primară)
ID_STUD -> NUME_STUD (dependenţă partială)
NR_CAMIN -> ADR_CAMIN, CAMERA, AN, SPECIALIZARE (dependenţă partială)
AN -> SPECIALIZARE (dependenţă tranzitivă)
ID_STUD , DATA_INTR -> NR_CAMIN, ADR_CAMIN, DATA_IES, CAMERA, AN, SPECIALIZARE (cheie candidat)
NR_CAMIN, DATA_INTR -> ID_STUD, NUME_STUD, DATA_IES (cheie candidat)

Acum verificam dacă relaţia “CameraCamin” se află în forma FN2 prin identificarea dependenţelor parţiale de cheia primară. Putem remarca următoarele:

Atributul (NUME_STUD) este dependent parţial de cheia primară ID_STUD.
Atributele (ADR_CAMIN, CAMERA, AN, SPECIALIZARE ) sunt parţial dependente de cheia primară, ele sunt dependente numai de atributul “NR_CAMIN”.

Ca să putem transforma relaţia “CameraCamin” în forma FN2 trebuie să creăm noi relaţii astfel încat să eliminăm atributele care nu sunt chei primare împreună cu o copie a părţii din cheia primară de care sunt total dependente. În acest mod obţinem trei relaţii noi şi anume:

Student (ID_STUD, NUME_STUD)
OcupareCamera (ID_STUD, NR_CAMIN, DATA_INTR, DATA_IES )
CaminStudent (NR_CAMIN, ADR_CAMIN, CAMERA, AN, SPECIALIZARE )A treia formă normală (FN3)

Ca să putem înţelege a treia formă normală (FN3) trebuie să înţelegem mai întai ce este dependenţa tranzitivă. Un atribut care depinde de alt atribut care nu este cheie primară sau identificator unic a unei relaţii spunem ca este dependent tranzitiv.
Ca să aducem la a treia formă normală (FN3) o relaţie care este în a doua formă normală (FN2), mutăm atributele dependente tranzitiv în relaţii în care depind numai de cheia primară.
„O relaţie este în FN3 dacă este în FN2 şi fiecare atribut care nu este cheie nu este dependent tranzitiv de cheia primară.”
Deci o relaţie este în a treia formă normală (FN3), atunci când aceasta îndeplineşte cerinţa de a fi în a doua formă normală (FN2) şi de asemenea:

– dependenţele funcţionale asupra câmpurilor care nu sunt cheie sunt eliminate prin plasarea acestora într-un tabel separat. La acest nivel, toate câmpurile (coloanele) care nu sunt cheie depind de cheia primară.
– un rând este în formă normală (FN3) dacă şi numai dacă este în a doua formă normală (FN2) şi atributele care nu contribuie la o descriere a cheii primare sunt mutate într-un tabel separat.

In exemplul următor analizăm dependenţele funcţionale din tabelele (relaţiile) „Student”, „OcupareCamera” şi „CaminStudent”.

Tabelul Student
ID_STUD -> NUME_STUD

Tabelul OcupareCamera
ID_STUD, NR_CAMIN -> DATA_INTR, DATA_IES
ID_STUD, DATA_INTR -> NR_CAMIN, DATA_IES
NR_CAMIN, DATA_INTR -> ID_STUD, DATA_IES

Tabelul CaminStudent
NR_CAMIN -> ADR_CAMIN, CAMERA, AN, SPECIALIZARE (dependenţa partială)
AN-> SPECIALIZARE (dependenţa tranzitivă)

Toate atributele tabelelor (relaţiilor) „Student” şi „OcupareCamera” care nu sunt chei primare sunt functional dependente doar de cheile primare. În aceste relaţii (tabele) nu avem dependente tranzitorii, deci se gasesc deja în FN3.
În tabelul (relaţia) „CaminStudent” atributul „SPECIALIZARE” este dependent tranzitiv de atributul „AN”. Ca sa putem transforma acest tabel (relaţie) în FN3 trebuie să eliminăm această dependentă tranzitivă. Facem acest lucru dacă cream alte două noi relaţii (tabele) şi anume „Camin” şi „Studentul”.

Camin (NR_CAMIN, ADR_CAMIN, CAMERA)

Studentul (AN, SPECIALIZARE)

Acum putem observa că tabelul nenormalizat „Studenti” l-am transformat prin intermediul procesului de normalizare în patru relaţii (tabele) de forma FN3. Acestea sunt:

Student ( ID_STUD, NUME_STUD )
OcupareCamera ( ID_STUD, NR_CAMIN, DATA_INTR, DATA_IES )
Camin ( NR_CAMIN, ADR_CAMIN, CAMERA )

Reguli de integritate

Modelul relațional definește anumite reguli de integritate, care, deși nu fac parte din definiția formelor normale sunt, totuși, o parte necesară a oricărei baze de date relaționale. Există două tipuri de reguli de integritate: generale și specifice bazei de date. Aceste reguli reglementează operațiile care pot fi efectuate asupra datelor și a structurii bazei de date.
Modelul relațional specifică două reguli generale de integritate. Acestea sunt denumite reguli generale, pentru că se aplică la toate bazele de date. Acestea sunt: integritatea entității și integritatea referențială. Regula de integritate a entității se referă la constrăngerea pe care cheia primară trebuie să o respecte şi aceasta ne spune că cheia primară nu poate conține valori “null” şi de asemenea trebuie să fie unică. Nu putem identifica în mod unic un rând sau să facem o referire într-un tabel, în cazul în care cheia primară a tabelului are valoarea “null”. De asemenea această regulă se aplică la ambele chei simple şi compuse. Pentru chei compuse, nici una dintre coloanele individuale nu pot fi de tip “null”. Dacă un tabel nu îndeplinește aceste două cerințe, spunem ca tabelul respectiv încalcă regula de integritate a entității.
Regula de integritate referențială spune că orice valoare a cheii externă (străină) trebuie să se potrivească la o valoare de cheie primară într-un tabel asociat. Integritate referențială ne asigură că putem naviga în mod corect între entitățile de legătură. Această constrângere este specificată între două tabele (părinte și copil), ea menține corespondența dintre rândurile din aceste tabele. Aceasta înseamnă ca referința unui rând dintr-un tabel în alt tabel trebuie să fie validă.

Exemplu de constrângere de integritate referenţiala:

Avem două relaţii, entitaţi sau tabele şi anume “ANGAJAT” şi “CONT” cu urmatoarele atribute/câmpuri:

ANGAJAT( ang_id, ang_nume)
CONT( cont_id, ang_id, data_cont)

Pentru a ne asigura că nu există înregistrări care nu se potrivesc, avem nevoie să impunem regula de integritate referențială. O înregistrare invalidă este acea valoare a cheii străine a cărei valoare nu este găsită în entitatea corespondentă, adică acolo unde se află cheia primară. Trebuie să existe o asociere între cheia primară şi cheia străină a celor două relaţii. Deci regula de integritate referinţială în cazul celor două entitaţi din exemplu ne spune ca “ang_id” din tabelul “CONT” trebuie să se potrivească cu valoarea cheii primare “ang_id” din tabelul “ANGAJAT”. Deci când se creează tabelele se stabilesc şi constrângerile de integritate referențială.

Securitatea în BD Oracle

De ce securizarea datelor ?
Este important să înțelegem de la bun început de ce trebuie să investim în securitatea unui SGBD ?
Voi incerca să răspund la această întrebare pe parcursul acestui capitol. Toate informaţiile care interesează şi prezintă importanţă se află de obicei stocate într-o bază de date. Fie că este vorba de date financiare, date despre o anumită companie, date despre clienţi sau angajați, informații despre carduri de credit, toate aceste informaţii se stochează în general într-o bază de date.
Securitatea, la fel ca orice altă investiție în domeniul IT trebuie să fie justificată şi să fie în măsură să răspundă la întrebarea de ce securizarea datelor este importantă. Securitatea este din multe puncte de vedere o artă defensivă. Trebuie să înțelegem atacatorii, care sunt motivațiile lor, spre ce anume ţintesc, şi modul în care aceştia vor încerca să işi atingă scopul. Pentru scenariul de jaf bancar, motivațiile şi ţinta sunt evidente. Efectuarea unei analize a securitaţii unei banci implică o înțelegere a faptului cine sunt potenţialii hoți, (angajați sau din afara bancii) şi modul în care aceştia vor încerca să fure banii. Dacă personalul unei instituţii de exemplu nu înțelege de ce anume trebuie să se protejeze şi ce anume poate oferi protecţie s-ar putea aplica o soluţie de securitate pentru o problemă care fie nu există, fie nu poate fi rezolvată cu tactica avută în vedere.
Multe dintre tehnicile folosite pentru a preveni furtul de către angajații băncii sunt diferite de cele folosite pentru a preveni furtul de la persoanele din afara băncii.
Dacă cineva întreabă, “Cum pot face în mod eficient criptarea datelor?” Ar putea să apară întrebarea, “De ce crezi că ai nevoie de criptarea datelor? Ce date vrei sa protejezi, şi de cine? Răspunsurile la aceste întrebări ne va ghida spre soluţia de securitate corectă şi ne ajută să ne asigurăm că folosim instrumentele şi tehnicile adecvate.


Proiectarea securităţii

Când suntem întrebati, “Când începe securitatea?” Mulți vor răspunde atunci când utilizatorul se autentifică. Securitatea începe atunci când este proiectată aplicaţia. Primul principiul este acesta: Securitate trebuie să fie construită în sistem, şi nu după aceea. O proiectare adecvată a securității ne ajută să ne asiguram că o aplicație va fi corect securizată.
Al doilea principiu pentru o securitate eficientă ne spune că securitatea ar trebui să fie compusă din mai multe nivele. Acest lucru implică faptul nu vom avea niciun punct slab sau vulnerabil în cadrul domeniului securității.Prin crearea de nivele multiple de securitate, putem genera un sistem cu securitate mai mare. În cazul în care se trece de un nivel, un alt nivel va ține locul. Apărare în profunzime este folosită cu succes în multe domenii ale tehnologiei, şi este, de asemenea, aplicabilă şi cererilor bazelor de date. Prin folosirea de instrumente adecvate securității, proiectate şi implementate pe mai multe nivele, putem să punem bazele pentru un mediu cu adevărat sigur.
Al treilea principiul eficient al securitaţii este acela de a se acorda mai puţine drepturi asupra sistemului (aplicaţiei). Cele mai puține drepturi înseamnă să acordăm oamenilor numai permisiunile de care au nevoie pentru a putea să işi facă treaba şi nimic mai mult.
Unul dintre cele mai simple moduri de a compromite un sistem este acela de a exploata acele conturi la care au fost acordate prea multe privilegii.
İdeea care stă la baza acordării privilegilor minime unui utilizator este simplă. Incepe prin neacordarea de drepturi şi apoi se acordă numai drepturile sau privilegiile minime necesare.
Nerespectarea principiului acordării celor mai mici privilegii poate duce la consecințe.
Pentru administratorii care nu sunt familiarizați cu securitatea bazei de date, este nevoie de muncă, în general, să se stabilească exact ce privilegii sunt necesare pentru a efectua un set de sarcini. grave. Sa luăm în considerare un exemplu în cazul bazelor de date.De ce nu este acest principiu respectat în mod regulat? Un motiv principal pentru care acest principiu nu este respectat este comoditatea. În principiu faptul de a acorda toate privilegiile unui utilizator este greşit.
Securitatea unei bazei de date se bazează pe privilegii. Abuzul de privilegii nu poate avea loc în cazul în care drepturile nu au fost acordate. În timp ce este nevoie de un efort suplimentar pentru a determina ce drepturi sunt necesare, este esențial menținerea privilegilor minime şi privilegile minime sunt necesare pentru o securitate eficientă.


Securizarea bazei de date Oracle

Ce trebuie să facem şi care sunt paşii necesari pe care trebuie sa-i urmăm în primul rând pentru a asigura securitatea în mod corespunzător într-o bază de date Oracle? În acest capitol, am să analizez patru elementele de bază pentru gestionare riscurilor utilizate pentru a proteja bazele de date Oracle şi datele lor:

1. Autentificarea
2. Controlul accesului
3. Configurarea securitaţii


4. Auditul1.Autentificarea

Autentificarea este primul pas în obţinerea accesului la o bază de date. Oracle are mai multe moduri de a se autentifica la baza de date. Prin aceste metode vin şi multe riscuri în cazul în care autentificarea nu este gestionată în mod corespunzător. Vulnerabilitățile cele mai evidente sunt conturile implicite şi parolele. De la lansarea versiunii Oracle9i, Oracle a blocat conturile, precum şi setarea parolelor asociate cu cele mai multe conturi implicite să expire după instalare. De fapt, doar câteva conturi sunt de obicei accesibile după instalare.
Există aproximativ 600 de combinaţii de nume de utilizator implicite şi parole care pot exista în Oracle, în funcție de modul în care este configurat. Este esențial pentru securitatea sistemului să modificăm aceste conturi implicite. Din fericire, în versiunea Oracle Database 11g, Oracle include vizualizarea „dba_users_with_defpwd’, care face mai uşor verificarea acestor conturi de utilizator cu parole implicite prin următoarea interogare:

SQL> SELECT * FROM dba_users_with_defpwd

Cu toate acestea, este important să ştim că nu toate parolele pot fi verificate prin intermediul acestei vizualizări. Unele sunt specifice aplicaţiei, şi nu ne putem aştepta la baza de date Oracle să ştie despre toate conturile specifice aplicatiei care pot fi adăugate la baza de date. De aceea, ar trebui să efectuăm încă o verificare pentru a vedea dacă avem conturi implicite rămase. Pentru a verifica aceste conturi, putem utiliza o listă de conturi implicită, şi apoi să o comparăm cu rezultatul pe care îl obţinem de la următoarea interogare:

SQL> SELECT username, password from dba_users;

Oracle oferă, de asemenea, protecţie în continuare profilurilor conturilor bazei de date. Prin interogarea „dba_users”, putem identifica ce profil a fost aplicat şi la care cont:

SQL> SELECT username, profile FROM dba_users;

Odată ce ştim ce profile sunt pârghie, putem interoga „dba_profiles’ pentru a determina setările de profil:

SQL> SELECT * FROM dba_profiles;

Aici vom găsi setările legate de parolă. Există, de asemenea, o serie de parametri de configurare care trebuie luaţi în considerare atunci când se utilizează conturi autentificate ale sistemului de operare, în special, „remote_os_authent” şi parametrii „remote_os_roles”. Aceste setări de parametri determină dacă Oracle va avea încredere în sistemele de operare de la distanță sau numai în sistemul de operare local pentru aceste conturi. De exemplu, în cazul în care „remote_os_authent” este setat la TRUE, Oracle va avea încredere în orice sistem de operare de la distanță. De aceea, trebuie să limităm numărul de conturi autentificate ale sistemului de operare şi ce sisteme de operare să poată să facă autentificarea. Următoarea interogare identifică conturile care sunt autentificate sistemului de operare:

SQL> SELECT username FROM dba_users WHERE password=’EXTERNAL’;2. Controlul accesului

Verificarea „control acces” este esenţială pentru securizarea în mod corespunzător a bazei de date.
După ce un utilizator a fost autentificat, controalele de acces dictează ce îi este permis utilizatorului să facă. Preocupările concernelor, de asemenea, a condus la acordarea utilizatorilor o serie de privilegii şi permise de care nu au nevoie. De exemplu, atunci când funcționalitatea nu lucrează cum era de aşteptat, un administrator ar putea emite o comandă de genul “acordă toate privilegiile utilizatorului”, pentru a permite accesul, uneori doar temporar, dar apoi uită să revină înapoi la privilegiile şi setările anterioare. Cu acest nivel de acces, utilizatorii primesc peste 100 de privilegii, dintre care multe din ele poate nu au nevoie. Există, de asemenea, o setare de acces public în care orice utilizator care are un cont la baza de date Oracle automat i se acordată privilegii publice. În mod implicit, privilegile publice au un număr mai mare de drepturi, dintre care multe ar trebui să fie limitate în majoritatea mediilor. Un privilegiu specific poate să obţină literalmente privilegii publice. Atunci când controalele de acces sunt inactive trebuie să ne uităm la privilegiile fiecărui utilizator individual, precum şi la privilegiile acordate pentru public.
Următoarele interogări identifică privilegiile acordate în cadrul mediului:

SQL> SELECT * FROM dba_sys_privs;
SQL> SELECT * FROM dba_role_privs;
SQL> SELECT * FROM dba_col_privs;
SQL> SELECT * FROM dba_tab_privs;

Separarea sarcinilor este de asemenea importantă. Separarea sarcinilor se aplică într-o mulțime de moduri diferite în cadrul medilor. De exemplu, rolurile administratorului bazei de date şi audit-ului trebuie să fie diferite şi cu responsabilități şi cerințele de acces separate. Este, de asemenea, important să se separe mediile de producție, de cele de testare, precum şi de dezvoltare.
Ca o concluzie, trebuie să luăm, în considerare aplicaţia. Fiecare aplicaţie este diferită şi poate introduce riscuri unice la baza de date, cum ar fi vulnerabilitatea la atacurile SQL injection şi aplicarea altor metode de atac a bazei de date.


3. Configurarea securităţii

Am să subliniez unele dintre domeniile-cheie de configurare. Acestea includ:
Ascultarea portutilor: punctul de contact inițial pentru o bază de date Oracle este portul ascultat. Atunci când un utilizator doreste să se conecteze de la distanță la baza de date Oracle, el se conectează de fapt la portul pe care asculta aplicaţia server pentru a face acea conexiune. Fără ascultarea porturilor, nu ne putem conecta la baza de date. Este important să ne asigurăm că suntem conectaţi la porturile pe care asculta aplicaţia server. Mecanismele de autentificare locală a sistemului de operare au fost încorporate în toate versiunile de Oracle de la lansarea Oracle Database 10g. Fişierul „listener.ora” va conține informații despre setările de conectare.
Parametrii: Ca urmare există o listă de parametri-cheie care pot controla multe din riscurile de securitate în baza de date. Desigur, aceştia nu sunt toți parametrii importanți, dar sunt cei mai mari parametrii cu grad mare de risc. Unii dintre aceşti parametri nu au existat înainte de versiunea Oracle Database 11g, deşi majoritatea au existat. Aceştia sunt:

• AUDIT_FILE_DEST
• AUDIT_SYS_OPERATIONS (Should be set to TRUE.)
• AUDIT_TRAIL (Avoid FALSE or NONE settings.)
• DIAGNOSTIC_DEST
• DISPATCHERS
• GLOBAL_NAMES (Should be set to TRUE.)
• LOG_ARCHIVE_% (Note: There are multiple parameters that exist that begin with LOG_ARCHIVE.)
• MAX_ENABLED_ROLES
• O7_DICTIONARY_ACCESSIBILITY (Should be set to FALSE.)
• OS_AUTHENT_PREFIX (Should be set to NULL, if possible. Should not be set to ops$.)
• OS_ROLES (Should be set to FALSE.)
• REMOTE_LISTENER (Should be set to NULL, unless a remote listener is needed.)
• REMOTE_LOGIN_PASSWORDFILE (Should be set to NONE, if possible.)
• REMOTE_OS_AUTHENT (Should be set to FALSE.)
• REMOTE_OS_ROLES (Should be set to FALSE.)
• RESOURCE_LIMIT (Should be set to TRUE.)
• SEC_CASE_SENSITIVE_LOGON (Should be set to TRUE.)
• SEC_MAX_FAILED_LOGIN_ATTEMPTS (Should be set to 10.)
• SEC_PROTOCOL_ERROR_FURTHER_ACTION (Avoid the setting NONE.)
• SEC_PROTOCOL_ERROR_TRACE_ACTION (Avoid the setting NONE.)
• SEC_RETURN_SERVER_RELEASE_BANNER (Should be set to FALSE.)
• SMTP_OUT_SERVER (Should list only authorized SMTP servers, if utilized.)
• SPFILE
• SQL92_SECURITY (Should be set to TRUE.)
• UTL_FILE_DIR (Should be set to a specific directory used only for necessary purposes. Values such as /tmp or * should not exist.)
• _TRACE_FILES_PUBLIC (Should be set to FALSE.)Putem aborda vulnerabilitățile de securitate pe care le-am menționat mai sus, prin aplicarea patch-urilor. Fara patch-uri corespunzătoare în vigoare, un atacator ar putea folosi vulnerabilitățile respective pentru a exploata privilegiile lor sau chiar pentru a obţine accesul.

Pentru a vizualiza patch-urile care au fost instalate, utilizăm comanda „opatch lsinventory” de la sistemul de operare. În cele din urmă, în cazul în care am simplifica foarte mult o bază de date Oracle, aceasta este în esență o grămadă de fişiere pe un sistem de operare, de aceea, securitatea sistemului de operare este critică. În plus, măsurile de securitate de rețea, cum ar fi firewall-uri, IDS / IPS, segmentarea, şi asa mai departe, sunt extrem de utile şi oferă niveluri suplimentare de protecție împotriva atacatorilor şi abuzurilor din interiorul bazei de date.


4. Auditul

Securitate înseamnă nu numai prevenirea atacurilor, de asemenea, înseamna şi detectarea potențialelor atacuri. Acesta este cazul în care auditul poate fi benefic. Auditul ne permite să monitorizăm mediul şi să identificăm potențiale atacuri. În primul rând parametrul „audit_sys_operations” ar trebui setat la valoarea TRUE. Parametrul „audit_trail” ne spune dacă auditul bazei de date a fost activat în cadrul bazei de date şi unde acesta a expediat datele.
De exemplu, datele auditului (de control) pot fi scrise în baza de date, syslog, sau în fişiere XML în funcție de cum este specificat parametrul. Presupunând că auditul a fost activat, vizualizările specifice ne spune ce se întâmpla. Concret, următoarele interogări ne spun dacă conţinutul vizualizărilor respective sau un privilegiu sunt verificate.

SQL> SELECT * FROM dba_stmt_audit_opts
SQL> SELECT * FROM dba_priv_audit_opts;Putem utiliza următoarea interogare pentru a determina obiectul verificat:

SQL> SELECT * FROM dba_obj_audit_opts;

În cazul în care auditul(controlul) nu este activat, trebuie să activăm auditul de activități, cum ar fi crearea de sesiuni şi alte date şi comenzi definite precum crearea sau stergerea tabelelor. Începand cu versiunea Oracle Database 11g, Oracle oferă o listă recomandată de setări implicite de control (audit). Putem activa aceste setări pe timpul instalării versiunii Oracle Database 11g Release 1. Oracle Database 11g Release 2 porneste automat setările implicite recomandate.
Putem vedea lista setărilor implicite de control (audit) în documentația Oracle.
După ce am activat setările de audit (control), este important să centralizăm datele auditului şi să cream rapoarte, astfel încât să putem revedea înregistrările auditului.


Criptarea

Criptografia este un termen larg care include utilizarea de tehnici matematice, în contextul securitătii informațiilor. Cuvântul provine din cuvintele grecesti „Krypto” care înseamnă “ascuns” şi „Grafo”, care înseamnă “a scrie”. Cei mai mulți oameni echivalează criptografia cu criptarea. Criptarea este procesul de conversie a textului clar în text cifrat. Desi criptarea este cu siguranță una dintre cele mai comune utilizări ale criptografie, aceasta nu este singurul lucru care se utilizează pentru chei şi algoritmi. Principalele elemente ale criptografie pe care le voi prezenta în acest capitol sunt:

Cifrurile bloc – de exemplu, Cipher Block Chaining (CBC)
Algoritmi cu cheie simetrică – de exemplu, AES si 3DES
Algoritmi cu cheie publică – de exemplu, rural service area (RSA)
Certificate – de exemplu, certificate X.509
Mesaje rezumate – de exemplu secure hash algorithm-1 (SHA-1) si (MD5)
Semnăturile digitale – de exemplu, semnăturile digitale RSA
Serviciile de securitate – de exemplu, SSL
Aceste elemente sunt apoi utilizate pentru următoarele scopuri (toate acestea sunt relevante în securitatea Oracle):
Confidențialitatea, cum ne putem asigura că spargătorii de coduri sau un hoţ care sustrage datele wireless nu le poate citi?
İntegritatea mesajului, cum putem şti că un mesaj nu a fost falsificat şi modificat înainte de a ajunge în baza de date?
Autentificarea – cum putem şti că un mesaj sau o acțiune vine de la o anumită persoană sau organizaţie?Criptare, algoritmi de criptare, şi cifruri

Criptarea este procesul de transformare a textului clar într-o anumită formă folosind un algoritm pentru a îl face imposibil de citit pentru oricine, cu excepția celor care posedă cunostințele necesare înţelegerii lui.
Există două tipuri de criptografie sau criptare, algoritmi cu cheie simetrică şi criptografie cu cheie publică. În criptografia cu cheie simetrică cele două părți comunică partajand aceeaşi cheie (ele pot fi diferite, dar pot fi calculate cu usurință una din alta). Aproape toate metodele de criptare / decriptare în lume se bazează pe criptografia cu chei simetrice – inclusiv toate metodele pe care le foloseste Oracle pentru a cripta datele în tranzit.

Există mulţi algoritmi de cheie simetrică (sau cifruri). Toate aceste cifruri funcționează în acelasi mod în ceea ce priveste faptul că o cheie de criptare se utilizează pentru criptarea textului clar pentru a forma un text cifrat şi apoi aceeaşi cheie este utilizată pentru a decripta textul cifrat în text clar. Există mai multe cifruri pe care le putem alege. Atunci când utilizam criptarea în cadrul Oracle vom putea alege unul din aceste cifruri:

DES-DES este un algoritm pe care nu ar trebui să-l folosim niciodată. DES a fost ales ca standardul oficial american în 1976, când computerele erau mult mai slabe în ceea ce priveste puterea de procesare. Algoritmul a fost întotdeauna controversat, are o lungime scurtă a cheii de 56 de biți, şi pentru că părțile din el sunt clasificate, s-a crezut întotdeauna că US National Security Agency (NSA) a menținut o cale de acces spre acest algoritm. Cu calculatoare de astăzi se poate sparge DES în aproximativ 24 de ore, deci e bine să nu-l utilizăm niciodată.

3DES – triplu DES este un algoritm care a fost în uz pe scară largă şi este încă – în special în sectorul financiar. Acesta este considerat a fi un algoritm puternic, dar există algoritmi mai buni in ziua de azi pe care îi putem alege. DES este prea slab din cauza cheii sale scurte de 56 biti, astfel 3DES a evoluat ca o modalitate simplă de a consolida criptarea împotriva atacului de tip „brute force”. Există două variante. In prima variantă, numită EEE, sunt făcute trei etape de criptare. În a doua variantă, numită EDE, primul pas şi al treilea sunt pasi de criptare, dar al doilea pas este un pas de decriptare (evident, nu cu aceeaşi cheie ca primul pas). 3DES fie are o lungime de 168 biți a cheii (de trei ori 56 biți utilizati în DES) sau 112 biți în cazul în care prima şi a treia cheie DES sunt aceleaşi.

AES-AES este algoritmul pe care ar trebui să-l utilizăm întotdeauna dacă avem de ales. AES (cunoscut sub numele de Rijndael ) a fost adoptat ca standard de criptare de catre guvernul Statelor Unite în 2002, după o perioadă de cinci ani cât a durat procesul de analiză, comparație şi selecție. Acesta a fost analizat pe larg şi este utilizat pe scară largă în toată lumea. Dimensiunile cheilor sunt fie 128, 192, sau 256 biti – adică AES128, AES192, AES256 deci optiuni care pot fi selectate atunci când acestea apar în Oracle.

AES, 3DES, DES toate sunt numite cifruri bloc. Se numesc cifruri bloc, deoarece acestea funcționează întotdeauna pe un bloc de date.

Criptografie cu cheie publică

În criptarea cu cheie simetrică, cele două chei utilizate pentru criptare şi decriptare sunt aceleaşi (sau strâns legate) şi trebuie să ne asiguram că ambele părți au aceeaşi cheie. În criptografia cu cheie publică cheia de criptare este complet diferită de cheia de decriptare. Când utilizam criptografia cu cheie publica avem două chei, o cheie publică şi o cheie privată. Atunci când dorim să trimitem un mesaj spre o altă parte utilizam o cheie publică pentru a cripta mesajul şi partea care primeste mesajul utilizează cheia lor privată pentru a decripta mesajul. Dacă utilizam aceeaşi cheie folosită la criptare pentru a decripta, mesajul pe care îl vom primi va fi un nonsens ( fară înteles). Doar cheia privată care se potriveşte cheii publice ne va ajuta să obţinem textul în clar din cel criptat. Există o proprietate foarte importantă în matematică şi anume că criptografia cu cheie publică se bazează pe faptul că nu se va demonstra existența unor perechi de chei, care sunt complementare între ele, care pot fi uşor generate de un algoritm, că nu există nicio cheie de altă natură care pot fi inversate între ele, şi că nu se poate calcula una din cealaltă.

Deci criptografia cu cheie publică nu are o problemă în a distribui cheia, problemă care exista în criptografia cu chei simetrice. Dacă dorim ca un client şi serverul să comunice printr-un canal nesigur tot ce trebuie să facem este să generăm două perechi de chei publică / privată – o cheie pentru client şi una pentru server.

Cheia publică nu poate fi utilizată pentru a decripta mesajul numai cheia privată poate face acest lucru şi cheia privată nu poate fi calculată din cheia publică. Serverul primeşte mesajul şi îl decriptează folosind cheia sa privată. Daca vrea să trimită un răspuns clientului, ia mesajul şi îl criptează folosind cheia publică a clientului. Acest text criptat este trimis pe canalul nesigur şi clientul îl decriptează folosind cheia sa privată. Clientul şi serverul reuşesc să comunice fără să partajeze vreun secret.

De ce avem nevoie de criptografia cu chei simetrice?
Motivul este că, desi criptografia cu cheie publică rezolvă într-adevăr problema de distribuţie a cheii, criptarea cu cheie publica este de aproximativ 1000 de ori mai lentă decât criptarea cu chei simetrice. Acesta este un motiv de ce încă se foloseşte criptarea cu cheie simetrică.


Identificarea

Procesul securitaţii bazei de date poate fi sintetizat prin următoarele trei etape:
În primul rând, un utilizator prezintă o identitate în baza de date. De exemplu, introduce numele de utilizator Utilizatorul dovedeste că identitatea prezentată este valabilă. De exemplu, el furnizeaza o parolă. Parola este verificată de către baza de date pentru a determina dacă aceasta este parola corectă pentru numele de utilizator prezentat. Presupunând că parola este corectă, baza de date presupune ca identitatea poate fi de încredere. Baza de date va determina, pe bază de identitate, ce privilegii şi autorizații are utilizatorul. Accesul la date este reglementat de privilegiile utilizatorului şi de autorizații.
De obicei, oamenii îşi petrec majoritatea timpului lor şi fac eforturi pentru a pune în aplicare procesele necesare pentru al treilea pas. Primele două etape sunt importante, deoarece ele formează temelia securitaţii; avem nevoie de ele pentru a ajunge la pasul trei. Pasul unu este de identificare, iar pasul doi este de autentificare.
Există un fapt adesea trecut cu vederea în proiectarea şi implementarea de soluţii de securitate şi anume – securitate nu se poate baza pe anonimat. Deci intâi trebuie să ne identificăm, să dăm dovada că suntem, de fapt, cine pretindem că suntem. Dacă o aplicație de baze de date nu ştie cine suntem, nu ne poate acorda autorizațiile sau privilegiile corespunzătoare, se aplică controalele de acces necesare.


Metode de identificare

Identificarea este procesul specific şi distinct de recunoaştere clară a unei identităti (persoană). İdentificarea este o parte din viața de fiecare zi. Ne identificăm la locul de muncă, la telefon, prin e-mail, ne identificăm atât de mult încât probabil că nici nu ne dăm seama chiar şi atunci când o facem. İdentificarea vine în multe forme: fotografii cu noi inşine, amprente digitale, numărul de angajat , numărul de cont bancar sau a cardului de credit şi desigur, numele nostru de utilizator, toate acestea ne pot reprezenta pe noi în procesul de identificare.
Astăzi, există mai multe forme de identificare şi multe moduri de a ne identifica. Metodele de identificare se încadrează în două categorii: utilizatorul furnizează identitatea şi identificarea realizată de tehnologie.


Identificare furnizată de utilizator

Solicită utilizatorului să furnizeze propria identitate, este metoda cea mai răspândită pentru identificarea din ziua de azi. În majoritatea aplicațiilor informatice, identificarea se bazează pe numele de utilizator. Banca unde avem un cont de exemplu, probabil, îi place să ne identifice după numărul contului nostru. În toate cazurile, utilizatorul este responsabil pentru furnizarea de informații corecte de identificare. Acest lucru este important, deoarece cunoaşterea unei identităţi valabile oferă o anumită siguranță. De exemplu, nu putem retrage bani dintr-un cont bancar care nu există. Este puțin probabil să putem să ne conectam la baza de date, dacă nu se poate furniza un nume de utilizator valabil bazei de date. Pentru hackeri care încearcă să pătrundă într-un sistem, un bun punct de plecare este să obțină o listă de utilizatori valabilă pe sistem. Numele de utilizator “Administrator” implică privilegii mari şi prin urmare, este o țintă de atac mai valoroasa pentru un hacker decât un nume mai neutru, cum ar fi “Utilizator 123.” care are privilegii mai reduse. Cu toate acestea, proiectarea şi punerea în aplicare a securitaţii bazate exclusiv pe cunoaşterea identificatorului de exemplu, un nume de utilizator sau numărul de cont este riscantă, deoarece acesta poate fi relativ usor de ghicit sau de a obține o identitate valabilă din altă sursă.

Avantajul de a folosi identificarea furnizată de utilizator este că identificatorul (de exemplu, numele de utilizator) este, în general, flexibil. Acest lucru permite administratorilor să creeze identificatori intuitivi, care sunt usor de reamintit pentru utilizatori. De exemplu, un nume de utilizator poate fi creat pe baza primei initiale a numelui persoanei şi prenumele, dar acest beneficiu este o slăbiciune. Identificatorii, care pot fi ghiciti cu usurință pot slăbi securitatea globală.


Identificare realizată prin tehnologie

Tehnologia oferă, de asemenea, o varietate de moduri de a ne identifica, inclusiv date biometrice, identitatea calculatorului, şi identitățile digitale.

Tehnologia biometrică

O tehnologie în continuă crestere şi interesantă care vine în sprijinul modalitaţii de identificare a utilizatorului este tehnologia biometrică. Biometria se refera la caracteristicile biologice ale oamenilor, care pot fi măsurate pentru a distinge diferențele dintre aceştia. Putem utiliza datele biometrice în mod constant pentru a identifica persoane. Creierul nostru foloseşte recunoaşterea facială, când vedem persoane familiare şi recunoaştem vocea atunci când răspundem la un apel telefonic de la o persoană pe care o cunoaştem.

Mai multe companii în prezent încearcă să aducă la maturitate diverse tehnologii biometrice. Recunoaşterea facială, scanerea irisului, geometria mâinii, şi cititoare de amprente sunt printre cele mai populare. Datele biometrice sunt ideale din multe puncte de vedere. Utilizatorii nu le pot uita, şi aceste date pot fi aproape imposibil de ghicit. Furtul părții biometrice este puțin probabilă, dar există un risc asociat cu reprezentarea digitală biometrică care poate fi furată. Confuzia referitoare la cum sunt utilizate datele biometrice este frecventă. Acest lucru se datorează faptului că datele biometrice pot fi folosite atât pentru identificare cât şi în procesele de autentificare. Cu identificarea biometrică, informaţiile biometrice sunt considerate unice şi pot fi utilizate pentru a identifica cu exactitate persoana care prezintă aceste date biometrice. Acest mod de identificare diferă de identificarea furnizată de utilizator, deoarece utilizatorul nu va spune sistemului cine este, sistemul îl identifică în mod automat. De reținut un lucru, aceasta nu este autentificare, aceasta este doar identificarea, autentificarea biometrica este procesul de comparare a semnăturii, datele biometrice, cu o referință pentru a dovedi sau infirma o identitate.


Identitatea calculatorului

În mediu de calcul, identitatea se poate baza pe alte elemente non-standard, cum ar fi numele computerului, adresa de rețea fizică (de exemplu, adresa MAC identificator unic pe cardul de rețea pentru calculator), adresa de rețea logică (adresa IP), sau alte dispozitive care poate fi aplicate la un calculator. Adresele IP şi domenii de IP sunt utilizate în cadrul arhitecturii de securitate destul de frecvent. Adresei respective sau domeniului fie îi este permis accesul fie nu.

Firewall-urile şi diverse tehnologii securizate de rutare sunt puternic dependente de adrese MAC şi adresele IP. Servere de aplicații şi bazele de date securitate pot utiliza, de asemenea, adresele IP pentru a ajuta la furnizarea de straturi suplimentare de securitate.


Identităţi digitale

O altă formă răspândită de identificare este prin intermediul reprezentării digitale sau identităților digitale. Un exemplu vazut azi e certificatul digital utilizat ca parte a infrastructurilor de chei publice (PKI). PKI oferă mai multe capabilități de securitate, inclusiv identificarea, autentificarea şi criptarea. Pentru identificare PKI utilizează certificate digitale bazate pe un format standard cunoscut sub numele de X.509. Entitățile, de obicei, utilizatorii de calculatoare sau servere, primesc certificate digitale unice care reprezintă identitatea lor. Certificatele includ informații descriptive despre entitate, cum ar fi numele lor, numărul de angajat, organizarea, şi locația.

Ne putem gândi la un certificat ca la un paşaport digitalizat. Identitățile digitale sunt bine definite, atât structural cât şi semantic, şi sunt consecvente în toate aplicațiile şi platforme care acceptă standardele certificate. Acest ultim punct este esențial pentru asigurarea interoperabilității între aplicațiile şi produsele oferite de către diferiţi furnizori. Certificatele digitale sunt populare, nu numai pentru că certificatele sunt bazate pe standarde, dar şi pentru că certificatele conțin informații suplimentare care pot fi utilizate în punerea în aplicare a controalelor de securitate eficiente. Pentru identificarea utilizatorului, certificatele digitale sunt de obicei instalate în browserele Web ale utilizatorului. Ele pot fi, de asemenea, integrate în dispozitivele fizice, cum ar fi cardurile inteligente. Pentru a securiza identitatea digitală, utilizatorul poate fi obligat să furnizeze un cod PIN sau o parolă pentru deblocarea certificatului.

Una dintre provocările pentru punerea în aplicare a securității eficiente implică asigurarea identităților. În cazul în care securitatea se bazează pe identificarea corectă, atunci este firesc să tragem concluzia că această verigă în procesul de securitate prezinta un grad sporit de risc. Daca compromitem procesul de identitate, am şi compromis integritatea şi securitatea aplicatiei bazei de date, sau ambele.


Falsificarea

O modalitate deosebit de eficientă şi care are succes pentru a învinge o bună securitate este de a dejuca securitatea. În loc de a încerca să depăsim controalele de acces şi de a evita auditarea, se poate pretinde că suntem altcineva decât ceeia ce suntem. Deghizat ca un alt utilizator, sau falsificarea, este echivalentul digital al furtului de identitate. Acest „altcineva” poate fi un utilizator privilegiat sau doar un alt utilizator. În ambele cazuri, falsificarea poate duce la rezultate dezastruoase. Prin intermediul falsificării, securitatea sistemului poate deveni un aliat pentru atacator. De exemplu, este posibil să nu fie chiar aşa de dificil de a copia sau fura un certificat digital care nu este corect securizat. Certificatele digitale, care pot acționa ca identitaţi digitale, sunt mici (aproximativ 10KB) și pot fi usor stocate pe mai multe dispozitive, cum ar fi dischete, drive-uri USB, etc. Dacă certificatul este furat, acesta poate fi apoi folosit pentru a falsifica identitatea şi autentificarea unui utilizator. Arhitectura de securitate a rețelei poate include firewall-uri, criptarea de rețea şi sisteme de detectare a intruşilor, dar niciunul nu poate detecta acțiunile de falsificare în curs de desfăşurare. Acest lucru, în general, se întâmplă doar în cazul în care certificatul nu este asigurat de către un alt factor, cum ar fi o parolă puternică sau codul PIN.

Retragerea certificatului, care există în aproape toate aplicațiile care acceptă certificate digitale, rezolvă utilizarea ilicită a certificatelor digitale, dar numai atunci când utilizatorul sau administratorul devine constient de faptul că furtul a avut loc.

Există nenumărate moduri de a falsifica şi a pretinde că suntem altcineva, dar ideea principala este ca identitatea utilizatorului este esențială pentru procesul de securitate. Garantarea ca identitatea este securizata printr-o autentificare corespunzătoare, implementarea şi monitorizarea este esențială pentru a asigura o securitatea eficientă.


Furtul de identitate

Furtul de identitate este o problemă tot mai mare care afectează lumea de astăzi. În termeni simpli furtul de identitate este pur şi simplu utilizarea abuzivă şi declarații false de informații asociate cu un singur individ pentru beneficiul altuia. Această circumstanță nefericită s-a intensificat în ultimii ani din numeroase motive. Protejarea identității utilizatorului poate fi la fel de importantă ca şi protejarea datelor de identitate a persoanei respective prin care se obţine accesul. Cunoscându-se chiar şi puţine date precum un număr de identificare a unei persoane şi data ei de naştere de exemplu, cineva poate fi în măsură să fure o identitate pentru a deschide un cont bancar nou, să aplice pentru împrumuturi, să cumpere diverse lucruri scumpe, sau să facă nenumărate alte activități ilegale, sub pretextul de a fi altcineva decat este în realitate.

Deoarece o mulțime de informații care pot fi utilizate pentru a crea identități false sunt deturnate din bazele de date şi aplicații prost concepute. Alegerea necorespunzătoare a unui element de identificare ar putea fi un catalizator pentru furtul de identitate. Să ne uităm la o structură de tabel posibilă ca să vedem ce riscuri există.

CREATE TABLE CLIENTI (Nume VARCHAR2(50),
Prenume VARCHAR2(50),
Nr_identif_client VARCHAR2(11),
Zi_nastere DATE);Datele din acest tabel sunt în mod clar importante (sensibile). Protejarea accesului la datele din acest tabel este o cerință de securitate evidentă. La prima vedere nu există un risc de securitate chiar atât de evident şi din acest motiv nu este neobişnuit şi anume ca un proiectant de aplicații de baze de date să utilizeze „Nr_identif_client” ca un identificator al clientului. Acest lucru este foarte riscant şi considerat a fi o decizie foarte proastă. Motivul este faptul că identificatorii clienţilor sunt uneori necesari dezvoltatorilor de aplicații pentru testare sau depanare, sau pentru verificarea accesului la baza de date de către administratorii bazei de date.

Astfel, există un risc semnificativ ca numarul de identificare al clientului şi numele sau data de naştere să fie folosite neadecvat, scrise pe o hârtie şi lăsate pe birou, sau expediate pe e-mail într-o manieră nesigură. Acest lucru ar putea conduce la dezvăluirea neintenționată de informații importante (sensibile). Acesta este tipul de practici, care pot duce la furtul de identitate. Deci ar trebui să evaluăm şi să mânuim cu grija identitătile pe care le utilizăm şi să ne asigurăm că informaţiile confidenţiale nu sunt folosite pentru a reprezenta identitatea clientului.


Autentificarea

Prezentând o identitate unui sistem informatic este din punct de vedere tehnic tot ceea ce este necesar pentru ca sistemul să acorde autorizațiile corespunzatoare, să impună controlul accesului şi auditul. Dar este bine ca, o identitate, în general, să fie însoţită de altceva care dovedeşte că identitatea persoanei este legitimă. Pentru ca o identificare să se execute cu succes, trebuie să existe un proces pentru a dovedi că o persoană este cea care pretinde a fi, iar acest proces este denumit autentificare.


Metode de autentificare
Metodele de autentificare se încadrează în următoarele trei categorii:

Ceva ce stim, cum ar fi de exemplu o parolă sau un număr de identificare personală (PIN). Parolele sunt metoda de autentificare cea mai comună pentru sistemele informatice, deoarece acestea sunt, în general, uşor de implementat şi întretinut.
Ceva de ce dispunem, cum ar fi un certificat X.509, un card inteligent, o cheie de maşină, un card de credit, sau o cheie de licență software. Uneori, autentificarea este doar pentru a dovedi că suntem o entitate legitimă, cum ar fi un card de acces într-o clădire care dovedeşte că suntem un angajat sau o cheie de licență care dovedeşte că suntem persoana sau entitatea care am plătit pentru software-ul respectiv.
Datele biometrice, amprentele digitale, recunoaştere facială, scanarea irisului, şi poate într-o zi ADN-ul va fi utilizat pentru autentificarea oamenilor.

Autentificare puternică, de obicei, implică faptul că autentificarea nu poate fi usor de ghicit sau falsificat. Tehnologiile de autentificare au diferite abilități pentru a îndeplini sarcinile lor de autentificare. Unul dintre criterile pentru determinarea complexitătii de autentificare este de exemplu, cât de greu este să se falsifice metoda de autentificare.

Ceva ce noi suntem şi ceva ce noi avem (posedăm) sunt considerate forme mai puternice de autentificare decât ceva ce noi stim. Parolele pot fi ghicite şi prin urmare, sunt considerate metode de autentificare slabă. Falsificarea unui certificat X.509 (ceva ce avem) sau duplicarea datelor biometrice (ceva ce avem), nu este la fel de usor de falsificat ca şi ceeia ce ştim (parolele). Prin urmare, certificatele digitale, autentificări biometrice sunt considerate metode puternice de autentificare.

Nu vreau aici să sugerez că parolele nu ar trebui să fie utilizate pentru autentificare. Putem de exemplu, în calitate de administrator de baze de date, să ne asigurăm că utilizatorii bazei de date folosesc parole puternice prin implementarea unei rutine în care se utilizează parole de complexitate mare şi un profil de parolă.


Cele mai bune practici de autentificare securizată. Criptarea autentificatorilor.

Criptarea este un instrument important pentru securizarea autentificatorilor. De exemplu, să presupunem ca un utilizator se autentifică cu o amprentă. Dacă amprenta este trecută printr-un canal necriptat de rețea, o persoana rău intenţionată cu un program de tip detector de rețea ar putea înregistra identitatea utilizatorului şi amprente digitale. Mai târziu, acea persoana rău intentionată ar putea reda sau să prezinte identitatea capturată şi amprenta digitală, astfel falsificând cu succes utilizatorul inițial. Cu criptare de rețea, o nouă cheie este utilizată pentru fiecare sesiune de comunicare. Cheia care a fost capturată şi folosită în prima sesiune nu mai poate fi refolosită mai tarziu. Refolosind o captură a unor date biometrice criptate care au fost capturate nu vor funcționa folosind criptarea standard de rețea, cum ar fi SSL. Autentificatorii au un risc mare, deoarece acestea adesea traversează rețelele de calculatoare. Criptarea traficul de rețea este o apărare bună împotriva copierii autentificatorilor. Criptarea întregului flux de rețea asigură o securitate optimă. Criptarea protejează nu numai autentificatorii, dar, de asemenea protejează şi identităţile utilizatorilor, interogările acestora, precum şi rezultatele returnate.

Asigurarea securității pentru stocarea autentificatorilor este la fel de importantă. Adesea, autentificatorii vor fi păstraţi într-o formă criptată pentru a păstra confidențialitatea autentificatorului.


Abrevierea (prescurtatea) autentificatorilor

Atunci când sunt utilizate parole pentru autentificare, parolele nu ar trebui să fie stocate în text clar. Criptarea pare a fi soluția optimă, dar nu este. Criptare, este procesul de conversie a textului în clar în text indescifrabil, dar implică decriptarea, care este procesul de conversie a textului indescifrabil înapoi în text clar.

Criptarea parolelor, care permite o probabilă decriptarea a acestora, ar putea obţine parolele în text clar. Pentru a rezolva acestă problemă, se poate utiliza o tehnologie numită abrevierea sau prescurtarea parolelor. Prin intermediul abrevierii textul în clar se converteşte în text indescifrabil. Spre deosebire de criptare, nu există nicio modalitate de a obţine înapoi textul în clar. Deci, nu există nici o modalitate de a lua o valoare în forma abreviată şi apoi să determinăm ce a creat această valoare. Abrevierea este numită o funcție unidirecțională din cauza acestei proprietăţi. O altă proprietate importantă a abrevierii este faptul că aceeaşi intrarea va genera întotdeauna aceeaşi ieşire. Autentificarea prin parolă are loc prin abrevierea parolei şi stocarea rezultatului într-o valoare trunchiată sau abreviată. Atunci când utilizatorul introduce o parolă pentru autentificare, valoarea autentificarii furnizate de utilizator (a parolei), va fi comparată prin intermediul procesului de autentificare cu valoarea abreviată stocată. Dacă valoarea trunchiată sau abreviată se potriveste, atunci intrarea trebuie de asemenea sa se potrivească şi prin urmare parolele sunt aceleaşi. Modalitatea de abreviere poate fi folosită pentru alți autentificatori în acelaşi mod.

Din moment ce autentificatorii nu se folosesc pentru activități cum ar fi sortarea, calcule cumulate şi aşa mai departe, abrevierea este o soluție bună pentru stocarea datelor de autentificare. Abrevierea cu cheie, care presupune o criptare a valorii abreviate, este adesea o alternativă mai bună decât abrevierea de bază, atât timp cât cheia poate fi protejată.

Baza de date

Un mecanism primar al unei baze de date este numele de utilizator şi parola. Autentificarea este critică, deoarece numele de utilizator poate fi ghicit şi în unele cazuri, sunt bine cunoscute. Pentru utilizatorii identificați în baza de date avem următoarele opțiuni de autentificare:

Parolele: Parolele pot fi fie autentificate de către baza de date sau de catre Oracle LDAP
Oracle suportă autentificarea sistemului de operare şi autentificări puternice, care includ certificate PKI, Kerberos, DCE şi RADIUS. Standardul RADIUS extinde capacitățile de autentificare pentru a include elementele biometrice integrate, şi carduri inteligente.Asocierea utilizatoriilor cu schemele bazelor de date

Atunci când se pune problema construirii de aplicaţii, există de obicei trei modele care pot fi folosite pentru cartografierea utilizatorilor finali la conturile de baze de date. Există diferite beneficii şi riscuri în cadrul fiecărui model, aşa că este important să inţelegem fiecare model. Această înțelegere este crucială, deoarece modelul de multe ori limitează ceea ce facem şi cum o facem.

1:1 Această schemă „unu-la-unu „ se produce în principal în programe client-server. Acest lucru înseamnă că fiecare utilizator final are un cont distinct bazei de date.
N: M Acesta schemă „totii-la-mai-multi” se întâmplă ocazional în aplicații Web. Aceasta înseamnă că toți utilizatorii finali sunt mapaţi la mai multe scheme diferite. Toți utilizatorii cu aceleaşi privilegii sunt conectaţi la aceeaşi schemă.
N: 1 Acestă schemă „toti-la-unul” este o aplicație Web tipică. Aplicația conectează toți utilizatorii finali la aceeaşi schemă a bazei de date. Schema dispune de o uniune a tuturor privilegiilor pentru toţi utilizatorii conectaţi la ea.Schema sau maparile sunt enumerate în ordine de la simplu la complex pentru a construi securitatea bazei de date. Există mai mulți factori care influențează alegerea modelului. Scalabilitatea, performanţa şi administrarea uşor de folosit ne solicită de multe ori cea mai mare atenție. Securitatea însă trebuie să fie de asemenea un aspect care trebuie avut în vedere.


Privilegiile utilizatorului pentru conturile unice în baza de date.

În funcție de cum va fi accesată baza de date şi rolul aplicaţiilor s-ar putea sau nu să avem o mulțime de conturi reale de utilizatori finali. Schema (maparea) 1:1 poate avea loc în mai multe moduri, dar ideea este că există o mapare directă a fiecărui utilizator la o identitate în baza de date (acesta este, contul bazei de date). În modul cel mai simplu, utilizatorul furnizează un nume de utilizator și o parolă, care sunt efectiv numele de utilizator şi parola contului bazei de date. Alternativ, aplicaţia ar putea furniza propria mapare. Atunci când creăm conturi bazei de date de tipul 1:1, este important să aplicam aceleaşi minime privilegii utilizate în conturile de gestionare pe sisteme de operare. Deci, ar trebui să creăm utilizatorii fără privilegii și apoi să le acordăm selectiv privilegiile de care au nevoie pentru a putea să execute în baza de date serviciul sau cererea de care au nevoie. Această schemă este deosebit de importantă pentru administratorii de baze de date și pentru alţi utilizatori privilegiaţi.

Partajarea unui cont privilegiat printre un grup de utilizatori este o practică proastă. În multe organizații, schimbul de conturi de utilizator este interzisă de politica de securitate, dar este totuși încă folosită şi se practica de multe ori. Dacă ceva nu merge bine în acest caz, nu vom fi în măsură să spunem care utilizator a fost conectat ca utilizator al bazei de date în momentul în care s-a întâmplat ceva. Prin urmare, nu există nicio responsabilitate a utilizatorului. Schema 1:1 face securitatea bazei de date simplă pentru că identitatea utilizatorului este întotdeauna disponibilă pentru baza de date, prin urmare, utilizatorul este responsabil.

În plus, multe dintre capacitățile de securitate ale bazei de date funcționează la nivel de schemă individuală. Dacă fiecare utilizator are o schemă unică, atunci baza de date poate aplica ușor securitatea corespunzătoare pentru utilizatorii corespunzători, bazată pe scheme.


Conturi de baze de date partajate

Privilegiile minime sunt importante, chiar dacă utilizatorii nu sunt conectați direct la baza de date. Este o practică frecventă pentru utilizatori să aibă un cont unic de aplicație și să partajeze o schemă de baze de date. Există două scheme pentru aceasta. În primul rând schema N: M, partiționeaza utilizatorii în diverse scheme. Acest lucru se face în general prin organizarea utilizatorilor după rolul lor, toţi utilizatorii cu acelaşi rol se conectează la aceeaşi schemă. Partea importantă este să ne asiguram că în principiu cele mai puține privilegii sunt încă menținute. Putem face în mod eficient acest lucru, dacă toţi utilizatorii care se atasează la schema bazei de date să aibă exact aceleaşi privilegii în baza de date. Transmiterea identitătii utilizatorului este importantă în acest model, deoarece baza de date poate fi în imposibilitatea de a distinge între utilizatorii racordați la aceeaşi schemă.

Modelul de schemă N: 1, conectează toți utilizatorii finali la aceeaşi schemă a bazei de date. Această schemă este întotdeauna cea mai îndoielnică în ceea ce priveste securitatea. Problema cu proiectarea este faptul că e dificil pentru baza de date să separe privilegiile de securitate pentru utilizatori diferiți, deoarece toți sunt conectaţi la aceeaşi schemă. Garantarea că numai privilegiile potrivite sunt disponibile pentru utilizator este lăsată în cea mai mare parte apliacatiei. Când proiectam şi construim aplicații, trebuie să ne asiguram că este mentinut principiul cu privilegii minime. Proprietarul datelor are toate privilegiile asupra datelor. În cazul în care utilizatorii se conectează la această schemă, chiar dacă prin intermediul aplicației noastre exista un risc semnificativ de penetrare a securităţii sistemului. Aceasta se poate întampla, în cazul în care un utilizator poate sparge aplicaţia, utilizatorul va avea control complet pe partea datelor. Din acest motiv, o practică mai bună de securitate este să ne asigurăm că utilizatorii aplicației nu se pot conecta direct la contul de date.

Deci ca o concluzie putem spune că nu trebuie niciodată să permitem utilizatorilor finali să se conecteze la schemele de date.

Un aspect important al procesului de identificare este păstrarea identității. Noi trebuie să ne asigurăm că identitățile de utilizator sunt disponibile peste tot unde securitatea le solicită.

Se întâmplă adesea că utilizatorul se autentifică la o aplicație, iar aplicaţia se conectează la baza de date nu ca utilizator de drept (real), ci ca anonim sau pseudo-anonim. La proiectarea aplicațiilor de baze de date, mai multe informații cu privire la identitatea utilizatorului ne pot oferi nivelurile mai subtile de securitate care se pot aplica. Deşi multe aplicații (sau baze de date) sunt concepute în jurul valorii de control al accesului la nivel de utilizator şi de audit, acest lucru nu este tot ce ar fi necesar. Aproape toate aplicațiile sunt bazate pe identificarea utilizatorilor în sine sau ca membri ai unui grup. İdentificarea şi autentificarea formează temelia proceselor de securitate. Acestea trebuie să fie puse în aplicare în primul rând şi trebuie să fie facute corect. Păstrarea identității utilizatorului la baza de date permite utilizarea bazei de date în sigurantă, iar aceasta este în conformitate cu principiul securizarii în profunzime. Va trebui să luam în calcul proiectarea acestei securitaţi în aplicațiile noastre dinainte. Modelul de utilizator al bazei de date este important pentru a se prevedea ce capabilități ale bazei de date vor putea fi folosite. Cel puțin ar trebui să separăm schemele de utilizator şi schemele de date.

Administratorii nu ar trebui să partajeze conturi. Schemele de partajare ar trebui să fie făcute doar atunci când identitatea utilizatorilor finali poate fi păstrată şi privilegiile bazei de date sunt identice pentru toți utilizatorii conectați la aceeaşi schemă. Înțelegerea identificării şi autentificării este importantă pentru modul în care formulăm politicile noastre de securitate. Trebuie să evaluam cu atenție cerințele de securitate, valoarea şi importanţa datelor utilizate, administrarea lor, precum şi costurile asociate cu diferite tehnologii de autentificare.


Studiul de caz

Exemplele din lucrarea de fată se referă la proiectarea unui model de date ce oferă informaţii referitoare la evidenţa unui magazin ce are ca activitate închirierea de filme către clienţi. Construirea schemei conceptuale, a schemelor relaţionale, precum şi normalizarea va creea un model de date relaţional prin intermediul căruia se va elimina anumite clase de anomalii ce apar în proiectarea modelului de date din această lucrare.

Crearea bazei de date
Pentru a crea baza de date denumită “FILM” voi utiliza aplicaţia cu interfaţă grafică Oracle Database XE 11.2. Fereasta de login este aratată în figura 9 de mai jos.

Figura 9. Fereastră login aplicaţie Oracle Database XE 11.2

După ce procesul de logare în aplicaţie a avut loc, vom fi directionaţi spre o fereastră prin intermediul căreia putem crea baza noastră de date “FILM”. În această fereastră aplicaţia ne solicită să alegem crearea unei noi baze de date sau utilizarea unei baze deja existente, numele bazei de date, în cazul nostru alegem “FILM”, numele de utilizator şi parola, apoi facem clic pe Create Workspace. Fereastra prin intermediul careia creăm baza de date “FILM” este aratată în fig.10.

Figura 10. Fereastră creare bază de date „FILM”

După ce baza de date a fost creată avem acces la interfata grafica a aplicaţiei prin intermediul careia putem crea, insera, actualiza şi sterge tabelele şi informaţiile conţinute în baza noastra “FILM”. İnterfaţa grafică a aplicaţiei este aratată în figura 11.

Figura 11. Interfaţa grafică aplicaţie Oracle Application Express

Tabelele bazei de date

În baza de date am creat urmatoarele tabele:

FILM_STOC
GEN_FILM
LIMBA_FILM
SUBTITRARE
FILM_LIPSA_STOC
COPII_FILM
FILME_INCHIRIATE
CLIENTI_INCHIRIERE_FILMStructura detaliată a tabelelor este următoarea:

FILM_STOC – tabelul conţine id-ul filmelor care sunt pe stoc, adica un cod unic ce identifică fiecare film, acest cod unic este “id_film “care împreuna cu câmpul “cod_gen_film” reprezintă şi cheia primară a tabelului. Comanda de creare a tabelului este urmatoarea:

CREATE TABLE “FILM_STOC”
(“ID_FILM” NUMBER NOT NULL ENABLE,
“COD_GEN_FILM” VARCHAR2(10) NOT NULL ENABLE,
“NUME_FILM” VARCHAR2(50),
“PRET_VHS” NUMBER(2,0),
“PRET_DVD” NUMBER(2,0),
“AN_APARITIE” NUMBER(4,0),
CONSTRAINT “FILM_STOC_PK” PRIMARY KEY (“ID_FILM”, “COD_GEN_FILM”) ENABLE
) ;

GEN_FILM – tabelul conţine un cod care identifica genul de filme pe care le deţinem pe stoc. Cheia primară este “cod_gen_film “.Comanda de creare a tabelului este următoarea:

CREATE TABLE “GEN_FILM”
(“COD_GEN_FILM” VARCHAR2(6) NOT NULL ENABLE,
“DESCRIERE_FILM” VARCHAR2(10),
CONSTRAINT “GEN_FILM_PK” PRIMARY KEY (“COD_GEN_FILM”) ENABLE
) ;

LIMBA_FILM – tabelul conţine informaţii despre limba originală a filmelor existente pe stoc. Cheia primară a tabelului este o cheie compusă din câmpurile “id_film” şi “cod_limba”. Comanda de creare a tabelului este urmatoarea:

CREATE TABLE “LIMBA_FILM”
(“ID_FILM” NUMBER NOT NULL ENABLE,
“COD_LIMBA” VARCHAR2(6) NOT NULL ENABLE,
CONSTRAINT “LIMBA_FILM_PK” PRIMARY KEY (“ID_FILM”, “COD_LIMBA”) ENABLE
) ;

SUBTITRARE – tabelul conţine informaţii despre limba de subtitrare a filmelor din stoc. Chei primară a acestui tabel este o cheie compusă din campurile “ cod_limba” şi “nume_limba”. Comanda de creare a tabelului este următoarea:

CREATE TABLE “SUBTITRARE”
(“COD_LIMBA” VARCHAR2(3) NOT NULL ENABLE,
“NUME_LIMBA” VARCHAR2(10) NOT NULL ENABLE,
CONSTRAINT “SUBTITRARE_PK” PRIMARY KEY (“COD_LIMBA”, “NUME_LIMBA”) ENABLE );FILM_LIPSA_STOC – tabel ce conţine informaţii despre filmele care nu sunt disponibile, are un cod unic carte identifică filmele nedisponibile, cod care este şi cheie primară a tabelului. Comanda de creare a tabelului este următoarea:

CREATE TABLE “FILM_LIPSA_STOC”
(“ID_LIPSA_FILM” NUMBER NOT NULL ENABLE,
“FILM_DENUMIRE” VARCHAR2(50),
“FORMAT_SUPORT” VARCHAR2(3),
CONSTRAINT “FILM_LIPSA_STOC_PK” PRIMARY KEY (“ID_LIPSA_FILM”) ENABLE
) ;COPII_FILM – tabel ce conţine informaţii despre filmele care au copii, cât şi numărul acestor copii. Cheia primară este una compusă din câmpurile “id_film” şi “ nr_copii”. Comanda de creare a tabelului este următoarea:

CREATE TABLE “COPII_FILM”
(“ID_FILM” NUMBER NOT NULL ENABLE,
“NR_COPII” NUMBER NOT NULL ENABLE,
“DENUMIRE_FILM” VARCHAR2(50),
“FORMAT_MEDIA” VARCHAR2(3),
CONSTRAINT “COPII_FILM_PK” PRIMARY KEY (“ID_FILM”, “NR_COPII”) ENABLE
) ;FILME_INCHIRIATE – tabel ce conţine informaţii despre filmele închiriate clienţilor. Cheia primară este o cheie compusă din campurile “ id_film” şi “id_film_copie”. Comanda de creare a tabelului este următoarea:

CREATE TABLE “FILME_INCHIRIATE”
(“ID_FILM” NUMBER,
“ID_FILM_COPIE” NUMBER,
“DATA_INCHIRIERE” DATE,
“TITLU_FILM” VARCHAR2(50),
“PRET_INCHIRIERE” NUMBER,
“PENALIZARE_INTARZIERE_PIERDERE” NUMBER,
“DATA_RETURNARE” DATE,
CONSTRAINT “FILME_INCHIRIATE_PK” PRIMARY KEY (“ID_FILM”, “ID_FILM_COPIE”) ENABLE
) ;CLIENTI_INCHIRIERE_FILM – tabel ce conţine un cod ce identifică unic fiecare client care a închiriat filme , cât şi datele personale ale acestora. Codul unic care identifică clienţii este şi cheia primară a tabelului. Comanda de creare a tabelului este următoarea:

CREATE TABLE “CLIENTI_INCHIRIERE_FILM”
(“CLIENT_ID” NUMBER,
“NUME” VARCHAR2(20),
“PRENUME” VARCHAR2(20),
“ADRESA” VARCHAR2(50),
“ORAS” VARCHAR2(16),
“CNP” VARCHAR2(13),
“TEL” VARCHAR2(10),
CONSTRAINT “CLIENTI_INCHIRIERE__FILM_PK” PRIMARY KEY (“CLIENT_ID”) ENABLE );

Inserare date în baza de date

Pentru a insera datele corespunzatoare în baza noastră de date referitor la filmele pe care le deţinem vom utiliza limbajul SQL, şi anume instrucţiunea INSERT. Codul SQL este următorul:

INSERT INTO “FILM”.”FILM_STOC” (ID_FILM, COD_GEN_FILM, NUME_FILM, PRET_VHS, PRET_DVD, AN_APARITIE) VALUES (’01’, ‘act’, ‘The Matrix’, ’30’, ’18’, ‘2001’)
INSERT INTO “FILM”.”FILM_STOC” (ID_FILM, COD_GEN_FILM, NUME_FILM, PRET_VHS, PRET_DVD, AN_APARITIE) VALUES (‘4’, ‘com’, ‘You Have Got Mail’, ’35’, ’15’, ‘2007’)
INSERT INTO “FILM”.”FILM_STOC” (ID_FILM, COD_GEN_FILM, NUME_FILM, PRET_VHS, PRET_DVD, AN_APARITIE) VALUES (‘5’, ‘dra’, ‘Red Corner’, ’34’, ’15’, ‘2004’)
INSERT INTO “FILM”.”FILM_STOC” (ID_FILM, COD_GEN_FILM, NUME_FILM, PRET_VHS, PRET_DVD, AN_APARITIE) VALUES (‘6’, ‘SF’, ‘Blade Runner – Director is Cut’, ’36’, ’19’, ‘2008’)
INSERT INTO “FILM”.”FILM_STOC” (ID_FILM, COD_GEN_FILM, NUME_FILM, PRET_VHS, PRET_DVD, AN_APARITIE) VALUES (‘8’, ‘cart’, ‘A Bug is Life’, ’32’, ’14’, ‘2008’)
INSERT INTO “FILM”.”FILM_STOC” (ID_FILM, COD_GEN_FILM, NUME_FILM, PRET_VHS, PRET_DVD, AN_APARITIE) VALUES (‘9’, ‘com’, ‘There is Something About Mary’, ’34’, ’17’, ‘2003’)
INSERT INTO “FILM”.”FILM_STOC” (ID_FILM, COD_GEN_FILM, NUME_FILM, PRET_VHS, PRET_DVD, AN_APARITIE) VALUES (’10’, ‘dra’, ‘Beloved’, ’30’, ’13’, ‘2002’)
INSERT INTO “FILM”.”FILM_STOC” (ID_FILM, COD_GEN_FILM, NUME_FILM, PRET_VHS, PRET_DVD, AN_APARITIE) VALUES (‘2’, ‘act’, ‘Under Siege’, ’28’, ’17’, ‘2000’)
INSERT INTO “FILM”.”FILM_STOC” (ID_FILM, COD_GEN_FILM, NUME_FILM, PRET_VHS, PRET_DVD, AN_APARITIE) VALUES (‘3’, ‘act’, ‘Lethal Weapon’, ’28’, ’19’, ‘2006’)
INSERT INTO “FILM”.”FILM_STOC” (ID_FILM, COD_GEN_FILM, NUME_FILM, PRET_VHS, PRET_DVD, AN_APARITIE) VALUES (‘7’, ‘thril’, ‘Frantic’, ’37’, ’20’, ‘2010’)Tabelul „FILM_STOC” din baza noastră de date „FILM” va avea structura în urma inserării datelor ca în figura 1.

Figura 1. Conţinut tabel Film Stoc

Pentru a introduce date în tabelul „GEN_FILM” utilizăm următorul cod SQL:

INSERT INTO “FILM”.”GEN_FILM” (COD_GEN_FILM, DESCRIERE_FILM) VALUES (‘act’, ‘actiune’)
INSERT INTO “FILM”.”GEN_FILM” (COD_GEN_FILM, DESCRIERE_FILM) VALUES (‘com’, ‘comedie’)
INSERT INTO “FILM”.”GEN_FILM” (COD_GEN_FILM, DESCRIERE_FILM) VALUES (‘dra’, ‘drama’)
INSERT INTO “FILM”.”GEN_FILM” (COD_GEN_FILM, DESCRIERE_FILM) VALUES (‘SF’, ‘stiintific’)
INSERT INTO “FILM”.”GEN_FILM” (COD_GEN_FILM, DESCRIERE_FILM) VALUES (‘cart’, ‘desene an.’)
INSERT INTO “FILM”.”GEN_FILM” (COD_GEN_FILM, DESCRIERE_FILM) VALUES (‘thril’, ‘triller’)Tabelul „GEN_FILM” va avea structura în urma inserării datelor ca în figura 2.

Figura 2. Conţinut tabel Gen Film


Pentru a introduce date în tabelui „LIMBA_FILM” utilizăm următorul cod SQL:

INSERT INTO “FILM”.”LIMBA_FILM” (ID_FILM, COD_LIMBA) VALUES (‘1’, ‘en’)
INSERT INTO “FILM”.”LIMBA_FILM” (ID_FILM, COD_LIMBA) VALUES (‘4’, ‘en’)
INSERT INTO “FILM”.”LIMBA_FILM” (ID_FILM, COD_LIMBA) VALUES (‘5’, ‘en’)
INSERT INTO “FILM”.”LIMBA_FILM” (ID_FILM, COD_LIMBA) VALUES (‘6’, ‘en’)
INSERT INTO “FILM”.”LIMBA_FILM” (ID_FILM, COD_LIMBA) VALUES (‘8’, ‘en’)
INSERT INTO “FILM”.”LIMBA_FILM” (ID_FILM, COD_LIMBA) VALUES (‘9’, ‘en’)
INSERT INTO “FILM”.”LIMBA_FILM” (ID_FILM, COD_LIMBA) VALUES (’10’, ‘en’)
INSERT INTO “FILM”.”LIMBA_FILM” (ID_FILM, COD_LIMBA) VALUES (‘2’, ‘en’)
INSERT INTO “FILM”.”LIMBA_FILM” (ID_FILM, COD_LIMBA) VALUES (‘3’, ‘en’)
INSERT INTO “FILM”.”LIMBA_FILM” (ID_FILM, COD_LIMBA) VALUES (‘7’, ‘en’)Tabelul “LIMBA_FILM” va avea structura în urma inserării datelor ca în figura 3.

Figura 3. Conţinut tabel Limba Film

Tabelui „SUBTITRARE” arată corespondenţa dintre limba originală a filmului şi limba în care este subtitrat. Pentru a introduce în tabel datele care arată această corespondenţă utilizăm următorul cod SQL:

INSERT INTO “FILM”.”SUBTITRARE” (COD_LIMBA, NUME_LIMBA) VALUES (‘en’, ‘romana’)Tabelul “SUBTITRARE” va avea structura în urma inserării datelor ca în figura 4.

Figura 4. Conţinut tabel Subtitrare

Pentru a introduce date în tabelul „FILM_LIPSA_STOC” utilizăm următorul cod SQL:

INSERT INTO “FILM”.”FILM_LIPSA_STOC” (ID_LIPSA_FILM, FILM_DENUMIRE, FORMAT_SUPORT) VALUES (’23’, ‘Courage Under Fire’, ‘DVD’)
INSERT INTO “FILM”.”FILM_LIPSA_STOC” (ID_LIPSA_FILM, FILM_DENUMIRE, FORMAT_SUPORT) VALUES (’41’, ‘Die Hard a Vengeance’, ‘VHS’)
INSERT INTO “FILM”.”FILM_LIPSA_STOC” (ID_LIPSA_FILM, FILM_DENUMIRE, FORMAT_SUPORT) VALUES (’63’, ‘The Replacement Killers’, ‘DVD’)Tabelul “FILM_LIPSA_STOC” va avea structura în urma inserării datelor ca în figura 5.

Figura 5. Conţinut tabel Film Lipsa Stoc

Pentru a introduce date în tabelui „COPII_FILM” utilizăm urmatorul cod SQL:

INSERT INTO “FILM”.”COPII_FILM” (ID_FILM, NR_COPII, DENUMIRE_FILM, FORMAT_MEDIA) VALUES (‘3’, ‘4’, ‘Lethal Weapon’, ‘DVD’)
INSERT INTO “FILM”.”COPII_FILM” (ID_FILM, NR_COPII, DENUMIRE_FILM, FORMAT_MEDIA) VALUES (‘1’, ‘6’, ‘The Matrix’, ‘DVD’)
INSERT INTO “FILM”.”COPII_FILM” (ID_FILM, NR_COPII, DENUMIRE_FILM, FORMAT_MEDIA) VALUES (‘7’, ‘3’, ‘Frantic’, ‘DVD’)Tabelul “COPII_FILM” va avea structura în urma inserării datelor ca în figura 6 şi va conţine filmele care deţin copii.

Figura 6. Conţinut tabel Copii Film

Pentru a introduce datele corespunzătoare filmelor pe care le-am închiriat în tabelul „FILME_INCHIRIATE”, utilizăm următorul cod SQL:

INSERT INTO “FILM”.”FILME_INCHIRIATE” (ID_FILM, ID_FILM_COPIE, DATA_INCHIRIERE, TITLU_FILM, PRET_INCHIRIERE) VALUES (‘3’, ‘2’, TO_DATE(’04-APR-06′, ‘DD-MON-RR’), ‘Lethal Weapon’, ’19’)
INSERT INTO “FILM”.”FILME_INCHIRIATE” (ID_FILM, ID_FILM_COPIE, DATA_INCHIRIERE, TITLU_FILM, PRET_INCHIRIERE) VALUES (‘1’, ‘3’, TO_DATE(’21-JUN-01′, ‘DD-MON-RR’), ‘The Matrix’, ’18’)
INSERT INTO “FILM”.”FILME_INCHIRIATE” (ID_FILM, ID_FILM_COPIE, DATA_INCHIRIERE, TITLU_FILM, PRET_INCHIRIERE) VALUES (‘7’, ‘3’, TO_DATE(’11-AUG-10′, ‘DD-MON-RR’), ‘Frantic’, ’20’)Tabelul “FILME_INCHIRIATE” va avea structura în urma inserării datelor ca în figura 7.

Figura 7. Conţinut tabel Filme Inchiriate

Pentru a introduce datele clienţilor care au închiriat filme de la magazinul nostru, în tabelul „CLIENTI_INCHIRIERE_FILM”, utilizăm următorul cod SQL:

INSERT INTO “FILM”.”CLIENTI_INCHIRIERE_FILM” (CLIENT_ID, NUME, PRENUME, ADRESA, ORAS, CNP, TEL) VALUES (‘2632’, ‘Popescu’, ‘Valentin’, ‘Republicii 22’, ‘Bucuresti’, ‘1426784951209’, ‘0214716683’)
INSERT INTO “FILM”.”CLIENTI_INCHIRIERE_FILM” (CLIENT_ID, NUME, PRENUME, ADRESA, ORAS, CNP, TEL) VALUES (‘1874’, ‘Ana’, ‘Maria’, ‘Take Ionescu 12’, ‘Timisoara’, ‘2705448793256’, ‘0256447391’)
INSERT INTO “FILM”.”CLIENTI_INCHIRIERE_FILM” (CLIENT_ID, NUME, PRENUME, ADRESA, ORAS, CNP, TEL) VALUES (‘4133’, ‘Alexandru’, ‘Nicolae’, ‘Soroca 36’, ‘Brasov’, ‘1203698754128’, ‘0729477596’)Tabelul “CLIENTI _INCHIRIERE_FILM” va avea structura în urma inserării datelor ca în figura 8 şi va conţine datele personale ale clienţilor care au inchiriat filme.

Figura 8. Conţinut tabel Clienti Inchiriere Film


Diagrama entitate – relaţie
Diagrama E/R pentru modelul de date prezentat se poate vedea în figura 12.

Fig.12. Diagrama E/R a studiului de caz

Pentru modelul de date pe care îl descriu entităţile sunt următoarele:

FILM_STOC, GEN_FILM, LIMBA_FILM, SUBTITRARE, FILM_LIPSA_STOC, COPII_FILM, FILME_INCHIRIATE, CLIENTI_INCHIRIERE_FILMAm să prezint în continuare entitaţile modelului de date al studiului de caz şi voi face o descriere a fiecareia. Voi preciza cheia primară pentru fiecare entitate.

FILM_STOC = conţine informaţii despre numele filmelor pe care le deţine în stoc societatea care are ca activitate închirierea de filme către clienţi. De asemenea tot aici găsim şi preţul de închiriere pentru aceste filme atât pe supart VHS cât şi pe DVD, anul apariţiei filmului şi un cod asociat filmului respectiv. Cheia primară a entitaţii este “id_film”.

GEN_FILM = oferă informaţii despre genul filmelor deţinute pe stoc. Cheia primară a entitaţii este “cod_gen_film”.

LIMBA_FILM = furnizează informaţii despre limba originală a filmelor existente pe stoc. Cheia primară a entitaţii este o cheia compusă din “id_film” şi “cod_limba”.

SUBTITRARE = ne spune limba în care sunt titrate filmele care au un anumit cod pentru limbă în entitatea LIMBA_FILM. Adica ce subtitrare îi corespunde unui anumit film care are un cod pentru limbă în entitatea LIMBA_FILM. Cheia primară a entitaţii este o cheie compusă din “ cod_limba” şi “nume_limba”

FILM_LIPSA_STOC = ne oferă informaţii despre filmele care nu sunt disponibile în stoc şi formatul acestora VHS sau DVD. Cheia primară a entitaţii este “id_lipsa_film”.

COPII_FILM = oferă informaţii despre nr. de copii existente ale filmelor din stoc, denumirea acestor filme căt şi suportul pe care se găsesc aceste filme VHS sau DVD. Cheia primară a entitaţii este o cheia compusă din “ id_film” şi “ nr_copii”.

FILME_INCHIRIATE = furnizează informaţii despre filmele închiriate clienţilor, titlul filmelor închiriate , pretul de închiriere, data închirierii, data cand filmele trebuie returnate cât şi penalizarea pentru întarzierea returnării sau pierderii produsului. Cheia primară a entitaţii este o cheie compusă din “id_film” şi “id_film_copie”.

CLIENTI_INCHIRIERE_FILM = ne oferă informaţii despre datele personale ale clienţilor care au inchiriat filme, cât şi numarul de telefon al acestora. Cheia primară a entitaţii este “client_id”.

Am să prezint relaţiile modelului de date al studiului de caz şi voi face o descriere a acestora. De asemenea pentru fiecare relaţie voi prezenta cardinalitatea minimă şi maximă.

FILM_STOC are GEN_FILM = relaţia dintre FILM_STOC şi GEN_FILM reflectă legătura dintre acestea ( un film existent pe stoc are un anumit gen, de ex. actiune, comedie, etc). Ea are cardinalitatea minima 1:1 (un film existent în stoc are un anumit gen şi un anumit gen de film poate să existe în filmele de pe stoc) şi cardinalitatea maximă 1:n ( un film existent în stoc are un anumit gen, dar mai multe genuri de filme pot exista pe stoc).

FILM_STOC închiriază FILME_INCHIRIATE = relaţia de tip many-to-many dintre entitatea FILM_STOC şi FILME_INCHIRIATE reflectă legatura dintre acestea ( unul sau mai multe filme de pe stoc sunt oferite spre a fi inchiriate ). Această relaţie are cardinalitatea 1:1 ( un anumit film existent în stoc este oferit spre a fi inchiriat şi de asemenea un film inchiriat este unul din filmele existente pe stoc) şi cardinalitatea maximă m:n ( mai multe filme existente pe stoc sunt oferite spre inchiriere şi mai multe filme închiriate sunt dintre filmele existente pe stoc).

FILM_STOC are COPII_FILM = relaţie de tip many-to-many dintre entitaţile FILM_STOC şi COPII_FILM arată legatura dintre acestea (mai multe filme existente pe stoc au mai multe copii ). Această relatie are cardinalitatea maximă m:n şi cardinalitatea minima 1:1.

FILM_STOC are LIMBA_FILM = relaţia dintre entitaţile FILM_STOC şi LIMBA_FILM reflectă legatura dintre aceste entitaţi ( unul sau mai multe filme de pe stoc au o limbă originală în care au fost regizate ). Aceasta relaţie are cardinalitatea minimă 1:1 ( un film de pe stoc are o limbă în care a fost regizat ) şi cardinalitatea maximă 1:n ( mai multe filme din stoc au o singură limbă în care au fost regizate ).

LIMBA_FILM are SUBTITRARE = relaţia dintre entităţile LIMBA_FILM şi SUBTITRARE ( limba originală în care a fost regizat un anumit film are o anumită subtitrare ). Relaţia are cardinalitatea minimă 1:1 (un film are o subtitrare şi o subtitrare corespunde unui film) şi cadinalitatea maximă 1:n (o subtitrare poate exista la mai multe filme).

CLIENTI_INCHIRIERE_FILM închiriază FILME_INCHIRIATE = relaţie de tip many-to-many dintre entitaţile CLIENTI_INCHIRIERE_FILM şi FILME_INCHIRIATE reflectă legătura dintre acestea ( filmele care sunt închiriate clientilor ). Această relaţie are cardinalitatea maximă m:n (mai multe filme sunt închiriate la mai mulţi clienţi şi mai multi clienti au inchiriat mai multe filme) şi cardinalitatea minimă 1:1 (un film este închiriat la un client şi un client a închiriat un singur film).

COPII_FILM închiriază FILME_INCHIRIATE = relaţie de tip many-to-many dintre entitaţiile COPII_FILM şi FILME_INCHIRIATE reflectă legătura dintre aceste entitaţi (copii a filmelor sunt închiriate). Această relaţie are cardinalitatea maximă m:n (mai multe copii ale filmelor sunt închiriate şi mai multe filme închiriate sunt dintre filmele care au copii).

FILM_LIPSA_STOC are GEN_FILM = relaţia dintre entitaţile FILM_LIPSA_STOC şi GEN_FILM reflectă legătura dintre acestea ( filmele care nu sunt disponibile pe stoc au anumite genuri ). Aceasta relaţie are cardinalitatea 1:1 ( un film inexistent pe stoc are un gen şi un anumit gen de film nu există printre filmele care nu sunt momentan disponibile pe stoc ), şi cardinalitatea maximă n:m.

În continuare am să descriu trei entitaţi împreună cu atributele acestora, tipurile de date, lungimea lor maximă şi o descriere a acestora pentru exemplificare.

Entitatea FILM_STOC are ca atribute:

id_film = variabilă de tip number, de lungime maximă 2, care reprezintă id-ul unui film existent pe stoc

code_gen_film = variabilă de tip varchar 2, de lungime maximă 8 biti, care reprezintă codul genului de film existent pe stoc

nume_film = variabilă de tip varchar 2, de lungime maximă 50 biti, care reprezintă numele filmului

pret_VHS = variabilă de tip float, de lungime maximă 2, care reprezintă preţul de închiriere a unui film pe suport VHS

pret_DVD = variabilă de tip float, de lungime maximă 2, care reprezintă preţul de închiriere a unui film pe suport DVD

an _aparitie = variabilă de tip number, de lungime maximă 4, care reprezintă anul de aparitie al filmului

Entitatea FILME_INCHIRIATE are ca atribute:

Id_film = variabilă de tip number, de lungime maximă 2, care reprezintă id-ul filmului închiriat

Id_film_copie = variabilă de tip number, de lungime maximă 2, care reprezintă id-ul filmului copie şi împreuna cu id_film formerază cheia primară a entitaţii FILME_INCHIRIATE

Data_inchiriere = variabilă de tip date, care reprezintă data la care a fost închiriat un anumit film

Titlu_film = variabilă de tip varchar 2 , de lungime 50 biti, care reprezintă titlul filmului închiriat

Pret_inchiriere = variabilă de tip float, de lungime maximă 2, care reprezintă preţul închirierii filmului

Penalizare_intarziere_pierdere = variabilă de tip number, de lungime maximă 4, care reprezintă preţul penalizării restituirii filmului sau al pierderii acestuia

Data_returnare = variabilă de tip date, care reprezintă data la care a fost returnat filmul închiriat

Entitatea CLIENTI_INCHIRIERE_FILM are ca atribute:

Client_id = variabilă de tip number, de lungime maximă 2, care reprezintă id-ul clientului care a închiriat un anumit film

Nume = variabilă de tip varchar 2, de lungime maximă 16 biti, care reprezintă numele clientului care a închiriat filme

Prenume = variabilă de tip varchar 2, de lungime maximă 16 biti, care reprezintă prenumele clientului care a închiriat filme

Adresa = variabilă de tip varchar 2 , de lungime 32 biti, care reprezintă adresa clientului care a închiriat filme

Oras = variabilă de tip varchar 2, de lungime maximă 16 biti, care reprezintă oraşul din care este clientul care a închiriat filme

Cnp = variabilă de tip varchar 2, de lungime maximă 13 biti, care reprezintă codul numeric personal al clientului

Tel = variabilă de tip varchar 2, de lungime maximă 16 biti, care reprezintă numarul de telefon al clientului

Voi descrie în continuare ca exemplu atributele relaţiei “FILM_STOC are GEN_FILM”, tipul de date, lungimea în biti a fiecarui atribut al relaţiei şi ce reprezintă fiecare.

Relaţia FILM_STOC are GEN_FILM are ca atribute :

cod_gen_film = variabilă de tip varchar 2, de lungime maximă 8 biti, care reprezintă codul genului de film. Atributul trebuie să corespundă la o valoare a cheii primare din tabelul (entitatea) GEN_FILM.

id_film = variabilă de tip number, de lungime maximă 2, care reprezintă id-ul unui film existent pe stoc. Atributul trebuie să corespundă la o valoare a cheii primare din tabelul (entitatea) FILM_STOC.

descriere_film = variabilă de tip varchar 2, de lungime maximă 50 biti, care oferă o scurtă descriere despre un anumit film. Atributul trebuie să corespundă la o valoare corespunzătoare a tipului de date din tabelul (entitatea) GEN_FILM.

nume_film = variabilă de tip varchar 2, de lungime maximă 50 biti, care reprezintă numele filmului. Atributul trebuie să corespundă la o valoare corespunzatoare a tipului de date din tabelul (entitatea) FILM_STOC.

pret_VHS = variabilă de tip float, de lungime maximă 2, care reprezintă pretul de închiriere a unui film pe suport VHS. Atributul trebuie să corespundă la o valoare corespunzătoare a tipului de date din tabelul (entitatea) FILM_STOC.

pret_DVD = variabilă de tip float, de lungime maximă 2, care reprezintă preţul de închiriere a unui film pe suport DVD. Atributul trebuie să corespundă la o valoare corespunzătoare a tipului de date din tabelul (entitatea) FILM_STOC.

an _aparitie = variabilă de tip number, de lungime maximă 4, care reprezintă anul de apariţie al filmului. Atributul trebuie să corespundă la o valoare corespunzatoare a tipului de date din tabelul (entitatea) FILM_STOC.


Diagrama conceptuală – cheia primară, cheia străină
Primul pas în proiectarea unei baze de date relaţionale este acela de a analiza situaţia reală pe care trebuie să o reprezentăm sau să o modelăm prin intermediul bazei noastre de date.

Acest lucru implica:

Cerinţele utilizatorilor în ce priveşte datele pe care trebuie să le stocăm şi administrăm
Cerinţele utilizatorilor în ce priveşte operaţiile care trebuie să fie efectuate cu aceste dateÎn cazul modelului relaţional din lucrarea mea, pentru a obţine schema conceptuală voi pleca de la o descriere mai detaliată a entitaţilor şi atributelor, a relaţiilor dintre aceste entitaţi şi condiţiile pe care acestea trebuie să le îndeplinească, deci voi pleca de la diagrama E/R a studiului de caz. Scopul este de a reprezenta entităţiile şi legăturile dintre entităţi prin intermediul unor relaţii sau tabele.

În diagrama conceptuală voi reprezenta prin simbolul “x” locul unde este plasată cheia externă, iar prin simbolul “x” voi arăta că respectiva cheie externă este conţinută în cheia primară.

Schema conceptuală a bazei de date corespunde unei descrieri de forma:

nume_entitate = {listă de atribute}

Cheile primare sunt atributele subliniate. Entitaţile şi atributele sunt apelate prin substantive, iar relaţiile dintre entitaţi sunt denumite prin verbe. În unele cazuri ordinea entitaţilor din relaţie este importanta şi atunci avem doua relaţii care se citesc de la stanga la dreapta şi invers de la dreapta la stanga, dar şi situaţii în care ordine nu conteaza. Numele date entitaţilor şi relaţiilor trebuie să fie unice, iar numele atributelor trebuie să fie unice numai la nivelul aceleiaşi entitaţi. Este de preferat pentru simplitatea referinţelor, ca numele atributelor care sunt chei primare să fie unice la nivelul bazei de date.

Entitaţile independente CLIENTI_INCHIRIERE_FILM, FILM_LIPSA_STOC devin tabele independente. Cheile primare ale celor doua entitaţi independente sunt:

CLIENTI_INCHIRIERE_FILM = {CLIENT_ID, NUME, PRENUME, ADRESA, ORAS, CNP, TEL};

FILM_LIPSA_STOC = {ID_LIPSA_FILM, FILM_DENUMIRE, FORMAT_SUPORT};

Entitaţiile dependente devin tabele dependente. Cheile primare ale celor trei entitaţi dependente sunt urmatoarele:

COPI_FILM = { ID_FILM, NR_COPII, DENUMIRE_FILM, FORMAT_MEDIA };

FILME_INCHIRIATE = {ID_FILM, ID_FILM_COPIE, DATA_INCHIRIERE, TITLU_FILM, PRET_INCHIRIERE, PENALIZARE_INTARZIERE_PIERDERE, DATA_RETURNARE };

GEN_FILM = {COD_GEN_FILM, DESCRIERE_FILM };

Subentitatea SUBTITRARE devine subtabel , avand cheia primară compusă din atributele COD_LIMBA şi NUME_LIMBARelaţiile de tip one-to-one şi one-to-many devin chei externe.

Relaţia LIMBA_FILM are SUBTITRARE devine cheie externă în tabelul LIMBA_FILM, iar cheia externă “cod_limba” din tabelul LIMBA_FILM este conţinută în cheia primară a tabelului LIMBA_FILM.

Relaţia FILM_STOC închiriaza FILME_INCHIRIATE devine cheie externă în tabelul FILME _INCHIRIATE

Relaţiile de tip many-to-many devin tabele asociative, având două chei externe “id_film” şi “cod_gen_film” pentru cele patru tabele asociate.

Relaţia CLIENTI_INCHIRIERE_FILM închiriază FILME _INCHIRIATE devine tabel asociativ (INCHIRIAZA).

Relaţia FILME_INCHIRIATE închiriază COPII_FILM devine tabel asociativ (INCHIRIAZA).

Relaţia FILM_LIPSA_STOC are GEN_FILM devine tabel asociativ (ARE).

Relaţia FILM_STOC are GEN_FILM devine tabel asociativ (ARE).

Relaţiile de tipul trei (cele care leagă cel putin trei entitaţi) devin tabele asociative, având chei externe pentru fiecare dintre tabelele asociate.

Relaţia ‘are” care leagă entităţile FILM_STOC, GEN_FILM, LIMBA_FILM, COPII_FILM devine tabel asociativ (ARE). Tabelul asociativ are chei externe atributele: ID_FILM şi COD_GEN_FILM , acestea sunt conţinute în cheile primare.

Schemele relaţionale corespunzătoare diagramei conceptuale sunt următoarele:

FILM_STOC(ID_FILM#, COD_GEN_FILM#, NUME_FILM, PRET_VHS, PRET_DVD, AN_APARITIE )
GEN_FILM(COD_GEN_FILM#, DESCRIERE_FILM )
LIMBA_FILM(ID_FILM#, COD_LIMBA# )
SUBTITRARE ( COD_LIMBA#, NUME_LIMBA# )
COPII_FILM ( ID_FILM#, NR_COPII#, DENUMIRE_FILM, FORMAT_MEDIA )
FILM_LIPSA_STOC ( ID_LIPSA_FILM#, FILM_DENUMIRE, FORMAT_MEDIA )
FILME_INCHIRIATE ( ID_FILM#, ID_FILM_COPIE#, DATA_INCHIRIERE, TITLU_FILM, PRET_INCHIRIERE, PENALIZARE_INTARZIERE_PIERDERE, DATA_RETURNARE )
CLIENTI_INCHIRIERE_FILM ( CLIENT_ID#, NUME, PRENUME, ADRESA, ORAS, CNP, TEL )Diagrama conceptuală a schemelor relaţionale mai sus menţionate se poate vedea în figura 13.

Fig.13. Diagrama conceptuală a studiului de caz

Interogări – exemple de interogări

Pentru a selecta toate filmele pe care le deţinem în baza de date folosim instrucţiunea SELECT în felul urmator:

SELECT * FROM FILM_STOC;Rezultatul aceste interogări se poate vedea în tabelul 14.

Fig.14. Conţinut tabel Film Stoc

Pentru a selecta doar un anumit film din baza noastră de date de ex. filmul “Under Siege” folosim instructiunea SELECT împreuna cu clauza WHERE în felul urmator:

SELECT * FROM FILM_STOC
WHERE NUME_FILM = ‘Under Siege’;Rezultatul acestei interogari va fi cel din figura 15.

Fig.15. Rezultat interogare folosind clauza WHERE

Pentru a vedea căte copii ale filmului “Lethal Weapon” avem utilizăm urmatoarea interogare:

SELECT * FROM COPII_FILM
WHERE DENUMIRE_FILM =’Lethal Weapon’
AND ID_FILM = ‘3’;Rezultatul acestei interogari va fi cel din fig. 16.

Fig.16. Rezultat interogare după nr. copii film Lethal Weapon

Pentru a interoga baza noastră de date şi a afla dacă filmul ‘Die Hard a Vengeance’ este unul din filmele care nu le detinem pe stoc la un moment dat, iar formatul suportului este VHS putem utiliza următoarea interogare:

SELECT * FROM FILM_LIPSA_STOC
WHERE FILM_DENUMIRE =’Die Hard a Vengeance’
AND FORMAT_SUPORT = ‘VHS’;Rezultatul interogarii este cel din fig. 17.

Fig.17. Rezultat interogare după film lipsa stoc şi suport VHS

Dacă dorim să interogam baza noastră de date pentru a afla informatii care sunt dispuse în două sau mai multe tabele putem utiliza instrucţiunea SELECT în combinaţie cu clauzele WHERE şi JOIN. De exemplu dacă dorim să aflăm denumirea filmelor care au copii, formatul media al acestor filme şi data la care aceste copii ale filmelor au fost închiriate clienţilor utilizăm clauzele WHERE şi JOIN în interogare în felul următor:

SELECT DENUMIRE_FILM, FORMAT_MEDIA, DATA_INCHIRIERE FROM COPII_FILM C, FILME_INCHIRIATE F WHERE C.ID_FILM = F.ID_FILM;

sau cu clauza join:SELECT DENUMIRE_FILM, FORMAT_MEDIA, DATA_INCHIRIERE FROM COPII_FILM C JOIN FILME_INCHIRIATE F ON (C.ID_FILM=F.ID_FILM);

sau în felul urmator:SELECT DENUMIRE_FILM, FORMAT_MEDIA, DATA_INCHIRIERE FROM COPII_FILM JOIN FILME_INCHIRIATE USING (ID_FILM);

Rezultatul acestor trei metode de interogări va fi cel din fig.18

Fig.18. Rezultatul interogărilor întoarce date din două tabele

Selecţia de mai jos cu clauza JOIN extrage date din tabelele FILM_STOC şi LIMBA_FILM şi ne oferă informaţii despre numele filmului, anul apariţiei şi limba în care a fost regizat filmul.

SELECT NUME_FILM, AN_APARITIE, COD_LIMBA
FROM FILM_STOC F JOIN LIMBA_FILM L ON (F.ID_FILM = L.ID_FILM);Rezultatul interogarii este arătat în figura 19.

Fig.19. Rezultatul interogării întoarce date din tabelul FILM_STOC şi LIMBA_FILM

Daca dorim să aflăm o scurtă descriere a fiecarui film din figura 19 putem utiliza următoarea interogare folosind clauza JOIN în felul urmator:

SELECT NUME_FILM, DESCRIERE_FILM
FROM FILM_STOC F JOIN GEN_FILM G ON (F.COD_GEN_FILM = G.COD_GEN_FILM);sau în felul urmator:

SELECT NUME_FILM, DESCRIERE_FILM
FROM FILM_STOC JOIN GEN_FILM USING (COD_GEN_FILM);Rezultatul celor două modalităţi de interogare va fi cel din figura 20.

Fig. 20. Rezultatul celor două interogării oferă o scurtă descriere a fiecărui film din fig 19

Daca dorim să ţinem evidenţa tuturor filmelor de acţiune care au fost închiriate într-o perioadă de timp, numele şi prenumele celor care au închiriat aceste filme, cât şi data închirierii şi preţul avem nevoie să consultăm informaţii care se află în trei tabele şi anume FILM_STOC, CLIENTI_INCHIRIERE_FILM, FILME_INCHIRIATE. Pentru a obţine aceste informaţii putem crea o vizualizare şi apoi să consultăm acea vizualizare ca să obţinem informaţiile care ne interesează.

Vizualizarea pe care am creat-o ca exemplu se numeste FILME_ACT_INCHIRIATE şi are urmatorul cod SQL:

CREATE VIEW FILME_ACT_INCHIRIATE AS
SELECT COD_GEN_FILM, NUME_FILM, NUME, PRENUME, DATA_INCHIRIERE, PRET_INCHIRIERE
FROM FILM_STOC, CLIENTI_INCHIRIERE_FILM, FILME_INCHIRIATE
WHERE COD_GEN_FILM = ‘act’ ;Acum putem consulta vizualizarea creată şi deci obţine informaţiile care ne interesează. Pentru a face acest lucru folosim urmatoarea interogare:

SELECT * FROM FILME_ACT_INCHIRIATE;Rezultatul acestei selecţii va afişa vizualizarea creată anterior, vezi fig.21

Fig.21. Vizualizare FILME_ACT_INCHIRIATE

Putem căuta în vizualizarea noastră doar informaţiile care ne interesează, de exemplu dorim să ştim ce filme a închiriat un anumit client şi anume Popescu Valentin. Pentru a obţine doar acele linii din vizualizarea noastră care corespund clientului Popescu Valentin, rafinăm căutatea noastră adăugând clauza WHERE în interogare ca în exemplul de mai jos:

SELECT * FROM FILME_ACT_INCHIRIATE
WHERE NUME = ‘Popescu’ AND PRENUME = ‘Valentin’;Acum rezultatul selecţiei din vizualizarea noastră va întoarce doar înregistrarile care corespund clientului Popescu Valentin. În figura 22 putem vedea doar înregistrarile referitoare la clientul Popescu Valentin.

Fig.22. Vizualizare FILME_ACT_INCHIRIATE care corespunde clientului Popescu Valentin




Web Analytics