On Nov 26, 2:19 am, "Mr. Scott" <do_not_re... (AT) noone (DOT) com> wrote:

You really don't understand the relational model.

The "relvar predicate" that is the conjunction of all its constraints
is the characteristic predicate of the set of tuples that can ever be
in the relation. Date now calls this the "total relvar constraint" but
it used to be called the "internal predicate" (which term is now
deprecated by Date). But there is a different "relvar predicate",
which the designer specifies to tell the user what the relvar is
saying about the world. Date now calls this the "relvar predicate"; it
used to be called the "external predicate" (which term is now
deprecated by Date).

The relationship between the two "predicates" is as follows. The
designer specifies the relvar predicate so that a user updating the
database can observe the world and figure out whether a given tuple
makes it true and so that a user looking at the database can find out
what is true of the world. Next the designer figures out all the
possible tuples that could ever turn up in a relation because of the
way the world can be and then writes the total relvar constraint so
the dbms can tell the user they made an error if they ever try to put
some other tuple into the relation.

A row in a relation asserts one proposition for each syntactically
valid row. If a such a row is in the relation then the proposition is
its relvar predicate with free variables replaced by attribute values.
If such a row is not in the relation then the proposition is its
relvar predicate with free variables replaced by attribute values,
negated. Since these are all asserted, that's the same as asserting
their conjunction.

If one were to use the "open world assumption" then the latter
propositions are not asserted. But then a dbms cannot calculate the
answer for a query that can only be written using a "NOT" (or in
relational algebra, MINUS, assuming the other primitives are JOIN,
UNION, PROJECT, EQUALS-RESTRICT and RENAME).

, regardless
I don't know what "atomic formulas" you think are being ANDed/IFFed.
But if the database were asserting the IFF of some propositions then
it would be saying they are either all true or all false. So a user
would know that either they are all true or all false, but not which.
(That's a rather moot hypothetical since it *isn't* what a database
asserts.) Whereas in the relational model the user knows they are all
true. (That is, all the propositions above, some of which are ground
terms and some of which are negated ground terms, are all true.)

I don't know what you mean by "the atomic formulas represented by a
row". If one thinks of a relation's predicate as being an arbitrary
wff (it's usually thought of as being in natural language, or as being
wffs with natural language for ground terms) then the truth value of a
particular constituent atomic formula when the overall predicate is
true depends (like usual in predicate logic) on the connectives/
quantifiers. A row does not have a bunch of things ANDed together; the
propositions above are ANDed together (or more simply, just asserted).

After a delete a row it is no longer in the relation. So the database
is asserting the negation of the proposition that you get by
substituting its attribute values for attribute names in the
proposition.

Once again, a row does not in general assert the conjunction of wffs.

If you think otherwise please explain very clearly, hopefully with a
fully worked out simple example, because you won't be able to assume I
know what you are talking about, because what you have written is not
how the relational model works. From this message you should also be
able to work that example out "correctly".

philip

compdb (AT) hotmail (DOT) com wrote:
....
I believe IFF as well as AND can be expressed with NAND. So, what is the
argument?

The only thing I wonder about is why constraints must be truth-valued.
I'd rather they were allowed to have relation values other than dee and
dum. Seems the only way to allow defaults/mandatory tuples without
introducing some other concept.

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

The issue is that denying a conjunction merely asserts that at least one of
the conjuncts is false, but not which. When the logical connective is IFF,
denial of any of the operands denies all of the operands, otherwise the
result would be inconsistent.

An example might help. In the 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 course <COURSE>,'
that 'there is a teacher <TEACHER>,'
that 'course <COURSE> is taught by teacher <TEACHER>,'
that 'there is a room <ROOM>,'
that 'course <COURSE> is held in room <ROOM>,'
that 'teacher <TEACHER> teaches in room <ROOM>,'
that 'course <COURSE> is taught by teacher <TEACHER> in room <ROOM>,'
that 'there is a student <STUDENT>,'
that 'course <COURSE> is taken by student <STUDENT>,'
that 'teacher <TEACHER> teaches student <STUDENT>,'
that 'course <COURSE> is taught by teacher <TEACHER> to student
<STUDENT>,'
that 'student <STUDENT> studies in room <ROOM>,'
that 'teacher <TEACHER> teaches student <STUDENT> in room <ROOM>,'
that 'student <STUDENT> takes course <COURSE> in room <ROOM>,' and
that 'course <COURSE> is taught by teacher <TEACHER> in room <ROOM> to
student <STUDENT>.'

When one deletes that only row, one effectively denies them, every one.
It's an all or nothing proposition. Either all of the atomic formulas
represented by the row are true, or none of them are. That is consistent
with the logical connective between those formulas being IFF rather than
AND.

But what if there is more than one row? The information content of a table
is the logical sum (disjunction) of the information represented by each row.
Isn't it true that

(P IFF Q) OR (P IFF R) = P IFF (Q OR R)?

As a result, denying (P IFF R) in this context doesn't necessarily deny P.

But those can easily be transformed into into truth-valued constraints,
can't they?

Mr. Scott wrote:
....
That's a good example of mysticism. Unless an application requirement
is given that rooms are independent in this way, one might just as
easily conclude that CTRS is the only base relation in the db. In that
case, the set of rooms must be a projection of CTRS. Without further
information, I'd have no choice but to conclude that second choice. In
my experience, the implementation of unstated requirements has been a
huge unnecessary cost in many db's.

Mr. Scott wrote:
....

The conventional view is that is that the information in a table is the
logical conjunction of the information represented by the rows in the
table. Just because the table is formed by a summing operation doesn't
change that.

....
Not easy if users aren't required to know default values. I don't see
why they should. Contrary to Dr. Strangelove, the whole point of
defaults is to avoid users having to know them!

paul c wrote:

Ahem. Conjunction of the domains. A relation is the extension of a
predicate. That predicate can be represented as the disjunction of the
tuples.


Defaults are not constraints.

--
is there something in it for them, like maybe bailouts, if they can
panic us into doing something politically to cover them?

November 19, 2007 - John S Bolton

http://tinyurl.com/y9e4vxh

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

What do you mean by mysticism? A room is a room even if it isn't being used
to hold classes. It's existence is therefore independent of the existence
of any courses, teachers, or students. That's just plain ordinary common
sense--the opposite of mysticism.

That is my point exactly: if CTRS is the only table in the db, then there
are delete anomalies due to the existence of a room being dependent upon the
existence of at least one each of courses, teachers and students, and
further that those delete anomalies are a direct consequence of the logical
connective that interconnects the atomic formulas that are represented by
each row. The point of my example was to emphasize that whenever a row
represents a non-atomic proposition, the logical connective between the
atomic formulas that the proposition is composed of is not AND but IFF.
Since each row exemplifies the table's predicate, that predicate must also
be composed of a collection of interconnected atomic formulas, and the
logical connective must be IFF rather than AND. It therefore doesn't make
sense to define a relvar's predicate as the logical /conjunction/ of all of
the constraints that mention it.

On Nov 27, 7:32*pm, com... (AT) hotmail (DOT) com wrote:
The line
"possible values of the relation that could ever turn up because of
the"
That is, the designer communicates the set of. (They actually
communicate all the possible database states that could ever arise,
via the "total database constraint". But above I was just addressing
the term "total relvar constraint".)

philip

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


<snip>

I am going to revisit the example I posted for paul.

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 course <COURSE>,'
that 'there is a teacher <TEACHER>,'
that 'course <COURSE> is taught by teacher <TEACHER>,'
that 'there is a room <ROOM>,'
that 'course <COURSE> is held in room <ROOM>,'
that 'teacher <TEACHER> teaches in room <ROOM>,'
that 'course <COURSE> is taught by teacher <TEACHER> in room <ROOM>,'
that 'there is a student <STUDENT>,'
that 'course <COURSE> is taken by student <STUDENT>,'
that 'teacher <TEACHER> teaches student <STUDENT>,'
that 'course <COURSE> is taught by teacher <TEACHER> to student
<STUDENT>,'
that 'student <STUDENT> studies in room <ROOM>,'
that 'teacher <TEACHER> teaches student <STUDENT> in room <ROOM>,'
that 'student <STUDENT> takes course <COURSE> in room <ROOM>,' and
that 'course <COURSE> is taught by teacher <TEACHER> in room <ROOM> to
student <STUDENT>.'

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.

When one deletes that only row, one effectively denies all of those
assertions, every one.
It's an all or nothing proposition. Either all of the atomic formulas
represented by the row are true, or none of them are. That is consistent
with the logical connective between those formulas being IFF rather than
AND. If the logical connective were AND, then denying just some of the
above assertions should be allowable, but since it is the last row being
deleted, there would no longer be anywhere for the positive assertions that
remain, leaving the database inconsistent.

That should explain how things work when the first row is being inserted or
when the last row is being deleted, but what if there is more than one row?
The information content of a table
is the logical sum (disjunction) of the information represented by each row.
Isn't it true that

(P IFF Q) OR (P IFF R) = P IFF (Q OR R)?

As a result, denying (P IFF R) in this context doesn't deny P. It follows
that if there were more than one course taught in room <ROOM>, deleting only
one row wouldn't deny that 'there is a room <ROOM>.'

On Nov 27, 5:13*am, Clifford Heath <no.s... (AT) please (DOT) net> wrote:

No, my approach is very different from NIAM/ORM. My approach is a kind
of ER, while NIAM/ORM isn’t. I have entities and relationships and a
lot of semantic modeling.
I don’t have any of basic things from NIAM/ORM, such as object, roles
and fact types.
ORM uses concepts and I also use concepts. In ORM the concept is not
defined although it is basic thing. I defined the term concept with
general definition and I also defined the following particular
concepts: properties, entities, relationships and states. When we
speak about basic facts, I must say that I haven’t noticed a
definition of facts in ORM. So, for example how do you know that facts
are types if you haven’t defined facts?
As you wrote, I use attributes a lot and this is also a big difference
between my approach and ORM. I believe that more than 90% of the data
in my DBs is related to attributes.
All of the above mentioned are fundamental differences between my
approach and the one in NIAM/ORM.


However, there is one thing I believe you haven’t noticed. It is about
a sentence and its corresponding thought. No doubt a sentence denotes
its truth-value. But sentence is not a possessor of truth-value. So a
sentence is not a fact, rather a fact is related to the its
corresponding thought.
This is the reason why I introduced two very different things: a fact
about an entity and the corresponding factual sentence.
I also determined the construction of a fact about an entity. It
involves the construction of Binary Concept of an entity, the
construction of attribute’s abstraction (see 3.3.3 in my paper),
etc.
And in my opinion this is very different from ORM and from any other
DB models and designs.


Regarding “temporal” DBs, I gave a solution. You can see it on my web
site. Note that the solution is more general than the field of
“temporal” DBs. I put the main ideas on my web page in 2005 and have
completely integrated them in this paper. I am fairly certain that my
solution for the first time solves “temporal” and historical DBs and
that is one of the things which is novel.

Vladimir Odrljin