Creating Tabular Models using AMO

Question

Hi,
   I am trying to setup Tabular Models on SSAS using AMO referring to the materials available at Technet and the Codeplex AMO Tabular Tutorial. I have a few questions/issues
currently and was hoping I could get some help from here. The tool I am working with currently supports Multidimensional mode via AMO and I am trying to extend most of its features from the Multidimensional model. So, some of the questions might not exactly
fit into the Tabular model and if so, please do point them out.
RELATIONSHIPS: While creating relationships among tables,
would it suffice to create the relationship in the Data Source View Schema (as the tool currently does for the Multidimensional mode) or should we explicitly create relationships under the dimensions that we create to represent the table in Tabular mode? The
latter is the approach mentioned in the tutorial and I wanted to know if there is any difference between the relationships created using the 2 methods.
MEASURES: I am trying to create measures using Native
OLAP Measure objects in the Tabular model. I understand the shortcomings of this type of measures but I would still need to create them for basic aggregation functions like SUMMATION, COUNTS etc… I tried creating the measures using the same Measure Group that
was created to represent the table and used a ColumnBinding to the Measure’s source-column for the measure object’s source property but I get the following error:
Binding for VertiPaq measure MEASURE_NAME in measure group MEASURE_GROUP_NAME is invalid because it does not match any property binding of the fact dimension
TABLE_NAME
Am I missing anything here? Is there a better way of creating OLAP measures in TABULAR model without using the default Table dimensions that we create?
HIERARCHIES: I tried creating new Dimensions to hold
hierarchies for a table but when creating them, I get the error about MISSING ROWNUMBER attribute. Is this attribute mandatory for every dimension that is created?
To avoid this problem, I used the same dimension that was created to represent the table and tried adding inter-table attribute relationships to it but I get the following exception
message which I cannot figure out.
VertiPaq property ‘’ cannot have a name binding.
In general, can we create separate measure groups and dimensions, apart from the ones we use to represent the table, to store the custom measures and hierarchies? Is this a recommended
approach? This way, I am trying to keep things in parallel with the Multidimensional model that our tool currently supports but when I create such individual dimensions and measure groups, I get an error on the mismatch between the number of measure groups
and dimensions in the table.
   Please bear with the long list of questions. I could not find any help online for these and so am posting them all here.
Thank you.

Answer 1

RELATIONSHIPS: While creating relationships among tables,
would it suffice to create the relationship in the Data Source View Schema (as the tool currently does for the Multidimensional mode) or should we explicitly create relationships under the dimensions that we create to represent the table in Tabular mode? The
latter is the approach mentioned in the tutorial and I wanted to know if there is any difference between the relationships created using the 2 methods.
No - relationships in the DSV have no impact on the end model. You need to explicitly create relationships between your dimensions and measure groups for them to be picked up as relationships in your tabular model.
MEASURES: I am trying to create measures using Native OLAP
Measure objects in the Tabular model. I understand the shortcomings of this type of measures but I would still need to create them for basic aggregation functions like SUMMATION, COUNTS etc… I tried creating the measures using the same Measure Group that was
created to represent the table and used a ColumnBinding to the Measure’s source-column for the measure object’s source property but I get the following error:
Binding for VertiPaq measure MEASURE_NAME in measure group MEASURE_GROUP_NAME is invalid because it does not match any property binding of the fact dimension TABLE_NAME
Am I missing anything here? Is there a better way of creating OLAP measures in TABULAR model without using the default Table dimensions that we create?
There is no concept of native measures in a Tabular model. You need to create all your measures as "Calculated Measures" in AMO, but using the appropriate DAX expressions instead of MDX.
HIERARCHIES: I tried creating new Dimensions to hold hierarchies
for a table but when creating them, I get the error about MISSING ROWNUMBER attribute. Is this attribute mandatory for every dimension that is created?
To avoid this problem, I used the same dimension that was created to represent the table and tried adding inter-table attribute relationships to it but I get the following exception message
which I cannot figure out.
VertiPaq property ‘’ cannot have a name binding.
Yes, I believe every table needs the hidden RowNumber attribute. The
TableAddEmptyTable function in the tabular AMO sample on codeplex shows you how to create this.
In general, can we create separate measure groups and dimensions, apart from the ones we use to represent the table, to store the custom measures and hierarchies? Is this a recommended
approach? This way, I am trying to keep things in parallel with the Multidimensional model that our tool currently supports but when I create such individual dimensions and measure groups, I get an error on the mismatch between the number of measure groups
and dimensions in the table.
No you can't create any extra structures. Tabular projects only supports a subset of AMO. You need to follow the example on codeplex very closely and read all the code comments if you are making changes because it's very easy to break things.
My suggestion is to create an abstraction layer either using the TabularAMO library from codeplex as it is or creating your own library if you only need a subset of the functionality. This will mean that your core code is not too tightly bound to AMO. The
reason for this is that I would hope that MS will replace AMO with something better for Tabular models in a coming release and having a clear abstraction layer should make it easier to update to a new API.
http://darren.gosbell.com - please mark correct answers