How to rename PlanType (database) name in Hyperion Planning

Say you have a Hyperion Planning application “Candy” with Plan Types “PlanType2,” “PlanType3,” and your main database “NYC.”

However, you need are told to rename “NYC” to “Handy” so that the App-DB name would be Candy-Handy.

This is how you can achieve this.

Before making any changes, however, make sure that you have stopped all the Services on the app server. Not doing so may lock tables.

After stopping the services, log on to Oracle SQL Developer (I have Oracle 11G and SQL Developer). You log on to what DB you use.

Find the HSP_OBJECT table for the Schema User used for the Application Candy. Mine is called Candy_adm. So, I choose the HSP_OBJECT table under user Candy_adm.

In the HSP_OBJECT table, under column OBJECT_NAME, find the old database name that you want to rename. In this case, since, I have three plan types (NYC for PlanType1, and PlanType2 and PlanType3), they fall under column OBJECT_ID – 100, 101, and 102.

Rename NYC to Handy as you want the new database to be Handy. Save

Now, open table HSP_PLAN_TYPE.

Rename NYC to Handy. Save.

If you already have the old database (NYC) created in Essbase, go to EAS console and rename the name of the database as well.

Start EPM services in the app server (the ones that you had stopped).

Open the planning application Candy. You should be able to see the Handy database name instead of NYC.

Refresh DATABASE so that you have it in Essbase as well.

Essbase Hierarchy

Essbase, being a multidimensional OLAP tool, hierarchy is of utmost importance as aggregation in Essbase depends on its hierarchical structure. 
Under each dimension in Essbase, we see other members to branch out which further branch out to several others.
For example:
Year
      Qtr1
              Jan
              Feb
              Mar
      Qtr2
              Apr
              May
              Jun                     etc.

We can view Essbase hierarchy from three points of views: Genealogy, Generation, Level.

1. Genealogy: From this point of view, the member at the top most level is the ancestor of the one below it. In this example, Year is the ancestor of Jan, Feb. Jan is the descendant of Year. Year is the parent of Qtr1 and Qtr2, and Qtr1 and Qtr2 are the children of Year. Jan, Feb, and March are siblings. 

2. Generation: We also use G1, G2, G3, etc for generation reference. The member at the top is Generation1, so in this case, Year is G1 or generation1, followed by Qtr1 and Qtr2 being G2, and Jan to Jun being G3. So, G starts from 1 and increases as we drill down towards lower members in the hierarchy.

Level: Level reference works opposite to Generation reference and it starts with the number 0. This means the members at the lowest level in the hierarchy is Level 0 and the level increases as we go higher. In this example, Jan, Feb, Mar, etc are the bottom-level members, so they are Level 0 members. Qtr1 and Qtr2, in this example, are Level 1 members and Year Level 2. The bottom-level members are also referred to as leaf members.