Databases Reference
In-Depth Information
enrolled in any number of wellness programs, each of which
may enroll any number of clients. Thus, the entity Wellness
Program Enrollment is an associative entity, implementing a
many-to-many relationship between clients and programs.
The business meaning of the entities, attributes and relation-
ships should need no explanation, with the possible exception of
the two attributes with a suffix of “a1c”. As all diabetics know,
a1c is a blood test that measures what percentage of a person's
hemoglobin has glucose attached to it.
As ERwin data modelers will immediately recognize, primary
keys are shown above the horizontal line in each entity. Foreign
keys, of course, have “(FK)” as a separate suffix. Since all of these
entities will be generated as temporal tables, all these FKs will be
replaced by temporal foreign keys, by TFKs.
As we said earlier, the current implementation of Asserted
Versioning uses ERwin's user-defined properties to capture the
metadata needed to generate a bi-temporal database schema
from a non-temporal data model. In this chapter, however, we
will organize that metadata as a set of five metadata tables.
Referential Constraints Between Non-Temporal
and Bi-Temporal Tables
There is nothing semantically wrong about a bi-temporal
table being the child table in a referential integrity relationship.
In that case, the bi-temporal table will contain a conventional
foreign key which points to a row in a parent non-temporal
table. Conversely, there is nothing semantically wrong about a
non-temporal table being the child table in a temporal referen-
tial integrity relationship. In that case, the non-temporal table
will contain a temporal foreign key which points to an episode
in a parent bi-temporal table.
In both cases, the referential relationships reflect an
existence
dependency
between the objects involved. When both tables are
non-temporal, we represent that existence dependency as a ref-
erential integrity dependency. When both tables are bi-temporal,
we represent it as a temporal referential integrity dependency.
When one table is non-temporal and the other bi-temporal, the
existence dependency between their objects isn't somehow
nullified because of our choice of how to represent it. And so
our managed objects should be able to express that dependency
even in that “mixed” case.
As bi-temporal theory, Asserted Versioning interprets non-
temporal
tables as tables whose rows are bi-temporal, but
