2

My thought/contention is that once a database schema is in 4NF it by definition can only be changed into something less than 4NF (Denormalisation, 3NF etc) and that there is no alternative 4NF design for it to take.

That is, once a design is in 4NF there is no design choice/change that will take it to some other different 4NF design.

Is this correct (or are there any cases where 2 different 4NF designs are put up for comparison or converted between)?

2
  • Maybe Single Table Inheritance vs Class Table Inheritance? Not sure if STI can be considered 4NF though... – Neil McGuigan Apr 5 '16 at 5:01
  • @Neil McGuigan Thanks Neil. I was waiting for this one :). My thought is that STI is not strictly 4NF but it's a common enough design decision to be made and perhaps changed. For myself, I'd put it as a design decision at the border of 4NF so personally I'd include it even if it isn't strictly 4NF. Is there anyone unhappy with that? – Rob Bygrave Apr 5 '16 at 5:17
1

I dont think so except for the fact that there is a 5NF, which describes a design where your joins are only on the candidate keys.

Many "4NF" designs meet this criteria, but not all, and it is definitely something you can change a 4NF "into" to be be more normalized.

3
  • I'm expecting this to be the correct answer. We'll give it a day to see if some alternative views come in. Thanks!! – Rob Bygrave Apr 4 '16 at 23:22
  • I am always interested in education :) – ConstantineK Apr 4 '16 at 23:37
  • 1
    Ok there is maybe one being DB ARRAY types (aka Postgres ARRAY) - so that could be a case where the same "logical" 4NF has 2 "physical" 4NF options (Postgres ARRAY type vs a TABLE). I think that might be one. – Rob Bygrave Apr 5 '16 at 1:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.