Re: Sixth normal form

On 3 aug, 17:55, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> "Jan Hidders" <hidd..._at_gmail.com> wrote in message
>
> news:1186049901.210928.158310_at_q75g2000hsh.googlegroups.com...
>
>
>
> > On 1 aug, 15:51, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> >> "Jan Hidders" <hidd..._at_gmail.com> wrote in message
>
> >>news:1185813030.422971.126780_at_k79g2000hse.googlegroups.com...
>
> >> > On 30 jul, 12:45, Sameeksha <sameeksha.ch..._at_gmail.com> wrote:
> >> >> Googling out for definition and explanation for sixth normal form only
> >> >> resulted in the following information - "6th normal form states that a
> >> >> relation R should not contain any non-trivial join dependencies". Also
> >> >> everywhere it is stated that this normal form takes into account the
> >> >> temporal (time) dimension to the relational model, and that current
> >> >> implementations like SQL server 2005 do not implement this normal
> >> >> form.
>
> >> > It would help if you first explained what you already know, so we
> >> > don't spend time on explaining what you already know. Do you know what
> >> > at join dependency is? Do you know when it is trivial?
>
> >> > Btw. where and in what context did you read that SQL server did not
> >> > support this normal form? That is a rather odd statement since the
> >> > normal form is just about how much to split your relations into
> >> > projections, so strictly speaking it needs no support at all form the
> >> > DBMS. But perhaps support for temporal features was meant?
>
> >> >> Any more explanation and preferably an example would help in
> >> >> understanding the concept behind this normal form.
>
> >> > Informally put it says that every distinct fact gets its own relation
> >> > or "if you can split, then you should". So if you have a relation
> >> > Student(student_id, name, address) then the fact that the student with
> >> > a certain id has a certain name is split form the fact the this
> >> > student lives at a certain address. This is different from 5NF since
> >> > there you only split when there is a risk of redundancy or update
> >> > anomalies.
>
> >> I think it is important to emphasize the fact that vertically splitting a
> >> 5NF relation into a set of 6NF relations has consequences, specifically
> >> the
> >> need to enforce mutual foreign keys or a circular inclusion dependency,
> >> depending upon the number of resulting 6NF relations. This is important
> >> because support in commercial RDBMSs for enforcing such constraints is
> >> severely limited, if not nonexistent, since it requires an implementation
> >> of
> >> multiple assignment. Therefore splitting should only be done when
> >> absolutely necessary, for example, to support a temporal dimension.
>
> > Agreed. I would add that this is not specific for going from 5NF to
> > 6NF but anywhere you decompose to go from a lower to a higher normal
> > form.
>
> Not always. If two sets of attributes are independent, as is the case when
> moving from 1NF to 2NF, then there is no need for a referential constraint;
> if two projections are independent, as is the case when moving from BCNF to
> 4NF, then there is no need for a referential constraint.

I have no idea what you mean here. In all those cases you need a cyclic pair of nclusion dependencies if you want the new schema to be equivalent with the old. And if you only want the new schema to contain at least as much information as the old then you strictly speaking don't need any inclusion dependency at all.

> The difference between moving from 1NF to 5NF and moving from 5NF to 6NF is
> that breaking up a set of two or more dependent attributes in a 5NF relation
> /always/ requires a cyclical constraint in order for an instance of the
> database schema to be able to contain /at least the same/ information
> content.

Also here you don't need any inclusion dependency to get a schema that can contain at least as much information as the old.

> If a relation is already in 5NF, then there is no way to separate
> the set of dependent attributes without losing information. Suppose that A,
> B and C are dependent attributes in a 5NF relation schema. Then FD ABC -->
> ABC is implied by the candidate key, as well as the FDs ABC --> A, ABC -->
> B, and ABC --> C. Splitting the relation vertically so that each relation
> schema is in 6NF causes those FDs to be lost.

The dependencies that are left allow you derive ABC --> ABC for the result of joining them back together, which is what the old set of FDs also told you. So no information is lost.

• Jan Hidders