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

Mikito Harakiri wrote:

>"Steve Kass" <skass_at_drew.edu> wrote in message
>news:b2h9jb$p0h$1_at_slb4.atl.mindspring.net...
>
>
>>I didn't read the whole thread, but in the right context, the
>>bags are functions, and intersect, union, etc. are all well-defined.
>>
>>
>
>I don't agree that the matter is "context dependent". One either has a model
>with a consistent set of operations that users like, or not.
>
>
Whether "users like" something has nothing to do with its mathematical consistency.

>
>
>>Definition: A multiset M over a domain U is a function with
>>domain U and range the set of non-negative integers.
>>
>>We say that the element x is in M if M(x) > 0.
>>We say that the element x appears in M with multiplicity k, if M(x) = k
>>We say that M = M' for two multisets M and M' on domains U and U'
>>respectively if M(x) = M'(x) for all x in the intersection of U and U' and
>>M(x) = 0 when x is not in U, and M'(x) = 0 when x is not in U'.
>>
>>Functions are well-defined in terms of sets also, subsets of U x Z where
>>(x,n) and (x,m) both in a function f implies n = m (single-valuedness).
>>
>>It makes no sense to take the union of two functions, but it does make
>>
>>
>sense
>
>
>>to take the sum (union all), min (intersection), and other operations.
>>
>>
>
>Union is redundant in multiset model anyway. It is a distinct "union all".
>"Distinct" is a grouped aggregate.
>
>
>
>>Just define things carefully and it's all much easier. If you think the
>>intersection
>>of two multisets, one containing two S's and one containing 3 should be a
>>multiset containing 6 S's, then see if it the product operation f*g(x) =
>>f(x)*g(x)
>>has useful properties for modeling the real world.
>>
>>
>
>With my definition
>
>select name from e1
>intersect
>select name from e2
>
>is identical to
>
>select e1.name from e1, e2
>where e1.name = e2.name
>
>This is not true with the "min" definition.
>
>
I didn't say it was. I said that "intersect" as you define it is given by the product of the functions. "intersect" the way SQL defines it is given by the minimum of the functions. They are both valid definitions, and if one is better for you, create a language for multiset manipulations that uses the word intersect for that one.

Because of its use for sets, intersect (I think) gives the impression of, well, intersection, not product. I just don't see why you'd call the operation defined by f op g (x) = f (x) * g(x) "intersect" instead of product.

>
>
>>I don't see why you
>>would
>>call something like that intersect, though.
>>
>>
>
>See the above.
>
>
>
>>As for what laws hold for multisets, you just go figure out which ones do.
>>
>>
>
>Found one that doesn't hold for multisets:-(
>
>select e1.name from (
> select e1.name, e2.name from emp e1, emp e2
>)
>
>is not the same as
>
>select name from emp
>
>More concisely:
>
>PROJECT*POWER != 1
>
>
>
Right. But there's no problem here, just as there's no problem with the fact that matrix multiplication is not commutative, even though matrices can be considered a generalization of a set where the multiplication is commutative.

For the record, the inverse operation of what you are calling power is relational division.

Let emp be a multiset. Let emp X emp be the cartesion product of two copies of emp. Then (emp X emp) / emp is emp, if we read / to mean relational division. The mathematical analogy is the factor operation where you factor a group by a normal subgroup to obtain cosets.

Steve

>
>
>
>
>
>
Received on Fri Feb 14 2003 - 06:31:35 CET