>-----Name  -----<
            Link        >-----Intvn -----<     Term  >----- Vocab
                        >-----Event -----<
                        >-----Diary -----<

NAME TABLE:
     name_id
     full name
     sort name
     dob

EVENT TABLE:
     event_id
     event_name

INTVN TABLE:
     intvn_id
     intvn_name

TERM TABLE:
     entity_id      (points to Diary, Event, Intvn or Name record)      
     table_ptr      (points to Diary, Event, Intvn or Name Table)      
     vocab_id

LINK TABLE:
     diary_id
     entity_id      (points to Event, Intvn or Name record)      
     table_ptr      (points to Event, Intervn or Name table)      
     role

DAIRY TABLE:
     diary_id
     rule_name
     start_date
     end_date
     other_date
     diary_notes

VOCAB TABLE:
    vocab_id
    role
    term

The NAME, INTVN and EVENT tables represent the BASIC entities. Most of the attributes in these tables are held in the TERM TABLE which consists of three fields, entity_id, table_ptr and vocab_id. For example the NAME TABLE would contain certain fields for data which was always required (eg Name, date-of-birth), but the other entity fields would be held in TERM (eg a if the vocab_id of the term 'doctor' was 6, and the name_id of a person on the database who was a doctor was 5, this person would have a term record: 5, 'name', 6.

The LINK TABLE structure chosen is similar to that used in the second sample table design for an xBase implementation. The LINK TABLE has four fields, a diary-id field which contains the same value for all the related records in the link (rule instance), an entity_id field containing an id value from one of the basic data tables. In addition there are two further fields for specifying the entity-id, a table_ptr field which indicates the id type (ie. which table it refers to) and a role field which indicates the role of the table-id in the rule, for example a person from the name table can be in the role of victim, perpetrator or source.

The DIARY provides a simple and very flexible structure for recording information as it is acquired and reflecting time sequences in the data. It contains a diary_id, rule_name, a series of dates and a notes field. Other terms associated with the diary entry are stored in the TERM TABLE. In a sense it provides a fuller explanation of a link, such as dates of the act, and detailed notes about it. Depending on how the data is selected in a query, it can show all the known information about a particular case, event, source etc, or a subset, such as only the acts, or only the interventions involving a victim. It lends itself to implementation of easy, intuitive user interface tools where the user enters data as they receive it, but can then use it to analyze the complex relations in the database by choosing the different views.