Oracle Data Relationship Management is a commonly misunderstood tool. Our expert data governance consultants continually see the same mistakes due to inexperience with the application. The good news is these mistakes can be fixed and your practices can be modified.
In this blog post, we’ll look at best practices for different components of DRM, including:
- Versions
- Hierarchies
- Nodes/Members
- Properties
- Queries & Validations
Versions
If you don’t already know, versions are containers for multiple hierarchies that enable period-by-period change control. Your old versions should be retained for history and audit purposes. Versions also can be copied to create a starting point for the next period’s master data and used for ad-hoc planning scenarios.
A version strategy is extremely important to DRM’s performance. We often see users with a single version that they make all their changes in — this will cause instability and malfunction in your DRM application. DRM was not designed to support an infinitely open “working” version.
Another issue we commonly see revolves around master data life cycle version status management. During month end close, we frequently see people open a version to put a copy of the previous month’s data so that they have a backup of their hierarchy. The problem with this is you’re not getting last month’s transaction history — you can’t see who made the changes and when. But there’s a different and better way to view your transaction history. When you open versions, you’ll see a baseline (which shouldn’t be messed with). There you can find all your transaction history without having to create a new version and clutter your application.
Hierarchies
DRM supports primary and alternate hierarchies, and you can create as many as you need. DRM also supports multiple member node mappings across different hierarchies — meaning you can relate information between different hierarchy structures.
Dimensions, domains, and hierarchies are terms often used interchangeably. When you hear someone say “dimension” or “domain,” it might imply multiple hierarchies. In DRM, the term “hierarchy” has a very specific meaning — a hierarchy is defined by its “top node” and the top node might also have a parent in an alternate hierarchy. Types of hierarchies include:
- Flat Lists
- Ragged/Natural
- Balanced
- ABBA DABBA
A node can be a member of multiple hierarchies, but nodes will always have the same descendants in alternate hierarchies.
Nodes/Members
DRM member nodes are “global,” meaning that once a member has been added to DRM you can insert the member into as many hierarchy structures you want within that version.
In DRM, thousands of records can be loaded in just a few minutes. After you complete the import, your hierarchies can be “blended” into final destination versions. The DRM blender is a piece of functionality that’s paired with the import — it allows any two hierarchy fragments to be merged. There are many ways to process this with many different options. When using blenders, you should use them in steps — process structural changes first and property attribute changes last.
DRM also supports shared nodes, but it won’t allow duplicates. Shared nodes exist only once but can be re-used in multiple locations in multiple hierarchies. As we discussed in the previous section, nodes will always have the same descendants.
Properties
Through properties, DRM reduces the amount of data you need to input. Properties are a very powerful tool; their definitions will span the entire repository and are visible to all versions, hierarchies, and nodes. Property definitions can also cross versions — making a change to a property definition can affect current and historical data.
If you don’t define your properties correctly, it can negatively impact your application. First and foremost, be sure to name your properties correctly — they can’t be named any way you want. “Custom.” must be at the beginning of all non-Oracle delivered properties.
Other things you need to consider about properties:
- Properties can be local, global, hierarchy, or version.
- Local properties can have different values for the same node in different hierarchies.
- Local properties may hold different values for shared nodes within a hierarchy.
- Any property that involves position in a hierarchy must be local.
- Global properties for any node have the same value everywhere that node is used.
Derived formulas used with properties and validations can greatly impact your overall system performance. To learn the five steps for improving system performance with formulas, watch the video.
Queries & Validations
DRM validations can be performed in batch, in real time, and on demand. When you run an export, you can run a specific validation and, if it fails, it won’t go to Essbase.
DRM Classic cannot test for the existence of a value until the record is committed or saved. However, you can use DRG for this type of user interfacing. DRG can also validate using an external database table.
We don’t tend to see many people using list/lookups, which can help you avoid unnecessary validations. You should also use consistent naming — standards for naming should be established before any DRM component is configured.
Want to discover more DRM best practices? Watch DRM Best Practices, Unlocked!
