Compararea metodologii de proiectare depozit de date pentru Microsoft SQL Server

de: Arshad Ali | actualizat: 2013-06-24 | Comentarii (9) | Related: > analiza servicii de dezvoltare

problema

în ultimele mele câteva sfaturi, am vorbit despre importanța unei soluții de Business Intelligence, de ce devine forexecutives prioritate, ceea ce un arhitectura sistemului de informații de afaceri Arată etc. În acest sfat, voi vorbi în detaliudespre modul în care un depozit de date este diferit de stocarea datelor operaționale și de diferitele metodologii de proiectare pentru un depozit de date.

soluție

acest sfat va acoperi depozitele de date (DW, uneori numit și un depozit de date pentru întreprinderi sau EDW), modul în care diferă de stocarea de date operaționale (ODS) și diferite metodologii de proiectare a depozitului de date.

Enterprise Data Warehouse (EDW sau DW) Vs. Magazin de date operaționale (ODS)

scopul depozitului de date în arhitectura generală de Business Intelligence este de a integra date corporative din diferite surse de date eterogene pentru a facilita raportarea analizei istorice și a tendințelor. Acesta acționează ca un depozit central și conține „versiunea unică a adevărului” pentru organizația care a fost construită cu atenție din datele stocate în baze de date operaționale interne și externe disparate\sisteme. Pentru o performanță mai bună, cea mai mare parte a datelor din depozitul de date vor fi în formă de-normalizată, care poate fi clasificată fie în schemele star sau snowflake (mai multe despre acest lucru în următorul sfat).

scopul stocării datelor operaționale (ODS) este de a integra date corporative din diferite surse de date eterogene pentru a facilita raportarea operațională în timp real sau aproape în timp real. Adesea, datele din ODS vor fi structurate similar cu sistemele sursă, deși în timpul integrării pot implica curățarea datelor, de-duplicarea și pot aplica reguli de afaceri pentru a asigura integritatea datelor. Un ODS este destinat în principal să integreze date destul de frecvent la cel mai scăzut nivel granular pentru raportarea operațională într-un scenariu de integrare a datelor în timp real. În mod normal,un ODS nu va fi optimizat pentru analiza istorică și tendință pe set imens de date.

să rezumăm diferențele dintre un ODS și DW:

• un ODS este destinat raportării operaționale și acceptă cerințe de raportare curente sau aproape în timp real, în timp ce DW este destinat analizei istorice și tendințelor raportarea unui volum mare de date
• un ODS este destinat interogărilor granulare scăzute, în timp ce un DW este utilizat pentru interogări complexe împotriva sumar-level sau asupra datelor agregate
• un ODS oferă informații pentru decizii operaționale, tactice cu privire la whereasa DW oferă feedback pentru deciziile strategice care conduc la îmbunătățiri globale ale sistemului
• într-un ODS frecvența încărcării datelor ar putea fi orară sau zilnică, în timp ce într-un Dwfrecvența încărcărilor de date ar putea fi zilnică, săptămânală, lunară sau trimestrială

metodologii de proiectare a depozitului de date

există două metodologii diferite urmate în mod normal la proiectarea unei soluții de depozit de date și pe baza cerințelor proiectului dvs. puteți alege care se potrivește scenariului dvs. particular. Aceste metodologii suntrezultatul cercetărilor de la BillInmon și Ralph Kimball.

Bill Inmon-abordarea de proiectare a depozitului de date de sus în jos

Bill Inmon este uneori denumit și „părintele depozitării datelor”; metodologia sa de proiectare se bazează pe o abordare de sus în jos și definește depozitul de date în acești Termeni

• orientat spre subiect-datele dintr – un depozit de date sunt clasificate pe baza zonei subiectului și, prin urmare, sunt „orientate spre subiect”.
• integrat – datele sunt integrate din diferite surse de date disparate și, prin urmare, convenții universale de denumire, măsurători, clasificări și așa mai departe utilizate în depozitul de date. Depozitul de date oferă o viziune consolidată a datelor și, prin urmare, este desemnat Aso soluție integrată.
• Non-volatile – odată ce datele sunt integrate\încărcate în depozitul de date, acestea pot fi citite numai. Utilizatorii nu pot face modificări ale datelor și acest lucrupractica face ca datele să nu fie volatile.
• varianta de timp-în cele din urmă, datele sunt stocate pentru perioade lungi de timp cuantificate în ani și au o dată și o marcă de timp și, prin urmare, sunt descrise ca „variantă de timp”.

Bill Inmon a văzut nevoia de a integra date din diferite sisteme OLTP într-un depozit centralizat (numit depozit de date) cu așa-numita abordare de sus în jos. Bill Inmon prevede un depozit de date în centrul „fabricii de informații corporative” (CIF), care oferă un cadru logic pentru furnizarea de informații de afaceri (BI), analize de afaceri și capabilități de gestionare a afacerilor.

acest design de sus în jos oferă o vedere dimensională extrem de consistentă a datelor din marturile de date, deoarece toate marturile de date sunt încărcate din depozitul centralizat (depozitul de date).Designul de sus în jos s-a dovedit, de asemenea, flexibil pentru a sprijini schimbările de afaceri, deoarece arată la organizație în ansamblu, nu la fiecare funcție sau proces de afaceri al organizației. Generarea unui nou marts de date dimensionale împotriva datelor stocate înmagazinul de date este o sarcină relativ simplă. Deși există unele provocări pentru abordarea de sus în jos, de exemplu, aceasta reprezintă un proiect foarte mare, cu un domeniu de aplicare foarte larg și, prin urmare, costul inițial pentru implementarea unui depozit de date utilizând metodologia de sus în jos este semnificativ.Mai mult, durata de timp de la începutul proiectului până la punctul în care utilizatorii finali încep să experimenteze beneficiile inițiale ale soluției poate fi substanțială. De asemenea, metodologia de sus în jos poate fi inflexibilă și nu răspunde la nevoile în schimbare ale departamentelor sau ale proceselor de afaceri (o preocupare pentru mediul în schimbare dinamică de astăzi) în timpul fazei de implementare.

Ralph Kimball – abordare de proiectare a depozitului de date de Jos în sus

Ralph Kimball este un autor renumit pe tema depozitării datelor. Metodologia sa de proiectare se numește modelare dimensională saumetodologia Kimball. Această metodologie se concentrează pe o abordare de jos în sus, subliniind valoarea depozitului de date pentru utilizatori cât mai repede posibil. În viziunea sa, un depozit de date este copia datelor tranzacționale structurate special pentru interogarea și raportarea analitică pentru a susținesistemul de suport decizional. Conform metodologiei sale, data marts sunt create mai întâi pentru a oferi capabilități de raportare și analiză pentru procesele funcționale specifice afacerii și mai târziu aceste data marts pot fi în cele din urmă Unite împreună pentru a crea un depozit de date cuprinzător al întreprinderii. Abordarea de jos în sus se concentrează pe fiecare proces de afaceri la un moment dat, astfel încât randamentul investiției ar putea fi la fel de rapid ca primul data mart este creat. Deși, dacă nu este planificat cu atenție, s-ar putea să vă lipsească imaginea de ansamblu a depozitului de date al întreprinderii prin lipsa unor dimensiuni sau prin crearea unor dimensiuni redundante etc. când sunteți prea concentrat pe un proces individual de afaceri.

abordarea de Jos în sus a lui Ralph Kimball propune crearea unei matrice de afaceri care să conțină toate elementele comune (care sunt utilizate de data marts, cum ar fi dimensiunea conformată, măsurile etc.) definit pentru întreaga întreprindere. Cu aceasta, utilizatorul poate proiecta și dezvolta soluții care acceptă efectuarea de analize în procesele de afaceri pentru vânzarea încrucișată. Puteți afla mai multe desprematrix aici.

pentru o persoană care dorește să facă o carieră în domeniul Data Warehouse și Business Intelligence, aș recomanda studierea cărților lui Bill Inmon (Building the Data Warehouse și DW 2.0: The Architecture for the Next Generation of Data Warehousing) și Cartea lui Ralph Kimball (Microsoft Data Warehouse Toolkit).

pașii următori

• Recenziemicrosoft SQL Server Business Intelligence – ce, de ce și cum – Partea 1.
• Recenziemicrosoft SQL Server Business Intelligence arhitectura sistemului – Partea 2.
• consultați toatesql Server Business Intelligence sfaturi despre MSSQLTips.com.

Ultima actualizare: 2013-06-24

despre autor

Arshad Ali este un dezvoltator SQL și BI concentrându-se pe proiecte de depozitare a datelor pentru Microsoft.
Vezi toate sfaturile mele

Resurse conexe

• mai multe sfaturi de Business Intelligence…