Sisteme OLAP și OLTP OLTP – prelucrare online a datelor tranzacționale OLAP – prelucrare online a datelor analitice. OLTP - sisteme de procesare a tranzacțiilor online

Astăzi, dintre instrumentele oferite de piața tehnologiei informației pentru procesarea și vizualizarea datelor pentru luarea deciziilor de management, tehnologiile OLTP și OLAP sunt cele mai potrivite. Tehnologia OLTP este axată pe procesarea operațională a datelor, iar tehnologia OLAP mai modernă se concentrează pe analiza interactivă a datelor. Sistemele dezvoltate pe baza lor fac posibilă înțelegerea proceselor care au loc la o unitate de management prin accesul prompt la diferite secțiuni de date (reprezentări ale conținutului bazelor de date, organizate pentru a reflecta diferite aspecte ale activităților întreprinderii). În special, oferind o reprezentare grafică a datelor, OLAP este capabil să facă rezultatele prelucrării datelor ușor de înțeles.

OLTP (Online Transaction Processing) - procesarea tranzacțiilor în timp real. O metodă de organizare a unei baze de date în care sistemul funcționează cu tranzacții de dimensiuni mici, dar cu un flux mare, iar în același timp clientul necesită cel mai rapid timp de răspuns posibil din partea sistemului.

În SGBD-urile moderne, serializarea tranzacțiilor este organizată printr-un mecanism de blocare, adică. În timpul executării unei tranzacții, DBMS blochează baza de date sau partea acesteia accesată de tranzacție, blocarea este menținută până când tranzacția este confirmată. Dacă, în timpul procesării paralele, o altă tranzacție încearcă să acceseze datele blocate, atunci procesarea tranzacției este suspendată și reluată numai după ce tranzacția care a blocat datele se încheie și blocarea este eliberată. Cu cât obiectul blocat este mai mic, cu atât eficiența bazei de date este mai mare. O tranzacție care actualizează datele prin mai multe noduri de rețea se numește DISTRIBUIT. Dacă o tranzacție funcționează cu o bază de date situată pe un nod, atunci se numește LOCAL. Din punctul de vedere al utilizatorului, tranzacțiile locale și distribuite ar trebui procesate în același mod, adică. SGBD-ul trebuie să organizeze procesul de execuție a distribuției tranzacțiilor astfel încât toate tranzacțiile locale incluse în acesta să fie angajate sincron către toate nodurile sistemului distribuit afectate de acestea. În acest caz, o tranzacție distribuită ar trebui să fie comisă numai dacă toate tranzacțiile sale locale constitutive sunt comise, iar dacă cel puțin una dintre tranzacțiile locale este întreruptă, întreaga tranzacție distribuită trebuie să fie întreruptă. Pentru a implementa aceste cerințe în practică, DBMS folosește un mecanism de confirmare a tranzacției în două etape.

1. Serverul de baze de date care comite o tranzacție distribuită trimite comanda „Pregătiți pentru comitere” tuturor nodurilor de rețea înregistrate pentru a efectua tranzacții. Dacă cel puțin unul dintre servere nu răspunde despre pregătire, atunci serverul de baze de date distribuite derulează înapoi tranzacția locală pe toate nodurile.

2. Toate SGBD-urile locale sunt pregătite pentru comitere, de ex. serverul procesează tranzacția distribuită, termină comiterea acesteia, trimițând o comandă de comitere a tranzacției către toate serverele locale.

OLAP (ing. procesare analitică online, procesare analitică în timp real) este o tehnologie de prelucrare a informațiilor, care include compilarea și publicarea dinamică a rapoartelor și documentelor. Folosit de analiști pentru a procesa rapid interogări complexe de baze de date. Servește pentru întocmirea rapoartelor de afaceri în scopuri de vânzări, marketing, management, așa-numitele. data mining - data mining (o metodă de analiză a informațiilor dintr-o bază de date cu scopul de a găsi anomalii și tendințe fără a afla sensul semantic al înregistrărilor).

OLAP face un instantaneu al unei baze de date relaționale și o structurează într-un model de interogare spațială. Timpul de procesare declarat pentru interogări în OLAP este de aproximativ 0,1% din interogările similare dintr-o bază de date relațională.

Structura OLAP creată din date operaționale se numește cub OLAP. Un cub este creat prin unirea tabelelor folosind o schemă stea sau o schemă fulg de zăpadă. În centrul schemei stea se află un tabel de fapte, care conține faptele cheie pe care se fac interogările. Tabelele cu mai multe dimensiuni sunt asociate unui tabel de fapte. Aceste tabele arată cum pot fi analizate datele relaționale agregate. Numărul de agregări posibile este determinat de numărul de moduri în care datele originale pot fi afișate ierarhic.

De exemplu, toți clienții pot fi grupați pe oraș sau pe regiune a țării (Vest, Est, Nord etc.), astfel încât 50 de orașe, 8 regiuni și 2 țări vor alcătui 3 niveluri de ierarhie cu 60 de membri. De asemenea, clienții pot fi uniți în raport cu produse; dacă există 250 de produse în 2 categorii, 3 grupuri de produse și 3 divizii de producție, atunci numărul de unități va fi 16560. Când adăugați dimensiuni la diagramă, numărul de opțiuni posibile ajunge rapid la zeci de milioane sau mai mult.

Un cub OLAP conține date și informații de bază despre dimensiuni (agregate). Cubul poate conține toate informațiile care ar putea fi necesare pentru a răspunde la orice întrebări. Datorită numărului mare de unități, de multe ori un calcul complet are loc doar pentru unele măsurători, în timp ce pentru restul este efectuat „la cerere”.

Provocarea în utilizarea OLAP este crearea de interogări, selectarea datelor de bază și proiectarea schemei și, ca rezultat, majoritatea produselor OLAP moderne vin cu un număr mare de interogări preconfigurate. O altă problemă este în datele de bază. Ele trebuie să fie complete și consecvente

Primul produs care a efectuat interogări OLAP a fost Express (IRI). Cu toate acestea, termenul OLAP în sine a fost inventat de Edgar Codd, „părintele bazelor de date relaționale”. Iar munca lui Codd a fost finanțată de Arbor, o companie care și-a lansat propriul produs OLAP, Essbase (achiziționat ulterior de Hyperion, care a fost achiziționat de Oracle în 2007) cu un an înainte.

Alte produse OLAP cunoscute includ Microsoft Analysis Services (numite anterior OLAP Services, parte din SQL Server), Oracle OLAP Option, IBM DB2 OLAP Server (în esență EssBase cu adăugiri de la IBM), SAP BW, SAS OLAP Server, produse Brio, BusinessObjects , Cognos, MicroStrategy și alți producători.

OLAP este cel mai frecvent utilizat în planificarea afacerilor și în produsele de depozit de date.

OLAP folosește o vizualizare multidimensională a datelor agregate pentru a oferi acces rapid la informații strategice pentru o analiză aprofundată. Aplicațiile OLAP trebuie să aibă următoarele proprietăți de bază:

• reprezentarea datelor multidimensionale;
• suport pentru calcule complexe;
• luarea în considerare corectă a factorului timp.

Avantajele OLAP:

• creșterea productivității personalului de producție și a dezvoltatorilor de programe de aplicații. Acces în timp util la informații strategice.
• oferind oportunități suficiente utilizatorilor de a face propriile modificări ale schemei.
• Aplicațiile OLAP se bazează pe depozitele de date și pe sistemele OLTP pentru a furniza date actualizate, menținând astfel controlul asupra integrității datelor corporative.
• reducerea sarcinii sistemelor OLTP și depozitelor de date.

OLAP	OLTP
Depozitul de date ar trebui să includă atât date interne ale companiei, cât și date externe	principala sursă de informații care intră în baza de date operațională este activitățile corporației, iar analiza datelor necesită implicarea surselor externe de informații (de exemplu, rapoarte statistice)
Volumul bazelor de date analitice este cu cel puțin un ordin de mărime mai mare decât volumul celor operaționale. Pentru a efectua analize și prognoze fiabile într-un depozit de date, trebuie să aveți informații despre activitățile corporației și condițiile de piață pe mai mulți ani.	Pentru o prelucrare promptă, sunt necesare date pentru ultimele luni
Depozitul de date trebuie să conțină informații uniform prezentate și consecvente, cât mai apropiate de conținutul bazelor de date operaționale. Este necesară o componentă pentru extragerea și „curățarea” informațiilor din diferite surse. În multe corporații mari, există simultan mai multe sisteme informaționale operaționale cu propriile baze de date (din motive istorice).	Bazele de date operaționale pot conține informații echivalente din punct de vedere semantic prezentate în diferite formate, cu indicații diferite ale momentului primirii acesteia, uneori chiar contradictorii
Setul de interogări către o bază de date analitică nu poate fi prezis. Depozitele de date există pentru a răspunde întrebărilor ad-hoc din partea analiștilor. Poți conta doar pe faptul că cererile nu vor veni prea des și vor implica cantități mari de informații. Dimensiunea bazei de date analitice încurajează utilizarea interogărilor cu agregate (suma, minim, maxim, medie etc.)	Sistemele de prelucrare a datelor sunt create pentru a rezolva probleme specifice. Informațiile din baza de date sunt selectate frecvent și în porțiuni mici. De obicei, un set de interogări către o bază de date operațională este cunoscut deja în timpul proiectării
Când variabilitatea bazelor de date analitice este scăzută (doar la încărcarea datelor), ordonarea matricelor, metodele de indexare mai rapide pentru eșantionarea în masă și stocarea datelor preagregate se dovedesc a fi rezonabile.	Sistemele de prelucrare a datelor prin natura lor sunt foarte variabile, ceea ce este luat în considerare în SGBD-ul utilizat (structură normalizată a bazei de date, rânduri stocate în afara ordinului, arbori B pentru indexare, tranzacționale)
Informațiile analitice ale bazei de date sunt atât de critice pentru o corporație încât este necesară o mai mare granularitate a protecției (drepturi de acces individuale la anumite rânduri și/sau coloane ale tabelului)	Pentru sistemele de prelucrare a datelor, protecția informațiilor la nivel de tabel este de obicei suficientă.

Obiectivele sistemului OLTP sunt colectarea rapidă și plasarea cât mai optimă a informațiilor în baza de date, precum și asigurarea completității, relevanței și consecvenței acesteia. Cu toate acestea, astfel de sisteme nu sunt concepute pentru cea mai eficientă, rapidă și multidimensională analiză.

Desigur, este posibil să se construiască rapoarte pe baza datelor colectate, dar acest lucru necesită ca analistul de afaceri fie să interacționeze constant cu un specialist IT, fie să aibă o pregătire specială în programare și tehnologie informatică.

Cum arată procesul tradițional de luare a deciziilor într-o companie rusă care utilizează un sistem informațional construit pe tehnologia OLTP?

Managerul încredințează sarcina specialistului departamentului de informații în conformitate cu înțelegerea acestuia a problemei. Specialistul departamentului de informații, după ce a înțeles sarcina în felul său, construiește o cerere către sistemul operațional, primește un raport electronic și îl aduce în atenția managerului. Această schemă de luare a deciziilor critice are următoarele dezavantaje semnificative:

• se utilizează o cantitate neglijabilă de date;
• procesul durează mult, deoarece întocmirea cererilor și interpretarea unui raport electronic sunt operațiuni destul de plictisitoare, în timp ce managerul poate avea nevoie să ia o decizie imediat;
• Ciclul trebuie repetat dacă este necesar să se clarifice datele sau să se ia în considerare datele dintr-o perspectivă diferită, precum și dacă apar întrebări suplimentare. Mai mult, acest ciclu lent trebuie repetat și, de regulă, de mai multe ori, în timp ce se petrece și mai mult timp analizei datelor;
• Diferența de pregătire profesională și domenii de activitate a unui specialist în tehnologia informației și a unui manager are un impact negativ. Adesea ei gândesc în categorii diferite și, ca urmare, nu se înțeleg;
• un efect nefavorabil este exercitat de un astfel de factor precum complexitatea rapoartelor electronice pentru percepție. Managerul nu are timp să selecteze numerele de interes din raport, mai ales că pot fi prea multe. Este clar că munca de pregătire a datelor revine cel mai adesea specialiştilor din departamentele de informare. Drept urmare, un specialist competent este distras de munca de rutină și ineficientă de compilare a tabelelor, diagramelor etc., ceea ce, în mod firesc, nu contribuie la îmbunătățirea abilităților sale.

Există o singură cale de ieșire din această situație și a fost formulată de Bill Gates sub forma expresiei: „Informația la îndemâna ta”. Informațiile inițiale trebuie să fie disponibile pentru consumatorul direct – analistul. Este direct accesibil. Iar sarcina angajaților departamentului de informații este de a crea un sistem de colectare, acumulare, stocare, protejare a informațiilor și asigurarea disponibilității acesteia pentru analiști.

Industria globală este familiarizată de mult cu această problemă și de aproape 30 de ani există tehnologii OLAP care sunt concepute special pentru a permite analiștilor de afaceri să opereze cu datele acumulate și să participe direct la analiza lor. Astfel de sisteme analitice sunt opusul sistemelor OLTP în sensul că elimină redundanța informațională (informația „colapsată”). În același timp, este evident că redundanța informațiilor primare este cea care determină eficacitatea analizei. DSS, combinând aceste tehnologii, face posibilă rezolvarea unui număr de probleme:

• Sarcini analitice: calcularea indicatorilor specificati si a caracteristicilor statistice ale proceselor de afaceri pe baza informatiilor retrospective aflate in depozitele de date.
• Vizualizarea datelor: prezentarea tuturor informațiilor disponibile într-o formă grafică și tabelară ușor de utilizat.
• Obținerea de noi cunoștințe: determinarea relației și interdependenței proceselor de afaceri pe baza informațiilor existente (testarea ipotezelor statistice, clustering, găsirea de asociații și modele temporale).
• Probleme de simulare: modelarea matematică a comportamentului sistemelor complexe pe o perioadă de timp arbitrară. Cu alte cuvinte, acestea sunt sarcini legate de nevoia de a răspunde la întrebarea: „Ce se va întâmpla dacă...?”
• Sinteza controlului: determinarea acțiunilor de control acceptabile care asigură realizarea unui obiectiv dat.
• Probleme de optimizare: integrarea metodelor de simulare, management, optimizare și statistică de modelare și prognoză.

Managerii de întreprindere care folosesc instrumente tehnologice OLAP, chiar și fără pregătire specială, pot obține în mod independent și rapid toate informațiile necesare studierii modelelor de afaceri și într-o mare varietate de combinații și secțiuni de analiză de afaceri. Un analist de afaceri are ocazia să vadă în fața lui o listă de măsurători și indicatori ai unui sistem de afaceri. Cu o interfață atât de simplă, un analist poate construi orice rapoarte, rearanja măsurători (de exemplu, face tab-uri încrucișate - suprapune o măsurătoare pe alta). În plus, are posibilitatea de a-și crea propriile funcții pe baza indicatorilor existenți, de a efectua o analiză „ce-ar fi dacă” - obține rezultate prin specificarea dependențelor oricăror indicatori ai funcțiilor de afaceri sau a unei funcții de afaceri de indicatori. În acest caz, răspunsul maxim al oricărui raport nu depășește 5 secunde.

Pentru rezolvarea problemelor de analiză a datelor și căutarea soluțiilor, este necesar să se acumuleze și să stocheze volume suficient de mari de date. Bazele de date (DB) servesc acestor scopuri.

Pentru a stoca datele conform oricărui model de domeniu, structura bazei de date trebuie să corespundă cât mai mult cu acest model. Prima astfel de structură folosită într-un SGBD a fost o structură ierarhică, care a apărut la începutul anilor 60 ai secolului trecut.

Structura ierarhică presupunea stocarea datelor sub forma unei structuri arborescente.

O încercare de a îmbunătăți structura ierarhică a fost structura de rețea a bazei de date, care presupune reprezentarea structurii de date ca o rețea.

Bazele de date relaționale sunt cele mai comune astăzi. Pentru stocarea acestui tip de informații se propune utilizarea modelelor post-relaționale sub forma unor structuri de stocare a datelor orientate pe obiect. Abordarea generală este de a stoca orice informație ca obiecte. Mai mult decât atât, obiectele în sine pot fi organizate în cadrul unui model ierarhic. Din păcate, această abordare, spre deosebire de structura relațională, care se bazează pe algebră relațională, nu este suficient de formalizată, ceea ce nu permite utilizarea pe scară largă în practică.

În conformitate cu regulile Codd, SGBD trebuie să asigure executarea operațiunilor pe baza de date, oferind în același timp capacitatea de lucru simultan de mai mulți utilizatori (de pe mai multe calculatoare) și garantând integritatea datelor. Pentru a implementa aceste reguli, SGBD utilizează un mecanism de gestionare a tranzacțiilor.

O tranzacție este o secvență de operațiuni pe o bază de date, considerată de SGBD ca un întreg. O tranzacție mută baza de date dintr-o stare integrală în alta.

De regulă, o tranzacție constă în operațiuni care manipulează date aparținând unor tabele diferite și legate logic între ele. Dacă, la executarea unei tranzacții, se efectuează operațiuni care modifică doar o parte din date, iar datele rămase nu sunt modificate, atunci integritatea va fi încălcată. Prin urmare, fie trebuie finalizate toate operațiunile incluse într-o tranzacție, fie nici una dintre ele nu trebuie finalizată. Procesul de anulare a unei tranzacții se numește rollback tranzacție. Salvarea modificărilor făcute ca rezultat al operațiunilor de tranzacție se numește comitarea unei tranzacții.

Proprietatea unei tranzacții de a transfera o bază de date dintr-o stare integrală în alta ne permite să folosim conceptul de tranzacție ca unitate de activitate a utilizatorului. În cazul accesării simultane a utilizatorilor la baza de date, tranzacțiile inițiate de diferiți utilizatori nu sunt executate în paralel (ceea ce este imposibil pentru o singură bază de date), ci în conformitate cu un anumit plan sunt puse în coadă și executate secvenţial. Astfel, pentru utilizatorul din inițiativa căruia a fost creată tranzacția, prezența tranzacțiilor altor utilizatori va fi invizibilă, cu excepția unei oarecare încetiniri a funcționării față de modul monoutilizator.

Există mai mulți algoritmi de bază pentru programarea tranzacțiilor. În SGBD-urile centralizate, cei mai des întâlniți algoritmi sunt cei bazați pe sincronizarea captării obiectelor bazei de date.

Când se utilizează orice algoritm, sunt posibile situații de conflict între două sau mai multe tranzacții pentru a accesa obiectele bazei de date. În acest caz, una sau mai multe tranzacții trebuie să fie anulate pentru a menține planul. Acesta este unul dintre cazurile în care un utilizator al unui SGBD multi-utilizator poate simți de fapt prezența tranzacțiilor altor utilizatori în sistem.

Istoria dezvoltării DBMS este strâns legată de îmbunătățirea abordărilor pentru rezolvarea problemelor de stocare a datelor și de gestionare a tranzacțiilor. Mecanismul de gestionare a tranzacțiilor dezvoltat în SGBD-urile moderne le-a făcut principalul mijloc de construire a sistemelor OLTP, a căror sarcină principală este de a asigura execuția operațiunilor bazei de date.

3.1.3. Folosind tehnologia OLTP
în sistemele de sprijinire a deciziei

Sistemele de procesare a tranzacțiilor online OLTP se caracterizează printr-un număr mare de modificări, acces simultan de către mulți utilizatori la aceleași date pentru a efectua diverse operațiuni - citire, scriere, ștergere sau modificare a datelor. Blocările și tranzacțiile sunt folosite pentru a asigura funcționarea normală a mai multor utilizatori. Procesarea eficientă a tranzacțiilor și suportul de blocare sunt printre cele mai importante cerințe pentru sistemele de procesare a tranzacțiilor online.

Apropo, primele DSS – sisteme informaționale de management – ​​aparțin și ele acestei clase de sisteme. Astfel de sisteme, de regulă, sunt construite pe baza SGBD-urilor relaționale, includ subsisteme pentru colectarea, stocarea și analiza informațiilor de recuperare a informațiilor și, de asemenea, conțin un set predefinit de interogări pentru munca de zi cu zi. Fiecare cerere nouă, neprevăzută la proiectarea unui astfel de sistem, trebuie mai întâi descrisă formal, codificată de programator și abia apoi executată. Timpul de așteptare în acest caz poate fi de ore și zile, ceea ce este inacceptabil pentru luarea rapidă a deciziilor.

Practica utilizării sistemelor OLTP a arătat ineficacitatea utilizării acestora pentru analiza cuprinzătoare a informațiilor. Astfel de sisteme rezolvă cu succes problemele de colectare, stocare și extragere a informațiilor, dar nu îndeplinesc cerințele pentru DSS modern. Abordările legate de creșterea funcționalității sistemelor OLTP nu au dat rezultate satisfăcătoare. Principalul motiv al eșecului este cerințele contradictorii pentru sistemele OLTP și DSS.

Principalele cerințe pentru sistemele OLTP și DSS sunt următoarele:

1. Gradul de detaliu al datelor stocate. O interogare tipică într-un sistem OLTP tinde să afecteze selectiv înregistrările individuale din tabele, care sunt preluate eficient folosind indecși.

2. Calitatea datelor. Sistemele OLTP, de regulă, stochează informațiile introduse direct de utilizatorii sistemului (operatorii de computere). Prezența „factorului uman” în timpul introducerii crește probabilitatea datelor eronate și poate crea probleme locale în sistem.

3. Format de stocare a datelor. Sistemele OLTP care deservesc diferite domenii de lucru nu sunt interconectate. Ele sunt adesea implementate pe diferite platforme software și hardware. Aceleași date în diferite baze de date pot fi prezentate în diferite forme și pot să nu coincidă (de exemplu, datele despre un client care a interacționat cu diferite departamente ale companiei pot să nu coincidă în bazele de date ale acestor departamente).

4. Permiterea datelor redundante. Structura bazei de date care deservește un sistem OLTP este de obicei destul de complexă. Poate conține multe zeci sau chiar sute de tabele care se referă unul la celălalt. Datele dintr-o astfel de bază de date sunt extrem de normalizate pentru a optimiza resursele necesare. Interogările analitice către baza de date sunt foarte greu de formulat și sunt extrem de ineficient de executat, deoarece conțin vederi care combină un număr mare de tabele.

5. Gestionarea datelor. Cerința principală pentru sistemele OLTP este să se asigure că operațiunile de modificare sunt efectuate pe baza de date. Se presupune că acestea trebuie efectuate în mod real și adesea foarte intens.

6. Cantitatea de date stocată. De regulă, sistemele de analiză sunt concepute pentru a analiza dependențele de timp, în timp ce sistemele OLTP se ocupă de obicei cu valorile curente ale unor parametri.

7. Natura interogărilor de date. În sistemele OLTP, datorită normalizării bazei de date, compunerea interogărilor este o muncă destul de complexă și necesită calificările necesare.

8. Timp de procesare a cererilor de date. Sistemele OLTP funcționează de obicei în timp real, așa că au cerințe stricte de procesare a datelor.

9. Natura sarcinii de calcul a sistemului. După cum sa menționat mai devreme, lucrul cu sistemele OLTP se efectuează de obicei în timp real.

10. Prioritatea caracteristicilor sistemului. Pentru sistemele OLTP, prioritatea este performanța ridicată și disponibilitatea datelor, deoarece lucrează cu acestea în timp real. Pentru sistemele de analiză, sarcinile cu prioritate mai mare sunt de a asigura flexibilitatea sistemului și independența utilizatorului, adică ceea ce au nevoie analiștii pentru a analiza datele.

Trebuie remarcat faptul că cerințele contradictorii pentru sistemele OLTP și sistemele axate pe analiza profundă a informațiilor complică sarcina de integrare a acestora ca subsisteme ale unui singur DSS. În prezent, cea mai populară soluție la această problemă este o abordare de depozitare a datelor.

Ideea generală a depozitelor de date este de a separa bazele de date pentru sisteme și bazele de date pentru analiză și apoi de a le proiecta conform cerințelor corespunzătoare.

DSS rezolvă trei sarcini principale: colectarea, stocarea și analiza informațiilor stocate. Sarcina de analiză în general poate include: analiză de regăsire a informațiilor, analiză analitică operațională și analiză predictivă.

Subsistemele pentru colectarea, stocarea informațiilor și rezolvarea problemelor de analiză de regăsire a informațiilor sunt în prezent implementate cu succes în cadrul sistemelor de analiză de regăsire a informațiilor care utilizează DBMS. Pentru implementarea subsistemelor care efectuează analize analitice operaționale, se utilizează conceptul de reprezentare multidimensională a datelor. Subsistemul data mining implementează metodele.

Pentru a simplifica dezvoltarea programelor de aplicație care utilizează baze de date, sunt create sisteme de gestionare a bazelor de date (DBMS) - software pentru managementul datelor, stocarea datelor și securitatea datelor.

SGBD-urile au un mecanism dezvoltat de gestionare a tranzacțiilor, ceea ce le-a făcut principalul mijloc de creare a sistemelor de procesare a tranzacțiilor online (sisteme OLTP). Astfel de sisteme includ primul DSS care rezolvă problemele analizei de regăsire a informațiilor - ISR.

Sistemele OLTP nu pot fi utilizate eficient pentru a rezolva problemele de analiză operațională a informațiilor analitice și intelectuale. Motivul principal este cerințele contradictorii pentru sistemul OLTP și DSS.

În prezent, pentru a crește eficiența analizei operaționale analitice și intelectuale, conceptul de depozite de date este utilizat pentru a combina subsistemele OLTP și subsistemele de analiză într-un singur sistem. Ideea generală este alocarea unei baze de date pentru subsistemele OLTP și a unei baze de date pentru efectuarea analizelor. Acest lucru asigură o abordare optimă a procesării datelor în sistemele de asistență decizională.

Întrebări pentru autocontrol

1. Enumerați principalele sarcini pe care le rezolvă sistemele de sprijinire a deciziilor.

2. Subliniați direcțiile conceptuale pentru construirea depozitelor de date în sistemele de sprijinire a deciziilor.

3. Precizați tipurile de structuri pentru organizarea depozitelor de date în DSS. Care sunt avantajele și dezavantajele fiecărui tip de structură?

4. Justificați fezabilitatea utilizării unui model post-relațional al subsistemului pentru colectarea și prelucrarea informațiilor în DSS.

5. Cum este interpretat conceptul de tranzacție în sistemele de prelucrare a datelor?

6. Care este proprietatea principală a unei tranzacții în sistemele de prelucrare a datelor?

7. Descrieți pe scurt mecanismul de gestionare a tranzacțiilor în sistemele OLTP.

8. Specificați rolul și locul sistemelor OLTP pentru procesarea tranzacțiilor online. De ce sunt sistemele OLTP ineficiente pentru rezolvarea problemelor operaționale de analiză analitică și predictivă?

9. Care sunt cerințele de bază pentru sistemele OLTP. Care sunt cerințele contradictorii pentru sistemele OLTP?

10. Numiți modalități de creștere a eficienței analizei operaționale analitice și intelectuale în DSS.

Comparația modelelor normalizate și nenormalizate

Analiza criteriilor pentru modelele de date normalizate și nenormalizate

Să punem cap la cap rezultatele analizei criteriilor după care am dorit să evaluăm impactul modelării datelor logice asupra calității modelelor de date fizice și a performanței bazei de date:

După cum se poate observa din tabel, relațiile mai puternic normalizate sunt mai bine concepute (trei plusuri, unul minus). Sunt mai relevante pentru domeniul subiectului, mai ușor de dezvoltat, iar operațiunile de modificare a bazei de date sunt efectuate mai rapid pentru ei. Adevărat, acest lucru se realizează cu prețul unei oarecare încetiniri a execuției operațiunilor de recuperare a datelor.

Singurul avantaj al relațiilor slab normalizate este că, dacă baza de date este accesată doar cu interogări pentru a prelua date, atunci pentru relații slab normalizate astfel de interogări sunt executate mai rapid. Acest lucru se datorează faptului că, în astfel de relații, conexiunea relațiilor a fost deja făcută și nu se pierde timpul cu aceasta la preluarea datelor.

Astfel, alegerea gradului de normalizare a relațiilor depinde de natura interogărilor cu care se accesează cel mai des baza de date.

Este posibil să se identifice anumite clase de sisteme pentru care modelele de date puternic sau slab normalizate sunt mai potrivite.

Modelele de date extrem de normalizate sunt potrivite pentru așa-numitele aplicații OLTP (Procesarea tranzacțiilor on-line (OLTP )- procesarea promptă a tranzacțiilor ). Exemple tipice de aplicații OLTP sunt sistemele de contabilitate în depozit, sistemele de comandă de bilete, sistemele bancare care efectuează operațiuni de transfer de bani etc. Funcția principală a unor astfel de sisteme este de a efectua un număr mare de tranzacții scurte. Tranzacțiile în sine par relativ simple, de exemplu, „retrageți o sumă de bani din contul A, adăugați această sumă în contul B”. Problema este că, în primul rând, există o mulțime de tranzacții, în al doilea rând, acestea sunt executate simultan (mai multe mii de utilizatori concurenți pot fi conectați la sistem), în al treilea rând, dacă apare o eroare, tranzacția trebuie să fie complet anulată și returnată sistem către statul care se afla înainte de începerea tranzacției (nu ar trebui să existe o situație în care banii au fost retrase din contul A, dar nu au ajuns în contul B). Aproape toate interogările bazei de date din aplicațiile OLTP constau în comenzi de inserare, actualizare și ștergere. Interogările de selectare sunt concepute în primul rând pentru a permite utilizatorilor să selecteze din diferite directoare. Majoritatea cererilor sunt astfel cunoscute dinainte în faza de proiectare a sistemului. Prin urmare, viteza și fiabilitatea operațiunilor scurte de actualizare a datelor sunt critice pentru aplicațiile OLTP. Cu cât este mai mare nivelul de normalizare a datelor într-o aplicație OLTP, cu atât aceasta tinde să fie mai rapidă și mai fiabilă. Abateri de la această regulă pot apărea atunci când, deja în stadiul de dezvoltare, sunt cunoscute unele interogări frecvente care necesită relații de conectare și a căror viteză de execuție afectează semnificativ funcționarea aplicațiilor. În acest caz, puteți sacrifica normalizarea pentru a accelera execuția unor astfel de interogări.

Un alt tip de aplicație este așa-numita aplicații OLAP (Procesare analitică online (OLAP ) - prelucrarea operațională a datelor analitice ). Acesta este un termen generalizat care caracterizează principiile construcției sisteme de sprijinire a deciziei (Sistem de sprijin pentru decizii - DSS ), depozite de date (Depozitul de date ), sisteme de data mining (Exploatarea datelor ). Astfel de sisteme sunt concepute pentru a găsi dependențe între date (de exemplu, puteți încerca să determinați modul în care volumul vânzărilor de mărfuri este legat de caracteristicile potențialilor cumpărători), pentru a efectua o analiză „ce ar fi dacă…”. Aplicațiile OLAP operează pe cantități mari de date deja acumulate în aplicațiile OLTP, preluate din foi de calcul sau din alte surse de date. Astfel de sisteme se caracterizează prin următoarele caracteristici:

• Date noi sunt adăugate în sistem relativ rar în blocuri mari (de exemplu, o dată pe trimestru, datele bazate pe rezultatele vânzărilor trimestriale sunt descărcate dintr-o aplicație OLTP).
• Datele adăugate în sistem nu sunt de obicei șterse niciodată.
• Înainte de încărcare, datele sunt supuse diferitelor proceduri de „curățare”, datorită faptului că un sistem poate primi date din mai multe surse care au formate de prezentare diferite pentru aceleași concepte, datele pot fi incorecte sau eronate.
• Interogările către sistem sunt nereglementate și, de regulă, destul de complexe. Foarte des, o nouă interogare este formulată de un analist pentru a clarifica rezultatul obținut dintr-o interogare anterioară.
• Viteza de execuție a interogărilor este importantă, dar nu critică.

Datele din aplicațiile OLAP sunt de obicei reprezentate ca unul sau mai multe hipercuburi, ale căror dimensiuni sunt date de referință, iar celulele hipercubului însuși stochează datele reale. De exemplu, puteți construi un hipercub, ale cărui dimensiuni sunt: ​​timpul (în trimestre, ani), tipul de produs și ramurile companiei, iar celulele stochează volumele vânzărilor. Un astfel de hipercub va conține date despre vânzările diferitelor tipuri de mărfuri pe trimestru și divizie. Pe baza acestor date, puteți răspunde la întrebări precum „care divizie are cele mai bune volume de vânzări în acest an?” sau „cum sunt tendințele de vânzări ale diviziilor din regiunea Sud-Vest în acest an în comparație cu anul precedent?”

Din punct de vedere fizic, un hipercub poate fi construit pe baza unui special model de date multidimensionale (MOLAP - OLAP multidimensional ) sau construit folosind un model de date relaționale ( ROLAP - OLAP relațional ).

Revenind la problema normalizării datelor, putem spune că în sistemele OLAP care utilizează modelul de date relaționale (ROLAP), este recomandabil să stocăm datele sub forma unor relații slab normalizate care conțin totaluri de bază precalculate. Redundanța mare și problemele asociate cu aceasta nu sunt înfricoșătoare aici, pentru că actualizarea are loc numai atunci când este încărcată o nouă porțiune de date. În acest caz, ambele date noi sunt adăugate și rezultatele sunt recalculate.

PROCESAREA TRANZACȚIILOR ON LINE OLTP este concepută pentru a servi rapid solicitări relativ simple de la un număr mare de utilizatori. Aceste sisteme necesită protecție împotriva accesului neautorizat, a integrității datelor și a erorilor hardware și de programare.

Acestea se caracterizează prin timpi mici de așteptare pentru ca cererile să fie finalizate.

Domeniul de aplicare: plăți, contabilitate, rezervări, bănci și operațiuni de bursă

Tranzacţie- aceasta este o acțiune finalizată asupra bazei de date din punctul de vedere al utilizatorului.

Sisteme de prelucrare a datelor analitice (PROCESARE A ANALIZĂ ON LINE) OLAP sunt sisteme de sprijin decizional axate pe executarea de interogări mai complexe care necesită prelucrarea statistică a datelor istorice acumulate într-o anumită perioadă de timp. Sistemele analitice includ:

1. instrumente de prelucrare a informațiilor bazate pe metode de inteligență artificială

2. mijloace de prezentare grafică a datelor.

Aceste sisteme sunt determinate de un volum mare de date istorice, permițând extragerea de informații semnificative din ele, de ex. dobândiți cunoștințe din date.

Cerințele privind viteza și calitatea analizei au condus la apariția sistemelor de procesare analitică (OLAP). Eficiența procesării este atinsă prin utilizarea unei tehnologii puternice cu multiprocesor, a metodelor complexe de analiză și a depozitelor de date specializate.

Clasele date de sisteme (OLAP și OLTP), se bazează pe utilizarea unui SGBD, dar tipurile de interogări sunt foarte diferite.

Procesarea tranzacțiilor în sisteme OLTP

Tranzacție - o succesiune indivizibilă de operaţii de manipulare a datelor din perspectiva influenţării bazei de date. Aceasta ar putea fi o operație de citire, ștergere, inserare etc.

Tranzacția implementează o acțiune care este semnificativă din punctul de vedere al utilizatorului, de exemplu, transferul de bani dintr-un cont, rezervarea unui loc sau livrarea unui nou angajat.

O tranzacție trebuie să aibă 4 proprietăți principale:

1. atomicitate, tranzacția trebuie executată ca o singură operațiune de acces la baza de date, trebuie finalizată complet sau deloc efectuată.

2. consistenta, garantează integritatea reciprocă a datelor.

3. izolare, tranzacțiile vor fi executate izolat pe sistemul utilizatorului.

4. durabilitate, dacă tranzacția este finalizată cu succes, atunci modificările pe care le face asupra datelor nu se vor pierde sub nicio formă.

Rezultatul unei tranzacții poate fi al acestuia fixareȘi rollback

Fixare - Aceasta este o acțiune care asigură că toate modificările sunt înregistrate în baza de date.

Rollback- dacă finalizarea normală a tranzacției este imposibilă, baza de date revine la starea inițială, toate modificările sunt anulate.

La derularea înapoi și la efectuarea unei tranzacții, aceasta este utilizată Jurnal de tranzacții,în care sunt salvate toate modificările.

La efectuarea oricărei operațiuni care modifică baza de date, SGBD salvează automat stările rândurilor modificate înainte și după operație în jurnalul de tranzacții. Abia după aceasta, se fac modificări în baza de date.

La derularea înapoi, DBMS utilizează jurnalul de tranzacții pentru a restaura acele rânduri care au fost modificate.

Limitele tranzacției- Aceasta este prima și ultima operațiune inclusă în ea. Se presupune că tranzacția începe cu prima instrucțiune SQL, următoarele instrucțiuni alcătuiesc corpul tranzacției și corpul se poate ramifica:

1. Lucrul de comitere a instrucțiunii SQL

Operator SQL rollback

2. prin simpla completare a extrasului care a numit tranzactia.

Salvați puncte- utilizate în tranzacții lungi, de ex. corpul tranzacției poate defini puncte în care este salvată starea bazei de date.

Utilizarea unei tranzacții este un mecanism eficient pentru organizarea accesului multi-utilizator la o bază de date.

Probleme:

1. cum să eviți pierderea modificărilor din baza de date într-o situație în care mai multe programe citesc aceleași date, le schimbă și le scriu în același loc. Modificările dintr-un program pot fi salvate în baza de date, rezultatele tuturor celorlalte se vor pierde.

2. excludeți posibilitatea citirii modificărilor necommitate, de exemplu, atunci când o tranzacție face modificări în baza de date, acestea sunt citite imediat în alte tranzacții, dar apoi o altă tranzacție este întreruptă de operatorul rollback.

Pentru a elimina acest lucru, utilizați serializarea (procesare în comun):

1. tranzacția nu poate accesa datele neangajate

2. rezultatul executării în comun a tranzacţiilor trebuie să fie echivalent cu rezultatul succesiunii lor de executare.

Într-un SGBD modern, serializarea tranzacțiilor este implementată prin mecanism de blocare:În timpul execuției tranzacției 1, SGBD blochează partea din baza de date pe care o accesează tranzacția 1. Blocarea este menținută până la comiterea tranzacției 1, dacă în acest moment o altă tranzacție 2 accesează datele blocate, atunci tranzacția 2 este suspendată până la finalizarea tranzacției 1;

Blocarea tranzacțiilor

Lăsați tranzacția t1 să actualizeze relația - o1. În continuare, această tranzacție t1 încearcă să modifice relația o2, care a fost blocată anterior de tranzacția t2. Tranzacția t1 este transferată în starea de așteptare până când blocarea relației o2 este eliberată; în același moment, tranzacția t2 încearcă să modifice datele relației o1, care a fost blocată anterior de tranzacția t1. DBMS este forțat să pună tranzacția T2 în starea de așteptare, prin urmare, apare o situație de blocare a tranzacției.

SGBD-ul verifică periodic blocarea și dacă există blocaje, atunci una dintre tranzacții este anulată forțat.

Instrumente de recuperare în caz de dezastru

Una dintre principalele cerințe pentru sistemele informaționale moderne este fiabilitatea stocării datelor. SGBD-ul trebuie să poată restaura baza de date după orice defecțiuni hardware sau software. Există un jurnal de tranzacții pentru asta. Principiul recuperării - rezultatele tranzacției înainte de eșec trebuie restabilite, rezultatele necomite prin tranzacție trebuie șterse.

Dacă conținutul memoriei externe este distrus fizic, atunci stocarea datelor duplicat este implementată pentru a elimina acest lucru.

OLTP(prelucrarea tranzacțiilor în timp real) este implicată în funcționarea unui anumit sistem. OLTP se caracterizează printr-un număr mare de tranzacții online scurte (INSERT, UPDATE, DELETE). Accentul principal pentru sistemele OLTP este procesarea foarte rapidă a interogărilor, asigurând integritatea datelor în medii cu acces multiplu și eficiența măsurată prin tranzacții pe secundă. O bază de date OLTP are date detaliate și actuale, iar schema utilizată pentru stocarea bazelor de date tranzacționale este un model de entitate (de obicei 3NF). Include Interogări asociate cu o înregistrare individuală, cum ar fi „Actualizare e-mail” într-o bază de date a companiei.

OLAP(prelucrare analitică on-line) se ocupă de date istorice sau de arhivă. OLAP se caracterizează printr-un volum relativ scăzut de tranzacții. Interogările sunt adesea foarte complexe și implică agregari. Pentru sistemele OLAP, timpul de răspuns este o măsură a eficienței. Aplicațiile OLAP sunt utilizate pe scară largă de tehnicile de data mining. O bază de date OLAP stochează date istorice agregate stocate în scheme multidimensionale (de obicei o schemă stea). Uneori, o interogare trebuie să acceseze o cantitate mare de date din înregistrările de management, cum ar fi profiturile companiei dvs. anul trecut.

Raspuns foarte scurt:

Diferite baze de date au utilizări diferite. Nu sunt expert în baze de date. Când am dubii, folosesc doar SQL.

Răspuns scurt:

Să ne uităm la două exemple de scenarii:

Scenariul 1:

Construiți un magazin online/un site web și doriți să puteți:

• stocați datele utilizatorului, parolele, tranzacțiile anterioare...
• stocați produsele curente și prețul asociat acestora.

Doriți să găsiți date pentru un anumit utilizator, să îi schimbați numele... Practic efectuați operațiuni de INSERT, UPDATE, DELETE asupra datelor utilizatorului. La fel cu produsele etc.

Vrei să poți face tranzacții, poate implicând un utilizator care achiziționează un produs (aceasta este o relație). Atunci OLTP este probabil o potrivire bună (gândiți-vă la SQL RDBMS).

Scenariul 2:

Ai un magazin online/site web și vrei să calculezi lucruri de genul

• „cheltuiala totală a banilor pentru toți utilizatorii”
• „care este cel mai bine vândut produs”

Aceasta este în zona de analiză/business intelligence, deci OLAP este probabil mai potrivit.

Dacă te gândești în termeni de „Ar fi bine să știi cum/ce/cât”... și include un întreg „obiect” de unul sau mai multe feluri (ca toți utilizatorii și majoritatea produselor să știi cât a fost cheltuit în total), atunci OLAP este probabil , se potrivește mai bine.

Răspuns mai lung:

Desigur, nu este atât de simplu. Deci trebuie să punem mai întâi etichete mici precum OLTP și OLAP. Fiecare bază de date trebuie evaluată independent la final.

Deci, care ar putea fi diferența fundamentală dintre OLAP și OLTP?

Ei bine, bazele de date trebuie să stocheze date undeva. Nu este surprinzător că modul în care sunt stocate datele reflectă în mare măsură posibila utilizare a bazei de date menționate. Datele sunt de obicei stocate pe un hard disk. Gândiți-vă la hard disk ca fiind cea mai mare bucată de hârtie pe care putem citi și scrie. Există două moduri de a ne organiza lecturile și scrierile, astfel încât să poată fi eficiente și rapide.

Una dintre metode- faceți o carte un pic ca o carte de telefon. Pe fiecare pagină a cărții stocăm informații despre un anumit utilizator. Acum că este frumos, putem găsi cu ușurință informații pentru un anumit utilizator! Doar du-te la pagina! Putem avea chiar și o pagină specială la început care să ne spună pe ce pagină se află utilizatorii dacă vrem. Dar, pe de altă parte, dacă am vrea să aflăm, să zicem, câți bani au cheltuit toți utilizatorii noștri, ar trebui să citim fiecare pagină, adică. toata cartea! Acesta va fi un registru de lucru/bază de date pe rând (OLTP). Pagina opțională de la început va fi indexul.

Altă cale folosiți o foaie mare de hârtie - faceți o carte de conturi. Nu sunt contabil, dar imaginați-vă dacă am avea o pagină pentru „cheltuieli”, „cumpărări”... Acest lucru este bine pentru că acum putem interoga foarte repede lucruri precum „dați-mi venit total” (doar citiți „cumpărări” „ "). De asemenea, putem cere lucruri mai interesante precum „da-mi zece produse vândute" și totuși să avem performanțe acceptabile. Dar acum gândește-te cât de dureros ar fi să găsești cheltuieli pentru un anumit utilizator. Ar trebui să parcurgi tot enumerați toate cheltuielile și filtrați datele acelui utilizator și apoi rezumați-le.

Rezultă că:

• Bază de date

OLTP este destinat să fie utilizat pentru multe tranzacții mici și servește de obicei ca „sursă unică de adevăr”.

Pe de altă parte, bazele de date

OLAP este mai potrivit pentru analiză, data mining, mai puține interogări, dar de obicei mai mare (funcționează cu mai multe date).

Este puțin mai implicat decât atât, desigur, și aceasta este o imagine de ansamblu de 20.000 de picioare a modului în care diferă bazele de date, dar mă împiedică să mă pierd într-o mare de acronime.

Apropo de acronime:

Diferența este destul de simplă.

OLTP (procesarea tranzacțiilor on-line).

OLTP este o clasă de sisteme informatice care facilitează și gestionează aplicațiile tranzacționale. OLTP a fost, de asemenea, utilizat pentru a aborda procesarea în care sistemul răspunde imediat la solicitările utilizatorilor. Aplicațiile de procesare a tranzacțiilor pe internet au un randament ridicat și necesită o intensitate de intrare sau actualizare în gestionarea bazelor de date. Câteva exemple de sisteme OLTP includ sisteme de introducere a comenzilor, vânzări cu amănuntul și tranzacții financiare.

OLAP (prelucrare analitică on-line)

OLAP face parte din categoria mai largă de business intelligence, care include, de asemenea, baze de date relaționale, raportare și data mining. Aplicațiile OLAP tipice includ raportarea afacerilor pentru vânzări, marketing, raportare de management, management al proceselor de afaceri (BPM), bugetare și prognoză, raportare financiară și domenii similare.

OLTP (O n- L ine T răzbunare P prelucrare) vs OLAP (O n- L ine A analitic P)p>

Putem împărți sistemele IT în cele tranzacționale ( OLTP) și analitice ( OLAP). În general, se poate presupune că OLTP sistemele furnizează date de intrare către depozitele de date, în timp ce sistemele OLAP ajuta la analiza.

Următorul tabel rezumă diferențele majore dintre proiectarea sistemului OLTP și OLAP.