Right now it is to be expected that I will be spreading the good
relational word among my peers, in the near future. That is an
opportunity one doesn't want to fuck up; many enough have gone down
that road already. So I've been going over, and over, and over the
basics. Don't want them to be able to catch me off guard with the
minutiae, after all...

So now I bump into my first real surprise, and the chills immediately
go down my spine. That's Date et al.'s answer regarding the
implications between 6NF and DK/NF, at http://www.dbdebunk.com/page/page/621935.htm
.. In there they flat out state that DK/NF doesn't imply 6NF.

So, my first question is, can this really be true? I mean, this seems
highly suspect to me: since 6NF is a normal form like any other and is
as such defined by the constraints it upholds by design, and on the
other hand DK/NF is by definition a normal form where any constraint
whatsoever follows from the domain and key ones, shouldn't it be self-
evident that DK/NF logically implies 6NF, and in fact any other form?
No matter the fact that there might well be databases which could be
put into 6NF which cannot attain DK/NF? I think at the very least said
implication should follow at the price of making it a vacuous truth
(i.e. all (non-trivial?) 6NF databases could be such that they cannot
be put into DK/NF)?

In particular I suspect that the seeming lack of implication follows
from not treating the time dimension(s) on an equal footing with the
rest of the attributes in a relation. That, then, would at least to me
seem like a rather grave violation of the information principle.

The second point ain't as much a rebuke as a retort: I wonder whether
Date and Darwen chose their model of time -- which 6NF is defined on
top of -- based on convenience and familiarity, instead of some deeper
theoretical reasoning. To me the idea that time in a relational
database should be treated as a discrete, countably infinite set of
disjoint moments at a preset temporal granularity seems just
unnatural, and unnecessarily limiting.

To me it would seem much more natural to model time as a full
continuum of precise moments in time, and to constrain such real life
models using a finite (but otherwise unlimited cardinality) set of
FOPL constraints, relying on the full linear order on top of the
reals, on top. I.e. to model time using CW-complexes over the real
line (i.e. finite unions of open, closed and semi-closed intervals of
reals), in a fully discrete but also fully variable precision
approximation.

Model-wise, 6NF as D&D define it immediately generalizes to this --
all that needs to be changed is to quantify every defining formula
over the corresponding nondenumerable set -- yet the possibility of
rigorously modelling the interaction between open and closed intervals
as well is a considerable plus when dealing with general intersection
queries. I also consider the the fact that imputing any kind of chosen-
ahead granularity parameter into the basic model suddenly becomes
unnecessary a huge plus. So, do you think this sort of approach is
sound?

Finally, I of course have the firm intention of covering the
essentials, including the basics of dependency and normalization
theory at least upto 6NF and DK/NF. If my audience proves to be game,
I'd also like to mention in passing some of the lesser known, more
esoteric, and less fully researched topics in dependency theory like
(E)(B)MVD's (cf. e.g. http://www2.cs.uregina.ca/~butz/publications/ipmu00.pdf
), just to make sure people don't accidentally think they've mastered
the subject after what is a mere, hurried, introduction. I'd hope to
pique some genuine interest in the relational way of thought, among
people who perhaps haven't been exposed to the mindset, eventhough
otherwise more than capable in modelling data. If you could suggest
other ways to accomplish the feat, I would greatly appreciate a hint.
--
Sampo

On Nov 16, 11:42 am, Sampo Syreeni <de... (AT) iki (DOT) fi> wrote:
Go read a definition carefully. Eg wiki dknf.
It's in DK/NF iff all constraints follow from the domain and key ones.
So it's not in DK/NF iff some constraint doesn't follow from the
domain and key ones,
In other words, if there other constraints is just isn't *in* DK/NF.
(It's not a very useful concept.)

philip

Somebody once called me pretentious.

I replied, "Moi?"

On Mon, 16 Nov 2009 11:42:21 -0800 (PST), Sampo Syreeni <decoy (AT) iki (DOT) fi>
wrote:

Regards,
Casey

On Nov 18, 1:08*am, com... (AT) hotmail (DOT) com wrote:

But that's just my point: we *assumed* DK/NF, so there cannot be any
other constraints. 6NF should logically be subsumed, if not else then
vacuously.

Personally I find it very useful, at least as a mental aid, because it
forces one to concentrate on the possibility of constraining your
schema just a little bit further. No matter the means.
--
Sampo

So what sense do make then of Date's example?

"EMP {EMP#,DEPT#,SALARY} KEY {EMP#}
(with the obvious semantics)"

You are confused. This is why I said to read some definitions.

If some relations and constraints meet certain criteria,
we say they are in some certain normal form.
The example has one relation and no (non-key-or-type) constraints.
Since there are no non-key-or-type constraints, that collection
of relations and constraints is in DK/NF.
But the relation in the example has more than one non-key attribute.
So that collection of relations and constraints is not in 6NF.

The sense of "constraint" in the first quote is the normal dbms one.
But you seem to think 6NF is some kind of "constraint".
We could say that in some sense
"a given set of relations and constraints rearranged
into some normal form is more constrained than it was".
But this is using the word "constraint" with a different meaning.
This seems to be where you are confused.

It would probably help if you didn't use vague and/or suggestive
(thus, meaningless) phrases like "logically subsumed".
You do this a lot.
Force yourself to identify and refer to the things, notions and
terms you find in definitions
(like, a collection of some relations and some constraints).

philip

On Nov 19, 5:56*am, com... (AT) hotmail (DOT) com wrote:

The definition of 6NF is that the schema must not satisfy any non-
trivial join dependencies at all. This implies at most one non-prime
attribute per relation. As I see it, the condition that there be at
most one non-prime attribute is a constraint on the relation in the
usual sense. It does not follow from key and domain constraints,
however. Hence, the relation may not be in 6NF, but I don't think it
is in DK/NF either. If so, it isn't a counter-example to DK/NF
implying 6NF like Date seems to think.

At least that one has a perfectly standard meaning in mathematics.
It's strictly the same as "is implied by".
--
Sampo

On Nov 19, 1:32 am, Sampo Syreeni <de... (AT) iki (DOT) fi> wrote:

If you look into it you might find differently.

Regardless (or perhaps, with regard to those "other ones"),
it has been my experience that phrases like "As I see it"
are rhetorical wafflings. As if, when later shown wrong, you can say,
ok, that might not be the way it is, but that's the way I saw it,
and all I claimed was that I saw it that way, and I did, so I wasn't
wrong.
I am not trying to catch you at anything.
I'm trying to help (about normal forms and your writing, both).
(And because of the exercise in improving my reasoning,
understanding and writing.)
As I said, it helps to force oneself to be direct and precise,
because it (painfully) makes one think and write more clearly.

Regarding constraints & you vs Date we remain in disagreement.
Hope someone else can help.

philip

Sampo Syreeni wrote:

Doesn't this make it a bit hard to predict how long queries
on time-valued domains may take? The amount of time required for
manipulating a value will greatly vary. My guess is that why
Date and Darwen rule it out for this reason. Then again, Date
defines the use of essentially arbitrary domains elsewhere.

--
Reinier

On Nov 20, 10:18*pm, rp... (AT) pcwin518 (DOT) campus.tue.nl (rpost) wrote:

I don't think so, because all of the logic would still revolve around
similar comparison operations, on an identical number of endpoints.
The only difference would be that in some cases there would be a less-
than-or-equal-to where a less-than was before, the numerical values
used to store time ranges would have their lowest order bit used to
denote the distinction between an open and a closed end point, and
variable precision would be available at least at the conceptual
level. At the physical one, it could always be implemented so that the
complexity if bounded by the less precise of the compared values, or
in fact limited to some fixed value at physical design time. And since
one would have to have a bona fide range datatype, building in
handling for infinite ranges would also be easy; that'd get rid of one
of the most persistent reasons why people incorporate nulls into
designs.
--
Sampo

Sampo Syreeni wrote:

I think you are being excessively optimistic. The most persistent (and
most common) reason people incorporate nullable columns into designs is
because they have a misplaced desire to minimize the number of tables in
the design, and think that conflating multiple fact types in one table
is clever, efficient, and harmless.

--
Roy