Un aspect esențial al ingineriei software este subdivizarea procesului de dezvoltare într-o serie de faze sau pași, fiecare dintre aceștia concentrându-se pe un aspect al dezvoltării. Colecția acestor pași este uneori denumită ciclul de viață al dezvoltării software (software development life cycle, SDLC). Produsul software se deplasează prin acest ciclu de viață (uneori în mod repetat pe măsură ce este rafinat sau reamenajat) până când este în cele din urmă retras din utilizare. În mod ideal, fiecare fază din ciclul de viață poate fi verificată pentru corectitudine înainte de a trece la faza următoare.
Ciclul de viață al dezvoltării software – Cascada
Să începem cu o prezentare generală a modelului cascadă, așa cum veți găsi în majoritatea manualelor de inginerie software. Această diahramă a cascadei, văzută în Figura 13.1, ilustrează un model general de cascadă care s-ar putea aplica oricărei dezvoltări de sisteme informatice. Acesta arată procesul ca o secvență strictă de pași în care ieșirea unui pas este intrarea în următorul și fiecare pas trebuie finalizat înainte de a trece la următorul.
Putem folosi procesul în cascadă ca mijloc de identificare a sarcinilor care sunt necesare, împreună cu intrarea și ieșirea pentru fiecare activitate. Ceea ce este important este sfera activităților, care poate fi rezumată după cum urmează:
- Stabilirea cerințelor implică consultarea și acordul între părțile interesate cu privire la ceea ce doresc de la un sistem, exprimat ca o declarație de cerințe.
- Analiza începe prin luarea în considerare a declarației de cerințe și se termină prin producerea unei specificații a sistemului. Specificația este o reprezentare formală a ceea ce ar trebui să facă un sistem, exprimată în termeni independenți de modul în care poate fi realizat.
- Proiectarea începe cu o specificație a sistemului, produce documente de proiectare și oferă o descriere detaliată a modului în care ar trebui construit un sistem.
- Implementarea este construirea unui sistem informatic conform unui anumit document de proiectare și luând în considerare mediul în care sistemul va funcționa (de exemplu, hardware sau software specific disponibile pentru dezvoltare). Implementarea poate fi organizată, de obicei cu un sistem inițial care poate fi validat și testat înainte ca un sistem final să fie lansat pentru utilizare.
- Testarea compară sistemul implementat cu documentele de proiectare și specificațiile cerințelor și produce un raport de acceptare sau, mai de obicei, o listă de erori și erori care necesită o revizuire a proceselor de analiză, proiectare și implementare pentru a corecta (testarea este de obicei sarcina care duce la modelul cascadei iterând prin ciclul de viață).
- Întreținerea implică gestionarea modificărilor cerințelor sau a mediului de implementare, remedierea erorilor sau portarea sistemului în medii noi (de exemplu, migrarea unui sistem de la un PC independent la o stație de lucru UNIX sau un mediu în rețea). Deoarece întreținerea implică analiza modificărilor necesare, proiectarea unei soluții, implementarea și testarea acelei soluții pe durata de viață a unui sistem software întreținut, ciclul de viață al cascadei va fi revizuit în mod repetat.
Ciclul de viață al bazei de date
Putem folosi ciclul cascadei ca bază pentru un model de dezvoltare a bazelor de date care încorporează trei ipoteze:
- Putem separa dezvoltarea unei baze de date – adică specificarea și crearea unei scheme pentru a defini datele dintr-o bază de date – de procesele utilizatorilor care folosesc baza de date.
- Putem folosi arhitectura cu trei scheme ca bază pentru a distinge activitățile asociate cu o schemă.
- Putem reprezenta constrângerile pentru a impune semantica datelor dintr-o bază de date, mai degrabă decât în cadrul fiecărui proces de utilizator care utilizează datele.
(Un model de cascadă a activităților și a rezultatelor acestora pentru dezvoltarea bazei de date.)
Folosind aceste ipoteze și Figura 13.2, putem vedea că această diagramă reprezintă un model al activităților și al rezultatelor acestora pentru dezvoltarea bazei de date. Este aplicabil oricărei clase de SGBD, nu doar unei abordări relaționale.
Dezvoltarea aplicației bazei de date este procesul de obținere a cerințelor din lumea reală, analizarea cerințelor, proiectarea datelor și funcțiilor sistemului și apoi implementarea operațiunilor în sistem.
Colectarea cerințelor
Primul pas este colectarea cerințelor. În această etapă, proiectanții bazei de date trebuie să intervieveze clienții (utilizatorii bazei de date) pentru a înțelege sistemul propus și pentru a obține și documenta datele și cerințele funcționale. Rezultatul acestui pas este un document care include cerințele detaliate furnizate de utilizatori.
Stabilirea cerințelor implică consultarea și acordul între toți utilizatorii cu privire la datele persistente pe care doresc să le stocheze, împreună cu un acord cu privire la semnificația și interpretarea elementelor de date. Administratorul de date joacă un rol esențial în acest proces, deoarece face o prezentare generală a problemelor de afaceri, juridice și etice din cadrul organizației care au impact asupra cerințelor de date.
Documentul privind cerințele de date este utilizat pentru a confirma înțelegerea cerințelor de către utilizatori. Pentru a vă asigura că este ușor de înțeles, nu ar trebui să fie prea formal sau foarte codificat. Documentul ar trebui să ofere un rezumat concis al tuturor cerințelor utilizatorilor – nu doar o colecție de cerințe ale persoanelor – deoarece intenția este de a dezvolta o singură bază de date partajată.
Cerințele nu ar trebui să descrie modul de procesare a datelor, ci mai degrabă care sunt elementele de date, ce atribute au, ce constrângeri se aplică și relațiile care există între articolele de date.
Analiza
Analiza datelor începe cu enunțul cerințelor de date și apoi produce un model conceptual de date. Scopul analizei este de a obține o descriere detaliată a datelor care se vor potrivi cerințelor utilizatorilor, astfel încât să fie abordate atât proprietățile la nivel înalt, cât și cele scăzute ale datelor, precum și utilizarea acestora. Acestea includ proprietăți, cum ar fi gama posibilă de valori care pot fi permise pentru atribute (de exemplu, în exemplul bazei de date școlare, codul cursului studentului, titlul cursului și punctele de credit).
Modelul conceptual de date oferă o reprezentare partajată și formală a ceea ce este comunicat între clienți și dezvoltatori în timpul dezvoltării bazei de date – se concentrează pe datele dintr-o bază de date, indiferent de eventuala utilizare a acestor date în procesele utilizatorilor sau implementarea datelor în medii informatice specifice. Prin urmare, un model conceptual de date se referă la semnificația și structura datelor, dar nu și la detaliile care afectează modul în care acestea sunt implementate.
Modelul conceptual de date este atunci o reprezentare formală a datelor care ar trebui să conțină o bază de date și a constrângerilor pe care datele trebuie să le îndeplinească. Acest lucru ar trebui exprimat în termeni care sunt independenți de modul în care modelul poate fi implementat. Ca rezultat, analiza se concentrează pe întrebările „Ce este necesar?”, nu „Cum se realizează?”
Proiectarea logică
Proiectarea bazei de date începe cu un model conceptual de date și produce o specificație a unei scheme logice; aceasta va determina tipul specific de sistem de baze de date (rețea, relațional, orientat pe obiect) care este necesar. Reprezentarea relațională este încă independentă de orice SGBD specific; este un alt model conceptual de date.
Putem folosi o reprezentare relațională a modelului de date conceptuale ca intrare în procesul de proiectare logică. Rezultatul acestei etape este o specificație relațională detaliată, schema logică, a tuturor tabelelor și constrângerilor necesare pentru a satisface descrierea datelor din modelul de date conceptuale. În timpul acestei activități de proiectare se iau decizii cu privire la ce tabele sunt cele mai potrivite pentru reprezentarea datelor într-o bază de date. Aceste alegeri trebuie să ia în considerare diverse criterii de proiectare, incluzând, de exemplu, flexibilitatea pentru schimbare, controlul duplicării și modul în care să reprezinte cel mai bine constrângerile. Tabelele definite de schema logică determină ce date sunt stocate și cum pot fi manipulate în baza de date.
Proiectanții de baze de date familiarizați cu bazele de date relaționale și SQL ar putea fi tentați să meargă direct la implementare după ce au produs un model conceptual de date. Cu toate acestea, o astfel de transformare directă a reprezentării relaționale în tabele SQL nu duce neapărat la o bază de date care are toate proprietățile dorite: completitudine, integritate, flexibilitate, eficiență și usabilitate. Un bun model conceptual de date este un prim pas esențial către o bază de date cu aceste proprietăți, dar asta nu înseamnă că transformarea directă în tabele SQL produce automat o bază de date bună. Acest prim pas va reprezenta cu exactitate tabelele și constrângerile necesare pentru a satisface descrierea modelului de date conceptuale și, prin urmare, va satisface cerințele de completitudine și integritate, dar poate fi inflexibil sau poate oferi o utilizare slabă. Primul design este apoi flexat pentru a îmbunătăți calitatea proiectării bazei de date. Flexarea este un termen care este destinat să surprindă ideile simultane de a deforma ceva pentru un scop diferit și de a slăbi aspectele acestuia în timp ce este deformat.
Figura 13.3 rezumă pașii iterativi (repetați) implicați în proiectarea bazei de date, pe baza prezentării generale. Scopul său principal este de a distinge problema generală a tabelelor care ar trebui utilizate de definiția detaliată a părților constitutive ale fiecărui tabel – aceste tabele sunt considerate pe rând, deși nu sunt independente unul de celălalt. Fiecare iterație care implică o revizuire a tabelelor ar duce la un nou design; în mod colectiv, acestea sunt denumite de obicei modele de a doua tăiere, chiar dacă procesul se repetă mai mult de o singură buclă.
(Un rezumat al etapelor iterative implicate în proiectarea bazei de date.)
În primul rând, pentru un model de date conceptual dat, nu este necesar ca toate cerințele utilizatorilor pe care le reprezintă să fie satisfăcute de o singură bază de date. Pot exista diverse motive pentru dezvoltarea mai multor baze de date, cum ar fi necesitatea unei operațiuni independente în diferite locații sau controlul departamental asupra datelor „lor”. Cu toate acestea, dacă colecția de baze de date conține date duplicate și utilizatorii trebuie să acceseze date în mai multe baze de date, atunci există posibile motive pentru care o bază de date poate satisface cerințe multiple sau trebuie examinate problemele legate de replicarea și distribuirea datelor.
În al doilea rând, una dintre ipotezele despre dezvoltarea bazei de date este că putem separa dezvoltarea unei baze de date de dezvoltarea proceselor utilizatorilor care o utilizează. Aceasta se bazează pe așteptarea ca, odată ce o bază de date a fost implementată, toate datele necesare proceselor identificate în prezent de utilizator au fost definite și pot fi accesate; dar avem nevoie și de flexibilitate pentru a ne permite să îndeplinim viitoarele modificări ale cerințelor. În dezvoltarea unei baze de date pentru unele aplicații, poate fi posibil să se prezică solicitările comune care vor fi prezentate bazei de date și astfel putem optimiza proiectarea noastră pentru cele mai frecvente solicitări.
În al treilea rând, la un nivel detaliat, multe aspecte ale proiectării și implementării bazei de date depind de SGBD-ul particular utilizat. Dacă alegerea SGBD este fixă sau făcută înainte de sarcina de proiectare, acea alegere poate fi utilizată pentru a determina criteriile de proiectare, mai degrabă decât pentru a aștepta până la implementare. Adică, este posibil să se încorporeze decizii de proiectare pentru un anumit SGBD, mai degrabă decât să producă un design generic și apoi să îl adapteze la SGBD în timpul implementării.
Nu este neobișnuit să constatăm că un singur design nu poate satisface simultan toate proprietățile unei baze de date bune. Deci, este important ca proiectantul să acorde prioritate acestor proprietăți (de obicei folosind informații din specificațiile cerințelor); de exemplu, pentru a decide dacă integritatea este mai importantă decât eficiența și dacă usabilitatea este mai importantă decât flexibilitatea într-o anumită dezvoltare.
La sfârșitul etapei noastre de proiectare, schema logică va fi specificată prin declarații SQL Data Definition Language (DDL), care descriu baza de date care trebuie implementată pentru a satisface cerințele utilizatorului.
Implementarea
Implementarea implică construirea unei baze de date în conformitate cu specificația unei scheme logice. Aceasta va include specificarea unei scheme adecvate de stocare, aplicarea securității, schema externă și așa mai departe. Implementarea este puternic influențată de alegerea SGBD-urilor disponibile, a instrumentelor de bază de date și a mediului de operare. Există sarcini suplimentare dincolo de simpla creare a unei scheme de baze de date și implementarea constrângerilor – datele trebuie introduse în tabele, problemele legate de utilizatori și procesele utilizatorilor trebuie abordate, iar activitățile de management asociate cu aspecte mai largi ale gestionării datelor corporative trebuie să fie sprijinite. În conformitate cu abordarea SGBD, dorim ca să fie abordate cât mai multe dintre aceste preocupări în SGBD. Ne uităm la câteva dintre aceste preocupări acum pe scurt.
În practică, implementarea schemei logice într-un SGBD dat necesită o cunoaștere foarte detaliată a caracteristicilor și facilităților specifice pe care SGBD le poate oferi. Într-o lume ideală și în concordanță cu bunele practici de inginerie software, prima etapă de implementare ar presupune potrivirea cerințelor de proiectare cu cele mai bune instrumente de implementare disponibile și apoi utilizarea acestor instrumente pentru implementare. În termeni de baze de date, aceasta ar putea implica alegerea produselor furnizorului cu variantele SGBD și SQL cele mai potrivite pentru baza de date pe care trebuie să o implementăm. Cu toate acestea, nu trăim într-o lume ideală și, cel mai adesea, alegerea hardware-ului și deciziile referitoare la SGBD vor fi luate cu mult înainte de luarea în considerare a proiectării bazei de date. În consecință, implementarea poate implica o flexibilitate suplimentară a proiectului pentru a depăși orice limitări software sau hardware.
Realizarea designului
După ce a fost creat designul logic, avem nevoie ca baza noastră de date să fie creată în conformitate cu definițiile pe care le-am produs. Pentru o implementare cu un SGBD relațional, aceasta va implica probabil utilizarea SQL pentru a crea tabele și constrângeri care să satisfacă descrierea schemei logice și alegerea schemei de stocare adecvate (dacă SGBD permite acel nivel de control).
O modalitate de a realiza acest lucru este să scrieți instrucțiunile SQL DDL adecvate într-un fișier care poate fi executat de un SGBD astfel încât să existe o înregistrare independentă, un fișier text, al instrucțiunilor SQL care definesc baza de date. O altă metodă este de a lucra interactiv folosind un instrument de bază de date precum SQL Server Management Studio sau Microsoft Access. Orice mecanism este utilizat pentru a implementa schema logică, rezultatul este că o bază de date, cu tabele și constrângeri, este definită, dar nu va conține date pentru procesele utilizatorului.
Popularea bazei de date
După ce a fost creată o bază de date, există două moduri de populare a tabelelor – fie din datele existente, fie prin utilizarea aplicațiilor utilizator dezvoltate pentru baza de date.
Pentru unele tabele, pot exista date existente dintr-o altă bază de date sau fișiere de date. De exemplu, în stabilirea unei baze de date pentru un spital, vă așteptați să existe deja unele evidențe ale întregului personal care trebuie inclus în baza de date. Datele pot fi, de asemenea, aduse de la o agenție externă (listele de adrese sunt aduse frecvent de la companii externe) sau produse în timpul unei sarcini mari de introducere a datelor (convertirea înregistrărilor manuale copiate în fișiere computerizate poate fi făcută de o agenție de introducere a datelor). În astfel de situații, cea mai simplă abordare pentru popularea bazei de date este folosirea facilităților de import și export găsite în SGBD.
Facilitățile de import și export de date în diferite formate standard sunt de obicei disponibile (aceste funcții sunt cunoscute și în unele sisteme ca date de încărcare și descărcare). Importul permite copierea unui fișier de date direct într-un tabel. Când datele sunt păstrate într-un format de fișier care nu este adecvat pentru utilizarea funcției de import, atunci este necesar să pregătiți un program de aplicație care citește datele vechi, le transformă după cum este necesar și apoi le introduce în baza de date folosind codul SQL produs special pentru acel scop. Transferul de cantități mari de date existente într-o bază de date este denumit o încărcare în bloc. Încărcarea în bloc a datelor poate implica încărcarea unor cantități foarte mari de date, câte un tabel la rând, astfel încât să puteți constata că există facilități SGBD pentru a amâna verificarea constrângerilor până la sfârșitul încărcării în bloc.
Liniile directoare pentru dezvoltarea unei diagrame ER
Notă: Acestea sunt îndrumări generale care vor ajuta la dezvoltarea unei baze solide pentru proiectarea reală a bazei de date (modelul logic).
- Documentați toate entitățile descoperite în timpul etapei de colectare a informațiilor.
- Documentați toate atributele care aparțin fiecărei entități. Selectați cheile candidat și primare. Asigurați-vă că toate atributele non-cheie pentru fiecare entitate sunt complet funcționale dependente de cheia primară.
- Elaborați o diagramă ER inițială și revizuiți-o cu personalul corespunzător. (Amintiți-vă că acesta este un proces iterativ.)
- Creați entități noi (tabele) pentru atribute cu mai multe valori și grupuri repetate. Incorporați aceste noi entități (tabele) în diagrama ER. Revizuiți cu personalul adecvat.
- Verificați modelarea ER prin normalizarea tabelelor.
Termeni cheie
- analiza: începe prin luarea în considerare a declarației de cerințe și se termină prin producerea unei specificații de sistem
- ciclul de viață al dezvoltării software (SDLC): seria de pași implicați în procesul de dezvoltare a bazei de date
- colectarea cerințelor: un proces în timpul căruia proiectantul bazei de date intervievează utilizatorul bazei de date pentru a înțelege sistemul propus și pentru a obține și documenta datele și cerințele funcționale
- design: începe cu o specificație a sistemului, produce documente de proiectare și oferă o descriere detaliată a modului în care ar trebui construit un sistem
- document de cerințe de date: utilizat pentru a confirma înțelegerea cerințelor de către utilizator
- flexare: un termen care surprinde ideile simultane de a deforma ceva pentru un scop diferit și de a slăbi aspectele acestuia, în timp ce este deformat
- implementare: construirea unui sistem informatic conform unui document de proiectare dat
- încărcare în masă: transferul unor cantități mari de date existente într-o bază de date
- întreținere: implică gestionarea modificărilor cerințelor sau a mediului de implementare, remedierea erorilor sau portarea sistemului în medii noi
- model de cascadă: arată procesul de dezvoltare a bazei de date ca o secvență strictă de pași în care ieșirea unui pas este intrarea în următorul
- modele de a doua tăiere: colecția de iterații care implică fiecare o revizuire a tabelelor care duc la un nou design
- procesul cascadei: un mijloc de identificare a sarcinilor necesare dezvoltării bazei de date, împreună cu intrarea și ieșirea pentru fiecare activitate (vezi modelul cascadei)
- stabilirea cerințelor: implică consultarea și acordul între părțile interesate cu privire la ceea ce doresc de la un sistem; exprimat ca o declarație de cerințe
- testare: compară sistemul implementat cu documentele de proiectare și specificațiile cerințelor și produce un raport de acceptare
Sursa: Adrienne Watt, Database Design – 2nd Edition. Descărcare gratuită de la B.C. Open Textbook Collection. © 2014 Adrienne Watt and Nelson Eng. Licența (inclusiv imagini) CC BY 4.0. Traducere Nicolae Sfetcu
© 2021 MultiMedia Publishing, Baze de date, Volumul 1
Lasă un răspuns