Hugh Darwen
University of Warwick 
Department of Computer Science


CS252 Questions and Answers

This page is for my answers to questions that have been asked by students attending CS252.  if you would like to send me a question.

CONTENTS:

Q1.

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

Q2.

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

Q3. What is meant by BASE RELATION? (ref. Lecture 1, slide 12)
Q4. What is meant by THE_C(SN)? (ref. Lecture 2, slide 16)
Q5. What is the distinction between Tutorial D and Rel? (ref. Lecture 1, slide 2)
Q6. What is the difference between an argument and a parameter? (ref. Lecture 2, slide 6)

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.

top
Q2.

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

A2.

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.

top
Q3. What is meant by BASE RELATION? (ref. Lecture 1, slide 12)
A3. Slide 12 shows two imperatives, written in Tutorial D, one to create a new variable in the database, the other to destroy an existing variable.  The question refers to the first of these imperatives:

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.

top
Q4. What is meant by THE_C(SN)? (ref. Lecture 2, slide 16)
A4. This is really beyond the scope of CS252 and you will not be examined on it.  But the answer is fairly simple ...

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.

top
Q5. What is the distinction between Tutorial D and Rel? (ref. Lecture 1, slide 2)
A4. Tutorial D is a language definition and as such could be regarded as some kind of standard.  Rel is one particular implementation of Tutorial DRel does not yet implement the whole of Tutorial D.  For example, it does not yet support user-defined types in the manner required by Tutorial D.  Also, there are a few minor syntactic features in Rel that are not defined in Tutorial D, such as the use of <= to mean "is subset of", in place of the normal mathematical symbol for that purpose.
top
Q6. What is the difference between an argument and a parameter? (ref. Lecture 2, slides 2-3)
A6. A parameter belongs to the definition of an operator.  An argument appears in an invocation of an operator.  An invocation must include an argument corresponding to each parameter of the definition.

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 denotesit 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.

top