Depozit de date - Data warehouse

Prezentare generală a depozitului de date
Arhitectura de bază a unui depozit de date

În calcul , un depozit de date ( DW sau DWH ), cunoscut și sub numele de antrepozit de date pentru întreprinderi ( EDW ), este un sistem utilizat pentru raportare și analiză a datelor și este considerat o componentă de bază a business intelligence . DW-urile sunt depozite centrale de date integrate dintr-una sau mai multe surse disparate. Acestea stochează date curente și istorice într-un singur loc, care sunt utilizate pentru crearea de rapoarte analitice pentru lucrătorii din întreaga întreprindere.

Datele stocate în depozit sunt încărcate din sistemele operaționale (cum ar fi marketingul sau vânzările). Datele pot trece printr-un depozit de date operaționale și pot necesita curățarea datelor pentru operațiuni suplimentare pentru a asigura calitatea datelor înainte de a fi utilizate în DW pentru raportare.

Extragere, transformare, încărcare (ETL) și extragere, încărcare, transformare (ELT) sunt cele două abordări principale utilizate pentru a construi un sistem de depozitare de date.

Depozitare de date bazată pe ETL

Depozitul tipic de date bazat pe extragere, transformare, încărcare (ETL) folosește stadiile , integrarea datelor și straturile de acces pentru a găzdui funcțiile sale cheie. Stratul de stocare sau baza de date de stocare stochează date brute extrase din fiecare dintre sistemele de date sursă disparate. Stratul de integrare integrează seturi de date disparate prin transformarea datelor din stratul de etapizare stocând adesea aceste date transformate într-o bază de date de stocare a datelor operaționale (ODS). Datele integrate sunt apoi mutate într-o altă bază de date, denumită adesea baza de date a depozitului de date, unde datele sunt aranjate în grupuri ierarhice, deseori numite dimensiuni, și în fapte și fapte agregate. Combinația de fapte și dimensiuni este uneori numită schemă stelară . Stratul de acces ajută utilizatorii să recupereze date.

Sursa principală a datelor este curățată , transformată, catalogată și pusă la dispoziție pentru utilizare de către manageri și alți profesioniști în afaceri pentru minerit de date , prelucrare analitică online , cercetare de piață și suport pentru decizii . Cu toate acestea, mijloacele de recuperare și analiză a datelor, extragerea, transformarea și încărcarea datelor și gestionarea dicționarului de date sunt, de asemenea, considerate componente esențiale ale unui sistem de depozitare a datelor. Multe referințe la depozitarea datelor utilizează acest context mai larg. Astfel, o definiție extinsă pentru depozitarea datelor include instrumente de business intelligence , instrumente pentru extragerea, transformarea și încărcarea datelor în depozit și instrumente pentru gestionarea și recuperarea metadatelor .

Depozitare de date bazată pe ELT

Arhitectură Data Warehouse bazată pe ELT

Depozitarea de date bazată pe ELT scapă de un instrument ETL separat pentru transformarea datelor. În schimb, menține o zonă de stocare în interiorul depozitului de date. În această abordare, datele sunt extrase din sisteme sursă eterogene și sunt apoi încărcate direct în depozitul de date, înainte de a se produce orice transformare. Toate transformările necesare sunt apoi gestionate în interiorul depozitului de date. În cele din urmă, datele manipulate sunt încărcate în tabelele țintă din același depozit de date.

Beneficii

Un depozit de date păstrează o copie a informațiilor din sistemele de tranzacții sursă. Această complexitate arhitecturală oferă posibilitatea:

  • Integrați date din mai multe surse într-o singură bază de date și un model de date. Mai multă adunare de date într-o singură bază de date, astfel încât un singur motor de interogare poate fi utilizat pentru a prezenta date într-un ODS.
  • Atenuați problema contenției de blocare a nivelului de izolare a bazei de date în sistemele de procesare a tranzacțiilor cauzată de încercările de a rula interogări de analiză de lungă durată în bazele de date de procesare a tranzacțiilor.
  • Păstrați istoricul datelor , chiar dacă sistemele de tranzacții sursă nu.
  • Integrați date din mai multe sisteme sursă, permițând o vizualizare centrală a întregii întreprinderi. Acest beneficiu este întotdeauna valoros, dar mai ales atunci când organizația a crescut prin fuziune.
  • Îmbunătățiți calitatea datelor , oferind coduri și descrieri coerente, semnalizând sau chiar remediind datele necorespunzătoare.
  • Prezentați informațiile organizației în mod consecvent.
  • Furnizați un singur model de date comun pentru toate datele de interes, indiferent de sursa datelor.
  • Restructurați datele astfel încât să aibă sens pentru utilizatorii de afaceri.
  • Restructurați datele astfel încât să ofere performanțe excelente de interogare, chiar și pentru interogări analitice complexe, fără a afecta sistemele operaționale .
  • Adăugați valoare aplicațiilor operaționale de afaceri, în special sistemele de gestionare a relației cu clienții (CRM).
  • Faceți mai ușor de scris interogările de asistență pentru luarea deciziilor.
  • Organizați și dezambiguați datele repetitive

Generic

Mediul pentru depozite de date și marturi include următoarele:

  • Sisteme sursă care furnizează date depozitului sau magazinului;
  • Tehnologia și procesele de integrare a datelor necesare pentru pregătirea datelor pentru utilizare;
  • Diferite arhitecturi pentru stocarea datelor în depozitul de date al unei organizații sau în data marts;
  • Diferite instrumente și aplicații pentru o varietate de utilizatori;
  • Metadatele, calitatea datelor și procesele de guvernanță trebuie să fie în vigoare pentru a se asigura că depozitul sau magazinul își îndeplinesc scopurile.

În ceea ce privește sistemele sursă enumerate mai sus, R. Kelly Rainer afirmă: „O sursă comună pentru datele din depozitele de date sunt bazele de date operaționale ale companiei, care pot fi baze de date relaționale”.

În ceea ce privește integrarea datelor, Rainer afirmă: „Este necesar să extrageți date din sistemele sursă, să le transformați și să le încărcați într-un depozit sau într-un depozit de date”.

Rainer discută despre stocarea datelor în depozitul de date al unei organizații sau în data marts.

Metadatele sunt date despre date. "Personalul IT are nevoie de informații despre sursele de date; numele bazelor de date, tabelelor și coloanelor; programele de reîmprospătare și măsurile de utilizare a datelor".

Astăzi, cele mai de succes companii sunt cele care pot răspunde rapid și flexibil la schimbările și oportunitățile pieței. O cheie a acestui răspuns este utilizarea eficientă și eficientă a datelor și informațiilor de către analiști și manageri. Un „depozit de date” este un depozit de date istorice care este organizat de subiect pentru a sprijini factorii de decizie din organizație. Odată ce datele sunt stocate într-un magazin de date sau un depozit, acestea pot fi accesate.

Sisteme conexe (date mart, OLAPS, OLTP, analize predictive)

Un martie de date este o formă simplă de depozit de date care se concentrează pe un singur subiect (sau zonă funcțională), prin urmare, extrag date dintr-un număr limitat de surse, cum ar fi vânzări, finanțe sau marketing. Marturile de date sunt adesea construite și controlate de un singur departament din cadrul unei organizații. Sursele ar putea fi sisteme operaționale interne, un depozit central de date sau date externe. Denormalizarea este norma pentru tehnicile de modelare a datelor în acest sistem. Având în vedere că datele martiale acoperă în general doar un subset de date conținute într-un depozit de date, acestea sunt adesea mai ușor și mai rapide de implementat.

Diferența dintre depozitul de date și data mart
Atribut Depozit de date Data mart
Domeniul de aplicare al datelor la nivel de întreprindere la nivel de departament
Numărul de domenii multiplu singur
Ce greu de construit dificil uşor
Cât timp durează pentru a construi Mai mult Mai puțin
Cantitatea de memorie mai mare limitat

Tipurile de marturi de date includ marturi de date dependente , independente și hibride.

Procesarea analitică online (OLAP) se caracterizează printr-un volum relativ mic de tranzacții. Interogările sunt adesea foarte complexe și implică agregări. Pentru sistemele OLAP, timpul de răspuns este o măsură eficientă. Aplicațiile OLAP sunt utilizate pe scară largă de tehnicile de Data Mining . Bazele de date OLAP stochează date istorice agregate în scheme multidimensionale (de obicei scheme stelare ). Sistemele OLAP au de obicei o latență a datelor de câteva ore, spre deosebire de date marts, în care se așteaptă ca latența să fie mai aproape de o zi. Abordarea OLAP este utilizată pentru a analiza date multidimensionale din mai multe surse și perspective. Cele trei operațiuni de bază din OLAP sunt Roll-up (Consolidare), Drill-down și Slicing & Dicing.

Procesarea tranzacțiilor online (OLTP) se caracterizează printr-un număr mare de tranzacții scurte on-line (INSERT, UPDATE, DELETE). Sistemele OLTP subliniază procesarea foarte rapidă a interogărilor și menținerea integrității datelor în medii cu acces multiplu. Pentru sistemele OLTP, eficacitatea se măsoară prin numărul de tranzacții pe secundă. Bazele de date OLTP conțin date detaliate și actuale. Schema utilizată pentru stocarea bazelor de date tranzacționale este modelul entității (de obicei 3NF ). Normalizarea este norma pentru tehnicile de modelare a datelor în acest sistem.

Analiza predictivă se referă la găsirea și cuantificarea tiparelor ascunse în date folosind modele matematice complexe care pot fi utilizate pentru a prezice rezultatele viitoare. Analiza predictivă este diferită de OLAP prin faptul că OLAP se concentrează pe analiza datelor istorice și este reactivă în natură, în timp ce analiza predictivă se concentrează pe viitor. Aceste sisteme sunt utilizate și pentru gestionarea relației cu clienții (CRM).

Istorie

Conceptul de stocare a datelor datează de la sfârșitul anilor 1980, când cercetătorii IBM Barry Devlin și Paul Murphy au dezvoltat „antrepozitul de date pentru afaceri”. În esență, conceptul de depozitare a datelor a fost destinat să ofere un model arhitectural pentru fluxul de date de la sistemele operaționale la mediile de sprijinire a deciziilor . Conceptul a încercat să abordeze diferitele probleme asociate acestui flux, în principal costurile ridicate asociate acestuia. În absența unei arhitecturi de depozitare a datelor, a fost necesară o cantitate enormă de redundanță pentru a sprijini mai multe medii de sprijin pentru decizii. În corporațiile mai mari, era obișnuit ca mai multe medii de sprijinire a deciziilor să funcționeze independent. Deși fiecare mediu a deservit utilizatori diferiți, deseori au necesitat o mare parte din aceleași date stocate. Procesul de colectare, curățare și integrare a datelor din diverse surse, de obicei din sistemele operaționale existente pe termen lung (denumite de obicei sisteme vechi ), a fost de obicei reprodus parțial pentru fiecare mediu. Mai mult, sistemele operaționale au fost frecvent reexaminate pe măsură ce au apărut noi cerințe de sprijin pentru luarea deciziilor. Adesea, noile cerințe au necesitat colectarea, curățarea și integrarea noilor date din „ martie de date ”, care au fost adaptate pentru accesul rapid al utilizatorilor.

În plus, odată cu publicarea The IRM Imperative (Wiley & Sons, 1991) de James M. Kerr, a devenit populară ideea de a gestiona și a pune o valoare în dolari asupra resurselor de date ale unei organizații și apoi de a raporta acea valoare ca activ într-un bilanț . În carte, Kerr a descris o modalitate de a popula bazele de date din subiecte din datele derivate din sistemele bazate pe tranzacții pentru a crea o zonă de stocare în care datele rezumative să poată fi folosite în continuare pentru a informa deciziile executive. Acest concept a servit pentru a promova gândirea în continuare a modului în care un depozit de date ar putea fi dezvoltat și gestionat într-un mod practic în cadrul oricărei întreprinderi.

Evoluții cheie în primii ani de depozitare a datelor:

  • Anii 1960 - General Mills și Dartmouth College , într-un proiect comun de cercetare, dezvoltă termenii dimensiuni și fapte .
  • Anii 1970 - ACNielsen și IRI furnizează date martiale dimensionale pentru vânzările cu amănuntul.
  • Anii 1970 - Bill Inmon începe să definească și să discute termenul Data Warehouse.
  • 1975 - Sperry Univac introduce MAPPER (MAintain, Prepare și Produce Executive Reports), un sistem de gestionare și raportare a bazelor de date care include primul 4GL din lume . Este prima platformă concepută pentru construirea de centre de informații (un precursor al tehnologiei contemporane de depozitare a datelor).
  • 1983 - Teradata introduce computerul bazei de date DBC / 1012 conceput special pentru sprijinirea deciziilor.
  • 1984 - Metaphor Computer Systems , fondată de David Liddle și Don Massaro, lansează un pachet hardware / software și GUI pentru utilizatorii de afaceri pentru a crea un sistem de analiză și gestionare a bazelor de date.
  • 1985 - Sperry Corporation publică un articol (Martyn Jones și Philip Newman) despre centrele de informații, unde introduc termenul depozit de date MAPPER în contextul centrelor de informații.
  • 1988 - Barry Devlin și Paul Murphy publică articolul „O arhitectură pentru o afacere și un sistem informațional” unde introduc termenul „antrepozit de date pentru afaceri”.
  • 1990 - Red Brick Systems, fondată de Ralph Kimball , introduce Red Brick Warehouse, un sistem de gestionare a bazelor de date special pentru depozitarea datelor.
  • 1991 - James M. Kerr autorii Imperativul IRM, care sugerează că resursele de date ar putea fi raportate ca un activ într-un bilanț, promovând interesul comercial în înființarea depozitelor de date.
  • 1991 - Prism Solutions, fondată de Bill Inmon , introduce Prism Warehouse Manager, software pentru dezvoltarea unui depozit de date.
  • 1992 - Bill Inmon publică cartea Building the Data Warehouse .
  • 1995 - Se înființează Institutul de depozitare a datelor, o organizație cu scop lucrativ care promovează depozitarea datelor.
  • 1996 - Ralph Kimball publică cartea The Data Warehouse Toolkit .
  • 2000 - Dan Linstedt lansează în domeniul public modelarea bazei de date , concepută în 1990 ca o alternativă la Inmon și Kimball pentru a furniza stocarea istorică pe termen lung a datelor provenite din mai multe sisteme operaționale, cu accent pe urmărire, audit și rezistența la schimbare a modelului de date sursă.
  • 2008 - Bill Inmon , împreună cu Derek Strauss și Genia Neushloss, publică „DW 2.0: Arhitectura pentru următoarea generație de depozitare de date”, explicând abordarea sa de sus în jos a depozitării de date și inventând termenul, depozitare de date 2.0.
  • 2012 - Bill Inmon dezvoltă și face cunoscută tehnologia publică sub numele de „dezambiguizare textuală”. Dezambiguizarea textuală aplică contextul textului brut și reformatează textul brut și contextul într-un format standard de bază de date. Odată ce textul brut este trecut prin dezambiguizare textuală, acesta poate fi accesat și analizat cu ușurință și în mod eficient prin tehnologia standard de business intelligence. Dezambiguizarea textuală se realizează prin executarea ETL textual. Dezambiguizarea textului este utilă oriunde se găsește textul brut, cum ar fi în documente, Hadoop, e-mail și așa mai departe.

Stocarea informațiilor

Fapte

Un fapt este o valoare, sau măsurare, care reprezintă un fapt despre entitatea sau sistemul administrat.

Faptele, astfel cum au fost raportate de entitatea raportoare, se spune că sunt la nivel brut; de exemplu, într-un sistem de telefonie mobilă, dacă un BTS ( stație de emisie-recepție de bază ) primește 1.000 de cereri de alocare a canalelor de trafic, alocă pentru 820 și respinge restul, va raporta trei fapte sau măsurători unui sistem de management:

  • tch_req_total = 1000
  • tch_req_success = 820
  • tch_req_fail = 180

Faptele de la nivelul brut sunt în continuare agregate la niveluri superioare în diferite dimensiuni pentru a extrage din acesta mai multe informații relevante pentru servicii sau afaceri. Acestea se numesc agregate sau rezumate sau fapte agregate.

De exemplu, dacă există trei BTS într-un oraș, atunci faptele de mai sus pot fi agregate de la BTS la nivelul orașului în dimensiunea rețelei. De exemplu:

  • tch_req_success_city = tch_req_success_bts1 + tch_req_success_bts2 + tch_req_success_bts3
  • avg_tch_req_success_city = (tch_req_success_bts1 + tch_req_success_bts2 + tch_req_success_bts3) / 3

Abordare dimensională versus normalizată pentru stocarea datelor

Există trei sau mai multe abordări principale pentru stocarea datelor într-un depozit de date - cele mai importante abordări sunt abordarea dimensională și abordarea normalizată.

Abordarea dimensională se referă la abordarea lui Ralph Kimball în care se afirmă că depozitul de date ar trebui să fie modelat folosind un model dimensional / schemă stelară . Abordarea normalizată, numită și modelul 3NF (Third Normal Form), se referă la abordarea lui Bill Inmon în care se afirmă că depozitul de date ar trebui să fie modelat folosind un model ER / model normalizat.

Abordare dimensională

Într-o abordare dimensională , datele despre tranzacții sunt partiționate în „fapte”, care sunt în general date numerice despre tranzacții și „ dimensiuni ”, care sunt informațiile de referință care dau context faptelor. De exemplu, o tranzacție de vânzare poate fi împărțită în fapte precum numărul de produse comandate și prețul total plătit pentru produse și în dimensiuni precum data comenzii, numele clientului, numărul produsului, expedierea comenzii și facturarea locații și agentul de vânzări responsabil pentru primirea comenzii.

Un avantaj cheie al unei abordări dimensionale este că depozitul de date este mai ușor de înțeles și utilizat de utilizator. De asemenea, extragerea datelor din depozitul de date tinde să funcționeze foarte repede. Structurile dimensionale sunt ușor de înțeles pentru utilizatorii de afaceri, deoarece structura este împărțită în măsurători / fapte și context / dimensiuni. Faptele sunt legate de procesele de afaceri ale organizației și de sistemul operațional, în timp ce dimensiunile care le înconjoară conțin context despre măsurare (Kimball, Ralph 2008). Un alt avantaj oferit de modelul dimensional este că nu implică de fiecare dată o bază de date relațională. Astfel, acest tip de tehnică de modelare este foarte util pentru interogările utilizatorului final din depozitul de date.

Modelul faptelor și dimensiunilor poate fi de asemenea înțeles ca un cub de date . În cazul în care dimensiunile sunt coordonatele categorice într-un cub multidimensional, faptul este o valoare corespunzătoare coordonatelor.

Principalele dezavantaje ale abordării dimensionale sunt următoarele:

  1. Pentru a menține integritatea faptelor și dimensiunilor, încărcarea depozitului de date cu date din diferite sisteme operaționale este complicată.
  2. Este dificil să modificați structura depozitului de date dacă organizația care adoptă abordarea dimensională schimbă modul în care își desfășoară activitatea.

Abordarea normalizată

În abordarea normalizată, datele din depozitul de date sunt stocate urmând, într-o anumită măsură, reguli de normalizare a bazei de date . Tabelele sunt grupate pe subiecte care reflectă categorii generale de date (de exemplu, date despre clienți, produse, finanțe etc.). Structura normalizată împarte datele în entități, ceea ce creează mai multe tabele într-o bază de date relațională. Atunci când este aplicat în întreprinderi mari, rezultatul este zeci de tabele care sunt legate între ele printr-o rețea de îmbinări. Mai mult, fiecare dintre entitățile create este convertită în tabele fizice separate atunci când baza de date este implementată (Kimball, Ralph 2008). Principalul avantaj al acestei abordări este că este simplu să adăugați informații în baza de date. Unele dezavantaje ale acestei abordări sunt că, din cauza numărului de tabele implicate, poate fi dificil pentru utilizatori să unească date din diferite surse în informații semnificative și să acceseze informațiile fără o înțelegere precisă a surselor de date și a structurii datelor. a depozitului de date.

Ambele modele normalizate și dimensionale pot fi reprezentate în diagrame entitate-relație, deoarece ambele conțin tabele relaționale unite. Diferența dintre cele două modele este gradul de normalizare (cunoscut și sub denumirea de forme normale ). Aceste abordări nu se exclud reciproc și există și alte abordări. Abordările dimensionale pot implica normalizarea datelor într-un anumit grad (Kimball, Ralph 2008).

În Business-Driven Business , Robert Hillard propune o abordare pentru a compara cele două abordări pe baza nevoilor de informații ale problemei de afaceri. Tehnica arată că modelele normalizate conțin mult mai multe informații decât echivalentele lor dimensionale (chiar și atunci când sunt utilizate aceleași câmpuri în ambele modele), dar aceste informații suplimentare sunt în detrimentul utilizabilității. Tehnica măsoară cantitatea de informații în termeni de entropie informațională și de utilizare în termeni de măsură de transformare a datelor în Lumile Mici.

Metode de proiectare

Design de jos în sus

În abordarea de jos în sus , martele de date sunt create mai întâi pentru a oferi rapoarte și capacități analitice pentru anumite procese de afaceri . Aceste date martie pot fi apoi integrate pentru a crea un depozit de date cuprinzător. Arhitectura autobuzului de depozit de date este în primul rând o implementare a „autobuzului”, o colecție de dimensiuni conformate și fapte conforme , care sunt dimensiuni care sunt partajate (într-un mod specific) între fapte în două sau mai multe marturi de date.

Design de sus în jos

Abordarea de sus în jos este concepută utilizând un model de date întreprindere normalizat . Datele „atomice” , adică datele la cel mai înalt nivel de detaliu, sunt stocate în depozitul de date. Martorii de date dimensionale care conțin date necesare pentru anumite procese de afaceri sau departamente specifice sunt create din depozitul de date.

Design hibrid

Depozitele de date (DW) seamănă adesea cu arhitectura hub și spițe . Sistemele vechi care alimentează depozitul includ adesea managementul relației cu clienții și planificarea resurselor întreprinderii , generând cantități mari de date. Pentru a consolida aceste diferite modele de date și a facilita procesul de încărcare a transformării extraselor , depozitele de date folosesc adesea un depozit de date operațional , informațiile din care sunt analizate în DW-ul real. Pentru a reduce redundanța datelor, sistemele mai mari stochează adesea datele într-un mod normalizat. Martorii de date pentru rapoarte specifice pot fi apoi construiți deasupra depozitului de date.

O bază de date DW hibridă este păstrată pe a treia formă normală pentru a elimina redundanța datelor . O bază de date relațională normală, totuși, nu este eficientă pentru rapoartele de business intelligence în care modelarea dimensională este predominantă. Martorii de date mici pot cumpăra date din depozitul consolidat și pot utiliza datele specifice filtrate pentru tabelele de date și dimensiunile necesare. DW oferă o singură sursă de informații din care pot fi citite martorii de date, oferind o gamă largă de informații comerciale. Arhitectura hibridă permite înlocuirea unui DW cu un depozit principal de gestionare a datelor în care ar putea locui informații operaționale (nu statice).

Componentele de modelare a seifului de date urmează arhitectura hub și spițe. Acest stil de modelare este un design hibrid, constând din cele mai bune practici atât din forma a treia normală, cât și din schema stelelor . Modelul seifului de date nu este o adevărată a treia formă normală și încalcă unele dintre regulile sale, dar este o arhitectură de sus în jos, cu un design de jos în sus. Modelul seifului de date este conceput pentru a fi strict un depozit de date. Nu este conceput pentru a fi accesibil utilizatorului final, care, atunci când este construit, necesită în continuare utilizarea unei date mart sau a unei zone de lansare bazate pe schemă stelară în scopuri comerciale.

Caracteristicile depozitului de date

Există caracteristici de bază care definesc datele din depozitul de date care includ orientarea subiectului, integrarea datelor, varianta de timp, datele nonvolatile și granularitatea datelor.

Orientat spre subiect

Spre deosebire de sistemele operaționale, datele din depozitul de date se învârt în jurul subiectelor întreprinderii. Orientarea subiectului nu este normalizarea bazei de date . Orientarea subiectului poate fi cu adevărat utilă pentru luarea deciziilor. Adunarea obiectelor necesare se numește orientată spre subiect.

Integrat

Datele găsite în depozitul de date sunt integrate. Deoarece provine din mai multe sisteme operaționale, toate neconcordanțele trebuie eliminate. Coerențele includ convenții de denumire, măsurarea variabilelor, structuri de codificare, atribute fizice ale datelor și așa mai departe.

Varianta timpului

În timp ce sistemele operaționale reflectă valorile actuale, deoarece susțin operațiunile de zi cu zi, datele din depozitele de date reprezintă un orizont lung de timp (până la 10 ani) ceea ce înseamnă că stochează în principal date istorice. Este destinat în principal pentru extragerea datelor și pentru prognoză. (De exemplu, dacă un utilizator caută un model de cumpărare pentru un anumit client, acesta trebuie să analizeze datele privind achizițiile curente și anterioare.)

Ne volatil

Datele din depozitul de date sunt doar în citire, ceea ce înseamnă că nu pot fi actualizate, create sau șterse (cu excepția cazului în care există o obligație reglementară sau legală de a face acest lucru).

Opțiuni de depozitare de date

Agregare

În procesul de stocare a datelor, datele pot fi agregate în martie de date la diferite niveluri de abstractizare. Utilizatorul poate începe să analizeze unitățile totale de vânzare ale unui produs într-o regiune întreagă. Apoi utilizatorul se uită la stările din acea regiune. În cele din urmă, pot examina magazinele individuale într-un anumit stat. Prin urmare, în mod obișnuit, analiza începe la un nivel mai înalt și trece la niveluri mai mici de detalii.

Arhitectura depozitului de date

Diferitele metode utilizate pentru a construi / organiza un depozit de date specificat de o organizație sunt numeroase. Hardware-ul utilizat, software-ul creat și resursele de date necesare în mod specific pentru funcționalitatea corectă a unui depozit de date sunt principalele componente ale arhitecturii depozitului de date. Toate depozitele de date au faze multiple în care cerințele organizației sunt modificate și ajustate.

Versus sistemul operațional

Sistemele operaționale sunt optimizate pentru păstrarea integrității datelor și a vitezei de înregistrare a tranzacțiilor comerciale prin utilizarea normalizării bazei de date și a unui model entitate-relație . Proiectanții de sistem operațional respectă, în general, cele 12 reguli de normalizare a bazei de date Codd pentru a asigura integritatea datelor. Proiectele de baze de date complet normalizate (adică cele care îndeplinesc toate regulile Codd) duc adesea la stocarea informațiilor dintr-o tranzacție comercială în zeci până la sute de tabele. Bazele de date relaționale sunt eficiente în gestionarea relațiilor dintre aceste tabele. Bazele de date au performanțe de inserare / actualizare foarte rapide, deoarece doar o cantitate mică de date din aceste tabele este afectată de fiecare dată când este procesată o tranzacție. Pentru a îmbunătăți performanța, datele mai vechi sunt de obicei eliminate periodic din sistemele operaționale.

Depozitele de date sunt optimizate pentru modele de acces analitic. Modelele de acces analitic implică în general selectarea câmpurilor specifice și rareori, dacă este vreodată select *, care selectează toate câmpurile / coloanele, așa cum este mai frecvent în bazele de date operaționale. Datorită acestor diferențe în tiparele de acces, bazele de date operaționale (vag, OLTP) beneficiază de utilizarea unui SGBD orientat pe rând, în timp ce bazele de date analitice (vag, OLAP) beneficiază de utilizarea unui SGBD orientat pe coloane . Spre deosebire de sistemele operaționale care păstrează un instantaneu al afacerii, depozitele de date mențin în general un istoric infinit care este implementat prin procese ETL care migrează periodic date din sistemele operaționale către depozitul de date.

Evoluția în utilizarea organizației

Acești termeni se referă la nivelul de rafinament al unui depozit de date:

Depozit de date operaționale offline
Depozitele de date din această etapă de evoluție sunt actualizate pe un ciclu de timp regulat (de obicei zilnic, săptămânal sau lunar) din sistemele operaționale și datele sunt stocate într-o bază de date integrată orientată spre raportare.
Depozit de date offline
Depozitele de date din această etapă sunt actualizate în mod regulat din datele din sistemele operaționale, iar datele din depozitul de date sunt stocate într-o structură de date concepută pentru a facilita raportarea.
Depozit de date la timp
Depozitarea integrată de date online reprezintă depozitul de date în timp real datele din depozit sunt actualizate pentru fiecare tranzacție efectuată pe datele sursă
Depozit de date integrat
Aceste depozite de date colectează date din diferite domenii de activitate, astfel încât utilizatorii să poată căuta informațiile de care au nevoie în alte sisteme.

Referințe

Lecturi suplimentare