Re: Sixth normal form

"JOG" <jog_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:

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

>
> 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)".
>