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ă, notată cu 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ță.

Parțial funcţional bani gheata dependență (lege federală parțială) Este apelată dependența unui atribut non-cheie de o parte a unei chei compuse. În relația luată în considerare, atributul Must depinde funcțional de atributul Nume complet, care face parte din cheie. Astfel, atributul Must este parțial dependent de cheia relației.

O variantă alternativă este dependență funcțională deplină pod atribut non-cheie din întreaga cheie compusă. În exemplul nostru, atributul ViewZan depinde pe deplin funcțional de cheia compusă.

Atributul C depinde de atributul A în mod tranzitiv (există tranzitiv dependență), dacă pentru atributele A, B, C sunt îndeplinite condițiile A->B și B->C, dar nu există o relație inversă. În raport cu Fig. 4.4 Atributele sunt conectate prin dependență tranzitivă:

Nume complet -> Sarcina -> Salariu

Poate exista o relație cu mai multe valori între atribute.

Î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 din R,

Dependențe cu mai multe valori pot fi „unu la mulți” (1:M), „mulți la unul” (M:1) sau „mulți la mulți” (M:M), notate corespunzător: A => B, A<=Би А<=>B.

De exemplu, lăsați un profesor să predea mai multe materii și fiecare materie poate fi predată de mai mulți profesori, apoi locația depinde de numele complet<=>Articol. Deci, din tabelul prezentat în fig. 4.4, este clar că profesorul Ivanov I.M. predă cursuri la două discipline, iar disciplina DBMS este predată de doi profesori: I.M.Ivanov. și Petrov M.I.

cometariu . În general, dependențele pot exista între două atribute ale unei relații: 1:1, 1:M, M:1 și M:M. Deoarece dependențele dintre atribute provoacă anomalii, ele încearcă să împartă relațiile cu dependențe de atribute în mai multe relații. Ca urmare, se formează un set de relații (tabele) înrudite cu conexiuni de forma 1:1, 1:M, M:1 și M:M (subsecțiunea 3.2). 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. În cazul a două atribute, absenţa dependenţei atributului A faţă de atributul B se poate nota astfel: A¬->B. Cazul când A¬->B și B¬->A poate fi notat cu A¬<->ÎN.

4.3.3 Axiomele lui Armstrong

Pentru a determina cheile și a înțelege consecințele logice ale dependențelor funcționale în cazul general, este necesar să se evalueze închiderea F + din F sau cel puțin știu pentru un dat F și dependență funcțională X Y, este cuprins X Y V F + . Pentru a face acest lucru, trebuie să aveți reguli de inferență care să specifice cum să deduceți alte dependențe din una sau mai multe dependențe.

Multe astfel de reguli sunt numite Axiomele lui Armstrong. Să presupunem că ni se oferă o schemă de relație cu multe atribute M, set universal atribute și multe dependențe funcționale F, conectând numai atribute aparținând M. Atunci avem următoarele reguli de inferență (axiome):

A1: (reflexivitate). Dacă Y ≤ X ≤ M, atunciX Y rezultă logic din F. Rețineți că această regulă dă dependențe banale, adică dependențe a căror latură dreaptă este conținută în partea stângă. Utilizarea sa nu depinde de F.

A2: (reaprovizionare). Dacă XY şi Z≤ M, Acea X U Z  Y U Z . Este important să ne amintim că această dependență XY fie aparține F, sau poate fi derivat din apartenenţă F dependențe folosind axiomele descrise.

A3: (tranzitivitatea). Dacă XY Și YZ, atunci XZ.

Este relativ ușor de demonstrat că axiomele lui Armstrong sunt de încredere, adică conduc doar la concluzii adevărate. Aceasta înseamnă că folosindu-le nu putem deduce din F orice dependență care nu aparține F + . Este mai dificil să se demonstreze completitatea lor, ceea ce înseamnă că aceste axiome pot fi folosite pentru a obține fiecare consecință validă a dependențelor. Aceasta înseamnă că pentru un anumit set de dependențe F regulile ne permit să deducem toate dependențele cărora le aparțin F + .

Din axiome Armstrong Mai sunt derivate 5 axiome (extensie, continuare, pseudotranzitivitate, unire și descompunere) folosite pentru a construi familia completă Lege federala.

Constrângerile de unicitate impuse de declarațiile cheii primare și candidate ale unei relații sunt un caz special al constrângerilor asociate conceptului. dependențe funcționale.

Pentru a explica conceptul de dependență funcțională, luați în considerare următorul exemplu.

Să ni se dea o relație care conține date despre rezultatele unei anumite sesiuni. Diagrama acestei relații arată astfel:

Sesiune ( Caietul de note nr. , Numele complet, Articol , Grad);

Atributele „Nr. caietul de note” și „Subiect” formează o cheie primară compusă (din moment ce două atribute sunt declarate ca cheie) a acestei relații. Într-adevăr, din aceste două atribute se pot determina fără ambiguitate valorile tuturor celorlalte atribute.

Cu toate acestea, pe lângă constrângerea de unicitate asociată cu această cheie, relația trebuie în mod necesar să fie supusă condiției ca un carnet de note să fie emis unui singur unei anumite persoane si deci in aceasta privinta tupluri cu acelasi numar Caietul de note trebuie să conțină aceleași valori pentru atributele „Nume”, „Prenumele” și „Patronimic”.

Dacă avem următorul fragment al unei baze de date specifice studenților instituție educațională după o anumită sesiune, apoi în tuplurile cu numărul de note 100, atributele „Nume”, „Prenumele” și „Patronimic” coincid, dar atributele „Subiect” și „Notă” nu coincid (ceea ce este de înțeles, pentru că în ele despre care vorbim despre diferite subiecte și performanță în ele). Aceasta înseamnă că atributele „Nume”, „Prenumele” și „Patronimic” dependente funcțional din atributul „Numărul caietului de note”, iar atributele „Subiect” și „Notă” sunt independente funcțional.

Prin urmare, dependenta functionala este o dependență clară tabelată în sistemele de gestionare a bazelor de date.

Acum să dăm o definiție strictă a dependenței funcționale.

Definiție: fie X, Y subscheme ale relațiilor de schemă S care definesc peste schema S Diagrama dependenței funcționale X > Y(citiți „Săgeata X Y”). Să definim inv restricții de dependență funcțională > Y> ca o afirmație că, în raport cu schema S, oricare două tupluri care coincid în proiecția către subschema X trebuie să coincidă și în proiecția către subschema Y.

Să scriem aceeași definiție în formă formală:

Inv > Y> r(S) = t 1 , t 2 ? r(t 1 [X] = t 2 [X] ? t 1 [Y] = t 2 [Y]), X, Y? S;

Interesant este că această definiție folosește conceptul de operație de proiecție unară, pe care l-am întâlnit mai devreme. Într-adevăr, cum altfel, dacă nu folosiți această operație, puteți arăta că două coloane ale unui tabel de relații, mai degrabă decât rânduri, sunt egale între ele? Prin urmare, am scris în ceea ce privește această operație că coincidența tuplurilor în proiecția pe un atribut sau mai multe atribute (subschema X) implică cu siguranță coincidența acelorași coloane de tuplu pe subschema Y dacă Y depinde funcțional de X .

Este interesant de observat că, în cazul unei dependențe funcționale a lui Y față de X, ei spun și că X definește funcțional Y sau ce Y dependente funcțional de la X. Într-o diagramă de dependență funcțională X > Y, subcircuitul X este numit partea stângă, iar subcircuitul Y este numit partea dreapta.

În practica de proiectare a bazelor de date, o diagramă de dependență funcțională este de obicei denumită diagramă de dependență funcțională pentru concizie.

Sfârșitul definiției.

În cazul special când partea dreaptă a dependenței funcționale, adică subschema Y, coincide cu întreaga schemă de relație, constrângerea dependenței funcționale devine o constrângere de unicitate pentru cheia primară sau candidată. Într-adevăr:

Inv<K > S> r(S) = ? t 1 , t 2 ? r(t 1 [K] = t 2 [K] > t 1 (S) = t 2 (S)), K ? S;

Doar că, în definirea unei dependențe funcționale, în loc de subcircuitul X, trebuie să luați denumirea cheie K și, în loc de partea dreaptă a dependenței funcționale, subcircuitul Y, trebuie să luați întreaga diagramă de relații S, adică într-adevăr, constrângerea de unicitate pentru cheile de relație este un caz special al constrângerii de dependență funcțională când partea dreaptă este egală cu schemele de dependență funcțională cu întreaga schemă relațională.

Iată exemple de imagini de dependență funcțională:

(număr carnet de calificare) > (Nume, Prenume, Patronimic);

(Nota nr., Subiect) > (Notă);

2. Regulile de inferență ale lui Armstrong

Dacă orice relație de bază satisface dependențe funcționale definite de vector, atunci altele pot fi obținute folosind diverse reguli speciale de inferență dependențe funcționale, pe care această relație de bază le va satisface cu siguranță.

Un bun exemplu de astfel de reguli speciale sunt regulile de inferență ale lui Armstrong.

Dar înainte de a începe să analizăm regulile de inferență ale lui Armstrong în sine, să introducem în considerare un nou simbol metalingvistic „+”, care se numește simbol al unei meta-afirmații despre deductibilitate. La formularea regulilor, acest simbol este scris între două expresii sintactice și indică faptul că formula din dreapta acestuia este derivată din formula din stânga acesteia.

Să formulăm acum regulile de inferență ale lui Armstrong în sine sub forma următoarei teoreme.

Teorema. Următoarele reguli, numite regulile de inferență ale lui Armstrong, sunt valabile.

Regula de inferență 1.+ X > X;

Regula de inferență 2. X > Y+ X ? Z > Y;

Regula de inferență 3. X > Y, Y? W > Z + X ? W > Z;

Aici X, Y, Z, W sunt subscheme arbitrare ale schemei de relații S. Simbolul unei meta-enunțuri despre deductibilitate separă liste de premise și liste de enunțuri (concluzii).

1. Prima regulă de inferență se numește „ reflexivitate” și sună după cum urmează: „regula este derivată: „X implică funcțional X.” Aceasta este cea mai simplă dintre regulile de inferență ale lui Armstrong. Iese literalmente din aer.

Este interesant de observat că se numește o dependență funcțională care are ambele părți din stânga și din dreapta reflectorizant. Conform regulii reflexivității, restricția dependenței reflexive este satisfăcută automat.

2. A doua regulă de inferență se numește „ reaprovizionare” și se citește astfel: „dacă X determină funcțional Y, atunci se derivă regula: „uniunea subcircuitelor X și Z implică funcțional Y”. Regula de reaprovizionare vă permite să extindeți partea stângă a constrângerii de dependență funcțională.

3. A treia regulă de inferență se numește „ pseudotranzitivitatea” și se citește după cum urmează: „dacă subcircuitul X implică funcțional subcircuitul Y și unirea subcircuitelor Y și W implică funcțional Z, atunci se deduce regula: „uniunea subcircuitelor X și W determină funcțional subcircuitul Z”.

Regula pseudotranzitivității generalizează regula tranzitivității corespunzătoare cazului special W: = 0. Să dăm o reprezentare formală a acestei reguli:

Trebuie remarcat faptul că premisele și concluziile prezentate mai devreme au fost prezentate în formă prescurtată folosind denumirile schemelor de dependență funcțională. În formă extinsă, acestea corespund următoarelor restricții de dependență funcțională.

Regula de inferență 1. inv X>r(S);

Regula de inferență 2. inv Y> r(S) ? inv Y>r(S);

Regula de inferență 3. inv Y> r(S) & inv Z> r(S) ? inv Z>r(S);

Să ducem la îndeplinire dovada aceste reguli de inferență.

1. Dovada regulii reflexivitate rezultă direct din definiția restricției dependenței funcționale la înlocuirea subcircuitului X în locul subcircuitului Y.

Într-adevăr, să luăm constrângerea dependenței funcționale:

Inv Y> r(S) și înlocuiți X în loc de Y în el, obținem:

Inv X> r(S), iar aceasta este regula reflexivității.

Regula reflexivității a fost dovedită.

2. Dovada regulii reaprovizionare Să ilustrăm cu diagrame de dependență funcțională.

Prima diagramă este diagrama premiselor:

pachet: X>Y

A doua diagramă:

concluzie: X ? Z>Y

Să fie tuplurile egale pe X? Z. Atunci ei sunt egali pe X. Conform premisei, vor fi egali pe Y.

Regula de reaprovizionare a fost dovedită.

3. Dovada regulii pseudotranzitivitatea Vom ilustra, de asemenea, cu diagrame, dintre care vor fi trei în acest caz particular.

Prima diagramă este prima premisă:

premisa 1: X > Y

premisa 2: Y ? W>Z

Și, în sfârșit, a treia diagramă este diagrama concluziei:

concluzie: X ? W>Z

Să fie tuplurile egale pe X? W. Atunci ei sunt egali atât pe X, cât și pe W. Conform premisei 1, vor fi egali pe Y. Prin urmare, conform premisei 2, vor fi egali pe Z.

Regula pseudotranzitivității a fost dovedită.

Toate regulile au fost dovedite.

3. Reguli de inferență derivate

Un alt exemplu de reguli cu ajutorul cărora pot fi derivate noi reguli de dependență funcțională, dacă este necesar, sunt așa-numitele reguli de inferență derivate.

Care sunt aceste reguli, cum se obțin?

Se știe că dacă din unele reguli care există deja, legal metode logice derivă altele, atunci aceste noi reguli, numite derivate, poate fi folosit alături de regulile originale.

Trebuie remarcat în mod special că aceste reguli foarte arbitrare sunt „derivate” tocmai din regulile de inferență Armstrong pe care le-am parcurs mai devreme.

Să formulăm regulile derivate pentru deducerea dependențelor funcționale sub forma următoarei teoreme.

Teorema.

Următoarele reguli sunt derivate din regulile de inferență ale lui Armstrong.

Regula de inferență 1.+X? Z > X;

Regula de inferență 2. X > Y, X > Z + X ? Y > Z;

Regula de inferență 3. X > Y ? Z + X > Y, X > Z;

Aici X, Y, Z, W, ca și în cazul precedent, sunt subscheme arbitrare ale schemei de relații S.

1. Prima regulă derivată se numește regula trivialitățiiși citește după cum urmează:

„Regula este derivată: „uniunea subcircuitelor X și Z implică funcțional X.”

Se numește o dependență funcțională cu partea stângă fiind un subset al părții drepte banal. Conform regulii trivialității, constrângerile de dependență triviale sunt satisfăcute automat.

În mod interesant, regula trivialității este o generalizare a regulii reflexivității și, ca și aceasta din urmă, ar putea fi derivată direct din definiția constrângerii dependenței funcționale. Faptul că această regulă este derivată nu este întâmplător și este asociat cu caracterul complet al sistemului de reguli al lui Armstrong. Vom vorbi mai multe despre caracterul complet al sistemului de reguli al lui Armstrong puțin mai târziu.

2. Se numește a doua regulă derivată regula aditivitățiiși se citește după cum urmează: „Dacă subcircuitul X definește funcțional subcircuitul Y și X definește simultan Z din punct de vedere funcțional, atunci din aceste reguli se derivă următoarea regulă: „X definește funcțional uniunea subcircuitelor Y și Z”.

3. Se numește a treia regulă derivată regula proiectivitatii sau regula" inversarea aditivității" Se citește după cum urmează: „Dacă subcircuitul X definește funcțional uniunea subcircuitelor Y și Z, atunci din această regulă se derivă regula: „X definește funcțional subcircuitul Y și în același timp X definește funcțional subcircuitul Z””, adică într-adevăr , aceasta este o regulă derivată este inversul regulii aditivității.

Este curios că regulile de aditivitate și proiectivitate așa cum sunt aplicate dependențelor funcționale cu părțile stângi identice ne permit să combinăm sau, dimpotrivă, să împărțim părțile din dreapta ale dependenței.

La construirea lanțurilor de inferență, după formularea tuturor premiselor, se aplică regula tranzitivității pentru a include o dependență funcțională cu partea dreaptă situată în concluzie.

Să ducem la îndeplinire dovada regulile de inferență arbitrare enumerate.

1. Dovada regulii banalitate.

Să o realizăm, ca toate dovezile ulterioare, pas cu pas:

1) avem: X > X (din regula lui Armstrong de reflexivitate a inferenței);

Regula trivialității a fost dovedită.

2. Să facem o dovadă pas cu pas a regulii aditivitatea:

1) avem: X > Y (aceasta este premisa 1);

2) avem: X > Z (aceasta este premisa 2);

3) avem: Y ? Z > Y? Z (din regula lui Armstrong de reflexivitate a inferenței);

4) avem: X? Z > Y? Z (obținut prin aplicarea regulii de pseudotranzitivitate a derivației lui Armstrong, iar apoi ca o consecință a primului și al treilea pas al demonstrației);

5) avem: X? X > Y ? Z (obținut prin aplicarea regulii de pseudotranzitivitate a lui Armstrong și apoi urmează din al doilea și al patrulea pas);

6) avem X > Y? Z (urmează de la pasul cinci).

Regula aditivității a fost dovedită.

3. Și, în final, vom construi o dovadă a regulii proiectivitate:

1) avem: X > Y? Z, X > Y ? Z (aceasta este o parcelă);

2) avem: Y > Y, Z > Z (derivat folosind regula Armstrong de reflexivitate a inferenței);

3) avem: Y ? z > y, Y ? z > Z (obținut din regula de completare a derivației lui Armstrong și un corolar din a doua etapă a demonstrației);

4) avem: X > Y, X > Z (aceasta se obține prin aplicarea regulii pseudotranzitivității derivației lui Armstrong, iar apoi ca o consecință a primului și al treilea pas al demonstrației).

Regula proiectivitatii a fost dovedita.

Toate regulile de inferență derivate au fost dovedite.

4. Completitudinea sistemului de reguli al lui Armstrong

Lăsa F(S) - un set dat de dependențe funcționale definite pe o diagramă de relații S.

Să notăm prin inv <F(S)> limitarea impusă de acest set de dependențe funcționale. Hai sa o scriem:

Inv <F(S)> r(S) = ?X > Y ? F(S) [inv Y> r(S)].

Deci, acest set de restricții impuse de dependențe funcționale este descifrat astfel: pentru orice regulă din sistemul de dependențe funcționale X > Y, aparținând setului de dependențe funcționale F(S), restricția de dependență funcțională inv este în vigoare Y> r(S), definite pe un set de relaţii r(S).

Lasă ceva atitudine r(S) satisface această constrângere.

Aplicarea regulilor de inferență ale lui Armstrong la dependențele funcționale definite pentru un set F(S), puteți obține noi dependențe funcționale, așa cum a fost deja spus și demonstrat de noi mai devreme. Și, ceea ce este semnificativ, limitările acestor dependențe funcționale sunt legate F(S) va satisface automat, așa cum se poate vedea din forma extinsă de scriere a regulilor de inferență ale lui Armstrong. Să vă reamintim forma generala aceste reguli de inferență extinse:

Regula de inferență 1. inv < X >X> r(S);

Regula de inferență 2. inv Y> r(S) ? inv ? Z>Y> r(S);

Regula de inferență 3. inv Y> r(S) & inv ? W>Z> r(S) ? inv ? W>Z>;

Revenind la raționamentul nostru, să completăm setul F(S) noi dependențe derivate din acesta folosind regulile lui Armstrong. Vom aplica această procedură de completare până când nu vom mai obține noi dependențe funcționale. În urma acestei construcții, obținem un nou set de dependențe funcționale, numit scurt circuit seturi F(S) și notat F+(S).

Într-adevăr, acest nume este destul de logic, deoarece noi înșine, printr-o construcție îndelungată, am „închis” multe dependențe funcționale existente de noi înșine, adăugând (de unde „+”) toate dependențele funcționale noi rezultate din cele existente.

Trebuie remarcat faptul că acest proces de construire a unei închideri este finit, deoarece schema relațională în sine, pe care se realizează toate aceste construcții, este finită.

Este de la sine înțeles că închiderea este un superset al setului care este închis (într-adevăr, este mai mare!) și nu se schimbă deloc atunci când este închis din nou.

Dacă notăm ceea ce tocmai s-a spus în formă formală, obținem:

F(S) ? F + (S), [F + (S)] + = F + (S);

În plus, din adevărul dovedit (adică legalitatea, legalitatea) regulilor de inferență ale lui Armstrong și definiția închiderii, rezultă că orice relație care satisface constrângerile unui set dat de dependențe funcționale va satisface constrângerea dependenței aparținând închiderii. .

X > Y ? F + (S) ? ?r(S) [inv <F(S)> r(S) ? inv Y> r(S)];

Deci, teorema de completitudine a lui Armstrong pentru sistemul de reguli de inferență afirmă că implicația externă poate fi înlocuită în mod complet legitim și justificat de echivalență.

(Nu vom lua în considerare demonstrarea acestei teoreme, deoarece procesul de demonstrare în sine nu este atât de important în cursul nostru specific.)

O bază de date relațională conține atât structurale, cât și informație semantică. Structura unei baze de date este determinată de numărul și tipul de relații pe care le conține și de relațiile unu-la-mulți care există între tuplurile acestor relații. Partea semantică descrie setul de dependențe funcționale care există între atributele acestor relații. Să definim dependența funcțională.

Definiție: Dacă sunt date două atribute X și Y ale unei relații, atunci se spune că Y depinde funcțional de X dacă în orice moment de timp fiecare valoare a lui X corespunde exact unei valori a lui Y. Dependența funcțională este notată cu X -> Y. Rețineți că X și Y pot reprezenta nu sunt doar atribute unice, ci și grupuri formate din mai multe atribute ale unei relații. Putem spune că dependențele funcționale sunt relații unu-la-mai multe care există în cadrul unei relații.

Relația de a doua formă normală (2NF). Determinarea dependenței funcționale complete și 2NF. Caracteristicile relațiilor din 2NF. Algoritm pentru reducerea la 2NF. Teorema lui Heath. Exemple.

Conceptdependență funcțională completă.

Definiție: atribut non-cheie complet dependente din punct de vedere funcțional dintr-o cheie compusă dacă este dependentă funcțional de întreaga cheie ca întreg, dar nu este dependentă funcțional de niciunul dintre atributele sale constitutive.

Definiție: dependență funcțională excesivă- o dependență care conține informații care pot fi obținute pe baza altor dependențe disponibile în baza de date.

2NF - a doua formă normală.

Definiția celei de-a doua forme normale: o relație este în 2NF, dacă este în 1NF și fiecare atribut non-cheie este complet dependent funcțional de cheie.

O schemă de bază de date care nu are dependențe funcționale redundante este considerată corectă. În caz contrar, trebuie să recurgeți la procedura de descompunere (descompunere) a setului de relații existent. În acest caz, mulțimea generată conține un număr mai mare de relații, care sunt proiecții ale relațiilor mulțimii inițiale. (Operația de proiecție este descrisă în secțiunea despre algebra relațională.) Procesul reversibil pas cu pas de înlocuire a unui set dat de relații cu o altă schemă, eliminând dependențele funcționale redundante, se numește normalizare.

Condiția de reversibilitate impune ca descompunerea să păstreze echivalența circuitelor la înlocuirea unui circuit cu altul, adică. în relațiile rezultate:

1) nu ar trebui să apară tuplurile care lipsesc anterior;

2) pe relații noua schema Setul original de dependențe funcționale trebuie să fie satisfăcut.

Teorema lui Heath

Să fie dată relația.

Dacă r satisface dependenţa funcţională, atunci este egală cu unirea proiecţiei sale şi

Relația a treia formă normală (3NF). Definiția dependenței tranzitive și 3NF pentru reducerea la 3NF. Definiție și algoritm pentru reducerea la BCNF. Caracteristicile relațiilor în 3NF și în NFBC. Exemple.

Dependenta functionala.

Un atribut B este dependent funcțional de un atribut A dacă o valoare a lui A determină exact o valoare a lui B.

Dacă pentru o relație dată toate atributele sale depind funcțional de un singur atribut, atunci acest atribut este potențială cheie simplă, dacă valorile sale în cadrul relației sunt unice. Una dintre cheile potențiale este desemnată ca cheie de relație.

Într-o relație, uneori este posibil să se identifice un set de mai multe atribute de care depind funcțional toate celelalte atribute. Dacă valorile sale sunt unice în agregat într-o relație, atunci acest agregat este relație supercheie ,

Dacă atributul B este dependent funcțional de o supercheie, dar nu există nicio dependență funcțională de niciun subset al supercheii, atunci dependență funcțională deplină Intră de la superkey.

Dacă toate atributele unei relații sunt dependente funcțional de o anumită supercheie, dar nu există nicio dependență funcțională de niciun subset al acelei superchei, atunci supercheia este potențială cheie .

Cheie compusă relațiile sunt selectate din potențiale chei.

Vă rugăm să rețineți că termenul dependenta functionala corespunde conceptului de funcție din matematică. Dacă non-cheie atributul depinde de întreaga cheie compusă și nu depinde de părțile ei, atunci se vorbește despre dependența funcțională completă a atributului de cheia compusă.

Dacă atributul A depinde de atributul B și B depinde de atributul C, dar nu există o dependență inversă, atunci se spune că atributul C depinde tranzitiv de A.

Tipuri de relații în bazele de date relaționale

Înregistrările sunt de fapt legate relații diferite DB, totuși, se obișnuiește să se vorbească despre legarea acestor relații. La legare, se stabilesc legături între tupluri ale unei relații și tupluri ale unei alte relații aparținând aceleiași baze de date.

În total, sunt acceptate patru tipuri de relații (legături): „unu la unu”, „mulți la unul”, „unu la mulți”, „mulți la mulți”.

Relație unu-la-mulți

Atitudine X legat de atitudine U„unu-la-mulți”, dacă fiecare tuplu de X se potrivește mai multe tupluri din U. În acest caz, este indicat ce câmp X din X câmp referințe la din U.

Pentru a stabili legături, DBMS are un mod de proiectare a legăturilor. Pentru ca SGBD să funcționeze corect cu o bază de date conectată, legăturile trebuie să îndeplinească condiții care să protejeze integritatea bazei de date. Constrângerile sunt stabilite asupra proprietăților câmpurilor care sunt legate. În acest caz, referitor la X(pe partea „una”) câmp de legătură X trebuie să aibă valori unice, iar câmpul la din U nu trebuie să conțină valori care nu sunt incluse în X. Camp X numit cheia principala , și câmpul la – cheie externă . În acest sens, atitudinea X, în care se află cheia primară este apelată atitudinea principală , și raportul U, care conține cheia externă, este apelată atitudine subordonată .

Exemplu de relații unu-la-mai multe:

relația „Comenzi” (subordonat) și relația „Produse” (principal);

relația „Comenzi” (subordonat) și relația „Clienți” (master).

Referitor la COMENZI chei externe pentru comunicarea cu relatia PRODUSE si CLIENTI: Comanda_produs și Comanda_client. In relatia PRODUSE si CLIENTI chei primare Cod_produs și Cod_client, la care se referă cheile externe.

Comunicare unu-la-unu

Dacă se datorează unul la mai mulți extern cheia y conține doar valori unice, atunci acesta este un tip de relație unu-la-unu - fiecare înregistrare în U corespunde unei intrări în Xși fiecare intrare în X se potrivește cu cel mult o intrare în U. În acest caz, cheia externă y nu este, ca X, cheia primară a relației, deoarece în domeniu X pot exista valori care nu sunt incluse la. Și în câmp la valori care nu sunt în domeniu X, nu poate fi. Într-o relație XȘi U Pot fi număr diferit tupluri.

Relație multi-la-unu

Definită ca o relație unu-la-mulți, dar relația XȘi Uîn definiţie îşi schimbă locurile.

Relație de la mulți la mulți

Stabilit între două relații XȘi Uh, dacă în fiecare dintre ele există cheia principala legătura cu a treia relație CU,în care se află două chei străine relaţii unu-la-mai multe între XȘi CUși unu-la-mulți între CUȘi U. Atitudine CU numit liant . Într-o relație CU trebuie să atribuiți o cheie compusă (nu una simplă). Această cheie compusă trebuie să includă cheile străine ale celor două relații (sau Mai mult, dacă astfel de perechi ca XȘi Uh, legat prin CU, sunt câteva).

Două cerințe de bază (constrângeri) sunt fixate pentru a menține integritatea. Constrângeri de integritate după entitateȘi prin linkuri trebuie să fie suportat de un SGBD relațional.

Primul integritatea entităţilor . obiect domeniul subiectului(sau entități din modelul de domeniu) în bazele de date relaționale corespund tuplurilor de relații. Mai exact, cerința este ca orice tuplu din orice relație să se distingă de orice alt tuplu din aceeași relație. Cu alte cuvinte: orice relație trebuie să aibă o cheie. Această cerință este satisfăcută automat dacă proprietățile de bază ale relațiilor nu sunt încălcate în sistem.

A se conforma integritate pe entitate este suficient pentru a garanta că nu există tupluri cu aceeași valoare cheie în orice relație.

Al doilea o cerință se numește cerință integritate referenţială si este ceva mai complex. Evident, entitățile model de domeniu complexe sunt reprezentate într-o bază de date relațională ca mai multe tupluri de relații multiple legate.

Cerință sau cerință de integritate referențială cheie externă, este că pentru fiecare valoare cheie străină a unei relații subordonate, trebuie să existe un tuplu cu această valoare în relația principală cheia principala, sau valoarea cheii externe trebuie să fie nedefinită (nu indică nimic). Pentru exemplul de relații dintre înregistrările relațiilor de angajați și departament, aceasta înseamnă că dacă pentru un angajat din relația de angajați numărul de departament este specificat în câmpul departament, atunci acest departament trebuie să existe în relația de departamente.

La actualizarea sclavului relații (inserarea de noi tupluri sau modificarea valorii unei chei străine în tupluri existente), este suficient ca SGBD să se asigure că valori incorecte cheie străină (acele valori care nu sunt în câmpul cheii primare al relației principale). La ștergerea unui tuplu dintr-o relație principală, dacă este referită printr-o relație subordonată, SGBD are mai multe dintre următoarele tehnici, fiecare dintre acestea menținând integritatea referențială.

1) Este interzisă ștergerea unui tuplu la care se face referire (adică trebuie să ștergeți mai întâi tuplurile de referință sau să modificați valorile cheii străine ale acestora în consecință).

2) Când un tuplu referit este șters, valoarea cheii externe din toate tuplurile de referință devine automat nedefinită.

3) Se creează o ștergere în cascadă, care constă în faptul că atunci când un tuplu este șters din relația principală, toate tuplurile de referință sunt șterse automat din relația subordonată.

În SGBD-urile relaționale avansate, puteți alege o metodă de menținere a integrității referențiale pentru fiecare situație individuală. Pentru a lua o decizie, este necesar să se analizeze cerințele unui domeniu specific.

Proiectarea bazelor de date relaționale. Normalizare.

Conceptul de normalizare

Se va lua în considerare abordarea clasică, în care întregul proces de proiectare se realizează în termeni model relațional date prin metoda aproximărilor succesive la un set satisfăcător de scheme de relaţii.

Punctul de plecare este reprezentarea domeniului subiectului sub forma uneia sau mai multor relații, iar la fiecare pas de proiectare schema inițială de relații este transformată într-o anumită mulțime care are proprietăți mai bune.

Procesul de proiectare este un proces normalizarea tiparelor de relație , aducând relații cu "forme normale" Mai mult, fiecare formă normală ulterioară are proprietăți mai bune decât cea anterioară. În realitate, procesul de normalizare se realizează prin descompunerea relațiilor, urmând anumite reguli, care vor fi discutate mai jos. Descompunerea este cea care aduce relația cu următoarea formă normală.

Fiecare formă normală corespunde unora set specific constrângeri, iar o relație este într-o formă normală dacă își satisface setul inerent de constrângeri.

Cerința primei forme normale este generală cerință de bază model clasic de date relaționale. O limitare semnificativă a primei forme normale este că atributele unei relații sunt atomice, adică atributele nu sunt relații în sine și nu sunt divizate în continuare (ca atomii).

În teoria bazelor de date relaționale sunt cunoscute teoretic 7 forme normale, aici se evidențiază următoarea succesiune de 6 forme normale:

· prima formă normală (1NF);

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

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

forma normală Boyce-Codd (BCNF);

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

· a cincea formă normală sau formă normală proiecție-joncțiune (5NF sau PJ/NF).

Semnificație practică au primele trei forme normale.

Proprietățile de bază ale formelor normale

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

Cele mai importante forme normale de relații în practică se bazează pe conceptul de dependență funcțională, fundamental în teoria bazelor de date relaționale. Acest concept a fost discutat în prelegerea nr. 4. Să clarificăm definițiile extinzându-le la seturi de câmpuri.

Informațiile au avut întotdeauna un interes dinamic adecvat. Dezvoltarea de limbaje de programare, baze de date relaționale și tehnologia Informatiei a schimbat radical conţinutul şi structura interesului. S-a dezvoltat un anumit sistem strict de idei. Formalizarea, matematica exactă și relațiile binare au devenit un domeniu de cunoaștere și experiență de succes și în dezvoltare rapidă.

Lumea naturală a informației nu și-a schimbat dinamica și, dezvoltând conținutul și structura, sa ridicat înălțimi noi. Are forme netede și nu există nimic în natură "dreptunghiular". Informația, desigur, se pretează la formalizare, dar are dinamică nu doar datele și algoritmii de procesare a acestora, ci și sarcinile în sine și domeniile lor de aplicare.

Informații > formalizare >> date

Informația se transformă într-o structură informațională, o bază de date...) așa cum o vede programatorul. Nu există nicio garanție că această viziune este corectă, dar dacă programul său rezolvă problema, atunci datele au fost prezentate cât mai adecvat posibil.

Întrebarea cât de corect au fost formalizate informațiile este o chestiune de timp. Până acum, conceptul de dinamică (autoadaptare la condițiile de utilizare în schimbare) este doar un vis de programare.

Dependenta functionala: " solutie corecta= program (programator)” și condiția: „respectarea continuă a sarcinii” sunt valabile în majoritatea cazurilor, dar numai împreună. Dar nu este la fel baza matematica, care este folosit la crearea bazelor de date.

O afirmație directă: dinamica naturală și continuă a informației și a algoritmilor de rezolvare a problemelor sunt întotdeauna reale. Și acestea sunt relații binare + matematică strictă + construcții formale precise, + ...

și baze de date

Modul în care sunt stocate datele a fost mult timp lipsit de importanță: fie el RAM sau dispozitiv extern. Componenta hardware a atins un ritm constant de dezvoltare și oferă calitate bună in cantitati mari.

Principalele opțiuni de stocare, care diferă în opțiunile de utilizare a datelor:

• dosare;
• Bază de date.

Primul este lăsat în seama programatorului (ce să scrie, în ce format, cum se face, cum se citește...), al doilea aduce imediat nevoia de a înțelege o simplă dependență funcțională.

Viteza de preluare și scriere a informațiilor atunci când lucrați cu fișiere (de o dimensiune rezonabilă, nu astronomică) este foarte rapidă, dar viteza operațiunilor similare cu o bază de date poate fi uneori considerabil lentă.

Experiență personală și înțelepciune colectivă

În istorie au existat încercări de a trece dincolo limitele atinse, dar tot domina baze de date relaționale date. S-a acumulat un mare potențial teoretic, practica aplicației este extinsă, iar dezvoltatorii sunt înalt calificați.

Dezvoltatorii de baze de date impun programatorului conceptul de dependență funcțională, chiar dacă acesta nu intenționează să folosească bogata experiență matematică și logică în construirea de structuri complexe de informații, procese de lucru cu acestea, regăsirea și înregistrarea informațiilor.

Chiar și în caz simplu programatorul depinde de logica bazei de date cu care alege să lucreze. Nu există nicio dorință de a urma canoanele, puteți folosi fișiere, veți obține o mulțime de fișiere și multe experienta personala. Se va petrece mult timp personal și problema va fi rezolvată pe o perioadă lungă de timp.

Indiferent cât de complexe ar părea exemplele de dependență funcțională, nu este deloc necesar să ne scufundăm în profunzimea sensului și a logicii. Ar trebui adesea recunoscut că mintea colectivă a fost capabilă să creeze baze de date excelente, diferite dimensiuni si functionalitate:

• Oracol solid;
• exigent MS SQL Server;
• popularul MySQL.

Baze de date relaționale excelente, cu o bună reputație, ușor de utilizat, rapid în mâinile potrivite. Utilizarea lor economisește timp și elimină nevoia de a scrie mai multe foi de cod auxiliar.

Caracteristici de programare și date

De multă vreme, programarea are boala de a rescrie constant ceva, de a repeta munca predecesorilor pentru a adapta cumva ceva la informațiile modificate, la o sarcină sau la condițiile de utilizare a acesteia.

Problema dependenței funcționale este că, la fel ca în programare, o greșeală poate fi foarte costisitoare. Sarcina este rareori simplă. De obicei, în timpul formalizării informațiilor, se obține o reprezentare complexă a datelor. De obicei, elementele lor sunt izolate, apoi sunt legate prin chei în anumite relații, apoi algoritmii pentru formarea tabelelor, interogările și algoritmii pentru preluarea informațiilor sunt ajustați.

De multe ori mare importanță are o legătură cu codificarea. Nu toate bazele de date oferă soluții mobile, poți întâlni adesea cum un MySQL perfect configurat, pe care se află o duzină de baze de date, funcționând perfect și stabil, obligă dezvoltatorul să facă a unsprezecea bază de date similară cu cele care există deja.

Sunt momente când hosting partajat limitează funcționalitatea PHP și acest lucru își lasă amprenta asupra accesului de programare la baza de date.

ÎN programare modernă responsabilitatea pentru algoritmul programului este echivalentă cu responsabilitatea pentru crearea modelului de date. Totul ar trebui să funcționeze, dar nu ar trebui să te scufunzi întotdeauna în jungla teoriei.

DB: dependență simplă de date

În primul rând, conceptul de bază de date este atât o bază de date, atât un sistem de management (de exemplu, MySQL), cât și o anumită structură de informații care reflectă datele sarcinilor și conexiunile dintre acestea. unu Baza de date MySQL„deține” orice număr de structuri de informații în diverse domenii de aplicare. unu Baza de date Oracle, poate oferi procesele informaţionale companie mare sau banca, monitorizați problemele de securitate și integritatea datelor cel mai înalt nivel, situat pe multe computere situate la distanțe diferite, în diferite medii de instrumente.

Este general acceptat că relația este fundamentală în modelul relațional. O relație elementară este un set de coloane cu nume și rânduri cu valori. Clasic "dreptunghi"(tabel) - simplu și realizare eficientă progres. Complexitatea și dependența funcțională a unei baze de date începe atunci când "dreptunghiuri"începe să intre în relații unul cu celălalt.

Numele fiecărei coloane din fiecare tabel trebuie să fie unic în contextul sarcinii. Aceleași date nu pot fi în două tabele. Cunoașteți semnificația conceptelor:

• „definiți entitățile”;
• „elimină redundanța”;
• „reglați relații”;
• „pentru a asigura autenticitatea.”

O necesitate elementară pentru utilizarea unei baze de date și construirea unui model de date pentru o anumită sarcină.

Încălcarea oricăruia dintre aceste concepte înseamnă eficiență scăzută a algoritmului, eșantionare lentă a datelor, pierdere de date și alte probleme.

Dependența funcțională: logică și sens

Nu trebuie să citiți despre tupluri de relații, despre faptul că o funcție este o corespondență între un set de argumente și un set de valori, iar o funcție nu este doar o formulă sau un grafic, ci poate fi specificată printr-o set de valori - un tabel.

Nu este necesar, dar nu strică să te gândești la o dependență funcțională ca:

F(x1, x2, …, xN) = (y1, y2, …, yN).

Dar este imperativ să înțelegeți că intrarea este un tabel, iar rezultatul este, de asemenea, un tabel sau o soluție specifică. De obicei, o dependență funcțională stabilește logica relațiilor dintre tabele, interogări, privilegii, declanșatoare, proceduri stocate și alte aspecte (componente) ale bazei de date.

De obicei, tabelele sunt convertite unul în celălalt, apoi în rezultat. Dar utilizarea dependenței funcționale nu se limitează doar la această idee. Programatorul însuși își construiește propria reprezentare a imaginii de date, structura informatiei... nu contează cum îl numești, dar dacă funcționează pe o anumită bază de date, trebuie construit după logica ei, ținând cont de sensul său și de dialectul limbajului folosit, de obicei SQL.

Se poate argumenta că proprietățile dependențelor funcționale ale unei baze de date sunt accesibile prin dialectul utilizat Limbajul SQL. Dar este mult mai important de înțeles: după toate vicisitudinile dezvoltării, nu au supraviețuit multe baze de date, dar există și multe dialecte ale acestei limbi și caracteristici ale structurilor interne în bazele de date.

Despre vechiul Excel bun

Când computerul s-a arătat cu Partea pozitivă, lumea a fost imediat împărțită în programatori și utilizatori. De regulă, primii folosesc:

• PHP, Perl, JavaScript, C++, Delphi.
• MySQL, Oracle, Visual FoxPro.

• Cuvânt.
• Excela.

Unii utilizatori reușesc să creeze baze de date în Word pe cont propriu (fără ajutorul programatorilor) - aceasta este o adevărată prostie.

Experiența utilizatorului în Excel pentru a crea baze de date este practică și interesantă. Important este că Excel în sine este funcțional, colorat și practic.

Ideea tabulară a definit conceptul de dependență funcțională într-un mod clar și accesibil, dar fiecare bază de date are nuanțe. Fiecare are propria „față”, dar toată lumea, de la Excel la Oracle, manipulează pătrate simple, adică tabele.

Dacă considerați că Excel nu este deloc o bază de date, dar mulți utilizatori (nu programatori) îl folosesc așa, iar Oracle este cea mai complexă și puternică realizare a unei echipe mari de dezvoltatori în domeniul bazelor de date, atunci devine firesc să admit că o bază de date este o reprezentare specifică programatorului (echipă) despre sarcina specifica si solutia ei.

Ce este dependența funcțională, cu ce, unde, de ce... este evident doar pentru autor sau pentru o echipă a acestora.

Despre unde se îndreaptă relațiile relaționale

Progresul științific și tehnologic este o procedură foarte dureroasă și uneori crudă. Dacă vă amintiți cum au început bazele de date, ce este *.dbf, cum a fost marcată cibernetica, atunci s-au îndrăgostit de informatică și au început să creeze obstacole în mișcare tehnologie avansata la nivel de țară, devine clar de ce bazele de date relaționale sunt atât de rezistente și bune. De ce stil clasic programarea încă trăiește și astăzi, iar programarea orientată pe obiecte este pur și simplu apreciată, dar nu a domnit încă.

Oricât de frumos dependența funcțională în contextul matematicii:

Aceasta nu este o relație binară, sau mai degrabă, este un motiv pentru a regândi ideea de a stabili relații între mai multe atribute, explorând „unu-la-mulți”, „mulți-la-unu”, „mulți-la-unu”. -multe” sau „multe în general și unele în special” relații.

Puteți veni cu o mare varietate de opțiuni de relație. Este matematică cu logică și este riguroasă! Informația este propria ei matematică, specială. În ea, se poate vorbi despre formalitate doar cu un minus foarte mare.

Puteți oficializa munca departamentului de resurse umane, puteți scrie un sistem de control automat pentru producția de ulei sau producția de lapte, pâine, puteți face o selecție în baza de date imensa Google, Yandex sau Rambler, dar rezultatul va fi întotdeauna static și același în fiecare moment!

Dacă dependența funcțională = logică strictă și matematică = baza bazelor de date, atunci despre ce fel de dinamică putem vorbi? Orice soluție va fi formală, orice model de date formal + algoritm strict = soluție exactă și lipsită de ambiguitate. Informațiile și domeniul de aplicare al oricărui program sunt mereu în schimbare.

Probă motor de căutare pe aceeași expresie de căutare nu poate fi aceeași într-o oră sau două și, cu siguranță, într-o zi - dacă expresie de căutare se referă la domeniul informației în care numărul de site-uri, resurse, cunoștințe și alte elemente este în continuă schimbare.

Chiar dacă programul este pur matematic și baza sa de date nici măcar nu se gândește la dinamică, totul este întotdeauna linii. Și sfoara are o lungime. Și nu poate fi nesfârșit. Nu poate fi nici măcar o variabilă, doar o variabilă condiționată. Printre altele, orice bază de date, cu aparatul ei birocratic matematic și binar, impune o mulțime de formalități, iar asta înseamnă rapiditate + calitate de prelevare și prelucrare a informațiilor.

Și dacă anumite câmpuri din baza de date sunt numere, în special cele reale, atunci se vor adăuga următoarele restricții: capacitatea cifrelor numerice, prezența literei „e”, formatul de reprezentare - pe scurt, peste tot și întotdeauna avem importante Proprietăți de dependență funcțională a bazei de date:șiruri de lungime condiționat variabilă, cu multe formalități binare și restricții matematice stricte.

Dacă schimbați tonul și ascultați pulsul dinamicii, atunci totul poate fi pictat în obiecte. La o primă aproximare, numele unei coloane dintr-un tabel este un obiect, o listă de nume este tot un obiect, pe scurt, un tabel este un obiect antet și în el numele coloanelor din antet. Și poate să nu existe deloc pălărie...

Dar pot exista rânduri în tabel. Și șirul poate avea valori. Și de ce ar trebui să fie întotdeauna același număr? Deplin masă pătrată - acesta este un lucru special și, în cele mai multe cazuri, unul privat.

Dacă reprezentați toate constructele din baza de date ca obiecte, atunci poate că nu va trebui să construiți relații binare stricte. Acest lucru are o semnificație naturală și reală, fie și numai pentru că, conform logicii obiective (cu siguranță nu matematice), reflectă dinamica informației și mediul în care există probleme.