Baze de date relaționale. Conceptul unei baze de date relaționale. Baze de date relaționale

De regulă, orice aplicație web poate fi împărțită în 2 părți principale: front-end, unde sunt afișate toate informațiile site-ului, și back-end, unde aceste informații format şi aşezat. În acest articol vom vorbi despre ce sunt bazele de date relaționale și despre cum să le proiectăm.

Baza de date stochează înregistrările într-un mod special organizat, astfel încât informațiile să poată fi găsite și recuperate cu ușurință. Orice bază de date constă din unul sau mai multe tabele. Foaie de calcul este format din rânduri și coloane. Toate liniile au coloane identice, iar fiecare coloană conține date. În general, pentru o mai bună înțelegere, să definim că tabelele din baza de date sunt foarte asemănătoare cu cele pe care le-ați văzut în Excel.

Datele tabelare pot fi inserate, restaurate, actualizate și șterse. O abreviere specială CRUD (Create-Read-Update-Delete) a fost creată pentru pachetul acestor operațiuni.

Bazele de date relaționale sunt baze de date în care toate informațiile sunt stocate în tabele legate între ele relatie speciala. Aceste relații ne permit să extragem și să unim date dintr-unul sau mai multe tabele folosind o singură interogare.

Dar toate acestea sunt doar cuvinte. Pentru a înțelege cu adevărat ce sunt bazele de date relaționale, trebuie să exersați mai mult. Să începem și să vedem cu ce date trebuie să lucrăm.

Pasul 1: Pregătirea datelor

Pentru ca noi să avem cu ce să lucrăm, am tastat interogarea „#base de date” pe Twitter și am creat un tabel cu 10 înregistrări:

Tabelul 1

Numele complet	nume de utilizator	următorul_nume de utilizator
Boris Hadjur	_DreamLead	Scootmedia, MetiersInternet
Gunnar Svalander	GunnarSvalander	klout, linlow
GE Software	GEsoftware	DayJobDoc, byosko
Adrian Burch	adrianburch	Cindy Crawford, Arjantim
Andy Ryder	AndyRyder5	Michael Dell, Yahoo
Andy Ryder	AndyRyder5	Michael Dell, Yahoo
Brett Englebert	Brett_Englebert
Brett Englebert	Brett_Englebert	RealSkipBayless, stephenasmith
Nimbus Data Systems	NimbusData	dellock6, rohitkilam
SSWUG.ORG	SSWUGorg	drsql, steam_games

În primul rând, să ne uităm la coloane:

Acestea sunt date reale. Dacă doriți, le puteți găsi și actualiza.

Amenda. Acum toate datele noastre sunt într-un singur loc. Ne permite acest lucru să le căutăm cu ușurință? Nu chiar. Acest tabel departe de a fi ideal. În primul rând, avem intrări duplicat în unele coloane: de exemplu, în x „nume utilizator” și „following_username”. De asemenea, coloana „following_username” încalcă regulile modelelor relaționale, deoarece există mai mult de 1 valoare în celule (inregistrările sunt separate prin virgule).

În plus, întâlnim dubluri în rânduri.

Datele duplicate sunt într-adevăr o problemă pentru că... ele îngreunează procesul CRUD. De exemplu, atunci când căutați un anumit tabel, va dura procesarea duplicatelor timp suplimentar. În plus, dacă utilizatorul actualizează tweet-ul, atunci va trebui să suprascriem toate duplicatele.

Soluția la această problemă este împărțirea tabelului 1 în mai multe tabele. Să trecem la rezolvarea primei probleme și anume eliminarea dublelor din coloane.

Pasul 2. Scapa de duplicatele din coloane

După cum sa menționat mai sus, coloanele „nume de utilizator” și „following_username” conțin date duplicat. Au apărut pentru că am vrut să arăt relația dintre tweet-uri și utilizatori. Să ne îmbunătățim structura bazei de date prin separare tabelul existentîn două: într-una vom stoca informații, iar în cealaltă - relații dintre înregistrări.

Deoarece @Brett_Englebert urmărește @RealSkipBayless, vom afișa acest lucru în tabelul „următorul” după cum urmează: vom plasa numele @Brett_Englebert în coloana „from_user” și @RealSkipBayless în „to_user”. Să vedem cum va arăta tabelul „următorul” după împărțire Tabelele 1:

Tabelul 2. în continuare

de la_utilizator	către_utilizator
_DreamLead	Scootmedia
_DreamLead	MetiersInternet
GunnarSvalander	klout
GunnarSvalander	zgomotos
GEsoftware	DayJobDoc
GEsoftware	byosko
adrianburch	CindyCrawford
adrianburch	Arjantim
AndyRyder	Michael Dell
AndyRyder	Yahoo
Brett_Englebert	RealSkipBayless
Brett_Englebert	stephenasmith
NimbusData	dellock6
NimbusData	rohitkilam
SSWUGorg	drsql
SSWUGorg	jocuri_aburi

Tabelul 3. utilizatori

Numele complet	nume de utilizator	text	creat_la
Boris Hadjur	_DreamLead	Ce părere aveți despre #e-mailurile #campaniilor #traficul în #SUA? Este o piață bună în zilele noastre? ai #baze de date?	Mar, 12 februarie 2013 08:43:09 +0000
Gunnar Svalander	GunnarSvalander	Bill Gates vorbește despre baze de date, software gratuit pe Reddit http://t.co/ShX4hZlA #billgates #databases	Mar, 12 februarie 2013 07:31:06 +0000
GE Software	GEsoftware	RT @KirkDBorne: Citiri în #Baze de date: listă excelentă de lectură, multe categorii: http://t.co/S6RBUNxq via @rxin Fascinating.	Mar, 12 februarie 2013 07:30:24 +0000
Adrian Burch	adrianburch	RT @tisakovich: @NimbusData la @Barclays Big Data conferință de astăzi la San Francisco, despre #virtualizare, #baze de date și #memorie flash.	Mar, 12 februarie 2013 06:58:22 +0000
Andy Ryder	AndyRyder5	http://t.co/D3KOJIvF articol despre Madden 2013 folosind AI pentru a prezice super bowl #baze de date #bus311	Mar, 12 februarie 2013 05:29:41 +0000
Andy Ryder	AndyRyder5	http://t.co/rBhBXjma un articol despre setările de confidențialitate și facebook #datebase #bus311	Mar, 12 februarie 2013 05:24:17 +0000
Brett Englebert	Brett_Englebert	#BUS311 NCFPD de la Universitatea din Minnesota creează #baze de date pentru a preveni „frauda alimentară”. http://t.co/0LsAbKqJ	Mar, 12 februarie 2013 01:49:19 +0000
Brett Englebert	Brett_Englebert	Companiile #BUS311 ar putea să-și protejeze bazele de #date de producție, dar ce despre fișierele lor de rezervă? http://t.co/okJjV3Bm	Mar, 12 februarie 2013 01:31:52 +0000
Nimbus Data Systems	NimbusData	@NimbusData CEO @tisakovich @BarclaysOnline Conferința Big Data din San Francisco astăzi, vorbind despre #virtualizare, #baze de date și #memorie flash	Luni, 11 februarie 2013 23:15:05 +0000
SSWUG.ORG	SSWUGorg	Nu uitați să vă înscrieți la expoziția noastră GRATUITĂ vineri: #Baze de date, #BI și #Sharepoint: Ce trebuie să știți! http://t.co/Ijrqrz29	Luni, 11 februarie 2013 22:15:37 +0000

Deja mai bine. Acum, în tabelul „utilizatori” (Tabelul 3) stocăm doar informații despre tweet-uri, iar în tabelul următor (Tabelul 2) stocăm dependențele utilizatorilor.

Fondatorul teoriei baze de date relaționale date, Edgar Codd ar apela acest proces (eliminarea repetițiilor din coloanele tabelului) aducând baza de date la prima formă normală.

Pasul 3: Eliminarea duplicatelor din rânduri

Acum vom trece la remedierea altor probleme, și anume, scăparea de duplicate din rândurile tabelului „utilizatori”. Deoarece @AndyRyder5 și @Brett_Englebert au postat fiecare mai multe tweet-uri, numele lor sunt în tabelul „utilizatori” ( Tabelul 3) sunt duplicate în coloana full_name. Această problemă poate fi rezolvată și prin partiționarea tabelului „utilizatori”.

Deoarece textul tweet și ora la care a fost creat sunt date unice, le vom plasa în același tabel. De asemenea, trebuie să indicăm relația dintre tweet-uri și utilizatori. Pentru asta am creat rubrică specială nume de utilizator.

Tabelul 4. tweet-uri

nume de utilizator	text	creat_la
_DreamLead	Ce părere aveți despre #e-mailurile #campaniilor #traficul în #SUA? Este o piață bună în zilele noastre? ai #baze de date?	Mar, 12 februarie 2013 08:43:09 +0000
GunnarSvalander	Bill Gates vorbește despre baze de date, software gratuit pe Reddit http://t.co/ShX4hZlA #billgates #databases	Mar, 12 februarie 2013 07:31:06 +0000
GEsoftware	RT @KirkDBorne: Citiri în #Baze de date: listă excelentă de lectură, multe categorii: http://t.co/S6RBUNxq via @rxin Fascinating.	Mar, 12 februarie 2013 07:30:24 +0000
adrianburch	RT @tisakovich: @NimbusData la conferința @Barclays Big Data din San Francisco astăzi, vorbind despre #virtualizare, #baze de date și #memorie flash.	Mar, 12 februarie 2013 06:58:22 +0000
AndyRyder5	http://t.co/D3KOJIvF articol despre Madden 2013 folosind AI pentru a prezice super bowl #baze de date #bus311	Mar, 12 februarie 2013 05:29:41 +0000
AndyRyder5	http://t.co/rBhBXjma un articol despre setările de confidențialitate și facebook #datebase #bus311	Mar, 12 februarie 2013 05:24:17 +0000
Brett_Englebert	#BUS311 NCFPD de la Universitatea din Minnesota creează #baze de date pentru a preveni „frauda alimentară”. http://t.co/0LsAbKqJ	Mar, 12 februarie 2013 01:49:19 +0000
Brett_Englebert	Companiile #BUS311 ar putea să-și protejeze bazele de date de producție, dar cum rămâne cu fișierele lor de rezervă? http://t.co/okJjV3Bm	Mar, 12 februarie 2013 01:31:52 +0000
NimbusData	@NimbusData CEO @tisakovich @BarclaysOnline Conferința Big Data din San Francisco astăzi, vorbind despre #virtualizare, #baze de date și #memorie flash	Luni, 11 februarie 2013 23:15:05 +0000
SSWUGorg	Nu uitați să vă înscrieți la expoziția noastră GRATUITĂ vineri: #Baze de date, #BI și #Sharepoint: Ce trebuie să știți! http://t.co/Ijrqrz29	Luni, 11 februarie 2013 22:15:37 +0000

Tabelul 5. utilizatori

Numele complet	nume de utilizator
Boris Hadjur	_DreamLead
Gunnar Svalander	GunnarSvalander
GE Software	GEsoftware
Adrian Burch	adrianburch
Andy Ryder	AndyRyder5
Brett Englebert	Brett_Englebert
Nimbus Data Systems	NimbusData
SSWUG.ORG	SSWUGorg

După partiționare în tabelul utilizatori ( Tabelul 5) avem linii unice (nerepetate).

Acest proces Eliminarea duplicatelor din șiruri se numește turnare la a doua formă normală.

Pasul 4. Uniți mesele pe baza cheilor

Deci, ca urmare a acțiunilor noastre, Tabelul 1 a fost împărțit în 3 părți: următoarele (Tabelul 2), tweet-uri (Tabelul 4), utilizatorii (Tabelul 5). Toate duplicatele au fost eliminate. Pentru a putea extrage cu ușurință date din această structură în viitor, trebuie să conectăm tabele independente cu relații speciale care ne vor oferi informații despre ce utilizator deține ce tweet și cine urmărește pe cine.

Pentru a crea relații între înregistrări, trebuie să introducem un identificator unic numit cheie primară.

În general vorbind, în tabelele 4 și 5 am făcut deja acest lucru. În tabelul „utilizatori”, cheia primară este coloana „nume utilizator”, deoarece numele de utilizator trebuie să fie o valoare unică și nu poate fi repetat. În tabelul „tweets” pe care îl folosim cheia dată pentru a indica o conexiune între un utilizator și un tweet. Coloana „nume de utilizator” din tabelul „tweets” se numește cheie străină.

Dacă ați lucrat vreodată cu baze de date, atunci este posibil să aveți o întrebare: putem folosi coloana „nume de utilizator” ca cheie primară?

Pe de o parte, acest lucru poate simplifica procesul de căutare, deoarece nu folosim niciun ID numeric. Pe de altă parte, ce se întâmplă dacă utilizatorul dorește să-și schimbe datele de conectare? Acest lucru poate duce la un număr imens probleme. Pentru a nu intra în situație similară, este mai bine să folosiți ID-uri numerice. Totul depinde de sistemul dvs. Dacă oferiți utilizatorilor posibilitatea de a schimba datele de conectare, atunci este mai bine să utilizați un câmp ID numeric cu incrementare automată ca cheie primară. În caz contrar, coloana „nume de utilizator” este destul de potrivită pentru acest rol. O să o las așa cum este.

Să ne uităm la tabelul de tweet-uri (Tabelul 4). Cheia primară trebuie să fie unică pentru fiecare rând. Ce coloană din acest tabel putem selecta pentru acest rol? Coloana „created_at” nu va funcționa, deoarece practic 2 utilizator diferit poate publica o intrare în același timp. Coloana „text” este aceeași: doi utilizatori diferiți pot crea un tweet cu textul „Hello World”. Coloana „nume de utilizator” din acest tabel este o cheie străină pentru a indica relația dintre utilizator și tweet. Deci, din moment ce totul opțiuni posibile nu sunt potrivite pentru noi, atunci cea mai bună soluție ar fi adăugarea unei coloane ID, care va fi cheia primară pentru acest tabel.

Tabelul 6. tweet-uri cu coloana id

ID	nume de utilizator	text	creat_la
1	_DreamLead	Ce părere aveți despre #e-mailurile #campaniilor #traficul în #SUA? Este o piață bună în zilele noastre? ai #baze de date?	Mar, 12 februarie 2013 08:43:09 +0000
2	GunnarSvalander	Bill Gates vorbește despre baze de date, software gratuit pe Reddit http://t.co/ShX4hZlA #billgates #databases	Mar, 12 februarie 2013 07:31:06 +0000
3	GEsoftware	RT @KirkDBorne: Citiri în #Baze de date: listă excelentă de lectură, multe categorii: http://t.co/S6RBUNxq via @rxin Fascinating.	Mar, 12 februarie 2013 07:30:24 +0000
4	adrianburch	RT @tisakovich: @NimbusData la conferința @Barclays Big Data din San Francisco astăzi, vorbind despre #virtualizare, #baze de date și #memorie flash.	Mar, 12 februarie 2013 06:58:22 +0000
5	AndyRyder5	http://t.co/D3KOJIvF articol despre Madden 2013 folosind AI pentru a prezice super bowl #baze de date #bus311	Mar, 12 februarie 2013 05:29:41 +0000
6	AndyRyder5	http://t.co/rBhBXjma un articol despre setările de confidențialitate și facebook #datebase #bus311	Mar, 12 februarie 2013 05:24:17 +0000
7	Brett_Englebert	#BUS311 NCFPD de la Universitatea din Minnesota creează #baze de date pentru a preveni „frauda alimentară”. http://t.co/0LsAbKqJ	Mar, 12 februarie 2013 01:49:19 +0000
8	Brett_Englebert	Companiile #BUS311 ar putea să-și protejeze bazele de date de producție, dar cum rămâne cu fișierele lor de rezervă? http://t.co/okJjV3Bm	Mar, 12 februarie 2013 01:31:52 +0000
9	NimbusData	@NimbusData CEO @tisakovich @BarclaysOnline Conferința Big Data din San Francisco astăzi, vorbind despre #virtualizare, #baze de date și #memorie flash	Luni, 11 februarie 2013 23:15:05 +0000
10	SSWUGorg	Nu uitați să vă înscrieți la expoziția noastră GRATUITĂ vineri: #Baze de date, #BI și #Sharepoint: Ce trebuie să știți! http://t.co/Ijrqrz29	Luni, 11 februarie 2013 22:15:37 +0000

Putem face același lucru cu următorul tabel, deoarece nicio coloană existentă nu poate servi drept cheie primară. Coloanele „from_user” și „to_user” sunt chei străine și indică relația dintre abonamentele utilizatorilor.

Deci, în acest moment, am făcut deja o mulțime de lucruri. Am scăpat de informațiile duplicate în coloane și rânduri și am selectat coloane potrivite pentru ca tabelele noastre să acționeze ca chei primare și externe pentru a indica dependențele dintre date. Acest proces se numește normalizare și este conceput pentru a vă reduce tabelele model relațional. Datorită normalizării, putem implementa operațiunile CRUD într-un mod mai simplu.

Mai jos puteți vedea o diagramă a tabelelor noastre și a relațiilor dintre ele:

Sisteme de management al bazelor de date

Acum că avem o bază de date relațională, cum o putem implementa? Pentru a face acest lucru, putem folosi sisteme de gestionare a bazelor de date (DBMS). Există un întreg set programe similare, atât cu plată, cât și gratuit. Printre cele plătite se numără Oracle Database, IBM DB2 și Microsoft SQL Server. Gratuit: MySQL, SQLite și PostgreSQL.

Cel mai adesea, diverse companii folosesc MySQL. Twitter în acest sens nu face excepție.

SQLite este folosit mai des atunci când se dezvoltă aplicații pentru iOS și Android, unde sunt stocate diferite tipuri de stocare. informații confidențiale. Browser Google Chrome folosește SQLite pentru a stoca istoricul de navigare, cookie-uri, imagini...

PostgreSQL este folosit mai rar. Pentru ea există extensie utilă PostGIS, care face acest SGBD convenabil pentru stocarea datelor de geolocalizare. De exemplu, serviciul OpenStreetMap folosește PostgreSQL.

Limbajul de interogare structurat (SQL)

După ce ați ales SGBD-ul potrivit pentru dvs. și l-ați instalat, următorul pas ar fi crearea tabelelor și gestionarea datelor. Pentru a face acest lucru, putem folosi un limbaj special numit SQL.

Crearea unei baze de date de dezvoltare:

CREAREA BAZEI DE DATE dezvoltarea;

Crearea tabelului Users:

CREATE TABLE utilizatori (nume_complet VARCHAR(100), nume de utilizator VARCHAR(100));

La crearea câmpurilor, trebuie să specificăm tipul de informații care trebuie stocate și dimensiunea acesteia. Coloanele „full_name” și „username” vor fi de tip VARCHAR, care este conceput pentru a stoca șiruri de caractere. Dimensiunea 100 de caractere. Puteți găsi o listă de toate tipurile.

Adăugarea unei intrări:

INSERT INTO utilizatori (nume_complet, nume de utilizator) VALORI ("Boris Hadjur", "_DreamLead");

Preluarea tuturor intrărilor de la utilizatorul _DreamLead:

Actualizare post:

Ștergerea unei intrări:

SQL este foarte asemănător cu limbajul uman (engleza). Fiecare SGBD SQL are o serie de caracteristici și diferențe proprii, dar, în general, toate soiurile de SQL sunt similare între ele.

Concluzie

În această lecție, am analizat procesul de creare a unei baze de date relaționale, am luat un set de date și le-am distribuit în tabele conform modelului relațional. De asemenea, am aruncat o privire rapidă asupra SGBD-urilor existente și a limbajului SQL.

Nivelul 1: Nivel modele externe- acesta este cel mai mult nivel superior unde fiecare model are propria sa vedere asupra datelor. Acest strat definește punctul de vedere al bazei de date a aplicațiilor individuale.

Nivel conceptual: Legătura centrală de control, unde baza de date este prezentată cel mai mult vedere generală, care combină datele utilizate de toate aplicațiile. De fapt, nivelul conceptual reflectă un model generalizat al disciplinei.

Stratul fizic(Baza de date): Acestea sunt datele în sine aflate în fișiere sau în structuri de pagină situate pe medii de stocare externe.

Modele de date

Evidențiați urmatoarele modele date:

1. Infologic

2. Data logică

3. Fizic

Procesul de proiectare a bazei de date începe cu proiectarea unui model de informații. Un model de date infologice este o descriere informală generalizată a bazei de date create, realizată folosind limbajul natural, formule matematice, tabele, grafice și alte instrumente care sunt ușor de înțeles pentru toți oamenii care lucrează la proiectarea bazelor de date.

Tuplu de domeniu

Modelul informațional reflectă lumea reală într-un concept ușor de înțeles de om, complet independent de mediul de stocare a datelor. Prin urmare, Modelul Infologic nu ar trebui să se schimbe până la unele modificări lumea reală nu va necesita modificări în afara definiției pentru ca acest model să continue să reprezinte domeniul.

Există multe abordări pentru construirea acestui model: modele grafice, rețele semantice, esență – conexiune și altele.

Model datalogic

Modelul infologic trebuie să fie afișat într-un model datalogic care să fie înțeles de SGBD. Un model datalogic este o descriere formală a unui model de informații în limbajul DBMS.

Model ierarhic

Acest model este o colecție de elemente înrudite care formează o structură ierarhică. Conceptele de bază ale ierarhiei includ nivelul, nodul și relația.

nivelul de comunicare

Un nod este o colecție de atribute de date care descriu un obiect. Fiecare nod este conectat la un nod pentru mai mult de nivel înaltși cu orice număr de noduri nivel inferior. Excepția este nodul de cel mai înalt nivel. Numărul de arbori din baza de date este determinat de numărul de rădăcini ale copacilor. Pentru fiecare înregistrare de bază de date există singura cale de la intrarea rădăcină. Un exemplu simplu este sistemul de nume de domeniu de Internet\adresă. Pe primul nivel (rădăcina copacului) se află planeta noastră, pe al doilea Țara, pe al treilea Regiunea, pe al patrulea - zona populata, strada, casa, apartamentul. Un reprezentant tipic este un DBMS de la IBM - IMS.

Toate copiile de acest tip descendenții cu o instanță comună de tipul strămoșului se numesc gemeni. Definit pentru baza de date comanda completa ocolire. De sus în jos și de la dreapta la stânga.

Modelul fizic

Un model fizic este construit pe baza modelului datalogic. Organizarea fizică datele au un impact major asupra performanței bazei de date. Dezvoltatorii DBMS încearcă să creeze cele mai productive modele de date fizice, oferind utilizatorilor unul sau altul instrument pentru a personaliza modelul pentru o anumită bază de date.

Exemplu: În special pentru o bază de date relațională, aceasta ia deja în considerare:

1. Aspecte fizice ale stocării tabelelor în fișiere specifice.

2. Crearea de indici care optimizează viteza operațiunilor de date folosind aplicația.

3. Efectuarea diferitelor acțiuni asupra datelor asupra anumitor evenimente definite de utilizatori folosind declanșatoare și proceduri stocate.

Modele infologice X

Modele fizice

Pentru toate nivelurile și pentru orice metodă de prezentare domeniul subiectului, constă codificarea conceptelor de relații dintre concepte. Un pas cheie în dezvoltarea oricărui sistem informatic este de a efectua o analiză a sistemului:

Formalizarea disciplinei și reprezentarea sistemului ca ansamblu de componente.

Compoziția ca bază a analizei sistemului poate fi funcțională (construirea unei ierarhii).

Cu toate acestea, în majoritatea sistemelor, când vine vorba de baze de date, tipurile de date sunt un element mai static decât modul în care sunt procesate. Prin urmare, metode de analiză a sistemului, cum ar fi diagrama fluxului de date, au primit o dezvoltare intensivă. Dezvoltarea bazelor de date relaționale. A stimulat dezvoltarea metodologiilor de dezvoltare a datelor, în special diagramele ER ER. Modelul de date relațional folosește în mod direct conceptul de relație ca o mapare. Ea este cea mai apropiată de model conceptual prezentarea datelor. Și adesea se află în centrul acesteia.

Spre deosebire de teoreticianul modelului de graf, în modelul relațional, conexiunile dintre relații sunt implementate într-un mod neexplicit, pentru care se folosesc chei de relație. De exemplu, relațiile tip ierarhic implementat prin mecanismul cheilor primare și străine, când faptul de atribute trebuie să fie prezent în relația de subordonare.

Un astfel de atribut al relațiilor din relația principală va fi numit o cheie primară, iar într-o relație subordonată una secundară.

Progresul în dezvoltarea limbajelor de programare legate în primul rând de tastarea datelor și apariția limbajelor orientate pe obiecte a făcut posibilă abordarea analizei sisteme complexe din punctul de vedere al reprezentărilor ierarhice, adică folosind clase de obiecte cu proprietăți de polimorfism, moștenire, încapsulare.

RELAȚIA ESTE O TABELĂ.

Editarea tabelelor, înregistrărilor...

Ștergerea a ceea ce ați creat și

Editare.

Modelul bazei de date relaționale

Modelele de date relaționale au câștigat în prezent cea mai mare popularitate tocmai pentru această reprezentare a datelor.

Modelul relațional poate fi gândit ca o metodă specială de reprezentare a datelor care conține propriile date (sub formă de tabele) și modalități de lucru și manipulare a acestora (sub formă de relații). Modelul relațional presupune trei elemente conceptuale: Structură, Integritate și Procesarea datelor. Aceste elemente au propriile lor concepte obligatorii care trebuie explicate pentru prezentare ulterioară.

Tabelul este considerat ca un depozit de date direct. În mod tradițional, în sistemele relaționale se numește un tabel atitudine. Se numește un rând de tabel caravană, și coloana atribut. În acest caz, atributele au nume unice(în cadrul relației).

Numărul de tupluri dintr-un tabel este numit număr cardinal. Numărul de atribute grad. Se stabilește un identificator unic pentru o relație, adică unul sau mai multe atribute ale căror valori nu sunt aceleași în același timp - identificatorul se numește cheie primară.Domeniu acesta este setul de valori omogene valide pentru un anumit atribut. Astfel, un domeniu poate fi considerat ca un set numit de date, iar componentele acestui set sunt unități indivizibile din punct de vedere logic (de exemplu, o listă de nume de angajați ai unei instituții poate acționa ca un domeniu, dar nu toate numele pot fi prezente în tabel).

SUMĂ Kireeva 25.50 Motyleva 17.05 … …. …

Atitudine

atribute

Câmpurile KOD, NAME, SUMM sunt atribute de tabel conținute în antet.

Perechile KOD 5216, NAME Kireeva, SUMM 25.50 sunt elemente ale corpului relației.

În bazele de date relaționale, spre deosebire de alte modele, utilizatorul specifică ce date este nevoie pentru el și nu cum să o facă. Din acest motiv, procesul de mutare și navigare a unei baze de date în sisteme relaționale este automat, iar această sarcină este efectuată într-un SGBD. optimizator. Treaba lui este să profite la maximum într-un mod eficient preluarea datelor din baza de date la cerere. Astfel, optimizatorul trebuie să fie cel puțin capabil să determine din ce tabele sunt selectate datele, câte informații sunt în aceste tabele și care este ordinea fizică a înregistrărilor din tabele și cum sunt grupate.

În plus, o bază de date relațională îndeplinește și funcții de director. Directorul stochează o descriere a tuturor obiectelor care alcătuiesc baza de date: tabele, indecși, declanșatoare etc. Este evident că este vital pentru funcționare corectăîntregul sistem, o componentă precum optimizatorul. Optimizatorul folosește informațiile stocate în director. Un fapt interesant este că catalogul în sine este un set de tabele, astfel încât SGBD-ul îl poate manipula în moduri tradiționale, fără a recurge la vreo tehnici sau metode speciale.

Domenii și relații

Definiții de bază: Domenii, tipuri de relații, predicate.

Relațiile au o serie de proprietăți de bază:

1. În chiar caz general nu există tupluri comune în relații - aceasta rezultă din însăși definiția relațiilor. Cu toate acestea, pentru unele SGBD-uri, în unele cazuri sunt permise abateri de la această proprietate. Atâta timp cât există o cheie primară în relație, tuplurile identice sunt excluse.

2. Tuplurile nu sunt ordonate de sus în jos - pur și simplu nu există un concept de număr pozițional într-o relație. În relații, fără a pierde informații, poți aranja cu succes tupluri în orice ordine.

3. Atributele nu sunt ordonate de la stânga la dreapta. Atributele din antetul relației pot fi aranjate în orice ordine fără a compromite integritatea datelor. Prin urmare, nici conceptul de număr pozițional în raport cu un atribut nu există.

4. Valorile atributelor constau din unități logic indivizibile - acest lucru rezultă din faptul că valorile sunt preluate din domenii, în caz contrar, putem spune că relațiile nu conțin grupuri de repetiție; Adică sunt normalizate.

Sistemele relaționale suportă mai multe tipuri de relații:

1. Cele numite sunt variabile de relație definite în SGBD de către operatorii de creație și, de regulă, necesare pentru o prezentare mai convenabilă a informațiilor pentru utilizator.

2. Relațiile de bază sunt direct parte importantă DB, deci la proiectare li se dă propriul nume.

3. O relație derivată este una care a fost definită prin alte relații, de obicei de bază, folosind instrumente DBMS.

4. Această reprezentare este de fapt o relație numită derivată, iar reprezentarea este exprimată exclusiv prin operatori DBMS aplicați relațiilor numite, deci nu există fizic în baza de date.

5. Rezultatul interogărilor este o relație derivată fără nume care conține date (rezultatul unei anumite interogări). Rezultatul nu este stocat în baza de date, dar există atâta timp cât utilizatorul are nevoie de el.

6. O relație stocată este una care este menținută fizic în memoria relațiilor stocate cel mai adesea includ baza relațiilor; Pe baza celor de mai sus, putem defini o bază de date relațională ca un set de relații interconectate.

Contact in în acest caz, este asocierea a două sau mai multe relații.

KOD	ADRES

1 1 O relație unu-la-mulți este aceea că la un moment dat fiecărui element (tuplu A) îi corespunde mai multe elemente ale tuplurilor B
∞ Conexiune binară

Elevii

Profesori

Programul cursurilor

∞

Elevii

Conexiuni ternare

Integritatea datelor

În modelele relaționale, problemei integrității datelor i se acordă un loc special. Amintiți-vă că o cheie sau o cheie potențială este un set minim de atribute ale căror valori pot fi folosite pentru a găsi în mod unic tuplul necesar înseamnă că excluderea oricărui atribut din set nu permite identificarea tuplului prin atributele rămase;

Fiecare relație are cel puțin o cheie posibilă. Una dintre ele este luată ca cheie primară.

Atunci când alegeți o cheie primară, ar trebui să se acorde preferință cheilor necompozite sau cheilor compuse din set minim atribute. De asemenea, nu este de dorit să folosiți chei cu valori de text lungi (este de preferat să folosiți atribute întregi ca chei). Deci, pentru a identifica un angajat, puteți utiliza fie un număr unic de personal, fie un număr de pașaport, fie un set de nume de familie, nume de mijloc și numere de departament. Nu este permis ca cheia primară a unei relații, adică orice atribut care participă la cheia primară, să ia valori nedefinite. În acest caz, va apărea o situație contradictorie ( coliziune): apare un element cheie primară neunică. Prin urmare, acest lucru ar trebui monitorizat cu atenție atunci când proiectați o bază de date.

Despre cheile externe. Este de remarcat faptul că, deoarece relația C leagă relațiile B și A, trebuie să includă chei străine corespunzătoare cheilor primare ale relațiilor A și B.

Cheia externă a unui tabel este formată folosind mai multe chei primare ale altor tabele.

Astfel, atunci când luăm în considerare problema alegerii unei metode de conectare a unei relații într-o bază de date, se pune întrebarea care ar trebui să fie cheile străine. În același timp, pentru toată lumea cheie străină este necesar să se rezolve problema asociată cu posibilitatea (sau imposibilitatea) unor valori nedefinite (NULL – valori - valoare atribut pentru informațiile lipsă). Cu alte cuvinte, poate exista un tuplu într-o relație pentru care tuplu în relațiile sale asociate nu este cunoscut?

Pe de altă parte, este necesar să ne gândim în avans la ceea ce se va întâmpla atunci când eliminați tuplurile dintr-o relație la care face referire o cheie străină. Există următoarele posibilități posibile:

· Funcționare cascade– adică ștergerea tuplurilor din relații duce la ștergerea tuplurilor asociate relației. De exemplu, ștergerea informațiilor despre nume, prenume etc. angajatul într-o privință duce la ștergerea salariului în altă privință;

· Funcționare limitat - adică numai acele tupluri pentru care nu există alte informații asociate sunt eliminate. Nu toate informațiile sunt șterse (nu în toate privințele), deoarece acestea pot fi utilizate și în altă privință, eliminarea informațiilor în care duce la o încălcare a integrității datelor. Dacă astfel de informații sunt disponibile, ștergerea nu poate fi efectuată, de exemplu, ștergerea informațiilor despre prenume, prenume etc. angajatul este posibil numai dacă nu există informații legate de salariul său.

Este necesar să oferiți tehnologie pentru ceea ce se va întâmpla atunci când încercați să actualizați cheia primară a unei relații la care face referire o cheie străină. Aici aveți aceleași opțiuni ca atunci când ștergeți:

· Operația este în cascadă, adică atunci când cheia primară este actualizată, cheia externă din relația aferentă este actualizată. De exemplu, actualizarea cheii primare în relația în care sunt stocate informații despre angajați duce la o actualizare a cheii străine în relația care conține informații despre salariu.

· Operația se limitează la actualizarea doar a acelor chei primare pentru care altfel nu există informații asociate. Dacă astfel de informații sunt disponibile, actualizarea nu poate fi făcută. De exemplu, actualizarea cheii primare într-o relație în care sunt stocate informații despre un angajat este posibilă numai dacă informațiile despre salariul său lipsesc în relația aferentă.1

Algebra relațională

Baza formală a modelului bazei de date relaționale este algebra relațională, bazată pe teoria mulțimilor și considerând operator special peste relații și calcul relațional bazat pe logica matematică.

Lucru

A A A B B C

A Y D

G D

A B C

A Y D

F F W

Trebuie remarcat faptul că algebra relațională are putere mare - interogări complexe la baza de date poate fi exprimată folosind o singură expresie. Din acest motiv, aceste mecanisme sunt incluse în modelul de date relaționale. Orice interogare exprimată folosind o expresie de algebră relațională sau o formulă de calcul relațional poate fi exprimată folosind un operator în acest limbaj.

Algebra relațională are proprietate importantă- este inchis in ceea ce priveste conceptul de relatie. Aceasta înseamnă că o expresie de algebră relațională este efectuată asupra relațiilor bazelor de date relaționale și rezultatele calculului acestora reprezintă, de asemenea, relații.

Ideea principală a algebrei relaționale este că mijloacele de manipulare a relațiilor considerate ca un set se bazează pe operații multiple tradiționale completate de unele operații specifice bazei de date.

Să descriem versiunea de algebră care a fost propusă de CODD. Operațiunea constă din 8 operatori principali:

· Raportul de eșantionare ( operație unară)

Proiecția relației (operație unară)

· Fuziunea relațiilor

· Intersecția relațiilor (operație binară)

· Scăderea rapoartelor

Produsul relațiilor

· Relații de legătură

· Împărțirea relațiilor

Aceste operațiuni pot fi explicate după cum urmează:

· Rezultatul selectării unei relații bazate pe o anumită condiție este o relație care include doar acele tupluri ale relației originale care îndeplinesc această condiție.

· La proiectarea unei relații pe un set dat de atribute ale acesteia, se va obține o relație ale cărei tupluri sunt luate din tuplurile corespunzătoare primei relații.

· La efectuarea operației de îmbinare a două relații se va obține o relație care include toate tuplurile incluse în cel puțin una dintre relațiile care participă la operație.

· La efectuarea operației de intersecție a două relații se va obține o relație care include toate tuplurile incluse în ambele relații inițiale.

· La efectuarea operației de scădere a două relații se va obține o relație care include toate tuplurile incluse în prima relație, cu excepția celor care sunt incluse și în a doua relație.

· La efectuarea produsului direct al două relaţii se obţine o relaţie ale cărei tupluri sunt o combinaţie a tuplurilor primei şi celei de-a doua relaţii.

· Când două relații sunt conectate în funcție de o anumită condiție, se formează o relație rezultată de tupluri ale căror tupluri sunt o combinație de tupluri ale primei și celei de-a doua relații care îndeplinesc această condiție.

· Operația de împărțire relațională are doi operanzi – o relație binară (formată din două atribute) și o relație unară (formată dintr-un atribut). Rezultatul operației este o relație constând din tupluri, inclusiv relația primului atribut de tupluri din prima relație și astfel încât setul de valori al celui de-al doilea atribut să coincidă cu setul de valori al celui de-al doilea atribut. .

În plus față de cele de mai sus, există o serie de operațiuni speciale specifice lucrului cu baze de date:

· Ca rezultat al operației de redenumire, o relație este un set de tupluri care coincide cu corpul relației originale, dar numele atributelor au fost schimbate.

Rezultă că rezultatul unei operații relaționale este o anumită relație este posibil să se formeze expresii relaționale în care, în loc de relația originală (operand), se va folosi o expresie relațională încorporată. Acest lucru se datorează faptului că operațiile algebrei relaționale sunt cu adevărat închise conceptului de relație. Să începem cu operația unificarea relaţiilor, cu toate acestea, aceasta este în în egală măsură se aplică și operațiilor de intersecție și combinare, adică în algebra relațională, rezultatul operației de unire este o relație. Dacă presupunem în algebra relaţională posibilitatea asociatii arbitrare două relații cu seturi diferite de atribute, atunci rezultatul unei astfel de operații va fi o mulțime, dar un set de tupluri de diferite tipuri, adică, în general, nu o relație. Dacă pornim de la cerința ca algebra relațională să fie închisă în raport cu conceptul de relație, atunci o astfel de operație asociatii este lipsit de sens. Aceasta duce la apariția conceptului compatibilitatea relațiilor De unificare: Două relații sunt compatibile numai dacă au aceleași antete, adică au același set de nume de atribute, iar aceleași atribute sunt definite în același domeniu.

Cu condiția ca două relații să fie compatibile prin unire, atunci când se efectuează în mod normal o operație unire-intersecție-scădere asupra lor, rezultatul operației este o relație cu un antet corect definit care se potrivește cu antetul fiecăruia dintre relațiile operandului. Dacă două relații nu sunt pe deplin compatibile cu îmbinarea, adică compatibile în toate, cu excepția numelor de atribute, atunci înainte de a efectua o operație de tip de îmbinare, aceste relații pot fi făcute compatibile pe deplin cu îmbinarea prin aplicarea unei operații de redenumire.

Funcționarea produsului direct al două relații ridică noi probleme. În teoria mulţimilor, produsul direct poate fi obţinut pentru orice mulţime. Elementele setului rezultat vor fi perechi formate din elemente ale primului și celui de-al doilea set. Deoarece relațiile sunt mulțimi, pentru oricare două relații este posibil să se obțină un produs direct. Cu toate acestea, rezultatul nu va fi o relație. Elementele rezultatului nu vor fi tupluri, ci perechi de tupluri. Prin urmare, în algebra relațională folosim formă specială operațiuni directe de produs - produs direct extins de relații. Atunci când se ia produsul direct extins a două relații, elementul relației rezultate este un tuplu format prin fuzionarea unui tuplu din prima relație și un tuplu din a doua relație. Imediat apare o a doua problemă legată de obținerea unui antet corect format al relației rezultate, aceasta duce la necesitatea introducerii conceptului de compatibilitate relațională prin luarea unui produs direct extins.

Două relații sunt compatibile prin luarea unui produs direct numai dacă setul de nume de atribute ale acestor relații nu se intersectează. Orice două relații pot fi convertite într-o formă de produs direct compatibil, aplicând o operație de redenumire uneia dintre relații.

Operația de preluare necesită două relații: o relație inițială, operandul și o condiție simplă de constrângere. În urma operației de selecție, se produce o relație al cărei cap coincide cu antetul relației de operand, iar corpul include acele tuple ale relației de operand care satisfac valorile condiției de constrângere.

Să introducem un număr de operatori.

Fie unire să însemne operația de unire, intersectare – operația de intersecție, minus – operația de scădere. Pentru a desemna operația de eșantionare, vom folosi construcția A unde B, unde A este relația operandului și B este o condiție simplă de comparație. Fie C1 și C2 două condiții simple de eșantionare

A unde C1 ȘI C2 este identic (A unde C1) se intersectează (A unde C2)

A unde C1 SAU C2 este identică cu (A unde C1) uniunea (A unde C2)

A unde C1 nu C2 este identic cu (A unde C1) minus (A unde C2)

Folosind aceste definiții, puteți implementa operațiuni de eșantionare în care condiția de eșantionare este arbitrară expresie logică alcătuită din conditii simple folosind conexiuni logice (și, sau, nu). Operația de preluare a proiecțiilor relației A pe lista de atribute a1, a2,…,an va fi o relație al cărei cap este mulțimea de atribute, a1,a2,…,an. Corpul rezultatului va fi format din tupluri pentru care în relația A există un tuplu, atributul a1 are valoarea b1, atributul a2 are valoarea b2< и так далее атрибут an – bn. По сути при выполнении операции проекции определяется «Вертикальная» вырезка отношения - операнда с удалением возникающих кортежей –дубликатов.

Operația de îmbinare, numită uneori îmbinare condiționată, necesită doi operanzi, relațiile fiind unite și un al treilea operand, condiția simplă. Fie conectate relația A și B Ca și în cazul operației de selecție, condiția de îmbinare C are forma, (a comp –op b) sau (a comp –op const) unde A și B sunt numele de. atribute ale relațiilor A și B, const este literalmente specificată constantă. Comp-op este o operațiune de comparație validă în acest context. Atunci, prin definiție, rezultatul operației de conectare este relația obținută prin efectuarea operației de restricție, conform condiției C, produsul direct al relației A și B.

Există un important caz special conexiuni, conexiune naturală. O operație de îmbinare se numește operație de îmbinare naturală dacă condițiile de îmbinare sunt de forma (a=b) unde a și b sunt atribute ale operanzilor de îmbinare diferiți. Acest caz este important pentru că este deosebit de comun în practică și există algoritmi eficienti implementare într-un SGBD. Operația natural join se aplică unei perechi de relații A și B care au un atribut comun P, adică un atribut cu același nume și definit pe același domeniu. Fie ab să desemneze uniunea antetelor relațiilor A și B. Atunci o îmbinare naturală este rezultatul îmbinării lui A și B proiectate pe ab. Operațiile de îmbinare naturală nu sunt incluse direct în setul de operații algebrei relaționale. dar au o semnificație practică foarte importantă.

Operația de împărțire a relațiilor necesită o explicație mai detaliată deoarece este greu de înțeles. Să fie date două relații A (a1,a2,..,an,b1,b2,…,bm)

B (b1,b2,…,bn) Presupunem că atributul b1 al relației A și atributul b1 al relației B sunt definite pe același domeniu. Să numim mulțimea de atribute (aj) un atribut compus a, iar mulțimea (bj) c un atribut compus b. După aceasta, vom vorbi despre împărțirea relațională a relației binare A (a,b) în relația unară B (b).

Rezultatul împărțirii lui A la B este o relație unară C (a), constând din tupluri v astfel încât în relația A există tupluri care în setul de valori (w) includ setul de valori ale lui b în raport cu B.

Deoarece împărțirea este cea mai dificilă operațiune, să o explicăm cu un exemplu. Să existe două relații în baza de date a studenților: STUDENTI (NUME COMPLET, NUMĂR) și NUME (NUME COMPLET), iar relația unară NUME conține toate numele pe care le au studenții institutului. Apoi, după efectuarea operației de împărțire relațională a relației STUDENTI în relația NUME, se va obține o relație unară care să conțină numerele de carnete de studenți aparținând studenților cu toate prenumele posibile la acest institut.

Notație relațională

Să presupunem că există o bază de date cu structura STUDENTI (număr, nume, bursă, cod grup) și relația GRUPURI (gr_nom, gr_col, gr vechi) Să presupunem că trebuie să aflați numele și numerele studenților. bilete pentru studenții care sunt prefecți de grupuri cu mai mult de 25 de persoane În algebră relațională, trebuie să luați pașii următori pentru o cerere ca aceasta:

1. Conectați relațiile STUDENTI și GRUPURI, conform condiției „număr_elev = stea_grup”;

2. Limitați raportul rezultat prin condiția gr_col>25.

3. Proiectați rezultatul operației anterioare pe atributul student_name, student_number.

Iată o formulare pas cu pas a secvenței de execuție a interogării în baza de date, fiecare dintre acestea corespunde unei operații relaționale. dacă formulăm aceeași interogare folosind calculul relațional, atunci am obține o formulă care poate fi citită: Emite STUDY_NAME și STUDY_NUMBER pentru astfel de studenți, astfel încât un astfel de grup GR_STAR și valoarea GR_NUM>25 să coexiste. În a doua formulare am indicat doar caracteristicile relației rezultate, dar nu am spus nimic despre metoda de formare a acesteia. În acest caz, SGBD însuși trebuie să decidă ce fel de operațiuni și în ce ordine trebuie efectuate asupra relațiilor STUDENTI și GRUPURI. Ambele metode discutate în exemplu sunt de fapt echivalente și nu există conversii foarte complexe de la una la alta.

Conceptele de bază ale calculului relațional sunt conceptele unei variabile cu o anumită zonă a valorii sale și conceptele unei formule corect construite bazate pe variabile și funcții speciale. Funcții. Care este domeniul de definire al unei variabile diferă între calculul tuplu și calculul domeniului, adică de-a lungul sau de-a lungul. În calculul tuplurilor, domeniile definiției variabilelor sunt relația bazei de date, adică. valoare valabilă Fiecare variabilă este un tuplu al unei relații. În calculul domeniului, domeniile de definire a variabilei sunt domeniile pe care sunt definite atributele relațiilor de baze de date, adică valoarea validă a fiecărei variabile este valoarea fiecărei variabile.

octet

Întreg

Şir

Char

Comanda RANGE este folosită pentru a defini tupluri. De exemplu, pentru a defini variabila STUDENT al cărei scop este STUDENTS, trebuie să utilizați construcția RANGE STUDENT IS STUDENTS. Din această definiţie rezultă că în orice moment al timpului variabila student reprezintă un anumit tuplu al relaţiei STUDENTI. Când utilizați variabile tuple în formule, puteți face referire la valorile atributelor variabilelor. De exemplu, pentru a face referire la valoarea atributului STUDENT_NAME al variabilei STUDENT, trebuie să utilizați construcția STUDENT.STUDENT_NAME.

Formulele construite corect sunt folosite pentru a exprima condițiile impuse variabilelor tuple. Astfel de formule se bazează pe comparații simple, care sunt operații de comparare a valorilor atributelor variabilelor și constantelor literale. De exemplu, construcția STUDENT.STUD_NOM=123456. Este o comparație simplă. Mai mult varianta dificila formulele compuse sunt formate folosind conexiuni logice AND, OR, NOT, IF...THEN. În cele din urmă, este posibil să se construiască formule bine formate folosind cuantificatori. Dacă F este o formulă bine formată care implică variabila var, atunci construcția EXIST (cuantificator de existență) var (F) și FORALL (pentru toate tuplurile) var (F) sunt corecte.

Variabilele incluse în formulele corect construite pot fi libere sau legate. Toate variabilele incluse în componența lor în timpul construcției cărora nu s-au folosit cuantificatori sunt libere. Aceasta înseamnă că dacă pentru un set de valori ale variabilelor tuple libere se obține valoarea „adevărată” la calcularea formulelor, atunci aceste valori pot fi incluse în relația rezultată. Dacă se folosește un cuantificator la construirea formulelor, atunci variabilele sunt legate. Atunci când se calculează valoarea unei astfel de formule corect construite, nu se utilizează o singură valoare a variabilei asociate, ci întregul său domeniu de definire.

1)EXISTĂ STUD2 (STUD.1STUD_STIP> STUD2.STUD_STIP)

2) FORALL STUD2 (STUD.1STUD_STIP> STUD2.STUD_STIP)

Fie STUD1 și STUD2 două variabile tuplu definite pentru relația elevi, atunci formula pentru tuplu curent al variabilei STUD1 ia valoarea adevărată numai dacă în întreaga relație elevi există un astfel de tuplu asociat cu variabila STUD2 astfel încât valoarea atributului său STUD_STIP satisface condiția de comparație internă. Formula corect construită nr. 2 pentru tuplul construit STUDENT 1 ia valoarea adevărată dacă pentru toate tuplurile relația STUDENTS asociată variabilei STUDENT 2, valoarea atributului STUDENT.STIP satisface condiția internă.

Astfel, formulele bine formate oferă un mijloc de exprimare a condițiilor de eșantionare dintr-o relație de bază de date. Pentru a putea folosi calculul relațional pentru munca adevarata cu baza de date este necesară o altă componentă care definește setul și numele coloanelor relației rezultate. Această componentă se numește lista tinta.

Lista țintelor are forma:

· Var.attr este numele unei variabile libere, attr este numele atributului relației pe care este definită variabila var.

· Var care este echivalent cu relația din listă, Var.attr1, Var.attr1... Var.attr№ include numele tuturor atributelor relației definitorii.

· Nume_nou = var.attr; noul nume al atributului corespunzător relației rezultate.

Ultima opțiune este necesară în cazurile în care codul din formulă folosește mai multe variabile libere cu același domeniu. În calculul domeniului, domeniul de definire a domeniilor nu este relațiile, ci domeniile. În legătură cu baza de date STUDENTS GROUP, putem vorbi despre variabilele de domeniu NUME (Valorile de domeniu sunt nume valide sau NOM STUD). (Valorile domeniului sunt numere de student valide).

Principala diferență dintre calculul de domeniu și calculul tuplu este prezența set suplimentar predicate care permit exprimarea așa-numitelor condiții de apartenență. Dacă R este o relație n-ară cu atribute (a1, a2, … an), atunci condiția de apartenență are forma R(ai1:Vi1,ai2:Vi2,...aim:Vim) unde (m<=n). Где в Vij это либо литерально заданная константа либо имя кортежной переменной. Условие членства принимает значение истина, только в том случае если в отношении R существует кортеж, содержащий следующие значения указанных атрибутов. Если от Vij константа то на атрибут aij накладывается жёсткое условие независящее от текущих доменных переменных. Если же Vij имя доменной переменной то условие членства может принимать различные значения при разных значениях этой переменной.

Un predicat este o funcție logică care returnează adevărat sau fals pentru un argument. O relație poate fi considerată ca un predicat cu argumente care sunt atribute ale relației în cauză. Dacă un anumit set specific de tupluri este prezent în relație, atunci predicatul va produce un rezultat adevărat, altfel va produce un rezultat fals.

În toate celelalte privințe, formulele și expresiile calculului de domeniu arată similar cu formulele și expresiile calculului tuplu. Evaluarea domeniului relațional este baza pentru majoritatea interogărilor de limbaj bazate pe formulare.

Informații conexe.

Model relațional

Modelul bazei de date relaționale a fost propus în 1969 de matematicianul și cercetătorul IBM E.F. Codd (E.F. Codd). Pentru câteva informații de bază despre bazele de date relaționale, consultați articolul de prezentare generală „ DB și DBMS" 2. Deoarece bazele de date relaționale sunt în prezent dominante, în acest articol (precum și în articolele " Descrierea datelor”, “Prelucrarea datelor" Și " Proiectarea bazei de date” 2) sunt discutate în detaliu conceptele cele mai esențiale ale modelului relațional.

Să observăm imediat că teoria bazelor de date relaționale a fost formulată inițial într-un limbaj matematic strict și tocmai conceptele matematice stricte, definite formal, descriu cel mai bine esența lucrurilor. Totodată, în cele mai multe cazuri este posibil, fără prea multă pagubă, să sacrificăm rigoarea terminologiei în favoarea transparenței prezentării, ceea ce vom încerca să facem.

Ideea principală a modelului relațional este următoarea. Baza de date constă dintr-o serie de neordonate mesele(în cel mai simplu caz - dintr-un singur tabel). Tabelele pot fi manipulate prin operațiuni non-procedurale (declarative) - cereri, ale căror rezultate sunt tot tabele.

Adesea, cuvântul „relațional” ( relaționale) în termenul „model relațional” se interpretează pe baza faptului că conexiunile sunt stabilite într-o bază de date relațională ( relatează) între mese. Această explicație este convenabilă, dar nu este exactă. În sistemul original de termeni al lui Codd, termenii de conexiune ( relaţii), atribute ( atribute) și tupluri ( tupluri) au fost folosite acolo unde majoritatea dintre noi folosim termenii mai familiari tabele, coloane (câmpuri) și rânduri (înregistrări).

Când construiți un model de informare al unui domeniu (vezi „ DB și DBMS”, “Proiectarea bazei de date” 2) ies în evidență esenţă(obiecte), descrie-le proprietăți a (caracteristici, atribute) care sunt esențiale pentru scopuri de modelare și se stabilesc conexiuni între entități. În etapa de trecere de la un model relațional infologic la unul datalogic, apar tabele. De obicei, fiecare entitate este reprezentată de un tabel. Fiecare rând al tabelului (o înregistrare) corespunde unei instanțe a entității, iar fiecare câmp descrie o anumită proprietate (atribut).

De exemplu, dacă trebuie să stocăm informații despre persoane, inclusiv numele de familie, prenumele, patronimul, TIN, țara de reședință și data nașterii fiecărei persoane, atunci entitatea este persoana, iar datele specificate sunt atributele. Entitatea însăși devine în mod natural numele tabelului.

Masa „Bărbat”

Modelul relațional necesită ca fiecare rând dintr-un tabel să fie unic, adică. astfel încât oricare două rânduri diferă în valoarea a cel puțin unui atribut.

Forma tabelară tradițională este utilă atunci când trebuie să prezentați datele în sine. Dacă, ca în exemplul de mai sus, vă interesează doar structura- numele câmpurilor, apoi din punct de vedere al clarității, ușurinței de utilizare în diagrame și economisirii spațiului, este mai convenabil să le descrieți după cum urmează:

Chei

Cheie meseleeste un câmp sau un grup de câmpuri care conțin valori unice într-un tabel dat. Cheia identifică în mod unic rândul corespunzător al tabelului. Dacă cheia constă dintr-un singur câmp, este adesea numită simplu, dacă din mai multe - compozit. În exemplul de mai sus, cheia este câmpul TIN (presupunem că se știe că TIN-urile sunt unice într-o țară).

Să ne uităm la un exemplu de tabel cu o cheie compusă. Site-urile de prognoză meteo prezintă adesea informații după cum urmează: pentru fiecare dată indică temperatura prognozată noaptea, dimineața, după-amiaza și seara. Pentru a stoca aceste informații, puteți utiliza un tabel ca acesta:

În acest tabel, nici câmpurile Data, Ora zilei și nici Temperatură nu sunt cheie - valorile pot fi repetate în fiecare dintre aceste câmpuri. Dar combinația câmpurilor Data + Ora zilei este unică și identifică în mod unic un rând de tabel. Aceasta este o cheie compusă.

Există adesea situații în care alegerea cheii nu este clară. Să revenim la primul exemplu. Să presupunem că, pe lângă nume, prenume, patronim, TIN, data nașterii, este necesar să se păstreze seria și numărul unui pașaport general și seria și numărul unui pașaport străin. Tabelul va arăta astfel:

Puteți selecta până la trei chei în acest tabel. Una dintre ele este simplă (TIN), celelalte două sunt compuse (Seria + Număr pașaport general și Seria + Număr pașaport străin). Într-o astfel de situație, dezvoltatorul alege cheia care este cea mai convenabilă din punctul de vedere al organizării bazei de date (în cazul general, cheia a cărei valoare durează cel mai puțin timp pentru a fi găsită). Tasta selectată în acest caz este adesea numită cheia principală sau primar, cheie și alte combinații de coloane din care se poate face o cheie sunt posibil, sau chei alternative. Rețineți că există întotdeauna cel puțin o cheie posibilă într-un tabel, deoarece rândurile nu pot fi repetate și, prin urmare, combinația tuturor coloanelor este garantată a fi o cheie posibilă.

Când descrieți tabele, este obișnuit să evidențiați cheile primare ale tabelelor. De exemplu, câmpurile relevante sunt adesea subliniate. Și Microsoft Access evidențiază câmpurile cheie cu caractere aldine.

Chiar mai des decât cu ambiguitatea în alegerea unei chei, dezvoltatorii se confruntă cu absența unei chei printre datele care trebuie stocate. Un fapt similar poate fi stabilit în procesul de analiză a domeniului subiectului. De exemplu, dacă trebuie să stocați o listă simplă de persoane - prenume, nume de familie, patronimice și date de naștere, atunci nu există nicio cheie în acest set de atribute - este posibilă o situație când două persoane diferite au același datele complet. În acest caz, trebuie să introduceți artificial un câmp suplimentar, de exemplu, un număr unic de persoană. O astfel de cheie este uneori numită în literatură surogat. Adesea, o cheie surogat este introdusă din motive de eficiență. Dacă, de exemplu, un tabel are o cheie compusă lungă, atunci dezvoltatorii introduc adesea o cheie surogat numerică scurtă suplimentară și o fac cheia primară. Acest lucru se face adesea chiar dacă există o cheie simplă care are un tip de date „incomod” (ineficient pentru căutare), de exemplu, un șir. Astfel de operații nu mai sunt relevante pentru teorie, dar sunt adesea întâlnite în practică.

Cititorul atent poate observa că cheia poate fi aproape întotdeauna extinsă (cu excepția cazului în care include toate câmpurile tabelului) prin includerea câmpurilor redundante. Formal, o astfel de cheie va rămâne o cheie, dar din punct de vedere practic, acesta este doar un joc de concepte. Astfel de chei nici măcar nu sunt considerate posibile, deoarece este întotdeauna necesar să se depună eforturi pentru a minimiza lungimea (complexitatea) cheii.

Forme normale, normalizare

Nu orice tabel pe care îl putem desena pe hârtie sau în Word poate fi un tabel de bază de date relaționale. Și nu orice tabel care poate fi folosit într-o bază de date relațională este corect din punctul de vedere al cerinței modelului relațional.

În primul rând, necesită ca toate datele din aceeași coloană să fie de același tip(despre tipuri vezi“Descrierea datelor” 2). Din acest punct de vedere, exemplul de mai jos nici nu are sens să discutăm:

În al doilea rând, necesită ca tabelul să aibă o cheie primară atribuită.

Aceste cerințe sunt necesare, dar nu suficiente. Teoria bazelor de date relaționale introduce conceptele de așa-numitele „forme normale” - cerințe pentru organizarea datelor în tabele. Formele normale sunt numerotate succesiv pe măsură ce cerințele devin mai stricte. Într-o bază de date proiectată corespunzător, tabelele sunt în cel puțin a treia formă normală. În consecință, vom lua în considerare primele trei forme normale. Să reamintim că avem de-a face cu tabele care satisfac cele două cerințe de bază formulate mai sus.

Prima formă normală (1NF)

Prima formă normală dictează că toate datele conținute într-un tabel trebuie să fie atomice(indivizibil). Lista tipurilor de date atomice corespunzătoare este determinată de SGBD. Cerința 1NF este complet naturală. Înseamnă că fiecare câmp al fiecărei înregistrări ar trebui să conțină o singură valoare, și nu o matrice sau orice altă structură de date. Să dăm un exemplu semnificativ de tabel care nu este în 1NF. Să avem liste cu notele elevilor la o anumită materie.

Deoarece valoarea câmpului Evaluări nu este atomică, tabelul nu îndeplinește cerințele 1NF.

O posibilă modalitate de a prezenta o listă de evaluări este descrisă în instrucțiunile pentru articol. „Design DB” 2.

A doua formă normală (2NF)

Se spune că un tabel este în a doua formă normală dacă este în 1NF și fiecare coloană fără cheie este complet dependentă de cheia primară. Cu alte cuvinte, valoarea fiecărui câmp trebuie să fie determinată în întregime de valoarea cheii primare. Este important de menționat că dependența de o cheie primară este înțeleasă tocmai ca o dependență de cheie în ansamblu, și nu de componenta sa individuală (în cazul unei chei compuse). Să dăm un exemplu de tabel care nu este în 2NF. Pentru a face acest lucru, să revenim la exemplul prognozei meteo și să adăugăm o altă coloană la tabel - ora răsăritului (acesta este un exemplu complet plauzibil; acest tip de informații sunt adesea furnizate pe site-urile de prognoză meteo).

După cum ne amintim, acest tabel are o cheie compusă Data+Ora zilei. Câmpul Temperatură este complet dependent de cheia primară - nu există probleme cu acesta. Dar câmpul Răsărit depinde doar de câmpul Data. Ora zilei nu afectează în mod natural ora răsăritului.

Aici este potrivit să punem întrebarea: care este sensul practic al 2NF? La ce folosesc aceste restricții? Se dovedește că este mare. Să presupunem că în exemplul de mai sus, dezvoltatorul ignoră cerințele 2NF. În primul rând, cel mai probabil va exista un așa-numit redundanţă- stocarea datelor inutile. La urma urmei, dacă ora răsăritului este deja stocată pentru o înregistrare cu o dată dată, atunci pentru toate celelalte înregistrări cu o dată dată ar trebui să fie aceeași și, în general, nu este nevoie să o stocați.

Să fim atenți la cuvintele „ar trebui să fie”. Ce se întâmplă dacă nu? La urma urmei, la nivelul bazei de date, acest lucru nu este controlat în niciun fel - cheia din tabel este compusă, pot exista date identice (și din punct de vedere al semnificației, cel mai probabil vor exista). Și nicio restricție formală (și înțelegerea noastră că „asta nu se poate întâmpla” nu este una dintre ele) interzice indicarea orelor diferite de răsărit pentru aceeași dată.

A treia formă normală (3NF)

Se spune că un tabel este în 3NF dacă este 2NF și toate coloanele care nu sunt cheie sunt independente reciproc.

Dependența reciprocă a coloanelor este convenabil înțeleasă după cum urmează: Coloanele sunt reciproc dependente dacă este imposibil să schimbați una dintre ele fără a o schimba pe cealaltă.

Să dăm un exemplu de tabel care nu este în 3NF. Să luăm în considerare un exemplu de notebook simplu pentru stocarea numerelor de telefon de acasă ale persoanelor care locuiesc, poate, în diferite regiuni ale țării.

Acest tabel are o dependență între coloanele non-cheie Oraș și Cod oraș, prin urmare tabelul nu este în 3NF.

Rețineți că dezvoltatorul determină prezența dependenței de mai sus analizând domeniul subiectului - o astfel de coliziune nu poate fi văzută prin nicio metodă formală. La modificarea proprietăților domeniului subiectului, dependența dintre coloane poate dispărea. De exemplu, dacă în același oraș sunt introduse coduri diferite (cum ar fi 495 și 499 în Moscova), coloanele corespunzătoare nu mai sunt legate în ceea ce privește încălcarea cerințelor 3NF.

În teoria bazelor de date relaționale sunt considerate și forme de ordin superior - forma normală Boyce-Codd, 4NF, 5NF și chiar mai mare. Aceste forme nu au o semnificație practică prea mare, iar dezvoltatorii, de regulă, se opresc întotdeauna la 3NF.

Normalizarea bazei de date

Normalizarea este procesul de reducere a tabelelor bazei de date la o formă normală selectată. Normalizarea la 2NF, de regulă, se reduce la descompunere - împărțirea unui tabel în mai multe. Normalizarea la 3NF poate fi realizată de obicei prin eliminarea coloanelor dependente (calculate). În unele cazuri, atunci când normalizați la 3NF, trebuie să efectuați și descompunerea.

Baze de date cu mai multe tabele, relații între tabele, chei externe

În practică, bazele de date cu un singur tabel sunt destul de rare, deoarece din punctul de vedere al modelării unei baze de date de domeniu, prezența unui singur tabel înseamnă prezența unei entități. La rândul său, prezența mai multor entități înseamnă de obicei prezența unor legături între ele.

Fără a stabili scopul unui design complet de baze de date, să luăm în considerare un exemplu care ne permite să demonstrăm relațiile în baze de date cu mai multe tabele.

Să presupunem că avem de-a face cu o școală în care sunt elevi grupați pe clase și profesori care predau anumite materii. Deosebim imediat patru entități: elevi, profesori, clase și obiecte. Aceste entități ne oferă deja patru tabele.

În continuare, trebuie să rezolvăm problema atributelor entității - ce fel de informații vom stoca. Deoarece exemplul nostru are doar scop demonstrativ, vom încerca să minimizăm cantitatea de informații stocate. Vom fi de acord să păstrăm numele de familie și prenumele pentru fiecare elev, pentru clasă - numărul paralel și litera de identificare a clasei în cadrul paralelei, pentru profesor - numele de familie, prenumele și patronimul, pentru materie - doar numele acesteia .

Acum trebuie să rezolvăm problema cu cheile primare. Tabelele pentru elevi și profesori practic nu au o cheie, așa că vom introduce o cheie numerică surogat în ele - un număr. Tabelele de clase și articole, în general, au chei. În tabelul de clase, cheia este compusă, este formată din atributele Număr paralel + Literă, iar în tabelul de obiecte, o cheie simplă este formată dintr-un singur câmp - numele obiectului. Reamintim că atunci când am vorbit despre chei, am menționat că cheile surogat sunt adesea adăugate din motive de eficiență, încercând să scăpăm de cheile compuse sau câmpurile cheie de tipuri incomode, cum ar fi șirurile de caractere. Asta vom face. Să adăugăm o cheie numerică surogat la fiecare dintre tabele.

Ca urmare, vom primi următorul set de tabele corespunzătoare entităților descrise.

Înțelegând de ce domeniu ne ocupăm, știm că entitățile noastre nu există de la sine - sunt conectate prin anumite relații pe care le-am subliniat mai sus. Dar cum să le conectăm tehnic? Aici nu puteți face fără introducerea de câmpuri suplimentare și chiar tabele suplimentare. Să ne uităm la relațiile dintre entități în ordine.

Pentru a atribui un elev la o anumită clasă, să adăugăm un câmp suplimentar, Numărul clasei, la tabelul „Student”. (Este clar că tipul său trebuie să se potrivească complet cu tipul câmpului Numărul clasei din tabelul „Clasă”.) Acum putem lega tabelele „Student” și „Clasă” folosind valorile potrivite ale câmpurilor Numărul clasei ( nu întâmplător am numit aceste câmpuri la fel, în practică Acest lucru se face adesea pentru a naviga cu ușurință în câmpurile de legătură). Rețineți că o înregistrare din tabelul „Clasă” poate corespunde multor înregistrări din tabelul „Student” (și, în practică, cel mai probabil corespunde - este dificil să vă imaginați o clasă de un student). Se spune că astfel de tabele sunt legate de relația „ unu la multi" Și câmpul Numărul clasei din tabelul „Student” este numit cheie străină. După cum puteți vedea, scopul cheilor externe este de a lega tabele. Rețineți că o cheie externă se referă întotdeauna la cheia primară a tabelului aferent (adică cheia externă se află pe partea „multe”). Cheia primară asociată cu o străină este apelată părintească, deși acest termen este folosit mai rar.

Să ilustrăm acest lucru cu o diagramă în stilul Microsoft Access (mai multe informații despre „Schema de date” Access sunt scrise în articol „Descrierea datelor” 2).

Acum să ne gândim la profesori și materii. Analizând tematica (asta este singura modalitate - la urma urmei, este imposibil să extragem adevărata stare a lucrurilor din modelul formal în sine), observăm că tipul de legătură dintre entitățile „profesor” și „subiect” este diferit. din cele discutate mai sus. La urma urmei, nu numai că mulți profesori pot preda o singură materie, dar un profesor poate preda multe discipline. Astfel, există o legătură între aceste entități” multi la multi" Aici nu te poți descurca fără să introduci câmpuri suplimentare (încearcă!). Relațiile multi-la-multe sunt întotdeauna rezolvate prin introducerea unui tabel suplimentar. Și anume, organizăm tabelul „Profesor-Subiect”, care are următoarea structură:

Tabel „Profesor-Materia”

Acest tabel are o cheie compusă formată din două dintre câmpurile sale. Atât tabelul „Profesor”, cât și tabelul „Subiect” sunt legate de acest tabel într-o relație unu-la-mai mulți (desigur, în ambele cazuri „mulți” se află pe partea „Profesor-Subiect”). În consecință, în tabelul „Profesor-Subiect” există două chei străine (ambele sunt părți ale unei chei primare compuse, care nu este interzisă), care servesc la conectarea cu tabelele corespunzătoare.

În practică, pe lângă relațiile considerate „unu-la-mulți” și „mulți-la-mulți”, există și relația „ unu la unu" Din punct de vedere teoretic, o astfel de relație nu prezintă interes, deoarece două tabele conectate printr-o relație unu-la-unu pot fi întotdeauna combinate într-unul singur. Cu toate acestea, în bazele de date reale, o relație unu-la-unu este utilizată pentru a optimiza procesarea datelor. Să ilustrăm acest lucru cu un exemplu.

Să presupunem că stocăm o mulțime de informații diferite despre oameni - date din tot felul de documente, numere de telefon, adrese etc. Cel mai probabil, majoritatea acestor date vor fi folosite foarte rar. Și de multe ori avem nevoie doar de un nume de familie, prenume, patronimic și număr de telefon. Apoi, are sens să organizezi două mese și să le relaționezi într-o relație unu-la-unu. Stocați informațiile utilizate frecvent într-un tabel (mic), iar restul într-un altul. Desigur, tabelele legate printr-o relație unu-la-unu au aceeași cheie primară.

Reguli de integritate

Modelul relațional definește două reguli generale pentru integritatea bazei de date: integritatea obiectului și integritatea referențială.

Regula de integritate obiecte foarte simplu. Ea necesită ca cheile primare de tabel să nu conțină valori nule (nule)..

Regula de integritate referenţială cere ca cheile străine să nu conțină valori care sunt incompatibile cu cheile lor părinte. Revenind la exemplul discutat mai sus, trebuie să cerem, de exemplu, ca elevii să aparțină numai clasei al cărei număr este indicat în tabelul „Clasuri”.

Majoritatea SGBD-urilor sunt capabile să monitorizeze integritatea datelor (desigur, acest lucru necesită eforturi corespunzătoare din partea dezvoltatorului în etapa de descriere a structurilor de date). În special, mecanismele sunt utilizate pentru a menține integritatea referențială în cascadă operațiuni. Cascada implică, în special, că, atunci când ștergeți o înregistrare dintr-un tabel „părinte” care este conectat la un alt tabel printr-o relație unu-la-mai mulți, toate înregistrările asociate sunt șterse automat din tabelul „mai multe” (de către SGBD însuși, fără intervenția utilizatorului). Și acest lucru este firesc, deoarece astfel de înregistrări „atârnă în aer” nu mai sunt legate de nimic.

Indexarea

Indexarea este extrem de importantă din punct de vedere al aplicării practice, dar opțională din punctul de vedere al teoriei pure. Scopul principal al indexării este optimizarea (accelerarea) căutării (și, în consecință, alte operațiuni cu baza de date). Indexarea necesită în orice caz resurse suplimentare (fișierele index speciale sunt cel mai adesea create la nivel fizic). Indexarea poate chiar încetini operațiunile legate de modificarea datelor, prin urmare, tabelele care sunt rareori modificate și căutate frecvent sunt de obicei indexate.

Un fișier index este foarte asemănător cu un index obișnuit de carte. Pentru fiecare valoare de index, este stocată o listă de rânduri de tabel care conțin acea valoare. În consecință, pentru a căuta, nu trebuie să vă uitați prin întregul tabel - doar căutați în index. Cu toate acestea, atunci când modificați înregistrările, poate fi necesar să reconstruiți indexul. Și asta necesită timp suplimentar.

Desigur, nu se pune problema de a prezenta teoria bazelor de date relaționale ca parte a unui curs de bază de informatică! Cu toate acestea, acest articol este foarte important pentru enciclopedia noastră, deoarece în acest caz avem de-a face cu materiale care nu pot fi prezentate pe deplin în lecții, dar profesorul trebuie să-l stăpânească. De ce?

În primul rând, pentru că în cadrul cursului de bază sunt studiate o serie de concepte. Aceasta include o vizualizare de tabel a datelor și cheilor de tabel. Și știm cu toții că este foarte dificil să prezinți corect și precis doar unele concepte fără a prezenta imaginea de ansamblu.

În al doilea rând, efectuarea de interogări simple în baza de date cu copii (materialul relevant este prezentat în articol „Prelucrarea datelor” 2), este necesar să ne ocupăm de tabele care sunt corecte din punctul de vedere al teoriei relaționale. Nu este nevoie să le explicați elevilor că aceste tabele sunt corecte, dar „dacă doar..., atunci tabelul ar fi incorect”, dar este inacceptabil să folosiți exemple proaste.

Într-un curs specializat de informatică, situația poate fi fundamental diferită. Cea mai importantă și extrem de productivă formă de muncă în clasele de specialitate este munca pe proiecte. În cadrul proiectelor educaționale, este posibil și necesar să se dezvolte baze de date simple, iar aici nu se poate face fără fundamentele teoriei prezentate. Cu toate acestea, trebuie luate în considerare următoarele:

Temele care se modelează nu trebuie să fie prea mari;

Ar trebui să fie foarte familiari studenților (în acest sens, proiectul „Școala”, de care toată lumea s-a săturat, nu este cea mai proastă alegere!);

Este naiv să ne așteptăm ca, după ce au ascultat elementele de bază ale teoriei, studenții vor putea să proiecteze ei înșiși ceva. Fiecare pas trebuie făcut împreună cu ei, justificându-vă acțiunile în detaliu.

O bază de date (DB) este o colecție de informații despre obiecte, procese, evenimente sau fenomene legate de un anumit domeniu, subiect sau sarcină, organizate în conformitate cu anumite reguli și păstrate în memoria computerului. Este organizat astfel încât să asigure nevoile de informare ale utilizatorilor, precum și stocarea convenabilă a acestei colecții de date, atât în ansamblu, cât și în orice parte a acesteia.

O bază de date relațională este un set de tabele interconectate, fiecare dintre ele conține informații despre obiecte de un anumit tip. Fiecare rând al tabelului conține date despre un obiect (de exemplu, o mașină, un computer, un client), iar coloanele tabelului conțin diferite caracteristici ale acestor obiecte - atribute (de exemplu, numărul motorului, marca procesorului, numerele de telefon). a companiilor sau clientilor).

Rândurile unui tabel se numesc înregistrări. Toate înregistrările de tabel au aceeași structură - sunt formate din câmpuri (elementele de date) în care sunt stocate atributele obiectului (Fig. 1). Fiecare câmp de înregistrare conține o caracteristică a obiectului și reprezintă un tip de date specificat (de exemplu, șir de text, număr, dată). O cheie primară este folosită pentru a identifica înregistrările. O cheie primară este un set de câmpuri de tabel a căror combinație de valori identifică în mod unic fiecare înregistrare din tabel.

Orez. 1. Numele obiectelor din tabel

Sistemele de management al bazelor de date (DBMS) sunt folosite pentru a lucra cu date. Principalele funcții ale SGBD:

Definirea datelor (descrierea structurii bazei de date);

Prelucrarea datelor;

Gestionarea datelor.

Dezvoltarea structurii bazei de date este cea mai importantă sarcină rezolvată la proiectarea unei baze de date. Structura unei baze de date (setul, forma și relațiile tabelelor sale) este una dintre principalele decizii de proiectare atunci când se creează aplicații folosind o bază de date. Structura bazei de date creată de dezvoltator este descrisă în limbajul de definire a datelor DBMS.

Orice SGBD vă permite să efectuați următoarele operații cu date:

Adăugarea înregistrărilor la tabele;

Eliminarea înregistrărilor dintr-un tabel;

Actualizarea valorilor unor câmpuri dintr-una sau mai multe înregistrări din tabelele bazei de date;

Caută una sau mai multe înregistrări care îndeplinesc o condiție specificată.

Pentru a efectua aceste operații, se folosește un mecanism de interogare. Rezultatul executării interogărilor este fie un set de înregistrări selectate după anumite criterii, fie modificări în tabele. Interogările către baza de date sunt formate într-o limbă special creată în acest scop, care se numește „limbaj interogări structurate„(SQL – Limbajul de interogare structurat).

Guvernanța datelor se referă de obicei la protejarea datelor împotriva accesului neautorizat, la sprijinirea procesării datelor cu mai mulți utilizatori și la asigurarea integrității și consecvenței datelor.

BAZĂ DE DATE RELAȚIONALĂ ȘI CARACTERISTICILE EI. TIPURI DE RELAȚII ÎNTRE TABELE RELAȚIONALE

Baza de date relațională este o colecție de tabele interconectate, fiecare dintre ele conține informații despre obiecte de un anumit tip. Un rând de tabel conține date despre un obiect (de exemplu, un produs, un client), iar coloanele tabelului descriu diferite caracteristici ale acestor obiecte - atribute (de exemplu, nume, cod de produs, informații despre client). Înregistrările, adică rândurile de tabel, au aceeași structură - sunt compuse din câmpuri care stochează atributele obiectului. Fiecare câmp, adică coloană, descrie o singură caracteristică a obiectului și are un tip de date strict definit. Toate înregistrările au aceleași câmpuri, doar că afișează diferite proprietăți de informații ale obiectului.

Într-o bază de date relațională, fiecare tabel trebuie să aibă o cheie primară - un câmp sau o combinație de câmpuri care identifică în mod unic fiecare rând din tabel.

Tabelele bazelor de date relaționale trebuie să îndeplinească cerințele pentru normalizarea relațiilor. Normalizarea relațiilor este un aparat formal de restricții privind formarea tabelelor, care elimină dublarea, asigură consistența datelor stocate în baza de date și reduce costurile cu forța de muncă pentru întreținerea bazei de date.

Lăsați să fie creat un tabel Student care să conțină următoarele câmpuri: numărul grupului, numele complet, numărul de înregistrare al studentului, data nașterii, numele specialității, numele facultății. O astfel de organizare a stocării informațiilor va avea o serie de dezavantaje:

duplicarea informațiilor (numele specialității și facultății se repetă pentru fiecare student), prin urmare, volumul bazei de date va crește;
procedura de actualizare a informațiilor din tabel este complicată din cauza necesității de a edita fiecare intrări în tabel.

Normalizarea tabelului este concepută pentru a rezolva aceste deficiențe. Disponibil trei forme normale de relaţii.

Prima formă normală. Un tabel relațional este redus la prima formă normală 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. Deci, dacă trebuie să obțineți informații din tabelul Student după numele studentului, atunci câmpul Nume complet ar trebui să fie împărțit în părți Nume, Prenume și Patronimic.

A doua formă normală. Un tabel relațional este definit în a doua formă normală dacă îndeplinește cerințele primei forme normale și toate câmpurile sale care nu sunt incluse în cheia primară au o dependență funcțională completă de cheia primară. Pentru a reduce un tabel la a doua formă normală, este necesar să se determine dependența funcțională a câmpurilor. O dependență funcțională a câmpurilor este o dependență în care, într-o instanță a unui obiect informațional, o anumită valoare a unui atribut cheie corespunde unei singure valori a unui atribut descriptiv.

A treia formă normală. Un tabel este în a treia formă normală dacă îndeplinește cerințele celei de-a doua forme normale conform cărora niciunul dintre câmpurile sale non-cheie nu este dependent funcțional de orice alt câmp non-cheie. De exemplu, în tabelul Student (Nr. grup, Nume complet, Nr. caiet de note, Data nașterii, Director), trei câmpuri - Nr. caiet de note, Nr. grup, Director sunt în dependență tranzitivă. Numărul grupului depinde de numărul caietului de note, iar șeful depinde de numărul grupului. Pentru a elimina dependența tranzitivă, este necesar să transferați unele dintre câmpurile tabelului Student într-un alt tabel Grup. Tabelele vor avea următoarea formă: Student (număr grup, nume complet, număr carnet de studii, data nașterii), Grup (număr grup, director).

Următoarele operații sunt posibile pe tabele relaționale:

Îmbinați tabele cu aceeași structură. Rezultatul este un tabel comun: mai întâi primul, apoi al doilea (concatenare).
Intersectia tabelelor cu aceeasi structura. Rezultat - sunt selectate acele înregistrări care se află în ambele tabele.
Scăderea tabelelor cu aceeași structură. Rezultat - sunt selectate acele înregistrări care nu sunt în cea scăzută.
Eșantion (subset orizontal). Rezultat - sunt selectate înregistrările care îndeplinesc anumite condiții.
Proiecție (subset vertical). Rezultatul este o relație care conține unele dintre câmpurile din tabelele sursă.
Produsul cartezian a două tabele Înregistrările tabelului rezultat sunt obținute prin combinarea fiecărei înregistrări a primului tabel cu fiecare înregistrare a celuilalt tabel.

Tabelele relaționale pot fi legate între ele, prin urmare datele pot fi preluate din mai multe tabele simultan. Tabelele sunt legate între ele pentru a reduce în cele din urmă dimensiunea bazei de date. Fiecare pereche de tabele este conectată dacă au coloane identice.

Există următoarele tipuri de link-uri de informații:

unu-la-unu;
unu-la-mai multe;
multi-la-multi.

Comunicare unu-la-unu presupune că un atribut al primului tabel corespunde unui singur atribut al celui de-al doilea tabel și invers.

Comunicare unu-la-mulți presupune că un atribut al primului tabel corespunde mai multor atribute ale celui de-al doilea tabel.

Comunicare multi-la-multi presupune că un atribut al primului tabel corespunde mai multor atribute ale celui de-al doilea tabel și invers.