Several alternatives exist for the level of detail when defining a database schema, and each has associated advantages and disadvantages.
At one extreme, the schema may be indicated indirectly by a description of what data is stored in the database. With this approach, the number of relation schemas and even the number of attributes may be left to the interpretation of the user. When this type of benchmark is applied to a query language, an initial task is to design an appropriate database schema which may contain the data indicated in the benchmark. It appears to be beneficial to leave schema design to the individual models when applying the benchmark to diverse models for which no common, best database schema exists. On the other hand, it may be more difficult to propose queries for the benchmark if the schema is unclear. Further, it becomes difficult to compare data models based on the benchmark when queries are expressed in terms of different schemas.
Next, the database schema may be specified in terms of a design model, such as the E-R model (or one of its extensions). Here, the user must first map the design model (E-R model) schema into a schema in the temporal data model at hand. The exact transformation is left unspecified and allows many models to use the benchmark.
Another option is to define the non-temporal aspects of the benchmark database schema. This was the approach chosen in the current benchmark. Thus, the number and names of relation schemas are specified, and specific attributes are given for each relation schema.
The desired level of detail of the schema and the intended scope of the benchmark are clearly interdependent. Specifically, it may be argued that a mismatch exists in the current benchmark where the database instance (designed after the schema was frozen) indicates the need for a data model with object-oriented features such as identity (``DI'' and ``ED'' may be perceived as object identifiers). In contrast, the schema design perhaps appears to assume a purely value-based data model.
A final alternative is to completely design the database schema of the benchmark. This alternative appears to be problematic because the benchmark is intended to be used for comparing different models that do not use the same type of schema. This alternative restricts the scope to a narrow range of models.