Re: Why relational division is so uncommon?

Vadim Tropashko <vadimtro_invalid@xxxxxxxxx> wrote in
news:1177691936.963082.35840@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:

On Apr 26, 6:45 pm, "V.J. Kumar" <vjkm...@xxxxxxxxx> wrote:
My simple point is that you cannot talk about the set containment
join if the relation attributes are not sets. You can say that the
set containment join is similar to relational division but saying
that it is the same thing would only confuse people.

Can't argue about terminology, although it is frequently useful to be
able to refer to relational division as a join.

What you are saying is, essentially, that

(a)
R1 <X,Y>: {<1, a>, <1, b>, <2, c>}

and

R2 <X,Y>: {<1, {a, b}> <2, {c}>}

are 'the same' relation;


(b)
'/' in

R1 / D1 = {<1>}, where D1<Y> = {<a>, <b>}

is 'the same' operation

as 'project/join' in

project(join(R2, D2, D2.Y is_a_subset_of R2.Y), X) = {<1>}, where D2<Y>
= <{a, b}>.

Obviously, neither (a) nor (b) is true, but I won't argue with you ;)


Some medical db developers
represent a set of symptoms as a comma delimited string:
"headache,nausea,fever". By doing that, they can express relational
division more efficiently, in some cases, than with traditional
well- known SQL queries.

I wonder how they can transform set containment into string
containment. Do they use a user defined function

contains(string1, string2)

which is possibly adapted to strings of comma separated words?



Yes, something like that.

PatientDecease(PatientName,DeceaseName) =
PatientSymptom(PatientName,SymptomName) /
DeceaseSymptom(SymptomName, DeceaseName)

One more point about this schema is normalization. I have a de ja vu
of 5 NF generalized to accomodate set joins...

How can a 5NF schema accomodate a set join if the set join tables are not
even in 1NF ?!





.