Depozitarea datelor și planificarea resurselor întreprinderii | DWH și ERP

ARHIVA DATE CENTRAL : ISTORIE ED EVOLUŢIE

Cele două teme dominante ale tehnologiei corporative în anii 90 au fost i depozit de date și ERP-ul. Multă vreme, aceste două fluxuri puternice au făcut parte din IT-ul corporativ fără a avea vreodată o intersecție. Era aproape ca și cum ar fi materie și antimaterie. Dar creșterea ambelor fenomene a dus inevitabil la intersecția lor. Astăzi companiile se confruntă cu problema ce să facă cu ERP și depozit de date. Acest articol va explica care sunt problemele și cum sunt rezolvate de companii.

LA INCEPUT…

La început a existat depozit de date. Depozit de date s-a născut pentru a contracara sistemul de aplicații de procesare a tranzacțiilor. În primele zile memorarea de date a fost menit să fie doar un contrapunct al aplicațiilor de procesare a tranzacțiilor. Dar în zilele noastre există viziuni mult mai sofisticate despre ceea ce a depozit de date. În lumea de astăzi, depozit de date este inserat într-o structură care poate fi numită Fabrica de informații corporative.

FABRICA DE INFORMAȚII CORPORATE (CIF)

Fabrica de informații corporative are componente arhitecturale standard: un strat de integrare și transformare a codului care integrează i de date în timp ce i de date se deplasează din mediul de aplicare în mediul de depozit de date al companiei; A depozit de date a companiei în care de date istorici detaliați și integrați. The depozit de date a întreprinderii servește drept fundație pe care pot fi construite toate celelalte părți ale mediului depozit de date; un depozit de date operaționale (ODS). Un ODS este o structură hibridă care conține un anumit aspect al depozit de date și alte aspecte ale unui mediu OLTP; marturi de date, unde diferite departamente pot avea propria lor versiune a depozit de date; A depozit de date explorare în care gânditorii companiei își pot trimite interogările de 72 de ore fără niciun efect dăunător asupra depozit de date; și o memorie aproape de linie, în care de date batran si de date detaliile în vrac pot fi stocate la ieftin.

UNDE SE COMBINA ERP-UL CU FABRICĂ DE INFORMAȚII CORPORATE

ERP-ul fuzionează cu Fabrica de informații corporative în două locuri. În primul rând ca o aplicație de bază care oferă i de date a cererii către depozit de date. În acest caz i de date, generate ca un produs secundar al unui proces de tranzacție, sunt integrate și încărcate în depozit de date al companiei. A doua legătură între ERP și CIF este ODS. Într-adevăr, în multe medii ERP este folosit ca ODS clasic.

În cazul în care ERP este utilizat ca aplicație de bază, același ERP poate fi folosit și în CIF ca ODS. În orice caz, dacă ERP urmează să fie utilizat în ambele roluri, trebuie să existe o distincție clară între cele două entități. Cu alte cuvinte, atunci când ERP joacă rolul de aplicație de bază și ODS, trebuie să se distingă cele două entități arhitecturale. Dacă o singură implementare a unui ERP încearcă să îndeplinească ambele roluri simultan, vor apărea inevitabil probleme în proiectarea și implementarea acelei structuri.

ODS SEPARATE ȘI APLICAȚII DE BAZĂ

Există multe motive care duc la împărțirea componentelor arhitecturale. Poate cel mai grăitor punct în separarea diferitelor componente ale unei arhitecturi este că fiecare componentă a arhitecturii are propria sa viziune. Aplicația de bază are un alt scop decât ODS. Încercați să vă suprapuneți

o viziune de bază a aplicației asupra lumii unui ODS sau invers nu este o modalitate corectă de a lucra.

În consecință, prima problemă a unui ERP în CIF este de a verifica dacă există o distincție între aplicațiile de bază și ODS.

MODELE DE DATE ÎN CORPORATE FABRICĂ DE INFORMAȚII

Pentru a realiza coeziunea între diferitele componente ale arhitecturii CIF, trebuie să existe un model de de date. Modelele de de date ele servesc ca o legătură între diferitele componente ale arhitecturii, cum ar fi aplicațiile de bază și ODS. Modelele de de date ele devin „foaia de parcurs intelectual” pentru a obține sensul potrivit din diferitele componente arhitecturale ale CIF.

Mergând mână în mână cu această noțiune, ideea este că ar trebui să existe un model mare și unic de date. Evident că trebuie să existe un model de de date pentru fiecare dintre componente și, în plus, trebuie să existe o cale sensibilă care să conecteze diferitele modele. Fiecare componentă a arhitecturii – ODS, aplicații de bază, depozit de date a companiei și așa mai departe.. – are nevoie de propriul model de de date. Și deci trebuie să existe o definiție precisă a modului în care aceste modele de de date ele interacționează între ele.

MUȘCARE I DATE A ERP-ului ÎN DATE DEPOZIT

Dacă originea de date este o aplicație de bază și/sau un ODS, atunci când ERP introduce i de date în depozit de date, această inserare trebuie să aibă loc la cel mai scăzut nivel de „granularitate”. Pur și simplu recapitulați sau agregați i de date pe măsură ce ies din aplicația de bază ERP sau ERP ODS nu este lucrul corect de făcut. THE de date sunt necesare detalii în depozit de date pentru a forma baza procesului DSS. Astfel de de date ele vor fi remodelate în multe feluri prin data marts și explorare depozit de date.

Mutarea lui de date de la mediul de aplicație de bază ERP la depozit de date al companiei se face într-o manieră relativ relaxată. Această mutare are loc la aproximativ 24 de ore de la actualizare sau creare în ERP. Faptul de a avea o mișcare „leneșă” a de date în depozit de date al companiei permite de date venind de la ERP să se „reconecteze”. Odată eu de date sunt stocate în aplicația de bază, apoi puteți muta în siguranță de date a ERP-ului în întreprindere. Un alt obiectiv care poate fi atins datorită mișcării „leneșe” a lui de date este delimitarea clară între procesele operaționale și DSS. Cu o mișcare „rapidă” a de date linia dintre DSS și operațional rămâne vagă.

Mișcarea de de date de la ODS-ul ERP la depozit de date al companiei se face periodic, de obicei săptămânal sau lunar. În acest caz mișcarea de de date se bazează pe necesitatea „curățării” celor vechi de date istorici. Desigur, ODS conține i de date care sunt mult mai noi decât cele de date istoricii gasiti in depozit de date.

Mutarea lui de date în depozit de date aproape niciodată nu se face „cu ridicata” (într-o manieră cu ridicata). Copiați un tabel din mediul ERP în depozit de date nu are sens. O abordare mult mai realistă este de a muta anumite unități de de date. Doar de date care s-au schimbat de la ultima actualizare a depozit de date sunt cele care ar trebui mutate în depozit de date. O modalitate de a ști care dintre ele de date s-au schimbat de la ultima actualizare este să se uite la marcajele de timp ale de date găsite în mediul ERP. Designerul selectează toate modificările care au avut loc de la ultima actualizare. O altă abordare este utilizarea tehnicilor de captare a schimbărilor de date. Cu aceste tehnici sunt analizate jurnalele și casetele jurnal pentru a determina care dintre ele de date trebuie mutat din mediul ERP în cel al depozit de date. Aceste tehnici sunt cele mai bune, deoarece jurnalele și casetele de jurnal pot fi citite din fișierele ERP fără un efect suplimentar asupra altor resurse ERP.

ALTE COMPLICATII

Una dintre problemele ERP din CIF este ceea ce se întâmplă cu alte surse de aplicații sau IA de date a ODS la care trebuie să contribuie depozit de date dar nu fac parte din mediul ERP. Având în vedere natura închisă a ERP, în special SAP, încercarea de a integra chei din surse externe ale de date cu i de date care provin din ERP la momentul mutarii i de date în depozit de date, este o mare provocare. Și care sunt exact probabilitățile ca i de date de aplicații sau ODS din afara mediului ERP vor fi integrate în depozit de date? De fapt, șansele sunt foarte mari.

GĂSI DATE ISTORIC DIN ERP

O altă problemă cu i de date a ERP este cea care derivă din nevoia de a avea de date istorici din cadrul depozit de date. De obicei, cel depozit de date are nevoie de date istorici. Și tehnologia ERP de obicei nu stochează acestea de date istoric, cel puţin nu în măsura în care este necesar în depozit de date. Când o cantitate mare de de date jurnalele încep să se adună în mediul ERP, acel mediu trebuie curățat. De exemplu, să presupunem că a depozit de date ar trebui să fie încărcat cu cinci ani de de date istoric în timp ce ERP păstrează maximum șase luni din acestea de date. Atâta timp cât compania este mulțumită să colecteze un număr de de date istoric pe măsură ce trece timpul, atunci nu există nicio problemă în utilizarea ERP-ului ca sursă pentru depozit de date. Dar când depozit de date trebuie să se întoarcă în timp și să ia zei de date înregistrările care nu au fost colectate și salvate anterior de ERP, atunci mediul ERP devine ineficient.

ERP ȘI METADATE

O altă considerație de făcut despre ERP e depozit de date este cea de pe metadatele existente în mediul ERP. Așa cum metadatele se mută din mediul ERP la depozit de date, metadatele trebuie mutate în același mod. În plus, metadatele trebuie transformate în formatul și structura cerute de infrastructură depozit de date. Există o mare diferență între metadatele operaționale și metadatele DSS. Metadatele operaționale sunt în principal pentru dezvoltator și pentru

programator. Metadatele DSS sunt în primul rând pentru utilizatorul final. Metadatele existente în aplicațiile ERP sau ODS-uri trebuie convertite, iar această conversie nu este întotdeauna ușoară și simplă.

SURSA DE DATE ERP

Dacă ERP-ul este utilizat ca furnizor de de date pentru depozit de date trebuie să existe o interfață solidă care să miște i de date de la mediul ERP la mediu depozit de date. Interfața trebuie să:

• ▪ să fie ușor de utilizat
• ▪ permite accesul la de date a ERP-ului
• ▪ prelua sensul de de date care sunt mutate în depozit de date
• ▪ să cunoască limitările ERP care ar putea apărea la accesarea de date al ERP:
• ▪ integritatea referenţială
• ▪ relaţii ierarhice
• ▪ relaţii logice implicite
• ▪ convenţia de aplicare
• ▪ toate structurile de de date susținut de ERP și așa mai departe...
• ▪ să fie eficient în accesare de date, furnizand:
• ▪ mişcarea directă a de date
• ▪ dobândirea schimbării de date
• ▪ sprijină accesul în timp util la de date
• ▪ înțelegeți formatul de date, și așa mai departe… INTERFATA CU SAP Interfața poate fi de două tipuri, autohtonă sau comercială. Unele dintre interfețele comerciale majore includ:

• ▪ SAS
• ▪ Prime Solutions
• ▪ D2k și așa mai departe... MULTIPLE TEHNOLOGII ERP Tratarea mediului ERP ca și cum ar fi o singură tehnologie este o mare greșeală. Există multe tehnologii ERP, fiecare cu punctele sale forte. Cei mai cunoscuți furnizori de pe piață sunt:

• ▪ SAP
• ▪ Oracle Financials
• ▪ PeopleSoft
• JD Edwards
• ▪ Baans SAP SAP este cel mai mare și mai cuprinzător software ERP. Aplicațiile SAP includ multe tipuri de aplicații în multe domenii. SAP are reputația de a fi:

• ▪ foarte mare
• ▪ foarte dificil și costisitor de implementat
• ▪ are nevoie de mulți oameni și consultanți pentru implementare
• ▪ are nevoie de oameni specializati pentru implementare
• ▪ are nevoie de mult timp pentru a implementa De asemenea, SAP are o reputație de memorare de date îndeaproape, făcând dificil pentru cineva din afara zonei SAP să le acceseze. Puterea SAP este că este capabil să capteze și să stocheze o cantitate mare de de date. SAP și-a anunțat recent intenția de a-și extinde aplicațiile la depozit de date. Există multe avantaje și dezavantaje în utilizarea SAP ca furnizor depozit de date. Un avantaj este că SAP este deja instalat și majoritatea consultanților sunt deja familiarizați cu SAP.
  Dezavantajele de a avea SAP ca furnizor de depozit de date sunt multe: SAP nu are experiență în lumea depozit de date Dacă SAP este furnizorul de depozit de date, este necesar să „scoate” i de date de la SAP la depozit de date. Data un istoric SAP de sistem închis, este puțin probabil să fie ușor să obțineți eu de la SAP în el (???). Există multe medii vechi care alimentează SAP, cum ar fi IMS, VSAM, ADABAS, ORACLE, DB2 și așa mai departe. SAP insistă asupra unei abordări „nu inventat aici”. SAP nu dorește să colaboreze cu alți furnizori pentru a utiliza sau a crea depozit de date. SAP insistă să-și genereze propriul software.

Deși SAP este o companie mare și puternică, faptul de a încerca să rescrie tehnologia ELT, OLAP, administrarea sistemului și chiar baza de cod a dbms este doar o nebunie. În loc să luați o atitudine de cooperare cu furnizorii depozit de date De mult timp, SAP a urmat abordarea pe care „o cunosc cel mai bine”. Această atitudine împiedică succesul pe care SAP l-ar putea avea în domeniu depozit de date.
Refuzul SAP de a permite furnizorilor externi să le acceseze prompt și grațios pe ale lor de date. Însăși esența utilizării a depozit de date este ușor de accesat de date. Întreaga poveste a SAP se bazează pe îngreunarea accesului de date.
Lipsa de experiență a SAP în tratarea unor volume mari de de date; în domeniul depozit de date sunt volume de de date niciodată văzut de la SAP și pentru a gestiona aceste cantități mari de de date trebuie să ai tehnologia potrivită. SAP se pare că nu este conștient de această barieră tehnologică care există pentru a intra în domeniul depozit de date.
Cultura corporativă SAP: SAP a construit o afacere în obținerea i de date din sistem. Dar pentru a face asta trebuie să ai o altă mentalitate. În mod tradițional, companiile de software care au fost bune în introducerea datelor într-un mediu nu au fost bune în a face ca datele să meargă în sens invers. Dacă SAP reușește să facă acest tip de schimbare, va fi prima companie care va face acest lucru.

Pe scurt, este discutabil dacă o companie ar trebui să selecteze SAP ca furnizor al depozit de date. Există riscuri foarte serioase pe de o parte și foarte puține recompense pe de altă parte. Dar există un alt motiv care descurajează alegerea SAP ca furnizor depozit de date. Pentru că fiecare companie ar trebui să aibă același lucru depozit de date a tuturor celorlalte companii? The depozit de date este inima avantajului competitiv. Dacă fiecare companie ar adopta același lucru depozit de date ar fi dificil, deși nu imposibil, să obții un avantaj competitiv. SAP pare să creadă că a depozit de date poate fi privit ca un cookie și acesta este încă un semn al mentalității lor de a „introduce datele în” aplicații.

Niciun alt furnizor de ERP nu este la fel de dominant ca SAP. Fără îndoială vor exista companii care vor merge pe calea SAP pentru a lor depozit de date dar probabil acestea depozit de date SAP-urile vor fi mari, costisitoare și consumatoare de timp.

Aceste medii includ activități precum procesarea casierului bancar, procesele de rezervări ale companiilor aeriene, procesele de reclamații de asigurări și așa mai departe. Cu cât sistemul de tranzacții era mai performant, cu atât era mai evidentă nevoia de separare între procesul operațional și DSS (Decision Support System). Cu toate acestea, cu sistemele de resurse umane și de personal, nu te confrunți niciodată cu volume mari de tranzacții. Și, desigur, atunci când o persoană este angajată sau părăsește compania, aceasta este o înregistrare a unei tranzacții. Dar, comparativ cu alte sisteme, sistemele de resurse umane și de personal pur și simplu nu au multe tranzacții. Prin urmare, în sistemele de resurse umane și de personal nu este complet evident că este nevoie de un DataWarehouse. În multe privințe, aceste sisteme sunt amalgamări ale sistemelor DSS.

Dar există un alt factor care trebuie luat în considerare atunci când aveți de-a face cu datawarehouse și PeopleSoft. În multe cercuri, i de date HR și resursele personale sunt secundare activității principale ale companiei. Majoritatea companiilor produc, vând, furnizează servicii și așa mai departe. Sistemele de resurse umane și de personal sunt de obicei secundare (sau sprijină) linia principală de activitate a companiei. Prin urmare, este echivoc și incomod a depozit de date separat pentru suport pentru resurse umane și resurse personale.

PeopleSoft este foarte diferit de SAP în acest sens. Cu SAP, este obligatoriu să existe un depozit de date. Cu PeopleSoft, nu este chiar atât de clar. Un depozit de date este opțional cu PeopleSoft.

Cel mai bun lucru care se poate spune despre de date PeopleSoft este că depozit de date poate fi folosit pentru a arhiva i de date legate de vechile resurse umane și personale. Un al doilea motiv pentru care o companie ar dori să folosească un depozit de date a

dezavantajul mediului PeopleSoft este de a permite accesul și accesul gratuit la instrumentele de analiză, ai de date de PeopleSoft. Dar dincolo de aceste motive, pot exista cazuri în care este de preferat să nu ai un depozit de date pentru de date PeopleSoft.

În rezumat

Există multe idei care se referă la construcția unui depozit de date în interiorul unui software ERP.
Unele dintre acestea sunt:

• ▪ Are sens să ai un depozit de date cine seamana cu oricare altul din industrie?
• ▪ Cât de flexibil este un ERP depozit de date software-ul?
• ▪ Un ERP depozit de date software-ul poate gestiona un volum de de date care se află într-odepozit de date arenă"?
• ▪ Care este înregistrarea de urmărire pe care o face furnizorul ERP în fața unui IA ușor și ieftin, consumator de timp de date? (Care este istoricul furnizorilor de ERP privind livrarea de date ieftine, la timp și ușor de accesat?)
• ▪ Care este înțelegerea de către furnizorul ERP a arhitecturii DSS și a fabricii de informații corporative?
• ▪ Furnizorii ERP înțeleg cum să obțină de date în mediul înconjurător, dar înțelegeți și cum să le exportați?
• ▪ Cât de deschis este furnizorul ERP la instrumentele de depozitare a datelor?
  Toate aceste considerații trebuie luate în considerare atunci când se determină unde să se pună depozit de date care va găzdui i de date ale ERP și altele de date. În general, cu excepția cazului în care există un motiv convingător pentru a face altfel, se recomandă construirea depozit de date în afara mediului de furnizor ERP. CAPITOLUL 1 Prezentare generală a organizației BI Puncte cheie:
  Depozitele de informații funcționează în mod opus arhitecturii de business intelligence (BI):
  Cultura corporativă și IT pot limita succesul construirii organizațiilor BI.

Tehnologia nu mai este factorul limitativ pentru organizațiile BI. Problema pentru arhitecți și planificatorii de proiecte nu este dacă tehnologia există, ci dacă pot implementa eficient tehnologia disponibilă.

Pentru multe companii a depozit de date este puțin mai mult decât un depozit pasiv care distribuie i de date utilizatorilor care au nevoie de el. THE de date sunt extrase din sistemele sursă și sunt populate în structurile țintă de depozit de date. Eu de date se pot curata si cu orice noroc. Cu toate acestea, nicio valoare suplimentară nu este adăugată sau colectată de către de date în timpul acestui proces.

În esență, dw pasiv, în cel mai bun caz, oferă doar i de date curat și operațional pentru asociațiile de utilizatori. Crearea informațiilor și înțelegerea analitică depind în întregime de utilizatori. Judecând dacă DW (Depozit de date) dacă un succes este subiectiv. Dacă judecăm succesul pe baza capacității de a colecta, integra și curăța eficient i de date corporative pe o bază previzibilă, atunci da, DW este un succes. Pe de altă parte, dacă ne uităm la colectarea, consolidarea și exploatarea informațiilor organizației în ansamblu, atunci DW este un eșec. Un DW oferă o valoare informatică mică sau deloc. Drept urmare, utilizatorii sunt nevoiți să se descurce, creând astfel silozuri de informații. Acest capitol prezintă o viziune cuprinzătoare pentru a recapitula arhitectura BI (Business Intelligence) a întreprinderii. Începem cu o descriere a BI și apoi trecem la discuții despre proiectarea și dezvoltarea informațiilor, spre deosebire de simpla furnizare de date către utilizatori. Discuțiile se concentrează apoi pe calcularea valorii eforturilor dvs. de BI. Încheiem prin definirea modului în care IBM abordează cerințele arhitecturale BI ale organizației dumneavoastră.

Descrierea arhitecturii organizație BI

Sistemele de informații puternice orientate spre tranzacții sunt acum la ordinea zilei în fiecare mare întreprindere, echivalând efectiv condițiile de concurență pentru corporațiile din întreaga lume.

A rămâne competitiv, însă, necesită acum sisteme orientate analitic care pot revoluționa capacitatea companiei de a redescoperi și de a utiliza informațiile pe care le dețin deja. Aceste sisteme analitice derivă din înțelegerea din bogăția de date disponibil. BI poate îmbunătăți performanța tuturor informațiilor din cadrul întreprinderii. Companiile pot îmbunătăți relațiile client-furnizor, pot îmbunătăți profitabilitatea produselor și serviciilor, pot genera oferte noi și mai bune, pot controla riscul și, printre multe alte câștiguri, pot reduce drastic cheltuielile. Cu BI, compania ta începe în sfârșit să folosească informațiile despre clienți ca un activ competitiv datorită aplicațiilor care au obiective de piață.

A avea mijloacele de afaceri potrivite înseamnă a avea răspunsuri definitive la întrebări cheie precum:

• ▪ Care dintre noi clienții Ne fac să câștigăm mai mult sau ne fac să pierdem bani?
• ▪ Unde trăiesc cei mai buni ai noștri clienții în raport cu magazin/ depozit pe care îl frecventează?
• ▪ Care dintre produsele și serviciile noastre pot fi vândute cel mai eficient și cui?
• ▪ Ce produse pot fi vândute cel mai eficient și cui?
• ▪ Ce campanie de vânzări are mai mult succes și de ce?
• ▪ Ce canale de vânzare sunt cele mai eficiente pentru ce produse?
• ▪ Cum putem îmbunătăți relațiile cu cei mai buni clienții? Majoritatea companiilor au de date aspru să răspund la aceste întrebări.
  Sistemele operaționale generează cantități mari de produse, clienți și costuri de date din punctele de vânzare, rezervări, servicii clienți și sisteme de suport tehnic. Provocarea este extragerea și exploatarea acestor informații. Multe companii profită doar de mici fracțiuni ale lor de date pentru analize strategice.
  I de date rămasă, adesea combinată cu i de date surse externe, cum ar fi rapoartele guvernamentale și alte informații cumpărate, sunt o mină de aur care așteaptă să fie explorată și de date ele trebuie doar să fie rafinate în contextul informațional al organizației dumneavoastră.

Aceste cunoștințe pot fi aplicate în mai multe moduri, de la proiectarea unei strategii corporative generale până la comunicarea personală cu furnizorii, prin centre de apel, facturare, Internet si alte puncte. Mediul de afaceri de astăzi impune că DW și soluțiile BI aferente evoluează dincolo de gestionarea structurilor tradiționale de afaceri. de date precum i de date normalizate la nivel atomic și „ferme stele/cub”.

Ceea ce este necesar pentru a rămâne competitiv este o fuziune a tehnologiilor tradiționale și avansate într-un efort de a sprijini un peisaj analitic larg.
În sfârșit, mediul general trebuie să îmbunătățească cunoașterea companiei în ansamblu, asigurându-se că acțiunile întreprinse în urma analizelor efectuate sunt utile pentru ca toată lumea să beneficieze.

De exemplu, să presupunem că vă clasați pe propriul dvs clienții în categorii de risc ridicat sau scăzut.
Indiferent dacă aceste informații sunt generate de un model de minerit sau de alte mijloace, acestea trebuie introduse în DW și făcute accesibile oricui, prin intermediul oricărui instrument de acces, cum ar fi rapoarte statice, foi de calcul, tabele sau procesare analitică online (OLAP).

Cu toate acestea, în prezent, o mare parte din acest tip de informații rămân în siloz de date a persoanelor sau departamentelor care generează analiza. Organizația în ansamblu are puțină sau deloc vizibilitate pentru înțelegere. Numai prin amestecarea acestui tip de conținut de informații în DW-ul companiei dvs. puteți elimina silozurile de informații și vă puteți îmbunătăți mediul DW.
Există două obstacole majore în dezvoltarea unei organizații BI.
În primul rând, avem problema organizației în sine și a disciplinei sale.
Deși nu putem ajuta cu schimbările politicii organizaționale, putem ajuta la înțelegerea componentelor BI a unei organizații, arhitectura acesteia și modul în care tehnologia IBM facilitează dezvoltarea acesteia.
A doua barieră de depășit este lipsa tehnologiei integrate și cunoașterea unei metode care apelează întregul spațiu BI, spre deosebire de doar o mică componentă.

IBM răspunde la schimbările în tehnologia de integrare. Este responsabilitatea ta să oferi un design conștient. Această arhitectură trebuie dezvoltată cu tehnologie aleasă pentru o integrare neconstrânsă sau, cel puțin, cu tehnologie care aderă la standarde deschise. De asemenea, conducerea companiei dvs. trebuie să se asigure că întreprinderea Bi se desfășoară în termen și nu acela de a permite dezvoltarea unor silozuri de informații care decurg din agende sau obiective de autoservire.
Acest lucru nu înseamnă că mediul BI nu este sensibil la reacția la nevoile și cerințele diferite ale diferiților utilizatori; în schimb, înseamnă că implementarea acelor nevoi și cerințe individuale se face în beneficiul întregii organizații BI.
O descriere a arhitecturii organizației BI poate fi găsită la pagina 9 din Figura 1.1.Arhitectura demonstrează un amestec bogat de tehnologii și tehnici.
Din perspectiva tradițională, arhitectura include următoarele componente ale depozitului

Stratul atomic (Stratul atomic).

Acesta este fundamentul, inima întregului Dw și, prin urmare, a raportării strategice.
I de date stocate aici vor păstra integritatea istorică, rapoartele de de date și să includă valori derivate, precum și să fie curățate, integrate și stocate folosind modele de minerit.
Toate utilizarea ulterioară a acestora de date iar informațiile aferente sunt derivate din această structură. Aceasta este o sursă excelentă pentru minerit de date și pentru rapoarte cu interogări SQL structurate

Depozit operațional de de date sau baza de raport de de date(Magazin de date operaționale (ODS) sau raportare Baza de date.)

Aceasta este o structură a de date concepute special pentru raportarea tehnică.

I de date stocate și raportate deasupra, aceste structuri se pot propaga în cele din urmă în depozit prin zona de depozitare, unde ar putea fi utilizate pentru semnalizare strategică.

Zona de scenă.

Prima oprire pentru majoritatea de date destinat mediului de depozit este zona de organizare.
Aici eu de date sunt integrate, curatate si transformate in de date profituri care vor popula structura depozitului

Date marți.

Această parte a arhitecturii reprezintă structura de de date folosit special pentru OLAP. Prezența datamart-urilor, dacă i de date sunt stocate în schemele stelare pe care le suprapun de date multidimensionale într-un mediu relațional, sau în fișierele de de date proprietatea utilizată de o tehnologie OLAP specifică, cum ar fi DB2 OLAP Server, nu este relevantă.

Singura constrângere este că arhitectura facilitează utilizarea de date multidimensionale.
Arhitectura include, de asemenea, tehnologii și tehnici critice Bi care se disting prin:

Analiza spațială

Spațiul este un avantaj informațional pentru analist și este esențial pentru rezolvarea completă. Spațiul poate reprezenta informații despre oamenii care locuiesc într-o anumită locație, precum și informații despre locația respectivă din punct de vedere fizic în raport cu restul lumii.

Pentru a efectua această analiză, trebuie să începeți prin a vă lega informațiile de coordonatele de latitudine și longitudine. Aceasta se numește „geocodare” și trebuie să facă parte din procesul de extragere, transformare și încărcare (ETL) la nivelul atomic al depozitului dumneavoastră.

Exploatarea datelor.

Extragerea de de date permite companiilor noastre să crească numărul de clienții, pentru a prezice tendințele de vânzări și a permite gestionarea relațiilor cu i clienții (CRM), printre alte inițiative BI.

Extragerea de de date trebuie deci integrată cu structurile de de date depozit și sprijinit de procese de depozit pentru a stabili atât utilizarea eficientă, cât și eficientă a tehnologiei și a tehnicilor aferente.

După cum se indică în arhitectura BI, nivelul atomic Dwhouse, precum și datamart-urile, sunt o sursă excelentă de de date pentru extracție. Aceleași proprietăți trebuie să fie, de asemenea, destinatarii rezultatelor extracției pentru a asigura disponibilitatea pentru cea mai largă audiență.

Agenți.

Există diverși „agenți” pentru a examina clientul în orice punct, cum ar fi sistemele de operare ale companiei și dw-ul în sine. Acești agenți pot fi rețele neuronale avansate antrenate pentru a afla despre tendințe în fiecare moment, cum ar fi cererea viitoare de produse bazată pe promoții de vânzări, motoare bazate pe reguli pentru a reacționa la un Dato set de circumstanțe, sau chiar simpli agenți care raportează excepții directorilor de top. Aceste procese au loc în general în timp real și, prin urmare, trebuie să fie strâns cuplate cu mișcarea proceselor de date. Toate aceste structuri ale de date, tehnologiile și tehnicile vă asigură că nu veți petrece noaptea generând o organizare a BI-ului dvs.

Această activitate se va desfășura în trepte, pentru puncte mici.
Fiecare pas este un efort independent de proiect și este denumit o iterație în dw sau inițiativa dumneavoastră BI. Iterațiile pot include implementarea de noi tehnologii, începând cu noi tehnici, adăugarea de noi cadre la de date , încărcarea i de date suplimentar sau cu extinderea analizei mediului dumneavoastră. Acest paragraf este discutat mai detaliat în capitolul 3.

Pe lângă cadrele DW tradiționale și instrumentele BI, există și alte aspecte ale organizației dvs. BI pentru care trebuie să vă proiectați, cum ar fi:

Puncte de contact cu clientul (Atinge client puncte).

Ca și în cazul oricărei organizații moderne, există o serie de puncte de contact cu clienții care indică cum să aveți o experiență pozitivă pentru dvs clienții. Există canale tradiționale, cum ar fi comercianții, operatori de centrală telefonică, poștă directă, publicitate multimedia și tipărită, precum și canale mai actuale, cum ar fi e-mailul și web-ul, de date produsele cu un anumit punct de contact trebuie să fie achiziționate, transportate, curățate, procesate și apoi populate în instalații de date al BI.

Bazele de de date asociații operaționale și de utilizatori (Operational

baze de date și comunități de utilizatori).
La sfârșitul punctelor de contact ale clienții se gasesc fundatiile de date ale comunităților de aplicații și utilizatori ale companiei. THE de date existente sunt de date tradiționale care trebuie reunite și îmbinate cu de date curgând din punctele de contact pentru a satisface informațiile necesare.

Analiștii. (Analiști)

Beneficiarul principal al mediului BI este analistul. El este cel care beneficiază de extracția actuală a de date operațional, integrat cu diferite surse de de date , completat cu caracteristici precum analiza geografică (geocodare) și prezentat în tehnologiile BI care permit mining, OLAP, raportare SQL avansată și analiză geografică. Interfața principală pentru analist cu mediul de raportare este portalul BI.

Cu toate acestea, analistul nu este singurul care beneficiază de arhitectura BI.
Directori, mari asociații de utilizatori și chiar membri, furnizori și i clienții ar trebui să găsească beneficii în BI-ul întreprinderii.

Bucla de alimentare înapoi.

Arhitectura BI este un mediu de învățare. Un principiu caracteristic al dezvoltării este de a permite structuri persistente ale de date să fie actualizat de tehnologia BI utilizată și de acțiunile întreprinse de utilizator. Un exemplu este notarea clienților.

Dacă departamentul de vânzări realizează un model de extragere a punctajelor clienților, cum ar fi utilizarea unui nou serviciu, atunci departamentul de vânzări nu ar trebui să fie singurul grup care beneficiază de serviciu.

În schimb, extragerea modelelor ar trebui să fie efectuată ca o parte naturală a fluxului de date în cadrul întreprinderii, iar scorurile clienților ar trebui să devină o parte integrată a contextului informațiilor din depozit, vizibilă pentru toți utilizatorii. Suita IBM Bi-bI-centric, inclusiv DB2 UDB, DB2 OLAP Server include cele mai importante componente tehnologice, definite în figura 1.1.

Folosim arhitectura așa cum apare în această figură din carte pentru a ne oferi un nivel de continuitate și pentru a demonstra modul în care fiecare dintre produsele IBM se încadrează în schema generală de BI.

Furnizarea de conținut de informații (furnizarea continutul informatiilor)

Proiectarea, dezvoltarea și implementarea mediului dumneavoastră BI este o sarcină descurajantă. Designul trebuie să îmbrățișeze atât cerințele actuale, cât și viitoare ale afacerii. Desenul arhitecturii trebuie să fie cuprinzător pentru a include toate concluziile găsite în timpul fazei de proiectare. Execuția trebuie să rămână dedicată unui singur scop: dezvoltarea arhitecturii BI așa cum este prezentată în mod oficial în proiectare și bazată pe cerințele de afaceri.

Este deosebit de dificil de argumentat că disciplina va asigura un succes relativ.
Acest lucru este simplu pentru că nu dezvoltați un mediu BI dintr-o dată, ci în pași mici în timp.

Cu toate acestea, identificarea componentelor BI ale arhitecturii dvs. este importantă din două motive: veți conduce toate deciziile ulterioare privind arhitectura tehnică.
Veți putea să planificați în mod conștient o anumită utilizare a tehnologiei, chiar dacă s-ar putea să nu aveți nevoie de această tehnologie timp de câteva luni.

Înțelegerea suficientă a cerințelor dvs. de afaceri va influența tipul de produse pe care le achiziționați pentru arhitectura dvs.
Designul și dezvoltarea arhitecturii dumneavoastră asigură că depozitul dumneavoastră este

nu un eveniment întâmplător, ci mai degrabă un anunț bine gândit și atent construit operă a artei ca mozaic de tehnologie mixtă.

Conținutul de informații de proiectare

Toată proiectarea inițială trebuie să se concentreze și să identifice componentele majore BI de care mediul general va avea nevoie acum și în viitor.
Cunoașterea cerințelor de afaceri este importantă.

Chiar înainte de a începe orice planificare formală, planificatorul de proiect poate identifica adesea una sau două componente imediat.
Echilibrul de componente care poate fi necesar pentru arhitectura dvs., totuși, nu poate fi găsit cu ușurință. În timpul fazei de proiectare, partea principală a arhitecturii leagă sesiunea de dezvoltare a aplicațiilor (JAD) de o cercetare pentru a identifica cerințele de afaceri.

Uneori, aceste cerințe pot fi încredințate instrumentelor de interogare și raportare.
De exemplu, utilizatorii afirmă că, dacă doresc să automatizeze un raport curent, trebuie să genereze manual prin integrarea a două rapoarte curente și adăugând calculele derivate din combinația dintre de date.
Deși această cerință este simplă, ea definește o anumită funcționalitate pe care trebuie să o includeți atunci când achiziționați instrumente de raportare pentru organizația dvs.

Designerul trebuie să urmărească, de asemenea, cerințe suplimentare pentru a obține o imagine completă. Doresc utilizatorii să se aboneze la acest raport?
Sunt subseturi de rapoarte generate și trimise prin e-mail către diverși utilizatori? Doriți să vedeți acest raport în portalul companiei? Toate aceste cerințe fac parte din simpla necesitate de a înlocui un raport manual, așa cum este cerut de utilizatori. Avantajul acestor tipuri de cerințe este că toată lumea, utilizatorii și designerii, este familiarizat cu conceptul de rapoarte.

Există însă și alte tipuri de afaceri pe care trebuie să le planificăm. Atunci când cerințele de afaceri sunt enunțate sub formă de întrebări strategice de afaceri, este ușor pentru planificatorul experimentat să discerne cerințele dimensionale și de măsurare/fapt.

Dacă utilizatorii JAD nu știu cum să-și expună cerințele sub forma unei probleme de afaceri, designerul va oferi adesea exemple pentru a omite sesiunea de colectare a cerințelor.
Planificatorul expert poate ajuta utilizatorii să înțeleagă nu numai afaceri strategice, ci și cum să le modeleze.
Abordarea colectării cerințelor este discutată în capitolul 3; pentru moment vrem doar să subliniem necesitatea de a proiecta pentru toate tipurile de cerințe BI.

O problemă strategică de afaceri nu este doar o cerință de afaceri, ci și un indiciu de proiectare. Dacă trebuie să răspundeți la o întrebare multidimensională, atunci trebuie să memorați, să prezentați de date dimensională, iar dacă trebuie să memorați de date multidimensional, trebuie să decideți ce tip de tehnologie sau tehnică veți folosi.

Implementați o schemă cu stea cub rezervată sau ambele? După cum puteți vedea, chiar și o simplă problemă de afaceri poate influența foarte mult designul. Dar aceste tipuri de cerințe de afaceri sunt obișnuite și, desigur, cel puțin de către planificatorii de proiecte și designeri experimentați.

Au existat destule dezbateri despre tehnologiile și suportul OLAP și sunt disponibile o mare varietate de soluții. Până acum ne-am referit la necesitatea de a combina raportarea simplă cu cerințele dimensionale ale afacerii și modul în care aceste cerințe influențează deciziile de arhitectură tehnică.

Dar care sunt cerințele care nu sunt ușor de înțeles de utilizatori sau de echipa Dw? Veți avea vreodată nevoie de analiză spațială (analiza spațială)?
Modelele miniere ale de date Vor fi ele o parte necesară a viitorului tău? Cine ştie?

Este important de reținut că aceste tipuri de tehnologii nu sunt bine cunoscute de comunitățile generale de utilizatori și de membrii echipei DW, în parte, acest lucru ar putea fi din cauză că sunt de obicei gestionate de unii experți tehnici interni sau terți. Este un caz marginal al problemelor pe care le generează aceste tipuri de tehnologii. Dacă utilizatorii nu pot descrie cerințele de afaceri sau nu le pot încadra pentru a oferi îndrumări designerilor, pot trece neobservați sau, mai rău, pur și simplu ignorați.

Devine mai problematică atunci când designerul și dezvoltatorul nu pot recunoaște aplicarea uneia dintre aceste tehnologii avansate, dar critice.
Așa cum am auzit adesea designerii spunând: „Ei bine, de ce nu-l lăsăm deoparte până când obținem asta? „Sunt cu adevărat interesați de priorități sau pur și simplu evită cerințele pe care nu le înțeleg? Cel mai probabil este cea din urmă presupunere. Să presupunem că echipa dvs. de vânzări a comunicat o cerință de afaceri, așa cum se arată în Figura 1.3, după cum puteți vedea, cerința este încadrată sub forma unei probleme de afaceri. Diferența dintre această problemă și problema dimensională tipică este distanța. În acest caz, echipa de vânzări dorește să cunoască, lunar, vânzările totale din produse, depozite și clienții care locuiesc pe o rază de 5 mile de depozitul în care fac cumpărături.

Din păcate, designerii sau arhitecții pot ignora pur și simplu componenta spațială spunând: „Avem clientul, produsul și de date a depozitului. Să ținem distanța până la o altă iterație.

"Răspuns greșit. Acest tip de problemă de afaceri este legată de BI. Reprezintă o înțelegere mai profundă a afacerii noastre și un spațiu analitic robust pentru analiștii noștri. BI este dincolo de simpla interogare sau raportare standard sau chiar OLAP. Asta nu înseamnă că aceste tehnologii nu sunt importante pentru BI, dar ele în sine nu reprezintă mediul BI.

Proiectare pentru contextul informațional (Design pentru conținut informațional)

Acum că am identificat cerințele de afaceri care disting diferitele componente de bază, acestea trebuie incluse într-un desen arhitectural general. Unele dintre componentele BI fac parte din eforturile noastre inițiale, în timp ce unele nu vor fi implementate timp de câteva luni.

Cu toate acestea, toate cerințele cunoscute sunt reflectate în proiectare, astfel încât atunci când trebuie să implementăm o anumită tehnologie, suntem pregătiți să facem acest lucru. Ceva despre proiect va reflecta gândirea tradițională.

Acest set de de date este folosit pentru a sprijini utilizări ulterioare ale de date dimensional condus de problemele de afaceri pe care le-am identificat. Pe măsură ce sunt generate documente suplimentare, cum ar fi dezvoltarea proiectului de date, vom începe prin a formaliza ca i de date se răspândesc în mediu. Am constatat necesitatea reprezentării i de date într-un mod dimensional, împărțindu-le (în funcție de nevoile specifice) în marturi de date.

Următoarea întrebare la care trebuie să răspundeți este: Cum vor fi construite aceste magazine de date?
Construiți stelele pentru a susține cuburile, sau doar cuburi, sau doar stelele? (sau cuburi drepte, sau stele drepte). Generați arhitectura pentru magazinele de date dependente care necesită un strat atomic pentru toți de date dobandesti? Permiteți magazinelor independente de date să achiziționeze i de date direct din sistemele de operare?

Ce tehnologie Cube vei încerca să standardizezi?

Aveți o mulțime de zei de date necesare pentru analiza dimensională sau aveți nevoie de cuburi ale forței de vânzări naționale săptămânal sau ambele? Creați un obiect puternic, cum ar fi DB2 OLAP Server pentru finanțe sau cuburi Cognos PowerPlay pentru organizația dvs. de vânzări sau ambele? Acestea sunt marile decizii de proiectare arhitecturală care vor avea un impact asupra mediului dumneavoastră BI în viitor. Da, ați identificat o nevoie pentru OLAP. Acum, cum vei realiza acest tip de tehnică și tehnologie?

Cum vă afectează unele dintre tehnologiile mai avansate design-urile? Să presupunem că ați identificat o nevoie spațială în organizația dvs. Acum trebuie să vă amintiți edițiile de desen de arhitectură chiar dacă nu aveți de gând să faceți componente spațiale timp de câteva luni. Arhitectul trebuie să proiecteze astăzi în funcție de ceea ce este necesar. Anticipați nevoia de analiză spațială care generează, stochează, întreține și oferă acces la de date spațială. Aceasta, la rândul său, ar trebui să servească drept o constrângere în ceea ce privește tipul de tehnologie software și specificațiile platformei pe care le puteți lua în considerare în prezent. De exemplu, sistemul de administrare al Bază de date relaționale (RDBMS) pe care le menții pentru stratul tău atomic trebuie să aibă o extindere spațială robustă disponibilă. Acest lucru ar asigura performanță maximă atunci când utilizați geometrie și obiecte spațiale în aplicațiile dvs. analitice. Dacă RDBMS-ul dvs. nu poate gestiona de date (centric spațial) intern, deci va trebui să stabiliți o Bază de date (centric spațial) extern. Acest lucru complică gestionarea problemelor și compromite performanța dvs. generală, ca să nu mai vorbim de problemele suplimentare pe care le creează pentru DBA, deoarece aceștia probabil au o înțelegere minimă a elementelor de bază ale de date de asemenea spațială. Pe de altă parte, dacă motorul RDMBS se ocupă de toate componentele spațiale și optimizatorul său este conștient de nevoile speciale (de exemplu, indexarea) obiectelor spațiale, atunci DBA-urile dvs. pot gestiona cu ușurință problemele de gestionare și puteți maximiza performanța.

De asemenea, trebuie să ajustați zona de pregătire și stratul de mediu atomic pentru a include curățarea adresei (a

element cheie pentru analiza spațială), precum și salvarea ulterioară a obiectelor spațiale. Succesiunea edițiilor de design continuă acum, când am introdus noțiunea de curățenie a adresei. În primul rând, această aplicație va dicta tipul de software de care aveți nevoie pentru efortul dvs. ETL.

Aveți nevoie de produse precum Trillium pentru a vă oferi o adresă curată sau de un furnizor ETL la alegere pentru a vă oferi această funcționalitate?
Deocamdată este important să apreciați nivelul de proiectare care trebuie finalizat înainte de a începe să vă întrețineți depozitul. Exemplele de mai sus ar trebui să demonstreze multitudinea de decizii de proiectare care trebuie să urmeze identificarea oricărei cerințe specifice de afaceri. Atunci când sunt luate corect, aceste decizii de proiectare promovează interdependența dintre structurile fizice ale mediului dumneavoastră, selecția tehnologiei utilizate și fluxul de propagare a conținutului informațional. Fără această arhitectură BI convențională, organizația dvs. va fi supusă unui amestec haotic de tehnologii existente, în cel mai bun caz împletite vag împreună pentru a oferi stabilitate aparentă.

Menține conținutul informațional

Aducerea valorii informațiilor în organizația dvs. este o sarcină foarte dificilă. Fără suficientă înțelegere și experiență, sau fără o inginerie și design adecvate, chiar și cele mai bune echipe ar eșua. Pe de altă parte, dacă ai o mare intuiție și un design detaliat, dar nu ai disciplină de executat, doar ți-ai pierdut banii și timpul pentru că efortul tău este sortit eșecului. Mesajul ar trebui să fie clar: dacă vă lipsesc una sau mai multe dintre aceste abilități, înțelegere/experiență sau disciplina de planificare/design sau implementare, acest lucru va duce la paralizarea sau distrugerea construcției organizației BI.

Este echipa ta suficient de pregătită? Înțelege cineva din echipa ta BI vastul peisaj analitic disponibil în mediile BI și tehnicile și tehnologiile necesare pentru a menține acel peisaj? Există cineva în echipa ta care poate face diferența în aplicarea avansată

raportare statică și OLAP, sau diferențele dintre ROLAP și OLAP? Unul dintre membrii echipei dumneavoastră recunoaște în mod clar modul de extragere și modul în care acesta ar putea avea impact asupra depozitului sau modul în care depozitul poate susține performanța minieră? Un membru al echipei înțelege valoarea de date tehnologie spațială sau bazată pe agenți? Aveți pe cineva care apreciază aplicarea instrumentelor unice ale tehnologiei ETL vs Message Broker? Daca nu il ai, ia unul. BI este mult mai mare decât un strat atomic normalizat, OLAP, scheme stelare și un ODS.

A avea înțelegerea și experiența pentru a recunoaște cerințele BI și soluțiile acestora este esențială pentru capacitatea dumneavoastră de a formaliza în mod corespunzător nevoile utilizatorilor și de a proiecta și implementa soluțiile acestora. Dacă comunitatea dvs. de utilizatori întâmpină dificultăți în a descrie cerințele, este la latitudinea echipei din depozit să ofere această înțelegere. Dar dacă echipa de depozit

nu recunoaște aplicația specifică a BI - de exemplu, data mining - atunci nu este cel mai bine ca mediile BI să fie adesea limitate la a fi depozite pasive. Cu toate acestea, ignorarea acestor tehnologii nu le diminuează importanța și efectul pe care îl au asupra apariției capacităților de business intelligence ale organizației dumneavoastră, precum și asupra activului informațional pe care intenționați să îl promovați.

Designul trebuie să includă noțiunea de desen și ambele necesită o persoană competentă. În plus, planificarea necesită o filozofie a căminului de echipă și respectarea standardelor. De exemplu, dacă compania dvs. a stabilit un standard de platformă sau a identificat un anumit RDBMS pe care dorește să-l standardizeze pe platformă, toți membrii echipei sunt obligați să adere la aceste standarde. În general, o echipă exprimă nevoia de standardizare (comunităților de utilizatori), dar echipa în sine nu este dispusă să adere la standardele stabilite în alte zone ale companiei sau poate chiar în companii similare. Nu numai că este ipocrit, dar stabilește că compania nu este capabilă să exploateze resursele și investițiile existente. Nu înseamnă că nu există situații care să justifice o platformă sau o tehnologie nestandardizată; totusi eforturile depozitului

ar trebui să păzească cu gelozie standardele întreprinderii până când cerințele de afaceri dictează altfel.

A treia componentă cheie necesară pentru a construi o organizație BI este disciplina.
Depinde în totalitate, în egală măsură de indivizi și de mediu. Planificatorii de proiecte, sponsorii, arhitecții și utilizatorii trebuie să aprecieze disciplina necesară pentru a construi resursele informaționale ale companiei. Designerii trebuie să își orienteze eforturile de proiectare pentru a completa alte eforturi necesare în societate.

De exemplu, să presupunem că compania dumneavoastră construiește o aplicație ERP care are o componentă de depozit.
Astfel, este responsabilitatea designerilor ERP să colaboreze cu echipa de mediu depozit pentru a nu concura sau duplica munca deja începută.

Disciplina este, de asemenea, un subiect care trebuie abordat de întreaga organizație și este de obicei stabilit și mandatat la nivel executiv.
Sunt directorii dispuși să adere la o abordare proiectată? O abordare care promite să creeze conținut de informații care, în cele din urmă, va oferi valoare tuturor zonelor întreprinderii, dar poate compromite agendele individuale sau departamentale? Amintește-ți zicala „A te gândi la toate este mai important decât a te gândi la un singur lucru”. Această zicală este adevărată pentru organizațiile BI.

Din păcate, multe depozite își concentrează eforturile pe încercarea de a viza și de a oferi valoare unui anumit departament sau anumiti utilizatori, cu puțină atenție pentru organizație în general. Să presupunem că managerul solicită asistență din partea echipei de la fostă. Echipa răspunde cu un efort de 90 de zile care include nu numai furnizarea cerințelor de notificare definite de executiv, ci și asigurarea că toate de date de bază sunt amestecate în nivelul atomic înainte de a fi introduse în tehnologia cubului propusă.
Acest adaos de inginerie asigură că întreprinderea cabană va beneficia de pe urma de date necesare managerului.
Cu toate acestea, executivul a vorbit cu firme de consultanță din afara care au propus o aplicație similară cu livrare în mai puțin de 4 săptămâni.

Presupunând că echipa internă a căminului este competentă, executivul are de ales. Cine poate susține disciplina suplimentară de inginerie necesară pentru a crește activele de informații ale întreprinderii sau poate alege să-și construiască rapid propria soluție. Acesta din urmă pare să fie ales mult prea des și este folosit doar pentru a crea containere de informații care beneficiază câtorva sau individului.

Obiective pe termen scurt și lung

Arhitecții și planificatorii de proiecte trebuie să oficializeze o viziune pe termen lung a arhitecturii generale și a planurilor pentru dezvoltarea unei organizații BI. Această combinație de câștig pe termen scurt și planificare pe termen lung sunt cele două părți ale eforturilor de BI. Venitul pe termen scurt este aspectul BI care este asociat cu iterațiile depozitului dvs.

Aici planificatorii, arhitecții și sponsorii se concentrează pe îndeplinirea cerințelor specifice de afaceri. La acest nivel se construiesc structurile fizice, se achiziționează tehnologia și se implementează tehnici. Ele nu sunt în niciun caz făcute pentru a răspunde cerințelor specifice, așa cum sunt definite de anumite comunități de utilizatori. Totul este realizat cu scopul de a răspunde cerințelor specifice definite de o anumită comunitate.
Cu toate acestea, planificarea pe termen lung este cealaltă fațetă a BI. Aici planurile și proiectele au asigurat că orice structură fizică a fost construită, tehnologiile selectate și tehnicile realizate realizate cu un ochi către întreprindere. Planificarea pe termen lung este cea care oferă coeziunea necesară pentru a se asigura că câștigurile ferme sunt obținute din orice câștiguri pe termen scurt găsite.

Justificați-vă efortul de BI

Un depozit de date în sine nu are valoare inerentă. Cu alte cuvinte, nu există o valoare inerentă între tehnologiile de depozit și tehnicile de implementare.

Valoarea oricărui efort de depozit se regăsește în acțiunile efectuate ca urmare a mediului de depozit și a conținutului informațional cultivat de-a lungul timpului. Acesta este un punct critic de înțeles înainte de a încerca vreodată să estimați valoarea oricărei inițiative wherehouse.

Prea des, arhitecții și planificatorii încearcă să aplice valoare componentelor fizice și tehnice ale depozitelor atunci când de fapt valoarea se bazează pe procesele de afaceri care sunt afectate pozitiv de depozit și de informațiile bine captate.

Aici constă provocarea înființării BI: Cum justificați investiția? Dacă depozitul în sine nu are valoare intrinsecă, planificatorii de proiect trebuie să investigheze, să definească și să oficializeze beneficiile pentru acele persoane care vor folosi depozitul pentru a îmbunătăți procesele specifice de afaceri sau valoarea informațiilor protejate sau ambele.

Pentru a complica lucrurile, orice proces de afaceri afectat de eforturile din depozit ar putea oferi beneficii „substanțiale” sau „ușoare”. Beneficiile semnificative oferă o măsură tangibilă pentru măsurarea rentabilității investiției (ROI) – de exemplu, predarea stocului pentru o perioadă suplimentară de timp într-o anumită perioadă sau pentru un cost mai mic de transport per transport. Este mai dificil să definești beneficii subtile, cum ar fi accesul îmbunătățit la informații, în termeni de valoare tangibilă.

Conectați-vă proiectul pentru a cunoaște cereri de afaceri

Prea des, planificatorii de proiecte încearcă să lege valoarea depozitului cu obiectivele amorfe ale întreprinderii. Declarând că „valoarea unui depozit se bazează pe capacitatea noastră de a satisface solicitări strategice” deschidem discuția într-un mod plăcut. Dar numai asta nu este suficient pentru a determina dacă investiția în depozit are sens. Cel mai bine este să conectați reprezentanții depozitului cu întrebări și note de afaceri specifice.

Măsurați rentabilitatea investiției

Calcularea rentabilității investiției într-un depozit poate fi deosebit de dificilă. Este deosebit de dificil dacă conduce

a unei anumite repetiții este ceva intangibil sau ușor de măsurat. Un studiu a constatat că utilizatorii percep cele două beneficii principale ale inițiativelor BI:

• ▪ Creați capacitatea de a lua decizii
• ▪ Creați acces la informații
  Aceste beneficii sunt beneficii blânde (sau ușoare). Este ușor de văzut cum putem calcula un ROI pe baza unui beneficiu greu (sau mai mare), cum ar fi costul redus de transport, dar cum măsurăm capacitatea de a lua decizii mai bune?
  Aceasta este cu siguranță o provocare pentru planificatorii de proiecte atunci când încearcă să determine compania să investească într-un anumit efort de depozit. Creșterea vânzărilor sau scăderea costurilor nu mai sunt temele centrale care conduc mediul BI.
  În schimb, căutați cererile de afaceri pentru un acces mai bun la informații, astfel încât un anumit departament să poată lua decizii mai rapid. Aceștia sunt factori strategici care se întâmplă să fie la fel de importanți pentru întreprindere, dar sunt mai ambigui și mai dificil de caracterizat într-o metrică tangibilă. În acest caz, calcularea rentabilității investiției poate fi înșelătoare, dacă nu chiar irelevantă.
  Proiectanții de proiecte trebuie să fie capabili să demonstreze o valoare tangibilă pentru ca directorii să decidă dacă investiția într-o anumită iterație merită. Cu toate acestea, nu vom propune o nouă metodă de calculare a rentabilității investiției și nici nu vom aduce niciun argument pro sau contra.
  Există multe articole și cărți disponibile care discută elementele fundamentale ale calculării rentabilității investiției. Există propuneri de valoare speciale, cum ar fi valoarea investiției (VOI), oferite de grupuri precum Gartner, pe care le puteți cerceta. În schimb, ne vom concentra asupra aspectelor de bază ale oricăror ROI sau alte propuneri de valoare pe care trebuie să le luați în considerare. Aplicarea rentabilității investiției Dincolo de argumentul despre beneficiile „hard” versus „soft” asociate eforturilor de BI, există și alte aspecte de luat în considerare atunci când se aplică rentabilitatea investiției. De exemplu:

Atribuind prea multe economii eforturilor DW care ar veni oricum
Să presupunem că compania dumneavoastră a trecut de la o arhitectură mainframe la un mediu UNIX distribuit. Așadar, orice economii care pot (sau nu) să fie realizate din acest efort nu ar trebui să fie atribuite exclusiv, dacă este deloc (?), depozitului.

A nu ține cont de totul este scump. Și sunt multe lucruri de luat în considerare. Luați în considerare următoarea listă:

• ▪ Costul de pornire, inclusiv fezabilitate.
• ▪ Costul hardware-ului dedicat cu stocarea și comunicațiile asociate
• ▪ Costul software-ului, inclusiv managementul de date și extensii client/server, software ETL, tehnologii DSS, instrumente de vizualizare, aplicații de planificare și flux de lucru și software de monitorizare, .
• ▪ Costul proiectării structurii de date, cu crearea și optimizarea
• ▪ Costul dezvoltării software asociat direct cu efortul de BI
• ▪ Costul asistenței la domiciliu, inclusiv optimizarea performanței, inclusiv controlul versiunii software și operațiunile de ajutor Aplicați rentabilitatea investiției „Big-Bang”. Construirea depozitului ca un singur efort gigantic este sortită eșecului, așa că și calculați rentabilitatea investiției pentru o inițiativă de mare întreprindere Oferta este surprinzătoare și că planificatorii continuă să facă încercări slabe de a estima valoarea întregului efort. De ce încearcă planificatorii să pună o valoare monetară inițiativei de afaceri dacă este larg cunoscut și acceptat că estimarea iterațiilor specifice este dificilă? Cum este posibil? Nu este posibil cu câteva excepții. Nu o face. Acum că am stabilit ce să nu facem atunci când calculăm rentabilitatea investiției, iată câteva puncte care vă vor ajuta să stabiliți un proces de încredere pentru estimarea valorii eforturilor dumneavoastră de BI.

Obținerea consimțământului pentru rentabilitatea investiției. Indiferent de tehnica pe care o alegeți pentru estimarea valorii eforturilor dumneavoastră de BI, aceasta trebuie să fie agreată de toate părțile, inclusiv de planificatorii de proiecte, sponsorii și directorii corporativi.

Împărțiți rentabilitatea investiției în părți identificabile. Un pas necesar către un calcul rezonabil al rentabilității investiției este concentrarea acelui calcul pe un anumit proiect. Acest lucru vă permite apoi să estimați o valoare pe baza cerințelor specifice ale afacerii care sunt îndeplinite

Definiți costurile. După cum am menționat, trebuie luate în considerare numeroase costuri. În plus, costurile trebuie să includă nu numai cele asociate cu iterația individuală, ci și costurile asociate cu asigurarea conformității cu standardele întreprinderii.

Definiți beneficiile. Prin legarea clară a rentabilității investiției cu cerințele specifice ale afacerii, ar trebui să putem identifica beneficiile care vor duce la îndeplinirea cerințelor.

Reduceți costurile și beneficiile în câștiguri iminente. Este cel mai bun mod de a vă baza evaluările pe valoarea actuală netă (VAN), spre deosebire de a încerca să preziceți valoarea viitoare a câștigurilor viitoare.

Păstrați timp pentru a vă împărți rentabilitatea investiției la minimum. Este bine documentat pe termen lung, a fost folosit în rentabilitatea investiției.

Utilizați mai mult de o formulă de rentabilitate a investiției. Există numeroase metode de estimare a rentabilității investiției și ar trebui să planificați să utilizați una sau mai multe dintre ele, inclusiv valoarea actuală netă, rata internă de rentabilitate (IRR) și rambursarea.

Definiți procesul repetabil. Acest lucru este crucial pentru calcularea oricărei valori pe termen lung. Un singur proces repetabil trebuie documentat pentru toate subsecvențele ulterioare ale proiectului.

Problemele enumerate sunt cele mai frecvente definite de experții în mediul adăposturilor. Insistența conducerii de a oferi un ROI „Big-Bang” este foarte confuză. Dacă începeți toate calculele ROI prin împărțirea lor în părți identificabile, tangibile, aveți șanse mari să estimați o estimare exactă a rentabilității investiției.

Întrebări despre beneficiile ROI

Oricare ar fi beneficiile tale, soft sau hard, poți folosi câteva întrebări de bază pentru a determina valoarea lor. De exemplu, folosind un sistem de scară simplu, de la 1 la 10, puteți măsura impactul oricărui efort folosind următoarele întrebări:

• Cum ați aprecia înțelegerea de date Urmăriți acest proiect al companiei dvs.?
• Cum ați evalua îmbunătățirile procesului ca urmare a acestui proiect?
• Cum ați măsura impactul noilor perspective și inferențe puse acum la dispoziție prin această iterație
• Care a fost impactul unor medii informatice noi și mai bune ca urmare a celor învățate? Daca raspunsurile la aceste intrebari sunt putine, este posibil ca intreprinderea sa nu merite investitia facuta. Întrebările cu scoruri ridicate indică câștiguri semnificative de valoare și ar trebui să servească drept ghiduri pentru investigații ulterioare. De exemplu, un scor mare pentru îmbunătățirea proceselor ar trebui să-i determine pe proiectanți să examineze modul în care procesele au fost îmbunătățite. Este posibil să descoperiți că unele sau toate câștigurile realizate sunt tangibile și, prin urmare, o valoare monetară poate fi aplicată cu ușurință. Profitați la maximum de prima iterație a depozit Cel mai mare profit al efortului companiei tale este adesea în primele câteva iterații. Aceste eforturi timpurii stabilesc în mod tradițional cel mai util conținut de informații pentru public și ajută la stabilirea bazei tehnologice pentru aplicațiile ulterioare de BI. De obicei, fiecare succesiune ulterioară a de date a proiectelor de depozit aduc din ce în ce mai puțină valoare suplimentară întreprinderii în ansamblu. Acest lucru este valabil mai ales dacă iterația nu adaugă subiecte noi sau nu satisface nevoile unei noi comunități de utilizatori.

Această caracteristică de stocare se aplică și stivelor în creștere de de date istorici. Deoarece eforturile ulterioare necesită mai mult de date si cat mai mult de date sunt turnate în depozit în timp, majoritatea de date devine mai puțin relevantă pentru analiza utilizată. Aceste de date sunt adesea numiti de date inactiv și este întotdeauna costisitor să le păstrați, deoarece nu sunt folosite aproape niciodată.

Ce înseamnă asta pentru sponsorii de proiect? În esență, primii sponsori împart mai mult decât costurile de investiție. Acest lucru este esențial, deoarece ele reprezintă impulsul pentru întemeierea stratului larg de tehnologie și mediu al resurselor din depozit, inclusiv organic.

Dar acești primi pași au cea mai mare valoare și, prin urmare, planificatorii de proiecte trebuie adesea să justifice investiția.
Proiectele realizate după inițiativa dvs. de BI pot avea costuri mai mici (comparativ cu prima) și directe, dar aduc mai puțină valoare întreprinderii.

Și proprietarii organizațiilor trebuie să înceapă să ia în considerare aruncarea acumularii de date și tehnologii mai puțin relevante.

Data Mining: Extracție DATI

Multe componente arhitecturale necesită variații ale tehnologiilor și tehnicilor de extragere a datelor -
de exemplu, diferiții „agenți” pentru examinarea punctelor de interes ale clienții, sistemele de operare ale companiei și pentru același dw. Acești agenți pot fi rețele neuronale avansate antrenate pe tendințele pot, cum ar fi cererea viitoare de produse bazată pe promoții de vânzări; motoare bazate pe reguli pentru a reacționa la un set Dato a circumstanțelor, de exemplu, diagnostic medical și recomandări de tratament; sau chiar simpli agenți cu rolul de a raporta excepțiile directorilor de top. În general, aceste procese de extracție de date si

verifica in timp real; prin urmare, ele trebuie să fie unite complet cu mișcarea celui de date pe ei.

Procesare analitică online

Analiza online

Capacitatea de a tăia, a tăia, a arunca, a detalia și a efectua analize
ce-dacă se află în domeniul de aplicare al suitei tehnologice IBM. De exemplu, funcții de procesare analitică online (OLAP) există pentru DB2, care aduce analiza dimensională în motorul Baza de date la fel .

Funcțiile adaugă utilitate dimensională la SQL, culegând în același timp toate beneficiile de a fi o parte naturală a DB2. Un alt exemplu de integrare OLAP este instrumentul de extracție, DB2 OLAP Analyzer Server. Această tehnologie permite scanarea rapidă și automată a cuburilor DB2 OLAP Server pentru a localiza și raporta valorile de date neobișnuit sau neașteptat pentru orice cub pentru analistul de tranzacționare. Și, în sfârșit, funcțiile DW Center oferă arhitecților un mijloc de a verifica, printre altele, profilul unui server cub DB2 OLAP ca parte naturală a proceselor ETL.

Analiza spatiala Analiza spatiala

Spatiul reprezinta jumatate din ancorele (conductiile) analitice necesare unei panorame
analitic larg (timpul reprezintă cealaltă jumătate). Nivelul atomic al depozitului, reprezentat în Figura 1.1, include bazele atât pentru timp, cât și pentru spațiu. Timpurile ancorează analizele în funcție de timp și informațiile de adresă ancorează analizele în funcție de spațiu. Marcajele temporale conduc analiza în funcție de timp, iar informațiile de adresă efectuează analiza în funcție de spațiu. Diagrama prezintă geocodarea – procesul de conversie a adreselor în puncte dintr-o hartă sau puncte din spațiu, astfel încât concepte precum distanța și interior/exterior să poată fi utilizate în analiză – efectuat la nivel atomic și analiza spațială fiind pusă la dispoziția analistului. IBM oferă extensii spațiale, dezvoltate împreună cu Institutul de Cercetare a Sistemului de Mediu (ESRI), al Baza de date DB2, astfel încât obiectele spațiale să poată fi menținute ca o parte normală a Baza de date relaționale. db2

Spatial Extenders oferă, de asemenea, toate extensiile SQL pentru a profita de analiza spațială. De exemplu, extensiile SQL pentru a interoga
distanța dintre adrese sau dacă un punct se află în interiorul sau în afara unei zone poligonale definite, sunt un standard analitic cu Spatial Extender. Consultați capitolul 16 pentru mai multe informații.

Baza de date-Rezident Tools Instrumente Baza de date-Rezident

DB2 are multe caracteristici rezidente SQL BI care ajută la acțiunea de analiză. Acestea includ:

• Funcții recursive pentru a efectua analize, cum ar fi „găsiți toate căile de zbor posibile din San Francisco a New York".
• Funcțiile analitice pentru funcțiile de clasare, cumulativ, cub și rollup pentru a facilita sarcinile care apar în mod normal numai cu tehnologia OLAP, sunt acum o parte naturală a motorului Baza de date
• Capacitatea de a crea tabele care conțin rezultate
  Vânzătorii de Baza de date liderii amestecă mai multe caracteristici BI în Baza de date în sine.
  Principalii furnizori de Bază de date ei amestecă mai multe caracteristici BI în Baza de date în sine.
  Acest lucru oferă performanțe mai bune și mai multe opțiuni de execuție pentru soluțiile BI.
  Caracteristicile și funcțiile DB2 V8 sunt discutate în detaliu în următoarele capitole:
  Arhitectura tehnică și fundamentele managementului datelor (Capitolul 5)

• Fundamentele DB2 BI (Capitolul 6)
• Tabele de interogări materializate DB2 (Capitolul 7)
• Funcții DB2 OLAP (Capitolul 13)
• Caracteristici și funcții BI îmbunătățite DB2 (Capitolul 15) Sistem simplificat de livrare a datelor Sistemul de livrare a de date simplificat

Arhitectura descrisă în Figura 1.1 include numeroase structuri de date fizic. Unul este depozitul de de date de operare. În general, un ODS este orientat pe obiect, integrat și actual. Ai construi un ODS pentru a sprijini, de exemplu, biroul de vânzări. Vânzările de ODS ar suplimenta de date din multe sisteme diferite, dar ar păstra doar, de exemplu, tranzacțiile de astăzi. ODS poate fi, de asemenea, actualizat de mai multe ori pe zi. Simultan, procesele împing i de date integrate în alte aplicații. Această structură este concepută special pentru a se integra de date actual și dinamic și ar fi un candidat probabil pentru a sprijini analize în timp real, cum ar fi furnizarea de agenți de servicii clienții informațiile curente de vânzări ale unui client prin extragerea informațiilor despre tendințele vânzărilor din inventarul însuși. O altă structură prezentată în figura 1.1 este o stare formală pentru dw. Nu numai că acesta este locul pentru execuția integrării necesare, a calității de de date, și a transformării lui de date de depozit de intrare, dar este și o zonă de depozitare fiabilă și temporară pentru de date replici care ar putea fi utilizate în analiza în timp real. Dacă decideți să utilizați un ODS sau o zonă de pregătire, unul dintre cele mai bune instrumente pentru a popula aceste structuri de date utilizarea diferitelor surse operaționale este interogarea distribuită eterogenă a DB2. Această capacitate este furnizată de caracteristica opțională DB2 numită DB2 Relational Connect (doar interogări) și prin DB2 DataJoiner (un produs separat care oferă capacitate de interogare, inserare, actualizare și ștergere la RDBMS-uri distribuite eterogene).

Această tehnologie permite arhitecților să de date a lega de date de producţie cu procese analitice. Nu numai că tehnologia se poate adapta practic la oricare dintre cerințele de replicare care ar putea apărea cu analiza în timp real, dar se poate conecta și la o mare varietate de de date cele mai populare, inclusiv DB2, Oracle, Sybase, SQL Server, Informix și altele. DB2 DataJoiner poate fi utilizat pentru a popula o structură de date formale precum un ODS sau chiar un tabel permanent reprezentat în depozit conceput pentru recuperarea rapidă a actualizărilor instantanee sau pentru vânzare. Desigur, aceste structuri în sine de date pot fi populate folosind

o altă tehnologie importantă concepută pentru replicarea de date, IBM DataPropagator Relational. (DataPropagator este un produs separat pentru sistemele centrale. DB2 UNIX, Linux, Windows și OS/2 includ servicii de replicare pentru de date ca o caracteristică standard).
O altă metodă de deplasare de date care operează în cadrul întreprinderii este un integrator de aplicații de întreprindere, altfel cunoscut sub numele de broker de mesaje. Această tehnologie unică permite un control de neegalat pentru țintire și deplasare de date în jurul companiei. IBM are cel mai utilizat broker de mesaje, MQSeries, sau o variantă a produsului care include cerințele pentru e-commerce, IBM WebSphere MQ.
Per più discussione su come sfruttare MQ per sostenere un magazzino e un ambiente BI, visitare website del libro. Per ora, è sufficiente dire che questa tecnologia è un mezzo eccellente per catturare e trasformare (utilizzando MQSeries Integrator) de date operativi vizați recrutați pentru soluții BI. Tehnologia MQ a fost integrată și ambalată în UDB V8, ceea ce înseamnă că acum cozile de mesaje pot fi gestionate ca și cum ar fi tabele DB2. Conceptul de mesaje de coadă de sudură și universul Baza de date relațional se direcționează către un mediu puternic de livrare a de date.

Latență zero Latență zero

Scopul strategic final pentru IBM este analiza cu latență zero. După cum este definit de
Gartner, un sistem BI trebuie să fie capabil să deducă, să ingereze și să ofere informații pentru analiști la cerere. Provocarea, desigur, este cum să amesteci de date curent și în timp real cu informațiile istorice necesare, cum ar fi i de date tendință/model asociată sau informații extrase, cum ar fi profilarea clienților.

Astfel de informații includ, de exemplu, identificarea clienții risc ridicat sau scăzut sau ce produse i clienții cel mai probabil vor cumpăra dacă au deja brânză în coșul de cumpărături.

Obținerea unei latențe zero depinde de fapt de două mecanisme fundamentale:

• Unirea completă a de date care sunt analizate cu tehnicile stabilite şi cu instrumentele create de BI
• Un sistem de livrare de de date eficient pentru a se asigura că analizele în timp real sunt cu adevărat disponibile. Aceste premise pentru o latență zero nu sunt diferite de cele două obiective stabilite de IBM și descrise mai sus. Cupla strânsă a de date face parte din programul de integrare perfectă al IBM. Și creați un sistem de livrare de de date eficient este complet dependent de tehnologia disponibilă care simplifică procesul de livrare de date. În consecință, două dintre cele trei obiective ale IBM sunt esențiale pentru atingerea celui de-al treilea. IBM își dezvoltă în mod conștient tehnologia pentru a se asigura că latența zero este o realitate pentru eforturile de depozitare. Rezumat / Sinteză Organizația dumneavoastră BI oferă o foaie de parcurs pentru construirea mediului dumneavoastră
  iterativ. Trebuie ajustat pentru a reflecta nevoile afacerii dvs., atât actuale, cât și viitoare. Fără o viziune arhitecturală amplă, iterațiile depozitului sunt puțin mai mult decât implementări întâmplătoare ale depozitului central care nu fac nimic pentru a crea o întreprindere mare, informativă. Primul obstacol pentru liderii de proiect este cum să justifice investiția necesară pentru a crește organizația BI. În timp ce calculele rentabilității investiției au rămas un pilon de bază al realizărilor inventarului, devine din ce în ce mai dificil de prezis cu exactitate. Acest lucru a condus la alte metode pentru a determina dacă obțineți valoarea banilor dvs. Value on Investment2 (VOI), de exemplu, este achiziționată ca soluție. Este de sarcina arhitectilor de de date iar planificatorii de proiecte generează și oferă în mod deliberat informații asociațiilor de utilizatori și nu pur și simplu oferă un serviciu de date. Există o diferență uriașă între cele două. Informația este ceva care face diferența în luarea deciziilor și eficacitatea; relativ, i de date ele sunt elemente de bază pentru obținerea acelei informații.

Chiar dacă critică sursa de date pentru a răspunde cerințelor afacerii, mediul BI ar trebui să aibă un rol mai important în crearea conținutului de informații. Trebuie să luăm pașii suplimentari pentru a curăța, integra, transforma sau crea în alt mod conținut informațional asupra căruia utilizatorii pot acționa și apoi trebuie să ne asigurăm că acele acțiuni și decizii, acolo unde sunt rezonabile, se reflectă în mediul BI. Dacă retrogradăm depozitul să servească numai pe de date, fiți siguri că asociațiile de utilizatori vor crea conținutul informativ necesar pentru a lua măsuri. Acest lucru asigură că comunitatea lor va fi capabilă să ia decizii mai bune, dar întreprinderea suferă de o lipsă de cunoștințe pe care le-au folosit. Data că arhitecții și planificatorii de proiecte inițiază proiecte specifice în mediul BI, ei rămân responsabili față de întreprindere în ansamblu. Un exemplu simplu al acestei caracteristici cu două fețe a iterațiilor BI se găsește în sursă de date. Toate de date primite pentru cereri comerciale specifice trebuie să fie populate în primul strat atomic. Acest lucru asigură dezvoltarea activului informațional al întreprinderii, precum și gestionarea, adresarea solicitărilor specifice ale utilizatorilor definite în iterație.

Ce este un depozit de date?

Depozit de date a fost inima arhitecturii sistemelor informatice din 1990 si sustine procesele informatice oferind o platforma solida integrata de de date istoric luat ca bază pentru analizele ulterioare. THE depozit de date oferă ușurință de integrare într-o lume de sisteme de aplicații incompatibile. Depozit de date a evoluat pentru a deveni un moft. Depozit de date organizează și memorează i de date necesare proceselor informaţionale şi analitice pe baza unei lungi perspective istorice temporale. Toate acestea presupun un efort considerabil și constant în construcția și întreținerea depozit de date.

Deci, ce este a depozit de date? o depozit de date și:

• ▪ orientat spre subiect
• ▪ sistem integrat
• ▪ variaţia timpului
• ▪ nevolatil (nu se anulează)

o colectie de de date utilizate pentru a sprijini deciziile manageriale în implementarea proceselor.
I de date introdus în depozit de date ele derivă în majoritatea cazurilor din medii operaţionale. The depozit de date este realizat dintr-o unitate de stocare, separata fizic de restul sistemului, pe care il contine de date transformate anterior de aplicatii care opereaza pe informatii provenite din mediul de operare.

Definiția literală a lui a depozit de date merită o explicație amănunțită deoarece există motivații importante și semnificații subiacente care descriu caracteristicile unui depozit.

ORIENTARE SUBIECTUL ORIENTARE TEMATICĂ

Prima caracteristică a a depozit de date este că este orientat către subiectele majore ale unei companii. Ghidul proceselor prin de date este în contrast cu metoda mai clasică care prevede orientarea aplicațiilor către procese și funcții, metodă comună în mare parte de majoritatea sistemelor de management mai puțin recente.

Lumea operațională este concepută în jurul aplicațiilor și funcțiilor precum împrumuturi, economii, carduri bancare și încredere pentru o instituție financiară. Lumea dw este organizată în jurul unor subiecte principale precum clientul, vânzătorul, produsul și activitatea. Alinierea în jurul subiectelor afectează proiectarea și implementarea de date găsit în dw. Cel mai important, subiectul principal afectează cea mai importantă parte a structurii cheii.

Lumea aplicațiilor este influențată atât de proiectarea bazelor de date, cât și de proiectarea proceselor. Lumea dw este concentrată exclusiv pe modelarea video de date iar asupra designului Baza de date. Proiectarea proceselor (în forma sa clasică) nu face parte din mediul dw.

Diferențele dintre alegerea procesului/aplicației funcției și alegerea subiectului sunt, de asemenea, relevate ca diferențe în conținutul de date la nivel de detaliu. THE de date del dw nu includ i de date care nu va fi folosit pentru a procesa DSS în timpul aplicațiilor

orientat operaţional de date conțin eu de date pentru a satisface imediat cerințele funcționale/de procesare care pot avea sau nu vreo utilizare pentru analistul DSS.
Un alt mod important în care aplicațiile orientate către operațional pentru de date diferă de de date de dw este în rapoartele de de date. Eu de date operatorii mențin o relație continuă între două sau mai multe mese pe baza unei reguli de afaceri care este activă. THE de date de dw acoperă un spectru de timp și rapoartele găsite în dw sunt multe. Multe reguli comerciale (și, în consecință, multe rapoarte despre de date ) sunt reprezentate în stocul de de date între două sau mai multe mese.

(Pentru o explicație detaliată a modului în care relațiile dintre de date sunt gestionate în DW, vă rugăm să consultați subiectul tehnic referitor la problema respectivă.)
Din nicio altă perspectivă decât cea a diferenței fundamentale dintre o alegere de aplicație funcțională/proces și o alegere de subiect, există o diferență majoră între sistemele de operare și de date și DW.

INTEGRARE INTEGRARE

Cel mai important aspect al mediului dw este că i de date găsite în dw sunt integrate cu ușurință. MEREU. FĂRĂ EXCEPȚII. Esența însăși a mediului dw este că i de date cuprinse în limitele depozitului sunt integrate.

Integrarea se dezvăluie în multe moduri diferite – în convenții identificate consecvente, în măsurarea consecventă a variabilelor, în structuri codificate consistente, în atributele fizice ale de date consistente și așa mai departe.

De-a lungul anilor, designerii diferitelor aplicații au luat multe decizii cu privire la modul în care ar trebui să fie dezvoltată o aplicație. Stilul și deciziile de design individualizate ale aplicațiilor designerilor sunt dezvăluite în o sută de moduri: în diferențe de codare, structura cheie, caracteristici fizice, convenții de identificare și așa mai departe. Capacitatea colectivă a multor designeri de aplicații de a crea aplicații inconsistente este legendară. Figura 3 expune unele dintre cele mai importante diferențe în modul în care sunt proiectate aplicațiile.

Codificare: Codificare:

Designerii de aplicații au ales codificarea câmpului – genul – în mai multe moduri. Un designer reprezintă genul ca „m” și „f”. Un alt designer reprezintă genul ca un „1” și un „0”. Un alt designer reprezintă genul ca „x” și „y”. Un alt designer reprezintă genul ca „masculin” și „femei”. Chiar nu contează cum intră sexul în DW. „M” și „F” sunt probabil la fel de bune ca orice reprezentare.

Ceea ce contează este că, indiferent de sursa din care provine câmpul sexual, acel câmp ajunge în DW într-o stare integrată consecventă. În consecință, atunci când câmpul este încărcat în DW dintr-o aplicație în care a fost reprezentat în exterior în formatul „M” și „F”, de date trebuie convertit în format DW.

Măsurarea atributelor: Măsurarea Atribute:

Designerii de aplicații au ales să măsoare conductele într-o varietate de moduri de-a lungul anilor. Un designer magazin i de date a conductei în centimetri. Un alt designer de aplicații stochează de date a conductei în termeni de inci. Un alt designer de aplicații stochează de date a conductei în milioane de picioare cubi pe secundă. Și un alt designer stochează informații despre conducte în termeni de metri. Oricare ar fi sursa, atunci când informațiile de conductă ajung în DW, acestea trebuie măsurate în același mod.

După cum se arată în figura 3, problemele de integrare afectează aproape fiecare aspect al proiectului – caracteristicile fizice ale de date, dilema de a avea mai multe surse de de date, problema eșantioanelor identificate inconsecvente, formate de de date inconsecventă și așa mai departe.

Oricare ar fi argumentul de proiectare, rezultatul este același – i de date trebuie să fie stocate în DW într-un mod unic și acceptabil la nivel global chiar și atunci când sistemele de operare subiacente stochează i de date.

Când analistul DSS se uită la DW, accentul analistului ar trebui să fie exploatarea de date care sunt în depozit,

mai degrabă decât să ne întrebăm despre credibilitatea sau consistența de date.

VARIANTA DE TIMP

toate de date în DW sunt precise la un moment dat. Această caracteristică de bază a de date în DW este foarte diferit de de date găsite în mediul de operare. THE de date ale mediului de operare sunt la fel de precise ca în momentul accesării. Cu alte cuvinte, în mediul de operare când se accesează o unitate de date, este de așteptat să reflecte valori la fel de precise ca în momentul accesării. De ce eu de date în DW sunt precise, deoarece la un moment dat în timp (adică, nu „în acest moment”), i de date găsite în DW sunt „varianța în timp”.
Varianta de timp a de date de către DW se face referire în numeroase moduri.
Cel mai simplu mod este ca i de date a unui DW reprezintă de date pe un orizont de timp lung – cinci până la zece ani. Orizontul de timp descris pentru mediul de operare este mult mai scurt decât valorile actuale de astăzi cu până la șaizeci și nouăzeci
Aplicațiile care trebuie să funcționeze bine și trebuie să fie disponibile pentru procesarea tranzacțiilor trebuie să aducă cantitatea minimă de de date dacă permit orice grad de flexibilitate. Deci aplicațiile operaționale au un orizont de timp scurt, cum ar fi un subiect de proiectare a aplicațiilor audio.
Al doilea mod în care „varianța de timp” apare în DW este în structura cheii. Fiecare structură cheie din DW conține, implicit sau explicit, un element de timp, cum ar fi ziua, săptămână, lună etc. Elementul de timp este aproape întotdeauna în partea de jos a cheii concatenate găsite în DW. În aceste ocazii, elementul de timp va exista implicit, cum ar fi cazul în care un întreg fișier este duplicat la sfârșitul lunii sau trimestrului.
Al treilea mod în care este afișată variația de timp este că i de date din DW, doar înregistrat corect, nu poate fi actualizat. THE de date din DW sunt, pentru toate scopurile practice, o serie lungă de instantanee. Desigur, dacă instantaneul a fost făcut incorect, atunci instantaneele pot fi modificate. Dar presupunând că instantaneele sunt făcute corect, acestea nu sunt modificate imediat ce sunt făcute. În unele

cazuri, poate fi lipsit de etică sau chiar invalid ca instantaneele din DW să fie modificate. THE de date operațional, fiind la fel de precis ca în momentul accesării, poate fi actualizat pe măsură ce este nevoie.

NU VOLATIL

A patra caracteristică importantă a DW este că este nevolatil.
Actualizările, inserările, ștergerile și modificările sunt efectuate în mod regulat în mediile operaționale, înregistrări cu înregistrare. Dar manipularea de bază a de date necesare în DW este mult mai ușor. Există doar două tipuri de operații care apar în DW – încărcarea inițială a de date si acces la de date. Nu există nicio actualizare a de date (în sensul general de actualizare) în DW ca operație normală de procesare. Există câteva consecințe foarte puternice ale acestei diferențe de bază între procesarea operațională și procesarea DW. La nivel de proiectare, necesitatea de a fi precaut cu privire la actualizarea în caz de accident nu este un factor în DW, deoarece actualizarea de date nu se realizează. Aceasta înseamnă că la nivelul fizic al designului, pot fi luate libertăți pentru a optimiza accesul la de date, în special în tratarea subiectelor de normalizare și denormalizare fizică. O altă consecință a simplității operațiunii DW este tehnologia de bază utilizată pentru a rula mediul DW. Pentru a suporta actualizări online înregistrare cu înregistrare (cum este adesea cazul în cazul calculului operațional) necesită ca tehnologia să aibă o bază foarte complexă sub o simplitate aparentă.
Tehnologia care acceptă backup și recuperare, tranzacții și integritatea datelor de date iar detectarea și remedierea blocajului este destul de complexă și inutilă pentru procesarea DW. Caracteristicile unui DW, orientarea designului, integrarea de date în cadrul DW, variația de timp și ușurința de gestionare a de date, totul duce la un mediu foarte, foarte diferit de mediul de operare clasic. Sursa aproape tuturor de date ale DW sunt mediul de operare. Este tentant să credem că există o redundanță masivă de de date între cele două medii.
Într-adevăr, prima impresie pe care o au mulți oameni este aceea de mare redundanță de date între mediul de operare şi mediul de

Extensie DW. O astfel de interpretare este superficială și demonstrează o lipsă de înțelegere a ceea ce se întâmplă în DW.
Într-adevăr, există un minim de redundanță de date între mediul de operare și i de date din DW. Luați în considerare următoarele: I de date sunt filtrate Dato că treceți de la mediul de operare la mediul DW. Mulți de date nu ies niciodată în afara mediului de operare. Numai că eu de date care sunt necesare procesării DSS își găsesc direcția în mediu

▪ orizontul de timp al de date este foarte diferit de la un mediu la altul. THE de date în mediul de operare sunt foarte proaspete. THE de date în DW sunt mult mai vechi. Doar din perspectiva orizontului de timp, există foarte puțină suprapunere între mediul de operare și DW.

▪ DW conține de date rezumat care nu sunt niciodată în mediu

▪ I de date suferă o transformare fundamentală pe măsură ce tranziția la Figura 3 ilustrează faptul că majoritatea de date sunt modificate semnificativ cu condiția să fie selectate și mutate în DW. Altfel spus, majoritatea de date este schimbat fizic și radical pe măsură ce este mutat în DW. Din punct de vedere al integrării nu sunt la fel de date locuind în mediul de operare. Având în vedere acești factori, redundanța de de date între cele două medii este un eveniment rar, care duce la mai puțin de 1% redundanță între cele două medii. STRUCTURA DEPOZITULUI DW-urile au o structură distinctă. Există diferite niveluri de rezumat și de detaliu care delimitează DW-urile.
Diferitele componente ale unui DW sunt:

• Metadata
• DATI detalii actuale
• DATI de detaliu vechi
• DATI putin rezumat
• DATI foarte rezumat

De departe principala preocupare este pentru i de date detalii actuale. Este preocuparea principală deoarece:

• I de date Detaliile actuale reflectă cele mai recente evenimente, care sunt întotdeauna de mare interes și
• i de date datele curente de detaliu sunt voluminoase deoarece sunt stocate la cel mai scăzut nivel de granularitate și
• i de date detaliile curente sunt aproape întotdeauna stocate în memoria discului, care este rapid de accesat, dar costisitoare și complexă de la I de date de detaliu sunt mai vechi de date care sunt stocate pe o anumită memorie a masa. Este accesat sporadic și stocat la un nivel de detaliu compatibil cu de date detalii actuale. Deși nu este obligatorie stocarea pe un mediu de stocare alternativ, din cauza volumului mare de de date unit cu accesul sporadic al de date, suportul de stocare pentru de date detaliile mai vechi nu sunt de obicei stocate pe disc. THE de date ușor rezumate sunt de date care sunt distilate de la nivelul scăzut de detaliu găsit până la nivelul actual de detaliu. Acest nivel de DW este aproape întotdeauna stocat în memoria discului. Problemele de proiectare care se prezintă arhitectului de date în construcția acestui nivel al DW sunt:

• Ce unitate de timp este rezumatul făcut mai sus
• Ce conținut, atribute vor rezuma ușor conținutul de date Următorul nivel al de date găsit în DW este cel al de date foarte rezumat. THE de date foarte rezumate sunt compacte și ușor accesibile. THE de date foarte rezumate se găsesc uneori în mediul DW și în alte cazuri i de date foarte abstracte se găsesc în afara zidurilor imediate ale tehnologiei care găzduiește DW. (în orice caz, i de date foarte rezumate fac parte din DW, indiferent de unde i de date sunt adăpostite fizic). Componenta finală a DW este aceea a metadatelor. În multe privințe, metadatele se află într-o dimensiune diferită de altele de date din DW, deoarece metadatele nu conțin niciuna Dato preluate direct din mediul de operare. Metadatele au un rol special și foarte important în DW. Metadatele sunt folosite ca:

• un director care să-l ajute pe analistul DSS să localizeze conținutul DW-ului,
• un ghid de cartografiere de date de cum eu de date au fost transformate din mediul de operare în mediul DW,
• un ghid al algoritmilor utilizați pentru rezumarea între i de date detalii actuale ei de date putin rezumat, i de date foarte rezumat, metadatele joacă un rol mult mai important în mediul DW decât a avut vreodată în mediul operațional MEDIU DE DEPOZITARE DE DETALII VECHI Banda magnetică poate fi folosită pentru a stoca astfel de de date. Într-adevăr, există o mare varietate de medii de stocare care ar trebui luate în considerare pentru stocarea celor vechi de date de detaliu. În funcție de volumul de de date, frecvența accesului, costul instrumentelor și tipul de acces, este absolut probabil ca alte instrumente să aibă nevoie de vechiul nivel de detaliu din DW. FLUXUL DE DATE Există un flux normal și previzibil al de date în cadrul DW.
  I de date intră în DW din mediul de operare. (NOTĂ: Există câteva excepții foarte interesante de la această regulă. Cu toate acestea, aproape toate de date introduceți DW din mediul de operare). Data că i de date ei intră în DW din mediul de operare, acesta este transformat așa cum este descris mai sus. Cu condiția să introduceți DW, i de date introduceți nivelul actual de detaliu, așa cum se arată. Se află acolo și este folosit până când apare unul dintre cele trei evenimente:

• este purificat,
• este rezumat și/sau ▪este Procesul învechit din interiorul unui DW mută i de date detalii actuale a de date de detaliu vechi, după vârsta de de date. Procesul

rezumarea folosește detaliul de de date pentru a calcula de date niveluri ușor rezumate și foarte rezumate ale de date. Există câteva excepții de la fluxul afișat (care vor fi discutate mai târziu). Cu toate acestea, de obicei, pentru marea majoritate a de date găsit într-un DW, fluxul de de date este așa cum este reprezentat.

UTILIZAREA DATAWAREHOUSE

Nu este surprinzător diferitele niveluri de de date în cadrul DW nu primesc niveluri diferite de utilizare. De regulă, cu cât nivelul de rezumare este mai mare, cu atât i de date sunt folosite.
Multe utilizări apar în de date foarte rezumat, în timp ce vechiul de date de detaliu nu sunt aproape niciodată folosite. Există motive întemeiate pentru a trece organizația la paradigma de utilizare a resurselor. Mai mult rezumat i de date, cu atât se ajunge mai rapid și mai eficient de date. În cazul în care o magazin constată că efectuează o mulțime de procesări la nivel de detaliu a DW-ului, apoi se consumă o cantitate mare de resurse ale mașinii. Este în interesul tuturor să procesăm un rezumat atât de înalt cât mai curând posibil.

Pentru multe magazine, analistul DSS într-un mediu pre-DW a folosit de date la nivel de detaliu. În multe privințe sosirea la de date detaliat arată ca o pătură de securitate, chiar și atunci când sunt disponibile alte niveluri de rezumat. Una dintre activitățile arhitectului de de date este de a înțărca utilizatorul DSS de la utilizarea constantă a de date la cel mai scăzut nivel de detaliu. Există două motivații la îndemâna arhitectului de date:

• instalarea unui sistem de rambursare, în care utilizatorul final plătește pentru resursele consumate e
• care indică faptul că se poate obține un timp de răspuns foarte bun atunci când comportamentul cu i de date este la un nivel ridicat de rezumat, în timp ce timpul de răspuns slab provine din comportamentul de date la un nivel scăzut de ALTE CONSIDERAȚII Există câteva alte considerente privind construcția și managementul DW.
  Prima considerație este aceea a indicilor. THE de date la niveluri superioare de rezumare pot fi indexate liber, în timp ce i de date

la niveluri inferioare de detaliu sunt atât de voluminoase încât pot fi indexate cu moderație. Din același motiv, i de date la niveluri ridicate de detaliu pot fi restructurate relativ ușor, în timp ce volumul de de date la nivelurile inferioare este atât de mare încât i de date nu pot fi recondiționate ușor. În consecință, modelul de date iar munca formală realizată de proiectare pune bazele DW aplicate aproape exclusiv la nivelul actual de detaliu. Cu alte cuvinte, activitățile de modelare ale de date ele nu se aplică nivelurilor de rezumat, în aproape toate cazurile. Un alt aspect structural este cel al subdiviziunii a de date de DW.

Partiția se poate face la două niveluri – la nivelul de dbms și la nivel de aplicație. În divizia la nivel dbms, dbms este informat despre divizii și le controlează în consecință. În cazul unei diviziuni la nivel de aplicație, doar programatorul este la curent cu diviziile și responsabilitatea pentru administrarea acestora îi revine acestuia.

Sub nivel dbms, multă muncă se face automat. Există multă inflexibilitate asociată cu autoadministrarea diviziilor. În cazul aplicării la nivel de diviziune a de date del depozit de date, o mare parte a muncii revine programatorului, dar rezultatul final este flexibilitatea în administrarea de date în depozit de date

ALTE ANOMALII

În timp ce componentele depozit de date funcționează așa cum este descris pentru aproape toți de date, există câteva excepții utile care trebuie discutate. O excepție este cea a de date rezumate publice (date rezumate publice). Acestea sunt de date rezumate care au fost calculate din depozit de date dar sunt folosite de societate. THE de date rezumatele publice sunt stocate și gestionate în depozit de date, deși, așa cum am menționat mai sus, sunt descoperite. Contabilii lucrează pentru a produce astfel de trimestri de date cum ar fi veniturile, cheltuielile trimestriale, profitul trimestrial și așa mai departe. Munca efectuată de contabili este externă depozit de date. Oricum eu de date sunt folosite „intern” în cadrul companiei – din marketing, vânzări etc. O altă anomalie, despre care nu se va discuta, este aceea a de date extern.

Un alt tip remarcabil de de date care poate fi găsit într-o depozit de date este cel al datelor de detaliu permanent. Acestea determină nevoia de a stoca permanent de date la un nivel detaliat din motive etice sau legale. Dacă o companie își expune lucrătorii la substanțe periculoase, este nevoie de aceasta de date detaliat și permanent. Dacă o companie fabrică un produs care implică siguranța publică, cum ar fi piese pentru un avion, este necesar să de date detalii permanente, precum și dacă o companie încheie contracte periculoase.

Compania nu își poate permite să treacă cu vederea detaliile deoarece în următorii câțiva ani, în cazul unui proces, rechemare, defect de construcție în litigiu etc. expunerea companiei ar putea fi mare. Ca rezultat, există un tip unic de de date cunoscute sub denumirea de date cu detalii permanente.

REZUMAT

Un depozit de date este o variantă orientată obiect, integrată, tensionată, o colecție de de date nevolatile în sprijinul nevoilor decizionale ale administraţiei. Fiecare dintre funcțiile importante ale a depozit de date are implicațiile sale. În plus, există patru niveluri de de date del depozit de date:

• Detalii vechi
• Detaliu curent
• DATI putin rezumat
• DATI Metadatele foarte rezumate sunt, de asemenea, o parte importantă a depozit de date. ABSTRACT Conceptul de depozitare a de date a primit recent multă atenție și a devenit o tendință a anilor 90. Acest lucru se datorează capacității unui depozit de date pentru a depăși limitările sistemelor de susținere a managementului, cum ar fi sistemele de sprijin pentru decizii (DSS) și sistemele de informații executive (EIS). Deși conceptul de depozit de date pare promițător, implementați i depozit de date poate fi problematică din cauza proceselor de depozitare la scară largă. În ciuda complexității proiectelor de depozitare a de date, mulți furnizori și consultanți care stochează de date susțin că depozitarea de de date nu prezinta nicio problema. Cu toate acestea, la începutul acestui proiect de cercetare, aproape că nu s-a făcut nicio cercetare independentă, riguroasă și sistematică. În consecință, este dificil de spus ce se întâmplă de fapt în industrie atunci când sunt construite depozit de date. Acest studiu a explorat practica de depozitare a de date contemporani care își propune să dezvolte o înțelegere mai bogată a practicii australiene. Revizuirea literaturii de specialitate a oferit contextul și fundamentul studiului empiric. Există o serie de rezultate din această cercetare. În primul rând, acest studiu a relevat activitățile care au avut loc în timpul dezvoltării depozit de date. În multe zone, i de date adunate au confirmat practica raportată în literatura de specialitate. În al doilea rând, problemele și problemele care pot afecta dezvoltarea depozit de date au fost identificate prin acest studiu. În cele din urmă, beneficiile obținute de organizațiile australiene asociate cu utilizarea depozit de date au fost dezvăluite.

Capitolul 1

Caută context

Conceptul de depozitare a datelor a primit o expunere pe scară largă și a devenit o tendință emergentă în anii 90 (McFadden 1996, TDWI 1996, Shah și Milstein 1997, Shanks și colab. 1997, Eckerson 1998, Adelman și Oates 2000). Acest lucru se poate observa din numărul tot mai mare de articole despre depozitarea datelor în publicațiile comerciale (Little și Gibson 1999). Multe articole (vezi, de exemplu, Fisher 1995, Hackathorn 1995, Morris 1995a, Bramblett and King 1996, Graham et al. 1996, Sakaguchi and Frolick 1996, Alvarez 1997, Brousell 1997, Clarke 1997, Donnell 1997, McCar 1997 Edwards 1998, TDWI 1999) au raportat beneficii semnificative pentru organizațiile care implementează depozit de date. Ei și-au susținut teoria cu dovezi anecdotice ale implementărilor de succes, cifre ridicate ale rentabilității investiției (ROI) și, de asemenea, prin furnizarea de orientări sau metodologii pentru dezvoltarea depozit de date

(Shanks și colab. 1997, Seddon și Benjamin 1998, Little și Gibson 1999). Într-un caz extrem, Graham și colab. (1996) au raportat o rentabilitate medie a unei investiții pe trei ani de 401%.

O mare parte din literatura actuală, totuși, a trecut cu vederea complexitățile implicate în realizarea unor astfel de proiecte. Proiectele de depozit de date ele sunt de obicei complexe și la scară largă și, prin urmare, au o probabilitate mare de eșec dacă nu sunt controlate cu atenție (Shah și Milstein 1997, Eckerson 1997, Foley 1997b, Zimmer 1997, Bort 1998, Gibbs și Clymer 1998, Rao 1998). Ele necesită cantități mari de resurse umane și financiare, timp și efort pentru a le construi (Hill 1998, Crofts 1998). Timpul tipic și mijloacele financiare necesare sunt de aproximativ doi ani și, respectiv, două până la trei milioane de dolari (Braly 1995, Foley 1997b, Bort 1998, Humphries et al. 1999). Acest timp și mijloace financiare sunt necesare pentru a controla și consolida multe aspecte diferite ale depozitării datelor (Cafasso 1995, Hill 1998). Pe lângă considerentele hardware și software, alte funcții, care variază de la extragerea de date la procesele de încărcare a de date, capacitatea memoriei de a gestiona actualizările și meta de date pentru instruirea utilizatorilor, trebuie luate în considerare.

La momentul în care a început acest proiect de cercetare, se desfășurau foarte puține cercetări academice în domeniul depozitării datelor, în special în Australia. Acest lucru a fost evident din lipsa articolelor publicate despre depozitarea datelor de reviste sau alte scrieri academice ale vremii. Multe dintre scrierile academice disponibile descriau experiența SUA. Lipsa cercetării academice în domeniul depozitării datelor a determinat o cerere pentru cercetări riguroase și studii empirice (McFadden 1996, Shanks și colab. 1997, Little și Gibson 1999). În special, studii de cercetare privind procesul de implementare a depozit de date trebuie făcut pentru a extinde cunoștințele generale despre implementarea depozit de date și va servi drept bază pentru un viitor studiu de cercetare (Shanks et al. 1997, Little and Gibson 1999).

Prin urmare, scopul acestui studiu este de a investiga ce se întâmplă de fapt atunci când organizațiile implementează și utilizează i depozit de date in Australia. Mai exact, acest studiu va implica o analiză a unui întreg proces de dezvoltare a unui depozit de date, începând cu inițierea și proiectarea prin proiectare și implementare și utilizarea ulterioară în cadrul organizațiilor australiene. În plus, studiul va contribui, de asemenea, la practica curentă prin identificarea domeniilor în care practica poate fi îmbunătățită în continuare și ineficiențele și riscurile pot fi minimizate sau evitate. În plus, va servi drept bază pentru alte studii despre depozit de date în Australia și va umple golul care există în prezent în literatură.

Întrebări de cercetare

Obiectivul acestei cercetări este de a studia activitățile implicate în implementarea depozit de date și utilizarea lor de către organizațiile australiene. În special, sunt studiate elementele privind planificarea, dezvoltarea, operarea, utilizarea proiectului și riscurile implicate. Deci întrebarea acestei cercetări este:

„Cum este practica actuală a depozit de date in Australia?"

Pentru a răspunde eficient la această întrebare, sunt necesare o serie de întrebări de cercetare subsidiare. În special, trei subîntrebări au fost identificate din literatura de specialitate, care este prezentată în capitolul 2, pentru a ghida acest proiect de cercetare: Cum sunt depozit de date de organizații australiene? Care sunt problemele întâlnite?

Care sunt beneficiile experimentate?
Pentru a răspunde la aceste întrebări, a fost utilizat un design de cercetare exploratorie care utilizează un sondaj. Ca studiu exploratoriu, răspunsurile la întrebările de mai sus nu sunt complete (Shanks et al. 1993, Denscombe 1998). În acest caz, este necesară o anumită triangulare pentru a îmbunătăți răspunsurile la aceste întrebări. Cu toate acestea, investigația va oferi o bază solidă pentru lucrările viitoare care examinează aceste întrebări. O discuție detaliată despre justificarea și proiectarea metodei de cercetare este prezentată în capitolul 3.

Structura proiectului de cercetare

Acest proiect de cercetare este împărțit în două părți: studiul contextual al conceptului de depozitare a datelor și cercetarea empirică (vezi Figura 1.1), fiecare dintre acestea fiind discutată mai jos.

Partea I: Studiu contextual

Prima parte a cercetării a constat într-o trecere în revistă a literaturii actuale despre diferite tipuri de depozitare de date, inclusiv sisteme de suport decizional (DSS), sisteme de informare executivă (EIS), studii de caz de depozit de date și conceptele de depozit de date. De asemenea, rezultatele forumurilor pe depozit de date și grupurile de întâlnire de experți și practicieni conduse de grupul de cercetare Monash DSS, au contribuit la această fază a studiului, care a fost menită să obțină o perspectivă asupra practicii depozit de date și să identifice riscurile pe care le implică adoptarea acestora. În această perioadă de studiu contextual, a fost stabilită o înțelegere a zonei problemei pentru a oferi baza de cunoștințe pentru investigațiile empirice ulterioare. Cu toate acestea, acesta a fost un proces în curs de desfășurare, deoarece studiul de cercetare a fost efectuat.

Partea a II-a: Cercetare empirică

Conceptul relativ nou de depozitare de date, în special în Australia, a creat necesitatea unui sondaj pentru a obține o imagine amplă a experienței de utilizare. Această parte a fost realizată odată ce domeniul problemei a fost stabilit printr-o revizuire extinsă a literaturii. Conceptul de depozitare a datelor format în timpul fazei de studiu contextual a fost folosit ca intrare pentru chestionarul inițial al acestui studiu. După aceasta, chestionarul a fost revizuit. Ești expert în depozit de date a participat la test. Scopul testării chestionarului inițial a fost de a verifica caracterul complet și acuratețea întrebărilor. Pe baza rezultatelor testului, chestionarul a fost modificat, iar versiunea modificată a fost trimisă participanților la sondaj. Chestionarele returnate au fost apoi analizate pentru i de date în tabele, diagrame și alte formate. THE

rezultatele analizei de de date formați un instantaneu al practicii de depozitare a datelor din Australia.

PREZENTARE GENERALĂ A DEPOZITĂRII DE DATE

Conceptul de depozitare de date a evoluat odată cu îmbunătățirea tehnologiei computerelor.
Acesta are ca scop depășirea problemelor întâlnite de grupurile de suport pentru aplicații precum Decision Support System (DSS) și Executive Information System (EIS).

În trecut, cel mai mare obstacol al acestor aplicații a fost incapacitatea acestor aplicații de a oferi a Bază de date necesare analizei.
Acest lucru este cauzat în principal de natura activității conducerii. Interesele conducerii unei companii variază constant în funcție de zona acoperită. Prin urmare i de date fundamentale pentru aceste aplicații trebuie să se poată schimba rapid în funcție de piesa de tratat.
Aceasta înseamnă că i de date trebuie să fie disponibile în forma adecvată pentru analizele necesare. De fapt, grupurilor de suport pentru aplicații le era foarte dificil în trecut să colecteze și să integreze de date din surse complexe și diverse.

Restul acestei secțiuni prezintă o privire de ansamblu asupra conceptului de depozitare de date și discută modul în care depozit de date poate depăși problemele grupurilor de suport pentru aplicații.
Termenul "Depozitul de datea fost popularizat de William Inmon în 1990. Definiția sa des citată vede Depozitul de date ca o colecție de de date orientat pe subiect, integrat, nevolatil și variabil în timp, în sprijinul deciziilor de management.

Folosind această definiție, Inmon subliniază că i de date cu domiciliul într-o depozit de date trebuie să posede următoarele 4 caracteristici:

• ▪ Orientat pe subiect
• ▪ Integrat
• ▪ Nevolatil
• ▪ Variabil în timp Prin Inmon orientat pe subiect înseamnă că i de date în depozit de date în cele mai mari zone organizatorice care au fost

definite în model de date. De exemplu toate de date referitor la i clienții sunt cuprinse în domeniul subiectului CLIENȚI. La fel toate de date referitoare la produse sunt cuprinse în domeniul PRODUSE.

Prin Integrated Inmon înseamnă că i de date de pe platforme diferite, sisteme și locații sunt combinate și stocate într-un singur loc. În consecință de date cele similare trebuie transformate în formate consistente pentru a fi adăugate și comparate cu ușurință.
De exemplu, genul masculin și feminin sunt reprezentate de literele M și F într-un sistem și de 1 și 0 în altul. Pentru a le integra corect, unul sau ambele formate trebuie transformate astfel încât cele două formate să fie egale. În acest caz, am putea schimba M cu 1 și F cu 0 sau invers. Orientat pe subiect și integrat indică faptul că depozit de date este conceput pentru a oferi o viziune funcțională și transversală a de date de la companie.

Prin Non-volatil el înseamnă că i de date în depozit de date rămân consecvenți și actualizați de date nu este necesar. În schimb, orice schimbare în de date originale se adaugă la Baza de date del depozit de date. Aceasta înseamnă că istoricul din de date este cuprins în depozit de date.

Pentru variabilele cu timp, Inmon indică faptul că i de date în depozit de date conțin întotdeauna indicatorii de tempo ei de date ele traversează în mod normal un anumit orizont de timp. De exemplu a
depozit de date poate conține 5 ani de valori istorice ale clienții din 1993 până în 1997. Disponibilitatea istoricului și a unei serii temporale a de date vă permite să analizați tendințele.

Un depozit de date el poate să-și adune pe al său de date din sisteme OLTP; din origini de date externă organizației și/sau din alte proiecte speciale de sisteme de captare de date.
I de date extractele pot trece printr-un proces de curățare, în acest caz i de date sunt transformate și integrate înainte de a fi stocate în Baza de date del depozit de date. Apoi eu de date

cu domiciliul în Baza de date del depozit de date sunt puse la dispoziția utilizatorilor finali autentificări și instrumente de recuperare. Folosind aceste instrumente, utilizatorul final poate accesa vizualizarea integrată a organizației de date.

I de date cu domiciliul în Baza de date del depozit de date sunt stocate atât în ​​formate detaliate, cât și în formate rezumative.
Nivelul rezumatului poate depinde de natura de date. Eu de date detaliat poate consta din de date curent şi de date istorici
I de date reale nu sunt incluse în depozit de date până când eu de date în depozit de date sunt reactualizate.
Pe lângă stocarea de date ei înșiși, a depozit de date poate stoca și un alt tip de Dato numite METADATE care descriu i de date locuind în a lui Baza de date.
Există două tipuri de metadate: metadate de dezvoltare și metadate de analiză.
Metadatele de dezvoltare sunt folosite pentru a gestiona și automatiza procesele de extragere, curățare, mapare și încărcare de date în depozit de date.
Informațiile conținute în metadatele de dezvoltare pot conține detalii despre sisteme de operare, detalii despre elementele de extras, modelul de date del depozit de date și reguli de afaceri pentru conversia datelor de date.

Al doilea tip de metadate, cunoscut sub numele de metadate de analiză, permite utilizatorului final să exploreze conținutul depozit de date pentru a găsi de date disponibile și semnificația lor în termeni clari, non-tehnici.

Astfel, metadatele de analiză funcționează ca o punte între depozit de date și aplicații pentru utilizatorii finali. Aceste metadate pot conține modelul de afaceri, descrieri ale de date corespunzătoare modelului de afaceri, interogări și rapoarte predefinite, informații pentru accesul utilizatorilor și index.

Metadatele de analiză și dezvoltare trebuie să fie combinate într-o singură metadate de izolare integrată pentru a funcționa corect.

Din păcate, multe dintre instrumentele existente au propriile lor metadate și în prezent nu există standarde existente

permite instrumentelor de depozitare a datelor să integreze aceste metadate. Pentru a remedia această situație, mulți furnizori de instrumente de top pentru depozitarea datelor au format Meta Data Council, care mai târziu a devenit Meta Data Coalition.

Scopul acestei coaliții este de a construi un set standard de metadate care să permită diferitelor instrumente de depozitare a datelor să convertească metadatele.
Eforturile lor au dus la nașterea Meta Data Interchange Specification (MDIS) care va permite schimbul de informații între arhivele Microsoft și fișierele MDIS aferente.

Existenta lui de date atât rezumat/indexat, cât și detaliat, oferă utilizatorului posibilitatea de a efectua un DRILL DROWN (foraj) din de date indexate la cele detaliate și invers. Existenta lui de date istoricul detaliat permite crearea de analize de tendințe în timp. În plus, metadatele de analiză pot fi folosite ca un director del Baza de date del depozit de date pentru a ajuta utilizatorii finali să găsească i de date necesar.

În comparație cu sistemele OLTP, cu capacitatea lor de a susține analiza de date și raportare, the depozit de date este văzut ca un sistem mai adecvat pentru procesele informaționale, cum ar fi realizarea și răspunsul la întrebări și elaborarea de rapoarte. Următoarea secțiune va evidenția în detaliu diferențele dintre cele două sisteme.

DEPOZIT DE DATE ÎMPOTRIVA SISTEMELOR OLTP

Multe dintre sistemele informaționale din cadrul organizațiilor sunt menite să sprijine operațiunile de zi cu zi. Aceste sisteme cunoscute sub numele de SISTEME OLTP, captează tranzacții zilnice care sunt actualizate continuu.

I de date în cadrul acestor sisteme sunt adesea modificate, adăugate sau șterse. De exemplu, adresa unui client se schimbă pe măsură ce se deplasează dintr-un loc în altul. În acest caz, noua adresă va fi înregistrată prin modificarea câmpului de adresă al Baza de date. Obiectivul principal al acestor sisteme este reducerea costurilor de tranzacție și, în același timp, reducerea timpilor de procesare. Exemplele de sisteme OLTP includ acțiuni critice, cum ar fi jurnalizarea comenzilor, statul de plată, facturile, producția, serviciul pentru clienți clienții.

Spre deosebire de sistemele OLTP, care au fost create pentru procese bazate pe tranzacții și evenimente, i depozit de date au fost create pentru a oferi suport de proces bazat pe analiză de date și asupra proceselor de luare a deciziilor.

Acest lucru se realizează în mod normal prin integrarea i de date din diverse OLTP și sisteme externe într-un singur „container” de de date, așa cum sa discutat în secțiunea anterioară.

Modelul procesului de depozitare a datelor Monash

Modelul procesului pentru depozit de date Monash a fost dezvoltat de cercetătorii de la Monash DSS Research Group și se bazează pe literatura de specialitate depozit de date, experiență în domeniile sistemelor de suport pentru dezvoltare, discuții cu furnizorii de aplicații pentru utilizare pe depozit de date, pe un grup de experți în utilizarea depozit de date.

Fazele sunt: ​​Inițiere, Planificare, Dezvoltare, Operațiuni și Explicare. Diagrama explică natura iterativă sau evolutivă a dezvoltării a depozit de date proces folosind săgeți bidirecționale plasate între diferitele faze. În acest context, „iterativ” și „evoluționar” înseamnă că, la fiecare pas al procesului, activitățile de implementare se pot propaga întotdeauna înapoi la etapa anterioară. Acest lucru se datorează naturii unui proiect depozit de date în care solicitări suplimentare din partea utilizatorului final apar în orice moment. De exemplu, în timpul fazei de dezvoltare a unui proces depozit de dateDacă utilizatorul final solicită o nouă dimensiune sau zonă de subiect, care nu făcea parte din planul inițial, aceasta trebuie adăugată în sistem. Acest lucru determină o schimbare în proiect. Rezultatul este că echipa de proiectare trebuie să modifice cerințele documentelor create până acum în timpul fazei de proiectare. În multe cazuri, starea actuală a proiectului trebuie să se întoarcă până la faza de proiectare, unde noua cerință trebuie adăugată și documentată. Utilizatorul final trebuie să poată vedea documentația specifică revizuită și modificările care au fost făcute în faza de dezvoltare. La sfârșitul acestui ciclu de dezvoltare, proiectul trebuie să obțină feedback bun atât din partea echipelor de dezvoltare, cât și a utilizatorilor. Feedback-ul este apoi reutilizat pentru a îmbunătăți un proiect viitor.

Planificarea capacitatii
dw tind să fie de dimensiuni foarte mari și să crească foarte rapid (Best 1995, Rudin 1997a) datorită cantității de de date istorice pe care le păstrează din durata lor. Creșterea poate fi cauzată și de de date suplimente solicitate de utilizatori pentru a crește valoarea de date pe care le au deja. În consecință, cerințele de depozitare pentru de date poate fi îmbunătățită semnificativ (Eckerson 1997). Astfel, este esențial să se asigure, prin efectuarea planificării capacității, că sistemul de construit poate crește pe măsură ce nevoile cresc (Best 1995, LaPlante 1996, Lang 1997, Eckerson 1997, Rudin 1997a, Foley 1997a).
În planificarea scalabilității depozitului de date, trebuie să cunoașteți creșterea așteptată a dimensiunii depozitului, tipurile de întrebări care pot fi adresate și numărul de utilizatori finali acceptați (Best 1995, Rudin 1997b, Foley 1997a). Construirea de aplicații scalabile necesită o combinație de tehnologii de server scalabile și tehnici de proiectare a aplicațiilor scalabile (Best 1995, Rudin 1997b. Ambele sunt necesare pentru construirea unei aplicații extrem de scalabile. Tehnologiile de server scalabile pot face mai ușor și rentabil adăugarea de stocare, memorie și CPU fără performanțe degradante (Lang 1997, Telephony 1997).

Există două tehnologii de server scalabile principale: procesare multiplă simetrică (SMP) și procesare masiv paralelă (MPP) (IDC 1997, Humphries et al. 1999). Un server SMP are de obicei mai multe procesoare care partajează memorie, magistrale de sistem și alte resurse (IDC 1997, Humphries et al. 1999). Pot fi adăugate procesoare suplimentare pentru a-i spori putere de calcul. O altă metodă de a crește putere calculul serverului SMP, este de a combina numeroase mașini SMP. Această tehnică este cunoscută sub numele de clustering (Humphries et al. 1999). Un server MPP, pe de altă parte, are mai multe procesoare, fiecare cu propria memorie, sistem de magistrală și alte resurse (IDC 1997, Humphries et al. 1999). Fiecare procesor este numit nod. O creștere a putere pot fi obținute de calcul

adăugarea de noduri suplimentare la serverele MPP (Humphries et al. 1999).

Un punct slab al serverelor SMP este că prea multe operațiuni de intrare-ieșire (I/O) pot congestiona sistemul de magistrală (IDC 1997). Această problemă nu apare în serverele MPP, deoarece fiecare procesor are propriul său sistem de magistrală. Cu toate acestea, interconexiunile dintre fiecare nod sunt în general mult mai lente decât sistemul de magistrală SMP. Mai mult, serverele MPP pot adăuga un nivel suplimentar de complexitate dezvoltatorilor de aplicații (IDC 1997). Astfel, alegerea dintre serverele SMP și MPP poate fi influențată de mulți factori, printre care complexitatea aplicațiilor, raportul preț/performanță, debitul necesar, aplicațiile dw împiedicate și creșterea dimensiunii Baza de date de dw și în numărul de utilizatori finali.

O serie de tehnici de proiectare a aplicațiilor scalabile pot fi utilizate în planificarea capacității. Se utilizează diverse perioade de raportare, cum ar fi zile, săptămâni, luni și ani. Avand diverse perioade de notificare, the Baza de date poate fi împărțit în bucăți grupate gestionabil (Inmon și colab. 1997). O altă tehnică este utilizarea tabelelor rezumative care sunt construite prin rezumare de date da de date detaliat. Astfel, i de date rezumatele sunt mai compacte decât detaliate, ceea ce necesită mai puțin spațiu de memorie. Asa ca de date detaliile pot fi arhivate într-o unitate de stocare mai puțin costisitoare, ceea ce economisește și mai mult spațiu de stocare. În timp ce utilizarea tabelelor rezumative poate economisi spațiu de stocare, acestea necesită mult efort pentru a le menține la zi și în conformitate cu nevoile afacerii. Cu toate acestea, această tehnică este utilizată pe scară largă și adesea folosită împreună cu tehnica anterioară (Best 1995, Inmon 1996a, Chauduri și Dayal
1997).

Definire Depozitul de date Arhitecturi tehnice Definirea tehnicilor de arhitectura dw

Primii adoptatori ai depozitării de date au imaginat în primul rând o implementare centralizată a depozitului de date în care toate de date, inclusiv i de date externe, au fost integrate într-un singur
depozit fizic (Inmon 1996a, Bresnahan 1996, Peacock 1998).

Principalul avantaj al acestei abordări este că utilizatorii finali pot accesa vizualizarea la nivelul întregii întreprinderi a de date organizatoric (Ovum 1998). Un alt plus este că oferă standardizarea de date în întreaga organizație, ceea ce înseamnă că există o singură versiune sau definiție pentru fiecare terminologie utilizată în metadatele depozitului (Flanagan și Safdie 1997, Ovum 1998). Dezavantajul acestei abordări, pe de altă parte, este că este costisitoare și dificil de construit (Flanagan și Safdie 1997, Ovum 1998, Inmon și colab. 1998). Nu mult după arhitectura de stocare de date centralizat a devenit popular, conceptul de minerit a celor mai mici subseturi de zei a evoluat de date pentru a sprijini nevoile aplicațiilor specifice (Varney 1996, IDC 1997, Berson și Smith 1997, peacock 1998). Aceste sisteme mici sunt derivate din cel mai mare depozit de date centralizat. Ele sunt numite depozit de date departamentele angajaților sau magazinele de date ale angajaților. Arhitectura dependentă de data mart este cunoscută ca arhitectură cu trei niveluri, unde primul nivel constă din depozit de date centralizat, al doilea este format din depozitele de de date departamentale iar a treia constă în accesul la de date și prin instrumente de analiză (Demarest 1994, Inmon et al. 1997).

Data mart-urile sunt în mod normal construite după depozit de date centralizat a fost construit pentru a răspunde nevoilor unităților specifice (White 1995, Varney 1996).
Magazinul de marturi de date i de date relevante pentru anumite unități (Inmon și colab. 1997, Inmon și colab. 1998, IA 1998).

Avantajul acestei metode este că nu va exista Dato nu este integrat și că i de date va fi mai puțin redundant în cadrul marților de date, deoarece toate de date provin dintr-un depozit de de date integrat. Un alt avantaj este că vor exista mai puține legături între fiecare data mart și sursele sale de date deoarece fiecare data mart are o singură sursă de de date. În plus, cu această arhitectură implementată, utilizatorii finali pot accesa în continuare de date

organizatii corporative. Această metodă este cunoscută ca metoda de sus în jos, în care martele de date sunt construite după depozit de date (păun 1998, Goff 1998).
Creșterea nevoii de a afișa rezultate din timp, unele organizații au început să construiască magazine independente de date (Flanagan și Safdie 1997, White 2000). În acest caz, magazinele de date le primesc pe ale lor de date direct de la elementele de bază ale de date OLTP și non-OLTP din depozitul centralizat și integrat, eliminând astfel nevoia de depozit central.

Fiecare data mart necesită cel puțin o legătură către sursele sale de date. Un dezavantaj de a avea mai multe legături către fiecare data mart este că, în comparație cu cele două arhitecturi anterioare, supraabundența de de date crește semnificativ.

Fiecare data mart trebuie să stocheze toate de date necesar la nivel local să nu aibă impact asupra sistemelor OLTP. Acest lucru determină i de date acestea sunt stocate în diferite magazine de date (Inmon et al. 1997). Un alt dezavantaj al acestei arhitecturi este că duce la crearea de interconexiuni complexe între magazinele de date și sursele lor de date. de date care sunt greu de implementat şi controlat (Inmon et al. 1997).

Un alt dezavantaj este că este posibil ca utilizatorii finali să nu poată accesa prezentarea generală a informațiilor companiei, deoarece i de date dintre diferitele magazine de date nu sunt integrate (Ovum 1998).
Un alt dezavantaj este acela că poate exista mai mult de o definiție pentru fiecare terminologie utilizată în data mart-urilor care generează inconsecvențe de date. de date în organizare (Ovum 1998).
În ciuda dezavantajelor discutate mai sus, magazinele de date independente încă atrag interesul multor organizații (IDC 1997). Un factor care le face atractive este că se dezvoltă mai rapid și necesită mai puțin timp și resurse (Bresnahan 1996, Berson și Smith 1997, Ovum 1998). În consecință, ele servesc în primul rând ca modele de testare care pot fi utilizate pentru a identifica rapid beneficiile și/sau deficiențele în proiectare (Parsaye 1995, Braly 1995, Newing 1996). În acest caz, partea care trebuie implementată în proiectul pilot trebuie să fie mică, dar importantă pentru organizație (Newing 1996, Mansell-Lewis 1996).

Prin examinarea prototipului, utilizatorii finali și conducerea pot decide dacă să continue sau să oprească proiectul (Flanagan și Safdie 1997).
Dacă decizia urmează să continue, magazinele de date pentru alte industrii ar trebui construite pe rând. Există două opțiuni pentru utilizatorii finali bazate pe nevoile lor în construirea matricilor de date independente: integrate/federate și neintegrate (Ovum 1998)

În prima metodă, fiecare nou data mart ar trebui să fie construit pe baza actualelor data mart și model de date utilizat de firmă (Varney 1996, Berson și Smith 1997, Peacock 1998). Necesitatea folosirii modelului de date a întreprinderii înseamnă că trebuie să vă asigurați că există o singură definiție pentru fiecare terminologie utilizată în cadrul martelor de date, de asemenea, pentru a vă asigura că diferitele magazine de date pot fi fuzionate pentru a oferi o imagine de ansamblu asupra informațiilor întreprinderii (Bresnahan 1996). Această metodă se numește metoda de jos în sus și este utilizată cel mai bine atunci când există o constrângere asupra mijloacelor financiare și a timpului (Flanagan și Safdie 1997, Ovum 1998, peacock 1998, Goff 1998). În a doua metodă, data mart-urile construite pot satisface doar nevoile unei anumite unități. O variantă a martului de date federat este depozit de date distribuite în care Baza de date Middleware-ul serverului hub este folosit pentru a îmbina multe magazine de date într-un singur depozit de date distribuit (White 1995). În acest caz, i de date afacerile sunt distribuite în mai multe magazine de date. Solicitările utilizatorilor finali sunt redirecționate către Baza de date middleware-ul serverului hub, care extrage tot de date solicitate de data marts și transmite rezultatele înapoi la aplicațiile utilizatorului final. Această metodă oferă informații comerciale utilizatorilor finali. Cu toate acestea, problemele magazinelor independente de date nu sunt încă eliminate. Există o altă arhitectură care poate fi folosită, numită depozit de date virtual (White 1995). Cu toate acestea, această arhitectură, care este prezentată în Figura 2.9, nu este o arhitectură de stocare a datelor de date real, deoarece nu mută încărcarea de la sistemele OLTP la depozit de date (Demarest 1994).

De fapt, cereri pentru de date de către utilizatorii finali, acestea sunt transmise sistemelor OLTP care returnează rezultate după procesarea solicitărilor utilizatorilor. Deși această arhitectură permite utilizatorilor finali să genereze rapoarte și să facă cereri, nu poate oferi i

de date istoricul și prezentarea de ansamblu a informațiilor companiei de când i de date întrucât diferitele sisteme OLTP nu sunt integrate. Prin urmare, această arhitectură nu poate satisface analiza de date precum previziunile.

Selectarea aplicațiilor de acces și de recuperare a datelor de date

Scopul construirii a depozit de date este de a transmite informații către utilizatorii finali (Inmon și colab. 1997, Poe 1996, McFadden 1996, Shanks și colab. 1997, Hammergren 1998); una sau mai multe aplicații de acces și recuperare de date trebuie furnizate. Până în prezent, există o mare varietate de astfel de aplicații din care utilizatorul poate alege (Hammergren 1998, Humphries et al. 1999). Aplicațiile selectate determină succesul efortului de depozitare de date într-o organizație deoarece aplicațiile sunt partea cea mai vizibilă a depozit de date utilizatorului final (Inmon et al. 1997, Poe 1996). Pentru a avea succes a depozit de date, trebuie să poată susține activități de analiză a datelor de date al utilizatorului final (Poe 1996, Seddon și Benjamin 1998, Eckerson 1999). Astfel, trebuie identificat „nivelul” a ceea ce își dorește utilizatorul final (Poe 1996, Mattison 1996, Inmon et al. 1997, Humphries et al. 1999).

În general, utilizatorii finali pot fi grupați în trei categorii: utilizatori executivi, analiști de afaceri și utilizatori cu putere (Poe 1996, Humphries et al. 1999). Utilizatorii executivi au nevoie de acces ușor la seturi predefinite de rapoarte (Humphries et al. 1999). Aceste rapoarte pot fi accesate cu ușurință cu navigarea prin meniu (Poe 1996). În plus, rapoartele ar trebui să prezinte informații folosind reprezentări grafice, cum ar fi tabele și șabloane, pentru a transmite rapid informațiile (Humphries et al. 1999). Analiștii de afaceri, care ar putea să nu aibă capabilitățile tehnice de a dezvolta rapoarte de la zero pe cont propriu, trebuie să fie capabili să modifice rapoartele curente pentru a satisface nevoile lor specifice (Poe 1996, Humphries et al. 1999). Utilizatorii puternici, pe de altă parte, sunt tipul de utilizator final care are capacitatea de a genera și scrie cereri și rapoarte de la zero (Poe 1996, Humphries et al. 1999). Ei sunt cei care

ei construiesc relații pentru alte tipuri de utilizatori (Poe 1996, Humphries et al. 1999).

Odată ce cerințele utilizatorului final au fost determinate, trebuie făcută o selecție de aplicații de acces și recuperare de date dintre toate cele disponibile (Poe 1996, Inmon et al. 1997).
Acces la de date și instrumentele de recuperare pot fi clasificate în 4 tipuri: instrument OLAP, instrument EIS/DSS, instrument de interogare și raportare și instrument de extragere a datelor.

Instrumentele OLAP permit utilizatorilor să creeze interogări ad-hoc, precum și cele făcute pe Baza de date del depozit de date. În plus, aceste produse permit utilizatorilor să detalieze de la de date general până la detaliat.

Instrumentele EIS/DSS oferă rapoarte executive, cum ar fi analiza „ce ar fi dacă” și acces la rapoartele bazate pe meniu. Rapoartele ar trebui să fie predefinite și îmbinate cu meniuri pentru o navigare mai ușoară.
Instrumentele de interogare și raportare permit utilizatorilor să producă rapoarte predefinite și specifice.

Instrumentele de extragere a datelor sunt folosite pentru a identifica relațiile care ar putea arunca o lumină nouă asupra operațiunilor uitate de date a depozitului de date.

Pe lângă optimizarea cerințelor fiecărui tip de utilizator, instrumentele selectate trebuie să fie intuitive, eficiente și ușor de utilizat. De asemenea, trebuie să fie compatibile cu alte părți ale arhitecturii și să poată lucra cu sistemele existente. De asemenea, se recomandă să alegeți instrumente de acces la date și de recuperare cu preț și performanță rezonabile. Alte criterii de luat în considerare includ angajamentul furnizorului de instrumente de a-și susține produsul și dezvoltările pe care le va avea în versiunile viitoare. Pentru a asigura implicarea utilizatorilor în utilizarea depozitului de date, echipa de dezvoltare implică utilizatorii în procesul de selecție a instrumentului. În acest caz, ar trebui efectuată o evaluare practică a utilizatorului.

Pentru a spori valoarea depozitului de date, echipa de dezvoltare poate oferi, de asemenea, acces web la depozitele lor de date. Un depozit de date activat pentru web permite utilizatorilor să acceseze de date din locuri îndepărtate sau în timpul călătoriilor. De asemenea, informațiile pot

să fie furnizate la un cost mai mic printr-o scădere a costurilor de formare.

2.4.3 Depozitul de date Faza de operare

Această fază constă din trei activități: definirea strategiilor de reîmprospătare a datelor, controlul activităților din depozitul de date și managementul securității depozitului de date.

Definirea strategiilor de reîmprospătare a datelor

După încărcarea inițială, i de date în Baza de date a depozitului de date trebuie reîmprospătat periodic pentru a reproduce modificările efectuate pe de date originale. Deci trebuie să decideți când să reîmprospătați, cât de des ar trebui să fie programată reîmprospătarea și cum să reîmprospătați de date. Se recomandă reîmprospătarea de date când sistemul poate fi deconectat. Rata de reîmprospătare este determinată de echipa de dezvoltare în funcție de cerințele utilizatorului. Există două abordări pentru reîmprospătarea depozitului de date: reîmprospătarea completă și încărcarea continuă a modificărilor.

Prima abordare, reîmprospătarea completă, necesită reîncărcarea tuturor de date de la zero. Aceasta înseamnă că toate de date necesare trebuie extrase, curățate, transformate și integrate în fiecare reîmprospătare. Această abordare ar trebui evitată ori de câte ori este posibil, deoarece necesită timp și resurse.

O abordare alternativă este încărcarea continuă a modificărilor. Aceasta adaugă i de date care s-au modificat de la ultimul ciclu de reîmprospătare a depozitului de date. Identificarea înregistrărilor noi sau modificate reduce semnificativ cantitatea de de date care trebuie propagate către depozitul de date în fiecare actualizare ca doar acestea de date va fi adăugat la Baza de date a depozitului de date.

Există cel puțin 5 abordări care pot fi folosite pentru a retrage i de date noi sau modificate. Pentru a realiza o strategie eficientă de reîmprospătare a videoclipurilor de date un amestec al acestor abordări care preia toate modificările din sistem poate fi util.

Prima abordare, care utilizează marcaje temporale, presupune că toată lumea este atribuită de date am editat și actualizat un marcaj de timp, astfel încât să le puteți identifica cu ușurință pe toate de date modificate si noi. Cu toate acestea, această abordare nu a fost utilizată pe scară largă în majoritatea sistemelor de operare astăzi.
A doua abordare este de a folosi un fișier delta generat de aplicație care conține doar modificările făcute la de date. Utilizarea acestui fișier amplifică și ciclul de actualizare. Cu toate acestea, nici măcar această metodă nu a fost folosită în multe aplicații.
A treia abordare este scanarea unui fișier jurnal, care conține practic informații similare cu fișierul delta. Singura diferență este că un fișier jurnal este creat pentru procesul de recuperare și poate fi dificil de înțeles.
A patra abordare este modificarea codului aplicației. Cu toate acestea, majoritatea codului aplicației este vechi și fragil; prin urmare, această tehnică trebuie evitată.
Ultima abordare este de a compara i de date surse cu fisierul principal dei de date.

Monitorizarea activitatilor din depozitul de date

Odată ce depozitul de date a fost eliberat utilizatorilor, acesta trebuie monitorizat în timp. În acest caz, administratorul depozitului de date poate folosi unul sau mai multe instrumente de management și control pentru a monitoriza utilizarea depozitului de date. În special, informațiile pot fi colectate despre persoane și despre momentul în care aceștia accesează depozitul de date. Haide de date colectate, poate fi creat un profil al muncii efectuate care poate fi folosit ca intrare în implementarea rambursării de către utilizator. Chargeback permite utilizatorilor să fie informați cu privire la costul procesării depozitului de date.

În plus, auditarea depozitului de date poate fi utilizată și pentru a identifica tipurile de interogări, dimensiunea acestora, numărul de interogări pe zi, timpii de reacție la interogări, sectoarele atinse și cantitatea de interogări. de date prelucrate. Un alt scop al auditării depozitului de date este de a identifica de date care nu sunt în uz. Aceste de date pot fi eliminate din depozitul de date pentru a îmbunătăți timpul

de răspuns la execuția interogării și controlează creșterea de date care locuiesc în Bază de date a depozitului de date.

Managementul securității depozitului de date

Un depozit de date conține de date integrat, critic, sensibil la care se poate ajunge ușor. Din acest motiv ar trebui să fie protejat de utilizatorii neautorizați. O modalitate de a implementa securitatea este utilizarea funcției del Baze de date pentru a atribui diferite privilegii diferitelor tipuri de utilizatori. În acest fel, trebuie menținut un profil de acces pentru fiecare tip de utilizator. O altă modalitate de a securiza depozitul de date este să-l criptați așa cum este scris în Bază de date a depozitului de date. Acces la de date iar instrumentele de recuperare trebuie să decripteze de date înainte de a prezenta rezultatele utilizatorilor.

2.4.4 Depozitul de date Faza de implementare

Este ultima etapă a ciclului de implementare a depozitului de date. Activitățile care urmează să fie desfășurate în această fază includ instruirea utilizatorilor pentru utilizarea depozitului de date și efectuarea de revizuiri ale depozitului de date.

Instruirea utilizatorilor

Instruirea utilizatorilor trebuie făcută înainte de accesare de date a depozitului de date și utilizarea instrumentelor de recuperare. În general, sesiunile ar trebui să înceapă cu o introducere în conceptul de stocare de date, conținutul depozitului de date, meta de date și caracteristicile de bază ale instrumentelor. Apoi, utilizatorii mai avansați ar putea studia, de asemenea, tabelele fizice și caracteristicile utilizatorilor de instrumente de acces la date și de recuperare.

Există multe abordări pentru a face instruirea utilizatorilor. Una dintre acestea implică o selecție de mulți utilizatori sau analiști aleși dintr-un grup de utilizatori, pe baza abilităților lor de conducere și comunicare. Aceștia sunt instruiți personal cu privire la tot ce trebuie să știe pentru a se familiariza cu sistemul. După instruire, se întorc la locurile de muncă și încep să învețe alți utilizatori cum să folosească sistemul. Pe

Pe baza a ceea ce au învățat, alți utilizatori pot începe să exploreze depozitul de date.
O altă abordare este să antrenezi mulți utilizatori în același timp, ca și cum te-ai antrena într-o clasă. Această metodă este potrivită atunci când există mulți utilizatori care trebuie instruiți în același timp. O altă metodă este de a instrui fiecare utilizator individual, unul câte unul. Această metodă este potrivită atunci când sunt puțini utilizatori.

Scopul instruirii utilizatorilor este de a vă familiariza cu accesarea de date și instrumente de recuperare, precum și conținutul depozitului de date. Cu toate acestea, unii utilizatori pot fi copleșiți de cantitatea de informații furnizate în timpul sesiunii de instruire. Apoi, trebuie făcute o serie de sesiuni de reîmprospătare pentru asistență continuă și pentru a răspunde la întrebări specifice. În unele cazuri, se formează un grup de utilizatori pentru a oferi acest tip de suport.

Colectarea feedback-ului

Odată ce depozitul de date a fost lansat, utilizatorii pot folosi i de date rezident în depozitul de date în diverse scopuri. În cea mai mare parte, analiștii sau utilizatorii folosesc i de date în depozitul de date pentru:

1. 1 Identificați tendințele companiei
2. 2 Analizați profilurile de cumpărare ale clienții
3. 3 Împărțiți i clienții și
4. 4 Oferiți cele mai bune servicii pentru clienții – personalizarea serviciilor
5. 5 Formulați strategii marketing
6. 6 Faceți oferte competitive pentru analize de cost și ajutați la control
7. 7 Sprijinirea procesului decizional strategic
8. 8 Identificați oportunitățile de apariție
9. 9 Îmbunătățiți calitatea proceselor de afaceri curente
10. 10 Verificați profitul

Urmând direcția de dezvoltare a depozitului de date, ar putea fi efectuate o serie de revizuiri ale sistemului pentru a obține feedback

atât de echipa de dezvoltare, cât și de comunitatea de utilizatori finali.
Rezultatele obţinute pot fi luate în considerare pentru următorul ciclu de dezvoltare.

Deoarece depozitul de date are o abordare incrementală, este esențial să învățați din succesele și greșelile dezvoltărilor anterioare.

2.5 Rezumat

În acest capitol au fost discutate abordările prezente în literatură. În secțiunea 1 a fost discutat conceptul de depozit de date și rolul său în știința deciziei. Secțiunea 2 a descris principalele diferențe dintre depozitele de date și sistemele OLTP. Secțiunea 3 a discutat modelul de depozit de date Monash, care a fost folosit în secțiunea 4 pentru a descrie activitățile implicate în procesul de dezvoltare a unui depozit de date, aceste afirmații nu s-au bazat pe cercetări riguroase. Ceea ce se întâmplă în realitate poate fi foarte diferit de ceea ce raportează literatura de specialitate, totuși aceste rezultate pot fi folosite pentru a crea un bagaj de bază care subliniază conceptul de depozit de date pentru această cercetare.

Capitolul 3

Metode de cercetare și proiectare

Acest capitol tratează metodele de cercetare și proiectare pentru acest studiu. Prima parte prezintă o vedere generică a metodelor de cercetare disponibile pentru regăsirea informațiilor, în plus sunt discutate criteriile de selectare a celei mai bune metode pentru un anumit studiu. În secțiunea 2 sunt apoi discutate două metode selectate cu criteriile de mai sus; unul dintre acestea va fi ales și adoptat pentru motivele expuse în secțiunea 3 unde sunt prezentate și motivele excluderii celuilalt criteriu. Secțiunea 4 prezintă proiectul de cercetare, iar secțiunea 5 concluziile.

3.1 Cercetare în sistemele informaţionale

Cercetarea sistemelor informaționale nu se limitează doar la domeniul tehnologic, ci trebuie extinsă și pentru a include scopuri comportamentale și organizaționale.
Datorăm acest lucru tezelor diverselor discipline, de la științele sociale până la cele naturale; aceasta conduce la necesitatea unui anumit spectru de metode de cercetare care implică metode cantitative și calitative care să fie utilizate pentru sistemele informaționale.
Toate metodele de cercetare disponibile sunt importante, de fapt mai mulți cercetători precum Jenkins (1985), Nunamaker și colab. (1991) și Galliers (1992) susțin că nu există o metodă universală specifică pentru efectuarea cercetărilor în diferitele domenii ale sistemelor informaționale; de fapt, o metodă poate fi potrivită pentru o anumită cercetare, dar nu pentru altele. Acest lucru ne conduce la necesitatea de a selecta o metodă care este potrivită pentru proiectul nostru de cercetare particular: pentru această alegere Benbasat et al. (1987) afirmă că trebuie luate în considerare natura și scopul cercetării.

3.1.1 Natura cercetării

Diferitele metode de cercetare bazate pe natură pot fi clasificate în trei tradiții larg cunoscute în știința informației: cercetare pozitivistă, interpretativă și critică.

3.1.1.1 Cercetare pozitivistă

Cercetarea pozitivistă este cunoscută și ca studiu științific sau empiric. Ea urmărește: „să explice și să prezică ce se va întâmpla în lumea socială, uitându-se la regularitățile și relațiile cauză-efect dintre elementele care o constituie” (Shanks et al 1993).

Cercetarea pozitivistă se caracterizează și prin repetabilitate, simplificări și respingeri. Mai mult, cercetările pozitiviste admit existența unor relații a priori între fenomenele studiate.
Conform lui Galliers (1992) taxonomia este o metodă de cercetare inclusă în paradigma pozitivistă, care însă nu se limitează la aceasta, de fapt există experimente de laborator, experimente de teren, studii de caz, demonstrații de teoreme, predicții și simulări. Folosind aceste metode, cercetătorii admit că fenomenele studiate pot fi observate obiectiv și riguros.

3.1.1.2 Cercetare interpretativă

Cercetarea interpretativă, care este adesea numită fenomenologie sau antipozitivism, este descrisă de Neuman (1994) ca „analiza sistematică a sensului social al acțiunii prin observarea directă și detaliată a oamenilor în situații naturale, pentru a ajunge la o înțelegere și interpretarea modului în care oamenii își creează și își mențin lumea socială”. Studiile interpretative resping presupunerea că fenomenele observate pot fi observate în mod obiectiv. De fapt, ele se bazează pe interpretări subiective. Mai mult, cercetătorii interpretativi nu impun semnificații a priori fenomenelor pe care le studiază.

Această metodă include studii subiective/argumentative, cercetare-acțiune, studii descriptive/interpretative, cercetări viitoare și jocuri de rol. În plus față de aceste anchete și studii de caz pot fi incluse în această abordare, deoarece se referă la studii ale indivizilor sau organizațiilor în situații complexe din lumea reală.

3.1.1.3 Cercetare critică

Căutarea critică este cea mai puțin cunoscută abordare din științele sociale, dar a primit recent atenția cercetătorilor din arena sistemelor informaționale. Presupunerea filozofică că realitatea socială este produsă și reprodusă istoric de oameni, precum și de sistemele sociale cu acțiunile și interacțiunile lor. Capacitatea lor este însă mediată de o serie de considerații sociale, culturale și politice.

Ca și cercetarea interpretativă, cercetarea critică susține că cercetarea pozitivistă nu are nimic de-a face cu contextul social și ignoră influența acestuia asupra acțiunilor umane.
Cercetarea critică, pe de altă parte, critică cercetarea interpretativă pentru că este prea subiectivă și pentru că nu își propune să-i ajute pe oameni să-și îmbunătățească viața. Cea mai mare diferență între cercetarea critică și celelalte două abordări este dimensiunea sa evaluativă. În timp ce obiectivitatea tradițiilor pozitiviste și interpretative este de a prezice sau explica status quo-ul sau realitatea socială, cercetarea critică își propune să evalueze critic și să transforme realitatea socială studiată.

Cercetătorii critici se opun de obicei status quo-ului pentru a elimina diferențele sociale și pentru a îmbunătăți condițiile sociale. Cercetarea critică are un angajament față de o viziune de proces a fenomenelor de interes și, prin urmare, este în mod normal longitudinală. Exemple de metode de cercetare sunt studiile istorice pe termen lung și studiile etnografice. Căutarea critică, însă, nu a fost utilizată pe scară largă în cercetarea sistemelor informaționale

3.1.2 Scopul cercetării

Împreună cu natura cercetării, scopul acesteia poate fi folosit pentru a ghida cercetătorul în selectarea unei anumite metode de cercetare. Scopul unui proiect de cercetare este strâns legat de poziția cercetării în raport cu ciclul de cercetare care constă din trei faze: construirea teoriei, testarea teoriei și perfecţionarea teoriei. Astfel, pe baza impulsului față de ciclul de cercetare, un proiect de cercetare poate avea un scop explicativ, descriptiv, explorator sau predictiv.

3.1.2.1 Cercetare exploratorie

Cercetarea exploratorie are ca scop investigarea unui subiect cu totul nou și formularea de întrebări și ipoteze pentru cercetările viitoare. Acest tip de cercetare este folosit în construirea teoriei pentru a obține referințe inițiale într-o zonă nouă. De obicei se folosesc metode de cercetare calitativă, precum studii de caz sau studii fenomenologice.

Cu toate acestea, este, de asemenea, posibil să se utilizeze tehnici cantitative, cum ar fi anchete exploratorii sau experimente.

3.1.3.3 Căutare descriptivă

Cercetarea descriptivă este concepută pentru a analiza și descrie în detaliu o anumită situație sau practică organizațională. Acest lucru este adecvat pentru construirea de teorii și poate fi folosit și pentru a confirma sau contesta ipoteze. Cercetarea descriptivă implică de obicei utilizarea măsurătorilor și a eșantioanelor. Metodele de cercetare adecvate includ anchete și analize de fond.

3.1.2.3 Cercetare explicativă

Cercetarea explicativă încearcă să explice de ce se întâmplă lucrurile. Se bazează pe fapte care au fost deja studiate și încearcă să găsească motivele acestor fapte.
Astfel, cercetarea explicativă este de obicei construită pe deasupra cercetării exploratorii sau descriptive și este auxiliară testării și rafinării teoriilor. Cercetarea explicativă utilizează de obicei studii de caz sau metode de cercetare bazate pe sondaje.

3.1.2.4 Cercetare preventivă

Cercetarea preventivă urmărește să prezică evenimentele observate și comportamentele care sunt studiate (Marshall și Rossman 1995). Predicția este testul științific standard al adevărului. Acest tip de cercetare utilizează, în general, anchete sau analize de date de date istorici. (Yin 1989)

Discuția de mai sus demonstrează că există o serie de metode de cercetare posibile care pot fi utilizate într-un anumit studiu. Cu toate acestea, trebuie să existe o metodă specifică care este mai potrivită decât celelalte pentru un anumit tip de proiect de cercetare. (Galliers 1987, Yin 1989, De Vaus 1991). Prin urmare, fiecare cercetător trebuie să evalueze cu atenție punctele forte și punctele slabe ale diferitelor metode, pentru a adopta cea mai potrivită metodă de cercetare compatibilă cu proiectul de cercetare. (Jenkins 1985, Pervan și Klass 1992, Bonomia 1985, Yin 1989, Himilton și Ives 1992).

3.2. Metode posibile de căutare

Obiectivul acestui proiect a fost de a studia experiența organizațiilor australiene cu i de date stocate cu o dezvoltare de depozit de date. Data că, în prezent, există o lipsă de cercetare în domeniul depozitării datelor în Australia, acest proiect de cercetare se află încă în faza teoretică a ciclului de cercetare și are un scop explorator. Explorarea experienței organizațiilor australiene care adoptă depozitarea de date necesită interpretarea societății reale. În consecință, ipoteza filozofică care stă la baza proiectului de cercetare urmează interpretarea tradițională.

După o examinare riguroasă a metodelor disponibile, au fost identificate două metode posibile de cercetare: anchete și studii de caz, care pot fi folosite pentru cercetări exploratorii (Shanks et al. 1993). Galliers (1992) argumentează adecvarea acestor două metode pentru acest studiu particular în taxonomia sa revizuită, spunând că ele sunt potrivite pentru construcția teoretică. Următoarele două subsecțiuni discută fiecare metodă în detaliu.

3.2.1 Metoda cercetării prin sondaj

Metoda de cercetare prin sondaj provine din metoda antică a recensământului. Un recensământ înseamnă colectarea de informații de la o întreagă populație. Această metodă este costisitoare și nepractică, mai ales dacă populația este mare. Astfel, în comparație cu un recensământ, un sondaj este de obicei axat pe colectarea de informații pentru un număr mic, sau eșantion, de reprezentanți ai populației (Fowler 1988, Neuman 1994). Un eșantion reflectă populația din care este extras, cu grade diferite de acuratețe, în funcție de structura eșantionului, dimensiunea și metoda de selecție utilizată (Fowler 1988, Babbie 1982, Neuman 1994).

Metoda anchetei este definită ca „instantanee ale practicilor, situațiilor sau punctelor de vedere la un anumit moment în timp, realizate folosind chestionare sau interviuri, din care se pot deduce concluzii.
made” (Galliers 1992:153) [fotografie instantanee a practicilor, situațiilor sau vederilor la un anumit moment în timp, luate folosind chestionare sau interviuri, din care se pot face inferențe]. Sondajele sunt preocupate de colectarea de informații despre anumite aspecte ale studiului de la un număr de participanți, punând întrebări (Fowler 1988). Aceste chestionare și interviuri, care includ interviuri telefonice față în față și interviuri structurate, sunt, de asemenea, tehnici de colectare de date utilizate în sondaje (Blalock 1970, Nachmias și Nachmias 1976, Fowler 1988), se pot folosi observații și analize (Gable 1994). Dintre toate aceste metode de colectare a zeilor de date, utilizarea chestionarului este cea mai populară tehnică, deoarece asigură că i de date

colectate sunt structurate și formatate și, astfel, facilitează clasificarea informațiilor (Hwang 1987, de Vaus 1991).

Analizând i de date, o strategie de anchetă utilizează adesea tehnici cantitative, cum ar fi analiza statistică, dar pot fi folosite și tehnici calitative (Galliers 1992, Pervan).

și Klass 1992, Gable 1994). În mod normal, i de date colectate sunt utilizate pentru a analiza distribuțiile și modelele de asocieri (Fowler 1988).

Deși sondajele sunt, în general, potrivite pentru căutările care se ocupă de întrebarea „ce?” (ce) sau derivând din el, cum ar fi „quanto” (cât) și „quant’è” (câte), ele pot fi puse prin întrebarea „de ce” (Sonquist și Dunkelberg 1977, Yin 1989). Potrivit Sonquist și Dunkelberg (1977), ancheta de cercetare vizează ipoteze dure, programe de evaluare, descrierea populației și dezvoltarea modelelor de comportament uman. Mai mult, anchetele pot fi folosite pentru a studia opinia, condițiile, credințele, caracteristicile, așteptările și chiar comportamentele trecute sau prezente ale unei anumite populații (Neuman 1994).

Sondajele permit cercetătorului să descopere relațiile populației, iar rezultatele sunt de obicei mai generale decât alte metode (Sonquist și Dunkelberg 1977, Gable 1994). Sondajele permit cercetătorilor să acopere o zonă geografică mai largă și să ajungă la un număr mare de respondenți (Blalock 1970, Sonquist și Dunkelberg 1977, Hwang și Lin 1987, Gable 1994, Neuman 1994). În cele din urmă, anchetele pot furniza informații care nu sunt disponibile în altă parte sau în forma necesară pentru analize (Fowler 1988).

Există, totuși, unele limitări în realizarea unui sondaj. Un dezavantaj este că cercetătorul nu poate obține multe informații despre obiectul studiat. Acest lucru se datorează faptului că anchetele sunt efectuate doar la un anumit moment și, prin urmare, există un număr limitat de variabile și persoane pe care cercetătorul le poate

studiu (Yin 1989, de Vaus 1991, Gable 1994, Denscombe 1998). Un alt dezavantaj este că efectuarea unui sondaj poate fi foarte costisitoare din punct de vedere al timpului și al resurselor, mai ales dacă implică interviuri față în față (Fowler 1988).

3.2.2. Metoda de cercetare prin anchetă

Metoda de cercetare prin investigare implică studiul aprofundat al unei anumite situații în contextul ei real pe o perioadă definită de timp, fără nicio intervenție din partea cercetătorului (Shanks & C. 1993, Eisenhardt 1989, Jenkins 1985). În principal, această metodă este folosită pentru a descrie relațiile dintre variabilele care sunt studiate într-o anumită situație (Galliers 1992). Investigaţiile pot implica cazuri unice sau multiple, în funcţie de fenomenul analizat (Franz şi Robey 1987, Eisenhardt 1989, Yin 1989).

Metoda cercetării prin anchetă este definită ca „o anchetă empirică care investighează un fenomen contemporan în contextul său real, folosind mai multe surse colectate din una sau mai multe entități, cum ar fi oameni, grupuri sau organizații” (Yin 1989). Nu există o separare clară între fenomen și contextul său și nu există control sau manipulare experimentală a variabilelor (Yin 1989, Benbasat et al. 1987).

Există o varietate de tehnici de colectare a zeilor de date care pot fi folosite în metoda de anchetă, care include observații directe, revizuiri de înregistrări de arhivă, chestionare, revizuire a documentației și interviuri structurate. Având o gamă variată de tehnici de recoltare de date, sondajele permit cercetătorilor să se ocupe de ambele de date calitativ și cantitativ în același timp (Bonoma 1985, Eisenhardt 1989, Yin 1989, Gable 1994). Așa cum este cazul metodei anchetei, un cercetător de anchetă servește ca observator sau cercetător și nu ca un participant activ în organizația studiată.

Benbasat și colab.(1987) afirmă că metoda investigației este deosebit de potrivită pentru construcția teoriei cercetării, care începe cu o întrebare de cercetare și continuă cu pregătirea.

a unei teorii în timpul procesului de colectare de date. Fiind potrivit și pentru scenă

de construcție a teoriei, Franz și Robey (1987) sugerează că metoda de investigare poate fi utilizată și pentru faza de teorie complexă. În acest caz, pe baza dovezilor colectate, o anumită teorie sau ipoteză este verificată sau infirmată. În plus, ancheta este potrivită și pentru cercetarea care se ocupă de întrebările „cum” sau „de ce” (Yin 1989).

În comparație cu alte metode, sondajele permit cercetătorului să capteze informații esențiale mai detaliat (Galliers 1992, Shanks et al. 1993). Mai mult, investigațiile permit cercetătorului să înțeleagă natura și complexitatea proceselor studiate (Benbasat et al. 1987).

Există patru dezavantaje principale asociate cu metoda de investigare. Prima este lipsa deducerilor controlate. Subiectivitatea cercetătorului poate altera rezultatele și concluziile studiului (Yin 1989). Al doilea dezavantaj este lipsa observării controlate. Spre deosebire de metodele experimentale, cercetătorul de anchetă nu poate controla fenomenele studiate deoarece acestea sunt examinate în contextul lor natural (Gable 1994). Al treilea dezavantaj este lipsa de replicabilitate. Acest lucru se datorează faptului că este puțin probabil ca cercetătorul să observe aceleași evenimente și nu poate verifica rezultatele unui anumit studiu (Lee 1989). În cele din urmă, ca o consecință a nereplicabilității, este dificil de generalizat rezultatele obținute din unul sau mai multe sondaje (Galliers 1992, Shanks et al. 1993). Toate aceste probleme, însă, nu sunt insurmontabile și pot fi, de fapt, minimalizate de către cercetător prin aplicarea unor acțiuni adecvate (Lee 1989).

3.3. Justificați metodologia cercetării adoptat

Dintre cele două metode de cercetare posibile pentru acest studiu, metoda sondajului este considerată a fi cea mai potrivită. Cea de anchetă a fost înlăturată în urma unei examinări atente a rudelor

merite și slăbiciuni. Comoditatea sau inadecvarea fiecărei metode pentru acest studiu este discutată mai jos.

3.3.1. Metodă de cercetare inadecvată de anchetă

Metoda de investigare necesită studiul aprofundat al unei anumite situații în cadrul uneia sau mai multor organizații pe o perioadă de timp (Eisenhardt 1989). În acest caz, perioada poate depăși intervalul de timp prevăzut pentru acest studiu. Un alt motiv pentru a nu adopta metoda de investigare este că rezultatele pot suferi de lipsa de rigoare (Yin 1989). Subiectivitatea cercetătorului poate influența rezultatele și concluziile. Un alt motiv este că această metodă este mai potrivită pentru întrebările de cercetare de tipul „cum” sau „de ce” (Yin 1989), în timp ce întrebarea de cercetare pentru acest studiu este de tipul „ce”. Nu în ultimul rând, este dificil de generalizat constatările dintr-un singur studiu sau din câteva sondaje (Galliers 1992, Shanks et al. 1993). Pe baza acestui raționament, metoda de cercetare prin sondaj nu a fost aleasă deoarece nu era adecvată pentru acest studiu.

3.3.2. Comoditatea metodei de căutare a anchetă

Când a fost efectuată această cercetare, practica de depozitare a datelor nu a fost adoptată pe scară largă de către organizațiile australiene. Prin urmare, nu au existat prea multe informații cu privire la implementarea lor în cadrul organizațiilor australiene. Informațiile disponibile au provenit de la organizații care au implementat sau utilizat a depozit de date. În acest caz, metoda de cercetare prin sondaj este cea mai potrivită deoarece permite obținerea de informații care nu sunt disponibile în altă parte sau în forma necesară analizei (Fowler 1988). În plus, metoda de cercetare prin investigare permite cercetătorului să obțină o bună perspectivă asupra practicilor, situațiilor sau opiniilor la un moment dat (Galliers 1992, Denscombe 1998). A fost solicitată o prezentare generală pentru a crește gradul de conștientizare a experienței de depozitare a datelor din Australia.

Mai mult, Sonquist și Dunkelberg (1977) afirmă că rezultatele cercetării prin sondaj sunt mai generale decât alte metode.

3.4. Proiectarea cercetării sondajului

Sondajul privind practicile de depozitare a datelor a fost realizat în 1999. Populația țintă era formată din organizații australiene interesate de studii privind depozitarea datelor, deoarece probabil că erau deja conștienți de de date pe care le stochează și, prin urmare, ar putea oferi informații utile pentru acest studiu. Populația țintă a fost identificată printr-un sondaj inițial al tuturor membrilor australieni ai „Institutului de depozitare de date” (Tdwi-aap). Această secțiune discută despre proiectarea fazei de cercetare empirică a acestui studiu.

3.4.1. Tehnica de colectare de date

Dintre cele trei tehnici utilizate în mod obișnuit în cercetarea prin sondaj (adică chestionar prin poștă, interviu telefonic și interviu personal) (Nachmias 1976, Fowler 1988, de Vaus 1991), chestionarul prin poștă a fost adoptat pentru acest studiu. Primul motiv pentru adoptarea acestuia din urmă este că poate ajunge la o populație dispersată geografic (Blalock 1970, Nachmias și Nachmias 1976, Hwang și Lin 1987, de Vaus 1991, Gable 1994). În al doilea rând, chestionarul prin poștă este potrivit pentru participanții cu studii superioare (Fowler 1988). Chestionarul prin poștă pentru acest studiu a fost adresat sponsorilor de proiect de depozitare de date, directorilor și/sau managerilor de proiect. În al treilea rând, chestionarele poștale sunt adecvate atunci când este disponibilă o listă sigură de adrese (Salant și Dilman 1994). TDWI, în acest caz, o asociație de încredere pentru depozitarea datelor a furnizat lista de corespondență a membrilor săi australieni. Un alt avantaj al chestionarului prin poștă față de chestionarele telefonice sau interviurile personale este că le permite respondenților să răspundă mai precis, în special atunci când respondenții trebuie să consulte înregistrările sau să discute întrebări cu alte persoane (Fowler 1988).

Un potențial dezavantaj poate fi timpul necesar pentru a efectua chestionare prin poștă. În mod normal, un chestionar prin e-mail este condus în această secvență: trimite scrisori, așteptați răspunsuri și trimiteți confirmarea (Fowler 1988, Bainbridge 1989). Astfel, timpul total poate fi mai mare decât timpul necesar pentru interviurile față în față sau interviurile telefonice. Cu toate acestea, timpul total poate fi cunoscut în avans (Fowler 1988, Denscombe 1998). Timpul petrecut pentru realizarea interviurilor personale nu poate fi cunoscut în avans, deoarece variază de la interviu la interviu (Fowler 1988). Interviurile telefonice pot fi mai rapide decât chestionarele prin poștă și interviurile personale, dar pot avea o rată mare de fără răspuns din cauza indisponibilității unor persoane (Fowler 1988). În plus, interviurile telefonice sunt în general limitate la liste relativ scurte de întrebări (Bainbridge 1989).

Un alt punct slab al unui chestionar trimis este rata mare de non-răspuns (Fowler 1988, Bainbridge 1989, Neuman 1994). Cu toate acestea, s-au luat măsuri de contracarare prin asocierea acestui studiu cu o instituție de depozitare de date de încredere (adică TDWI) (Bainbridge 1989, Neuman 1994), care emite două scrisori de reamintire pentru cei care nu răspund (Fowler 1988, Neuman 1994) și include, de asemenea, o scrisoare suplimentară de explicație. scopul studiului (Neuman 1994).

3.4.2. Unitatea de analiză

Scopul acestui studiu este de a obține informații despre implementarea depozitării de date și utilizarea acestuia în cadrul organizațiilor australiene. Populația țintă este toate organizațiile australiene care au implementat sau implementează: i depozit de date. Organizațiile individuale sunt apoi înregistrate. Chestionarul a fost trimis prin poștă organizațiilor interesate să adopte depozit de date. Această metodă asigură că informațiile colectate provin de la cele mai potrivite resurse ale fiecărei organizații participante.

3.4.3. Eșantion de sondaj

Lista de corespondență a participanților la sondaj a fost obținută de la TDWI. Din această listă, 3000 de organizații australiene au fost selectate ca bază pentru eșantionare. Eșantionului au fost trimise o scrisoare de continuare în care se explică proiectul și scopul sondajului, împreună cu un formular de răspuns și un plic preplătit pentru returnarea chestionarului completat. Din cele 3000 de organizații, 198 au fost de acord să participe la studiu. Era de așteptat un număr atât de mic de răspunsuri Dato numărul mare de organizații australiene care apoi îmbrățișaseră sau adoptaseră strategia de depozitare a datelor în cadrul organizațiilor lor. Astfel, populația țintă pentru acest studiu este formată din doar 198 de organizații.

3.4.4. Conținutul chestionarului

Proiectarea chestionarului sa bazat pe modelul de depozitare a datelor Monash (discutat mai devreme în partea 2.3). Conținutul chestionarului sa bazat pe analiza literaturii de specialitate prezentată în capitolul 2. O copie a chestionarului trimisă participanților la sondaj poate fi găsită în Anexa B. Chestionarul este compus din șase secțiuni, care urmează pașii modelului acoperit. Următoarele șase paragrafe rezumă pe scurt conținutul fiecărei secțiuni.

Secțiunea A: Informații de bază despre organizație
Această secțiune conține întrebări referitoare la profilul organizațiilor participante. În plus, unele dintre întrebări se referă la stadiul proiectului de depozitare de date al participantului. Informațiile confidențiale, cum ar fi numele organizației, nu au fost dezvăluite în analiza sondajului.

Secțiunea B: Începe
Întrebările din această secțiune sunt legate de începerea stocării de date. Au fost puse întrebări cu privire la inițiatorii proiectului, sponsorii, abilitățile și cunoștințele necesare, obiectivele dezvoltării depozitării de date și așteptările utilizatorilor finali.

Secțiunea C: Proiectare
Această secțiune conține întrebări legate de activitățile de planificare ale depozit de date. În special, întrebările au fost legate de domeniul de aplicare, durata proiectului, costul proiectului și analiza cost/beneficiu.

Secțiunea D: Dezvoltare
În secțiunea de dezvoltare există întrebări legate de activitățile de dezvoltare ale depozit de date: colecție de cerințe ale utilizatorului final, surse de de date, modelul logic al de date, prototipuri, planificare a capacității, arhitecturi tehnice și selecție de instrumente de dezvoltare pentru depozitarea datelor.

Secțiunea E: Funcționare
Întrebări operaționale legate de funcționarea și extensibilitatea depozit de date, pe măsură ce evoluează în următoarea etapă de dezvoltare. Acolo calitatea datelor, strategiile de reîmprospătare ale de date, granularitatea de date, scalabilitate a depozit de date și probleme de securitate depozit de date au fost printre tipurile de întrebări puse.

Secțiunea F: Dezvoltare
Această secțiune conține întrebări legate de utilizarea depozit de date de către utilizatorii finali. Cercetătorul a fost interesat de scopul și utilitatea depozit de date, strategiile de revizuire și formare adoptate și strategia de control a depozit de date adoptat.

3.4.5. Rata de raspuns

Chiar dacă sondajele prin poștă sunt criticate pentru că au o rată scăzută de răspuns, s-au luat măsuri pentru a crește rata rentabilității (după cum sa discutat mai sus în secțiunea 3.4.1). Termenul „rata de răspuns” se referă la procentul de persoane dintr-un anumit eșantion de sondaj care răspund la chestionar (Denscombe 1998). Următoarea formulă a fost utilizată pentru a calcula rata de răspuns pentru acest studiu:

Numărul de persoane care au răspuns
Rata de răspuns = —————————————————————————– X 100 Numărul total de chestionare trimise

3.4.6. Pilot de testare

Înainte ca chestionarul să fie trimis eșantionului, întrebările au fost testate prin efectuarea de teste pilot, așa cum au sugerat Luck și Rubin (1987), Jackson (1988) și de Vaus (1991). Scopul testelor pilot este de a dezvălui orice expresii incomode, ambigue și întrebări greu de interpretat, de a clarifica orice definiții și termeni folosiți și de a identifica timpul aproximativ necesar pentru completarea chestionarului (Warwick și Lininger 1975, Jackson 1988, Salant). și Dilman 1994). Testele pilot au fost efectuate prin selectarea subiecților cu caracteristici similare cu cele ale subiecților finali, așa cum a sugerat Davis e Cosenza (1993). În acest studiu, șase profesioniști în depozitarea datelor au fost selectați ca subiecți pilot. După fiecare test pilot s-au făcut corecțiile necesare. Din testele pilot efectuate, participanții au contribuit la remodelarea și resetarea versiunii finale a chestionarului.

3.4.7. Metode de analiză a DATI

I de date Datele sondajului colectate din chestionarele închise au fost analizate folosind un pachet software statistic numit SPSS. Multe dintre răspunsuri au fost analizate folosind statistici descriptive. Un număr de chestionare au fost returnate incomplete. Acestea au fost tratate cu mai multă atenție pentru a ne asigura că i de date lipsa nu a fost o consecință a erorilor de introducere a datelor, ci pentru că întrebările nu erau potrivite pentru solicitantul înregistrării sau pentru că solicitantul înregistrării a decis să nu răspundă la una sau mai multe întrebări specifice. Aceste răspunsuri lipsă au fost ignorate la analizarea datelor de date și au fost codificate ca „-9” pentru a asigura excluderea lor din procesul de analiză.

La pregătirea chestionarului, întrebările închise au fost precodificate prin atribuirea unui număr fiecărei opțiuni. Numărul a fost apoi folosit pentru a antrena i de date în timpul analizei (Denscombe 1998, Sapsford și Jupp 1996). De exemplu, au fost enumerate șase opțiuni la întrebarea 1 a secțiunii B: consiliu de administrație, director executiv, departament IT, unitate de afaceri, consultanți și altele. În dosarul lui de date din SPSS, a fost generată o variabilă pentru „inițiatorul de proiect”, cu șase etichete de valoare: „1” pentru „board”, „2” pentru „senior executive” și așa mai departe. Utilizarea scalei Likertin în unele dintre întrebările închise a permis, de asemenea, identificarea fără efort prin utilizarea valorilor numerice corespunzătoare introduse în SPSS. Pentru întrebările cu răspunsuri neexhaustive, care nu se excludeau reciproc, fiecare opțiune a fost tratată ca o singură variabilă cu două etichete de valoare: „1” pentru „verificat” și „2” pentru „nebifat”.

Întrebările deschise au fost tratate diferit de întrebările închise. Răspunsurile la aceste întrebări nu au fost introduse în SPSS. În schimb, au fost analizate manual. Utilizarea acestui tip de întrebare permite obținerea de informații despre ideile liber exprimate și experiențele personale la respondenți (Bainbridge 1989, Denscombe 1998). Acolo unde a fost posibil, a fost făcută o clasificare a răspunsurilor.

Pentru analiza de datesunt utilizate metode de analiză statistică simplă, cum ar fi frecvența răspunsurilor, media, abaterea standard și mediana (Argyrous 1996, Denscombe 1998).
Testul Gamma a fost performant pentru obținerea de măsuri cantitative ale asociilor dintre de date ordinale (Norusis 1983, Argyrous 1996). Aceste teste au fost adecvate deoarece scalele ordinale utilizate nu aveau multe categorii și puteau fi prezentate într-un tabel (Norusis 1983).

3.5 Rezumat

În acest capitol au fost discutate metodologia de cercetare și designul adoptat pentru acest studiu.

Selectarea celei mai potrivite metode de cercetare pentru un anumit studiu necesită
luarea în considerare a unui număr de reguli, inclusiv natura și tipul cercetării, precum și meritele și punctele slabe ale fiecărei metode posibile (Jenkins 1985, Benbasat et al. 1097, Galliers and Land 1987, yin 1989, Hamilton and ives 1992, Galliers 1992, neuman 1994). Având în vedere lipsa cunoștințelor și teoriei existente cu privire la adoptarea depozitării de date în Australia, acest studiu de cercetare solicită o metodă de cercetare interpretativă cu o capacitate de explorare de a explora experiențele organizațiilor australiene. Metoda de cercetare aleasă a fost selectată pentru a culege informații cu privire la adoptarea conceptului de depozitare de date de către organizațiile australiene. Ca tehnică de colectare a fost ales un chestionar poștal de date. Justificări pentru metoda de cercetare și tehnica de colectare de date selecțiile vor fi furnizate în acest capitol. De asemenea, a fost prezentată o discuție pe tema unității de analiză, eșantionul utilizat, procentele răspunsurilor, conținutul chestionarului, pretestarea chestionarului și metoda de analiză a de date.

Proiectarea unui Depozitul de date:

Combinând relațiile dintre entități și modelarea dimensională

REZUMAT
Magazin i de date este o problemă actuală majoră pentru multe organizații. O problemă cheie în dezvoltarea depozitării de date este designul lui.
Desenul trebuie să sprijine detectarea conceptelor în depozit de date la sistemul moștenit și alte surse de de date precum și o înțelegere ușoară și eficiență în implementarea depozit de date.
O mare parte din literatura de specialitate despre stocarea de date recomandă utilizarea modelării relațiilor de entitate sau a modelării dimensionale pentru a reprezenta proiectarea depozit de date.
În această lucrare arătăm cum ambele reprezentări pot fi combinate într-o abordare a proiectării depozit de date. Abordarea folosită este sistematică

examinat într-un studiu de caz și este identificat într-o serie de implicații importante cu profesioniști.

DEPOZITARE DE DATE

Un depozit de date este de obicei definită ca o „colecție de date orientată pe subiect, integrată, variabilă în timp și nevolatilă în sprijinul deciziilor managementului” (Inmon și Hackathorn, 1994). Orientat pe subiect și integrat indică faptul că depozit de date este conceput pentru a depăși granițele funcționale ale sistemelor moștenite pentru a oferi o perspectivă integrată a de date.
Varianta temporală se preocupă de natura istorică sau de serie temporală a videoclipurilor de date în a depozit de date, care permite analizarea tendințelor. Nevolatil indică faptul că depozit de date nu este actualizat continuu ca a Baza de date de OLTP. Mai degrabă este actualizat periodic, cu de date din surse interne și externe. The depozit de date este conceput special pentru cercetare, mai degrabă decât pentru a actualiza integritatea și performanța operațională.
Ideea de a stoca i de date nu este nou, a fost unul dintre scopurile managementului de date din anii şaizeci (Il Martin, 1982).
I depozit de date oferă infrastructura de date pentru sistemele de suport pentru management. Sistemele de suport pentru management includ sisteme de sprijin pentru decizii (DSS) și sisteme de informații executive (EIS). Un DSS este un sistem informatic bazat pe computer care este conceput pentru a îmbunătăți procesul și, în consecință, luarea deciziilor umane. Un EIS este de obicei un sistem de livrare de date care le permite directorilor de afaceri să acceseze cu ușurință vizualizarea de date.
Arhitectura generală a a depozit de date evidenţiază rolul de depozit de date în sprijinul managementului. Pe lângă oferirea infrastructurii de date pentru EIS și DSS, al depozit de date poate fi accesat direct prin interogări. THE de date incluse într-un depozit de date se bazează pe o analiză a cerințelor de informații de management și sunt obținute din trei surse: sistemele moștenite interne, sistemele de captare a datelor cu scop special și surse externe de date. THE de date în sistemele moștenite interne, acestea sunt adesea redundante, inconsecvente, de calitate scăzută și stocate în formate diferite, așa că trebuie reconciliate și curățate înainte de a putea fi încărcate în

depozit de date (Inmon, 1992; McFadden, 1996). THE de date din sistemele de stocare de date ad-hoc și din surse de date externe sunt adesea folosite pentru a mări (actualiza, înlocui) i de date din sistemele moștenite.

Există multe motive convingătoare pentru a dezvolta a depozit de date, care includ îmbunătățirea procesului de luare a deciziilor prin utilizarea eficientă a mai multor informații (Ives 1995), sprijin pentru concentrarea asupra afacerilor întregi (Graham 1996) și reducerea costurilor de luare a deciziilor de date pentru EIS și DSS (Graham 1996, McFadden 1996).

Un studiu empiric recent a constatat, în medie, o rentabilitate a investiției pentru i depozit de date cu 401% după trei ani (Graham, 1996). Cu toate acestea, celelalte studii empirice ale depozit de date au găsit probleme semnificative, inclusiv dificultăți în măsurarea și alocarea beneficiilor, lipsa unui scop clar, subestimarea sferei și complexității procesului de stocare de date, în special în ceea ce privește sursele și curățenia din de date. Magazin i de date poate fi considerată o soluţie la problema managementului de date intre organizatii. Manipularea de date ca resursă socială a rămas una dintre problemele cheie în managementul sistemelor informaționale la nivel mondial timp de mulți ani (Brancheau et al. 1996, Galliers et al. 1994, Niederman et al. 1990, Pervan 1993).

O abordare populară a managementului activelor de date în anii optzeci a fost dezvoltarea unui model de date social. Model de date social a fost conceput pentru a oferi o bază stabilă pentru dezvoltarea de noi sisteme de aplicații e Baza de date și reconstrucția și integrarea sistemelor moștenite (Brancheau et al.

1989, Goodhue şi colab. 1988:1992, Kim și Everest 1994). Cu toate acestea, există mai multe probleme cu această abordare, în special, complexitatea și costul fiecărei sarcini și timpul îndelungat necesar pentru a obține rezultate tangibile (Beynon-Davies 1994, Earl 1993, Goodhue și colab. 1992, Periasamy 1994, Shanks 1997). ).

Il depozit de date este o bază de date separată care coexistă cu bazele de date vechi, mai degrabă decât să le înlocuiască. Prin urmare, vă permite să direcționați managementul de date și evita reconstrucția costisitoare a sistemelor vechi.

ABORDĂRI EXISTENTE PRIVIND PROIECTAREA DATELOR

DEPOZIT

Procesul de construire și perfecționare a depozit de date ar trebui înțeles mai degrabă ca un proces evolutiv decât ca un ciclu de viață de dezvoltare a sistemelor tradiționale (Desio, 1995, Shanks, O'Donnell și Arnott 1997a). Există multe procese implicate într-un proiect depozit de date cum ar fi inițializarea, programarea; informatii obtinute din cerintele solicitate de la managerii companiei; surse, transformări, curățare de de date și sincronizați din sistemele vechi și alte surse de date; sisteme de livrare în curs de dezvoltare; monitorizarea depozit de date; și lipsa de sens a procesului evolutiv și a construirii a depozit de date (Stinchi, O'Donnell și Arnott 1997b). În acest jurnal, ne concentrăm pe cum să desenăm i de date stocate în contextul acestor alte procese. Există o serie de abordări propuse pentru arhitectura video depozit de date în literatură (Inmon 1994, Ives 1995, Kimball 1994 McFadden 1996). Fiecare dintre aceste metodologii are o scurtă trecere în revistă cu o analiză a punctelor forte și a punctelor slabe.

Abordarea lui Inmon (1994) pentru Depozitul de date Amenajări

Inmon (1994) a propus patru pași iterativi pentru proiectarea a depozit de date (vezi Figura 2). Primul pas este proiectarea unui șablon de date social pentru a înțelege cum i de date poate fi integrat în zonele funcționale din cadrul unei organizații prin subdiviziunea i de date depozitați în zone. Model de date este facut pentru depozitare de date referitoare la luarea deciziilor, inclusiv de date istorice și incluse de date deduse și agregate. Al doilea pas este identificarea domeniilor de implementare. Acestea se bazează pe priorități determinate de o anumită organizație. Al treilea pas implică desenarea a Baza de date pentru domeniul subiectului, acordați o atenție deosebită includerii nivelurilor adecvate de granularitate. Inmon recomandă utilizarea modelului de entitate și relație. Al patrulea pas este identificarea sistemelor sursă de date necesare și dezvolta procese de transformare pentru a captura, curăța și formata i de date.

Punctele forte ale abordării lui Inmon sunt că modelul de date social oferă baza pentru integrarea de date in cadrul organizarii si planificarii suporturilor pentru dezvoltarea iterativa a depozit de date. Dezavantajele sale sunt dificultatea și costul proiectării modelului de date sociale, dificultatea de a înțelege modelele de entități și relații utilizate în ambele modele, că de date socială şi cea a de date stocate în funcție de domeniu și caracterul adecvat al de date a desenului de depozit de date pentru realizarea de Baza de date relaţional dar nu pentru Baza de date multidimensională.

Abordarea lui Ives (1995). Depozitul de date Amenajări

Ives (1995) propune o abordare în patru pași pentru proiectarea unui sistem informațional despre care consideră că este aplicabil la proiectarea unui depozit de date (vezi Figura 3). Abordarea se bazează în mare măsură pe Ingineria Informației pentru dezvoltarea sistemelor informaționale (Martin 1990). Primul pas este să vă determinați obiectivele, succesul și factorii critici, precum și indicatorii cheie de performanță. Procesele cheie de afaceri și informațiile necesare sunt modelate pentru a ne conduce la un model de date social. Al doilea pas implică dezvoltarea unei arhitecturi definitorii de date stocat pe zonă, Baza de date di depozit de date, componentele tehnologice care sunt necesare, setul de suport organizațional necesar pentru implementare și operare cu depozit de date. Al treilea pas include selectarea pachetelor software și instrumentelor necesare. Al patrulea pas este proiectarea detaliată și construcția depozit de date. Ives notează acel magazin de date este un proces iterativ constrâns.

Punctele forte ale abordării Ives sunt utilizarea specificațiilor tehnice pentru a determina cerințele de informații, utilizarea unui proces structurat pentru a sprijini integrarea depozit de date, selecția corespunzătoare a hardware-ului și software-ului și utilizarea tehnicilor de reprezentare multiple pentru depozit de date. Defectele sale sunt inerente complexității. Altele includ dificultatea de a dezvolta multe niveluri de Baza de date în interiorul del depozit de date într-un timp și un cost rezonabil.

Abordarea lui Kimball (1994). Depozitul de date Amenajări

Kimball (1994) a propus cinci pași iterativi pentru proiectarea a depozit de date (vezi figurile 4). Abordarea sa este dedicată în special desenului unui solo depozit de date și asupra utilizării modelelor dimensionale în detrimentul modelelor de entități și relații. Kimball analizează acele modele dimensionale deoarece este mai ușor pentru liderii de afaceri să înțeleagă afacerile, este mai eficient atunci când se ocupă de consultări complexe și proiectarea Baza de date fizica este mai eficientă (Kimball 1994). Kimball recunoaște că dezvoltarea a depozit de date este iterativă și asta depozit de date separate pot fi integrate prin împărțirea în tabele de dimensiuni comune.

Primul pas este identificarea domeniului specific care trebuie perfecționat. Al doilea și al treilea pas implică modelarea dimensională. În al doilea pas, măsurile identifică lucrurile de interes din domeniul subiectului și le grupează într-un tabel de fapte. De exemplu, într-un domeniu al vânzărilor, măsurile de interes pot include cantitatea de articole vândute și dolarul ca monedă de vânzare. Al treilea pas implică identificarea dimensiunilor care sunt modalitățile prin care faptele pot fi grupate. Într-un domeniu de vânzări, dimensiunile relevante pot include articolul, locația și perioada de timp. Tabelul de fapte are o cheie cu mai multe părți pentru a-l lega la fiecare dintre tabelele de dimensiuni și de obicei conține un număr foarte mare de fapte. În schimb, tabelele de dimensiuni conțin informații descriptive despre dimensiuni și alte atribute care pot fi folosite pentru a grupa faptele. Tabelul de fapte și dimensiuni asociate propus formează ceea ce se numește o schemă stea datorită formei sale. Al patrulea pas implică construirea unui Baza de date multidimensională pentru a perfecționa modelul stelei. Pasul final este identificarea sistemelor sursă de date necesare și dezvolta procese de transformare pentru a captura, curăța și formata i de date.

Punctele forte ale abordării lui Kimball includ utilizarea modelelor dimensionale pentru a reprezenta i de date stocate ceea ce îl face ușor de înțeles și duce la un design fizic eficient. Un model dimensional care folosește cu ușurință ambele sisteme Baza de date relaționale pot fi perfecționate sau sisteme Baza de date multidimensionale. Defectele sale includ lipsa unor tehnici care să faciliteze planificarea sau integrarea multor scheme stelare în cadrul unui depozit de date și dificultatea de a proiecta din structura denormalizată extremă într-un model dimensional a de date în sistemele moștenite.

Abordarea datelor a lui McFadden (1996). Proiectare Depozit

McFadden (1996) propune o abordare în cinci etape a desenului a depozit de date (vezi Figura 5).
Abordarea sa se bazează pe o sinteză de idei din literatură și se concentrează pe designul unui singur depozit de date. Primul pas implică o analiză a cerințelor. Deși specificațiile tehnice nu sunt prescrise, notele lui McFadden identifică entitățile de date specificațiile și atributele acestora și se referă la cititorii Watson și Frolick (1993) pentru a surprinde cerințele.
În a doua etapă, este trasat un model de relație cu entitate depozit de date și apoi validate de directorii companiei. Al treilea pas implică determinarea cartografierii din sistemele moștenite și sursele externe ale depozit de date. Al patrulea pas implică procese de dezvoltare, implementare și sincronizare de date în depozit de date. În pasul final, livrarea sistemului este dezvoltată cu accent pe o interfață cu utilizatorul. McFadden observă că procesul de desenare este în general iterativ.

Punctele forte ale abordării lui McFadden sunt implicarea liderilor de afaceri în determinarea cerințelor, precum și importanța resurselor. de datecurăţarea şi colectarea acestora. Defectele sale sunt lipsa unui proces de împărțire a unui proiect mare depozit de date în multe etape integrate și acolo

dificultăți de înțelegere a modelelor de entități și relații utilizate la proiectarea depozit de date.

Nu doar cei care sunt aproape de noi ne aleg.