Data Warehouse Lite-dummies

Et datalager lite er et no-frills, bare-ben, lavteknologisk tilnærming til å gi data som kan hjelpe med noen av din beslutningsprosess. No-frills betyr at du sammen, når det er mulig, har bevist evner og verktøy som allerede er i organisasjonen for å bygge systemet.

Områder og datainnhold i et datalager lite

Et datalager lite er fokusert på rapportering eller analyse av bare ett eller muligens to fagområder. Anta at i jobben din på en trådløs avdeling av et telefonselskap analyserer du salg av tjenester som nettverksminutter, nettverksminutter, tekstmeldinger, Internett-tilgang og annen mobilbruk til forbrukerhusholdninger.

Hvis du bygger et datalager lite utelukkende for dette formålet, har du all nødvendig informasjon som støtter analyse og rapportering til forbrukermarkedet. Du har imidlertid ingen informasjon om bedriftsbrukere og betalingshistorikk, fordi den informasjonen er en del av et annet emneområde, som vist i denne figuren.

Basert på begrensning av fagområde, har et datalager lite akkurat nok datainnhold til å tilfredsstille det primære miljøet, men ikke nok for mange ustrukturerte hva-om-scenarier brukerne kan opprette.

Du må derfor nøye velge mellom settet av alle mulige dataelementer og velge et håndterbart delsett - elementer som uten tvil er viktige å ha. Denne prosessen er den samme for enhver data warehouse implementering, bortsett fra at du må være ekstremt disiplinert når du tar beslutninger om hvilket innhold som skal inkluderes.

Bruk standardrapporter, spesielt de som for øyeblikket krever mye manuell forberedelse, som en av dine primære guider for å bestemme datainnholdet i et datalager lite.

Datakilder

Et datalager lite har et begrenset sett med datakilder - vanligvis en til en håndfull. Som en del av et overordnet enkeltapplikasjonsmiljø, virker datalagerhuset lite som restruktureringsagenten for søknadens data for å gjøre det mer spørrings- og rapportvennlig.

Den vanligste måten å restrukturere en enkelt applikasjons data på er å deormalisere innholdet i applikasjonsdatabase tabeller for å eliminere så mange relasjonelle samvirkeoperasjoner (prosessen med å samle data fra flere databaser) som mulig når brukere kjører rapporter eller gjør enkel spørring.

Denormalisering er motsatt av relasjonsdatabase-konseptet for normalisering, et noe komplekst sett med retningslinjer som forteller deg hvilke dataelementer som skal være i hvilke tabeller i en database.

Når du denormaliserer en database, trenger du ikke bekymre deg for dupliserte data; du prøver å lage rader med data i et enkelt bord som mest sannsynlig speiler rapporter og spørringer som brukere kjører. Denne figuren viser et eksempel på et enkelt-kilde datalager lite bygget på denormalisering.

Selv om du kan bruke eksternt tilveiebragte data i en data warehouse lite implementering, er dataene du bruker, sjelden nylig kjøpt. Du er mer sannsynlig å inkorporere data som du allerede bruker for analyse (kanskje på en frittstående måte).

Business Intelligence Tools

Brukerne av et datalager lite spør spørsmål og lager rapporter som reflekterer et "Fortell meg hva som skjedde" perspektiv. Fordi de brukerne ikke gjør mye tungt analytisk behandling, bør produktene de bruker for å få tilgang til datalageret, være enkelt for dem å bruke.

Datautvinning, bevegelse og lasting

Enkelhet er navnet på spillet i et datalager lite. Gjør derfor prosessen med å utvinne data fra kilder og utføre alle funksjonene som er nødvendige for å forberede dataene for innlasting så enkelt som mulig ved å bruke disse to elementene:

• Enkle filutdrag fra drift-systemene og filoverføringer som Tillat deg å flytte data fra kildene til datalageret lite

• Enkel tilpasset kode (eller kanskje et brukervennlig verktøy) som kan trekke ut og flytte dataene

Hvis datakilden til datalageret ditt er Bygget på en relasjonsdatabase, og du planlegger å bruke det samme databaseproduktet for datalageret ditt, bruk SQL for å håndtere datautvinning og bevegelse. Disse trinnene - som vist på figuren - gir en standard prosedyre for denne prosessen (du vil selvsagt tilpasse disse trinnene til ditt eget miljø):

1. På systemet som lager ditt lager, bruk SQL CREATE TABLE uttalelse for å lage definisjonen for hvert bord i datalageret ditt lite.

2. Opprett en database backup som inneholder kopier av alle tabeller fra kilden som gir data til lageret, og deretter laster de opp tabellene i et oppføringsområde på systemet der du planlegger å finne datalagret ditt.

   Du bør sørge for at nettverksbåndbredden og tidvinduet er tilstrekkelig til å kopiere alle kildebordene til systemet ved hjelp av et filoverføringsprogram.

3. Bruk SQL INSERT-setningen, med en nestet SELECT-setning som angir kildebordene og deres respektive kolonner som vil fylle opp datalagertabellen (og hvordan tabellene blir slått sammen), for å laste dataene inn i datalageret lite.

4. Kjør en serie kvalitetssikringsrutiner (QA) for å bekrefte at alle dataene er lastet riktig.

   Sjekk radtall, talltall og alt annet du kan.

   

Arkitektur

Arkitekturen til et datalager lite består av databasen som brukes til å lagre dataene, de forreste forretningsinformasjonsverktøyene som brukes til å få tilgang til dataene, måten dataene flyttes på, og antall fag områder.Klokka på dette miljøet er minimalistisk: ingen klokkene, ingen fløyter, ingenting fancy - akkurat nok teknologi som brukes på miljøet for å gi brukerne tilgang til data de trenger.

Arkitekturen til et data warehouse lite, som vist i denne figuren, inneholder disse hovedkomponentene:

• En enkelt database inneholder varehusets data.

• Denne databasen blir matet direkte fra hver av kildene som gir data til lageret.

• Brukere får tilgang til data direkte fra lageret.