Proiectarea bazei de date. Ghid pentru structura și proiectarea 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, trebuie să aveți o descriere a celor selectate domeniul subiectului, care ar trebui să acopere obiectele și procesele 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ță:

Construcția informațiilor model logic date de domeniu;

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 relațiile dintre ele. Acest model vă permite să creați bază relațională date fără duplicare, ceea ce asigură o introducere 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ă on 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. Baza teoretica abordarea formală 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;

Defini 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 acestea atribute cheie forme 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 obiecte informaţionale model de date construit. Î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ă relațiile dintre înregistrări sunt stabilite și menținute corect în baza de date mese diferite la încărcarea, adăugarea și ștergerea înregistrărilor din tabelele 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 varietăți, dar toate se bazează pe diagrame grafice, propus de Chen. Diagramele sunt construite din numar mic 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 acest tip(entitati).

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 relație 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 unei expresii a gradului de conexiune ș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 folosind denumiri speciale(Fig. 2) indică 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. Un atribut 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. Dacă sunt mai multe chei posibile una dintre ele este desemnată ca cheie primară, iar celelalte sunt desemnate 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 din metodologia IDEF1X este numită independentă de identificare sau pur și simplu independentă dacă fiecare instanță a entității poate fi identificată în mod unic fără a defini relațiile sale 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 de dezvoltare a bazelor de date și sisteme de informare, și anume, creșterea productivității muncii, îmbunătățirea calității produselor software, 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 ca întreg din cheia 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.

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 și eşalonare a bazei de date

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. Acest proces este, de asemenea, un proces pas cu pas. munca de proiect, dar de obicei într-o structură de proiectare acești pași sunt absorbiți în scenă design conceptual– stadiul identificării obiectelor, atributelor, conexiunilor.

Crearea unui conceptual (model informațional) implică formarea preliminară a cerințelor conceptuale ale utilizatorului, inclusiv cerințe pentru aplicații care ar putea să nu fie implementate imediat, dar ținând cont de 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 față de cea anterioară) urmează etapa de formare a cerințelor pentru mediul de operare, în care sunt evaluate cerințele pentru resursele de calcul capabile să asigure funcționarea sistemului. În consecință, cu cât este mai mare volumul bazei de date proiectate, 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 sistem de operare. De exemplu, modul de operare multi-utilizator al viitoarei baze de date necesită conexiune retea folosind un sistem de operare potrivit pentru multitasking.

Următorul pas este ca proiectantul să selecteze un sistem de management al bazei de date (DBMS), precum și unelte programatic. 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 următoarei etape - apariția unui SGBD specific prevăzut cu instrumente model conceptual. Acest pas corespunde etapei de proiectare logică (crearea unui model logic).

In cele din urma, stadiu final Proiectarea bazei de date devine design fizic - etapa de conectare a structurii logice și a mediului 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 software DB,
• 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ă.

Întrucât utilizarea metodei „entitate-relație” este o metodă de proiectare combinată în această etapă, cel mai adesea 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:

• identificarea (cu valoare unică pentru entități 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țită î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

Alegerea sistemului de management al bazei de date depinde implementare practică Sistem informatic. 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 în formular structura ierarhica, 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, atunci când se lucrează de la niveluri inferioare definirea atributelor 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 implică identificarea unui număr de entități de nivel înalt și a relațiilor acestora cu detalii ulterioare pentru nivelul cerut, care 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 recuperarea datelor vor fi create copii de rezervă baza de date și păstrați un jurnal al tuturor modificărilor.

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.

Lectura

Proiectarea bazei de date.

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

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

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

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

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

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

7.2. Tipologia modelelor

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

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

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

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

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

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

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

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

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

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

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

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

7.3. Etape de proiectare și modelare obiecte

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

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

Prin combinarea vizualizărilor individuale ale conținutului bazei de date obținute în urma interviurilor cu utilizatorii cu opiniile dvs. asupra datelor care ar putea fi necesare pentru a rezolva probleme practice, analistul de sisteme creează mai întâi o descriere informală generalizată a bazei de date care este creată. Această descriere, realizată folosind limbaj natural, expresii matematice, tabele, grafice și alte instrumente care sunt înțelese de toți oamenii care lucrează la proiectarea bazelor de date, se numește model informativ.

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

Celelalte modele sunt orientate spre mașină. Cu ajutorul lor, SGBD permite programelor și utilizatorilor să acceseze datele stocate numai după numele lor, fără a-și face griji locatie fizica aceste date.

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

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

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

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

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

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

7.4. Abordări de proiectare a bazelor de date

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ÎN caz general Există două abordări pentru a determina compoziția și structura unui domeniu. (Diapozitivul 9 Funcțional - abordări obiect)

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

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

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

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

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

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

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

7.6. Modele datalogice

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

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

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

În primul rând, relațiile de domeniu pot fi afișate în două moduri, ambele declarative - în circuit logic, și procedural - stabilirea conexiunilor prin module software care procesează (legă) datele stocate corespunzătoare.

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

7.7. Modele fizice

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

- alegerea unei metode de organizare a bazei de date;

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

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

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

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

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

7.8. Proiectare instrumente de automatizare

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

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

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

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

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

instrumentele CASE în conformitate cu orientarea lor funcțională către anumite procese ciclu de viață IP poate fi împărțit în următoarele grupuri(diapozitivul 11 ​​– SAS.E.).

Limbile formale folosite pentru a reprezenta domeniul nu permit descrierea Toate relații pe care designerul le consideră importante. Pe de altă parte, multe proiecte (și, în special, cele aflate în considerare exemple ) sunt percepute ca fiind destul de simple și solutii de proiectare par evidente. În plus, un programator cu experiență poate oferi întotdeauna ceva empiric și poate valid metoda eficienta pentru prezentarea și prelucrarea țintită a informațiilor necesare.Totuși, aceasta înseamnă abandonarea unui singur formalism, care, odată cu creșterea cantității de date și conexiuni, complică semnificativ problemele de gestionare a bazelor de date și, în special, înțelegerea de către utilizator a organizare și metode de acces.

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

Trimiteți-vă munca bună în baza de cunoștințe este simplu. Utilizați formularul de mai jos

Buna treaba la site">

Studenții, studenții absolvenți, tinerii oameni de știință care folosesc baza de cunoștințe în studiile și munca lor vă vor fi foarte recunoscători.

Postat pe http://www.allbest.ru/

ÎNVmâncând

sistem de utilizator al programului de interfață

Astăzi, sute de milioane de oameni lucrează în lume calculatoare personale. Oamenii de știință, economiștii și politicienii cred că până la începutul celui de-al treilea mileniu:

Numărul de calculatoare din lume va fi egal cu numărul locuitorilor țărilor dezvoltate.

Majoritatea acestor calculatoare vor fi incluse în rețelele globale de informații.

toate informațiile acumulate de umanitate până la începutul mileniului trei vor fi traduse în formă computerizată (binară), iar toate informațiile vor fi pregătite cu ajutorul (sau cu participarea) computerelor; toate informațiile vor fi stocate pe termen nelimitat în rețelele de calculatoare;

un membru cu drepturi depline al societății mileniului al treilea va trebui să interacționeze în fiecare zi cu rețelele locale, regionale sau globale folosind computere.

Cu o astfel de informatizare a aproape tuturor sectoarelor activității umane, se pune problema creării de programe care să permită crearea unor astfel de baze de date. Prin urmare, a fost dezvoltat acest program, care vă permite să creați o bază de date care stochează informații despre progresul școlarilor.

1. Baza de date și metodele de prezentare a acesteia

O bază de date (DB) este o informație prezentată sub formă de tabele bidimensionale. Baza de date conține multe rânduri, fiecare dintre ele corespunde unui obiect. Pentru fiecare obiect se folosesc anumite poziții independente, care se numesc câmpuri. Să ne imaginăm o astfel de bază de date care conține rânduri și coloane ( cel mai simplu caz). Fiecare linie, numită și înregistrare, îi corespunde obiect specific. Fiecare coloană conține valorile datelor obiectului corespunzătoare.

O bază de date poate consta nu dintr-un tabel, ci din două, trei sau mai multe. Informații suplimentare despre un obiect pot fi stocate în tabele suplimentare.

Una dintre caracteristicile puternice ale bazei de date este că informațiile pot fi organizate în funcție de criteriile specificate de utilizator. În Pascal, baza de date este furnizată ca o listă de termeni de forma: database_predicate_name (record_fields). Numele bazelor de date sunt descrise în secțiune. Înregistrările bazei de date sunt accesate folosind un predicat de bază. pascal oferă destul de multe instrumente pentru lucrul cu astfel de baze de date: încărcare, scriere, adăugare etc.

O bază de date este o structură organizată concepută pentru a stoca informații. Bazele de date moderne stochează nu numai date, ci și informații.

Această afirmație este ușor de explicat dacă, de exemplu, luăm în considerare baza de date a unei bănci mari. Are de toate informatie necesara despre clienți, adresele acestora, istoricul de credit, starea conturilor curente, tranzactii financiare etc. Un număr destul de mare de angajați ai băncii au acces la această bază de date, dar printre aceștia nu există aproape o persoană care să aibă acces la întreaga bază de date și, în același timp, să poată face de una singură mâini modificări arbitrare. Pe lângă date, baza de date conține metode și instrumente care permit fiecărui angajat să opereze doar cu datele care sunt de competența sa. Ca urmare a interacțiunii datelor conținute în baza de date cu metodele de care dispun anumiți angajați, se generează informații pe care aceștia le consumă și pe baza cărora, în limita propriei competențe, introduc și editează date. Strâns legat de conceptul de bază de date este conceptul sisteme de management al bazelor de date. Acesta este un set de instrumente software concepute pentru a crea structura unei noi baze de date, a o completa cu conținut, a edita conținutul și a vizualiza informații. Sub vizualizarea informatiilor baza de date se referă la selectarea datelor afișate în conformitate cu un criteriu dat, ordonarea acestora, proiectarea și livrarea ulterioară către dispozitivele de ieșire sau transmiterea prin canale de comunicație. Există multe sisteme de gestionare a bazelor de date în lume. Deși pot funcționa diferit cu diferite obiecte și pot oferi utilizatorului diverse funcțiiși instrumente, majoritatea SGBD-urilor se bazează pe un singur set bine stabilit de concepte de bază. Acest lucru ne oferă posibilitatea de a lua în considerare un sistem și de a generaliza conceptele, tehnicile și metodele acestuia la întreaga clasă de SGBD. Ca astfel de obiect de antrenament, vom alege SGBD-ul Pascal 7.0, inclus în pachetul Pascal 7.0.

2. Proprietățile câmpurilor bazei de date

Câmpurile bazei de date nu numai că definesc structura bazei de date - ele determină și proprietățile de grup ale datelor scrise în celulele aparținând fiecăruia dintre câmpuri. Mai jos sunt enumerate principalele proprietăți ale câmpurilor tabelelor bazei de date folosind SGBD-ul Pascal 7.0 ca exemplu.

Nume câmp - determină cum trebuie accesate datele acestui câmp în timpul operațiunilor automate cu baza de date (în mod implicit, numele câmpurilor sunt folosite ca titluri de coloană de tabel).

Tip câmp - determină tipul de date care pot fi conținute în acest câmp.

Dimensiunea câmpului - determină lungimea maximă (în caractere) a datelor care pot fi plasate în acest câmp.

Format câmp - determină modul în care datele sunt formatate în celulele aparținând câmpului.

Mască de intrare - definește forma în care datele sunt introduse în câmp (instrument de automatizare a introducerii datelor).

Legendă - definește antetul coloanei tabelului pentru a acestui domeniu(dacă nu este specificată semnătura, atunci proprietatea Nume câmp este utilizată ca antet de coloană).

Valoarea implicită este valoarea care este introdusă automat în celulele câmpului (instrument de automatizare a introducerii datelor).

O condiție de valoare este o constrângere utilizată pentru a verifica corectitudinea introducerii datelor (un instrument de automatizare a introducerii care este utilizat în mod obișnuit pentru date care au un tip numeric, valutar sau de dată).

Mesajul de eroare este un mesaj text care este afișat automat atunci când încercați să introduceți date incorecte într-un câmp.

Câmp obligatoriu - o proprietate care determină dacă acest câmp trebuie completat la completarea bazei de date.

Linii goale - o proprietate care permite introducerea de date șiruri goale (diferă de proprietatea Câmp obligatoriu prin faptul că nu se aplică tuturor tipurilor de date, ci doar unora, de exemplu, text).

Câmp indexat - dacă un câmp are această proprietate, toate operațiunile legate de căutarea sau sortarea înregistrărilor după valoarea stocată în acest câmp sunt accelerate semnificativ. În plus, pentru câmpurile indexate, vă puteți asigura că valoarea din înregistrări va fi verificată cu acest câmp pentru duplicate, ceea ce vă permite să eliminați automat duplicarea datelor.

Deoarece câmpuri diferite pot conține date tipuri diferite, atunci proprietățile câmpurilor pot varia în funcție de tipul de date. De exemplu, lista proprietăților câmpurilor de mai sus se referă în principal la câmpuri de tip text.

Câmpurile de alte tipuri pot avea sau nu aceste proprietăți, dar pot adăuga propriile lor proprietăți. De exemplu, pentru reprezentarea datelor numere reale, o proprietate importantă este numărul de zecimale. Pe de altă parte, pentru câmpurile folosite pentru a stoca imagini, înregistrări audio, clipuri video și alte obiecte OLE, majoritatea proprietăților de mai sus sunt lipsite de sens.

3 . Tsedacă și sarcini

La crearea acestui program, s-au stabilit următoarele obiective:

· Scrieți un program care să vă permită să procesați, să sortați și să schimbați informații despre parcări.

De asemenea, la crearea acestui program au existat următoarele sarcini:

· Acest program ar trebui să aibă o interfață de utilizator simplă și convenabilă.

· Acest program ar trebui să aibă un consum redus de resurse.

4. Dezvoltarea meniului de sistem

Meniul de sistem sau meniul principal ar trebui să ofere utilizatorului o interacțiune convenabilă cu programul. Meniul ar trebui să includă opțiuni pentru salvare, vizualizare, introducere de date noi etc. Utilizatorul trebuie doar să apese butonul „enter”. Există șase elemente în meniul acestui program:

1 - Crearea fișierului

2 - Adăugarea unei intrări

3 - Corectarea înregistrării

4 - Vizualizați o înregistrare dintr-un fișier

5 - Ștergeți o intrare

6 - Ieșire

1 - Creați un fișier nou - Creat fișier nou cu un nume specificat de utilizatorul programului

2 - Vizualizarea conținutului fișierului - înregistrările create anterior sunt afișate pe ecran una câte una sub forma:

Numele proprietarului:

Numele proprietarului:

marca masina:

model la scara:

tipul corpului:

numarul masinii:

regiune:

anul emiterii:

culoare:

3 - Adăugarea unei intrări - Creare intrare nouăși fișierul adăugându-l la sfârșitul intrării.

4 - Căutare după numărul secției - Vă permite să găsiți date despre un turist după numărul secției în care este înregistrat turistul.

5 - Ieșiți din program - ieșiți din program

Concluzie

Munca depusă permite oricărui utilizator să creeze cu ușurință cantități mari de informații, să le proceseze, să le sorteze și să facă selecții în funcție de anumite criterii.

Folosind un astfel de program în lumea modernă facilitează foarte mult activitatea umană.

Postat pe Allbest.ru

Documente similare

Determinarea modulelor de program necesare și a structurii fișierelor bazei de date. Descrierea dezvoltării programului, depanării și testării. Dezvoltarea aplicației Organizer.exe, a meniului și a manualului de utilizare. Algoritm pentru procesarea evenimentelor din meniul principal (programe).

lucrare curs, adăugată 02.11.2014


Caracteristici de proiectare a unui program în C++ pentru prelucrarea datelor din tabelele bazei de date. Principalele funcții ale programului, crearea unui model de bază de date conceptuală și diagramă de clasă, dezvoltarea unei interfețe cu utilizatorul și interogări de bază de date.

lucrare de curs, adăugată 06.08.2012


Selectarea compoziției hardware și software pentru dezvoltarea sistemului. Descrierea datelor de intrare și de ieșire. Selectarea unui model de bază de date. Dezvoltarea unui subsistem pentru completarea bazei de date și generarea de rapoarte. Dezvoltarea interfeței cu utilizatorul, testarea sistemului.

lucrare curs, adaugat 12.04.2014


Etapele creării și dezvoltării bazei de date. Construirea unui model de domeniu. Dezvoltarea datalogică și modele fizice date, metode de prelucrare a datelor despre angajații organizației. Proiectarea aplicațiilor utilizator. Crearea unui formular de buton.

lucrare de curs, adăugată 14.02.2011


Întocmirea unei diagrame conceptuale a modelului de date. Dezvoltarea structurii bazei de date relaționale și a interfeței cu utilizatorul. Caracteristicile principalelor etape ale proiectării bazei de date. Metode de implementare a interogărilor și rapoartelor. Specificații ale manualului de utilizare.

lucrare de curs, adăugată 18.12.2010


Procesul de dezvoltare a unei baze de date pentru stocarea și procesarea informațiilor. Chei, indexuri, declanșatoare, proceduri stocate. Interfata utilizator si dezvoltare baze de date. Instrumente de bază pentru dezvoltarea părților client și server.

teză, adăugată 18.05.2013


Etapele proiectării bazei de date, definirea scopurilor și a conținutului tabelului. Adăugarea de date și crearea altor obiecte de bază de date. Model datalogic: structurare, normalizare, scheme de date. Ordinea și principiile creării unei interfețe cu utilizatorul.

lucrare curs, adaugat 26.03.2013


Tehnologia de dezvoltare a interfeței cu utilizatorul în Mediul Delphi. Crearea de tabele, meniuri, formulare pentru introducerea și editarea datelor. Principiile organizării meniurilor ca element al interfeței cu utilizatorul. Implementarea sortării, filtrarii, calculelor în tabel.

lucrare de curs, adăugată 13.11.2012


Reguli de bază pentru proiectarea interfeței cu utilizatorul. Crearea unei baze de date folosind modelele dezvoltate. Codarea modulelor sistem softwareîn scopul realizării unui prototip. Fereastra principală când pornește programul. Protecție împotriva pierderii de informații.

lucru de laborator, adaugat 13.06.2014


Descrierea domeniului de dezvoltare. Caracteristici de stocare a informațiilor despre mașini și proprietari. Descrierea structurii bazei de date. Tabelele principale: mașini, proprietari, tipuri de lucrări, piese de schimb, comenzi, servicii. Instrucțiuni pentru programator și utilizator.

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 bazelor de date.

1. Introducere.

Dacă intenționați să vă construiți propriile baze de date, este o idee bună să urmați instrucțiunile de proiectare a bazei 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ă recuperați cantități mari de informatii 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 luat 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ă Instalări 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. Acest utilitate gratuită Cu interfata grafica. Imaginile tabelului din acest manual sunt preluate de acolo.

Modelare vizuală.

Există un mare gratuit aplicație MySQL Banc de lucru. 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 ghid 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. Program de citire 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 de 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 în acest caz, acesta este titlul și categoria lui.

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. Voia să-și depășească neajunsurile model de rețea baze de date și model 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 multe sisteme cunoscute managementul bazelor de date relaționale (RDBMS):

- Oracol– folosit în principal pentru aplicații profesionale, mari.
- Microsoft SQL Server – RDBMS Microsoft. Disponibil numai pentru sistemul de operare Windows.
- mysql– un RDBMS foarte popular cu sursă deschisă cod sursa. 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 salvare rapidași obținerea unor 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 (incrementare automat) (1,2,3,4 etc.). Datele din tabele diferite 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 recuperate 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 în bun proiect Bază 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 unicitatea valorii înregistrărilor în această coloană. Ultima restricție este adesea folosită pentru câmpurile care conțin nume de înregistrare a utilizatorilor (autentificări) sau adrese 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 anumiți utilizatori. Unele 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 Declarație SQL A TE ALATURA. 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 stocarea rezultatelor deciziei. această problemă 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.