1 datavarehus Konsepter

Dette kapitlet gir en oversikt over Oracle data warehousing gjennomføring. Det inkluderer:

• Hva er en Data Warehouse?
• Data Warehouse Arkitektur

Merk at denne boken er ment som et supplement til standard tekster om data warehousing. Denne boken fokuserer på Oracle-materialet og ikke gjengi i detalj materiale av generell karakter., To standard tekster er:

• Data Warehouse Toolkit av Ralph Kimball (John Wiley og Sons, 1996)
• Bygning Data Warehouse av William Inmon (John Wiley og Sons, 1996)

Hva er en Data Warehouse?

En data warehouse er en relasjonsdatabase som er designet for spørring og analyse i stedet for behandling av transaksjoner. Det inneholder vanligvis historiske data som er avledet fra transaksjonen data, men det kan også inkludere data fra andre kilder., Det skiller analyse arbeidsmengde fra transaksjonen arbeidsmengde og gjør det mulig for en organisasjon å konsolidere data fra flere kilder.

I tillegg til en relasjonell database, en data warehouse miljøet omfatter en utvinning, transport, transformasjon, og laste (ETL) – løsning, en online analytical processing (OLAP) motor -, klient-analyse verktøy, og andre programmer som håndterer prosessen med innsamling av data og it til bedrifter.,

En vanlig måte å introdusere data warehousing er å henvise til egenskaper ved en data warehouse, som beskrevet av William Inmon:

• Faget er Orientert
• Integrert
• ikke-flyktig
• Tid Variant

Faget er Orientert

Data varehus er laget for å hjelpe deg med å analysere data. For eksempel, for å lære mer om selskapets salg av data, kan du bygge et lager som konsentrerer seg om salg. Ved hjelp av dette lageret, kan du svare på spørsmål som «Hvem var vår beste kunde for dette elementet siste året?,»Denne evnen til å definere en data warehouse av saksområdet, salg i dette tilfellet, gjør data warehouse emnet orientert.

Integrert

Integrering er nært knyttet til emnet orientering. Data varehus må sette data fra ulike kilder inn i en konsistent format. De må løse slike problemer som navngi konflikter og uoverensstemmelser blant måleenhet. Når de oppnår dette, de er sagt å være integrert.

ikke-flyktig

ikke-flyktig betyr at, en gang inn i galleriet, data bør ikke endres., Dette er logisk fordi hensikten med et lager er å gjøre deg i stand til å analysere hva som har skjedd.

Tid Variant

for å oppdage trender i næringslivet, analytikere trenger store mengder data. Dette er veldig mye i kontrast til online transaksjon behandling (OLTP) systemer, hvor krav til ytelse kreve at historiske data flyttes til et arkiv. En data warehouse er fokus på endring over tid, er hva som menes med begrepet tid variant.,

Kontrasterende OLTP og Data Warehousing Miljøer

Figur 1-1 illustrerer viktige forskjeller mellom en OLTP-systemet og en data warehouse.

Figur 1-1 Kontrasterende OLTP og Data Warehousing Miljøer

Tekst beskrivelse av illustrasjon https://docs.oracle.com/cd/B10500_01/server.920/a96520/dwhsg005.gif

En stor forskjell mellom de ulike typer system er at data varehus er ikke vanligvis i tredje normale form (3NF), en type data normalisering vanlig i OLTP-miljøer.

Data varehus og OLTP systemer har svært ulike behov., Her er noen eksempler på forskjeller mellom typiske data varehus og OLTP-systemer:

• Arbeid

  Data varehus er utviklet for å imøtekomme ad-hoc spørringer. Du vet kanskje ikke den belastningen av dine data warehouse på forhånd, så en data warehouse skal være optimalisert for å fungere bra for et bredt spekter av mulige spørring operasjoner.

  OLTP-systemer støtter kun forhåndsdefinerte operasjoner. Dine programmer kan være spesielt tilpasset eller bare utviklet for å støtte disse operasjonene.,

• Data modifikasjoner

  En data warehouse er oppdatert på en jevnlig basis av ETL-prosessen (kjør døgn eller uke) ved hjelp av bulk data modifikasjon teknikker. Sluttbrukerne av en data warehouse ikke direkte oppdatere data warehouse.

  I OLTP-systemer, sluttbrukere rutinemessig problemet individuelle data modifikasjon uttalelser til databasen. Den OLTP database er alltid oppdatert, og reflekterer nåværende tilstand av hver forretningstransaksjon.,

• Skjema design

  Data varehus ofte bruker denormalized eller delvis denormalized skjemaer (for eksempel en stjerne-skjema) for å optimalisere ytelse.

  OLTP-systemer ofte bruker fullt ut normalisert skjemaene for å optimalisere oppdatering/sette inn/slette ytelse, og for å sikre datakonsistens.

• Typiske operasjoner

  En typisk data warehouse spørring skanner tusenvis eller millioner av rader. For eksempel «Finn det totale salget for alle kunder sist måned.»

  En typisk OLTP drift tilgang er bare en håndfull av oppføringer. For eksempel, «Hent gjeldende for denne kunden.,»

• Historiske data

  Data varehus vanligvis lagre mange måneder eller år av data. Dette er for å støtte historisk analyse.

  OLTP-systemer vanligvis lagre data fra bare et par uker eller måneder. Den OLTP-systemet lagrer bare historiske data som trengs for å kunne oppfylle kravene til den aktuelle transaksjonen.

Data Warehouse Arkitektur på

Data varehus og deres arkitekturer variere avhengig av detaljene i en organisasjon situasjon., Tre vanlige arkitekturer er:

• Data Warehouse Arkitektur (Grunnleggende)
• Data Warehouse Arkitektur (med et oppsamlingsområde)
• Data Warehouse Arkitektur (med et oppsamlingsområde og Data Marts)

Data Warehouse Arkitektur (Grunnleggende)

Figur 1-2 viser en enkel arkitektur for et data warehouse. Sluttbrukere direkte tilgang til data som er avledet fra flere kildesystemer gjennom data warehouse.,

Figur 1-2 Arkitektur av en Data Warehouse

Tekst beskrivelse av illustrasjon https://docs.oracle.com/cd/B10500_01/server.920/a96520/dwhsg013.gif

I Figur 1-2, metadata og rådata av en tradisjonell OLTP-system er til stede, som er en ekstra type data, oppsummering av data. Oppsummeringer er svært verdifulle i data varehus fordi de pre-prosessering lang operasjoner på forhånd. For eksempel, en typisk data warehouse spørringen for å hente noe som August salg. En oppsummering i Oracle er kalt en materialisert vise.,

Data Warehouse Arkitektur (med et oppsamlingsområde)

I Figur 1-2, du trenger for å rengjøre og behandle dine operasjonelle data før du setter det inn i lageret. Du kan gjøre dette i et program, selv om de fleste data varehus bruke et midlertidig område i stedet. Et oppsamlingsområde forenkler bygning sammendrag og generell lagerstyring. Figur 1-3 viser denne typiske arkitektur.,

Figur 1-3 Arkitektur av en Data Warehouse med et oppsamlingsområde

Tekst beskrivelse av illustrasjon https://docs.oracle.com/cd/B10500_01/server.920/a96520/dwhsg015.gif

Data Warehouse Arkitektur (med et oppsamlingsområde og Data Marts)

Selv om arkitekturen i Figur 1-3 er ganske vanlig, du ønsker kanskje å tilpasse warehouse arkitektur for ulike grupper i organisasjonen. Du kan gjøre dette ved å legge til data marts, som er systemer som er utformet for en bestemt bransje., Figur 1-4 viser et eksempel der hvor å kjøpe, salg, og varelager er atskilt. I dette eksempelet, en finansanalytiker ønsker kanskje å analysere historiske data for kjøp og salg.

Figur 1-4 Arkitektur av en Data Warehouse med et oppsamlingsområde og Data Marts

Tekst beskrivelse av illustrasjon https://docs.oracle.com/cd/B10500_01/server.920/a96520/dwhsg064.gif