RULES Database

Entity information is stored in the RULES database.

ENTITY Table

The ENTITY table in the RULES database and linked tables store information about the portfolios and benchmarks for which you are calculating returns. The following table lists the key fields used in performance calculations.

You can also store information about each entity, such as the portfolio name, investment strategy, and portfolio manager.

ENTITY_EXTENSION Table

The ENTITY_EXTENSION table stores entity information used to measure performance. The following table lists the key field used in performance calculations.

ENTITY_HISTORY Table

The ENTITY_HISTORY table stores historical entity data that can be used for performance reports. For example, the history of the portfolio strategy, which may have changed over time. Because this option is on by default, Eagle recommends inserting a record into the ENTITY_HISTORY table using the fund's inception date as an effective date when you are initializing the database.

The following two tables show how the entity history data is used in performance calculations.

ENTITY_OVERRIDES Table

The ENTITY_OVERRIDES table stores the BUSINESS_CALENDAR_SOURCE column, which identifies the source associated with the business calendar for an entity. You can use entity level business calendars to override the Eagle PACE business calendar in many types of performance reports.

COMPOSITE_ENTITY and COMPOSITE_ENTITY_EXT Tables

The COMPOSITE_ENTITY table stores duplicate columns from the ENTITY table, and COMPOSITE_ENTITY_EXT table stores duplicate columns from the ENTITY_EXT table. The COMPOSITE_ENTITY and COMPOSITE_ENTITY_EXT tables can apply composite entity level field attributes to any level of the Performance Calculation report, down to the security level. This functionality allows you to separate composite information from the underlying constituent.

This functionality is available only for composites (COMP) and performance composites (ACOM) in Holdings and Cash mode.

Store Inception Dates

There are conventions used to store the inception date for calculating inception-to-date returns. When calculating multi-period returns, the return linker selects returns where the effective date is greater than the inception date. You can link from any inception date field, but the earliest inception date must be stored in the INCEPTION_DATE column.

For example, if the first return for a portfolio is on May 31 and you are reporting on a monthly frequency, the inception date should be set to April 30 so that the 5/31 return is retrieved from the database and you can count the days used to annualize returns for periods greater than 1 year. Since the May 31 return is a monthly return, it represents the period April 30 to May 31.

If instead, you report on a daily frequency and the first return was on May 31, then use May 30 as the inception date.
As an example of the conventions used to store inception dates, consider the following situation where you:

• Report annualized returns since inception date.

• Have a first-full-month performance reporting policy.

• Report performance on a monthly frequency basis.

• Report to the client the date on which they first contributed money, which might be different than the inception date.

• Report the first day of the first performance period.

In this example, you need to store three different inception dates in the Entity table. If the client first contributed money on June 15, then the first performance period will be the month of July (first full month). And you need to report the dates:

• June 15 is the first contribution date.

• June 30 is the inception date for the purposes of annualizing returns.

• July 1 is the first day of first performance period.

Because June 30 is the date you need to use to count the days since-inception for annualization purposes, you need to store this data in the INCEPTION_DATE column.

If this data is not available in the entity file from which you are loading from the legacy system, you can automate the maintenance of multiple inception dates. You can do this using a database trigger to either automatically populate two of these dates, or have the loader or entity windows set to load the first money date.

This June 15 example updates the inception date with the last day of that month, adds one day, and then updates the column where the first day of the first performance period is stored.

Assign Benchmarks

You can assign any number of benchmarks to an entity, and can use the same benchmark for different reporting purposes. If you are automating the assignment of benchmarks, the benchmark-to-portfolio relationships are stored in the ENTITY_DETAIL table. You can also manually maintain benchmarks using the Benchmark tab on the Entity Maintenance window. For more information about assigning benchmarks, see Benchmark Management.

About Entity Types

The following table describes how the entity type controls performance calculations.

On this page