127 Misplaced Facts
Normal-form violations are not random. They are often the algebraic footprint of a misplaced fact. The fact may be stored on the wrong subject, combined with facts that are independent of it, or stored as a base fact even though it is derivable from smaller facts.
Facts stored on the wrong subject
The 2NF, 3NF, and BCNF examples all had this shape:
- The shop's city was stored on
BookStock - The department name was stored on
Employee - The lecturer's course was stored on
CourseEnrolment
In each case an identifier was present, but the thing being identified was not modelled as the subject
of its own facts. The result was a partial, transitive, or non-superkey dependency. The repair was to
introduce a more specific domain: Shop, Department, or Lecturer.
This is a useful diagnostic: an identifier with attached facts often signals a domain. When a key identifies something and the model also records facts about that thing, that thing may deserve:
- a name
- a type
- a set of attributes
- a key
- a place in the schema
If that domain is not modelled explicitly, the schema often tries to repair itself by duplicating attributes, creating transitive dependencies, or embedding facts in the wrong place.
Independent facts combined together
The 4NF example had a different shape. Skills and languages were independent many-valued facts about
the same student, but they were combined into StudentCapability. The repair was not to introduce a
more specific domain. It was to keep the independent facts as separate attributes with many-valued
extensions on their common subject.
Derived combinations stored as base facts
The 5NF example had another shape. SupplyAssignment stored a ternary combination even though the
intended rule was the conjunction of smaller facts: supplier-part, supplier-project, and project-part.
The repair was to store those smaller facts directly and derive the ternary view when needed.
The 6NF example pushes the same instinct further: decompose facts until each one has a clear subject and a clear attribute. Predica does not require users to manually create one relation per attribute, because attributes are already unary predicates on domains. But the normal-form diagnosis remains useful: ask what each fact is about, whether it is independent of nearby facts, and whether it should be stored at all.
When the model uses an identifier for a thing that has its own properties, relationships, or lifecycle, model that thing explicitly. In many business schemas that means introducing an entity type. For mathematical values, use an enum, value, variant or quotient type. When the problem is not a missing domain, avoid inventing a false combination: keep independent many-valued facts separate, and derive composite views from their smaller facts.