Oracle DRM Blog

In the last part of our article, we talked about ways to automatically populate creation and update information for each node as they evolve. This is especially useful for building databases (e.g. slowly changing dimension). If you follow the last article, that’s probably enough to achieve the objective. Now, as you go from month to month, you will probably be creating new versions of hierarchies. When you’re creating a new version and you’re tracking changes, here’s a tip…

For those that are not familiar with versions, this is the way in which you can lock down a snapshot of a prior state. Why is this important? For example, it’s common in most companies to have a financial accounting close. During the close, accounting entries are often booked to the existing financial organizational structure. This is often represented in the ERP or inside the reporting tools. When the close is finished, a new financial period is open where more transactions can be added, and structures changed. In order to be able to preserve how the financial statement should look, you can lock down the current month version right after the close, and open a new version for newer changes. One simple advantage is you can build BI repositories for the past easily, and have a way to represent the past. This is even more useful whenever there’s a re-organization or merger/acquisition scenario. You see, in most of today’s BI system, for the purpose of speed, slowly changing dimension are rarely deployed properly. As a result, most of your Therefore, multiple versions of the same hierarchies are often kept inside of Oracle Hyperion DRM.

To create a new version of the existing hierarchies, you will right-click on the current version and select the “Copy as New…” option.

The system will prompt you for a new version name and description. Now, right underneath are two additional options.

• Clear Approval Properties
• Clear Changed Properties

Now the manual doesn’t tell you exactly how to use this, and while it’s tempting to check these boxes, you shouldn’t. If you want continuity in knowing who created each of the nodes and when, because you have set the “Change Tracking Properties we discussed in Part I”, then you want to leave these check boxes alone. When you click OK, the new version will carry over all those details. On the other hand, if you checked “Clear Changed Properties”, your new version will have NULL inside each of the change tracking properties.