Proiectarea bazei de date. Dezvoltarea bazei de date a bibliotecii

1. PROIECTAREA BAZEI DE DATE

1.1. Baza de date relațională și structura acesteia

O bază de date (DB) este o colecție de informații despre obiecte, procese, evenimente sau fenomene legate de un anumit domeniu, subiect sau sarcină, organizate în conformitate cu anumite reguli și păstrate în memoria computerului. Este organizat astfel încât să asigure nevoile de informare ale utilizatorilor, precum și stocarea convenabilă a acestei colecții de date, atât în ​​ansamblu, cât și în orice parte a acesteia.

Baza de date relațională este un set de tabele interconectate, fiecare dintre ele conținând informații despre obiecte de un anumit tip. Fiecare rând al tabelului conține date despre un obiect (de exemplu, o mașină, un computer, un client), iar coloanele tabelului conțin diferite caracteristici ale acestor obiecte - atribute (de exemplu, numărul motorului, marca procesorului, numerele de telefon). a companiilor sau clientilor).

Rândurile dintr-un tabel se numesc înregistrări. Toate înregistrările de tabel au aceeași structură - sunt formate din câmpuri (elementele de date) în care sunt stocate atributele obiectului (Fig. 1). Fiecare câmp de înregistrare conține o caracteristică a obiectului și reprezintă un tip de date specificat (de exemplu, șir de text, număr, dată). O cheie primară este folosită pentru a identifica înregistrările. Cheia principala este un set de câmpuri de tabel a căror combinație de valori identifică în mod unic fiecare înregistrare din tabel.

Orez. 1. Numele obiectelor din tabel

Sistemele de management al bazelor de date (DBMS) sunt folosite pentru a lucra cu date. Principalele funcții ale SGBD:

– definirea datelor (descrierea structurii bazei de date);

– procesarea datelor;

– Management de date.

Dezvoltarea structurii bazei de date este cea mai importantă sarcină rezolvată la proiectarea unei baze de date. Structura unei baze de date (setul, forma și relațiile tabelelor sale) este una dintre principalele decizii de proiectare atunci când se creează aplicații folosind o bază de date. Structura bazei de date creată de dezvoltator este descrisă în limbajul de definire a datelor DBMS.

Orice SGBD vă permite să efectuați următoarele operațiuni cu date:

– adăugarea înregistrărilor la tabele;

– ștergerea înregistrărilor din tabel;

– actualizarea valorilor unor câmpuri dintr-una sau mai multe înregistrări din tabelele bazei de date;

– caută una sau mai multe înregistrări care satisfac o anumită condiție.

Pentru a efectua aceste operații, se folosește un mecanism de interogare. Rezultatul executării interogărilor este fie un set de înregistrări selectate după anumite criterii, fie modificări în tabele. Interogările către baza de date sunt formate într-un limbaj special creat în acest scop, care se numește

„limbaj de interogare structurat” (SQL – Structured Query Language).

Guvernanța datelor se referă de obicei la protejarea datelor împotriva accesului neautorizat, la sprijinirea procesării datelor cu mai mulți utilizatori și la asigurarea integrității și consecvenței datelor.

1.2. Etapele proiectării unei baze de date relaționale

Principalul motiv pentru care proiectarea bazei de date este dificilă este că obiectele din lumea reală și relațiile dintre ele nu trebuie să aibă și, în general, nu au o structură compatibilă cu modelul de date relaționale. La proiectare, dezvoltatorul trebuie să vină cu o reprezentare pentru obiectele reale și relațiile acestora în termeni de tabele, câmpuri, atribute, înregistrări etc., adică în termeni de abstracții ale modelului de date relaționale. Prin urmare, în acest context, termenul „design” poate fi înțeles atât ca proces, al cărui rezultat este un proiect, cât și ca proces, al cărui rezultat este o proiecție.

Dezvoltarea unei baze de date eficiente implică mai mulți pași. Procesul de dezvoltare a bazei de date începe cu analiza cerințelor. Proiectantul în această etapă de dezvoltare trebuie să găsească răspunsuri la următoarele întrebări: ce elemente de date ar trebui stocate, cine le va accesa și cum.

În a doua etapă, se creează structura logică a bazei de date. Pentru a face acest lucru, determinați cum vor fi grupate datele în mod logic. Structura bazei de date în această etapă este exprimată în termeni de obiecte de aplicație și relații dintre acestea.

În etapa finală (a treia), structura logică a bazei de date este convertită într-una fizică, ținând cont de aspectele de performanță. Elementele de date în această etapă primesc atribute și sunt definite ca coloane în tabelele SGBD selectate pentru implementarea bazei de date.

Să luăm în considerare aplicarea în practică a conceptului de baze de date relaționale. Să ne imaginăm activitățile unei companii de turism. Evident, pentru funcționarea acestuia este necesară stocarea și urmărirea unui anumit set de informații despre clienții unei anumite agenții de turism (turiști), despre tururile oferite acestora, despre înregistrarea și plata voucherelor. Acest lucru se poate face într-un caiet obișnuit de hârtie, dar, în timp, căutarea înregistrărilor și a raportărilor financiare necesare va fi o muncă destul de rutină și consumatoare de timp.

1.2.1. Definirea cerințelor

Cerințele pentru o aplicație de bază de date sunt de obicei dezvoltate prin sondaje și conversații cu utilizatorii finali. Acesta este un proces iterativ în timpul căruia dezvoltatorii determină structura dialogurilor utilizatorilor, criteriile de căutare a documentelor și posibilele reacții ale utilizatorilor.

O tehnică generală pentru definirea și documentarea cerințelor bazei de date este compilarea unui dicționar de date. Dicționarul de date listează și definește elementele de date individuale care trebuie stocate în baza de date. O schiță inițială a unui dicționar de date pentru un manager de agenție de turism este prezentată în Tabelul 1.

tabelul 1

Dicționar de date pentru aplicația de bază de date a managerului agenției de turism

Element de date	Descriere
	Numele de familie al turistului
	Nume turistic
Nume de familie	Patronimul turistului
	Seria și numărul pașapoartelor turistice
	Număr de telefon de contact turistic
	Orașul de reședință al turistului
	Țara de reședință a turistului
	Cod poștal adresa turistică
	Numele călătoriei
	Prețul unei călătorii turistice
data de început	Ora începerii călătoriei turistice
Data de încheiere	Ora de încheiere a călătoriei turistice
informație	Informații suplimentare despre tur
data plății	Data plății pentru călătorie
	Suma de plată

Compilarea unui dicționar este o modalitate bună de a începe să definiți cerințele bazei de date. Dar un dicționar nu este suficient pentru a defini structura bazei de date, deoarece dicționarul de date nu descrie cum sunt legate elementele, cum sunt create, actualizate și selectate datele, cine va folosi baza de date și cum.

Necesar specificații funcționale, reflectând informații despre numărul de utilizatori concurenți, cât de des vor fi inserate și actualizate înregistrările și cum vor fi preluate informațiile din baza de date.

Descrierea funcțională pentru o aplicație de bază de date a managerilor de agenție de turism ar putea include, de exemplu, următoarele cerințe:

Aplicația va fi folosită de șeful agenției de turism, 2 directori de vânzări, un contabil, un casier și 2 angajați de birou ai agenției de turism - în total 7 utilizatori. Se presupune că nu mai mult de 3 angajați vor lucra simultan cu baza de date. Pentru a lucra, personalul contabil trebuie doar să aibă acces la datele de plată de călătorie.

Toți utilizatorii pot adăuga informații în baza de date în orice moment. Când informațiile sunt adăugate sau modificate, utilizatorul care a făcut modificarea și data și ora modificării trebuie înregistrate.

Unul dintre angajații biroului va fi numit administrator de sistem. Numai el ar trebui să mențină conturile de utilizator.

Specificația funcției și dicționarul de date sunt de obicei dezvoltate simultan, deoarece aceste documente se completează reciproc informațional.

O parte importantă a analizei cerințelor este de a anticipa nevoile utilizatorilor, deoarece aceștia nu sunt întotdeauna capabili să explice complet și clar propriile cerințe pentru sistem. În practică, o descriere funcțională ar trebui să prezinte sistemul cât mai complet și detaliat posibil.

1.2.2. Model logic

Diagramele ER

O modalitate obișnuită de a reprezenta un model de bază de date logică este de a construi diagrame ER (Entity-Relationship). În acest model, o entitate este definită ca un obiect discret pentru care sunt stocate elemente de date, iar o relație descrie relația dintre două obiecte.

ÎN În exemplul unui manager de agenție de turism, există 5 obiecte principale:

Turiştii

Tururi

Bonuri

anotimpuri

Plăți

Relațiile dintre aceste obiecte pot fi definite în termeni simpli:

Fiecare turist poate cumpăra unul sau mai multe (mai multe) vouchere.

Fiecărui voucher îi corespunde plata (plata

poate mai multe
dacă voucherul, de exemplu,
vândut pe credit).
Fiecare tur poate avea
mai multe sezoane.

Pachet de călătorie	de vânzare
un sezon dintr-un turneu.
Aceste obiecte și relații
poate fi reprezentat prin ER-
diagramă,	așa cum se arată		Orez. 2. Diagrama ER pentru aplicația DB
				manager de agentie de turism

Obiecte, atribute și chei

Modelul este dezvoltat în continuare prin definirea atributelor pentru fiecare obiect. Atributele obiectului sunt elemente de date legate de un anumit obiect care trebuie stocat. Analizăm dicționarul de date compilat, selectăm obiectele și atributele acestora în el și extindem dicționarul dacă este necesar. Atributele fiecărui obiect din exemplu sunt prezentate în Tabelul 2.

		Obiecte și atribute baze de date			masa 2
			Nume	data de început	data plății
				Data de încheiere
	Nume de familie		informație
Atribute

Vă rugăm să rețineți că lipsesc mai multe articole. Informațiile de înregistrare menționate în specificația funcțională au fost omise. Cum să ții cont, vei gândi singur și vei finaliza exemplul propus. Dar, mai important, atributele necesare pentru a conecta obiecte unele la altele încă lipsesc. Aceste elemente de date nu sunt reprezentate în modelul ER.

nu sunt, de fapt, atribute „naturale” ale obiectelor. Ele sunt prelucrate diferit și vor fi luate în considerare în modelul de date relaționale.

Modelul relațional se caracterizează prin utilizarea cheilor și a relațiilor. Există o diferență în contextul unei baze de date relaționale între termenii relație și relație. O relație este tratată ca un tabel bidimensional neordonat, cu rânduri neînrudite. Schema de date este formată între relații (tabele) prin atribute comune, care sunt chei.

Există mai multe tipuri de chei și, uneori, diferă doar în ceea ce privește relația lor cu alte atribute și relații. O cheie primară identifică în mod unic un rând dintr-o relație (tabel) și fiecare relație poate avea o singură cheie primară, chiar dacă mai multe atribute sunt unice. În unele cazuri, este necesar mai mult de un atribut pentru a identifica rândurile dintr-o relație. Setul acestor atribute este numit cheie compusă. În alte cazuri, cheia primară trebuie creată (generată) special. De exemplu, în relația „Turiști”, este logic să adăugați un identificator turistic unic (cod turistic) ca cheie primară a acestei relații pentru a organiza conexiuni cu alte relații de bază de date.

Un alt tip de cheie, numită cheie străină, există doar în ceea ce privește schema de date dintre două relații. O cheie externă într-o relație este un atribut care este cheia primară (sau o parte a unei chei primare) într-o altă relație. Acesta este un atribut distribuit care formează o schemă de date între două relații din baza de date.

Pentru baza de date proiectată, vom extinde atributele obiectului cu câmpuri de cod ca chei primare și vom folosi aceste coduri în relațiile cu bazele de date pentru a face referire la obiectele bazei de date, după cum urmează (Tabelul 3).

Este prea devreme să se considere finalizată schema bazei de date construită, deoarece este necesară normalizarea acesteia. Un proces cunoscut sub numele de normalizarea bazei de date relaționale este utilizat pentru a grupa atributele în moduri speciale pentru a minimiza redundanța și dependența funcțională.

	Obiecte și atribute DB cu câmpuri de cod extinse							Tabelul 3
		Cod turistic	Cod de călătorie			Cod de sezon		Cod de plată
			Cod turistic		Nume	data de început		data plății
Atribute			Cod de sezon			Data de încheiere
		Nume de familie			informație			Cod de călătorie

Normalizare

Dependențe funcționale apar atunci când valoarea unui atribut poate fi determinată din valoarea altui atribut. Un atribut care poate fi definit este numit dependente funcțional din atributul care este determinantul. Prin urmare, prin definiție, toate atributele non-cheie (fără o cheie) vor depinde funcțional de cheia primară în fiecare relație (deoarece cheia primară identifică în mod unic fiecare rând). Când un atribut al unei relații nu definește în mod unic un alt atribut, ci îl restricționează la un set de valori predefinite, se numește dependență cu mai multe valori O dependență parțială apare atunci când un atribut de relație este dependent funcțional de un atribut al unei chei compuse. Dependențe tranzitive sunt observate atunci când un atribut non-cheie este dependent funcțional de unul sau mai multe alte atribute non-cheie dintr-o relație.

Procesul de normalizare constă în construirea pas cu pas a unei baze de date în formă normală (NF).

Prima formă normală (1NF) este foarte simplă. Toate tabelele bazei de date trebuie să îndeplinească o singură cerință - fiecare celulă din tabele trebuie să conțină o valoare atomică, cu alte cuvinte, valoarea stocată în domeniul aplicației bazei de date nu trebuie să aibă o structură internă, ale cărei elemente pot fi solicitate de către aplicarea.

A doua formă normală (2NF) este creată atunci când toate dependențele parțiale sunt eliminate din relațiile de bază de date. Dacă nu există chei compuse în relație, atunci acest nivel de normalizare este ușor de atins.

A treia formă normală (3NF) a bazei de date necesită eliminarea tuturor dependențelor tranzitive.

A patra formă normală (4NF) este creată atunci când toate dependențele cu mai multe valori sunt eliminate.

Baza de date din exemplul nostru este în 1NF, deoarece toate câmpurile tabelelor bazei de date au conținut atomic. Baza noastră de date este și în 2NF, întrucât am introdus artificial în fiecare tabel coduri unice pentru fiecare obiect (Cod Turistic, Cod de călătorie etc.), datorită cărora am obținut 2NF pentru fiecare dintre tabelele bazei de date și întreaga bază de date în general. Rămâne să ne ocupăm de a treia și a patra formă normală.

Rețineți că acestea există doar în raport cu diferite tipuri de dependențe ale atributelor bazei de date. Există dependențe - trebuie să costați baza de date NF, nu există dependențe - baza de date este deja în NF. Dar această din urmă opțiune nu se găsește practic niciodată în aplicațiile reale.

Deci, ce dependențe tranzitive și multivalorice sunt prezente în exemplul nostru de bază de date a managerilor de agenții de turism?

Să analizăm atitudinea „Turiștilor”. Să luăm în considerare dependențele dintre atributele „Cod turistic”, „Nume”, „Prenumele”, „Patronimic” și „Pașaport” (Fig. 3). Fiecare turist, reprezentat prin combinația „Nume - Prenume - Patronimic”, are un singur pașaport pe durata călătoriei, în timp ce omonimii trebuie să aibă numere diferite de pașaport. Prin urmare, atributele „Nume - Prenume - Patronimic” și „Pașaport” formează o cheie compusă pentru turiști.

Cheie compusă

					Nume de familie
		Cod turistic

Orez. 3. Exemplu de dependență tranzitivă

După cum se poate observa din figură, atributul „Pașaport” depinde în mod tranzitiv de cheia „Cod turistic”. Prin urmare, pentru a elimina această dependență tranzitivă, împărțim cheia compusă a relației și relația însăși în 2 conform relațiilor unu-la-unu. Prima relație, să o lăsăm cu numele „Turiști”, include atributele „Cod turistic” și „Nume”, „Prenume”, „Patronimic”. A doua relație, să o numim „Informații despre turiști”, este formată din atributele „Codul turistic” și toate atributele rămase ale relației „Turiști”: „Pașaport”, „Telefon”, „Oraș”, „Țară”, "Index". Aceste două noi relații nu mai au dependență tranzitivă și sunt în 3NF.

Nu există dependențe cu mai multe valori în baza noastră de date simplificată. De exemplu, să presupunem că pentru fiecare turist ar trebui stocate mai multe numere de contact (acasă, serviciu, telefon mobil etc., ceea ce este foarte tipic în practică), și nu doar unul, ca în exemplu. Obținem o dependență cu mai multe valori a cheii - „Cod turistic” și atributele „Tip de telefon” și „Telefon” în această situație, cheia încetează să mai fie o cheie. Ce să fac? Problema este rezolvată și prin împărțirea schemei de relații în 2 scheme noi. Unul dintre ele ar trebui să reprezinte informații despre telefoane (relația „Telefoane”), iar al doilea despre turiști (relația „Turiști”), care sunt contactați folosind câmpul „Cod Turistic”. „Cod turistic” în raport cu „Turiști” va fi cheia principală, iar în raport cu „Telefoane” va fi cheia externă.

1.2.3. Modelul fizic

Modelul fizic de date depinde de SGBD selectat. De exemplu, dacă intenționați să utilizați un SGBD Oracle, atunci baza de date fizică va consta din fișiere de date, zone de tabel, segmente de rollback, tabele, coloane

și indici.

ÎN Acest tutorial va acoperi crearea unui model fizic de bază de date folosind Microsoft Access DBMS și serverul de baze de date Microsoft SQL Server 2005 Express Edition.

1.3. Crearea unei baze de date în Microsoft Access DBMS

1.3.1. Mese

Pentru a crea un tabel în DBMS Microsoft Access, folosim modul de proiectare (Fig. 4).

Orez. 4. Selectarea modului de proiectare

Orez. 5. Lista completă a câmpurilor din tabel

În fereastra „Table1: table” care apare, trebuie să definiți numele câmpurilor, care vor deveni titlurile din acest tabel. Să introducem următoarele nume de câmpuri (Fig. 5).

		Când introduceți un nume de câmp, pentru acesta
		este determinat tipul implicit de date
		"text". Pentru a schimba tipul:
		Nu este posibil să selectați valoarea dorită din meniul derulant
		dând lista (Fig. 6).
Orez. 6. Definirea tipului de date de câmp		Descrieri ale posibilelor tipuri de date
		Datele Microsoft Access sunt date în tabel.
		Tabelul 4
	Tipuri de date Microsoft Access
Tip de date	Descriere
Text	Text sau o combinație de text și numere, cum ar fi o adresă și
	numere care nu necesită calcule, de exemplu, numere de telefon,
	numere de inventar sau coduri poștale. Stochează până la 255 de caractere.
	Proprietatea „FieldSize” determină numărul maxim de
	Numărul de caractere care pot fi introduse în câmp
Câmp MEMO	Conceput pentru introducerea de informații text, volumul depășește
	255 de caractere. Un astfel de câmp poate conține până la 65.535 de caractere
	boi Acest tip de date diferă de tipul de text prin aceea că
	stând separat. Datorită acestui fapt, procesarea tabelelor (sortarea) este accelerată
	săpat, căutare etc.). Un câmp de tip MEMO nu poate fi o cheie sau
	indexate
Numeric	Date utilizate pentru calcule matematice, cu excepția
	financiar	calcule (pentru ele ar trebui să utilizați tipul
	"Monetar"). Stochează 1, 2, 4 sau 8 octeți. Tip specific de chi-
	câmpul cuvânt este determinat de valoarea proprietății Dimensiune câmp
Data Ora	Valori date și ore. Stochează 8 octeți
Monetar	Folosit pentru valori monetare și pentru a preveni rotunjirea
	leniya în timpul calculelor. Stochează 8 octeți
	Inserarea automată a secvenţialului unic (mărit
	1) sau numere aleatorii atunci când adăugați o înregistrare. co-
	stochează 4 octeți
Logic	Date care iau doar una dintre cele două valori posibile
	cum ar fi Da/Nu, Adevărat/Fals, Activat/Dezactivat. Valorile nule nu sunt
	sunt permise. Stochează 1 bit.
Câmp obiect	Obiecte OLE (cum ar fi documente Microsoft Word, electronice
	Foi de calcul Microsoft Excel, desene, înregistrări audio sau alte date în
	format binar) (limitat de spațiul pe disc)

Îmi este greu să dau sfaturi pentru că nu știu exact cum au făcut-o alții. Dar dacă proiectul tău vizează autoeducația, atunci cred că ar trebui mai întâi să exersezi cu adevărat pe o bază de date relațională clasică și abia apoi să treci la câteva opțiuni mai exotice. Trebuie să treci de la simplu la complex și numai atunci când simplul nu mai este suficient. În general, o bază de date relațională cu structura sa rigidă și restricțiile stricte pe care le stabiliți sunt prietenii dvs., deoarece încearcă să vă salveze datele de la distrugere.

În ceea ce privește afișarea diferitelor tipuri de produse în tabele diferite. Această decizie are atât părți bune, cât și părți rele. Principalul lucru bun este că puteți crea complet fiecare astfel de tabel, ținând cont de toate specificul fiecărui tip de produs. Dar partea proastă este că în acest caz va trebui să aveți grijă ca fiecare astfel de tabel să fie procesat separat. Pentru că dacă tabelele sunt diferite în design, atunci metodele de procesare ar trebui să fie diferite.

Poate că soluția optimă ar fi să te gândești cu atenție la ce parametri de produs vei avea nevoie pentru căutare și să le faci coloane indexabile separate ale tabelului general al produselor. Pentru unele tipuri de produse, aceste câmpuri ar fi goale. Și alți parametri care descriu pur și simplu produsul, dar nu sunt destinați căutării, puteți combina și stoca în acest formular într-o singură coloană. Și despachetați după cum este necesar, atunci când acestea trebuie date utilizatorului. Puteți pune tot felul de lucruri acolo, fără să vă faceți griji că aceste lucruri s-ar putea schimba pentru un anumit produs. Principalul lucru este să îl stocați sub formă de perechi de valori pentru a ști ce este - ați vrut să adăugați la descrierea produsului că crocodilii sunt gri-maronii și nu violet, ca toți ceilalți - asta este ceea ce aveți scrie - Crocodili => gri-brun.

Pe de altă parte, nu știți întotdeauna ce categorie de produse doriți să adăugați în continuare. Dar denaturarea și umflarea și „descărcarea” tabelului general de mărfuri nu este o idee foarte bună. Din acest punct de vedere al generalității, ideea ta de mese diferite pentru diferite produse poate fi foarte bună. La urma urmei, după ce a dezvoltat însăși baza - după ce ați elaborat diverse procesări pentru diverse tabele de produse, atunci când adăugați un nou tip de produs, trebuie doar să creați un tabel și să îi oferiți un handler care este potrivit pentru acesta. Nu trebuie să vă faceți griji cu privire la modul în care funcționează celelalte mese.

Ei bine, de exemplu, selectăm categoria de produse laptop-uri și căutăm în funcție de parametri care sunt tipici doar pentru laptopuri.

Lectura

Proiectarea bazei de date.

Modele de arhitectură pe mai multe niveluri a sistemelor de baze de date. Proiectare instrumente de automatizare

1. Modele de arhitectură multi-nivel a sistemelor de baze de date

În domeniul proiectării și dezvoltării sistemelor de baze de date, sunt utilizate diverse instrumente de modelare și chiar și în cadrul unui sistem specific este necesară o întreagă gamă de modele în scopuri diferite.

Raportul ANSI/X3/SPARC, publicat în 1975, a documentat nu numai acceptarea pe scară largă a conceptelor arhitecturii sistemelor de baze de date cu mai multe niveluri, ci și nevoia de a identifica în mod explicit un conceptual nivel de prezentare a bazei de date, uniform pentru toate aplicațiile sale și independent de acestea. Pe lângă acest nivel, au fost prevăzute încă două niveluri: un nivel intern, care ar trebui să ofere suport pentru vizualizarea bazei de date stocate, și un nivel extern, care să susțină vederi ale bazei de date „din punctul de vedere” al aplicațiilor. La fiecare nivel arhitectural s-a presupus utilizarea unuia sau altuia model de date. În plus, la nivel extern (aplicație, utilizator) pot exista mai multe astfel de modele. Modelele, precum și schemele specificate pe baza lor, se numesc, respectiv, externe, conceptuale și interne.

După cum este evident, scopul final al designului este acela de a construi o bază de date specifică care, într-o măsură sau alta, întruchipează ideea proiectantului despre domeniul subiectului și sarcinile rezolvate de utilizatori folosind baza de date creată. Considerând baza de date ca implementarea specifică a modelului, stabilim in esenta ordinea procesului prin separarea etapei de determinare a principiilor (ce baza trebuie sa fi) din etapa de implementare a acestor principii la implementarea unei baze de date într-un mediu SGBD specific, SO și limbaje de programare. Și, după cum arată practica, există întotdeauna discrepanțe între implementările bazelor de date și principiile construcției lor. Diferențele sunt o consecință a diverselor motive, dar cel mai adesea este o respingere explicită sau implicită a unor restricții fundamentale impuse, de exemplu, de modelul de date sau de algoritmii de procesare de bază (încorporați), în favoarea unei anumite soluții care, în opinia designerului, va fi mai eficient, de exemplu, să înțeleagă sau să proceseze datele.

Importanța separării designului la nivel abstract de implementarea fizică este că prin declararea principiilor, noi constructiv limităm domeniul de aplicare. În primul rând, dimensiunea și complexitatea problemei trebuie să fie redus la un asemenea nivel încât implementarea devine posibilă în anumite condiții specifice - resurse de mediu, profesionalismul proiectantului, pregătirea utilizatorului etc. În al doilea rând, deoarece o bază de date, prin definiție, este destinată multifuncțional utilizare variat utilizatori și, în același timp - la cererile de servicii, neprevăzut La proiectare, o astfel de declarație explicită de principii va face posibilă să nu inducă în eroare utilizatorul și să nu creeze aplicații pentru rezolvarea problemelor care, datorită diferențelor lor fundamentale față de cele luate în considerare la proiectare, vor duce la o prelucrare ineficientă a datelor. În al treilea rând, designul este un proces de un fel de coordonare a punctelor de vedere a două subiecte principale: utilizatorul și proiectantul bazei de date. Utilizatorul se caracterizează prin cerințe pentru un grad ridicat de generalitate și amploare a prezentării (și nu greoaiele descrierilor detaliate), permițându-i să obțină suficiente informații fără a cheltui timp sau resurse intelectuale semnificative. Pentru un administrator care proiectează și optimizează un sistem de baze de date, este necesar un grad ridicat de detaliere și formalizare pentru a asigura valabilitatea soluțiilor tehnice, precum și capacitatea de a automatiza proiectarea.

7.2. Tipologia modelelor

Principalele diferențe dintre orice metodă de prezentare a informațiilor constă în modul în care este surprinsă semantica domeniului subiectului. Dar, trebuie remarcat mai ales că pentru toate nivelurile și pentru orice metodă de reprezentare a domeniului subiectului (dar pentru noi este important ca în contextul creării și utilizării bazelor de date de mașini) baza afișajului (adică formarea efectivă a reprezentării) este codificare concepte și relații dintre concepte. Este ilustrat sistemul multi-nivel de modele de reprezentare a informațiilor diapozitive 2, 3, 4 (Tipologia modelelor) .

O etapă cheie în dezvoltarea oricărui sistem informațional este efectuarea unei analize de sistem: formalizarea domeniului subiectului și prezentarea sistemului ca un set de componente. Analiza sistemului permite, pe de o parte, să înțelegem mai bine „ce trebuie făcut” și „cine trebuie să o facă” (analist, dezvoltator, manager, utilizator) și, pe de altă parte, să urmărească modificările din model în conformitate cu luarea în considerare în timp și actualizarea proiectului.

Descompunerea, ca bază a analizei sistemului, poate fi funcțională (construirea ierarhiilor de funcții) sau bazată pe obiecte.

Cu toate acestea, în majoritatea sistemelor, cum ar fi bazele de date, tipurile de date sunt un element mai static decât modul în care sunt procesate. Prin urmare, metodele de analiză a sistemelor, cum ar fi Diagramele fluxului de date, au primit o dezvoltare intensivă. Dezvoltarea bazelor de date relaționale, la rândul său, a stimulat dezvoltarea metodelor de construire a modelelor de date și, în special, Diagrame ER (Diagrama relației cu entitate ). Dar atât descompunerea funcțională, cât și diagramele de date oferă doar o anumită secțiune transversală a domeniului studiat, dar nu permit obținerea unei reprezentări a sistemului în ansamblu.

Diferă și metodele de afișare utilizate în etapa de construire a modelelor datalogice, reflectând metoda identificării elementelor și conexiunilor, dar, cel mai important, în contextul reprezentării lor viitoare în spațiul de memorie unidimensional al unui computer. Modelele sunt împărțite în faptice - axate pe prezentarea informațiilor bine structurate și documentare - reprezentând cel mai comun mod de a reflecta informațiile semi-structurate. Dacă în primul caz se vorbește despre modele de date relaționale, ierarhice sau de rețea, atunci în al doilea caz se vorbește despre rețele semantice și modele documentare. Deși, împărțirea în fapte și documentare în acest grup de modele este destul de condiționată. Un document ca o secvență de câmpuri poate fi reprezentat, printre altele, printr-un model relațional. Și în acest caz, alegerea unei soluții specializate este cel mai adesea determinată de cerința eficienței generale.

La proiectarea sistemelor informaționale, proprietățile obiectelor (caracteristicile lor) sunt specificate prin atribute. Valorile atributelor fac posibilă distingerea atât a obiectelor diferite (tipuri de obiecte) în domeniul subiectului, cât și a instanțele lor diferite între obiecte de același tip. Reprezentarea atributelor este modelată cel mai convenabil prin relații teoretice de mulțimi. O relație este reprezentată vizual ca un tabel, unde fiecare rând este un tuplu al relației, iar fiecare coloană (domeniu) reprezintă un set de valori de atribut. Lista numelor de atribute de relație formează schema de relație, iar colecția de scheme de relații utilizate pentru a reprezenta baza de date formează, la rândul său, schema bazei de date.

Reprezentarea schemelor bazei de date ca diagrame de relații simplifică procedura de proiectare a bazei de date. Aceasta explică crearea lui si sisteme în care proiectarea bazei de date se realizează în termeni de rel modelul de date național și lucrul cu baza de date este suportat de SGBDunul dintre tipurile descrise în acest manual.

Modelul de date trebuie, într-un fel sau altul, să ofere o bază pentru descrierea datelor și manipularea datelor, precum și să ofere un mijloc de analiză și sinteză a structurilor de date. Orice model conform construită mai mult sau mai puțin precis din punct de vedere al matematicii, ea însăși creează obiecte pentru cercetare și începe să trăiască ca ar fi în paralel cu practica.

Este dat modelul relaționalnykh folosește direct conceptul de relație ca bază pentru cartografiere. Este cel mai apropiat de așa-numitul model conceptual al mediului subiect și deseori stă la baza acestuia din urmă.

Spre deosebire de modelele graf-teoretice, în modelul relațional, conexiunile dintre relații sunt implementate implicit, pentru care sunt folosite cheile relației. De exemplu, o relație de tip ierarhic este implementată de mecanismul cheie primară/străină, când o relație subordonată trebuie să conțină un set de atribute care leagă această relație de cea principală. Un astfel de set de atribute în relația principală va fi numit o cheie primară, iar într-o relație subordonată - o cheie secundară.

Progresul în dezvoltarea limbajelor de programare, asociat în primul rând cu tiparea datelor și apariția limbajelor orientate pe obiect, a făcut posibilă abordarea analizei sistemelor complexe din punctul de vedere al reprezentărilor ierarhice - clase de obiecte cu proprietăți de încapsulare. , moștenirea și polimorfismul, ale căror diagrame reflectă nu numai datele și relațiile lor, ci și metodele de prelucrare a datelor.

În acest sens, abordarea orientată pe obiect este o metodă hibridă și permite o formalizare mai naturală a sistemului în ansamblu. Ca rezultat, acest lucru face posibilă reducerea barierei existente între analiști și dezvoltatori (designeri și programatori), creșterea fiabilității sistemului și simplificarea întreținerii, în special, integrarea cu alte sisteme.

7.3. Etape de proiectare și modelare obiecte

Proiectarea bazei de date este un proces ordonat, formalizat de creare sisteme de descrieri interdependente, acestea. astfel de modele de domeniu care conectează (repară) datele stocate în baza de date cu obiectele de domeniu descrise de aceste date. Scopul practic al unor astfel de descrieri este de a se asigura că un utilizator care practic habar nu are despre organizarea datelor în baza de date (plasarea fizică a datelor în memorie și mecanismele de căutare a acestora), atunci când aplică o interogare la baza de date, ar au posibilitatea practică de a obține informații adecvate despre starea obiectului domeniului de studiu. (Diapozitivul 5 - Etape și obiecte)

Proiectarea începe cu o analiză a domeniului subiect și identificarea cerințelor funcționale și a altor cerințe pentru sistemul proiectat. Acest proces va fi discutat mai detaliat mai jos, dar aici observăm că proiectarea este de obicei realizată de o persoană (grup de oameni) - un analist de sistem (și, în practică, mai des, un administrator de baze de date), care poate fi fie un desemnat special. angajat sau un viitor utilizator al bazei de date, destul de familiarizat cu prelucrarea datelor mașinii.

Combinând ideile individuale despre conținutul bazei de date, obținute în urma unui sondaj cu utilizatorii, și propriile idei despre datele care pot fi necesare pentru rezolvarea problemelor practice, analistul de sisteme creează mai întâi o descriere informală generalizată a bazei de date în curs de creare. Această descriere, realizată folosind limbaj natural, expresii matematice, tabele, grafice și alte instrumente care sunt înțelese de toți oamenii care lucrează la proiectarea bazelor de date, se numește model informativ.

Un astfel de model orientat spre om este aproape complet independent de parametrii fizici ai mediului de stocare a datelor, care poate fi fie memoria umană, fie un computer. Prin urmare, modelul infologic nu se schimbă până când unele schimbări în lumea reală (acea parte a acestuia care este atribuită domeniului de subiect) necesită modificări în modelul fragmentului corespunzător al descrierii, astfel încât acest model să continue să reflecte în mod adecvat subiectul. zonă.

Celelalte modele sunt orientate spre mașină. Cu ajutorul lor, SGBD permite programelor și utilizatorilor să acceseze datele stocate doar după numele lor, fără a-și face griji cu privire la locația fizică a acestor date.

Deoarece datele sunt accesate folosind un anumit SGBD, modelele trebuie să fie prezentate în limbajul de descriere a datelor din acest SGBD. O astfel de descriere, creată folosind un model de date informaționale, este numită model datalogic date.

Pentru a localiza și căuta date pe dispozitive de stocare externe, DBMS folosește model fizic date.

Arhitectura prezentată pe trei niveluri (nivel infologic, datalogic și fizic) face posibilă asigurarea independenței datelor stocate față de programele care le folosesc. Datele stocate pot fi rescrise pe alte medii sau structura fizică a acestora poate fi reorganizată, inclusiv adăugarea de câmpuri pentru aplicații noi, dar acest lucru va presupune doar o schimbare a modelului fizic și, eventual, de date al datelor. Principalul lucru este că astfel de modificări ale modelelor fizice și datalogice nu vor fi observate de utilizatorii sistemului (vor fi „transparente” pentru aceștia). În plus, independența datelor face posibilă crearea de noi aplicații pentru a rezolva noi probleme fără a le distruge pe cele existente.

Citatul de mai sus ( Slide 6) este încă relevantă, deși cartea a fost publicată acum mai bine de 20 de ani. Într-adevăr, instrumentele de proiectare evoluează constant, dar sarcinile a căror soluție utilizatorul se așteaptă să fie automatizată folosind sisteme de baze de date au devenit semnificativ mai complexe, iar pentru utilizarea eficientă a instrumentelor de formalizare și automatizare este necesar să se înțeleagă natura modelului. sistem.

Din punctul de vedere al modelării obiectelor, este necesar să se facă distincția între modelele de domenii și modelele de baze de date. Aceste modele sunt interconectate deoarece reprezintă imagini ale aceluiași original - un anumit set de obiecte din lumea reală, informații despre care intenționăm să stocăm și să procesăm folosind baza de date proiectată. Natura relațiilor (și, în consecință, diferențele) se manifestă și în procesul de proiectare a unui sistem de baze de date. Modelul domeniului este mai probabil asociat cu nivelul informal al modelării semantice, iar modelul bazei de date este asociat cu nivelul formalizat al sistemului (și în special, SGBD).

Varietatea modelelor este, de asemenea, asociată cu diferența dintre paradigmele de modelare utilizate, care determină în esență calea reprezentare relaţiile dintre obiectele de la nivel structuri de date. Din acest punct de vedere se disting modele relaționale, de rețea, ierarhice, obiectuale, obiect-relaționale, documentare și alte tipuri de modele. În consecință, schemele de baze de date descrise prin mijloacele lor diferă și ele.

7.4. Abordări de proiectare a bazelor de date

Există două abordări principale pentru proiectarea bazelor de date: DescendentăȘi ascendent (diapozitivul 7)

La ascendent abordare, munca începe de la începutnivel inferior de atribute (adică proprietăți ale entităților și relațiilor), care, pe bazaanaliza legăturilor existente între ele sunt grupate în relaţii, preconstituind tipuri de entităţi şi legături între ele. În continuare vom discuta în detaliuproces de normalizare a relațiilor, care este o opțiune de jos în susabordare generală a proiectării bazei de date. Normalizarea prevede crearea normei relații lizate bazate pe dependențe funcționale între selectate atribute.

Abordarea de jos în sus este cea mai potrivită pentru proiectarebaze de date simple cu un număr relativ mic de atribute. Cu toate acestea, utilizarea acestei abordări devine semnificativ mai complicată atunci când se proiectează baze de date cu un număr mare de atribute, printre care totul există.dependențele funcționale existente este dificilă. DeoareceModelele de date conceptuale și logice pentru baze de date complexe pot conține sute până la mii de atribute, este important să alegeți o abordare carear ajuta la simplificarea fazei de proiectare. Mai mult, în fazele inițiale Formularea cerințelor de date poate fi dificilădar instaleaza toate atributele, care trebuie incluse în modelul de date.

O strategie mai adecvată pentru proiectarea bazelor de date complexe esteutilizare în jos abordare, care predetermina prioritatea dezvoltării unui model conceptual al unui SbA. Acest model conține mai multe entități și conexiuni de nivel înalt, care sunt rafinate (detaliate și extinse) până când sunt identificate toate obiectele, atributele lor și conexiunile dintre ele, care reflectă specificul sarcinilor unui anumit SbA.

Abordarea de jos în sus este adesea, de exemplu, în cazul SbA complex, un proces foarte incomod pentru proiectant însuși. Mai mult, apare aici limitările modelului relațional, în special: (diapozitivul 8)

- modelul relațional nu oferă mijloace suficiente pentru a capta sensul datelor, adică. semantica materiei nu este fixată direct în relaţii;

- Pentru multe aplicații, este dificil să modelezi domeniul problemei pe baza tabelelor plate;

- deși întregul proces de proiectare se desfășoară pe baza luării în considerare a dependențelor, modelul relațional nu are un mijloc de reprezentare (reflectare semantică) a acestor dependențe;

- Deși procesul de proiectare începe cu identificarea unor obiecte de domeniu care sunt esențiale pentru aplicație („entități”) și identificarea relațiilor dintre aceste entități, modelul de date relaționale nu oferă niciun aparat pentru a face distincția între entități și relații.

Pe lângă aceste abordări de proiectare,alte abordări, de exemplu, abordarea „de la general la specific” sau „mixtă”.strategie de proiectare”. O abordare " De la general la specific„amintește de Nishoabordare, dar diferă de aceasta prin faptul că este mai întâi identificat un set de fundamenteorice entități cu extinderea ulterioară a gamei de entități luate în considerare, conexiuni și atribute care interacționează cu cele definite inițialentitati. ÎN strategie mixtă crescător și descendent sunt folosite mai întâimers abordări pentru a crea diferite părți ale modelului, după care totulfragmentele sunt asamblate într-un singur întreg.

Privind puțin înainte, remarcăm relația dintre două metode binecunoscute de modelare a nivelului infologic - ER -diagrame si metoda de normalizare, adesea percepute ca alternative. De fapt, normalizarea folosind metode bine formalizate asigură descompunerea relaţiilor (variabilelor) originale de dimensiune mare la cel mai mare set posibil de relaţii, dar de dimensiune inferioară. Aceste metode nu depind de caracteristicile domeniului subiectului, dar ca urmare nu ne permit să stabilim relația inițială și, în consecință, semantica datelor prelucrate. Pentru aceasta convenabil utilizați tehnici precum ER -diagrame - se caracterizează prin abordări de sus în jos a tehnologiei de design și care dau o idee „în general”, dar tocmai din acest motiv (din cauza simplității comparative) nu permit un design cu drepturi depline al bazei este, putem spune că metoda de normalizare şi ER -diagramele sunt in esenta complementare.

7.5. Modele infologice (analiza de sistem) ale domeniului de studiu

Bazele de date în sine sunt de valoare relativă. Bazele de date sunt întotdeauna cele mai importante, dar numai unul dintre componente ale unui sistem informatic. Și trebuie remarcat faptul că orice sistem informatic destinat, de exemplu, pentru gestionarea operațională a unei întreprinderi sau arhivarea și recuperarea documentelor nu este doar programe, date și comunicații, ci și oameni (clienți, utilizatori, analiști, dezvoltatori), structuri organizatorice, precum și obiective, stimulente pentru munca unei întreprinderi sau a persoanelor fizice. Și toate aceste componente trebuie să fie înțelese atât de proiectant, cât și de utilizator și, în plus, conectate într-un mod consistent într-un singur sistem.

Ideea principală a procesului unei astfel de coordonări este că trebuie să înceapă cu o analiză a celor mai importante caracteristici ale domeniului de studiu, luând în considerare cele mai importante aspecte de fond. Și ar trebui să fie efectuată nu „mental” și nu „în cuvinte”, ci pe descrieri (modele) explicit ale obiectelor din domeniul subiectului, permițând să vedem toate relațiile esențiale. Dar trebuie remarcat faptul că încercările de a utiliza notațiile obișnuite ale modelelor formale (structurale, obiectuale sau oricare altele) în această etapă duc la un nivel mai scăzut (mai detaliat și în același timp limitat) de reprezentare a domeniului subiectului decât este necesar. pentru o înțelegere generală.

În general, există două abordări pentru determinarea compoziției și structurii unui domeniu. (Diapozitivul 9 Funcțional - abordări obiect)

Funcţionalabordarea presupune că proiectarea începe cu o analiză a sarcinilor și, în consecință, a funcțiilor care asigură implementarea nevoilor de informații.

La obiectiv(subiect), nevoile de informare ale utilizatorilor (sarcinile) nu sunt strict fixate, iar atenția principală este concentrată pe identificarea obiectelor esențiale - obiecte și conexiuni, informații despre care pot fi utilizate în sarcinile aplicate ale utilizatorului.

Convenționalitatea unei astfel de diviziuni este destul de evidentă, prin urmare, în practică, se folosesc opțiuni de compromis care implică, pe măsură ce sistemul se dezvoltă, o extindere atât a compoziției obiectelor, cât și a gamei de sarcini aplicate.

Scopul analizei de sistem a domeniului subiectului ca etapă de proiectare este evidențiați domeniul de subiect Cum un sistem de obiecte și relațiile lor, hotărând cerințe funcționale și informaționale pentru prezentarea lor ulterioară sub forma unui sistem de date interconectate.

Principalul rezultat al etapei de analiză a sistemului este determinarea paradigme model informațional (infologic): cerințele pentru mijloacele de prezentare a sistemului sunt determinate pe baza unei analize a nivelului de structură a informațiilor și a naturii percepției utilizatorului asupra semanticii acesteia (exact/aproximat, clar/incert).

De exemplu, alegerea formă atributivă de reprezentare obiectele disciplinei vor conduce, în consecință, la alegerea paradigmei baze de date de fapte, A verbal- la nevoia de alegere baza de date documentara. În prezentarea următoare, vom lua în considerare procesul de proiectare și instrumentele doar pentru cazul bazelor de date faptice care utilizează modelul relațional.

Schema conceptuală rezultată a bazei de date (în ceea ce privește modelul semantic) este apoi convertită într-o schemă relațională.

7.6. Modele datalogice

Sarcina următoarei etape de proiectare a unui sistem de baze de date este de a selecta un SGBD adecvat și de a mapa specificațiile modelului de informații de domeniu în mediul său (structurile de date). Cu alte cuvinte, modelul de domeniu al sistemului în curs de dezvoltare trebuie prezentat în termenii modelului de date la nivel conceptual al SGBD-ului specific selectat. Această etapă se numește proiectare logică (sau datalogică) a bazei de date, iar rezultatul ei este o diagramă conceptuală a bazei de date, care include definirea tuturor elementelor (unităților) și a relațiilor informaționale, inclusiv definirea tipurilor, caracteristicilor și numelor.

Deși proiectarea științei datelor nu funcționează cu înregistrări fizice, ci cu concepte logice asociate cu structura bazei de date, cu toate acestea, caracteristicile prezentării datelor, regulile și limbajele pentru agregarea și manipularea datelor au o influență decisivă. Nu toate tipurile de relații, cum ar fi multe-la-mulți, pot fi reprezentate direct într-un model logic.

În plus, pot exista multe opțiuni pentru maparea modelului infologic al domeniului subiectului în modelul datalogic al bazei de date. Aici ar trebui să se țină seama de influența următorilor doi factori semnificativi legați de practicile de dezvoltare a bazelor de date.

În primul rând, conexiunile subiectului pot fi afișate în două moduri, atât declarative - într-o diagramă logică, cât și procedurale - prin elaborarea conexiunilor prin module software care procesează (legă) datele corespunzătoare stocate.

În al doilea rând, natura procesării informațiilor poate fi un factor semnificativ. De exemplu, accesul frecvent la datele prelucrate în comun implică în mod evident stocarea în comun a acestora, iar datele (în special de dimensiuni mari) care sunt accesate rar ar trebui să fie stocate separat de datele utilizate frecvent.

7.7. Modele fizice

Etapa de proiectare a bazei de date fizice include, în general:

- alegerea unei metode de organizare a bazei de date;

- dezvoltarea unei specificații de schemă internă folosind modelul său de date la nivel intern;

- descrierea mapării unei diagrame conceptuale la una internă.

Este important de reținut că, spre deosebire de SGBD-urile timpurii, multe sisteme moderne nu oferă dezvoltatorului nicio opțiune în această etapă. În realitate, problemele de proiectare a unui model fizic includ alegerea schemei de plasare a datelor (separarea în fișiere sau tip RAID -array) și definirea numărului și tipului de indici (de exemplu, grupați sau negrupați în caz MS SQL Server).

Metoda de stocare a bazei de date este determinată automat de mecanismele SGBD „în mod implicit” pe baza specificațiilor schemei conceptuale a bazei de date, iar schema internă nu este utilizată în mod explicit în astfel de sisteme.

De asemenea, trebuie remarcat faptul că schemele de baze de date externe sunt de obicei construite în timpul dezvoltării aplicației.

7.8. Proiectare instrumente de automatizare

Cunoștințele formalizate despre un domeniu pot fi prezentate în general sub formă de descrieri text: seturi de fișe de post, reguli de afaceri etc. Cu toate acestea, modul textual de reprezentare a unui model de domeniu nu este eficient. Mai informative și mai utile la dezvoltarea bazelor de date și a sistemelor informaționale sunt descrierile domeniului subiectului, realizate cu ajutorul notațiilor grafice specializate care implementează metode de reprezentare a cunoștințelor despre domeniul subiectului. Cele mai cunoscute astăzi sunt metodele de analiză structurală SADT (Tehnica de analiză și proiectare structurată). ) și notația bazată pe acesta IDEF 0, diagrame de matrice de date, tehnici de analiză orientată pe obiecte UML (Limbaj de modelare unificat). ) etc. Oricare dintre aceste modele descrie, pe de o parte, procesele care au loc în domeniul subiectului, iar pe de altă parte, datele utilizate de aceste procese.

Cel mai complet sistem de modele, pe care se bazează metodele de modelare funcțională, informațională și comportamentală a SbA, este prezentat în familia standardelor IDEF (Definiție integrată )(diapozitivul 10).

Metodologia de proiectare conceptuală, bazată pe tehnici grafice vizuale, a oferit dezvoltatorilor de sisteme informaționale metode riguroase formalizate de descriere a sistemelor informaționale și a deciziilor tehnice luate. Aceste modele reprezintă în esență un sistem de acorduri care asigură înțelegerea reciprocă între analistul de afaceri, care reprezintă realitățile domeniului subiectului, și programatorul (sau instrumentul software), care creează un model de date care să reflecte starea acestui SbA. Dacă acordurile sunt implementate exact în produse software bazate pe această metodologie, atunci așa un sistem automatizat care poate „citi” modelele dezvoltate de analist vă va permite să controlați sintaxa modelului și, în cele din urmă, să generați o schemă de date.

În urma metodologiei de proiectare conceptuală, au apărut softuri specializate și instrumente tehnologice ale unei clase speciale - instrumente CASE care implementează tehnologia de creare și întreținere IS.

Tehnologia CASE este o metodologie de proiectare IS, precum și un set de instrumente care vă permit să modelați vizual un domeniu, să analizați acest model în toate etapele dezvoltării și întreținerii SI și să dezvoltați aplicații în conformitate cu nevoile de informații ale utilizatorilor.

Instrumentele CASE, în conformitate cu orientarea lor funcțională către anumite procese din ciclul de viață IS, pot fi împărțite în următoarele grupe(diapozitivul 11 ​​– SAS.E.).

Limbile formale folosite pentru a reprezenta domeniul nu permit descrierea Toate relații pe care designerul le consideră importante. Pe de altă parte, multe proiecte (și, în special, cele aflate în considerare exemple ) sunt percepute ca fiind destul de simple, iar soluțiile de proiectare par evidente. În plus, un programator cu experiență poate oferi întotdeauna o modalitate empirică și, poate, cu adevărat eficientă de reprezentare și prelucrare țintită a informațiilor necesare. Totuși, aceasta înseamnă abandonarea unui singur formalism, care, odată cu creșterea cantității de date și conexiuni , complică semnificativ problemele de gestionare a bazelor de date și, în special, înțelegerea organizării utilizatorilor și a metodelor de acces.

Ar fi mai corect să vorbim despre asta informalitatea asociat cu imposibilitatea de justificare lipsit de ambiguitate selectarea (din viața reală) a obiectelor instrumentelor utilizate pentru modelare.

30.03.17 3351

Urmând principiile descrise în acest articol, puteți crea o bază de date care funcționează conform așteptărilor și care poate fi adaptată la noile cerințe în viitor. Ne vom uita la principiile de bază proiectarea bazei de date, precum și modalități de optimizare.

Procesul de proiectare a bazei de date

Baza de date bine structurata:

• Ajută la economisirea spațiului pe disc prin eliminarea datelor inutile;
• Menține acuratețea și integritatea datelor;
• Oferă acces convenabil la date.

Dezvoltarea bazei de date include următoarele etape:

1. Analiza cerințelor sau determinarea scopului bazei de date;
2. Organizarea datelor în tabele;
3. Specificarea cheilor primare și analiza relațiilor;
4. Normalizarea tabelelor.

Să luăm în considerare fiecare etapa de proiectare a bazei de date mai multe detalii. Vă rugăm să rețineți că acest tutorial acoperă modelul bazei de date relaționale al lui Edgar Codd, scris în SQL ( mai degrabă decât modele ierarhice, de rețea sau de obiecte).

Analiza cerințelor: determinarea scopului bazei de date

De exemplu, dacă creați o bază de date pentru o bibliotecă publică, trebuie să luați în considerare modul în care atât cititorii, cât și bibliotecarii ar trebui să acceseze baza de date.

Iată câteva modalități de a aduna informații înainte de a crea o bază de date:

• Intervievarea persoanelor care îl vor folosi;
• Analiza formularelor de afaceri precum facturi, grafice, sondaje;
• Luarea în considerare a tuturor sistemelor de date existente ( inclusiv fișiere fizice și digitale).

Începeți prin a colecta datele existente care vor fi incluse în baza de date. Apoi, determinați tipurile de date pe care doriți să le salvați. Precum și obiectele care descriu aceste date. De exemplu:

Clienții

• Abordare;
• Oras (*): Stat (*): Cod postal;
• Adresa de e-mail.

Bunuri

• Nume;
• Preț;
• Cantitate in stoc;
• Cantitate de comandat.

Comenzi

• Număr de ordine;
• Reprezentant de vânzări;
• Data de;
• Produs;
• Cantitate;
• Preț;
• Preț.

La proiectarea unei baze de date relaționale, aceste informații vor deveni ulterior parte a dicționarului de date, care descrie tabelele și câmpurile bazei de date. Împărțiți informațiile în cele mai mici părți posibile. De exemplu, luați în considerare împărțirea câmpurilor pentru adresa străzii și de stat, astfel încât să puteți filtra oamenii după statul în care locuiesc.

Odată ce ați decis ce date vor fi incluse în baza de date, de unde vor veni datele și cum vor fi utilizate, puteți începe să planificați baza de date reală.

Structura bazei de date: blocuri de construcție

Următorul pas este reprezentarea vizuală a bazei de date. Pentru a face acest lucru, trebuie să știți exact cum sunt structurate bazele de date relaționale. În cadrul unei baze de date, datele aferente sunt grupate în tabele, fiecare dintre acestea fiind format din rânduri și coloane.

Pentru a converti listele de date în tabele, începeți prin a crea un tabel pentru fiecare tip de obiect, cum ar fi produse, vânzări, clienți și comenzi. Iată un exemplu:

Fiecare rând dintr-un tabel se numește înregistrare. Înregistrările includ informații despre ceva sau cineva, cum ar fi un anumit client. Coloane (numite și câmpuri sau atribute) conțin același tip de informații care sunt afișate pentru fiecare înregistrare, de exemplu, adresele tuturor clienților enumerați în tabel.

Pentru a asigura coerența între înregistrări atunci când proiectați modelul bazei de date, atribuiți tipul de date corespunzător fiecărei coloane. Tipurile comune de date includ:

• CHAR - lungimea specifică a textului;
• VARCHAR - text de diverse lungimi;
• TEXT - cantitate mare de text;
• INT — întreg pozitiv sau negativ;
• FLOAT , DOUBLE — numere în virgulă mobilă;
• BLOB - date binare.

Unele SGBD oferă, de asemenea, un tip de date Autonumber, care generează automat un număr unic pe fiecare rând.

Într-o reprezentare vizuală a bazei de date, fiecare tabel va fi reprezentat printr-un bloc în diagramă. Antetul fiecărui bloc ar trebui să precizeze ce descriu datele din acel tabel, iar atributele ar trebui să fie enumerate mai jos:

La proiectarea unei baze de date cu informații trebuie să decideți care atribute, dacă există, vor servi ca cheie primară pentru fiecare tabel. Cheia principala ( PK) este un identificator unic pentru acest obiect. Cu acesta, puteți selecta datele unui anumit client, chiar dacă știți doar acea valoare.

Atributele alese ca chei primare trebuie să fie unice, imuabile și nu pot fi setate la NULL ( nu pot fi goale). Din acest motiv, numerele de comandă și numele de utilizator sunt chei primare potrivite, dar numerele de telefon sau adresele nu sunt. De asemenea, puteți utiliza mai multe câmpuri în același timp ca cheie primară ( aceasta se numește cheie compusă).

Când vine timpul să creați baza de date reală, implementați atât structura logică, cât și cea fizică prin limbajul de definire a datelor suportat de SGBD.

De asemenea, trebuie să evaluați dimensiunea bazei de date pentru a vă asigura că puteți obține nivelul de performanță de care aveți nevoie și că aveți suficient spațiu pentru a stoca datele.

Crearea de relații între entități

Acum că datele au fost convertite în tabele, trebuie să analizăm relațiile dintre ele. Complexitatea unei baze de date este determinată de numărul de elemente care interacționează între două tabele înrudite. Determinarea complexității vă ajută să vă împărțiți datele în tabele în cel mai eficient mod.

Fiecare obiect poate fi interconectat cu altul folosind unul dintre cele trei tipuri de relații:

Comunicare unu-la-unu

Când există o singură instanță a obiectului A pentru fiecare instanță a obiectului B, se spune că au o relație unu-la-unu ( adesea notat 1:1). Puteți indica acest tip de relație într-o diagramă ER cu o linie cu o liniuță la fiecare capăt:

Dacă nu aveți niciun motiv să separați aceste date atunci când proiectați și dezvoltați baze de date, o relație 1:1 indică de obicei că este mai bine să combinați aceste tabele într-unul singur.

Dar, în anumite circumstanțe, este mai logic să creați tabele cu relații 1:1. Dacă aveți un câmp de date opțional, cum ar fi „descriere”, care este lăsat necompletat pentru multe înregistrări, puteți muta toate descrierile într-un tabel separat, eliminând câmpurile goale și îmbunătățind performanța bazei de date.

Pentru a vă asigura că datele sunt corelate corect, va trebui să includeți cel puțin o coloană identică în fiecare tabel. Cel mai probabil aceasta va fi cheia primară.

Comunicare unu-la-mulți

Aceste relații apar atunci când o înregistrare dintr-un tabel este legată de mai multe înregistrări din altul. De exemplu, un client poate plasa multe comenzi sau un cititor poate avea mai multe cărți împrumutate de la bibliotecă. Relațiile unu-la-mai multe (1:M) sunt indicate de așa-numitul semn al piciorului de corb, ca în acest exemplu:

Pentru a implementa o relație 1:M, adăugați cheia primară din tabelul „unul” ca atribut în celălalt tabel. Dacă cheia primară este specificată în acest fel într-un alt tabel, se numește cheie străină. Tabelul de pe partea „1” a relației este tabelul părinte la tabelul copil de pe cealaltă parte.

Comunicare multi-la-multi

Când mai multe obiecte dintr-un tabel pot fi legate de mai multe obiecte ale altuia. Ei spun că au o legătură” multi-la-multi» ( M:N). De exemplu, în cazul studenților și cursurilor, deoarece un student poate urma mai multe cursuri, iar fiecare curs poate fi urmat de mulți studenți.

Într-o diagramă ER, aceste relații sunt reprezentate folosind următoarele linii:

La proiectarea unei structuri de bază de date, este imposibil să se implementeze acest tip de conexiune. În schimb, trebuie să le despărțiți în două relații unu-la-mai multe.

Pentru a face acest lucru, trebuie să creați o nouă entitate între aceste două tabele. Dacă există o relație M:N între vânzări și produse, puteți numi acest nou obiect " produse_vândute„, deoarece va conține date pentru fiecare vânzare. Atât tabelul de vânzări, cât și tabelul de produse vor avea o relație 1:M cu produse_vândute . Acest tip de obiect intermediar se numește tabel de legături, obiect asociativ sau tabel de legături în diferite modele.

Fiecare intrare din tabelul de relații va corespunde la două entități din tabelele învecinate. De exemplu, un tabel de conexiuni între studenți și cursuri ar putea arăta astfel:

Obligatoriu sau nu?

Un alt mod de a analiza conexiunile este de a lua în considerare care parte a relației trebuie să existe pentru ca cealaltă să existe. Partea opțională poate fi marcată cu un cerc pe linie. De exemplu, o țară trebuie să existe pentru a avea un reprezentant la Națiunile Unite și nu invers:

Două obiecte pot fi interdependente ( unul nu poate exista fără celălalt).

Conexiuni recursive

Uneori, atunci când proiectați o bază de date, un tabel indică spre sine. De exemplu, un tabel de angajați poate avea un atribut „manager” care se referă la o altă persoană din același tabel. Aceasta se numește linkuri recursive.

Conexiuni suplimentare

Conexiunile străine sunt cele care sunt exprimate de mai multe ori. De obicei, puteți șterge una dintre aceste relații fără a pierde informații importante. De exemplu, dacă obiectul „elevi” are o relație directă cu un alt obiect numit „profesori”, dar are și o relație indirectă cu profesorii prin „subiecte”, trebuie să eliminați relația dintre „elevi” și „profesori”. Pentru că singurul mod în care elevii sunt alocați profesori este prin discipline.

Normalizarea bazei de date

După proiectarea preliminară a bazei de date, puteți aplica reguli de normalizare pentru a vă asigura că tabelele sunt structurate corect.

În același timp, nu toate bazele de date trebuie să fie normalizate. În general, bazele de date cu procesare a tranzacțiilor în timp real ( OLTP), trebuie normalizat.

Baze de date cu procesare analitică interactivă ( OLAP), permițând o analiză mai ușoară și mai rapidă a datelor, poate fi mai eficientă cu un anumit grad de denormalizare. Criteriul principal aici este viteza de calcul. Fiecare formă sau nivel de normalizare include reguli asociate cu formele inferioare.

Prima formă de normalizare

Prima formă de normalizare ( prescurtat 1NF) precizează că în timpul proiectarea bazei de date logice Fiecare celulă dintr-un tabel poate avea o singură valoare, nu o listă de valori. Prin urmare, un tabel ca cel de mai jos nu corespunde cu 1NF:

Poate doriți să ocoliți această limitare prin împărțirea datelor în coloane suplimentare. Dar acest lucru este și împotriva regulilor: un tabel cu grupuri de atribute duplicat sau strâns legate nu respectă prima formă de normalizare. De exemplu, tabelul de mai jos nu corespunde cu 1NF:

În schimb, în ​​timpul proiectării fizice a bazei de date, împărțiți datele în mai multe tabele sau înregistrări până când fiecare celulă conține o singură valoare și nu există coloane suplimentare. Se consideră că astfel de date sunt defalcate la cea mai mică dimensiune utilizabilă. În tabelul de mai sus, puteți crea un tabel suplimentar " Detalii de vânzări”, care va potrivi anumite produse cu vânzările. „Vânzări” va avea o relație 1:M cu „ Detalii de vânzări».

A doua formă de normalizare

A doua formă de normalizare ( 2NF) prevede că fiecare dintre atribute trebuie să depindă în întregime de cheia primară. Fiecare atribut trebuie să depindă direct de întreaga cheie primară, și nu indirect printr-un alt atribut.

De exemplu, atributul „vârstă” depinde de „ziua de naștere”, care, la rândul său, depinde de „ID de student”, are o dependență funcțională parțială. Un tabel care conține aceste atribute nu se va conforma celei de-a doua forme de normalizare.

În plus, un tabel cu o cheie primară constând din mai multe câmpuri încalcă a doua formă de normalizare dacă unul sau mai multe câmpuri nu depind de fiecare parte a cheii.

Astfel, un tabel cu aceste câmpuri nu se va potrivi cu a doua formă de normalizare, deoarece atributul „nume produs” depinde de ID-ul produsului, dar nu de numărul comenzii:

• Numărul comenzii (cheia primară);
• ID-ul produsului (cheie primară);
• Numele produsului.

A treia formă de normalizare

A treia formă de normalizare ( 3NF) : Fiecare coloană fără cheie trebuie să fie independentă de orice altă coloană. Eu gras proiectarea bazelor de date relaționale modificarea unei valori într-o coloană non-cheie determină modificarea unei alte valori, acest tabel nu respectă a treia formă de normalizare.

Conform 3NF, nu puteți stoca date derivate într-un tabel, cum ar fi coloana „Taxă”, care în exemplul de mai jos depinde direct de costul total al comenzii:

La un moment dat, au fost propuse forme suplimentare de normalizare. Inclusiv forma Boyce-Codd de normalizare, formele patru până la șase și normalizarea cheii de domeniu, dar primele trei sunt cele mai comune.

Date multidimensionale

Unii utilizatori ar putea avea nevoie să acceseze mai multe vizualizări ale aceluiași tip de date, în special în bazele de date OLAP. De exemplu, ar putea dori să cunoască vânzările în funcție de client, țară și lună. În această situație, este mai bine să creați un tabel central care să poată fi referit de către tabelele client, țări și luni. De exemplu:

Reguli de integritate a datelor

De asemenea, folosind instrumente de proiectare a bazelor de date este necesară configurarea bazei de date ținând cont de capacitatea de a verifica datele pentru respectarea anumitor reguli. Multe SGBD-uri, cum ar fi Microsoft Access, aplică automat unele dintre aceste reguli.

Regula de integritate afirmă că o cheie primară nu poate fi niciodată NULL. Dacă o cheie constă din mai multe coloane, niciuna dintre ele nu poate fi NULL. În caz contrar, poate identifica în mod ambiguu intrarea.

Regula de integritate referenţială cere ca fiecare cheie externă specificată într-un tabel să fie mapată la o cheie primară din tabelul la care face referire. Dacă o cheie primară este schimbată sau ștearsă, acele modificări trebuie implementate în toate obiectele la care se face referire de acea cheie din baza de date.

Regulile de integritate a logicii de afaceri asigură că datele sunt conforme cu anumiți parametri logici. De exemplu, ora întâlnirii trebuie să fie în intervalul orar de lucru standard.

Adăugarea de indici și vizualizări

Un index este o copie sortată a uneia sau mai multor coloane cu valori în ordine crescătoare sau descrescătoare. Adăugarea unui index vă permite să găsiți mai rapid înregistrările. În loc să resorteze pentru fiecare interogare, sistemul poate accesa înregistrările în ordinea specificată de index.

Deși indexurile accelerează recuperarea datelor, pot încetini adăugarea, actualizarea și ștergerea datelor, deoarece indexul trebuie reconstruit ori de câte ori se modifică o înregistrare.

O vizualizare este o solicitare salvată de date. Vizualizările pot include date din mai multe tabele sau pot afișa o parte a unui tabel.

Proprietăți avansate

După proiectarea modelului bazei de date Vă puteți rafina baza de date utilizând proprietăți avansate, cum ar fi textul de ajutor, măștile de introducere și regulile de formatare care se aplică unei anumite scheme, vizualizari sau coloane. Avantajul acestei metode este că, deoarece aceste reguli sunt stocate în baza de date însăși, prezentarea datelor va fi consecventă în mai multe programe care accesează datele.

SQL și UML

Limbajul de modelare unificat ( UML) este un alt mod vizual de a exprima sisteme complexe create într-un limbaj orientat pe obiecte. Unele dintre conceptele menționate în acest tutorial sunt cunoscute sub diferite nume în UML. De exemplu, un obiect în UML este cunoscut ca o clasă.

UML nu este folosit atât de des în zilele noastre. În prezent, este folosit în plan academic și în comunicarea între dezvoltatorii de software și clienții lor.

Sisteme de gestionare a bazelor de date

Structura bazei de date proiectate depinde de ce SGBD utilizați. Unele dintre cele mai comune:

• Oracle DB;
• MySQL;
• Microsoft SQL Server;
• PostgreSQL;
• IBM DB2.

Un sistem adecvat de gestionare a bazei de date poate fi selectat în funcție de cost, sistemul de operare instalat, disponibilitatea diferitelor caracteristici etc.

Traducerea articolului " Structura și proiectarea bazei de date» echipa de proiect prietenoasa.

Rău Bun

Etapele de proiectare a bazei de date

Toate subtilitățile construirii unui model de informare pentru o anumită arie a activității umane urmăresc un singur scop - obținerea unei baze de date bune. Să explicăm termenul – o bază de date bună și să formulăm cerințele pe care trebuie să le îndeplinească o astfel de bază de date:

1. Baza de date trebuie să satisfacă nevoile de informare ale utilizatorilor (organizațiilor) iar ca structură și conținut să corespundă sarcinilor care se rezolvă;

2. Baza de date trebuie să furnizeze datele solicitate într-un timp acceptabil, de ex. satisface cerințele de performanță;

3. Baza de date ar trebui extinsă cu ușurință atunci când domeniul subiectului este reorganizat;

4. Baza de date ar trebui să fie ușor de schimbat atunci când mediul software și hardware se schimbă;

5. Datele corecte încărcate în baza de date trebuie să rămână corecte (datele trebuie verificate pentru corectitudine când sunt introduse).

Să luăm în considerare principalele etape de proiectare (Fig. 3.5):

Primul stagiu. Planificarea dezvoltării bazei de date. În această etapă, va fi evidențiată cea mai eficientă modalitate de implementare a etapelor ciclului de viață al sistemului.

Faza a doua. Determinarea cerințelor de sistem. Sfera și limitele aplicației bazei de date sunt determinate, iar cerințele utilizatorilor sunt colectate și analizate.

A treia etapă. Proiectarea unui model conceptual de bază de date. Procesul de creare a unei baze de date începe cu definirea unui model conceptual care reprezintă obiectele și relațiile lor fără a specifica modul în care sunt stocate fizic. Eforturile în această etapă ar trebui să vizeze structurarea datelor și identificarea relațiilor dintre acestea. Acest proces poate fi împărțit în mai multe sub-etape:

a) Clarificarea problemei. Chiar înainte de a începe lucrul la o anumită aplicație, un dezvoltator are de obicei câteva idei despre ceea ce va dezvolta. În alte cazuri, atunci când o mică bază de date personală este în curs de dezvoltare, astfel de vederi pot fi destul de complete. În alte cazuri, când se dezvoltă o bază de date personalizată mare, pot exista foarte puține astfel de vizualizări sau cel mai probabil vor fi superficiale. În mod evident, este prea devreme pentru a începe dezvoltarea imediată prin definirea tabelelor, câmpurilor și relațiilor dintre ele. Această abordare ar putea duce la o reproiectare completă a unei mari părți a aplicației. Prin urmare, ar trebui să petreceți ceva timp întocmind o listă cu toate sarcinile principale pe care această aplicație ar trebui, în principiu, să le rezolve, inclusiv pe cele care pot apărea în viitor.

Orez. 3.5. Diagrama de proiectare a bazei de date

b) Clarificarea succesiunii sarcinilor. Pentru ca aplicația să funcționeze logic și convenabil, cel mai bine este să organizați sarcinile principale în grupuri și apoi să organizați sarcinile fiecărui grup astfel încât să fie aranjate în ordinea în care sunt finalizate. Gruparea și reprezentarea grafică a secvenței în care sunt efectuate va ajuta la determinarea ordinii naturale a sarcinilor.

c) Analiza datelor. După stabilirea listei de sarcini, este necesar ca fiecare sarcină să creeze o listă detaliată a datelor necesare pentru rezolvarea acesteia. După etapa de analiză a datelor, puteți începe să dezvoltați un model conceptual, de ex. la evidențierea obiectelor, atributelor și relațiilor.

Etapa a patra. Construirea unui model logic. Construirea unui model logic începe cu alegerea unui model de date. La alegerea unui model, un rol important îl joacă simplitatea, claritatea și compararea structurii naturale a datelor cu modelul care îl reprezintă. De exemplu, dacă structura ierarhică este inerentă datelor în sine, atunci alegerea unui model ierarhic va fi de preferat. Dar adesea această alegere este determinată de succesul (sau disponibilitatea) unuia sau altuia SGBD. Adică, dezvoltatorul alege SGBD, nu modelul de date. Astfel, în această etapă modelul conceptual este tradus într-un model de date compatibil cu SGBD selectat. Este posibil ca relațiile dintre obiecte sau unele atribute ale obiectelor afișate în modelul conceptual să se dovedească ulterior a fi irealizabile de către SGBD selectat. Acest lucru va necesita o schimbare a modelului conceptual. Se numește versiunea unui model conceptual care poate fi furnizată de un anumit SGBD model logic. Procesul de definire a modelelor conceptuale și logice este uneori numit definiție a structurii de date.

Etapa a cincea. Construirea unui model fizic. Modelul fizic definește aspectul datelor, metodele de acces și tehnicile de indexare. În etapa de proiectare fizică, devenim legați de un anumit SGBD și descriem schema de date mai detaliat, indicând tipurile, dimensiunile câmpurilor și restricțiile. Pe lângă proiectarea tabelelor și a indecșilor, această etapă implică și definirea interogărilor de bază.

Când construim un model fizic, trebuie să rezolvi două probleme reciproc opuse. Primul este de a minimiza spațiul de stocare a datelor, iar al doilea este de a obține performanță maximă, integritate și securitate a datelor. De exemplu, pentru a asigura o viteză mare de căutare, este necesar să se creeze indexuri, iar numărul acestora va fi determinat de toate combinațiile posibile de câmpuri care participă la căutare; Pentru a restaura datele, trebuie să păstrați un jurnal al tuturor modificărilor și să creați copii de siguranță ale bazei de date; Pentru funcționarea eficientă a tranzacțiilor, este necesară rezervarea spațiului pe disc pentru obiecte temporare etc., ceea ce duce la o creștere (uneori semnificativă) a dimensiunii bazei de date.

A șasea etapă. Evaluarea modelului fizic. În această etapă, se efectuează evaluarea performanței. Aici puteți verifica eficiența executării interogărilor, viteza de căutare, corectitudinea și ușurința efectuării operațiunilor cu bazele de date, integritatea datelor și eficiența resurselor informatice. Dacă caracteristicile de performanță sunt nesatisfăcătoare, se poate reveni la revizuirea modelelor de date fizice și logice, la alegerea unui SGBD și a tipului de calculator.

A șaptea etapă. Implementarea bazei de date. Dacă performanța este satisfăcătoare, puteți trece la crearea aspectului aplicației, adică a unui set de tabele de bază, interogări, formulare și rapoarte. Această machetă preliminară poate fi demonstrată clientului și poate fi obținută aprobarea înainte de implementarea detaliată a aplicației.

Etapa a opta. Testare și optimizare. O etapă obligatorie este testarea și optimizarea aplicației dezvoltate.

Etapa a noua, finala. Întreținere și exploatare. Deoarece nu este posibilă identificarea și eliminarea tuturor erorilor în etapa de testare, etapa de întreținere este normală pentru bazele de date.

Există două abordări principale pentru proiectarea schemei de date: de sus în jos și de jos în sus. Cu o abordare de jos în sus, lucrul începe la nivelul inferior - nivelul atributelor definitorii, care, pe baza unei analize a relațiilor existente între ele, sunt grupate în relații reprezentând obiecte și conexiuni între ele. Procesul de normalizare a tabelelor pentru un model de date relaționale este un exemplu tipic al acestei abordări. Această abordare este potrivită pentru proiectarea bazelor de date relativ mici. Când numărul de atribute crește la câteva sute sau chiar mii, o abordare de sus în jos este o strategie de proiectare mai potrivită. Această abordare începe prin definirea mai multor entități de nivel înalt și a relațiilor dintre ele. Aceste obiecte sunt apoi detaliate la nivelul necesar. Un exemplu al acestei abordări de proiectare este utilizarea unui model entitate-relație. În practică, aceste abordări sunt de obicei combinate. În acest caz, putem vorbi despre o abordare mixtă de design.