Re: Help! I can't support normalization

"David Cressey" <david_at_dcressey.com> wrote in message news:<huuB9.268$0I3.27200_at_petpeeve.ziplink.net>...
> > Cross product is just an aggregate operation
> >
> > select '<A,B>' as name, sum(a.value*b.value) from vector.a, vector.b
> > where a.name = 'A' and b.name = 'B'
> > and a.component# = b.component#
>
> Isn't the above the dot product, rather than the cross product?

Yes, the cross product of (a1,a2,a3) and (b1,b2,b3) is (a2.b3 - a3.b2, a3.b1 - a1.b3, a1.b2 - a2.b3).

Although it seems wrong to have a triple (1,2,3) in a single row and column of a table, it is nice in the sense that we can define the above expression once only. One of the principles of relational theory is that all information should be stored in relations. Assuming your RDBMS allows you to define your domains in relations (domain being a type plus operators?) you could define this complex formula only once and use it like:

SELECT * FROM t WHERE CROSSPRODUCT(t.r1, t.r2) = (0,0,0)

Also, strings could be thought of as non-primitive types if you think of "cat" as ('c', 'a', 't'). So is it any more wrong to have a "string" domain than it is to have a "3-tuple" domain?

Maybe RDBMSs should expose domains as relation more so you could do say "SELECT * FROM domain_string" where domain_string is a definition table of the domain of strings, and it would return all possible strings. Of course it wouldn't really store all the strings at the physical level, but calculate them as and when needed.

I'm often having to programatically create tables containing integers 1 to 100 say, it would be good if this was built-in so I could just do "SELECT integer FROM domain_integer WHERE integer BETWEEN 1 AND 100".

I'm not sure how you would relationally store the definitions of things like integer addition or the cross product mentioned above. I wonder if any has ever tried to make a totally pure RDBMS with the only built-in domain being {0,1} with the basic logical operations defined on it, and then to build up your usual domains from scratch?

Maybe to make the 3-tuple domain look better you could have a domain table where you list every possible 3-tuple and have an integer as the "public face" of the domain. Then use that integer in your main table instead of tuples.
so (1,2,3) might be denoted as "1" and (4,5,6) as "2". And (5,7,9) as "10". Then "1" + "2" would be "10" in this domain where we define "+" in the standard way. Is the concept of a domain even necessary - can we replace it with foreign key constraints? Should we distinguish between relations which are "domains" and relations which are "data tables"? Maybe the problem is domains which we don't explicitly list but generate with some algorithm?

Paul. Received on Tue Nov 19 2002 - 16:05:20 CET