Re: The Practical Benefits of the Relational Model

"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message news:akli2v$2jve$1_at_sp15at20.hursley.ibm.com...
> >my definition of this "application logic" is not restricted to the client
> >application screens, or the database contraints, triggers, sprocs, etc.
> My
> >definition would have to include the concept of "organisational
> >intelligence" and if the organisation were busines oriented,
> > then this would be called the "business intelligence" or "business
> rules".
>
> Humm, so your "organisational intelligence" = "business rules" if we are
> talking about "business oriented organisations"
>
> So why exclude NGOs etc?
> But more to the point "business rules" = Database Constraints as far as
> I'm (and, oh him again: CJ Date) are concerned.
>
> If you disagree, give me an example of piece of "organisational
> intelligence" that you don't think can be expressed as relation values or
> as database constraints.

No. I agree this is emminently feasible in theory. See below.

> Regards
> Paul Vernon
> Business Intelligence (not a term I have a great love for), IBM Global
> Services

Thankyou also Jan for the response, very similar to the above, inasmuch as I probably need to be educated as to the formalised and reserved manner of expressing things in "theory of databases".

My problem stems from the fact that I studied database theory in Uni only for a short time in the very early 70s. From 1984 to the present I have been involved with the management of production databases, and my experience is from government and business...SQLServer rdbms and Wang Labs DBMS

From the above there are two issues to try and clarify:

1. What are the NGO's (which I have excluded?)
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.

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.

ie: That RDBMS applications retain much of the OI at the applications software level, inside explicit code sections in VB,C,Java, etc, etc, etc.

ie: that the physical location of the expression of the relational values is not always inside the RDBMS, that although there appears to be some form of physical migration of OI/BR happening (eg: increased use of stored procedures, triggers, contraints, etc) there is still bulk resident ALSO within the Apps Environment and not resident where I would like to see it exclusively located, internal to the RDBMS (as per CJDate, etc)

I would like to stop here in order to determine whether you think I am making any sense.

Thanks for the responses to this issue.
Best wishes,

Farmer Brown
Falls Creek,
OZ

PS: My apologies to Nathan Allan who started this thread for tangentiating in this manner a document which looked very broad yet cohesively structured. Received on Fri Aug 30 2002 - 02:17:57 CEST