What would be a best practice on documenting the assembly of a data cube, metric set, and maybe nuances of a dashboard? I tried a log, tried Excel, but as time goes by and urgent changes creep in, I'm losing the recollection of what and why. Anybody have a great idea how I can document what the essentials are? It's too labor intensive to slog through the details way-after-the-fact!
Documenting your own data cubes, metric sets, and filters
This is a very deep question, so I was hoping some people in the community will contribute ideas based on their experience.
The short and easy answer would be that, depending on the development life cycle you ended up with, there should be software designed specifically for this purpose. I believe any type of project management software can give at least a semi-decent result.
With that aside, it is essential that you start your solution development with a well documented KPI. We are using a KPI Definition table, in which you collect as much information as possible (Context of the measures, filtering, states, action, data sources, and any additional comments). This makes the initial design of data cubes and metric sets easier.
As for the urgent changes and their reasoning, you want to be detailed with leaving comments during every check in. If you then view the revision history, you get a good picture of the change and their timeline in development process.
Hope this helps.
I can share that I try to document my data cubes, metric sets and filters in Excel. I always leave myself with a revision history upon checking-in, but as you might imagine, one session might have too many changes to itemize in that brief area. I frequently exit without checking-in simply because I'm not done or don't want anybody to access a half-baked development.
The nature of my question is probably motivated by the distance between my changes, particularly when you pass a year, it's harder to recall the nuances of the change (given the often times cryptic revision history comment). While in the development cycle, it's not so hard to dial-in, but way beyond, the nuances become eurekas :-)
I even tried screen shots in my Excel doc, they take up too much real estate, and when I'm discussing the results with colleagues, neither navigating the Excel recap or the actual item in Dundas is easy.
Now I feel whiney like other developers: do want functional code, documentation, or delivery on time. Pick two. It's a hard life to document!
Most of my data cubes are pure sql queries that I can fully document.
Dashboards only thing I can say is name everything and I mean everything even rectangles, scripts layers, buttons. I also never just drag an data element onto a dashboard because it makes a metric set for you that you cannot find the references to until you promote it (if you do do this promote it name it and put it in the folder for that dashboard.
For notes on a dashboard the only thing I can think of is making a script and just have comments but that could get out of hand I would think. Might be ok for a few lines but I would note do more.
I can’t think of any other easy things right now. I not happy with the check in notes area. It is hard to read when you view the history.
I will ponder on it more if I come up with something other than a word or excel document I will repost.
I agree with James, we also build all cubes outside of DUNDAS based on SQL queries, OLAP and/or Microsoft SSAS Tabular. A great tool we're using for documenting MS SQL/ SSAS models and cubes is APEX SQLDoc.
We've also built a DUNDAS dashboard with a (own implemented) data input table component to document each session.
But automated, on-demand documenting via scripting would be great to have. Will think about this approach in more detail / put this on our TODO list and come back if I've a substantial script available.
I created an excel file with multiple tabs and then cells that link to each tab.
For example whenever I would create a new data cube it would go into my data cube tab. When I would create a new dashboard I would have a dashboard tab. This tab would have the dashboard name in one column and then every other column would be the name of a control on the dashboard. If that control used a data cube or a metric set it would be a linked cell to the appropriate tab and cell of my data cube used for that control.
I would do the same if my data cube was based on a stored procedure. The data cube would be linked to my "stored procedure" tab and the appropriate cell. This way I could easily figure out the source data of any control if there was an issue or changes needed to be made.
We're new to Dundas having just succesfully completed the alpha release on a data product. We, too, use SSAS or SQL rather than the Dundas database as we'd like to have the flexibility to use other tools, like Excel, to access the data.
Our documentation process for Dundas has been to make good use of the Dundas commit notes, commit often (we have separate dev, test, and production environments so half-baked commits aren't a problem). In addition, we sometimes use a DevNotes layer with a single HTML Label we can put notes about any unusual things done to that dashboard, known issues, etc. All our scripts are copy/pasted into a text editor and committed to a Git repository - this has been very handy for finding example code and a convenience when editing longer code blocks.
What I'd like to see is a way to get a non-binary export of dashboards / metric sets / etc. automatically on every commit. Better still would be a way for this to hook into Git automatically in Dundas, although we can manage this with a file watcher and script.
Question for Dundas: Are .DBIE files compressed text, i.e. JSON? If so, can we uncompress them using something off the shelf?
1 Like