# teaching relational basics to people, questions

Date: Mon, 16 Nov 2009 11:42:21 -0800 (PST)

Message-ID: <3e504a39-b3a1-427d-93da-0963f2a31815_at_m38g2000yqd.googlegroups.com>

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

-- SampoReceived on Mon Nov 16 2009 - 13:42:21 CST