Kolliderar ideen bakom multidimensionella databaser - dummies

Multidimensionella databaser (MDDB) slänger ut sina konventionella förfädernas konventioner och organiserar data på ett sätt som är mycket framkallande för multidimensionell analys. För att förstå multidimensionella databaser måste du först förstå grunderna för de analytiska funktionerna som utförs med data lagrade i dem.

Multidimensionell analys bygger på några enkla dataorganisationskoncept - specifikt fakta och dimensioner:

• Fakta: A faktum är en förekomst av en viss händelse eller händelse och egenskaperna hos händelsen som alla lagras i en databas. Säljer du en klocka till en kund i fredags eftermiddag? Det är ett faktum. Har din butik fått en försändelse av 76 klassringar i går från en viss leverantör? Det är ett annat faktum.

• Mått: A dimension är en nyckelbeskrivare, ett index där du kan få tillgång till fakta enligt värdet (eller värdena) du vill ha. Du kan till exempel organisera dina försäljningsdata enligt dessa dimensioner: tid, kund och produkt.

Grunderna

I dessa enkla exempel kan du organisera och visa dina försäljningsdata som en tredimensionell matris, indexerad av tid, kund och produktdimensioner:

• I oktober 2008 (tidsdimensionen) köpte kund A (kunddimensionen) klassringar (produktdimensionen) - 79 av dem för 8 $, 833.

• Under 2007 (tidsdimensionen) köpte kund A (kunddimensionen) många olika produkter (produktdimensionen) - totalt 3 333 enheter för $ 55, 905 (fakta).

Lägg märke till den subtila skillnaden mellan hur dimensionerna används i dessa två exempel. I den första avser tidsdimensionen en månad; kunddimensionen avser en viss kund och produktdimensionen är för en specifik produkt.

I det andra exemplet är dock tiden för ett år, inte en månad; Kunden är fortfarande densamma (en enskild kund); och produkten är för hela produktlinjen.

Flerdimensionell analys stöder begreppet hierarkier i dimensioner. Du kan till exempel organisera tid i en hierarki av år → kvartal → månad. Du kan se fakta (eller konsolidering av fakta) i databasen på någon av dessa nivåer: efter år, kvart eller månad.

På samma sätt kan du organisera produkter i en hierarki av produktfamilj → produkttyp → specifika produkter. Klassringar kan vara en produkttyp; "Klassring, modern stil, onyxsten" kan vara en specifik produkt.Vidare skulle klassringar, klockor, andra ringar och andra saker alla röra sig in i smyckenproduktfamiljen.

Finns det en gräns för antalet dimensioner?

Teoretiskt kan du ha så många dimensioner i din multidimensionella modell som behövs. Frågan finns emellertid alltid om din multidimensionella databasprodukt kan stödja dem. Men här är en viktigare fråga - även om en produkt tillåter ett visst antal dimensioner (15 till exempel), är det vettigt att skapa en modell av den storleken?

Du borde arbeta nära dina användare för att bestämma om antalet dimensioner gör din lösning för komplex - och därigenom begränsar användarnas befolkning - eller förbättrar användarvänligheten - och därigenom utökar användarbefolkningen.

Du kan till exempel lägga till geografi i dimensionslistan som innehåller tid, kund och produkt så att du kan se och organisera fakta enligt försäljningsområden, stater, städer och specifika butiker.

Hur ska du välja nivåerna i en hierarki?

Nivåerna i en hierarki gör att du kan utföra drill down -funktionalitet. Och genom att ha flera nivåer inom en hierarki kan du snabbt få svar på dina frågor på grund av informationen som har ställts in på vart och ett av de angivna nivåerna, så informationen väntar bara på dina frågor.

Eftersom multidimensionella databaser har ganska styva strukturer som byggts kring före - beräkning av fakta (skapa och lagra aggregat i databasen, istället för att utföra rapporttidssamling och beräkning) Ju fler dimensioner du har och ju fler nivåer du har i varje dimension, desto större är lagringskraven och ju längre dina bygg- eller lasttider.

Fysiska databasstrukturer i en MDDB

Även om nästan alla MDDB-produkter är byggda kring fakta, dimensioner och hierarkier, har ingen kommit överens med en MDDB-standarddefinition. I relationsvärlden har icke-standardisering också varit något av ett problem, särskilt i förhållande till mervärdefunktioner, såsom begränsningar och lagrade förfaranden.

Den grundläggande relationella tabellraden-kolonnstrukturen har dock varit ganska lätt att exportera eller lossa i en platt fil av någon typ och sedan ladda den till en annan RDBMS-produkt.

I MDDB-världen har leverantörerna tagit en mängd olika tillvägagångssätt för sina respektive produkters fysiska uppgifter om data. De söker alla sätt för att övervinna lagrings- och komplexitetsproblem som orsakas av stora dimensioner (till exempel mer än 15) och djupa nivåer av hierarkier (till exempel 20 nivåer djupa).

När du utvärderar produkter, bli inte upptagen i att oroa dig för fysisk lagringsteknik: Kontrollera bara att de logiska representationer som följer med produkterna (som hierarkier, nivåer och fakta) kan uppfylla dina företagsbehov. Eliminera produkter som verkar klumpiga eller som exempelvis har en hierarkimodell som inte verkar helt rätt för dina data.

Sedan, efter att du har hittat produkter som verkar passa ditt företag, sparka däcken lite (så att säga) för att se hur de fungerar inuti.