Period group

Period group (or "repeating group") is a term from database theory . It refers to groups of database fields that appear several times in a data record . The order of the groups in the data record is important.

example

A new database table should contain data records for the individual employees. For each employee, information about his or her professional career can also be saved there. The fields "Start date", "End date", "Position", "Department" are provided for this. These four fields are combined into a (data) group "Employment".

Since an employee can hold different positions over time, it is necessary for the recording of his career that an initially indefinite number of data groups "employment" can be saved. When using period groups, this task is solved in that the group "Employment" can appear as often as desired in a data record. The individual versions of the group can be read or written by specifying an index.

Advantages and disadvantages

The use of period groups contradicts the first normal form of relational theory and is therefore not supported by relational database management systems . Additional tables must be created in them to include information that can occur more than once.

The advantage of databases that support period groups (e.g. Adabas ) is that all information about an object can be stored in a single data record. This can bring significant performance advantages over systems in which the information is stored in many tables.

A period group is therefore a logical table that is mapped in a physical table. If you save the physical table, the logical table is also saved automatically. If the physical one is restored, it is inevitably consistent with the logical table. Disadvantage: INSERT / DELETE operations cannot be carried out on the logical table, but inserting and deleting is achieved using UPDATE commands on the physical table, which requires a little virtual thinking. Furthermore, the number of table elements is not unlimited, with today's Adabas 191 repetitions can be mapped.

A well-known analogy compares relational database systems with a car, in which the wheels and seats first have to be removed (because they occur multiple times) before it can be parked in the garage, and then later reinstalled before you can drive away .