Meniul
AcasăCuvânt

Exemplu de proiectare a bazei de date. Universitatea de Stat din Amur. Etapele de proiectare a bazei de date

La dezvoltarea unei baze de date se pot distinge următoarele etape de lucru.

Etapa I. Formularea problemei.

În această etapă, este generată o sarcină pentru crearea unei baze de date. Descrie în detaliu compoziția bazei de date, scopul și scopul creării acesteia și, de asemenea, enumeră ce tipuri de lucrări ar trebui efectuate în această bază de date (selectare, adăugare, modificare a datelor, tipărire sau emitere a unui raport etc. ).

Etapa II. Analiza obiectelor.

În această etapă, luăm în considerare din ce obiecte poate consta baza de date și care sunt proprietățile acestor obiecte. După împărțirea bazei de date în obiecte individuale este necesar să se ia în considerare proprietățile fiecăruia dintre aceste obiecte sau, cu alte cuvinte, să se stabilească prin ce parametri este descris fiecare obiect. Toate aceste informații pot fi aranjate sub formă de înregistrări și tabele separate. În continuare, trebuie să luăm în considerare tipul de date al fiecărei unități de înregistrare individuale. Informațiile despre tipurile de date ar trebui incluse și în tabelul pe care îl creați.

Etapa III. Sinteza modelului.

În această etapă, conform analizei de mai sus, este necesar să se selecteze un anumit model DB. În continuare, sunt luate în considerare avantajele și dezavantajele fiecărui model și se compară cu cerințele și obiectivele bazei de date în curs de creare. După o astfel de analiză, este selectat un model care poate asigura cel mai bine implementarea sarcinii. După alegerea unui model, trebuie să desenați diagrama acestuia indicând relațiile dintre tabele sau noduri.

Etapa IV. Selectarea metodelor de prezentare a informațiilor și a instrumentelor software.

După crearea modelului, este necesar, în funcție de produsul software selectat, să se determine forma de prezentare a informațiilor.

În majoritatea SGBD-urilor, datele pot fi stocate în două tipuri:

  • utilizarea formularelor;
  • fără a folosi formulare.

Formă este creat de utilizator GUI pentru a introduce date în baza de date.

etapa V. Sinteză model de calculator obiect.

În procesul de creare a unui model de computer, există câteva etape care sunt tipice pentru orice SGBD.

Etapa 1. Lansarea DBMS, crearea unui nou fișier de bază de date sau deschiderea unei baze de date create anterior.

Etapa 2. Creați tabelul sau tabelele inițiale.

Când creați tabelul sursă, trebuie să specificați numele și tipul fiecărui câmp. Numele câmpurilor nu trebuie repetate în același tabel. În timp ce lucrați cu baza de date, puteți adăuga câmpuri noi la tabel. Tabelul creat trebuie salvat, dându-i un nume unic în baza de date creată.

1. Informațiile din tabel nu trebuie duplicate. Nu ar trebui să existe repetări între mese. Când anumite informații sunt stocate într-un singur tabel, atunci acestea vor trebui modificate doar într-un singur loc. Acest lucru face munca mai eficientă și, de asemenea, elimină posibilitatea nepotrivirii informațiilor între acestea mese diferite Oh. De exemplu, un tabel ar trebui să conțină adresele clienților și numerele de telefon.

2. Fiecare tabel trebuie să conțină informații despre un singur subiect. Informațiile despre fiecare subiect sunt mult mai ușor de procesat dacă sunt conținute în tabele care sunt independente unele de altele. De exemplu, este mai bine să stocați adresele clienților și comenzile în tabele diferite, astfel încât atunci când o comandă este ștearsă, informațiile despre client să rămână în baza de date.

3. Fiecare tabel trebuie să conțină câmpurile obligatorii. Fiecare câmp din tabel trebuie să conțină informații separate despre subiectul tabelului. De exemplu, un tabel cu date despre clienți poate conține câmpuri pentru numele companiei, adresa, orașul, țara și numărul de telefon. Când proiectați câmpuri pentru fiecare tabel, trebuie să vă amintiți că fiecare câmp trebuie să fie legat de subiectul tabelului. Nu este recomandat să includeți date într-un tabel care este rezultatul unei expresii. Tabelul trebuie să conțină toate informatie necesara. Informațiile ar trebui să fie împărțite în cele mai mici unități logice (de exemplu, câmpurile Prenume și Nume, mai degrabă decât un câmp general Prenume).

4. Baza de date trebuie să aibă o cheie primară. Acest lucru este necesar pentru ca SGBD să poată lega date din tabele diferite, de exemplu, datele clienților și comenzile acestuia.

Etapa 3. Crearea de formulare de ecran.

Inițial, trebuie să specificați tabelul pe baza căruia va fi creat formularul. Îl puteți crea folosind vrăjitorul de formulare, specificând ce tip ar trebui să aibă, sau îl puteți crea singur. Când creați un formular, puteți specifica nu toate câmpurile pe care le conține tabelul, ci doar câteva dintre ele. Numele formularului poate fi același cu numele tabelului pe care a fost creat. Pe baza unui tabel, puteți crea mai multe formulare, care pot diferi prin tipul sau numărul de câmpuri utilizate din acest tabel. După crearea formularului, trebuie să-l salvați. Formularul creat poate fi editat prin modificarea locației, mărimii și formatului câmpurilor.

Etapa 4. Completarea bazei de date.

Procesul de completare a bazei de date poate fi efectuat în două forme: sub formă de tabel și sub formă de formular. Numerică și câmpuri de text poate fi completat ca un tabel, iar câmpuri precum MEMO și OLE - ca un formular.

Etapa VI. Lucrul cu baza de date creată.

Lucrul cu baza de date include următoarele acțiuni:

  • căutarea informațiilor necesare;
  • sortarea datelor;
  • selectarea datelor;
  • imprimare;
  • modificarea și adăugarea datelor.

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 analizarea acesteia din punct de vedere public ț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 î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 conceptului ( model informativ) presupune formarea preliminară a cerințelor conceptuale ale utilizatorilor, inclusiv cerințe pentru aplicații care pot să nu fie implementate imediat, dar luând în considerare care vor î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 resurse 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 instrumente software. După aceasta, modelul conceptual trebuie transferat la un model de date compatibil cu sistemul de management selectat. Dar, adesea, aceasta implică efectuarea de modificări și modificări ale modelului conceptual, deoarece interconexiunile dintre obiectele reflectate în modelul conceptual nu pot fi întotdeauna implementate folosind mijloacele unui SGBD dat.

Această împrejurare determină apariția 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).

În cele din urmă, etapa finală a proiectării bazei de date este proiectarea fizică - etapa de conectare structura logicaș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 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 informaţional al domeniului subiectului în ușor de utilizatîn termeni care nu depind de implementarea specifică a bazei de date, sunt descrise structura și proprietățile dinamice ale domeniului subiectului. 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 utilizat dacă funcțiile și sarcinile persoanelor care, cu ajutorul bazei de date proiectate, își vor servi nevoi de informare.
  2. Abordarea subiectului se concentrează pe informații despre informațiile care vor fi conținute în baza de date, în ciuda faptului că structura interogării poate să nu fie definită. În acest caz, cercetarea pe un domeniu se concentrează pe afișarea sa cea mai adecvată în baza de date în contextul întregii game de solicitări de informații așteptate.
  3. O abordare integrată folosind metoda „entitate-relație” combină avantajele celor două anterioare. Metoda se reduce la împărțirea întregii zone a subiectului în părți locale, care sunt modelate separat și apoi recombinate într-o zonă întreagă.

Deoarece utilizarea metodei entitate-relație este o metodă de proiectare combinată pentru în această etapă, devine o prioritate mai des decât altele.

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 de proprietăți specifice) și conceptul de „tip de entitate” - un obiect pentru care este caracteristic denumirea 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, se specifică conexiunile în vizualizarea locală (împărțită în opțional și obligatoriu) și se îmbină vizualizările locale.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 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, 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 presupune identificarea unui număr de entități de nivel înalt și a relațiilor acestora cu detalierea ulterioară la nivelul cerut, ceea ce se reflectă, de exemplu, într-un model creat pe baza metodei „entitate-relație”. Dar, în practică, ambele abordări sunt de obicei combinate.

Proiectarea bazei de date fizice

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

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

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

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

  • pentru ca tranzacțiile să funcționeze eficient, trebuie să rezervați spațiu pe disc pentru obiecte temporare,
  • pentru a crește viteza de căutare, trebuie să creați indecși, al căror număr este determinat de numărul tuturor combinațiilor posibile de câmpuri implicate în căutare,
  • pentru 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 proiectării imediate a bazei de date.

Curs 8. Etapele proiectării bazei de date

Este imposibil să creați o bază de date fără o descriere detaliată a acesteia, la fel cum nu este posibil să faceți niciun produs complex fără un desen și o descriere detaliată a tehnologiilor pentru producerea acestuia. Cu alte cuvinte, avem nevoie de un proiect. Proiect Este în general acceptat să se ia în considerare o schiță a unui dispozitiv, care ulterior va fi tradusă în realitate.

Procesul de proiectare a bazei de date este un proces de tranziții de la descrierea verbală informală structura informatiei domeniul subiectului la o descriere formală a obiectelor domeniului subiectului în termenii unui anumit model. Scopul final al designului este construirea unei baze de date specifice. Evident, procesul de proiectare este complex și, prin urmare, are sens să îl împărțim în părți finalizate logic - etape.

Există cinci etape principale ale proiectării bazei de date:

1. Colectarea de informații și analiza de sistem a domeniului subiect.

2. Design infologic.

3. Selectarea unui SGBD.

4. Proiectare datalogică.

5. Design fizic.

Colectarea de informații și analiza de sistem a domeniului subiect - acesta este primul și etapa cea mai importantă la proiectarea unei baze de date. Este necesar să se realizeze o descriere verbală detaliată a obiectelor domeniului de studiu și a legăturilor reale prezente între obiectele reale. Este de dorit ca descrierea să definească relațiile dintre obiectele din domeniul subiectului.

ÎN caz general Există două abordări pentru alegerea compoziției și structurii unui domeniu:

· Abordare funcțională – este utilizat atunci când funcțiile unui anumit grup de persoane și seturile de sarcini pentru care este creată această bază de date sunt cunoscute în prealabil, i.e. minim este clar vizibil set necesar obiecte ale domeniului subiectului pentru descriere.

· Abordarea subiectului – atunci când nevoile de informații ale clienților bazei de date nu sunt clar înregistrate și pot fi multidimensionale și dinamice. ÎN în acest caz, set minim Este dificil să selectați obiecte de domeniu. Descrierea domeniului subiectului include astfel de obiecte și relații care sunt cele mai caracteristice și esențiale pentru aceasta. În același timp, baza de date devine specifică subiectului și este potrivită pentru rezolvarea multor probleme (ceea ce pare cel mai tentant). Cu toate acestea, dificultatea acoperirii universale a domeniului subiectului și imposibilitatea de a specifica nevoile utilizatorilor duce la redundanță schema complexa O bază de date care va fi ineficientă pentru unele sarcini.

Analiza sistemului trebuie să se încheie descriere detaliata informații despre obiecte din domeniul subiectului, care ar trebui să fie stocate în baza de date, odată cu formularea sarcini specifice, care va fi rezolvată folosind această bază de date cu descriere scurta algoritmi pentru soluția lor, descrierea documentelor de ieșire și de intrare atunci când lucrați cu baza de date.

Design infologic – o descriere parțial formalizată a obiectelor din domeniul de studiu în termenii unui anumit model semantic.

De ce este necesar un model de informații și de ce beneficiază proiectanții? Faptul este că procesul de proiectare este lung și necesită discuții cu clientul și experții în domeniu. În plus, atunci când se dezvoltă serioase corporative sisteme de informare proiectul bazei de date este fundația pe care se construiește întregul sistem în ansamblu, iar problema posibilității de împrumut este adesea decisă de experții băncii pe baza unui proiect de bază de date informaționale bine realizat. În consecință, modelul informațional ar trebui să includă o astfel de descriere formalizată a domeniului subiectului care să fie ușor de perceput nu doar de specialiștii bazelor de date. Descrierea ar trebui să fie atât de mare încât să se poată evalua profunzimea și corectitudinea dezvoltării proiectului de bază de date.

Astăzi, cel mai utilizat model este modelul „Ensity-Relationship” al lui Chen ( Relația cu entitate ), a devenit standardul de facto în modelarea informațiilor și a fost numit ER – model.

Selectarea unui SGBD se desfășoară pe baza diferitelor cerințe pentru baza de date și, în consecință, a capacităților SGBD, precum și în funcție de experiența existentă a dezvoltatorilor.

Proiectare datalogică există o descriere a bazei de date în termenii modelului de date logic de date acceptat. În bazele de date relaționale, proiectarea datalogică sau logică duce la dezvoltarea schemei bazei de date, adică. seturi de scheme de relații care modelează în mod adecvat obiectele din domeniul de studiu și relațiile semantice dintre obiecte. Baza pentru analiza corectitudinii unui circuit este dependențe funcționaleîntre atributele bazei de date. În unele cazuri, pot apărea dependențe nedorite între atributele relației, care provoacă efecte secundare și anomalii la modificarea bazei de date. Sub modificareînțelege introducerea de date noi în baza de date, ștergerea datelor din baza de date, precum și actualizarea valorilor unor atribute. Pentru a elimina eventualele anomalii, este planificată normalizarea relațiilor cu bazele de date.

Etapa de proiectare logică nu este doar despre proiectarea diagramei relațiilor. Ca urmare a acestei etape, de regulă, trebuie obținute următoarele documente rezultate:

· Descrierea schemei conceptuale a bazei de date în termeni de SGBD selectat.

· Descriere modele externeîn ceea ce privește SGBD selectat.

· Descrierea regulilor declarative pentru menținerea integrității bazei de date.

· Dezvoltarea procedurilor de menținere a integrității semantice a bazei de date.

Design fizic consta in legarea structurii logice a bazei de date si a mediului fizic de stocare pentru a plasa cat mai eficient datele, i.e. maparea structurii logice a bazei de date în structura de stocare. Problema plasării datelor stocate în spațiul de memorie, selectând metode eficiente acces la diverse componente baza de date „fizică”, problemele sunt rezolvateasigurarea securității și securității datelor.Sunt implementate constrângeri în modelul de date logic prin diverse mijloace DBMS, de exemplu, folosind indecși, constrângeri de integritate declarativă, declanșatoare, proceduri stocate. În același timp, din nou, deciziile luate la nivelul modelării logice determină niște limite în cadrul cărora este posibil să se dezvolte model fizic date. La fel, în aceste limite se poate accepta diverse solutii. De exemplu, relațiile conținute în modelul de date logic trebuie convertite în tabele, dar pentru fiecare tabel puteți declara suplimentar diverși indici, crescând viteza de acces la date.

in afara de asta , funcțiile pot fi folosite pentru a îmbunătăți performanța procesare paralelă date. Ca urmare, baza de date poate fi localizată pe mai multe calculatoare din rețea. Pe de altă parte, pot fi utilizate avantajele sistemelor multiprocesor.

Pentru a asigura siguranța și securitatea datelor, problemele de recuperare după eșecuri sunt rezolvate, Rezervă copie informații, configurarea sistemelor de protecție pentru a se potrivi cu politica de securitate selectată etc.

Trebuie remarcat faptul că unele moderne SGBD relațional folosesc în principal structuri fizice și metode de acces bazate pe tehnologia de proiectare a fișierelor, care elimină în esență problema designului fizic.

Astfel, este clar că deciziile luate în fiecare etapă a modelării și dezvoltării bazei de date vor afecta etapele ulterioare. De aceea acceptarea joacă un rol deosebit decizii corecte în fazele incipiente ale modelării.

Întrebări de control

1. Ce este un proiect?

2. Ce etape ale proiectării bazei de date se disting de obicei?

3. Care este scopul analizei sistemelor?

4. Ce abordări pot fi utilizate în analiza de sistem a unui domeniu?

5. Care este etapa de proiectare a informațiilor?

6. Care este diferența dintre etapele infologice și datalogice ale proiectării?

7. Ce documente și modele trebuie obținute la finalizarea etapei de proiectare a științei datelor?

8. Prezentați rezultatele proiectării fizice.

Sarcini pentru muncă independentă

Citiți cu atenție exemplul de descriere a domeniului și stabiliți care puncte principale sunt definite în descriere și care ar putea să nu fie. A trage concluzii.

Un exemplu de descriere a domeniului subiect al proiectului „Bibliotecă”.

Să presupunem că trebuie să dezvoltați un sistem informatic pentru a automatiza contabilitatea primirii și emiterii cărților într-o bibliotecă. Sistemul trebuie să ofere moduri pentru menținerea unui catalog de sistem care să reflecte lista domeniilor de cunoștințe pentru care cărțile sunt disponibile în bibliotecă. În cadrul unei biblioteci, zonele de cunoștințe dintr-un catalog sistematic pot avea un unic număr de interiorși numele complet. Fiecare carte poate conține informații din mai multe domenii de cunoaștere. Fiecare carte din bibliotecă poate fi prezentă în mai multe exemplare. Fiecare carte stocată în bibliotecă este caracterizată de următorii parametri:

· cifru unic;

· Nume;

· locul publicării (oraș);

· Editura;

· anul publicării;

· număr de pagini;

· costul cărții;

· numărul de exemplare ale unei cărți din bibliotecă.

Cărțile pot avea aceleasi nume, dar diferă prin cifra lor unică (ISBN).

Biblioteca menține un index al cititorilor.

Următoarele informații sunt introduse în indexul cardului pentru fiecare cititor:

· Numele complet;

· adresa de acasa;

· Data nașterii.

Fiecărui cititor i se atribuie un număr unic de card de bibliotecă. Fiecare cititor nu poate deține mai mult de 5 cărți simultan. Un cititor nu trebuie să dețină mai mult de un exemplar al unei cărți cu același titlu la un moment dat.

Fiecare carte din bibliotecă poate fi prezentă în mai multe exemplare. Fiecare instanță are următoarele caracteristici:

· număr unic de inventar;

· cifrul cărții, care se potrivește cu cifrul unic din descrierea cărții;

· locație în bibliotecă.

Dacă o copie a unei cărți este eliberată unui cititor, biblioteca păstrează un insert special în care trebuie să fie înregistrate următoarele informații:

· numărul de bilet al cititorului care a luat cartea;

· data emiterii cărții;

· data întoarcerii.

Furnizați următoarele restricții pentru informații din sistem:

2. Biblioteca trebuie să aibă cititori înregistrați care au cel puțin 17 ani.

3. Biblioteca conține cărți publicate din 1960 până în anul curent.

4. Fiecare cititor nu poate deține mai mult de 5 cărți.

5. La înscrierea la bibliotecă, fiecare cititor trebuie să furnizeze un număr de telefon pentru comunicare: poate fi la serviciu sau acasă.

6. Fiecare domeniu de cunoaștere poate conține referințe la multe cărți, dar fiecare carte se poate referi la diverse zone cunoştinţe.

Trebuie să lucreze cu acest sistem informatic următoarele grupuri utilizatori:

· bibliotecari;

· cititori;

· administrarea bibliotecii,

Când lucrează cu sistemul, bibliotecarul ar trebui să fie capabil să rezolve următoarele sarcini:

1. Acceptați cărți noi și înregistrați-le în bibliotecă.

2. Atribuiți cărțile uneia sau mai multor domenii de cunoaștere.

3. Catalog cărți, adică atribuiți noi numere de inventar cărților nou acceptate și, așezându-le pe rafturile bibliotecii, amintiți-vă locația fiecărui exemplar.

4. Efectuați catalogarea suplimentară dacă au fost primite mai multe exemplare ale unei cărți care se află deja în bibliotecă, în timp ce informațiile despre carte nu sunt introduse în catalogul de subiecte, iar fiecărui exemplar nou i se atribuie un nou număr de acces și un loc pe raftul bibliotecii îi este atribuit.

5. Ștergeți cărțile vechi și mai puțin solicitate. Doar cărțile pot fi copiate dacă cititorii nu au o singură copie a acestora. Radiațiile se efectuează conform unui act special de radiere, care este aprobat de administrația bibliotecii.

6. Păstrați evidența cărților emise cititorilor, în acest caz se presupun două moduri de funcționare: eliberarea cărților către cititor și primirea cărților returnate de la acesta înapoi la bibliotecă. La emiterea cărților, se înregistrează când și ce exemplar al cărții a fost eliberat unui anumit cititor și până la ce oră cititorul trebuie să returneze acest exemplar al cărții. La emiterea cărților, disponibilitatea unui exemplar gratuit și a acestuia număr specific poate fi determinat printr-un anumit cod unic de carte sau numărul de inventar poate fi cunoscut în prealabil. Nu este necesar să se mențină o „istorie” a cărților de citit, adică se cere să reflecte doar starea actuală a bibliotecii. La acceptarea unei cărți returnate de un cititor, numărul de inventar returnat al cărții este verificat pentru a se potrivi cu numărul de inventar emis și este plasat în locul vechi pe raftul bibliotecii.

7. Şterge cărţile pierdute de cititor conform unui act special de radiere sau înlocuire semnat de administraţia bibliotecii.

8. Închideți abonamentul cititorului, adică distrugeți datele despre el, dacă cititorul dorește să iasă din bibliotecă și nu este debitorul acesteia, adică nu are o singură carte de bibliotecă.

Cititorul ar trebui să fie capabil să rezolve următoarele probleme:

1. Vizualizați catalogul de sistem, adică o listă cu toate domeniile de cunoștințe pentru care cărțile se află în bibliotecă.

2. Pentru domeniul de cunoștințe ales, obțineți o listă completă a cărților care sunt listate în bibliotecă.

3. Pentru cartea selectată, obțineți numărul de inventar al unei copii gratuite a cărții sau un mesaj că nu există copii gratuite ale cărții. Dacă nu există copii disponibile ale unei cărți, cititorul ar trebui să poată afla data următoarei returnări așteptate a unei copii a acestei cărți. Cititorul nu poate afla informații despre cine are în prezent copii ale acestei cărți sunt la îndemână (pentru a asigura siguranța personală a deținătorilor cărții solicitate).

Administrația bibliotecii ar trebui să poată obține informații despre cititorii bibliotecii debitori care nu au returnat cărțile împrumutate la timp; informații despre cărți care nu sunt populare, adică nici un singur exemplar

care nu sunt în mâinile cititorilor; informații despre costul unei anumite cărți pentru a stabili posibilitatea rambursării costului unei cărți pierdute sau posibilitatea înlocuirii acesteia cu o altă carte; informații despre cele mai populare cărți, adică acelea ale căror copii sunt toate în mâinile cititorilor.

Acesta este complet mic exemplu arată că înainte de a începe dezvoltarea este necesar să avem o idee exactă a ceea ce ar trebui să fie efectuat în sistemul nostru, ce utilizatori vor lucra în el, ce sarcini va rezolva fiecare utilizator. Și asta este corect, pentru că atunci când construim o clădire, ne asumăm și în avans; în ce scop este destinat, în ce climă va sta, pe ce sol și în funcție de aceasta, designerii ne pot oferi cutare sau cutare proiect. Dar, din păcate, de foarte multe ori în legătură cu bazele de date se crede că totul poate fi determinat ulterior, când proiectul de sistem a fost deja creat. Absența unor obiective clare pentru crearea unei baze de date poate anula toate eforturile dezvoltatorilor, iar proiectul bazei de date se va dovedi a fi „rău”, incomod și nu corespunde nici obiectului real care se modelează, nici sarcinilor care ar trebui rezolvate. folosind această bază de date.

Procesul de proiectare a bazei de date este o secvență de tranziții de la o descriere verbală informală a structurii informaționale a unui domeniu la o descriere formalizată a obiectelor software în termenii unui anumit model. În general, se pot distinge următoarele etape de proiectare:

eu. Analiza sistemului și descrierea verbală a obiectelor informaționale software. Există două abordări pentru alegerea compoziției și structurii unui domeniu:

· Abordare funcțională. Implementează principiul mișcării „din sarcini” și este utilizat atunci când sunt cunoscute funcțiile unui anumit grup de oameni și seturi de sarcini, pentru a servi nevoilor de informații pentru care este creată o bază de date. În acest caz, este posibil să se identifice clar setul minim necesar de obiecte care trebuie descrise.

· Abordarea subiectului. Nevoile de informare ale viitorilor utilizatori nu sunt strict fixate. Este imposibil să selectați setul minim necesar de obiecte care trebuie descrise. În acest caz, descrierea software-ului include astfel de obiecte și relații care sunt cele mai caracteristice și esențiale pentru acesta. Baza de date proiectată se numește bază de date subiect și poate fi utilizată pentru multe sarcini diferite, predeterminate. Această abordare pare a fi cea mai promițătoare, dar poate duce la redundanța sarcinii sau a nevoilor utilizatorului și, pe de altă parte, ia în considerare posibilitatea de a crește noi aplicații.

II. Proiectarea unui model informatic software. Sarcina etapei de proiectare infologică este de a obține modele de date semantice (semnificative) (de exemplu, în ceea ce privește modelele ER) care afișează conținutul informațional al unui software specific. În primul rând, partea necesară a software-ului este izolată de realitatea percepută, limitele sale sunt determinate și părțile neimportante sunt extrase pentru o aplicație specifică a bazei de date. Ca urmare, obiectele, proprietățile și relațiile lor sunt determinate care vor fi semnificative pentru viitorii utilizatori ai sistemului.

III. Proiectarea bazei de date datalogice sau logice, adică descrierea bazei de date în termenii modelului de date logic de date acceptat (de exemplu, relațional). Sarcina etapei de proiectare logică este de a organiza datele selectate în etapa anterioară într-o formă care este acceptată în SGBD-ul specific selectat, folosind tipurile și modelele de date ale acestuia. Sunt oferite recomandări pentru alegerea metodelor de acces la date.

IV. Proiectarea bazei de date fizice, adică alegerea unui plasament eficient al bazei de date pe medii externe pentru a asigura cel mai mult munca eficienta aplicatii. Sarcina etapei de proiectare fizică este de a selecta o structură rațională de stocare a datelor. și metode de accesare a acestora, bazate pe arsenalul de instrumente și metode pe care un anumit DBMS le oferă dezvoltatorului.

La proiectarea unei baze de date sunt rezolvate două probleme principale:

    Cum să mapați obiectele de domeniu la obiecte abstracte ale modelului de date? Această problemă se numește problema de proiectare a bazei de date logică.

    Cum să asigurați execuția eficientă a interogărilor bazei de date, de ex. cum, ținând cont de caracteristicile unui anumit SGBD, să aranjați datele în memorie externa, ce structuri suplimentare (de exemplu, indecși) ar trebui create etc.? Această problemă se numește problema de proiectare a bazei de date fizice.

În cazul bazelor de date relaționale, este dificil să se ofere rețete generale pentru proiectarea fizică. Aici prea mult depinde de SGBD utilizat. Prin urmare, ne vom limita la problemele de proiectare logică a bazelor de date relaționale, care sunt esențiale atunci când se utilizează orice SGBD relațional.

Mai mult, nu vom atinge un aspect foarte important al designului - definirea constrângerilor de integritate (cu excepția constrângerii cheii primare). Faptul este că atunci când se utilizează un SGBD cu mecanisme dezvoltate de constrângere a integrității (de exemplu, sisteme orientate spre SQL), este dificil să se propună vreo abordare generală pentru definirea constrângerilor de integritate. Aceste restricții pot fi foarte forma generala, iar formularea lor până acum se referă mai mult la domeniul artei decât la competența inginerească. Cel mai mult care se propune în acest sens în literatura de specialitate este o verificare automată a consistenței unui set de constrângeri de integritate.

    din ce relaţii ar trebui să constea baza de date şi

    ce atribute ar trebui sa aiba aceasta relatie?

Există trei abordări principale pentru proiectarea bazelor de date:

1. colectarea de informații despre obiectele problemei care se rezolvă în cadrul unui singur tabel și descompunerea lui ulterioară în mai multe tabele interdependente pe baza procedurilor de normalizare ( metoda clasica);

2. trecerea de la modelul semantic (infologic) al etapei a doua folosind instrumentele CASE la diagramă gata făcută DB sau chiar un sistem informatic pentru aplicații (IS) gata făcut;

3. structurarea informațiilor pentru utilizare în sistemele informaționale în procesul de realizare a analizei de sistem pe baza unui set de reguli practice și recomandări.

În primul rând, vom lua în considerare abordarea clasică, în care întregul proces de proiectare este realizat în termenii unui model de date relaționale prin metoda aproximărilor succesive la un set satisfăcător de modele de relații. Punctul de plecare este reprezentarea software-ului sub forma uneia sau mai multor relații, iar la fiecare pas de proiectare este produs un anumit set de diagrame de relații cu cele mai bune proprietăți. Procesul de proiectare este un proces de normalizare a modelelor de relații, fiecare formă normală ulterioară având proprietăți mai bune decât cea anterioară.

În teoria bazelor de date relaționale, se distinge de obicei următoarea secvență de forme normale:

    prima formă normală (1NF);

    a doua formă normală (2NF);

    a treia formă normală (3NF);

    forma normală Boyce-Codd (BCNF);

    a patra formă normală (4NF);

    a cincea formă normală (5NF sau PJ/NF).

Proprietățile de bază ale formelor normale:

    fiecare formă normală succesivă este într-un fel mai bună decât cea anterioară;

    la trecerea la următoarea forma normala se păstrează proprietăţile proprietăţilor normale anterioare.

Procesul de proiectare se bazează pe metoda normalizării, descompunerea unei relații găsite într-o formă normală anterioară în două sau mai multe relații care satisfac cerințele următoarei forme normale.

Cele mai importante forme normale de relații în practică se bazează pe conceptul fundamental în teoria bazelor de date relaționale dependenta functionala. Pentru o discuție ulterioară vom avea nevoie de mai multe definiții.

Definiția 1. Dependenta functionala

În ceea ce privește R, atributul Y este dependent funcțional de atributul X (X și Y pot fi compus) dacă și numai dacă fiecare valoare a lui X corespunde exact unei valori a lui Y: R.X ->R.Y.

Definiția 2 . Dependență funcțională completă

O dependență funcțională R.X ->R.Y se spune că este completă dacă atributul Y nu depinde funcțional de niciun subset exact al lui X.

Definiția 3. Dependență funcțională tranzitivă

O dependență funcțională R.X -> R.Y se numește tranzitivă dacă există un atribut Z astfel încât există dependențe funcționale R.X -> R.Z și R.Z -> R.Y și nu există dependență funcțională R.Z -/-> R.X.

Definiția 4. Atribut non-cheie

Un atribut non-cheie este orice atribut al unei relații care nu face parte din cheia primară (în special, cheia primară).

Definiția 5 . Atribute independente reciproc

Două sau mai multe atribute sunt reciproc independente dacă niciunul dintre atribute nu este dependent funcțional de celelalte.

Deoarece cerința primei forme normale este o cerință de bază a modelului relațional clasic date, vom presupune că setul inițial de relații îndeplinește deja această cerință, i.e. toate atributele sunt atomice. Dacă tabelul conține atribute compuse, atunci îl puteți converti în 1NF folosind algoritm de normalizare propus de E. Codd:

    începând cu tabelul sursă, luați-i cheia primară și adăugați-o la fiecare tabel copil (atribut compus);

    Cheia primară a fiecărui tabel extins constă din cheia primară a tabelului copil și cheia primară părinte adăugată;

    după aceasta, toate atributele non-simple sunt șterse din tabelul părinte, iar această procedură se repetă pentru fiecare dintre tabelele subordonate;

    condiția pentru sfârșitul algoritmului este atomicitatea tuturor atributelor.

Exemplul 5.1 Să considerăm ca domeniu de studiu o organizație care derulează unele proiecte. Descriem modelul de domeniu în următorul text informal:

    Angajații organizației realizează proiecte.

    Proiectele constau din mai multe sarcini.

    Fiecare angajat poate participa la unul sau mai multe proiecte sau nu poate participa temporar la niciun proiect.

    La fiecare proiect pot lucra mai mulți angajați, sau proiectul poate fi suspendat temporar, apoi niciun angajat nu lucrează la el.

    Exact un angajat lucrează la fiecare sarcină din proiect.

    Fiecare angajat este înregistrat într-un singur departament.

    Fiecare angajat are un telefon situat în departamentul angajatului.

Pe parcursul clarificării ulterioare a datelor care trebuie luate în considerare, au devenit clare următoarele:

    Fiecare angajat trebuie să aibă un număr de personal. Numărul de personal este unic pentru fiecare angajat.

    Fiecare departament are un număr unic.

    Fiecare proiect are un număr. Numărul proiectului este unic.

    Fiecare sarcină din proiect are un număr care este unic în cadrul proiectului.

Să ne imaginăm o diagramă de relații (toate informațiile într-un singur tabel):

SALARIATI-DEPARTAMENTE-PROIECTE

(COTR_NUMBER, COTR_ZARP, DEPARTMENT_NUMBER, PRO_NUMBER, COTR_SET)

Cheia principala:

COTR_NUMBER, PRO_NUMBER

Dependențe funcționale:

COTR_NUMBER -> COTR_ZARP

COTR_NUMBER -> DEPARTMENT_NUMBER

DEPARTMENT_NUMBER -> SOTR_ZARP

COTR_NUMBER, PRO_NUMBER -> COTR_JOB

După cum puteți vedea, deși cheia primară este atributul compus COTR_NUMBER, PRO_NUMBER, atributele COTR_ZARP și STD_NUMBER sunt dependente funcțional de o parte a cheii primare, atributul COTR_NUMBER. Ca urmare, nu vom putea insera în relația ANGAJATI-DEPARTAMENTE-PROIECTE un tuplu care descrie un angajat care nu lucrează încă la niciun proiect (cheia primară nu poate conține o valoare nulă). La ștergerea unui tuplu, nu numai că distrugem legătura acestui angajat cu acest proiect, dar pierdem informațiile că lucrează într-un anumit departament. Când transferăm un angajat într-un alt departament, vom fi forțați să modificăm toate tuplurile care descriu acest angajat, sau vom obține un rezultat inconsecvent. Se numesc astfel de fenomene neplăcute anomalii scheme de relații. Ele sunt eliminate prin normalizare.

Definiția 6 . A doua formă normală(aceasta definiție presupune că singura cheie a relației este cheia primară)

O relație R este în a doua formă normală (2NF) dacă și numai dacă este în 1NF și fiecare atribut non-cheie este complet dependent de cheia primară.

Puteți face următoarea descompunere a relației ANGAJATI-DEPARTAMENTE-PROIECTE în două relații ANGAJATE-DEPARTAMENTE și ANGAJATI-PROIECTE:

ANGAJAȚII-DEPARTAMENTE (COTR_NUMBER, COTR_SARP, DEPARTMENT_NUMBER)

Cheia principala:

COTR_NUMBER

Dependențe funcționale:

COTR_NUMBER -> COTR_ZARP

COTR_NUMBER -> DEPARTMENT_NUMBER

DEPARTMENT_NUMBER -> SOTR_ZARP

Cheia principala:

COTR_NUMBER, PRO_NUMBER

Dependențe funcționale:

COTR_NUMBER, PRO_NUMBER -> COTR_SET

Fiecare dintre aceste două relații este în 2NF și elimină anomaliile notate mai sus (este ușor de verificat că toate operațiunile specificate sunt efectuate fără probleme).

Să ne uităm din nou la relația ANGAJAT-DEPARTAMENT găsită în 2NF. Rețineți că dependența funcțională SOTR_NUMBER -> SOTR_ZARP este tranzitivă; este o consecință a dependențelor funcționale SOTR_NUMBER -> OTD_NUMBER și OTD_NUMBER -> SOTR_ZARP. Cu alte cuvinte, salariul unui angajat nu este de fapt o caracteristică a angajatului, ci a departamentului în care lucrează (aceasta nu este o presupunere foarte firească, dar suficientă pentru exemplu).

Ca urmare, nu vom putea introduce în baza de date informații care caracterizează salariul unui departament până când cel puțin un angajat apare în acest departament (cheia primară nu poate conține o valoare nedefinită). Dacă ștergem tuplul care descrie ultimul angajat al unui anumit departament, vom pierde informații despre salariul departamentului. Pentru a schimba salariul departamentului într-o manieră consistentă, va trebui mai întâi să găsim toate tuplurile care descriu angajații departamentului respectiv. Acestea. Mai sunt anomalii in ceea ce priveste SALARIATI-DEPARTAMENTE. Acestea pot fi eliminate printr-o normalizare ulterioară.

Definiția 7. A treia formă normală(Definiția este dată presupunând existența unei singure chei.)

O relație R este în a treia formă normală (3NF) dacă și numai dacă este în 2NF și fiecare atribut non-cheie nu este dependent tranzitiv de cheia primară.

Este posibil să se descompună relația ANGAJATI-DEPARTAMENTE în două relații ANGAJATE și DEPARTAMENTE:

ANGAJAȚI (JOB_NUMBER, DEPARTMENT_NUMBER)

Cheia principala:

COTR_NUMBER

Dependențe funcționale:

COTR_NUMBER -> DEPARTMENT_NUMBER

DEPARTAMENTE (DEPARTMENT_NUMBER, COTR_ZARP)

Cheia principala:

DTD_NUMBER

Dependențe funcționale:

DEPARTMENT_NUMBER -> SOTR_ZARP

Fiecare dintre aceste două relații este în 3NF și lipsită de anomaliile notate.

Dacă renunțăm la constrângerea că o relație are o singură cheie, definiția 3NF ia următoarea formă:

Definiția 7*

O relație R este în a treia formă normală (3NF) dacă și numai dacă este în 2NF și fiecare atribut non-cheie nu este dependent tranzitiv de nicio cheie a lui R.

În practică, a treia formă normală de diagrame de relații este suficientă în majoritatea cazurilor, iar prin reducerea la a treia formă normală a procesului de proiectare bază relațională datele se epuizează de obicei.

Cu toate acestea, uneori este utilă continuarea procesului de normalizare.

Exemplul 5.2 Luați în considerare următorul exemplu de diagramă de relații:

ANGAJATI-PROIECTE (JOB_NUMBER, JOB_NAME, PRO_NUMBER, JOB_TASK)

Chei posibile:

COTR_NUMBER, PRO_NUMBER

COTR_NAME, PRO_NUMBER

Dependențe funcționale:

COTR_NUMBER -> COTR_NAME

COTR_NUMBER -> PRO_NUMBER

CORR_NAME -> CORR_NUMBER

SOTR_NAME -> PRO_NUMBER

COTR_NUMBER, PRO_NUMBER -> COTR_SET

COTR_NAME, PRO_NUMBER -> COTR_JOB

În acest exemplu, presupunem că identitatea unui angajat este în întregime determinată atât de numărul, cât și de numele acestuia (din nou, aceasta nu este o presupunere foarte realistă, dar este suficient de bună de dragul exemplului).

Conform definiției 7*, relația ANGAJAT-PROIECT este în 3NF. Cu toate acestea, faptul că există dependențe funcționale ale atributelor de relație de un atribut care face parte din cheia primară duce la anomalii. De exemplu, pentru a schimba numele unui angajat cu un anumit număr într-o manieră consecventă, ar trebui să modificăm toate tuplurile care includ numărul său.

Definiția 8. Determinant

Un determinant este orice atribut de care un alt atribut este complet dependent din punct de vedere funcțional.

Definiția 9 . Forma normală Boyce-Codd

O relație R este în formă normală Boyce-Codd (BCNF) dacă și numai dacă fiecare determinant este o cheie candidată.

Evident, această cerință nu este îndeplinită pentru relația ANGAJAT-PROIECT. Îl puteți descompune în relațiile ANGAJATE și ANGAJATE-PROIECTE:

ANGAJATI (CORPORATE_NUMBER, CORPORATE_NAME)

Chei posibile:

COTR_NUMBER

Dependențe funcționale:

COTR_NUMBER -> COTR_NAME

COTR_NAME -> COTR_NUMBER

ANGAJATI-PROIECTE (COTR_NUMBER, PRO_NUMBER, COTR_TASK)

Cheie posibilă:

COTR_NUMBER, PRO_NUMBER

Dependențe funcționale:

COTR_NUMBER, PRO_NUMBER -> COTR_SET

O descompunere alternativă este posibilă dacă alegeți SOTR_NAME ca bază. În ambele cazuri, relațiile rezultate ANGAJAT și ANGAJAT-PROIECT sunt în BCNF și nu prezintă anomaliile notate.

Exemplul 5.3 Luați în considerare un exemplu din următoarea diagramă de relații:

PROIECTE (PRO_NUMBER, PRO_SOTR, PRO_TASKED)

Relația PROIECTE conține numere de proiect, pentru fiecare proiect o listă de angajați care pot realiza proiectul și o listă de sarcini prevăzute de proiect. Angajații pot participa la mai multe proiecte, iar proiecte diferite pot implica aceleași sarcini.

Fiecare tuplu de relație asociază un proiect cu un angajat care participă la acel proiect și cu o sarcină pe care angajatul o îndeplinește ca parte a acelui proiect (presupunem că orice angajat care participă la un proiect îndeplinește toate sarcinile pentru acel proiect). Datorită condițiilor formulate mai sus, singura cheie de relație posibilă este atributul compus PRO_NUMBER, PRO_COTR, ​​​​PRO_SET și nu există alți determinanți. Prin urmare, relația PROIECTE este în BCNF. Dar, în același timp, are și dezavantaje: dacă, de exemplu, un angajat se alătură unui proiect dat, este necesar să se introducă în relația PROIECTE atâtea tupluri câte sarcini există în ea.

Definiția 10 . Dependențe cu mai multe valori

În relația R (A, B, C), există o dependență multivalorică R.A -> -> R.B dacă și numai dacă mulțimea de valori B corespunzătoare unei perechi de valori A și C depinde numai de A și nu nu depind de C.

În legătură cu PROIECTE, există următoarele două dependențe cu mai multe valori:

PRO_NUMBER -> -> PRO_COTR

PRO_NUMBER -> -> PRO_SET

Este ușor de arătat că în cazul general, în relația R (A, B, C), există o dependență multivalorică R.A -> -> R.B dacă și numai dacă există o dependență multivalorică R.A -> -> R.C.

Normalizarea ulterioară a relațiilor similare cu relația PROIECTE se bazează pe următoarea teoremă:

teorema lui Fagin

Relația R(A,B,C) poate fi proiectată fără pierderi în relațiile R1(A,B) și R2(A,C) dacă și numai dacă MVD A -> -> B | C.

Proiecția fără pierderi se referă la o metodă de descompunere a relațiilor în care relația inițială este complet și fără redundanță restaurată printr-o conexiune naturală a relațiilor rezultate.

Definiția 11 . A patra formă normală

O relație R este în a patra formă normală (4NF) dacă și numai dacă, având în vedere existența unei dependențe multivalorice A -> -> B, toate celelalte atribute ale lui R sunt dependente funcțional de A.

În exemplul nostru, putem descompune relația PROIECTE în două relații PROIECTE-ANGAJATI și PROIECTE-SARCINI:

PROIECTE-COLABORAȚI (PRO_NUMBER, PRO_COTR)

PROIECTS-TASKS (PRO_NUMBER, PRO_TASK)

Ambele aceste rapoarte sunt în 4NF și lipsite de anomaliile notate.

În toate normalizările luate în considerare până în acest punct, a fost efectuată o descompunere a unei relații în două. Uneori acest lucru nu se poate face, ci descompunerea în număr mai mare relații, fiecare dintre ele având cele mai bune proprietăți.

Exemplul 5.4 Luați în considerare, de exemplu, relația

ANGAJATI-DEPARTAMENTE-PROIECTE (JOB_NUMBER, DEPARTMENT_NUMBER, PRO_NUMBER)

Să presupunem că același angajat poate lucra în mai multe departamente și poate lucra la mai multe proiecte în fiecare departament. Cheia primară a acestei relații este setul complet al atributelor sale; nu există dependențe funcționale sau cu mai multe valori.

Prin urmare, relația este în 4NF. Cu toate acestea, pot exista anomalii în el care pot fi eliminate prin descompunere în trei relații.

Definiția 12. Dependența de conexiune

Relația R (X, Y, ..., Z) satisface dependența de conexiune * (X, Y, ..., Z) dacă și numai dacă R este restaurat fără pierderi prin conectarea proiecțiilor sale pe X, Y, .. ., Z.

Definiția 13 . A cincea formă normală

O relație R este în cea de-a cincea formă normală (forma normală de proiecție-join - PJ/NF) dacă și numai dacă orice dependență de îmbinare în R decurge din existența unei chei posibile în R.

Să introducem următoarele nume de atribute compuse:

CO = (COTR_NUMBER, DEPARTMENT_NUMBER)

SP = (COTR_NUMBER, PRO_NUMBER)

OP = (DEPARTMENT_NUMBER, PRO_NUMBER)

Să presupunem că există o dependență de asociere în relația ANGAJATI-DEPARTAMENTE-PROIECTE:

* (SO, SP, OP)

Este ușor de arătat cu exemple că pot apărea probleme la inserarea și ștergerea tuplurilor. Ele pot fi eliminate prin descompunerea relației inițiale în trei relații noi:

ANGAJAȚII-DEPARTAMENTE (JOB_NUMBER, DEPARTMENT_NUMBER)

ANGAJATI-PROIECTE (EMPLOYEE_NUMBER, PRO_NUMBER)

DEPARTAMENTE-PROIECTE (DEPARTMENT_NUMBER, PRO_NUMBER)

A cincea formă normală este ultima formă normală care poate fi obținută prin descompunere. Condițiile sale sunt destul de netriviale și, în practică, 5NF nu este utilizat. Rețineți că o dependență de unire este o generalizare atât a unei dependențe cu mai multe valori, cât și a unei dependențe funcționale.

cometariu . Dacă relațiile nu sunt normalizate, atunci apar probleme redundanță, inconsecvență potențială (anomalii de actualizare), anomalii de includere, anomalii de ștergere.

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 vă asigură că datele sunt introduse o singură dată. descărcare inițialăși ajustări, 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. obiecte 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. 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;

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 încorporate și instrumente de bază de date, baza de date este creată interfața cu utilizatorul, permițându-vă 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

Disponibil întreaga linie tehnici de creare a informaţiilor ş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 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 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. Și invers: nu se poate aplica aceeași interpretare nume diferite, cu excepția cazului în care 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 din identificator unic(cheia principala).

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 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 în dezvoltarea bazelor de date și a sistemelor informaționale și anume creșterea productivității muncii, îmbunătățirea calității. produse software, susținând un 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 cheie externă marcate cu literele FK între paranteze.