On Sat, 28 Nov 2009 05:06:40 GMT, paul c <toledobythesea (AT) oohay (DOT) ac>
wrote:

[snip]

Is the given constraint true of the data? Either it is, or it is
not. That is why constraints are truth-valued.

What other values could you use? What would having a general
relation value as a result tell you about the constraint being
followed or not?

Sincerely,

Gene Wirchenko

Bob Badour wrote:
....
Yes, yes and yes, thanks. Maybe I was a bit clumsy. Still, once people
start talking about propositions, I have to note that any two tuples in
a relation are conventionally treated as if the ones they represent are
both true.

On Nov 21, 6:24*pm, Roy Hann <specia... (AT) processed (DOT) almost.meat> wrote:

(Apologies for the delay.) That is absolutely correct. That is the
general mistake, and my particular example (validity time spans) was
just one, if recurring, instance of the more general class. Here, too,
we refuse to consider relations with and without an end date two
separate types of objects, and then conflate them into one relation
with nulls allowed in the end date.

I think there are two aspects to this problem. The first and obvious
one is the psychological: people do have immense problems getting a
hold on a data model with lots of separate entities. E.g. think of SAP
or the foundation schemata Teradata peddles, with their thousands of
relation types. Trying to sort through something like that, e.g. to
update it, is a real pain and you can never be quite certain you've
actually taken everything necessary into consideration.

But then there's the second, more subtle aspect: it is quite possible
that the problem is in sparse metadata and/or in the substandard tools/
interfaces used to access it, so that it could in fact be solved with
the right set of tools and methodology/process. I mean, envision the
metadata heaven where we have all of the formal semantics of our data
model neatly encoded within the database catalog, and further, we have
tools which automatically, graphically, and in a procedure oriented
way guide our way through all of the possible dependencies,
remembering for us which ones we've already covered. In that case
there is no possibility that you could have forgotten something once
you're done. The hassle in learning the necessary semantic
information, and *only* the necessary information, is minimal, because
all of the formal aspects are recorded within the database and your
tools show it to you on the fly, plus any linkages to the outside,
semantic world are also documented in a human readable and easily
accessible form.

In this ideal world, when you're about to handle one of those thousand
relations, you just click a column in the database client and out pops
a representation of the full generalization hierarchy of this
particular type. Want a semantic description of your entity? One click
more. Want the constraints? Another click, and voilà, it gives you
every single one of them in a nice chart alongside the top and bottom
parts of the type lattice, so that with one click more, you can get
the human readable version which maps the constraint to the external
model/business process equivalent that was used to derive the formal
constraint in the first place. Want to see where the particular domain
you're handling is used? One click. Want to see the domain definition
itself? Click.

Want to find a suitable, existing domain for your new relation,
beginning with a blank slate? Your database/client of course easily
handles a mixture of both formal and free form queries, at the level
of specificity that rivals Google, so that when you put in something
like "person company (cardinality>10) (last access within two years)
(list all relations with conflicting keys)", in a couple of seconds
you can find every single existing relation in the system which might
have something to do with your problem domain, in a well-ordered query
result form. Plus of course you should be able to dig in from the
perspective of a humanly composed ontology, or three, of everything
that is in the system, ODP style.

That sort of thing is of course a pipe dream at the moment, but then
quite a lot could already be done to organize database schemata using
existing technology. I mean, even a freely manipulable selection list
of "my relations" which retains a history of every relation you've
touched, with metadata on what you have done to them, would be a real
asset. Or when we talk about this typical case of relations related by
contraction of nulls, a UI side tool which lets us work with views of
otherwise identical relations, some of which contain "null, value not
applicable" values while updating multiple underlying tables/views,
would take 95% out of the steam to not work with more than one
relation at the same time.

So I think this thing is mostly about UI design and formal conceptual
organization of the data model, and not about any intrinsic cognitive
limitation (which do exist as well: I for one don't think there is a
single person who could reliably spot an irreducible, ten component
decomposition into PJ/NF).
--
Sampo

On Nov 29, 12:31 am, "Mr. Scott" <do_not_re... (AT) noone (DOT) com> wrote:
Thank you for giving an example. Especially when my stated intent is
to show you misunderstand something.

Your explanation is still unclear.

The user looks at the world and the relation variable's predicate(s)
and combines them to determine what rows to put in and what rows to
leave out. Similarly, they look at the rows present and absent in a
relation variable and combine them with the predicate(s) to produce
statements about the world. Please tell me what the designer gives
with a relation variable (a predicate, or set of predicates?) and the
correspondence between an overall proposition about the world and the
rows in and the rows not in that variable (now and/or previously).

The designer gives a relation variable. It's not clear what else you
claim they give. A single predicate per variable? A set of predicates
per variable? Do you mean that (some function of) this list is a
clarification of the preceding (parameterized) statement? If so,
exactly what predicate does the user form from the list that is
supposed to be equivalent to the statement? Or do you mean that the
designer specifies the statement and you think the list is derivable
from the statement by the system?

I can't tell when you write "when one inserts a row" or "inserting a
single row", whether you just mean mean "when a given row is in a
relation". Or whether by "inserting a single row" or "deletes that
only row" you specifically mean the old value of a relation variable
is also involved in mapping to instantiated predicates.

First you write "one effectively asserts" the things in the list
(whatever "effectively" means); asserting a number of things is the
same as asserting their conjunction. But then you write "the logical
connective between those formulas being IFF", so I guess you mean the
IFF of the things in the list is asserted. So you're not being clear.

And no, it's not consistent with the logical connective between those
formulas being IFF. For example, although
a1 IFF a2 IFF a3
is true when all ai are true and it is false when all ai are false, it
is also true when a1 and a2 are false and a3 is true. So the above
expression does not assert that they're all true or all false. For
that you would want something like
(a1 AND a2 AND a3) OR ((NOT A1) AND (NOT a2) AND (NOT a3))
ie (NOT (a1 OR a2 OR a3)) OR (a1 AND a2 AND a3)
ie (a1 OR a2 OR a3) IMPLIES (a1 AND a2 AND a3)
ie the whole thing is true when all are false or all are true but it's
false when there's a mix. (Not that I think you ever want the ai all
individually false.)

On the other hand I can imagine that you are thinking that for each
syntactically valid row it is in the relation iff all the
corresponding instantiated assertions in the list are true. But that's
not what you have said. (In fact you've said "all of the atomic
formulas represented by the row are true, or none of them are".) And
anyway that's not a relation's statement about the world; it is a
statement about how the value of a relation variable maps to its
statement about the world.

This is clearer, but as I said I can't figure out what you think is
asserted by a row in the table (or by a row not in 'the table) to be
ORed together. (Note that it makes sense to OR together equalities
like COURSE='Math' as the characteristic predicate of a set, but to
AND together things like "there is a course 'Math'" as a statement or
assertion about the world.) But I also don't know whether you mean
this applies to all relation variable values, or only the values of
ones that that are empty, or just became empty or nonempty, or didn't,
or what.

So please start out with what the designer gives, then tell me clearly
how to form the proposition is that is "the information represented by
each row" that is syntactically valid, then what the proposition is
that is "the information content of a table". And whether it depends
on the old state as well as the new. And tell me whether I am using
that predicate as a statement about the world or as the characteristic
predicate of some set. In other words, be clear. Then I can discuss
your approach (ie show it doesn't do what you think it does).

It's also pointless for me to address your justifications for
individual steps if I don't understand the overall process.

philip

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

Thank you for pointing that out. I really wasn't very clear. By
interdependent I mean that the connective between any two atomic formulas
(atoms) is a biconditional, not that the only connectives are
biconditionals, so for three atoms, it's not

a1 iff a2 iff a3,

but rather,

(a1 iff a2) and (a1 iff a3) and (a2 iff a3)

which is true whenever all ai are true or all ai are false and false
otherwise.

For four atoms, it's not

a1 iff a2 iff a3 iff a4,

but rather,

(a1 iff a2) and (a1 iff a3) and (a1 iff a4) and
(a2 iff a3) and (a2 iff a4) and (a3 iff a4)

which is true whenever all ai are true or all ai are false and false
otherwise.

Constraints specify what can be represented in a table. They don't say
anything about what actually is the case other than that it can be the case.
What actually is the case is a matter of interpretation.


{COURSE:Physics, TEACHER:Brown, ROOM:145, STUDENT:Jones}

This row doesn't "state" anything. That it is in the table is evidence that
someone with authority asserted as fact that Brown teaches Jones Physics in
room 145, and that it is still in the table is evidence that noone with
authority has since denied it. It is reasonable, therefore, to treat as
fact that Brown teaches Jones Physics in room 145. From this fact a number
(14 to be exact) of other facts can be inferred. That's 15 distinct facts
in total represented by a single row. Each row of CTRS isn't just a single
fact, but a family of interdependent facts. Brown can't teach Jones Physics
in room 145 if he doesn't teach Physics or if there is no room 145, and
under the assumptions that CTRS is the only table in the database and that
there is only a single row that mentions Physics, Brown, 145 or Jones, there
can't be a student called Jones unless he is being taught Physics by Brown
in room 145. The addition of a second row, for example,

{COURSE:Calculus, TEACHER:Green, ROOM:154, STUDENT:Jones},

weakens that condition so that there can't be a student called Jones unless
he is being taught Physics by Brown in room 145 or he is being taught
Calculus by Green in room 154. The addition of a separate table, S
{STUDENT}, for example, also weakens the condition because then there could
be a student called Jones even if he isn't taking any courses from any
teachers in any rooms. It doesn't change the form of the assertion
represented by each row, though, where the logical connective between any
two atoms is IFF, yielding a non-atomic formula, but the logical connective
between any two of those formulas is AND.

The logical connective that separates the facts represented by one row from
the facts represented by another is OR (unless there is a self-referencing
inclusion dependency), as is the logical connective that separates the facts
represented in one table from the facts represented in another (unless there
is an inclusion dependency).

On Dec 10, 6:12*pm, "Mr. Scott" <do_not_re... (AT) noone (DOT) com> wrote:

Thanks, but this is no clearer.
philip

On Dec 10, 8:12*pm, "Mr. Scott" <do_not_re... (AT) noone (DOT) com> wrote:
Hello Mr. Scott,

If I'm understanding your explanation properly, in a database with
only table:

BIG_US_CITIES {CITY_NAME, STATE_CODE}

(that is, lacking table STATES {STATE_CODE}) one must logically infer,
from the CWA, that states with no big cities, e.g. 'RI', do not exist?

On Fri, 11 Dec 2009 13:29:26 -0800 (PST), Kevin Kirkpatrick
<kvnkrkptrck (AT) gmail (DOT) com> wrote:

[snip]

Effectively yes. You can only go by what is in the database. If
that is not sufficient for your purposes, then the database should be
redesigned. If it is sufficient, well and good. The idea of a
database is not to model all that exists but only that which you are
interested in.

Sincerely,

Gene Wirchenko

"Kevin Kirkpatrick" <kvnkrkptrck (AT) gmail (DOT) com> wrote

<snip>
The inference is valid, but it is not due to the CWA. If the only place in
the database for assertions like 'there is a state called <STATE_CODE>,' is
in BIG_US_CITIES, which houses facts like 'There is a big city named
<CITY_NAME> in a state called <STATE_CODE>,' then one can logically conclude
that there aren't any states with no big cities. Even under the OWA, there
can't be any states with no big cities. Under the CWA, all and only states
with big cities are represented in the database, and under the OWA, only but
not necessarily all states with big cities are represented in the database.
In both cases, only states with big cities can be represented in the
database. There isn't anywhere to record the assertion that there is a
state with no big cities, so there can't be any. The table STATES
{STATE_CODE} provides a place to record assertions like 'there is a state
called <STATE_CODE>' independent of whether there is also a big city.

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

If CTRS is base, that question is strictly not answerable. 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?".

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