Given the complimentary nature of managed and Self-Service data environments, it's reasonable to assume that in most organizations, at least one data warehouse will exist and will be available as the primary source of information.
Prior to the introduction of Tabular Models, cubes were often implemented as the outermost information interface for reporting and analysis. This configuration provided preaggregated values, ad-hoc analysis functionality, and a central store for business calculations. However, the development and maintenance of the Cube is in the exclusive domain of IT, and the business calculations are written in the MultiDimensional eXpressions (MDX) language (not the easiest of languages to learn). So, cubes are the logical (multidimensional) extension of the managed data environment. They provide high quality information and are consistent as well as fast to query, but dependent on their defined relational sources and, as a result, often slow to respond to changing needs.
The Tabular Model, like cubes part of the Analysis Services platform and multidimensional in nature offers much greater flexibility for the introduction of new data sources and subsequent definition of new dimensions, attributes, and measures.
Note
No formal ETL or data modeling is required; so, turnaround times for updates are greatly reduced, and no MDX is needed in order to define calculated values, as this is done via the new language, Data Analysis Expressions (DAX). Though the DAX language is considered by many to be easier to learn and use than MDX, it is not, in its current version, as capable as MDX. So, while certain basic operations are easier to express in DAX compared to MDX, implementing complex calculations is much more difficult using DAX. Although this book isn't dedicated to MDX or DAX, you can learn about the useful constructs of these languages in Chapter 6, MDX and Chapter 10, DAX Calculations and Queries.
In most environments, both cubes and Tabular Models will be used as each provides a useful and specific set of functionality. Determining which should be used for a given set of requirements will depend on the particulars of those requirements, but the following checklist provides a high-level guideline for selecting the most appropriate tool.
A Cube is best if the following requirements are satisfied (not a comprehensive list, more of a top five):
You need Writeback functionality: Writeback is most commonly used for budgeting and what-if analysis. It's not the most widely used functionality but can be a very important part of some BI environments. This functionality is not currently supported in the Tabular Model.
You have complex calculations: It's difficult in DAX to create complex calculations, which are relatively straightforward in MDX.
You plan to have Named sets: Named sets are very useful and user friendly. However, they are not currently supported in Tabular Models.
You have Many-to-Many relationships: While many-to-many relationships are possible in Tabular Models, they are complicated to set up, whereas in cubes these relationships are native and relatively easy.
You will use Role Playing Dimensions: Like many-to-many relationships, Role Playing Dimensions are possible in Tabular Models, but they are complex to set up and also not very intuitive for users.
A Tabular Model is best if the following requirements are satisfied (again, not a comprehensive list):
You need the ability to quickly add additional or external data: The Tabular Model allows you to connect to a wide variety of sources, while the cube is far more constrained on its source requirements. The Tabular Model also offers greater data compression compared to the multidimensional model. Generally, the cycle for Tabular Model development will be shorter compared to that for multidimensional model development.
Your model is relatively simplistic: As mentioned earlier, complex design scenarios, such as many-to-many relationships as well as parent-child or role playing dimensions can be implemented with the Tabular Model, but it would require much greater effort compared to the effort with the multidimensional model.
Fastest possible query performance is required: The Tabular Model is entirely stored in memory, so it is very fast at query time. Note that cubes are cached as they are queried, so there is a point at which the Cube may match the Tabular Model for a similar query but, in most cases, the Tabular Model will outperform the Cube for sheer query speed.
You want to use Power View or intend to run reports at a low granularity of data: An add-in for SQL Server Reporting Services, Power View is an ad hoc visualization and analysis tool with which users may explore Power Pivot or the Tabular Model data in a familiar Office-like interface. Prior to SQL 2012 SP1, Power View could not use a Cube as a source. This is no longer a limitation with the release of SP1. The Tabular Model is also likely to be more efficient to retrieve data at low granularity, as opposed to retrieving just the summary values.
For additional information on the comparison between tabular and multidimensional models, refer to http://technet.microsoft.com/en-us/library/hh212940.aspx.