A relvar R is in sixth normal formif and only if it satisfies no nontrivial join dependencies at all — where, as before, a join dependency is trivial if and only if at least one of the projections involved is taken over the set of all attributes of the relvar concerned.
Date et al. have also given the following definition:
Relvar R is in sixth normal form if and only if every JD of R is trivial — where a JD is trivial if and only if one of its components is equal to the pertinent heading in its entirety.
Any relation in 6NF is also in 5NF. Sixth normal form is intended to decompose relation variables to irreducible components. Though this may be relatively unimportant for non-temporal relation variables, it can be important when dealing with temporal variables or other interval data. For instance, if a relation comprises a supplier's name, status, and city, we may also want to add temporal data, such as the time during which these values are, or were, valid but the three values may vary independently of each other and at different rates. We may, for instance, wish to trace the history of changes to Status; a review of production costs may reveal that a change was caused by a supplier changing city and hence what they charged for delivery. For further discussion on Temporal Aggregation in SQL, see also Zimanyi. For a different approach, see TSQL2.
DKNF
Some authors have used the term sixth normal form differently: as a synonym for Domain/key normal form. This usage predates Date et al.'s work.
Usage
The sixth normal form is currently being used in some data warehouses where the benefits outweigh the drawbacks, for example using Anchor Modeling. Although using 6NF leads to an explosion of tables, modern databases can prune the tables from select queries where they are not required and thus speed up queries that only access several attributes.
Examples
In order for a table to be in 6NF, it has to comply with the 5NF first and then it requires that each table satisfies only trivial join dependencies. Let’s take a simple example with a table already in 5NF: Here, in the users table, every attribute is non null and the primary key is the username: Users_table This table is in 5NF because each join dependency is implied by the unique candidate key of the table. More specifically, the only possible join dependencies are:,. The 6NF version would look like this: Users Users_dept So, from one table in 5NF, 6NF produces two tables. Following is another example: TABLE 1
