Re: What are we asking of a data model?

Thanks, Tom that clears it up -- so our objective in creating a data model is to, uh, what was that again?
smiles. --dawn

"Tom Hester" <tom_at_metadata.com> wrote in message news:e4668$40042100$45033832$24205_at_msgid.meganewsservers.com...
> Let see, I guess that Bob meant:
> "A data model is presented, based on the extension of the concept of a
DBTG
> owner-coupled set to permit static and dynamic sets and a new kind of set
> referred to as a virtual set. The notion of connection fields is
introduced,
> and it is shown how connection fields may be used to construct derived
> information bearing set names, and hence permit the specification of
> (dynamic) sets which are not predeclared in a schema. Virtual sets are
shown
> to reflect the functional dependencies which can exist within a file. A
> technique which permits the data model to be fully described
> diagrammatically by extended Bachman diagrams is described. A predicate
> calculus for manipulation of this data model is presented. Expressions
> written in this calculus are compared with corresponding expressions in a
> relational predicate calculus, DSL ALPHA. An argument for the relational
> completeness of the language is given."? Or perhaps: "To sum up, it is
> proposed that most users should interact with a relational model of the
data
> consisting of a collection of time-varying relationships (rather than
> relations). Each user need not know more about any relationship than its
> name together with the names of its domains (role qualified whenever
> necessary).[see note 3] Even this information might be offered in menu
style
> by the system (subject to security and privacy constraints ) upon request
by
> the user." Or,...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
> news:aLOdnSsB65zwhp7dRVn-iQ_at_golden.net...
> > "SPeacock" <Xpeacock_at_pacbell.net> wrote in message
> > news:4001BE3B.3BFF4B97_at_pacbell.net...
> > >
> > > "Dawn M. Wolthuis" wrote:
> > >
> > > > I'm sure we cannot get unanimous agreement on this, but can we get a
> > good
> > > > statement of what it is we are trying to accomplish with a data
model?
> > > >
> > > > For example, it seems that some are asking a question such as "What
> > > > mathematical model for structuring data is the simplest we can find
> for
> > > > hosting predicates and related propositions?" (and I'm sure someone
> > else
> > > > can word that better, so please take a crack at it)
> > > >
> > > > while others are asking: "which data model is most likely to yield
> > database
> > > > implementations that are the most cost-effective for the development
> and
> > > > on-going maintenance of software applications?" (again, not a
> > > > perfectly-stated question).
> > > >
> > > > I am looking for answers to the latter question. My interest is in
> data
> > > > models whose implementations yield software developer productivity
> both
> > with
> > > > initial development of applications and on-going support.
> > > >
> > > > If we were able to set up a contest to collect emperical evidence
from
> > > > various data model implementations and how they relates to developer
> > > > productivity, would that have any bearing on this discussion or
would
> > some
> > > > database theorists consider such scientific (emperical) data
> collection
> > to
> > > > be irrelevant to what they care about? I recognize that no
> > implementation
> > > > perfectly matches a mathematical model, so perhaps some are more
> > interested
> > > > in comparing only the models and not looking at what these models
have
> > to do
> > > > with actual database implementations.
> > > >
> > > > Thanks for any insight you can give on this. --dawn
> > >
> > > The main purpose for a data model is to represent the relationships
> > between
> > > data.
> >
> > SPeacock, you are as stupid and ignorant as Dawn. You deserve each
other.
> > plonk
> >
> > For the others out there, see what Codd wrote regarding the purpose of a
> > data model a couple decades ago and ignore these bozos.
> >
> >
>
> Received on Tue Jan 13 2004 - 18:52:41 CET