Re: Sixth normal form

From: JOG <jog_at_cs.nott.ac.uk>
Date: Mon, 20 Aug 2007 14:10:35 -0000
Message-ID: <1187619035.887929.213580_at_k79g2000hse.googlegroups.com>


On Aug 20, 12:47 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> "JOG" <j..._at_cs.nott.ac.uk> wrote in message
>
> news:1187531546.951730.47900_at_50g2000hsm.googlegroups.com...
>
>
>
> > On Aug 19, 1:43 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> >> "paul c" <toledobythe..._at_oohay.ac> wrote in message
>
> >>news:%CNxi.70306$fJ5.3346_at_pd7urf1no...
>
> >> > JOG wrote:
> >> >> ...
> >> >> Does anyone else understand any of this? ...
>
> >> > It strikes me as absurdly technocratic, no apparent value, ie. for me
> >> > the
> >> > answer is no. I don't see any value in theory for its own sake unless
> >> > you
> >> > can say or guess at *some* point along the way what the "sake" is.
>
> >> [snip]
>
> >> No apparent value.... I gave an example before, but perhaps it was a bit
> >> too complicated. Suppose that you have a 5NF relation schema,
>
> >> employee {emp#, last, first, ssn, payrate} where emp# is the key, last is
> >> the last name, and first is the first name, ssn is the social security
> >> account number and payrate is the hourly pay rate.
>
> >> Now split it into the family of 6NF schemata,
>
> >> emplast {emp#, last}
> >> empfirst {emp#, first}
> >> empssn {emp#, ssn}
> >> emppayrate {emp#, payrate}
>
> >> Wouldn't it be a bit strange for an employee to have a first name but not
> >> a
> >> last name?
>
> > Yes it would be strange if a person had no surname. Would be strange
> > that there is no proposition containing a person's last name. No. In
> > the RealWorld(tm) its always possible there we will be missing info.
> > See the difference?
>
> I see what you're driving at. I don't agree with your argument. If the
> last name could have been missing, then the relation wasn't in 5NF to begin
> with. 6NF isn't a substitute for modeling missing information. It could be
> a requirement that whenever one value is supplied, another value must also
> be supplied. That can't be modeled through decomposition into 6NF.

What is preventing the 6NF version from harnessing a database constraint that demands that for every proposition of the form (emp#:a, empfirst:x) there must also be a proposition (emp#a, emplast:y), if so desired?

>
> Besides, due to the domain closure assumption, the absence of a proposition
> containing a person's last name indicates that the person doesn't have a
> last name.

I only know of its use refererring to domains, where if a value is not contained within a enumerated domain, it is deigned not to exist. I don't see what relevance this has to propositions - their values do not make up a domain. In fact quite the opposite - they take values / from/ domains.

> So if emplast only contains supplied last names, then the
> meaning of last in emplast is different from the meaning of last in
> employee, and thus the join of the relations emplast, empfirst, empssn,
> emppayrate no longer means the same thing as the original relation.

I don't see how:
1) emp#(a) -> empfirst(b) ^ emplast(c)
differs from:
2) emp#(a) -> empfirst(b)
3) emp#(a) -> emplast(c)

Are we not agreed these are mathematically equivalent? If empfirst and emplast were nullable, then line 1 was an error. If they were "not_nullable" (and 6NF was not necessary) then the 6NF database requires a constraint to encode lines 2 and 3, but so what? No problem there.

>
>
>
> >> How about a pay rate without a social security account number?
> >> Under the domain closure assumption, if there is a value for emp#, then
> >> there is an employee with that employee number. For example, if there is
> >> a
> >> tuple {emp#:152, first:Brian} in empfirst, then there is an employee with
> >> employee number 152, and that employee has the first name, Brian. Under
> >> the
> >> closed world assumption, the absence of a tuple with employee number 152
> >> in
> >> emplast indicates that the employee with employee number 152 has no last
> >> name.
>
> > I disagree, it does not mean at all that employee 152 has no last
> > name. Under CWA in a data model, it means there is no proposition
> > describing that information. The first order objects are propositions,
> > not people. A subtle but invaluable distinction.
>
> But the domain closure assumption states that the only individuals that
> exist are represented by values in the body of the database. Are you
> denying the domain closure assumption?

I am questioning your use of it. If you are paraphrasing an academic paper's use in reference to database theory, then link me to it and I will check it out.

>
>
>
> >> So how can you determine how much to pay him without a pay rate? How
> >> can you produce a check to pay him without a last name? How can you
> >> report
> >> to the government how much he was paid without a social security account
> >> number. If you can't pay him, then is he really an employee?
>
> >> I now ask what is wrong with exploring why this can happen? Is this
> >> really
> >> theory for theory's sake? In order to find a correct solution, isn't it
> >> necessary to find the root cause?
>
> >> I could be wrong, but I think I may have found the root cause. I offered
> >> it
> >> up here in this forum--the database theory newsgroup. If you don't
> >> understand what I'm trying to say, then please ask for clarification. If
> >> you see a problem with my argument, or even better, if you can prove that
> >> I'm wrong, then by all means do it: I'm not afraid to be wrong and would
> >> prefer to be corrected so I don't waste any more time on it.
>
> > I don't think it is ever a waste of time to explore these issues.
>
> >> > When the foundation is nothing more than mysticism, arbitrary
> >> > vocabulary
> >> > and name dropping, any result no matter how ostensibly it appears to be
> >> > reasoned is likely to be up for grabs.
>
> >> Are you saying the foundation of the relational model is mysticism? The
> >> whole notion of keys is semantic in nature: does that mean that the model
> >> is
> >> based upon mysticism?
>
> > No, again I disagree 100%. Keys are not semantic in nature whatsoever.
> > They are the antecedents of any material implication in a statement of
> > FOL. Semantics or 'meaning' are added by the user at the conceptual
> > layer, as they are to any role or value.
>
> What does that have to do with it? Are you saying that a functional
> dependency is not a semantic notion? If you are, then I'm not alone in
> disagreement.

I don't see how material implication has "semantics" outside of IF/ THEN to a logical model. "If I have this (role/value), then I can determine some other (role/value)".

>
> >> The entirety of normalization theory is semantically
> >> oriented, does that mean that it is all founded upon mysticism?
>
> >> [snip]
Received on Mon Aug 20 2007 - 16:10:35 CEST

Original text of this message