Subject: Benchmark correspondence

From: "Patrick P Kalua" <[email-masked]>
Date: Wed, 17 Mar 1993 22:39:43 -0500

The TSQL Benchmark Draft
                       ************************

   Our comments and suggestions to Christian's proposal for TASK I of the
   consensus TSQL Benchmark :

   1) Restrictions
      ------------
        Since we are still dealing with some aspects of temporal reasoning, the
        restriction "Temporal reasoning is beyond ...." should perhaps be
        re-phrased to "General temporal reasoning ...."

        We also feel that the following restrictions are perhaps too strong and
        we should probably relax them abit.

            (a) that each relation be used only once in each query
            (b) queries involving aggregation facilities be excluded

        For the past few years we have been interacting with a number of
        demographic researchers and most of their questions seem to be centered
        around "events", "event sequences", "waiting times" etc We have also
        looked at a number of clinical databases where the queries involving
        these same parameters seem to dominate. Events and event sequences are
        facts of life and there are a lot of simple queries that we can form
        even on the present schema around these parameters. However all those
        queries involving event sequences would be eliminated with
        restriction (a).

        Temporal aggregation may involve :
           - summing attribute values of entity instances over time
           - counting entity instances over time
           - finding max/min/avg of attribute values over time
           - summing time period (spell) length
           - counting events
           - finding max/min/avg of time periods
           - finding moving average of attribute values over time
          
       Some of these operations are very simple and yet very important.
       Aggregation exhibits some important temporal semantics and since we are
       interested more in the semantics of the queries and not efficiency or
       performance, we feel that simple aggregation operations ought to be
       allowed. This would give us a semantically rich initial benchmark.
       **HOWEVER,** we also realize that because of the limited time between
       now and June, we could possibly move the addition of these operations
       to the second iteration of the benchmark (after the workshop). In that
       case, prioritizing the process of lifting the restrictions is something
       we should probably consider and agree upon.

   2) The Benchmark Database Schema
      -----------------------------

     2.1)  Criteria

         We propose adding another criterion :
               " The schema should be natural. That is, it should
                 correspond to a reasonable, though possibly greatly
                 simplified, segment of the real world. This both
                 reduces the need to explain the model and enhances
                 the ability to recognize verball pitfalls in the path
                 to the query instances."

      2.2) Proposed Schema

        The proposed schema seems simple enough and suitable for the purpose.
        However, we suggest that we add one or two non-temporal (that is,
        time-invariant) attributes to the Emp relation - gender and/or
        birthdate. This would :

            (a) potentially add a few more queries to the pool, and
            (b) perhaps more importantly, give us at least one NON-TEMPORAL
                attribute in the schema.

        If we agree to add only one them, our preference would be gender.
        While both of these can be considered to be non-temporal, birthdate
        involves some element of time, albeit user-defined time. Gender would
        automatically divide the data set into two subsets each which would be
        large enough to provide reasonable outputs. We are also influenced by
        our contact with social scientists, among whom gender-related queries
        are common.

        It would also be a good idea, possibly at a later stage, to add a
        traditionally multi-valued attribute such as "skills" where the
        following snapshot fd holds :
                      Name --->> Skills
        Our assumption here is, of course, that " a person can have multiple
        skills at a time and the set changes with time". In this schema, the
        assumption for the other attributes (Dept, Salary) is that they are
        single-valued. A person can be in only one dept at a time and will
        earn only one salary at a time. But over time, the person may have
        worked in several departments and may have earned several salaries.
        We call such attributes **"serially multi-valued"** as opposed to
        "Sex" which is traditionally single-valued and "Skills" which is
        traditinally multi-valued.

     We welcome any comments.

     Patrick P Kalua                       Ed L Robertson
     [email-masked]                  [email-masked]
                        Indiana University,
                        Computer Science Dept,
                        Bloomington, IN 47405.