Re: What are we asking of a data model?

"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. The 'relational' and the 'object' model method are probably not the best for this as they are so dependent upon the implantation of that model. For an example, the ER diagram model is simply an 'as built' or 'should be built' suggestion. There is almost a one to one relationship between the entity/attributes of the diagram and the tables of the implemented database. Normalization of the data model is paramount only for an implementation - NOT the description of what the data is and how it relates to other data.

What is needed is something that will easily display a set of relationships such as:

When I ride that horse I call it Trigger When you ride that horse you call it Champion The actual horse's name is Dobbin.

(the meaning of the name champion given to that horse only has context or meaning implied when that horse is ridden by you)

Or

A part number with a serial number has a part number serial number (read subassembly, here) contained within it installed on the subassembly on 1 January.

(the importance of the installation of that part on that date on that sub assembly of a major assembly is the important 'truth'). And you can't be confused by which assembly is somebody else's minor sub component.

all of these by using only a single (the same) tuple.

How those 'truths' are implemented is another level of abstraction.

The data model and the implementations of the model are at different levels of abstraction. Unfortunately current technique has the two so mixed up it is difficult to build a proper data model. If Codd had his way, you could only have one egg in each egg carton. And why can't people have multiple names and address in the same object. They do in real life. Its a fact.

Ok flame me. I have full flame retardant series #20 installed. Received on Sun Jan 11 2004 - 22:16:56 CET