Re: Article claims the following table is not in 1NF
Date: Thu, 23 Oct 2008 11:19:42 -0700 (PDT)
I apologize for my previous post, which should be posted in another thread
> 2) My book claims that if table is not normalized, then primary key
> > canít be made out of just one attribute. But how can that ALWAYS be
> > true, since even if a table has multi valued attributes or duplicative
> > columns, we could still have an attribute ( ORDER_ID ) that would
> > uniquely identify the row:
> If a table is not in 1NF, then it can't have a primary key at all. So the
> book's claim is true but meaningless.
Book based its arguments on the assumption that multi valued attributes are possible ( in theory, not in practice ) , since it argues that if we have multi-valued attributes, then table is not in 1NF, but at the same time it also implicitly suggests that if non organized table has a primary key, then it can only be concatenated primary key.
> Uniquely identifying a row is not what a primary key is all about. A lot of
> designers and even books make this mistake. In order for a primary key to
> really be a primary key, there must be one and only one column in the target
> table that might contain the value being retrieved. If ITEM1, ITEM2, and
> ITEM3 all carry the same semantics, then uniquely identifying a row isn't
> enough information to tell us where to look. We still have to look in all
> three items to find what we are looking for.
But formally ORDER_ID ( if I declare it as such ) is non the less considered to be primary key, even though it doesnít really do its job well?
> We believe you should not feel afraid to ask questions in this forum,
> so welcome to the forum and good on you for asking! Don't be upset if
> someone comes along in a minute and jumps up and down on you. Good
thanks mate, I appreciate it
thank you all for your kind help Received on Thu Oct 23 2008 - 20:19:42 CEST