This chapter explains how to design a data model and create dimensions and cubes using Analytic Workspace Manager. It contains the following topics:
Chapter 1 introduced the dimensional objects: Cubes, measures, dimensions, levels, hierarchies, and attributes. In this chapter, you will learn how to define them in Oracle Database, but first you need to decide upon the dimensional model you want to create. What are your measures? What are your dimensions? How can you distinguish between a dimension and an attribute in your data? You can design a dimensional model using pencil and paper, a database design software package, or any other method that suits you.
If your source data is already in a star or snowflake schema, then you already have the elements of a dimensional model:
Fact tables correspond to cubes.
Data columns in the fact tables correspond to measures.
Foreign key constraints in the fact tables identify the dimension tables.
Dimension tables identify the dimensions.
Primary keys in the dimension tables identify the base-level dimension members.
Parent columns in the dimension tables identify the higher level dimension members.
Columns in the dimension tables containing descriptions and characteristics of the dimension members identify the attributes.
You can also get insights into the dimensional model by looking at the reports currently being generated from the source data. The reports will identify the levels of aggregation that interest the report consumers, as well as the attributes used to qualify the data.
While investigating your source data, you may decide to create relational views that more closely match the dimensional model that you plan to create.
Analytic Workspace Manager is the primary tool for creating, developing, and managing dimensional objects in Oracle Database. Your goal in using Analytic Workspace Manager is to create a dimensional data store that supports business analysis. This data store can stand alone or store summary data as part of a relational data warehouse.
Populating dimensional objects involves a physical transformation of the data. The first step in that transformation is defining the cubes, measures, dimensions, levels, hierarchies, and attributes. Afterward, you can map these dimensional objects to their relational data sources. The data loading process transforms the data from a relational format into a dimensional format.
Develop a dimensional model of your data.
Instantiate that model as dimensional objects.
Load data from relational tables into those objects.
Define information-rich calculations.
Create materialized views that can be used by the database refresh system.
Automatically generate relational views of the dimensional objects.
You must have
SELECT privileges on the relational data sources so you can load the data into the dimensions and cubes. This chapter assumes that you have a star, snowflake, or other relational schema that supports dimensional objects.
Figure 3-1 shows the main window of Analytic Workspace Manager. It contains menus, a toolbar, a navigation tree, and property sheets. When you select an object in the navigation tree, the property sheet to the right provides detailed information about that object. When you right-click an object, you get a choice of menu items with appropriate actions for that object.
Analytic Workspace Manager has a full online Help system, which includes context-sensitive Help.
An analytic workspace is a container for storing related cubes. You create dimensions, cubes, and other dimensional objects within the context of an analytic workspace.
Open Analytic Workspace Manager and connect to your database instance as the user defined for this purpose.
Create a new analytic workspace in the database:
In the navigation tree, expand the folders until you see the schema where you want to create the analytic workspace.
Right-click Analytic Workspaces, then choose Create Analytic Workspace.
Complete the Create Analytic Workspace dialog box, then choose Create.
The new analytic workspace appears in the Analytic Workspaces folder for the schema.
Define the dimensions for the data.
Define the cubes for the data.
See "Creating Cubes".
Load data into the cubes and dimensions.
When you have finished, you will have an analytic workspace populated with the detail data fetched from relational tables or views. You may also have summarized data and calculated measures.
Develop custom cube scripts to customize the builds.
Generate materialized views that support automatic refresh and query rewrite.
Support multiple languages by adding translations of metadata and attribute values.
Define measure folders to simplify access for end users.
Saves occur when you take an action such as these:
Click OK or the equivalent button in a dialog box.
For example, when you click Create in the Create Dimension dialog box, the new dimension is committed to the database.
Click Apply in a property sheet.
For example, when you change the labels on the General property page for an object, the change takes effect when you click Apply.
Dimensions are lists of unique values that identify and categorize data. They form the edges of a cube, and thus of the measures within the cube. In a report, the dimension values (or their descriptive attributes) provide labels for the rows and columns.
You can define dimensions that have any of these common forms:
Level-based dimensions that use parent-child relationships to group members into levels. Most dimensions are level-based.
Value-based dimensions that have parent-child relationships among their members, but these relationships do not form meaningful levels.
List or flat dimensions that have no levels or hierarchies.
Every dimension member must be a unique value. Depending on your data, you can create a dimension that uses either natural keys or surrogate keys from the relational sources for its members. If you have any doubt that the values are unique across all levels, then keep the default choice of surrogate keys.
Source keys are read from the relational sources without modification. To use the same exact keys as the source data, the values must be unique across levels. Because each level may be mapped to a different relational column, this uniqueness may not be enforced in the source data. For example, a dimension table might have a Day column with values of
366 and a Week column with values of
52. Unless you take steps to assure uniqueness, the values from the Week column will overwrite the first 52 Day values.
Surrogate keys ensure uniqueness by adding a level prefix to the members while loading them into the analytic workspace. For the previous example, surrogate keys create two dimension members named
WEEK_1, instead of a single member named
1. A dimension that has surrogate keys must be defined with at least one level-based hierarchy.
Analytic Workspace Manager creates surrogate keys unless you specify otherwise.
You can define dimensions as either User or Time dimensions. Business analysis is performed on historical data, so fully defined time periods are vital. A time dimension table must have columns for period end dates and time span. These required attributes support comparisons with earlier or later time periods. If this information is not available, then you can define Time as a User dimension, but it will not support time-based analysis.
You must define a Time dimension with at least one level to support time-based analysis, such as a custom measure that calculates the difference from the prior period.
Expand the folder for the analytic workspace.
Right-click Dimensions, then choose Create Dimension.
The Create Dimension dialog box is displayed.
Complete the General tab.
If the keys in the source table are unique across levels, you can change the default setting on the Implementation Details tab.
The new dimension appears as a subfolder under Dimensions.
Figure 3-2 shows the creation of the Product dimension.
For business analysis, data is typically summarized by level. For example, your database may contain daily snapshots of a transactional database. Days are the base level. You might summarize this data at the weekly, quarterly, and yearly levels.
Levels have parent-child or one-to-many relationships, which form a level-based hierarchy. For example, each week summarizes seven days, each quarter summarizes 13 weeks, and each year summarizes four quarters. This hierarchical structure enables analysts to detect trends at the higher levels, then drill down to the lower levels to identify factors that contributed to a trend.
For each level that you define, you must identify a data source for dimension members at that level. Members at all levels are stored in the same dimension. In the previous example, the Time dimension contains members for weeks, quarters, and years.
Expand the folder for the dimension.
Right-click Levels, then choose Create Level.
The Create Level dialog box is displayed.
Complete the General tab of the Create Level dialog box.
The new level appears as an item in the Levels folder.
Tip:Alternatively, you can create levels in the Create Dimension dialog box Levels tab.
Figure 3-3 shows the creation of the Class level for the Product dimension.
Most hierarchies are level-based. Analytic Workspace Manager supports these common types of level-based hierarchies:
Normal hierarchies consist of one or more levels of aggregation. Members roll up into the next higher level in a many-to-one relationship, and these members roll up into the next higher level, and so forth to the top level.
Ragged hierarchies contain at least one member with a different base, creating a "ragged" base level for the hierarchy. Ragged hierarchies are not supported for cube materialized views.
Skip-level hierarchies contain at least one member whose parents are more than one level above it, creating a hole in the hierarchy. An example of a skip-level hierarchy is City-State-Country, where at least one city has a country as its parent (for example, Washington D.C. in the United States).
In relational source tables, a skip-level hierarchy may contain nulls in the level columns. Skip-level hierarchies are not supported for cube materialized views.
Multiple hierarchies for a dimension typically share the base-level dimension members and then branch into separate hierarchies. They can share the top level if they use all the same base members and use the same aggregation operators. Otherwise, they need different top levels to store different aggregate values. For example, a Customer dimension may have multiple hierarchies that include all base-level customers and are summed to a shared top level. However, a Time dimension with calendar and fiscal hierarchies must aggregate to separate Calendar Year (January to December) and Fiscal Year (July to June) levels, because they use different selections of base-level members.
You may also have dimensions with parent-child relations that do not support levels. For example, an employee dimension might have a parent-child relation that identifies each employee's supervisor. However, levels that group together first-, second-, and third-level supervisors and so forth may not be meaningful for analysis. Similarly, you might have a line-item dimension with members that cannot be grouped into meaningful levels. In this situation, you can create a value-based hierarchy defined by the parent-child relations, which does not have named levels. You can create value-based hierarchies only for dimensions that use the source keys, because surrogate keys are formed with the names of the levels.
Expand the folder for the dimension.
Right-click Hierarchies, then choose Create Hierarchy.
The Create Hierarchy dialog box is displayed.
Complete the General tab of the Create Hierarchy dialog box.
Click Help for information about these choices.
The new hierarchy appears as an item in the Hierarchies folder.
Figure 3-4 shows the creation of the Primary hierarchy for the Product dimension.
Attributes provide information about the individual members of a dimension. They are used for labeling crosstabular and graphical data displays, selecting data, organizing dimension members, and so forth.
Analytic Workspace Manager creates some attributes automatically when creating a dimension. These attributes have a unique type, such as "Long Description."
All dimensions are created with long and short description attributes. If your source tables include long and short descriptions, then you can map the attributes to the appropriate columns. However, if your source tables include only one set of descriptions, then you can map the long description attributes. If you map the short description attributes to the same column, the data will be loaded twice.
You can create additional "User" attributes that provide supplementary information about the dimension members, such as the addresses and telephone numbers of customers, or the color and sizes of products.
Expand the folder for the dimension.
Right-click Attributes, then choose Create Attribute.
The Create Attribute dialog box is displayed.
Complete the General tab of the Create Attribute dialog box.
Some attributes apply to all dimension members, and others apply to only one level. Your selection in the Apply Attributes To box controls the mapping of the attribute to one column or to more than one.
Click Help for information about these choices.
To change the data type from the default choice of
VARCHAR2, complete the Implementation Details tab.
The new attribute appears as an item in the Attributes folder.
Figure 3-5 shows the creation of the Marketing Manager attribute for the Product dimension. Notice that this attribute applies only to the Item level.
Materialized views require that each dimension of the cube have unique key attributes. These attributes store the original key values of the source dimensions, which may have been changed when creating the embedded total dimensions of the cubes.
Mapping identifies the relational data source for each dimensional object. After mapping a dimension to a column of a relational table or view, you can load the data. You can create, map, and load each dimension individually, or perform each step for all dimensions before proceeding to the next step.
The mapping window has a tabular view and a graphical view. You can switch between the two views, using the icons at the top of the canvas.
Tabular view: Drag-and-drop the names of individual columns from the schema navigation tree to the rows for the dimensional objects.
Graphical view: Drag-and-drop icons, which represent tables and views, from the schema navigation tree onto the mapping canvas. Then draw lines from the columns to the dimensional objects.
You can use expressions when mapping dimensions in the tabular view. This capability enables you to create the top level of a dimension without having a source column in the dimension table.
Click Help on the Mapping window for more information.
In the navigation tree, expand the dimension folder and click Mappings.
The Mapping window contains a schema navigation tree on the left and a mapping table for the dimension with rows for the levels and their attributes. This is the tabular view.
To enlarge the Mapping Window, drag the divider to the left.
In the schema tree, expand the tables, views, or synonyms that contain the dimension members and attributes.
Drag-and-drop the source columns onto the appropriate cells in the mapping table for the dimension.
After you have mapped all levels and attributes, click Apply.
Drag the divider back to the right to reveal the navigation tree.
Figure 3-6 shows the Product dimension mapped in the tabular view. The arrow highlights how the
PRODUCT_DIM.ITEM_BUYER column maps to the
You can view the contents of a particular source column without leaving the mapping window. The information is readily available, eliminating the guesswork when the names are not adequately descriptive.
Right-click the source object in either the schema tree or the graphical view of the mapping canvas.
Choose View Data from the pop-up menu.
Figure 3-7 shows the data stored in the
Analytic Workspace Manager provides several ways to load data into dimensional objects. The quickest way when developing a data model is using the default choices of the Maintenance Wizard. Other methods may be more appropriate in a production environment than the one shown here. They are discussed in "Choosing a Data Maintenance Method".
In the navigation tree, right-click the Dimensions folder or the folder for a particular dimension.
Choose Maintain Dimension.
The Maintenance Wizard opens on the Select Objects page.
Select one or more dimensions from Available Target Objects and use the shuttle buttons to move them to Selected Target Objects.
Click Finish to load the dimension values immediately.
The additional pages of the wizard enable you to create a SQL script or submit the load to the Oracle job queue. To use these options, click Next instead.
Errors are typically caused by problems in the mapping. Check for incomplete mappings or changes to the source objects.
Figure 3-8 shows the first page of the Maintenance Wizard. Only the Product dimension has been selected for maintenance. All the Product dimension members and attributes will be fetched from the mapped relational sources.
The Maintenance Wizard automatically generates relational views of dimensions and hierarchies. Chapter 4 describes these views and explains how to query them.
Figure 3-9 shows the description of the relational view of the Product Primary hierarchy. You can view the data on the Data tab.
In the navigation tree, right-click the name of a dimension.
Choose View Data.
Figure 3-10 shows the Primary hierarchy of the Product dimension.
Cubes are informational objects that identify measures with the exact same dimensions and thus are candidates for being processed together at all stages: data loading, aggregation, storage, and querying.
Expand the folder for the analytic workspace.
Right-click Cubes, then choose Create Cube.
The Create Cube dialog box is displayed.
On the General tab, enter a name for the cube and select its dimensions.
On the Aggregation tab, click the Rules subtab and select an aggregation method for each dimension. If the cube uses more than one method, then you may need to specify the order in which the dimensions are aggregated to get the desired results.
You can ignore the bottom of the tab, unless you want to exclude a hierarchy from the aggregation.
If you run the advisors after mapping the cube, Oracle OLAP can determine the best partitioning and storage options. However, if you want to define these options yourself, then complete the Partitioning and Storage tabs before creating the cube.
Click Create. The new cube appears as a subfolder under Cubes.
Figure 3-11 shows the Rules subtab for the Units cube with the list of operators displayed.
See Also:"Aggregation Operators" for descriptions of the aggregation operators
Measures store the facts collected about your business. Each measure belongs to a particular cube, and thus shares particular characteristics with other measures in the cube, such as the same dimensions. The default characteristics of a measure are inherited from the cube.
Expand the folder for the cube that has the dimensions of the new measure.
Right-click Measures, then choose Create Measure.
The Create Measure dialog box is displayed.
On the General tab, enter a name for the measure.
The new measure appears in the navigation tree as an item in the Measures folder.
Figure 3-12 shows the General tab of the Create Measure dialog box.
You use the same interface to map cubes as you did to map dimensions, as described in "Mapping Dimensions".
You can use expressions when mapping cubes in the tabular view. This capability enables you to perform tasks like these as part of data maintenance, without any intermediate staging of the data:
Perform calculations on the relational data using any combination of functions and operators available in the OLAP expression syntax.
Create measures that are more aggregate than their relational sources. For example, suppose the Time dimension has columns for Day, Month, Quarter, and Year, and the fact table for Sales is related to Time by the Day foreign key column. In a basic mapping, you would store data in the cube at the Day level. However, you could aggregate it to the Month level during the data refresh. Using a technique called one-up mapping, you would map the cube to the Month column for Time, and specify a join between the dimension table and the fact table on the Day columns.
Click Help on the Mapping window for more information about these techniques.
In the navigation tree, expand the cube folder and click Mappings.
The Mapping window contains a schema navigation tree on the left and a mapping table for the cube and its dimensions. This is the tabular view.
To enlarge the Mapping window, drag the divider to the left.
In the schema tree, expand the tables, views, or synonyms that contain the data for the measures.
Drag-and-drop the source columns onto the appropriate cells in the mapping table for the cube.
After you have mapped all dimensions and measures, click Apply.
Drag the divider back to the right to reduce the size of the Mapping window.
Figure 3-13 shows the mapping canvas with the Units cube mapped to columns in the
UNITS_FACT table. After you save the mappings, Analytic Workspace Manager provides the join conditions for base-level mappings such as the ones shown here.
Improves scalability by keeping data structures small. Each partition functions like a smaller measure.
Keeps the working set of data smaller both for queries and maintenance, since the relevant data is stored together.
Enables parallel aggregation during data maintenance. Each partition can be aggregated by a separate process.
Simplifies removal of old data from storage. Old partitions can be dropped, and new partitions can be added.
The number of partitions affects the database resources that can be allocated to loading and aggregating the data in a cube. Partitions can be aggregated simultaneously when sufficient resources have been allocated.
The Cube Partitioning Advisor analyzes the source tables and develops a partitioning strategy. You can accept the recommendations of the Cube Partitioning Advisor, or you can make your own decisions about partitioning.
Note:Run the Cube Partitioning Advisor after mapping the cube to a data source and before loading the data. You can change the partitioning strategy at any time using the Cube Partitioning Advisor, but you will need to reload the data afterward.
You can specify your own partitioning strategy only when creating the cube.
If your partitioning strategy is driven primarily by life-cycle management considerations, then you should partition the cube on the Time dimension. Old time periods can then be dropped as a unit, and new time periods added as a new partition. In Figure 3-15, for instance, the Quarter level of the Time dimension is used as the partitioning key. The Cube Partitioning Advisor has a Time option, which will recommend a hierarchy and a level in the Time dimension for partitioning.
If life-cycle management is not a primary consideration, then run the Cube Partitioning Advisor and choose the Statistics option. The Cube Partitioning Advisor will develop a strategy designed to achieve optimal build and query performance.
Map the cube to its data source, if you have not done so already.
On the navigation tree, select the cube to display its property pages.
On the Partitioning tab, click Cube Partitioning Advisor.
Choose Partition Using a Time Dimension or Partition Using Statistics.
Wait while the Cube Partitioning Advisor analyzes the cube. When it is done, the Cube Partitioning Advisor displays its recommendations.
Evaluate the recommendations of the Cube Partitioning Advisor.
Select Accept Partition Advice to accept the recommendations. The cube will be re-created with the new partitions.
Clear the Accept Partition Advice box to reject the recommendations.
Figure 3-14 shows the Cube Partitioning Advisor dialog box.
The Cube Partitioning Advisor might recommend partitioning at the Quarter level of the Calendar hierarchy of the Time dimension. Each Quarter and its descendants are stored in a separate partition. If there are three years of data in the analytic workspace, then partitioning on Quarter produces 12 bottom partitions, in addition to the default top partition. The top partition contains all remaining levels, that is, those above Quarter (such as Year) and those in other hierarchies (such as Fiscal Year or Year-to-Date).
Figure 3-15 illustrates a Time dimension partitioned by Quarter.
You load data into cubes using the same methods as dimensions. However, loading and aggregating the data for your business measures typically takes more time to complete. Unless you are developing a dimensional model using a small sample of data, you may prefer to run the build in one or more background processes.
In the navigation tree, right-click the Cubes folder or the name of a particular cube.
Choose Maintain Cube.
The Maintenance Wizard opens on the Select Objects page.
Select one or more cubes from Available Target Objects and use the shuttle buttons to move them to Selected Target Objects. If the dimensions are already loaded, you can omit them from Selected Target Objects.
On the Dimension Data Processing Options page, you can keep the default values.
On the Task Processing Options page, you can submit the build to the Oracle job queue or create a SQL script that you can run outside of Analytic Workspace Manager.
You can also select the number of processes to dedicate to this build. The number of parallel processes is limited by the smallest of these numbers: The number of partitions in the cube, the number of processes dedicated to the build, and the setting of the
JOB_QUEUE_PROCESSES initialization parameter.
Click Help for information about these choices.
Figure 3-16 shows the build submitted immediately to the Oracle job queue.
In the navigation tree, right-click the cube.
Choose View Data from the pop-up menu.
The Measure Data Viewer displays the selected measure in a crosstab at the top of the page and a graph at the bottom of the page. On the crosstab, you can expand and collapse the dimension hierarchies that label the rows and columns. You can also change the location of a dimension by pivoting or swapping it. If you wish, you can use more than one dimension to label the columns and rows, by nesting one dimension under another.
To pivot, drag a dimension from one location and drop it at another location, usually above or below another dimension.
To swap dimensions, drag and drop one dimension directly over another dimension, so they exchange locations.
To make extensive changes to the selection of data, choose Query Builder from the File menu.
Figure 3-17 shows the Units cube in the Measure Viewer.
The Maintenance Wizard automatically generates relational views of a cube. Chapter 4 describes these views and explains how to query them.
Figure 3-18 shows the description of the relational view of the Units cube.
While developing a dimensional model of your data, mapping and loading each object immediately after you create it is a good idea. That way, you can detect and correct any errors that you made to the object definition or the mapping.
However, in a production environment, you want to perform routine maintenance as quickly and easily as possible. For this stage, you can choose among data maintenance methods.
You can refresh all cubes using the Maintenance Wizard. This wizard enables you to refresh a cube immediately, or submit the refresh as a job to the Oracle job queue, or generate a PL/SQL script. You can run the script manually or using a scheduling utility, such as Oracle Enterprise Manager Scheduler or the
DBMS_SCHEDULER PL/SQL package.
The data for a partitioned cube will be loaded and aggregated in parallel when multiple processes have been allocated to the build. You will be able to see this in the build log.
In addition, each cube can support these data maintenance methods:
Custom cube scripts
Cube materialized views
If you are defining cubes to replace existing materialized views, then you will use the materialized views as an integral part of data maintenance. Materialized view capabilities restrict the types of analytics that can be performed by a custom cube script.
A cube script is an ordered list of steps that prepare a cube for querying. Each step represents a particular data transformation. By specifying the order in which these steps are performed, you can allow for interdependencies.
Each cube automatically has a default cube script named Load_and_Aggregate that loads the data and aggregates it using the rules defined on the cube. You can define any number of additional scripts and designate one of them as the default cube script. All methods of refreshing a cube execute the default cube script. You can execute other cube scripts manually using the Maintenance Wizard.
Clear Data: Clears the data from the entire cube, from selected measures, or from selected portions of the cube. You can clear just the detail data (called leaves) for a fast refresh, just the aggregate data, or both for a complete refresh. Clearing old data values is typically done before loading new values.
Analyze: Generates optimizer statistics, which can improve the performance of some types of queries. For more information, see "Analyzing Cubes and Dimensions". Generating statistics is typically done at the end of data maintenance.
If a cube is used to support advanced analytics in a cube script, then it cannot be enhanced as a cube materialized view, as described in "Adding Materialized View Capability to a Cube". In this case, you are responsible for detecting when the data in the cube is stale and needs to be refreshed.
Expand the folder for a cube.
Right-click Cube Scripts, then choose Create Cube Script.
The Create Cube Script dialog box is displayed.
On the General tab, enter a name for the cube script.
To create a new step, click New Step.
Choose the type of step.
The New Step dialog box is displayed for that type of step.
Complete the tabs, then click OK.
The new step is listed on the Cube Script General tab.
The new cube script appears as an item in the Cube Script folder.
To run the cube script:
Right-click the cube script on the navigation tree, and choose Run Cube Script.
The Maintenance Wizard opens.
Follow the steps of the wizard.
To view the results, right-click the cube and choose View Data.
Figure 3-19 shows the Create Cube Script dialog box, in which several steps have already been defined.
Oracle OLAP cubes can be enhanced with materialized view capabilities. They can be incrementally refreshed through the Oracle Database materialized view subsystem, and they can serve as targets for transparent rewrite of queries against the source tables. A cube that has been enhanced in this way is called a cube materialized view.
The OLAP dimensions associated with a cube materialized view are also defined with materialized view capabilities.
A cube must conform to these requirements, before it can be designated as a cube materialized view:
All dimensions of the cube have at least one level and one hierarchy. Ragged and skip-level hierarchies are not supported.
All dimensions of the cube use the same aggregation operator, which is either
The cube is fully defined and mapped. For example, if the cube has five measures, then all five are mapped to the source tables.
The detail tables support dimension and rely constraints. If they have not been defined, then use the Relational Schema Advisor to generate a script that defines them on the detail tables.
The cube is compressed.
The cube can be enriched with calculated measures, but it cannot support more advanced analytics in a cube script.
See Also:"Cube Materialized Views"
In the navigation tree, select a cube.
The property sheets for the cube are displayed.
Choose the Materialized Views tab.
Review the check list and, if some tests failed, fix the cause of the problem.
You cannot define a cube materialized view until the cube is valid.
For automatic refresh, complete just the top half of the page. For query rewrite, complete the entire page.
Click Help for information about the choices on this page.
The cube materialized views appear in the same schema as the analytic workspace. A materialized view is created for the cube and each of its dimensions. Cube materialized views do not store data; the data is stored in the cube. A
CB$ prefix identifies the tables as cube materialized views.
The initial state of a new materialized view is stale, so it will not support query rewrite until after it is refreshed. You can specify the first refresh time on the Materialized View tab of the cube, or you can run the Maintenance Wizard.
Figure 3-20 shows the Materialized View tab of the Units Cube. It specifies an automatic refresh of the data every Thursday at 10:00 P.M.
A single analytic workspace can support multiple languages. This support enables users of OLAP applications and tools to view the metadata in their native languages. For example, you can provide translations for the display names of measures, cubes, and dimensions. You can also map attributes to multiple columns, one for each language.
The number and choice of languages is restricted only by the database character set and your ability to provide translated text. Languages can be added or removed at any time.
In the navigation tree, expand the folder for the analytic workspace.
Select Languages to display its property page.
On the General tab, click Modify Languages.
On the Modify Languages dialog box, select the languages that you want the analytic workspace to support. Use the shuttle keys to move them to the Selected Languages box.
Click OK to return to the Languages property page.
Enter the translations of the various labels and descriptions. Each language has a column where you can enter this information.
For each dimension, open the Mappings window. Map the attributes to the source columns for each language.
Measure folders organize and label groups of measures. Users may have access to several analytic workspaces or relational schemas with measures named Sales or Costs, and measure folders provide a way for applications to differentiate among them.
Expand the folder for the analytic workspace.
Right-click Measure Folders, then choose Create Measure Folder from the pop-up menu.
Complete the General tab of the Create Measure Folder dialog box.
Click Help for specific information about these choices.
The new measure folder appears in the navigation tree under Measure Folders. You can also create subfolders.
Figure 3-21 shows creation of a measure folder.
Analytic Workspace Manager enables you to save all or part of the data model as a text file. This text file contains the XML definitions of the dimensional objects, such as dimensions, levels, hierarchies, attributes, and measures. Only the metadata is saved, not the data. Templates are small files, so you can easily distribute them by email or on a Web site, just as the templates for Global and Sales History are distributed on the Oracle Web site. To re-create the dimensional objects, you simply identify the templates in Analytic Workspace Manager.
You can save the following types of objects as XML templates:
Analytic workspace: Saves all dimensional objects. You can save measure folders only by saving the complete analytic workspace.
Dimension: Saves the dimension and its levels, hierarchies, attributes, and mappings.
Cube: Saves the cube and its measures, calculated measures, cube scripts, and mappings.
You can save the template in anywhere on your local system.
In the navigation tree, right-click an analytic workspace, a dimension, or a cube, and choose Save object to Template.
In the navigation tree, right-click Analytic Workspaces and choose Create Analytic Workspace From Template.
Create or open an analytic workspace.
In the navigation tree, right-click Dimensions or Cubes and choose Create object From Template.