Is this a fair summarisation?
Finally three questions:
1) To what extent is "an environment external to the
database" referenced within database theory?
2) What extent of the user interface in any general database
application software system and supporting dbms/rdbms
(or depending on how your view it ... in any general
dbms/rdbms software and supporting application software
system) is external to the dbms/rdbms, and what is internal?
3) In the above, "internal" means literally defined with the
dbms/rdbms software as sql or contraints or triggers or
indexation management etc. Considering this definition
are there any examples of solutions in today's world
whereby database application software systems are
functioning close to 100% within the dbms/rdbms environment
rather than distributed on the clients, or application servers?
(ie: they are defined close to totally within the dbms/rdbms env)
Thanks for your consideration of the above three questions
and any comments on the fairness of the opening comment.
Farmer Brown
Falls Creek
OZ
www.mountainman.com.au/music
Q: What is a djembe?
A: An African drum.
I don't think I understand this, so I can't really comment.
> Finally three questions:
>
> 1) To what extent is "an environment external to the
> database" referenced within database theory?
In my experience, slim to none. In practice, we see
things like jdbc and odbc as APIs for the external
world to access the dbms, but these are not theoretical
concerns. Date makes passing mention of such things
in TTM but they don't seem to interest him.
> 2) What extent of the user interface in any general database
> application software system and supporting dbms/rdbms
> (or depending on how your view it ... in any general
> dbms/rdbms software and supporting application software
> system) is external to the dbms/rdbms, and what is internal?
It's all external. The only UI elements I've seen in a database
have been user-visible strings, and that usually (but not
always!) makes for a hard-to-internationalize application.
> 3) In the above, "internal" means literally defined with the
> dbms/rdbms software as sql or contraints or triggers or
> indexation management etc. Considering this definition
> are there any examples of solutions in today's world
> whereby database application software systems are
> functioning close to 100% within the dbms/rdbms environment
> rather than distributed on the clients, or application servers?
> (ie: they are defined close to totally within the dbms/rdbms env)
Not that I'm aware of.
Marshall
What's to understand?
There have been a few astute posts here and there to the effect that
notwithstanding the benefit of the development of "the internal
combustion engine" for automobiles, for the last 20 years automobile
theory (a la Shelby for example) has remained automobile centric in
its thinking.
I would say these "astute" posters have a fine grasp of the obvious.
An automobile consists of a number of inter-related parts perhaps the
most important being the internal combustion engine which drives the
entire assembly.
A computer system run by any general large organisation consists of
a number of inter-related parts the most important being the database
engine (dbms/rdbms) which is at the heart of the organisational
intelligence assembly.
One would expect database theory should say something concerning
how the dbms/rdbms sits within another "external" (horror!) environment
and how it relates to other software in the environment, particularly
the nature of any associated application system software.
However the experts appear strangely silent on the matter, preferring
to remain undividedly focused only on the engine component of the
overall assembly. Is this a fair comment?
How is this going to solve problems associated with the relationship
between the database engine (dbms/rdbms) and the overall assembly
(ie: the generic organisation's entire computer systems software concert)
> I would say these "astute" posters have a fine grasp of the obvious.
We'll see.
The whole point of any model (irrespective of the field of study) is
to allow all external systems using it to have a standardised means of
using it. Certainly, the Relational Database Model (from Codd, Date,
Darwen, st al) is intended to provide a systematic means of looking at
data so that every user and application within or without the
organisation in question can access it in an uniform manner. How the
actual RDBMS is implemented is irrelevant to the manner of obtaining
information from it or placing information into it. If a better
implemenation is found, then the RDBMS is changed with no impact on
the surrounding systems. Relational database theoty is about how to
manage your data in a manner that is correct, complete and safe.
I have seen too many databases that allow you to disregard the
business rules and data integrity rules, as well as allowing
inappropriately duplicated information that eventually gets so out of
sync that noone knows what is true and what is false. Having spent a
long time in analysing and finding the correct information and then
not having any way to have the stored information to be corrected, I
find it frustrating that people still insist on not using the
appropriate knowledge to alleviate this humungous problem.
From my perspective (in a business sense), anyone who advocates any
process, methodology or model that doesn't have a firm foundation is
either
a). ignorant of the problems that can and do arise
b). a used car salesman after a quick buck
c). couldn't care less about the consequences
d). should be doing something else more useful for everyone else
e). hasn't yet had the oppotunity to get better educated
I look forward to the time in a few short years when I no longer will
have to clean up the mess that has been foisted on the world by those
in the IT industry who have their agendas that are intended to pad
their own pockets at the expence of everyone else. I am thankful that
there are people of integrity in this industry - I just wish that
there were more.
The worst aspect of the IT industry (particularly the DB side of it)
is that due to those who are dishonourable, the rest of us get the
short end of the stick and are treated as .....
>
> However the experts appear strangely silent on the matter, preferring
> to remain undividedly focused only on the engine component of the
> overall assembly. Is this a fair comment?
Relational database theory doesn't actually look at the engine but at
the interface between the engine and the rest of the environment.
>
> How is this going to solve problems associated with the relationship
> between the database engine (dbms/rdbms) and the overall assembly
> (ie: the generic organisation's entire computer systems software concert)
>
The relationship between any two systems in any organisation are at
the mercy of the political influences within the organisation at any
time. This is not a matter for theory.
>
> > I would say these "astute" posters have a fine grasp of the obvious.
>
>
> We'll see.
Just don't expect many of the major commercial interests to make any
changes until their customers realise that there is something better
and that will only come with appropriate education.
mountain man wrote:
>
> There have been a few astute posts here and there
> to the effect that notwithstanding the benefit of the
> development of "the relational model" for databases,
> for the last 20 years database theory (a la Date for
> example) has remained database centric in its thinking.
>
You 're doing the same trick again: need to get the computer environment into
database theory, 'cause it 's incomplete without it.
Gosh: need to get the organizational environment into computing theory, 'cause
it 's no use without organization (wasn't it you writing about organizational
intellegence).
Yeah: we 'll have to get the society as a whole into the organizational theory,
'cause the organization does not function in a vacuum.
Your approach will lead you to a theory of everything. There are, at least to my
knowledge, no good examples of theories of everything. That is simply to
complicated.
One of the first steps in theory-building is choosing a limited field of which
you can build a good (simplified) model. Try and make that step.
Regards,
Ruud.
--
--------------------------------------------------------------------------------------
Ruud de Koter HP OpenView Software Business Unit
Senior Software Engineer IT Service Management Operation
Telephone: +31 (20) 514 15 89 Van Diemenstraat 200
Telefax : +31 (20) 514 15 90 PO Box 831
Telnet : 547 - 1589 1000 AV Amsterdam, the Netherlands
Email : ruud_d...@hp.com
internet: http://www.openview.hp.com/products/servicedesk
intranet: http://ovweb.bbn.hp.com/itservicemanager
--------------------------------------------------------------------------------------
So:
Appropriate education ==> Customer awareness ==> Commercial interests?
Are customers influenced more by education or the major commercial interests?
Maybe it's more like:
Commercial interests ==> Market saturation ==> Appropriate Education?
Stolen from sci.math:
FoxPro Programmers Who Have Read Bad Popular
Science And Decide That Now The Time Has Come
To Present Their Final Theory To The World.
Mike,
Personal experience follows:
A product had been developed (database) for a telecommunications based
company for the design of mobile phone networks. The transmission
design engineers had a number of requirements that they wanted. The
original development gave them a very uncoordinated and frustrating to
used facility to meet their needs. They were told that that was the
way it was going to be. As they were not familar with the possiblities
that cpuld be achieved, they put up with it.
Then I came along and was working on the system in question. As per my
usual behaviour, I was chatting with them regarding how they found it,
what extra facilities would be useful for them, what rules the system
should hold for them and so on. One of them raised the problem they
had with it as a complaint and said that they wished it could do what
they wanted. At this point, I told them that what they wanted was
quite feasible and this led into a discussion about the details. I
then helped them to draft their requirements and told them that they
were to push for the changes. Part of their attck was to state that
they now had advise that what they wanted was achievable.
It took me a couple of days to incorporate the changes but saved them
much more time in getting their job done.
Her it was educating them to the possiblities that were available to
them. I repeated this a number of times with different people and
project teams. All it required was for them to know that something was
possible and to their advantage and they ran with it. They then put
out the effort to ensure that the commercial reality of their desires
came to be.
As long as people don't know that there is a better way, they will
accept what they are given. But show them a better way and at least a
small number will push for that to become reality.
The fundamental rule to bringing about change is to get the the
gogetters educated (WHETHER GOOD OR BAD EDUCTAION) in the way you want
them to go and they will drag everyone else along with them.
This is how the world works - commercial interests "educate" people in
how "good" their products are so that people will buy them. But it is
always education first before change.
So that if you want:
Interest (commercial or otherwise) ==> Education ==> Acceptance ==>
Saturation
regards
Bruce Rennie
from God's Own Country Downunder
...[summary point]...
> > However the experts appear strangely silent on the matter, preferring
> > to remain undividedly focused only on the engine component of the
> > overall assembly. Is this a fair comment?
>
> Relational database theory doesn't actually look at the engine but at
> the interface between the engine and the rest of the environment.
OK this makes some degree of sense in an existential mode.
Thanks.
FWIW from my perspective everything concerns integrity.
That the whole point of the database is to maintain data with integrity.
That data without integrity is worse than no data at all.
Consequently I do understand
where you are coming from.
10-4
Good day.
> mountain man wrote:
> >
> > There have been a few astute posts here and there
> > to the effect that notwithstanding the benefit of the
> > development of "the relational model" for databases,
> > for the last 20 years database theory (a la Date for
> > example) has remained database centric in its thinking.
> >
>
> You 're doing the same trick again: need to get the computer environment
into
> database theory, 'cause it 's incomplete without it.
What I am doing is trying to understand this implication.
Is there anything wrong with trying to understand the nature of a
generalised computer system (os, rdbms,apps) in which the apps
environment has been contained within the rdbms?
See below...
> Gosh: need to get the organizational environment into computing theory,
'cause
> it 's no use without organization (wasn't it you writing about
organizational
> intellegence).
>
> Yeah: we 'll have to get the society as a whole into the organizational
theory,
> 'cause the organization does not function in a vacuum.
My article was about a term labelled organisational intelligence.
It is not a term used widely in theory.
As I have found since, the term is mainly used in selling.
This is unfortunate. My aim is the theory here.
However in my article I defined OI quite specifically.
Firstly I loosely defined it to be that OI contained in the computer
software.
by this ... "the sum of the data plus the sum of the source code"
I then derived a formula for the location and distribution of this OI
across a client server software environment consistent of:
* operating system software
* rdbms software
* application system software
Give us a break. Do you understand the formula?
> Your approach will lead you to a theory of everything. There are, at least
to my
> knowledge, no good examples of theories of everything. That is simply to
> complicated.
I agree. TOES are not the whole appendage system.
You have missed the fundamental.
In my case however, this theory has emerged after the contruction
of a software tool for the sql server rdbms whereby application software
components can be configured and stored as rdbms stored procedures.
This tool is not complicated.
It is not a theory. It is a tool I developed in my trade as a database
engineer which has the potential to change the way application system
software components are stored.
When an entire suite of application system software components
are represented and function as stored procedures within the rdbms
then what is left external to the rdbms software? Only this tool,
functioning as the interface between the user and the database.
> One of the first steps in theory-building is choosing a limited field of
which
> you can build a good (simplified) model. Try and make that step.
In this case I have built the software first, as a tool of my trade.
It is a concrete thing, very simple, very straightforward.
I walk into a sql server site with the tool and need no other application
development tool to commence the development of applications. The
application development is accomplished by the development of stored
procedures. All this is quite internal to the rdbms.
Nothing is external to the rdbms enviornment, except the tool.
(In terms of OI as defined: source code of the software and the data)
I am trying to understand if this has theoretical implications.
> Regards,
>
> Ruud.
Best wishes,
Farmer Brown
Falls Creek
OZ
www.mountainman.com.au/software
> Stolen from sci.math:
>
> FoxPro Programmers Who Have Read Bad Popular
> Science And Decide That Now The Time Has Come
> To Present Their Final Theory To The World.
Is this something like an index of emergent modern
scientific theories concerning the ancient aether?
http://www.mountainman.com.au/aetherqr.htm
Is it? I don't read about FoxPro so I wouldn't know. The idea seems pretty
obvious though, I wouldn't claim it to be highly original.
Should I read up on this, or is it only interesting for FoxPro issues?
Regards,
Ruud.
This will not be a long and detailed reply to your remarks. I 'll just state
that you seem to miss the difference between computer systems and the rest of
the world as it exists out there. The fundamental problem you seem to encounter
is an unability to grasp that a computer system (and a database as well) can
only contain a representation of real-world fenomena. What is in a computer is
never the real thing.
Consequently, organizational intelligence as such can never be stored (and
fixed) into a computer system. Organizations are complex structures consisting
of people (most importantly), structures, buildings, and equipment. Those are
all real-world things. They do not exist in computers. They are registered in
computers, perhaps simulated, but they don't exist there.
As long as computers are not intelligent, the same applies for (organizational)
intelligence: it resides in the people, perhaps in regulations, but not in
computers (and don't start about regulations being implemented by means of
computers, 'cause it 's still the regulations that are primary here).
Think about this. Try and grasp this. I don't know about your background, but do
realize: the world doesn't start or end with computers.
Regards,
Ruud.
--
[anecdote of educating users to possibilities snipped]
> As long as people don't know that there is a better way, they will
> accept what they are given.
Indeed. Just as Pickies and various other groups accept what they are given.
> But show them a better way and at least a
> small number will push for that to become reality.
You presume much.
> The fundamental rule to bringing about change is to get the the
> gogetters educated (WHETHER GOOD OR BAD EDUCTAION) in the way you want
> them to go and they will drag everyone else along with them.
>
> This is how the world works - commercial interests "educate" people in
> how "good" their products are so that people will buy them.
I see you put educate in quotes. Commercial interests seldom educate anyone.
Instead, they persuade. A huge chasm separates the persuasion and education.
> But it is
> always education first before change.
I disagree with respect to the "always" part.
> So that if you want:
>
> Interest (commercial or otherwise) ==> Education ==> Acceptance ==>
> Saturation
Commercial Interest ==> Persuasion ==> Acceptance ==> Saturation
I don't think so. The small number may not be successful but they will
push.
>
> > The fundamental rule to bringing about change is to get the the
> > gogetters educated (WHETHER GOOD OR BAD EDUCTAION) in the way you want
> > them to go and they will drag everyone else along with them.
> >
> > This is how the world works - commercial interests "educate" people in
> > how "good" their products are so that people will buy them.
>
> I see you put educate in quotes. Commercial interests seldom educate anyone.
> Instead, they persuade. A huge chasm separates the persuasion and education.
>
What is eductaion but the persuasion of others that you have the
correct information. Most people don't question what they are taught
and how many teachers/instructors have you had over the years that
allowed you to question what they were teaching you. I suspect that
there were very few.
It is not possible for you to check every thing that you are taught -
you would spend a lifetime just on a little bit of checking what you
know. An example, my middle son the other night made a staement about
the world being round and I said to him that since he hadn't proved
it, how did he know it was the truth. I then told him that the
flat-earther's could be very convincing about proving the world was
flat. I took him through a number of possible ways to prove that it
was not flat. What most people forget is that they do not question
what they know. If something in their experience tells them that
someting is true, even if false, thay will believe it. If something
else tells them that something is false, even if true, they will
believe it is false.
I suggest that there are few people who really want to know the truth
and then seek for it. Most people want to feel good about themselves
and so don't want to check that if they are wrong - it's too
uncomfortable.
>
> > But it is
> > always education first before change.
>
> I disagree with respect to the "always" part.
>
That's your point of view, but I suggest that it is nearly impossible
to bring about any change before you have educated at least some of
the people to the changes desired.
>
> > So that if you want:
> >
> > Interest (commercial or otherwise) ==> Education ==> Acceptance ==>
> > Saturation
>
> Commercial Interest ==> Persuasion ==> Acceptance ==> Saturation
regards
Bruce
Mate, the entire evolution of computing may validly be resolved
as an evolution in the ability to store a dynamic measure of
organisational intelligence within the computing system.
A less general term than OI is "business rules". These are
elements of organisational intelligence for a business organisation.
Surely you can see that business rules can be encoded to a computer.
You will find evidence of Organisational Intelligence everywhere
you look .... In the data such as contraints, etc and in the application
source code.
Gimme a break dude.
Philosophically I'd agree with the statement that the world does
not start and end with computers ---- there is more to the world.
But this isn't the alt.philosophy.computer.OI newgroup.
Have a good weekend.
"Ruud de Koter" <ruud_d...@hp.com> wrote in message
news:3FA23FCA...@hp.com...
You seem to feel a need to add some add hominem (rather misplaced):
>
> What do you do for aliving Ruud?
> Are you a brickie's laborer?
I might be. The important part is that I am trying to share some things with you
that I owe to a Uunivesity education. These are:
- if you discuss something, know what domain you are discussing (the start of
this thread: database theory is about databases, not about computers in
general),
- also: be sure to discuss the proper things (this post: the fact that business
rules can be encoded in a computer does not make them internal to the computer,
as you seem to think. Business rules are still external, but you -can- represent
them in a computer. This is no different from a database containing data on
people: the people are not internal to the database because there are data
stored on them. By the way: one way you could try and convince me (and possibly
others) of the validity of your approach is in showing where business rules are
different from people). More specifically: be on guard for confusion between
'the real thing' and the model thereof.
>
> Mate, the entire evolution of computing may validly be resolved
> as an evolution in the ability to store a dynamic measure of
> organisational intelligence within the computing system.
>
> A less general term than OI is "business rules". These are
> elements of organisational intelligence for a business organisation.
> Surely you can see that business rules can be encoded to a computer.
>
> You will find evidence of Organisational Intelligence everywhere
> you look .... In the data such as contraints, etc and in the application
> source code.
>
> Gimme a break dude.
>
> Philosophically I'd agree with the statement that the world does
> not start and end with computers ---- there is more to the world.
> But this isn't the alt.philosophy.computer.OI newgroup.
I am trying to give you a break: that 's why I respond. As you should be aware
of you are (also) posting at comp.databases.theory, and what I am writing is
theory. It may not be the piece of theory you want or expect, but it is theory.
In fact I am trying to show you that organizational intelligence (or whatever
term you prefer) is a field that is not related to computer science. The only
thing computers help at, is modeling organizational intelligence. But that can
be done in one's mind, on paper, on clay tablets, whatever. To the best of my
judgment, you are confusing the medium for the content. Don't want to hear this?
Then don't post.
One final remark: stop this silly anonymous posting. It raises the suspicion
that there is a reason why you don't post under your own name.
Regards,
Ruud.
--
--------------------------------------------------------------------------------------
Thanks. My main crop is soil, which I make by gathering masses
of schredded paper and mixing with grass clippings, bush scrap
and manure to turn to mulch, watered and turned periodically.
> You seem to feel a need to add some add hominem (rather misplaced):
It seems that many posters to this ng feel this need.
When in Rome ...
> > What do you do for aliving Ruud?
> > Are you a brickie's laborer?
>
> I might be.
It's not a bad job - did it for a while myself travelling around.
>The important part is that I am trying to share some things with you
> that I owe to a Uunivesity education.
Well thanks Ruud, I appreciate the dialogue.
>These are:
>
> - if you discuss something, know what domain you are discussing (the start
of
> this thread: database theory is about databases, not about computers in
> general),
One would expect that the domain of database theory would somehow
interface to the nature of, and the development of dbms/rdbms software.
Can you have in theory a database without a computer and operating
system? Perhaps on a backup tape or CD. But it would be difficult
to run a production (database related) system in this manner.
> - also: be sure to discuss the proper things (this post: the fact that
business
> rules can be encoded in a computer does not make them internal to the
computer,
> as you seem to think. Business rules are still external, but you -can-
represent
> them in a computer.
Business rules may be defined within the rdbms/dbms software.
Business rules may also be defined in the application system software.
This definition is by way of software code.
>This is no different from a database containing data on
> people: the people are not internal to the database because there are data
> stored on them.
> By the way: one way you could try and convince me (and possibly
> others) of the validity of your approach is in showing where business
rules are
> different from people). More specifically: be on guard for confusion
between
> 'the real thing' and the model thereof.
My claim would that business rules are a general form of organisational
intelligence
specific to a business organisation. In many instances these "rules" are in
response
to government legislation under which the business operates.
The rules can be simple or complex. In the simple case you'd only
need consider the allocation of pricing to shelf-stock in a supermarket.
If the item number is 239776532211 then the price is $22.00
Complex business rules cover the workflow of the business and
attempt to come to terms with the financial reporting cycles that
characterise all businesses, perhaps automating end-of-month
reports in various parts of the database on an anuual schedule.
Both the simple and complex forms resolve to parameters held
in the database schema in control tables that are responsible for
the automation of business processes and schedules.
Thus the business rules (or OI) may be stored as data in the
database, by representation as above. Not all businesses take
things to the nth degree, but many do.
> > Mate, the entire evolution of computing may validly be resolved
> > as an evolution in the ability to store a dynamic measure of
> > organisational intelligence within the computing system.
> >
> > A less general term than OI is "business rules". These are
> > elements of organisational intelligence for a business organisation.
> > Surely you can see that business rules can be encoded to a computer.
> >
> > You will find evidence of Organisational Intelligence everywhere
> > you look .... In the data such as contraints, etc and in the application
> > source code.
> >
> > Gimme a break dude.
> >
> > Philosophically I'd agree with the statement that the world does
> > not start and end with computers ---- there is more to the world.
> > But this isn't the alt.philosophy.computer.OI newgroup.
>
> I am trying to give you a break: that 's why I respond. As you should be
aware
> of you are (also) posting at comp.databases.theory, and what I am writing
is
> theory. It may not be the piece of theory you want or expect, but it is
theory.
Another poster commented that database theory deals with the
interface between the database and the rest of the system.
> In fact I am trying to show you that organizational intelligence (or
whatever
> term you prefer) is a field that is not related to computer science.
I was aware that the term (OI) was not in the academic literature.
However I believe it should be. Perhaps not necessarily database
theory, but certainly information technology management.
> The only
> thing computers help at, is modeling organizational intelligence. But that
can
> be done in one's mind, on paper, on clay tablets, whatever. To the best of
my
> judgment, you are confusing the medium for the content. Don't want to hear
this?
> Then don't post.
Modern production systems contain the dynamic workflow of
all their business processes and rules. In a fully automated and
electronic production site there would be no paper or clay
tablets. All is retained electronically in the database.
There are no ledgers, nothing except electronic data bound by
dbms/rdbms software into rows and tables.
> One final remark: stop this silly anonymous posting. It raises the
suspicion
> that there is a reason why you don't post under your own name.
I dont rate names highly, only ideas --- and ideas should be
able to be discussed independent of identity.
Thanks for the pointers.
Farmer Brown
(Pete Brown)
Falls Creek
OZ
www.mountainman.com.au