Few confusing things about first normal form

#1

greetings

1) For DB to be in 1NF there must be no multi-valued attributes, and
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?

2)

a) What else do we mean by repeating groups? Just duplicative columns
and multi-valued attributes, or …?

b) What qualifies as a duplicative column? I imagine there are cases
where it is not so obvious whether we are dealing with duplicative
columns or not?

thank you

#2

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-D.../dp/0321197844

--
David Portas

#3

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-D.../dp/0321197844

--
David Portas

#4

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-D.../dp/0321197844

--
David Portas

#5

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-D.../dp/0321197844

--
David Portas

#6

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-D.../dp/0321197844

--
David Portas

#7

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-D.../dp/0321197844

--
David Portas

#8

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-D.../dp/0321197844

--
David Portas

#9

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-D.../dp/0321197844

--
David Portas

#10

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-D.../dp/0321197844

--
David Portas