Re: Why relational division is so uncommon?

On Apr 26, 6:23 am, paul c <toledobythe..._at_oohay.ac> wrote:
> V.J. Kumar wrote:
> > You wrote: "Informally, Relational Division corresponds to the any
> > quantifier in calculus, which should be as frequent as its exists
> > counterpart!"
>
> > In which calculus ? In SQL, ANY is a synonym for SOME (see a SQL
> > reference). In spoken English, ANY can be interpreted either universally
> > or existentially. Perhaps, you've meant FORALL ?

Sloppy language -- fixed.

> > In a word, it one of the most distinguished relational database features
> > - referential integrity - that undermines a possibility for a non vacuous
> > relational division query.
> > "
>
> > That's a strange conclusion based on a trivial Emp/Dept schema ! I hope
> > you are not denying that relational division can be quite useful to
> > express some queries. Consider a query: what patients have all of such
> > and so symptoms, or any similar question.

Just compare how many queries you can write for a sample apps database with those 7 relations:
1. You can project by any subset of columns. Or group by and aggregate.
2. You can join relations according to join graph, then group and count.
3. You can query even more things with negation.

> > The problems with the r.d. are that it arguably cannot be implemented
> > efficiently and is not as easy to understand as a typical SPJ query.
>
> I notice also that the example doesn't suggest a lot of activity, other
> than bureaucratic activity, this company might go out of business soon
> if there is no "sales" or "orders" or "inventory" relations. Lots of
> other useful queries would then arise, "who has paid all their invoices
> on time?", "which students have passed all course exams?".

Quite an interesting perspective. Although, the query "who has paid all their invoices
on time?" doesn't seem to be a relational division (what relation are you dividing into?)

> I have a feeling that most programmers aren't hip to divide and write
> more elaborate queries than they need to, involving "not exists" and
> maybe db designers end up with more attributes than are really needed.

This is an interesting observation as well. Consider a medical database schema:

PatientSymptom (

    name string,
    symptom string
)

DeceaseSymptom (

   name string,
   symptom string
)

Would db designers pressed hard to avoid set joins and create a redundant relation

PatientDeceases (

    patient_name string,
    decease_name string,
)

? Received on Thu Apr 26 2007 - 19:08:04 CEST