Few confusing things about first normal form

#41

On 23 Oct, 01:28, Sru... (AT) gmail (DOT) com wrote:

Quote:

greetings

I realize that the arguments you gave here basically also answered my
first question in another thread. But with regards to my second
question in that other thread, your argument here is also that SQL
doesn’t allow multi valued attributes. But if we limit our discussion
just to the theory, then multi valued attributes can exist. Thus table
( where ITEM column holds multiple values ) in my second question

ORDER ( ORDER_ID, ITEM )

is not normalized and as such the question is still valid?

If ITEM truly is multi-valued then ORDER is not a relation. All
attributes are equally important. The fact that it has a regular
scalar attribute as a key is irrelevant because if ITEM isn't one
value then the operators like equality, assignment and projection
can't apply in their usual sense.

I don't mean to exclude the possibility of relation-valued attributes.
A relation is a value so RVA's are perfectly OK in principle.

--
David Portas

#42

On 23 Oct, 01:28, Sru... (AT) gmail (DOT) com wrote:

Quote:

greetings

I realize that the arguments you gave here basically also answered my
first question in another thread. But with regards to my second
question in that other thread, your argument here is also that SQL
doesn’t allow multi valued attributes. But if we limit our discussion
just to the theory, then multi valued attributes can exist. Thus table
( where ITEM column holds multiple values ) in my second question

ORDER ( ORDER_ID, ITEM )

is not normalized and as such the question is still valid?

If ITEM truly is multi-valued then ORDER is not a relation. All
attributes are equally important. The fact that it has a regular
scalar attribute as a key is irrelevant because if ITEM isn't one
value then the operators like equality, assignment and projection
can't apply in their usual sense.

I don't mean to exclude the possibility of relation-valued attributes.
A relation is a value so RVA's are perfectly OK in principle.

--
David Portas

#43

On 23 Oct, 01:28, Sru... (AT) gmail (DOT) com wrote:

Quote:

greetings

I realize that the arguments you gave here basically also answered my
first question in another thread. But with regards to my second
question in that other thread, your argument here is also that SQL
doesn’t allow multi valued attributes. But if we limit our discussion
just to the theory, then multi valued attributes can exist. Thus table
( where ITEM column holds multiple values ) in my second question

ORDER ( ORDER_ID, ITEM )

is not normalized and as such the question is still valid?

If ITEM truly is multi-valued then ORDER is not a relation. All
attributes are equally important. The fact that it has a regular
scalar attribute as a key is irrelevant because if ITEM isn't one
value then the operators like equality, assignment and projection
can't apply in their usual sense.

I don't mean to exclude the possibility of relation-valued attributes.
A relation is a value so RVA's are perfectly OK in principle.

--
David Portas

#44

On 23 Oct, 01:28, Sru... (AT) gmail (DOT) com wrote:

Quote:

greetings

I realize that the arguments you gave here basically also answered my
first question in another thread. But with regards to my second
question in that other thread, your argument here is also that SQL
doesn’t allow multi valued attributes. But if we limit our discussion
just to the theory, then multi valued attributes can exist. Thus table
( where ITEM column holds multiple values ) in my second question

ORDER ( ORDER_ID, ITEM )

is not normalized and as such the question is still valid?

If ITEM truly is multi-valued then ORDER is not a relation. All
attributes are equally important. The fact that it has a regular
scalar attribute as a key is irrelevant because if ITEM isn't one
value then the operators like equality, assignment and projection
can't apply in their usual sense.

I don't mean to exclude the possibility of relation-valued attributes.
A relation is a value so RVA's are perfectly OK in principle.

--
David Portas

#45

On 23 Oct, 01:28, Sru... (AT) gmail (DOT) com wrote:

Quote:

greetings

I realize that the arguments you gave here basically also answered my
first question in another thread. But with regards to my second
question in that other thread, your argument here is also that SQL
doesn’t allow multi valued attributes. But if we limit our discussion
just to the theory, then multi valued attributes can exist. Thus table
( where ITEM column holds multiple values ) in my second question

ORDER ( ORDER_ID, ITEM )

is not normalized and as such the question is still valid?

If ITEM truly is multi-valued then ORDER is not a relation. All
attributes are equally important. The fact that it has a regular
scalar attribute as a key is irrelevant because if ITEM isn't one
value then the operators like equality, assignment and projection
can't apply in their usual sense.

I don't mean to exclude the possibility of relation-valued attributes.
A relation is a value so RVA's are perfectly OK in principle.

--
David Portas

#46

On 23 Oct, 01:28, Sru... (AT) gmail (DOT) com wrote:

Quote:

greetings

I realize that the arguments you gave here basically also answered my
first question in another thread. But with regards to my second
question in that other thread, your argument here is also that SQL
doesn’t allow multi valued attributes. But if we limit our discussion
just to the theory, then multi valued attributes can exist. Thus table
( where ITEM column holds multiple values ) in my second question

ORDER ( ORDER_ID, ITEM )

is not normalized and as such the question is still valid?

If ITEM truly is multi-valued then ORDER is not a relation. All
attributes are equally important. The fact that it has a regular
scalar attribute as a key is irrelevant because if ITEM isn't one
value then the operators like equality, assignment and projection
can't apply in their usual sense.

I don't mean to exclude the possibility of relation-valued attributes.
A relation is a value so RVA's are perfectly OK in principle.

--
David Portas

#47

paul c wrote:

Quote:

Srubys (AT) gmail (DOT) com wrote:
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. ...

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.

I think we can be certain he did intend it casually because he never
went on to make any argument based on what it (might) mean. So in
effect his failure to define it is no more significant than Euclid
failing to define or comment on the concept of colour.

Furthermore we know that relational algebra doesn't provide tools to
discern the internal structure of any value. If we were going to
explain that to someone we'd probably also say values are atomic. It's
an excellent word for the idea.

The usual misunderstanding seems to be to think that RT and SQL tell us
we have to do something to our designs to *make* our values atomic. But
that is backwards. We can use any kind of value we want, including the
classic list of pizza toppings, but RT (if not SQL) will only ever be
able to treat it as an atom. (Having said that, I am still not at all
happy with RVAs! :-)

--
Roy

#48

paul c wrote:

Quote:

Srubys (AT) gmail (DOT) com wrote:
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. ...

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.

I think we can be certain he did intend it casually because he never
went on to make any argument based on what it (might) mean. So in
effect his failure to define it is no more significant than Euclid
failing to define or comment on the concept of colour.

Furthermore we know that relational algebra doesn't provide tools to
discern the internal structure of any value. If we were going to
explain that to someone we'd probably also say values are atomic. It's
an excellent word for the idea.

The usual misunderstanding seems to be to think that RT and SQL tell us
we have to do something to our designs to *make* our values atomic. But
that is backwards. We can use any kind of value we want, including the
classic list of pizza toppings, but RT (if not SQL) will only ever be
able to treat it as an atom. (Having said that, I am still not at all
happy with RVAs! :-)

--
Roy

#49

paul c wrote:

Quote:

Srubys (AT) gmail (DOT) com wrote:
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. ...

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.

I think we can be certain he did intend it casually because he never
went on to make any argument based on what it (might) mean. So in
effect his failure to define it is no more significant than Euclid
failing to define or comment on the concept of colour.

Furthermore we know that relational algebra doesn't provide tools to
discern the internal structure of any value. If we were going to
explain that to someone we'd probably also say values are atomic. It's
an excellent word for the idea.

The usual misunderstanding seems to be to think that RT and SQL tell us
we have to do something to our designs to *make* our values atomic. But
that is backwards. We can use any kind of value we want, including the
classic list of pizza toppings, but RT (if not SQL) will only ever be
able to treat it as an atom. (Having said that, I am still not at all
happy with RVAs! :-)

--
Roy

#50

paul c wrote:

Quote:

Srubys (AT) gmail (DOT) com wrote:
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. ...

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.

I think we can be certain he did intend it casually because he never
went on to make any argument based on what it (might) mean. So in
effect his failure to define it is no more significant than Euclid
failing to define or comment on the concept of colour.

Furthermore we know that relational algebra doesn't provide tools to
discern the internal structure of any value. If we were going to
explain that to someone we'd probably also say values are atomic. It's
an excellent word for the idea.

The usual misunderstanding seems to be to think that RT and SQL tell us
we have to do something to our designs to *make* our values atomic. But
that is backwards. We can use any kind of value we want, including the
classic list of pizza toppings, but RT (if not SQL) will only ever be
able to treat it as an atom. (Having said that, I am still not at all
happy with RVAs! :-)

--
Roy