Partea 1.

Proiectarea logică a bazelor de date

Capitolul 3. Procesul de proiectare al bazei de date

Succesul unui mediu de baze de date este puternic determinat de cât de bine a
fost structurată logic baza de date. Acest capitol introduce concepte de bază
în proiectarea bazelor de date.

3.1. Ciclu de viaţă. Durate de viaţă (lifecycles)

Sintagma “ciclu de viaţă” este folosită ca loc comun în analiza sistemelor şi

în prelucrarea datelor pentru o secvenţă de faze în evoluţia software-ului.
Conceptele de “ciclu de viaţă” sunt folosite pentru a explica dezvoltarea
sistemelor, pentru a organiza proiecte de sisteme, pentru a standardiza
documentaţia şi pentru a comunica progresul sistemelor.
În general, nu există concordanţă asupra ceea ce înseamnă fază în
ciclul de viaţă al sistemului. Unii vorbesc de 17 faze pentru a descrie
dezvoltarea sistemului, alţii nu folosesc mai mult de trei faze. Multe
propuneri cad pe undeva între aceste limite.
Următoarele faze descriu percepţia tipică a procesului de dezvoltare
a sistemului:
Definirea problemei: recunoaşterea faptului că este nevoie de un sistem nou,
identificarea scopurilor şi a obiectivelor, redactarea (întocmirea)
costurilor şi a restricţiilor de livrare.
Studiu de fezabilitate: decizia asupra magnitudinii efortului de dezvoltare,
urmărirea disponibilităţii resurselor, estimarea costurilor şi
planificării preliminare, evaluarea costurilor versus beneficii.
Analiza sistemului existent: revederea documentaţiei de sistem, a soft-ului
şi a procedurilor existente şi identificarea deficienţelor şi
insuficienţelor sistemelor existente.
Proiectarea preliminară: identificarea subsistemelor majore, a funcţiile lor,
a interfeţelor subsisteme, descrierea fişierelor de bază şi a fluxului în

31
 sistem, analizarea mediilor de calculator gazdă şi de comunicaţii
precum şi a formelor de bază pentru intrări şi ieşiri.
Proiectarea detaliată: identificarea modulelor de codificat, dezvoltarea
algoritmilor detaliaţi, a procedurilor, a controalelor, a fişierelor, a
organizării rapoartelor şi a formelor de intrare.
Programarea: scrierea codului pentru a implementa modulele identificate în
faza de proiectare detaliată şi testarea unităţilor.
Testarea: dezvoltarea datelor de test pentru integrarea sistemului, testerea
sistemului, evaluarea performanţei sistemului şi obţinerea acceptării
pentru sistem.
Conversia: transferarea sistemului în starea de producţie; convertirea
fişierelor în noile formate, conducerea operaţiilor paralele şi
realizarea despărţirii de cel vechi.
Operarea: gestionarea sistemului colectarea de rapoarte de probleme,
oferirea de rapoarte şi de date operaţionale, proiecţia încărcărilor
de lucru.
Documentarea, antrenarea şi gestionarea proiectului se realizează în paralel
cu aceste faze ale ciclului de viaţă.

Definirea
problemei 1
Studiu de fezabilitate
2
Operare 9

Analiza sistemului
Conversie 8
existent 3

Testare 7
Proiectarea
preliminară 4

Programare Proiectarea
6 detaliată 5

Fig.3.1. Durata de viaţă convenţională pentru dezvoltarea de sisteme

Aceasta este o vedere tradiţională a dezvoltării sistemelor, care

statuează dezvoltarea sistemelor pe instrucţiuni precise de cerinţe funcţionale
şi apoi o prelucrează de la proiectarea preliminară la cea detaliată până când
sistemul terminat este livrat utilizatorilor săi. Ea presupune să sistemele se
nasc, trăiesc şi apoi, eventual, se înbolnăvesc şi mor, după care sunt înlocuite

32
cu mai “tinere” şi înbunătăţite generări de cod. Ciclul de viaţă al codului
aplicaţiilor sistem este de aproximativ 10 ani, dar în scădere. Datele, ca şi
sistemele au ciclu de viaţă. Când datele se nasc, ele sunt personale, căci sunt
proprietatea persoanei care le-a creat şi sunt complet sub controlul persoanei.
Dacă datele persoanei se dovedesc utile, există o presiune care le face
cunoscute din ce în ce mai multor persoane, aşa că datele personale devin
date partajate. Datele nu mor niciodată. Datele istorice pot fi arhivate, dar ele
nu dispar. Ele nu sunt înlocuite de date noi, cu toate că pot primi roluri
diferite (de ex. arhivare) atunci când noi date sunt achiziţionate. Noile
sisteme de aplicaţii nu sunt create pentru a înlocui datele vechi cu date noi ci
pentru a înbunătăţi modul de prelucrare şi gestionare a datelor. Atunci când
datele sunt partajate, calitatea lor trebuie să fie mai bine controlată. Cu cât o
dată se maturizează, nevoia de control creşte. Cu cât oamenii se încred mai
mult în dată, cu atât devine mai important ca datele să fie protejate, accesibile
şi de o înaltă calitate. Recunoaşterea unui ciclu de viaţă a datelor conduce la
înţelegerea faptului că datele au vieţi distincte de cele ale sistemului construit
pentru a le manipula şi accesa.

3.2. Necesitatea unei metodologii de dezvoltare a sistemelor axate pe date

Dacă bazele de date sunt implementate folosind orientarea tradiţională pe

aplicaţii, discutată în capitolul precedent, atunci proiectele de baze de date
vor urma ciclul de viaţă tradiţional. Din nou, acest ciclu presupune că bazele
de date vor muri şi lucrul acesta este pregătit încă din start.
O alternativă este de a lăsa resursa de date să evolueze, fără a o
constrânge la limitele de astăzi ale aplicaţiilor şi organizaţiilor. Într-adevăr,
anumite companii mută oamenii pentru a înbunătăţi comunicarea în cadrul
organizaţiei şi înţelegerea de către angajaţi a afacerii companiei. Marginile
naturale ale aplicaţiei au tendinţa de a mişca mai încet decât cele ale
organizaţiei, dar totuşi ele se mişcă.
O modalitate de a implementa un mediu efectiv orientat pe date este
de a adopta un cadru care
1. explică tipurile de relaţii de date pertinente în mediile de baze de date.
2. accentuează independenţa aspectelor utilizator şi implementare în
gestionarea datelor.
3. este independent de orice abordare de modelare date particulară unui
vânzător de DBMS.
Un astfel de cadru este abordarea cu trei scheme pe care am
prezentat-o sumar în capitolul introductiv al acestui curs. Vom reveni acum
mai pe larg asupra acestei arhitecturi propuse la mijlocul anilor 70 şi
publicate în 1977 într-unraport ANSI “The ANSI/X3/SPARC DBMS
Framework: Report of the Study Group on Database Management Systems”.
O definiţie de dicţionar a schemei este “diagramă, plan, proiect, schiţă”. Într-
un context de gestionare de date, cuvântul schemă înseamnă însă o structură

33
de date care este formalizată în concordanţă cu o mulţime de reguli. O
schemă este un model, pictat uzual în diagrame şi câteodată însoţit de
descrieri în cuvinte. Abordarea cu trei scheme are trei tipuri de scheme,
fiecare cu un scop specific. În plus, abordările alternative pot fi mapate pe
abordarea cu 3 scheme, ceea ce vom vedea în capitolele următoare.

3.3. Abordarea cu trei scheme

Abordarea cu trei scheme se bazează pe presupunerile că:

 calculatoarele şi utilizatorii au nevoie de a vedea aceleaşi date în moduri
diferite
 diferiţi utilizatori au nevoie de a vedea diferite părţi ale ansamblului de
date
 este de dorit pentru calculatoare şi utilizatori să fie posibil a schimba
modurile în care ei văd datele
 nu este de dorit ca un calculator să dicteze sau să restrângă modurile în
care utilizatorii văd datele
Astfel, este necesar să fim în stare să oferim diferitele vederi ale resursei de
date.
Separarea vederilor utilizator de vederile de implementare.
Utilizatorii au nevoie să lucreze cu reprezentări de date care sunt
independente de modurile în care datele sunt memorate şi gestionate în
calculator. Utilizatorul vede datele ca entităţi de nivel înalt, de exemplu
instrumente, vehicule, produse, clienţi. Deocamdată, facilităţil calculatorului
(incluzând metodele de acces, sistemele de operare şi DBMS-urile) sunt în
stare să lucreze cu reprezentări fizice. Ele văd datele în termeni de înregistrări
şi fişiere, cu structuri index, B-arbori, liste înlănţuinte, pointeri, adrese,
pagini, etc. Aceste cerinţe ne conduc să concluzionăm, pentru început, că
există două tipuri diferite de vederi asupra datelor, vederi utilizator şi vederi
implementare. Vederile utilizator sunt modele ale lumii reale; ele comunică
cu utilizatorii. Vederile de implementare, pe de altă parte, sunt orientate spre
calculator.
Folosind terminologie abordării cu trei scheme, schemele externe
sunt vederi utilizator asupra datelor aşa cum sunt văzute de una sau mai
multe apicaţii, iar schemele interne sunt vederi de implementare ale bazelor
de date. Schemele conţin metadate, adică, date despre date. De exemplu,
NUME_CLIENT şi CHARACTER(17) sunt metadate descriind valoare dată
ION IONESCU. Metadatele dau semnificaţii; valorile de date dau fapte;
semnificaţiile şi faptele împreună dau datele.
Mapări interscheme. Obiectivul gestionării datelor este de a
permite utilizatorilor să acceadă date computerizate. Astfel, trebuie să existe
mapări sau transformări intre vederile utilizator şi vederile de
implementare. Aceste mapări ar putea fi simple dacă există numai o schemă

34
externă şi numai o schemă internă. În exemplul simplificat din capitolul
introductiv am considerat existenţa unei singure scheme interne. Totuşi în
cazul real nu numai că există o multitudine de scheme externe, dar şi numărul
schemelor interne în intreprindere poate fi mai mare. Fiecare schemă externă
poate fi mapată direct pe baza de date. Această soluţie suferă, totuşi, atunci
când oricare din tipurile de schemă se modifică. De exemplu, dacă o bază de
date fizică este restructurată pe disc pentru a oferi o performanţă mai mare,
atunci maparea pe fiecare schemă externă care referă baza de date poate fi
afectată. Dacă o schemă externă este revizuită pentru a prezenta datele într-o
manieră oarecum diferită, atunci maparea pe fiecare din bazele de date
referite poate fi afectată. Folosirea pamării directe schemă internă - schemă
externă previne independenţa între aplicaţii şi implementare. Factorii de
calculator fizic restricţionează astfel modurile în care utilizatorii văd datele
lor. Pentru a permite diferiţilor utilizatori să-şi partajeze resursa de date care
poate fi implementată pe mai multe baze de date fizice, abordarea cu trei
scheme inserează o vedere neutră, integrată între schemele externe şi cele
interne. În termenii abordării cu trei scheme, această vedere este schema
conceptuală sau vederea intreprinderii sau vederea comunităţii.

Vedere utilizator 1
Baza de date A

Baza de date B

Vedere utilizator 2

Baza de date C

Vedere utilizator 2 Baza de date D

Fig. 3.2. Maparea directă a vederilor utilizator pe vederile de

implementare

35
 Schema
externă 1 Schema
internă1

Schema Schema Schema

externă 2 conceptuală internă2

Schema
Schema internăM
externă N

Fig. 3.3. Arhitectura cu trei scheme: o schemă conceptuală oferită pentru

integrarea şi independenţa multitudinii de scheme externe şi interne

Schema conceptuală. O schemă conceptuală este extensibilă,

consistentă, accesibilă şi partajabilă şi ea permite ca resursa de date să
evolueze după cum se modifică şi se maturizează nevoile. Fig. 3.3. ilustrează
relaţiile între cele trei tipuri de scheme. Schemele şi mapările între ele permit
atât independenţa datelor cât şi suportul pentru vederi multiple. O schemă
internă poate fi modificată pantru a înbunătăţi performanţa şi pentru a profia
de noile dezvoltări tehnice, fără a altera schema conceptuală sau schemele
externe. Schemele externe pot fi modificate pentru a reflecta schimbări în
vederea unei aplicaţii sau folosirea datelor, fără a afecta schema conceptuală
sau schemele interne. Schema conceptuală reprezintă cunoştiinţe despre date
partajabile. Pot exista controale de acces şi restricţii de securitate asupra
acestor date comune, dar ele nu sunt restricţionate la a fi cunoscute numia de
un utilizator. Schema conceptuală nu descrie date personale ci, mai degrabă,
date partajate controlate de intreprindere. Domeniul schemei conceptuale se
expandează în timp. Abordarea bazată pe date a proiectelor baze de date, care
este discutată în secţiunea următoare, expandează continuu schema
conceptuală pentru a include cunoştiinţe despre tot mai multe date partajate.
Un proiect bază de date în abordarea bazată pe date nu redefineşte resursa de
date şi nici nu crează o nouă bază de date de sine stătătoare. în loc de acestea,
fiecare proiect trebuie să determine modul în care datele din domeniul său se

36
leagă de ceea ce este deja cunoscut din schema conceptuală. Rezultatul este o
resursă de date integrată al cărui domeniu este expandat gradat. Resursele de
date ale unei organizaţii nu pot fi integrate toate deodată; sarcina trebuie
executată pe bucăţi, iar schema conceptuală este integratorul.

3.4. Ciclul de viaţă al unui proiect bazat pe date (data-driven)

Obiectivul primar al ciclului de viaţă al unui proiect bazat pe date este de a

implementa bazele de date şi software-ul utilizator pe baza unei scheme
conceptuale integrate. Modelul de mai jos nu este singurul ciclu de viaţă
posibil pentru un proiect bazat pe date, dar este unul care a fost testat şi s-a
arătat de succes într-o varietate de medii. Ciclul de viaţă al proiectului bazat
pe date nu este acelaşi cu cel convenţional pentru dezvoltarea sistemelor,
introdus la începutul capitolului. Mai degrabă, abordarea convenţională
construieşte baze de date şi fişiere separate, pe când abordarea bazată pe date
construieşte baze de date integrate. Abordarea convenţională se bizuie pe
declaraţii complete şi corecte de cerinţe înainte de a oferi ceva concret
utilizatorului. Abordarea bazată pe date promovează prototiparea pentru a
ajuta la descoperirea de cerinţe, iar utilizatorii contribuie activ şi esenţial în
acest proces de prototipare. Prototipurile oferă posibilităţi de un cost relativ
scăzut pentru a determina care ar trebui să fie funcţia sistemului obiectiv, căci
ele permit experimentarea înainte ca proiectarea să fie realizată în formă
finală.
Fazele. Fazele dintr-un proiect bazat pe date (fig. 3.4.) sunt:
1. Examinarea: a stabili domeniul şi planificarea proiectului, a colecta şi
analiza informaţii despre datele din domeniul proiectului, a dezvolta
modele de date logice de nivel înalt, a identifica posibilităţi de
înbunătăţire.
2. Proiectarea: a dezvolta modele de date logice detaliate pentru noul mediu,
a planifica procesul de prototipare, a redacta schiţa cu specificaţiile
tranzacţiilor bazei de date.
3. Prototipare: a proiecta structura bazei de date fizice pentru prototipul
iniţial al bazei de date, a încărca prototipul, a folosi prototipul pentru a
rafina şi valida vederile utilizator şi a defini tranzacţiile cerute, a dezvolta
tranzacţiile şi a transfera prototipul în starea de lucru.
4. Integrare: a integra modele de date logice prototip cu schema conceptuală
şi a ajusta mapările interscheme.
5. Reglaj: a rafina structurile bazei de date fizice şi a optimiza software-ul.
6. Revizie: a monitoriza calitatea ieşirilor proiectului şi a transfera prototipul
din starea de pregătire în starea de producţie.
Această abordare a proiectării se bazează puternic pe construcţia modelelor
de date care reprezintă resursele de date din diferite perspective. Accentul, în
fazele de examinare, proiectare, prototipare şi integrare cade pe modelele de
date logice, care reprezintă semnificaţia datelor.

37
 Prototiparea bazei de date. Să notăm buclele de feedback din
ciclul de viaţă din fig.3.4. Buclele de feedback din faza de prototipare permit
modifcarea vederilor utilizator şi a acestor contribuţii la schema conceptuală
înainte de a muta baza de date în starea de producţie. Utilizatorii sunt
puternic imlpicaţi în faza de prototipare, înainte ca baza de date să devină o
declaraţie completă de cerinţe. Aceasta este în contrast cu ciclul de viaţă al
dezvoltării sistemelor convenţionale. care aşteaptă până când toate cerinţele
sunt cunoscute şi abia apoi începe proiectarea. Folosind acest ciclu de viaţă al
proiectului, se pot construi prototipuri şi se pot pune în lucru rapid, de ordinul
zilelor. Ciclul de viaţă lucrează, de asemenea, cu prototipuri de domeniu larg,
în care trebuiesc luni de zile pentru a ajunge din stadiul de iniţiere al
proiectului la o bază de date în lucru. Structura fizică prototip a bazei de date
poate fi modificată astfel încât ea să acopere mai eficient performanţele de
producţie cerute. Modelul său de date logice, totuşi, nu este abandonat ci este
integrat în schema conceptuală şi mapat pe structura fizică, adică pe
versiunea de producţie a schemei interne.
Echipele proiectului. Abordarea bazată pe date în dezvoltarea
bazelor de date cere echipe de proiect compuse atât din personal de
prelucrare date cât şi din utilizatori. Decât să-şi trimită cerinţele lor
departamentului de prelucrare date şi apoi să vadă ce primesc de acolo,
utilizatorii (end-users) ajută la determinarea relaţiilor şi tranzacţiilor de date.
Ei sunt implicaţi în sistem ca şi creatori şi nu numai după ce acesta a fost
dezvoltat, ca şi indivizi ce trebuie să trăiască cu el.

3.5. Integrarea şi schema conceptuală

Una dintre cele mai importante caracteristici ale acestui ciclu de viaţă al
dezvoltării este aceea că fiecare proiect nu trebuie să-şi recreeze propria sa
bază de date separată. Mai degrabă, fiecare proiect trebuie să examineze cum
se leagă datele din domeniul său cu datele din schema conceptuală existentă.
Schema conceptuală evoluează după cum apar proiecte adiţionale bazate pe
date. Fiecare proiect îşi poate crea propria bază de date fizică prototip
separată, dar se urmăreşte integrarea acestor baze de date. Câteodată se
iniţează un proiect şi apoi se descoperă că datele necesare pentru a-l susţine
sunt deja disponibile şi descrise în schema conceptuală. Se poate dezvolta
atunci o nouă schemă externă şi ea se poate mapa pe schema conceptuală care
este mapată pe una sau mai multe scheme interne.
Cele de mai sus nu implică crearea unei baze de date uriaşă pentru a
conţine toate informaţiile de producţie necesare, deoarece în concordanţă cu
abordarea cu trei scheme, schema conceptuală poate fi mapată pe oricâte
scheme interne, fiecare reprezentând o bază de date fizică. Aceste baze de
date fizice pot fi rezidente pe mai multe calculatoare şi pot fi distribuite
geografic pe tot cuprinsul unei intreprinderi. Schema conceptuală integrează
aceste componente distribuite. Astfel, schema conceptuală integrează vederile

38
 Schema conceptuală externă

Conducerea
examinării Modele
operaţionale “este-ca”
as-is
Dezvoltarea
proiectării Modele
conceptuale “a fi”
Model de
Prototiparea date
bazei de date validat
şi a
Integrarea
tranzacþiilor
proiectului
model de date
Noua schemã conceptualã
în schema
conceptualã
Baza
A potrivi de date
Baza de date şi tranzacţiile
eficienţa şi
tranzac
A revedea ţiile
calitatea
de pro-
ducţie

Fig.3.4.Ciclul de viaţă al unui proiect bazat pe date, cu prototipuri.

39
orientate pe aplicaţie, reprezentate de schemele externe, sau dintr-o altă
perspectivă, ea integrează vederile orientate pe implementare, reprezentate de
schemele interne.
Scheme conceptuale pasive şi active. Datele nu sunt integrate până
când legătura ermetică dintre schemele interne şi externe nu este spartă.
Schema conceptuală trebuie să controleze accesul la manipularea resurselor
de date, şi nu aplicaţiile program. Spargerea legăturii între schemele interne şi
externe nu este simplă. Există doi paşi intermediari care superimpun, la
început a schemă conceptuală pasivă şi apoi o vedere completă cu trei
scheme în vârful legăturii directe intern-extern. Moştenirea majorităţii
mediilor de aplicaţii baze de date este arătată în fig.3.5.a. Schemele interne şi
externe sunt unite prin codul aplicaţiei program. Nu există nici o vedere
intreprindere a resursei de date. Notaţia cu “punct mare” folosită în figura
3.5. arată tipul de relaţie posibilă între entităţile din cutii. Un “punct mare”
înseamnă mai multe. Fig. 3.5.a spune că o schemă internă poate suporta
direct mai multe scheme externe şi că o schemă externă poate fi suportată
direct de mai multe scheme interne. În pasul 1. (fig.3.5.b) se introduce
schema conceptuală iar schemele interne şi externe continuă să fie legate
direct. O schemă conceptuală descrie toate datele disponibile în toate
schemele interne, într-o vedere integrată, neutră şi pasivă a resurselor de date.
Orice control pe care îl are schema conceptuală asupra resurselor de date
depinde complet de politicile, procedurile şi administrarea resurselor. Schema
conceptuală rezidă într-un dicţionar de date (vezi cap. 1.) şi este descrisă ca
un model de date logice (vezi cap. 4.). Pasul 2. (fig.3.5.c) oferă o altă punte
spre integrare. Schemele externe sunt mapate pe schema conceptuală iar
dicţionarul de date poate fi folosit pentru a determina cine accede la date.
Pasul 3 (fig.3.5.d) arată o schemă conceptuală activă. Atunci când se
foloseşte o schemă conceptuală activă, software-ul de gestionare date
realizează operaţiile necesare pentru a prelua o cerere utilizator în forma din
schemă externă şi a o mapa pe schema conceptuală şi apoi pe cele interne.
Aplicaţiile program se confruntă numai cu schemele externe. O aplicaţie
program sau o tranzacţie particulară poate accesa date din mai multe baze de
date, fără a se preocupa de locul unde se găsesc datele. Baza de date poate să
fie distribuită pe mai multe calculatoare ale reţelei. Transformările
interscheme nu se realizează în codul aplicaţiei program ci în software-ul de
gestionare date care oferă controlul activ al schemei conceptuale. Logica
poate fi astfel partajată de mai mulţi utilizatori şi de mai multe aplicaţii.
Cu toate că software-ul de gestionare date care să realizeze
transformările interscheme în medii de date distribuite nu există încă în forma
de producţie, prototipuri au fost construite de către mai multe proiecte de
cercetare. Eforturile depuse în construcţia schemelor conceptuale pasive
astăzi vor fi răsplătite atât pe distanţă scurtă cât şi pe distanţă lungă prin
planificarea şi implementarea înbunătăţită a sistemelor informatice.

40
Schema externă

Fig.3.5. Paşii în controlul schemei conceptuale.

41
 3.6.
Schema internă Schema conceptuală

suportă direct descrie pasiv

Schema externă Schema internă

Schema internă

suportă direct

Schema conceptuală Schema externă

descrie descrie
pasiv pasiv

Planificarea
pentru un mediu
baze de date
suportă

direct

Probabilitatea de a implementa cu succes un mediu baze de date poate fi

mărită dacăSchema conceptuală
se urmează sugestiile:
1. este
Recunoaşte că un DBMS reprezintă un instrument pentru gestionarea
este implementată
resursei de
accesată de date şi nu o metodă extravagantă de acces la fişiere.
prin

42

Schema externă Schema internă

2. Formează un comitet adecvat de gestionare a resurselor.
3. Păstrează domeniul fiecărui proiect de implementare rezonabil şi
reliazabil. Rezultatele vor fi disponibile în şase luni.
4. Planifică procesul de dezvoltare şi stabileşte puncte de revizie.
5. Fazează implementarea (şi evoluţia schemei conceptuale) în incremente
realiste de atins cu un plan de fazare conservator.
6. Deplasează responsabilităţile spre experţi şi fii sigur că utilizatorii îşi
definesc cerinţele lor şi validează posibilităţile sistemului.
7. Antrenează o echipă tehnică în tehnologia bazelor de date, devreme şi
continuu.
8. Stabileşte o funcţie de administrare date.
9. Când ester potrivit, foloseşte prototipuri pentru a defini cerinţe.
10. Cere şi acceptă ajutor de la un distribuitor de baze de date.
11. Fereşte-te de încurcături, inclusiv de supradependenţa de distribuitorul
DBMS.
Planificarea pentru un mediu baze de date înseamnă înţelegerea
abordării bazate pe date în gestionarea datelor. O bază de date trebuie
proiectată pentru generalitate, flexibilitate şi extensibilitate. După ce baza de
date a fost proiectată, programele orientate pe aplicaţii şi tranzacţii care
depind de acea bază de date pot fi specificate. Mai important pentru succesul
pe termen lung al proiectului este neutralitatea şi calitatea proiectării bazei de
date logice decât programarea. Planificarea pentru un mediu baze de date
înseamnă deasemenea recunoaşterea faptului că un DBMS este un instrument
pentrz acel mediu şi nu un obiectiv.

Memento

ANSI/X3/SPARC Vedere logică Prototip

Schemă conceptuală Schemă externă Mapare
Bazat pe date (data-driven) Schemă internă Metadată
Vedere intreprindere Vedere fizică Schema

Bibliografie

1. Appleton, D.S. Data driven prototyping, Datamation, Nov. 1959, pp. 259-
268
2. Tsichritzis, D.; Klug, A. The ANSI/X3/SPARC DBMS framework report of
the study group on database management systems, Info Systems, 1978

43