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

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:40545c79$0$557$e4fe514c_at_news.xs4all.nl...

...[trim]...

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

It's only usenet ascii. I'd be keen to summarise it if a number of viewpoints can be agreed upon. We'll see what further contributions can reveal about the environment in general ....

> > From an IT engineering aspect, the RM is harnessed and part of
> > (to some nominal degree that is non-zero and not yet 100%) within
> > let us say the major RDBMS vendors at this point in history.
> >
> > There are hundred of thousands (therefore) of implementation
> > instances of the (evolving) Relational Model.
>
> 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.

Not at all, because these tasks are inherent in the proper conduct of IT professionals at the site, as the system and the organisation evolves. The model IMO is the theoretical blue-print which needs to be consulted at every change.

> In other words:
> What do you mean with an implementation instance of the RM?

A production load of database (RDBMS) and associated application software layer, etc to commence daily business for the organisation realtime, such that the RDBMS is to be responsible for the organisational data.

Or a development and DBA team heading towards the event described above.

...[trim]...

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

Normally it is the application level software (E3) that instigates data I/O or throughput in the form of add, delete or edit transactions upon the database.

However as has been pointed out RDBMS stored procedures are quite capable of acting as application software components. These are internal to the RDBMS.

Therefore IMO, the only other thing required is that a user interface be present such that users within an organisation can add, delete and edit the data. The user interface is traditionally associated with E3.

...[trim]...

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

Not sure myself at this stage. However it has something to do with the migration of the entire application layer (previously external to the RDBMS on the client machines largely) to the form of stored procedures (in totality) such that all the code for the application layer is housed along with the data within the RDBMS software layer.

I have accomplished a tool to engineer the above on SQL Server, and it works just fine in a number of sites here.

However I am interested in the theory of what I have done in practice, and the implications of that theory. Originally I posted the term "organisational intelligence" but too many misunderstandings arose, so I have approached things different in this thread.

Thanks for tagging along.

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

My reading of Date is only a few months old, but I have several decades of experience with database technology and what may or may not be engineered with it in terms of organisational solutions and systems of varying degrees of efficiency and automation, per unit manhours.

Information technology is the youngest of the modern sciences, and probably did not exist say 4 decades ago with the exception of a few organisations (IBM) and governments (US).

Consequently, I believe the RM of the data can be in the future developed and augmented by provision for reference to the corresponding applications which share that data, and handle the add/delete/edit interface to the organisational workgroups and individual users.

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

Thanks for the comments.

> >>>>>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.
>
> [snip]
>
> > 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.

What I should have said was that the middle tier is a bridge between the application (E3) and the RDBMS (E2) that has been used for a number of reasons.

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

An interesting exercise, indeed.

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

Precisely, to start with!

Added to the above elements of theory, the environment can often be clouded with things that most organisations dont really like talking about, but nevertheless resolve to internal issues of management and decision making, especially related to IT.

And then there are the usual "thousand one issues" which they dont teach you in theory classes that can emerge from a day's production business. Issues related to data integrity, or to change management in general.

Essentially, the database (E2) and the apps (E3) must evolve and change in response to the needs of the organisation. This change is ongoing, and is often resource depleting unless it is handles in an appropriate manner.

> > However I still maintain that the Relation Model itself, being mute
> > on the subject of the application layer, is not assisting clarity.
>
> 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?

The Relational Model (of data) imo seems to be a theoretical blueprint for the structure of the data. Some say it is yet to be incarnate, others say it is incarnate and evolving in existent RDBMS software (eg: SLQ Server, Oracle, DB2, etc).

My opinion is the latter.

In which case, it seems to me that the RM needs to be updated such that it can offer industry a great deal more than just the model of the data structure. (See below)

Date's subject matter is database systems, and the presentation is as if these systems are insular, which they were 20 years ago.

But really, IMO, database systems are effectively the following series of software, layed across a hardware layer (E0):

E1: Operating and network operating system software.
E2: RDBMS software
E3: Application system software.

These environments are symbiotic and not insular and although a great deal can be achieved in studying each separately, when push comes to shove in the real world, they MUST be managed concurrently.

As discussed, the E2-E3 combination is the wild-seed diverse element that resolves to an organisation specific implementation due to the different operating requirements every single organisation has compared to another.

As it happens, if one accepts like I do that the best manifestation of the Relational Model of data has been implemented in modern RDBMS software (albeit shall we concede not quite perfectly), then it seems very reasonable to examine a number of aspects associated with the large scale IT management of RDBMS instalations as exist today.

This involves acknowledging that each RDBMS site, say over a certain size and managed in an appropriate fashion might be used as an example of an "instance of implementation of the relational model".

The application layer (E3) actually also shares the data structure. The component E3 objects refer to different parts of the database in general, and need to be change-managed with this coordination firmly in mind.

Add to the above the use of stored procedures in place of external application E3 objects and you have a situation where not only are the E3 objects logically connected to the data structures, but they are physically housed within the RDBMS software.

In this situation it makes sense to me that on the basis of the above the theoretical relational model of the data might validly be expanded in time to address other areas of the database system that are to coexist with its implementation instances.

Hope this makes some element of sense.

Best wishes for now,

-- 
Pete Brown
Winluck P/L
IT Managers & Engineers
Falls Creek
Australia
www.mountainman.com.au/software