Re: Sixth normal form


"JOG" <jog@xxxxxxxxxxxxx> wrote in message
news:1187619035.887929.213580@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Aug 20, 12:47 pm, "Brian Selzer" <br...@xxxxxxxxxxxxxxxxxxx> wrote:
"JOG" <j...@xxxxxxxxxxxxx> wrote in message

news:1187531546.951730.47900@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx



On Aug 19, 1:43 pm, "Brian Selzer" <br...@xxxxxxxxxxxxxxxxxxx> wrote:
"paul c" <toledobythe...@xxxxxxxx> wrote in message

news:%CNxi.70306$fJ5.3346@xxxxxxxxxxxx

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.

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]




.

Relevant Pages

  • Re: Sixth normal form
    ... employee, and thus the join of the relations emplast, empfirst, empssn, ... Under the domain closure assumption, if there is a value for emp#, ... there is an employee with that employee number. ... exist are represented by values in the body of the database. ...
    (comp.databases.theory)
  • Re: Sixth normal form
    ... Besides, due to the domain closure assumption, the absence of a proposition ... employee, and thus the join of the relations emplast, empfirst, empssn, ... there is an employee with that employee number. ... I don't see how material implication has "semantics" outside of IF/ ...
    (comp.databases.theory)
  • Re: Bookmark not working (again) in Access 2007
    ... I haven't changed anything in the database. ... I have a database that tracks accidents. ... Each employee in the employee table called, ... A main data entry form called, ...
    (microsoft.public.access.forms)
  • Re: Bookmark not working (again) in Access 2007
    ... If you think there may be corruption in tables, export each table to a format that Access recognizes from your working database -- try XML format since it retains more structure information -- second choice would be Excel, then CSV ... Each employee in the employee table called, ... A main data entry form called, ... I'm now thinking there might have been some kind of corruption with the database. ...
    (microsoft.public.access.forms)
  • Re: Bookmark not working (again) in Access 2007
    ... I haven't changed anything in the database. ... I have a database that tracks accidents. ... Each employee in the employee table called, ... A main data entry form called, ...
    (microsoft.public.access.forms)