Print      Open PDF Version of Online Help

Analytics > Designing an Analysis > Getting Started with Analytics > Selecting Subject Areas

Previous Topic

Next Topic

Selecting Subject Areas

To select a subject area for a report, click the Analytics tab and then click Analysis in the Create pane.

The Select Subject Area page contains two categories of subject areas: Historical Analytics and Real-time Reporting. The subject areas in the Historical Analytics category generate reports that are historical and that show trend analyses, based on data that is refreshed nightly. The subject areas in the Real-time Reporting category provide up-to-the-second data analyses and real-time information.

Subject areas represent information pertinent to a particular area of the business, or the reporting and analysis needs of a particular audience. Subject area names correspond to the type of information that they contain, such as dimension objects (record types) and fact metrics, which the business users want to analyze. Subject area names organize and categorize this information in various folders.

Historical Analytics Subject Areas

The following links provide detailed information on each subject area, including its business purpose, its relationship type (one-to-one, one-to-many, many-to-many, and so on), and a listing of the dimensions and metrics that are available:

Real-time Reporting Subject Areas

The following links provide detailed information on each subject area, including its business purpose, its relationship type (one-to-one, one-to-many, many-to-many, and so on), and a listing of the dimensions and metrics that are available:

The following table shows the five types of subject areas that Analytics uses.

Subject Area Type

Description

Simple

This subject area type consists of a single fact table that contains all the metrics of the driving record type. The report always provides a result that can be understood. In other words, whatever combination of attributes and metrics you select for your report, the report always returns a result that reflects the data in Oracle CRM On Demand.

Simple subject areas are appropriate when you want to report on a single set of metrics. They allow you to drill down on the detail in transactional data.

Multifact

This subject area type consists of two or more fact tables at different dimensional levels. The fact tables are joined by conformed (shared) dimensions. Multifact allows you to perform combined fact analysis.

Not all dimensions have a relationship with all the fact tables. For example, the quota metric table has a relationship only with the Owned By User, Quota, and the Date dimensions. These dimensions are also called conforming dimensions in dimensional-modeling terminology. In a multifact subject area, if you select attributes from a dimension and a metric from a fact, and they have no direct relationship with each other, then your report will not work correctly. In some cases, the metric field is empty, or an error appears in the report.

Multifact subject areas are appropriate when you want to report on multiple, yet related, sets of metrics.

Summary

This subject area type consists of a single summarized fact table. It allows you to perform summary analysis of metrics using a key dimension. It is called summary, because it provides summary information for a specific dimension or record type in Oracle CRM On Demand analytics, such as the Account record type. From this subject area, you can obtain all the CRM functionality related metrics, such as sales revenue, service request, activity, and lead metrics.

Summary subject areas are appropriate when you want summaries of metrics, using a key dimension, but without analyzing these metrics, using other dimensions.

Many-to-Many (M:M)

This subject area type represents both many-to-many and one-to-many relationships between two record types. It contains a fact table but it might also be a subject area without a fact table.

The one-to-many relationship between Custom Object 01 and Account can also be reported from this subject area. However, if you want to report on the many-to-one relationship between Account and Custom Object 01, then do not use this subject area. The Custom Object 01 subject area, which is a simple design subject area, allows you to report on all of the many-to-one relationships between all the standard record types and Custom Object 01.

The Many-to-Many subject areas are the only ones that you can use to report on the many-to-many and one-to-many relationships between record types.

Federated

This subject area type allows you to report on both one-to-many and many-to-one relationships between the Custom Object record types and other record types, but not on many-to-many relationships.

The first four types of subject areas mentioned (Simple, Multifact, Summary, and Many-to-Many) are standard subject areas. The fifth type of subject area is a federated subject area for custom objects.

Standard Subject Areas

Standard subject areas are intended to report on the relationship among standard record types, including Custom Objects 01, 02, and 03. Standard record types and Custom Objects 01, 02, and 03 can have the following relationships:

  • One-to-many
  • Many-to-one
  • Many-to-many

Oracle CRM On Demand provides dedicated subject areas that allow the reporting of a many-to-one relationship between a standard record type and other record types. For example, the Opportunities subject area allows the reporting of an opportunity record type’s relationship with other record types. Dedicated subject areas also allow the reporting of a many-to-many relationship between two record types. For example, the Opportunity and Partner History subject area allows the reporting of a many-to-many relationship between opportunity and partner record types.

Federated Subject Areas

There are two Federated subject areas:

  • The Advanced Custom Objects Real-Time Reporting subject area allows you to report on the relationships between Custom Objects 04 through 40 and multiple other record types, including Custom Objects 01, 02, and 03. All types of relationships can be reported on using this subject area, except for the many-to-many relationship between Custom Objects 04 through 40 and other record types, which is not supported directly by Oracle CRM On Demand.

    The Advanced Custom Objects Real-Time Reporting subject area is the only subject area that unites the reporting of all custom objects and their associated objects under a single subject area.

  • The Advanced Custom Objects Historical Analytics subject area allows you to report on the relationships between Custom Objects 01 through 05 and accounts, activities, campaigns, contacts, leads, opportunities, partners, and service requests.

In a Federated subject area, the concept of a single driving record type does not apply. The lack of a driving record type means that you must always add a default metric to the analysis. Because a federated subject area does not have a single driving object, the analysis must always contain a metric in order to choose a relationship path among objects. In non-Federated subject areas, you do not need to choose a metric because the relationship is defined already in the repository using an implicit fact metric.

A Federated subject area provides access to the metrics for the supported related record types, so that you can build a summary report for the related metrics. Using the Advanced Custom Objects Real-Time Reporting subject area, you can build a summary analysis that includes most of the record types in Oracle CRM On Demand.

With a Federated subject area, you can build analyses that show the one-to-many and many-to-many relationships for the supported record types. In the many-to-many design, you must use the subject area for the standard record type (for example, the Account record type) and the custom object subject area to report on the one-to-many relationship, and you must use the custom object subject area to report on the one-to-many relationship between other record types and that custom object. By using the Advanced Custom Objects Real-Time Reporting subject area and the Advanced Custom Objects Historical Analytics subject area, you can have access to both types of relationships. However, a many-to-many analysis is not available in these subject areas.

Record Type Renaming in Analytics

Oracle provides record type renaming in analytics for all standard record types. Company administrators can rename record types in Oracle CRM On Demand. These new names are reflected in the analytics part of Oracle CRM On Demand. The renamed record types appear with their new names in subject areas, reports, and dashboards. For example, if a company administrator changes the account record type name to Physician in Oracle CRM On Demand, then the word Account is replaced in all of the answers and subject areas. So, the subject area Account Address becomes Physician Address. The subject area Account Metrics becomes Physician Metrics, and so on.

Row_ID and Object ID

For each record type in a subject area (such as account, activity, asset, and so on) the Row_ID field in the database is mapped to a field named <object> ID, for example, one of the following: Account ID, Lead ID, Service Request ID, and so on.

Optimized Custom Fields

Some dimensions have custom fields that are optimized to reduce the query time when they are used in filters. Optimized custom fields are in folders where the name ends with Optimized Custom Fields, Optimized Custom Metrics, or Optimized Picklist Fields (Code), such as Account Optimized Custom Fields, Opportunity Optimized Custom Metrics, and Account Optimized Picklist Fields (Code). Numeric custom fields, such as those with a type of CUR, INT, or NUM, are available as metrics in the optimized custom metrics folder, if the record type is the driving object in a specific subject area. For example, the Account record type is the driving object in the Account History subject area.

Some dimensions in real-time subject areas have fields that are optimized for reducing the query time when they are used in filters. Optimized fields end with the words Code or UTC. For example, the Account dimension has an Account Type field. There is also an Account Type Code field, which is the optimized version of the Account Type field. Similarly, there is an Indexed Date UTC field, which is the optimized version of the Indexed Date field. Using the optimized field in the filter generates faster queries. This method is faster than using the standard field. For information on using optimized filtering fields, see Using Optimized Filtering Fields.
Published 12/9/2020 Copyright © 2005, 2021, Oracle and/or its affiliates. Legal Notices.