Today’s post is from a request via Twitter by @timrcase who asked if I could talk about my naming conventions for objects in MicroStrategy. Everyone is going to have different opinions, and while there may be more tried and true or common methods, there’s really no wrong answer as long as it works for your environment. Just remember, that future generations will need to be able to find things, and when users become savvy enough to build their own reports, naming conventions will be critical.
First and foremost, I start out with the standard folder structure, with some exceptions. I try to place all objects in their pre-designated folders, such as Metrics, Filters, Schema, etc. These of course are all optional, as an Attribute living in the Metrics folder will work just as well as if it lives in the Attributes folder, but it’s a pretty common sense organizational structure. The Reports folder is the only special folder, since this is what the Web Shared Reports folder is mapped too, so anything here will be visible (by default at least) to Web users.
The Documents folder is the first exception to this rule. Honestly, I don’t know what this folder is for, since it’s not readily accessible via Web the way the Reports folder is. As such, that folder is always empty in my environments, and Documents co-exist with Reports for me. For Intelligent Cubes, I place them in their own sub folder below Public Objects as opposed to along with the Reports folder. This is just to keep them all in one place and out of the way.
Under the Reports folder, I like to create separate folders for each Department and Subject Area. This way, a user from Finance will know where to go for reports that will interest them, as opposed to a Sales user. I use Shortcuts in the event that there are reports that would be interesting to multiple groups, and I’ve very rarely used any kind of Report security so they’re all freely accessible to all users. This of course will depend on the nature of your data. Under each of those folders may be folders pertaining to a specific sub-subject when the folder starts to get full. I’ll also put hidden folders that contain all of the data sets for a Document to avoid the clutter in the main folders.
Then of course on top of all of these folder structures, I like to use a Portal Style Landing Page to really put the reports at the user’s finger tips. I’ve found this report organizational method always works the best in my projects.
Object Naming Conventions and Prefixes
For Facts, I like to leave their names matching the columns they’re coming from. Since these are objects that are not seen by the end users, I find that this makes the breadcrumb trail between MicroStrategy and the Database a little easier to follow. I organize these Facts in folders based on Subject Areas that they belong to just to make them easier to find.
For Attributes, I try to give these a standard business name as much as possible. In any young BI project, you’ll find that everyone calls it something different, and one of the biggest benefits from a BI project is the emergence of a data dictionary that standardizes terminology across the business. For properties like a Status or Category, I also prefix it with the dimension it’s related to. For example, Store, Store Status, Store Category, Store Size. This not only groups them together alphabetically, but differentiates ambiguous objects (like Status and Category) from other dimensions.
For Reports, I hate putting the name “Report” at the end (they’re all reports!). Just a little pet peeve, but I usually leave them off unless the users insist, (ie, “Store Sales” instead of “Store Sales Report”).
As previously stated, I like to keep objects in their designated folders, but I do break that rule quite often. For example, when I use “Report as Filters” when building reports, and I keep those in the Filters folder (even though they’re technically reports), and I prefix them with “(Filter)” since that’s their true intention.
If a Report has a very unique requirement for a type of calculation that involves some goofy metrics I’d never be able to use anywhere else, I’ll usually keep it locally with the Report under the Reports folder, as opposed to putting it in the Metrics folder. This is to keep the Metrics folder clean and make it easy to find common Metrics in there when needed. I’ll simply create a subfolder under where the Report is, hide it, and place all of those specific objects. I find that in maintaining the report, this makes it easier to find these rare objects as well.
I could probably drone on even longer than I have, but those are the main points. In the end, I want to make sure that objects are organized logically so someone that doesn’t live in the project like I do could browse to what they’re looking for, and that no two objects share the same name so that there isn’t any confusion when performing searches. Be open to accepting feedback from your colleagues and users, and whatever your standards may be, enforce them! Although there’s no wrong way to do it, if you have several developers doing it differently, then that’s wrong!