O bază de date relațională este o colecție de relații care conține toate informațiile care ar trebui să fie stocate în baza de date. Cu toate acestea, utilizatorii pot percepe o astfel de bază de date ca o colecție de tabele.
1. Fiecare masă constă din același tip de linii și are un nume unic.
2. String-urile au un număr fix de câmpuri (coloane) și valori (mai multe câmpuri și grupuri duplicate nu sunt permise). Cu alte cuvinte, în fiecare poziție a mesei la intersecția unui rând și a unei coloane există întotdeauna o singură valoare sau nimic.
3. Rândurile tabelului diferă în mod necesar una de cealaltă cel puțin printr-o singură valoare, ceea ce face posibilă identificarea unică a oricărui rând dintr-un astfel de tabel.
4. Coloanele din tabel sunt denumiri atribuite în mod unic, iar în fiecare dintre acestea sunt plasate valori omogene de date (date, nume de familie, numere întregi sau sume de bani).
6. Atunci când efectuați operații pe o masă, rândurile și coloanele sale pot fi procesate în orice ordine, indiferent de conținutul lor de informație. Acest lucru este facilitat de prezența denumirilor tabelelor și a coloanelor acestora, precum și de posibilitatea de a evidenția oricare dintre liniile lor sau orice set de linii cu caracteristicile indicate (de exemplu, zboruri cu destinația "Paris" și timp de sosire de până la 12 ore).
Manipularea datelor relaționale
Propunând un model de date relațional, EF Codd a creat, de asemenea, un instrument pentru munca convenabilă cu relații - algebră relațională. Fiecare operație a acestei algebre utilizează unul sau mai multe tabele (relații) ca operanzi și produce un nou tabel ca rezultat, adică vă permite să "tăiați" sau să "lipiți" masa.
Fig. 3.3. Unele operații de algebră relațională
Limbile de manipulare a datelor au fost create, ceea ce face posibilă implementarea tuturor operațiunilor de algebră relațională și aproape orice combinație a acestora. Dintre acestea, cele mai frecvente sunt SQL (limba de interogare structurată a limbajului structurat) și QBE (Quere-By-Example - căutarea după model). Ambele se referă la limbi foarte înalte, prin care utilizatorul specifică ce date să obțină, fără a specifica procedura de obținere a acestora.
Folosind o singură interogare în oricare dintre aceste limbi, puteți să vă alăturați mai multor tabele într-o tabelă temporară și să decupați rândurile și coloanele necesare din ele (selecție și proiecție).
33. Modele de date. Obiectivele de proiectare a unei baze de date și a unui raport universal. Normalizarea, dependențele funcționale și multivalue.
Bazele de date individuale pot combina toate datele necesare pentru a rezolva una sau mai multe aplicații sau date referitoare la orice domeniu (de exemplu, finanțe, studenți, profesori, bucătării etc.). Primele sunt denumite de obicei baze de date de aplicații, în timp ce celelalte două sunt numite "baze de date obiect" (corelate cu obiectele organizației, și nu cu aplicațiile sale informatice). (Primul poate fi comparat cu bazele de aprovizionare cu materiale și tehnice sau de recreere, iar ultima - cu baze de legume și pantofi.)
Bazele de date Object sprijină toate aplicațiile curente și viitoare, deoarece un set de elemente de date include seturi de elemente de date ale bazelor de date aplicate. Ca rezultat, bazele de date obiect creează baza pentru procesarea interogărilor și aplicațiilor neformalizate, schimbătoare și necunoscute (aplicații pentru care cerințele de date nu pot fi determinate în prealabil). O astfel de flexibilitate și adaptabilitate face posibilă crearea unor sisteme de informații destul de stabile pe baza bazelor de date cu obiecte, adică Sisteme în care pot fi efectuate cele mai multe modificări fără a fi necesară suprascrierea aplicațiilor vechi.
Pe baza aceleiași concepții a bazei de date cu privire la aplicațiile actuale și previzibile, este posibil să se accelereze în mod semnificativ crearea unui sistem de informare foarte eficient, adică un sistem a cărui structură ține cont de cele mai frecvente modalități de accesare a datelor. Dar, pe măsură ce crește numărul de aplicații ale unor astfel de sisteme informatice, numărul de baze de date ale aplicațiilor crește rapid, nivelul de dublare a datelor crește brusc, iar costul întreținerii acestora crește.
Astfel, fiecare dintre abordările luate în considerare pentru proiectarea influențelor de proiectare are ca rezultat direcții diferite. Dorința de a atinge atât flexibilitate, cât și eficiență a condus la formarea unei metodologii de proiectare care utilizează atât abordările tematice, cât și abordările aplicate. În general, abordarea subiectului este utilizată pentru a construi structura inițială a informației și a aplicat-o pentru ao îmbunătăți pentru a îmbunătăți eficiența procesării datelor.
Scopul principal al designului bazei de date - este reducerea redundanței datelor stocate, și, în consecință, economisind utilizarea memoriei, reduce costul de mai multe copii redundante ale operațiunii de actualizare și eliminarea posibilității unui conflict din cauza depozitării în diferite informații locuri despre același obekte.Tak numit Un proiect "curat" DB ("Fiecare faptă într-un singur loc") poate fi creat utilizând metodologia de normalizare a relațiilor.
Această variantă a tabelului nu este o relație, deoarece majoritatea rândurilor sale nu sunt atomice. Doar valorile câmpurilor Dish, View, Recipe (deși este mare), porțiunile și data sunt atomice. În câmpurile rămase, tabelele sunt plural. Pentru ca aceste date să reprezinte o relație, este necesară reconstituirea tabelului. Cea mai simplă modalitate de a face acest lucru este printr-un proces simplu de inserare. Cu toate acestea, o astfel de conversie are ca rezultat o cantitate mare de date redundante.
Un tabel este o instanță a unei relații valide. Se numește relația universală a bazei de date proiectate. O relație universală include toate atributele de interes și poate conține toate datele care ar trebui să fie plasate în baza de date în viitor. Pentru bazele de date mici (care nu includ mai mult de 15 atribute), o relație universală poate fi utilizată ca punct de plecare în proiectarea bazei de date.
Normalizarea este partiționarea unui tabel în două sau mai multe, cu proprietăți mai bune când datele sunt incluse, modificate sau șterse. Scopul final al normalizării este obținerea unui proiect de bază de date în care fiecare fapt apare numai într-un singur loc, adică redundanța informațiilor este exclusă. Acest lucru nu se face cu atât mai mult cu scopul de a salva memoria, pentru a elimina posibila inconsistență a datelor stocate. Fiecare tabel într-o bază de date relațională satisface condiția potrivit căreia în poziția la intersecția fiecărui rând și coloană a tabelului este întotdeauna o singură valoare atomică, și niciodată nu poate fi setat astfel de valori. Orice tabel care satisface această condiție se numește normalizat. De fapt, tabelele neormalizate, adică tabelele care conțin grupuri duplicate nu sunt nici măcar permise în baza de date relațională. Un tabel normalizat este considerat automat un tabel în prima formă normală, abreviată la 1NF. Astfel, strict vorbind, "normalizat" și "localizat în 1NF" înseamnă același lucru. În practică, cu toate acestea, termenul „normalizat“ este adesea folosit într-un sens mai restrâns - a „complet normalizată“, ceea ce înseamnă că proiectul nu încalcă principiile normalizatsii.Teper, în plus față de 1NF este posibil să se identifice alte niveluri de normalizare -second formă normală (2NF), al treilea forma normală (3NF), etc. În esență, tabelul este în 2NF, dacă este în 1NF și îndeplinește, în plus, o condiție suplimentară, esența căreia va fi luată în considerare mai jos. Masa este în 3NF dacă este în 2NF și, în plus, satisface o altă condiție suplimentară etc.
Astfel, fiecare formă normală este într-un anumit sens mai limitată, dar și mai favorabilă decât cea anterioară. Acest lucru se datorează faptului că "forma normală" (N + 1) "nu posedă unele caracteristici neatractive caracteristice formei normale" N ". Sensul general al condiției suplimentare impuse formei normale (N + 1) cu privire la forma normală N constă în eliminarea acestor caracteristici neatractive.
Teoria normalizării se bazează pe prezența uneia sau a alteia dintre relațiile dintre câmpurile mesei. Sunt definite două tipuri de astfel de dependențe: funcționale și multivaluează.
Dependența funcțională. Câmpul B al tabelului depinde în mod funcțional de câmpul A al aceleiași tabele dacă și numai dacă, la un moment dat în timp, pentru fiecare dintre valorile diferite ale câmpului A, este necesar să existe numai una dintre valorile diferite ale câmpului B. Rețineți că este permisă aici că câmpurile A și B pot fi compuse. De exemplu, în tabelul Dish, câmpurile Dish and View sunt funcțional dependente de cheia BL, iar în tabelul Vendors în Fig. 4.3 Câmpul Tara este funcțional dependent de cheia compozită (Vendor, City). Cu toate acestea, ultima dependență nu este completă din punct de vedere funcțional, deoarece Țara depinde în mod funcțional de partea cheii - domeniul orașului. Câmpul B este în dependență completă funcțională de câmpul compus A dacă depinde funcțional de A și nu depinde în mod funcțional de nici un subset al câmpului A.