Subject: Additional Comments on Benchmark Proposal

From: Jim Clifford <[email-masked]>
Date: Tue, 6 Apr 93 13:42:10 EDT

Greetings, fellow temporal database researchers:

I have looked over the current version of the Benchmark schema and
database and would like to register the following additional points in
this e-mail forum:

(1) I agree with those who would like to add the Budget attribute,
so that the database will have multiple relation schemes that include a
single-valued, time-varying numeric 
attribute.

(2) I was already somewhat confused by the relation currently constituted as
       MGR (Dept Manager)

I am even more confused by especially if it is changed to the following:
       MGR (Dept Manager Budget)

The discussion in the first paragraph on "Section 2.2 The Schema"
about the E-R model leads one to believe that this relation is intended
to represent a "relationship", but I believe that the natural question
(between which entities?)  leads to the natural answer (Departments and
Managers). However, the proposed schema has no relations that directly
model either of these 2 entities.  What I think this means is the
following two things:

(a) this relation should be re-named DEPT. Especially in light of the
added attribute Budget, this seems to be the only appropriate
interpretation. Note that this re-naming is still in conformity with
the stated mutual FD between Dept and Manager.

(b) in keeping with the naming conventions seemingly adopted, (namely,
to NOT use the same name for an attribute as for a relation), this
would lead to the following relation scheme instead of the Mgr relation in
the proposal:

       DEPT (Department Manager Budget)

(3) In the interest of completeness, the discussion about the "keys"
of the relation schemes should be expanded.  Currently, the only
statement about keys is that "Name is the primary key of Emp".  We
should also state the keys of the other 2 relations:

  Name is the primary key of Skills

  Department is the primary key of DEPT  (if 2a is agreed upon)

I will return to the issue of "key" in my last comment.

(4) Finally, I have a quarrel with the Proposed Benchmark Data in Section 3.

I believe that the following criterion should be used in
populating the agreed-upon schema with data:

   the database instance should accord with ALL AND ONLY those 
   constraints which are explicitly stated.

The proposed database instance violates the AND ONLY part of this criterion in
at least the following way (and possibly others):

there is an implicit assumption about the meaning of being a "key"
that I believe is (i) stronger than necessary, and (ii) at the very
least should at least be made explicit.

The only explicit assumption stated about, e.g., the "key" attribute Name in 
relation EMP is  that it obeys the "snapshot function dependency"
   Name --> Salary, Dept, Gender, D-birth 
This means that for all snapshots, no 2 tuples can have the same Name. 
I assume, therefore, that this is the intended meaning of the use of the term "key".

However, the proposed database also assumes that the "key" attribute
Name is time-invariant. This is a stronger condition than the notion
of "key" as a "snapshot function dependency," and biases the proposed
benchmark in favor of the tuple-stamped models.

I welcome comments on these remarks.

--jim--

************************************************************************
Jim Clifford                                     [email-masked]
Associate Professor                              TEL: (212) 998-0803
Department of Information Systems                FAX: (212) 995-4228
Leonard N. Stern School of Business
New York University
Management Education Center
44 West 4th Street, Suite 9-74
New York, NY 10012-1126
************************************************************************