Orientat pe obiecte
Modelul post-relațional
Avantajele și dezavantajele modelului de date relaționale
Principal demnitate model de date relaționale - este ușor de înțeles, vizual și are o justificare matematică strictă.
dezavantaje următoarele:
Modelul de date relaționale nu permite reprezentarea obiectelor cu o structură complexă, întrucât în cadrul acestuia este posibilă modelarea doar folosind tabele bidimensionale;
· datele despre obiecte sunt cuprinse, de regulă, în multe tabele. În consecință, extragerea informațiilor despre fiecare astfel de obiect necesită efectuarea multor operațiuni de îmbinare folosind chei primare și externe, ceea ce încetinește semnificativ procesarea datelor.
Recent, modele precum post-relațional, orientat pe obiecte, obiect-relațional și multidimensional modele.
Post-relațional modelul de date în cazul general este un model relațional extins care înlătură restricția indivizibilității valorilor câmpului.
Adică, sunt permise câmpuri cu mai multe valori, ale căror valori constau în subvalori. Un exemplu de model postrelațional este un tabel care este o colecție de date din tabelele relaționale conexe CLIENȚI și COMENZI.
Avantaje model de date post-relaționale:
· posibilitatea de a reprezenta tabele relaționale înrudite printr-un singur tabel post-relațional. Acest lucru asigură o vizibilitate ridicată a prezentării datelor și crește eficiența prelucrării acestora;
· nu există restricții privind lungimea câmpurilor și numărul acestora în înregistrările tabelului.
Defect model post-relațional – dificultatea de a asigura integritatea datelor.
Modelele orientate pe obiect și relaționale sunt folosite pentru a depăși dizabilități model relațional pentru stocare și procesare obiecte complexe cum ar fi, de exemplu, document, sunet, video, imagine grafică si etc.
Model orientat pe obiecte reprezintă o structură care poate fi reprezentată grafic ca un arbore ale cărui noduri sunt obiecte.
Fiecare obiect este unic identificator, stare și comportament. Stat obiectul este definit de setul de valori ale atributelor sale. Comportament obiect descrie metode numite proceduri. Adică, o parte integrantă a descrierii obiectului sunt procedurile care pot efectua acțiuni asupra atributelor obiectului în cazul apariției anumitor evenimente. .
Obiectele pot fi combinate în clase . Instanțele aceleiași clase diferă doar în valorile proprietăților lor, dar nu și în metodele lor. Metodele sunt setate atunci când clasa este definită.
Pentru a efectua acțiuni asupra obiectelor, se folosesc mecanisme orientate pe obiecte - moștenire, încapsulare, polimorfism.
esență moştenire este că, pe baza unei clase existente, puteți forma o nouă clasă de obiecte care vor moșteni proprietățile clasei părinte.
Accesul la date se realizează numai în conformitate cu regulile de comportament ale obiectului, descrise prin metodele ( încapsulare ).
Polimorfismul – capacitatea obiectelor de a răspunde diferit la același eveniment din lumea înconjurătoare. Polimorfismul este folosit pentru a unifica procesarea obiectelor diferite. De exemplu, metoda Print Result poate fi definită pentru multe clase de obiecte, dar funcționează diferit în funcție de clasa la care este aplicată.
Principal demnitate OOMD este capacitatea de a afișa informații despre obiecte complexe cu o descriere exhaustivă a relațiilor dintre ele și comportamentul lor dinamic.Acest model este de obicei utilizat pentru domenii complexe, a căror modelare nu are funcționalitatea modelului relațional (de exemplu, sisteme de automatizare a proiectării, sisteme de publicare etc.).
Defect OOMD este complexitatea aparatului conceptual, care complică aplicarea acestuia și afectează negativ acumularea de experiență în crearea și funcționarea bazelor de date orientate pe obiecte.
Model de date relaționale obiect este un model hibrid care combină capacitățile modelului relațional cu proprietățile obiectului datelor.
1. Obiecte vizibile pe interfata externa, sunt mapate la tabele din baza de date relațională subiacentă. În schimb, obiectele sunt preluate din reprezentarea lor într-un mediu de stocare tabelar atunci când sunt solicitate de utilizatori sau aplicații. (abordare hibridă).
Această abordare a fost populară la sfârșitul anilor 1980. și întruchipată în produse software pentru automatizarea programării (CASE), pentru automatizarea proiectării (CAD), în depozite (baze de date concepute pentru a stoca nu datele utilizatorului, ci ale sistemului).
2. Mecanismele relaționale interne ale SGBD-ului de gestionare a datelor sunt extinse cu capabilități orientate pe obiecte ( abordare relațională extinsă).
Această abordare este mai avansată din punct de vedere tehnologic și este preferată în prezent de majoritatea dezvoltatorilor RDBMS. El a fost întruchipat în 1996-1997. într-un număr de servere de baze de date obiect-relaționale.
Caracteristica distinctivă a modelului obiect-relațional din OOMD este că se bazează pe strategia modelului relațional. Includerea obiectelor în modelul relațional poate fi discutată în această etapă doar ca o direcție generală în dezvoltarea bazelor de date.
DBMS cu un nivel mult mai ridicat de complexitate. Încearcă să salveze programatorul de la efectuarea operațiunilor de rutină de gestionare a datelor care sunt atât de caracteristice modelelor ierarhice și de rețea.În modelul relațional, o bază de date este un depozit centralizat de tabele care oferă acces sigur, simultan la informații de către mulți utilizatori. În rândurile de tabele, unele câmpuri conțin date legate direct de înregistrare, iar unele conțin link-uri către înregistrările din alte tabele. Astfel, relațiile dintre înregistrări sunt o proprietate esențială a modelului relațional.
Fiecare intrare de tabel are aceeași structură. De exemplu, într-un tabel care conține descrieri de vehicule, toate înregistrările vor avea același set de câmpuri: producător, model, an, kilometraj și așa mai departe. Astfel de tabele sunt ușor de reprezentat grafic.
Modelul relațional realizează independență informațională și structurală. Înregistrările nu sunt suficient de legate încât schimbarea uneia dintre ele să le afecteze pe celelalte, iar modificarea structurii bazei de date nu duce neapărat la recompilarea aplicațiilor care lucrează cu aceasta.
În SGBD relațional se folosește limbajul SQL, care face posibilă formularea de interogări arbitrare, ad-hoc. Este o limbă de a patra generație, astfel încât orice utilizator poate învăța rapid cum să scrie interogări. În plus, există multe aplicații care vă permit să construiți scheme de interogare logice într-o formă grafică. Toate acestea se întâmplă din cauza înăspririi cerințelor pentru performanța computerelor. Din fericire, modern putere de calcul mai mult decât adecvată.
Baze de date relaționale suferă de diferențe în implementarea limbajului SQL, deși aceasta nu este o problemă a modelului relațional. Fiecare SGBD relațional implementează un subset al standardului SQL plus un set de comenzi unice, ceea ce face dificilă pentru programatori care încearcă să migreze de la un SGBD la altul. Trebuie să faci o alegere dificilă între portabilitate maximă și performanță maximă. În primul caz, trebuie să respectați setul minim comun de comenzi acceptate în fiecare SGBD. În al doilea caz, programatorul se concentrează pur și simplu pe lucrul în acest DBMS special, profitând de comenzile și funcțiile sale unice.
MySQL este un SGBD relațional, iar acest tutorial este despre modelul relațional. Dar teoria bazelor de date nu stă pe loc. Apar noi tehnologii care extind modelul relațional.
Baze de date orientate pe obiecte
Baza de date orientată pe obiecte (OODB) permite programatorilor care lucrează cu limbaje din a treia generație să interpreteze toate entitățile lor de informații ca obiecte stocate în memorie cu acces aleator. Un strat suplimentar de abstracție a interfeței oferă interceptarea cererilor care accesează acele părți ale bazei de date care se află în stocare permanentă pe disc. Modificările aduse obiectelor sunt transferate optim de pe memorie pe disc.
Avantajul OODB este codul simplificat. Aplicațiile sunt capabile să interpreteze datele în contextul limbajului de programare în care sunt scrise. O bază de date relațională returnează valorile tuturor câmpurilor sub formă de text, apoi sunt turnate în tipuri de date locale. În OOBD, această etapă este eliminată. Metodele de manipulare a datelor sunt întotdeauna aceleași, indiferent dacă datele sunt pe disc sau în memorie.
Datele din OODB pot lua forma oricărei structuri care poate fi exprimată în limbajul de programare utilizat. Relațiile dintre entități pot fi, de asemenea, arbitrar complexe. OODB gestionează memoria cache a obiectelor, mutând obiectele între buffer și stocarea pe disc, după cum este necesar.
OODB rezolvă două probleme. În primul rând, structurile informaționale complexe sunt exprimate în ele mai bine decât în bazele de date relaționale, iar în al doilea rând, nevoia de a traduce datele din formatul suportat de SGBD este eliminată. De exemplu, într-un SGBD relațional, dimensiunea numerelor întregi poate fi de 11 cifre, iar în limbajul de programare folosit poate fi de 16. Programatorul va trebui să țină cont de această situație.
SGBD-ul orientat pe obiecte realizează multe funcții suplimentare. Acest lucru dă roade dacă relațiile dintre date sunt foarte complexe. În acest caz, performanța OODB este mai mare decât cea a SGBD-ului relațional. Dacă datele sunt mai puțin complexe, funcții suplimentare se dovedesc a fi redundante. Interogările ad-hoc sunt acceptate în modelul obiect de date, dar limbajul lor nu este neapărat SQL. Este posibil ca reprezentarea logică a datelor să nu corespundă modelului relațional, astfel încât utilizarea limbajului SQL va deveni lipsită de sens. Este adesea mai convenabil să procesați obiecte din memorie prin efectuarea de căutări adecvate.
Un mare dezavantaj al bazelor de date orientate pe obiect este legătura lor strânsă cu limbajul de programare utilizat. Orice aplicație poate accesa date stocate într-un SGBD relațional, în timp ce, de exemplu, un obiect Java plasat într-un OODB va fi de interes doar pentru aplicațiile scrise în Java.
Baze de date relaționale obiect
SGBD-ul obiect-relațional combină caracteristicile modelelor relaționale și ale modelului obiect. Apariţia lor se explică prin faptul că baze de date relaționale funcționează bine cu tipurile de date încorporate și mult mai rău - cu cele definite de utilizator, nestandard. Când apare un nou tip de date importante, trebuie fie să includeți suport pentru acesta în DBMS, fie să forțați programatorul să gestioneze el însuși datele din aplicație.
Nu toate informațiile au sens să fie interpretate ca șiruri de caractere sau numere. Imaginați-vă o bază de date muzicală. Un cântec codificat ca fișier audio poate fi plasat într-un câmp de text marime mare, dar cum ar fi efectuată o căutare text în acest caz?
Reconstruirea unui SGBD pentru a include suport pentru un nou tip de date nu este cea mai bună cale de ieșire. În schimb, un SGBD cu relații obiect vă permite să încărcați cod conceput pentru a procesa date „atipice”. Astfel, baza de date își păstrează structura tabulară, dar modul în care sunt tratate anumite câmpuri ale tabelelor este determinat extern, adică. programator.
În prezent, SGBD-urile relaționale domină printre sistemele de management al datelor. Avantajele unei abordări orientate pe obiecte pentru crearea de aplicații specializate complexe, pe de o parte, și dorința dezvoltatorilor de sisteme de gestionare a bazelor de date, pe de altă parte, de a extinde limitele de aplicare a SGBD-ului corespunzător au condus la includerea componentelor orientate pe obiect (sistem de tip extensibil de utilizator, încapsulare, moștenire, polimorfism etc.) în modelul de date al unui SGBD relațional. SGBD corespondent, numit obiect-relațional , uniți cele mai bune calități baze de date relaționale și orientate pe obiecte. Rețineți că diferite SGBD implementează un set diferit de componente orientate pe obiecte enumerate. Astfel, nu există un model obiect-relațional general acceptat, ci mai degrabă există mai multe astfel de modele care suportă un anumit set de componente orientate pe obiect. Cu toate acestea, tabelele relaționale stau la baza tuturor astfel de modele, este folosit un limbaj de interogare, este inclus conceptul de obiect, iar unele implementează suplimentar capacitatea de a salva metode în baza de date.
Schimbările corespunzătoare în modelul relațional au necesitat extinderea standardului lingvistic interogări SQL. Prima versiune a acestui standard a fost numită SQL3. Lucrările la standard sunt încă în desfășurare.
Un exemplu de SGBD orientat pe obiecte în măsura maximă este SGBD de cercetare Postgres(3).
Să notăm elementele SGBD-ului Microsoft Server 2008 care sunt considerate extensii de obiecte.
· Extensii personalizate. Utilizatorii au capacitatea de a interfera cu setul de instrumente furnizat inițial de DBMS, creând, în special, noi tipuri de date definite de utilizator.
· Stocarea unor cantitati mari de date. Alături de datele care erau în mod tradițional stocate în baza de date, Microsoft SQL Server 2008 vă permite să stocați date mari în coloanele tabelului (sunt acceptate tipurile de date corespunzătoare).
· Noi tipuri de date specifice obiectului. Sistemul definește noi tipuri de date (geometrie, geografie), care sunt tipice pentru acele domenii în care abordarea orientată pe obiect este foarte eficientă și des folosită (cartografie și aplicații conexe, reprezentarea geometrică a obiectelor de natură foarte diferită).
· Stocat proceduri . Într-un anumit sens, procedurile stocate sunt, de asemenea, o extensie a obiectului, efectuând acțiunile necesare utilizatorului asupra datelor (o abordare procedurală care este standard pentru OOP).
2. Baze de date distribuite
O bază de date este o colecție integrată de date cu care lucrează mulți utilizatori. Prezentarea tuturor secțiunilor anterioare presupunea o singură bază de date găzduită pe un singur computer. Amintiți-vă principiile de bază care stau la baza teoriei bazelor de date:
stocare centralizată a datelor;
· întreținerea centralizată a datelor (intrare, corectare, citire, control al integrității).
Rețineți că bazele de date au apărut în perioada de dominare a mainframe-urilor. Baza de date a fost menținută pe un singur computer, toți utilizatorii au lucrat pe computer (modurile posibile de funcționare sunt descrise în prelegerea 3). Alte opțiuni pentru utilizarea tehnologiei informatice la acea vreme pur și simplu nu existau. Dacă analizăm munca utilizatorilor cu date în companii, organizații, întreprinderi în perioada „pre-computer”, este ușor de observat că în unele zone utilizatorii lucrau cu datele „lor” (colectau anumite date, stocau, procesau, transferau date prelucrate către alte domenii).sau niveluri de management).
Această tehnologie a avut dezavantaje semnificative, care au fost deja remarcate în secțiunile anterioare: duplicarea unor date, lipsa posibilității unei analize comparative a datelor de pe toate site-urile. Cu toate acestea, această tehnologie a avut și avantaje semnificative: datele au fost introduse și stocate în locurile de generare a acestora; un utilizator care este un specialist în aceste date anume a lucrat cu aceste date, ceea ce i-a permis să controleze în mod eficient corectitudinea datelor în toate etapele prelucrării; datele au fost localizate direct la utilizator, ceea ce a făcut posibilă prelucrarea lor cu promptitudine. Centralizarea datelor pe un singur computer, care oferă fără îndoială posibilități eficiente de stocare și prelucrare a datelor, nu a permis implementarea avantajelor de mai sus.
Dezvoltarea calculatoarelor retele de calculatoare a condus la noi oportunități în organizarea și întreținerea bazelor de date, permițând fiecărui utilizator să aibă propriile date pe computerul său și să lucreze cu acestea, permițând în același timp tuturor utilizatorilor să lucreze cu întregul set de date ca o singură bază de date centralizată. Colectarea corespunzătoare de date se numește bază de date distribuită.
Termenul " baza de date distribuita' este destul de comun în literatură. Cu toate acestea, în surse diferite Acest termen înseamnă lucruri complet diferite. Unii autori înțeleg printr-o bază de date distribuită că există un server la distanță pe care se află datele, precum și computere client situate geografic într-un loc diferit. Această interpretare ni se pare incorectă. real baza de date distribuita rezidă pe mai multe computere. În acest caz, unele fișiere se află pe un computer, altele pe altul și așa mai departe. Mai mult, este posibil și chiar adesea există o situație în care informațiile de pe aceste computere se suprapun și sunt duplicate.
O bază de date distribuită este un set de date partajate interconectate logic (și descrierile structurilor acestora) distribuite fizic într-o rețea de calculatoare.
Model de date orientat pe obiecte
Modelul de date orientat pe obiect este o extensie a prevederilor programării orientate pe obiect (în timp ce modelul relațional a luat naștere pe baza teoriei mulțimilor, și anume ca model de date). Object DataBase Management Group a dezvoltat standardul ODMG-93 (Object DataBase Management Group). Acest standard nu a fost încă implementat pe deplin.
Structura unei baze de date orientate pe obiecte este reprezentată grafic ca un arbore, ale cărui noduri sunt obiecte. Structura vizibilă a unui obiect este determinată de proprietățile clasei sale. Clasă include obiecte, în timp ce structura și comportamentul obiectelor din aceeași clasă sunt aceleași. Fiecare obiect, și anume o instanță a unei clase, este considerat un descendent al obiectului în care este definit ca proprietate. Proprietățile obiectului- sau tip standard, cum ar fi șir de caractere sau un tip de clasă construit de utilizator. Comportamentul obiectelor este stabilit prin metode. Metodă este o operație care poate fi aplicată unui obiect.
Ca exemplu, luați în considerare baza de date „BIBLIOTECĂ” (Fig. 4.4). Proprietățile, tipurile și valorile acestora sunt definite pentru fiecare obiect. În DB:
„BIBLIOTECĂ” - părinte (strămoș) pentru „SUBSCRIPTION”, „CATALOG”, „RELEASE”;
„CATALOG” este părintele pentru „CARTE”.
„CARTE” – obiecte diferite pot avea aceiași părinți sau diferiți. Dacă același părinte (un autor), atunci numerele de inventar sunt diferite, dar isbn, UDC, titlul și autorul sunt aceleași.
Structura logică a unei baze de date orientate pe obiecte este similară cu una ierarhică, principala diferență este în metodele de manipulare a datelor. Pe baza de date, puteți efectua acțiuni precum operații logice, îmbunătățite prin metode orientate pe obiect de încapsulare, moștenire și polimorfism.
Încapsulare limitează domeniul de aplicare al unui nume de proprietate la obiectul în care este definit. Deci, dacă proprietatea este adăugată la „CATALOG” telefon autorul cărții, apoi se obțin în mod similar în „ABONAMENT” și „CATALOG”. Semnificația proprietății va fi determinată de obiectul în care este încapsulată.
Moştenire, dimpotrivă, extinde domeniul de aplicare al proprietății la toți descendenții obiectului. Deci, tuturor obiectelor de tip „CARTE”, care sunt descendenți ai „CATALOG”, li se pot atribui proprietățile isbn părinte, UDC, titlul și autorul.
Poliformismulînseamnă capacitatea aceluiași codul programului lucrează cu diferite tipuri de date. Cu alte cuvinte, înseamnă admisibilitate în obiecte tipuri diferite au metode - proceduri și funcții - cu același nume. În timpul execuției unui program obiect, aceleași metode operează pe obiecte diferite în funcție de tipul argumentului. Pentru baza de date „BIBLIOTECĂ”, aceasta înseamnă că obiectele clasei „CARTE” care au părinți diferiți de clasa „CATALOG” pot avea un set diferit de proprietăți, adică. programele de lucru cu un obiect din clasa „CARTE” pot conține cod polimorf. În clasă, metoda nu are un corp, adică nu este definit ce acțiuni specifice ar trebui să efectueze. Fiecare subclasă efectuează operațiile necesare. Încapsularea ascunde detaliile de implementare de la toate obiectele din afara ierarhiei date.
Avantajele unui model orientat pe obiecte în comparație cu unul relațional sunt capacitatea de a afișa informații despre relațiile complexe ale obiectelor, absența limitărilor în structurile de stocare a datelor. O bază de date orientată pe obiecte poate stoca nu numai structura, ci și aspectele comportamentale ale datelor. Folosind abordarea orientată pe obiect, se pot crea și baze de date cu cantități mari de informații semantice, cum ar fi baze de date multimedia și baze de date specializate pentru domenii specifice (geografice, design etc.).
Dezavantajele acestei abordări includ complexitatea conceptuală ridicată, inconvenientul procesării datelor și viteza scăzută de execuție a interogărilor.
În anii 1990, au fost create prototipuri ale bazelor de date orientate pe obiecte existente. Aceștia sunt POET (POET Software), JASMINE (ASOCIAȚI DE CALCULATOR), IRIS, ORION, POSTGRES.
Tema 5
Abordarea relaţională în construirea unui model informaţional-logic: concepte de bază
Model de date relaționale. Noțiuni de bază
După cum sa menționat în secțiunea prelegerii anterioare, modelul relațional este în prezent unul dintre cele mai comune modele de pe piața bazelor de date. Baza acestui model este un set de tabele (relații) interdependente.
Principalele idei teoretice ale modelului relațional au fost conturate în lucrările de teorie relațională ale logicianului american Charles Souders Peirce (1839-1914) și ale logicianului german Ernst Schroeder (1841-1902), precum și ale matematicianului american Edgar Codd.
În lucrările lui Pierce și Schroeder s-a dovedit că setul de relații este închis sub niște operații speciale care formează împreună o algebră abstractă. Această proprietate esențială a relațiilor a fost folosită în modelul relațional pentru a dezvolta un limbaj de manipulare a datelor.
În 1970 a apărut un articol al lui E. Codd despre prezentarea datelor organizate sub formă de tabele bidimensionale, numite relații. Codd a introdus mai întâi conceptele de bază și limitările modelului relațional ca bază pentru stocarea datelor și a arătat posibilitatea procesării datelor folosind operații tradiționale pe seturi și operații relaționale speciale introduse.
Conceptele de bază ale modelului relațional sunt prezentate în tabel. 3.1.
Obiectele modelului relațional sunt în principal tabele (relații). Integritatea datelor este asigurată de chei străine și primare (vezi Secțiunea „Integritatea datelor relaționale”).
Operatorii din modelul relațional sunt un set de instrucțiuni care asigură preluarea și manipularea datelor.
Tabelul 5.1. Elemente ale modelului relațional
| Termen model relațional | Descriere |
| Baza de date (DB) | Un set de tabele și alte obiecte necesare pentru reprezentarea abstractă a celor selectați domeniul subiectului |
| Schema DB | Un set de anteturi de tabel legate între ele |
| Atitudine | Tabel - un set de obiecte din lumea reală care sunt caracterizate prin proprietăți și caracteristici comune (câmpuri de tabel) |
| Antetul relației | Antet tabel - numele câmpurilor (coloanelor) din tabel |
| Organul de relație | Corpul tabelului este un set de valori pentru toate obiectele din lumea reală, care este reprezentat ca intrări în tabel (rânduri de tabel) |
| schema de relatii | Rând antet coloană tabel (antet tabel) |
| atribut de relație | Numele coloanei tabelului (câmpul tabelului) |
| relație tuplu | Rând tabel (înregistrare) – o reprezentare unu-la-unu a unui obiect din lumea reală creată folosind valorile câmpului tabelului |
| Domeniu | Setul de valori de atribute valide |
| Valoarea atributului | Valoarea câmpului din înregistrare (tuplu) |
| cheia principala | Unul sau mai multe (în cazul unei chei compuse) atribute care definesc în mod unic valoarea tuplului (valoarea rândului tabelului) |
| Cheie externă | Un atribut al unui tabel ale cărui valori corespund cu valorile unei chei primare dintr-un alt tabel înrudit (părinte, primar). O cheie externă poate consta din unul sau mai multe atribute (cheie externă compusă). Dacă numărul de atribute ale cheii străine este mai mic decât numărul de atribute ale cheii primare corespunzătoare, atunci se numește cheie străină trunchiată (parțială). |
| Gradul (aritatea) relației | Numărul de coloane din tabel |
| Puterea relațională | Numărul de rânduri (tupluri) din tabel |
| Instanță de relație | Un set de înregistrări (tupluri) pentru un anumit tabel (relație). O instanță se poate schimba în timp. Deoarece o bază de date obișnuită la momentul actual funcționează cu o singură versiune a relației, o astfel de instanță a relației se numește cea curentă. |
| Tip de date | Tipul valorii elementului de tabel |
| Raportul de bază | Relație care conține una sau mai multe coloane care caracterizează proprietățile obiectului, precum și o cheie primară |
| Relație derivată | Nu este o relație de bază, adică nu caracterizează proprietățile obiectului și este folosit pentru a oferi legături între alte tabele, nu poate conține o cheie primară. Dacă este specificată o cheie primară, atunci aceasta constă din chei străine legate de cheile primare ale relației de bază |
| Conexiune | Stabilește o relație între valorile de potrivire în câmpurile cheie - cheia primară a unui tabel și cheia externă a altuia |
| Comunicare unu-la-unu (1:1) | Când se utilizează acest tip de relație, o intrare dintr-un tabel poate avea cel mult o intrare asociată într-un alt tabel. În ambele tabele, câmpurile cheie trebuie să fie primare. Folosit pentru a separa tabele cu mai multe câmpuri sau pentru cerințele de protecție a datelor |
| Relație unu-la-mulți (1:M) | Când se utilizează acest tip de relație, fiecare înregistrare a unui tabel poate corespunde mai multor înregistrări a celui de-al doilea, dar fiecare înregistrare a celui de-al doilea tabel corespunde doar unei înregistrări a primului tabel. Primul tabel trebuie să aibă o cheie primară, al doilea trebuie să aibă o cheie străină. |
| Relație multi-la-mulți (N:M) | Cu acest tip de relație, o înregistrare din primul tabel poate corespunde mai multor înregistrări ale celui de-al doilea tabel, dar o înregistrare din cel de-al doilea tabel poate corespunde mai multor înregistrări ale primului. Nu este necesară unicitatea cheilor pentru astfel de tabele. În procesul de proiectare a unei scheme de bază de date, astfel de legături sunt transformate. Pentru a face acest lucru, trebuie să introduceți o relație auxiliară care vă permite să înlocuiți relația multi-la-mulți cu două relații unu-la-mulți |
Structura de date a modelului relațional presupune reprezentarea domeniului subiect al problemei luate în considerare ca un set de relații interdependente.
În fiecare relație, o relație poate acționa ca principală (bază, părinte), iar cealaltă ca subordonată (derivată, copil). Pentru a menține aceste legături, ambele relații trebuie să conțină un set de atribute prin care sunt legate: în relația principală, aceasta este cheia primară a relației (identifică în mod unic tuplul relației principale); relația copil trebuie să aibă un set de atribute corespunzătoare cheii primare a relației principale. Aici, acest set de atribute este deja o cheie secundară sau o cheie străină, adică definește un set de tupluri de relații derivate asociate cu un singur tuplu al relației de bază.
Se formează un set de tabele interconectate schema bazei de date.
Deci relația R este un tabel bidimensional care conține unele date.
Din punct de vedere matematic N relație -ariană R este mulţimea produsului cartezian D 1×D 2×…×Dn seturi (domenii) D 1 , D 2 ,…,D n(n≥1), opțional diferite:
R D 1×D 2×…×Dn,
Unde D 1×D 2×…×Dn este produsul cartezian complet, i.e. un set de combinații posibile de n elemente fiecare, unde fiecare element este luat din domeniul său.
Domeniu este un concept semantic care poate fi gândit ca un subset de valori ale unor tipuri de date care au o semnificație specifică.
Proprietățile domeniului:
Domeniul are un nume unic (în baza de date),
Definit pe unele tip simplu date sau pe alt domeniu,
Poate avea o condiție booleană pentru a descrie subsetul de date permis pentru acel domeniu,
Poartă o anumită încărcătură semantică.
Valoarea principală a domeniilor este că restricționează comparațiile: nu poți compara valori din domenii diferite, chiar dacă au același tip de date.
Atribut relația este o pereche de formă
<Имя_атрибута: Имя_домена>(sau<ANUNȚ>).
Numele atributelor dintr-o relație sunt unice. Adesea, numele atributelor sunt aceleași cu numele de domenii corespunzătoare.
O relație R definită pe un set de domenii conține două părți: un antet și un corp.
Antetul relației– un număr fix de atribute de relație care descriu produsul cartezian al domeniilor pe care este specificată relația:
(<A1: D1>, <A2: D2 >, …, <Si n>).
Antetul este static: nu se modifică în timpul lucrului cu baza de date.Dacă atributele sunt modificate, adăugate sau șterse în relație, atunci se obține o altă relație. Chiar și cu numele salvat.
Corp relația conține un set de tupluri de relație.
Fiecare tuplu este un set de perechi de forma:
<Имя_атрибута: Значение атрибута>:
R(<A1:Val1>, <A2:Val2 >, …, <A n: Val n>).
Astfel încât valoarea Val i atribut Ai aparține domeniului D i.
Corpul relației este un set de tupluri, adică o submulțime a produsului cartezian al domeniilor. Astfel, corpul relației este de fapt o relație în sensul matematic al cuvântului. Corpul relației se poate schimba în timpul lucrului cu baza de date, deoarece tuplurile se pot modifica, pot fi adăugate și eliminate în timp.
Relația este de obicei scrisă astfel:
R(<A1: D1>, <A2: D2 >, …, <Si n>),
sau prescurtat: R(A 1, A2, …, A n) sau R.
schema de relatii este un set de anteturi de relații incluse în baza de date, adică o listă de nume de atribute ale unei relații date, indicând domeniul la care se referă:
S R =(A 1, A2, …, A n), A i D i, i = 1,...,n.
Dacă atributele iau valori din același domeniu, atunci ele sunt numite θ-comparabile, unde θ este setul de comparații valide specificate pentru acest domeniu.
De exemplu, dacă domeniul conține date numerice, atunci toate operațiunile de comparare sunt permise pentru acesta: θ == (=,<>,>=,<=,<,>). Cu toate acestea, pentru domeniile care conțin date de caractere, nu pot fi specificate numai operațiuni de comparare pentru egalitatea și inegalitatea valorilor. Dacă unui anumit domeniu i se oferă o ordonare lexicografică, atunci are și un set complet de operații de comparare.
Se numesc scheme a două relații echivalent, dacă au același grad și este posibil să se aranjeze numele atributelor în scheme astfel încât atributele comparabile, adică atributele care preiau valori din același domeniu, să fie în aceleași locuri.
Astfel, pentru relațiile echivalente sunt îndeplinite următoarele condiții:
Avand acelasi numar de atribute;
Prezența atributelor cu aceleași nume;
Prezența șirurilor identice în relații, ținând cont de faptul că ordinea atributelor poate varia;
Relațiile de acest fel sunt reprezentări diferite ale aceleiași relații.
Proprietățile relației rezultă direct din definiția de mai sus a unei relații. Aceste proprietăți sunt principalele diferențe dintre relațiile modelelor de date relaționale și tabelele simple:
Unicitatea numelui relației. Numele unei relații trebuie să fie diferit de numele altor relații.
Unicitatea tuplurilor. Nu există tupluri identice în relație. Într-adevăr, corpul relației este un set de tupluri și, ca orice mulțime, nu poate conține elemente care nu se pot distinge. Tabelele, spre deosebire de relații, pot conține rânduri identice. Fiecare celulă de relație conține doar o valoare atomică (indivizibilă).
Tulburarea tuplilor. Tuplurile nu sunt ordonate (de sus în jos), deoarece corpul relației este o mulțime, iar mulțimea nu este ordonată (pentru comparație, rândurile din tabele sunt ordonate). Aceeași relație poate fi reprezentată prin tabele diferite cu rânduri în ordine diferită.
Tulburare de atribute. Atributele nu sunt ordonate (de la stânga la dreapta).
Unicitatea numelui atributului în cadrul relației. Fiecare atribut are un nume unic în cadrul relației, ceea ce înseamnă că ordinea atributelor nu contează (pentru comparație, coloanele din tabel sunt ordonate). Această proprietate distinge oarecum o relație de definiția matematică a unei relații. Aceeași relație poate fi reprezentată prin tabele diferite în care coloanele sunt într-o ordine diferită.
Atomicitatea valorilor atributelor. Toate valorile atributelor sunt atomice. Acest lucru rezultă din faptul că atributele de bază au valori atomice, adică un domeniu de valoare (un tip elementar separat) este asociat cu fiecare tribut, valorile atributelor sunt preluate din același domeniu. Schema și tuplurile relației sunt mulțimi, nu liste, deci ordinea în care sunt prezentate nu contează. Pentru comparație - în celulele tabelului pot fi plasate diverse informații: matrice, structuri, alte tabele etc.
Cometariu:
Din proprietăţile relaţiei rezultă că nu fiecare tabelul poate fi o relație. Pentru ca un anumit tabel să definească o relație, este necesar ca tabelul să aibă o structură simplă (conține doar rânduri și coloane, iar fiecare rând trebuie să aibă același număr de câmpuri), tabelul să nu aibă aceleași rânduri, orice coloana tabelului trebuie să conțină date de un singur tip, toate tipurile de date utilizate trebuie să fie simple.
Trebuie remarcat faptul că modelul relațional este o bază de date sub forma unui set de relații interdependente, care se numesc schema bazei de date relaționale.
12 mai 2010 la 14:04Baze de date relaționale vs baze de date orientate pe obiecte
- Dezvoltare site
Din păcate, nu am găsit suficiente stoluri interesante despre bazele de date orientate pe obiecte (OODB) pe Habré. Aș dori să ridic acest subiect, pentru că. S-a vorbit din ce în ce mai mult despre OODB în ultima vreme. Cu toate acestea, nu va fi posibil să puneți toate informațiile într-un singur articol, așa că voi oferi o mică prezentare generală și gândurile mele despre acest subiect pentru început. În acest articol, nu voi lua în considerare soluții specifice bazate pe fiecare dintre tehnologii, ci voi încerca doar să compar tehnologiile în sine.
fundal
Proiectez și dezvolt baze de date de aproximativ 6 ani. În acest timp, mi-am dezvoltat propria viziune despre cum să abordez cel mai bine proiectarea, cum să aleg arhitectura sistemului, care sunt caracteristicile în normalizarea și denormalizarea bazelor de date relaționale, cum să optimizez anumite structuri și interogări. În primul an de muncă, am ajuns la concluzia că nu vreau să mă ocup de rutina de a scrie aceleași interogări. Drept urmare, am scris propriul meu generator de proceduri stocate, care, conform structurii bazei de date, a generat majoritatea interogărilor de rutină (dacă este interesant, pot scrie un articol pe acest subiect). Apoi acest generator a evoluat de la an la an și, drept urmare, am ajuns la nevoia de a stoca obiectele așa cum sunt, pentru a nu deranja translatarea modelului obiect într-o structură relațională. Acestea. de fapt, am ajuns la generarea unui fel de supliment ORM. Desigur, puteți spune că au fost deja create un număr suficient de suplimente ORM de înaltă calitate și baze de date obiect-relaționale care pot fi utilizate cu succes (și sunt de acord cu dvs., dar cu unele rezerve). Dar nici asta nu mi s-a potrivit. Și am decis să merg mai departe.Influența ORM
În opinia mea umilă, utilizarea suplimentelor ORM nu face decât să încetinească dezvoltarea OODB. Voi încerca să explic această afirmație destul de controversată. Nu cred că ORM este rău, dar nici nu este un bine absolut. Tehnologia ORM a jucat, fără îndoială, (și joacă încă) un rol important în dezvoltarea instrumentelor de dezvoltare, a arătat că programatorului de fapt nu trebuie să-i pese de logica de stocare a datelor. Totuși, aici, ca și în altă parte, există „DAR”.Utilizarea ORM accelerează fără îndoială dezvoltarea produsului, reduce costurile cu forța de muncă și bla bla bla. Cu toate acestea, orice ORM este un fel de strat care va funcționa întotdeauna mai lent decât munca directă (nu cer deloc transferul tuturor apelurilor de interogare SQL către aplicație - ar trebui să existe un mijloc de aur peste tot). Prezența ORM permite dezvoltatorilor să nu se gândească prea mult la funcționarea DBMS (și nu se gândesc în cea mai mare parte), ceea ce presupune, ca să spunem ușor, funcționarea nu tocmai optimă a aplicației sub sarcină. Pentru a optimiza, trebuie să intri în strat cu mâinile și să configurezi interogări astfel încât acestea să înceapă să funcționeze mai repede, trebuie să intri în baza de date și să reconfigurezi indecșii și tabelele. Astfel, pentru funcționarea optimă a aplicației, trebuie depus mai mult efort decât atunci când ORM-ul nu este prezent. Drept urmare, reducem costurile de dezvoltare și grăbim lansarea primei versiuni a produsului, dar complicăm procesul de optimizare.
Cu toate acestea, nimeni nu se gândește la optimizare în momentul scrierii primei (și adesea a doua și a treia) versiune a produsului. Pentru majoritatea companiilor, principalul factor acum nu este calitatea, ci viteza de dezvoltare. Este de înțeles: inițial, clientul dorește să primească produsul cât mai devreme, cheltuind un minim de bani. Și numai după un timp, când baza de date este umplută cu date reale, trec câteva luni, clientul (și dezvoltatorul) este surprins să constate că timpul de eșantionare aproape s-a dublat, când 10-20 de utilizatori lucrează la în același timp, DBMS încearcă să se sinucidă etc. etc. Dezvoltatorul este adesea ghidat de înțelepciunea orientală: Și acolo, ori va muri măgarul, ori sultanul, ori Khoja însuși. Dar, dacă nimeni nu a murit, atunci dezvoltatorul începe să caute blocaje, smulge interogările generate automat din ORM, le rescrie manual, reconstruiește indecși în tabelele bazei de date și alocă mult timp și efort pentru asta și altele. optimizare.
Ceva m-a tras în lateral. Sper că mi-am făcut poziția cu privire la ORM suficient de clară. Să revenim la comparația (sau, dacă doriți, la opoziția) bazelor de date relaționale și orientate pe obiecte.
Baze de date relaționale vs OODB
În ciuda popularității uriașe a paradigmei OOP în programare, această paradigmă nu este încă foarte populară în tehnologia de dezvoltare a bazelor de date. Există motive atât obiective, cât și subiective pentru aceasta.- Popularitate. Multe produse minunate au fost create pentru baze de date relaționale care trebuie întreținute și dezvoltate. S-au investit deja mulți bani în aceste produse și clienții sunt gata să investească mai mulți bani în dezvoltarea lor. Dimpotrivă, relativ puține produse comerciale serioase au fost dezvoltate folosind OODB, există puține OODBMS puternice.
- Limbajul de interogare și standardizarea acestuia.În 1986, a fost adoptat primul standard SQL-86, care a determinat soarta bazelor de date relaționale. După adoptarea standardului, toți dezvoltatorii de SGBD relaționali au fost obligați să-l urmeze. Pentru bazele de date orientate pe obiecte, nu există încă un limbaj standard de interogare. În acest moment, nici măcar nu există un consens în rândul dezvoltatorilor cu privire la ceea ce ar trebui să facă acest limbaj de interogare, cu atât mai puțin despre cum ar trebui să o facă.
- Aparat matematic. Pentru bazele de date relaționale, la un moment dat, Edgar Codd a pus bazele aparatului matematic al algebrei relaționale. Acest covoraș. aparatul explică modul în care trebuie efectuate operațiunile de bază asupra relațiilor din baza de date, dovedește optimitatea acestora (sau arată unde este necesară optimizarea). Pe de altă parte, nu există un astfel de aparat pentru OODB, chiar dacă lucrările în acest domeniu au fost în desfășurare încă din anii 80. Astfel, nu există încă termeni stricti în OODB, cum ar fi produsul cartezian, relația etc.
- Problema stocării datelor și metodelor. Bazele de date relaționale stochează doar date simple. Ce va face aplicația cu ele depinde de aplicație. În OODB, dimpotrivă, obiectele ar trebui să fie stocate, iar un obiect este o colecție de proprietăți (parametrii obiectului) și metodele (interfața obiectului). De asemenea, nu există un consens asupra modului în care OODB ar trebui să stocheze obiecte și asupra modului în care un dezvoltator ar trebui să dezvolte și să proiecteze aceste obiecte. Aici se pune și problema stocării ierarhiei obiectelor, stocării claselor abstracte etc.
Concluzii și perspective
În lumina situației actuale din lumea dezvoltării, perspectiva unor soluții serioase și populare folosind OODB pare foarte îndoielnică (dar nu mai puțin dezirabilă) până când problemele fundamentale sunt rezolvate (aparatul mat și standardul limbajului de interogare). Ca dezvoltator, acest lucru mă întristează oarecum, deoarece am ajuns la concluzia că prezența unui OODB puternic și convenabil este pur și simplu necesară pentru dezvoltarea calitativă ulterioară a instrumentelor de dezvoltare a bazelor de date.În ceea ce privește perspectivele pentru bazele de date relaționale, cred că acestea vor trăi destul de mult. OODB încă nu va putea înlocui în totalitate bazele de date relaționale. În unele sarcini reale, este încă mai convenabil și mai corect să stocați datele nu în obiecte, ci în tabele.
Astfel, cred că în timp, OODB va recâștiga o parte din piața de sisteme comerciale din bazele de date relaționale, dar nu pot obține un avantaj atât de total pe care îl au în prezent bazele de date relaționale.
