Bi what is a cube

View Guide Now. View Customer Stories. Speak to an Expert What to expect minute discovery call with a product expert. Discover which solutions are best suited for your needs.

Live demo tailored to your business requirements. No high pressure sales pitch. Prospective Customer Current Customer Partner. Yes No. Yemen Zambia Zimbabwe. I agree to receive digital communications from insightsoftware containing, news, product information, promotions, or event invitations.

I understand that I can withdraw my consent at any time. This field is for validation purposes and should be left unchanged. Related Resources. Drag any measure or dimension onto a metric set or dashboard canvas, and the metric set will be based directly on the OLAP cube. A cube perspective lets you define a subset of a native OLAP cube.

This is an optional item you can create in order to limit the measures and dimensions available to users when creating corresponding metric sets, dashboards, reports, etc.

Dundas Data Visualization, Inc. Overview This article outlines the overall data model in Dundas BI. The natural progression here is that the more dimensions you wanted to analyze, the more nested arrays you would use: a 3-dimensional array is a list of list of lists, a 4-dimensional array is a list of list of list of lists, and so on.

Because nested arrays exist in all the major programming languages, the idea of loading data into such a data structure was an obvious one for the designers of early BI systems. Early BI systems decided to do the next logical thing: they aggregated and then cached subsets of data within the nested array — and occasionally persisted parts of the nested array to disk.

The impact of the OLAP cube was profound — and changed the practice of business intelligence to this very day. For starters, nearly all analysis began to be done within such cubes. This in turn meant that new cubes often had to be created whenever a new report or a new analysis was required. Say you want to run a report on car sales by province. OLAP cube usage also meant that data teams had to manage complicated pipelines to transform data from an SQL database into these cubes.

If you were working with a large amount of data, such transformation tasks could take a long time to complete, so a common practice would be to run all ETL extract-transform-load pipelines before the analysts came in to work. This approach, of course, became more problematic as companies globalized, and opened offices in multiple timezones that demanded access to the same analytical systems.

Using OLAP cubes in this manner also meant that SQL databases and data warehouses had to be organized in away that made for easier cube creation. If you became a data analyst in the previous two decades, for instance, it was highly likely that you were trained in the arcane arts of Kimball dimensional modeling , Inmon-style entity-relationship modeling, or data vault modeling. Kimball, Inmon and their peers observed that certain access patterns occured in every business.

They also observed that a slap-dash approach to data organization was a terrible idea, given the amount of time data teams spent creating new cubes for reporting. Eventually, these early practitioners developed repeatable methods to turn business reporting requirements into data warehouse designs — designs that would make it easier for teams to extract the data they need in the formats they need for their OLAP cubes.

These constraints have shaped the form and function of data teams for the better part of four decades. It is important to understand that very real technological constraints lead to the creation of the OLAP cube, and the demands of the OLAP cube led to the emergence of data team practices that we take for granted today. For instance, we:. Today, however, many of the constraints that lead to the creation of the data cube have loosened somewhat.

Computers are faster. Memory is cheap. The cloud works. And data practitioners are beginning to see that OLAP cubes come with a number of problems of their own. What would this world look like? This is stupidly obvious: why bother going through an extra step of building and generating new cubes when you can simply write queries in an existing SQL database?

Why bother maintaining a complex tapestry of pipelines if the data you need for reporting could be copied blindly from your OLTP database into your OLAP database? And why bother training your analysts in anything other than SQL? If you were an analyst in this situation, you would feel powerless to meet your deadlines. Your business users would block on you; you would block on your data engineers; and your data engineer would most likely be grappling with the complexity of your data infrastructure.

This is bad for everyone. Better to avoid the complexity completely. Second, if we lived in an alternate world where compute was cheap and memory was plentiful … well, we would ditch serious data modeling efforts. This sounds ridiculous until you think about it from a first principles perspective. We model data according to rigorous frameworks like Kimball or Inmon because we must regularly construct OLAP cubes for our analyses.

Historically, this meant a period of serious schema design.