This section details how the OIDF models are delivered and how they can be installed and configured into the required environment. The first two sections give you an understanding of the Delivery Mechanism and OIDF Installation. The Data Dictionary and Download Specifications sections explain how the self-documenting erwin file includes the data dictionary and Download Specifications within erwin itself.
In addition, the Extending Data Model section has guidelines for customization and designing the Staging and Results Area of Physical Data Model.
Topics:
· OIDF Supporting Documentation
· Extending the OIDF Physical Data Model
OIDF being a collection of data model artifacts includes a readily deployable model (the OIDF Physical Data Model). The data model (Physical) is delivered as erwin files. The OIDF hence requires a license of the erwin Data Modeler application.
erwin is the current and only supported modeling tool to view and edit the model. Currently, the minimum version of Erwin Data Modeler application supported is 2019R1 or a higher version.
NOTE:
OFS AAI supports data model upload for data models generated using erwin. For information on compatible versions, see the corresponding release of the Oracle Financial Services Analytical Applications (OFSAA) Technology Matrix.
As detailed earlier, OIDF requires the Oracle Financial Services Analytical Application Infrastructure release to deploy and operate.
See the Oracle Insurance Data Foundation Application Pack Installation and Configuration Guide Release 8.1.2.0.0 for step-wise instructions on how to configure and install OIDF on an OFSAAI instance.
The preceding sections have provided an overview of the organization of the OIDF and its several component data models. Appendix A, page A-1 explains the naming conventions used in the OIDF data model.
The OIDF is a detailed model, with nearly 850 entities across both the Staging and Results Area in the physical data model.
Since it is delivered as an erwin file, all the detailed metadata for the model (Table, Column, Entity, Attribute, Relationship) definitions are embedded in the file itself. The advantage of this approach is that any site-specific customizations to OIDF can be performed within erwin, and the updated documentation is retained in the file in the form of additional metadata.
The two key detailed artifacts of OIDF documentation that can be extracted from within the erwin Data Model are as follows:
For more information on Dimension Management and AMHM, see the Dimension Management section in the Oracle Financial Services Advanced Analytical Applications Infrastructure User Guide Release 8.1.2.0.0 and Dimension Load Procedure section in Oracle Financial Services Analytical Applications Data Model Utilities User Guide.
The data dictionary for OIDF can be extracted from the erwin file using erwin's reporting capability, using a pre-built set of templates for data extraction.
Instructions for how to do so are provided in a separate accompanying document that provides step-by-step instructions. See the Oracle Financial Services Analytical Applications (OFSAA) Data Model Document Generation Release 8.1.x, which details how to extract the data dictionary from the erwin section.
As detailed in the staging area section, the mapping from the Staging Data Model to use cases, called the Download Specification (My Oracle Support) provides an efficient way to manage the sourcing of data into the OIDF staging area. This is done by mapping the staging model at a column level to use cases. This mapping information is embedded in erwin at a column level using metadata called User Defined Properties (UDPs).
The Download Specifications can be extracted using pre-built templates, in a manner similar to the Data Dictionary. Instructions for how to do so are also provided in the Oracle Financial Services Analytical Applications (OFSAA) Data Model Document Generation Release 8.1.x, which details how to extract the data dictionary from the erwin section.
Oracle Insurance Data Foundation (OIDF) Physical Data Model (PDM) design evolves as the analytical use cases covered by the OIDF and enhanced as improvements are engineered as a part of the product lifecycle. While the model satisfies a very large number of analytical use cases across Risk, Finance, Marketing, and Compliance subject areas, customers may need to customize the model for a specific installation. These custom changes however may impact the ability of the OIDF installation to be upgraded to later versions of the product. The guidelines outlined in this section will help minimize the impact of custom changes to the model when the installation needs to be upgraded to a later version of OIDF.
Topics:
· Customization Process Guidelines
· Staging Area Design Guidelines
· Results Area Design Guidelines
It is strongly recommended to consult the OFSAA Support or Field Engineers or Consulting Staff before making any changes to the PDM for the following reasons:
· Tables in the PDM common Staging Area are designed to meet the complex needs of data sourcing for many different financial services analytical use cases and as such have a large number of columns, and the need for the modification should be reviewed with OFSAA consultants.
The Results Area star schemas have been designed with a set of common fact tables and dimension tables to support the integration of results from multiple analytical applications and any customization should be reviewed in order to ensure that the unified reporting capabilities of the model are preserved.
After a review with OFSAA field consultants, an extension to the model should first be logged as a request for product enhancement via the standard support process. This allows:
· Product support and product management teams to identify if a similar enhancement request was submitted on behalf of another customer so that a uniform Model Enhancement design recommendation can be provided to all customers.
· OIDF product management to evaluate if the enhancement request is applicable more broadly to other customers and if the change should in fact is to be taken as a design requirement for subsequent releases.
NOTE:
OFS AAI supports data model upload for data models generated using erwin Data Modeler application 2019R1 or a higher version.
The following guidelines apply to the Staging Area Design:
· Ensure that the naming conventions as detailed in Appendix A, page A-1 section are followed.
· Entity relationships and constraints are enforced through the OFSAAI data management toolkit and are not enforced via database referential integrity checks.
· The model should not be changed to enforce referential integrity checks and other data quality checks via database definitions.
· All Staging Area tables must have a column that identifies the system from where data is sourced (source system ID).
· The code columns in master data tables and tables that contain dimension data should be designed to hold alphanumeric values.
· The Domain dictionary maintains the list of attribute domains. New columns must be identified with an existing domain instead of explicitly defining column data type and valid values. See guidelines in Appendix A, page A-1 section on the use of defined Domains.
· Tables (for example, reference or lookup tables with static data) required only for a specific application or use case should be a part of the application-specific processing area and should not be part of the common Staging Area in OIDF.
· OIDF download specifications identify the tables and columns for which data needs to be sourced for a specific analytical use case. Any new tables and (or) columns should have its "APPLICATION USAGE" UDP set with the appropriate application value so that the generated download specification includes the customized column and table. The master list of UDP's is maintained as a central dictionary in erwin.
· All columns added or modified as a part of the customization should be marked as such:
§ The column level UDP named "CUSTOM" must be marked YES, identifying the column as a custom property.
§ The "Customization Reason" UDP should be specified. Valid values are provided as a drop-down list and can be "Pending Enhancement Request" or "Specific to Customer".
The "Type of Change" UDP should be set to the appropriate type of change as provided in the drop-down list (Length, Datatype, Logical Name, Description, and Addition).
The Results Area consists of a set of star schemas with conformed dimensions and common fact tables. The integration of results from multiple application use cases is achieved by having common fact tables for customer and account level measures. The design of the results area allows for drill-down and drill-across BI reporting, which should be preserved after customization.
Following are the Results Area Design Guidelines:
· Ensure that the naming convention for results tables and columns detailed in Appendix A, page A-1 section is followed.
· Dimensional conformance should be maintained: The same dimensional information should not be represented in different forms. In addition, dimension table design should be compatible with the slowly changing dimension process design and so should have the required columns.
· The common accounts summary fact table (FCT_COMMON_POLICY_SUMMARY) consolidates measures at an account level granularity for all applications. Account-level attributes captured from source systems in staging and those attributes that do not vary between runs should be part of the common accounts summary table. This enables the integrated reporting of account information.
NOTE:
Any account-level application-specific attributes and measures that are computed by applications should be part of the application-specific account summary entities.
· The common customer summary fact table (FCT_COMMON_CUSTOMER_SUMMARY) consolidates measures at a customer level granularity for all applications. Customer level attributes captured from source systems in staging and those attributes that do not vary between runs should be part of the common customer summary table. This enables the integrated reporting of customer information.
NOTE:
Any customer level application-specific attributes and measures that are computed by applications should be part of the application-specific customer summary entities.
· Aggregate Entities: Depending on performance requirements for each application, information can be reported out of aggregate entities. However, a drill through to the base entity from the aggregate entity is mandatory.
· Reporting and local currency support: Include additional attributes in the fact tables to store reporting and local currency equivalent of base measures. These attributes need to be computed by looking into the exchange rates.
· Support for full history: Any new tables in the Results area should be designed to support the maintenance of full history.
The model upgrade process is achieved through the erwin Model Compare and Merge utility. See the erwin documentation Oracle Financial Services Analytical Applications (OFSAA) Data Model Extension Guidelines Document Release 8.1.x for more information about the Menu options, the process of comparing, and merging models.
For information about upgrading the OIDF Application Pack from the 8.0.x versions to 8.1.2.0.0 for an incremental data model, see the Oracle Insurance Data Foundation Application Pack Upgrade Guide Release 8.1.0.0.0.