Hugh Darwen
University of Warwick 
Department of Computer Science

Q1.

What is a degenerate case? (ref. Lecture 4, slide 16)

Q2.

Is relation = or ≠ table? (ref. Lecture 1, slide 8)

Q1.

What is a degenerate case? (ref. Lecture 4, slide 16)

A1.

By "degenerate" (case of an operator invocation) we mean a case that is in some particular and interesting way simpler than the general case.  For example, adding 0 to any number x is a degenerate case of addition because it always yields x itself.  Similarly, "times 1" is a degenerate case of multiplication.  Each of these two examples involves the so-called identity under the operator in question: 0 for addition and 1 for multiplication.  With some dyadic operators the case where the two operands are equal is also an interesting degenerate case.  For example, x-x is always equal to 0, and x/x is always equal to 1 (except when x=0 of course, when it is undefined).

In set theory the empty set (usually denoted by the greek letter phi: v) is such that for an arbitrary set A, A 4 v = A, A - v = A, and A 3 v = v.  We can therefore note these three cases as degenerate cases of union, difference, and intersection, respectively.

Is relation = or ≠ table? (ref. Lecture 1, slide 8)

The title of this slide is trying to say that the terms “relation” and “table” are NOT synonymous.

For one thing, although every relation can be depicted as a table, not every table is a representation of (i.e., denotes) some relation.  For another, several different tables can all represent the same relation.

A table that does not depict any relation is shown in the EXERCISE given in the last slide of Lecture 1.

Some people have suggested that there are two relations in particular that cannot be depicted as tables.  These are TABLE_DEE and TABLE_DUM, which we meet in Lecture 4, Slide 21.  It is certainly difficult to have a table with no columns at all!

Several different tables can all denote the same relation, because we can simply change the left-to-right order in which the columns are shown and/or the top-to-bottom order in which the rows are shown and yet still be depicting (denoting) the same relation.

VAR ENROLMENT BASE RELATION
{ StudentId SID ,
   Name CHAR,
   CourseId CID }
KEY { StudentId, CourseId } ;

BASE, which can also be spelled REAL, is a key word indicating that the variable is to be part of the database.  If BASE were omitted, then the imperative would result in creation of a local variable.  Database variables are said to persist until they are explicitly destroyed, whereas a local variable is automatically destroyed when the program unit ("block") in which it is declared finishes its execution.

The explanation for the alternative spelling, REAL, lies in the fact that Tutorial D recognizes the existence of "virtual" variables—a concept not really dealt with in CS252, though Worksheet 4 introduces you to it by way of an exercise using Rel.  Note that virtual variables are defined ultimately in terms of real variables; so real variables can be thought of as in a certain sense primitive.

THE_C(SN) in Tutorial D means the same as SN.C would in Java.  SN is a variable of type SID (student ids).  THE_C is an operator that yields the value of the C component of the representation of a given SID value.  I am supposing that the representation of values of the user-defined type SID consists of a single component named C, of type CHAR (character strings).  Thus, THE_C(SN) returns a character string.  If the current value of SN is the student id SID('S1'), then THE_C(SN) returns the character string 'S1'.

In general, in Tutorial D, an expression of the form THE_x(y) denotes the value of the component named x of the representation of y.

You will not be examined on these terms but we use them at times in our explanations of the relational operators you learn in CS252 and you might find them useful in your own written answers.  As a matter of fact, the two terms are very often confused in the literature, so we will be forgiving if you get them the wrong way round too.  But please try not to!

A parameter defines an operand by specifying a parameter name (possibly) and type name.  For example, the operator + has two parameters, both of type RATIONAL (in Tutorial D).  This means that every invocation of + must include two expressions as arguments, both denoting rational numbers.  The term argument can be used to refer either to the expression or to the value it denotes—it is usually unimportant to distinguish between the two.

Parameter names are not needed in the case of + because the operator is built-in.  In the case of a user-defined operator, the parameters are referred to by name in the code that implements that operator.