[Will Thompson] I've just merged a couple of very close scenarios, which all have similar great ideas! Something we're considering for the future, so I'm keen to hear your feedback on this. I like th...
In tabular modelling it is a very common (and useful) patterns to define "Parameter Tables" (see the pattern described here: http://www.daxpatterns.com/parameter-table/). In a way, those "tables" are a neat work-around as they don't technically contain a dimension of the database, but instead are created primarily for the purpose of creating slicers for users to interactively change the behavior of certain measures. Both, Excel and Power BI, as clients of tabular models already distinguish between two "types" of tables when representing the schema to users, even though both use slightly different semantics. Excel groups all measures from a given table into a distinct node and keeps them separate from the table's columns. Power BI displays a "measure group" node only when the containing table has no visible columns, otherwise it merges all measures and columns together into the same table node (which makes for a very poor user experience). Despite the differences, though, both effectively have a notion of "measure (only)" tables vs "dimensional" tables in terms of how the model is displayed to users. I would like to propose a change where data modelers can mark any table as a parameter table, to be used by the Power BI UI so that it would use a third type of icon (something like a slicer?) to represent those tables and keep them separate from tables that represent a genuine dimension of the data model. Especially when dealing with more complex models, this would enhance usability enormously, at a very low cost. The use case I'm targeting here is where there is an organisational split between data modelers and analysts/report builders - which should be fairly common in enterprise environments. Where the semantics of available models need to be communicated to consumers.
