Understand Eagle Data Warehouse

Portfolio Data Center is part of the Eagle Data Management solution, a data-centric processing model that builds and maintains enhanced data in the Eagle data warehouse. The processing model includes the following pieces:

  • DataMart. A data repository in the Eagle data warehouse that enables you to organize information for a specific business purpose and distribute it to support specific business needs.

  • Eagle Analytics. A module that provides built-in features for valuating and calculating analytics for fixed income and derivative securities under a licensing agreement for the FINCAD® Analytics Suite.

  • Reference Data Center. A center that enables you to create, maintain, and composite security reference data.

  • Pricing Center. An application that enables you to manage the daily pricing process for best-of-breed security prices and foreign exchange (FX) rates.

  • Metadata Center. A data governance tool that helps to organize, manage, and monitor metadata.

  • Eagle Enrichment. A component that uses an original source of accounting data as a baseline to create a modified set of data warehouse data for an entity under a unique source for advanced analysis, such as exposure valuations and alternate price/FX valuations for targeted asset types.

Rules Database

The Eagle data warehouse maintains information for multiple historic change dates, validates individual fields, tracks entity-to-entity relationships, and creates enriched data for consumption by clients. It consists of various tables. The master entity data resides in the Entity table (ENTITY) or the Entity Extension table (ENTITY_EXTENSION in the Rules) RULES database.

The historic imprints of an entity reside in the Entity History table (ENTITY_HIST) or the Entity Extension History table (ENTITY_EXTENSION_HIST). In addition, the Entity Detail table (ENTITY_DETAIL) and the Entity Detail History table (historic imprints) (ENTITY_DETAIL_HISTORY) store certain entity relationships, among them:

  • Benchmark and peer group assignments for an entity

  • Constituent entities held in a static list

  • Constituent entities held in a reporting composite (Type = COMP)

The Entity Range Details table (ENTITY_RANGE_DETAILS) stores other entity relationships. These entity relationships are GIPS composites that the system uses with start dates and end dates to track constituent members.

The Custom Index Attributes table (CUSTOM_INDEX_ATTRIBUTES) and the Custom Index Attribute Details table (CUSTOM_INDEX_ATTR_DETAIL) store other entity relationships, which are custom-blended benchmark details.

Composite Tables

Portfolio Data Center builds and maintains the current version of The Composite table (RULESdbo.ENTITY) stores the current version of the entity record. Portfolio Data Center builds and maintains this table.lt and maintained. Entity data in the Composite table is not identified with a  SRC_INTFC_INST or an Effective Date (EFFECTIVE_DATE) because the data at this level is the most current data available and is typically used as production data considered to be the gold copy, which is the latest greatest information for a fund.

In addition, the Composite table stores the following dates:

  • Update source date (UPDATE_SOURCE), which identifies the last person or process that modified the record

  • Update date (UPDATE_DATE), which identifies when the record was last updated. Each entity has only a single composite record. You can build additional composite records, but the records reside in the history tables. No column exists for SRC_INTFC_INST.
    The following table is a sample Entity table.

ENTITY_ID

ENTITY_NAME

ENTITY LEGAL NAME

INCEPTION DATE

ACCT TYPE CODE

UPDATE SOURCE

UPDATE DATE

ENTITY_ID

ENTITY_NAME

ENTITY LEGAL NAME

INCEPTION DATE

ACCT TYPE CODE

UPDATE SOURCE

UPDATE DATE

100

Portfolio 100

Portfolio 100 Tax Exempt Muni

5/25/2001

A1A

PDC_Engine

12/31/2010

Entity table (RULESdbo.ENTITY)

History Tables

The History table stores records for each change date, which is the effective date when data in the entity changed. The system stores each history record with an EFFECTIVE_DATE. A new history record is loaded every time a data element changes from the last history record.

Therefore, multiple history records exist for each entity. Data for the most recent record should match the composite record. The following figure shows a sample ENTITY_HIST table:

EFFECTIVE DATE

ENTITY_ID

ENTITY_NAME

ENTITY LEGAL NAME

INCEPTION DATE

ACCT TYPE CODE

UPDATE SOURCE

UPDATE DATE

EFFECTIVE DATE

ENTITY_ID

ENTITY_NAME

ENTITY LEGAL NAME

INCEPTION DATE

ACCT TYPE CODE

UPDATE SOURCE

UPDATE DATE

5/25/2001

100

Portfolio 100

Portfolio 100 Tax Exempt Muni

5/25/2001

C3C

PDC_Engine

5/25/2001

12/31/2005

100

Portfolio 100

Portfolio 100 Tax Exempt Muni

5/25/2001

B2B

PDC_Engine

12/31/2005

12/31/2010

100

Portfolio 100

Portfolio 100 Tax Exempt Muni

5/25/2001

A1A

PDC_Engine

12/31/2010

Entity History table (RULESdbo.ENTITY_HIST)

Master Entity

After the system loads the CRM/source into the Eagle data warehouse, Portfolio Data Center processes the entity history records through a Policy, which identifies the following data:

  • Entities managed by the policy

  • Field groups and release levels in the policy

  • Validation rules for each database field (if applicable)

  • Enrichment rules for each field (if applicable)

  • Input values, such as the default and override values

  • Policy level overrides to field-level defaults

When Portfolio Data Center processes the policy, it validates and enriches the history record for the fund. PDC loads updated data into fields the Master Entity record. The system updates the master record from only the latest history record (that is, before or on the current date).

Fields from the History record that do not pass validation remain in a temporary status in the Scrubdbo tables until a business user releases or fixes the exception. Portfolio Data Center also enables you to apply changes for future dates.

For example, the annual expense ratio is changing as of a day next week. You can give such changes a future date, and the change does not affect the master record until the future date.