Databases Reference
In-Depth Information
Mixed referential relationships should be addressed, but they
will not be addressed in the first release of the AVF. And so, in the
remainder of this chapter, and in most of the remainder of this
book, we will not discuss them.
Asserted Versioning Metadata
Figures 8.3 through 8.7
show the metadata needed by the AVF
to generate an Asserted Versioning database from the LDM
shown in
Figure 8.2
. As with other figures showing tables, we
indicate foreign keys by italicizing the column heading, and
primary keys by underlining the column heading.
We show these metadata tables as themselves conventional
tables, and therefore all relationships as ones implemented with
conventional foreign keys. This simplifies the discussions in this
chapter, and allows us to concentrate on the metadata without
being concerned about keeping a bi-temporal history of changes
to that data.
Table Type Metadata
In a logical data model that will generate an Asserted
Versioning database, we need a metadata list of which entities
to generate as non-temporal tables and which entities to gener-
ate as asserted version tables. This metadata table lists all the
tables that will be generated as asserted version tables, as shown
in
Figure 8.3
. For this data model, we will generate all its entities
as asserted version tables.
The non-key column in this metadata table is the business
key flag. If it is set to 'Y', then the table is considered to have a
reliable business key. Otherwise, it is set to 'N', indicating that
the business key for the table is not reliable.
Table-Type
tbl-nm
bus-key-
rlb-flag
Client
Y
Y
Y
Y
Y
Y
Policy
Policy_Amendment
Wellness_Program
Wellness_Program_Category
Wellness_Program_Enrollment
Figure 8.3 The Table Type Metadata Table.
