Re: teaching relational basics to people, questions

From: Mr. Scott <>
Date: Tue, 15 Dec 2009 07:37:31 -0500
Message-ID: <>

"paul c" <> wrote in message news:O_aVm.55874$Db2.49482_at_edtnps83...

> Mr. Scott wrote:

>> "paul c" <> wrote in message
>> news:DASUm.55772$Db2.7870_at_edtnps83...
>>> Mr. Scott wrote:
>>> ...
>>>> In a typical table,
>>>> each row states that a particular COURSE is taught by a particular 
>>>> in a particular ROOM to a particular STUDENT.
>>>> Now, while it can be argued that there can't be a course without a 
>>>> teacher,
>>>> or that there can't be a course without a student, or that there can't 
>>>> be a
>>>> student without a teacher, the room exists independent of whether there 
>>>> is a
>>>> course, or a teacher or a student.  It therefore follows that locating 
>>>> the
>>>> fact that 'there is a room <ROOM>' only in table CTRS is a problem 
>>>> because
>>>> then there could only be a room whenever there is at least one course 
>>>> and at
>>>> least one teacher and at least one student.  When one inserts a row 
>>>> into an
>>>> empty CTRS, one effectively asserts
>>>>     ...
>>>>     that 'there is a room <ROOM>,' ...
>>> This presumes that the predicate for a table R { ROOM } is the same as 
>>> the predicate of CTRS { ROOM } but from the dbms perspective it's patent 
>>> they can't be, since R and CTRS don't even have the same heading.  If 
>>> CTRS is not base, maybe you can say such but if it is base, one can only 
>>> assert that there exists some teacher, student and course such that room 
>>> <ROOM> is involved.

>> There is no table R. The only place in the database to record assertions
>> that there is a particular room is in CTRS, but one cannot assert that
>> there is a particular room without also asserting that there is a
>> particular teacher, that there is a particular student, and that said
>> teacher is teaching a particular course to said student in that room.
>>>> If you disagree that all of these assertions are a consequence of 
>>>> inserting a single row, then how is it that there can be an answer to 
>>>> the query, "is course <COURSE> held in room <ROOM>?"  Unless there is 
>>>> the possibility that 'course <COURSE> is held in room <ROOM>,' there 
>>>> can be no answer (at least not a yes or a no) to the query.
>>>> ...
>>> If CTRS is base, that question is strictly not answerable.

>> Yes, it is answerable. The fact that a particular teacher is teaching a
>> particular student a particular course in a particular room implies the
>> fact that that particular course is held in that particular room.
>>> I suspect that the man in the street might think such a query is 
>>> possible (not to mention many db designers) but to be precise I think 
>>> it's important to distinguish what is from what could be, otherwise we 
>>> lapse into mysticism.  A query that is answerable from CTRS is "are 
>>> there some teachers and students such that course <COURSE> and room 
>>> <ROOM> are involved?".

>> I think you're assuming that it is possible for there to be courses in
>> rooms even if there aren't any students or teachers, but that hasn't been
>> established, and in fact since there is no place in the database for such
>> assertions, there cannot be courses in rooms without students or
>> teachers. The queries that are answerable are therefore not limited to
>> just those that involve all four attributes.

>> If there were a place in the database for such assertions, such as a
>> table


>> Then what is in the database would consist of the logical sum of all
>> courses in rooms without students or teachers and all courses in rooms
>> with students and teachers. The query "Is course <COURSE> held in room
>> <ROOM>?" would involve both CR and CTRS, unless there is an inclusion
>> dependency from CTRS[COURSE,ROOM] to CR[COURSE,ROOM], in which case the
>> query could be answered without involving CTRS.
>>> Just because SQL and the like might not be expressive enough to prevent 
>>> the query doesn't mean the most basic condition, ie., the definition of 
>>> CTRS, can be ignored.  A language that might reflect this might have two 
>>> sets of operands for projection instead of one.
>>> (I also realize that the usual explanations of projection operators 
>>> don't make this clear.  Not that table/relvar names carry any 
>>> significance other than as a device to segregate rows/tuples according 
>>> to predicate but it might be more suggestive of the actual situation if 
>>> the name of CTRS were changed to 'EXPELLED'.)

>> Table names are significant. There can be more than one table with the
>> same set of columns. The closest logical analog to a table name is a
>> predicate symbol. Predicate symbols are significant.

>> P(X) may be true for a given X even if Q(X) is false for the same X.
> Perhaps the most remarkably bald of these assertions is that a 'particular 
> ROOM' has 'independent' 'existence' when a 'particular' STUDENT or TEACHER 
> or COURSE doesn't.  I've never even liked the word 'exists'... 'forall' is 
> okay but 'is present' would help keep one's eye on the ball.  To avoid the 
> chronic mystical persuasion, basically all we really need to be concerned 
> with is the presence of symbols.

The idea that symbols can be 'present' is very strange. For each table in a database there is a collection of assertions that can be represented by a row in the table. Some of those assertions may be true, and some may be false, but the symbols from which those assertions are composed are always 'present' regardless of whether the assertions are true or not. They are part of the language. The non-logical symbols of a typical first-order language consists of a set of predicate symbols of various arities, a set of function symbols of various arities, and a set of variable names. Arbitrary propositions are 0-ary predicate symbols. Constants are 0-ary function symbols. The idea that those sets of symbols can somehow change undermines the basis of the logic. Moreover, the unique name assumption demands that everything that has a name has one and only one name for all time, but if the pool of names can change, then there's no longer any guarantee that the name of something won't be different at some future time.

I think you're continual reference to mysticism is misplaced. Ignorance may be bliss, but it has no place in database theory. It is a mistake to deliberately ignore the fact that since databases can change, the propositions represented by the rows that can be in the database must concern concrete rather than abstract objects, since abstract objects are independent of time. Propositions that concern abstract objects are either necessarily true or necessarily false, so they have no place in a time-varying relation. Think:

P -> (~#~P /\ ~#P): P implies possibly P but not necessarily P.

Every proposition that can be represented by a row in the database has to have a similar form. If the contents of a table can change, then the propositions that can be represented by a row in the table must be possible but not necessary, and the only way they can be possible but not necessary is if they concern concrete rather than abstract objects.

Probably the most important property of concrete objects is that they have lifetimes. They can come into existence and they can cease to exist. This is not mysticism: it is a logical consequence of the fact that the contents of a table can change. But I understand your dislike of 'exists' as a quantifier. I prefer to use 'there is' instead of 'there exists,' not because there is something mystical about actual existence, but because a fixed domain is easier to work with, especially for temporal data. A fixed domain includes everything that ever was, everything that actually is, and everything that can ever be. When the domain is fixed, the collection of assertions that can be represented in the database is also fixed, so the determination of which are represented at a given time is as simple as assigning a truth value to each. There is no need to extend every time there is an update. For example, suppose that someone tries to insert a row for part '123455,' but there actually is no part '123455.' The row is inconsistent with the database because there is no part '123455' in the domain of parts, so there wouldn't be any propositions in the extension that concern part '123455,' but what if someone at some later time defines a part

'123455?'  At that time the row would be consistent because the part 
'123455' would be in the domain of parts.  How would the information that 
'123455' is in the domain of parts be maintained so that consistency can be 
ensured? Domains are not tables. One can't insert values into a domain without altering the database scheme. However, with a fixed domain, it is always the case that '123455' can be a part, and the fact that '123455' actually is a part would have to be recorded in a table somewhere in the database. It is also a simple matter with a fixed domain to represent something in the database that no longer actually exists or something that may occur in the future. Received on Tue Dec 15 2009 - 13:37:31 CET

Original text of this message