Normalizarea bazei de date sau dependența funcțională este o situație în care o valoare permite o tranziție lină la următoarea valoare dintr-o secvență fără nicio întrerupere. Pentru acest tip de situație, există un flux de informații în baza de date care are loc fără întârzieri sau probleme, iar integritatea datelor în sine este menținută. Dependența funcțională este critică pentru crearea și funcționarea bazelor de date relaționale, deoarece procesul implică asocieri ușoare cu o singură valoare sau un tip de date cu valori corespunzătoare.

Una dintre cele mai ușoare modalități de a înțelege modul în care dependența funcțională duce la îndeplinire treaba este să luați în considerare utilizarea unui număr de identificare guvernamentală, cum ar fi un număr de securitate socială, care este emis în mod regulat fiecărui cetățean rus. Prin utilizarea acestui număr ca mijloc de identificare, este posibil ca angajatorii să aibă acces la informații despre proprietarul acestui număr; Potențialii creditori și alți creditori pot folosi numărul de acces pentru a accesa informații financiare relevante despre solicitant, iar numărul permite accesul la informații precum impozite, angajamente și impozite plătite, venituri de la un an la altul și pentru calculele de pensionare atunci când persoana respectivă. se va bucura în cele din urmă de ceea ce merită după pensionare. În multe cazuri, angajatorii pot folosi de fapt același număr ca numărul de identificare principal al angajatului sau o parte din numărul de instrumente relaționale pentru a accesa restul fișierului electronic al angajatului.

Ca parte a proiectării și funcționării bazei de date, o dependență funcțională permite utilizatorilor să introducă anumite valori care pot fi apoi folosite pentru a obține informațiile dorite. De exemplu, un agent de vânzări poate introduce o valoare a numelui companiei pentru a prelua toate înregistrările asociate cu contactele asociate cu un client corporativ. De asemenea, un agent de vânzări care intenționează să vândă poate introduce un nume de oraș ca valoare și ca mijloc de accesare a numelui și informațiilor de contact ale tuturor clienților aflați în apropierea destinației sale, facilitându-i să aranjeze întâlniri cu acești clienți. .

În timp ce structura exactă, cum ar fi sistemul care oferă dependența funcțională, poate varia în funcție de aplicație, rezultatul final va fi în continuare același. Un sens este legat de altul, permițându-vă să accesați informațiile de care aveți nevoie cu relativă ușurință. Având în vedere că atât de multe înregistrări sunt stocate în baze de date, în loc să se bazeze pe vechea metodă de copiere a fișierelor pe hârtie, acest tip de dependență relațională este foarte importantă pentru găsirea și utilizarea datelor relevante.

Adnotare: Această prelegere introduce conceptul de dependență funcțională. Acest concept stă la baza teoriei matematice a bazelor de date relaționale.

Informații, date, sisteme informaționale

Conceptul de dependență funcțională în date

Să lăsăm deoparte deocamdată răspunsul la întrebarea de ce proiectele de baze de date relaționale sunt proaste, adică. De ce trebuie să proiectați o bază de date relațională? Să încercăm mai întâi să răspundem la întrebările „Ce este proiectarea bazelor de date relaționale? și „Care este baza procedurilor?”

După cum se știe, unitatea principală de reprezentare a datelor în modelul relațional este o relație, care este specificată matematic printr-o listă de nume de atribute, altfel - schema de relatii. Pe scena design logicÎntr-o bază de date relațională, proiectantul definește și construiește diagrame de relații într-un anumit domeniu, și anume, reprezintă entități, grupează atributele acestora și identifică principalele conexiuni dintre entități. Astfel, în sensul cel mai general, proiectarea unei baze de date relaționale implică alegerea în cunoștință de cauză a schemelor de relație specifice dintr-o varietate de alternative diferite de scheme.

În practică, construcția unui model de bază de date logică, indiferent de modelul de date utilizat, se realizează ținând cont de două cerințe principale: eliminarea redundanței și maximizarea fiabilității datelor. Aceste cerințe provin din cerința de utilizare colectivă a datelor de către un grup de utilizatori. Mijloacele formale de descriere a datelor necesare pentru a verifica corectitudinea completării structurilor model nu sunt în mod clar suficiente. Selecția entităților, atributelor și înregistrarea relațiilor dintre entități depinde de semantica domeniului de studiu și este realizată de analistul de sistem în mod subiectiv, în conformitate cu înțelegerea personală a specificului sarcinii aplicației. Diferiți oameni definesc și prezintă datele în moduri diferite.

Prin urmare, orice cunoaștere a priori a constrângerilor de domeniu impuse relațiilor dintre date și valorile datelor, precum și cunoașterea proprietăților și relațiilor dintre acestea pot juca un rol în îndeplinirea cerințelor de mai sus. Formalizarea unor astfel de cunoștințe a priori despre proprietățile datelor din domeniul bazei de date este reflectată în concept dependenta functionala date, adică restricții privind posibilele relații între date care pot fi valorile curente ale schemei de relații.

Tuplurile de relație pot reprezenta instanțe entități de domeniu sau înregistrați relația lor. Dar chiar dacă aceste tupluri sunt definite corect, i.e. corespund schemei relației și sunt selectate din domenii valide, nu toate pot fi valoarea curentă a unei relații. De exemplu, vârsta unei persoane este rareori mai mare de 120 de ani sau același pilot nu poate efectua două zboruri diferite în același timp. Astfel de restricții asupra semanticii domeniului nu au practic niciun efect asupra alegerii uneia sau alteia scheme de relații. Ele reprezintă restricții asupra tipurilor de date.

Restricțiile de domeniu a priori privind relația dintre valorile atributelor individuale au cel mai mare impact asupra procesului de proiectare scheme de baze de date relaționale. Potrivirea valorii anumitor atribute ale diferitelor relații de baze de date, de ex. dependența valorilor lor una de alta determină indicatori de fiabilitateși corectitudinea datelor stocate atunci când sunt utilizate colectiv și într-o manieră consecventă.

Să ne amintim definiția unei funcții ca corespondență a unui set de argumente cu anumite valori din setul de definiții ale funcțiilor și metodele de specificare a funcțiilor: formulă, grafic și enumerare (tabel). Nu este greu de înțeles asta dependenta functionala(FZ) poate fi definit pe o clasă destul de largă de obiecte. Definiția unei funcții nu impune nicio restricție asupra setului de argumente și setului de valori al funcției, altele decât existența acestora și existența unei corespondențe între elementele lor. Deoarece Legea federală poate fi specificată într-un tabel, iar tabelul este o formă de reprezentare a relației, legătura dintre Legea federală și relație devine evidentă. Atitudinea poate fi stabilită de Legea federală. Această afirmație este prima (1) idee constructivă care formează baza teoriei proiectarea bazelor de date relaționale.

Definiție 1. Fie r (A 1, A 2, ..., A n) o schemă a relației R, iar X și Y submulțimi ale lui r. Se spune că X determină funcțional Y dacă valoarea fiecărui atribut relație de tuplu de la X nu corespunde mai mult de o valoare de atribut a aceluiași relație de tuplu de la Y. O astfel de lege federală este desemnată ca.

După cum se vede din definiție, dependenta functionala invariabil la modificările stărilor bazei de date în timp.

Exemplu. Conceptul de dependență funcțională Să demonstrăm conceptul de dependență funcțională folosind exemplul unui program de zbor de aeroport. FLIGHT_SCHEDULE (pilot, zbor, data_plecare, ora_plecare)

Se știe că:

• fiecare zbor are o anumită oră de plecare;
• Este posibil un singur zbor pentru fiecare pilot, data si ora plecarii;
• un anumit pilot este alocat unei anumite zile și unui zbor.

Prin urmare:

• „Departure_time” depinde funcțional de „Flight”: „Zbor” -> „Ora plecării_()” ;
• „Zborul” depinde funcțional de ("Pilot", "Data_plecare", "Ora_plecare"): („Pilot”, „Data_plecare”, „Ora_plecare”) -> „Zbor” ;
• „Pilot” depinde funcțional de ("Zbor", "Data_plecare"): ("Zbor", "Data_plecare") -> "Pilot".

O sarcină importantă în identificarea dependențe funcționale asupra atributelor unei relații, care prin definiție este o mulțime, este de a afla care dintre atribute acționează ca argument și care ca valoare a Legii federale. Cei mai potriviți candidați pentru argumentele FZ sunt cheile posibile, deoarece tuplurile reprezintă instanțe de entitate, care sunt identificate prin valorile atributelor cheii lor. Vorbind, dependența funcțională apare într-o relație când valorile unui tuplu pe un set de atribute determină în mod unic valorile unui tuplu pe alt set de atribute. Această definiție de lucru a unei legi federale nu conține acele elemente formale care ne permit să răspundem la întrebarea „Cum putem verifica prezența unei legi federale între atributele unei relații?” Formalismul necesar pentru aceasta ne oferă folosirea operații relaționale. Pentru a obține o definiție formală (strictă) a prezenței unei legi federale în legătură cu operații relaționale.

Definiția 2. Fie o relație R cu schema r, X și Y sunt două submulțimi ale lui R. FZ se menține pe R dacă setul are cel mult un tuplu pentru fiecare valoare a lui x. Un astfel de FD se mai numește și F-dependență.

După cum se poate observa din definiție, o verificare formală a prezenței unei legi fizice în raport cu R constă în selectarea (selectarea) unei relații pe baza valorilor cheie posibilăși stabilirea prezenței lipsei de ambiguitate între valoarea sa și valorile altor atribute.

Algoritmul care verifică dacă o relație R satisface Legea Federală constă în sortarea relației după valori cheie posibilăși stabilirea faptului de lipsă de ambiguitate între valoarea sa și valorile altor atribute. Acest algoritm este util, dar este de natură auxiliară.

Este clar că, dacă semantica subiectului bazei de date este complexă, atunci verificarea tuplurilor pentru apartenența la o lege federală este destul de dificilă. Este dificil de stabilit în general prezența celor mai multe dependenta functionala corespunzătoare naturii datelor luate în considerare. Folosind o astfel de metodă formală, este posibilă identificarea problemelor fizice care nu sunt reale și sunt de natură aleatorie. Un proiectant de baze de date relaționale ar trebui să fie conștient de această metodă de verificare a prezenței unei legi federale, dar atunci când proiectează o nouă bază de date, utilizarea acesteia este ineficientă. Poate fi util la reproiectarea unei baze de date existente.

Dependențe funcționale de fapt, ele sunt afirmații despre toate relațiile unui domeniu. Aceste relații pot fi valori ale schemei r și, în esență, nu pot fi obținute prin metode formale. Singura modalitate de a stabili dependențe funcționale căci schema relaţiei r este un studiu al semanticii atributelor entități de domeniu. Fiind afirmații despre entități de domeniu, nu pot fi dovedite. Această împrejurare dă naștere, în esență, unei reprezentări neunice a domeniului subiectului prin relațiile bazei de date relaționale.

Acesta este un loc bun pentru a formula ipoteze despre motivul pentru care există baze de date bune și proaste. În primul rând, datorită subiectivității abordărilor către analiza domeniului analiștii pot pierde legile federale importante. Acest lucru poate determina proiectantul să lucreze la multe modele evident inechivalente pentru a crea un design nesatisfăcător al bazei de date. În al doilea rând, reprezentarea neunică a unui domeniu prin relații duce la problema alegerii dintre multe alternative. În acest caz, schema bazei de date selectată dintr-un set de scheme echivalente este corectă, dar poate organiza datele pentru utilizator într-un mod neobișnuit. În al treilea rând, este posibil să se definească scheme de baze de date („tăiate”) astfel încât, ca urmare a operațiunilor cu Legea federală, atât Legea federală, cât și datele în sine să se piardă.

Metoda formelor normale

Profesor

Orez. 6.4. Atitudine inițială PROFESOR

Redundanță implicită se manifestă în aceleași salarii pentru toți profesorii și în aceleași sporuri salariale pentru aceeași vechime în muncă. Dacă salariul se schimbă de la 500 rub. până la 510 ruble, atunci această valoare trebuie modificată pentru toți profesorii. Dacă Sidorov este omis, baza de date va deveni inconsecventă. Acesta este un exemplu de anomalie de editare a relațiilor cu redundanță implicită.

Eliminarea redundanței constă în normalizarea relațiilor.

Metoda formei normale este o metodă clasică de proiectare a bazelor de date relaționale. Se bazează pe conceptul fundamental de dependență între atributele unei relații.

Atributul B dependente funcțional din atributul A, dacă fiecare valoare a lui A corespunde exact unei valori a lui B. Matematic, dependența funcțională a lui B de A se notează prin notația A ® B. Aceasta înseamnă că în toate tuplurile cu aceeași valoare a atributului a, ATRIBUT B VA AI ACEEAȘI VALOARE. Atributele A și B pot fi compuse - constând din două sau mai multe atribute. În raport cu Profesorul, dependențele funcționale sunt următoarele: Nume complet ® Departament, Nume complet ® Sarcina, Sarcina ® Salariu etc.

Interdependența funcțională. Dacă există o dependență funcțională de forma A ® B și B ® A, atunci între A și B există o corespondență unu-la-unu, sau interdependență funcțională. Din punct de vedere matematic, interdependența este notată ca A „B sau B” A.

Exemplu. Atributul N (seria și numărul pașaportului) este interdependent funcțional cu atributul numelui complet (nume, prenume și patronimic), dacă se presupune că este exclusă situația de coincidență deplină a numelor de familie, prenumelui și patronimicului a două persoane. .

Dependență funcțională parțială Este apelată dependența unui atribut non-cheie de o parte a unei chei compuse. În relația Profesor, cheia este compusă și constă din atributele Nume complet, Subiect și Grup. Toate atributele non-cheie sunt dependente funcțional de cheie cu diferite grade de dependență. De exemplu, atributul Poziție depinde funcțional de atributul Nume complet, care face parte din cheie, adică. depinde parțial de cheie.

Dependență funcțională completă - dependența unui atribut non-cheie de întreaga cheie compusă. De exemplu, atributul ViewZan depinde pe deplin funcțional de cheia compusă.

Atributul C depinde de atributul A în mod tranzitiv (există dependenta tranzitiva ), dacă pentru atributele A, B, C sunt îndeplinite condițiile A ® B și B ® C, dar nu există o relație inversă. În exemplu, atributele sunt conectate printr-o dependență tranzitivă:

Nume complet ® Funcția ® Salariu

În raport cu R, atributul B depinde foarte mult din atributul A dacă fiecare valoare a lui A corespunde unui set de valori ale lui B care nu sunt asociate cu alte atribute din R. Dependențe cu mai multe valori pot fi unu-la-mulți (1:M), multe-la-unu (M). :1) sau many-to-one to many” (M:M), notată respectiv: A Þ B, A Ü B și A Û B.

În exemplul luat în considerare, există o relație multivalorică M:M între atributele Nume complet Û Subiect (un profesor poate preda mai multe materii și o materie poate fi predată de mai mulți profesori).

Deoarece dependența dintre atribute este cauza anomaliilor, ei încearcă să împartă astfel de relații în mai multe relații. Ca rezultat, se formează un set de relații (tabele) înrudite cu conexiuni de forma 1:1, 1:M, M:1 și M:M. Relațiile dintre tabele reflectă dependențele dintre atributele diferitelor relații.

Atribute independente reciproc. Se spune că două sau mai multe atribute sunt independente reciproc dacă niciunul dintre atribute nu este dependent funcțional de celelalte atribute. Matematic, absența dependenței atributului A de atributul B se notează A Ø® B. Dacă au loc A Ø® B și B Ø® A, atunci independența reciprocă se notează A Ø = B.

Identificarea dependențelor dintre atribute. Identificarea dependențelor dintre atribute este necesară pentru a realiza proiectarea bazei de date folosind metoda formularelor normale.

Exemplu. Fie dată o relație R cu o schemă R(A1, A2, A3) de forma:

Se știe a priori că există dependențe funcționale:

A1®A2 și A2®A3.

Din analiză reiese clar că există și dependențe în relație:

A1®A3, A1A2®A3, A1A2A3®A1A2, A1A2®A2A3 etc.

In relatie nu exista dependenta functionala a atributului A1 de atributul A2 si de atributul A3, i.e.

A2 Ø® A1, A3 Ø® A1.

Absența dependenței lui A1 de A2 se explică prin faptul că aceeași valoare a atributului A2 (21) corespunde unor valori diferite ale atributului A1 (12 și 17).

Toate dependențele funcționale existente într-o relație sunt set complet de dependențe funcționale , pe care o notăm cu F + . Setul complet de dependențe funcționale poate fi dedus pe baza a 8 axiome de inferență: reflectivitate, completare, tranzitivitate, extensie, continuare, pseudotranzitivitate, unire și descompunere.

Pentru relația Profesor, pot fi derivate următoarele dependențe funcționale:

Nume complet ® Salariu

Nume complet ® Îndatorire

Nume complet ® Experiență

Nume complet ® Nadb

Numele complet ® Kaf

Experience ® Nadb

Salariu Duty®

Salariu ® Datorie

NUMELE COMPLET. Subiect Salariu de grup ®

Orez. 6.5. Dependențe între atribute.

Se presupune că un profesor dintr-o grupă poate conduce un tip de clasă (prelegeri sau lucrări de laborator). Nume complet – unic. Există o dependență Nume Complet ® Experiență, dar afirmația inversă nu este adevărată, deoarece Mai mulți profesori au aceeași experiență. În ceea ce privește alte dependențe, raționamentul este similar. Se stabilește o relație unu-la-unu între funcție și salariu.

Un profesor dintr-o grupă la diferite materii poate conduce diferite tipuri de ore. Definiția tipului de ocupație este asociată cu indicarea numelui complet, subiectului și grupului. Într-adevăr, Petrov M.I. în grupa 256 susține prelegeri și ține cursuri de laborator, dar ține prelegeri despre DBMS și lucrări de laborator despre grafică.

Dependențele dintre atributele Nume, Subiect și Grup nu sunt afișate, deoarece ele formează o cheie compusă și nu sunt luate în considerare în procesul de normalizare a relației (tabelului).

Forme normale. Procesul de proiectare a bazelor de date folosind forme normale este iterativ și constă în transferul secvenţial de relaţii de la prima formă normală la forme normale de ordin superior. Fiecare formă ulterioară limitează un anumit tip de dependență funcțională, elimină anomaliile corespunzătoare atunci când se efectuează operațiuni asupra relațiilor de baze de date și păstrează proprietățile formularelor anterioare.

Se distinge următoarea succesiune de forme normale:

° Prima formă normală (1NF);

° A doua formă normală (2NF);

° A treia formă normală (3NF);

° Forma normală a treia consolidată sau forma normală Boyce-Codd (BCNF);

° A patra formă normală (4NF);

° A cincea formă normală (5NF).

Prima formă normală O relație este în 1NF dacă toate atributele sale sunt simple (au o singură valoare). Relația originală este construită în așa fel încât să fie în 1NF.

Transformarea unei relații în următoarea formă normală se realizează folosind metoda „descompunere fără pierderi”, adică interogările (eșantionarea datelor în funcție de condiție) la relația inițială și la relațiile obținute ca urmare a descompunerii ar trebui să dea același rezultat.

Operația principală a metodei de descompunere este operația de proiecție.

Exemplu. Fie relația R(A,B,C,D,E,...) să aibă o dependență funcțională C ® D. Descompunerea relației R în două relații noi R1(A, B,C,E,...) iar R2(C,D) va elimina dependența funcțională a atributelor și va transfera relația R la următoarea formă normală. Relația R2 este o proiecție a relației R pe atributele C și D.

Relația originală Profesorul are o cheie compusă Nume complet, subiect, grupși este în 1NF. Atributele Experiență, Nadb, Caf, Duty, Salary depind funcțional de o parte a cheii compuse - atributul Numele complet. Această dependență parțială duce la redundanța explicită și implicită a datelor, ceea ce creează probleme cu editarea datelor. O parte din redundanță este eliminată prin conversia relației la 2NF.

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

Pentru a elimina dependența parțială, este necesar să folosiți operația de proiecție, extinzând relația inițială în mai multe relații, după cum urmează:

° Construiți o proiecție fără atribute care sunt parțial dependente de cheia primară;

° Construiți proiecții pe părți ale unei chei primare compuse și atribute care depind de aceste părți.

Să traducem relația Profesor în 2NF. Ca rezultat, obținem două relații R1 și R2.

R1

Orez. 6.6. Relații baze de date PROFESOR în 2 SF

În relația R1, cheia primară este compusă Nume complet, subiect, grup, în raport cu R2 cheia este NUMELE COMPLET. Ca urmare, redundanța evidentă a datelor despre profesori este eliminată. Există încă o duplicare implicită a datelor în R2.

Pentru îmbunătățiri suplimentare, vom converti relațiile în 3NF.

Dependențe funcționale

Dependența funcțională descrie relația dintre atribute și este unul dintre conceptele de bază ale normalizării. Să presupunem că schema relațională are atribute (A, B, C,..., Z) și întreaga bază poate fi reprezentată ca o relație universală R=(A, B, C,..., Z). Prin urmare, fiecare atribut din baza de date are un nume unic.

Dacă A și B sunt atribute ale unei relații R și fiecare valoare a lui A este asociată cu una și numai o singură valoare a lui B (și fiecare dintre atribute poate consta din unul sau mai multe atribute), atunci atributul B dependente funcțional din atributul A (ВАА).

Se numește o dependență funcțională care este valabilă în orice condiții banal. Dependențe netriviale definesc constrângerile de integritate asupra relațiilor.

Dependenta tranzitiva pentru atributele A, B și C ale unei relații înseamnă următoarele: dacă AàB și BàC, atunci C depinde tranzitiv de atributul A prin atributul B (cu condiția ca A să fie independent funcțional de B sau C).

Pentru a evita redundanța datelor, care poate duce la pierderea integrității, este necesar să se utilizeze un set minim suficient de dependențe.

Proiectarea bazei de date folosind normalizarea începe cu definirea dependențelor funcționale care sunt evidente din punct de vedere semantic, de exemplu. reducerea la prima formă normală.

Un tabel în prima formă normală trebuie să îndeplinească următoarele cerințe:

1) tabelul nu trebuie să aibă înregistrări duplicat;

2) tabelul nu trebuie să conțină grupuri duplicate de câmpuri;

3) fiecare câmp trebuie să fie indivizibil din punct de vedere semantic.

Un tabel în a doua formă normală trebuie să îndeplinească toate cerințele 1NF orice câmp non-cheie este identificat în mod unic printr-un set complet de câmpuri cheie, adică fiecare atribut al relației este complet sau parțial dependent de un alt atribut.

Dependența funcțională a AàB este deplin dependenţă funcţională dacă eliminarea oricărui atribut din A duce la pierderea acestei dependenţe. Dependența funcțională a AàB se numește parțial, dacă în A există un anumit atribut, atunci când este eliminat, această dependență rămâne.

Un tabel care este în a treia formă normală trebuie să îndeplinească toate cerințele din 2NF niciun câmp non-cheie nu este identificat de un alt câmp non-cheie, adică o relație care este în prima și a doua formă normală și nu are atribute care nu sunt; în cheia primară a atributelor , care ar fi într-o dependență funcțională tranzitivă de această cheie primară.

Boyce Code Normal Form (BCNF) se bazează pe dependențe funcționale care iau în considerare toate cheile potențiale ale unei relații, dar cu restricții mai stricte.

Determinant al dependenței funcționale este un atribut (sau un grup de atribute) de care un alt atribut depinde complet funcțional.

Pentru a verifica dacă o relație aparține BCNF, este necesar să găsiți toți determinanții ei și să vă asigurați că sunt potențiale chei.

Diferența dintre 3NF și BCNF este că dependența funcțională AàB este permisă într-o relație 3NF dacă atributul B este o cheie primară și atributul A nu este neapărat o cheie candidată. Pentru BNF, această dependență este permisă numai atunci când atributul A este o cheie candidată. Prin urmare, BCNF este o versiune mai strictă a 3NF, deoarece fiecare relație BCNF este 3NF, dar nu fiecare relație 3NF este BCNF.

O relație este în BCNF numai dacă fiecare dintre determinanții ei este o potențială cheie.

A patra formă normală (4NF) este o relație în BCNF care nu conține dependențe multivalorice non-triviale.

Dependență multivalorică reprezintă o relație între atributele unei relații (de exemplu, A, B și C), astfel încât fiecare valoare a lui A reprezintă un set de valori pentru B și un set de valori pentru C. Cu toate acestea, seturile de valori pentru că B și C sunt independente unul de celălalt.

O dependență cu mai multe valori poate fi definită în continuare ca fiind trivială sau netrivială. O dependență multivalorică AàB a unei relații R este definită ca fiind trivială dacă atributul B este un subset al atributului A sau . În schimb, o dependență cu mai multe valori este definită ca netrivială dacă nicio condiție nu este îndeplinită. O dependență multivalorică trivială nu impune nicio restricție asupra acestei relații, dar una netrivială o face.

Când partiționați o relație folosind operația de proiecție, metoda de descompunere utilizată este determinată cu precizie. Este necesar ca atunci când relațiile rezultate sunt reconectate, relația inițială să poată fi restabilită. Această descompunere se numește descompunerea conexiunii fără pierderi(sau o alăturare win-win sau non-additive) deoarece păstrează toate datele din relația originală și elimină crearea de rânduri fictive suplimentare.

A cincea formă normală (5NF), numită și formă normală conjunctivă proiectivă, înseamnă că o relație în această formă nu are dependențe de îmbinare. O relație R cu un submulțime de atribute A,B,...,Z satisface o dependență de îmbinare dacă fiecare valoare admisibilă a lui R este egală cu îmbinarea proiecțiilor sale pe submulțimile A,B,...,Z.

Atributul B dependente funcțional din atributul A dacă fiecare valoare a lui A corespunde exact unei valori a lui B.

Desemnare: A → B. Aceasta înseamnă că în toate tuplurile cu aceeași valoare pentru atributul A, și atributul B va avea aceeași valoare.

Dacă există o dependență funcțională de forma A→B și B→A, atunci între A și B există corespondență unu-la-unu, sau dependenta functionala. DESPRE

Desemnare: A↔B sau B↔A.

Dacă relația este în 1NF, atunci toate atributele non-cheie sunt dependente funcțional de cheie cu diferite grade de dependență.

Dependență parțială(dependență funcțională parțială) – dependența unui atribut non-cheie de o parte a unei chei compuse.

Dependență funcțională completă– dependența unui atribut non-cheie de întreaga cheie compusă.

Dependenta tranzitiva

Atributul C depinde de atributul A în mod tranzitiv(există dependenta tranzitiva), dacă sunt îndeplinite condițiile A→B și B→C pentru atributul A, B, C, nu există o relație inversă.

Dependență multiplă

În raport cu R, atributul B depinde foarte mult din atributul A, dacă fiecare valoare a lui A corespunde unui set de valori a lui B care nu sunt asociate cu alte atribute ale lui R.

Denumiri: A => B, A<=B, A<=>B.

Atribute independente reciproc

Sunt numite două sau mai multe atribute independent reciproc, dacă niciunul dintre aceste atribute nu este dependent funcțional de alte atribute.

Denumiri: A →B, A=B.

Forme normale:

Prima formă normală(1NF). O relație este în 1NF dacă toate atributele sale sunt simple (au o singură valoare).

A doua formă normală(2NF). O relație este în 2NF dacă este în 1NF și fiecare atribut non-cheie este dependent funcțional de cheia primară (compozit).

A treia formă normală(3NF). O relație este în 3NF dacă și numai dacă toate atributele relației sunt reciproc independente și complet dependente de cheia primară.

Forma normală Boyce-Codd(NFBC). O relație este în BCNF dacă este în 3NF și nu există dependențe cheie (atribute cheie compuse) pe atribute non-cheie.

A patra formă normală(4NF). O relație este în 4NF dacă și numai dacă există o dependență multivalorică A=>B, iar toate celelalte atribute ale relației depind funcțional de A.

A cincea formă normală(5NF). O relație este în 5NF dacă este în 4NF și satisface dependențele de conexiune în raport cu proiecțiile sale.

A șasea formă normală(6NF). O relație este în 6NF dacă și numai dacă nu poate fi descompusă în continuare fără pierderi.

Asigurarea consecvenței și integrității datelor din baza de date

Răspuns :

Integritate este o proprietate a unei baze de date, ceea ce înseamnă că conține informații complete, consecvente și care reflectă în mod adecvat despre domeniul subiectului.

Sunt:

Integritatea fizică– disponibilitatea accesului fizic la date și faptul că datele nu se pierd.

Integritate logică– absența erorilor logice în baza de date, care includ încălcarea structurii bazei de date sau a obiectelor acesteia, ștergerea sau modificarea conexiunilor stabilite între obiecte etc.

Menținerea integrității bazei de date include:

Verificarea integrității (monitorizare)

Restaurare în cazul detectării neconcordanțelor în baza de date.

Starea integrală este specificată folosind constrângeri de integritate(condiții pe care datele trebuie să le îndeplinească). Două tip de constrângeri de integritate:

Restricționarea valorilor atributelor relației. De exemplu: cerința de inadmisibilitate a valorilor NULL, inadmisibilitatea valorilor duplicate în atribute, controlul apartenenței valorilor atributelor la un interval dat.

Constrângeri structurale asupra tuplurilor relaționale. Definește cerințe integritatea entității și integritatea referențială.

Cerinţă integritatea entităţilor este asta orice tuplu al unei relații trebuie să fie diferit de orice alt tuplu al acelei relații, cu alte cuvinte, orice relație trebuie să aibă cheia principala.

Cerinţă integritate referenţială este că pentru fiecare valoare a cheii străine din tabelul părinte, trebuie să existe un rând în tabelul copil cu aceeași valoare a cheii primare.

Metoda entitate-relație

Răspuns :

Metoda entitate-relație(Metoda diagramei ER) este o metodă bazată pe utilizarea diagramelor numite, respectiv, diagrame de instanță ER și diagrame de tip ER.

Noțiuni de bază

Esență– acesta este un obiect, informații despre care sunt stocate în baza de date.

Atribut este o proprietate a unei entități.

Cheia de entitate este un atribut (set de atribute) folosit pentru a identifica o instanță a unei entități.

Conexiune intre entitati este dependența dintre atributele acestor entități.

Grafică, folosit pentru claritate și ușurință în proiectare:

DiagramăER-copii;

DiagramăER-tip sau ER-diagramă.

Pe baza analizei diagramelor ER se formează relațiile bazei de date proiectate. Aceasta ține cont de gradul de legătură dintre entități și clasa lor de apartenență.

Gradul de conectare– aceasta este o caracteristică a relației dintre entități (1:1, 1:M; M:1; M:M).

Clasa de membru entitățile pot fi: obligatoriuȘi opțional.

Necesar– dacă toate instanțele entității participă în mod necesar la relația în cauză.

Opțional– nu toate instanțele participă la conexiunea în cauză.

Etapele de proiectare a bazei de date

Răspuns :

eu. Design conceptual– colectarea, analiza și editarea cerințelor de date.

Ţintă: crearea unui model conceptual de date bazat pe înțelegerea de către utilizator a domeniului subiectului.

Proceduri:

Definirea entităților și documentarea acestora;

Determinarea relațiilor dintre entități și documentarea acestora;

Crearea unui model de domeniu;

Determinarea valorilor atributelor;

Definirea cheilor primare pentru entități.

II. Design logic– se creează o structură de date pe baza modelului conceptual.

Ţintă: transformarea unui model conceptual bazat pe modelul de date selectat într-un model logic, independent de caracteristicile SGBD utilizat ulterior pentru implementarea fizică a bazei de date.

Proceduri:

Selectarea unui model de date;

Definirea unui set de tabele și documentarea acestora;

Normalizarea tabelelor;

Determinați cerințele pentru menținerea integrității datelor și documentați-le.

III. Design fizic– determinarea caracteristicilor datelor și a metodelor de acces.

Scop: descrierea unei implementări specifice a bazei de date, plasarea în memoria externă a calculatorului.

Proceduri:

Proiectare de tabele de baze de date;

Proiectarea organizării fizice a bazei de date;

Dezvoltarea unei strategii de protectie a bazei de date.

Ciclul de viață al bazei de date

Răspuns :

Ciclul de viață al bazei de date este procesul de proiectare, implementare și întreținere a sistemelor de baze de date.

Etapele ciclului de viață al bazei de date:

Analiză– analiza domeniului și identificarea cerințelor pentru aceasta, evaluarea relevanței sistemului.

Proiecta– crearea unei structuri logice a bazei de date, descrierea funcțională a modelelor de programe și solicitările de informații.

Implementarea– dezvoltare software pentru baza de date, se efectuează testarea.

Exploatare Și acompaniament.

Etapele ciclului de viață al bazei de date:

Pre-planificare– planificarea bazei de date, implementarea planului strategic de dezvoltare a bazei de date (ce aplicații sunt utilizate, ce funcții îndeplinesc, ce fișiere sunt asociate cu fiecare dintre aceste aplicații și ce fișiere și aplicații noi sunt în procesul de dezvoltare).

Verificarea fezabilității– verificarea fezabilității tehnologice, operaționale și economice.

Definirea cerințelor– selectarea scopului bazei de date, identificarea cerințelor de informații pentru baza de date, cerințele pentru echipamente și software, determinarea cerințelor utilizatorilor.

Design conceptual– realizarea unei diagrame conceptuale.

Implementarea– aducerea modelului conceptual într-o bază de date funcțională.

Selectarea și achiziționarea DBMS-ului necesar.

Transformarea unui model conceptual într-un model logic și fizic.

Pe baza modelului de informații, se construiește o schemă de date pentru un anumit SGBD.

Se stabilește ce procese de aplicare trebuie implementate ca proceduri stocate.

Implementați restricții menite să asigure integritatea datelor.

Declanșatoare de proiectare.

Dezvoltați o strategie de indexare și grupare, estimați dimensiunile tabelelor, clustere și indici.

Determinați nivelurile de acces ale utilizatorilor, dezvoltați și implementați reguli de securitate.

Dezvoltați o topologie de rețea pentru baza de date.

Crearea unui dicționar de date.

Completarea bazei de date.

Creare de aplicatii software, control de management.

Instruirea utilizatorilor.

Evaluarea și îmbunătățirea schemei bazei de date.

Reguli pentru formarea relațiilor

Răspuns :

Reguli de formare relațiile se bazează pe luarea în considerare a următoarelor:

Gradul de legătură între entități (1:1, 1:M, M:1, M:M);

Clasa de apartenență a instanțelor de entitate (obligatorie și opțională).