Re: A problem in SQL (a real challenge)

David Cressey wrote:

> Whether I agree with you or not depends on the interpretation of "has a
> primary key".
> I know this sounds like a politician, but I'm not trying to be evasive.
>
> A table might have the following features, in the abstract: no two rows
> will ever be identical,
> according to the business rules. Of all the columns, some are mandatory.
> That is, NULLS are
> not allowed. Some subset of the mandatory columns would make an adequate
> primary key,
> according to the business rules. And yet, no primary key has been declared
> to the database.
>
> Many people would say that such a table has no primary key. And for
> purposes of discussing things at the DBMS level, I would agree. However,
> if the question is "is this table in 1NF?" I would say that, in this
> context, the table has a possible primary key, and is therefore in 1NF.
>

The table is in 1FN because all the values are atomic, not by the fact that the table has a possible primary key. If you have the table:

column1 column2

a                1
b                2
b                3
a                1
b                3

this table has not a possible primary key but is in 1FN.

A table that is not in 1FN is:

column1 column2

a                1
                  2               row 1
                  4
  ..............................
b                3
                  2               row 2
  ..............................

in which the column2 has many values for a row. Is not that the value "a" of the column1 correspond with values "1", "2", and "4" in many rows but the value "a" of the column1 correspond with values "1", "2", and "4" in the SAME row. SQL not support this structure and so every table defined in SQL is in 1FN, no matter if has or not a possible primary key.

Cheers,

Raimundo Lozano Received on Fri May 12 2000 - 00:00:00 CEST