Re: The Practical Benefits of the Relational Model

"Jan.Hidders" <hidders_at_hcoss.uia.ac.be> wrote in message news:3d6f5561$1_at_news.uia.ac.be...
> In article <j%yb9.18405$g9.57408_at_newsfeeds.bigpond.com>,
> mountain man <prfbrown_at_magna.com.au> wrote:
> >
> >2) I do not disagree. In fact it is my observation not from theory but
> >from the production floor that has convinced me that "IN THEORY" there is
> >nothing that cannot be expressed by the SQL at the RDBMS level.
>
> Do you mean that SQL can express all queries? That's not true, it may
often
> be in practice, but certainly not in theory; SQL is not computationally
> complete.

Can you provide me with an example of computation exemplifying the (theoretical) incompleteness of SQL?

> Or do you mean that with SQL you can express all database
> constraints? That's also not true. Roughly speaking it only covers
> first-order logic.

While that may be, armed with SQL code, some R&D and an RDBMS scheduled task queue I can enforce all constraints without exception whatever they may be.

> >In practice however, one invariably finds that the bulk of this OI/BR/etc
> >is in fact resident in the applications code and NOT in the RDBMS. This
> >was my point.
>
> Yes, but (1) you still haven't explained exactly what you mean with
> "OI/BR/etc"

Organisational Intelligence/Business Rules/etc The guts of the specific database application software code that the organisation or business happens to use.

>and (2) it's not clear whose fault that is. Many DBMSs already
> allow you to formulate complex database constraints. What do you think is
> the problem then?

The problem is the percentage of "OI/BR/etc" in the RDBMS and the percentage of "OI/BR/etc" remnant in the database applications software environment (external to the RDBMS).

The problem as I see it is to leverage the percentage towards the RDBMS as far as it possibly can be shoved, and there is no reason not to aim for 100%.

>Are the constraint languages not powerful enough? Is it
> not efficient enough? Are the application designer not able to formulate
the
> database constraints in some formal logic? Or what?

When any contemporary database application software system environment is loaded on top of an RDBMS, which has already been loaded on top of an Operating System Software environment, the total number of software systems environments is 3.

Using current program development tools and methodologies application developers do not use the RDBMS exclusively to code constraints and rules and often maintain these in the Apps environment code.

Ideally, according to CJ Date, this situation should be resolvable in the general sense such that all the logic contained in the APPS environment (ie: OI/BR/etc) might be represented entirely within the RDBMS. Somehow. But how is this to happen?

The problem is to migrate the code (usually written by application vendors) representing the BR out of the application code and into the RDBMS by some means. Does this make any sense to you on the other side of the Pacific?

Farmer Brown
Falls Creek, OZ Received on Fri Aug 30 2002 - 21:17:49 CEST