"paul c" <toledobythesea (AT) oohay (DOT) ac> wrote

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.

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

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.

Mr. Scott wrote:
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.

On Dec 11, 1:29 pm, Kevin Kirkpatrick <kvnkrkpt... (AT) gmail (DOT) com> wrote:
On Dec 11, 1:36 pm, Gene Wirchenko <ge... (AT) ocis (DOT) net> wrote:
On Dec 11, 8:15 pm, "Mr. Scott" <do_not_re... (AT) noone (DOT) com> wrote:
It is more reasonable to say that the database is silent about the
existence of states and cities. But even if it did, the inference that
some state doesn't exist is wrong.

If the predicate is "the city named city_name in state state_code is
big", then what you know is that for every tuple <c, s> in
big_us_cities "city named c in state s is big", and that (by the cwa)
for every tuple <c, s> typed by but not in in big_us_cities "it is not
the case that: the city named c in state s is big". (Maybe there is
no such named city anywhere; or maybe there's one in one or more in
other states; and/or maybe they're just not big; or there's no such
state; or that city in s is small; etc.) (If it were the case, the
tuple would have been in the relation. The use of this interpretation
of relations, which is done in a relational dbms and the relational
algebra needs in order to answer queries, is "assuming a closed
world".) This particular database (ie relation variable plus
predicate) has nothing to say about the existence of states or cities.
There is no way to write a relation expression whose predicate
involves existence starting from only the given predicate.

Now, if the user is allowed to assume (which they would using the
everyday meaning of the predicate above) that "exists c: the city
named c in state s is big" implies "there is a state named s" then
they could reason from <c,s> being in big_us_cities that "there is a
state named s". But from <c,s> not in big_us_cities they still
couldn't infer that "s is not a state". (Maybe there's just no such
city; or it's small in state s; etc.)

Note that the database has no idea what the predicate is, let alone
what "big" means or what a "state" is or the consequences (like
"existence") of there being or not being a big city named c in state
s. With this relation and predicate you can write a query that tells
you whether (ie its predicate is) for some city c "there exists an s
such that the city named c in state s is big". But there is no query
that answers "is there a state s". (But I told you how to derive it).

This should not be surprising since if we change the predicate for
big_us_cities to "the number of characters in string city_name is not
the age of any dog whose tag says state_id" we wouldn't expect any
query to give a different answer for any given value of big_us_cities.
Regarding silence on existence, we also wouldn't expect any such
change if we do add explicit information about existence.

Also regarding non-existence: Suppose existence is made explicit by
the predicate being something like "state state_code exists and city
city_name exists in that state and that city is big". Then when <c, s>
is in big_us_cities you know "state s exists" because it follows from
"state s exists and ...". But if <c,s> is not in big_us_cities you
still don't know which (one or more) of the conjuncts is false to make
the whole thing false. You only know the whole predicate is fakse
using <c,s>. So you don't know that "state s doesn't exist".

philip

On Dec 4, 4:26 pm, com... (AT) hotmail (DOT) com wrote:
On Dec 11, 12:07*am, com... (AT) hotmail (DOT) com wrote:
Mr. Scott,

I received an early xmas gift from my database designer: a relational
dbms. Its database has relation variables vr{A,B,C,D} and vs{A,X} with
respective predicates pr(A,B,C,D) and ps(A,X). Observing the world I
can determine for a particular tuple whether a given predicate is true
with corresponding attributes/parameters substituted. All attributes
are of the same type.

At some point when the database reflects the world:

If pr(a,b,c,d) is true, what does this imply about the tuples in vr?
If pr(a,b,c,d) is false, what does this imply about the tuples in vr?
If a tuple <a,b,c,d> is in vr, what does this imply about the world,
in terms of pr?
If a tuple <a,b,c,d> is not in vr, what does this imply about the
world, in terms of pr?
What does vr imply about the world?
What does the database imply about the world?

What query (relation expression) returns:
The set of tuples <a,b,c,d> for which pr(a,b,c,d)?
The set of tuples <b,c,d> for which there exists an A such that pr
(A,b,c,d)?
The set of tuples <a,b,c,d,x> for which pr(a,b,c,d) and ps(a,x)?
The set of tuples <a,b,c,d> for which pr(a,b,c,d) and not ps
(a',b',c',d')?

Each of the following queries returns a relation. For each query, what
does the returned value imply about the world?
vr
vr project all but {A}
vr join vs
vr minus relation{A a',B b',C c',D d'}

Maybe you don't consider these to be appropriate questions. If so
please give precise rules mapping between the world and the database
state and between queries and predicates.

philip

<compdb (AT) hotmail (DOT) com> wrote

No, it isn't wrong. An assertion that there is a state with no big cities
is inconsistent with the definition of the database: it cannot be true.

<snip>

the fact that there is an (a,b,c,d) such that pr (a,b,c,d) is represented
in the database as the tuple {A:a,B:b,C:c,D:d} in vr.

the fact that there is not an (a,b,c,d) such that pr (a,b,c,d) is
represented
in the database as the absence of the tuple {A:a,B:b,C:c,D:d} in vr.

that there is an (a,b,c,d) such that pr (a,b,c,d).

that there is not an (a,b,c,d) such that pr (a,b,c,d).

that there can be an (A,B,C,D) such that pr (A,B,C,D)

that there can be an (A,B,C,D) such that pr (A,B,C,D) OR there can be an
(A,X) such that ps (A,X)

(you didn't specify whether there is an inclusion dependency from vr[A] to
vs[A], so the logical connective is OR).

You are being inconsistent. Is <a,b,c,d> a tuple or a set of tuples?

forall A forall B forall C forall D,
which (A,B,C,D) are such that pr (A,B,C,D)?

This is really beyond the scope of a single newsgroup post, but,

assuming that A,B,C,D are free in pr,

pr (A,B,C,D) IFF (((pr A) B) C) D IFF (pr A) (B,C,D)

so vr project all but {A} is

forall A forall B forall C forall D,
which (B,C,D) are such that (pr A) (B,C,D)?

forall A forall B forall C forall D forall X,
which (A,B,C,D,Z) are such that pr(A,B,C,D) and ps(A,X)?

forall A forall B forall C forall D,
which (A,B,C,D) are such that pr (A,B,C,D)
and not (A = a' and B = b' and C = c' and D = d')?

Mr. Scott wrote:

I really do hesitate to comment on this ever more imbecilic thread, but
this is a kind of discussion that always gets my goat.

Relational databases (and being generous, I will include SQL databases)
use logic and set theory to manage human testimony about the world. We
are not required to deny our own certain knowledge to satisfy the
machinations of the DBMS. It is the DBMS that is constrained to use the
closed world hypothesis, not us. But knowing that it is constrained in
that way, we are obliged to design databases to accomodate what we
know is true, and to never tell us anything we know is untrue.

But we have to accept that a DBMS can't tell us all that we know is
true. We human users are never obliged to use a closed world when we
interpret the result of a query.

--
Roy

"paul c" <toledobythesea (AT) oohay (DOT) ac> wrote

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.

On Dec 15, 4:34*am, Roy Hann <specia... (AT) processed (DOT) almost.meat> wrote:
In the real world, I qualify the results of all queries as, "According
to the database [inference from the query]". I'll recast my point in
this light. My question on this thread was: given a database with
only one relvar BIG_US_CITIES {CITY, STATE} and associated predicate
"<CITY> is a big city in the state of <STATE>", if I run a query with
selection "STATE='Rhode Island'" and get no rows back, should I
interpret this result as:

A: "According to the database, Rhode Island is not a state" or
B: "According to the database, there are no large cities in Rhode
Island"

Mr. Scott is [I believe] claiming that both of these are valid
interpretations of the query result. I'd argue that only the latter
interpretation valid, and feel the example itself shows mine to be the
more sensible approach.

"Roy Hann" <specially (AT) processed (DOT) almost.meat> wrote

You're missing the point. The constraints that define the database clearly
and precisely specify what can and cannot be true in the context of the
database. That context is the micro-world that the database is supposed to
model, which may or may not be a subset of the real world. It might even be
a completely fictional world, but within that context, only assertions that
are consistent with the definition of the database can be true. The above
mentioned database is concerned only with states with big cities because
there is only a place for assertions about states with big cities, and in
that context, there can be no states with no big cities--even though we know
that in reality there are indeed states with no big cities.