Ideen bag multidimensionale databaser - dummier

Multidimensionelle databaser (MDDB'er) smider ud af deres relationelle forfædres konventioner og organiserer data på en måde, som yderst befordrende for multidimensionel analyse. For at forstå multidimensionale databaser skal du derfor først forstå grunduddannelsen for de analytiske funktioner, der udføres med de data, der er lagret i dem.

Multidimensionel analyse er bygget op omkring et par enkle data organisationsbegreber - specifikt fakta og dimensioner:

• Fakta: A faktum er en forekomst af en bestemt begivenhed eller begivenhed og egenskaberne af arrangementet alle gemt i en database. Har du solgt et ur til en kunde i fredags eftermiddag? Det er et faktum. Har din butik modtaget en forsendelse af 76 klasse ringe i går fra en bestemt leverandør? Det er et andet faktum.

• Dimensioner: A dimension er en nøglebeskrivelse, et indeks, hvorved du kan få adgang til fakta i henhold til værdien (eller værdierne), du ønsker. Du kan f.eks. Organisere dine salgsdata i henhold til disse dimensioner: tid, kunde og produkt.

Grundlæggende

I disse enkle eksempler kan du organisere og se dine salgsdata som et tredimensionelt array indekseret af tid, kunde og produktdimensioner:

• I oktober 2008 (tidsdimensionen) købte kunden A (kundedimensionen) klasse ringe (produktdimensionen) - 79 af dem for $ 8, 833.

• I 2007 (tidsdimensionen) købte kunde A (kundedimensionen) mange forskellige produkter (produktdimensionen) - i alt 3, 333 enheder til $ 55, 905 (fakta).

Bemærk det subtile, der er forskelligt mellem mådenes dimensioner anvendes i disse to eksempler. I den første vedrører tidsdimensionen en måned; kundens dimension vedrører en bestemt kunde og produktdimensionen er for et bestemt produkt.

I det andet eksempel er tiden dog et år, ikke en måned; kunden er stadig den samme (en individuel kunde); og produktet er for hele produktlinjen.

Multidimensionel analyse understøtter begrebet hierarkier i dimensioner. For eksempel kan du organisere tid i et hierarki af år → kvartal → måned. Du kan se fakta (eller konsolidering af fakta) i databasen på et hvilket som helst af disse niveauer: efter år, kvartal eller måned.

På samme måde kan du organisere produkter i et hierarki af produktfamilie → produkttype → specifikke produkter. Klasse ringe kan være en produkttype; "Klasse ring, moderne stil, onyx sten" kan være et bestemt produkt.Derudover vil klassen ringe, ure, andre ringe og andre ting alle rulles op i smykker produktfamilien.

Er der en grænse for antallet af dimensioner?

Teoretisk kan du have så mange dimensioner i din multidimensionale model som nødvendigt. Spørgsmålet eksisterer dog altid om, hvorvidt din multidimensionale databaseprodukt kan understøtte dem. Men her er et vigtigere spørgsmål - selv om et produkt tillader et bestemt antal dimensioner (f.eks. 15), giver det mening at lave en model af den størrelse?

Du bør arbejde tæt sammen med dine brugere for at afgøre, om antallet af dimensioner gør din løsning for kompleks - og dermed begrænser brugernes befolkning - eller forbedrer brugervenligheden - og udvider derfor brugernes befolkning.

Du kan f.eks. Tilføje geografi til dimensionlisten, der indeholder tid, kunde og produkt, så du kan se og organisere fakta i henhold til salgsområder, stater, byer og specifikke butikker.

Hvordan skal du vælge niveauerne i et hierarki?

Niveauerne i et hierarki giver dig mulighed for at udføre drill down funktionalitet. Og ved at have flere niveauer inden for et hierarki, kan du hurtigt få svar på dine spørgsmål på grund af de oplysninger, der er oprettet på hvert af de angivne niveauer, så informationen venter bare på dine forespørgsler.

Fordi multidimensionale databaser har ret stive strukturer opbygget omkring pre - beregning af fakta (oprettelse og lagring af aggregater i databasen i stedet for at udføre rapporteringstid og aggregering og beregning) Jo flere dimensioner du har, og jo flere niveauer i hver dimension du har, desto større er lagerkravene og jo længere er bygnings- eller belastningstiderne.

Fysiske databasestrukturer i en MDDB

Selv om næsten alle MDDB-produkter er bygget op omkring fakta, dimensioner og hierarkier, har ingen kommet op med en MDDB-standarddefinition. I relationelle verden har ikke-standardisering også været noget af et problem, især i forhold til værditilvækstfunktioner, såsom begrænsninger og lagrede procedurer.

Den grundlæggende relationelle tabel-række-kolonne struktur har imidlertid været ret nem at eksportere eller aflæse til en flad fil af en eller anden type og derefter genindlæse den i et andet RDBMS-produkt.

I MDDB-verden har leverandørerne taget en række forskellige tilgange til deres respektive produkters fysiske repræsentationer af data. De søger alle måder at overvinde lagrings- og kompleksitetsproblemer forårsaget af mange dimensioner (f.eks. Mere end 15) og dybe niveauer af hierarkier (for eksempel 20 niveauer dybt).

Når du vurderer produkter, skal du ikke blive foruroliget i at bekymre dig om fysiske lagringsteknikker: Bare sørg for, at de logiske repræsentationer, der følger med produkterne (som hierarkier, niveauer og fakta), kan opfylde dine forretningsbehov. Eliminer produkter, der virker klumpede, eller som f.eks. Har en hierarkimodel, der ikke synes helt rigtig for dine data.

Derefter, efter at du har fundet produkter, der synes at passe til din virksomhed, skal du slå dækene lidt (for at sige) for at se, hvordan de fungerer indeni.