Re: teaching relational basics to people, questions
Date: Mon, 21 Dec 2009 12:24:45 -0800 (PST)
Message-ID: <2568ebc5-3d4f-4f71-b72c-7ede8dd22189_at_m16g2000yqc.googlegroups.com>
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 -
The notation of objects is also questionable. As far as I know this
notation was first introduced by G. Frege.
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.
Vladimir Odrljin