# Re: teaching relational basics to people, questions

From: vldm10 <vldm10_at_yahoo.com>
Date: Mon, 21 Dec 2009 12:24:45 -0800 (PST)

On Dec 15, 1:37 pm, "Mr. Scott" <do_not_re..._at_noone.com> wrote:
> "paul c" <toledobythe..._at_oohay.ac> wrote in message
>
> news:O_aVm.55874\$Db2.49482_at_edtnps83...
>
>
>
>
>
> > Mr. Scott wrote:
> >> "paul c" <toledobythe..._at_oohay.ac> wrote in message
> >>news:DASUm.55772\$Db2.7870_at_edtnps83...
> >>> Mr. Scott wrote:
> >>> ...
> >>>> In a typical table,
>
> >>>> CTRS {COURSE, TEACHER, ROOM, STUDENT},
>
> >>>> each row states that a particular COURSE is taught by a particular
> >>>> TEACHER
> >>>> 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
>
> >> CR {COURSE,ROOM}
>
> >> 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.- Hide quoted text -
>
> - Show quoted text -

If you use the terms abstract and concrete objects in the context of a certain theory it might be interesting to know which framework you used. I get the impression that these themes are becoming very important in modern mathematics and some other sciences.