Essbase® Analytic Services Database Administrator's Guide | | Update Contents | Previous | Next | Print | ? | |
Information Map | |
When you build a new partition, each database in the partition uses a partition definition file to record all information about the partition, such as its data source and data target and the areas to share. You must have Database Designer permissions or higher to create a partition.
Note: The information in this chapter is designed for block storage databases. Some of the information is not relevant to aggregate storage databases. For detailed information on the differences between aggregate and block storage, see Comparison of Aggregate and Block Storage. For information on creating aggregate storage applications, see Aggregate Storage Applications, Databases, and Outlines.
This chapter contains the following sections that describe how to create a replicated, transparent, or linked partition:
Caution: You must design partitions carefully. Hyperion strongly recommends that you read Designing Partitioned Applications, before creating partitions.
After you create a partition, you must maintain the partition. This chapter contains the following sections that describe how to maintain an existing partition:
Here is the suggested process for creating database partitions.
When you create a partition, choose one of the following types:
To choose a partition type, see "Specifying the Partition Type and Settings" in the Essbase Administration Services Online Help.
You must set up the data source and the data target, including specifying their location, entering notes about each one (optional), and specifying the source outline.
To set up the data source and the data target:
Specify the names of the Analytic Server, application, and database to use as the data source. See "Specifying Connection Information for Partitions" in the Essbase Administration Services Online Help.
Specify the names of the Analytic Server, application, and database to use as the data target. See "Specifying Connection Information for Partitions" in the Essbase Administration Services Online Help.
Note: Do not use network aliases, such as localhost, for the data source or data target names unless you are certain that they are propagated to all computers on your system. If you're not certain, use the full server name. This is especially important for linked partitions, because this is the host name that clients connected to the data target use to find the data source.
See "Specifying Connection Information for Partitions" in the Essbase Administration Services Online Help.
By default, all changes made on the data source outline overwrite the data target outline when you synchronize the outlines. You can, however, specify that changes made to the data target outline overwrite the data source outline when you synchronize the outlines. For more information, see Synchronizing Outlines.
You must specify a user name and password for Analytic Services to use when communicating between the data source and the data target. The user name and password must be identical on both the data source and the data target. Analytic Services uses this user name and password to:
For more information, see Planning for Security for Partitioned Databases.
To set the user name and password for the data source and the data target, see "Specifying Connection Information for Partitions" in Essbase Administration Services Online Help.
You can define or edit the areas of the data source to share with the data target in a partition. An area is a subcube within a database. For example, an area could be all Measures at the lowest level for Actual data in the Eastern region. A partition is composed of one or more areas.
When you define a replicated area, make sure that both the data source and data target contain the same number of cells. This verifies that the two partitions have the same shape. For example, if the area covers 18 cells in the data source, the data target should contain an area covering 18 cells into which to put those values. The cell count does not include the cells of attribute dimensions.
For more information on partition areas, see Determining Which Data to Partition.
Note: Use member names instead of their aliases to create area definitions. Although Analytic Services validates the aliases, the partitions will not work.
To define a partition area, see "Defining Areas in Partitions" in Essbase Administration Services Online Help.
To create a partition, Analytic Services must be able to map all shared data source members to data target members. Hyperion recommends that data source member names and data target member names are the same to reduce the maintenance requirements for the partition, especially when the partition is based on member attributes.
If the data source and the data target contain the same number of members and use the same member names, Analytic Services automatically maps the members. You need only validate, save, and test the partitions, as described in Validating Partitions, Saving Partitions, and Testing Partitions. If Analytic Services cannot map automatically, you must map manually.
Map data source members to data target members in any of the following ways:
To map members, see "Defining Global Mappings in Partitions" in Essbase Administration Services Online Help.
The following sections provide details about mapping members:
If the data source outline and data target outline contain different members or if the members have different names in each outline, you must map the data source members to the data target members. In the following example, the first two member names are identical, but the third member name is different:
Source | Target |
---|---|
Because you know that East in the data source corresponds to East_Region in the data target, map East to East_Region. Then, all references to East_Region in the data target point to East in the data source. For example, if the data value for Cola, 1998, East is 15 in the data source, the data value for Cola, 1998, East_Region is 15 in the data target.
The number of dimensions in the data source and data target may vary. The following example illustrates a case where there are more dimensions in the data source outline than in the data target outline:
Source | Target |
---|---|
If you want to map member 1997 of the Year dimension from the data source to the data target, you can map it to Void in the data target. But first, you must define the areas of the data source to share with the data target:
Source | Target |
---|---|
You can then map the data source member to Void in the data target:
Source | Target |
---|---|
"Void" is displayed automatically; entering "Void" yourself may cause errors.
If you do not include at least one member from the extra dimension in the area definition, you will receive an error message when you attempt to validate the partition.
Note: When you map a member from an extra dimension, the partition results reflect data only for the mapped member. In the above example, the Year dimension contains three members: 1999, 1998, and 1997. If you map member 1997 from the data source to the data target, then the partition results reflect Product and Market data only for 1997. Product and Market data for 1998 and 1999 will not be extracted.
The following example illustrates a case where the data target includes more dimensions than the data source:
Source | Target |
---|---|
In such cases, you must first define the shared areas of the data source and the data target:
Source | Target |
---|---|
You can then map member East from the Market dimension of the data target to Void in the data source:
Source | Target |
---|---|
If member East from the Market dimension in the data target is not included in the target areas definition, you will receive an error message when you attempt to validate the partition.
When you create a replicated or transparent partition using a shared member, use the real member names in the mapping. Analytic Services maps the real member, not the shared one, from the data source.
You can import member mappings from a text file. Mapping files must end in .txt
. A sample member file must contain all of the following (except extra columns):
Figure 80: Member Mapping Import File
To import member mappings, see "Importing Member Mappings for Partitions" in Essbase Administration Services Online Help.
You must accurately map attribute dimensions and members from the data source to the data target to ensure that the partition is valid.
Note: You cannot map members of attributes dimension in replicated partitions. For more information, refer to Rules for Replicated Partitions. You can, however, map attributes in transparent and linked partitions. For information on using attributes in partitions, see Attributes in Partitions.
In the following example, the outline for the data source contains a Product dimension with a member 100 (Cola). Children 100-10 and 100-20 are associated with member TRUE of the Caffeinated attribute dimension, and child 100-30 is associated with member FALSE of the Caffeinated attribute dimension.
The data target outline has a Product dimension with a member 200 (Cola). Children 200-10 and 200-20 are associated with member Yes of the With_Caffeine attribute dimension, and child 200-30 is associated with No of the With_Caffeine attribute dimension.
First define the areas to be shared from the data source to the data target:
Source | Target |
---|---|
Then map attributes as follows:
Source | Target |
---|---|
If you map attribute Caffeinated_True to attribute With_Caffeine_No, you receive an error message during validation. You must associate caffeinated cola from the data source to caffeinated cola in the data target.
There can be instances where an attribute dimension or an attribute member exists in the outline of the data source but not in the outline of the data target, or vice versa. For example:
Source | Target |
---|---|
In such cases, you have the following choices:
For a comprehensive discussion of attributes, see Working with Attributes. For a general discussion of attributes in partitions, see Attributes in Partitions.
If you can map all of the members in your data source to their counterparts in the data target using standard member mapping, then you don't need to perform advanced area-specific mapping.
If, however, you need to control how Analytic Services maps members at a more granular level, you may need to use area-specific mapping. Area-specific mapping maps members in one area to members in another area only in the context of a particular area map.
Use area-to-area mapping when you want to:
Since Analytic Services cannot determine how to map multiple members in the data source to a single member in the data target, you must logically determine how to divide your data until you can apply one mapping rule to that subset of the data. Then use that rule in the context of area-specific mapping to map the members.
To create area-specific mappings, see "Defining Area-Specific Member Mappings in Partitions (Optional)" in Essbase Administration Services Online Help.
The data source and data target contain the following dimensions and members:
Source | Target |
---|---|
The data source does not have a Scenario dimension. Instead, it assumes that past data is actual data and future data is forecast, or budget, data.
You know that 1998 in the data source should correspond to 1998, Actual in the data target and 1999 in the data source should correspond to 1999, Budget in the data target. So, for example, if the data value for Cola, East, 1998 in the data source is 15, then the data value for Cola, East, 1998, Actual in the data target should be 15.
Because mapping works on members, not member combinations, you cannot simply map 1998 to 1998, Actual. You must define the area (1998 and 1998, Actual) and then create area-specific mapping rules for that area.
Because the data source does not have Actual and Budget members, you must also map these members to Void in the data target.
You can also use advanced area-specific mapping if the data source and data target are structured very differently but contain the same kind of information.
This strategy works, for example, if your data source and data target contain the following dimensions and members:
Source | Target |
---|---|
You know that NY and Actual in the data source should correspond to NY_Actual in the data target and NY and Budget in the data source should correspond to NY_Budget in the data target. So, for example, if the data value for NY, Budget in the data source is 28, then the data value for NY_Budget in the data target should be 28.
Because mapping works on members, not member combinations, you cannot simply map NY, Actual to NY_Actual. You must define the area (NY and Actual, and NY_Actual) and then create area-specific mapping rules for that area.
Because the data target does not have NY and CA members, you must also map these members to Void in the data target so that the dimensionality is complete when going from the data source to the data target.
When you create a partition, validate it to ensure that it is accurate before you use it. In order to validate a partition, you must have Database Designer permissions or higher. After you validate, save the partition definition. If necessary, you can edit an existing partition.
When Analytic Services validates a partition definition, it checks on the Analytic Server for the data source and the data target to ensure that:
After you validate, save the partition. When you save a partition, the partition definition is saved to two different .ddb
files, on both the data source server and the data target server.
To validate a partition, use any of the following methods:
Tool |
Topic |
Location |
---|---|---|
After you validate the partition definition, you can save the partition definition to any of the following locations:
.ddb
files..ddb
file.To save a partition definition, see "Saving Partitions" in the Essbase Administration Services Online Help.
Here is the suggested process for maintaining database partitions.
When you partition a database, Analytic Services must be able to map each dimension and member in the data source outline to the appropriate dimension and member in the data target outline. After you map the two outlines to each other, Analytic Services can make the data in the data source available from the data target as long as the outlines are synchronized and the partition definitions are up-to-date.
If you make changes to one of the outlines, the two outlines are no longer synchronized. Although Analytic Services does try to make whatever changes it can to replicated and transparent partitions when the outlines are not synchronized, Analytic Services may not be able to make the data in the data source available in the data target.
However, Analytic Services tracks changes that you make to your outlines and provides tools to make it easy to keep your outlines synchronized.
This section describes Analytic Services synchronizes outlines.
Before you can synchronize your outlines, you must determine which outline is the source outline and which is the target outline.
By default, the source outline is from the same database as the data source; that is, outline and data changes flow in the same direction. For example, if the East database is the data source and the Company database is the data target, then the default source outline is East.
You can also use the data target outline as the source outline. You might want to do this if the structure of the outline (its dimensions, members, and properties) is maintained centrally at a corporate level, while the data values in the outline are maintained at the regional level (for example, East). This allows the database administrator to make changes in the Company outline and apply those changes to each regional outline when she synchronizes the outline.
Analytic Services updates as many changes as possible to the target outline. If Analytic Services cannot apply all changes, a warning message prompts you to see the application log for details. Messages that pertain to outline synchronization are prefixed with OUTLINE SYNC. For more information, see in Viewing the Analytic Server and Application Logs.
To set the source outline, see Setting up the Data Source and the Data Target.
To synchronize outlines, use any of the following methods:
Tool |
Topic |
Location |
---|---|---|
Note: For synchronizing non-Unicode-mode outlines with multi-byte characters, you can use only non-Unicode clients such as ESSCMD or MaxL statements executed through the MaxL Shell.
Note: Outline synchronization cannot be performed on an outline containing a Dynamic Calc member that has many (approximately 100 or more) children.
The following table describes what happens when you change the source outline and then synchronize the target outline with the source outline:
Caution: If you choose not to apply some changes, you cannot apply those changes later.
An actual member and its shared members in the source outline are propagated to the target outline if at least one actual or shared member is defined in the partition area. In illustrated in Figure 81, the partition definition is @IDESC("Diet"). The parent 100 and its children (100-10, 100-20, 100-30) are not defined in the partition area. The parent Diet and its children (100-10, 100-20, 100-30) are defined in the partition area. The children of Diet are shared members of the actual members.
Figure 81: Shared Members and Outline Synchronization
If you make a change to an actual member in the undefined partition area, such as adding an alias to the 100-10 actual member, that change is propagated to the target outline because it is associated with a shared member in the defined partition area.
The reverse is also true. If a shared member is not in the partition area and its actual member is, a change to the shared member in the undefined area is propagated to the target outline.
Any change made to a member that does not have at least one actual member (or shared member) in the defined partition area is not propagated to the target outline. For example, in Figure 81, a change to the parent 100 is not propagated to the target outline because it is in the undefined partition area and does not have an associated shared member in the defined partition area.
If a shared member is included in the partition area, then it is recommended to include its parent. In the above example, the parent Diet is included in the outline because its children are shared members and in the defined partition area.
Implied shared members are treated the same as shared members during outline synchronization. Actual members and their implied shared members in the source outline are propagated to the target outline if at least one actual or implied shared member is defined in the partition definition.
Using the partition definition as @CHILD("A") in the example in Figure 82, A1 and A2 are in the defined partition area, and A11, A21, A22 are in the undefined partition area. Although A11 (implied shared member) is in the undefined partition area, a change to A11 is propagated to the target outline because its parent, A1, is in the defined partition area. The change to the children A21 and A22 is not propagated to the target outline because these members are not defined in the partition area and are not associated with a member that is in the defined partition area.
Figure 82: Implied Shared Members and Outline Synchronization
The reverse is true again. If A1 is not defined in the partition area and its implied shared member is, then any change to A1 is propagated to the target outline.
The database administrator should regularly update data in a replicated partition. How frequently you update replicated partitions depends on users' requirements for up-to-the-minute data. Analytic Services keeps track of when the data source was last changed and when the data target was last updated so that you can determine when to update replicated partitions. This information is saved at the data source. Either database administrator-that of the data source site or that of the data target site-can be responsible for replicating data.
Analytic Services also tracks which cells in a partition are changed. You can choose to update:
Note: If you've deleted data blocks on the data source, Analytic Services updates all data cells at the data target even if you choose to update only changed cells. You can delete data blocks at the data source by using the CLEARDATA command in a calculation script; using "Clear combinations" in your rules file during a data load; issuing CLEAR UPPER, CLEAR INPUT or RESETDB commands in Administration Services; restructuring the database keeping only level 0 or input data; or deleting sparse members.
To update a replicated partition, use any of the following methods:
Tool |
Topic |
Location |
---|---|---|
You can edit and delete existing partitions. When you edit a partition, you use the same interface that you used to create the partition, making modifications as necessary.
When you delete a partition, Analytic Services deletes the partition definition from the .ddb
file on the data source and data target servers.
To edit or delete a partition, see "Opening the Create or Edit Partition Window" and "Deleting Partitions" in Essbase Administration Services Online Help.
To view information about a partition, use any of the following methods:
Tool |
Topic |
Location |
---|---|---|
The following table lists common problems that you may encounter when using partitions.
![]() |