Formally speaking any relation is *always* in 1NF by definition. A table
(for instance in SQL) is said to be in 1NF if it accurately represents some
relation, ie. it has: no duplicate rows; unique column names; no nulls; at
least one key. SQL doesn't permit multiple values in a column or repeating
goups of columns so those problems do not arise.

Informally, other notions are sometimes claimed to be associated with 1NF.
It is sometimes said that a column value "must" be "atomic" or that a
collection of attributes representing the same or similar things is a
violation of 1NF. The problem is that these are highly subjective ideas
which don't make much sense as hard and fast rules. It's best to consider
these as design guidelines and nothing to do with a formal definition of 1NF
proper, which is simply the definition of a relation.

If you expect to learn these concepts from miscellaneous web sites then you
will come to grief. Get a decent text by a respected author such as:
http://www.amazon.com/Introduction-Database-Systems-8th/dp/0321197844

When Codd first used the word "atomic", he may have intended it very
casually, as some of his intended audience were decision-makers, but
(just as they often are today) many of those were non-technical people.
It seems he was very much aware that no matter how good his idea was, it
still needed to be sold.

CJ Date and like-minded people have discarded the term "atomic", saying
it is at least imprecise and at worst meaningless as far as a Codd-ian
relation is concerned.

They now like to use a more mathematical term - scalar.  In their
approach, in a the kind of relation Codd had in mind, the values of
attributes are inherently scalar values.  But many authors still natter
on about atomic attributes.  Maybe they are the kin of the 1960's
secondary school teachers who were told to teach math from a set-theory
perspective, never having been taught the latter themselves.

Anyway, Date and company's attitude might make one wonder if 2NF should
be called 1NF, et cetera.

They discount "repeating groups" as well.  As far as I can tell for the
same reason.  When Codd wrote his first papers, several hierarchical
dbms's of the day as well as lower-level access methods had built-in
support for such constructs.  In fact I seem to remember that support
had even found its way into Ansi Cobol.  In his 1970 paper, Codd went
out of his way to show that such a construct was redundant and therefore
unnecessary.

Many in this camp also acknowledge the logical possibility of RVA's,
relation-valued-attributes, at the same time as saying that the
practical need for RVA's is rare.

Over the last hundred years or so, even the notion of atomic as being
indivisible that physicists used has wandered, not just because it was
discovered that atoms could be divided but also as more fundamental
particles were discovered. Even before then, some had surmised that
electrons might be jumping from atom to atom.  Somewhere Date makes the
point that data whose organization is expected to endure should be
stored using durable principles. If the same goes for the lingo used, a
mathematical noun/adjective seems better suited than a word like atomic
that has so many nuances in common language.

On Oct 22, 7:35 pm, Sru...@gmail.com wrote:

The site you refer to, if you have understood it correctly, is
mistaken. Both of the following are in 1NF:

R1 <name, age>
R2 <firstname, lastname, age>

It is a design decision which is appropriate for your task. However,
in almost all cases the second will be by far the better design .

A repeating group occurs when there are attributes in a proposition
which share the same role name. For example:

"person:Frank favourite pizza has topping:Peperoni, topping:Ham and
topping:Pineapple on it".

In this instance the "topping" role represents a repeating group.

In my experience it is always extremely obvious.

I would also echo Roy's sentiments concerning what is meant by
atomicity. I understand Codd's use of the word atomic as meaning that
a value cannot be decomposed by the relational algebra, unless it is a
relation. That is not to say, of course, a particular DBMS will bolt
on its own methods of decomposing data items - e.g. string or data
functions - but these are (correctly) not part of the RA proper.

greetings

no repeating groups. When so, data is said to be atomic. One site
claims that even first name and last name must be featured in separate
columns, but some other sites did  put  both first name and last name
into a single column, and yet still claimed the table was in 1NF? So
which is true?

First name and last name do not have the same semantics.  A person whose
name is "SAMUEL CHRISTOPHER"  does not have the same name as a person whose
name is "CHRISTOPHER SAMUEL".  Since the attributes are different
attributes, putting them in spearate columns does not cause an implicit
repeating group.

If you go across cultures, the semantics can become obscured.  For example,
the family name of "MAO ZEDONG" is "MAO".  Many Europeans do not realize
this.