Re: Pizza Example

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:vMRcc.51783$db7.38366_at_newssvr16.news.prodigy.com...
> "Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message
> news:FeMW8KFKa0cAFwbr_at_thewolery.demon.co.uk...
> > Yet
> > if I try to predict where Mercury will be in a year's time, using
> > Newtonian Mechanics, I am going to get it embarrassingly wrong.
> >
> > What is important is knowing which models are appropriate, and when - I
> > would perfectly happily use Newtonian Mechanics to calculate the orbit
> > of Venus ... it's just that I know the answer will not be perfect. And
> > while the error is insignificant for Venus, it's very noticeable for
> > Mercury.
>
> I'm going to take another crack at this later, since I got little sleep
and
> am very tired, but the analogies between data models and physical
scientific
> models are just wrong, comparing apples and hockey pucks. But I lack the
> eloquence to explain it right now - maybe someone else could chime in.

I'll toss in some thoughts that may not be worth much:

There are many types of models, and definitions of the word. A model plane might in fact be capable of flight, which makes it a small plane. An economic model may be similar in its limited scope and size, though derived from equations suitable for larger scales, as a test of the fullblown model. Every computer system contains a model of the business or domain it's meant to support - and in some cases the system IS the model.

Normally in systems we talk about a model as an abstraction, but it's also a logical machine meant to simulate some of the workings of the business while ignoring many aspects that aren't important (and sometimes some that are). This is a different thing than a physical theory, meant to predict and explain. How? I dunno - I'm still working on it.

But because in information systems correlating a system to the business can be difficult if not impossible (because the system is part of the business, and "the business" can be hard to directly observe and predict, especially in light of future directions), it doesn't have the same goals or characteristics as a physical model, nor the same verifiability. A text file can be used to run a business - just not very well. If a database has no constraints, and puts the burden on users, then they can't very well complain about it being wrong, since they type in the data (and repeat much). Once you introduce constraints, you're making assertions, some of which are obvious and some of which aren't.

Given all that, we still need to distinguish between a model of a particular business, and (for example) the relational data model, which with respect to a given business data model is a "generator" of that model. I don't think that a "model generator" has the same purpose or criteria for success that a given model does, and assert that the relational "model generator" is superior in light of its ability to model any data, with minimum redundancy and thus minimal impact on users and DBMS implementers. A particular "business data model" can be compared to the business it's meant to model, but that's something "more concrete" than the relational data model - it's one particular use of it. And as systems analysis can be tough, that's clearly its own domain with its own problems.

Sorry for the rambling - I'm especially incoherent today. Received on Wed Apr 07 2004 - 14:29:43 CEST