Dezvoltarea bazei de date. Normalizarea bazei de date. Proprietățile câmpului bazei de date

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 amendamente și modificări la modelul 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:

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.
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.
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:

sarcini de minimizare a spațiului de stocare a datelor,
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 designului imediat al bazei de date.

Teme: etapele de proiectare a bazei de date, proiectarea bazei de date pe baza unui model de tip obiect-relație.

Înainte de a crea o bază de date, dezvoltatorul trebuie să stabilească din ce tabele ar trebui să conțină baza de date, ce date trebuie să fie plasate în fiecare tabel și cum se leagă tabelele. Aceste probleme sunt rezolvate în etapa de proiectare a bazei de date.

Ca urmare a proiectării, trebuie determinată structura logică a bazei de date, adică compoziția tabelelor relaționale, structura acestora și relațiile dintre tabele.

Înainte de a crea o bază de date, este necesar să existe o descriere a domeniului subiectului selectat, care să acopere obiecte și procese reale, să identifice toate sursele de informații necesare pentru a satisface solicitările așteptate ale utilizatorilor și să determine nevoile de prelucrare a datelor.

Pe baza unei astfel de descrieri, în etapa de proiectare a bazei de date, se determină compoziția și structura datelor din domeniul subiectului, care ar trebui să fie în baza de date și să asigure îndeplinirea interogărilor și sarcinilor utilizatorului necesare. Structura de date a domeniului subiect poate fi afișată printr-un model logic informațional. Pe baza acestui model, o bază de date relațională poate fi creată cu ușurință.

Etapele proiectării și creării unei baze de date sunt determinate de următoarea secvență:

Construirea unui model informatic-logic de date al domeniului;

Determinarea structurii logice a unei baze de date relaționale;

Proiectare de tabele de baze de date;

Crearea unei scheme de date;

Introducerea datelor în tabele (crearea înregistrărilor);

Dezvoltarea formularelor, interogărilor, macro-urilor, modulelor, rapoartelor necesare;

Dezvoltarea interfeței cu utilizatorul.

În procesul de dezvoltare a unui model de date, este necesar să se selecteze obiecte informaționale care îndeplinesc cerințele de normalizare a datelor și să se determine conexiunile dintre ele. Acest model vă permite să creați o bază de date relațională fără duplicare, ceea ce asigură introducerea unică a datelor în timpul încărcării și ajustărilor inițiale, precum și integritatea datelor atunci când se fac modificări.

Atunci când se dezvoltă un model de date, pot fi utilizate două abordări. În prima abordareÎn primul rând, se determină sarcinile principale pentru soluția pentru care se construiește baza, se identifică nevoile de date ale sarcinilor și se determină în consecință compoziția și structura obiectelor informaționale. La a doua abordare Obiectele tipice din domeniul subiectului sunt instalate imediat. Cea mai rațională combinație a ambelor abordări. Acest lucru se datorează faptului că, în stadiul inițial, de regulă, nu există informații complete despre toate sarcinile. Utilizarea unei astfel de tehnologii este cu atât mai justificată cu cât instrumentele flexibile pentru crearea bazelor de date relaționale vă permit să faceți modificări în baza de date și să modificați structura acesteia în orice stadiu de dezvoltare fără a deteriora datele introduse anterior.

Procesul de identificare a obiectelor informaționale din domeniul de studiu care îndeplinesc cerințele de normalizare poate fi realizat pe baza unei abordări intuitive sau formale. Bazele teoretice ale abordării formale au fost dezvoltate și prezentate integral în monografii privind organizarea bazelor de date de către celebrul om de știință american J. Martin.

Cu o abordare intuitivă, obiectele informaționale corespunzătoare obiectelor reale pot fi identificate cu ușurință. Cu toate acestea, modelul informațional-logic rezultat, de regulă, necesită transformări ulterioare, în special transformarea relațiilor cu mai multe valori între obiecte. Cu această abordare, erori semnificative sunt posibile dacă nu există suficientă experiență. Verificarea ulterioară a conformității cu cerințele de normalizare arată de obicei necesitatea clarificării obiectelor informaționale.

Să luăm în considerare regulile formale care pot fi folosite pentru a evidenția obiectele informaționale:

Pe baza descrierii subiectului, identificați documentele și atributele acestora pentru a fi stocate în baza de date;

Determinați dependențe funcționale între atribute;

Selectați toate atributele dependente și indicați pentru fiecare toate atributele sale cheie, adică cele de care depinde;

Grupați atributele care depind în mod egal de atributele cheie. Grupurile rezultate de atribute dependente, împreună cu atributele lor cheie, formează obiecte informaționale.

La definirea structurii logice a unei baze de date relaționale pe baza unui model, fiecare obiect informațional este reprezentat adecvat printr-un tabel relațional, iar relațiile dintre tabele corespund relațiilor dintre obiectele informaționale.

În timpul procesului de creare, tabelele bazei de date corespunzătoare obiectelor informaționale ale modelului de date construit sunt mai întâi construite. În continuare, poate fi creată o schemă de date în care sunt înregistrate conexiunile logice existente între tabele. Aceste conexiuni corespund conexiunilor obiectelor informaționale. Schema de date poate fi configurată pentru a menține integritatea bazei de date dacă modelul de date a fost proiectat pentru a îndeplini cerințele de normalizare. Integritatea datelor înseamnă că baza de date a stabilit și menținut corect relații între înregistrările diferitelor tabele la încărcarea, adăugarea și ștergerea înregistrărilor din tabele aferente, precum și la modificarea valorilor câmpurilor cheie.

După ce se formează schema de date, sunt introduse date consecvente din documentele din domeniul subiectului.

Pe baza bazei de date create se generează interogările necesare, formulare, macro-uri, module, rapoarte care realizează prelucrarea necesară a datelor bazei de date și prezentarea acestora.

Folosind instrumente și instrumente de bază de date încorporate, este creată o interfață cu utilizatorul care vă permite să gestionați procesele de introducere, stocare, procesare, actualizare și prezentare a informațiilor bazei de date.

Proiectarea unei baze de date bazată pe modelul obiect-relație

Există o serie de tehnici pentru crearea de informații și modele logice. Una dintre cele mai populare metode în prezent de dezvoltare a modelelor folosește ERD (Entity-Relationship Diagrams). În literatura în limba rusă, aceste diagrame sunt numite „obiect - relație” sau „esență - conexiune”. Modelul ERD a fost propus de Peter Ping Shen Chen în 1976. Până în prezent, au fost dezvoltate mai multe variante, dar toate se bazează pe diagramele grafice propuse de Chen. Diagramele sunt construite dintr-un număr mic de componente. Datorită clarității prezentării, acestea sunt utilizate pe scară largă în instrumentele CASE (Computer Aided Software Engineering).

Să ne uităm la terminologia și notația folosită.

Entitate- un obiect real sau imaginar care este semnificativ pentru domeniul în cauză, informații despre care sunt supuse stocării.

Fiecare entitate trebuie să aibă un identificator unic. Fiecare instanță a unei entități trebuie să fie identificabilă în mod unic și distinctă de toate celelalte instanțe de acel tip (entitate).

Fiecare entitate trebuie să aibă anumite proprietăți:

Să aibă un nume unic; Mai mult, aceeași interpretare (definiția entității) trebuie întotdeauna aplicată acestui nume. În schimb, aceeași interpretare nu poate fi aplicată unor nume diferite decât dacă sunt pseudonime;

Posedă unul sau mai multe atribute care sunt fie deținute de entitate, fie moștenite de aceasta printr-o relație;

Au unul sau mai multe atribute care identifică în mod unic fiecare instanță a unei entități.

O entitate poate fi independentă sau dependentă. Un semn al unei entități dependente este prezența atributelor moștenite printr-o relație (Fig. 1.).

Fiecare entitate poate avea orice număr de conexiuni cu alte entități din model.

Relaţie- o asociere denumită între două entități care este semnificativă pentru domeniul în cauză. Una dintre entitățile care participă la conexiune este independentă, numită entitate părinte, cealaltă este dependentă, numită entitate copil sau descendentă. De obicei, fiecare instanță a unei entități părinte este asociată cu un număr arbitrar (inclusiv zero) de instanțe ale unei entități copil. Fiecare instanță a unei entități copil este asociată cu exact o instanță a entității sale părinte. Astfel, o instanță a unei entități copil poate exista numai dacă există entitatea părinte.

Conexiunii i se dă un nume, exprimat prin turnarea gramaticală a verbului și plasat lângă linia de legătură.

Numele fiecărei relații dintre două entități date trebuie să fie unic, dar numele relațiilor din model nu trebuie să fie unic. Fiecare conexiune are o definiție. Definiția unei relații se formează prin combinarea numelui entității părinte, a numelui relației, a expresiei gradului de legătură și a numelui entității fii.

De exemplu, relația vânzătorului cu contractul ar putea fi definită după cum urmează:

Vânzătorul poate primi compensații pentru unul sau mai multe Contracte;

Contractul trebuie inițiat de exact un Vânzător.

În diagramă, conexiunea este reprezentată ca un segment (polilinie). Capetele segmentului folosesc simboluri speciale (Fig. 2) pentru a indica gradul de conectare. În plus, natura liniei – întreruptă sau continuă – indică faptul că conexiunea este obligatorie.

Atribut- orice caracteristică a unei entități care este semnificativă pentru domeniul în cauză. Acesta are scopul de a califica, identifica, clasifica, cuantifica sau exprima starea unei entități. Un atribut reprezintă un tip de caracteristici (proprietăți) asociate unui set de obiecte reale sau abstracte (oameni, locuri, evenimente, stări, idei, perechi de obiecte etc.) (Fig. 3).

Instanță de atribut este o anumită caracteristică a unei instanțe specifice a unei entități. O instanță de atribut este definită de tipul caracteristicii (de exemplu, „Culoare”) și valoarea acesteia (de exemplu, „violet”), numită valoarea atributului. În modelul ER, atributele sunt asociate cu entități specifice. Fiecare instanță de entitate trebuie să aibă o valoare specifică pentru fiecare dintre atributele sale.

Atributul poate fi fie obligatoriu, sau opțional. Obligatoriu înseamnă că atributul nu poate accepta valori nule. Atributul poate fi fie descriptiv (adică, un descriptor obișnuit al unei entități), fie parte dintr-un identificator unic (cheie primară).

Identificator unic este un atribut sau un set de atribute și/sau relații care caracterizează în mod unic fiecare instanță a unui anumit tip de entitate. În cazul identificării complete, o instanță a unui anumit tip de entitate este complet identificată prin propriile sale atribute cheie, în caz contrar, atributele unei alte entități, părintele, participă și ele la identificare.

Natura identificării este afișată într-o diagramă pe linia de comunicație (Fig. 4).

Fiecare atribut este identificat printr-un nume unic, exprimat printr-o frază nominală gramaticală care descrie caracteristica pe care o reprezintă atributul. Atributele sunt reprezentate ca o listă de nume într-un bloc de entitate asociat, fiecare atribut ocupând o linie separată. Atributele care definesc cheia primară sunt plasate în partea de sus a listei și evidențiate cu semnul „#”.

Fiecare entitate trebuie să aibă cel puțin o cheie posibilă. O cheie candidată pentru o entitate este unul sau mai multe atribute ale căror valori identifică în mod unic fiecare instanță a entității. Când există mai multe chei posibile, una dintre ele este desemnată ca cheie primară, iar celelalte ca chei alternative.

În prezent, pe baza abordării lui Chen, a fost creată metodologia IDEF1X, care este concepută ținând cont de cerințe precum ușurința de învățare și posibilitatea de automatizare. Diagramele IDEFlX sunt utilizate de o serie de instrumente CASE comune (în special, ERwin, Design/IDEF).

O entitate în metodologia IDEF1X se spune că este independentă de identificare sau pur și simplu independentă dacă fiecare instanță a entității poate fi identificată în mod unic fără a-și defini relațiile cu alte entități. O entitate este numită dependentă de identificator sau pur și simplu dependentă dacă identificarea unică a unei instanțe a entității depinde de relația acesteia cu o altă entitate (Fig. 5).

Fiecare entitate primește un nume și un număr unic, separate printr-o bară oblică „/” și plasate deasupra blocului.

Dacă o instanță a unei entități copil este determinată în mod unic de relația sa cu entitatea părinte, atunci relația se numește identificatoare, în caz contrar se numește neidentificare.

Relația de identificare dintre o entitate părinte și o entitate copil este reprezentată ca o linie continuă. În fig. 5: Nr. 2 - entitate dependentă, Relația 1 - relație de identificare. O entitate copil într-o relație de identitate este o entitate dependentă de identificator. Entitatea-mamă într-o relație de identificare poate fi fie o entitate independentă, fie o entitate dependentă de identificator (acest lucru este determinat de relațiile sale cu alte entități).

Linia întreruptă reprezintă o relație de neidentificare. În fig. 5: Nr. 4 - entitate independentă, Relația 2 - relație de neidentificare. O entitate copil într-o relație de neidentificare va fi independentă de identificator, cu excepția cazului în care este și o entitate copil într-o relație de identificare.

Relația poate fi definită în continuare prin specificarea gradului sau cardinalității (numărul de instanțe ale unei entități copil care poate exista pentru fiecare instanță a unei entități părinte).

Următoarele puteri de legătură pot fi exprimate în IDEF1X:

Fiecare instanță de entitate părinte poate avea zero, una sau mai multe instanțe de entitate copil asociate cu ea;

Fiecare instanță de entitate părinte trebuie să aibă cel puțin o instanță de entitate copil asociată cu ea;

Fiecare instanță de entitate părinte trebuie să aibă cel mult o instanță de entitate copil asociată cu ea;

Fiecare instanță a unei entități părinte este asociată cu un număr fix de instanțe ale unei entități copil.

Puterea de comunicare este indicată așa cum se arată în Fig. 6 (putere implicită - N).

Atributele sunt reprezentate ca o listă de nume în interiorul unui bloc de entitate. Atributele care definesc cheia primară sunt plasate în partea de sus a listei și separate de alte atribute printr-o linie orizontală (Fig. 7).

Rezultatul este un model informațional-logic, care este utilizat de o serie de instrumente CASE comune, cum ar fi ERwin, Design/IDEF. La rândul lor, tehnologiile CASE au un potențial ridicat pentru dezvoltarea bazelor de date și a sistemelor informaționale, și anume, creșterea productivității muncii, îmbunătățirea calității produselor software și susținerea unui stil de lucru unitar și consistent.

Entitățile pot avea și chei străine. Într-o relație de identificare, ele sunt utilizate ca parte sau întregul cheie primară într-o relație de neidentificare, ele servesc ca atribute non-cheie. În lista de atribute, o cheie străină este marcată cu literele FK între paranteze.

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:

Analiza cerințelor sau determinarea scopului bazei de date;
Organizarea datelor în tabele;
Specificarea cheilor primare și analiza relațiilor;
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 colecta 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 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 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 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 al cursurilor, deoarece un student poate urma mai multe cursuri, iar fiecare curs poate avea 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ătură î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 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 management al 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 funcții etc.

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

Rău Bun

Orez. 3.5.

În stadiul formulării şi analiza cerințelor sunt stabilite scopurile organizației, sunt determinate cerințele pentru baza de date. Acestea constau din cerințele generale definite mai sus și cerințe specifice. Pentru a formula cerințe specifice, se folosește de obicei tehnica intervievarii personalului de la diferite niveluri de conducere. Toate cerințele sunt documentate într-o formă accesibilă utilizatorului final și proiectantului bazei de date.

Etapa de proiectare conceptuală constă în descrierea și sintetizarea cerințelor privind informațiile utilizatorului într-o proiectare inițială a bazei de date. Datele sursă pot fi un set de documente utilizator (Fig. 3.3) în abordarea clasică sau algoritmi de aplicare (algoritmi de afaceri) în abordarea modernă. Rezultatul acestei etape este o reprezentare la nivel înalt (sub forma unui sistem de tabele de baze de date) a cerințelor de informații ale utilizatorilor bazate pe diverse abordări.

În primul rând, este selectat modelul bazei de date. Apoi, folosind DML, se creează o structură a bazei de date, care este umplută cu date utilizând comenzi DML, sisteme de meniu, formulare de ecran sau în modul de vizualizare a tabelului bazei de date. Aici, protecția și integritatea (inclusiv integritatea referențială) datelor sunt asigurate folosind un SGBD sau prin construirea declanșatorilor.

În curs design logic reprezentarea la nivel înalt a datelor este convertită în structura SGBD utilizată. Scopul principal al acestei etape este eliminarea redundanței datelor folosind reguli speciale de normalizare.

Scopul normalizării este de a minimiza repetarea datelor și posibilele modificări structurale în baza de date în timpul procedurilor de actualizare. Acest lucru se realizează prin împărțirea (descompunerea) unui tabel în două sau mai multe și apoi prin utilizarea operațiilor de navigare în interogări. Primit structura logica O bază de date poate fi cuantificată folosind diverse caracteristici (număr de accesări la înregistrările logice, volumul de date din fiecare aplicație, volumul total de date). Pe baza acestor estimări structura logica poate fi îmbunătățită pentru a obține o eficiență mai mare.

Procedura de gestionare a bazei de date merită o discuție specială. Este cel mai ușor în modul pentru un singur utilizator. În modul multi-utilizator și în bazele de date distribuite, procedura devine mult mai complicată. Dacă mai mulți utilizatori au acces simultan fără a lua măsuri speciale, este posibil ca încălcarea integrității. Pentru a elimina acest fenomen, utilizați un sistem de tranzacții și un mod de blocare pentru tabele sau înregistrări individuale.

Tranzacţie- procesul de modificare a unui fișier, înregistrare sau bază de date cauzat de transmiterea unui singur mesaj de intrare.

În etapa de proiectare fizică, problemele legate de performanța sistemului sunt rezolvate și structuri de depozitare date și metode de acces.

Interacțiunea dintre fazele de proiectare și sistemul de dicționar trebuie luată în considerare separat. Procedurile de proiectare pot fi utilizate independent în absența unui sistem de dicționar. Sistemul dicționar în sine poate fi considerat un element de automatizare a designului.

Instrumentele de proiectare și criteriile de evaluare sunt utilizate în toate etapele de dezvoltare. În prezent, incertitudinea în selectarea criteriilor este cel mai slab punct în proiectarea bazei de date. Acest lucru se datorează dificultății de a descrie și identifica un număr mare de soluții alternative.

Situația este mai simplă când se lucrează cu criterii cantitative, care includ timpul de răspuns la o solicitare, costul modificării, costul memoriei, timpul de creare, costul reorganizării. Dificultatea poate fi cauzată de criteriile care se contrazic reciproc.

În același timp sunt multe criterii de optimitate, care sunt proprietăți incomensurabile care sunt greu de exprimat cantitativ sau ca funcție obiectivă.

Criteriile de calitate pot include flexibilitatea, adaptabilitatea, accesibilitatea pentru noi utilizatori, compatibilitatea cu alte sisteme, capacitatea de a se converti într-un alt mediu de calcul, capacitatea de a fi restaurat, capacitatea de distribuire și extindere.

Procesul de proiectare este lung și necesită forță de muncă și durează de obicei câteva luni. Principalele resurse ale designerului bazei de date sunt propria intuiție și experiență, astfel încât calitatea soluției în multe cazuri poate fi scăzută.

Principalele motive pentru eficiența scăzută a bazelor de date proiectate pot fi:

analiza insuficient de profundă a cerințelor (etapele inițiale de proiectare), inclusiv semantica și relațiile de date ale acestora;
durata lungă a procesului de structurare, făcând acest proces obositor și dificil de efectuat manual.

În aceste condiții, problemele de automatizare a dezvoltării devin primordiale.

Principalele etape ale dezvoltării bazei de date

Etapa 1. Clarificarea sarcinilor

În prima etapă, se întocmește o listă cu toate sarcinile principale care, în principiu, ar trebui rezolvate de această aplicație, inclusiv cele care nu sunt necesare astăzi, dar care pot apărea în viitor. Sarcinile „de bază” se referă la funcțiile care trebuie să fie reprezentate în formularele sau rapoartele aplicației.

Etapa 2. Succesiunea sarcinilor

Pentru ca aplicația să funcționeze logic și convenabil, cel mai bine este să organizați sarcinile principale în grupuri tematice și apoi să organizați sarcinile fiecărui grup astfel încât să fie aranjate în ordinea în care sunt finalizate. Se poate întâmpla ca unele sarcini să fie asociate cu diferite grupuri, sau ca finalizarea unei anumite sarcini să preceadă finalizarea alteia aparținând unui alt grup.

Etapa 3: Analiza datelor

După generarea unei liste de sarcini, cel mai important pas este alcătuirea unei liste detaliate cu toate datele necesare pentru rezolvarea fiecărei sarcini. Unele date vor fi necesare ca date inițiale și nu se vor modifica. Alte date vor fi verificate și modificate pe măsură ce sarcina progresează. Unele elemente de date pot fi eliminate sau adăugate. În cele din urmă, unele date vor fi obținute prin calcule: rezultatul lor va fi parte a problemei, dar nu vor fi introduse în baza de date.

Etapa 4. Definirea structurii datelor

După o analiză preliminară a tuturor elementelor de date necesare, trebuie să le organizați în obiecte și să corelați obiectele cu tabelele și interogările bazei de date. Bazele de date cu acces relațional folosesc un proces numit normalizare pentru a crea cea mai eficientă și flexibilă modalitate de stocare a datelor.

Etapa 5. Dezvoltarea aspectului aplicației și a interfeței cu utilizatorul

După specificarea structurii tabelelor aplicației, în Microsoft Access este ușor să-i creați aspectul folosind formulare și să le legați între ele folosind macrocomenzi simple sau proceduri de gestionare a evenimentelor. Este ușor să demonstrați clientului un aspect preliminar de lucru și să obțineți aprobarea acestuia chiar înainte de implementarea detaliată a sarcinilor aplicației.

Etapa 6. Creați o aplicație

Pentru sarcini foarte simple, aspectul creat este aproape o aplicație completă. Cu toate acestea, destul de des trebuie să scrieți proceduri care vă permit să automatizați complet soluția tuturor sarcinilor subliniate în proiect. Prin urmare, va trebui să creați formulare speciale de conectare care asigură tranziția de la o sarcină la alta.

Etapa 7. Testare și îmbunătățire

După finalizarea lucrărilor la componentele aplicației individuale, trebuie să verificați funcționarea aplicației în fiecare dintre modurile posibile. Este necesar să se verifice funcționarea macrocomenzilor utilizând modul de depanare pas cu pas, în care va fi executată o comandă macro specifică. Când utilizați Visual Basic pentru aplicații, aveți la dispoziție o varietate de instrumente de depanare pentru a vă testa aplicația și pentru a identifica și corecta erorile.

Pe măsură ce se dezvoltă secțiuni de sine stătătoare ale aplicației, este recomandabil să le predați clientului pentru a le verifica funcționarea și a obține o opinie cu privire la necesitatea efectuării anumitor modificări. După ce clientul se familiarizează cu funcționarea aplicației, aproape întotdeauna are sugestii suplimentare de îmbunătățire, indiferent cât de amănunțit a fost studiul preliminar al proiectului. Utilizatorii constată adesea că unele dintre lucrurile pe care le-au spus au fost foarte importante și necesare în timpul procesului de stabilire a sarcinilor, de fapt, nu joacă un rol semnificativ în utilizarea practică a aplicației. Identificarea modificărilor necesare în etapele incipiente ale dezvoltării aplicației poate reduce semnificativ timpul pentru relucrarea ulterioară.

Traducerea unei serii de 15 articole despre proiectarea bazelor de date.
Informația este destinată începătorilor.
M-a ajutat. Poate că va ajuta pe altcineva să completeze golurile.

Ghid de proiectare a bazei de date.

1. Introducere.

Dacă intenționați să vă construiți propriile baze de date, este o idee bună să respectați ghidurile de proiectare a bazelor de date, deoarece acest lucru va asigura integritatea pe termen lung și ușurința de întreținere a datelor dvs. Acest ghid vă va spune ce sunt bazele de date și cum să proiectați o bază de date care urmează regulile de proiectare a bazelor de date relaționale.

Bazele de date sunt programe care vă permit să stocați și să preluați cantități mari de informații aferente. Bazele de date constau din Mese, care conțin informație. Când creați o bază de date trebuie să vă gândiți la ce Mese trebuie să creezi și ce comunicatii există între informațiile din tabele. Cu alte cuvinte, trebuie să te gândești proiect baza ta de date. Frumos proiect baza de date, așa cum sa menționat mai devreme, va asigura integritatea datelor și ușurința întreținerii.

O bază de date este creată pentru a stoca informații în ea și pentru a prelua aceste informații atunci când este necesar. Aceasta înseamnă că trebuie să putem plasa, introduce ( INTRODUCE) informații în baza de date și dorim să putem prelua informații din baza de date ( SELECTAȚI).
Un limbaj de interogare a bazei de date a fost inventat în aceste scopuri și a fost numit Limbajul de interogare structurat sau SQL. Operațiile de inserare a datelor (INSERT) și de selectare a acestora (SELECT) fac parte chiar din acest limbaj. Mai jos este un exemplu de solicitare de recuperare a datelor și rezultatul acesteia.

SQL este un subiect mare și depășește scopul acestui tutorial. Acest articol este strict axat pe prezentare procesul de proiectare a bazei de date. Voi acoperi elementele de bază ale SQL mai târziu într-un tutorial separat.

Model relațional.

În acest tutorial, vă voi arăta cum să creați un model de date relaționale. Modelul relațional este un model care descrie modul de organizare a datelor în tabele și modul de definire a relațiilor dintre aceste tabele.

Regulile modelului relațional dictează modul în care informațiile ar trebui să fie organizate în tabele și modul în care tabelele sunt legate între ele. În cele din urmă, rezultatul poate fi prezentat sub forma unei diagrame de bază de date sau, mai precis, a unei diagrame entitate-relație, ca în figură (Exemplu preluat din MySQL Workbench).

Exemple.

Am folosit o serie de aplicații ca exemple în ghid.

RDBMS.

RDBMS-ul pe care l-am folosit pentru a crea exemplele de tabele a fost MySQL. MySQL este cel mai popular RDBMS și este gratuit.

Utilitar de administrare a bazelor de date.

După instalarea MySQL, veți obține doar o interfață de linie de comandă pentru a interacționa cu MySQL. Personal, prefer un GUI pentru a-mi gestiona bazele de date. Folosesc des SQLyog. Acesta este un utilitar GUI gratuit. Imaginile tabelului din acest manual sunt preluate de acolo.

Modelare vizuală.

Există o aplicație gratuită excelentă numită MySQL Workbench. Vă permite să vă proiectați baza de date grafic. Imaginile diagramei din manual sunt realizate în acest program.

Design independent de RDBMS.

Este important de știut că, deși acest tutorial oferă exemple pentru MySQL, proiectarea bazei de date este independentă de RDBMS. Aceasta înseamnă că informațiile se aplică bazelor de date relaționale în general, nu doar MySQL. Puteți aplica cunoștințele din acest tutorial în orice baze de date relaționale precum Mysql, Postgresql, Microsoft Access, Microsoft Sql sau Oracle.

În partea următoare, voi vorbi pe scurt despre evoluția bazelor de date. Veți afla de unde provin bazele de date și modelul de date relaționale.

2. Istorie.

În anii 70 și 80, când informaticienii încă purtau smoking maro și ochelari cu rame mari, pătrate, datele erau stocate nestructurate în fișiere, care erau un document text cu date separate prin (de obicei) virgule sau file.

Așa arătau profesioniștii în tehnologia informației în anii 70. (În stânga jos este Bill Gates).

Fișierele text sunt încă folosite astăzi pentru a stoca cantități mici de informații simple. Valori separate prin virgulă (CSV) - Valorile separate prin virgulă sunt foarte populare și sunt acceptate pe scară largă astăzi de diverse software și sisteme de operare. Microsoft Excel este un exemplu de programe care pot funcționa cu fișiere CSV. Datele stocate într-un astfel de fișier pot fi citite de un program de calculator.

Mai sus este un exemplu despre cum ar putea arăta un astfel de fișier. Programul care citește acest fișier trebuie anunțat că datele sunt separate prin virgule. Dacă programul dorește să selecteze și să afișeze categoria în care se află lecția „Tutorial pentru proiectarea bazei de date”, apoi ea trebuie să citească rând cu rând până când cuvintele sunt găsite „Tutorial pentru proiectarea bazei de date”și apoi va trebui să citească cuvântul după virgulă pentru a deduce categoria Software.

Tabele baze de date.

Citirea unui fișier linie cu linie nu este foarte eficientă. Într-o bază de date relațională, datele sunt stocate în tabele. Tabelul de mai jos conține aceleași date ca și fișierul. Fiecare rând sau „înscriere” conține o lecție. Fiecare coloană conține anumite proprietăți ale lecției. În acest caz, acesta este titlul și categoria acestuia.

Un program de calculator ar putea căuta în coloana tutorial_id a unui anumit tabel un anumit tutorial_id pentru a găsi rapid titlul și categoria corespunzătoare. Acest lucru este mult mai rapid decât căutarea fișierului linie cu linie, la fel cum face un program într-un fișier text.

Bazele de date relaționale moderne sunt concepute pentru a permite preluarea datelor de pe anumite rânduri, coloane și mai multe tabele în același timp, foarte rapid.

Istoria modelului relațional.

Modelul bazei de date relaționale a fost inventat în anii 70 de Edgar Codd, un om de știință britanic. El a dorit să depășească neajunsurile modelului bazei de date de rețea și ale modelului ierarhic. Și a avut mare succes în asta. Modelul bazei de date relaționale este acum larg acceptat și considerat un model puternic pentru organizarea eficientă a datelor.

O gamă largă de sisteme de gestionare a bazelor de date sunt disponibile astăzi, de la aplicații desktop mici la sisteme de server bogate în funcții, cu metode de căutare extrem de optimizate. Iată câteva dintre cele mai cunoscute sisteme de management al bazelor de date relaționale (RDBMS):

- Oracol– folosit în principal pentru aplicații profesionale, mari.
- Microsoft SQL Server– RDBMS de la Microsoft. Disponibil numai pentru sistemul de operare Windows.
- mysql este un RDBMS open source foarte popular. Folosit pe scară largă atât de profesioniști, cât și de începători. Ce mai este nevoie?! Este gratis.
- IBM– are un număr de RDBMS-uri, cel mai cunoscut fiind DB2.
- Microsoft Access– RDBMS, care este folosit la birou și acasă. De fapt, este mai mult decât o bază de date. MS Access vă permite să creați baze de date cu o interfață de utilizator.
În partea următoare vă voi spune ceva despre caracteristicile bazelor de date relaționale.

3. Caracteristicile bazelor de date relaţionale.

Bazele de date relaționale sunt concepute pentru a stoca și a prelua rapid cantități mari de informații. Mai jos sunt câteva caracteristici ale bazelor de date relaționale și ale modelului de date relaționale.

Folosind chei.

Fiecare rând de date dintr-un tabel este identificat printr-o „cheie” unică numită cheie primară. Adesea, cheia primară este un număr care crește automat (creștere automată) (1,2,3,4 etc.). Datele din diferite tabele pot fi legate între ele folosind chei. Valorile cheii primare ale unui tabel pot fi adăugate la rândurile (înregistrările) altui tabel, legând astfel acele înregistrări între ele.

Folosind Structured Query Language (SQL), datele din diferite tabele care sunt legate de o cheie pot fi preluate dintr-o singură mișcare. De exemplu, puteți crea o interogare care va selecta toate comenzile din tabelul de comenzi care aparțin ID utilizator 3 (Mike) din tabelul utilizatori. Vom vorbi despre chei în continuare în următoarele părți.

Coloana ID din acest tabel este cheia primară. Fiecare înregistrare are o cheie primară unică, adesea un număr. Coloana grup de utilizatori este o cheie externă. Judecând după numele său, se pare că se referă la un tabel care conține grupuri de utilizatori.

Fără redundanță de date.

Într-un proiect de bază de date care urmează regulile modelului de date relaționale, fiecare informație, cum ar fi numele unui utilizator, este stocată într-un singur loc. Acest lucru elimină nevoia de a lucra cu date în mai multe locuri. Datele duplicate se numesc redundanță de date și ar trebui evitate într-un design bun al bazei de date.

Limitare de intrare.

Folosind o bază de date relațională, puteți determina ce fel de date pot fi stocate într-o coloană. Puteți crea un câmp care conține numere întregi, zecimale, bucăți mici de text, bucăți mari de text, date etc.

Când creați un tabel de bază de date, furnizați un tip de date pentru fiecare coloană. De exemplu, varchar este un tip de date pentru bucăți mici de text cu un număr maxim de caractere de 255 și int este un număr.

Pe lângă tipurile de date, RDBMS vă permite să limitați și mai mult datele pe care le puteți introduce. De exemplu, limitați lungimea sau forțați valoarea unică a înregistrărilor dintr-o coloană dată. Ultima restricție este adesea folosită pentru câmpurile care conțin nume de utilizator sau adrese de e-mail.

Aceste restricții vă oferă control asupra integrității datelor dvs. și previn situații precum următoarele:

Introducerea unei adrese (text) în câmpul în care vă așteptați să vedeți un număr
- introducerea unui index de regiune cu o lungime a aceluiași index de o sută de caractere
- crearea de utilizatori cu același nume
- crearea de utilizatori cu aceeași adresă de e-mail
- introduceți greutatea (numărul) în câmpul de naștere (data)

Menținerea integrității datelor.

Prin ajustarea proprietăților câmpurilor, legând tabele și configurând constrângeri, puteți crește fiabilitatea datelor dvs.

Cesiunea de drepturi.

Majoritatea RDBMS-urilor oferă setări de permisiuni care vă permit să atribuiți anumite drepturi anumitor utilizatori. Câteva acțiuni care pot fi permise sau refuzate utilizatorului: SELECT, INSERT, DELETE, ALTER, CREATE etc. Acestea sunt operațiuni care pot fi efectuate folosind Structured Query Language (SQL).

Limbajul de interogare structurat (SQL).

Pentru a efectua anumite operații asupra bazei de date, cum ar fi stocarea datelor, preluarea acestora, modificarea acesteia, se folosește un limbaj de interogare structurat (SQL). SQL este relativ ușor de înțeles și permite... și selecții stivuite, cum ar fi preluarea datelor asociate din mai multe tabele folosind instrucțiunea SQL JOIN. După cum am menționat mai devreme, SQL nu va fi discutat în acest tutorial. Mă voi concentra pe proiectarea bazei de date.

Modul în care vă proiectați baza de date va avea un impact direct asupra interogărilor pe care va trebui să le executați pentru a prelua date din baza de date. Acesta este un alt motiv pentru care trebuie să vă gândiți care ar trebui să fie baza dvs. Cu o bază de date bine concepută, interogările dvs. pot fi mai curate și mai simple.

Portabilitate.

Modelul de date relaționale este standard. Urmând regulile modelului de date relaționale, puteți fi sigur că datele dumneavoastră pot fi transferate într-un alt RDBMS cu relativă ușurință.

După cum sa menționat mai devreme, proiectarea bazei de date este o chestiune de identificare a datelor, relaționarea acestora și plasarea rezultatelor acestei întrebări pe hârtie (sau într-un program de calculator). Proiectați o bază de date independentă de RDBMS pe care intenționați să îl utilizați pentru ao crea.

În partea următoare vom arunca o privire mai atentă asupra cheilor primare.