Does normalization always reduce row counts?

No; the example increases total rows while reducing repeated name facts.

Can it resolve conflicting source values automatically?

No; those need a separate correctness decision.

Is any split into smaller tables valid?

No. Reconstruction and dependency behavior matter.

AI Glossary / Data governance and quality / Advanced

Relational data analysis

Definition

Relational data analysis is the examination and restructuring of data according to relational design principles, commonly called database normalization. In the supplied DAMA glossary context, it concerns organizing data into appropriate relations to reduce unnecessary duplication and improve structural consistency. It does not mean every statistical analysis performed on a relational database, and it should not be confused with scaling numerical features before machine learning.

What it means

The central question is which facts belong together and what determines their values. A record that mixes article details, contributor details and review events may repeat facts at different levels. Relational data analysis makes those dependencies explicit before deciding how to separate the information.
This is a design activity. Two columns that happen to have unique values in a small sample do not necessarily form a reliable identity rule. The analyst needs the intended business meaning, including what may change and what combinations should remain possible.

How it works

The analyst identifies attributes, candidate keys and dependencies, then examines the design against suitable normal forms. A functional dependency means that equal values of a determining attribute set require equal values of the determined attributes in every valid instance. It is a rule about permitted data, not simply an observed correlation.
When a relation is decomposed, the analyst checks whether joining its projections can reconstruct the original valid relation without introducing extra combinations. This is the lossless-join requirement. Dependency preservation is another consideration: important rules should remain enforceable through the decomposed design. These properties differ, so satisfying one does not automatically establish the other. Query and operational needs also require evaluation; normalization does not guarantee that every query becomes faster.

Three practical examples

Contributor details: A fictional article register repeats each contributor's display name beside every article. If the intended rule is that a contributor ID determines one current display name, keeping that fact in a contributor relation avoids maintaining independent copies throughout the article register.
Repeated reviews: A project stores Review1, Review2 and Review3 columns. The analyst asks whether review events should instead have their own records, with an article reference and a round identifier. This avoids building an arbitrary maximum of three reviews into the column layout.
Historical labels: A report stores a category label as it appeared when an article was published. The analyst first clarifies whether that historical label is intentional evidence or an accidental duplicate of today's category name. Replacing history with a current lookup would change meaning, even if the resulting structure looked tidier.

Think of it this way

Think of organizing an office's records so that an address book stores current contact details and an assignment register stores who is responsible for each job. Copying the full address onto every assignment creates extra places to maintain it. But a signed historical document may need the address as it was at signing. Good organization distinguishes these facts before removing repetition.

Worked example

Consider a fictional relation ArticleInfo(article_id, title, contributor_id, contributor_name). Assume each article has exactly one contributor, each article ID identifies one article, and each contributor ID determines one current contributor name. Names may repeat.
The three rows are (A1, Alpha, C1, Mira), (A2, Beta, C1, Mira) and (A3, Gamma, C2, Omar). Mira's current name appears twice because C1 contributes to two articles. If the name changes and only one row is updated, the register can disagree about the same contributor.
Decompose it into Articles(article_id, title, contributor_id) with three rows and Contributors(contributor_id, contributor_name) with two rows. Joining them on contributor_id reconstructs the original three rows under the stated dependencies. The contributor-name fact for C1 now has one designated place to update rather than two.
This does not reduce the total row count: three original rows become five rows across two relations. The improvement concerns how facts are represented, not a rule that normalization must produce fewer rows. The contributor ID still appears in several places because it connects the facts. If articles can have multiple contributors or names must be preserved historically, the assumptions and design need revision.

Illustrative case study

A fictional AI learning website imports article records from several teams. The imported register repeats contributor contact details, category labels and review outcomes. Different editors update different copies, creating contradictory values that complicate publication checks.
The project team interviews the data owners before restructuring the register. It separates current contributor information from article facts and review events, while retaining publication-time details where the business explicitly needs history. It then checks that representative reports can be reconstructed and that important relationships remain valid.
The team also resolves existing disagreements rather than assuming decomposition will choose the correct value automatically. This invented case separates structural improvement from deciding which conflicting source values are true.

Common misconceptions and mistakes

Relational data analysis is not the same as feature normalization in machine learning. It is also more than splitting a wide table into smaller tables: an arbitrary split can lose information about which values belonged together. Repeated identifiers are not automatically harmful redundancy, because they can express necessary relationships. Another mistake is inferring permanent dependencies from a small sample without checking business rules. Finally, a normalized structure does not independently verify the accuracy, timeliness or completeness of the facts stored in it.

Business use

For an AI publishing project, use relational data analysis when defining the underlying content and workflow records. Document what each record represents and which facts depend on its identity. Keep historical and current-state requirements explicit. Test whether the proposed structure supports key reports and whether updates preserve the intended rules. If a reporting copy deliberately repeats data for convenience, document how it stays synchronized with its source instead of letting it become an unexplained competing record.

Check your understanding

Answer: Which attribute determines the current contributor name? contributor_id.

How many rows exist after decomposition?

Answer: Five across two relations.

Why is the repeated contributor ID acceptable?

Answer: It connects article facts with contributor facts.

What assumption fails for coauthored articles?

Answer: Exactly one contributor per article.

Related terms

Database normalization
Functional dependency
Candidate key
Relation
Update Anomalies
lossless decomposition
dependency preservation
update anomaly

Learn next

Add a second contributor to one article in the example. Redesign the relationships, then explain how the original single-contributor assumption affected the first design.

Sources

DAMA UK, Glossary of Data Management Terms, Relational data analysis: https://www.dama-uk.org/pages/glossary Northeastern database design teaching material, normalization and decomposition: https://northeastern-datalab.github.io/cs3200/fa18s2/download/L15-Design.pdf IBM, Database normalization, overview of anomalies and trade-offs: https://www.ibm.com/think/topics/database-normalization The article/contributor example and publishing case are original illustrations.

Previous: Relation Schema Next: Relational data mining