The following figure shows an entity relationship diagram for the audit data and supporting tables and provides a brief description of each from a reporting perspective.
Figure 7. Audit tables schema
Note the following points:
The primary table is _aud-audit-data, whichholds the details of the event that was audited, such as who did it and when, for example. It may also contain a delimited list of modified field values depending on the audit policy level settings.
The _aud-audit-data-value table optionally stores additional details for modified fields showing the new and, optionally, the old values. The level of detail recorded (for example, simply the fact that something happened, the new value of modified fields, both old and new values, or a stream of an audited streams values) is driven by the table policy. Records are created in this child table only if the policy is set to record one record per field.
The _client-session table optionally records additional session information such as the authentication domain and client name.
The _db-detail table provides a description of the database for which the audit data exists, as well as the passkey used to optionally seal the audit data records.
The _aud-event table provides additional audit event information that is useful for reporting, rather than simply showing the integer event ID. The event definition itself determines the structure of the information in the other tables.
A Foreign Key is denoted by the abbreviation FK.
The fields above the line are the Primary Key fields, in order.
IEx.y denotes an Inversion Entry (nonunique alternate index) key with the first number (x) being the index number and the second number (y) being the position of the field within the index.
The primary table is _aud-audit-data, whichholds the details of the event that was audited, such as who did it and when, for example. It may also contain a delimited list of modified field values depending on the audit policy level settings.