Re: What are we asking of a data model?

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:btim0m$516$1_at_news.netins.net...
> 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?

The observer here is the "we", and in this forum there are many observers who are coming from a number of - lets call them entity-relationships to the organisation who is going to use this data model in production for their bread and butter.

This "we" could thus consist of any of the following:

1. CEO in the organisation
2. IT Manager of the organisation
3. Database application software develoment project leader (Impl phase only)
4. Application Development: programming staff (internal to organisation)
5. Application development: programming staff (external to organisation)
6. External consultants/team handling the development & implementation.
7. Database Design consultantcy.
8. Operations Manager of the organisation and helpdesk coordinator
9. Executive board of organisation responsible for "OKing" large expenditure.
10. DBA of the organisation, and/or DBA delegated staff.
11. External DBA resources and contractors
12. External software house who provide the major database application.
13. other database user, internal or external (to organisation)

I believe that one of the reasons for the disagreement is that the above sample of "we's" will necessarily all have differing perspectives of the whole picture, due to their relationship with the organisation which is going to host the finshed product.

> 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)

Given that all approaches will lend towards optimisations of one form or another, I'd summarise this approach as the one in which the optimisations
are those quantified by theoretical mathematics (eg: set theory).

> 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).

Cost is obviously important, and various parties listed above will perhaps have better understanding of its components than others.

Nevertheless, the above question highlights the fact that the data schema is one aspect, and the database application software is a second aspect.

If we consistently call the operating system software layer E1 and the dbms or rdbms software layer E2, then the application system software layer should for reference termed E3.

The E3 layer fits between E2 and the user of the database in the above list. I have taken the time to highlight this because I believe the answer to your question below is contingent upon understanding this.

> 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.

The data model is one variable, and this is defined in within E2 (see above).
The application software (E3) however is a second, independent and mandatory variable in the environment. It is usually sourced from different parties (software hourses) or developed in house or a bit of both.

E3 (database application system software) has issues associated with it that are not common to E2 (rdbms - the data implementation). My research and experiences has highlighted the fact that the data model is independently maintained and reflected in the code of E3.

Every user-interface screen component of E3, unless it does a query of the database schema, holds a copy of the data schema (for the data fields in that element of the interface).

Change management in the E3 environment therefore requires constant coordination between the data schema (layout) defined initially at E2, and all subsequent changes to it. This can be very expensive in itself. (eg: adding a column to database, updating the application E3 for the end-user)

> 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.

The implementation of the data model is half the consideration of the complete implementation due to the fact that the data model is defined in the E2 layer, and the user needs an E3 layer to see it.

The other half of the consideration is the development of the E3 application layer between the data and the user. In today's world there are various tools and methodologies for this development, selections of platforms. Often in the past it depended on the RDBMS selected.

Whatever E3 is it is organisation specific, and even if two separate organisations for example both select one application product E3 off the shelf, in the end their use of it will diverge. E3 often consists of modules - in general a business activity module surrounded by financial modules (AR. AP, GL etc).

> Thanks for any insight you can give on this. --dawn

I have reference to existing articles that seems to me to be relevant to the question asked.

http://www.mountainman.com.au/software/Theory_of_Organizational_Intelligence.htm

The introduction of the term "organisational intelligence" seems to be to be required
in order to define the full scope of "the code" and "the data" in a computer system
nowdays. While the term might sound strange to some initially I have attempted
in the article to properly and formally define it.

Pete Brown
Falls Creek
Oz Received on Thu Jan 08 2004 - 20:29:45 CET