The calculation engine (aka Vertipaq) then answers queries against this heavily compressed data. In-memory imports and heavily compresses all of the data into a new database that is stored in memory, hence the name. Similar to how multidimensional has MOLAP and ROLAP, tabular has in-memory (aka import) and DirectQuery. Additional measures don’t increase the size of your database, nor do they increase processing time when you refresh your data. Rather than defining measures that only aggregate according to specified dimensions and attributes within those dimensions, measures in a tabular model are calculated against whatever they’re able to (usually defined by the relationships you create between your tables). In contrast to multidimensional “cubes”, in tabular you think in terms of “tables”. SQL Server or Oracle), and that query response times are much slower. The downside to ROLAP is that the underlying database must be relational (e.g. The benefits are that your data is always fresh and you don’t need additional storage for the OLAP database (because it doesn’t hold any of its own data, it just passes the queries on). In this mode instead of periodically processing and aggregating all of your data amongst the dimensions, you instead just perform them on an as needed basis or do pass-through (as in you pass the query from the OLAP database through to the underlying relational database). Well, then you’d deploy your multidimensional model in ROLAP mode (R for “relational”). What if you want your data to always be up to date? This type of multidimensional modelling is called MOLAP, as in Multidimensional Online Analytical Processing. When someone then queries your OLAP cube all they’re doing is querying a calculated number that might be rolled up from the lowest level dimensions. If you want to refresh the data every hour, you can set up a task to “process” the database by ingesting the data and performing all of the different aggregations against each combination of dimension. Within multidimensional you can choose how often you’ll perform the loading and processing from the underlying data. In doing this you’re developing a “cube”, with multiple different kinds of aggregations. In multidimensional you define different dimensions and then measures that will aggregate along those dimensions. To the user it doesn’t seem like there are two different types. This is because the newer tabular models were designed so that client applications don’t know whether they are querying a multidimensional or tabular model. The differences between the types of data models are mainly found when you’re authoring them. You can also develop tabular data models within Excel and Power BI workbooks that are embedded within the workbook (which is a great way to get started with Tabular). Tabular models can be deployed to SQL Server 2012 to the current version, as well as to Azure Analysis Services. Multidimensional models can be deployed to SQL Server all the way from SQL Server 7 (’98) to the current version. Standard client applications include Excel (via PivotTables, PivotCharts, and cube formulas), Power BI (via live connection and data import modes), and SQL Server Reporting Services. You can interact with these data models through different client applications, including custom developed applications via client libraries. While they can still do ad-hoc analysis of problems or experiments, they’re best suited for questions you’ll likely be asking again and again (or simple variants of the same question), such as “why were sales so low this month? Why does the company’s gross margin seem to be dropping? Why are my customer deliveries becoming less on time? How do you interact with them? First up, why even create a data model? In essence, they exist to assist you with recurring analysis of your data.
0 Comments
Leave a Reply. |