Ideen bak flerdimensjonale databaser - dummier

Multidimensjonale databaser (MDDB) kaster ut konvensjonene fra deres relasjonsforfedre og organiserer data på en måte som bidrar til flerdimensjonal analyse. For å forstå flerdimensjonale databaser må du derfor først forstå grunnleggende om de analytiske funksjonene som utføres med dataene som er lagret i dem.

Flerdimensjonal analyse er bygget opp rundt noen få enkle data organisasjonskonsepter - spesielt fakta og dimensjoner:

• Fakta: A faktum er en forekomst av en bestemt forekomst eller begivenhet og egenskapene til arrangementet alle lagret i en database. Har du solgt en klokke til en kunde i fredags ettermiddag? Det er et faktum. Har butikken din mottatt en forsendelse av 76 klasse ringer i går fra en bestemt leverandør? Det er et annet faktum.

• Dimensjoner: A dimensjon er en nøkkelbeskrivelse, en indeks, hvor du kan få tilgang til fakta i henhold til verdien (eller verdiene) du vil ha. For eksempel kan du organisere salgsdataene dine i henhold til disse dimensjonene: tid, kunde og produkt.

Grunnleggende

I disse enkle eksemplene kan du organisere og se salgsdata som et tredimensjonalt utvalg, indeksert av tid, kunde og produktdimensjoner:

• I oktober 2008 (tidsdimensjonen), kunden A (kundedimensjonen) kjøpte klasse ringer (produktdimensjonen) - 79 av dem for $ 8, 833.

• I 2007 (tidsdimensjonen) kjøpte kunde A (kundedimensjonen) mange forskjellige produkter (produktdimensjonen) - totalt 3, 333 enheter for $ 55, 905 (fakta).

Legg merke til den subtile forskjellen mellom måten dimensjonene brukes på i disse to eksemplene. I den første gjelder tidsdimensjonen i en måned; kundens dimensjon vedrører en bestemt kunde; og produktdimensjonen er for et bestemt produkt.

I det andre eksemplet er tiden imidlertid et år, ikke en måned; Kunden er fortsatt den samme (en individuell kunde); og produktet er for hele produktlinjen.

Flerdimensjonal analyse støtter begrepet hierarkier i dimensjoner. For eksempel kan du organisere tid i et hierarki av år → kvartal → måned. Du kan se fakta (eller konsolidering av fakta) i databasen på et hvilket som helst av disse nivåene: etter år, kvartal eller måned.

På samme måte kan du organisere produkter i et hierarki av produktfamilie → produkttype → spesifikke produkter. Klasseringene kan være en produkttype; "Klasse ring, moderne stil, onyx stein" kan være et bestemt produkt.Videre vil alle klasser ringer, klokker, andre ringer og andre ting rulle opp i smykker-produktfamilien.

Er det en grense for antall dimensjoner?

Teoretisk sett kan du ha så mange dimensjoner i din flerdimensjonale modell som nødvendig. Spørsmålet eksisterer imidlertid alltid om multidimensjonal databaseprodukt kan støtte dem. Men her er et viktigere spørsmål - selv om et produkt tillater et visst antall dimensjoner (for eksempel 15), er det fornuftig å lage en modell av den størrelsen?

Du bør jobbe tett med brukerne for å finne ut om antall dimensjoner gjør løsningen din for kompleks - og dermed begrense befolkningen til brukere - eller forbedrer brukervennligheten - og dermed utvider brukerpopulasjonen.

Du kan for eksempel legge til geografi i dimensjonslisten som inneholder tid, kunde og produkt, slik at du kan se og organisere fakta i henhold til salgsområder, stater, byer og bestemte butikker.

Hvordan skal du velge nivåene i et hierarki?

Nivåene i et hierarki gjør at du kan utføre drill down funksjonalitet. Og ved å ha flere nivåer innenfor et hierarki, kan du raskt få svar på dine spørsmål på grunn av informasjonen som er opprettet på hvert av de angitte nivåene, slik at informasjonen bare venter på dine spørsmål.

Fordi flerdimensjonale databaser har ganske stive strukturer bygget rundt pre - beregning av fakta (opprette og lagre aggregater i databasen, i stedet for å utføre rapporteringstid og aggregering) Jo flere dimensjoner du har og jo flere nivåer i hver dimensjon du har, desto større er lagringskravene dine og jo lengre bygg- eller lastetider.

Fysiske databasestrukturer i en MDDB

Selv om nesten alle MDDB-produkter er bygget rundt fakta, dimensjoner og hierarkier, har ingen kommet opp med en MDDB-standarddefinisjon. I relasjonsverdenen har ikke-standardisering også vært noe av et problem, særlig i forhold til verdiskapende funksjoner, for eksempel begrensninger og lagrede prosedyrer.

Den grunnleggende relasjonelle tabell-rad-kolonne strukturen har imidlertid vært ganske enkelt å eksportere eller laste ut i en flat fil av noe slag og deretter laste den på nytt i et annet RDBMS-produkt.

I MDDB-verden har leverandørene tatt en rekke forskjellige tilnærminger til deres respektive produkters fysiske dataopplysninger. De søker alle måter å overvinne lagrings- og kompleksitetsproblemer forårsaket av store dimensjoner (for eksempel mer enn 15) og dype nivåer av hierarkier (for eksempel 20 nivåer dyp).

Når du vurderer produkter, ikke bli opptatt av å bekymre deg for fysisk lagringsteknikker: Bare vær sikker på at de logiske representasjonene som følger med produktene (som hierarkier, nivåer og fakta), kan oppfylle dine forretningsbehov. Eliminer produkter som virker clunky eller som for eksempel har en hierarkimodell som ikke virker helt riktig for dataene dine.

Etter at du har funnet produkter som synes å passe til virksomheten din, kan du dekk litt på dekkene for å se hvordan de fungerer inni.