Re: Why relational division is so uncommon?
- From: Vadim Tropashko <vadimtro_invalid@xxxxxxxxx>
- Date: 26 Apr 2007 10:08:04 -0700
On Apr 26, 6:23 am, paul c <toledobythe...@xxxxxxxx> 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,
)
?
.
- Follow-Ups:
- Re: Why relational division is so uncommon?
- From: paul c
- Re: Why relational division is so uncommon?
- From: V.J. Kumar
- Re: Why relational division is so uncommon?
- References:
- Re: Why relational division is so uncommon?
- From: paul c
- Re: Why relational division is so uncommon?
- Prev by Date: Re: Newbie question on table design.
- Next by Date: Re: temporal data constraints
- Previous by thread: Re: Why relational division is so uncommon?
- Next by thread: Re: Why relational division is so uncommon?
- Index(es):
Relevant Pages
|