Re: does a table always need a PK?

Ed,

"Ed prochak" <ed.prochak_at_magicinterface.com> kirjoitti viestissä news:4b5394b2.0308290703.1f0b1179_at_posting.google.com... > "Heikki Tuuri" <Heikki.Tuuri_at_innodb.com> wrote in message news:<q593b.818$n62.433_at_read3.inet.fi>...
> > Christopher,
> >
> > "Christopher Browne" <cbbrowne_at_acm.org> kirjoitti viestissä
> > news:bij2l3$9tgnj$3_at_ID-125932.news.uni-berlin.de...
> > > Centuries ago, Nostradamus foresaw when "Bob Badour"
<bbadour_at_golden.net>
> > would write:
> > > > Even still, I find it unforgivable for someone to implement a
> > > > self-proclaimed rdbms and not have any familiarity with this book.
It is
> > > > unforgivable for someone to claim an opinion on what constitutes an
> > rdbms
> > > > and not even know what 4VL is.
> > >
> > > I haven't seen any opinion being expressed, on the "MySQL side," as to
> > > what they think constitutes an RDBMS.
> > >
> > > Certainly nothing resembling the "Peano Axioms" that the MySQL guy
> > > seems to think _everyone else_ should consider as the level of
> > > discourse.
> >
> > I have said that the concept of an 'RDBMS' is vague. Lee Fesperman and
Bob
> > Badour say it is not vague. It is their job to provide the exact
definition.
> > In the threads with Mikito Harakiri and Jan Hidders you find some
reasons
> > why I am asking these questions.
> >

>
> I've been observing this thread and really you miss the point. Lee and
> Bob mentioned the paper. Bob gave a link to it. Reading it leads to
> this:
>
> <begin quote>
> The term relation is used here in its accepted mathematical sense.
> Given sets S1, S1, ···, Sn, (not necessarily distinct), R is a
> relation on these n sets if it is a set of n-tuples each of which has
> its first element from S1, its second element from S1, and so on. We
> shall refer to Sj as the jth domain of R. As defined above, R is said
> to have degree n. Relations of degree 1 are often called unary, degree
> 2 binary, degree 3 ternary, and degree n n-ary.
> For expository reasons, we shall frequently make use of an array
> representation of relations, but it must be remembered that this
> particular representation is not an essential part of the relational
> view being expounded. An array which represents an n-ary relation R
> has the following properties:
>
> 1.Each row represents an n-tuple of R.
> 2. The ordering of rows is immaterial.
> 3. All rows are distinct.
> 4. The ordering of columns is significant - it corresponds to the
> ordering S1, S1, ···, Sn of the domains on which R is defined (see,
> however, remarks below on domain-ordered and domain-unordered
> relations ).
> 5. The significance of each column is partially conveyed by labeling
> it with the name of the corresponding domain.
> <end quote>
>
> So Codd's paper is not adhoc, but really mathematical. The properties
> listed look very axiomatic to me. And to get back to the topic - is a
> primary key needed? - I think property 3 says it all. In the extreme
> case, all colums together form the key, but usually you have something
> less. So a PK is required. The only significant space for discussion
> is how to identify that key. (since there are practical reasons for
> wanting a PK that is less than all the columns). But tables must have
> a PK for it to be a relational DB by Codd's Definition as quoted
> above.
>
> I hope that answers at least this question.

you should read the postings also from other threads.

Yes, the above definition is exact and mathematical, because it describes a mathematical relation. It does not describe an 'RDBMS'. You cannot find a formal specification of Codd's rules below from it.

http://www.cis.ohio-state.edu/~sgomori/570/coddsrules.html

"
9. Logical Data Independence
Application programs and terminal activities remain logically unimpaired when information preserving changes of any kind that theoretically permit unimpairment are made to the base tables. "

"
6. View Updating Rule
All views that are theoretically updateable are also updateable by the system.
"

"
3. Systematic Treatment of Null Values
Null values (distinct from empty character string or a string of blank characters and distinct from zero or any other number) are supported in the fully relational DBMS for representing missing information in a systematic way, independent of data type.
"

> Ed

Regards,

Heikki Received on Fri Aug 29 2003 - 17:26:29 CEST