Thursday, November 3, 2022


09/19/23: For the latest on 1NF see: FIRST NORMAL FORM - A DEFINITIVE GUIDE


Note: In "Setting Matters Straight" posts I debunk online pronouncements that involve fundamentals which I first post on LinkedIn. The purpose is to induce practitioners to test their foundation knowledge against our debunking, where we explain what is correct and what is fallacious. For in-depth treatments check out the POSTS and our PAPERS, LINKS and BOOKS (or organize one of our on-site/online SEMINARS, which can be customized to specific needs). Questions and comments are welcome here and on LinkedIn.

(Continued from Part 2)

In this part we set matters straight about first normal form (1NF)

What's right/wrong about this database picture?

“A relation is in first normal form (1NF) if (and only if):
  • Each attribute contains only one value.
  • All attribute values are atomic, which means they can’t be broken down into anything smaller.
In practice, 1NF means that you should not have lists or other composite structures as attribute values. Below is an example of a relation that does not satisfy 1NF criteria:This relation is not in 1NF because the courses attribute has multiple values.

 Jane Smith       Databases, Mathematics
 John Lipinsky    English Literature, Databases
 Dave Beyer       English Literature, Mathematics

To transform this relation to the first normal form, we should store each course subject as a single value, so that each student-course assignment is a separate tuple.”


DBDebunk was maintained and kept free with the proceeds from my @AllAnalitics column. The site was discontinued in 2018. The content here is not available anywhere else, so if you deem it useful, particularly if you are a regular reader, please help upkeep it by purchasing publications, or donating. On-site seminars and consulting are available.Thank you.


10/29 NEW "DATA MODELS" 3 (t&n)


10/16 NEW "DATA MODELS" 2 (t&n)


08/20 Added Logic and databases course to LINKS page.

- 08/19 Logical Symmetric Access, Data Sub-language, Kinds of Relations, Database Redundancy and Consistency, paper #2 in the new UNDERSTANDING THE REAL RDM series.
- 02/18 The Key to Relational Keys: A New Understanding, a new edition of paper #4 in the PRACTICAL DATABASE FOUNDATIONS series.
- 04/17 Interpretation and Representation of Database Relations, paper #1 in the new UNDERSTANDING THE REAL RDM series.
- 10/16 THE DBDEBUNK GUIDE TO MISCONCEPTIONS ABOUT DATA FUNDAMENTALS, my latest book (reviewed by Craig Mullins, Todd Everett, Toon Koppelaars, Davide Mauri).

- To work around Blogger limitations, the labels are mostly abbreviations or acronyms of the terms listed on the
FUNDAMENTALS page. For detailed instructions on how to understand and use the labels in conjunction with that page, see the ABOUT page. The 2017 and 2016 posts, including earlier posts rewritten in 2017 were relabeled accordingly. As other older posts are rewritten, they will also be relabeled. For all other older posts use Blogger search.
- The links to my AllAnalytics columns no longer work. I re-published only the 2017 columns @dbdebunk, and within them links to sources external to AllAnalytics may or may not work.

I deleted my Facebook account. You can follow me @DBDdebunk on Twitter: will link to new posts to this site, as well as To Laugh or Cry? and What's Wrong with This Picture? posts, and my exchanges on LinkedIn.


It is unknown, based on sheer tabular visualization, whether a relation is in 1NF, namely if attributes have:

  • Single or multiple values;
  • Atomic or or decomposable values.


We have defined precisely value atomicity and 1NF throughly and discussed it extensively in multiple posts. Instead of repeating all that here, we refer the reader to them:

First Normal Form in Theory and Practice series

Simple Domains and Value Atomicity

How to Think (and Not to Think) During Database Design

Forward to the Past: Out-clevering the DBMS

Setting Matters Straight

Is the relation visualized by the above table in 1NF or not?

Seldom are non-1NF relations designed intentionally in practice these days (but only because, luckily, SQL DBMSs do not support nested relations), and not because practitioners understand what it and value atomicity mean, and the implications. Indeed, as the above example demonstrates, few in the industry -- if any -- understand what value atomicity means in RDM. You can confirm this by testing your knowledge against our references.

Whether a relation is a database relation (i.e., is in 1NF as well as 5NF) cannot be determined by sheer inspection of a tabular display of the body of the relation (its extension), but only in conjunction with the conceptual model the database is intended to represent, which includes the semantic constraints (domain constraints in particular) (the intension of the relation) guaranteeing semantic consistency of the database with that model.

(Continued in Part 4)

No comments:

Post a Comment

View My Stats