Re: Multiplicity, Change and MV

JOG wrote:
> Apologies for this basic (and contrived) example,

Not at all. It's a lovely example.

> but hopefully its
> sufficient to show that change will have knock on effects to the
> queries of extant applications which interact with the database.

Well... you can keep the old-style "Lecturers" relvar as a derived relvar (view): the join of the new "Lecturers" and "Teaching". The key(s) will be different, of course, but many of your queries should remain unaffected. Those that make assumptions about cardinality will not, of course, but there's no helping that.

> This is what I'd like to focus on here - I am interested in exploring
> how one might reduce the dependency between query-form and
> db-structure. I find it jarring that a change in multiplicity has
> introduced a new relation

A multiplicity change is jarring anyway, I think---if the problem domain changes, I *expect* the database to change. I would be suspicious if it didn't.

> - perhaps it should have existed in the first
> place even with the 1-m relationship?

I routinely model 1-1 and 1-n relationships as separate relvars. That way, multiplicity changes only affect the key(s) (ignoring user interface issues), and I avoid nulls for optional relationships.

-- 
Jon