Ce este un sub și cu ceea ce este mâncat?

Prelegeri pe tema "Introducere în teoria SGBD"

Înainte de a începe să practici modelarea, proiectarea unei baze de date complexe sau gestionarea unei baze de date heaped, trebuie să vă îmbogățiți cu cel puțin abilități teoretice minime. În timpurile antice, când au fost visate doar bazele de date, cineva a observat că fără teorie nu există practică.







CE ESTE UN RDBMS ȘI CU CE ESTE MĂSAT

Cei care au auzit despre bazele de date, nu are sens să vorbească despre modele, link-uri etc. Primul lucru de care ai nevoie pentru a începe o narațiune este definiția de bază, pentru care intri în arsenalul tău, vei digera cu ușurință orice altceva.

Nevoia de a stoca date sub forma unor structuri, adică ordonarea de informații despre anumite obiecte din lumea înconjurătoare, a fost palpabilă pentru omenire în orice moment. În acest caz, un obiect este înțeles fie ca un obiect, fie ca un concept mai abstract (de exemplu, procesul de a produce ceva).

Introducerea unui obiect în baza de date este doar jumătate din bătălie. Încă mai trebuie să caracterizeze, să conecteze cu ea o anumită valoare. Și apoi trebuie să introduceți conceptul de "dat". Acesta este un anumit indicator care caracterizează obiectul și îi conferă o anumită valoare. Și nu neapărat, că obiectul a fost determinat de o singură dată - pot fi mulți. Imaginați-vă că aveți de-a face cu o structură hacker. Hacking-ul este un obiect. Dar datele - aceasta este hacking-ul, experiența activităților ilegale, numărul de exploatații scrise și mașinile hacked etc. Cu alte cuvinte, datele sunt caracteristicile unui anumit obiect. Acesta este cel mai important interes pentru client, care a apelat la baza de date viitoare.

Creați un fișier cu mai multe megabyte cu tone de informații (care, apropo, poate fi redundant) nu este o soluție la problemă. O persoană iubește confortul, de exemplu, pentru a sparge informațiile către un hacker mare, clientul fiind obligat să furnizeze porecla de cracare, iar informația exhaustivă despre criminalul cibernetic va deveni o armă a justiției. Este foarte dificil să se organizeze un astfel de sistem, a durat câteva decenii înainte ca fișierele individuale să devină baze de date demne de încredere (baza de date din fișierul ini este de asemenea elegantă - notează dr.). Acum, totul a devenit mult mai ușor din cauza existenței unor fișiere structurate - baze de date și diverse modele de organizare a datelor.

De fapt, modelul este baza pe care se bazează baza sau baza de date. În unul sau alt model, sunt determinate relațiile dintre date, tipurile de date de intrare, metodele de stocare, gestionare etc. Comunicarea datelor cu programele de aplicații este furnizată prin intermediul unui DBMS sau prin intermediul sistemelor de gestionare a bazelor de date.

Deci, DBMS este un set de instrumente de limbaj și software concepute pentru a crea, întreține și partaja o bază de date cu mulți utilizatori. Cu alte cuvinte, cu ajutorul unui DBMS, oricine dorește (cu anumite drepturi, bineînțeles) va putea să acceseze baza de date și să scoată informațiile care îi interesează.

Acest sau acel DBMS depinde de model, care este baza bazei de date. În prezent, cele două modele cele mai comune au devenit comune: modelul relațional (model de relație) și modelul orientat pe obiect (modelul obiect). Despre ele și vor fi discutate în acest articol.

Să începem cu modelul relațional. În distanta din 1969, un matematician american, Dr. E.F. Codd (E.F. Codd) a analizat stadiul stratificat de timp în bazele de date și a ajuns la concluzia că problema a fost rea. În toate modelele disponibile la acea dată, au existat deficiențe semnificative: redundanța datelor, complexitatea procesării și lipsa securității stocării informațiilor etc. După o reflecție dureroasă, Codd a decis să-și creeze propriul model - cel relațional. Pentru cei care au ignorat în mod malefic engleza, îmi amintesc că relația este tradusă ca "atitudine" sau pur și simplu "tabel". Doctorul ingenios tocmai a realizat stocarea datelor în formă tabulară, adică a organizat astfel de "magazine" sub formă de structuri logice (metode fizice de stocare pot fi oricare). Astfel, Codd a reușit să realizeze vizibilitatea prezentării informațiilor și a confortului procesării acestora. Datorită realizării acestui geniu, a fost suficient să se îndeplinească o anumită interogare logică, care respectă legile algebrei booleene, pentru a crea un tabel de date. Dintre operatorii de manipulare a datelor există cel puțin trei operații: extragerea rândurilor (SELECT), extragerea coloanelor (PRO-JECT) și tabelele de îmbinare (JOIN). Ca urmare a acestor acțiuni, obținem un tabel. Și o simplă concluzie din toate acestea: rezultatul oricărei operațiuni în modelul relațional este un obiect de același fel ca și obiectul peste care a fost efectuată acțiunea.

Aceasta este proprietatea principală a modelului descris.

Pe lângă cunoștințele de bază, avem nevoie de definiții de bază aplicabile acestui model: tipul de date, atributul, tuplul, relația și cheia primară.

Un tip de date este o definiție care corespunde conceptului de tip în limbile de programare. Cu alte cuvinte, modelul relațional poate Mentionam-Debit mediu la astfel de tipuri principale ca „întreg“, „string“, „caractere“, „număr de virgulă mobilă“, „data“ și „zi-Gl“ (care, în timpul nostru, fără bani :)).

Un atribut este o coloană într-un tabel de date. De exemplu, dacă ecranul conține informații despre atacurile hackerilor, exploatații și experiența de lucru, atunci toate aceste coloane sunt atribute.

O tuplă este un rând într-un tabel cu date. Astfel, informațiile exhaustive despre un anumit hacker sunt o tuplă.

Raportul este tabelul în ansamblu. Descrierea tipurilor de date utilizate în etichetă se numește denumirea relației, iar orice altceva (datele de proprietate) este corpul relației.

Cheia primară este setul minim de atribute (coloane) care determină unicitatea unică a fiecărui tuplu (rânduri) în raport cu (tabelul). Atunci când creați o bază de date, ar trebui să aveți o atentă atenție la atribuirea cheii primare - în exemplul nostru, porecla hacker-ului va fi inadecvată (dintr-o dată cineva va dori să ia porecla idolului său.)). Se întâmplă ca un câmp suplimentar cu un număr ordinal să fie introdus pentru autentificare, care va fi diferit pentru fiecare linie. Dar nimeni nu interzice să aleagă pentru cheia primară două sau trei atribute: tot ce doriți, dacă numai această acțiune ar fi justificată logic (o gamă similară de atribute va fi numită cheie primară).







Pentru a obține o gestionare eficientă a bazei de date, este necesar să se asigure conectivitatea datelor. Pur și simplu, trebuie să puteți asocia două sau mai multe tabele într-o bază de date (dacă sunt, desigur, există). În acest scop, a fost inventată o așa-numită "cheie străină", ​​care este un atribut (sau un set de atribute) într-un singur tabel care coincide în tip cu cheia primară a celuilalt. Dar, de asemenea, este necesar să se respecte condiția ca fiecare valoare din coloana unui tabel să coincidă cu o anumită valoare în cealaltă. Esența acestei definiții este descoperirea după explicația mea privind eventualele conexiuni de date.

În teoria SGBD se disting trei tipuri de legături: unul la unul, unul la mulți și mulți la mulți. Vă voi spune în detaliu despre fiecare specie.

1. Unu-la-unu. Acest tip de conexiune este utilizat atunci când cheia primară a unei tabele se referă la cheia celuilalt. Pentru a face mai clară, voi da un exemplu: să presupunem că avem trei tabele ale unei baze de date hacker. Prima este informația despre hacker: data nașterii, sexul (fetele sunt de asemenea biscuiți;)) și ICQ. Al doilea este curenții de hacker (tipul fluxului, complexitatea acestuia și investițiile inițiale de capital). Și a treia este tipul de acces la Internet (tehnologie, viteză de acces, evaluare de securitate). Toate aceste tabele nu pot fi reduse la unul, deoarece, din cauza lipsei de conexiune între datele privind accesul la Internet și despre curenții hacker (și nu numai despre ei), vom deveni confuzi. Și când implementați conexiunea sub forma a trei tabele diferite (cu ajutorul cheii primare - numărul ordinal), furnizați atât viteză mare de procesare, cât și ordonarea datelor.

2. Unu-la-mulți. Cea mai tipică conexiune. Este implementat atunci când se copiază cheia primară a unui tabel în altul. În acest caz, în al doilea tabel, această cheie este numită externă. Nu este clar? Apoi, din nou, mă îndrept spre exemplu. Luați două tabele - cu informații despre hacker (tabelul "Hackerii") și despre relația cu caracteristicile explozilor pe care le-a scris (tabelul "Exploits"). De fapt, ele sunt legate printr-un mecanism unul-la-multe. Într-adevăr, fiecare hacker poate fi un auto-

Rum mai multe exploituri (așa cum se întâmplă de multe ori), dar fiecare exploata poate fi scris de către unul și numai unul AB-tor (chiar și atunci când se lucrează împreună a fost un singur om în hack exploata anumite grupuri). Aici, ca o cheie externă în tabelul „exploateaza“ hackeri porecla folosit și ca primar - numele exploata. În acest caz, o cheie „porecla hacker“ străin este cheia primară din tabelul „Ascendente“, iar aici a introdus NAMA-Renno pentru a comunica două tabele și Orga-TION regăsire dorită. De altfel, raportul dintre „exploateaza“ nu obja-va conține în mod necesar doar un singur atribut - puteți adăuga caracteristice-ticuri ale sistemelor de operare, care se aplică exploata, numărul de goluri, tipul (local sau la distanță-NY), etc.

Aici, de fapt, și toate informațiile despre modelul relațional. Pentru a îmbunătăți această secțiune, voi spune că multe dintre DBMS-urile sunt construite pe baza sa. Cu plăcere vorbeam despre algebra booleană, ale cărei legi se bazează pe modelul relațional, dar, din păcate, volumele acestui articol nu îmi vor permite să fac acest lucru.

Și restul bazei de date? La ce model aparțin? De fapt, pe lângă modelul relațional există și alții. Nici unul dintre aceștia nu a primit o distribuție specială, cu excepția, probabil, orientată pe obiecte, care a apărut mai târziu ca o relațională (de aceea se numește uneori postrelaționala) și este încă folosită astăzi.

Condiția principală a modelului relațional este regula normalizării. Toate valorile tabelului trebuie să fie indivizibile logic, coloanele și rândurile nu sunt ordonate și nu ar trebui să existe două tuple identice în relație. O astfel de normalizare adesea încalcă legăturile ierarhice naturale dintre obiecte, ceea ce este extrem de incomod, astfel încât dezvoltatorii au propus un nou DBMS, și anume, orientat pe obiecte. Esența unei astfel de paradigme este aceea că aria pre-metrică conform acesteia este reprezentată sub forma obiectelor care sunt conectate la așa-numitele clase. Fiecare obiect din clasă este dotat cu caracteristici sau metode pasive. Gestionarea obiectului este posibilă numai prin metode care se referă la acesta. Atributele unui obiect pot lua una dintre o varietate de valori valide și un set de valori specifice determină comportamentul obiectului. Un set de obiecte cu aceeași valoare a atributelor și metodelor definesc o clasă de obiecte.

Se pare că teoria unei baze de date orientate pe obiecte este similară cu organizarea oricărui limbaj de programare orientat pe obiect. Așa este. Orice clasă de obiecte poate fi moștenită dintr-o altă clasă și poate conține toate metodele sale împreună cu propria sa clasă. De asemenea, se respectă regula de încapsulare: este posibilă numai modificarea valorilor atributelor unui obiect cu ajutorul metodelor. În cele din urmă, polimorfismul este mecanismul de redefinire a metodelor pentru un obiect moștenit.

Principalul avantaj al OODB este că acest lucru permite pentru baza aspectului tac comportamental al obiectului, în contrast cu re-translațională SGBD, în care între structura și comportamentul este timpul-ryv. Cu toate acestea, pentru a implementa OODB, sunt necesare limbi de programare speciale, ceea ce complică foarte mult viața designerului :).

Pentru a preveni astfel de suprapuneri, s-au încercat să se îmbină DBMS orientat relațional și obiect. Este clar că acest lucru ar necesita extinderea standardelor și modernizarea limbajelor de programare existente. Astfel, companiile mari IBM și Oracle și-au finalizat DBMS prin adăugarea unei suprastructuri de obiecte peste nucleul relațional al sistemului.

Pentru fiecare model de bază de date, are propriul limbaj de control. Pentru un model relațional, această limbă este SQL (Language Structured Query, sau limbă de interogare structurată). Creatorii acestui limbaj au aspirat să-și aducă copilul mai aproape de limbajul uman (englez) și, în același timp, să-l umple cu un sens logic.

Limba SQL face mult mai ușor pentru cei care se ocupă în mod constant de bazele de date relaționale. Strict vorbind, fără un limbaj structurat pe care multe accidente ar trebui să Wee-SAT de program, de exemplu, în C. Imaginați-vă: la complet Rabo hoț în tabel, trebuie să creați mai întâi obiectul, tratamentul apoi Progr-zată pentru tratamente ei (eliminarea și adăugarea de rânduri ). Pentru a scăpa de hemoroizii, dezvoltatorii DBMS au avut grijă de crearea limbajului SQL.

Toate interogările SQL sunt foarte asemănătoare cu condițiile logice ale algebrei booleene (care nu au ignorat matematica, care mă vor înțelege :)). Veți vedea pentru dvs. dacă vă uitați la bara laterală cu comenzile principale ale limbii.

După cum am menționat deja, există și alte tipuri, cu excepția celor relaționale. În special, obiect orientat. Este normal ca astfel de baze de date să fie folosite pentru un alt limbaj de interogare.

În majoritatea bazelor de date orientate pe obiecte, există o interfață grafică simplă care permite utilizatorului să acceseze obiecte în stilul de navigare. Acest lucru ignoră principiul de încapsulare: nimeni nu vă va interzice să vedeți direct interiorul obiectelor. Dar, după cum spun experții, stilul de navigație în OODB este într-un sens un "pas înapoi" în comparație cu limbile de interogare din DBMS-urile relaționale. Și mu-chitelnye caută cele mai bune limba zap-rosov la OODB merge până acum.

Limbile de bază ale accesului la baze de date se bazează încă pe sintaxa SQL simplă și au un fel de extensie care se aplică obiectelor. Exemple de astfel de limbi sunt ORION, Iris și O2 Reloop.

După cum puteți vedea, niciun model relațional nu este renumit pentru baza de date a bazelor de date. În zilele noastre, dezvoltatorii încearcă să-și extindă produsele software prin diverse inovații, adăugând adaosuri orientate pe obiecte la motorul bazei de date relaționale existente. În plus, limbajul de interogare SQL este, de asemenea, modificat. În SQL3, există deja metode specifice existente pentru a lucra cu OODB-uri, dar implementarea lor până acum nu lasă mult de dorit.

Pentru nevoile persoanei obișnuite (adică voi), există suficient DBMS relațional, care este folosit peste tot. Este popular iubit de MySQL, și accesul mai puțin favorit, și MSSQL. Există o mulțime de astfel de sisteme de management, ați decis și alegeți unul care este mai mult pentru inima ta. Și face această alegere dificilă, ca întotdeauna, acest start unic SPECIAL va ajuta;).


Care sunt bazele de date? În cele mai multe cazuri, soluțiile programatorilor sunt limitate la două tipuri: server local și client. În primul caz, se obține șamponul "all-in-one". În al doilea rând, separăm datele și aplicația client și obținem două nivele.

Cu toate acestea, un al treilea nivel a fost deja identificat pentru o perioadă lungă de timp, iar modelul pe trei niveluri se află în plină desfășurare. fiind frică de complexitatea sa. În acest articol, vom examina fiecare model separat, cu toate avantajele și dezavantajele acestuia.







Articole similare

Trimiteți-le prietenilor: