# Re: Extending my question. Was: The relational model and relationalalgebra - why did SQL become the industry standard?

Date: Thu, 13 Feb 2003 20:48:53 -0500
Message-ID: <TfY2a.1416\$oU3.169475160_at_mantis.golden.net>

"Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message news:XPW2a.15\$O%2.103_at_news.oracle.com...
> "Steve Kass" <skass_at_drew.edu> wrote in message
> news:b2h96p\$ma2\$1_at_slb9.atl.mindspring.net...
> > Mikito,
> >
> > It's pointless to talk about the limit of a set S without setting
forth
> > some context. If you are talking about sets, the limit of {0,x} as the
> > real number x goes to zero is {0}. Why is the change of cardinality
> > "nasty"? There is no mathematical reason to think that the
> > cardinality function must be continuous.
>
> Steve,
>
> Let me try to provide an example as a context.
>
> Consider a database of all polynomial roots. In multiset model we have
>
> table Polynomial (
> id integer,
> power integer,
> coeff number
> )
>
> CONSTRAINT c1 UNIQUE KEY (id, power)
> CONSTRAINT c2 CHECK ( power >= 0 )
>
> table Roots (
> polynomial id number,
> root number
> )
>
> In the set model, I would have to make all tuples in the Roots relation to
> be distinct, and, therefore, add some extra column. When sets advocates
talk
> about a tuple reflecting some real-world relationship, how would they
> interpret this extra column? If numbers are real, it might be the
> enumeration induced by the total ordering of the roots. What if the
numbers
> are complex?

table Roots (

polynomial id number,
root number,
degree integer
)

CONSTRAINT c3 UNIQUE KEY (polynomial id, root) CONSTRAINT c4 CHECK ( degree > 0 )
CONSTRAINT c5 CHECK P in Polynomial (

P.power = sum(R.degree | { R in Roots, P.id = R.polynomial id}) )

I would interpret 'degree' as the number of coincident roots at 'root', and my interpretation does not depend on the specific set of values in the 'number' type. Received on Fri Feb 14 2003 - 02:48:53 CET

Original text of this message