Din când în când mă uit pe Toster.ru și uneori chiar răspund la întrebări acolo. Cel mai adesea, oamenii întreabă două lucruri - cum să devii programator și cum să proiectezi corect o schemă de bază de date. Mie personal mi se pare foarte ciudat că atât de mulți oameni pun ultima întrebare. Din anumite motive, mi s-a părut întotdeauna că acesta este un lucru atât de simplu pe care îl poate face toată lumea. Dar, din moment ce atât de mulți oameni sunt interesați, aici voi încerca să dau un răspuns destul de detaliat și în același timp scurt.

Presupun că știi SQL. Adică, nu este nevoie să explicăm ce sunt tabelele, rândurile, indecșii, cheile primare și integritatea referențială. Dacă nu este cazul, mă tem că trebuie să vă trimit la literatura de specialitate. Din fericire, sunt multe acum.

Desenarea unei diagrame

Să presupunem că doriți să proiectați o schemă de bază de date care stochează informații despre artiștii muzicali, albume și melodii. În stadiul inițial, când încă nu avem nimic, este convenabil să începem prin a desena o diagramă a schemei viitoare. Puteți începe cu o schiță cu un pix pe o foaie de hârtie sau puteți folosi imediat un editor specializat. Sunt multe acum, toate sunt aranjate într-un mod destul de asemănător. În pregătirea acestei note, am folosit DbSchema. Acesta este un program plătit, dar cred că merită banii. În plus, companiile normale plătesc de obicei costul software-ului necesar pentru job. Perioada de probă pentru DbSchema, dacă este ceva, este de două săptămâni.

Mi-a luat aproximativ zece minute să desenez următoarea diagramă:

Dacă nu ați mai lucrat niciodată cu astfel de diagrame, nu vă alarmați, totul este simplu. Dreptunghiurile sunt tabele, rândurile din dreptunghiuri sunt numele coloanelor, săgețile indică cheile străine, iar cheile indică cheile primare. Dacă doriți, puteți vedea chiar și indecși, tipuri de coloane și dacă acestea trebuie completate (null / not null), dar pentru noi acum acest lucru nu este atât de important.

Generați SQL și alimentați-l la DBMS

Este ușor de observat că această diagramă este mapată cu ușurință în cod pentru crearea unei scheme de bază de date în SQL. În DbSchema, puteți genera SQL spunând Schema → Generare Schema și Script de date. Apoi scriptul rezultat poate fi transmis în SGBD-ul pe care îl utilizați:

pisica muzica.sql | psql -hlocalhost test_database test_user

Am folosit PostgreSQL. Veți găsi informații despre cum să instalați acest DBMS în această notă.

Deci, ce m-a ghidat atunci când am proiectat circuitul?

Forme normale

Procesul de eliminare a redundanței și inconsecvenței într-o bază de date este numit normalizare. Există așa-numitele forme normale, dintre care în practică rareori cineva își amintește mai mult decât primele trei.

În linii mari, un tabel este în prima formă normală (1NF) dacă există exact o valoare la intersecția oricărui rând și a oricărei coloane din tabel. În RDBMS-urile moderne, această condiție este întotdeauna îndeplinită. Chiar dacă SGBD acceptă seturi sau matrice, exact o valoare de set sau matrice este stocată la intersecția unui rând și a unei coloane. Dar în tabel (utilizator varchar(100), număr întreg de telefon) nu poate exista o linie alex - 1234, 5678 . În 1NF pot exista doar doi termeni - alex - 1234 și alex - 5678.

A doua formă normală (2NF) înseamnă că tabelul este în prima formă normală și fiecare atribut non-cheie ireductibil depinde de valoarea cheii primare. Irreductibilitatea înseamnă următoarele. Dacă cheia primară constă dintr-un singur atribut, atunci orice dependență funcțională de aceasta este ireductibilă. Dacă cheia primară este compusă, atunci tabelul nu poate avea un atribut a cărui valoare este determinată în mod unic de valoarea unui subset de atribute ale cheii primare.

Un tabel este în a treia formă normală dacă este în 2NF și niciun atribut non-cheie nu are o dependență funcțională tranzitivă de cheia primară. De exemplu, luați în considerare tabelul (angajat varchar(100) cheie primară, departament varchar(100), departament_telefon întreg). Evident că este în 2NF. Dar numărul de telefon al departamentului este într-o dependență funcțională tranzitivă de numele angajatului, deoarece angajatul specifică în mod unic departamentul, iar departamentul specifică în mod unic numărul de telefon al departamentului. Pentru a converti un tabel în 3NF, trebuie să îl împărțiți în două tabele - angajat - departament și departament - telefon.

Este ușor de observat că normalizarea reduce redundanța bazei de date și previne introducerea de erori aleatorii. De exemplu, dacă părăsiți tabelul din ultimul exemplu din 2NF, puteți atribui din greșeală numere de telefon diferite aceluiași departament. Sau luați în considerare o companie cu cinci departamente și 1.000 de angajați. Dacă numărul de telefon al unui departament s-a schimbat, atunci pentru a-l actualiza în baza de date, în cazul 2NF, va trebui să scanați 1000 de rânduri, iar în cazul 3NF, doar cinci.

Esența proiectării bazei de date, ca orice alt proces de proiectare, este de a crea o descriere a unui nou sistem care nu a existat anterior sub această formă, care, atunci când este implementat, este capabil să funcționeze în condiții adecvate. De aici rezultă că etapele de proiectare a bazei de date trebuie să reflecte în mod consecvent și logic esența acestui proces.

Conținutul de proiectare a bazei de date și etapizare

Intenția de proiectare se bazează pe o anumită nevoie socială formulată. Această nevoie are un mediu pentru apariția ei și un public țintă de consumatori care vor folosi rezultatul designului. În consecință, procesul de proiectare a bazei de date începe cu studierea unei anumite nevoi din punctul de vedere al consumatorilor și al mediului funcțional al plasării ei vizate. Adică, prima etapă este colectarea informațiilor și definirea unui model al domeniului subiect al sistemului, precum și o privire asupra acestuia din punctul de vedere al publicului țintă. În general, pentru a determina cerințele de sistem, se determină domeniul de activitate, precum și limitele aplicațiilor de baze de date.

În continuare, designerul, care are deja anumite idei despre ceea ce trebuie să creeze, clarifică sarcinile presupus rezolvate de aplicație, creează o listă a acestora (mai ales dacă dezvoltarea proiectului este o bază de date mare și complexă), clarifică succesiunea rezolvării. probleme și efectuează analiza datelor. Un astfel de proces este și o lucrare de proiectare în etape, dar de obicei în structura de proiectare acești pași sunt absorbiți de etapa de proiectare conceptuală - etapa de identificare a obiectelor, atributelor și conexiunilor.

Crearea unui conceptual (model informațional) implică formarea preliminară a cerințelor conceptuale ale utilizatorului, inclusiv cerințe pentru aplicații care pot să nu fie implementate imediat, dar luând în considerare ceea ce va îmbunătăți funcționalitatea sistemului în viitor. Ocupându-se de reprezentări ale obiectelor de abstractizare a seturilor (fără a specifica metodele de stocare fizică) și relațiile acestora, modelul conceptual corespunde în esență modelului de domeniu. Prin urmare, în literatura de specialitate, prima etapă a proiectării bazei de date se numește proiectare infologică.

În continuare, o etapă separată (sau o completare la cea anterioară) urmează etapa de formare a cerințelor pentru mediul de operare, în care sunt evaluate cerințele pentru resurse de calcul capabile să asigure funcționarea sistemului. În consecință, cu cât volumul bazei de date proiectate este mai mare, cu atât este mai mare activitatea utilizatorului și intensitatea solicitărilor, cu atât sunt mai mari cerințele de resurse: pentru configurația computerului, pentru tipul și versiunea sistemului de operare. De exemplu, operarea cu mai mulți utilizatori a unei baze de date viitoare necesită o conexiune la rețea folosind un sistem de operare adecvat pentru multitasking.

Următorul pas este ca proiectantul să selecteze un sistem de management al bazei de date (DBMS), precum și instrumente software. După aceasta, modelul conceptual trebuie transferat la un model de date compatibil cu sistemul de management selectat. Dar, adesea, aceasta implică efectuarea de modificări și modificări ale modelului conceptual, deoarece interconexiunile dintre obiectele reflectate în modelul conceptual nu pot fi întotdeauna implementate folosind mijloacele unui SGBD dat.

Această împrejurare determină apariția etapei următoare - apariția unui model conceptual prevăzut cu mijloacele unui SGBD specific. Acest pas corespunde etapei de proiectare logică (crearea unui model logic).

În cele din urmă, etapa finală de proiectare a bazei de date este proiectarea fizică - etapa de legătură între structura logică și mediul fizic de stocare.

Astfel, principalele etape de proiectare în formă detaliată sunt prezentate în următoarele etape:

• proiectarea informatiilor,
• formarea cerinţelor pentru mediul de operare
• selectarea sistemului de control și a software-ului bazei de date,
• design logic,
• design fizic

Cele cheie vor fi discutate mai detaliat mai jos.

Design infologic

Identificarea entităților formează baza semantică a designului infologic. O entitate aici este un obiect (abstract sau concret), informații despre care vor fi acumulate în sistem. În modelul infologic al domeniului subiectului, structura și proprietățile dinamice ale domeniului subiectului sunt descrise în termeni ușor de utilizat, care nu depind de implementarea specifică a bazei de date. Dar termenii sunt luați la o scară standard. Adică, descrierea este exprimată nu prin obiecte individuale ale domeniului subiectului și relațiile lor, ci prin:

• descrierea tipurilor de obiecte,
• constrângeri de integritate asociate tipului descris,
• procese care conduc la evoluţia unui domeniu - trecerea acesteia la o altă stare.

Un model de informare poate fi creat folosind mai multe metode și abordări:

1. Abordarea funcțională se bazează pe sarcinile atribuite. Se numește funcțional deoarece este folosit dacă sunt cunoscute funcțiile și sarcinile persoanelor care își vor servi nevoile de informații cu ajutorul bazei de date proiectate.
2. Abordarea subiectului se concentrează pe informații despre informațiile care vor fi conținute în baza de date, în ciuda faptului că structura interogării poate să nu fie definită. În acest caz, cercetarea pe un domeniu se concentrează pe afișarea sa cea mai adecvată în baza de date în contextul întregii game de solicitări de informații așteptate.
3. O abordare integrată folosind metoda „entitate-relație” combină avantajele celor două anterioare. Metoda se reduce la împărțirea întregii zone a subiectului în părți locale, care sunt modelate separat și apoi recombinate într-o zonă întreagă.

Deoarece utilizarea metodei „entitate-relație” este o metodă de proiectare combinată în această etapă, de cele mai multe ori devine o prioritate.

Atunci când sunt împărțite metodic, reprezentările locale ar trebui, dacă este posibil, să includă informații care ar fi suficiente pentru a rezolva o problemă separată sau pentru a răspunde solicitărilor unui anumit grup de potențiali utilizatori. Fiecare dintre aceste zone conține aproximativ 6-7 entități și corespunde unei aplicații externe separate.

Dependența entităților se reflectă în împărțirea lor în puternice (bază, părinte) și slabe (copil). O entitate puternică (de exemplu, un cititor într-o bibliotecă) poate exista în baza de date singură, dar o entitate slabă (de exemplu, abonamentul acestui cititor) este „atașată” uneia puternice și nu există separat.

Este necesar să se separe conceptele de „instanță de entitate” (un obiect caracterizat prin valori specifice proprietăților) și conceptul de „tip de entitate” - un obiect caracterizat printr-un nume comun și o listă de proprietăți.

Pentru fiecare entitate individuală, sunt selectate atribute (un set de proprietăți), care, în funcție de criteriu, pot fi:

• identificatoare (cu o valoare unică pentru entitățile de acest tip, făcându-le potențiale chei) sau descriptive;
• cu o singură valoare sau cu mai multe valori (cu numărul adecvat de valori pentru o instanță de entitate);
• de bază (independent de alte atribute) sau derivate (calculat pe baza valorilor altor atribute);
• simplu (indivizibil monocomponent) sau compozit (combinat din mai multe componente).

După aceasta, se specifică atributul, conexiunile sunt specificate în vizualizarea locală (împărțite în opțional și obligatoriu) și vizualizările locale sunt îmbinate Dacă numărul de zone locale este de până la 4-5, acestea pot fi combinate într-un singur pas . Dacă numărul crește, îmbinarea binară a zonelor are loc în mai multe etape.

În această etapă și în alte etape intermediare, se reflectă natura iterativă a designului, care se exprimă aici prin faptul că pentru a elimina contradicțiile este necesar să revenim la etapa de modelare a reprezentărilor locale pentru clarificare și modificare (de exemplu, pentru a schimba aceleași nume de obiecte semantic diferite sau pentru a coordona atribute de integritate pe aceleași atribute în aplicații diferite).

Selectarea unui sistem de control și a unui software de bază de date

Implementarea practică a sistemului informațional depinde de alegerea sistemului de management al bazei de date. Cele mai importante criterii în procesul de selecție sunt următorii parametri:

• tipul de model de date și conformitatea acestuia cu nevoile domeniului de studiu,
• rezerva de posibilitati in cazul extinderii sistemului informatic,
• caracteristicile de performanță ale sistemului selectat,
• fiabilitatea operațională și confortul DBMS,
• instrumente destinate personalului de administrare a datelor,
• costul DBMS în sine și al software-ului suplimentar.

Erorile în alegerea unui SGBD vor provoca, aproape sigur, ulterior necesitatea ajustării modelelor conceptuale și logice.

Proiectarea bazei de date logice

Structura logică a bazei de date trebuie să corespundă modelului logic al domeniului subiectului și să țină cont de conectarea modelului de date cu SGBD-ul suportat. Prin urmare, etapa începe cu alegerea unui model de date, unde este important să se țină cont de simplitatea și claritatea acestuia.

Este de preferat atunci când structura naturală a datelor coincide cu modelul care o reprezintă. Deci, de exemplu, dacă datele sunt prezentate sub forma unei structuri ierarhice, atunci este mai bine să alegeți un model ierarhic. Cu toate acestea, în practică, o astfel de alegere este adesea determinată de sistemul de management al bazei de date, mai degrabă decât de modelul de date. Prin urmare, modelul conceptual este de fapt tradus într-un model de date care este compatibil cu sistemul de management al bazei de date selectat.

Acest lucru reflectă, de asemenea, natura designului, care permite posibilitatea (sau necesitatea) de a reveni la modelul conceptual pentru a-l schimba dacă relațiile dintre obiectele (sau atributele obiectului) reflectate acolo nu pot fi implementate folosind SGBD-ul ales.

La finalizarea etapei, trebuie generate scheme de baze de date ale ambelor niveluri de arhitectură (conceptual și extern), create în limbajul de definire a datelor suportat de SGBD selectat.

Schemele bazelor de date sunt formate folosind una dintre cele două abordări diferite:

• sau folosind o abordare de jos în sus, când munca provine de la nivelurile inferioare ale atributelor definitorii, grupate în relații reprezentând obiecte, pe baza relațiilor existente între atribute;
• sau folosind o abordare inversă, de sus în jos, utilizată atunci când numărul de atribute crește semnificativ (până la sute și mii).

A doua abordare presupune identificarea unui număr de entități de nivel înalt și a relațiilor acestora cu detalierea ulterioară la nivelul cerut, ceea ce se reflectă, de exemplu, într-un model creat pe baza metodei „entitate-relație”. Dar, în practică, ambele abordări sunt de obicei combinate.

Proiectarea bazei de date fizice

La următoarea etapă a proiectării fizice a bazei de date, structura logică este afișată sub forma unei structuri de stocare a bazei de date, adică este legată de mediul fizic de stocare în care datele vor fi plasate cât mai eficient posibil. Aici schema de date este descrisă în detaliu, indicând toate tipurile, câmpurile, dimensiunile și restricțiile. Pe lângă dezvoltarea de indecși și tabele, sunt definite interogări de bază.

Construirea unui model fizic presupune rezolvarea unor probleme în mare măsură contradictorii:

1. sarcini de minimizare a spațiului de stocare a datelor,
2. provocări pentru a atinge integritatea, securitatea și performanța maximă.

A doua sarcină intră în conflict cu prima deoarece, de exemplu:

• pentru ca tranzacțiile să funcționeze eficient, trebuie să rezervați spațiu pe disc pentru obiecte temporare,
• pentru a crește viteza de căutare, trebuie să creați indecși, al căror număr este determinat de numărul tuturor combinațiilor posibile de câmpuri implicate în căutare,
• Pentru a restabili datele, vor fi create copii de siguranță ale bazei de date și va fi păstrat un jurnal cu toate modificările.

Toate acestea măresc dimensiunea bazei de date, astfel încât proiectantul caută un echilibru rezonabil în care problemele să fie rezolvate optim prin plasarea inteligentă a datelor în spațiul de memorie, dar nu în detrimentul securității bazei de date, care include atât protecție împotriva accesului neautorizat, cât și protecție. din eșecuri.

Pentru a finaliza crearea unui model fizic, sunt evaluate caracteristicile operaționale ale acestuia (viteza de căutare, eficiența executării interogărilor și consumul de resurse, corectitudinea operațiunilor). Uneori, această etapă, precum etapele de implementare a bazei de date, testare și optimizare, precum și întreținere și exploatare, este luată în afara proiectării imediate a bazei de date.

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 de date comune includ:

• CHAR - lungimea specifică a textului;
• VARCHAR - text de diverse lungimi;
• TEXT - cantitate mare de text;
• INT este un număr î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 de 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 necesar de performanță ș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 dintr-un 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 de picior 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ă el însuși. 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 bazei de date fizice, î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ă o modificare a 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, ele 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 de rezolvat;

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, dezvoltatorul 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 rezolvării 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 datelor.

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 computerului. 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 adecvată. 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.

Proiectare baze de date

Concepte de bază despre baze de date și SGBD

Sistem informatic (IS) este un sistem construit pe baza tehnologiei informatice, conceput pentru stocarea, cautarea, prelucrarea si transmiterea unor cantitati semnificative de informatii, avand un anumit domeniu practic de aplicare.

Bază de date- Acesta este IP care este stocat electronic.

Baza de date (DB)– o colecție organizată de date destinată stocării pe termen lung în memoria externă a computerului, actualizare și utilizare constantă.

Bazele de date sunt folosite pentru a stoca și a căuta cantități mari de informații. Exemple de baze de date: caiet, dicționare, cărți de referință, enciclopedii etc.

Clasificarea bazei de date:

1. În funcție de natura informațiilor stocate:

- Factual – conțin informații succinte despre obiectele descrise, prezentate într-un format strict definit (indexuri de carduri, de exemplu: baza de date a colecției de carte a bibliotecii, baza de date a personalului instituției),

- Documentar – conțin documente (informații) de diferite tipuri: text, grafic, audio, multimedia (arhive, de exemplu: cărți de referință, dicționare, baze de date cu acte legislative din domeniul dreptului penal etc.)

2. După metoda de stocare a datelor:

- Centralizat (stocat pe un singur computer),

- Distribuit (utilizat în rețelele de calculatoare locale și globale).

3. Conform structurii de organizare a datelor:

- Relațional (tabular),

- Non-relațional.

Termenul „relațional” (din latinescul relatio – relație ) indică faptul că un astfel de model de stocare a datelor este construit pe relația dintre părțile sale constitutive. Relațional baza de date este în esență bidimensională masa. Fiecare rând al unui astfel de tabel se numește înregistrare. Coloanele tabelului se numesc câmpuri: fiecare câmp este caracterizat prin numele și tipul de date. Un câmp de bază de date este o coloană de tabel care conține valorile unei anumite proprietăți.

Proprietățile modelului de date relaționale:

Fiecare element de tabel este un element de date;

Toate câmpurile tabelului sunt omogene, adică au un singur tip;

Nu există intrări identice în tabel;

Ordinea înregistrărilor din tabel poate fi arbitrară și poate fi caracterizată prin numărul de câmpuri și tipul de date.

Ierarhic se numește bază de date în care informațiile sunt ordonate astfel: un element este considerat principal, restul sunt subordonate. ÎN ierarhicÎn baza de date, înregistrările sunt aranjate într-o anumită secvență, ca treptele unei scări, iar căutarea datelor poate fi efectuată într-o „coborâre” secvențială de la pas la pas. Acest model este caracterizat de parametri precum niveluri, noduri, conexiuni. Principiul de funcționare al modelului este astfel încât mai multe noduri de un nivel inferior sunt conectate folosind o conexiune cu un nod de un nivel superior.

Nodul este un model informativ al unui element situat la un anumit nivel de ierarhie.

Proprietățile modelului de date ierarhice:

Mai multe noduri de nivel inferior sunt conectate doar la un singur nod de nivel superior;

Un arbore ierarhic are un singur vârf (rădăcina) și nu este subordonat niciunui alt vârf;

Fiecare nod are propriul nume (identificator);

Există o singură cale de la înregistrarea rădăcină la înregistrarea de date mai privată.

Baza de date ierarhică este Directorul de foldere Windows, cu care puteți lucra lansând Explorer. Nivelul superior este ocupat de folderul Desktop. La al doilea nivel se află folderele My Computer, My Documents, Network Neighborhood și Recycle Bin, care sunt descendenți ai folderului Desktop, fiind gemeni. La rândul său, folderul My Computer este un strămoș în raport cu folderele de nivel al treilea, folderele de disc (Disc 3.5 (A:), C:, D:, E:, F:) și folderele de sistem (Imprimante, Panoul de control etc. .).

Reţea se numește bază de date în care se adaugă legături orizontale relațiilor ierarhice verticale. Orice obiect poate fi un stăpân și un sclav.

Baza de date a rețelei este de fapt World Wide Web al rețelei globale de calculatoare Internet. Hyperlinkurile leagă sute de milioane de documente împreună într-o singură bază de date de rețea distribuită.

Software-ul conceput pentru a lucra cu baze de date este numit Sistemul de gestionare a bazelor de date(DBMS). SGBD-urile sunt utilizate pentru stocarea și procesarea ordonată a unor volume mari de informații.

Sistemul de gestionare a bazelor de date(DBMS) este un sistem care oferă căutare, stocare, corectare a datelor și generare de răspunsuri la interogări. Sistemul asigură siguranța datelor, confidențialitatea, mișcarea și comunicarea cu alt software.

Principalele acțiuni pe care un utilizator le poate efectua folosind SGBD:

Crearea unei structuri de baze de date;

Completarea bazei de date cu informații;

Modificarea (editarea) structurii și conținutului bazei de date;

Căutarea informațiilor în baza de date;

sortarea datelor;

Protecția bazei de date;

Verificarea integrității bazei de date.

SGBD modern face posibilă includerea nu numai a informațiilor text și grafice, ci și a fragmentelor de sunet și chiar a clipurilor video.

Ușurința de utilizare a SGBD vă permite să creați noi baze de date fără a apela la programare, ci folosind doar funcții încorporate. DBMS asigură corectitudinea, completitudinea și consistența datelor, precum și accesul convenabil la acestea.

SGBD populare - FoxPro, Acces pentru Windows, Paradox.

Astfel, este necesar să se facă distincția între bazele de date în sine (DB) - seturi ordonate de date și sistemele de management al bazelor de date (DBMS) - programe care gestionează stocarea și prelucrarea datelor. De exemplu, aplicația Access, inclusă în suita de birou Microsoft Office, este un SGBD care permite utilizatorului să creeze și să proceseze baze de date tabelare.

Principii de proiectare a sistemelor de control baze de date rezultă din cerințele pe care trebuie să le îndeplinească o organizație de baze de date:

- Productivitate și disponibilitate. Solicitările de la utilizator de către baza de date sunt satisfăcute cu viteza necesară pentru utilizarea datelor. Utilizatorul primește rapid date ori de câte ori are nevoie.

- Costuri minime. Cost redus de stocare și utilizare a datelor, minimizând costul efectuării modificărilor.

- Simplitate și ușurință în utilizare. Utilizatorii pot afla și înțelege cu ușurință ce date sunt disponibile pentru ei. Accesul la date ar trebui să fie simplu, eliminând posibilele erori din partea utilizatorului.

- Ușor de făcut modificări. Baza de date poate crește și se poate modifica fără a perturba utilizările existente ale datelor.

- Posibilitate de cautare. Un utilizator al bazei de date poate face o varietate de interogări cu privire la datele stocate în ea. Pentru a implementa acest lucru, se folosește un așa-numit limbaj de interogare.

- Integritate. Bazele de date moderne pot conține date partajate de mulți utilizatori. Este foarte important ca în timpul lucrului elementele de date și conexiunile dintre ele să nu fie întrerupte. În plus, erorile hardware și diferitele tipuri de defecțiuni aleatorii nu ar trebui să ducă la pierderi ireversibile de date. Aceasta înseamnă că sistemul de management al datelor trebuie să conțină un mecanism de recuperare a datelor.

- Securitate și confidențialitate. Securitatea datelor înseamnă protecția datelor de accesul accidental sau intenționat la acestea de către persoane neautorizate, de modificarea (schimbarea) neautorizată a datelor sau distrugerea acestora. Confidențialitatea este definită ca dreptul persoanelor sau organizațiilor de a decide când, cum și câte informații pot fi partajate cu alte persoane sau organizații.

În continuare, folosind exemplul unuia dintre cele mai comune sisteme de gestionare a bazelor de date - Microsoft Access face parte din popularul pachet Microsoft Office - ne vom familiariza cu principalele tipuri de date, metode de creare a bazelor de date și tehnici de lucru cu bazele de date.

Proiectare baze de date

Ca orice produs software, o bază de date are propriul ciclu de viață (LCD). Componenta principală a ciclului de viață al bazei de date este crearea unei baze de date unice și a programelor necesare funcționării acesteia.

LCBD include următoarele etape principale:

1. Planificarea dezvoltării bazei de date;

2. Determinarea cerințelor de sistem;

3. Colectarea și analiza cerințelor utilizatorilor:

4. Proiectarea bazei de date:

Proiectarea conceptuală a bazei de date este crearea unui model conceptual de date, adică a unui model de informații. Un astfel de model este creat fără a se concentra pe vreun SGBD specific și model de date. Cel mai adesea, modelul conceptual al unei baze de date include: o descriere a obiectelor informaționale, sau concepte ale domeniului subiectului și conexiunile dintre acestea; descrierea constrângerilor de integritate, de ex. cerințe pentru valorile acceptabile ale datelor și relațiile dintre acestea;

Proiectarea bazei de date logice – crearea unui model de date logic; crearea unei scheme de bază de date bazată pe un model de date specific, cum ar fi un model de date relaționale. Pentru un model de date relaționale, un model logic este un set de diagrame de relații, indicând de obicei chei primare, precum și „legături” între relații, care sunt chei străine.

Transformarea unui model conceptual într-un model logic se realizează de obicei după reguli formale. Această etapă poate fi în mare măsură automatizată.

În etapa de proiectare logică, sunt luate în considerare specificul unui anumit model de date, dar este posibil să nu fie luate în considerare specificul unui anumit SGBD.

Proiectare fizică a bazei de date – crearea unei scheme de bază de date pentru un anumit SGBD, crearea unei descrieri a SGBD. Specificul unui anumit DBMS poate include restricții privind denumirea obiectelor bazei de date, restricții privind tipurile de date acceptate etc. În plus, specificul unui anumit SGBD în timpul proiectării fizice includ alegerea soluțiilor legate de mediul fizic de stocare a datelor (selectarea metodelor de gestionare a memoriei pe disc, împărțirea bazei de date în fișiere și dispozitive, metode de acces la date, dezvoltarea instrumentelor de protecție a datelor). ), crearea de indici etc.;

5. Dezvoltarea aplicației:

Proiectarea tranzacției (un grup de instrucțiuni SQL (un set de comenzi) executate ca un întreg);

Design interfață utilizator;

6. Implementare;

8. Testare;

9. Operare și întreținere:

Analiza funcțională și suport pentru versiunea originală a bazei de date;

Adaptarea, modernizarea și sprijinirea opțiunilor reproiectate.

Proiectare baze de date– procesul de creare a unei scheme de baze de date și de determinare a constrângerilor de integritate necesare (respectarea informațiilor disponibile în baza de date cu logica internă, structura și toate regulile specificate în mod explicit).

Principalele sarcini ale proiectării bazei de date:

Asigurarea că toate informațiile necesare sunt stocate în baza de date.

Asigurarea capacității de a obține date pentru toate solicitările necesare.

Reduceți redundanța și duplicarea datelor.

Asigurarea integrității bazei de date.