Sincronizarea bazelor de date SQL Server din diverse surse. Prezentare generală a instrumentelor de sincronizare a bazelor de date MySQL

Sincronizarea bazei de date MySQL vă permite să creați și să mențineți automat două sau mai multe baze de date cu conținut identic. Sincronizarea este necesară pentru a crea oglinzi, clustere etc. Software-ul Handy Backup vă permite să automatizați complet procesul de sincronizare a bazei de date MySQL.

Metode de sincronizare a bazei de date MySQL

În MySQL, sincronizarea a două baze de date poate fi unidirecțională sau bidirecțională.

Sincronizare unidirecțională

Conținutul unei baze (master) este copiat pe altul (slave). În MySQL, sincronizarea bazei de date pe diferite servere este utilizată pentru replicarea tabelelor, crearea de baze de date de testare și backup, backup MySQL etc.

Sincronizare în două sensuri

Sincronizarea bidirecțională MySQL asigură că cele mai recente modificări sunt copiate din fiecare bază de date în alta. Această tehnică este folosită în primul rând pentru distribuirea sarcinilor de calcul legate de bazele de date - crearea de clustere și oglinzi de baze de date.

Beneficiile Handy Backup pentru sincronizarea bazei de date MySQL

Handy Backup conține un plugin MySQL încorporat care vă permite să faceți o copie de rezervă a stării bazelor de date și a tabelelor MySQL în modul „fierbinte” (fără a opri serverul), precum și în modul „rece” (cu oprire). Aceasta oferă următoarele beneficii:

• Sincronizarea datelor MySQL (copiere și restaurare) conform programului;
• Stocarea tabelelor MySQL în format text care poate fi citit de om dintr-o listă de comenzi SQL;
• Oprire automată a serverului țintă MySQL în timpul recuperării datelor;
• Copierea versiunii și crearea de mărci de timp pe copii după cum este necesar;
• Obținerea accesului la servere MySQL externe.

Cum se sincronizează MySQL cu Handy Backup?

Sincronizarea bazelor de date MySQL constă în crearea unei copii de rezervă a bazei de date și apoi restaurarea tabelelor acestei baze de date pe un alt server folosind pluginul „MySQL”. Acest proces include 2 sarcini succesive:

Faceți o copie de rezervă a datelor tabelului original (în cazul sincronizării unidirecționale) sau a ambelor tabele (în cazul sincronizării simetrice).

Recuperarea datelor la un tabel MySQL sincronizat, complet sau diferențial, în funcție de tipul de sincronizare.

O descriere detaliată a sarcinilor de backup și restaurare MySQL este disponibilă în Manualul utilizatorului.

Automatizarea sarcinilor de sincronizare a tabelelor MySQL

Pentru ca procesul de sincronizare a bazei de date MySQL să fie complet automat, vă rugăm să acordați atenție următoarelor puncte:

1. Împărțiți ora de pornire a sarcinilor de backup și restaurare MySQL la o perioadă suficientă de timp, astfel încât sarcina de backup a bazei de date care rulează să aibă timp să se termine înainte de a începe restaurarea.
2. Alegeți medii suficient de rapid pentru copiile intermediare MySQL: unități locale și externe, dispozitive NAS / SAN și servere FTP / SFTP / FTPS cu o lățime de bandă largă a interfeței de rețea.
3. Utilizați capacitățile de la Pasul 7 (setarea programelor să ruleze înainte și/sau după finalizarea sarcinii) pentru a opri și reporni automat serverul MySQL pe partea de recuperare, precum și pe partea de scriere pentru datele de încărcare la rece.

1. Deoarece copiile de siguranță sunt stocate într-un format text care poate fi citit, utilizați instrumentele după cum este necesar pentru a corecta fișierele restaurate - de exemplu, pentru a schimba motorul de stocare.

Achiziționarea unei licențe

După cum sa menționat mai sus, sincronizarea bazei de date MySQL (DB) nu înlocuiește backup-urile obișnuite. Vă recomandăm să furnizați sarcini de copiere a bazei de date MySQL utilizând una dintre soluțiile noastre software orientate spre afaceri.

• Dacă trebuie să lucrați doar cu un singur server MySQL, Handy Backup Office Expert vă va oferi toate capabilitățile necesare pentru aceasta și multe funcții suplimentare.
• Dacă aveți nevoie să întrețineți mai multe servere și stații de lucru, organizând procesele de copiere de rezervă a bazei de date MySQL și a oricăror alte date dintr-un loc de muncă comun, utilizați soluția noastră emblematică Handy Backup Server Network.

Pentru a compara prețurile pentru aceste produse și alte produse, vă rugăm să consultați pagina Cumpărați.

Tutorial video

Următorul tutorial video vă va arăta cum să faceți copii de rezervă și să restaurați baza de date MySQL utilizând versiunea pentru Windows a Handy Backup. Videoclipul este disponibil momentan numai în limba engleză.

Descărcați și instalați software-ul nostru chiar acum - prima copie de rezervă a datelor dvs. va fi gata în câteva minute!

Handy Backup oferă un instrument de încredere, rapid și extrem de personalizabil pentru sincronizarea MySQL la nivel de tabel și bază de date. Încercați-l acum descarcând versiunea completă a programului gratuit timp de 30 de zile!

Când utilizați un computer Inteligența in sistemele cu arhitectura distribuita este necesara sincronizarea bazelor de date ale Serverelor si ale URMA. Sincronizarea bazelor de date vă permite să stocați date atât central (pe un Server sau URMA), cât și distribuite (replicarea datelor din bazele de date ale diferitelor Servere și URMA ale sistemului de supraveghere video). Sincronizarea bazelor de date asigură lucru paralel cu bazele de date ale Serverelor și URMA și actualizări automate atunci când acestea se modifică.

Baza de date implicită pentru PC Inteligența pe Servere și URMA nu sunt sincronizate între ele. De obicei PC Inteligența este configurat în așa fel încât toate bazele de date să fie sincronizate cu o singură bază de date centralizată situată pe Serverul de Administrare.

Notă.

Dacă una sau mai multe baze de date sunt stocate în format MS Access, este necesar să convertiți bazele de date în format de server MS SQL înainte de a configura sincronizarea.

Pentru a configura sincronizarea bazei de date Configurare pachete software Inteligența cu baza de date a serverului de administrare (sau altă bază de date), trebuie să efectuați următorii pași:

1. Verificați dacă software-ul MS SQL Server rulează.
2. Rulați utilitarul idb.exe situat în rădăcina directorului de instalare a computerului Inteligența(de exemplu, C: \ Program Files (x86) \ Intellect). Va fi afișată caseta de dialog a utilitarului idb.exe.
3. Din listă Selectați sursa de date: selectați elementul Sursă sincronizată.
4. Bifeaza casuta Utilizare.
5. apasa butonul Ton.
6. Va fi afișată o casetă de dialog Proprietățile legăturii de date... La fereastră Proprietățile legăturii de date trebuie să mergi la filă Furnizor de date.
   
7. Din listă Furnizorii OLE DB trebuie să selectați un articol Furnizor Microsoft OLE DB pentru SQL Server.
8. apasa butonul Mai departe.
9. După apăsarea butonului Mai departe se va comuta automat la fila Conexiune.
   
10. În linie 1. Selectați sau introduceți un nume de server:În această fereastră trebuie să selectați din listă sau să introduceți manual numele serverului MS SQL care stochează baza de date cu care doriți să o sincronizați pe cea curentă.
11. Într-un grup 2. Pentru a intra pe server utilizați: trebuie să specificați tipul și să specificați parametrii de autentificare pentru conectarea la serverul MS SQL. Autentificarea pe serverul MS SQL se realizează utilizând un cont de utilizator autorizat în sistemul de operare Windows, sau prin nume de utilizator (login) și parolă, care sunt folosite pentru a proteja conexiunea la serverul MS SQL.
    Metoda și parametrii utilizați pentru autentificare pe serverul MS SQL sunt specificați la instalarea serverului MS SQL.
    În funcție de metoda de autentificare pe care trebuie să o utilizați pentru a vă conecta la serverul MS SQL, trebuie să specificați următorii parametri:
    1. În cazul în care autentificarea pe serverul MS SQL este efectuată folosind un cont de utilizator în sistemul de operare Windows, setați comutatorul în poziția Acreditările Windows NT... În acest caz, este necesar ca în sistemul de operare Windows de pe computerul pe care este instalat serverul MS SQL și să fie stocată baza de date cu care doriți să configurați sincronizarea, un cont sub care utilizatorul este autorizat în prezent în sistemul de operare Windows pe calculator de pe care se realizează configurarea sincronizarea.
    2. În cazul în care autentificarea pe serverul MS SQL este efectuată prin nume de utilizator (login) și parolă, trebuie să efectuați următoarele acțiuni:
       1. Setați comutatorul în poziție următorul nume de utilizator și parolă:.
       2. În câmp Utilizator: introduceți numele de utilizator (login) pentru a vă conecta la serverul MS SQL.
       3. Dacă accesul la serverul MS SQL este protejat prin parolă, debifați caseta Parola goală iar în câmp Parola introduceți o parolă pentru a accesa baza de date.
12. apasa butonul Verificați conexiunea.
13. Dacă conexiunea la serverul MS SQL are succes, pe ecran va apărea o fereastră cu mesajul Verificarea conexiunii a fost finalizată.
    
    apasa butonul Bineîn caseta de mesaj, care va închide automat fereastra.
14. Dacă numele serverului MS SQL și/sau parametrii de autentificare utilizați pentru conectarea la serverul MS SQL au fost specificati incorect, pe ecran va fi afișat un mesaj corespunzător.
    
    Pentru a închide fereastra de mesaj, apăsați butonul Bine... Apoi, trebuie să modificați datele introduse și să verificați din nou conexiunea la serverul MS SQL.
15. Din listă Selectați o bază de date pe server selectați numele bazei de date cu care doriți să o sincronizați pe cea curentă.
16. apasa butonul Bineîn caseta de dialog Proprietățile legăturii de date. Ca urmare a acestei acțiuni, fereastra va fi închisă.
17. apasa butonul Bine situat în colțul din dreapta jos al ferestrei utilitarului idb.exe.

Aceasta completează configurarea sincronizării bazei de date.

Prieteni, salut tuturor! Mă bucur să vă văd pe toți ca invitați 😉 Astăzi vă voi spune cum să sincronizați bazele de date WordPress. Și, de asemenea, despre ce tabele din baza de date sunt cele mai importante și cum să lucrezi cu ele.

Acopăr acest subiect cu un motiv. După cum vă amintiți, am vorbit despre cum. O oportunitate foarte convenabilă pentru dezvoltarea site-ului web.

Deci, după ce site-ul a fost revizuit, acesta trebuie returnat la găzduire. Și cu asta, în general, nu există probleme. În cazul în care în timpul lucrului dumneavoastră pe serverul local, site-ul aflat pe Internet nu a fost actualizat. Dar astfel de cazuri sunt extrem de rare.

Dar dacă ați actualizat în mod regulat site-ul și, în același timp, ați lucrat, ca și mine, la designul său pe computer, atunci apare o anumită dificultate. Baza de date locală va avea un design nou, dar nu vor avea articole sau comentarii noi.

Și aici intervine sincronizarea bazei de date. Acesta este modul în care puteți combina atât modele noi, cât și înregistrări noi în baza de date. Și după aceea, fără probleme, transferați site-ul finalizat înapoi pe găzduire.

Și acesta este doar un exemplu, dar tu însuți ai înțeles deja că manipularea abil a bazei de date îți deschide noi posibilități în lucrul pe site.

Structura bazei de date WordPress

Înainte de a începe sincronizarea, trebuie să vă dați seama ce să sincronizați. Baza de date WordPress constă din multe tabele care stochează date despre utilizatori, articole, categorii, etichete, plugin-uri, comentarii, setări de sistem și multe altele.

În general, nu este necesar să înțelegeți temeinic toate tabelele. Este suficient să știi ce tabele conțin informații despre articole, comentarii și așa mai departe. Aceste tabele sunt cheia sincronizării.

Deci, să aruncăm o privire la tabelele cheie dintr-o bază de date WordPress.

wp_options - conține toate setările site-ului;

wp_posts - toate articolele și postările de pe site;

wp_postmeta - date auxiliare despre articole și postări de pe site;

wp_comments - comentarii;

wp_commentmeta - informații auxiliare despre comentarii;

wp_term_relationships - link-uri de articole și postări cu categorii și etichete;

wp_terms - legături de categorii (titluri) cu legături;

wp_term_taxonomy - linkuri de categorii, tag-uri, link-uri;

wp_usermeta - informații despre toți utilizatorii înregistrați;

wp_users - informații despre administrator.

Multe alte tabele din baza de date sunt create de tot felul de pluginuri, widget-uri și alte asemenea instrumente. Practic, aceste tabele colectează informații despre sistem, acestea putând fi folosite cu beneficii. Deci, după ce te uiți cu atenție la aceste tabele, poți afla la ce solicitare cheie a venit vizitatorul, la ce pagină, dacă a fost prima vizită sau a doua și chiar din ce browser și sistem de operare.

Acum că aveți o înțelegere generală a bazei de date WordPress, puteți continua la scopul lecției noastre - sincronizarea bazei de date.

Pregătirea pentru procesul de sincronizare

Înainte de a începe să lucrați cu baza de date, asigurați-vă că ați făcut o copie de rezervă. Pentru că dacă o faci, ceva nu este în regulă. Puteți restaura totul din copie.

Deci, veți înțelege procesul și veți putea să creați baza de date necesară pe computer și să transferați baza de date gata făcută în găzduire.

Cel mai important, nu uitați să faceți backup.

Compararea bazelor de date în phpMyAdmin

Acest pas este opțional, dar este mai bine dacă știi să compari bazele de date folosind mijloacele disponibile. Aceste cunoștințe mă ajută adesea.

Pentru aceasta vom folosi utilitarul phpMyAdmin, care este disponibil atât pe hosting, cât și pe serverul local.

Ca o comparație, vom folosi baza de date de pe serverul local, pe care am folosit-o în lucru. Și baza de date pe care o folosesc pe blogul meu.

Pentru comparație, să luăm o cifră - numărul de articole. Pentru că pentru site-uri ca al meu, acesta este cel mai valoros lucru. Și comentariile, desigur. În plus, aceste numere sunt întotdeauna în vizorul dumneavoastră.

Analizarea site-ului de testare și a bazei de date:

În primul rând, să ne uităm la numărul de articole. Acest lucru se poate face în panoul de administrare WordPress. Este suficient să deschideți consola.

După cum puteți vedea în captură de ecran, pe site-ul de testare există 136 de articole.

După ce am actualizat tema, am reușit să mai scriu câteva articole. Și acum sunt 138 dintre ei.

Numărul de articole trebuie să se potrivească cu numărul de intrări din tabelul wp_posts. Dar, dacă deschideți acest tabel, atunci veți vedea mult mai multe înregistrări.

După cum puteți vedea în captură de ecran, există 2.245 de înregistrări în total. Și printre acestea se numără articole și intrări individuale. Și este, de asemenea, o grămadă de schițe și alte înregistrări despre imagini și așa mai departe.

Prin urmare, este nerealist să determinați imediat numărul de articole. Pentru a face acest lucru, trebuie să faceți o mică interogare cu parametrii de sortare.

Deschideți baza de date - tabelul wp_posts - accesați fila SQL - introduceți interogarea:

SELECTAȚI * FROM `wp_posts` WHERE` post_status` = "publicați" ȘI `post_type` =" postare "

Această solicitare spune că în tabelul wp_posts trebuie să selectați toate înregistrările (*), unde statutul este publicat (publicare) și acesta este un articol (post).

Ca rezultat, obținem 136 de înregistrări. Acum această cifră corespunde numărului de articole.

Cealaltă bază de date este verificată în același mod. În cazul meu - baza reală de pe blogul meu.

Aceste cunoștințe te vor ajuta să nu pierzi nimic important. Și verificați după sincronizare dacă totul a mers bine.

Ca exemplu enervant, o să vă spun o mică poveste. O cunoştinţă de-a mea s-a mutat odată de la o găzduire la alta. A făcut totul conform instrucțiunilor, suportul tehnic l-a ajutat. Dar, după ceva timp, a observat că pe site-ul său lipsesc două articole. Când mi-a cerut să-mi dau seama care ar putea fi problema, am verificat-o și s-a dovedit că noua bază de date nu are două înregistrări care se află în vechea bază de date. Cel mai probabil, când a transferat baza de date, a greșit ceva și a pierdut aceste două articole. Drept urmare, a trebuit să fac puțină magie și să readuc aceste două articole la locul lor.

Acesta este motivul pentru care este important să știi cum să reconciliezi. Și asigurați-vă că, după sincronizare, toate înregistrările dumneavoastră au fost transferate cu succes dintr-o bază de date în alta.

Sincronizarea bazelor de date WordPress

Toate acțiunile vor fi efectuate pe serverul local. Și apoi baza de date finalizată poate fi importată în găzduire.

Pasul 1. Creați două baze de date goale

Dacă apare întrebarea de ce există două baze de date, atunci explic - acest lucru este necesar pentru a nu atinge bazele de date de lucru și pentru a arăta un exemplu de la zero.

Mai întâi de toate, porniți Denver și tastați localhost / tools / în browser, apoi faceți clic pe linkul phpmyadmin.

Pasul 2. Importarea datelor în baza de date

Deci, am făcut copii de siguranță ale bazelor de date. Unul de pe un site de testare, unul de pe blogul meu de pe internet. Acestea vor fi necesare pentru a importa conținut în bazele de date nou create. Și atunci vor fi asigurare.

Ar trebui să aveți și două baze pe care le veți sincroniza.

Acum trebuie să importați datele din copii de siguranță în baze de date noi. Pentru a face acest lucru, selectați o nouă bază - deschideți marcajul "Import"- alege "Fisier de rezerva"- apasa butonul "BINE".

Pasul 3. Sincronizarea bazelor de date

În general, este posibil să copiați pur și simplu tabelele necesare dintr-o bază de date în alta. Dar ne vom uita direct la procesul de sincronizare. Atât complet cât și parțial (sub formă de tabele separate).

Pentru a face acest lucru, accesați pagina principală a phpMyAdmin și selectați secțiunea "Sincroniza".

Acum, ca sursă, definim o bază de date dintr-un blog de pe Internet (este mai recent), iar ca bază de date țintă, o bază de date dintr-un site de testare. Sarcina noastră este să copiem articole noi, comentarii și etichete în baza de date a site-ului de testare.

După ce s-a făcut comparația. Vi se va oferi posibilitatea de a sincroniza tabelele individuale în care există modificări sau de a efectua o sincronizare completă.

Dacă doriți să sincronizați tabele individuale, atunci trebuie să faceți clic pe literele S sau D. Aceste litere vor deveni gri, iar în fereastra de mai jos veți vedea tabelele adăugate pentru sincronizare. Apoi puteți sincroniza aceste tabele făcând clic pe butonul Aplicați modificările selectate.

În cazul nostru, această metodă este potrivită, deoarece trebuie doar să sincronizăm articolele, comentariile și metadatele.

Pentru a sincroniza complet bazele de date, nu trebuie să verificați nimic. Doar apăsați butonul „Sincronizați baze de date”.

Asta e tot. Acest lucru finalizează procesul de sincronizare. Puteți verifica rezultatul. Pentru un exemplu ilustrativ, am schimbat baza de date pe site-ul local. Dacă cineva a uitat, acest lucru se face în fișierul wp-config.php. Și acum puteți compara numărul de articole, postări și comentarii. Adevărat, au fost puțin mai multe comentarii pe blog în timp ce scriam articolul.

Testați statisticile blogului:

Statistici blog de locuri de muncă:

Și, în sfârșit, permiteți-mi să vă reamintesc că sincronizarea bazei de date este încă jumătate din luptă. Fișierele utilizate în funcționarea site-ului trebuie să fie și ele atașate bazei de date. De exemplu, dacă nu copiați capturile de ecran care însoțesc articolul, atunci articolul va fi fără ele cu spații goale.

Și acum vă sfătuiesc să urmăriți un tutorial video în care vă arăt pas cu pas întreg procesul de sincronizare a bazei de date.

Asta e tot pentru azi. Le doresc tuturor bună dispoziție. Ne vedem în materiale noi. Și bineînțeles, aștept cu nerăbdare comentariile voastre 😉 Și cunoștințele acumulate vă vor fi de folos când.

Abonați-vă la articole noi!

Conceptul bazei de date. Clasificarea bazelor de date (după forma de prezentare a informațiilor; după natura organizării datelor; după tipul de model utilizat; după tipul de informații stocate; după natura organizării stocării datelor și a accesului la acestea).

Bază de date(DB) este o colecție de date special organizate stocate în memoria unui sistem de calcul și care reflectă starea obiectelor și interrelațiile lor în domeniul subiectului luat în considerare.

Bază de date Este un sistem de date special organizat ( baze de date), instrumente software, tehnice, lingvistice, organizatorice și metodologice menite să asigure acumularea centralizată și utilizarea colectivă multifuncțională a datelor. În definiția de mai sus a BND, pe de o parte, se subliniază că banca de date este un sistem complex care include toate subsistemele suport necesare pentru funcționarea oricărui sistem automat de prelucrare a datelor. Pe de altă parte, această definiție indică și principalul caracteristici distinctive ale băncilor de date:

Bazele de date sunt de obicei create nu pentru a rezolva orice problemă pentru un utilizator, ci pentru utilizare multifuncțională.

Bazele de date reprezintă o parte specifică a lumii reale. Trebuie să ne străduim să ne asigurăm că toate informațiile care descriu subiectul sunt înregistrate în baza de date o singură dată, acumulate și păstrate la zi central, iar toți utilizatorii care au nevoie de aceste informații ar trebui să poată lucra cu ele.

Bazele de date sunt date special organizate, de ex. sisteme de date interconectate, a căror unitate și integritate este susținută de software special.

Pentru ca BnD să funcționeze, este necesar să existe un limbaj și instrumente software speciale (numite DBMS) care să faciliteze efectuarea de către utilizatori a tuturor operațiunilor legate de organizarea stocării datelor, actualizarea și accesarea acestora. utilizatorii BnD.

1. Utilizatori finali. Utilizatorilor finali nu ar trebui să li se ceară să aibă nicio cunoștință de calculator și limbaj.

2. Personalul serviciului de informare. Ei folosesc în principal metainformații. Este adesea de dorit ca alte informații să fie închise pentru ei.

3. Administratorii BnD- persoanele responsabile cu crearea BND și funcționarea fiabilă a acestuia, pentru respectarea regulilor de acces la datele stocate, pentru dezvoltarea BND (administratori de domeniu, administratori de baze de date, administratori de aplicații).

Clasificarea bazelor de date.

1. După forma de prezentare a informaţiei. Componenta centrală a băncii de date este baza de date și majoritatea caracteristicilor de clasificare se referă la aceasta. Prin forma de prezentare a informaţiei distinge vizualși audio sisteme cât și sisteme multimedia... Această clasificare arată în ce formă sunt stocate informațiile în baza de date și transmise din baze de date către utilizatori: sub formă de imagine, sunet sau este posibil să se utilizeze diferite forme de afișare a informațiilor. Conceptul de „imagine” este folosit aici într-un sens larg - poate fi un text simbolic, o imagine grafică fixă ​​(imagini, desene etc.), fotografii, hărți geografice, imagini în mișcare.

2.După natura organizării datelor DB-urile pot fi împărțite în unele nestructurate, parțial structuratși structurat... Această caracteristică de clasificare se referă la informațiile prezentate sub formă simbolică. Bazele de date nestructurate includ baze de date organizate sub formă de rețele semantice. Bazele de date sub formă de text simplu sau sisteme hipertext pot fi considerate parțial structurate. Bazele de date structurate necesită proiectarea preliminară și descrierea structurii bazei de date. Numai atunci bazele de date de acest tip pot fi populate cu date.

3. Baze de date structurate la rândul lor după tipul de model utilizat sunt impartite in: ierarhic, de rețea, relațional, mixtși multi-model.

Clasificare după tipul de model se aplică nu numai bazelor de date, ci și DBMS.

În bazele de date structurate, se disting de obicei mai multe niveluri de unități de informații, care sunt incluse unele în altele. Cele mai multe sisteme structurate acceptă la nivel de câmp, înregistrare și fișier.

Spre câmp cea mai mică unitate semantică de informație corespunde; un set de câmpuri sau/și alte unități de informații, mai complexe, dacă sunt permise într-un anumit SGBD, formă înregistrare, și multe înregistrări de același tip reprezintă fişier bază de date... Recent, majoritatea DBMS-urilor acceptă în mod explicit nivelul Bază de date ca o colecție de fișiere de baze de date interconectate.

În modelele ierarhice și de rețea, pot fi definite legături între elementele de informații (înregistrări ale diferitelor fișiere).

Reprezentarea grafică a modelului ierarhic este un grafic de tip „arbore”. Într-un astfel de model, există un vârf - rădăcina copacului, care este intrarea în structură. Fiecare vârf, altul decât o rădăcină, poate avea un singur vârf original și, în cazul general, atâtea vârfuri generate cât se dorește.

Reprezentarea grafică a modelului de rețea este un grafic de tip „rețea”. Orice vârf poate fi o intrare într-o astfel de structură. Fiecare vârf poate avea atât mai multe vârfuri generate, cât și mai multe vârfuri originale. Între o pereche de vârfuri pot fi declarate mai multe legături. Marea majoritate a SGBD-urilor suportă structuri de rețea simple, adică o relație 1: M este menținută între fiecare pereche de tipuri de înregistrări.

Pe lângă modelele de rețea cu fișiere peer-to-peer, există modele de rețea cu fișiere eterogene. În astfel de modele, se face o distincție între fișierele principale (principale) și cele dependente. Intrarea în structură este posibilă numai prin fișierele principale. Numai înregistrările de diferite tipuri pot comunica între ele.

Un loc special în rândul sistemelor structurate îl ocupă sistemele construite pe utilizarea lui fișiere inversate... Particularitatea organizării datelor în ele este că datele efectiv stocate și informațiile despre legături sunt separate logic și fizic unele de altele. Datele de bază din aceste sisteme sunt stocate în fișiere, ale căror înregistrări pot avea o structură complexă. Toate informațiile de control sunt concentrate în asociat. Legătura logică între fișiere se stabilește printr-o componentă a asociatorului numită rețea de comunicații. În fig. principiul stabilirii conexiunilor în astfel de sisteme este prezentat schematic. În realitate, conexiunile nu se stabilesc direct cu elementele de comunicare, așa cum se arată în figură, ci prin convertorul de adrese. În sistemele construite pe fișiere inversate, este posibil să se transfere o relație M:M între înregistrările de fișiere (pe care niciun alt sistem nu o permite). Separarea informațiilor asociative de datele stocate efectiv vă permite să schimbați legăturile fără a modifica fișierele în sine.

4. După tipul de informații stocate DB-urile sunt împărțite în: documentar, factualși lexicografic... Dintre bazele documentare se disting bibliografic, rezumatși text complet... Bazele de date lexicografice includ diverse dicționare (clasificatoare, dicționare multilingve, dicționare cu rădăcini de cuvinte etc.).

În sistemele de tip faptic, baza de date stochează informații despre obiectele domeniului de interes de interes pentru utilizator sub formă de „fapte” (de exemplu, date biografice despre angajați, date despre producția de produse de către producători etc. .). Ca răspuns la solicitarea utilizatorului, se emite informațiile solicitate despre obiectul/obiectele de interes pentru acesta sau mesajul că informațiile solicitate sunt absente în baza de date.

În bazele de date documentare, unitatea de stocare este orice document (de exemplu, textul unei legi sau al unui articol), iar utilizatorului, ca răspuns la solicitarea sa, i se emite fie un link către document, fie către documentul însuși, în care poate găsiți informațiile de interes.

Bazele de date de tip documentar pot fi organizate în diferite moduri: fără stocare și cu stocarea documentului original în sine pe suportul mașinii. Sistemele de primul tip includ baze de date bibliografice și abstracte, precum și indicatori de baze de date, „referindu-se” la sursa informației. Sunt apelate sistemele în care este prevăzută stocarea textului integral al documentului text complet.

5. De către natura organizării stocării datelor și accesul la acestea distinge local(personal), general(integrat, centralizat) și distribuite Bază de date.

Baza de date personală Este o bază de date destinată utilizării locale de către un singur utilizator. Bazele de date locale pot fi create de fiecare utilizator independent sau pot fi preluate dintr-o bază de date comună.

Integrat și distribuit DB-urile presupun posibilitatea accesului simultan al mai multor utilizatori la aceeași informație (multiuser, mod de acces paralel).

Baze de date distribuiteîn plus, au trăsături caracteristice asociate cu faptul că părțile fizic diferite ale bazei de date pot fi localizate pe computere diferite și, în mod logic, din punctul de vedere al utilizatorului, ar trebui să fie un singur întreg.

Banca de date este un sistem complex om-mașină și nu numai DB, ci și alte componente BnD pot fi distribuite pe nodurile rețelei. Mai mult, este posibil ca baza de date în sine să nu fie distribuită (de exemplu, atunci când se oferă acces multiutilizator la o bază de date centralizată în rețea). Mai mult, sub distribuit BnD ne referim la o bancă de date în care este distribuită cel puțin una dintre componentele sale.

Distinge extensiale(EBD) și intensional DB. O bază de date intensională (IDB) este construită folosind regulile care îi determină conținutul, și nu prin stocarea explicită a datelor într-o bază de date, ca în bazele de date extensiale.

Conceptul de sistem de management al bazelor de date (DBMS). Clasificarea sistemelor de management al bazelor de date. Grupări de clasificare legate de banca de date în ansamblu.

Sistemul de gestionare a bazelor de date (DBMS) Este un complex de instrumente lingvistice și software concepute pentru crearea, întreținerea și partajarea de baze de date de către mulți utilizatori. De obicei, un SGBD se distinge prin modelul de date utilizat. Deci, SGBD-urile bazate pe utilizarea unui model de date relaționale se numesc SGBD relațional.

După limbile de comunicare SGBD-urile sunt împărțite în deschis,închisși amestecat.

Sistemele deschise sunt sisteme în care sunt folosite limbaje de programare universale pentru a accesa bazele de date. Sistemele închise au propriile limbi de comunicare cu utilizatorii BND.

După numărul de niveluriîn arhitectură, se disting sistemele cu un nivel, două niveluri, trei niveluri.

Nivelul arhitectural al SGBD este înțeles ca o componentă funcțională, ale cărei mecanisme servesc la susținerea unui anumit nivel de abstractizare a datelor (niveluri logice și fizice, precum și „vizualizarea” utilizatorului - nivelul extern).

Numerotarea nivelurilor din figură este condiționată, dar totuși reflectă semnificația lor (modelul intern poate fi construit doar pe baza celui conceptual; aceste două niveluri pot fi combinate, dar SGBD-ul este întotdeauna suportat; nivelul extern în arhitectura DBMS poate fi absentă).

După funcţiile îndeplinite SGBD-urile sunt împărțite în informațieși săli de operație... SGBD-urile de informații permit organizarea stocării informațiilor și accesul la acestea. Pentru a efectua procesări mai complexe, trebuie să scrieți programe speciale. SGBD-urile operaționale efectuează procesări destul de complexe, de exemplu, permit automat obținerea de indicatori agregați care nu sunt stocați direct în baza de date, pot modifica algoritmii de procesare etc.

În funcție de domeniul de aplicare posibil distinge universalși de specialitate, de obicei SGBD orientat spre probleme.

Prin "putere" SGBD-urile sunt împărțite în „Desktop”și "Corporativ"... Trăsăturile caracteristice ale DBMS desktop sunt cerințe relativ scăzute pentru mijloace tehnice, concentrare pe utilizatorul final și costuri reduse.

SGBD-urile Enterprise oferă lucru într-un mediu distribuit, performanță ridicată, suport pentru lucrul în echipă în proiectarea sistemului, au instrumente de administrare avansate și capabilități mai largi de menținere a integrității.

Cele mai cunoscute SGBD-uri corporative sunt Oracle, Informix, Sybase, MS SQL Server, Progress și altele.

Există o împărțire a DBMS pe generații:

Generația 1 - bazată pe un model ierarhic și de rețea.

A 2-a generație - Sisteme relaționale.

Generația a 3-a - DBMS trebuie să suporte structuri complexe de date și mijloace mai avansate de asigurare a integrității datelor, să îndeplinească cerințele pentru sistemele deschise.

Grupări de clasificare legate de BnD în ansamblu.

Conform termenilor de serviciu distinge liberși plătit bănci de date. BnD plătite, la rândul lor, sunt împărțite în nonprofitși comercial... Băncile de date non-profit funcționează pe principiul autosuficienței și nu urmăresc obținerea de profit.

Scopul principal al creării băncilor de date comerciale este de a obține profit din activitățile de informare.

Sisteme OLTP și OLAP: caracteristici comparative.

Sistemele informatice diferă prin natura prelucrării informaţionale predominante... În unele, sunt implementate în principal un număr mare de interogări destul de simple (astfel de sisteme se numesc OLTP (On-Line Transaction Processing) - sisteme de procesare a tranzacțiilor online... În altele, dimpotrivă, este necesară o prelucrare complexă a datelor analitice (pentru această clasă de sisteme a ajuns să fie folosit termenul OLAP (On-line Analytical Processing)). termenul OLAP

adesea echivalat cu suportul decizional (DSS (Decision Support Systems) - sisteme de sprijin pentru decizii). Și ca sinonim pentru ultimul termen, este folosit Data Warehousing, adică un set de soluții organizaționale, software și hardware pentru furnizarea analiștilor de informații bazate pe date din sistemele de procesare a tranzacțiilor de nivel inferior și din alte surse.

„OLAP în sens restrâns” - acestea sunt sisteme care oferă doar o selecție de date în diferite secțiuni și „OLAP în sens larg”, sau pur și simplu OLAP, care include:

suport pentru mai mulți utilizatori care editează baza de date;

funcții de modelare, inclusiv mecanisme de calcul pentru obținerea rezultatelor derivate, precum și agregarea și combinarea datelor;

prognoza, detectarea tendințelor și analiza statistică.

Depozitele de date pot fi clasificate în două tipuri: depozite de date pentru întreprinderi și magazine de date. Depozitele de date ale întreprinderii conțin informații la nivel corporativ, colectate dintr-o varietate de surse operaționale pentru analiză consolidată. Data mart-urile conțin un subset de date corporative și sunt construite pentru departamente sau divizii din cadrul unei organizații. Chioșcurile de date sunt adesea construite de departamentul însuși și acoperă un aspect specific de interes pentru angajații departamentului respectiv.

Caracteristici comparative ale sistemelor OLTP și OLAP:

Model de date relaționale: concepte de bază. Principalele tipuri de conexiuni dintre relații și caracteristicile acestora.

Model relațional datele (RMD) ale unui anumit domeniu reprezintă un set de relații care se modifică în timp. Atunci când creați un sistem informațional, un set de relații vă permite să stocați date despre obiecte din domeniul subiectului și să modelați conexiuni între ele.

Atitudine este cel mai important concept și este un tabel bidimensional care conține unele date.

Esenta există un obiect de orice natură, ale cărui date sunt stocate în baza de date. Datele entității sunt stocate într-o relație.

Atribute sunt proprietăți care caracterizează o entitate. În structura tabelului, fiecare atribut este numit și corespunde antetului unei anumite coloane din tabel.

Din punct de vedere matematic, relația poate fi descrisă după cum urmează. Să fie date n mulțimi D1, D2, D3, ..., Dn, atunci relația R este mulțimea ordonată tupluri, unde dk Dk, dk - atribut, a nu știu - domeniu relaţie R.

Orez. Reprezentarea relatiei ANGAJAT

Domeniu este un set de toate valorile posibile pentru un anumit atribut al unei relații. Relația ANGAJAT K include 4 domenii. Domeniul 1 conține numele tuturor angajaților, domeniul 2- numerele tuturor departamentelor companiei, domeniul 3- titlurile tuturor posturilor, domeniul 4 - datele de naștere a tuturor angajaților. Fiecare domeniu formează valori de același tip de date, de exemplu, numerice sau caractere.

Relația ANGAJAT conține 3 tupluri. Tuplul relației luate în considerare este format din 4 elemente, fiecare dintre ele selectat din domeniul corespunzător. Fiecare tuplu are un rând corespunzător în tabel.

Schema relației (antetul relației) este o listă de nume de atribute. De exemplu, pentru exemplul dat, diagrama de relații are forma ANGAJAT (nume complet, Departament, Funcție, Zi de naștere). Setul de tupluri reale ale unei relații este adesea numit conţinut (corp) relație.

Cheie primară (cheie de relație, atribut cheie) este un atribut de relație care identifică în mod unic fiecare dintre tuplurile sale. De exemplu, în raport cu ANGAJAT (nume complet, departament, funcție, ziua de naștere), atributul cheie este „nume complet”. Cheie poate compozit (complex), adică este format din mai multe atribute. Pot exista cazuri în care o relație are mai multe combinații de atribute, fiecare dintre ele identificând în mod unic toate tuplurile relației. Toate aceste combinații de atribute sunt posibile chei relaţie. Oricare dintre cheile posibile poate fi aleasă ca primar.

Dacă cheia primară aleasă constă din setul minim necesar de atribute, se spune că este nu redundant .

Cheile sunt utilizate în mod obișnuit în următoarele scopuri:

1) eliminarea dublării valorilor în atributele cheie;

2) ordonarea tuplurilor;

3) accelerarea lucrului cu tupluri de relație;

4) organizarea tabelelor de legătură.

Fie relația R1 să aibă nu cheie atributul A ale cărui valori sunt valori cheie Atributul B într-o altă relație R2. Atunci se spune că atributul A al relației R1 este cheie externă .

Legăturile dintre relații sunt stabilite folosind chei străine. De exemplu, există două relații STUDENT (nume complet, grup, specialitate) și SUBJECT (Numele Pr, Ore), care sunt legate prin relația STUDENT_ SUBJECT (nume complet, Numele Pr, Evaluare) (Fig.). Într-o relație de legătură, atributele Name și Name.Pr formează o cheie compusă. Aceste atribute sunt chei străine care sunt cheile primare ale altor relații.

Orez. Legătură de relație

Condiții a căror îndeplinire permite ca tabelul să fie considerat o relație.

1. Toate rândurile tabelului trebuie să fie unice, adică nu pot exista rânduri cu aceleași chei primare.

2. Numele coloanelor din tabel trebuie să fie diferite, iar valorile lor simple, adică un grup de valori într-o coloană dintr-un rând nu este permis.

3. Toate rândurile unui tabel trebuie să aibă o structură corespunzătoare numelor și tipurilor de coloane.

4. Ordinea rândurilor din tabel poate fi arbitrară. Cel mai adesea, tabelul cu relația se află într-un fișier separat.

Dacă relația specificată de tabel are o cheie, atunci tabela este considerată a avea și o cheie și este apelată cheie sau tabel cu câmpuri cheie.

Principalele tipuri de conexiuni dintre relații și caracteristicile acestora.Între tabele pot fi stabilite legături binare (între două tabele), ternare (între trei tabele) și, în general, n-are. Să luăm în considerare cele mai comune binar comunicare.

Când conectați două tabele, sunt selectate tabelele principale și suplimentare (subordonate). Conectarea logică a tabelelor se face folosind cheie de comunicare . Cheia de legătură este formată din unul sau mai multe câmpuri, care în acest caz sunt numite domeniile de comunicare (PS).

Esența legăturii este de a stabili o corespondență între câmpurile de legătură ale tabelelor principale și suplimentare. Câmpurile de legătură ale tabelului principal pot fi obișnuite și cheie. Câmpurile cheie sunt cel mai adesea folosite ca câmpuri de legătură ale tabelului subordonat.

În funcție de modul în care sunt definite câmpurile de legătură ale tabelelor principale și suplimentare (cum se leagă câmpurile cheie cu câmpurile de legătură), următoarele patru tipuri principale de legături pot fi stabilite între două tabele în cazul general (tabel):

unu - unul (1: 1);

unul - mai mulți (1: M);

multe - unul (M: 1);

multe - multe (M: M sau M: N).

Tab. Caracteristicile tipurilor de legături dintre tabele

Relație 1: 1. O relație 1: 1 se formează atunci când toate câmpurile de relație ale tabelelor principale și suplimentare sunt cheie. Deoarece valorile din câmpurile cheie ale ambelor tabele nu se repetă, se asigură o corespondență unu-la-unu a înregistrărilor din aceste tabele. Mesele în sine, de fapt, devin egale aici.

Tipul de relație 1: M. Relația 1: M apare atunci când o înregistrare din tabelul principal corespunde mai multor înregistrări din tabelul auxiliar.

Relația de tip M: 1. Relația M: 1 apare atunci când una sau mai multe înregistrări ale tabelului principal sunt asociate cu o înregistrare a tabelului suplimentar.

Relație de tip M: M. Cel mai general tip de relație M: M apare atunci când mai multe înregistrări ale tabelului principal corespund mai multor înregistrări ale tabelului suplimentar.

cometariu . În practică, o legătură implică de obicei mai multe tabele simultan. În acest caz, unul dintre tabele poate avea diverse tipuri de legături cu mai multe tabele. În cazurile în care tabelele înrudite, la rândul lor, au relații cu alte tabele, se formează o ierarhie sau un arbore de relații.

Teoretica multimilor si operatii speciale ale algebrei relationale.

Algebră se numește un set de obiecte cu un set de operații pe el, închis față de această mulțime, numit setul principal.

Mulțimea de bază în algebra relațională este mulțimea relațiilor. Întregul set de operații poate fi împărțit în două grupe: operații teoretice și operații speciale. Prima grupă include 4 operații. Primele trei operații teoretice de mulțimi sunt binare, adică implică două relații și necesită scheme echivalente ale relațiilor originale.

Consolidare două relații se numește relație care conține un set de tupluri aparținând fie primei, fie celei de-a doua relații originale, fie ambelor relații în același timp.

Să fie date două relații R 1 = (r 1), R 2 = (r 2), unde r 1 și r 2 sunt, respectiv, tuplu ale relațiilor R 1 și R 2, apoi uniunea R 1 R 2 = (r | r R 1 Vr R 2). Aici r este un tuplu al unei noi relații, V este o operație de adunare logică „OR”.

Trecere

R 3 = R 1 R 2 = (r | r R 1 ^ r R 2), aici ^ este operația de înmulțire logică („ȘI” logic).

Diferență

Trecere relațiile se numesc relație care conține un set de tupluri aparținând simultan primei și celei de-a doua relații R1 și R2:

R 3 = R 1 R 2 = (r | r R 1 ^ r R 2), aici ^ este operația de înmulțire logică ("ȘI").

Diferență relațiile R1 și R2 se numesc o relație care conține o mulțime de tupluri aparținând lui R1 și care nu aparțin lui R2:

R 5 = R 1 \ R 2 = (r | r R 1 ^ r R 2)

Ambreiaj, sau concatenare, tupluri cu = și q = .., q m> este un tuplu obținut prin adăugarea valorilor celui de-al doilea la sfârșitul primului. Legătura cu și q este notată ca (c, q).

(c, q) =<с 1 с 2 , ... , с n , q 1 , q 2 , .... q m >

Aici n este numărul de elemente din primul tuplu c, m este numărul de elemente din al doilea tuplu q.

Toate operațiunile anterioare nu au modificat gradul sau aritatea relațiilor - aceasta rezultă din definiția echivalenței schemelor de relații. Operația cu produsul cartezian modifică gradul relației rezultate.

Produsul Cartezian Extins relația R, gradul n cu schema S R1 = (A 1, A 2 ..., A n) și relația R 2 de gradul m cu schema S R2 = (B 1, B 2, ..., B m) se numește raportul R 3 grade n + m cu schema

S R3 = (A 1, A 2, ..., A n, B 1, B 2, ..., B m) care conține tuplurile obținute prin concatenarea fiecărui tuplu r al relației R 1 cu fiecare tuplu q al relația R2.

Adică, dacă R 1 = (r), R 2 = (q)

R1R2 = ((r, q) | rR1^qR2).

Operații speciale ale algebrei relaționale.

Prima operație specială a algebrei relaționale este selecție orizontală, sau operatie de filtrare, sau operațiune de relații limitative.

Fie a o expresie booleană compusă din termeni de comparație folosind conectivele ȘI (^), SAU (V), NU (-) și, eventual, paranteze. Următoarele sunt permise ca termeni de comparație:

a) termenul A os a, unde A este numele unui atribut care ia valori din domeniul D; a este o constantă luată din același domeniu D, a D; os - una dintre operațiile de comparare permise pentru domeniul dat D;

b) termenul A os B, unde A, B sunt denumirile unor atribute Q-comparabile, adică atribute care iau valori din același domeniu D.

Atunci rezultatul unei operații de selecție sau filtrare specificată pe relația R sub forma unei expresii booleene definite pe atributele relației R este relația R [G], care include acele tupluri din relația originală pentru care selecția sau condiția de filtrare este adevărată:

R = (r | r R ^ G (r) = „Adevărat”)

Următoarea operațiune specială este operatiune de proiectare... Fie R o relație, S R = (А 1, ..., А n) - schema unei relații R. Fie B submulțimea [Аi]; В (Аi) În plus, fie В 1 setul de atribute din (Ai) neincluse în B. Dacă В = (A 1 jA 2 j ..... A kj), В 1 = (А 1 j, А 2 j, ..., А kj) și r =<а 1 j, а 2 j,...,а k j >, și k j А k ji, apoi r [В], s =< a 1 j, а 2 j, ... , а m , >; a m, A m j

Proiecția unei relații R pe un set de atribute B, notat cu R [B], este o relație cu o schemă corespunzătoare unui set de atribute B S R | B | = B, care conține tupluri obținute din tupluri ale relației originale R prin eliminarea valorilor din acestea care nu aparțin atributelor din mulțimea B.

Prin definiția unei relații, toate tuplurile duplicate sunt eliminate din relația rezultată.

Operația de proiectare, numită uneori și operația de selecție verticală, permite obținerea doar a caracteristicilor cerute obiectului modelat. Cel mai adesea, operația de proiectare este utilizată ca pas intermediar în operațiunile de selecție orizontală sau de filtrare. Este utilizat independent în etapa finală a primirii unui răspuns la o solicitare.

Următoarea operație specială în algebra relațională este îmbinare condiționată.

Spre deosebire de operațiile speciale considerate ale algebrei relaționale: filtrarea și proiecția, care sunt unare, adică sunt efectuate pe o relație, operația unei îmbinări condiționate este binară, adică două relații sunt inițiala pentru aceasta și rezultatul este unul.

Fie R = (r), Q = (q) - relații inițiale, S R, S Q - scheme ale relațiilor R și, respectiv, Q.

SR = (A 1, A 2, ..., A k): SQ = (B 1 B 2, ..., B m), unde A, B sunt numele atributelor din schemele de relații R și Q, respectiv. În acest caz, presupunem că sunt date seturile de atribute A și B

A (Ai), j = 1, k; În (B ​​j) j = 1, m și aceste mulțimi constau din atribute Q-comparabile.

Atunci conexiunea relațiilor R și Q în condiția p va fi o submulțime a produsului cartezian al relațiilor R și Q, ale căror tupluri satisfac condiția p, considerată ca îndeplinirea simultană a condițiilor:

r.A j Q j В i,: i = l, k, unde k este numărul de atribute incluse în seturile A și B, iar Q j este o operație specifică de comparare.

A j Q j В i D i Qi este i-lea predicat de comparație, determinat din setul de operații de comparare permise pe domeniul D i.

R [P] Q = (r.q) | (r. q) | r.A Q j q.B j - „Adevărul”, i = l, k)

Ultima operație inclusă în setul de operații pentru algebra relațională este operația Divizia.

Pentru a defini o operație de divizare, să luăm în considerare mai întâi conceptul de set de imagini.

Fie R o relație cu schema S R = (A1, A 2, ..., A k);

Fie A un set de atribute A (A i) i = l, k, A 1 - un set de atribute neincluse în mulțimea A.

Intersecția mulțimilor A și A 1 este goală: A A 1 = 0; uniunea mulțimilor este egală cu mulțimea tuturor atributelor relației inițiale: A A 1 = S R.

Atunci setul de imagini ale unui element al proiecției R [A] este mulțimea unor astfel de elemente ale proiecției R pentru care concatenarea (x, y) este tuplu ale relației R, adică

QA (x) = (y | y R ^ (x, y) R) este mulțimea de imagini.

Să definim acum operația Divizia. Să fie date două relaţii R şi respectiv T cu scheme: S R = (A 1, A 2, ..., A k); ST = - (B 1, B 2, ..., Bm);

A și B sunt seturi de atribute ale acestor relații, de aceeași lungime (fără repetări);

A S R; S T. Atributele A 1 sunt atribute din R care nu sunt incluse în setul A.

Intersecția mulțimilor A A 1 = - este goală și A A 1 = S R. Proiecțiile R [A] și T [B] sunt compatibile prin unire, adică au circuite echivalente: S R | A | ~ S T [B].

Atunci operația de împărțire pune în corespondență cu relațiile R și T raportul

Q = RT, ale căror tupluri sunt acele elemente ale proiecției R pentru care T [B] este inclus în setul de imagini construite pentru ele:

RT = (r | r R ^ T [B] (y | y R [A] ^ (r, y) R)).

Operația de împărțire este convenabilă atunci când doriți să comparați un set de caracteristici ale atributelor individuale.

Diverse soluții arhitecturale utilizate în implementarea DBMS multiuser. Arhitectură centralizată.

Conceptul de bază de date presupunea inițial capacitatea de a rezolva multe probleme de către mai mulți utilizatori. Cea mai importantă caracteristică SGBD modern este prezența tehnologiei de lucru multiutilizator. Diferite implementări ale unor astfel de tehnologii în momente diferite au fost asociate atât cu proprietățile de bază ale tehnologiei informatice, cât și cu dezvoltarea software-ului.

Arhitectură centralizată. Când se utilizează această tehnologie, baza de date, SGBD și programul de aplicație (aplicația) se află pe același computer (mainframe sau computer personal) (Fig. 1). Pentru această metodă de organizare nu este nevoie de suport de rețea și totul se reduce la muncă autonomă. Lucrarea este structurată astfel:

Baza de date ca set de fișiere se află pe hard diskul computerului.

Un SGBD și o aplicație pentru lucrul cu baza de date sunt instalate pe același computer.

Utilizatorul lansează aplicația. Folosind interfața de utilizator furnizată de aplicație, inițiază o solicitare către baza de date pentru a prelua/actualiza informații.

Toate apelurile către baza de date trec prin DBMS, care încapsulează toate informațiile despre structura fizică a bazei de date în interiorul său.

SGBD inițiază accesul la date, asigurându-se că solicitările utilizatorilor sunt îndeplinite.

Orez. 1. Arhitectură centralizată

O arhitectură similară a fost utilizată în primele versiuni ale DB2 și Oracle DBMS. Principalul dezavantaj al acestui model este degradarea dramatică a performanței pe măsură ce numărul de utilizatori crește.

Tehnologia de rețea și server de fișiere (arhitectura server de fișiere). Tehnologia client-server. Arhitectură client-server pe trei niveluri (multi-nivel).

Creșterea complexității sarcinilor, apariția computerelor personale și a rețelelor locale au fost premisele pentru apariția unei noi arhitecturi server de fișiere... Această arhitectură de baze de date accesibilă în rețea presupune că unul dintre computerele din rețea este desemnat ca un server dedicat unde vor fi stocate fișierele bazei de date. În funcție de solicitările utilizatorilor, fișierele cu server de fișiere sunt transferate pe stațiile de lucru ale utilizatorului, unde se realizează cea mai mare parte a prelucrării datelor. Serverul central îndeplinește în principal doar rolul de stocare a fișierelor, neparticipând la prelucrarea datelor în sine (Fig. 2.).

Orez. 2. Arhitectura „server de fișiere”.

Lucrarea este structurată astfel:

Baza de date sub forma unui set de fișiere se află pe hard disk-ul unui computer special dedicat (server de fișiere).

Există o rețea locală, formată din calculatoare client, pe fiecare dintre acestea fiind instalate un SGBD și o aplicație pentru lucrul cu baza de date.

Pe fiecare dintre computerele client, utilizatorii pot rula aplicația. Folosind interfața de utilizator furnizată de aplicație, inițiază o solicitare către baza de date pentru a prelua/actualiza informații.

Toate apelurile către baza de date trec prin SGBD, care încapsulează în sine toate informațiile despre structura fizică a bazei de date aflată pe serverul de fișiere.

SGBD inițiază apeluri către datele aflate pe serverul de fișiere, în urma cărora o parte din fișierele bazei de date sunt copiate pe computerul client și procesate, ceea ce asigură executarea solicitărilor utilizatorului (se efectuează operațiunile necesare asupra datelor).

Dacă este necesar, datele sunt trimise înapoi la serverul de fișiere pentru a actualiza baza de date.

SGBD returnează rezultatul în aplicație.

Aplicația, folosind interfața cu utilizatorul, afișează rezultatul interogărilor.

În cadrul arhitecturii" server de fișiere„au fost implementate primele versiuni ale popularului așa-numit SGBD desktop, precum dBase și Microsoft Access. Principalele dezavantaje ale acestei arhitecturi sunt:

Când mai mulți utilizatori accesează aceleași date în același timp, performanța scade dramatic.

Resursele computerului client și ale rețelei nu sunt utilizate în mod optim. Ca urmare, traficul în rețea crește și cerințele hardware pentru computerul utilizatorului cresc.

Este utilizată o abordare de navigare, axată pe lucrul cu înregistrări individuale.

Nivel scăzut de securitate - furt și vătămare, efectuând modificări eronate.

Un aparat de tranzacționare subdezvoltat servește ca sursă de erori în ceea ce privește încălcarea integrității semantice și referențiale a informațiilor în timp ce se efectuează simultan modificări.

Tehnologia client-server. Utilizarea tehnologiei" client server„presupune prezența unui număr de calculatoare conectate la o rețea, dintre care unul realizează funcții speciale de control (este un server de rețea).

Arhitectura" client server"separă funcțiile aplicației utilizator (client) și ale serverului. Aplicația client generează o cerere către serverul unde se află baza de date în limbajul de interogare SQL structurat. Serverul la distanță primește cererea și o înaintează către serverul SQL de bază de date. .Serverul SQL este un program special care controlează.Serverul SQL asigură executarea interogării în baza de date, formarea rezultatului executării interogării și emiterea acestuia către aplicația client.Calculatorul client trimite doar interogarea către baza de date server și primește rezultatul, dupa care il interpreteaza ca fiind necesar si il prezinta utilizatorului.rezultatul cererii este trimis aplicatiei client, doar datele de care clientul are nevoie "calatoresc" prin retea.Ca urmare, sarcina pe reteaua este redusa.Intrucat cererea este executata in acelasi loc in care sunt stocate datele (pe server), nu este nevoie de a trimite pachete mari de date.Serverul SQL optimizeaza interogarea primita astfel incat aceasta sa fie executata la minimum posibil Timp cu cele mai mici costuri generale. Arhitectura sistemului este prezentată în Fig. 3.

Toate acestea măresc performanța sistemului și reduc timpul de așteptare pentru rezultatul interogării. Atunci când serverul execută interogări, gradul de securitate a datelor este semnificativ crescut, deoarece regulile de integritate a datelor sunt definite în baza de date de pe server și sunt aceleași pentru toate aplicațiile care utilizează această bază de date. Acest lucru elimină posibilitatea de a defini reguli conflictuale pentru menținerea integrității.

Orez. 3. Arhitectura client-server.

Baza de date sub forma unui set de fișiere se află pe hard disk-ul unui computer special dedicat (server de rețea).

Există o rețea locală formată din computere client, fiecare dintre ele având instalată o aplicație client pentru a lucra cu baza de date.

Pe fiecare dintre computerele client, utilizatorii pot rula aplicația. Folosind interfața de utilizator furnizată de aplicație, inițiază un apel către SGBD-ul situat pe server pentru a prelua/actualiza informații. Pentru comunicare, se folosește un limbaj special de interogare SQL, de ex. numai textul cererii este transmis prin rețea de la client la server.

SGBD-ul încapsulează în sine toate informațiile despre structura fizică a bazei de date situate pe server.

SGBD inițiază apeluri către datele aflate pe server, în urma cărora toată prelucrarea datelor este efectuată pe server și numai rezultatul interogării este copiat pe computerul client. Astfel, SGBD returnează rezultatul în aplicație.

Aplicația, folosind interfața cu utilizatorul, afișează rezultatul interogărilor.

Functiile aplicatiei client: trimiterea cererilor; interpretarea cererilor; prezentarea rezultatelor.

Funcții partea serverului: primirea cererilor; asigurarea sistemului de securitate și diferențierea accesului; managementul integrității bazei de date; implementarea stabilității modului de operare multi-utilizator.

In arhitectura" client server„Așa-numitele” SGBD-uri industriale funcționează. Se numesc industriale datorită faptului că SGBD-ul acestei clase este cel care poate asigura munca unui IS de scara unei întreprinderi mijlocii și mari, organizații, bănci (MS). SQL Server, Oracle, InterBase etc.).

Serverul SQL este întreținut de un angajat individual sau de un grup de angajați. Aceștia gestionează caracteristicile fizice ale bazei de date, optimizează, configurează și redefinesc diverse componente ale bazei de date, creează baze de date noi, modifică pe cele existente etc.

Să luăm în considerare principalele avantaje ale acestei arhitecturi în comparație cu arhitectura „server de fișiere”:

Traficul în rețea este redus semnificativ.

Complexitatea aplicațiilor client este redusă (cea mai mare parte a încărcăturii cade pe partea serverului) și, în consecință, cerințele hardware pentru computerele client sunt reduse.

Prezența unui instrument software special - un server SQL - duce la faptul că o parte semnificativă a sarcinilor de proiectare și programare a fost deja rezolvată.

Integritatea și securitatea bazei de date este semnificativ crescută.

Dezavantajele includ costuri financiare mai mari pentru hardware și software, precum și anumite dificultăți în actualizarea la timp a aplicațiilor client pe toate computerele client.

Arhitectură client-server pe trei niveluri (multi-nivel).Trei legături(in unele cazuri multi-link)arhitectură reprezintă o îmbunătățire suplimentară a tehnologiei" client server— Având în vedere arhitectura. client server„, putem concluziona că este un 2-link: primul link este aplicația client, al doilea link este serverul bazei de date + baza de date în sine. arhitectura pe trei niveluri toată logica de afaceri (logica de afaceri) care a fost inclusă anterior în aplicațiile client este separată într-o legătură separată numită server de aplicații. În acest caz, rămâne doar interfața cu utilizatorul pentru aplicațiile client. De exemplu, aplicația client din exemplul de mai sus este un browser Web, astfel încât atunci când logica de afaceri se schimbă, nu mai trebuie să modificați aplicațiile client și să le actualizați pentru toți utilizatorii. În plus, cerințele pentru echipamentele utilizatorului sunt minimizate.

Prin urmare, lucrarea este structurată după cum urmează:

DB sub forma unui set de fișiere situate pe hard disk-ul unui computer special dedicat (server de rețea).

SGBD-ul este, de asemenea, localizat pe serverul de rețea.

Există un server de aplicații dedicat care găzduiește software-ul de analiză a afacerii (logica de afaceri).

Există multe computere client, fiecare dintre ele având un așa-numit „client subțire” - o aplicație client care implementează interfața cu utilizatorul.

Pe fiecare dintre computerele client, utilizatorii pot rula o aplicație client subțire. Folosind interfața cu utilizatorul oferită de aplicație, inițiază un apel către software-ul de analiză de afaceri situat pe serverul de aplicații.

Serverul de aplicații analizează cerințele utilizatorului și generează interogări către baza de date. Pentru comunicare, se folosește un limbaj special de interogare SQL, de ex. numai textul solicitării este transmis prin rețea de la serverul de aplicații la serverul de baze de date.

SGBD-ul încapsulează în sine toate informațiile despre structura fizică a bazei de date.

SGBD inițiază apeluri către datele aflate pe server, în urma cărora rezultatul interogării este copiat pe serverul de aplicații.

Serverul de aplicații returnează rezultatul aplicației client (utilizatorului).

Aplicația, folosind interfața cu utilizatorul, afișează rezultatul interogărilor.

Conceptul de integritate a bazei de date. Integritatea logică și fizică a bazei de date. Clasificarea constrângerilor de integritate.

Asigurarea integrității datelor este cea mai importantă sarcină în proiectarea și operarea sistemelor de procesare a datelor (PDS). Problema integrității este de a asigura... că datele din baza de date sunt corecte în orice moment.” Integritate - relevanța și consistența informațiilor, protecția acesteia împotriva distrugerii și modificărilor neautorizate.

Integritatea este unul dintre aspectele securității informațiilor, alături de accesibilitate - capacitatea de a obține serviciul de informații solicitat la un cost acceptabil și confidențialitatea - protecție împotriva citirii neautorizate.

Integritatea datelor este o proprietate inalienabilă a bazei de date, iar întreținerea acesteia este cea mai importantă sarcină a proiectării BnD. Integritatea datelor este descrisă de un set de oferte speciale numite constrângeri de integritate. Constrângerile de integritate sunt declarații despre valorile acceptabile ale elementelor individuale de informații și relațiile dintre acestea. Aceste limitări sunt determinate în majoritatea cazurilor de specificul domeniului subiectului. La efectuarea operațiunilor pe baza de date se verifică îndeplinirea constrângerilor de integritate. Constrângerile de integritate pot fi clasificate în funcție de diferite criterii (Fig.).

Integritate logică - starea bazei de date, caracterizată prin absența încălcărilor constrângerilor de integritate inerente modelului de date logic (adică constrângeri implicite), și a constrângerilor explicite specificate declarativ sau procedural. Integritate fizică – nicio încălcare a specificațiilor schemei de stocare, precum și nicio distrugere fizică a datelor de pe mediu.

Pentru a controla integritatea bazei de date, este utilizat și un mecanism de declanșare. Trigger Este o acțiune care este activată atunci când are loc evenimentul specificat (inserați, ștergeți, actualizați o înregistrare). Declanșatoarele sunt specificate în schema bazei de date. Un concept mai larg în raport cu declanșatorul este conceptul procedură stocată. Procedurile stocate descriu părți ale logicii aplicației care sunt stocate și executate pe server pentru a îmbunătăți caracteristicile de performanță.

Integritatea datelor- o proprietate integrală a unei baze de date, iar furnizarea acesteia este cea mai importantă sarcină de proiectare a unei baze de date. Integritatea datelor este descrisă de un set de oferte speciale numite constrângeri de integritate. Constrângerile de integritate sunt declarații despre valorile acceptabile ale elementelor individuale de informații și relațiile dintre acestea. Aceste limitări sunt determinate în majoritatea cazurilor de specificul domeniului subiectului. La efectuarea operațiunilor pe baza de date se verifică îndeplinirea constrângerilor de integritate. Constrângeri de integritate pot fi clasificate după diferite criterii (fig. mai jos).

Distingeți între integritatea logică și fizică a bazei de date. Integritate logică- starea bazei de date, caracterizată prin absența încălcărilor constrângerilor de integritate inerente modelului de date logic (adică constrângeri implicite), și a constrângerilor explicite specificate declarativ sau procedural. Integritate fizică- absența încălcării specificațiilor schemei de stocare, precum și distrugerea fizică a datelor de pe suport.

9. Problema integrității bazei de date. Tranzacții și încuietori. Sincronizarea muncii utilizatorului.

Integritatea este unul dintre aspectele securității informațiilor, alături de accesibilitate - capacitatea de a obține serviciul de informații solicitat la un cost acceptabil și confidențialitatea - protecție împotriva citirii neautorizate.

Asigurarea integrității datelor este cea mai importantă sarcină în proiectarea și operarea sistemelor de procesare a datelor (PDS). Problema integrității este să ne asigurăm că datele din baza de date sunt corecte în orice moment.” Integritate - relevanța și consistența informațiilor, protecția acesteia împotriva distrugerii și modificărilor neautorizate.

Pentru a controla integritatea bazei de date, este, de asemenea, utilizat mecanism de declanșare. Trigger Este o acțiune care este activată atunci când are loc evenimentul specificat (inserați, ștergeți, actualizați o înregistrare). Declanșatoarele sunt specificate în schema bazei de date. Un concept mai larg în legătură cu un declanșator este procedură stocată... Procedurile stocate descriu părți ale logicii aplicației care sunt stocate și executate pe server pentru a îmbunătăți caracteristicile de performanță.

Tranzacții. O tranzacție este un set complet de acțiuni dintr-o bază de date, care o transferă de la o stare logică, integrală, la alta. Tranzacțiile sunt supuse unui set de cerințe cunoscute sub numele de ACID (atomicitate, consistență, izolare, durabilitate). Aceste cerințe rezultă din definiția unei tranzacții.

Atomicitatea O tranzacție este o colecție de acțiuni finalizate. Sistemul asigură executarea acestora pe principiul „totul sau nimic” – fie se efectuează toate acțiunile, apoi tranzacția este „angajată”; sau, dacă nu există nicio oportunitate de a efectua toate acțiunile, de exemplu, în cazul unor eșecuri, tranzacția este „retrocedată”, iar baza de date rămâne în starea inițială.

Consecvență Se presupune că, în urma unei tranzacții, sistemul trece de la o stare corectă la alta.

Izolare În timpul executării unei tranzacții, datele pot fi temporar într-o stare inconsistentă. Astfel de date nu ar trebui să fie vizibile pentru alte tranzacții până când modificările sunt finalizate (adică până când ponderea modificării este comisă în mod oficial).

Durabilitate Dacă tranzacția este efectuată, atunci rezultatele acesteia ar trebui să fie durabile. Stările tuturor obiectelor vor persista chiar și în cazul defecțiunilor hardware sau ale sistemului.

Încuietori. Cei mai populari algoritmi de control al accesului simultan se bazează pe mecanismul de blocare. Blocarea este interzicerea unor operațiuni asupra datelor dacă acestea sunt prelucrate de un alt utilizator. În această schemă, ori de câte ori o tranzacție încearcă să acceseze o unitate de date, se aplică o blocare acelei unități.

Încuietorile sunt atribuite conform regulilor de compatibilitate a lacăturilor pentru a evita disputele citire-scrie, scriere-citireși înregistrare-înregistrare.

Se știe că serializarea tranzacțiilor este garantată dacă blocările asociate cu tranzacțiile concurente îndeplinesc următoarea regulă: „Nici o blocare în numele vreunei tranzacții nu ar trebui să fie achiziționată până când este eliberată un blocare setat anterior”. Această regulă este cunoscută ca blocare în două faze , întrucât tranzacția trece prin prima fază creştere, când capătă încuietori și apoi o fază de strângere când încuietorile sunt eliberate. Blocarea poate fi efectuată automat sau poate controlat de utilizator.

În funcție de unitățile de informații blocate, se pot distinge următoarele niveluri de blocare : bază de date, colecție de tabele aferente, tabel, colecție de înregistrări aferente, intrare, câmp. Obiectele blocate pot fi o pagină, un grup de pagini sau o zonă de bază de date.

Unele sisteme oferă dinamic o schemă de blocare în care tranzacția blochează mai întâi o informație mare, cum ar fi o pagină.

Distinge pesimist șioptimist blocare... Blocările pesimiste interzic accesul la datele altor tranzacții atunci când o tranzacție funcționează deja cu ea. Blocările optimiste permit executarea simultană a tranzacțiilor, urmărirea și rezolvarea conflictelor.

Sincronizarea muncii utilizatorului.Dublare - tehnologia utilizată în RDB (baza de date de distribuție), care asigură suportul de copii ale întregii baze de date sau ale fragmentelor acesteia în mai multe noduri de rețea. Este apelată o copie a unei baze de date care este membră a unui set de alte copii care pot fi sincronizate între ele o replică. Copiile bazelor de date sunt de obicei aproape de locurile în care sunt utilizate informațiile. Replicarea este folosită sinonim cu replicarea. Procesul de actualizare a replicilor, care transferă înregistrările actualizate și alte obiecte și reconciliază datele duplicate, se numeștesincronizare . Schimbul de date între replici poate fi fie unidirecțional, fie bidirecțional. În plus, este posibilă sincronizarea replicilor sub controlul unui sincronizator. Spre deosebire de sistemele distribuite în sine, în care protocolul de comitere în două faze este implementat la executarea interogărilor distribuite, în sistemele cu baze de date replicate, se folosesc de obicei instrumente de replicare asincronă.

În prezent, multe SGBD bine-cunoscute oferă utilizatorilor capabilități de replicare. Unele sisteme folosesc metafore din publicare (editor, publicație, abonat). Setul de date care pot fi replicate este numit publicare.

start

Mai devreme sau mai târziu, toată lumea se confruntă cu asta. Ei bine, dacă nu toate, atunci multe. Se ciocnesc într-o măsură sau alta - cineva în cea mai simplă versiune, cineva într-o variantă dificilă. Uneori se găsesc instrumente standard, alteori se constată că sarcina poate fi simplificată la un anumit caz. Dar, uneori, problema apare în așa fel încât instrumentele standard nu sunt găsite sau nu se potrivesc, iar sarcina de sincronizare a bazelor de date nu este simplificată pentru un anumit caz ...

La un moment dat, această sarcină a apărut înaintea mea. Unele SGBD-uri au instrumente de sincronizare încorporate (acest proces este uneori numit și replicare, iar uneori aceste concepte se disting). Dar, în primul rând, trebuia să sincronizez bazele de date care rulează InterBase și, în al doilea rând, nici acele instrumente de la terți care există pentru acest DBMS nu mi se potriveau. Aveam nevoie de un mecanism de sincronizare care să nu asigure o monitorizare constantă de către administratori pe toate bazele de date - programul a fost scris pentru organizațiile mici. InterBase a fost ideal pentru asta - ușor, fiabil (cu siguranță mai fiabil decât bazele de date locale!), Practic nu necesită administrare cu încărcătură nu prea mare. Dar de unde să obțineți un astfel de replicator? Mai mult, pentru a fi la fel de simplu ca un dop - a început - a funcționat. Mai mult, pentru a introduce lucrarea în program! Mai mult, pentru a putea sincroniza bazele de date sub Win și sub Unix!

Două zile de căutare pe Internet pentru instrumente adecvate nu au dus nicăieri. Multe reclame, puține informații, prețuri exorbitante și, ceea ce este doar plictisitor, „instrumente foarte convenabile pentru administrator cu care este foarte ușor să corectezi coliziunile”. Ei bine, nu am un administrator care să monitorizeze fiecare sincronizare (care are loc de câteva ori pe zi) și să repare coliziunile! Ce sa fac?

Bine, încercarea nu este tortură, am decis să caut ceva pe algoritmii folosiți în replicarea bazei de date.
NIMIC.
Absolut nimic!
Dacă arătam prost și cineva îmi arată materiale interesante și disponibile gratuit în acest sens, mă voi bucura! Dar se pare că acesta este un know-how al firmelor de producție, sau unii algoritmi bine cunoscuți nu au fost încă dezvoltați pe această temă. Mă urc în Data. Nimic. Deci, raționez pe tema bazelor de date distribuite, dar ceea ce am nevoie nu este.

Într-un fel sau altul, dar după ce m-am rugat, am decis să mă gândesc și să văd ce se întâmplă. M-am gândit la asta. Am suferit. A scris. Corectat. Corectat. Am corectat din nou. Functioneaza. Glitchy. Fix - nu mai există erori. În timpul lucrului. Imi place. Lucrări! Există, desigur, probleme. Și unele sunt destul de decente. Dar... dar încă funcționează!

Așa că am decis să spun cine este interesat de ceea ce am gândit și ce am făcut.

Variante, terminologie

Toți termenii sunt făcuți de la sine, așa că nu vă jigniți dacă ceva pare o prostie. :)

Sincronizare- procesul prin care bazele de date sunt aduse într-o stare identică. Dacă cineva vine cu o definiție mai bună, îl voi asculta.

Mai întâi, să clasificăm sincronizarea după direcție și sincronizare.

Dacă datele se pot modifica doar într-una dintre bazele de date, iar în rest nu sunt modificate de utilizatori, atunci sincronizarea pe astfel de baze de date va fi numită unidirecțională sau unidirecțională. Dacă datele pot fi adăugate/modificate/șterse de către utilizatorii sistemului în mai multe baze ale sistemului, atunci va fi sincronizare bidirecțională (bidirecțională).

Dacă sincronizarea trebuie efectuată imediat după efectuarea modificărilor în baza de date, atunci o astfel de sincronizare va fi apelată sincronizare în timp real... Și dacă modificări de la unele baze de date ar trebui făcute în alte baze de date TARZIU, prin comanda / eveniment / etc - atunci va fi sincronizare întârziată.

Să împărțim acum sincronizarea amânată în încă două subclase. Dacă sincronizarea necesită o conexiune cu ambele baze de date a ionului se realizează prin analiza discrepanțelor din aceste baze de date, atunci o numim sincronizare pe starea curentă... Și dacă sincronizarea se realizează conform jurnalului - lista modificărilor făcute bazelor de date - atunci o vom numi - sincronizare prin jurnal... Ambele soiuri se găsesc în dezvoltări comerciale. Privind în viitor, voi spune că am implementat sincronizarea pe starea curentă.

Mai departe. Dacă, în timpul sincronizării, modificările pot fi detectate și făcute prin câmpuri separate de înregistrări, atunci aceasta sincronizare pe câmpuri... Dacă „unitatea” de sincronizare este o înregistrare, atunci aceasta este sincronizare prin înregistrări.

Toate acestea par să fie intuitiv clar, dar vrei rigoare și nu vrei certuri din cauza diferențelor de terminologie.

Acum o definiție foarte importantă, a cărei existență, se pare, unii dezvoltatori care au întâlnit prima dată problema noastră nu sunt familiari. Coliziune- aceasta este o oarecare incertitudine, uneori o eroare care apare în timpul sincronizării și se datorează faptului că algoritmii de sincronizare nu sunt ideali, iar problema în sine pune adesea probleme insolubile. Sau chiar deloc rezolvabil în cadrul schemei de sincronizare acceptate. Ne vom uita la diferite exemple de coliziuni mai târziu.

Tăiați inutil

Așadar, am menționat mai multe opțiuni de sincronizare și acum ar trebui să scapi de cele „în plus”. :) Nu vom lua în considerare sincronizarea în timp real, este încă o sarcină destul de exotică. Vom lua în considerare sincronizarea unidirecțională, dar foarte pe scurt - este o sarcină destul de simplă, poate fi rezolvată fără ciocniri (cel puțin, cred că da, deși s-ar putea să greșesc). Este clar că sincronizarea unidirecțională este ușor de implementat prin orice metodă bidirecțională (jurnal sau stare curentă), dar fără multe dintre problemele inerente sincronizării bidirecționale. Și, desigur, obiectivul nostru principal este sincronizarea întârziată în două sensuri.

Identificarea înregistrării

Pentru a realiza corect sincronizarea datelor în orice mod, este evident necesară identificarea unică a înregistrărilor în întregul sistem (cel puțin în cadrul unui tabel). Dacă pentru cineva pare că nu este evident, spune-mi, o să scriu mai detaliat.

Pentru unificare, este de dorit ca fiecare tabel inclus în procesul de sincronizare să aibă o cheie primară surogat (ID) - de obicei INTEGER. Cu toate acestea, acesta este cel mai adesea cazul. Cum putem oferi identificarea unică a înregistrărilor.

1. Puteți introduce un câmp suplimentar în fiecare tabel - numărul bazei de date în care a fost creată prima înregistrare (DBID). În acest caz, evident, ID-ul nu va mai fi cheia primară, în schimb cheia primară va fi o pereche (DBID, ID). Trebuie remarcat faptul că, din această cauză, această soluție nu este foarte atractivă.
2. Puteți face cheia primară un șir cu un format special, de exemplu XXXX-YYYY-ZZZZZZZZ, unde XXXX este identificatorul bazei de date în care a fost creată prima înregistrare, YYYY este identificatorul tabelului, ZZZZZZZZ este identificatorul înregistrării din un anumit tabel al unei anumite baze de date. Această soluție este foarte scalabilă, vă permite să „înghesuiți” o mulțime de informații suplimentare în ID, dar are și dezavantajele sale. În primul rând, există o anumită redundanță de informații. În al doilea rând, un mecanism mai complex pentru generarea unor astfel de ID-uri. De asemenea, ar fi bine să se limiteze valorile posibile ale ID-urilor la acest format. Acestea sunt și griji.
3. În opinia mea, cea mai bună opțiune pentru InterBase este următoarea - ID-ul pentru toate tabelele este generat de un declanșator obișnuit care selectează valorile dintr-un generator. În acest caz, valoarea inițială a generatorului este diferită pentru diferite baze de date, datorită cărora se va asigura unicitatea ID-urilor pentru toate bazele de date. Această abordare este tipică pentru InterBase. Utilizarea sa pentru alte SGBD-uri poate fi limitată de incapacitatea de a seta o valoare inițială pentru contorul câmpurilor auto-incrementale.

Este clar că am ales a treia variantă. :) Mai rămâne o întrebare - tipul de date pentru ID. Este clar că există INT64 (NUMERIC (18)) pentru ID, atunci întrebarea cu gama disponibilă de numere nu apare - gama este uriașă. Dar, din păcate, există unele probleme care împiedică acest lucru. Cert este că până acum în Delphi, suportul pentru câmpurile Int64 este oarecum șchiopăt. Acest lucru se datorează atât deficiențelor componentelor de acces la date (IBX, FIBPlus), cât și lipsei inițiale de suport pentru câmpurile Int64 din clasa TField.

În același timp, dacă ne uităm îndeaproape la gama INTEGER, găsim că pt

• folosind numai valori pozitive
• folosind un singur generator pentru toate tabelele bazei de date
• crearea zilnică a 10.000 de înregistrări în sistem

avem suficientă gamă INTEGER pentru 27 de ani de funcționare a sistemului din 21 de baze de date. În acest caz, valorile inițiale ale generatorilor diferitelor baze de date vor fi definite ca DBID * 100000000. Pentru majoritatea sistemelor, aceștia sunt indicatori destul de normali.

Ciocniri

În această secțiune, vom lua în considerare opțiunile posibile pentru modificări în baza de date și vom nota în ce cazuri este posibil să apară coliziuni. Să împărțim toate modificările făcute în două clase - modificări făcute la tabele independente individuale și făcute la tabele conectate prin relații FOREIGN KEY.

În plus, coliziunile pot fi cauzate de declanșatoare și restricții ale aplicațiilor.

Modificări la mesele individuale

O nouă înregistrare este adăugată la tabel

După sincronizare, această înregistrare ar trebui să apară în restul bazelor de date. Primul motiv al coliziunilor cu această modificare ar putea fi un conflict de cheie primară, dar această problemă este ușor de rezolvat (vezi mai sus). Deci, dacă o grămadă de înregistrări sunt adăugate la orice baze de date, toate ar trebui să fie duplicate fără probleme în restul.

Ei bine, ar putea fi de remarcat și faptul că, dacă imediat după sincronizare aceste înregistrări au fost șterse din baza de date inițială, atunci în timpul sincronizării următoare NU ar trebui restaurate. :) Cu toate acestea, se referă mai degrabă la următoarea subsecțiune:

Constrângerile de tip UNIQUE pot provoca coliziuni. Lasă-mă să explic. Fie că există 2 baze de date: A și B. Constrângerea UNIQUE (Câmp1) este impusă tabelului (Tabelul 1). Fie că la momentul inițial de timp în ambele baze NU există înregistrări cu Câmp1 = Valoare1. Să adăugăm mai întâi o astfel de înregistrare la A și apoi la B. Nu apar erori - constrângerea UNIQUE nu este încălcată. Acum încercăm să sincronizăm aceste baze de date. În mod logic, trebuie să creăm 1 înregistrare în fiecare bază de date. Dar nu putem, deoarece acest lucru va provoca o încălcare a constrângerii. Bineînțeles, cu condiția ca datele să fie introduse corect și modelul să fie construit corect, acestea ar trebui să fie înregistrări IDENTICE (pe câmpuri de subiect), ar trebui să descrie o singură entitate. Dar asta nu ne ușurează - a apărut o coliziune și trebuie rezolvată. Poate fi rezolvată prin ștergerea unei înregistrări dintr-o bază de date și reefectuând sincronizarea.

Acesta este un exemplu excelent al faptului că o coliziune poate apărea indiferent de implementarea specifică a mecanismului de sincronizare. Apare în principal din cauza distribuției sistemului și a sincronizării întârziate.

În general, astfel de coliziuni „logice” sunt practic de neidentificat. Și asta este foarte trist.

O înregistrare este ștearsă din tabel

După sincronizare, această înregistrare ar trebui să fie ștearsă, dacă există, din alte baze de date. Din nou, coliziunile „logice” sunt posibile - de exemplu, declanșatorul verifică prezența a cel puțin o înregistrare cu Câmp1 = Valoare1. În primul rând, ambele baze de date au avut două astfel de înregistrări. Ștergeți o înregistrare din ambele baze de date. În acest caz, nu vor exista erori, deoarece a doua rămâne. Dar dacă am șters diferite înregistrări în diferite baze de date, atunci după sincronizare va apărea o eroare, deoarece, ca urmare, nu va exista o singură înregistrare Field1 = Value1 în bazele de date. În cazul unor astfel de restricții, din nou, aparent, fără un administrator care să cunoască bine structura bazei de date și să fie capabil să remedieze astfel de coliziuni, nimic nu va ieși din asta :(.

Unele câmpuri ale înregistrării sunt modificate în tabel

După sincronizarea în alte baze de date, această înregistrare ar trebui să se schimbe în același mod.

Prima și foarte probabilă ciocnire este schimbarea simultană a înregistrărilor în diferite baze de date. Această coliziune are două opțiuni - dacă se modifică aceleași câmpuri și dacă se schimbă câmpuri diferite.

În primul caz, evident, o opțiune de modificare este incorectă - la urma urmei, entitatea descrisă are o valoare foarte specifică pentru acest parametru. Luând drept adevăr o modificare ulterioară sau o bază de date mai „principală”, putem rezolva cu ușurință problema.

Iar al doilea caz, la sincronizarea la nivel de înregistrări, poate provoca o problemă serioasă - pierderea informațiilor introduse. Iată un exemplu. Mai sus menționat Ivanov I.AND. a alergat din nou la instituțiile menționate mai sus. În primul, a alergat și a spus acolo, acum este o persoană cu dizabilități din a doua grupă, pe care operatorul a introdus-o în baza de date. După ce a alergat la a doua instituție în aceeași zi, a spus că are tripleți (sau pur și simplu a doua instituție este o maternitate și au aflat ei înșiși totul acolo, iar Ivanov a fugit doar la o singură instituție). Acolo a fost schimbat câmpul „număr de copii”. Atenţie! Dacă sincronizarea se realizează cu înregistrări întregi, atunci în funcție de momentul modificărilor sau de „superioritatea” bazelor, vom pierde cutare sau cutare informații introduse, cu excepția cazului în care un administrator inteligent vede o descriere detaliată a ceea ce s-a întâmplat și corectează această situație prin mână. Presupun că acest lucru este clar.

Așadar, vedem că sincronizarea la nivel de înregistrare nu numai că are ca rezultat schimbarea câmpurilor neschimbate, ci poate fi și o sursă de erori foarte urâte. În același timp, din păcate, pentru a implementa sincronizarea la nivel de teren, sunt necesare mult mai multe informații de serviciu și structuri de date mult mai complexe. În plus, implementarea sincronizării pe câmpuri se poate înfrunta cu capacitățile DBMS - este necesar să se definească o listă de câmpuri modificate și, adesea, aceasta este, de asemenea, o sarcină netrivială.

Modificări ale tabelelor legate

Vom lua în considerare coliziunile atunci când sincronizăm tabelele TableA și TableB. Tabelul B are o CHEIE STRĂINĂ care se referă la Tabelul A. Apoi, înregistrările din tabelul A vor fi părinte, iar înregistrările corespunzătoare din tabelul B vor fi copii.

Creează o nouă înregistrare parentală sau un nou copil pentru un părinte existent

Se creează o nouă înregistrare parentală și copiii săi.

Atât înregistrările părintelui, cât și ale copilului ar trebui să apară în alte baze de date. Aici devine importantă ordinea creării înregistrărilor în baza de date rezultată - mai întâi trebuie creată înregistrarea părinte, apoi cea fiidă. Totuși, în acele SGBD-uri în care constrângerile de integritate referențială sunt verificate numai atunci când se comite o tranzacție, acest lucru nu este necesar. Dar chiar și în ele, nu puteți crea toate înregistrările părinte noi, nu puteți confirma tranzacția și apoi creați înregistrări copii noi.

Înregistrarea copilului este ștearsă

Nu există particularități, nu apar probleme suplimentare din cauza conexiunii meselor.

Fișa părintelui și copiii sunt eliminate.

În baza de date rezultată, înregistrările copil trebuie șterse mai întâi, apoi părintele.

1. În baza A, se creează o înregistrare copil, în baza B, părintele este șters
2. În baza A, înregistrarea copil este transferată de la înregistrarea părinte 1 la înregistrarea părinte 2, în baza B, înregistrarea părinte 2 este ștearsă

bucle STRĂINE CHEIE

Impactul declanșatorilor

Sincronizare prin log - principii generale

Aceasta este metoda cea mai des folosită. Toate acțiunile efectuate în baza de date (crearea, ștergerea și modificarea înregistrărilor) sunt salvate într-un jurnal - de obicei un tabel separat sau un set de tabele în baza de date în sine.

Jurnalul este plin cu declanșatori care scriu suficiente informații în jurnal pentru a repeta acțiunea. Este clar că în cazul ștergerii unei înregistrări, este suficient să salvați ID-ul tabelului și valoarea cheii primare a înregistrării șterse, iar pentru a modifica sau crea o înregistrare trebuie să salvați și valorile câmpului. Marca temporală când a fost făcută modificarea este de obicei stocată.

Pentru a sincroniza două baze de date pe fiecare dintre ele, repetați toate acțiunile efectuate în cealaltă bază de date, extragându-le pe rând din jurnal. Prin urmare, urmează unul dintre avantajele sincronizării jurnalului - nu este nevoie să stabiliți o conexiune la baza de date - rezultatul jurnalului într-un fișier separat poate fi transferat prin „floppynet” :) Trebuie doar să rețineți cu atenție ce intrări de jurnal nu au fost transferat încă. Această problemă se agravează atunci când există mai multe baze de date sincronizate - trebuie să vă amintiți care ultima intrare de jurnal a fost transferată în fiecare dintre bazele de date.

Este clar că după aplicarea cu succes a jurnalului la o altă bază de date, jurnalul poate fi trunchiat. Dar, cu toate acestea, jurnalul ocupă mult spațiu - în cel mai bun caz, dublează intrările noi și modificate.

Dacă aceeași înregistrare a fost schimbată de mai multe ori la rând, atunci puteți fie să stocați toate modificările intermediare, fie să „lipiți” aceste modificări într-una singură. Acest lucru va reduce dimensiunea bușteanului, dar poate duce la ciocniri inutile.

Sincronizarea jurnalului se caracterizează printr-o creștere a datelor stocate proporțional cu numărul de modificări dintr-un ciclu de sincronizare, iar viteza de sincronizare este, de asemenea, proporțională cu numărul de modificări dintr-un ciclu de sincronizare.

De asemenea, trebuie menționat că puteți construi un serviciu de derulare a bazei de date bazat pe jurnal aproape în orice moment (cu excepția cazului în care datele corespunzătoare au fost eliminate din jurnal).

Sincronizarea cu jurnalul este destul de simplu de implementat, dar este evident că coliziunile sunt inevitabile. Pentru a ilustra acest lucru, vă ofer următoarea analogie. Imaginați-vă că aveți 2 camere cu sertare. Aveți un robot care poate fi programat să mute cutii. La momentul inițial, cutiile din cameră sunt amplasate în același mod. Dați comenzi robotului și acesta mută cutiile. Partenerul tău dă comenzi unui alt robot din a doua cameră. După aceea, ordonați roboților să schimbe locurile și să repete toate acțiunile, începând din momentul inițial. Evident, acest lucru poate duce la probleme - în prima cameră robotul muta caseta # 5, dar în a doua cameră nu era acolo, în prima a mutat caseta # 54 în colț, dar era ocupat în al doilea colț .

Trebuie remarcat faptul că o aplicare cu succes a jurnalului 2 la baza de date 1 nu înseamnă că jurnalul 1 va funcționa fără erori în baza de date 2.

Avantaje

• Nu este necesară nicio conexiune
• Puteți întoarce baza de date în orice punct din trecut
• Ușurință comparativă de implementare
• Viteză mare de sincronizare - proporțională cu numărul de modificări pe ciclu

dezavantaje

• Cantități mari de date stocate - proporțional cu numărul de modificări pe ciclu
• Ciocnirile sunt aproape inevitabile

Sincronizare pe starea actuală - principii generale

Sincronizarea după starea actuală în diverse produse a fost mult mai puțin comună pentru mine decât sincronizarea de către revistă. Dar, mi se pare, nu se poate trage o concluzie despre aplicabilitatea sa din aceasta. Se știe că în diferite sarcini este mai bine să se aplice metode mai potrivite.

Deci, sincronizarea de ultimă generație este întotdeauna conectată, astfel încât această metodă nu poate fi aplicată fără un fel de canal de comunicare între servere.

Procesul de realizare a sincronizării stabilește o conexiune cu ambele baze de date (dacă există mai mult de două baze de date, atunci sincronizarea se realizează în perechi - de exemplu, „lanț” sau „stea”) și rulează prin toate tabelele sincronizate căutând diferențe. Aici vedem primul dezavantaj semnificativ al metodei - viteza de sincronizare este proporțională cu numărul total de înregistrări din baza de date. Permiteți-mi să vă reamintesc că pentru sincronizarea jurnalului, viteza a fost proporțională cu numărul de date modificate.

Când se constată diferențele, procesul de control înlătură aceste diferențe, aducând ambele baze de date într-o formă identică. În acest caz, este necesar să se ia o decizie - care din baza de date conține datele mai corecte despre înregistrarea curentă în curs de procesare - dacă să ștergeți o înregistrare din baza de date 1 sau invers, să creați aceeași în baza de date B, unde nu este încă disponibil.

Totuși, spre deosebire de sincronizarea jurnalului, când nu există informații suplimentare atunci când este aplicat jurnalul, în acest caz procesul de control poate emite interogări auxiliare ambelor baze de date pentru a rezolva cât mai bine toate coliziunile - de exemplu, pentru a afla dacă alte tabele, înregistrări referitoare la aceasta. Astfel, prin stabilirea anumitor reguli, puteți rezolva automat o parte destul de mare a coliziunilor.

Dacă ne amintim analogia cu roboții, cutiile și camerele, atunci în acest caz robotul se va uita în ambele camere și, dacă vede că caseta numărul 15 este în locuri diferite, atunci, luând una dintre locații ca fiind corectă, va încerca să-l pun în același loc. Mai mult, dacă locul său este ocupat, atunci este posibilă o analiză suplimentară - și care casetă este ocupată? de ce nu sunt ocupat în prima cameră?

Este ușor de observat că o astfel de metodă este, în principiu, mai corectă - în loc să repeți stupid acțiuni dintr-o altă bază de date în condiții noi, este posibil să analizezi diferențele și să le elimini cât mai sigur.

Pentru a efectua sincronizarea după stare, se introduc de obicei unul sau mai multe câmpuri suplimentare pentru fiecare înregistrare a bazei de date, conform cărora procesul de control poate determina care dintre cele două înregistrări conține date mai relevante. Mărimea datelor suplimentare, din nou, se dovedește a fi proporțională cu cantitatea totală de date din baza de date, dar acest lucru nu poate fi comparat cu sincronizarea jurnalului, deoarece dimensiunea câmpurilor suplimentare este suficient de mică și nu crește cu mai multe modificări de date, iar înregistrările de jurnal dublează cel mai adesea complet înregistrările din tabel și se acumulează atunci când se efectuează modificări succesive.

Să rezumăm avantajele și dezavantajele pe care le-am luat în considerare într-o singură listă.

Avantaje

• Capabilitati bune de corectare a coliziunilor

dezavantaje

• Viteză scăzută de sincronizare - proporțională cu numărul tuturor înregistrărilor
• Necesită conectarea la ambele baze de date
• Sunt introduse câmpuri suplimentare pentru toate înregistrările - este cu adevărat imposibil de comparat cu sincronizarea jurnalului

Sincronizarea seturi independente de tabele

Deci, să presupunem că avem mai multe baze de date - A, B, C, ... În acest caz, modificarea datelor are loc (fără pierderea generalității) doar în baza de date A. De asemenea, trebuie menționat că dacă bazele de date au seturi independente de tabele, apoi într-un astfel de set, datele se pot schimba doar în baza de date A, iar în alta, doar în baza de date B (de exemplu). O astfel de structură poate fi considerată, de asemenea, un sistem de sincronizare unidirecțională, pur și simplu realizat separat pe mai multe seturi de tabele.

Să explic cu un exemplu. Compania are un magazin online. O bază de date se află în biroul companiei, cealaltă este pe serverul Web. Să presupunem că există mai multe tabele care descriu produsele magazinului online și tabele din cartea de oaspeți și forum. Aceste seturi sunt independente unele de altele, iar punctele de schimbare a datelor sunt diferite. Descrierile produselor sunt completate la birou, iar modificările trebuie trimise în baza de date a site-ului. Și informațiile de la clienți - postările pe forum și pe oaspeți sunt create pe site și merg în direcția opusă.

În această schemă, coliziunile sunt practic excluse - fluxurile de actualizare a bazei de date nu se intersectează. Puteți implementa o astfel de schemă în aproape orice mod, fără probleme.

Problemele încep când funcția de cumpărături online este introdusă în magazinul online. În acest caz, comenzile clienților depind de tabelele de produse. Și datele pentru acest set pot fi modificate în două baze de date în același timp.

Va urma...

În a doua parte, vom trece la soluția mea actuală - implementarea sincronizării bidirecționale bazată pe starea curentă a bazei de date.