![]() You are right that there is no equivalent (in terms of backend implementation) to this in tabular, and it is not something that can be moved to the ETL. In my experience, most users don’t want to conceptualize time utility dimensions they just want the same logic applied to various measures and an easy way to get at it. I would instead create calculated measures that are sliced by members of the time-utility dimensions and expose the calculated measures to the users. Whenever I created time-utility dimensions, I seldom exposed them directly to the end user. The Business Intelligence Wizard in multidimensional uses this technique (or close to it) in many cases. Typical examples are classic BI calculations such as YTD, MTD, 12 month moving average, … reused across multiple measures by scoping on them. They allow the same business logic to be applied to multiple measures. This technique is often referred to as time-utility dimensions.Īll the multidimensional cubes I ever built extensively use time-utility dimensions. I do not consider the end-user business functionality delivered through scoping in multidimensional to implement a date-calculation dimension to be a fringe use case. Update – post from Marco Russo: Updates about Multidimensional vs Tabular One could also argue that, as new features are built into tabular, could be stuck with multidimensional and unable to leverage better tabular capabilities in the future. ![]() Conversely a project may encounter performance issues with multidimensional that were not anticipated at the start of the project. It is a valid statement that a project may need some of the features unsupported by tabular at a later date, which could be a problem. I think it is widely accepted that Microsoft is more likely to build new features and put future development investment into tabular than multidimensional.When a project chooses multidimensional or tabular, it is not possible to change your mind without starting development again.For a multi-terabyte data warehouse implementation like a, then yes but again this is a fringe use case. Also, more memory will only become more viable in the future. On the tabular memory limitation, many customers I’ve talked to are worried they won’t fit into memory when they are actually nowhere near the upper limit of what they can relatively easily get on a server (especially when limited to the required data). Scoped-cell assignments are in the potential showstopper list too, but in most cases if calculation logic is pushed to the ETL layer (where it belongs if not one of the strengths of the cube/tabular model like aggregated level calcs, or those which would cause a data explosion problem at the relational level, etc) to avoid the formula engine where possible, then DAX is a pretty capable and powerful language for calculations built into the tabular model. Other use cases may be showstoppers like unary operators and writeback, but not for the majority of implementations. How many implementations use these features because the developer thought they were cool rather than having any real business need? I think quite a few. Hand a solution to support that uses MDX stored procs, extensive scoped-cell assignments and they will struggle. This applies to many-to-many relationships, parent-child hierarchies, role-playing dimensions (can create multiple instances of same table), and various other items.įor what I’m calling the fringe use cases, the supportability of some of these does not make sense for many customers. And the business people are the ones that matter. On the workarounds, if the same functionality can be delivered to the business, they don’t care if we technical people see it as a “workaround” because it’s not delivered the same way we are used to. For most customers, having fast performance is more important than the unsupported features – which invariably either have “workarounds” or are fringe use cases. However, tabular does make sense for many customers today. ![]() Without saying anything too controversial, MS corporate BI has been playing second fiddle lately. The Excel-like DAX formula bar is, to put it politely, annoying. The tabular-model designer inherited from Power Pivot is sluggish for models with lots of tables. Decisions: PowerPivot, SSAS Tabular, or SSAS Multidimensional Model in SQL Server 2012įirst thing I would like to say is I agree that there is lots of work for tabular to catch up to the feature-rich multidimensional. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |