|
|
|
INTRODUCERE IN BAZE DE DATE
Foarte multǎ lume discutǎ sau chiar foloseste notiunea de "Sisteme cu bazǎ de date", dar in afarǎ de pretiozitatea exprimǎrii, multi dintre acestia cred cǎ o colectie oarecare de fisiere, in orice limbaj care permite o prelucrare, ar fi suficientǎ pentru nevoile afacerii, dacǎ pregǎtirea nu este de specialitate coboarǎ si mai jos si folosesc un sistem de calcul tabelar (EXCEL) sau se reped intr-un SGBD (Sistem de Gestiune a Bazelor de Date ) care aratǎ cum se creazǎ si cum se utilizeazǎ o bazǎ de date si se lovesc pe parcurs de probleme, de obicei, insurmontabile.
Din ce cauzǎ? Ce lipseste?
Lipseste intelegerea distinctǎ a ceea ce inseamnǎ un Sistem cu baze de date si lipseste proiectarea in acord cu aceastǎ intelegere.
Exemplu de proiectare incorectǎ
Pentru intelegerea facilǎ a unor definitii teoretice care vor urma, o sǎ prezentǎm un exemplu.
Firma "Lectura inteligentǎ" vinde cǎrti prin corespondentǎ. Pentru aceasta culege planuri editoriale de la cateva edituri cu acrea re contracte si isi face reclamǎ in ziare, la radio, la televiziune sau prin corespondentǎ directǎ cu clientii mai vechi. In urma reclamei primeste comenzi pe care le satisface ulterior.
Bulǎ, bǎiatul patronului, elev strǎlucit
Cititorul isi va da seama cǎ titlul este pretentios.
Autorul isi propune sǎ descopere impreunǎ cu cititorul defectele acestei abordǎri, apǎrute pe mǎsurǎ ce afacerea lua amploare.
Intrarea in sistemul ingeniosului elev se face pe baza unui formular pe care un angajat il completeazǎ pentru fiecare volum pe care il comandǎ un client. Iatǎ acest formular:
Id client este creat combinand codul localitǎtii (patru cifre) cu primele trei litere ale numelui si cu un numǎr de ordine ( cinci cifre) .Deci Popescu Ion al 35-lea client din Brasov va avea identificatorul 220000800035. Acest cod, dupǎ cum se vede, asigurǎ unicitatea unui identificator pentru clienti.
Cum se desfǎsoarǎ activitatea?
Pe baza unui catalog clientul comandǎ una sau mai multe cǎrti. Cand cartea este disponibilǎ (se aflǎ in depozit) este trimisǎ la toti cei care au comandat-o si in cǎsuta comandǎ satisfǎcutǎ se marcheazǎ un X.
La prima vedere totul este simplu, in regulǎ, si treaba chiar a functionat o vreme. Scopul nostru este sǎ observǎm care sunt defectele unui asemenea proiect.
Defectul numǎrul 1
Baza de date contine multe date duplicate:
numele, adresa, .., unui client apar de cate ori acesta comandǎ o nouǎ carte
titlul, autorii apar de cate ori este comandatǎ aceiasi carte
Si ce dacǎ sunt date duplicate?
se ocupǎ mai mult loc pe mediul de stocare
scrierea de mai multe ori a aceluiasi lucru face ca aceastǎ scriere sǎ fie diferitǎ (exemplu cartea "Utilizarea ACCESS '95" poate sǎ aparǎ Utilizare Access '95 sau Utilizare Acces '95 ). Ultimele douǎ forme nu vor fi regǎsite in baza de date ce va face ca anumiti clienti sǎ nu fie satisfǎcuti, de aici decurgand o serie intreaga de probleme.
Solutia ar fi sǎ eliminǎm pe cat posibil duplicǎrile sau, atunci cand ne permite, acestea sǎ fie corecte (consistente). O proiectare corectǎ a unei baze de date rezolvǎ aceastǎ problemǎ.
Defectul numǎrul 2
Pentru cǎ firma fǎcea catalogul manual, cu un consum mare de muncǎ necalificatǎ, s-a pus problema editǎrii catalogului direct din baza de date. Dar din aceastǎ bazǎ de date este imposibil de realizat asa ceva pentru cǎ:
baza de date nu contine toate datele care fac posibilǎ alegerea unei cǎrti. (lipseste un scurt continut, de exemplu)
prin adǎugare am ajunge sǎ accentuǎm primul defect. Sǎ-l includem o singurǎ datǎ? Cum o sǎ stim unde l-am inclus? Cel mai grav insǎ, este faptul cǎ in catalog ar trebui sǎ aparǎ cǎrti care nu au fost comandate de nimeni si aceastǎ problemǎ nu poate fi rezolvatǎ cu acest sistem.
Defectul numǎrul 3
Problemele legate de stergerea datelor. Sǎ presupunem cǎ un client a comandat o singurǎ carte si cǎ aceastǎ carte nu mai este scoasǎ (exemplu interzisǎ de cenzurǎ) dacǎ stergem informatia despre carte o sǎ pierdem adresele tuturor clientilor care au comandat numai aceea carte si deci nu vom putea trimite catalogul la o multime de clienti posibili.
Defectul numǎrul 4
O altǎ mare problemǎ este acel identificator de client. Sunt prea multe lucruri incluse acolo. De multe ori sunt utile astfel de coduri mixte dar sǎ vedem ce se intamplǎ in cazul nostru dacǎ un client se mutǎ. Identificatorul de client se schimbǎ si vom avea comenzi pentru acelasi client pe douǎ adrese . de aici posibila duplicare a pachetelor sau trimiterea unui pachet la o adresǎ gresitǎ.
In acest curs vom invǎta sǎ proiectǎm corect o bazǎ de date astfel incat sǎ evitǎm aparitia acestor defecte. Proiectul nu este suficient pentru a rezolva problema. Datele sunt depuse in calculator impreunǎ cu relatiile dintre ele intr-un mod fizic care nun e intereseazǎ in acest moment. Noi vrem sǎ exprimǎm cerinte asupra bazei de date in limbajul proiectului. Traducerea din acest limbaj, cǎutarea si editarea rezultatelor este treaba Sistemului de Gestiune al Bazei de Date prescurtat SGBD.
