Re: Sixth normal form

From: JOG <jog_at_cs.nott.ac.uk>
Date: Tue, 21 Aug 2007 14:29:03 -0000
Message-ID: <1187706543.151687.49550_at_r29g2000hsg.googlegroups.com>


On Aug 21, 2:18 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> "JOG" <j..._at_cs.nott.ac.uk> wrote in message
>
> news: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?
>
> This is what Jan and I have been discussing. I think the cyclical
> referential constraint is always needed when moving from 5NF to 6NF.
>
>
>
>
>
> >> 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.
>
> I'm not sure what you're trying to say.
>
>
>
>
>
> >> >> 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.
>
> There is "Equality and Domain Closure in First-Order Databases" by Raymond
> Reiter which was published in the JACM in April 1980. An application of it
> can be seen in "Logic and Databases: A Deductive Approach," by Gallaire,
> Minker and Nocolas, also available in the ACM Digital Library. Another
> application can be found in "Maintaining State Constraints in Relational
> Databases: A Proof Theoretic Basis," by McCune and Henschen, again available
> online in the ACM Digital Library.

Ta. I will check the references out. It is not usage I have not come across before, and it seemed instinctively obtuse - but I will quell that thought prior to further reading.

>
> Sorry for the delay in responding. Your response caused me to question my
> own use of it and also my argument. The latter article, by McCune and
> Henschen, employs different domain closure axioms for the database values
> immediately preceeding and succeeding an insert, which supports my usage.
>
>
>
> >> >> 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 Tue Aug 21 2007 - 16:29:03 CEST

Original text of this message