Applied Dimensionality

Enterprise PLanning Objects Naming Convention.

Posted at — May 16, 2008
Enterprise PLanning Objects Naming Convention.

As I’ve promised, here are naming conventions I tend to follow in EP projects.

Setting up naming rules doesn’t seem so crucial at project start, but generally hits on you on the head on final phase, when development turns to support. And trying to support your colleagues model will leave you thinking about naming objects the same way more than once ;) So naming conventions are one of main project documents for me now.

I really expect and encourage comments on this naming proposal. Maybe together we will create something like Sun Java Code Conventions )

Object Naming rule Example
Library Library names are not that important, though if you use Analyst with Contributor, consider creating stub libraries for importing data to\from Contributor, as I’ve described here. No data in skeleton library is a motto that will help you more than once, I assure you. Library codes are important if you want to keep a single store of projects (in consulting company, or competency center) and you’d better create some seeding rules for creating unique 9 numbers for projects. A simple scheme of xxxxyylll, where xs are project code, ys – library type and ls – library order number will be sufficient in most of cases. Sales_Planning_skl with code 777701001
Dlist The main difference with Cognos initial coding standard. Dlists are numbered not up by their functions, but by type calculations happening in this dlist. I’ve got initial table from Erik Thomsen’s OLAP book and modified it to suit EP better. So it goes like this: 1 - IF-ELSE formulas 2 - *,^, / * 3 - Common Sums * 4 - Timescale Sums * 5 - No calculations. Second difference: these numbers are used as suffixes of dlists names, not as prefixes. This allows quick search by first letter of dlist name when you’re browsing the library and all product dlists will be kept together, regardless of type. Third rule: only latin names with spaces substituted by _ (underscore). This guarantees that published tables will be named meaningfully and their names won’t mutate after time (a real problem with cyrillic dlist\dcube names). Balance_Sheet_1 Products_3 Months_4
Dlist item names One really useful hint: mark all calculation temporary elements (not to be seen user) with leading # symbol. This allows creating simple saved selection with filter that will easily hide all unnecessary elements from users in Contributor #temporary_allocation_element
DCubes Once again, only latin names with underscores to keep publish tables names sane. Contributor translations allow you to rename these cubes for end users with whatever names they’d like. No i\o\c, we’re out of kindergarten Product_Sales_Global
Dlinks “<” instead of “:” in separating source from target. And some hints like + when you’ve got an add link, - for subtract, to allow better understanding of link logic while viewing it in update list table. BalanceSheet<Cashflow(+)
Allocation Tables Similar to links, just the allocated dimensions with some commentary ProductGroups<Products
File Maps Whatever you like, I prefer filename pl_export.csv
Contributor Latin verbs or sentences describing what you’re doing with macro. Latin for running from command line. Update_Products_Export_Elists
Applications Rather strict rules are implied by Contributor itself, so i’d just advise to name aplications meaningfully, given that these names will always appear in browser connection string. No doubt that seeing “sales_plan_v8_will_it_ever_work” will inspire confidence. sales_plan_by_brands
Access Tables Access Tables should always be named. It’s best to write a short sentence, describing access table meaning Closing product list based on managers responsibility
Saved selections Plain common sense: explain what this selection selects ) Accounts_special_calc_items
Administration links Need suggestions here. Since Administration link is a pack of links, I use macro notation — verbs describing the process, but I put target application first sales_plan_by_brands update from regions
Macros Need suggestions here too. Again some action descriptions, but I don’t have a common approach of separating macros by applications they’re working with or smth like that. Moreover macros aren’t grouped anyhow, so I sometimes tend to prefix macros with some block group with following description Sales_submission sales by brands to sales by regions
System Links These are for users, so names should be descriptive actions Load new currency rates

Whoa, it’s a really huge document, maybe I’ll it finish someday…

comments powered by Disqus