De idee achter multidimensionale databases - dummies

Multidimensionale databases (MDDB's) verdrijven de conventies van hun relationele voorouders en organiseren gegevens op een manier die zeer bevorderlijk is voor multidimensionale analyse. Om multidimensionale databases te begrijpen, moet u daarom eerst de basisbeginselen begrijpen van de analytische functies die worden uitgevoerd met de gegevens die daarin zijn opgeslagen.

Multidimensionale analyse is opgebouwd rond een paar eenvoudige gegevensorganisatieconcepten - met name feiten en dimensies:

Feiten: A feit is een instantie van een bepaalde gebeurtenis of gebeurtenis en de eigenschappen van de gebeurtenis zijn allemaal opgeslagen in een database. Heb je afgelopen vrijdag een horloge aan een klant verkocht? Dat is een feit. Heeft uw winkel gisteren een zending van 76 klassenringen van een bepaalde leverancier ontvangen? Dat is nog een feit.
Dimensies: A dimensie is een sleuteldescriptor, een index waarmee u de feiten kunt benaderen op basis van de gewenste waarde (of waarden). U kunt bijvoorbeeld uw verkoopgegevens indelen volgens deze dimensies: tijd, klant en product.

De basis

In deze eenvoudige voorbeelden kunt u uw verkoopgegevens organiseren en bekijken als een driedimensionale array, geïndexeerd op basis van tijd, klant en productdimensies:

In oktober 2008 (de tijdsdimensie), kocht klant A (de klantdimensie) klassenringen (de productdimensie) - 79 daarvan voor $ 8, 833.
In 2007 (de tijdsdimensie) koos klant A (de klantdimensie) veel verschillende producten (de productdimensie) - een totaal van 3, 333 eenheden voor $ 55, 905 (de feiten).

Let op het subtiele verschil tussen de manier waarop de dimensies in deze twee voorbeelden worden gebruikt. In de eerste heeft de tijdsdimensie betrekking op een maand; de klantdimensie heeft betrekking op een specifieke klant; en de productdimensie is voor een specifiek product.

In het tweede voorbeeld is tijd echter een jaar, geen maand; klant is nog steeds hetzelfde (een individuele klant); en product is voor de gehele productlijn.

Multidimensionale analyse ondersteunt het begrip hiërarchieën in dimensies. U kunt bijvoorbeeld de tijd in een hiërarchie van het jaar → kwartaal → maand ordenen. U kunt feiten (of de consolidatie van feiten) in de database bekijken op een van deze niveaus: per jaar, kwartaal of maand.

Evenzo kunt u producten in een hiërarchie van productfamilie → producttype → specifieke producten organiseren. Klasse ringen kunnen een producttype zijn; "Klaslokaal, moderne stijl, onyxsteen" kan een specifiek product zijn.Bovendien zouden klassenringen, horloges, andere ringen en andere items allemaal in de familie van sieradenproducten oprollen.

Is er een limiet aan het aantal dimensies?

In theorie kunt u zoveel dimensies in uw multidimensionale model hebben als dat nodig is. De vraag bestaat echter altijd of uw multidimensionale databaseproduct deze kan ondersteunen. Maar hier is een belangrijker vraag - zelfs als een product een bepaald aantal dimensies mogelijk maakt (bijvoorbeeld 15), is het dan logisch om een model van die omvang te maken?

U moet nauw samenwerken met uw gebruikers om te bepalen of het aantal dimensies uw oplossing te complex maakt - en dus de populatie van gebruikers te beperken - of het gebruiksgemak te vergroten - en daarom de gebruikerspopulatie uit te breiden.

U kunt bijvoorbeeld aardrijkskunde toevoegen aan de dimensielijst met tijd, klant en product, zodat u feiten kunt bekijken en ordenen op basis van verkoopregio's, staten, steden en specifieke winkels.

Hoe moet u de niveaus in een hiërarchie kiezen?

Met de niveaus in een hiërarchie kunt u drill-down -functionaliteit uitvoeren. En door meerdere niveaus binnen een hiërarchie te plaatsen, kunt u snel antwoorden op uw vragen krijgen vanwege de informatie die is ingesteld op elk van die opgegeven niveaus, zodat de informatie gewoon op uw vragen wacht.

Omdat multidimensionale databases tamelijk rigide structuren bevatten die zijn opgebouwd rond de pre - berekening van feiten (aggregaten maken en opslaan in de database, in plaats van aggregatie en berekening van rapporttijden uit te voeren), hoe meer dimensies u heeft en hoe meer niveaus in elke dimensie u heeft, hoe groter uw opslagvereisten en hoe langer uw build- of laadtijden.

Fysieke databasestructuren in een MDDB

Hoewel bijna alle MDDB-producten zijn gebaseerd op het concept van feiten, dimensies en hiërarchieën, heeft niemand een MDDB-standaarddefinitie bedacht. In de relationele wereld was niet-standaardisatie ook een beetje een probleem, vooral met betrekking tot functies met toegevoegde waarde, zoals beperkingen en opgeslagen procedures.

De eenvoudige relationele tabelrij-kolomstructuur was echter vrij eenvoudig te exporteren of uit te laden in een plat bestand van een bepaald type en vervolgens opnieuw te laden in een ander RDBMS-product.

In de MDDB-wereld hebben leveranciers verschillende benaderingen gekozen voor de fysieke weergave van hun respectieve producten. Ze zijn allemaal op zoek naar manieren om opslag- en complexiteitsproblemen te overwinnen die worden veroorzaakt door grote aantallen dimensies (bijvoorbeeld meer dan 15) en diepe niveaus van hiërarchieën (bijvoorbeeld 20 niveaus diep).

Als u producten evalueert, raakt u niet bezorgt over fysieke opslagtechnieken: zorg ervoor dat de logische weergaven die bij de producten worden geleverd (zoals de hiërarchieën, niveaus en feiten) aan uw bedrijfsbehoeften kunnen voldoen. Elimineer producten die onhandig lijken of die, bijvoorbeeld, een hiërarchiemodel hebben dat niet helemaal klopt voor uw gegevens.

Nadat u producten hebt gevonden die geschikt lijken voor uw bedrijf, kunt u de banden een beetje schoppen (om zo te zeggen) om te zien hoe ze binnen werken.