Re: MV and SQL

David Cressey wrote:
> "JOG" <jog_at_cs.nott.ac.uk> wrote
>
> > Ok, I have a question, with a bit of a build up: RM is based on the
> > satisfaction of a given predicate.
>
> [snip]
>
> > 1) Incomplete Data at entry time.
> > 2) Incorrect Design.
> > 3) Static Design which no longer matches how the real world has
> > shifted.
>
> [snip]
>
> >
> > In my eyes the fact that these 3 things happen so frequently indicates
> > that a system based on the satisfaction of a fixed predicate has poor
> > application to the real world and that the RM's solid mathematical
> > basis might be yet improved upon through integration of these issues.
> > Data is almost always incomplete, a designer cannot be omniscient and
> > will always make errors, but most importantly situations change.
> > Continually. It is preferable that we have a database model that
> > accomodates these factors: they are not orthogonal to data modelling
> > processes in the real world.
> >
>
> Without addressing your question about Pick, let me just comment on the
> above excerpts from your build up.
>
> First, the big to-do about nulls basically arises from the use of a single
> table row to encode more than one predicate. If one of the predicates is
> present, and the other one is absent, you get nulls.
> In theory, you could avoid nulls altogether by implementing a fully
> normalized design. In practice, it's better to live with nulls.

Hi david,

Yes, if I've followed the line of thought correctly, you are referring to predicate decomposition, where all rows are broken down to irreducible tuples. This makes perfect sense to me as someone focused on theory - but I'm obviously aware this isn't how we use RM in practical circumstances and afaik not how Codd envisioned such a system (hence his support for 3/4VL). The arguments I have heard against it are wholly practical - the colossal logistical weight of joining all those decomposed predicates to return appropriate results.

But then that is exactly my point - If RM at this decomposed level cannot function as desired in the practical world is this a weakness in the model? (perhaps a weakness that is satisfactorally bandaged with nulls) But is it something that other systems such as Pick have an advantage in?

I ask this as I am also particularly interested in schema evolution (or perhaps just design evolution). All models we currently use seem to have a rather static view of the world - they of course can adapt to new schema through structural change, but certainly don't seem particularly amenable to doing so. Are these MV models any different?

> Second, when you mention Incomplete data, that raises the question,
> incomplete with respect to what? Incomplete with respect to the real world
> requirements, or incomplete with respect to a designers idealized model of
> what the requirements are.
> The available data is the available data, whether it's "incomplete" or not.
> You can't store the unavailable data, no matter how clever you are. If the
> structure you've chose is too rigid to accomodate the data you've got, then
> there's a mismatch there. Whether or how Pick avoids that mismatch is
> something I'll leave to others.

Again I agree. When I refer to incompleteness I am referring to the mismatch that you've highlighted, between the designers idealized interpretation of the requirements, and the actual real world (and no doubt ever-changing) circumstances of data entry. This mismatch appears to happen so much that I wonder if should be a key consideration in the features of a model, rather than an afterthought. Again I was wondering if there are models out there which are notably advantageous in this area

> As far as incorrect design and obsolescent static design goes, that's a much
> longer subject.
>
> Two facets of that subject are: early binding vs late binding of design
> decisions, which is where my interest is going now, and the evolution of
> the schema as set forth by mountain man.
>
> Basically, you can't know what you are doing without fairly thorough
> analysis, and the art of analysis is still quite primitive, compared to
> design and implementation. If you aren't sure of what you're doing, late
> binding nearly always gives you better payback than early binding.

Sounds interesting - are there any good reference sources for this topic?

All best, Jim. Received on Mon Jan 23 2006 - 22:08:23 CET