Is it still normalized db schema? database

Question

I have the following db-schema .

FILE, GROUP and BLOCK represent the object structure of the XML file. FILE is the root. GROUP has FK to FILE. BLOCK has the one FK to GROUP and the another one FK to UNIT.

UNIT groups "similar" BLOCKs from diffrent GROUPs in the context of FILE.

The data base is currently in 3NF. Yet I would like to know which UNITs belong to FILE.id=1. To do this yet, I have to make a query which joins all 4 tables. To optimize this schema, I can create the new relation UNIT n--FK-->1 FILE. Yet my query joins only two tables on the optimized db-schema. And here is the question: is this DB(with this new FK) still in 3 NF ? What the theory says?

BLOCK  n--FK-->1  GROUP  n--FK-->1  FILE
 n 
 |
 FK    
 |    
 1  
Unit

or

            +--------+
      +-----|  File  |.....+
      |     +--------+     .
      |                    .
     /|\                  /.\
 +--------+           +--------+
 | Group  |--+     +--|  Unit  |
 +--------+  |     |  +--------+
             |     |
            /|\   /|\
           +---------+
           |  Block  |
           +---------+

Answer 1

It is not clear how the UNIT table fits into the schema before you make changes.

Obviously, after you make changes, all you have to do to know which units belong to a file is join the FILE and UNIT tables.

Since tables are in 3NF when all the functional dependencies are determined by the keys, the whole keys, and nothing but the keys (so help me Codd), you have to look at your schema in that light.

Given the available information, most likely the tables are all in 3NF (and BCNF, and AFAICT in 4NF and 5NF too).

Answer 2

I don't think your "crows foot" diagram supports the other dependencies outlined in your question. How did you come up with the 1:Many relationship between FILE and UNIT?

These are the functional dependencies that you describe...

• GROUP -> FILE
• BLOCK -> GROUP
• BLOCK -> UNIT

Also, I assume that each of the above attributes functionally determine some additional attributes not appearing on the left hand side of any other functional dependency. These would be:

• FILE -> other-file-attributes
• GROUP -> other-group-attributes
• BLOCK -> other-block-attributes
• UNIT -> other-unit-attributes

Constructing a set of 3NF relations from the above functional dependencies gives:

• FileRelation: (FILE, other-file-attributes)
• GroupRelation: (GROUP, FILE, other-group-attributes)
• UnitRelation: (UNIT, other-unit-attributes)
• BlockRelation: (BLOCK, GROUP, UNIT, other-block-attributes)

This pretty much corresponds to what you have described.

Determining which UNIT instances relate to a given FILE requires a join of FileRelation to GroupRelation on FILE and then GroupRelation to BlockRelation on GROUP then BlockRelation to UnitRelation on UNIT.

You want to avoid this multi-table join by inserting a new relationship somewhere in the model that gives a direct mapping from UNIT to FILE. Such a relation implies the functional dependency:

• UNIT -> FILE

This looks like the bit you added to the "crows foot" diagram. Adding this introduces a logical contradiction. The original schema supports having a given UNIT relating to multiple FILE instances. as in:

• FileRelation(F1, ...)
• FileRelation(F2, ...)
• GroupRelation(G1, F1, ...)
• GroupRelation(G2, F2, ...)
• BlockRelation(B1, G1, U1, ...)
• BlockRelation(B2, G2, U1, ...)
• UnitRelation(U1, ...)

UNIT instance U1 relates to FILE instances F1 and F2. Given this situation either the UNIT -> FILE functional dependency cannot be supported or the original set of functional dependencies were incomplete and the schema is not in 3NF.

At this point you need to resolve whether the real world supports the FILE -> UNIT dependency or not. If it does, then the original model is not in 3NF and a bit more reworking of the schema is in order. If the dependency is not supported then the best you can say is:

• FILE, UNIT -> nothing

and the corresponding relation:

• FileUnit: (FILE, UNIT)

is a de-normalization because its content may be derived through existing tables functional dependancies.

=================================================================================

EDIT

Based on a number of comments made to this and other answers, it appears that:

• UNIT -> FILE

is a true functional dependency, the functional dependency:

• BLOCK -> UNIT

while not incorrect, must be redundant. I believe the correct 3NF set of relations for this model now is:

• FileRelation: (FILE, other-file-attributes)
• GroupRelation: (GROUP, FILE, other-group-attributes)
• UnitRelation: (UNIT, FILE, other-unit-attributes)
• BlockRelation: (BLOCK, GROUP, other-block-attributes)

Notice that the UNIT foreign key has dropped from the BlockRelation. This is because the UNIT -> FILE FD made it redundant. The (BLOCK, UNIT) relation is now formed by joining UnitRelation to FileRelation on FILE then FileRelation to GroupRelation on FILE then GroupRelation to BlockRelation on GROUP.

The original schema was not in 3NF due to the unstated functional dependency: UNIT -> FILE. The proposed set of relations above is in 3NF.

Note: When normalizing a schema, every functional dependency needs to be stated up front. Missing one can change the whole picture!

Answer 3

From the information supplied, it appears that this is a true parallel hierarchy. On this basis, I believe that the proposed amended schema would still be normalised to 3NF.