Dezvoltarea unei baze de date relaționale. Guvernul Federației Ruse

REVIZUIREA NOTELOR DE PRELEGERE

Pentru studenții de specialitate
T1002 „Software tehnologia Informatiei»

(L.V. Rudikova, Ph.D., conferențiar)

Întrebarea 31. ARHITECTURA DBMS. MODEL DE DATE RELAȚIONALE

1. Conceptul de bază de date.

2. Arhitectura bazei de date pe trei niveluri.

3. Ciclu de viață Bază de date.

4. Arhitectura DBMS.

5. Model de date relaționale.

6. Proiectarea bazelor de date relaționale.

7. Forme normale de relații.

8. Algebră relațională.

1. Conceptul de bază de date.

Un sistem de baze de date este orice sistem informatic bazat pe computer în care datele pot fi partajate între mai multe aplicații.

Sistem informatic – un sistem automat care organizează datele și furnizează informații.

Sistem de informare și management – un sistem care oferă suport informativ management.

Date – fapte dispersate.

informație – date organizate și prelucrate.

Sub Bază de date se referă la un set de grupuri elementare interconectate de date (informații) care pot fi procesate de unul sau mai multe sisteme de aplicație. Sistem de baze de date constă dintr-o bază de date; software de uz general numit sistem de management al bazelor de date (DBMS) , și servește la gestionarea bazei de date; echipament și oameni adecvati.

Fiecare SGBD trebuie să îndeplinească următoarele cerințe:

· oferă utilizatorului posibilitatea de a crea baze de date noi și de a le defini schema (structura logica a datelor) prin utilizarea limbaj special - limbaj de definire a datelor; acceptă mai multe vizualizări ale acelorași date;

· lăsa " cerere» date și modificați-le folosind limbajul de interogare, sau limbaj de manipulare a datelor; permite integrarea și partajarea datelor între aplicații;

· susțin stocarea unor cantități foarte mari de date, măsurate în gigaocteți sau mai mult, pentru o perioadă lungă de timp, protejându-le împotriva deteriorării accidentale și a utilizării neautorizate și, de asemenea, oferă modificarea bazei de date și accesul la date prin interogări, de ex. garantarea securității și integrității datelor;

· controlează accesul la date simultan pentru mulți utilizatori; excludeți influența cererii unui utilizator asupra solicitării altuia și împiedicați accesul simultan, care ar putea deteriora datele, de exemplu; asigura controlul simultan al accesului la date.

Sistemul de baze de date este format din următoarele componente:

· Utilizatorii, adică persoane care folosesc date.

· Aplicații, de ex. programe de utilizator care necesită date din sistem.

· DBMS este un software care gestionează accesul la date și oferă specificații funcţionalitate sisteme de baze de date.

· Date, adică șiruri stocate în fișiere.

· Sistemul gazdă este sistemul informatic pe care sunt stocate fișierele. Rândurile de date sunt accesate de sistemul gazdă. Rolul SGBD este de a genera interogări care să permită utilizarea funcționalității sistemului de gestionare a fișierelor din sistemul gazdă pentru a servi aplicatii diverse. Un SGBD este un strat suplimentar de software construit deasupra software sistem gazdă.

Astfel, un sistem cu o bază de date poate fi reprezentat ca următoarea secvență de niveluri:

La cel mai de jos nivel se află datele stocate în fișiere fizice (memoria fizică a bazei de date). La nivel superior - aplicații cu propriile reprezentări ale acelorași date fizice. Fiecare vizualizare a bazei de date are un specific structura logica, construit din datele fizice subiacente. Pentru a oferi o interfață între memorie fizică Baza de date și diferitele sale versiuni logice (multe vizualizări acceptate) SGBD-ul, la rândul său, trebuie să fie format din mai multe niveluri.

2. Arhitectura bazei de date pe trei niveluri.

Distincția dintre reprezentarea logică și cea fizică a datelor a fost recunoscută oficial în 1978, când comitetul ANSI/SPARC a propus o structură generalizată a sistemelor de baze de date. Această structură se numește arhitectură pe trei niveluri. Cele trei niveluri de arhitectură sunt: ​​intern, conceptual și extern.

Nivel intern - acesta este nivelul care determină aspectul fizic baza de date, care este cea mai apropiată de stocarea fizică și este asociată cu metode de stocare a informațiilor pe dispozitivele fizice de stocare. Asociate cu acest strat sunt unități de disc, adrese fizice, indecși, pointeri etc. Acest nivel este responsabilitatea designerilor de baze de date fizice care decid ce dispozitive fizice va stoca datele, ce metode de acces vor fi folosite pentru a prelua și actualiza datele și ce măsuri ar trebui luate pentru menținerea sau îmbunătățirea performanței sistemului de management al bazei de date. Utilizatorii nu ating acest nivel.

Nivel conceptual – nivel structural care definește proiectarea logică a bazei de date. Pe acest nivel se realizează proiectarea conceptuală a bazei de date, care include analiza nevoilor de informații ale utilizatorilor și identificarea elementelor de date de care au nevoie. Rezultatul design conceptual este o diagramă conceptuală, o descriere logică a tuturor elementelor de date și a relațiilor dintre ele.

Nivel extern – nivelul structural al bazei de date, care definește vizualizările utilizatorilor asupra datelor. Fiecare grup de utilizatori primește propria sa vizualizare a datelor din baza de date. Fiecare astfel de vizualizare de date oferă o descriere centrată pe utilizator a elementelor de date care alcătuiesc vizualizarea de date și a relațiilor dintre acestea. Poate fi derivat direct din cadrul conceptual. Colectarea unor astfel de vizualizări ale datelor utilizatorului oferă nivelul extern.

Vizualizări utilizator și aplicație	Nivel extern
Afișări
Diagrama conceptuală	Nivel conceptual
Afişa	Nivel intern
Sistem gazdă
Date stocate

Orez. Niveluri DBMS

3. Ciclul de viață al bazei de date.

Procesul de proiectare, implementare și întreținere a unui sistem de baze de date este numit ciclul de viață al bazei de date (LDC). Se numește procedura de creare a unui sistem ciclul de viață al sistemului (SLC).

Înțelegerea și abordarea corectă a LCBD este foarte importantă și necesită considerație detaliată, deoarece se bazează pe abordare centrat pe date. Elementele de date sunt mai stabile decât funcțiile de sistem efectuate. Creare structura corecta datele necesită o analiză complexă a claselor de unități de date și a relațiilor dintre ele. Dacă construiți o schemă de bază de date logică, atunci în viitor puteți crea orice număr de sisteme funcționale care utilizează această schemă. Abordarea orientată pe funcție poate fi utilizată numai pentru a crea sisteme temporare care sunt proiectate pentru o perioadă scurtă de funcționare.

LCBD constă din următoarele etape:

1. Pre-planificare – planificarea bazei de date, realizată în procesul de elaborare a unui plan strategic de bază de date. În timpul procesului de planificare, sunt colectate următoarele informații:

· ce programe de aplicație sunt folosite și ce funcții îndeplinesc;

· ce fișiere sunt asociate cu fiecare dintre aceste aplicații;

· ce aplicații și fișiere noi sunt în lucru.

Aceste informații ajută la determinarea modului în care sunt utilizate informațiile aplicației și la determinarea cerințelor viitoare pentru sistemul de baze de date.

Informațiile din această etapă sunt documentate sub forma unui model de date generalizat.

2. Verificarea fezabilității . Aici se determină fezabilitatea tehnologică, operațională și economică a planului de creare a bazei de date, adică:

· fezabilitate tehnologică – este tehnologia disponibilă pentru implementarea bazei de date planificate?

· fezabilitate operațională – există fondurile și experții necesari pentru implementarea cu succes a planului bazei de date?

· fezabilitate economică – pot fi determinate concluzii? Se va amortiza sistemul planificat de la sine? Este posibil să se estimeze costurile și beneficiile?

3. Definirea cerințelor include selectarea obiectivelor bazei de date, clarificarea cerințelor de informații pentru sistem și cerințele pentru hardware și software. Astfel, pe în această etapă se creează colectarea datelor și definirea cerințelor model informativ general, exprimat în următoarele sarcini:

· Obiectivele sistemului sunt determinate prin analiza nevoilor de informații. De asemenea, indică în mod necesar ce tip de bază de date ar trebui creată (distribuită, holistică) și ce instrumente de comunicare sunt necesare. Documentul de ieșire este un comentariu care descrie obiectivele sistemului.

· Determinarea cerințelor utilizatorilor: documentare sub formă de informații generalizate (comentarii, rapoarte, anchete, chestionare etc.); fixarea funcţiilor sistemuluiși identificarea sistemelor de aplicații care vor îndeplini aceste cerințe. Datele sunt prezentate sub forma unor documente relevante.

· Determinarea cerințelor generale hardware și software legate de menținerea nivelului dorit de performanță. (Aflați numărul de utilizatori ai sistemului, numărul de mesaje introduse pe zi, numărul de imprimări). Aceste informații sunt utilizate pentru a selecta tipuri de computere și DBMS, capacitatea discului și numărul de imprimante. Datele din această etapă sunt prezentate într-un raport care conține exemple de configurații hardware și software.

· Elaborarea unui plan pentru crearea în etape a sistemului, inclusiv selecția aplicațiilor inițiale.

4. Design conceptual – crearea unei diagrame conceptuale a bazei de date. Specificațiile sunt dezvoltate în măsura în care este necesar pentru a trece la implementare.

Documentul principal de ieșire este un singur model informativ(sau schema bazei de date la nivel conceptual). La elaborarea acestui model sunt utilizate informații și funcții pe care sistemul trebuie să le îndeplinească, determinate în etapa de colectare și determinare a cerințelor sistemului. În această etapă, este de asemenea de dorit să se definească: 1) reguli pentru date; 2) reguli pentru procese; 3) reguli pentru interfață.

5. Implementarea – proces de transformare model conceptualîntr-o bază de date funcțională. Acesta include următorii pași.

1) Selectarea și achiziționarea DBMS-ului necesar.

2) Transformarea modelului conceptual (infologic) al bazei de date într-un model de date logic și fizic:

· Pe baza modelului de date infologice, se construiește o schemă de date pentru un anumit SGBD, dacă este necesar, baza de date este denormalizată pentru a accelera procesarea interogărilor în toate aplicațiile critice de timp;

· se determină ce procese de aplicație trebuie implementate în schema de date ca proceduri stocate;

· implementează constrângeri menite să asigure integritatea datelor și să aplice regulile privind datele;

· proiectează și generează declanșatori pentru a implementa toate regulile de date definite la nivel central și regulile de integritate a datelor care nu pot fi specificate ca constrângeri;

· dezvoltarea unei strategii de indexare și grupare; estimați dimensiunile tuturor tabelelor, clusterelor și indicilor;

· determina nivelurile de acces ale utilizatorilor, dezvoltă și implementează reguli de securitate și audit. Creați roluri și sinonime pentru a oferi acces multi-utilizator cu niveluri consistente de permisiuni de acces.

· dezvoltarea unei topologii de rețea a bazei de date și a unui mecanism de acces fără probleme la datele de la distanță (bază de date replicată sau distribuită).

3) Construirea unui dicționar de date care definește stocarea definițiilor structurii datelor bazei de date. Dicționarul de date conține, de asemenea, informații despre permisiunile de acces, regulile de protecție a datelor și controlul datelor.

4) Completarea bazei de date.

5) Creația programe de aplicație, control de gestiune.

6) Instruirea utilizatorilor.

6. Evaluarea și îmbunătățirea schemei bazei de date. Implică chestionarea utilizatorilor pentru a identifica nevoile funcționale nesatisfăcute. Modificările sunt făcute după cum este necesar, adăugând noi programe și elemente de date pe măsură ce nevoile se modifică și se extind.

Astfel, LCBD include:

· Studiați domeniul de studiu și furnizați documentația relevantă (1-3).

· Construirea unui model de informare (4).

· Implementare (5).

· Evaluarea performanței și suportul bazei de date (6).

4. Arhitectura DBMS.

Orez. Componentele principale ale SGBD

Date, metadate - conține nu numai date, ci și informații despre structura datelor ( metadate). Într-un SGBD relațional, metadatele includ tabele de sistem (relații), numele relațiilor, numele atributelor acelor relații și tipurile de date ale acelor atribute.

Adesea DBMS acceptă indici date. Index este o structură de date care ajută la găsirea rapidă a elementelor de date date o parte din valoarea lor (de exemplu, un index care găsește tupluri ale unei anumite relații care au o anumită valoare a unuia dintre atribute). Indecșii fac parte din datele stocate, iar descrierile care indică atributele pe care le au indecșii fac parte din metadate.

Manager de memorie -primește informațiile solicitate de la locația de stocare a datelor și modifică informațiile din acesta la solicitarea nivelurilor superioare ale sistemului.

În sistemele de baze de date simple, managerul de memorie poate fi sistemul de fișiere al sistemului de operare. Cu toate acestea, pentru a îmbunătăți eficiența, SGBD-ul efectuează de obicei un control direct al memoriei. Managerul de memorie este format din două componente:

· Manager de fișiere monitorizează locația fișierelor de pe disc și obține blocul sau blocurile care conțin fișierele atunci când este solicitat de managerul de buffer (discul este în general împărțit în blocuri de discuri- zone de memorie adiacente care conțin de la 4000 la 16000 de octeți).

· Manager tampon gestionează memoria principală. Acesta primește blocuri de date de pe disc printr-un manager de fișiere și selectează o pagină de memorie principală pentru a stoca un anumit bloc. Poate stoca temporar un bloc de disc în memoria principală, dar îl readuce pe disc atunci când este necesară o pagină de memorie principală pentru un alt bloc. Paginile sunt, de asemenea, returnate pe disc la cererea managerului de tranzacții.

Procesor „Solicitare”. - procesează cereri și solicită modificări ale datelor sau metadatelor. Acesta sugerează cel mai bun mod de a efectua operația necesară și oferă comenzile corespunzătoare manager de memorie.

Procesorul de interogări (managerul) transformă o acțiune de interogare sau de bază de date care poate fi finalizată foarte rapid nivel inalt(de exemplu, sub forma unei cereri SQL ), într-o secvență de solicitări de date stocate, cum ar fi tupluri individuale ale unei relații sau părți ale unui index pe o relație. Adesea cea mai dificilă parte a procesării cerere este al lui organizare, adică alegerea unuia bun plan de interogare sau o secvență de solicitări către sistemul de memorie care răspunde la cerere.

Manager de tranzacții - este responsabil de integritatea sistemului și trebuie să asigure procesarea simultană a mai multor cereri, absența interferenței cererilor (adăugare, minim maxim ) și protecția datelor în caz de defecțiune a sistemului. Interacționează cu managerul de interogări deoarece trebuie să știe ce date sunt afectate de interogările curente (pentru a evita conflictele) și poate amâna unele interogări și operațiuni pentru a evita conflictele. Managerul de tranzacții interacționează, de asemenea, cu managerul de memorie, deoarece schemele de protecție a datelor implică de obicei stocarea unui jurnal de modificare a datelor. La În ordinea corectă efectuați operația cu fișierul înregistrare va conține o înregistrare a modificărilor, astfel încât să puteți reexecuta chiar și acele modificări care nu au ajuns pe disc din cauza unei defecțiuni a sistemului.

SGBD-urile tipice permit utilizatorului să grupeze mai multe interogări și/sau modificări într-o singură tranzacție. Tranzacţie este un grup de operații care trebuie efectuate secvenţial ca un întreg.

De obicei, un sistem de baze de date acceptă mai multe tranzacții simultan. Este executarea corectă a tuturor acestor tranzacții care asigură manager de tranzacții. Este asigurată executarea corectă a tranzacțiilorACID -proprietăți (atomicitate, consistență, izolare, durabilitate):

· atomicitate- executarea fie a tuturor tranzacțiilor, fie a niciuna dintre ele (de exemplu, retragerea de bani de la un bancomat și efectuarea unui debit corespunzător în contul clientului trebuie să fie o singură tranzacție atomică; fiecare dintre aceste operațiuni nu este permisă să fie efectuată separat);

· consistenta - o stare în care datele îndeplinesc toate așteptările posibile (de exemplu, condiția de consistență pentru o bază de date a unei companii aeriene este ca niciun loc în avion să nu fie rezervat pentru doi pasageri);

· izolatie- cand doua sau mai multe tranzactii sunt executate in paralel, rezultatele acestora trebuie izolate unele de altele. Executarea simultană a două tranzacții în același timp nu ar trebui să conducă la un rezultat care nu ar fi avut loc dacă acestea ar fi fost executate secvențial (de exemplu, la vânzarea biletelor pentru același zbor în cazul unui ultimul loc liber când doi agenți solicită simultan , cererea unuia trebuie îndeplinită, a celuilalt - Nu);

· longevitate - după finalizarea tranzacției, rezultatul nu trebuie pierdut în cazul unei defecțiuni a sistemului, chiar dacă această defecțiune apare imediat după finalizarea tranzacției.

Să luăm în considerare și 3 tipuri de acces la DBMS:

1. Cereri - Întrebările despre date pot fi generate în două moduri:

A)prin utilizarea interfață comună de interogare(de exemplu, un SGBD relațional permite interogări SQL , care sunt transmise procesorului de cereri și primește și răspunsuri la acestea);

b) cu ajutorul interfețele programelor de aplicație- cererile sunt transmise printr-o interfață specială (cererile arbitrare nu pot fi transmise prin această interfață);

2. Modificări - Acestea sunt operațiuni de modificare a datelor. Ele pot fi, de asemenea, executate fie printr-o interfață comună, fie printr-o interfață de program de aplicație;

3. Modificări ale circuitului - Acestea sunt echipe de administratori de baze de date care au dreptul de a modifica schema bazei de date sau de a crea o nouă bază de date.

Arhitectura client/server. Multe versiuni de software modern implementează arhitectura client server: Un proces (clientul) trimite o cerere către alt proces (server) pentru a fi executat. De obicei, o bază de date este adesea împărțită într-un proces server și mai multe procese client.

În cea mai simplă arhitectură client/server, întregul SGBD este un server, cu excepția interfețelor de interogare, care interacționează cu utilizatorul și trimit interogări sau alte comenzi către server. De exemplu, un SGBD relațional folosește adesea limbajul SQL pentru a reprezenta cereri de la client la server. Serverul bazei de date oferă apoi clientului un răspuns sub forma unui tabel (relație). Există o tendință de a crește sarcina asupra clientului, deoarece dacă există mulți utilizatori de baze de date care lucrează simultan, pot apărea probleme cu serverul.

5. Model de date relaționale.

RMD-ul unui anumit domeniu este un set de relații care se schimbă în timp. Atunci când creați un sistem informațional, un set de relații vă permite să stocați date despre obiecte din domeniul subiectului și să modelați conexiunile dintre ele.

Atitudine este un tabel bidimensional care conține unele date. Matematic subN relație -ariană R înţelege setul de produse carteziane D 1 D 2 … D n seturi ( domenii) D 1, D 2, …, D n (), opțional diferit:

R D 1 D 2 … D n ,

unde D 1 D 2 … D n – produs cartezian complet, i.e. un set de toate combinațiile posibile de n elemente fiecare, unde fiecare element este preluat din domeniul său propriu.

Domeniu - Acest concept semantic. Un domeniu poate fi gândit ca un subset de valori ale unui tip de date care au o semnificație specifică. Domeniul este caracterizat de următoarele proprietăți:

· Domeniul are nume unic(în baza de date).

· Domeniul este definit la unii simplu tip de date sau pe un alt domeniu.

· Domeniul poate avea unele condiție logică, care vă permite să descrieți subsetul de date care este valabil pentru un anumit domeniu.

· Domeniul poartă un anumit încărcătură semantică.

Atribut de relație sunt câteva de acest fel<Имя_атрибута: Имя_домена>. Numele atributelor trebuie să fie unice în cadrul relației. Adesea, numele atributelor unei relații sunt aceleași cu numele domeniilor corespunzătoare.

Raport , definit pe mai multe domenii, conține două părți: un antet și un corp.

Antetul relației - Acest cantitate fixă atribute ale relatiei:

Capul relației descrie produsul cartezian al domeniilor pe care este definită relația. Antetul este static, nu se modifică în timpul lucrului cu baza de date. Dacă atributele sunt modificate, adăugate sau șterse într-o relație, atunci rezultatul va fi alte relație (chiar cu același nume).

Organul de relație conţine multe tupluri relaţie. Fiecare relație de tuplu reprezintă un set de perechi de formă<Имя_атрибута: Значение_атрибута>:

astfel încât valoarea atributului să aparțină domeniului . Corpul relației este un set de tupluri, adică. un subset al produsului cartezian al domeniilor. Astfel, corpul unei relații este de fapt o relație în sensul matematic al cuvântului. Corpul relației se poate schimba în timpul lucrului cu baza de date - tuplurile pot fi modificate, adăugate și șterse.

Relația este de obicei scrisă astfel:

sau mai scurt

,

sau pur și simplu

Numărul de atribute dintr-o relație este numit grad (sau -aritate ) relație. Cardinalitatea unui set de tupluri ale unei relații se numește putere relaţie.

Diagrama relațiilor este o listă de nume de atribute ale unei relații date, indicând domeniul căruia îi aparțin:

Dacă atributele iau valori din același domeniu, atunci ele sunt numite -comparabile, unde este setul de operațiuni de comparare valide specificate pentru un anumit domeniu. De exemplu, dacă un domeniu conține date numerice, atunci toate operațiunile de comparare sunt valabile pentru el, atunci . Cu toate acestea, pentru domeniile care conțin date de caractere, nu pot fi specificate numai operațiuni de comparare pentru egalitatea și inegalitatea valorilor. Dacă un domeniu dat are o ordonare lexicografică, atunci are și o gamă completă de operații de comparare.

Se numesc scheme a două relații echivalent , dacă au același grad și este posibil să ordonați numele atributelor în scheme în așa fel încât atributele comparabile, adică atributele care iau valori din același domeniu, să fie în aceleași locuri:

Lăsa – diagrama relațiilor. – schema relatiei dupa ordonarea numelor atributelor. Apoi

~

Astfel, pentru relațiile echivalente sunt îndeplinite următoarele condiții:

· Tabelele au același număr de coloane.

· Tabelele conțin coloane cu aceleași nume.

· Coloanele cu aceleași nume conțin date din aceleași domenii.

· Tabelele au aceleași rânduri, dar ordinea coloanelor poate varia.

Toate aceste tabele sunt diferite Imagini aceeași relație.

Proprietățile relațiilor. Proprietățile relațiilor decurg direct din definiția de mai sus a relației. Aceste proprietăți sunt principalele diferențe dintre relații și tabele.

· Nu există tupluri identice într-o relație .

· Tuplurile nu sunt comandate (de sus în jos) .

· Atributele nu sunt ordonate (de la stânga la dreapta) .

· Toate valorile atributelor sunt atomice .

Orez. Reprezentarea schematică a relației

Model relațional este o bază de date sub forma unui set de relații interconectate. În fiecare conexiune, o relație poate acționa ca principală, iar o altă relație acționează ca una subordonată. Astfel, un tuplu dintr-o relație principală poate fi asociat cu mai multe tuplu ale unei relații subordonate. Pentru a susține aceste relații, ambele relații trebuie să conțină seturile de atribute prin care sunt legate. Practic asta este cheia primară a relației , care definește în mod unic tuplu al relației principale. Pentru a modela o relație, o subrelație trebuie să aibă un set de atribute care să se potrivească cu cheia primară a relației principale. Cu toate acestea, aici este deja acest set de atribute cheie secundară sau cheie externă , adică definește un set de tupluri de relație care sunt asociate cu un singur tuplu al relației principale.

6. Proiectarea bazelor de date relaţionale.

La proiectarea unei baze de date relaționale, trebuie rezolvate următoarele probleme:

1) Ținând cont de semantica materiei, este necesar să se reprezinte cel mai bine obiectele domeniului sub forma unui model de date abstract (design de date). Acestea. - decide asupra schemei bazei de date: din ce relații ar trebui să constea baza de date, ce atribute ar trebui să aibă aceste relații, care sunt conexiunile dintre relații.

2) Asigurarea eficienței executării interogărilor la baza de date (proiectarea fizică a bazei de date).

După etapa de proiectare datalogică, trebuie obținute următoarele documente rezultate:

· Construirea unei scheme corecte de date bazată pe modelul de date relaționale.

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

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

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

· Dezvoltarea de proceduri pentru menținerea integrității semantice a bazei de date.

Deci, sarcina de a proiecta o bază de date relațională este de a selecta o schemă de bază de date dintre multe opțiuni alternative.

Corect este o schemă de bază de date în care nu există dependențe nedorite între atributele relației. Procesul de dezvoltare a unei scheme corecte de bază de date este numit design logic .

Proiectarea unei scheme de bază de date se poate face în două moduri:

· Metoda de descompunere (partiție). – setul original de relații inclus în schema bazei de date este înlocuit cu un alt set de relații care sunt proiecții ale relațiilor originale! În același timp, numărul relațiilor crește.

· Metoda de sinteză – layout-ul unei scheme de bază de date din dependențele elementare inițiale date între obiectele domeniului subiect.

Designul clasic al bazelor de date este asociat cu teoria normalizare , care se bazează pe analiza dependențelor funcționale dintre atributele relației. Dependențe funcționale definesc relații stabile între obiecte și proprietățile lor în domeniul subiectului luat în considerare.

Metoda de descompunere este un proces de normalizare secvențială a schemelor de relații: fiecare nouă iterație corespunde unei forme normale de ordin superior și are proprietăți mai bune în comparație cu cea anterioară. Astfel, se presupune inițial existența unei relații universale care conține toate atributele bazei de date, apoi, pe baza analizei conexiunilor dintre atribute, se realizează (sau se încearcă o descompunere a relației universale), adică. trecerea la mai multe relații de dimensiune inferioară, iar relația inițială trebuie restabilită folosind o operație de îmbinare naturală.

Deci, fiecare formă normală corespunde unui anumit set de constrângeri, iar o relație este într-o anumită formă normală dacă își satisface setul inerent de constrângeri.

În teoria bazelor de date relaționale, se disting de obicei următoarele forme normale:

primul forma normala (1 NF);

· a doua formă normală (2 NF);

· a treia formă normală (3 NF);

· Bays-Codd formă normală ( BCNF);

· a patra formă normală (4 NF);

· a cincea formă normală sau formă de proiecție - compuși (5 NF sau PYNF).

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 formă normală, proprietățile proprietăților normale anterioare sunt păstrate.

Sunt denumite scheme de baze de date echivalent, dacă conținutul bazei de date sursă poate fi obținut printr-o conexiune naturală a relațiilor incluse în schema rezultată și nu apar tuplu noi în baza de date sursă.

7. Forme normale de relaţii.

Procesul de normalizare se bazează pe o reflectare adecvată a domeniului subiectului sub formă de tabele care conțin date despre obiectul modelat și pe capacitatea de a schimba starea bazei de date în timp. De regulă, din cauza unei nepotriviri între modelul de date de domeniu, pot apărea anomalii care apar la efectuarea operațiunilor corespunzătoare:

· Anomalii de inserare (INSERT) – stocarea de informații eterogene într-un singur aspect.

· Anomalii de actualizare (UPDATE) – Redundanța datelor de relație datorită stocării eterogene.

· Anomalii de ștergere (DELETE) – stocarea de informații eterogene într-o relație.

De asemenea, este necesar să se țină cont de emergente nedefinit ( NUL) valori. În diferite SGBD, atunci când se efectuează diverse operații (comparare, îmbinare, sortare, grupare etc.) două NUL -valorile pot fi sau nu egale între ele, au efecte diferite asupra rezultatului efectuării operațiilor de determinare a valorilor medii și de a afla numărul de valori. Pentru a elimina erorile din multe SGBD-uri este posibilă înlocuirea NUL -valorile sunt zero la efectuarea calculelor, declarând toate NUL -valori egale între ele etc.

Normalizare – împărțirea unui tabel în mai multe, care au proprietăți mai bune la actualizarea, inserarea și ștergerea datelor. Acestea. normalizarea este procesul de înlocuire secvențială a unui tabel cu descompunerea lui completă până când toate sunt în 5NF, totuși, în practică, este suficient să convertiți tabelele în BCNF;

Procedura de normalizare se bazează pe faptul că singurele dependențe funcționale din orice tabel ar trebui să fie dependențe de forma , unde este cheia primară și este un alt câmp. Prin urmare, în timpul procesului de normalizare, ar trebui să scăpați de toate „celelalte” dependențe funcționale, de exemplu. din cele care au un aspect diferit de .

Dacă înlocuim codurile cheilor primare (străine) în timpul normalizării, atunci ar trebui să luăm în considerare 2 cazuri:

1. Tabelul are o cheie primară compusă, de exemplu, și un câmp care depinde funcțional de o parte a acestei chei, de exemplu, de (nu depinde de cheia completă). Se recomandă să creați un alt tabel care să conțină și ( – cheia primară) și să ștergeți din tabelul original:

Înlocuiește, cheie primară, legea federală

pe , cheie primară

și cheia primară.

2. Tabelul are o cheie primară (posibilă), un câmp care nu este o cheie posibilă, dar de care depinde funcțional și un alt câmp fără cheie care depinde funcțional de:. Se recomandă crearea unui tabel care să conțină atât ( - cheia primară) cât și - ștergerea din tabelul original: Trebuie remarcat faptul că, pentru a efectua astfel de operațiuni, trebuie să aveți inițial unele relații „mari” (universale) ca date de intrare.

Def.1. Relația este în prima formă normală (1NF) dacă și numai dacă niciunul dintre rândurile sale nu conține o singură valoare în niciunul dintre câmpurile sale și niciunul dintre câmpurile cheie ale relației nu este gol.

Conform definiției 1, orice relație va fi în 1NF, adică. o relație care satisface proprietățile relațiilor: nu există tuple identice în relație; tuplurile nu sunt ordonate; atributele nu sunt ordonate și diferă după nume; toate valorile atributelor sunt atomice.

Def.2. Relația este în a doua formă normală (2NF) dacă și numai dacă relația este în 1NF și nu există atribute non-cheie care depind de piesă cheie complexă(adică, toate câmpurile care nu sunt incluse în cheia primară au o dependență funcțională completă de cheia primară).

Dacă cheia candidată este primă, atunci relația este automat în 2NF.

Pentru a elimina dependența atributelor de o parte a unei chei complexe, este necesar să efectuați descompunere relații cu mai multe relații. Atributele care depind de o parte a unei chei complexe sunt plasate într-o relație separată.

Atributele unei relații sunt numite independent reciproc , dacă niciunul dintre ele nu este dependent funcțional de celălalt.

Def.3. Relația este în a treia formă normală (3NF) dacă și numai dacă relația este în 2NF și toate atributele non-cheie sunt reciproc independente (adică niciunul dintre câmpurile non-cheie ale relației nu depinde funcțional de orice alt câmp non-cheie).

Pentru a elimina dependența atributelor non-cheie, trebuie să descompuneți relația în mai multe relații. În acest caz, acele atribute non-cheie care sunt dependente sunt plasate într-o relație separată.

Când se reduc relațiile folosind algoritmul de normalizare la relații în 3NF, se presupune că toate relațiile conțin o cheie candidată. Acest lucru nu este întotdeauna adevărat. Există momente când o relație poate conține mai multe chei.

Def.4. Relația este în Bays-Codd formă normală (NFBK) dacă și numai dacă determinanții tuturor dependențelor funcționale sunt chei potențiale (sau dacă orice dependență funcțională între prietenii săi se reduce la o dependență funcțională completă de o posibilă cheie).

Dacă o relație este în BCNF, atunci este automat în 3NF, după cum reiese din Definiția 4. Pentru a elimina dependența de determinanți care nu sunt chei potențiale, trebuie efectuată descompunerea, plasând acești determinanți și părțile care depind de ei într-un relatie separata.

Există momente când o relație nu conține nicio dependență funcțională. Acestea. atitudinea este complet esențială, adică cheia unei relații este întregul set de atribute. Astfel, avem o dependență multivalorică, deoarece Există încă o relație între atribute.

Def.5. Relația este în a patra formă normală (4NF) dacă și numai dacă relația este în BCNF și nu conține dependențe multivalorice netriviale.

Relațiile cu dependențe multivalorice netriviale apar, de regulă, ca urmare a unei conexiuni naturale a două relații pe un câmp comun, care nu este cheie în niciuna dintre relații. În realitate, acest lucru duce la stocarea informațiilor despre două entități independente într-o singură relație.

Pentru a elimina dependențele multivalorice non-triviale, puteți descompune relația inițială în câteva noi.

Def.6. Relația este în a cincea formă normală (5NF) dacă și numai dacă orice dependență de conexiune prezentă este trivială.

Def.6. identic urmează și definiția.

Def.7. O relație nu este în 5NF dacă relația are o dependență de unire non-trivială.

Acea. Dacă în fiecare descompunere completă toate proiecțiile relației originale conțin o cheie posibilă, putem concluziona că relația este în 5NF. O relație care nu are nicio descompunere completă este, de asemenea, în 5NF.

Fără a ști nimic despre potențialele chei într-o relație și despre modul în care atributele sunt interconectate, nu se poate spune că această atitudine este în 5NF sau în alte forme normale.

Posibil indiciu relația este un set de atribute de relație care complet și unic (complet funcțional) determină valorile tuturor celorlalte atribute ale relației. În general, o relație poate avea mai multe chei posibile. Dintre toate cheile posibile ale unei relații, de obicei este selectată una, care este considerată cea principală și care se numește cheia primară a relației.

Atribute independente reciproc – Acestea sunt atribute care nu depind una de alta. Dacă într-o relație există mai multe legi fizice, atunci fiecare atribut sau set de atribute de care depinde un alt atribut se numește determinant al relației.

9. Algebră relațională.

Algebra relațională oferă un cadru pentru accesarea datelor relaționale. Scopul principal al algebrei este de a oferi expresii care pot fi scrise. Expresiile pot fi folosite pentru:

· definițiile zonei mostre, adică definirea datelor pentru selecție ca urmare a operațiunii de eșantionare;

· definițiile zonei actualizări, adică definirea datelor care urmează să fie inserate, modificate sau șterse ca urmare a unei operațiuni de actualizare;

· definiție (numite) relații virtuale, adică prezentare de date pentru vizualizare prin vizualizări;

· definiție instantanee, de ex. definirea datelor de stocat ca „instantaneu” al relației;

· definirea regulilor de siguranță, de ex. determinarea datelor pentru care se efectuează controlul accesului;

· determinarea cerințelor de sustenabilitate, de ex. determinarea datelor care sunt incluse în domeniul de aplicare pentru anumite operațiuni de control al concurenței;

· definirea regulilor de integritate, de ex. câteva reguli speciale pe care baza de date trebuie să le îndeplinească, împreună cu reguli generale, reprezentând o parte model relaționalși aplicat fiecărei baze de date.

Implementările unor SGBD-uri relaționale specifice nu sunt utilizate în prezent în formă pură nici algebră relațională și nici calcul relațional. Standardul de facto pentru accesarea datelor relaționale a devenit Limbajul SQL(Limbajul de interogare structurat).

Algebra relațională, definită de Codd, constă din 8 operatori cuprinzând 2 grupuri:

• operații tradiționale de set (unire, intersecție, scădere, produs cartezian);
• operații relaționale speciale (selecție, proiecție, legătură, împărțire).

În plus, algebra include o operație de atribuire, care vă permite să salvați rezultatele calculării expresiilor algebrice în baza de date și o operație de redenumire a atributelor, care face posibilă formarea corectă a antetului (schemei) relației rezultate.

O scurtă prezentare a operatorilor de algebră relațională.

Probă– returnează o relație care conține toate tuplurile unei anumite relații care îndeplinesc anumite condiții. Operația de eșantionare se mai numește și operațiune de restricție ( restrânge - limitare, acum eșantionarea este mai des acceptată - SELECTAȚI ).

Proiecție– returnează o relație care conține toate tuplurile (adică - sub-tuplurile) unei anumite relații după excluderea unor atribute din aceasta.

Muncă– returnează o relație care conține toate tuplurile posibile care sunt o combinație de două tupluri aparținând, respectiv, două relații definite.

O asociere– returnează o relație care conține toate tuplurile care aparțin uneia sau ambelor relații definite.

Intersecție -returnează o relație care conține toate tuplurile care aparțin simultan la două relații definite.

Scăderea –returnează o relație care conține toate tuplurile care aparțin primei dintre două relații definite și nu celei de-a doua.

Conexiune (naturală) – returnează o relație ale cărei tupluri sunt o combinație de două tupluri (aparținând, respectiv, două relații definite) care au o valoare comună pentru unul sau mai multe atribute comune ale celor două relații (și astfel de valori comune apar o singură dată în tuplul rezultat, nu de două ori).

Divizia -pentru două relații, binare și unare, returnează o relație care conține toate valorile unui atribut al relației binare care se potrivesc (în celălalt atribut) cu toate valorile din relația unară.

LITERATURĂ

1. Data K.J. Introducere în sistemele de baze de date, ediția a VI-a: Trans. din engleza - LA.; M.; SPb.: Editura„Williams”, 2000. – 848 p.

2. Connolly T., Begg K., Strachan A. Baze de date: proiectare, implementare și întreținere. Teorie și practică, ed. a II-a: Trad. din engleza – M.: Editura Williams, 2000. – 1120 p.

3. Karpova T.S. Baze de date: modele, dezvoltare, implementare. – Sankt Petersburg: Peter, 2001. – 304 p.

4. Faronov V.V., Shumakov P.V. Delphi 4. Ghidul dezvoltatorului bazelor de date. – M.: „Cunoașterea”, 1999. – 560 p.

5. J. Groff, P. Weinberg. SQL: Ghid complet: Per. din engleza – K.: BHV Publishing Group, 2001. – 816 p.

6. Ken Goetz, Paul Litwin, Mike Gilbert. Access 2000. Ghidul dezvoltatorului. T.1, 2. Per. din engleza – K.: Grupul Editura BHV, 2000. – 1264 p., 912 p.

7. Maklakov S.V BPwin și EPwin. Instrumente CASE pentru dezvoltarea sistemelor informatice. – M.: DIALOG-MEPhI, 2001. – 304 p.

8. Ullman D., Widom D. Introducere în sistemele de baze de date / Transl. din engleza – M.: „Lori”, 2000. – 374 p.

9. Khomonenko A.D., Tsygankov V.M., Maltsev M.G. Baze de date: Manual pentru instituţiile de învăţământ superior / Ed. Prof. A.D. Khomonenko. – Sankt Petersburg: print CORONA, 2000. – 416 p.

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

Ghid de proiectare a bazei de date.

1. Introducere.

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

Bazele de date sunt programe care vă permit să stocați și să 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 exact, a unei diagrame entitate-relație, ca în figură (Exemplu preluat din MySQL Workbench).

Exemple.

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

RDBMS.

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

Utilitar de administrare a bazelor de date.

După Instalări MySQL primești doar interfața Linie de comanda pentru a interacționa cu MySQL. Personal, prefer un GUI pentru a-mi gestiona bazele de date. Folosesc des SQLyog. Acest utilitate gratuită cu o interfață grafică. Imagini cu mesele din acest manual luate de acolo.

Modelare vizuală.

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

Design independent de RDBMS.

Este important de știut că, deși acest 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 reprezentau 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 din acest dosar, trebuie anunțat că datele sunt separate prin virgulă. Dacă programul dorește să selecteze și să afișeze categoria în care se află lecția „Tutorial pentru proiectarea bazei de date”, apoi ea trebuie să citească rând cu rând până când cuvintele sunt găsite „Tutorial pentru proiectarea bazei de date”și apoi va trebui să citească cuvântul după virgulă pentru a deduce categoria Software.

Tabele baze de date.

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

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

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

Istoria modelului relațional.

Modelul bazei de date relaționale a fost inventat în anii 70 de Edgar Codd, un om de știință britanic. 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 cele multifuncționale sisteme server cu metode de căutare foarte 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.
- Server Microsoft SQL– RDBMS de la Microsoft. Disponibil numai pentru sistemul de operare Windows.
- mysql este un RDBMS open source foarte popular. Folosit pe scară largă atât de profesioniști, cât și de începători. Ce mai este nevoie?! Este gratis.
- IBM– are un număr de RDBMS-uri, cel mai cunoscut fiind DB2.
- Microsoft Access– RDBMS, care este folosit la birou și acasă. De fapt, este mai mult decât o bază de date. MS Access vă permite să creați baze de date cu o interfață de utilizator.
În partea următoare vă voi spune ceva despre caracteristicile bazelor de date relaționale.

3. Caracteristicile bazelor de date relaţionale.

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

Folosind chei.

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

Folosind limbajul de interogare structurat (SQL), date din mese diferite, care sunt legate printr-o tastă, pot fi selectate simultan. 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 număr maxim caractere egale cu 255, iar inturile sunt numere.

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

Guvern Federația Rusă

Universitatea Nationala de Cercetare

LICEUL DE ECONOMIE

SUCURSALA PERM

Departamentul de Tehnologii Informaţionale în Afaceri

Tehnologia informației în munca de birou

Dezvoltarea unui sistem informatic al întreprinderii folosind un sistem de management al bazelor de date Accesați datele 2007

Manual educațional și metodologic

Perm 2011

Tehnologia informației în munca de birou. Dezvoltarea unui sistem informatic al întreprinderii utilizând sistemul de management al bazelor de date Access 2007 Manual educațional. NRU HSE PF, 2011, 40 p.

Compilat de: Vikentyeva Olga Leonidovna, Lebedev Valery Viktorovich.

Manualul educațional este întocmit în conformitate cu standardul educațional de stat, curriculumși conceptul disciplinei „Tehnologii informaționale în economie”. Manualul este destinat studenților și profesorilor Facultății de Pensii a Școlii Superioare de Economie a Universității de Stat și conține o serie orele practice, dezvăluind capacitățile tehnologiilor informaționale moderne de a crea sisteme pentru stocarea, preluarea și prezentarea datelor.

Referent: Profesor asociat al Departamentului de Informatică al Institutului Regional de Tehnologii Informaționale Pedagogice Perm, Candidat la Științe Pedagogice, Membru Corespondent al Academiei de Informatizare a Educației Kushev V.O.

Lecția 1. Proiectarea unei baze de date relaționale

În sensul obișnuit, o bază de date este un fișier sau un set de fișiere care au o anumită organizare. Cu toate acestea, atunci când lucrați cu sisteme convenționale prelucrarea fișierelor ridică o serie de probleme legate, în special, de redundanța și dependența datelor stocate în acestea. La proiectarea unei baze de date, aceste probleme sunt rezolvate.

Utilizatorul trebuie să ia parte la procesul de proiectare a bazei de date, deoarece numai el poate determina ce date sunt necesare pentru lucru, poate indica conexiunile care există între aceste date și poate fi atent la subtilitățile prelucrării lor.

Nevoile de informații ale unui utilizator individual afectează de obicei doar o parte din datele stocate în sistemul informațional, iar descrierea acestor nevoi poate să nu coincidă cu descrierile nevoilor altor utilizatori. Ideea pentru ce informații sunt necesare pentru muncă va fi diferită grupuri diferite utilizatorii, specialiști în diverse domenii – depinde de atribuțiile pe care le îndeplinesc (specialiștii în HR și angajații contabili, șefii de departament etc. au nevoie de diverse date pentru a-și îndeplini funcțiile). Aceste nevoi sunt descrise în nivel extern prezentarea datelor (viziunile A, B și C din Fig. 1).

În consecință, pot exista multe descrieri externe ale datelor stocate în baza de date. Ei trebuie să fie reuniți vedere conceptuală, descriind date la nivelul întregului sistem informațional în ansamblu. Reprezentarea internă a acestor date este determinată de modul în care sunt stocate în memoria externă.

Să luăm în considerare un exemplu de bază de date a unui sistem informatic al unei companii care furnizează mărfuri magazinelor din oraș și vom lua în considerare doar nevoile de informații a doi angajați ai companiei (într-o formă simplificată - altfel exemplul ar fi prea greoi ).

Figura 1. Formarea reprezentării datelor

Un angajat de relații cu clienții are nevoie de informațiile prezentate în Figura 2 pentru a-și îndeplini sarcinile.

Un angajat care lucrează cu formulare de plată are nevoie de alte informații despre clienți (Fig. 3).

Datele utilizate de specialiștii individuali se află într-un sistem informațional unificat al întreprinderii, într-o bază de date comună pentru aceștia. Prin urmare, punctele de vedere externe ale utilizatorilor individuali trebuie să fie integrate într-o vedere conceptuală, scopul descrierii datelor la nivel conceptual este de a crea o vedere atât de formală a datelor încât orice vedere externă să fie un subset al acestora. În procesul de integrare a reprezentărilor externe, ambiguități și contradicții în nevoi de informare utilizatori individuali. Descrierea conceptuală care reprezintă întreaga bază de date trebuie să fie unică.

Figura 2. Date pentru primul angajat

Figura 3. Date pentru al doilea angajat

În acest exemplu, vizualizarea conceptuală trebuie să includă toate informațiile necesare tuturor angajaților. Pot apărea contradicții din cauza faptului că angajații care folosesc Informații generale, îl poate reprezenta în diferite moduri (de exemplu: un număr de telefon poate fi scris în diferite formate). Toate aceste contradicții trebuie eliminate, datele și forma de prezentare a acestora trebuie să fie consistente.

Apoi descrierea conceptuală este determinată de următoarele informații

Datele descrise de schema conceptuală trebuie înregistrate în memoria externă, pe VRAM, destinată stocării informațiilor aflate în baza de date. Descrierea internă datele caracterizează modul în care datele sunt stocate în memoria externă.

Regulile de descriere a datelor sunt determinate de cei selectați Model de date(în acest caz se ia în considerare doar modelul relațional – cel mai comun în prezent).

Dacă luăm descrierea datelor despre clienții unei companii angajate în furnizarea de bunuri magazinelor din oraș din exemplul de mai sus, prezentat în Fig. 4, atunci datele descrise de acest tabel nu pot fi prezentate în această formă într-o bază de date relațională, deoarece nu toate valorile sunt atomice (componentele liniilor „Proprietar” și „Adresă” constau din mai multe valori, adică valorile acestor atribute sunt înlocuite cu alte relații, descifrate de acestea în relația care descrie proprietarul, câmpurile „ Adresa” și „Pașaportul” nu sunt, de asemenea, atomice, prin urmare se construiește o ierarhie).

La proiectarea unei baze de date, acestea pot fi preluate diverse solutii, dar există cerințe de bază care trebuie avute în vedere în timpul procesului de lucru: ansamblul relațiilor trebuie să asigure redundanță minimă în prezentarea informațiilor; manipularea datelor, ajustarea relațiilor nu ar trebui să conducă la încălcarea integrității datelor, ambiguitate și pierdere de informații; restructurarea setului de relații la adăugarea de noi atribute la baza de date ar trebui să fie minimă.

Figura 4. Prezentarea generală a datelor

Descrierea obiectelor reale și a relațiilor dintre ele este în mare măsură subiectivă, dar există anumite reguli generale, în special, reguli de normalizare. Normalizarea protejează integritatea datelor prin eliminarea dublării datelor. Ca rezultat, o reprezentare de date a unui singur obiect poate fi împărțită în mai multe tabele conexe mai mici (descompunere fără pierderi). Restricțiile care trebuie respectate la proiectarea unei baze de date relaționale sunt destul de numeroase. Respectarea restricțiilor la definirea unor relații specifice în baza de date este asociată cu implementarea forme normale. Formele normale sunt numerotate secvenţial, începând de la prima. Cu cât este mai mare numărul formei normale pe care o îndeplinește baza de date, cu atât trebuie respectate mai multe restricții asupra datelor stocate în baza de date. Este posibil să se introducă restricții tipice pentru SGBD-urile relaționale set suplimentar restricții, ceea ce va duce la creșterea numărului de forme normale.

O bază de date prost concepută poate stoca toate informațiile într-un singur tabel. Pentru exemplul descris mai sus, un astfel de tabel ar putea conține următoarele coloane:

Componentele de adresă stradă și casă au fost redenumite pentru a se conforma cu cerința conform căreia numele coloanelor trebuie să fie unice (regulile de denumire variază în funcție de SGBD).

Care sunt dezavantajele acestei idei?

Prima formă normală impune ca la orice intersecție a unui rând și a unei coloane să existe o singură valoare care trebuie să fie indivizibilă (cerința de atomicitate). În plus, un tabel relațional nu trebuie să conțină rânduri sau grupuri de date duplicat.

Cerința de atomicitate este îndeplinită - coloanele compuse „Adresa” și „Proprietar” (și pentru proprietar „Adresa” și „Pașaportul”) sunt împărțite în componente care sunt incluse în tabelul general. Dar un magazin poate avea mai mulți proprietari, iar o persoană poate deține mai multe magazine. Aceasta înseamnă că tabelul va trebui să includă toate rândurile care reprezintă „combinații” de magazine și proprietarii acestora, de exemplu. V linii diferite grupurile de date vor fi repetate (datele despre magazin vor fi repetate de mai multe ori - pentru fiecare dintre proprietarii săi, iar datele proprietarului vor fi repetate pentru fiecare dintre magazinele sale). O astfel de reprezentare a datelor duce la o redundanță enormă și la faptul că memoria de pe VRAM va fi folosită ineficient. În plus, duplicarea informațiilor poate duce la probleme la procesarea acestora: pentru a face modificări la informațiile despre un magazin (de exemplu, dacă contul său bancar se modifică), trebuie să modificați aceste date în mai multe înregistrări corespunzătoare diferiților proprietari.

Atunci când se determină ce tabele ar trebui incluse în baza de date și ce informații ar trebui stocate în ele, trebuie luată în considerare următoarea regulă: fiecare tabel descrie un obiect, existând independent, având proprietăți proprii. Construcția unei baze de date ar trebui să înceapă prin crearea unei reprezentări a fiecărui obiect sub formă de rânduri care conțin atributele acestuia în tabelul corespunzător; modele definitorii ale relaţiilor obiectuale. În exemplul luat în considerare, baza de date ar trebui să stocheze informații despre obiecte de două tipuri: despre magazine și despre proprietarii acestora. Aceste informații ar trebui plasate în două tabele diferite (Magazine și Proprietari) cu următoarele coloane:

"Magazinele"

„proprietari”

Fiecare rând din tabelul „Magazine” va descrie o instanță a obiectului corespunzător (un singur magazin). Și fiecare rând din tabelul „Proprietari” va conține informații despre un proprietar de magazin.

Când lucrați cu informații stocate într-o bază de date, SGBD-ul trebuie să poată distinge rândurile unul de celălalt. Atributul sau setul de atribute care identifică unic un rând este cheia sa primară.

Ce poate fi aleasă ca cheie primară pentru tabelele descrise mai sus?

Cheie o relație este un astfel de set de atribute încât fiecare combinație a valorilor lor apare într-un singur rând al relației și niciun subset al acestor atribute nu are această proprietate. Astfel, cheia identifică unic un rând și îi permite să fie selectat din întregul set de rânduri din relație.

Să definim o cheie pentru tabelul „Magazine”.

Dacă selectați atributul „Nume magazin” ca cheie, va fi satisfăcut cerință specificată? Nu, dacă într-un oraș pot exista mai multe magazine cu aceleași nume situate în diferite părți ale orașului. Pentru a asigura lipsa de ambiguitate, ar trebui să completați numele magazinului cu adresa acestuia (după numele magazinului și adresa sa, puteți selecta fără ambiguitate linia dorităîn tabel), atunci cheia relației va fi compusă.

O cheie simplă de identificare a magazinului dorit poate fi un număr de cont bancar (dacă fiecare magazin are un singur număr de cont bancar și fiecare cont bancar aparține unui singur magazin). Cheia poate fi, de asemenea, un număr de identificare fiscală ( un număr de identificare) magazin.

Să selectăm atributul „TIN” ca cheie primară. În plus, acest atribut va fi folosit pentru a organiza conexiuni între tabelele „Magazine” și „Proprietari” (aceste conexiuni ar trebui să reflecte relațiile reale dintre magazine și proprietarii acestora).

Să decidem cheile pentru tabelul „Proprietari”.

Dacă am putea presupune că nu există omonim printre proprietarii de magazine, atunci am putea selecta atributul „Nume” al relației în cauză ca cheie. Dar, din păcate, proprietarii de magazine pot fi nu numai omonimi, ci și desăvârșiți (putin probabil, dar destul de posibil). Prin urmare, puteți selecta datele pașaportului proprietarului ca cheie, de exemplu. utilizați o cheie compusă pentru a-l identifica, inclusiv atributele „Serie” și „Număr”. Vom considera această cheie ca fiind cheia primară. Cu ajutorul acestuia, vom stabili o legătură între proprietar și magazinele sale.

Cheile primare vor oferi nu numai claritate atunci când căutați informații (sunt unice), dar vă vor permite și să legați datele aflate în două tabele.

Să definim tipul de relație dintre tabelele „Magazine” și „Proprietari”.

Dacă presupunem că o persoană poate deține mai multe magazine, dar fiecare magazin are un singur proprietar, atunci ar trebui să stabilim o relație unu-la-mulți între aceste tabele. Pentru a organiza o astfel de conexiune în baza de date, ar fi posibilă includerea în rândul tabelului „Magazine” care conține informații despre magazin cheie externă, identificarea proprietarului magazinului, i.e. datele sale de pașaport – atributele „Serie” și „Număr”. Organizați comunicarea prin includerea cheii „TIN” care identifică magazinele ca cheie externăîn tabelul „Proprietari”, în acest caz este imposibil, deoarece în acest caz informațiile despre proprietar ar trebui să fie duplicate pentru fiecare magazin.

Dacă presupunem că o persoană poate deține un singur magazin, dar fiecare magazin poate avea mai mulți proprietari, obținem o relație unu-la-mai mulți, dar în acest caz cheie externă(numărul de identificare fiscală a magazinului) ar trebui inclus în tabelul care conține informații despre proprietari.

În realitate, fiecare persoană poate fi proprietarul mai multor magazine și fiecare magazin poate avea mai mulți proprietari, astfel încât între tabelele „Magazine” și „Proprietari” trebuie să se stabilească o relație multi-la-mulți, pentru organizarea căreia un tabel special. este creat care descrie relațiile dintre magazine și proprietari:

„Magazine-proprietari”

STANIU

Serie

Număr

Acest tabel vă va permite să găsiți toți proprietarii săi folosind atributul „TIN” al unui magazin (prin datele pașapoartelor lor) și folosind un atribut compus care include atributele „Serie” și „Număr” ale pașaportului proprietarului. găsi în baza de date toate magazinele pe care le deține.

Pentru a face acest lucru, după ce ați creat tabelul „Magazine-proprietari”, stabiliți relații unu-la-mai multe între tabelul „Magazine” și tabelul „Magazine-proprietari”, precum și între „Proprietari” și „Magazine-proprietari” Mese:

STANIU Serie Număr

„Magazine-proprietari”

Conexiunile stabilite ajută SGBD-ul să mențină integritatea și consistența informațiilor. De exemplu, puteți seta reguli pentru actualizarea informațiilor din tabelele aferente atunci când actualizați informațiile din tabelul principal (când un magazin este lichidat, de exemplu, informațiile despre acesta din baza de date ar trebui să fie șterse și transferate în arhivă, și nu numai rândul din tabelul „Magazine”, dar toate informațiile din tabelele asociate referitoare la acest magazin).

Pentru confortul utilizatorilor și pentru a accelera căutările, SGBD-urile acceptă posibilitatea de a căuta nu numai prin chei unice. De exemplu, puteți găsi în tabel toate magazinele cu aceleași nume sau toate magazinele deținute de același proprietar.

Normalizarea datelor a condus la partiţionarea tabelelor, separând relaţiile cheie primară-cheie străină în tabele mai mici. Rezultatul normalizării este o reducere a redundanței datelor - nu mai este nevoie să se dubleze datele despre fiecare proprietar pentru fiecare magazin.

A doua formă normală necesită ca orice coloană fără cheie să depindă de cheia sa primară (și de întreaga cheie, nu de componentele sale individuale). O relație este în a doua formă normală dacă este conformă cu prima formă normală și nu conține dependențe funcționale incomplete. O dependență funcțională incompletă este definită de două condiții: cheia relației definește funcțional un atribut non-cheie și o parte a cheii definește funcțional același atribut non-cheie.

O relație care nu corespunde formei normale a doua este caracterizată de redundanța datelor stocate.

În exemplul luat în considerare, setul de atribute de relație și alegerea cheilor sunt făcute în așa fel încât tabelele să corespundă formei normale a doua. Dacă această corespondență nu ar exista, pentru a reduce tabelele la a doua formă normală ar fi necesar să se separe informațiile repetate (parte a cheii și atributele non-cheie pe care le definește) în masa separata.

De exemplu: în baza de date este necesară stocarea informațiilor despre mărfurile care sunt livrate în magazine. Aceste informații includ atributele „Nume”, „Cod” și „Preț” ale produsului, precum și „Cantitatea” produsului livrat. Dacă includeți aceste informații în tabelul „Consumabile” în următoarea vizualizare:

"Provizii"

(aici „TIN” identifică magazinul către care a fost efectuată livrarea (aceasta este o cheie străină folosită pentru a crea o relație unu-la-mai multe între tabelul „Magazine” și acest tabel), „Nume” este numele produsului , „Codul” este acesta cod unic(produse cu caracteristici diferiteși, prin urmare, prețuri diferite pot avea același nume, dar codurile vor fi diferite), „Prețul” este prețul de vânzare al produsului, „Cantitatea” este cantitatea de produs furnizată), atunci poate apărea redundanță.

Pentru a defini o linie care reprezintă livrarea mărfurilor către un anumit magazin, puteți specifica o cheie compusă care include atributele „TIN” și „Cod”. Aceste informații fac posibilă determinarea prețului produsului și a cantității sale livrate în acest magazinși calculați, de asemenea, costul total al mărfurilor. Dacă presupunem că produsul este furnizat tuturor magazinelor la același preț, iar prețul nu se modifică în timp, atunci atributul non-cheie „Preț” este determinat nu numai de cheia compusă „TIN” + „Cod”, dar și partea sa - atributul „Cod” " Astfel, același preț se repetă în toate rândurile tabelului, care conțin informații despre furnizarea aceluiași produs. Acest lucru duce la redundanță. Denumirea produsului este determinată și de codul acestuia. Prin urmare, informațiile care se referă numai la produs și nu depind de magazin pot fi plasate într-un tabel separat:

Aici, câmpul cheie „Cod” vă va permite să legați datele din tabelul „Business” cu datele din tabelul „Produse”

Astfel, reducerea la a doua formă normală a eliminat redundanța prin separarea noilor tabele: tabelul „Aprovizionare” este împărțit în două tabele „Aprovizionare” și „Marfuri”, între care se stabilește o relație.

A treia formă normală crește și mai mult cerințele: relația corespunde celei de-a doua forme normale și nu există atribute tranzitive printre atributele sale dependențe funcționale(nicio coloană fără cheie nu trebuie să depindă de o altă coloană fără cheie, poate depinde doar de cheia primară).

În exemplul luat în considerare, ar apărea o discrepanță cu a treia formă normală dacă este îndeplinită următoarea condiție: toate mărfurile cu același nume au același preț (numele ar fi determinat de cod, iar prețul de numele produs). În acest caz, ar apărea redundanță, deoarece prețul pentru un anumit nume de produs ar fi repetat de câte ori se folosesc coduri diferite pentru acest produs.

Ar fi posibil să scăpați de redundanță împărțind tabelul „Produse” în două tabele (unul ar include atributele „Cod” și „Nume”, iar al doilea „Nume” și „Preț”).

Cu toate acestea, în exemplul luat în considerare situația este diferită: mărfurile au coduri diferite, dacă caracteristicile lor sunt diferite, prin urmare, prețurile ar trebui să fie diferite.

A patra formă normală interzice relație independentă tip unu-la-mai multe între coloanele cheie și non-cheie. Mai simplu spus, informațiile eterogene nu pot fi plasate într-un singur tabel, adică. date între care nu există o legătură directă.

Această regulă poate fi văzută în exemplul următor. Ofițerul de relații cu clienții intenționează să folosească informații despre membrii familiei proprietarilor de magazine pentru a-și îndeplini sarcinile. Aceste informații nu trebuie incluse în tabelul Proprietari, deoarece este dificil să se determine cât spațiu trebuie rezervat în rândurile tabelului corespunzătoare. anumite persoane, pentru a stoca date despre acestea starea civilă, - unul poate fi singur, iar celălalt poate fi tatăl multor copii. Informațiile despre membrii familiei trebuie plasate într-un tabel separat, fiecare rând al căruia va conține informații despre un membru al familiei, inclusiv o cheie străină care identifică proprietarul magazinului pentru a organiza o conexiune cu tabelul „Proprietari”.

A cincea formă normală de obicei finalizează procesul de normalizare. În această etapă, toate tabelele sunt împărțite în părți minime pentru a elimina redundanța în ele. Fiecare parte de date non-cheie din tabele ar trebui să apară o singură dată. Acest lucru elimină problemele legate de actualizarea informațiilor din baza de date: toate modificările informațiilor care nu sunt cheie trebuie făcute o singură dată, ceea ce oferă posibilitatea de a gestiona integritatea datelor.

Procesul de proiectare a bazei de date este foarte etapa importantaîn curs de dezvoltare sisteme de informare. Calitatea designului este cea care determină în mare măsură eficiența utilizării bazei de date.

În prezent utilizat pe scară largă mijloace speciale, facilitarea procesului de dezvoltare a sistemelor informatice (instrumente CASE - Computer-Aided Software/System Engineering).

Întrebări pentru autocontrol:

1. Ce este o bază de date?

2. Ce este o reprezentare externă a datelor?

3. Care este esența reprezentării conceptuale a datelor?

4. Ce este un model de date?

5. Ce este normalizarea?

6. Ce este o cheie de relație?

7. Care cheie se numește cheie străină?

8. Ce conexiuni pot fi organizate în baza de date?

9. Care este esența fiecăreia dintre cele cinci forme normale?

Misiunea pentru muncă independentă:

Proiectați bazele de date ale unei companii de servicii clienți. Trei angajați ai companiei au nevoie de baza de date. Prima dintre ele se ocupă de contabilitatea serviciilor prestate de companie și are nevoie de următoarele informații:

Al doilea angajat colectează informații despre artiști și este interesat de:

Al treilea angajat lucrează cu clienții și este important ca el să știe.

Proiectarea bazelor de date ale sistemelor informatice este o sarcină destul de intensivă în muncă. Se desfășoară pe baza formalizării structurii și proceselor domeniului subiectului, informații despre care ar trebui să fie stocate în baza de date. Distinge conceptualȘi circuit-structural proiecta.

Proiectarea conceptuală a unei baze de date a unui sistem informațional este în mare măsură un proces euristic. Adecvarea modelului informațional al domeniului de studiu construit în cadrul acesteia este verificată experimental în timpul funcționării sistemului informațional.

Enumerăm etapele designului conceptual:

* studierea materiei pentru a-și forma o idee generală despre aceasta;

* identificarea si analiza functiilor si sarcinilor SI dezvoltat;

* determinarea principalelor obiecte-entități ale domeniului de studiu și a relațiilor dintre acestea;

* reprezentarea oficială a domeniului de studiu.

La proiectarea unei scheme de baze de date relaționale, se pot distinge următoarele proceduri:

*definirea unei liste de tabele și relații dintre acestea;

*definirea listei de câmpuri, tipuri de câmpuri, câmpuri cheie ale fiecărui tabel (schema tabelului), stabilirea relațiilor dintre tabele prin chei externe;

*stabilirea indexarii campurilor din tabele;

* elaborarea de liste (dicționare) pentru câmpurile cu date enumerative;

* stabilirea de constrângeri de integritate pentru tabele și relații;

* normalizarea tabelelor, ajustarea listei de tabele și relații. Proiectarea bazei de date se realizează la nivel fizic și logic. Designul la nivel fizic este implementat folosind DBMS și este adesea automatizat.

Proiectarea logică constă în determinarea numărului și structurii tabelelor, dezvoltarea interogărilor bazei de date, raportarea documentelor, crearea de formulare pentru introducerea și editarea datelor în baza de date etc.

Una dintre cele mai importante sarcini ale proiectării bazelor de date logice este structurarea datelor. Se disting următoarele abordări ale proiectării structurilor de date:

*combinarea informațiilor despre obiectele entitate într-un singur tabel (o relație) cu descompunerea ulterioară în mai multe tabele interconectate pe baza procedurii de normalizare a relațiilor;

* formularea cunoștințelor despre sistem (determinarea tipurilor de date sursă și a relațiilor) și a cerințelor de prelucrare a datelor, obținerea unei scheme de baze de date gata făcute sau chiar a unui sistem informatic de aplicație gata făcut folosind sistemul CA5E;

* implementarea analizei sistemului si dezvoltarea structurilor

Sisteme de informare

Omenirea de astăzi se confruntă cu o explozie informațională. Volumul de informații care ajunge la o persoană prin toate mediile de informare este în continuă creștere. Prin urmare, pentru fiecare persoană care trăiește într-o societate informațională, este foarte important să stăpânească mijloacele de rezolvare optimă a problemei acumulării, organizării și utilizării raționale a informațiilor.

Capacitățile umane de procesare a informațiilor au crescut dramatic odată cu utilizarea computerelor. În utilizarea computerelor pentru rezolvarea problemelor de servicii de informare, se pot distinge două perioade:

 perioada iniţială, când un cerc restrâns de oameni – programatori de sistem – s-au angajat în rezolvarea problemelor de prelucrare a informaţiei şi organizare a datelor. Această perioadă se caracterizează prin faptul că instrumentele software au fost create pentru a rezolva sarcina specifica procesarea datelor. Totodată, pentru a rezolva o altă problemă în care s-au folosit aceleași date, a fost necesară crearea de noi programe;

 perioada de utilizare sistemică a calculatoarelor. Pentru a rezolva un set de probleme pe un computer, sunt create instrumente software care operează pe aceleași date, folosind o singură model informativ obiect. Aceste instrumente nu depind de natura obiectului sau de modelul acestuia, pot fi folosite pentru servicii de informare pentru diverse sarcini. Omenirea a ajuns să organizeze informația în sistemele informaționale.

Sistemele informaționale (IS) sunt cantități mari de date împreună cu software și hardware pentru procesarea acestora. Există următoarele tipuri de sisteme informaționale: sisteme factuale, documentare și experte.

IP reală - aceasta este o serie de fapte - valori specifice de date despre obiecte din lumea reală.

Informațiile din IS-ul factual sunt stocate într-o formă clar structurată, astfel încât să poată oferi răspunsuri fără ambiguitate la întrebările puse, de exemplu: „Cine este câștigătorul Campionatului Rusiei de gimnastică în 1999?”, „Cine deține AUDI 80 mașină cu numărul de înmatriculare PA899P77?”, „Care este numărul de telefon în departamentul de contabilitate al Universității de Stat din Moscova?”, „Cine a devenit președintele Rusiei la alegerile din martie 2002?” etc. Sistemele informaționale factuale sunt folosite literalmente în toate sferele activității umane - în știință, producție de materiale, transport, medicină, guvern și viața publică, comerț, criminologie, artă, sport.

Sisteme informatice documentare servesc unei clase fundamental diferite de sarcini care nu necesită un răspuns clar la întrebarea pusă. Baza de date a unor astfel de sisteme este formată dintr-un set de documente text nestructurate (articole, cărți, rezumate, texte de legi) și obiecte grafice, dotate cu unul sau altul aparat de căutare formalizat. Scopul sistemului, de regulă, este de a furniza, ca răspuns la o solicitare a utilizatorului, o listă de documente sau obiecte care întrunesc într-o oarecare măsură condițiile formulate în cerere. De exemplu: afișați o listă cu toate articolele în care apare cuvântul „Pușkin”. Caracteristica fundamentală a sistemului documentar este capacitatea sa, pe de o parte, de a produce documente care nu sunt necesare utilizatorului (de exemplu, în cazul în care cuvântul „Pușkin” este folosit într-un sens diferit de cel prevăzut) și, pe de altă parte, nu pentru a le produce pe cele necesare (de exemplu, dacă autorul a folosit un sinonim sau a scris greșit). Sistemul documentar trebuie să fie capabil să determine semnificația unui anumit termen pe baza contextului, de exemplu, să facă distincția între „margaretă” (plantă), „margaretă” (tip de cap de imprimare al imprimantei).

Sisteme experte (ES) - sisteme inteligente, menite să joace rolul unui „consilier”, sunt construite pe baza experienței și cunoștințelor oficializate ale expertului. Nucleul ES sunt bazele de cunoștințe care conțin cunoștințele experților (specialiști) într-un anumit domeniu, pe baza cărora SE permite modelarea raționamentului specialiștilor dintr-un domeniu dat.

Clasificarea specificată și atribuirea sistemelor informaționale la un tip sau altul sunt depășite, deoarece sistemele factuale moderne funcționează adesea cu blocuri de informații nestructurate (texte, grafică, sunet, video) echipate cu descriptori structurați.

Simplitatea și eficiența bazelor de date bazate pe modelul relațional continuă să determine poziția lor dominantă în aplicațiile software. În prezent, utilizarea bazelor de date relaționale în sistemele orientate pe obiect este considerată norma. sisteme software. Aceasta pare a fi o tendință durabilă și pe termen lung.

O bază de date relațională constă din multe tabele bidimensionale. Tabelele stochează diverse date. De exemplu, baza de date poate conține tabele de clienți, mărfuri, conturi etc. Structura tipică a unui tabel de baze de date relaționale este prezentată în Fig. 1.2.

Orez. 1.2. Structura tipică a unui tabel de baze de date relaționale

Rândurile tabelului sunt numite înregistrări sau în tupluri. Coloanele sunt numite atribute. La intersecția unui rând și a unei coloane se află valoarea indivizibilă (atomică) a elementului de date. Kit valori acceptabile atributul (coloana) este determinat de acesta domeniu. Domeniul poate fi foarte mic. Deci, valorile atributelor mărimea Tabelul costumelor sport sunt L, XL și XXL. Dimpotrivă, domeniul atributului Nume de familie foarte mare. Într-o bază de date, un domeniu este implementat folosind o constrângere de domeniu. De fiecare dată când o valoare este scrisă în baza de date, este verificată conformitatea acesteia cu domeniul înregistrat pentru un anumit atribut. Astfel, baza de date este protejată împotriva introducerii de valori nevalide, de exemplu, data de 32 mai.

Analogul virtual al tabelului este performanţă, care se comporta ca o masa obisnuita din punctul de vedere al clientului, dar nu exista de la sine. Un tabel obișnuit conține date. Vizualizarea nu conține date, ci specifică doar sursele acestora (una sau mai multe mese obișnuite, rânduri selectabile, coloane selectabile). De fapt, vizualizarea este stocată în baza de date ca o solicitare de a crea un anumit set de date. Rezultatul acestei interogări este conținutul vizualizării. Când datele din tabelele sursă se modifică, se modifică și conținutul vizualizării.

Pentru a identifica în tabel intrare separată folosește cheia. Cheia principala(Primarcheie, RK) fiecare masă are. Aceasta este o coloană care identifică în mod unic fiecare înregistrare din tabel. În exemplul nostru, ca RK ar putea fi o coloană Nume de familie. Acest lucru este corect până când, de exemplu, apare un alt Bender. Pentru a asigura unicitatea valorii cheii primare, sunt utilizate două tehnici. În primul rând, poate fi folosit cheie primară compusă (CompozitPrimarCheie), format din mai multe coloane (atribute naturale) ale unui tabel. În al doilea rând, ca RK puteți introduce o coloană suplimentară în tabel care nu are sens din punctul de vedere al domeniului subiectului. El este numit cheie surogat. De exemplu, o cheie surogat ar putea fi Numarul clientului sau NumărOrdin.

O altă cheie joacă un rol important în bazele de date relaționale - Cheie externă. Cheie externă (StrăinCheie,FK) este o coloană dintr-un tabel care face referire la cheia primară a altui tabel. Cheile externe sunt folosite pentru a stabili relații între diverse mese DB (un exemplu este prezentat în Fig. 1.3) – accelerarea accesului la un tabel folosind un index.

Orez. 1.3. Cheie externă

Acest exemplu arată că factura și tabelele clienți sunt legate prin cheie Numarul clientului. Dacă ne uităm la tabelul de conturi, atunci Numărul de cont va fi cheia primară și Numarul clientului - cheie externă.

Pentru a asigura integritatea datelor bazei de date, cheile străine trebuie să satisfacă constrângerea integritate referenţială.Înseamnă că fiecare valoare de cheie externă dintr-un tabel trebuie să aibă o valoare corespunzătoare într-o cheie primară existentă într-un alt tabel. Aceasta este cea mai importantă dintre toate constrângerile, deoarece asigură consistența referințelor încrucișate între tabele. Dacă valorile sunt corecte cheie externă nu verificați, integritatea referențială a datelor bazei de date poate fi încălcată. De exemplu, ștergerea unui rând din tabelul clienți poate duce la faptul că în tabelul comenzi vor rămâne înregistrări ale comenzilor făcute de un client acum necunoscut (și cine va plăti comanda?). Constrângerile de integritate referenţială trebuie menţinute automat. De fiecare dată când datele bazei de date sunt introduse sau modificate, controalele verifică constrângerile și se asigură că acestea sunt îndeplinite. Dacă restricțiile sunt încălcate, modificarea datelor este interzisă.

În plus, tabelul poate conține chei secundare - indecși. Sunt folosite ca index de subiecte în carte. Pentru a găsi un anumit termen într-o carte, nu trebuie să răsfoiți toate paginile la rând - doar căutați în indexul subiectului și găsiți numărul dorit pagini. De exemplu, puteți crea un index pe o coloană Nume de familie(Fig. 1.4).

Orez. 1.4. Accelerați accesul la tabel folosind un index

Ca urmare, se va forma un mic tabel care stochează numai nume de familie și link-uri către poziția de înregistrare din tabelul principal. Acum, pentru a căuta înregistrări, nu trebuie să vă uitați în întregime masa mare. Drept urmare, obținem un câștig în performanță. Cu toate acestea, atunci când adăugați și ștergeți înregistrări (în tabelul principal), tabelul index trebuie creat din nou. Acest lucru încetinește operațiunile.

Prelucrare operațională se realizează datele din baze de date relaţionale procesele stocateprostii. Un tip de procedură stocată este declanșatoare. Un declanșator este întotdeauna asociat cu un anumit tabel și este apelat automat atunci când are loc un anumit eveniment (de exemplu, inserarea, ștergerea sau actualizarea unei înregistrări).

Să discutăm despre relațiile dintre tabele. După ce tabelele sunt formate, ei decid cum să-și combine datele atunci când le extrag din baza de date. Primul pas este definirea relațiilor dintre tabele. După aceasta, este posibil să se creeze interogări, formulare și rapoarte care afișează date din mai multe tabele simultan. De exemplu, pentru a imprima o factură, trebuie să luați date din diferite tabele și să le combinați. O relație de tabel stabilește relații între valorile care se potrivesc în câmpurile cheie. Să ne uităm la tipurile de relații.

Relație unu-la-unu. În acest caz, fiecare rând (înregistrare) a unui tabel este asociat cu un rând al altui tabel (Fig. 1.5).

Orez. 1.5. Relație unu-la-unu

Un exemplu ar fi relația dintre un tabel de angajați și un tabel cu adresele acestora. Această relație este rară, deoarece datele relevante pot fi plasate cu ușurință într-un singur tabel.

Relație unu-la-mulți. O înregistrare a primului tabel este asociată cu mai multe înregistrări din al doilea tabel (Fig. 1.6).

Orez. 1.6. Relație unu-la-mulți

Fiecare înregistrare din al doilea tabel nu poate avea mai mult de o înregistrare corespunzătoare în primul tabel.

Relație de la mulți la mulți. O înregistrare a primului tabel poate corespunde mai multor înregistrări din al doilea tabel, iar o înregistrare a celui de-al doilea tabel poate corespunde mai multor înregistrări ale primului (Fig. 1.7).

Orez. 1.7. Relație de la mulți la mulți

De obicei, pentru a organiza astfel de relații, este necesar un tabel auxiliar, care constă din cheile primare a două tabele principale. Această relație apare între comenzi și produse. O comandă poate include mai multe nume de produse, iar un nume de produs poate fi inclus în mai multe comenzi. Astfel, trebuie să existe un tabel de comenzi, un tabel de produse și un tabel cu perechi comandă-produs.

Să luăm acum în considerare pe scurt normalizarea bazelor de date relaționale. Normalizarea asigură optimizarea structurii bazei de date. Conduce la eliminarea redundanței în seturile de date. Normalizarea bazei de date se realizează secvenţial, pas cu pas. Regulile de normalizare sunt prezentate sub forma unor forme normale.

Prima formă normală (1NF) necesită ca valorile tuturor elementelor de date din coloane să fie atomice. A doua formă normală (2NF) necesită ca fiecare coloană fără cheie să fie complet dependentă de cheia primară. A treia formă normală (3NF) necesită ca toate coloanele (atributele) fără cheie să fie reciproc independente și complet dependente de cheia primară. Există o dependență dacă, de exemplu, valorile unei coloane sunt calculate din datele din alte coloane. Rezultatul normalizării este o structură optimă a bazei de date în care există duplicarea necesară a datelor, dar nu există redundanță.