Conceptul de depozit de date. Stocarea datelor fizice și virtuale

Conceptul de depozit de date

Un „depozit de date” este o colecție de date specifică domeniului, limitată în timp și imuabilă pentru a sprijini procesul de luare a deciziilor de management.

Datele din depozit provin din sisteme operaționale (sisteme OLTP), care sunt concepute pentru a automatiza procesele de afaceri. În plus, stocarea poate fi completată din surse externe, de exemplu, rapoarte statistice, diverse cărți de referință etc. Pe lângă informații detaliate, depozitul de date conține agregate, de ex. rezumând informații precum sumele vânzărilor, cantitățile, costurile totale etc.

Depozitul de date fiscale trebuie privit ca un centru de informare în care calculul impozitelor amânate este automatizat, informațiile din surse externe sunt primite și stocate, iar datele sunt convertite într-un format ușor de utilizat. Un astfel de depozit oferă o platformă pentru stocarea datelor fiscale exacte și în timp util, care pot fi preluate și transmise către aplicatii externeîn scopuri de analiză, audit, planificare și prognoză.

Depozitul de date este un depozit resurse informaționaleși oferă consolidarea datelor întreprinderii în scopuri de raportare și analiză. Datele și informațiile, atât operaționale, cât și neoperaționale, sunt introduse în depozit, de obicei folosind instrumente ETL din surse, date pe măsură ce devin disponibile sau în mod regulat. Transformarea datelor vă permite să procesați cererile și să le analizați în timp util, ceea ce simplifică și accelerează procesul de onorare a solicitărilor de informații primite inițial din alte surse.
Beneficiile stocării includ capacitatea de a transforma datele în informații de calitate necesare pregătirii raportare fiscalăși conformitatea fiscală, pentru utilizatorii de toate nivelurile. Orice parte interesată - clienți, parteneri, angajați, manageri și directori - poate primi conținut interactiv oricând și oriunde.
Simpla existență a unei singure surse de informații pentru întocmirea rapoartelor fiscale și conformarea fiscală este un mare pas înainte pentru multe autorități fiscale.

De ce trebuie să construiți depozite de date - la urma urmei, acestea conțin informații evident redundante, care se află deja în bazele de date sau fișierele sistemelor de operare? Este imposibil sau foarte dificil să analizezi direct datele sistemelor operaționale. Acest lucru se datorează diverselor motive, inclusiv fragmentării datelor și stocării acestora în formate ale diferitelor SGBD. Dar chiar dacă într-o întreprindere toate datele sunt stocate pe un server central de baze de date, un analist aproape sigur nu va înțelege structurile lor complexe, uneori confuze.

Astfel, sarcina depozitului este de a furniza „materii prime” pentru analiză într-un singur loc și într-o structură simplă, de înțeles.

Mai există un motiv care justifică apariția unei stocări separate - interogările analitice complexe la informațiile operaționale încetinesc activitatea curentă a companiei, pentru o lungă perioadă de timp blocând tabele și confiscând resursele serverului.

O stocare nu este neapărat o acumulare gigantică de date - principalul lucru este că este convenabil pentru analiză.

Conceptul de depozit de date

Autorul conceptului de depozite de date ( Depozitul de date) este B. Inmon, care a definit depozitele de date ca: „seturi de date istorice specifice domeniului, integrate, imuabile, organizate în scopuri de asistență managerială” concepute pentru a acționa ca „singura și singura sursă de adevăr” care oferă managerilor și analiștilor informații fiabile necesare analizei operaționale și luării deciziilor. Schema depozitului de date poate fi reprezentată după cum urmează:

Implementarea fizică a acestei scheme poate fi foarte diversă. Să luăm în considerare prima opțiune - un depozit de date virtual, acesta este un sistem care oferă acces la un sistem convențional de înregistrare care emulează lucrul cu un depozit de date. Stocarea virtuală poate fi organizată în două moduri. Puteți crea o serie de „vizualizări” în baza de date sau utilizați mijloace speciale acces la baze de date (de exemplu, produse desktop OLAP).

Deoarece construirea unui depozit de date este un proces complex care poate dura câțiva ani, unele organizații construiesc în schimb un data mart care conține informații pentru anumite departamente. De exemplu, un magazin de date de marketing poate conține numai informații despre clienți, produse și vânzări și să nu includă planuri de aprovizionare. Mai multe magazine de date departamentale pot coexista cu depozitul de date subiacent, oferind o vedere parțială a conținutului depozitului. Data mart-urile sunt construite mult mai rapid decât un depozit, dar mai târziu pot cauza probleme serioase de integrare dacă planificarea inițială nu a fost făcută având în vedere întregul model de afaceri. Aceasta este a doua cale.

Construirea unui depozit de date de întreprindere cu drepturi depline se face de obicei într-o arhitectură cu trei niveluri. La primul nivel sunt localizate diverse surse de date - sisteme interne de înregistrare, sisteme de ajutor, surse externe (date agentii de stiri, indicatori macroeconomici). Al doilea nivel conține un depozit central, unde sunt colectate informații din toate sursele de la primul nivel și, eventual, un depozit de date operaționale care nu conține date istorice și îndeplinește două funcții principale.

Conceptul de depozit de date se bazează pe două idei fundamentale:

1) integrarea datelor detaliate deconectate anterior într-un singur depozit de date, reconcilierea lor și, eventual, agregarea:

· Arhivele istorice;

· Date din ODS tradiționale;

· Date din surse externe.

2) separarea seturilor de date utilizate pentru prelucrarea operațională și a seturilor de date utilizate pentru rezolvarea problemelor de analiză.

Scopul conceptului de depozit de date este de a afla cerințele pentru datele plasate în baza de date țintă a depozitului de date (Tabelul 1), de a determina principiile generale și etapele construcției acestuia, principalele surse de date, de a da recomandări. cu privire la modul de rezolvare a potențialelor probleme care apar în timpul descărcării, curățării, coordonării, transportului și încărcării lor în baza de date țintă.

Tabelul 1. Cerințe de bază pentru datele din Data Warehouse.

Orientarea subiectului	Toate datele despre un anumit subiect (obiect comercial) sunt colectate (de obicei dintr-un set diverse surse), curățate, reconciliate, completate, agregate și prezentate într-o formă unică, convenabilă pentru utilizarea lor în analiza de afaceri.
Integrare	Toate datele despre diferite obiecte de afaceri sunt coerente reciproc și stocate într-un singur depozit corporativ.
Imuabilitate	Datele originale (istorice), după ce au fost convenite, verificate și introduse în depozitul corporativ, rămân neschimbate și sunt utilizate exclusiv în modul citire.
Suport cronologic	Datele sunt structurate cronologic și reflectă istoricul pe o perioadă suficientă de timp pentru a finaliza sarcinile de analiză și prognoză ale afacerii.

Conceptul de depozit de date este datele în sine. După ce sistemul tradițional de procesare a datelor (DDS) este implementat și începe să funcționeze, acesta devine exact același obiect independent al lumii reale, ca orice proces de fabricație... Iar datele, care este unul dintre produsele finale ale unei astfel de producții, au exact aceleași proprietăți și caracteristici ca orice produs industrial: termen de valabilitate, locație de depozitare (stocare), compatibilitate cu datele din alte industrii (ODS), valoare de piață, transportabilitate. , completitudine, întreținere etc.

Din acest punct de vedere sunt luate în considerare datele din depozitele de date. Adică, scopul aici nu este modalitățile de descriere și afișare a obiectelor. domeniul subiectului, ci datele în sine, ca obiect independent al domeniului subiectului, generate ca urmare a funcționării sistemelor informaționale create anterior.

Pentru intelegere corecta Acest concept necesită înțelegerea următoarelor puncte fundamentale:

· Conceptul de depozite de date nu este un concept de analiză a datelor, ci mai degrabă un concept de pregătire a datelor pentru analiză.

· Conceptul de depozite de date nu predetermina arhitectura sistemului analitic tinta. Vorbește despre ce procese ar trebui efectuate pe sistem, dar nu despre unde exact și cum ar trebui efectuate aceste procese.

· Conceptul de depozite de date implică nu doar o singură vedere logică a datelor organizației, ci și implementarea unei singure surse de date integrate.

în afară de carte de referință unificată metadate, mijloace de descărcare, agregare și reconciliere a datelor, conceptul de depozite de date presupune: integrare, imuabilitate, suport istoric și consistența datelor. Și dacă primele două proprietăți (integrare și imuabilitate) afectează modurile de analiză a datelor, atunci ultimele două (suport istoric și consistență) restrâng semnificativ lista sarcinilor analitice de rezolvat.

Fără sprijinul cronologiei (prezența datelor istorice), este imposibil să vorbim despre rezolvarea problemelor de prognoză și analiză a tendințelor. Dar cele mai critice și dureroase probleme sunt cele legate de reconcilierea datelor.

Principala cerință a unui analist nu este atât eficiența, cât fiabilitatea răspunsului. Dar credibilitatea este determinată în cele din urmă de consecvență. Până nu se lucrează la acordul reciproc al valorilor datelor din diverse surse, este dificil să vorbim despre fiabilitatea acestora.

Adesea, un manager se confruntă cu o situație în care sisteme diferite pot oferi și, de obicei, pot oferi un răspuns diferit la aceeași întrebare. Acest lucru se poate datora naturii asincrone a momentelor de modificare a datelor, diferențelor de interpretare a acelorași evenimente, concepte și date, modificări în semantica datelor în procesul de dezvoltare a domeniului subiectului, erori elementare în timpul introducerii și procesării. , pierderea parțială a fragmentelor individuale de arhive etc. Evident, nu este realist să se țină cont și să se determine în prealabil algoritmi pentru rezolvarea tuturor coliziunilor posibile. În plus, este nerealist să o faci în modul de operare, dinamic, direct în procesul de formare a unui răspuns la o solicitare.

Informații similare.

Rețineți că depozitarea datelor este o tehnologie în evoluție. Ca pentru oricare dezvoltarea tehnologiei, ar trebui să existe un anumit grad de prudență atunci când se evaluează acțiunile producătorilor de software HD care încearcă să se poziționeze în rândul concurenților. De exemplu, discuții despre dimensiunea HD - de la ce dimensiune depozit de date poate fi considerat un depozit în sine? Cu 50 GB? Rețineți că în unele domenii de cercetare, dimensiunea matricei analizate poate fi foarte mică. Pur și simplu nu există date. Și analiza unei astfel de matrice este posibilă.

Să luăm în considerare principalele elemente ale conceptului de depozitare de date.

Extragerea datelor din sistemele de operare

Elementul principal al conceptului de depozitare a datelor este acela că cel mai eficient acces la datele stocate pentru analiză poate fi asigurat numai dacă este separat de sistemul de operare (tranzacțional), adică. datele din sistemul de operare trebuie mutate într-un alt sistem separat sistem de stocare a datelor... Această abordare este de natură istorică. Din cauza limitărilor hardware și tehnologiei, pentru a asigura performanța unui sistem tranzacțional, datele au fost arhivate pe benzi magnetice sau pe medii în afara unui astfel de sistem. Problema accesului la acestea a necesitat anumite soluții tehnologice.

Trebuie remarcat faptul că odată cu dezvoltarea conceptului, poziția de separare a datelor pentru analiză de date în sistemul OLTP a suferit puține modificări. A devenit mai formală și îmbogățită prin utilizarea fondurilor analiza multivariată date. În prezent, HD poate fi construit pe sistemul OLTP existent și deasupra acestuia și ca obiect independent. Acest lucru ar trebui să fie decis de managerul de proiect IT ca parte a alegerii arhitecturii HD.

Necesitatea de a integra date din mai multe sisteme OLTP

Sisteme de depozitare a datelor cel mai util atunci când datele pot fi preluate din mai multe sisteme OLTP. Atunci când datele trebuie colectate din mai multe aplicații de afaceri, este firesc să presupunem că acest lucru ar trebui făcut într-o locație diferită de cea în care au fost localizate aplicațiile originale. Chiar înainte de crearea HD structurat, analiștii, în multe cazuri, combinau datele extrase din sisteme diferite, într-o singură foaie de calcul sau bază de date. HD poate reuni foarte eficient date din aplicații specifice, cum ar fi vânzări, marketing, finanțe, producție, ținând cont de acumularea acestora, de ex. salvați seria temporală a indicatorilor cheie de afaceri - așa-numitele date istorice.

Rețineți că una dintre proprietățile datelor colectate din diferite aplicații și utilizate de analiști este capacitatea de a interoga acele date. În multe CD-uri, atributul „timp” este un criteriu natural pentru filtrarea datelor. Analiștii sunt interesați de comportamentul datelor din seria temporală care caracterizează procesele de afaceri.

Scopul multora sisteme de stocare este o prezentare generală a activităților de tip „an după an”. De exemplu, puteți compara vânzările din primul trimestru al acestui an cu vânzările din primul trimestru al anilor anteriori. Timpul în HD este un atribut fundamental interogări încrucișate... De exemplu, un analist ar putea încerca să evalueze impactul unei noi campanii de marketing anumite perioade când se iau în considerare vânzările pentru aceleași perioade. Abilitatea de a stabili și înțelege corelația dintre activitățile diferitelor departamente din organizație este adesea citată ca unul dintre cele mai importante argumente despre beneficii. sisteme de stocare.

Sistem de depozitare a datelor nu numai că poate funcționa ca o platformă eficientă pentru consolidarea datelor din diferite surse, dar poate și colecta versiuni multiple de date dintr-o singură aplicație. De exemplu, dacă o organizație a trecut la un software nou, atunci CD-ul va salva datele necesare din sistemul anterior... În acest sens sistem de stocare a datelor poate servi ca mijloc de integrare a datelor moștenite, menținând în același timp continuitatea analizei la schimbarea platformei software și hardware a sistemului OLTP.

Diferențele dintre prelucrarea datelor tranzacționale și analitice

Unul dintre cele mai importante motive pentru separarea datelor pentru analiză de datele OLTP a fost potențiala degradare a performanței interogărilor la efectuarea proceselor de analiză a datelor. Performanta ridicata iar timpii scurti de răspuns sunt parametri critici ai sistemelor OLTP. Pierderea de performanță și cheltuielile generale asociate cu procesarea interogărilor predefinite sunt de obicei ușor de estimat. Pe de altă parte, interogările pentru analiza datelor în DW sunt dificil de prezis și, prin urmare, dificil de estimat timpul de execuție al unei interogări.

Sistemele OLTP sunt proiectate pentru a executa în mod optim interogări predefinite în mod aproape în timp real. Pentru astfel de sisteme, de obicei, puteți determina distribuția sarcinii în timp, puteți determina timpul de încărcare maximă, puteți evalua interogările critice și le puteți aplica proceduri de optimizare susținute de SGBD-urile moderne. De asemenea, este relativ ușor să determinați maximul timp permis raspuns catre cerere specificăîn sistem. Costul timpului de răspuns al unei astfel de solicitări poate fi estimat pe baza raportului dintre costul efectuării operațiunilor I/O/costul costului traficului de rețea. De exemplu, pentru un sistem de procesare a comenzilor, puteți specifica numărul de manageri de casă activi și numărul mediu de comenzi pentru fiecare oră de funcționare.

Deși multe dintre întrebările și rapoartele din sistem de depozitare a datelor sunt predefinite, este aproape imposibil de prezis cu acuratețe comportamentul indicatorilor de sistem (timp de răspuns, trafic de rețea etc.) atunci când sunt executați. Procesul de explorare a datelor în HD este adesea imprevizibil. Liderii de toate gradele sunt pricepuți să pună întrebări neașteptate. În cursul analizei, pot apărea interogări ad-hoc, care sunt cauzate de rezultate neașteptate sau de neînțelegere de către utilizatorul final a modelului de date utilizat. Mai mult, multe dintre procesele de analiză tind să ia în considerare multe aspecte ale operațiunilor unei organizații, în timp ce sistemele OLTP sunt bine segmentate în funcție de activitate. Utilizatorul poate avea nevoie de mai mult informatii detaliate decât ceea ce este stocat în tabelele rezumative. Acest lucru poate duce la îmbinări a două sau mai multe tabele uriașe, rezultând un tabel temporar egal cu produsul numărului de rânduri din fiecare tabel și degradând dramatic performanța sistemului.

Datele din sistemele de depozitare de date rămân neschimbate

O altă proprietate cheie a datelor în sistem de depozitare a datelor consta in faptul ca datele din CD raman neschimbate. Aceasta înseamnă că, după ce datele sunt plasate în CD, acestea nu pot fi modificate. De exemplu, starea comenzii nu se modifică, dimensiunea comenzii nu se modifică etc. Această caracteristică a CD-ului este de mare importanță pentru selectarea tipurilor de date atunci când le plasați în CD, precum și pentru alegere a momentului în care datele trebuie introduse în CD. Ultima proprietate este numită granularitatea datelor.

Luați în considerare ce înseamnă ca datele să fie imuabile. Într-un sistem OLTP, obiectele de date trec prin modificări constante ale atributelor lor. De exemplu, o comandă își poate schimba starea de multe ori înainte de a fi plasată. Sau, atunci când un produs este asamblat pe o linie de asamblare, îi sunt aplicați mulți pași de fabricație. În general, datele dintr-un sistem OLTP trebuie încărcate în sistemul de stocare a datelor numai atunci când procesarea acestuia în cadrul proceselor de afaceri este complet finalizată. Aceasta ar putea însemna finalizarea unei comenzi sau a unui ciclu de produs. Odată ce comanda este finalizată și expediată, este puțin probabil să-și schimbe starea. Sau, odată ce un produs este asamblat și predat depozitului, este puțin probabil să ajungă în prima etapă a ciclului de asamblare.

Alții bun exemplu poate exista plasarea pe CD a unui instantaneu al datelor aflate în schimbare constantă în anumite momente în timp. Modulul de control al stocurilor OLTP poate modifica inventarul în aproape fiecare tranzacție; este imposibil să înregistrezi toate aceste modificări pe CD. Puteți specifica ca un astfel de instantaneu al stării stocului să fie introdus în CD în fiecare săptămână sau zilnic, în modul care ar fi adecvat pentru analiza într-o anumită organizație. Datele unui astfel de instantaneu sunt, desigur, imuabile.

După ce datele sunt introduse în CD, modificarea lor este posibilă în cazuri extrem de rare. Este foarte dificil (deși există astfel de încercări) să păstrezi datele dinamice pe un CD. Sarcina de sincronizare date schimbate frecvent în sistemele OLTP și este încă departe de a fi o soluție acceptabilă. De asemenea, trebuie menționat aici că plasarea datelor în schimbare dinamică în CD face în prezent obiectul unor cercetări intense. De exemplu, dezvoltarea procedurilor de susținere a tabelelor de dimensiuni care se schimbă lent în HD este o sarcină care își găsește deja soluția la nivelul software al producătorilor de soluții din domeniul HD.

Datele din depozitul de date sunt stocate mult mai mult timp decât în ​​sistemele OLTP

Majoritatea sistemelor OLTP arhivează datele imediat ce acestea devin inactive. De exemplu, o comandă poate deveni inactivă după ce a fost finalizată; un cont bancar poate deveni inactiv după ce a fost închis. Motivul principal pentru arhivarea datelor inactive este performanța sistemului OLTP (de ce stocați datele dacă nu sunt accesate). Cantități mari de astfel de date pot degrada semnificativ performanța interogărilor, presupunând că sunt procesate numai datele active. Pentru a procesa astfel de date, SGBD oferă diverse proceduri de împărțire a tabelelor de bază în secțiuni. Pe de altă parte, deoarece CD-urile sunt destinate, în special, să fie o arhivă pentru datele OLTP, datele sunt stocate în ele pentru o perioadă foarte lungă.

De fapt, proiectul sisteme de stocare poate începe fără niciun plan specific pentru arhivarea datelor de pe CD. Costul de întreținere a datelor după ce sunt încărcate în stocare este scăzut. Cel mai mare cost al creării unui depozit revine transformarea datelor(transfer de date) și curățarea acestora (scrub de date). Păstrarea datelor timp de cinci ani sau mai mult este tipică pentru sisteme de stocare... Prin urmare, procedurilor de arhivare a datelor de pe CD în etapele de creare și funcționare a acestora la începutul perioadei nu li se poate acorda mult timp. Mai ales când te gândești la scăderea prețurilor la hardware-ul computerelor.

Cu alte cuvinte, separarea datelor OLTP de datele de analiză este un concept fundamental în depozitarea datelor. În zilele noastre, afacerile sunt imposibile fără a lua decizii informate. Astfel de soluții pot fi construite pe baza unei analize cuprinzătoare a rezultatelor implementării proceselor de afaceri în organizație și a activităților organizației pe piața de bunuri și servicii. Timpul pentru luarea deciziilor în condiții moderne și fluxuri de informații este în scădere. Rolul de creare și întreținere sisteme de analiză a datelor bazat pe noi tehnologia Informatiei crește. HD este una dintre verigile principale în aplicarea unor astfel de tehnologii.

Poate fi distins următoarele motive pentru partajarea datelor sisteme de stocareși sisteme operaționale de prelucrare a datelor(fig. 1.5).

• Diferența dintre cerințele țintă pentru și sistemele OLTP.
• Necesitatea de a colecta date pe CD din diverse surse de informații, de ex. dacă datele sunt generate în sistemul OLTP însuși, atunci pt sisteme de stocareîn majoritatea cazurilor, datele sunt generate în afara acestuia.
• Când datele intră în CD, acestea rămân neschimbate în majoritatea cazurilor.
• Datele de pe CD sunt stocate mult timp.

Orez. 1.5.

Transformarea logică a datelor OLTP și modelarea datelor

Datele dintr-un CD sunt transformate în mod logic atunci când sunt transferate pe acesta dintr-un sistem OLTP sau altă sursă externă. Problemele asociate cu transformarea logică a datelor la transferul lor în depozitul de date pot necesita analize și eforturi semnificative ale designerilor. Arhitectură sisteme de stocareși modelele HD sunt esențiale pentru succesul unor astfel de proiecte. Mai jos vom lua în considerare câteva concepte fundamentale ale teoriei relaționale a bazelor de date, care nu sunt complet aplicabile sisteme de stocare... Chiar dacă majoritatea CD-urilor sunt implementate pe baze de date relaționale, unele dintre principiile de bază ale bazelor de date relaționale sunt încălcate în mod deliberat atunci când se creează un model logic și fizic de CD-uri.

Modelul de date HD își definește structura logică și fizică. Spre deosebire de datele pur și simplu arhivate, în acest caz este imposibil să faci fără proceduri detaliate de modelare. O astfel de modelare în etapele incipiente ale proiectării unui sistem de depozitare este necesară pentru a crea un sistem eficient care captează date din toate procesele și procedurile de afaceri ale organizației.

Procesul de modelare a datelor ar trebui să structureze datele din CD într-o formă independentă de model relațional datele sistemului care furnizează datele. După cum se discută mai jos, modelul HD este probabil să fie mai puțin normalizat decât modelul sursei de date OLTP.

În sistemele OLTP, datele din diferite subsisteme se pot suprapune semnificativ. De exemplu, informațiile despre dezvoltarea produsului sunt utilizate în diferite forme în multe subsisteme ale unui sistem OLTP. Sistem de depozitare a datelor ar trebui să combine toate aceste date într-un singur sistem. Unele dintre atributele obiectului care sunt esențiale pentru sistemul OLTP nu vor fi necesare pentru HD. Pot apărea noi atribute pe măsură ce entitatea din CD își schimbă calitatea. Cerința principală este ca toate datele din CD să participe la procesul de analiză.

Modelul de date HD ar trebui extins și structurat astfel încât să poată fi adăugate date din diferite aplicații. Un proiect HD în majoritatea cazurilor nu poate include date din toate aplicațiile de afaceri posibile ale unei organizații. De obicei, cantitatea de date din CD crește în mod incremental: datele sunt extrase din sistemele OLTP și adăugate la CD în anumite porțiuni. Încep prin a stoca date deosebit de importante, apoi își măresc în mod sistematic volumul după cum este necesar.

Modelul de depozit de date se adaptează la structura afacerii

Următorul punct important constă în faptul că modelul logic al HD-ului este adaptat la structura de business (axat pe tema), și nu la agregarea modelelor logice ale aplicațiilor specifice. Entitățile (obiectele) suportate în CD sunt similare cu entitățile (obiectele) afacerii - cum ar fi clienții, produsele (bunurile), comenzile și distribuitorii. În cadrul unor departamente specifice ale organizației, poate exista o vedere foarte restrânsă asupra obiectelor afacerii organizației, de exemplu, despre clienți. De exemplu, o echipă de deservire a creditelor bancare poate ști ceva despre un client numai în contextul unuia sau mai multor împrumuturi emise. O altă divizie a aceleiași bănci poate ști despre același client în context cont de depozit... Prezentarea datelor clienților în CD este mult mai mare decât cea a unei anumite unități bancare. Clientul din CD reprezintă clientul băncii în toate relațiile sale cu banca. Din punctul de vedere al teoriei relaționale, setul de bază de dependențe funcționale suportate în baza de date se schimbă.

CD-ul ar trebui să fie construit pe atributele entităților de afaceri (orientate pe subiect), culegând date despre aceste entități din diverse surse. Structura de date a oricărei surse de date unice este probabil să fie inadecvată pentru HD. Despre structura datelor aplicație specifică factori precum:

• un fel de proces de afaceri specific. Deci, în subsistem automatizat structura datelor privind achizițiile poate fi dictată de natura procedurilor comerciale de achiziții într-un anumit sector de piață;
• influența modelului sisteme de operare... De exemplu, aplicație sursă poate fi destul de vechi și ține cont de dezvoltarea modelului de date prin modificarea structurii bazei de date a aplicației. Multe dintre aceste modificări pot fi prost documentate;
• limitări ale platformei software și hardware. Este posibil ca o structură logică de date să nu suporte unele dintre relațiile logice dintre date sau poate avea limitări din cauza limitărilor platformei hardware și software.

Modelul HD nu este legat de constrângerile modelelor de date sursă. Pentru aceasta, ar trebui dezvoltat un model care să reflecte structura afacerii organizației, și nu structura procesului de afaceri. Astfel de model extins datele trebuie să fie înțelese atât pentru analiști, cât și pentru manageri. Astfel, designerul de CD trebuie să ajusteze obiectele CD-ului la structura de afaceri a organizației, ținând cont de procesele de afaceri și procedurile de afaceri ale acesteia.

Conversia informațiilor care descriu starea obiectelor din sistemul OLTP

Următorul punct important este că înainte de a plasa datele în HDD, acestea trebuie transformate. Majoritatea datelor dintr-un sistem OLTP sau altă sursă externă nu pot fi acceptate în HD. Multe dintre atributele obiectului dintr-un sistem OLTP sunt foarte dinamice și se modifică în mod constant. Multe dintre aceste atribute nu sunt încărcate în CD, în timp ce alte atribute sunt statice în timp și sunt încărcate în CD. Un CD nu trebuie să conțină informații despre obiecte care sunt dinamice și în permanență în stare de modificare.

Pentru a înțelege ce înseamnă să pierzi informații care descriu Starea curenta obiect, luați în considerare un exemplu de sistem de gestionare a comenzilor care urmărește starea inventarului pe măsură ce o comandă este completată. Mai întâi, să ne uităm la entitatea Comanda din sistemul OLTP. O comandă poate trece prin mai multe stări sau condiții diferite înainte de a fi finalizată și achiziționată stare finalizată... Starea comenzii poate indica faptul că este gata pentru a fi completată, că comanda este în curs de finalizare, returnată pentru revizuire, gata pentru expediere etc. O anumită comandă poate trece prin multe stări, care se reflectă în starea comenzii și sunt determinate de procesele de afaceri care i-au fost aplicate. Este practic imposibil să transferați toate atributele unui astfel de obiect pe CD. Sistem de depozitare a datelor ar trebui să conțină probabil doar un instantaneu final al unui obiect, cum ar fi o comandă. Astfel, obiectul „Comanda” trebuie transformat pentru a fi plasat în CD. Apoi, în CD, pot fi colectate informații despre multe obiecte de tip „comandă” și poate fi construit obiectul CD-ului final, „Comandă”.

Să ne uităm la un exemplu mai complex transformarea datelor la gestionarea stocului de mărfuri în sistemul OLTP. Stocul se poate schimba cu fiecare tranzacție. Cantitatea unui anumit produs din depozit poate fi redusă printr-o tranzacție a subsistemului de completare a comenzilor sau mărită la sosirea produsului achiziționat. Dacă sistemul de procesare a comenzilor efectuează zeci de mii de tranzacții pe zi, atunci nivelul real de inventar din baza de date este probabil să aibă mai multe stări și va fi capturat în multe instantanee în timpul acelei zile. Este imposibil să comiți toate aceste modificări permanente în baza de date și să le transferi pe CD. Afișarea unui astfel de comportament al unui obiect în sistem - sursa de date este încă una dintre problemele nerezolvate în sisteme de stocare... Există o serie de abordări pentru a rezolva această problemă. De exemplu, puteți captura periodic instantanee la nivel de stoc pe CD.

Această abordare poate fi aplicată unei porțiuni foarte mari de date din sistemele OLTP. La rândul său, o astfel de soluție va presupune o serie de sarcini legate de alegerea perioadei de timp, cantitatea de date care trebuie preluată etc. Astfel, majoritatea datelor despre starea obiectelor din sistemul OLTP nu pot fi transferate direct pe CD. Ele trebuie convertite la nivel logic.

Denormalizarea modelului de date

Următorul punct în proiectarea HD-urilor relaționale este de a decide cât de important este în HD să urmeze principiile teoriei relaționale, și anume: să permită denormalizarea modelului, în special, să crească performanța interogării. Înainte de a ne uita la denormalizarea unui model de date în contextul depozitării de date, să ne amintim pe scurt principalele puncte ale teoriei bazelor de date relaționale și proces de normalizare... E.F. Codd a dezvoltat teoria bazelor de date relaționale la sfârșitul anilor 1960 în timp ce lucra la un centru de cercetare IBM. Cele mai populare platforme de baze de date din ziua de azi urmează acest model complet. Modelul bazei de date relaționale este o colecție de tabele bidimensionale formate din rânduri și coloane. În terminologia modelului relațional, aceste tabele, rânduri și coloane sunt numite, respectiv, relații sau entități, tupluri, atribute și domenii. Modelul identifică chei unice (Key) pentru toate tabelele și descrie relația dintre tabele prin valorile atributelor (cheilor).

Normalizarea este un proces de modelare a bazelor de date relaționale în care relațiile sau tabelele sunt rupte până când toate atributele dintr-o relație sunt complet determinate de cheia sa primară. Majoritatea designerilor încearcă să obțină a treia formă normală (3NF) în toate privințele înainte de a fi denormalizați dintr-un motiv sau altul. Cei trei pași secvențiali ai normalizării bazelor de date relaționale sunt descriși pe scurt mai jos.

• Prima formă normală este 1NF (1NF). Se spune că o relație este în prima formă normală dacă descrie o singură entitate și nu conține matrice sau grupuri repetate de valori ca atribute. De exemplu, un tabel de comenzi care include articole de comandă nu va fi în prima formă normală deoarece conține atribute duplicat pentru fiecare articol de comandă.
• A doua formă normală 2NF (2NF). Ei spun că atitudinea este în a doua formă normală dacă este în prima formă normală și toate atributele non-cheie sunt pe deplin dependente funcțional de cheia primară a relației.
• A treia formă normală 3NF (3NF). Ei spun că atitudinea este în a treia formă normală dacă este în a doua formă normală iar atributele sale non-cheie sunt complet independente unele de altele.

Procesul de normalizare are ca rezultat împărțirea relației originale în mai multe relații independente. Fiecare relație din baza de date îi corespunde macar o masă. În timp ce modelul relațional este mai flexibil în reprezentarea datelor, poate fi mai complex și mai dificil de înțeles. De asemenea, un model complet normalizat poate fi foarte ineficient de implementat. Prin urmare, designerii bazei de date atunci când convertesc normalizat model logicîn modelul fizic permit o denormalizare semnificativă. Scopul principal al denormalizării este de a restricționa îmbinările între tabele în interogări.

Un alt motiv pentru denormalizarea modelului HD este, ca și în cazul sistemelor de operare, performanța și simplitatea. Fiecare interogare dintr-o bază de date relațională are o performanță de cost. Costurile de execuție a interogării sunt foarte mari în DW din cauza cantității de date procesate în interogare (și îmbinările tabelelor, care cresc proporțional cu dimensiunea modelului). Unirea a trei tabele mici într-un sistem OLTP poate avea un cost acceptabil pentru a executa o interogare, dar în sistem de depozitare a datelor poate dura foarte mult timp pentru a finaliza o astfel de conexiune.

Relații statice în datele istorice

Denormalizarea este proces importantîn modelarea HD: relația dintre atribute nu se modifică pentru datele istorice. De exemplu, în sistemele OLTP, un articol poate face parte dintr-un alt produs „A” în această lună și poate face parte dintr-un produs „B” luna următoare. În modelul de date normalizat, pentru a afișa acest fapt, trebuie să includeți atributul „grup de produse” în relația (entitate) „produs”, dar nu și în relația (entitate) „comandă”, care generează comenzi pentru acest produs. Entitatea de comandă include doar identificatorul articolului. Teoria relațională ar necesita o îmbinare între tabelele Order și Item pentru a defini grupul de articole și alte atribute pentru acel articol. Acest lucru ( dependenta functionala) este irelevant pentru CD, deoarece datele salvate se referă la comenzi deja finalizate, adică apartenența produsului la grup a fost deja remediată (de fapt, dependența funcțională specificată nu este acceptată). Chiar dacă obiectul îi aparține grupuri diferiteîn momente diferite, relația dintre grupul de produse și produsul fiecărei comenzi individuale este statică. Deci aceasta nu este o denormalizare pentru HD. În acest caz, dependența funcțională a sistemului OLTP nu este utilizată în HD.

Luați prețul unui articol ca un alt exemplu. Prețurile OLTP sunt supuse schimbărilor constante. Unele modificări ale acestor prețuri pot fi transferate pe CD, ca instantanee periodice ale tabelului „Prețul produsului”. În CD, istoricul listei de prețuri a mărfurilor este fix și este deja legat de comenzi, i.e. nu trebuie să determinați dinamic lista de prețuri la procesarea comenzii, deoarece aceasta a fost deja aplicată la comanda salvată. În bazele de date relaționale, este mai ușor să se mențină relații dinamice între entitățile de afaceri, în timp ce un CD conține relații între entități subiect la un moment dat.

Concept transformare logica aplicațiile sursă de date, discutate mai sus, necesită un efort în implementare și sunt foarte utile în dezvoltarea HD.

Transformarea fizică a datelor aplicației sursă

Un punct important în sisteme de stocare este transformarea fizică a datelor. Aceste proceduri în depozitarea datelor sunt cunoscute sub denumirea de procese de curățare a datelor, procesare în scenă a datelor sau procese de curățare a datelor. Procesul de curățare a datelor este cel mai intens și consumator de timp în orice proiect de creare de CD. Transformarea fizică implică utilizarea termenilor standard de domeniu HD și a standardelor de date. În timpul procesului de transformare fizică, datele sunt într-un fișier intermediar înainte de a fi introduse în CD. Atunci când datele sunt colectate din mai multe aplicații, integritatea acestora poate fi verificată în timpul procesului de generare a datelor transformate înainte de a fi încărcate în HD.

Termeni și nume atributele entității utilizate în sistemele OLTP, în procesul de conversie a datelor pentru CD, sunt convertite în universal, termeni standard acceptat pentru acest domeniu de afaceri. Aplicațiile pot folosi abrevieri sau termeni greu de înțeles din multe motive diferite. Platforma dispozitivului poate limita lungimea și formatul numelor, iar aplicațiile de linie de afaceri pot folosi termeni generici în toate domeniile. În HD, este necesar să folosiți termeni comerciali standard care sunt înțeleși de la sine pentru majoritatea utilizatorilor.

Identificatorul clientului (cumpărător) în sistemul OLTP poate fi numit „Cumpără.”, „Cumpără_id” sau „Nu cumpără”. Mai mult, diferite aplicații ale unor astfel de sisteme pot folosi diferite nume (sinonime) atunci când se referă la același atribut al unei entități. Designerul HD alege un termen de afaceri simplu, standard, cum ar fi ID-ul clientului. Deci numele atributele entității din sistemele de alimentare trebuie să fie unificate pentru utilizare în CD.

Diferitele subsisteme ale sistemelor OLTP și sursele de date externe pot folosi definiții diferite ale domeniilor de atribute pe planul fizic. stratul de prezentare... Astfel, un atribut de tip „identificator de produs” într-un sistem are o lungime de 12 caractere sau mai mult, iar în celălalt - 18 caractere. Pe de altă parte, software-ul unor sisteme existente poate avea restricții privind definirea lungimii numelor de atribute și un set slab de tipuri pentru definirea domeniilor, în timp ce în altele asemenea restricții pot fi absente și o selecție largă de tipuri de atribute poate fi furnizate.

La definirea atributelor în modelul fizic de date, este necesar să se utilizeze astfel de lungimi și tipuri de date în definirea domeniului de atribute, care să țină cont atât de cerințele domeniului, cât și de capacitățile sistemelor - surse de date. Definirea standardelor de domeniu pentru CD-uri este una dintre sarcinile importante ale designerilor de CD-uri. Regulile de transformare a domeniilor de atribute ale sistemelor - surse de date în domenii de atribute ale CD-ului ar trebui să fie înregistrate în metadatele CD-ului.

Toate atributele dintr-un CD ar trebui să utilizeze valori predefinite în mod constant. Aplicațiile diferite pot avea convenții diferite pentru valorile atributelor predefinite. Aceste valori predefinite includ valori implicite, valori de substituție nulă și așa mai departe. De exemplu, sexul în sisteme diferite poate avea semnificații diferite: în unele, acestea sunt valorile simbolice „M” și „F”, în altele - valorile digitale 0 și 1. Un exemplu mai neplăcut este cazul când o valoare de date este utilizată într-un aplicare în mai multe scopuri, de ex. atributul reprezintă de fapt o valoare plurală. De exemplu, când în atributul „tipul metodei de măsurare”, primele două cifre indică metoda de măsurare, iar al doilea - controlul fizic al măsurării. Astfel de valori diferite trebuie convertite într-o valoare predefinită acceptată în CD înainte de a fi încărcate pe CD.

Unele sisteme surse de date pot avea valori lipsă (date lipsă) sau nu pot fi convertite (date corupte). Este important ca în timpul procesului de conversie astfel de date să ia valori în fișa de date care să permită utilizatorilor să le interpreteze corect. Unor atribute li se poate atribui pur și simplu un implicit rezonabil în absența unei valori sau în conflicte de conversie, iar alte atribute pot fi deduse din valorile altor atribute. De exemplu, în entitatea Comanda, să presupunem că valoarea atributului unității de măsură a articolului este omisă. Această valoare poate fi obținută din atributul corespunzător al entității „Produs” a acestui sistem sursă. Unele atribute nu au valori implicite adecvate atunci când valorile lipsesc. Pentru astfel de valori lipsă, DD ar trebui să definească și o valoare implicită, de exemplu, ca valoare nulă.

Principalele diferențe în utilizarea datelor în

Dorința de a combina capacitățile sistemelor OLTP și ale sistemelor de analiză într-o arhitectură DSS a condus la apariția conceptului XranșilcăutadAnneX (HD).

Conceptul de HD a fost discutat într-un fel sau altul de experții în domeniul informației

sisteme de mation pentru o lungă perioadă de timp. Au apărut primele articole dedicate special HD

în 1988, de B. Devlin şi P. Murphy. În 1992 W. Inmon a descris acest concept în detaliu în monografia sa „Building the Data Warehouse” (ediția a doua – QED Publishing Group, 1996).

Conceptul de CD se bazează pe ideea separării datelor utilizate pentru

prelucrare operaţională şi pentru rezolvarea problemelor de analiză. Acest lucru vă permite să aplicați structuri de date care îndeplinesc cerințele de stocare pentru utilizare în sistemele OLTP și sistemele de analiză. Această separare vă permite să optimizați atât structurile de date ale stocării online (baze de date online, fișiere, foi de calcul etc.) pentru efectuarea operațiunilor de introducere, modificare, ștergere și căutare, cât și structuri de date utilizate pentru analiză (pentru efectuarea de interogări analitice). În DSS, aceste două tipuri de date sunt numite corespunzător. O P e R A T și v n s m și și Cu T O h n și La A m și d A nna X (OID) și XRAnicilșiSCHemdAnnsX.

În lucrarea sa, Inmon a dat următoarea definiție a HD.

X ra nici l și SCH e d A n n s X -orientat pe subiect, integrat,

Un set de date istoric imuabil, organizat în scopuri de sprijinire a deciziilor.

Să luăm în considerare proprietățile HD mai detaliat.

PRunitatimeTnoh ohrienTAqiEu sunt. Aceasta este diferența fundamentală dintre HD și OID.

Diferite OID-uri pot conține date care descriu același domeniu din puncte de vedere diferite (de exemplu, din punct de vedere al contabilității, controlului stocurilor, departamentului de planificare etc.). O decizie luată pe baza unui singur punct de vedere poate fi ineficientă sau chiar greșită. HD permite integrarea informațiilor care reflectă diferite puncte de vedere pe un subiect.

Orientarea obiectelor vă permite, de asemenea, să stocați pe CD numai datele care

sunt necesare pentru analiza lor (de exemplu, pentru analiză nu are sens să stocați informații despre numerele documentelor de cumpărare și vânzare, în timp ce conținutul acestora - cantitatea, prețul mărfurilor vândute - este necesar). Acest lucru reduce semnificativ costul mediilor de stocare și crește securitatea accesului la date.

ȘInTegrAqieu sunt. OID-urile, de regulă, sunt dezvoltate în momente diferite de mai multe echipe cu propriile lor instrumente. Acest lucru duce la faptul că datele care reflectă același obiect al lumii reale în sisteme diferite îl descriu diferit. Integrarea obligatorie a datelor în CD vă permite să rezolvați această problemă prin aducerea datelor într-un singur format. DeddeRfLaAXROnologii. Datele din OID sunt necesare pentru a efectua operațiuni asupra lor în momentul curent. Prin urmare, este posibil să nu fie limitate în timp. Pentru analiza datelor, este adesea important să puteți urmări istoricul modificărilor în valorile domeniului. Prin urmare, toate datele stocate pe CD trebuie să corespundă unor intervale de timp succesive. Neșigmeneu suntelunăCuTb. Cerințele OID impun constrângeri de timp

stocarea datelor în ele. Acele date care nu sunt necesare procesării operaționale, de regulă, sunt eliminate din OID pentru a reduce resursele consumate. Pe de altă parte, analiza necesită date pentru cea mai mare perioadă de timp posibilă. Prin urmare, spre deosebire de OID, datele de pe CD sunt citite numai după încărcare. Acest lucru vă permite să creșteți semnificativ viteza de acces la date, atât datorită posibilei redundanțe a informațiilor stocate, cât și datorită excluderii operațiunilor de modificare.

Când conceptul de CD este implementat în DSS, datele de la diferite OID-uri sunt copiate în stocarea centrală. Datele colectate sunt reduse la un singur format, coordonate și generalizate.Solicitările analitice sunt adresate CD-ului (Fig. 1).

Acest model duce inevitabil la duplicarea informațiilor în OID și în CD.

Cu toate acestea, Inmon în lucrarea sa susține că redundanța datelor stocate în

DSS, nu depășește 1%! Acest lucru poate fi explicat prin următoarele motive.

Când se încarcă informații de la OID pe CD, datele sunt filtrate. Multe dintre ele nu se încadrează în HD, deoarece sunt lipsite de sens din punctul de vedere al utilizării lor în procedurile de analiză.

Informațiile din OID sunt, de regulă, operaționale, iar datele s-au pierdut

relevanța sunt șterse. În schimb, CD-ul stochează informații istorice. Din acest punct de vedere, duplicarea conținutului CD-ului de către datele OID se dovedește a fi destul de nesemnificativă. CD-ul conține informații generalizate care sunt absente în OID.

În timpul încărcării pe CD, datele sunt șterse (informațiile inutile sunt șterse) și

după o astfel de prelucrare, ele ocupă mult mai puțin volum.

Subsistem de intrare (OLTP)

P o d s i s t e m

Interogări analitice

P o d s i s t e m

Despre

Subsistem de intrare (OLTP)

și analiză

RșiCulanOLa7. Structura DSS cu CD fizic

Redundanța informațiilor poate fi redusă la zero folosind CD-ul virtual. În acest caz, spre deosebire de CD-ul clasic (fizic), datele din OID nu sunt copiate într-o singură stocare. Acestea sunt preluate, transformate și integrate direct atunci când se efectuează interogări analitice în memoria RAM a computerului. De fapt, astfel de solicitări sunt adresate direct OID (Fig. 2). Principalele avantaje ale unui HD virtual sunt:

minimizarea cantității de memorie ocupată de informațiile de pe purtător; lucrați despre t și cu t e s u u m i, d e t l is i r o v și d d d d.

Subsistem de intrare (OLTP)

Subsistem de intrare (OLTP)

Subsisteme de intrare

Subsistemul de stocare a informațiilor

Interogări analitice

Subsistemul de analiză (OLAP,

Despre

V şi rt u a ln despre e

R și Cu la n O La 8. P r u c t u ra S PP R s v și rt u al n y m X D

Cu toate acestea, această abordare are multe dezavantaje.

Timpul de procesare pentru cererile către un disc virtual este mult mai mare decât cel corespunzător

Indicatori corespondenți pentru stocarea fizică În plus, structurile bazelor de date online, concepute pentru actualizarea intensivă a înregistrărilor unice, sunt extrem de normalizate. Pentru a executa o interogare analitică, trebuie să se alăture un număr mare de tabele, ceea ce duce și la degradarea performanței.

O vedere integrată a stocării virtuale este posibilă numai dacă este îndeplinită condiția de disponibilitate constantă a tuturor OID-urilor. Astfel, inaccesibilitatea temporară a cel puțin uneia dintre surse poate duce fie la eșecul interogării analitice, fie la rezultate incorecte.

Efectuarea de interogări analitice complexe asupra OID-urilor necesită resurse informatice semnificative. Acest lucru duce la o scădere a performanței sistemelor OLTP, ceea ce este inacceptabil, deoarece timpul de execuție a operațiunilor în astfel de sisteme este adesea foarte critic.

Diferite OID-uri pot suporta diferite formate de date și codificări. De multe ori

pot fi primite mai multe răspunsuri pentru aceeași întrebare. Acest lucru se poate datora:

momente asincrone de actualizare a datelor în diferite OID-uri; diferențe în descrierea obiectelor și evenimentelor identice din domeniul subiectului; erori de scriere; pierderea fragmentelor de arhive etc.

În acest caz, scopul - formarea unei singure vederi consistente a obiectului de control - poate să nu fie atins.

Principalul dezavantaj al stocării virtuale este practic

incapacitatea de a obține date pentru o perioadă lungă de timp. În lipsa stocării fizice, sunt disponibile doar datele care se află în OID la momentul solicitării. Scopul principal al sistemelor OLTP este prelucrarea online a datelor curente, astfel încât acestea nu sunt concentrate pe stocarea datelor pentru o perioadă lungă de timp. De îndată ce devin învechite, datele sunt încărcate în arhivă și șterse din baza de date operațională.

În ciuda avantajelor unui CD fizic față de unul virtual, este necesar

admit că implementarea lui este un proces destul de laborios.

Să ne oprim asupra principalelor probleme ale creării unui CD:

necesitatea de a integra date din surse eterogene în

mediu restrâns;

necesitatea stocării și procesării eficiente a unor cantități foarte mari de informații; necesitatea directoarelor cu metadate pe mai multe niveluri; O

cerințe crescute pentru securitatea datelor. Luați în considerare mai mult aceste probleme

detaliat.

NedespreXOdșilunăCuTbînTegrAqișidAnnhopașisneOdnOROdnhopașiCuTOhNickovvRACu- etcalimentelennOhCuRalimente. CD-urile sunt create pentru a integra date care pot proveni de la OID-uri eterogene aflate fizic pe diferite computere: baze de date, arhive electronice, cataloage electronice publice și comerciale, cărți de referință, colecții statistice. Când creați un CD, trebuie să rezolvați problema construirii unui sistem care să funcționeze împreună cu instrumente și soluții software eterogene. La alegerea instrumentelor pentru implementarea CD-ului trebuie luați în considerare mulți factori, inclusiv nivelul de compatibilitate a diferitelor componente software, ușurința dezvoltării și utilizării acestora, eficiența funcționării etc.

DeTRebnOCuTbvehffeLaTșivnohmXRAnenicișișiObRaboTLaeOcenbbolbwșiXdesprebemovînfORmacșiși. Proprietatea imuabilității unui CD presupune acumularea de informații în acesta pentru o perioadă lungă de timp, care ar trebui să fie susținută de o creștere constantă a volumului memoriei discului. Orientarea către executarea interogărilor analitice și normalizarea datelor asociate conduc la o creștere neliniară a cantității de memorie ocupată de CD cu o creștere a cantității de date. Cercetările care utilizează benchmark-ul TPC-D au arătat că bazele de date cu o dimensiune de 100 GB necesită memorie de 4,87 ori mai mare decât cantitatea necesară pentru stocarea datelor de încărcare utilă.

NedespreXOdșilunăCuTb mnOGOURovneafarăCuetcavohNickov meTAdAnnsX. Pentru sistemul de analiză, prezența metadatelor dezvoltate (date despre date) și mijloacele de furnizare a acestora către utilizatorii finali este una dintre principalele condiții pentru implementarea cu succes a CD.Metadatele sunt necesare pentru ca utilizatorii DSS să înțeleagă structura informațiilor pe pe baza căreia se ia o decizie. De exemplu, înainte ca un manager de corporație să adreseze sistemului întrebarea sa, el trebuie să înțeleagă ce informații sunt disponibile, cât de relevante sunt acestea, dacă se poate avea încredere în ele, cât timp poate dura formarea unui răspuns etc. La crearea unui CD, este necesar să se rezolve problema stocării și prezentării convenabile a metadatelor utilizatorilor.

PovswenicieTRebobanicialLabezoPACunOCuTșidAnnsX. Adunați împreună și co-

Informații consistente despre istoria dezvoltării corporației, succesele și eșecurile acesteia, relațiile cu furnizorii și clienții, istoricul și starea pieței fac posibilă analizarea activităților trecute și actuale ale corporației și construirea de previziuni pentru viitor. Evident, astfel de informații sunt confidențiale și accesul la acestea este limitat în cadrul companiei însăși, ca să nu mai vorbim de alte companii. Pentru a asigura securitatea datelor, este necesar să se rezolve problemele de autentificare a utilizatorilor, protecția datelor atunci când acestea sunt mutate în stocare

date din baze de date operaționale și surse externe, protecția datelor în timpul transmiterii acestora în rețea etc.

Reducerea costului de creare a unui CD poate fi realizată prin crearea unui sistem simplificat

opțiune - data mart.

V și T R în A d A n ne X (VD) - aceasta este o versiune simplificată a CD-ului, care conține doar subiectul

date comasate.

VD este cât mai aproape posibil de utilizatorul final și conține date,

axat tematic pe acesta (de exemplu, VD pentru angajații departamentului de marketing poate conține date necesare analizei de marketing). VD are un volum semnificativ mai mic decât HD, iar implementarea sa nu necesită costuri mari. Ele pot fi implementate atât independent, cât și împreună cu CD.

VD independente (Fig. 3) apar adesea în organizație din punct de vedere istoric și se găsesc în organizații mari, cu un număr mare de divizii independente care își rezolvă propriile sarcini analitice.

Design VD pentru a răspunde la o anumită gamă de întrebări; implementarea rapidă a traficului aerian autonom și obținerea unui randament; simplificarea procedurilor de completare a VD-ului și creșterea productivității acestora prin luarea în considerare a nevoilor unui anumit cerc de utilizatori.

Subsistem de intrare (OLTP)

Subsistem de intrare (OLTP)

Subsistemul de stocare a informațiilor

Interogări analitice

Interogări analitice

Subsistemul de analiză (OLAP,

P o d s i s t e m

Despre

Subsistem de intrare (OLTP)

și analiză

RșiCulanOLa9. Structura DSS cu VD independent

Dezavantajele VD-urilor autonome sunt:

stocarea multiplă a datelor în diferite VD-uri, ceea ce duce la creșterea costurilor de stocare și la potențiale probleme asociate cu necesitatea menținerii coerenței datelor; lipsa consolidării datelor la nivel de domeniu, dar,

deci - absența unei singure imagini.

Recent, ideea de a combina HD și VD în

un singur sistem. În acest caz, CD-ul este utilizat ca unica sursă de date integrate pentru toate VD-urile (Fig. 4).

HD este o singură sursă centralizată de informații pentru întregul domeniu,

organizate pentru a oferi informații despre secțiunile tematice ale zonei date. Utilizatorii finali au posibilitatea de a accesa date detaliate în depozit dacă nu există suficiente date în magazin, precum și de a obține o imagine mai completă a informațiilor.

Avantajele acestei abordări sunt:

simplitatea creării și umplerii VD-ului, deoarece umplerea are loc dintr-o singură sursă standardizată de încredere de date curățate - de pe CD; ușurința extinderii DSS prin adăugarea de noi VD; ÎNCĂRCARE REDUCERE ÎNCĂRCARE H D

Subsistem de intrare (OLTP)

Subsistemul de stocare a informațiilor

Interogări analitice

P o d s i s t e m

Despre

Subsistem de intrare (OLTP)

Subsistem de intrare (OLTP)

ANALITICĂ

Cereri HD

VD

și analiză

Subsistemul de analiză (OLAP,

RșiCulanOLa10. Structura DSS cu HD și VD

Dezavantajele includ:

redundanță (datele sunt stocate atât pe CD, cât și pe VD); costuri suplimentare pentru dezvoltarea unui DSS cu HD și VD.

Rezumând analiza modalităților de implementare a unui DSS folosind conceptul de CD, se pot distinge următoarele arhitecturi ale unor astfel de sisteme:

DSS cu HD fizică (clasică) (vezi Fig. 1); DSS cu CD virtual (vezi Fig. 2); DSS cu VD (vezi Fig. 3); DSS cu HD fizic și cu VD (Fig. 4).

În cazul arhitecturilor cu CD și/sau VD fizic, trebuie acordată atenție

organizarea (arhitectura) CD-ului și transferul de date de la OID la WCD.

Forrester Research a observat că majoritatea companiilor mari se confruntă următoarea problemă: se acumulează o cantitate mare informații care nu sunt niciodată folosite. În aproape orice organizație, o mulțime de sisteme tranzacționale funcționează de fapt, concentrate pe procesarea datelor operaționale (fiecare pentru o anumită clasă de sarcini) și completând continuu numeroase Bază de date... În plus, întreprinderile dețin adesea cantități uriașe de informații stocate în așa-numitele. sistemele moștenite. Toate aceste date sunt distribuite în rețele calculatoare personale sunt stocate pe mainframe, stații de lucru și servere. Astfel, există informații, dar sunt dispersate, inconsecvente, nestructurate, adesea redundante și nu întotdeauna de încredere. Prin urmare, în majoritatea organizațiilor, aceste date încă nu pot fi folosite pentru a lua decizii de afaceri critice. Conceptul de depozite de date are ca scop rezolvarea acestei contradicții.

Autorul conceptului Bill Inmon, în articolul său clasic What Are Data Warehouses (D2K Incorporated, 1996), definește depozitele de date ca „seturi de date istorice specifice domeniului, integrate, imuabile, organizate pentru a sprijini guvernanța”. El vede depozitele ca „singura și singura sursă de adevăr”, „centrul universului” al sistemelor de sprijinire a deciziilor (DSS). „Din depozitele de date”, scrie el, „informațiile circulă în diferite departamente, fiind filtrate în conformitate cu setările DSS specificate. Aceste baze de date separate de luare a deciziilor sunt numite vitrine date ".

Conceptul de depozite de date se bazează pe ideea combinării datelor corporative împrăștiate în sisteme operaționale de procesare a datelor, arhive istorice și alte surse externe. Aceste surse pot conține date care nu sunt utilizate direct în ODS, dar sunt vitale pentru DSS: cadrul legislativ(inclusiv previziuni fiscale), planuri de dezvoltare industrii, date statistice, directoare electronice. După cum arată practica, o decizie luată doar pe baza datelor interne se dovedește adesea a fi incorectă.

Scopul conceptului de depozit de date este de a clarifica diferențele dintre caracteristicile datelor din sistemele de operare și analitice, de a determina cerințele pentru datele plasate în depozit, de a determina principiile generale și etapele construcției acestuia, principalele surse de date. , să ofere recomandări cu privire la soluționarea potențialelor probleme apărute în timpul descărcării, curățării, coordonării, transportului și încărcării acestora în baza de date țintă a depozitului.

Compararea caracteristicilor datelor în sisteme de informare concentrat pe prelucrarea datelor operaționale și analitice

Caracteristică	De operare	Analitic
Frecvență de actualizare	Frecventa inalta, în porții mici	Frecvență joasă, porții mari
Surse de date	În principal intern	În principal extern
Volume de date stocate	Sute de megabytes, gigabytes	Gigabytes și Terabytes
Vârsta datelor	Curent (pentru o perioadă de la câteva luni la un an)	Actual și istoric (pe o perioadă de câțiva ani, zeci de ani)
Programare	Fixare, căutare online și transformare a datelor	Stocarea datelor istorice detaliate și agregate, procesare analitică, prognoză și modelare

Cerințe de bază pentru datele dintr-un depozit de date

Orientarea subiectului	Toate datele despre un anumit subiect (obiect de afaceri) sunt colectate (de obicei din multe surse diferite), curățate, reconciliate, completate, agregate și prezentate într-o formă unică și convenabilă pentru utilizare în analiza afacerii.
Integrare	Toate datele despre diferite obiecte de afaceri sunt reciproc coerente și stocate într-o singură stocare corporativă
Imuabilitate	Datele inițiale (istorice), după ce au fost agreate, verificate și introduse în general depozitare corporativă, rămân neschimbate și sunt utilizate exclusiv în modul citire
Suport cronologic	Datele sunt structurate cronologic și reflectă istoria pe o perioadă suficientă de timp pentru a finaliza sarcinile de analiză și prognoză de afaceri.

Subiectul conceptului de depozite de date nu este analiza datelor, ci datele în sine, adică conceptul pregătirii lor pentru analiza ulterioară. În același timp, conceptul de depozit de date definește nu doar o singură vedere logică a datelor corporative, ci și implementarea unei singure surse de date integrate.

Modele de analiză a datelor

În ciuda faptului că în conceptul de depozite de date formulat de B. Inmon, se pune accent pe datele în sine și pe identificarea celor mai proprietăți generale, caracteristici și relații, este clar că aceste date ar trebui folosite în procesul de luare a deciziilor de afaceri la toate nivelurile, până la corporate și inter-corporate. Până în prezent, s-au format istoric două modele principale de analiză a datelor, pe care se bazează DSS-urile analitice existente:

1. Analiza statica(DSS). Însuși conceptul de DSS (Decision Support Systems) este de fapt tradus ca DSS. Până de curând, acesta a fost singurul concept analitic. Rezultatul muncii unor astfel de sisteme au fost rapoarte de mai multe pagini strict reglementate, pentru formarea cărora au fost efectuate interogări pe termen lung, procesând cantități colosale de date. Astfel de solicitări ar putea dura câteva ore, uneori zeci de ore sau chiar zile.

2. Analiza datelor operaționale (OLAP). Autorul conceptului de OLAP (On-Line Analytical Processing) este Dr. E. Codd, care a formulat în 1993 12 cerințe de bază pentru mijloacele de implementare a OLAP. Diferența fundamentală acest model din DSS static tradițional este o reprezentare conceptuală a datelor ca un cub multidimensional. În același timp, E. Codd a arătat potențialele dezavantaje ale abordării relaționale în sistemele axate pe analiza datelor. Scopul creării acestui concept a fost posibilitatea fundamentală de a oferi utilizatorului final mijloacele de formare, procesare și executare a interogărilor analitice ad-hoc cu un timp minim de răspuns al sistemului. Necesitatea apariției acestui nou concept a fost predeterminată de faptul că, de multe ori, după primirea unui raport standard prin intermediul DSS, analistul avea o nouă întrebare sau își dădea seama că întrebarea în sine a fost formulată incorect. Drept urmare, a trebuit să facă din nou pentru mult timp așteptați următorul rezultat pentru a reveni apoi, eventual, la următoarea iterație a acestui proces.

Compararea caracteristicilor analizei statice și dinamice

Caracteristică	Analiza statica	Analiza dinamica
Tipuri de întrebări	Cat de mult? Cum? Când?	De ce? Ce-ar fi dacă?..
Timp de raspuns	Nereglementat
Operații tipice	Raport reglementat, diagramă	O secvență de rapoarte interactive, diagrame, formulare de ecran... Schimbați în mod dinamic nivelurile de agregare și secțiunile de date.
Nivelul cerințelor analitice
Tipul formularului de ecran	În mare parte predeterminat, reglementat	Definit de utilizator
Nivelul de agregare a datelor	Detaliat și rezumat	În mare parte cumulativ
Vârsta datelor	Istoric și actual	Istoric, actual și proiectat
Tipuri de cereri	În mare parte previzibil	Imprevizibil, ocazional
Programare	Prelucrare analitică reglementată	Analiză, modelare și prognoză multifuncțională

Astăzi direcția OLAP este, poate, cea mai promițătoare pentru rezolvarea problemelor de management analitic. Prin intermediul unui serviciu de raportare OLAP special creat, cele 12 cerințe formulate inițial de Dr. Codd au fost parțial revizuite și completate semnificativ atât de bază, cât și oportunități speciale, cum ar fi selectarea și procesarea datelor lipsă etc. Dar totuși nucleul conceptului OLAP este reprezentare multidimensională date la nivel conceptual.

Magazin de date

Conform definiției clasice, un Data Mart este un subset al unui depozit de date care reflectă specificul unui departament (obiect de afaceri) și oferă productivitate crescuta... Astfel, vitrina este linkul pe care se află un specific sistem analitic pentru a-și rezolva gama de sarcini. Cu toate acestea, este posibil ca o anumită zonă de activitate a întreprinderii să nu se coreleze practic cu altele și este posibil să se construiască un data mart corespunzător în mod autonom, fără a fi legat de un depozit corporativ. Apoi, vitrina va fi completată cu date direct din sistemele operaționale de procesare a tranzacțiilor. Astfel de magazine de date sunt numite independente, spre deosebire de martele clasice de date dependente de depozitul de date și alimentate din acesta.

În unele cazuri, pare recomandabil să instalați un data mart în loc de un depozit complet format. Magazinele de date sunt mai puțin solicitante, mai ieftine și mai ușor de construit și se bazează pe servere mai ieftine decât pe sisteme multiprocesor. Cu această abordare, nu este nevoie să folosiți întregul Sistem informatic corporații și sprijină proceduri complexe pentru actualizarea sincronă a data mart-ului la actualizarea depozitului. În același timp, este necesar să înțelegem că prin această abordare, martele de date se pot multiplica în complexe întregi de baze de date independente de informații și, firește, se va pune sarcina de a gestiona strategiile individuale de căutare, întreținere și recuperare. Pe de altă parte, construirea unui singur depozit corporativ bazat pe mai multe magazine independente de date este mult mai profitabilă decât să te bazezi pe date împrăștiate în sistemele de procesare a tranzacțiilor.

Deci, ce este adecvat de utilizat: stocare unificată, magazine de date independente, stocare cu magazine de date dependente sau alte opțiuni? Nu există un răspuns universal la întrebarea cu privire la necesitatea aplicării cutare sau cutare opțiune. In fiecare caz cea mai bună opțiune este determinat de cerințele afacerii, intensitatea cererii, arhitectura rețelei, capacitatea de răspuns necesară și alte condiții.

Tehnologia de implementare a depozitului de date

Când creați un depozit de date, este firesc să rămâneți la o dezvoltare în etape. În ciuda faptului că nicio descriere a procesului de construire a unui depozit de date sub forma unei secvențe de faze nu poate acoperi toate aspectele părere cu potențialii utilizatori, manageri și analiști, totuși, există câțiva pași de bază care se aplică procesului de construire a unei arhitecturi de întreprindere:

1. Determinarea nevoilor utilizatorilor finali și construirea unui model de întrebări de afaceri la care trebuie să se răspundă.

2. Identificarea datelor din surse corporative și externe care vor alimenta depozitul sau data mart-ul.

3. Analiza surselor de date și modelarea funcțiilor și proceselor pe care aceste surse le acoperă. Învățarea regulilor după care funcționează o afacere este una dintre ele conditii esentiale construirea de depozite de date sau de marturi de date, deoarece pe baza acesteia se stabilește nivelul de detaliu al elementelor din depozitul de date.

4. Determinarea procedurilor de transformare, curățare și integrare logică a datelor sursă înainte ca acestea să fie plasate într-un depozit de date sau data mart, precum și reglementarea implementării acestor proceduri care actualizează depozitul de date.

5. Crearea de metadate care descriu sursele și metodele de transformare a datelor și logica depozitului de date. Depozitul de metadate ar trebui să includă definiții de date, reguli de afaceri și o logică detaliată pentru a modela dezvoltarea sistemelor analitice.

6. Formarea tabelelor fizice ale depozitului de date și completarea acestuia. Acest proces poate dura mai multe iterații, ținând cont de posibila reproiectare a structurilor de date atunci când se analizează schema de date din depozit.

7. Construirea unui depozit de magazine de date, care va include subseturi de date din depozit și date pre-agregate. Unele dintre metadate vor descrie modul în care datele primare ale depozitului sunt transformate, agregate și stocate în cache în magazinele de date.

8. Instalarea instrumentelor OLAP, sistemelor de aplicații, serverelor Web și toate instrumentele necesareși programe server necesare pentru accesul, analiza și raportarea datelor.

9. Instalarea pe posturile de lucru ale utilizatorilor finali ai clientului software(client gros) sau browsere care acceptă formate de date standard și applet-uri Java și extensiile necesare plug-in (client „subțire”) pentru accesul utilizatorilor la date.

După finalizarea procesului de creare a unui depozit de date, poate părea că totul este deja făcut. De fapt, formarea unui depozit este un proces care include și fazele necesare de supraveghere și întreținere constantă a depozitului de date. O bună supraveghere presupune nu numai menținerea corectitudinii datelor, ci și asigurarea secretului acestora, mai ales dacă datele din depozit sunt accesate prin Web. „Deoarece depozitul de date conține unul dintre cele mai mari active dintr-o întreprindere”, spune R. Tenler, președintele Information Advantage, „datele trebuie să fie sigure. Dar pentru a realiza valoarea potențială a unui depozit de date, o organizație va trebui să o ofere potențialilor cumpărători.”

Menținerea depozitului de date în stare bună pe termen lung este o altă provocare majoră. Acest factor devine deosebit de important atunci când numărul de utilizatori care accesează sistemul începe să crească. Mai mult, dacă se află în procesul de proiectare a unui depozit de date servicii de informare o amănunţită reconciliere date, în timp, atenția oamenilor scade de obicei, iar depozitul de date se poate transforma într-o groapă. Pentru a preveni acest lucru, este necesar să se desemneze persoane responsabile pentru menținerea calității datelor, care vor implementa în mod constant verificare informații primite de la sistemele de procesare a tranzacțiilor, cu date într-un depozit sau vitrină.

În concluzie, se poate observa că procesul de proiectare a depozitului de date a folosit pentru a furniza informațiile necesare în luarea deciziilor nivel corporativ și inter-corporat, este esențial pentru viața întreprinderii. În stadiul implementării sale, trebuie să acordați atenție nu numai soluției probleme tehnice, dar și asupra problemelor asociate cu factorul uman. De asemenea, nu trebuie să uităm de necesitatea de a evalua în mod constant fezabilitatea eforturilor depuse. Pe lângă lanțul corect de management al proiectelor, este necesar în fiecare etapă să se țină cont atât de nevoile utilizatorilor, cât și de prezența aspectelor politice care pot încetini proiectul. Cu abordarea corectă pentru rezolvarea acestei probleme, depozitul de date ar putea deveni în curând parte din sistem comercialîntreprinderilor, oferind unei părți din utilizatorii terți, pentru o anumită taxă, posibilitatea de a utiliza date dintr-un anumit subset al stocării. Această abordare nu numai că va face posibilă recuperarea muncii la formarea depozitului de date, ci și să ofere canal nou chitanțe de venit.