Re: A Database Design Issue

As you are probably well aware, every equivalence relation R over a set E gives rise to a partition P of E, and vice-versa:

PR = { p subset of E : (\/a,b in p) a R b } RP = (\/a,b in E)( a R b <=> (-]p in P)a in P and b in P )

Representing EQUIV as a partition makes perfect sense, and avoids the redundancy you mentioned. Regarding Steve's question, if it's really an equivalence relation then no entity can belong to two groups. What might be more problematic is the fact that technically every member of E must belong to exactly one subset p in the partition P, which suggests that there be a one-to-one relationship between E and EQUIV. What you really want is a field in E containing the group id for that element, and perhaps the EQUIV table would remain, containing only one (important) field, the group id, as its primary key.

Josh

"Stelios Sfakianakis" <ssfak_at_ics.forth.gr> wrote in message news:9gkle6$26hc$1_at_ulysses.noc.ntua.gr...

> When I realized these problems I tried to find a different way to express
> this "equivalence" concept and i finally came up with a slightly different
> solution: the EQUIV table remains the same but the first attribute is not
> (necessarilly) an e_id but an id of a *group* of equivalent e_ids.
 

> Do you see any flaws in this second approach?
> Any thoughts/suggestions are very welcome!
Received on Sun Jul 22 2001 - 01:32:27 CEST