People sometimes build bad data models. Rather than them doing more training (or asking me to help), you could build a tool that points out common problems.
The user would click a button, wait a minute or so, and then get a list of potential problems and suggested changes.
The tool would describe an example using their data that they can use to prove the problem (e.g. "filter a widget by Location and Date and then you see it's double counting the Dollars field"); that would be more motivating than an abstract argument. Not only can they debug themselves, doing so will be better than training for teaching them to design better data models.
Here are my ideas for issues to look for. They might not always indicate a problem, but you can point them out for the user to decide.
- Do they use a convention for distinguishing Fact and Dim tables? Typically "fact" and "dim" prefixes for table names.
- Does any widget use a dim-table field in an aggregation in a Values pane formulas?
- Does any widget use a fact-table field in a non-values pane, or as a members filter in a formula?
- Do any dim-tables join to a fact-table via another fact-table?
- Does any pair of tables have multiple relationship paths of the shortest length? (Should be only one short path and it shouldn't include a fact table, but there might be several longer ones via other fact tables.)
- Any many-to-many relationships? Sometimes this is intentional and the user is meant to select a single item from a dim-table, so maybe ignore it if all uses in widgets filter one side of the relationship.
