Re: Principle of Orthogonal Design

On 21 jan, 18:58, JOG <j..._at_cs.nott.ac.uk> wrote:
> On Jan 21, 3:09 pm, "David Cressey" <cresse..._at_verizon.net> wrote:
>
>
>
> > "Brian Selzer" <br..._at_selzer-software.com> wrote in message
>
> >news:kO1lj.2507$nK5.335_at_nlpi069.nbdc.sbc.com...
>
> > > I think that there are times when it makes sense to 'collectivize' under a
> > > single predicate, and there are times when it does not.  In particular, if
> > > the individuals represented are just different kinds of the same sort of
> > > thing, such as is the case with the different kinds of phone numbers, then
> > > it makes sense to 'collectivize' those attributes that are common to all
> > of
> > > those individuals under a single predicate.  If, on the other hand, the
> > > individuals represented are different sorts of things that just happen to
> > > have the same attributes, then it doesn't.  A disjunctive
> > > predicate--something like, for example, each tuple exemplifies an
> > individual
> > > that is an X or a Y, just doesn't make any sense to me.  A conjunctive
> > > predicate on the other hand--for a relation that has multiple keys, for
> > > example--is not a problem since each tuple would exemplify an individual
> > > that is /both/ an X /and/ a Y.  So if the predicate can be stated so that
> > it
> > > is not disjunctive, then 'collectivizing' is to be preferred.
>
> > It seems to me that you are describing the generalization-specialization
> > pattern.
> > Am I reading you right?
>
> > > > Either way, I certainly find that appealing to notions of "meaning"
> > > > within formal design recommendations seems to head towards very
> > > > slippery ground.
>
> > Why?  If you called it "the semantics of the data"  instead, would that make
> > it less slippery ground?
>
> Absolutely not - worse in fact, because then it would be greased with
> buzzwords too ;) Years of working with the semantic web, ontologies,
> expert systems, etc have emphasised to me that "meaning" is only
> something that can be obtained via situated embodiement within the
> environment concerned, and that context is far too  complex a beast to
> be tamed by computerized encoding. As such I'd rather rules appealed
> to functional dependencies and logical consequents than to appeal to
> the slippery notion of "meaning".

Hear hear. But I think the part of POOD that actually does make sense and really removes redundancy and update anomalies can be defined that way. For example, if there is an inclusion dependency between a relation R and S then it makes sense to say that there is overlap in meaning. You can generalize this by defining the notion of overlap such that there is overlap if there is an inclusion dependency between (1) the result of a selection of R and (2) S, or vice versa. Or even more general, if "a selection of R" is interpreted as any conjunctive query, possibly with equalities and inequalities, that selects a subset of R. In all these case it holds that if you violate the POOD rule that says that there can be no overlap in meaning between different components of non-trivial join dependencies, then there is indeed redundancy. Moreover, in those cases you can solve that redundancy by making the redundant part explicit in a relation by horizontal and vertical splits.

Does that cover all types of redundancy caused by dependencies? I suspect not. For that you probably need to generalize the rule further such that it not only looks at overlap between components of join dependencies but also between the result of arbitrary conjunctive queries and components of join dependencies. It's currently not clear to me under which circumstances you are then still sure that this redundancy can be removed.

• Jan Hidders