Datavarehus Architecture, komponenter og diagram Concepts

Datavarehus Concepts

A datalager eksisterer for å gi et selskap én versjon av sannheten for beslutningstaking og prognoser. Det er et informasjonssystem som inneholder historiske og kumulative data hentet fra én eller flere kilder.

Ved å organisere disse dataene for analyse i stedet for transaksjoner, forenkler et datalager rapporterings- og analysearbeidet til en hel organisasjon.

Kjennetegn ved datavarehus

Et datavarehus har fire definerende egenskaper som skiller det fra en rutinemessig driftsdatabase:

• Fagorientert
• Integrert
• Tidsvariant
• Ikke-flyktig

Fagorientert

Et datavarehus er emneorientert fordi det leverer informasjon om et tema snarere enn et selskaps pågående drift. Typiske emner inkluderer salg, markedsføring og distribusjon.

I stedet for daglig prosessering, vektlegger lageret modellering og analyse for beslutningstaking. Det gir en enkel og konsis oversikt over hvert emne og utelater data som ikke støtter beslutningsprosessen.

Integrert

Integrasjon er nært knyttet til fagorientering. I et datavarehus betyr integrasjon å etablere en felles måleenhet for alle lignende data hentet fra ulike databaser, og lagre disse dataene på en felles, universelt akseptabel måte.

Et datavarehus bygges ved å integrere data fra ulike kilder, som stormaskiner, relasjonsdatabaser og flate filer. Det må også beholde konsistente navnekonvensjoner, formater og koding.

Denne konsistensen i navngivning, attributtmål og kodingstruktur er det som gjør effektiv analyse mulig. Tenk på følgende eksempel:

I eksemplet ovenfor lagrer tre applikasjoner merket A, B og C informasjon om kjønn, dato og saldo, men hver applikasjon lagrer den på en annen måte:

• Program A lagrer kjønnsfeltet som logiske verdier som M eller F.
• Program B lagrer kjønnsfeltet som en numerisk verdi.
• Program C lagrer kjønnsfeltet som en tegnverdi.
• Den samme variasjonen gjelder for feltene Dato og Saldo.

Etter transformasjons- og renseprosessen lagres alle disse dataene i et felles format i datalageret.

Tidsvariant

Tidshorisonten til et datalager er mye bredere enn for et operasjonelt system. Dataene gjenkjennes med en bestemt periode og tilbyr et historisk perspektiv, slik at de alltid har et element av tid, enten eksplisitt eller implisitt.

Ett sted hvor denne tidsvariansen forekommer er i strukturen til postnøkkelen. Hver primærnøkkel i lageret bør inneholde et tidselement, for eksempel dag, uke eller måned.

Et annet aspekt ved tidsvariasjon er at når data først er satt inn i lageret, kan de ikke oppdateres eller endres.

Ikke-flyktig

Et datalager er også ikke-flyktig, noe som betyr at tidligere data ikke slettes når nye data kommer inn. Dataene er skrivebeskyttet og oppdateres med jevne mellomrom, noe som hjelper analytikere med å studere historiske data og forstå hva som skjedde og når.

Fordi det ikke trenger transaksjonsbehandling, gjenoppretting eller samtidighetskontroll, utelater et datalager slette-, oppdatere- og innsettingsaktivitetene som er vanlige i en operativ applikasjon. Bare to dataoperasjoner utføres i datalager:

1. Innlasting av data
2. Datatilgang

Tabellen nedenfor fremhever noen viktige forskjeller mellom en driftsapplikasjon og et datalager:

Operasjonell søknad	Datavarehus
Komplekse program må kodes for å sikre at dataoppgraderingsprosesser opprettholder høy integritet til sluttproduktet.	Denne typen problem oppstår ikke fordi dataoppdatering ikke utføres.
Data plasseres i en normalisert form for å sikre minimal redundans.	Data lagres ikke i normalisert form.
Teknologi som trengs for å støtte problemer med transaksjoner, datagjenoppretting, tilbakerulling og løsning av vranglåser er ganske kompleks.	Det gir relativ enkelhet i teknologi.

Datavarehus Architecture

Datavarehus ArchiTekturen er kompleks fordi systemet lagrer historiske og kumulative data fra flere kilder. Det finnes tre tilnærminger til å konstruere lagerlagene: ett-lags, to-lags og tre-lags.

Enkeltlags arkitektur har som mål å minimere mengden data som lagres ved å fjerne redundans. Det brukes sjelden i praksis.

To-lags arkitektur skiller de fysisk tilgjengelige kildene fra datalageret. Det er ikke lett å utvide, støtter færre sluttbrukere og kan støte på tilkoblingsproblemer på grunn av nettverksbegrensninger.

Tre-lags arkitektur er den mest brukte designen av et datavarehus.

Den består av topp-, midtre og nederste nivåer:

1. Nederste nivå: Databasen til varehuset fungerer som det nederste laget. Det er vanligvis et relasjonsdatabasesystem, og data renses, transformeres og lastes inn i dette laget ved hjelp av backend-verktøy.
2. Mellomlag: Mellomnivået er en OLAP-server implementert ved hjelp av enten ROLAP- eller MOLAP-modellen. Den presenterer en abstractett visning av databasen og fungerer som en mellommann mellom sluttbrukeren og databasen.
3. Toppnivå: Det øverste laget er et front-end-klientlag. Det inneholder verktøyene og API-ene som brukes til å koble til og hente data ut av lageret, for eksempel spørreverktøy, rapporteringsverktøy, administrerte spørreverktøy, analyseverktøy og datautvinningsverktøy.

Datavarehuskomponenter

Komponentene og den overordnede arkitekturen til et datavarehus fungerer sammen som vist i diagrammet nedenfor.

Datavarehuset er basert på en RDBMS-server, et sentralt informasjonsarkiv omgitt av nøkkelkomponenter som holder hele miljøet funksjonelt, håndterbart og tilgjengelig.

Et datavarehus har fem hovedkomponenter, som er beskrevet nedenfor.

Datavarehusdatabase

Den sentrale databasen er grunnlaget for lagermiljøet og er implementert på RDBMS teknologi. Fordi et tradisjonelt RDBMS er innstilt for transaksjonsbehandling snarere enn lager, kan ressurskrevende operasjoner som ad hoc-spørringer, flertabellkoblinger og aggregater gjøre det tregere.

Av den grunn brukes alternative databasetilnærminger:

• Relasjonsdatabaser distribueres parallelt for å tillate skalerbarhet, ved hjelp av modeller for delt minne eller delt ingenting på forskjellige flerprosessor- eller massivt parallelle konfigurasjoner.
• Nye indeksstrukturer brukes til å omgå skanninger av relasjonstabeller og forbedre hastigheten.
• Flerdimensjonale databaser (MDDB-er) brukes til å overvinne begrensningene i relasjonelle lagermodeller. Et eksempel er Essbase fra Oracle.

Innkjøps-, anskaffelses-, opprydnings- og transformasjonsverktøy (ETL)

Verktøyene for datainnsamling, transformasjon og migrering utfører alle konverteringene, oppsummeringene og endringene som trengs for å gjøre data om til et enhetlig lagerformat. De kalles også Ex.tract, Transform og Load (ETL)-verktøy.

Funksjonaliteten deres inkluderer følgende:

• Anonymiser data i henhold til regulatoriske bestemmelser.
• Fjern uønskede data fra driftsdatabaser før lasting inn i lageret.
• Søk og erstatt vanlige navn og definisjoner for data som kommer fra forskjellige kilder.
• Beregn sammendrag og avledede data.
• Fyll ut manglende data med standardverdier.
• Dedupliker gjentatte data som kommer fra flere kilder.

Disse ETL-verktøy kan generere cron-jobber, bakgrunnsjobber, Cobol-programmer og skallskript som regelmessig oppdaterer lageret og bidrar til å vedlikeholde metadataene.

Fordi de henter inspirasjon fra mange systemer, må ETL-verktøy også håndtere heterogenitet i databaser og data.

metadata

Metadata høres kanskje avansert ut, men det er rett og slett data om data som definerer lageret. Det brukes til å bygge, vedlikeholde og administrere lageret.

Innenfor arkitekturen spesifiserer metadata kilden, bruken, verdiene og funksjonene til dataene, og definerer hvordan dataene kan endres og behandles, slik at de forblir tett knyttet til lageret.

For eksempel kan en linje i en salgsdatabase inneholde:

4030 KJ732 299.90

Dette er meningsløst inntil metadataene forklarer at det representerer modellnummeret 4030, salgsagent-ID-en KJ732 og et totalt salgsbeløp på 299.90 dollar.

Metadata er derfor en viktig ingrediens i å gjøre data om til kunnskap, og det bidrar til å svare på spørsmål som:

• Hvilke tabeller, attributter og nøkler inneholder lageret?
• Hvor kom dataene fra?
• Hvor mange ganger lastes dataene inn på nytt?
• Hvilke transformasjoner og rensing ble brukt?

Metadata faller inn i to kategorier:

1. Tekniske metadata: Dette beskriver lageret for designerne og administratorene som bygger og driver det.
2. Bedriftsmetadata: Dette gir sluttbrukerne en enkel måte å forstå informasjonen som er lagret på lageret.

Spørreverktøy

Et hovedmål med datavarehus er å gi bedrifter informasjonen de trenger for å ta strategiske beslutninger, og spørreverktøy er hvordan brukere samhandler med systemet.

Disse verktøyene faller inn i fire kategorier:

1. Spørrings- og rapporteringsverktøy
2. Verktøy for applikasjonsutvikling
3. Data mining-verktøy
4. OLAP-verktøy

Spørre- og rapporteringsverktøy

Spørre- og rapporteringsverktøy deles inn i to grupper: rapporteringsverktøy og administrerte spørreverktøy.

Rapporteringsverktøy delt videre inn i produksjonsrapporteringsverktøy og skrivebordsrapportforfattere:

1. Rapportforfattere: Disse er utviklet for sluttbrukere som bygger sine egne analyser.
2. Produksjonsrapportering: Disse lar organisasjoner generere regelmessige driftsrapporter og støtte store batchjobber som utskrift og beregning. Populære eksempler inkluderer Brio, Business Objects, Oracle, PowerSoft og SAS Institute.

Administrerte spørreverktøy hjelpe sluttbrukere ved å sette inn et meta-lag mellom brukeren og databasen, som skjuler kompleksiteten til SQL og databasestrukturen.

Verktøy for applikasjonsutvikling

Når innebygde grafiske og analytiske verktøy ikke kan dekke en organisasjons analytiske behov, bygges det tilpassede rapporter med verktøy for applikasjonsutvikling.

Datautvinningsverktøy

Datautvinning oppdager meningsfulle nye korrelasjoner, mønstre og trender i store datamengder, og datautvinningsverktøy automatiserer denne oppdagelsen.

OLAP-verktøy

OLAP Verktøyene er bygget på en flerdimensjonal database og lar brukere analysere data gjennom forseggjorte, flerdimensjonale visninger.

Datavarehusbuss Architecture

Datavarehusbussen bestemmer hvordan data flyter gjennom varehuset. Denne flyten kan kategoriseres som innstrøm, oppstrøm, nedstrøm, utstrøm og metastrøm.

Når du designer bussen, må du ta hensyn til de delte dimensjonene og faktaene som spenner over datamartene.

Data Marts

A datamart er et tilgangslag som brukes til å levere data til brukere. Det passer for store lagre fordi det tar mindre tid og penger å bygge, selv om det ikke finnes noen enkelt, avtalt definisjon av et datamart.

Enkelt sagt er et datamart et datterselskap av et datalager. Det partisjonerer data for en bestemt gruppe brukere og kan ligge i samme database som lageret eller i en fysisk separat database.

Datavarehus Architecture Best Practices

For å designe en solid datavarehusarkitektur, følg beste praksis nedenfor:

• Bruk datavarehusmodeller som er optimalisert for informasjonsinnhenting, enten det er en dimensjonale, denormalisert eller hybrid tilnærming.
• Velg en passende designtilnærming, enten ovenfra og ned eller nedenfra og opp.
• Sørg for at data behandles raskt og nøyaktig, samtidig som de konsolideres til én enkelt versjon av sannheten.
• Utform datainnsamlings- og renholdsprosessen for lageret nøye.
• Design en metadataarkitektur som tillater deling av metadata mellom komponenter i lageret.
• Tenk på en Operamodell for nasjonal datalagring (ODS) når hentebehovene er nær bunnen av dataabstraktentracsjonspyramide eller når flere operative kilder må tilgås.
• Sørg for at datamodellen er integrert snarere enn bare konsolidert. Bruk i så fall en 3NF-datamodell, som også er ideell når du anskaffer ETL- og datarensingsverktøy.

Spørsmål og svar