Oracle Hyperion DRM Basics | Defining a Property

Firstly Happy New Year and we hope that one of your New Year’s resolutions will be to embrace and deploy Oracle Hyperion DRM!

We want to start it by continuing with our technical blog series and to take a look at Properties within Oracle Hyperion Database Relationship Management (DRM).

As you will have seen in our previous technical post when you are implementing Oracle Hyperion DRM, your business masterdata will be stored as nodes within hierarchies.  Each node, hierarchy and version can have any number of attributes, which are stored as properties in Oracle Hyperion DRM. For example, if your core business concept was customer, then each customer’s address could represent an attribute, or property, of the customer. Off the shelf, DRM is configured with some core properties like name, description and level. However, the implementation process will define numerous custom properties according to the business requirements.

The previous technical post indicated how you can navigate in your hierarchies to see the properties of any node, hierarchy or version. We are now going to focus on the definition of these properties.

To create properties, navigate to “Administer”, then “New” and finally “Property Definition”. The screen below should appear!

Here is a list of the information you will require when creating a property:

1. “Name” – the system name for the property. It will not be visible to end users and should be unique to this property;

2. “Label” – the identifier that end users will see when they use DRM. So, while the name must be a unique identifier, the label should be informative and help the users understand the information they should enter;

3. “Description” – the purpose of the property;

4. “Data Type” – this permits you to select the type of data to be stored

5. “Property Level” – this will allow you to define the level at which the property will be used. The options are:

a)     Version – use this if you need the property to be global for the version;

b)     Hierarchy – use this if you need to store an attribute for the entire hierarchy;

c)     Global Node – use this option if you need to store an attribute of a node that should always be the same wherever it is. For example, the description is a global property. If you insert the same node in three different hierarchies, the node will always have the same description; and

d)     Local Node – use this option if you need to store an attribute that is unique to a node in a given hierarchy. For example, the node’s parent is a local property. The same node in two hierarchies can have two different parents.

6. “Property Type” – this allows you to define how your property should be populated. There are three options:

a)     Defined – users will define manually the value of this property;

b)     Lookup – the property will be populated according to another property according to a simple lookup table. If you select this option, the lookup table tab in the lower part of the screen will be enabled; and

c)     Derived – this property will then be populated according to a formula you will have to define in the parameter tab. We will see formulas later in posts dedicated to formulas.

7. “Default Value” – give your property a default value if necessary;

8. “Minimum Length” – set the property minimum length;

9. “Maximum Length” – set the property maximum length;

1o. “List” check box – if you select the “List” check box, the property will not be free form. Users will have to select a value from a list of valid values. The tab “List Values” will be enabled and you will be able to create the list of valid values;

11. “Inherited” check box – a defined property can be set to inherit the value across a hierarchy. So if a user sets the property against the parent node, the child nodes will automatically inherit the same value except if the property is manually overridden against a descendant; and

12. “Overridable” checkbox – this check box is only available for derived properties and indicates if end users can manually override the value of the property at lower levels of the hierarchy.

Finally, the bottom level tab “Categories” allows you to assign the property you are creating to property categories.

In the next technical blog we will introduce node types, which can be used to allow you to control what users see in Oracle Hyperion DRM. Until then please do not hesitate to reach out if you want to investigate Oracle Hyperion DRM’s potential.

This entry was posted in Technical and tagged , , , . Bookmark the permalink.

Comments are closed.