Role: This table plays a VITAL role in maintaining the historical consistency of the database. Each time a field in a record is specified or updated, a new entry is placed into the ATTR_UPDATE table, describing the particulars of the change: which user made the change, when it occurred, notes on the change, and any publications associated with the change. From this information, it is possible to reconstruct and display dynamically the history of changes to any record upon request.
How/Who enters: Records are entered continuously by the system, as new records of other data types are created and modified. Each change to the database generates a new ATTR_UPDATE record.
Security: Security issues are minimal because this table is invisible to users.
| Superclasses: | NONE |
PARENT_RECORD (ZDB ID#, REQUIRED). Contains the ZDB ID of the record in which the attribute resides. For instance, if you are extending a GENE record by filling in its protein sequence, this attribute refers to the original GENE record. The value is filled in automatically by the system.
ATTR_NAME (TEXT, REQUIRED). Contains the name of the attribute being updated, filled in by the system when the record is generated.
PERSON_ID (ZDB ID#: REQUIRED). This field contains the ZDB ID number of a PERSON record. The PERSON is the authorized submitter who is submitting a value for the attribute in question.
OLD_VALUE(TEXT, REQUIRED). In this field, the system casts to text and records the old value of the attribute being updated. In most cases this is NULL, but sometimes not. For instance, if the DB Admin changes an existing value, we record the old one automatically. In some cases (e.g. where the value is generated from an intersection table), it may not be possible to maintain this attribute.
NEW_VALUE (TEXT, REQUIRED). This field contains the new value of the attribute submitted in this update. The new value is also stored in the actual record that was updated ensuring query efficiency. This field provides a bit of redundancy.
CHANGE_DATE (TIMESTAMP, REQUIRED). This field is filled in by the system with a timestamp at the time the change is incorporated into the database.
COMMENTS (TEXT, OPTIONAL). A free form text field in which the person making the change/update can document reasons for the change or other information of interest.
PUBLICATIONS. When submitting any sort of attribute update, the submitter is prompted to identify (using the publication browser) publications that support the data being submitted. Any such selections create new records in the DATA-PUB intersection table. The publications associated with a particular update can be dynamically reconstructed by querying the DATA-PUB intersection table.
• Should we track changes to the “core” data classes only, i.e. the DATA_ITEM class and its subclasses or do we want to track user’s changes to things like their own PERSON records, LAB records, etc. as well. Who would ever want to know this stuff?
• Might be able to eliminate the CHANGE_DATE attribute and just use the timestamp the system puts on each record automatically.