Av: Arshad Ali | Oppdatert: 2013-06-24 | Kommentarer (9) | Relatert: > Analysis Services Development
Problem
i mine siste par tips snakket jeg om viktigheten Av En Business Intelligence-løsning, hvorfor det blir prioritert forexecutives, hva en typisk Business Intelligence Systemarkitektur Ser Ut, ETC. I dette tipset skal jeg snakke i detalj om hvordan et datalager er forskjellig fra operasjonell datalager og de forskjellige designmetodene for et datalager.
Løsning
dette tipset skal dekke Datavarehus (DW, en gang også kalt Et Bedriftsdatalager ELLER EDW), hvordan det skiller Seg fra Operational Data Store (ODS) og forskjellige Datavarehus designmetoder.
Enterprise Datalager (EDW eller DW) Vs. Operational Data Store (ODS)
Formålet Med Datalageret i Den overordnede Business Intelligence-Arkitekturen er å integrere bedriftsdata fra ulike heterogene datakilder for å legge til rette for historisk og trendanalyserapportering. Det fungerer som et sentralt lager og inneholder» single version of truth » for organisasjonen som er nøye konstruert fra data lagret i ulike interne og eksterne operative databaser\systemer. For bedre ytelse, for det meste data i datalager vil være i de-normalisert form som kan kategoriseres i enten stjerne eller snøfnugg skjemaer (mer om dette i neste tips).
Formålet Med Operation Data Store (ODS) er å integrere bedriftsdata fra ulike heterogene datakilder for å legge til rette for operativ rapportering i sanntid eller nær sanntid. Ofte data i ODS vil være i strukturert lik kildesystemene, men under integrasjon kan det innebære datarensing, de-duplisering og kan anvende forretningsregler for å sikre dataintegritet. EN ODS er hovedsakelig ment å integrere data ganske ofte på det laveste granulære nivået for operativ rapportering i et nær sanntids dataintegrasjonsscenario. Normalt vil EN ODS ikke bli optimalisert for historisk og trendanalyse på stort sett med data.
la oss oppsummere forskjellene mellom EN ODS og DW:
- EN ODS er ment for operativ rapportering og støtter nåværende eller nær sanntid rapporteringskrav whera dw er ment for historisk og trendanalyse rapportering på et stort volum av data
- EN ODS er rettet for lav granulære spørringer mens EN DW brukes for komplekse spørringer mot sammendragsnivå eller på aggregerte data
- EN ODS gir informasjon for operative, taktiske beslutninger om nåværende eller nær sanntids datainnsamling whereasa dw leverer tilbakemelding for strategiske beslutninger som fører til generelle systemforbedringer
- i en ods frekvensen av datalast kan være hver time eller daglig, mens i En DWthe frekvensen av datalast kan være daglig, ukentlig, månedlig eller kvartalsvis
Data Warehouse Design Metoder
det er to forskjellige metoder som normalt følges når du designer En Datalagerløsning og basert på kravene til prosjektet ditt, kan du velge hvilken som passer til ditt spesielle scenario. Disse metodene eret resultat av forskning Fra BillInmon og Ralph Kimball.
Bill Inmon-Top-down Data Warehouse Design Approach
Bill Inmon blir noen ganger også referert til som «datavarehusets far»; hans designmetodikk er basert på en top – down tilnærming og definerer datalager i disse vilkårene
- Fagorientert-dataene i et datalager er kategorisert på grunnlag av fagområdet og dermed er det «fagorientert».
- Integrert-Data blir integrert fra ulike ulike datakilder og dermed universelle navnekonvensjoner, målinger, klassifikasjoner og så videre som brukes i datalageret. Datalageret gir en konsolidert oversikt over data og er derfor betegnet som en integrert løsning.
- Ikke-flyktig – når dataene er integrert\lastet inn i datalageret, kan den bare leses. Brukere kan ikke gjøre endringer i dataene, og thisp gjør dataene ikke-flyktige.
- Tidsvariant-endelig lagres data i lange tidsperioder kvantifisert i år og har en dato og tidsstempel, og derfor er det beskrevet som «tidsvariant».
Bill Inmon så et behov for å integrere data fra FORSKJELLIGE OLTP-systemer i et sentralisert lager (kalt data warehouse) med en såkalt top-down tilnærming. Bill Inmon ser for seg et datalager i sentrum av» Corporate Information Factory » (Cif), som gir et logisk rammeverk for å levere business intelligence (BI), business analytics og business management evner.
denne top-down design gir en svært konsekvent dimensjonal visning av data på tvers av data marts som alle data marts er lastet fra sentralisert depotet (Datalager).Top-down design har også vist seg å være fleksibel for å støtte forretningsendringer som det ser ut i organisasjonen som helhet, ikke ved hver funksjon eller forretningsprosess i organisasjonen. Generering av en ny dimensjonsdatamart mot dataene som er lagret idatalageret er en relativt enkel oppgave. Selv om det er noen utfordringer for top-down-tilnærmingen, representerer det for eksempel et veldig stort prosjekt med et meget bredt omfang, og dermed er kostnaden for å implementere et datalager ved hjelp av top-down-metoden betydelig.Videre kan varigheten av tiden fra prosjektstart til sluttbrukerne begynner å oppleve de første fordelene med løsningen, være betydelig. Top-down-metoden kan også være ufleksibel og ikke svare på endrede avdelings-eller forretningsprosessbehov (en bekymring for dagens dynamisk skiftende miljø) i implementeringsfasen.
Ralph Kimball-Bottom-up Data Warehouse Design Approach
Ralph Kimball er en kjent forfatter på temaet datavarehus. Hans designmetodikk kalles dimensjonal modellering ellerkimball-metoden. Denne metoden fokuserer på en bottom-up tilnærming, og legger vekt på verdien av datalageret til brukerne så raskt som mulig. I sin visjon er et datalager kopien av transaksjonsdata som er spesielt strukturert for analytisk spørring og rapportering for å støtte beslutningsstøttesystemet. Som per hans metodikk, data marts er firstcreated å gi rapportering og analytiske evner for specificbusiness \ funksjonelle prosesser og senere disse data marts kan til slutt bliunioned sammen for å skape en omfattende enterprise data warehouse. Bottom-up-tilnærmingen fokuserer på hver forretningsprosess på et tidspunkt, så avkastningen på investeringen kan være så rask som first data mart blir opprettet. Selv om du ikke er nøye planlagt, kan du mangle det store bildet av bedriftens datalager ved å savne noen dimensjoner eller ved å skape overflødige dimensjoner, etc. når du er for fokusert på en individuell forretningsprosess.
Ralph Kimballs bottom-up tilnærming foreslår å lage en forretningsmatrise som skal inneholde alle de vanlige elementene(som brukes av data marts som i samsvar med \ delt dimensjon, tiltak, etc.) definert for virksomheten som helhet. Med dette kan brukeren designe og utvikle løsninger som støtter analyse på tvers av forretningsprosessene for kryssalg. Du kan lære mer ommatrisen her.
for en person som ønsker å gjøre en karriere I Datavarehus og Business Intelligence-domene, vil jeg anbefale Å studere Bill Inmons bøker (Building The Data Warehouse og DW 2.0: The Architecture For Next Generation Of Data Warehousing) og Ralph Kimballs bok (Microsoft Data Warehouse Toolkit).
Neste Trinn
- ReviewMicrosoft SQL Server Business Intelligence – Hva, Hvorfor Og Hvordan-Del 1.
- ReviewMicrosoft SQL Server Business Intelligence Systemarkitektur-Del 2.
- Sjekk ut alle theSQL Server Business Intelligence tips på MSSQLTips.com.
Sist Oppdatert: 2013-06-24
Om forfatteren
Arshad Ali er EN SQL Og BI Utvikler med fokus På Datavarehus prosjekter For Microsoft.Vis alle mine tips
- Flere Business Intelligence-Tips…
