Databases Reference
In-Depth Information
ENTITY:
EMPLOYEE PAYCHECK
FEDERAL TAX
DATA ELEMENTS:
EMPLOYEE_NBR
BEG_ANNI_SALARY_AMT
PAYCHECK_ISSUE_DT
END_ANNI_SALARY_AMT
PAY_PERIOD_BEG_DT
FED_TAX_RT
PAY_PERIOD_END_DT
BIWK_SALARY_AMT
FED_TAX_RT
This may be a problem, however, when the derivation algorithm is sub-
ject to change. If this occurs, having all the original values does not meet
the user's business information requirements because the values do not
yield the same result. If the data element is added to another entity, the
data modeler should identify the element as redundant and document its
source entity in the repository.
The ideal way to handle historical business information is to recognize
that change occurs and to plan for it. The data modeler can deal with this
by adding an effective date to the entity identifier of the entities whose
occurrences may be time-dependent. This ensures that the value of the
derived data element can be recalculated at any point in time and keeps
redundancy and derived business information to a minimum. The following
entry illustrates a scenario in which the year that the federal tax is applied
is used to obtain the appropriate tax rate from the federal tax entity:
ENTITY:
EMPLOYEE PAYCHECK
FEDERAL TAX
DATA ELEMENTS:
EMPLOYEE_NBR
FED_TAX_YR
PAYCHECK_ISSUE_DT
BEG_ANNI_SALARY_AMT
PAY_PERIOD_BEG_DT
END_ANNI_SALARY_AMT
PAY_PERIOD_END_DT
FED_TAX_RT
BIWK_SALARY_AMT
FED_TAX_YR
Referential integrity must be maintained between these two entities to
ensure that there is always an occurrence of the federal tax entity that cor-
responds to the federal tax year data element in the employee paycheck
entity. If these standards are not met, recalculation is not possible.
Another reason to include historical business information in the data
model is to fulfill a mandated requirement. A legal requirement or an orga-
nizationwide policy may stipulate that all business information that
relates to specific transactions must be recorded in full at the time the
Search WWH ::
Custom Search