Re: Date, the relational model and the application (software layer)

Hi mountain man,

Thank you for starting this thread.

Are you planning to summarize later on? I snipped a lot just to keep the size of this post within reasonable bounds, and even now it is huge, sorry for that. Maybe it is time to split.

mountain man wrote:

[snip most of Q1]

> "mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message
> news:4052ed00$0$565$e4fe514c_at_news.xs4all.nl...

>>It is very useful to have a datamodel of (parts of) hardware,
>>OS, the network and application software, preferably in terms of the RM.
>>Wether it is practical to actually maintain these data with the use of a
>>DBMS is another question. This suggests the RM exists (has a raison
>>d'etre) outside the realm of any DBMS.

This seems to disregard the important use of the RM as a reference for modelling and communicating the organization's data, regardless of some specific DBMS. In other words:
What do you mean with an implementation instance of the RM?

> Now, lets first
> concede that it is quite possible, and in many cases quite common,
> for the implementation of real-live organisational daily bread and
> butter database applications, the implementation could be done
> better. Let's leave this issue aside, and assume the best impl.

Useful implementations of anything formal can't be pure. So, while we might have a different view of what was implemented, we can agree on this assumption.

> Thus, in real terms we have this RDBMS at the very heart of
> the organisational activity.

It is *at* the heart allright. It doesn't pump, however. So, in this metaphore, the question becomes: What more is needed to get a pumping heart?

> Obviously, in a fully blow E-office,
> the hardware and network geography, topology, user-base
> (h/w) ditribution would be within tables in the RDBMS, and
> also presumeably a financial asset register, tracking this
> aspect of the hardware.
>
> OTOH the E1 software can be managed in tables,
> as can the E3 (application level) software. In fact,
> with large suites of E3, one cannot do without databases
> (eg: problem resolution, change management issues, Help
> Desk, etc). to assist in the admin of change.
>
> It is the E3 side that is to me important, because it is obviously
> the wild-seeded environment amidst the (E0,E1,E2,E3) melting
> pot which has to be appropriately managed at every one of
> the RDBMS sites on the planet.

I'm not sure what you are aiming at. A guess: A datamodel for proper management of the application layer.

[snip most of Q2]
> ... I think that in fact there is a fair degree of maturity inherent in the
> maturity of the mathematics available to the RM, because it in
> fact does represent so many centuries of development to be able
> to arrive at the contemporary understanding of group theory (to
> use your example).

 From my personal experience:

The times I tried to discuss data and the RM with people who professionally practise mathematics (one person 'pure' and one person 'actuarial'), we found an unsurmountable language barrier. All the familiar words seem to have a slightly to completely different meaning.
This does not happen on such a scale when we discuss other topics. My explanation is that the RM somehow declined this maturity - maybe for good reasons.
Other experiences and explanations welcome.

> The RDBMS is more than the vessel for the data model, due
> to its physical and genuinely central role it plays in today's
> production sites.
>
> It is also conquering things from the implementations of the existent
> RDBMS solutions as discussed above, world wide.
>
> If the model is indeed inculcated in the modern RDBMS software
> then the model needs not to remain mute on the interfaces between
> the RDBMS software layer (E2) and the others.

I understand this as: We need theorists agreeing on language and type issues, preferably in terms of the RM vocabulary (because that is supposed to be inculcated already). (Tutorial D or) D may prove valuable for this, but it is not enough. Maybe somebody else here can tell us where to look for other contributions.

>>>>>Question 3:
>>>>>In recent years there has been an increasing tendency to 
>>>>>migrate "code" from the application software environment 
>>>>>E3 to the RDBMS software environment E2.

> The whole reason for the existence of the middle tier is the
> misunderstanding that is capable of happening between
> the E2 and the E3. The middle tier is often necessary to
> rescue applications that are not capable of being changed
> to work correctly from the ground up.

I am not convinced that the proliferation of 3-tier apps is the result of this misunderstanding *only*, or that the middle tier's *only* purpose is to escape the consequences of mistakes.

However, as as far as they are, it looks promising to investigate what exact misunderstandings and mistakes helped causing this multi-million Euro market.

> Their purpose is to correctly interface an existent E3 package
> to an existent E2 package, when noone wants to do the task
> from the ground up, or it is too hard, or too expensive, or
> there are insufficient resources available to the organisation
> for example.

So: Where/what exactly are the error-prone problems preventing us from doing it the right way? I'ld hint at
1. ways to get your predicates right
2. languages and types

>>>>>Examples of this evolving tendency include the use of
>>>>>database constraints, triggers, but are dramatically highlighted by the
>>>>>utility of RDBMS stored procedures. (eg: this code may have been
>>>>>previously physically held external to the DBMS on the client app E3).
>>>>>
>>>>>Date does not seem to address this (evolving) issue ... How does the
>>>>>relational model interface the application software environment?
>>
>>Maybe not directly. I haven't read enough on this yet.
>>I do remember Chris Date requiring
>>computational completeness for a relational language.

To me it seems you are mixing (abstract) models and (recurring) architectures in a strange way here, but I also feel you are pointing
at a very real need for clarity.

So, and this sounds but is not meant to be cynical: Could you please try to restate
this need for clarity more clearly?

[snip most of Q4]

>>>1) the R-Model is theory about data (alone and independent of apps).
>>>2) the R-Model is embodied to some degree within RDBMS software.
>>>3) there is always "in production" an interface between RDBMS and the
>>>   application.
>>>    [you are absolutely correct that it is a service level interface]
>>>4) there appears "in DB theory" to be little if any interface between
>>>   the R-Model and the "models apps" (notwithstanding the 1st
>>>   sentence in the above).
>>...[1]

Most individual applications have a simplified model. This is a good thing(TM), it reduces complexity to a managable level.
These simplified models theoretically should be definable in views (a.k.a. 'virtual relvars').

In current practice this is often to cumbersome. Why?

> It may have certainly started out that way, however we have
> come a long way since Codd Rules etc, especially with the
> RDBMS implementations of the current day.

Types were not the issue in Codd's famous article. However, every DBMS vendor made (had to make) arbitrary choices regarding types. In practise we circumvent the consequences with mappings, conversion, translation, extractions, transformations, datamarts, whatever, whenever there is a business case. Cleaning up is necessary on a theoretical level, but who will do that?

>>4.2: Not necessarily - but that will come as no surprise
>>after my earlier remarks.

>>4.3:
>>A := database.new;

>
>>(A statement in some imaginary language that did
>>not abuse the single equals sign for assignment)

'=' is the traditional sign for 'equals' Many programming languages (C, Perl, Java) have used it to mean something different: there '=' is the simplest assignment operator. "T'is true, t'is pity." (Hamlet Act ii Sc. 2)

>>4.4:
>>I may not have understood the Q. As far as I did:
>>What would you/we need in that area beyond a language?

Hm... a need to express the data (including the model) to the environment in a simple way, a need to interpret queries. These seem language issues to me.

>>>>>...
>>>>>Question 5:
>>>>>The above 3 software layers might be physically and logically separate
>>>>>however they must be managed at an implementation concurrently.
>>>>>The end database systems solution thus appears as an evolving
>>>>>symbiosis of these 3 different software environments.  Is this a
>>>>>reasonable statement?
>... I am talking about managing the theory of it all

This sounds like what I would label a 'reference context' for a database. Sounds promising.

[snip]
> It's a SQL Server RDBMS.
> Bill has table 42. ;-)
Mice! I knew it.

> And there are indeed turtles
> all the way down!
Turtles pen-up pen-down .. wasn't that Logo? Received on Sun Mar 14 2004 - 14:21:42 CET