Databases Reference
In-Depth Information
A primary key column with an
oid
suffix is the unique identi-
fier of the object whose type is indicated by that table, and which
is represented by one or more managed objects contained in
that table. Thus
client_oid
, in the Client table, identifies a partic-
ular client which is represented in the Client table by one or
more episodes each consisting of one or more versions.
A non-primary key column with an
oid
suffix is a temporal
foreign key. Thus
client_oid
, in the Policy and Wellness Program
Enrollment tables, is a temporal foreign key. Temporal foreign
key relationships are graphically represented, in
Figure 8.8
,by
arrows from the primary key
oid
to the TFK
oid
.
Since we do not append a suffix to business key column
names, we have adopted the convention of listing the business
key column or columns of a table immediately below the pri-
mary key, and immediately followed by the episode begin date.
This shows us that Client, Policy, Wellness Program Category
and Wellness Program all have single-column business keys, that
the business key of Policy Amendment is the policy identifier
plus an amendment number, and that the business key of Well-
ness Program Enrollment is the concatenation of the client and
wellness program identifiers.
The process by which this physical data model (PDM) is gen-
erated from the non-temporal PDM corresponding to the LDM
of
Figures 8.1
and
8.2
is straightforward. As illustrated in
Fig-
ure 8.1
, the AVF does this automatically. However, as with all
the work the AVF does, this transformation of a non-temporal
PDM to a temporal PDM can be done manually. We describe this
process in the following section.
Generating an Asserted Versioning Database
from a Physical Data Model and Metadata
An Asserted Versioning database consists of data structures
plus constraints on the instances of data that conform to them.
The data structures are the table definitions. The constraints
are temporal entity integrity and temporal referential integrity,
applied to the asserted version tables in the database, and
implemented by the AVF as stored procedures.
However, other techniques could also be used to enforce
these constraints, including triggers, generalized and reusable
application code, and Java object persistence frameworks. The
AVF generates this logic based on the metadata associated with
each data model, and so it does not need to recreate this code
for each table.
