Data Warehousing: Et ODS Eksempel - Dummies

Her er et datalagringseksempel som hjelper deg med å forstå ODS (operativ datalager). Anta at du jobber i et stort finansielt selskap som tilbyr en rekke tjenester til elitefirmaer og enkeltpersoner over hele verden.

Ditt firma har vokst til sin nåværende form som følge av en rekke fusjoner og oppkjøp gjennom de siste 25 årene. Trenden de siste årene mot konvergens av bank- og verdipapirtjenester har gitt bedriften din muligheten til å bli en fullstendige leverandør til kundene dine.

Selskapets gjennomsnittlige kunde vil sannsynligvis delta i mange (kanskje alle) disse typer aktivitetene:

• Tradisjonell aksjemegling (kjøp og salg av aksjer av aksjer, inkludert marginalkontoaktivitet) < Renteinntekter (bedrifts- og statsobligasjoner)

• Valutakontoer, inkludert risikarambitrage

• Kontantforvaltning

• Kortsiktige lån og andre gjeldsinstrumenter

• Mellom- og langsiktige lån og andre gjeldsinstrumenter

• Investeringer i venturekapitaler

• Du vil at kundene skal bruke din bedrift som en -stopp shopping for alt som involverer store pengesummer. Bedriftens situasjon er imidlertid litt komplisert, men spesielt på disse to områdene:

Fusjoner og oppkjøp har forlatt IT-infrastrukturen din med et stort antall solo-applikasjoner (applikasjoner som ikke er integrert med hverandre, selv om de sannsynligvis bør være).

• Ett system håndterer aksjehandel for amerikanske aksjer, for eksempel, og et annet system håndterer aksjemarkedsaktivitet fra ikke-U. S. Globale utvekslinger. I tillegg håndterer separate systemer håndteringsaktivitet, all gjeldsaktivitet i USA, alle kortsiktige gjeld i Europa, og alle mellomliggende og langsiktige europeiske gjeld. Og listen fortsetter.

  Definisjonen av en kunde er litt uklar. Enkeltpersoner etablerer selskaper og partnerskap gjennom hvilke de foretar investeringer eller sikre lån til forretningsreiser. Dine bedriftskunder kan være datterselskaper av andre selskaper, som kanskje også er dine kunder.

• Forretningspraksis krever all kredittaktivitet hos hver kunde for å passere gjennom en serie kvalitetssikringskontroller før godkjenning:

Hver kunde av deg, enten enkeltperson eller selskap, har flere tak på gjeldsaktivitet. Et tak er et beløp på totalt utestående gjeld til enhver tid. Inntil en kunde når dette taket på første nivå, kan han eller hun uten et menneskelig inngrep automatisk ta ut et nytt lån eller handle mot en kredittlinje, kjøpe aksjer på margin eller utføre enhver annen type aktivitet som øker gjeld.

• Hver kunde kan overstige taket på første nivå til et andre takbeløp etter å ha mottatt godkjenning fra en av selskapets ledere.

• For at en leder skal godkjenne kredittaktivitet forbi det første taket til det andre, må han eller hun kontrollere en rekke tiltak.

• For eksempel må kunden ha en viss aktivitetsbalanse på plass; Kunden har kanskje ikke redusert totale eiendeler på hånden i alle kontoer av alle typer (for eksempel kontanter, aksjer og obligasjoner) med mer enn 15 prosent i de foregående 30 dagene; og banken har maksimale beløp for total gjeld i hvert land, justert av eiendeler holdt i hvert land.

  For å bidra til å kontrollere risikoen, sporer firmaet forholdet mellom alle dine kunder for å få et reelt bilde av kundens økonomiske tilstand. For eksempel kan en person styre en rekke selskaper, hvorav hver du behandler som en individuell kunde med egen eiendoms- og gjeldsaktivitet, i tillegg til individets egne kontoer.

• Når selskapets styremedlemmer godkjenner ytterligere gjeld uten gjeld, men (for et fastighetspartnerskap som involverer den enkelte), må lederne vurdere et samlet bilde av hva som skjer med den enkeltes aktivitet for å unngå for mye risikoeksponering i tilfelle økonomiske problemer.

  Selv om kvalitetssikringskontrollene beskrevet i forrige liste er konseptuelt enkle, er de ekstremt komplekse å implementere, av en enkel grunn: Disse kontrollene krever data fra systemer over hele bedriften, fra mange forskjellige systemer.

Denne informasjonen inneholder informasjon som all aktivaktivitet, all gjeldsaktivitet og utestående lån, og informasjon om hvilke lån som nettopp ble betalt tidligere i dag.

En tilnærming du kan prøve, er å gi bedriftens ledere (de som må ta beslutninger om lånegodkjenning) med grensesnitt til hvert system der de kan finne nødvendige data. Disse ledere kan deretter kjøre en lang rekke spørringer (hvis de selv kan støttes), trekke ut de riktige verdiene, lime dem inn i et regnearkprogram og ta avgjørelsen.

Denne tilnærmingen har imidlertid to problemer: Muligheten for menneskelig feil er høy, og tempoet der denne typen aktivitet må forekomme, er greit bare under "vanlige" tider.

I en tid med finanskrisen, når mange eller de fleste av firmaets kunder kjøper og selger aksjer, dekker marginer, kjøp og salg av alternativer, prøver å håndtere sine sikringskontoer, kjører mot kredittlinjer og gjør alle andre aktiviteter veldig raskt, selskapets ansatte kan bare ikke holde tritt.

I denne situasjonen kommer ODS til redning. Denne figuren illustrerer en konseptuell arkitektur som du kan bruke til å implementere en ODS som oppfyller dine forretningsoppdrag. For det første gir ODS et konsolidert bilde av en kundes saldoer for automatisk lånebehandling under det første taket. Deretter gjør ODS det mulig for ledere å ta ja-eller-nei beslutninger om låneforespørsler opp til det andre taket.

ODS gir brukerne et konsolidert, nesten øyeblikkelig bilde av forskjellige data til støtte for en bestemt forretningsoppgave.

For å få bedre oversikt over datastrømmene i ODS-miljøet, se denne figuren, der oppdateringer til en av datakildene (systemet som håndterer USAs gjeld) forplanter seg i ODS-miljøet.

ODS må gjenspeile dataene i hele bedriften så raskt som mulig.

Følgende trinn indikerer hva som skjer i ODS-miljøet:

En kunde foretar en regelmessig planlagt lånebetaling, og systemet som håndterer betalinger på amerikanske lån og kredittlinjer behandler betalingen.

1. Lånbetalingsprogrammet oppdaterer sin database for å reflektere betalingen.

2. Lånbetalingsprogrammet skyver deretter de oppdaterte dataene umiddelbart til ODS.

3. ODS mottar oppdateringen og behandler den, oppdaterer databasens innhold (i dette eksemplet reduserer kundens totale utestående gjeldsbeløp).

4. ODS utfører intern behandling, konsolidering, varsler eller andre nødvendige funksjoner.

5. Et miljø som det som er nevnt i forrige liste kan - hvis alt er bygget opp på riktig måte - gi et bilde av alle relevante data fra hele stedet - nå - til støtte for firmaets risikostyringsoppdrag.

Du må validere behovet for sanntidsoppdateringer i ODS fordi disse oppdateringene er komplekse å lage, som beskrevet i følgende avsnitt.

Utfordre stadig antagelser og stille spørsmål: "Hva skjer hvis du må vente til slutten av dagen? Hva om oppdateringer var to ganger om dagen? Hver time? "Vær helt sikker på at oppdraget dikterer sanntidsoppdateringer fordi å skape en ODS tar lengre tid (og er dyrere) enn et datalager.