Dezvoltarea unei baze de date relaționale. Proiectarea bazelor de date relaționale pe baza principiilor de normalizare: primii pași ai normalizării

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

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

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

Test

Proiectarea bazei de date relaționale

• Normalizarea relațiilor
• Dependențe funcționale
• Forma normală Boyce-Codd
• Literatură

Proiectarea bazei de date relaționale

Scopul principal al proiectării bazei de date este de a reduce redundanța datelor stocate și, prin urmare, de a economisi cantitatea de memorie utilizată, de a reduce costul operațiunilor multiple de actualizare a copiilor redundante și, în primul rând, de a elimina posibilitatea apariției inconsecvențelor din cauza stocării informațiilor despre același volum în locuri diferite același obiect. Redundanța înseamnă că unele date sau grupuri de date pot fi repetate de mai multe ori.

În timpul procesului de proiectare a bazei de date, pot apărea următoarele probleme:

Anomalii de actualizare - Din cauza redundanței datelor, toate datele trebuie revizuite la actualizarea acestora, cu toate acestea, poate apărea o situație în care nu toate datele sunt actualizate (potențială inconsecvență a datelor).

Anomalii de includere - este posibil ca datele să nu poată fi introduse în baza de date până când unele informații suplimentare nu au fost primite și introduse.

Anomalii de ștergere - problema opusă poate apărea atunci când unele date sunt șterse (posibila pierdere de informații utile).

Numărul de valori nul nu este minimizat. La fel ca și redundanța, valorile nule sunt o sursă de potențiale probleme în bazele de date relaționale, deoarece este imposibil să se determine ce înseamnă. Prin urmare, este recomandabil să minimizați utilizarea lor.

Primele trei probleme sunt rezolvate în procesul de normalizare a relațiilor.

dependență funcțională de bază relațională

Normalizarea relațiilor

Normalizare este o partiție (sau descompunere) a unui tabel în două sau mai multe care au proprietăți mai bune pentru adăugarea, modificarea și ștergerea datelor. Scopul final al normalizării este realizarea unui design „curat” al bazei de date în care „ fiecare fapt stocate numai V unu loc" , adică redundanța datelor este eliminată. Acest lucru se face nu atât pentru a economisi memorie, cât pentru a elimina eventualele inconsecvențe în datele stocate.

Fiecare tabel dintr-o bază de date relațională îndeplinește condiția ca să existe întotdeauna o singură valoare atomică la intersecția fiecărui rând și coloană a tabelului și nu pot exista niciodată mai multe astfel de valori. Orice tabel care îndeplinește această condiție este numit normalizat. De fapt, tabele nenormalizate, adică tabele care conțin grupuri repetate, nici măcar nu sunt luate în considerare într-o bază de date relațională.

Tabelul normalizat corespunde primul normal formă, prescurtat 1NF. Astfel, „normalizat” și „în 1NF” înseamnă același lucru pentru un tabel. Cu toate acestea, în practică, termenul „normalizat” este adesea folosit într-un sens mai restrâns - „complet normalizat”, ceea ce înseamnă că proiectarea nu încalcă niciun principiu de normalizare.

Acum, pe lângă 1NF, pot fi definite niveluri suplimentare de normalizare - a doua formă normală (2NF), a treia formă normală (3NF) etc. Un tabel este considerat a fi în 2NF dacă este în 1NF și, în plus, satisface o anumită condiție suplimentară, a cărei esență va fi discutată mai jos. Un tabel este în 3NF dacă este în 2NF și, de asemenea, satisface o altă condiție suplimentară etc.

Astfel, fiecare formă normală este într-un anumit sens mai limitată, dar și mai dezirabilă decât cea anterioară. Acest lucru se datorează faptului că (n+1)-n forma normală nu are unele dintre caracteristicile neatractive ale formei normale. Semnificația generală a condiției suplimentare impuse formei normale (n+1) față de cea de-a n-a formă normală este de a elimina aceste caracteristici neatractive.

Procedura de normalizare a relațiilor este reversibilă. De exemplu, un set de relații din 3NF poate fi convertit în relații din 2NF. Această proprietate foarte importantă a normalizării înseamnă că nu se pierde nicio informație în timpul procesului de normalizare.

Teoria normalizării se bazează pe prezența anumitor dependențe între câmpurile de tabel. Accentul este pus pe dependențele funcționale, multivalorice și de conexiune.

Dependențe funcționale

Fie X și Y subseturi arbitrare ale unui set de atribute ale unei relații R. Y este dependent funcțional de X dacă și numai dacă fiecare valoare a lui X este asociată cu exact o valoare a lui Y. Notație: XY (a se citi „X determină funcțional Y "). Părțile din stânga și din dreapta ale unei notații simbolice sunt numite parte determinantă și, respectiv, dependentă.

Orez. 1. Tabel de aprovizionare PIC

Cu alte cuvinte, dacă două tuple ale unei relații R coincid în valoarea lui X, atunci ele coincid și în valoarea lui Y. Pentru clarificare, luați în considerare figura prezentată în Fig. 1 este o versiune ușor modificată a tabelului de furnizare prezentat în Fig. 2.

Toate tuplurile relației PIC cu aceeași valoare a atributului P№ au aceleași valori ale atributului Hor. Aceasta înseamnă că atributele Munților depind funcțional de atributele P№: (P№)(Gor). Mai mult, în acest sens, există și alte dependențe funcționale constante: (P№, D№)(Kol), (P№, D№)(Gor), (P№, D№)(Gor, Col), (P Nr., DNo.)(PN.), (PN., DNo.)(PN., DNo., Gor, Kol), precum și dependențe care sunt funcționale la un moment dat, dar nu tot timpul, de exemplu , (Nr. P (Cant.).

Rețineți că dacă X este o cheie candidată a unei relații R, atunci toate atributele Y ale relației R trebuie să fie dependente funcțional de X (aceasta este o consecință a definiției unei chei candidate). De fapt, dacă relația R satisface dependența funcțională a lui AB și A nu este o cheie candidată, atunci R va fi caracterizat de unele redundanţă. De exemplu, în ceea ce privește PIC, informațiile că fiecare furnizor se află într-un anumit oraș se vor repeta de multe ori.

Dependențe funcționale sunt constrângeri de integritate, așa că trebuie verificate de fiecare dată când baza de date este actualizată. O modalitate evidentă de a reduce multe dependențe funcționale este eliminarea banal dependențe, adică cele care nu pot să nu fie îndeplinite. De exemplu, (P№, D№)(P№). Dependenţa funcţională este banal dacă și numai dacă partea dreaptă a notației simbolice este o submulțime a părții stângi. Astfel de dependențe nu prezintă interes din punct de vedere practic.

Atunci când se analizează relațiile, i se acordă un rol deosebit ireductibil dependențe. Un atribut B este dependent ireductibil de un atribut compus A dacă depinde funcțional de A și nu depinde funcțional de niciun subset al atributului A. În publicațiile timpurii, în loc de termen ireductibil dependenta termen folosit deplin funcţional dependenta.

Dependențe funcționale pot fi descrise folosind diagrame. Pentru baza de date furnizor și piese (Fig. 1), diagrama dependenței funcționale este prezentată în Fig. 2.

Fiecare săgeată din diagramă începe cu cheia primară a relației corespunzătoare. Alte săgeți sunt posibile pe diagramă. În acest caz, procedura de normalizare poate fi caracterizată informal ca o procedură de eliminare a săgeților care nu încep pe cheia primară.

Forme normale justificate de dependențe funcționale

Am menționat prima formă normală (1NF). Să dăm o definiție mai strictă a acesteia, precum și definiții ale altor forme normale.

Un tabel este în prima formă normală (1NF) dacă și numai dacă niciunul dintre rândurile sale nu conține mai mult de o valoare în niciunul dintre câmpurile sale și niciunul dintre câmpurile sale cheie nu este gol.

De exemplu, tabelul prezentat în Fig. 3 nu satisface aceste cerințe (datele din câmpul D№ nu sunt atomice):

Orez. 3. Exemplu de tabel care nu este o relație relațională

Astfel de tabele nici măcar nu sunt luate în considerare în modelele relaționale.

Dacă dezvoltăm o bază de date relațională, atunci în prima etapă poate fi creat un tabel care combină toate datele luate în considerare, de exemplu, Furnizori, Piese, Consumabile. Tabelul din fig. 3 reprezintă o relație relațională corectă. El este numit universal atitudine baza de date proiectată. O relație universală include toate atributele de interes și poate conține toate datele care se așteaptă să fie stocate în baza de date în viitor. Pentru bazele de date mici, relația universală poate fi folosită ca punct de plecare pentru proiectarea bazelor de date. Cheia primară a unui tabel este o combinație a câmpurilor P№ și D№. Acest tabel satisface toate cerințele 1NF.

				Dozimetru
				Radiometru
				Dozimetru
				Dozimetru
				Dozimetru

Orez. 4. Relația în prima formă normală

Diagrama dependențelor funcționale ale unei astfel de relații are forma prezentată în Fig. 4 (vom presupune că statutul furnizorului este determinat de oraș).

Relația în cauză, care este în 1NF, are o structură care din anumite motive nu este în întregime de dorit. De exemplu, există o redundanță evidentă a informațiilor. Acest lucru duce nu numai la o creștere a dimensiunii bazei de date, ci și la diferite anomalii:

Introduce. Nu puteți introduce date despre furnizor (P5) fără a specifica piesa (Valoarea nulă în câmpul cheie nu este permisă).

Șterge. Când ștergeți un anumit tuplu, trebuie să ștergeți prea multe alte informații (ștergerea informațiilor de furnizare șterge informațiile despre furnizor).

Actualizați. Informațiile excesive pot duce la rezultate inconsecvente. Dacă furnizorul P1 s-a mutat în alt oraș, iar actualizarea nu a fost făcută în toate tuplurile, atunci baza de date va conține informații contradictorii.

Aceste anomalii pot fi eliminate prin reducerea relației cu a doua formă normală, împărțind-o în două.

Un tabel este în a doua formă normală (2NF) dacă satisface definiția 1NF și toate câmpurile sale non-cheie primară au o dependență ireductibilă de cheia primară (sau sunt complet dependente funcțional de cheia primară).

Dependențele funcționale ale relațiilor din baza noastră de date reduse la 2NF sunt prezentate în Fig. 4, iar tabelele corespunzătoare sunt în Fig. 5.

Acum puteți introduce informații despre furnizori în baza de date fără informații despre produsul lor; atunci când ștergeți informații despre un produs, datele rămase rămân (despre furnizori, de exemplu), informațiile despre oraș apar o singură dată, iar acest lucru elimină problema asociată. cu redundanță de informații. Adică, datorită descompunerii, am scăpat de multe dintre problemele care erau prezente în relația în 1NF. În același timp, relațiile prezentate în Fig. 5 pot fi combinate și apoi vom reveni la relația prezentată în Fig. 3 - ceea ce înseamnă că descompunerea a fost efectuată fără pierderi de date.

Prin urmare, primul etapă proceduri normalizare relaţie este Creare proiecții Pentru excepții " citat" funcţional dependențe.

Orez. 7. Relații în 2NF

Cu toate acestea, structura relațiilor prezentată în Figura 7 poate crea unele probleme asociate cu o relație Furnizor în care atributele non-cheie nu sunt reciproc independente. Dependența atributului Status de atributul P№ este funcțională și ireductibilă, dar această dependență este și tranzitiv prin atributul City - fiecare valoare P№ determină valoarea City, iar fiecare valoare City determină valoarea Status. Dar dacă dependențele AB și BC sunt satisfăcute, atunci dependența AC este de asemenea satisfăcută. Dependențe tranzitive pot duce din nou la anomalii de actualizare:

Inserare - nu puteți include date despre un anumit oraș și starea acestuia, în timp ce nu există niciun furnizor în el.

Ștergere - atunci când un furnizor este șters, informațiile despre starea orașului se pierd (evident, cauza acestei probleme este informația comună - tabelul conține informații atât despre furnizori, cât și despre oraș).

Actualizare - starea orașelor se repetă de mai multe ori. Când schimbați statutul unui oraș, trebuie să vă uitați prin multe rânduri pentru a evita obținerea de rezultate inconsistente, dar rămâne posibilitatea de eroare.

Problema este rezolvată prin aducerea relației Furnizor la a treia formă normală prin descompunerea acesteia:

Această procedură elimină dependența tranzitivă și rezolvă toate dificultățile.

Atitudine situat V al treilea normal formă (3NF) Apoi Și numai Apoi, Când aceasta situat V 2NF Și fiecare non-cheie atribut intranzitiv depinde din primar cheie.

Cu alte cuvinte: masa situat V al treilea normal formă (3NF), Dacă ea situat V 2NF Și nici unu din a ei non-cheie câmpuri Nu depinde funcţional din orice o alta non-cheie câmpuri.

Prin urmare, al doilea etapă normalizare este Creare proiecții Pentru excepții tranzitiv dependențe.

În timpul procedurii de normalizare, apar adesea situații când o relație poate fi supusă descompunerii în mai multe moduri. De exemplu, relația Furnizor (Fig. 7) cu dependențele funcționale P#City și CityStatus și, prin urmare, dependența tranzitivă P#Status. Există opțiuni posibile pentru descompunerea acestei relații în două proiecții situate în 3NF:

A: (P№, Oraș) și (Oraș, Stare) (așa cum a fost propus mai devreme) și B: (P№, Oraș) și (P№, Stare)

A treia opțiune de descompunere în proiecții (P№, Status) și (Oraș, Status) nu poate fi aplicată, deoarece se realizează cu o pierdere de informații - mai multe orașe pot avea același statut, apoi informații despre orașul în care furnizorul se află se va pierde.

Din anumite motive, descompunerea B este mai puțin dezirabilă decât descompunerea A. De exemplu, după efectuarea descompunerii B, nu este posibilă introducerea informațiilor că un anumit oraș are un anumit statut fără a specifica furnizorul din acel oraș.

În descompunerea A, ambele proiecții sunt independente una de cealaltă, în sensul că actualizările în fiecare dintre proiecții pot fi efectuate complet independent una de cealaltă. În descompunerea B, actualizările oricăreia dintre cele două proiecții trebuie controlate pentru a nu rupe dependența originală CityStatus. Adică, proiecțiile descompunerii B nu sunt independente unele de altele.

Concept independenţă proiecții oferă un criteriu pentru alegerea uneia dintre mai multe descompunere posibilă. Proiecțiile R1 și R2 ale relației R sunt independente în sensul menționat mai sus dacă și numai dacă

Fiecare dependență funcțională în raport cu R este o consecință logică a dependențelor funcționale din proiecțiile R1 și R2;

Atributele comune ale proiecțiilor R1 și R2 formează o cheie candidată pentru cel puțin una dintre ele.

În exemplul luat în considerare în descompunerea A, cele două proiecții sunt independente, deoarece atributul lor comun City este o cheie potențială pentru a doua proiecție și fiecare dependență funcțională a relației originale este păstrată în proiecții. Dimpotrivă, în descompunerea B cele două proiecții nu sunt independente, deoarece dependența CityStatus nu poate fi derivată din dependențele funcționale ale acestor proiecții, deși atributul lor comun P№ este o cheie potențială pentru ambele proiecții.

Ideea de normalizare cu descompunere în proiecții independente a fost propusă de Rissanen și se numește descompunere Cu conservare dependențe.

Forma normală Boyce-Codd

Până acum, am presupus pentru simplitate că fiecare relație are o singură cheie candidată - cheia primară. Definiția de mai sus a 3NF nu este pe deplin potrivită dacă

- relația are două sau mai multe chei candidate;

- două chei candidate sunt complexe și se suprapun (au cel puțin un atribut comun).

Prin urmare, definiția 3NF a fost completată normal formă Boyce-Codd ( Boyce-Codd) - NFBC. Poate fi formulat astfel:

Atitudine situat V normal formă Boyce-Codd Apoi Și numai Apoi, Când determinanți sunt potenţial chei.

Cu alte cuvinte, într-o diagramă de dependență funcțională, săgețile ar trebui să înceapă doar cu cheile candidate.

O combinație de astfel de condiții nu se găsește adesea în practică, așa că pentru relațiile fără astfel de condiții, 3NF și BCNF sunt echivalente.

Să mai dăm o definiție: Masa situat V normal formă Boyce-Codd (NFBC), Apoi Și numai Apoi, Când orice funcţional dependenta între a ei câmpuri se reduce la La ireductibil funcţional dependențe din potenţial cheie.

Luați în considerare un exemplu care implică două chei candidate care nu se suprapun:

Furnizor (P№, Nume_P, Stare, Oraș),

unde atributele P№ și Name_P sunt potențiale chei, iar atributele Status și City sunt complet independente. Diagrama dependențelor funcționale este prezentată în Fig. 8. Această relație se regăsește în BCNF. Aici, toți determinanții sunt chei potențiale și toate săgețile încep cu chei potențiale.

Iată exemple de relații în care potențialele chei se suprapun.

Primul exemplu: Relația de livrare (P№, Name_P, D№, Cant.).

Există o oarecare redundanță în acest sens care provoacă anomalii de actualizare. Cheile potențiale aici sunt (P№, D№) și (Name_P, D№), iar P№ și Name_P se definesc reciproc. Această relație nu este în a doua formă normală și poate fi împărțită în două proiecții (P№, Name_P) și (P№, D№, Cantitate) pentru a obține dependențe funcționale ireductibile. Dar aceeași descompunere poate fi propusă pe baza faptului că relația nu este în BCNF, deoarece conține doi determinanți care nu sunt chei potențiale (P№ și Name_P sunt determinanți, deoarece se definesc unul pe celălalt):

Furnizor (P#, Name_P) și consumabile 1 (P#, D#, Cant.).

Al doilea exemplu: Raport SDP (S, D, P),

unde atributele reprezintă Studenți, Discipline și Profesori. Tuplu al relației SDP înseamnă că un elev C studiază o disciplină D de la un profesor P. Există restricții:

- Fiecare elev studiază o materie dată cu un profesor;

- Fiecare profesor predă o singură materie (dar fiecare materie poate fi predată de mai mulți profesori).

Prima constrângere implică dependența (C, D)P, iar a doua – PD. Figura 9 prezintă un exemplu de tabel și diagramă a dependențelor funcționale ale unei astfel de relații. În exemplul luat în considerare, există două chei potențiale care se suprapun - (S, D) și (S, P). Relația este în 3NF (dependența tranzitivă prezentă aici este de atributul cheie), dar nu este în BNFB și are unele anomalii de actualizare. De exemplu, dacă ștergem informațiile că Oleg studiază fizica, atunci vom pierde informațiile pe care Petrov le predă fizică. Această problemă este cauzată de faptul că P este un determinant, dar nu este o cheie candidată. Pentru a rezolva această problemă, relația inițială trebuie împărțită în două proiecții: SP și PD.

Astfel, conceptul de NFBC ne permite să scăpăm de unele dintre problemele inerente relațiilor din 3NF. Definiția BCNF este mai simplă decât definiția 3NF, deoarece nu folosește conceptele de forme normale, cheie primară și dependență tranzitivă. În plus, conceptul de cheie candidată poate fi înlocuit cu introducerea unui concept mai fundamental de dependență funcțională. Dar, pe de altă parte, conceptele de cheie primară, dependență tranzitivă etc. sunt utile în practică deoarece introduc ideea unui proces incremental efectuat de un dezvoltator pentru a reduce o relație arbitrară la un set echivalent de relații în BCNF.

Forme normale justificate de dependențe mai complexe

Orez. 10. Raportul DPU nenormalizat

Următoarele forme normale (4NF și 5NF) iau în considerare nu numai dependențele funcționale, ci și multivalorice și de conexiune între atributele relației. Pentru a vă familiariza cu ele, luați în considerare raportul nenormalizat prezentat în Fig. 10. Fiecare tuplu de relație conține numele unei discipline, un grup de nume de profesor și un set de manuale. Aceasta înseamnă că fiecare curs poate fi predat de orice profesor folosind orice manual. Să transformăm acest raport într-unul normalizat echivalent. Nu au fost definite dependențe funcționale pentru datele prezentate. Prin urmare, nu există o bază formală pentru descompunerea acestei relații, iar relația normalizată este prezentată în Fig. unsprezece.

		Mecanica
		Mecanica
Matematică		Geometrie
Matematică		Mat. analiză

Orez. 11. Raport DPU normalizat

Orez. 12. Proiecțiile (D,P) și (D,U) ale relației DPU

Evident, relația DPU este caracterizată de o redundanță semnificativă și duce la anomalii de actualizare, de exemplu, atunci când adăugați un profesor nou, trebuie să introduceți un tuplu pentru fiecare manual. Cu toate acestea, atitudinea este în întregime cheie și, prin urmare, este în BCNF. Problemele care apar sunt cauzate de faptul că profesorii și manualele sunt complet independente unele de altele. Problema raportului DPU normalizat nu ar apărea dacă toate grupurile repetate independente ar fi inițial separate. În cazul nostru, a fost posibilă îmbunătățirea situației prin înlocuirea raportului DPU cu proiecții (D, P) și (D, U) (Fig. 12). În acest caz, ambele proiecții sunt complet cheie și sunt situate în BCNF, iar conexiunea lor dă tabelul original, adică descompunerea se realizează fără pierderi. Această descompunere nu poate fi făcută pe baza dependențelor funcționale, care nu sunt prezente în acest exemplu. Poate fi implementat pe baza unei relații multivalorice. Dependențe cu mai multe valori sunt o generalizare a dependențelor funcționale în sensul că fiecare dependență funcțională este una cu mai multe valori a cărei parte dependentă este un set singleton.

În raport cu DPU, există două dependențe multivalorice: DP și DU.

Prima dintre aceste dependențe multivalorice înseamnă că, deși pentru fiecare disciplină nu există un singur profesor care să corespundă numai acestei discipline, adică. dependenta functionala a PD nu este indeplinita, insa fiecare disciplina are un anumit set de profesori, indiferent de denumirea manualului.

A doua dependență multivalorică este interpretată în mod similar.

Lăsa A, B, C sunt arbitrar subseturi seturi atribute relaţie R. ÎN ambiguu depinde din A (A ÎN) Apoi Și numai Apoi, Când o multime de valorile ÎN, adecvat dat cuplu valorile (A, CU) relaţie R, depinde numai din A, Dar Nu depinde din CU.

În mod evident, dependența multivalorică AB este satisfăcută numai atunci când dependența multivalorică AC este satisfăcută. Dependențe cu mai multe valori formează întotdeauna perechi înrudite: AB||C.

Revenind la problemele relației DPU, putem spune că acestea sunt asociate cu existența unor dependențe multivalorice care nu sunt funcționale (este prezența unor astfel de dependențe care necesită inserarea a două tuple atunci când este necesar să se adauge date despre un altul). profesor de fizică). Proiecțiile (D, P) și (D, U) nu conțin dependențe cu mai multe valori și, prin urmare, sunt mai de dorit. Înainte de a defini cea de-a patra formă normală, să ne familiarizăm cu teorema lui R. Fagin:

Fie A, B, C seturi de atribute ale relației R(A, B, C). Relația R va fi egală cu combinația proiecțiilor sale (A, B) și (A, C) dacă și numai dacă dependențele multivalorice AB și AC sunt îndeplinite pentru relația R.

Atitudine R situat V Al patrulea normal formă (4NF) Apoi Și numai Apoi, Când V caz existenţă polisemantic dependențe A B Toate odihnă atribute R funcţional depinde din A.

Cu alte cuvinte:

Atitudine R situat V 4NF, Dacă aceasta situat V NFBC Și Toate polisemantic dependențe relaţie R de fapt sunt funcţional dependențe din potenţial chei.

Relația DPU nu este în 4NF deoarece conține o dependență multivalorică care nu este o dependență funcțională. Cu toate acestea, ambele proiecții (D, P) și (D, U) sunt în 4NF, ceea ce, în comparație cu BCNF, vă permite să creați o structură îmbunătățită.

Rețineți că conceptul lui Rissanen de proiecții independente, bazat pe dependențe funcționale (relația R(A,B,C), care satisface dependențele funcționale A>B și B>C, ar trebui împărțit în proiecții (A,B) și (B, C), și nu (A,B) și (A,C)), este aplicabilă și alegerii căii de descompunere, dacă în loc de dependențe funcționale există dependențe multivalorice A>>B și A>>C. În acest caz, trebuie efectuată descompunerea în relații (A,B) și (A,C).

În toate procedurile de normalizare avute în vedere până la acest punct, a fost efectuată descompunerea unei relații în două. Uneori, acest lucru nu se poate face, dar este posibilă descompunerea într-un număr mai mare de relații, fiecare dintre ele având proprietăți mai bune. O astfel de relație se numește relație n-descompusă, pentru care n>2.

Luați în considerare, de exemplu, relația P-D-Pr (Furnizori-Piese-Proiecte) (Fig. 13). Același furnizor poate furniza mai multe tipuri de piese pentru proiecte diferite. Cheia primară a acestei relații este setul complet al atributelor sale; nu există dependențe funcționale și multivalorice (nu există dependență multivalorică, deoarece pentru P1 setul de părți depinde de proiect). Prin urmare, relația este în 4NF. Cu toate acestea, pot exista anomalii în el (nu întotdeauna evidente), care pot fi eliminate prin descompunerea în trei relații (descompunerea în două relații este imposibilă, deoarece operația inversă nu permite revenirea la relația inițială). Mai mult, gradul de descompunere depinde de tupluri. De exemplu, dacă în relația originală se elimină unul dintre primele trei tupluri sau se adaugă tuplu (P2, D1, P2), atunci acesta poate fi împărțit în două proiecții. Dacă în relația originală ultimul tuplu este eliminat sau înlocuit cu un tuplu (P2, D1, Pr2), atunci acesta nu poate fi împărțit în două sau trei proiecții fără a încălca integritatea datelor. Decompozibilitatea acestei relații poate fi o proprietate fundamentală și independentă de timp dacă se adaugă o constrângere suplimentară.

Afirmația că PDPr este egală cu combinația a trei proiecții PD, DPr, PrP este echivalentă cu următoarea afirmație:

IFpair (P1, D1) aparține relației PD

Ipara (D1, Pr1) apartine relatiei Dpr

Ipara (Pr,1P1) apartine relatiei PrP,

TOTtriplu (P1, D1, Pr1) aparține relației PDPr.

Acest lucru este evident, deoarece triplul P1, D1, Pr1 este situat în legătura proiecțiilor PD, Dpr, PrP. Afirmația inversă este, de asemenea, întotdeauna adevărată.

Pe de altă parte, este adevărat că perechea (P1, D1) este prezentă în raport cu PD dacă triplul (P1, D1, Pr2) este prezent în raport cu PDP, perechea (P1, D1) este prezentă în relație. la PPr dacă (P1, D2, Pr1) este în DPR, iar perechea (D1, Pr1) este în relație cu DPR, dacă (P2, D1, Pr1) este în DDP. Atunci, dacă luăm în considerare prima noastră afirmație, atunci tuplu (P1, D1, Pr1) trebuie să fie prezent într-o astfel de relație! Aceasta înseamnă că pentru a asigura corectitudinea raportului DPR în orice moment, este necesar să se introducă următoarea restricție:

Dacă tupluri (P1, D1 , Pp2), (P2, D1 , Pp1) Și (P1, D2 , Pp1) aparține atitudine PDPr, Acea Și caravană (P1, D1 , Pp1) De asemenea aparține acest atitudine.

Dacă această afirmație este întotdeauna adevărată, adică pentru toate tuplurile suplimentare posibile ale relației PDPr, atunci se va obține o constrângere independentă de timp asupra acestei relații, care se numește constrângere 3D. Deoarece o constrângere 3D este satisfăcută atunci când o relație este echivalentă cu o conexiune a unora dintre proiecțiile sale, o astfel de constrângere se numește constrângere de conexiune.

Puteți acorda atenție faptului că în exemplul pe care îl luăm în considerare există o anumită ciclicitate în date. Criteriul pentru n-descompunerea unei relații pentru n>2 este o constrângere ciclică. Ce înseamnă constrângere ciclică? În exemplul nostru, să fie ultimul tuplu să însemne că Smith furnizează chei pentru Proiectul Manhattan. Primele trei tupluri poartă informația că Smitt furnizează chei, Smitt este furnizor al Proiectului Manhattan, iar cheile sunt folosite în Proiectul Manhattan. Dar aceste afirmații nu implică faptul că Smith este cel care furnizează cheile pentru acest proiect. Dacă descompunem relația PDPr, constând din aceste trei tupluri, în trei proiecții, atunci conexiunea lor nu va fi egală cu cea originală - va apărea un al patrulea tuplu „extra” (P1, D1, Pr1), așa cum am menționat mai sus. Pentru a evita o astfel de discrepanță, se introduce o constrângere suplimentară, care poate fi implementată cu ușurință prin descompunerea relației. O astfel de descompunere este posibilă fără pierderi de informații numai dacă există o dependență de conexiune:

Atitudine R (X Y,. , Z) satisface dependențe conexiuni * (X Y,. , Z) V volum Și numai V volum caz, Când R este în curs de restaurare fără pierderi de conexiuni al lor proiecții pe X, Y,. , Z.

Să ne uităm la două exemple de anomalii care există într-o relație care este supusă unei constrângeri 3D.

2. În relația prezentată în Fig. 15, tuplu (P2, D1, Pr1) poate fi șters fără probleme. Dar dacă ștergeți (P1, D1, Pr1), atunci trebuie să ștergeți unul dintre cele rămase, astfel încât să nu existe ciclicitate în date.

Acum teorema lui Feigin poate fi formulată după cum urmează:

Atitudine R (A, B, C) satisface dependențe conexiuni * (AB, ACU) Apoi Și numai Apoi, Când aceasta satisface ambiguu dependențe A ÎN Și A CU.

O dependență de unire este o generalizare a conceptului de dependență multivalorică. În plus, este cea mai comună formă de dependență.

Revenind la relația Furnizori-Piese-Proiecte, veți descoperi că aceasta conține o dependență de unire PDPr * (PD, DPr, PrP), care nu este nici o dependență funcțională, nici cu mai multe valori și nu este implicată de singura sa cheie potențială - o combinație a tuturor atributelor. Se recomandă descompunerea unei astfel de relații în proiecții specificate de dependența de conexiune. Acest proces de descompunere poate fi repetat până când toate relațiile rezultate sunt înscrise a cincea normal formă (5NF).

Atitudine R situat V a cincea normal formă V volum Și numai V volum caz, Când orice dependenta conexiuni V R ar trebui să din existenţă niste posibil cheie V R.

O definiție mai puțin strictă a 5NF:

Masa situat V a cincea normal formă (5NF) Apoi Și numai Apoi, Când V fiecare a ei deplin descompunere Toate proiecții conține posibil cheie. Masa, Nu având nici unu deplin descompunere, De asemenea situat V 5NF.

Acum putem spune că după 3-descompunerea relațiilor PDPr proiecțiile sale PD, DPR și PPR sunt în formă normală 5, deoarece pentru ele nu există deloc dependență de conexiune.

A patra formă normală (4NF) este un caz special de 5NF, unde descompunerea completă trebuie să fie o unire a exact două proiecții. Nu este ușor să găsești o masă reală care să fie în 4NF, dar nu în 5NF.

Pentru o relație R dată, putem spune că este în 5NF, cu condiția ca toate cheile potențiale și toate dependențele de conexiune să fie cunoscute. Cu toate acestea, nu există un algoritm care să vă permită să determinați toate dependențele unei conexiuni. Dar astfel de relații sunt extrem de rare în practică.

A cincea formă normală este ultima formă normală care poate fi obținută prin descompunere. Condițiile sale sunt destul de nebanale, dar practic nu este folosit.

Procedura de normalizare și proiectare

Am analizat tehnologia de descompunere fără pierderi utilizată pentru proiectarea bazelor de date. Ideea de bază a acestei tehnologii este de a reduce sistematic relația originală, găsită în 1NF, la un set de relații mai mici, care într-un anumit sens este echivalent cu relația originală, dar este mai de preferat. Fiecare etapă a procesului de reducere constă în împărțirea în proiecții a relațiilor obținute în etapa anterioară. În acest caz, restricțiile specificate sunt utilizate la fiecare pas al procedurii de normalizare pentru a selecta proiecțiile în etapa următoare. Normalizarea este împărțirea unei relații (tabel) în mai multe relații care au proprietăți mai bune la actualizarea, inclusiv și ștergerea datelor. Acest proces de înlocuire succesivă a unui tabel cu descompunerile sale complete se realizează până când toate sunt în 5NF (în practică, ele se limitează de obicei la reducerea relației cu forma normală Boyce-Codd). În general, se pot distinge următoarele obiective ale procesului de normalizare:

eliminarea anumitor tipuri de redundanță;

remediază unele actualizări, activează și șterge anomalii;

proiectarea unui aspect al bazei de date care este o reprezentare „bună” a lumii reale, este intuitivă și oferă o bază bună pentru dezvoltarea ulterioară;

simplificarea procesului de impunere a constrângerilor de integritate.

Să enumerăm regulile de bază care sunt utilizate în procedura de normalizare.

1. Relația unificată trebuie redusă la 1NF.

2. Relațiile din 1NF ar trebui să fie împărțite în proiecții pentru a exclude toate dependențele funcționale care nu sunt ireductibile.

Cu alte cuvinte, dacă o relație are o cheie primară compusă de forma (K1, K2) și include și un câmp F, care depinde funcțional de o parte a acestei chei, de exemplu, de K2, dar nu de cheia completă, atunci în acest caz, se recomandă să se formeze o altă relație care să conțină K2 și F (cheia primară - K2) și să se elimine F din relația originală:

În urma acestei acțiuni se va obține un set de relații în 2NF.

3. Relațiile din 2NF ar trebui să fie împărțite în proiecții pentru a exclude orice dependențe funcționale tranzitive. Cu alte cuvinte, dacă o relație are o cheie candidată K, un atribut cheie non-candidat F1 care este dependent funcțional de K și un alt atribut non-cheie F2 care este dependent funcțional de F1, atunci se recomandă eliminarea atributului F2 din relația originală și formează o altă relație care conține F1 și F2, cu cheia primară F1.

Rezultatul va fi un set de relații în 3NF.

5. Relațiile din BCNF ar trebui să fie defalcate în proiecții pentru a elimina toate dependențele cu mai multe valori care nu sunt dependențe funcționale. Rezultatul va fi un set de relații în 4NF (în practică, astfel de dependențe multivalorice sunt de obicei excluse la crearea relațiilor originale, separând grupurile independente care se repetă).

6. Relațiile ar trebui să fie împărțite în proiecții pentru a elimina orice dependențe de unire care nu sunt implicate de cheile candidate, dacă pot fi identificate. Acest lucru va avea ca rezultat un set de relații în 5NF (descompunerea completă a relațiilor).

Când urmează regulile propuse, este necesar să ne amintim că partiționarea în proiecții trebuie efectuată fără pierderi de date și păstrând în același timp dependențele funcționale și cu mai multe valori.

Orientările de normalizare sugerate sunt doar linii directoare și pot exista situații în care normalizarea nu ar trebui finalizată de la început până la sfârșit. Există mai multe motive pentru această presupunere. În primul rând, normalizarea poate ajuta la capturarea unor constrângeri de integritate într-o formă simplă, dar pe lângă dependențele funcționale, cu valori multiple și de unire, pot exista și alte tipuri de dependențe în practică. În al doilea rând, există puține criterii pentru alegerea unei descompunere preferată. În al treilea rând, procesul de normalizare și persistența dependenței nu sunt întotdeauna compatibile. În al patrulea rând, nu toată redundanța poate fi eliminată în procesul de normalizare.

Proiectarea sistemelor de baze de date începe cu construirea unui model de date informaționale, i.e. identificarea entității. Următorii pași ai procedurii de proiectare trebuie apoi parcurși:

1. Reprezentați fiecare entitate independentă ca un tabel de bază de date (tabel de bază) și definiți cheia primară a acestui tabel de bază.

2. Reprezentați fiecare asociere (relație între entități) ca un tabel de bază. Utilizați chei străine în acest tabel pentru a identifica membrii asociației și pentru a specifica constrângerile asociate cu fiecare dintre aceste chei străine.

3. Reprezentați proprietățile entității ca tabele de bază cu o cheie externă care identifică entitățile corespunzătoare. Specificați constrângeri pentru cheile externe ale acestor tabele și cheile lor primare.

4. Pentru a exclude încălcările neintenționate ale oricăror principii de normalizare din proiect, efectuați procedura de normalizare.

5. Dacă în timpul procesului de normalizare s-au împărțit tabele, atunci modelul de informații al bazei de date ar trebui modificat și pașii de mai sus trebuie repeți.

6. Indicați constrângerile de integritate ale bazei de date proiectate și oferiți (dacă este necesar) o scurtă descriere a tabelelor rezultate și a câmpurilor acestora.

Pentru a reprezenta vizual structura sistemului proiectat, se poate folosi limbajul de modelare a informațiilor „Tabel-relație”, utilizat în cele mai comune baze de date relaționale. În acesta, toate entitățile sunt reprezentate ca tabele cu o singură coloană cu titluri care constau din numele entității. Rândurile tabelului sunt o listă de atribute de entitate, iar cele care alcătuiesc cheia primară sunt evidențiate. Relațiile dintre entități sunt indicate prin săgeți direcționate de la cheile primare sau componentele acestora.

7. Exemplu de proiectare a bazei de date

Scop și domeniu

Baza de date este concepută pentru a stoca informații despre personalul unei anumite companii. Compania are mai multe departamente. Fiecare departament are mai mulți angajați, mai multe proiecte și mai multe birouri. Fiecare angajat are mai multe sarcini. Pentru fiecare sarcină, există o declarație cu o listă a sumelor de bani primite de angajat pentru efectuarea acestei lucrări. Fiecare birou are mai multe telefoane.

Următoarele informații ar trebui stocate în baza de date:

Pentru fiecare departament: un număr unic de departament, buget și un număr unic al șefului de departament;

pentru fiecare angajat: un număr unic de angajat, numărul actual al proiectului, numărul biroului, numărul de telefon, precum și denumirea lucrării care se execută, împreună cu datele și sumele tuturor plăților primite pentru efectuarea acestei lucrări;

pentru fiecare proiect: număr unic de proiect și buget;

pentru fiecare birou: număr unic de birou, zonă, toate numerele de telefon.

Declarații semantice (restricții): Niciun angajat nu este simultan șeful mai multor departamente; niciun angajat nu lucrează în mai mult de un departament în același timp; niciun angajat nu lucrează simultan la mai multe proiecte; niciun angajat nu are mai mult de un birou la un moment dat; niciun angajat nu are mai mult de un telefon la un moment dat; niciun angajat nu are mai multe sarcini la un moment dat; niciun proiect nu este dat la mai mult de un departament la un moment dat; niciun birou nu aparține mai mult de un departament în același timp.

Proiectarea bazei de date

Analiza obiectelor și atributelor definite mai sus ne permite să identificăm entitățile bazei de date proiectate și să construim modelul de informații al acesteia sub forma unui „Tabel de legături” (Fig. 16).

Orez. 16. Informații despre companie care ar trebui stocate în baza de date

Structura ierarhică originală poate fi privită ca o relație nenormalizată:

DEPARTAMENTE (DEPARTAMENT NR., BUGET_O, MANAGEMENT NR., ANGAJATI, PROIECTE, BIROURI) CHEIA CANDIDATULUI (DEPARTAMENT NR.) CHEIA CANDIDATULUI (NR. MANAGEMENT)

Aici, semnificația atributelor DTD# (număr unic de departament), BUDGET_O, RUK# (număr manager) este clar din nume, iar atributele ANGAJATE, PROIECTE, BIRURI constau în valori de relație. Putem descrie atributele lor imbricate:

DEPARTAMENTE (Nr. DEPARTAMENT, BUGET, Nr. MANAGEMENT, ANGAJATI (Nr. STEAM, Nr. PROIECT, Nr. BIROU, Nr. TEL, LUCRARE (TEMA, PLATA (DATA, SUMA))), PROIECTE (Nr. PROIECT, BUGET_P ), BIROURI (NR. BIROU, ZONA, TELEFON (TEL#))) CHEIA CANDIDATULUI (# DEPARTAMENTUL) CHEIA CANDIDATULUI (RUNK#)

Acum putem reduce această relație la un set de relații în 1NF. În același timp, luând în considerare fiecare relație valoare separat, excludem toate dependențele multivalorice care nu sunt dependențe funcționale.

DEPARTAMENTE1 (DEPARTAMENT#, BUDGET_O, MANAGEMENT#) CHEIE PRIMARĂ (DEPARTAMENT#) CHEIE ALTERNATĂ (MANAGEMENT#)

ANGAJAT1 (Nr. COTR, ​​Nr. DEPARTAMENT, Nr. PROIECT, Nr. CABINA, Nr. TEL) CHEIE PRIMARĂ (NR. ANGAJAT)

LUCRARE1 (SUBIECTUL, NR. COPIATOR) CHEIE PRIMARĂ (SUBIECTUL, NR. COPIAȚI)

PLATA1 (NR. CORPORATIE, SUBIECTUL, DATA, SUMA) CHEIE PRIMARĂ (NR. CORPORATIE, SUBIECTUL, DATA)

PROIECTS1 (PROIECT#, BUDGET_P, DEPARTMENT#) CHEIE PRIMARĂ (PROIECT#)

BIROURI1 (NR. CAMERA, ZONA, NR. DEPARTAMENT) CHEIA PRIMARĂ (NR. CAMERA)

TELEFONURI1 (NUMĂR DE TELEFON, nr. cameră) CHEIE PRIMARĂ (Nr. DE TELEFON)

Relațiile DEPARTMENTS1, EMPLOYEE1, PAYMENT1, PROJECTS1, OFFICES1 și PHONES1 sunt deja în 2NF.

Relația JOB1 este o proiecție a relației PAYMENT1, prin urmare conține informații redundante și poate fi ștearsă fără pierderi de date. În același timp, relația PHONES1 este o proiecție a relației EMPLOYEES1, dar dacă este ștearsă, vor apărea anomalii de actualizare - datele despre telefoane nu vor exista fără date despre anumiți angajați.

Să arătăm acum structura unei baze de date, ale cărei relații sunt reduse la 2NF, folosind limbajul de modelare „Table-Relationship”, care este utilizat în MS ACCESS DBMS:

În plus, excluzând dependențele tranzitive, putem reduce relațiile la un set echivalent de relații în 3NF. Singura relație care nu este în 3NF este relația COTRUDN, în care atributele KABNo. și DTDNo. depind tranzitiv de cheia primară COTRNO. - KABNo. prin TELNo. și DTDNo. prin PROJECTNo. și, în plus, prin KABNo. . și TEL NR. Atunci relația COTRUDN poate fi înlocuită cu un set de proiecții situate în 3NF:

X (TEL#, CAB#) CHEIE PRIMARĂ (TEL#)

Y (Nr. PROIECT, Nr. DEPARTAMENT) CHEIE PRIMARĂ (Nr. PROIECT)

Z (KAB#, OTD#) CHEIE PRIMARĂ (KAB#)

Dar relația X este un analog al relației PHONE2, Y este o proiecție a relației PROJECT2, Z este o proiecție a OFFICE2 și, prin urmare, poate fi eliminat din modelul bazei de date. Prin urmare, un model de bază de date ale cărui relații sunt reduse la 3NF va arăta astfel:

DEPARTAMENTE3 (DEPARTAMENT#, BUDGET_O, MANAGEMENT#) CHEIE PRIMARĂ (DEPARTAMENT#) CHEIE ALTERNATĂ (MANAGEMENT#)

ANGAJAT3 (COTRNO., PROIECT NR., TEL.) CHEIE PRIMARĂ (COTRNO.)

PLATA3 (NR. CORPORATIE, SUBIECTUL, DATA, SUMA) CHEIE PRIMARĂ (NR. CORPORATIE, SUBIECTUL, DATA)

PROIECTS3 (PROIECT#, BUDGET_P, DEPARTMENT#) CHEIE PRIMARĂ (PROIECT#)

BIROURI3 (NR. CAMERA, ZONA, NR. DEPARTAMENT) CHEIA PRIMARĂ (NR. CAMERA)

TELEFONURI3 (NUMĂR DE TELEFON, nr. cameră) CHEIE PRIMARĂ (Nr. TELEFON)

Fiecare dintre aceste relații este în BCNF. Mai mult decât atât, sunt în 4NF - am scăpat de posibile dependențe multi-valorice în etapa de aducere a modelului la 1NF. Toate relațiile nu conțin anomalii vizibile și, prin urmare, se poate presupune că baza de date este construită corect.

Literatură

1. Beck, modele de implementare a aplicațiilor pentru întreprinderi Kent; M.: Williams, 2008. - 369 p.

2. Weimayer, R.; Sawtel, R. Master Microsoft SQL Server 2000 pe cont propriu în 21 de zile (+ CD-ROM); M.: Williams, 2013. - 549 p.

3. Ganderloy, Mike; Harkins, Susan Sales Automatizarea Microsoft Access cu VBA; M.: Williams, 2013. - 416 p.

4. Goetz, Ken; Ginbert, Michael; Litvin, Paul Access 2000. Ghidul dezvoltatorului. Volumul 1. Aplicații desktop. volumul 1; Kiev: BHV, 2008. - 576 p.

5. Golitsyna, O.L. și alte baze de date; Forum; Infra-M, 2013. - 399 p.

6. Grincenko, N.N. etc.Proiectarea bazei de date. Microsoft Access DBMS; Hot Line Telecom, 2012. - 613 p.

7. Date, K. J. Introducere în sistemele de baze de date; K.: Dialectică; ediția a VI-a, 2012. - 360 p.

8. Davidson, Louis proiectarea bazei de date pe SQL Server 2000; Beanom, 2009. - 631 p.

9. Duval, Paul M. Integrare continuă. Îmbunătățirea calității software-ului și reducerea riscului; M.: Williams, 2008. - 497 p.

10. Karatygin, S.; Tikhonov, A. Lucrul în Paradox pentru Windows 5.0 cu exemple; M.: Binom, 2011. - 512 p.

11. Karatygin, Sergey Access 2000 cu exemple. Ghidul utilizatorului cu exemple; M.: Laboratorul de Cunoștințe de bază, 2012. - 376 p.

12. Kaufeld, John Microsoft Office Access 2003 for Dummies; M.: Dialectică, 2013. - 439 p.

13. Couchman, Jason; Schwinn, Ulrike Oracle 8i CertifiedProfessionaql DBA Training administrator baze de date; LORI, 2009. - 510 p.

Documente similare

Conceptul unui sistem de baze de date. Modelul relațional și caracteristicile acestuia. Integritatea în modelul relațional. Algebră relațională. Probleme de proiectare a bazelor de date. Forme normale de relații. Proiectarea unei baze de date folosind metoda entitate-relație. Diagramele ER. Limbajul SQL.

curs de prelegeri, adăugat 10.03.2008


Folosind normalizarea. A doua și a treia formă normală. Forma normală Boyce-Codd. A patra și a cincea formă normală. Modelare semantică a datelor, diagrame ER. Concepte de bază ale modelului Entitate-Relație.

test, adaugat 08.07.2007


Conceptul de normalizare a tabelelor bazei de date și scopul acestuia. Etapele procesului de normalizare. Un exemplu de date nenormalizate. Forme normale la care se reduc tabelele. Algebra relațională asupra bazei educaționale. Baza de date pentru tema „Tutoriale”.

test, adaugat 30.07.2010


Crearea unei structuri de bază de date folosind exemplul „Jurnalului școlii” folosind metoda și principiul normalizării. Concepte de baze de date, arhitectură și design de baze de date. Descrierea domeniului subiectului; aplicații pentru lucrul cu baza de date TTable și TQuery.

teză, adăugată 04.01.2012


Studiul fundamentelor teoretice ale proiectării și dezvoltării bazelor de date. Identificarea dependențelor funcționale, construirea unui model informațional. Revizuirea limbajului și a instrumentelor software concepute pentru crearea, întreținerea și partajarea bazelor de date.

lucrare de curs, adăugată 22.02.2012


Autorizare cu cataloage de proiectare baze de date magazin. Sarcini de bază de date: contabilizarea tuturor bunurilor, căutarea și emiterea datelor clienților, adresa, numerele de telefon, prețul și disponibilitatea mărfurilor. Etapele proiectării bazei de date. Schema de date, crearea de interogări și formularele acestora.

rezumat, adăugat 22.10.2009


Fundamentele proiectării bazelor de date relaționale. Schema relațiilor dintre modele și reprezentări ale unui sistem complex în procesul de analiză orientată pe obiecte. Exemple de reprezentare grafică a unor clase specifice. Înțelegerea modelului de date informaționale.

prezentare, adaugat 14.10.2013


Definiții necesare înțelegerii procesului de proiectare a bazelor de date relaționale bazate pe normalizare. Descompunere fără pierderi folosind teorema lui Heath. Actualizări anormale. Dezvoltarea bazei de date și modele de aplicații, analiza problemelor în timpul creării acestora.

prezentare, adaugat 14.10.2013


Baza de date integrata. Dezvoltarea conceptului și structurii unei baze de date corporative pentru un nou sistem informațional. Abordări ale metodelor de proiectare a bazelor de date: deschiderea componentelor și interoperabilitatea semantică; dezvoltarea modelelor conceptuale.

raport, adăugat la 01.11.2011


Analiza domeniului de studiu, formalizarea acesteia folosind dependențe funcționale. Etape de minimizare a sistemului de dependențe funcționale și, pe baza sistemului redus rezultat, proiectarea unui model de bază de date. Crearea și modelarea interogărilor.

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

Ghid de proiectare a bazelor de date.

1. Introducere.

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

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

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

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

Model relațional.

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

Regulile modelului relațional dictează modul în care informațiile ar trebui să fie organizate în tabele și modul în care tabelele sunt legate între ele. În cele din urmă, rezultatul poate fi prezentat sub forma unei diagrame de bază de date sau, mai 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ă instalarea MySQL, veți obține doar o interfață de linie de comandă pentru a interacționa cu MySQL. Personal, prefer un GUI pentru a-mi gestiona bazele de date. Folosesc des SQLyog. Acesta este un utilitar GUI gratuit. Imaginile tabelului din acest manual sunt preluate de acolo.

Modelare vizuală.

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

Design independent de RDBMS.

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

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

2. Istorie.

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

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

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

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

Tabele baze de date.

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

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

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

Istoria modelului relațional.

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

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

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

3. Caracteristicile bazelor de date relaţionale.

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

Folosind chei.

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

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

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

Fără redundanță de date.

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

Limitare de intrare.

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

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

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

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

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

Menținerea integrității datelor.

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

Cesiunea de drepturi.

Majoritatea RDBMS-urilor oferă setări de permisiuni care vă permit să atribuiți anumite drepturi anumitor utilizatori. 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 instrucțiunea SQL JOIN. După cum am menționat mai devreme, SQL nu va fi discutat în acest tutorial. Mă voi concentra pe proiectarea bazei de date.

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

Portabilitate.

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

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

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

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 pentru prelucrarea 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 o problemă specifică de prelucrare a 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, se creează instrumente software care operează pe aceleași date și utilizează un singur model de informații al obiectului. Aceste instrumente nu depind de natura obiectului sau de modelul acestuia; ele pot fi utilizate 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. Se disting următoarele tipuri de sisteme informaționale: sisteme factice, 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 sunt capabile să ofere 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) - sistemele inteligente concepute pentru a juca rolul unui „consilier” sunt construite pe baza experienței și cunoștințelor formale ale unui expert. 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 software orientate pe obiect este considerată norma. 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. Setul de valori valide pentru un atribut (coloană) 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 sale (unul sau mai multe tabele 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.

O cheie este folosită pentru a identifica o înregistrare individuală într-un tabel. 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. Folosind chei străine, se stabilesc conexiuni între diferite tabele de baze de date (un exemplu este prezentat în Fig. 1.3) - accelerând accesul la 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 efectuate 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 index și găsiți numărul paginii dorite. 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ă doar nume de familie și link-uri către poziția de înregistrare în tabelul principal. Acum nu mai trebuie să vă uitați prin întregul tabel mare pentru a căuta înregistrări. 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.

Se realizează prelucrarea operațională a datelor în 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 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 tipări 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 fără date redundante.

REVIZUIREA NOTELOR DE PRELEGERE

Pentru studenții de specialitate
T1002 „Software pentru tehnologia informației”

(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. Ciclul de viață al bazei 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 informațional managementului.

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 gestionare a 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) folosind un 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. garanta securitatea și integritatea datelor;

· controlează accesul la date simultan pentru mulți utilizatori; exclude influența cererii unui utilizator asupra cererii altuia și împiedică accesul simultan, care ar putea corupe datele, de ex. 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ă funcționalitatea specificată a unui sistem 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ă ca funcționalitatea de gestionare a fișierelor sistemului gazdă să fie utilizată pentru a servi diferite aplicații. Un DBMS este un strat suplimentar de software construit peste software-ul sistemului 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 este o structură logică specifică construită din datele fizice subiacente. Pentru a oferi o interfață între memoria fizică a bazei de date și diferitele sale versiuni logice (mai multe vizualizări suportate), SGBD-ul, la rândul său, trebuie să fie format din mai multe straturi.

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ă cu trei niveluri. Cele trei niveluri de arhitectură sunt: ​​intern, conceptual și extern.

Nivel intern – acesta este nivelul care determină aspectul fizic al bazei de date, cel 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 vor stoca date, ce metode de acces vor fi utilizate pentru a prelua și actualiza datele și ce măsuri ar trebui luate pentru a menține sau îmbunătăți performanța 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. La 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 designului 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 sunt foarte importante și necesită o analiză detaliată, deoarece se bazează pe abordare centrat pe date. Elementele de date sunt mai stabile decât funcțiile de sistem efectuate. Crearea unei structuri de date corecte necesită o analiză complexă a claselor de unități de date și a relațiilor dintre acestea. 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, în această etapă de colectare a datelor și definirea cerințelor, a 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, sondaje, chestionare etc.); fixarea funcţiilor sistemuluiși identificarea sistemelor de aplicații care vor îndeplini aceste cerințe. Datele sunt prezentate sub formă de 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 folosite 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 – procesul de transformare a unui model conceptual într-o bază de date funcțională. 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 al 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) Crearea de programe aplicative, control de management.

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 emite comenzi adecvate managerului de memorie.

Procesorul de interogări (managerul) transformă o acțiune de interogare sau de bază de date care poate fi executată la un nivel foarte înalt (de exemplu, ca interogare 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 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. Dacă operația este efectuată corect, 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 s-ar fi produs dacă 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 este un 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.

· Un domeniu 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 este un număr fix de atribute de relație:

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

Relația corporală 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 de atribute. 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 bazei de date (design fizic al 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.

· Descrierea modelelor externe în ceea ce privește DBMS-ul 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.

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 baze 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 descompunerii 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:

prima formă normală (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 descompunerile sale complete 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, cheia primară, legea federală

pe , cheie primară

și, cheie 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 o parte a cheii complexe (adică toate câmpurile care nu sunt incluse în cheia primară sunt legate prin dependență funcțională deplină 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 este redusă 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 cheile potențiale sunt într-o relație și cum sunt interconectate atributele, nu se poate spune că o relație dată este în 5NF sau în alte forme normale.

Cheie posibilă 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. unele reguli specifice pe care o bază de date trebuie să le îndeplinească, împreună cu reguli generale care reprezintă o parte a modelului relațional și se aplică fiecărei baze de date.

Implementările unor SGBD-uri relaționale specifice în prezent nu folosesc algebră relațională pură sau calcul relațional în forma lor pură. Standardul de facto pentru accesarea datelor relaționale a devenit SQL (Structured Query Language).

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, la 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 cele 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 6-a: Trans. din engleza - LA.; M.; Sankt Petersburg: 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.: Grupul Editura BHV, 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. CASE-instrumente 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.