Creating and Maintaining the Presentation Layer 11-15
For example, consider a subject area called Sample Sales Reduced that contains a presentation table called Facts Other. If you rename the presentation column called
of Customers to Number of Customers, any requests that use of Customers fail. However, if you add of Customers to the list of synonyms in the Alias tab for
the Number of Customers column, then queries containing both of Customers and Number of Customers succeed and return the same results.
Note the following:
■
Aliases for presentation objects do not appear in Answers or other query clients when creating new queries. Only the primary names of subject areas, hierarchies,
levels, tables, and columns appear.
■
This feature works in a different way from SQL aliases or the alias feature in the Physical layer. It simply provides synonyms for object names, much like
synonyms in SQL.
■
Aliases are created automatically when you rename presentation objects. For example, if you change Catalog to Catalog1, the original name Catalog is added to
the Aliases list.
■
You cannot rename a Presentation layer object to a name that is already in use as an alias for an object of the same type.
To add or delete an alias for a presentation object: 1.
In the Presentation layer, double-click a presentation object, such as a subject area, table, column, or hierarchy.
2.
Click the Aliases tab.
3. To add an alias, click the New button, and then type the text string to use for the
alias.
4. To delete an alias, select the alias you want to delete from the Aliases list, then
click the Delete button. 5.
Click OK.
11-16 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition
12
Creating and Persisting Aggregates for Oracle BI Server Queries 12-1
12
Creating and Persisting Aggregates for Oracle BI Server Queries
Most data warehouse practitioners create aggregated data tables to dramatically improve the performance of highly summarized queries. These aggregate tables store
precomputed results that are aggregated measures typically summed over a set of dimensional attributes. Using aggregate tables is a typical technique used to improve
query response times in decision support systems.
If you write SQL queries or use a tool that only understands what physical tables exist and not their meaning, then using aggregate tables becomes more complex as the
number of aggregate tables increases. The aggregate navigation capability of the Oracle BI Server allows queries to use the information stored in aggregate tables
automatically. The Oracle BI Server lets you concentrate on asking the right business question, and then the server decides which tables provide the fastest answers.
Oracle Business Intelligence has an aggregate navigation feature to take advantage of those aggregates in source databases for more information, see
Chapter 10 . However,
it can be time consuming to create and maintain the data aggregation, as well as load database scripts and the corresponding metadata mappings. For that reason, Oracle
Business Intelligence provides an aggregate persistence feature that automates the creation and loading of the aggregate tables and their corresponding Oracle Business
Intelligence metadata mappings.
This chapter explains how to set up and use aggregate persistence in Oracle Business Intelligence.
This chapter contains the following topics:
■
About Aggregate Persistence in Oracle Business Intelligence
■
Identifying Query Candidates for Aggregation
■
Using the Aggregate Persistence Wizard to Generate the Aggregate Specification
■
Writing the Create Aggregates Specification Manually
■
Running the Aggregate Specification Against the Oracle BI Server
■
Troubleshooting Aggregate Persistence
About Aggregate Persistence in Oracle Business Intelligence
Use the Aggregate Persistence feature to create aggregates for Oracle BI Server queries. The Aggregate Persistence Wizard lets you automate the creation of the
aggregate specification script. When you run this script against a live Oracle BI Server, aggregate tables are created and are mapped into the metadata for navigation. When
12-2 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition
aggregates are persisted, indexes and statistics are created on relational tables for greater performance.
The Aggregate Persistence Wizard creates a SQL script that you can run on a scheduled basis against the Oracle BI Server. In the Aggregate Persistence Wizard, you
specify the measures, dimensionality, and other parameters of each star or cube based on your performance design. The script should run after each load of the base-level
tables, so that the aggregates are always synchronized with the detail-level data when the load window completes and users begin to run queries.
Aggregate creation runs against the master server in a cluster. It takes some time for the metadata changes to propagate to the slaves. The cluster refresh time is a
user-controlled option and results might be incorrect if a query hits a slave server before it is refreshed. It is the administrators responsibility to set an appropriate
cluster refresh interval.
Aggregate persistence requires a dedicated connection pool to create tables or cubes in the target database that will hold the aggregates. Because the Oracle BI repository
enables federation, the aggregated target can be on the same database as the detailed source, or in a completely different database. This dedicated connection pool must be
created before you run the Aggregate Persistence Wizard, so it can be selected during the appropriate step of the wizard.
The default prefix SA_ is automatically added to dimension level aggregates. You can change this default prefix by updating the AGGREGATE_PREFIX parameter in the
AGGREGATE_PERSISTENCE section of the NQSConfig.INI file:
AGGREGATE_PREFIX = prefix_name ; The target schema used to store aggregates must be appropriately secured and should
not allow public access. The schema should have privileges to connect, create, and drop tables and indexes. By default, only users who belong to the BIAdministrators
group can manage aggregates.
Do not use aggregate persistence against tables with active Virtual Private Database VPD security filters. There is a possibility that the aggregate information might be
persisted without the VPD filter, posing a security risk.
Identifying Query Candidates for Aggregation
When creating aggregates, you must identify which queries would benefit substantially from aggregated data. You will achieve the best results by aggregating to
the highest level possible. To identify slow-running queries, perform the following tasks:
■
Enable usage tracking in the Oracle BI Server. Usage tracking statistics can be
used in a variety of ways, such as database optimization, aggregation strategies, and billing users or departments based on the resources they consume. The Oracle
BI Server tracks usage at the detailed query level. When you enable usage tracking, statistics for every query are written to a usage tracking log file or
inserted into a database table.
Note: It is strongly recommended that you use the direct insertion
into a database method for usage tracking. See Managing Usage Tracking in Oracle Fusion Middleware System Administrators Guide for
Oracle Business Intelligence Enterprise Edition for full information about usage tracking.
Creating and Persisting Aggregates for Oracle BI Server Queries 12-3
■
Analyze the query run times and identify the slowest running queries as candidates for aggregation.
The run time for creating aggregates is dependent on the type of aggregates selected by the user. Creating aggregates from large fact
tables is slower than from smaller tables. You should carefully select the aggregates to be created.
Using the Aggregate Persistence Wizard to Generate the Aggregate Specification
You can use the Aggregate Persistence Wizard to create the SQL file that will be used to create and load aggregate tables and map them into the metadata. The resulting
SQL file must be executed against a running Oracle BI Server.
To use the Aggregate Persistence Wizard: 1.
In the Administration Tool, select Tools Utilities Aggregate Persistence, and then click Execute.
2.
On the Select File Location screen, specify the complete path and file name of the aggregate creation script. You can specify a new or an existing file name.
Typically, when you run the SQL script against the Oracle BI Server, it creates DDL and runs it against the target database schema to create the aggregate tables,
then loads them from the source, and finally creates the Oracle BI Server metadata so the aggregate navigation feature can use the new tables.
Alternatively, you can select Generate target DDL in a separate file if you want the DDL to be stored in a separate file from the Oracle BI Server SQL script. When
you select this option, two SQL scripts are generated:
■
The create aggregates script script_name
■
The prepare aggregates script script_name_DDL Both files are stored in the following location:
ORACLE_INSTANCE \bifoundation\OracleBIServerComponent\coreapplication_obisn\
aggr
Selecting Generate target DDL in a separate file gives you the flexibility to alter the auto-generated DDL and run it independently of the Oracle BI Server. For
example, you may want to alter the storage parameter or index settings. When you select this option, you first make manual updates to the DDL file, then you run the
DDL file prepare aggregates, then you run the create aggregates script.
Click Next after you have finished specifying options on the Select File Location screen.
3.
In the Select Business Measures screen, select the measures on which you want to aggregate. To do this, select a business model in the upper pane, then select a
Note: It is strongly recommended that you use the Aggregate
Persistence Wizard because it automatically enforces many of the constraints necessary when generating the aggregate specification.
However, you can manually write the aggregate Logical SQL as an alternative to using the wizard. Make sure to follow the guidelines
described in
Writing the Create Aggregates Specification Manually if
you choose to write your own aggregates specification.
12-4 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition
single fact table or a set of measures in the lower pane. You cannot select measures that span multiple fact tables. Use Ctrl-click to select multiple measures, or use
Shift-click to select a range of consecutive measures.
Note that the View Script button is not available during the creation of the first aggregate table block.
Figure 12–1 shows the Select Business Measures screen.
Figure 12–1 Aggregate Persistence Wizard: Select Business Measures Screen
Click Next after you have selected the appropriate measures. 4.
In the Select Levels screen, specify the level of aggregation by selecting a logical level for one or more dimensions. You can specify a surrogate key to be used for
the fact-dimension join.
The default join option between the aggregated fact and dimension tables is the primary key defined in the logical level you selected. If the primary key of the
level is large and complex, the join to the fact table is expensive, so using a surrogate key is recommended in this case. A surrogate key is an artificially
generated key, usually a number. For example, a surrogate key in the level aggregate table would simplify this join, removing unnecessary level primary
key columns from the fact table and resulting in a leaner fact table.
Using a surrogate key only changes the query response time, not the logical results of the queries. However, generating the surrogate keys can have the side effect of
increasing the aggregate table load time. Therefore, the recommended setting is as follows:
– If the primary key for the logical level you have selected is already a single,
numeric column, you typically should not select the Use Surrogate Key option since it may add to load processing time without producing a
performance benefit.
– If the primary key for the logical level you have selected is a text string, or
consists of multiple logical columns, you typically should use a surrogate key
Creating and Persisting Aggregates for Oracle BI Server Queries 12-5
to improve the performance of the queries that join to that aggregate dimension. However, keep in mind that generating the surrogate key can
increase the load time for that aggregate dimension table.
See Adding Surrogate Keys to Dimension Aggregate Tables
for additional information about surrogate keys.
Figure 12–2 shows the Select Levels screen.
Figure 12–2 Aggregate Persistence Wizard: Select Levels Screen
Click Next after you have selected the appropriate level of aggregation. 5.
In the Select Connection Pool screen, select the appropriate items to specify a location for the aggregate table.
A default aggregate table name is provided, and a prefix is added to the table name. The default prefix for the generated fact table is ag. For tables created for
dimension level aggregates, the default prefix is SA_ and can be changed by updating the AGGREGATE_PREFIX property in NQSConfig.INI. See Oracle Fusion
Middleware System Administrators Guide for Oracle Business Intelligence Enterprise Edition for more information about changing configuration settings.
Figure 12–3 shows the Select Connection Pool screen.
12-6 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition
Figure 12–3 Aggregate Persistence Wizard: Select Connection Pool Screen
Click Next after you have provided connection pool information. 6.
In the Finish screen, the View Script button becomes available for use, and the Logical SQL script appears for your review. Choose whether to define another
aggregate default or end the wizard, and then click Next.
7. In the Finish Script screen, the complete path and file name appears. Click Finish.
