Re: Date is Incomplete - database application software and database theory
Date: Tue, 25 May 2004 10:42:36 GMT
Message-ID: <wqFsc.9766$L.3569_at_news-server.bigpond.net.au>
"John Jacob" <jingleheimerschmitt_at_hotmail.com> wrote in message
news:72f08f6c.0405240803.31571097_at_posting.google.com...
> > The same author reserves one diagram and perhaps a few sentences
> > in regard to the applications layer in his "Intro to Database Systems".
> > I will keep a look out for this other work, but his major work is
> > flawed - for the reasons given.
>
> This is not his major work. It is an introduction to database
> systems, not application development. Why should you be surprised
> that it doesn't cover application development? Is this the only thing
> you've read of his? You really need to get some more reading time in.
Historically database systems and applications development were two separate sets of boots, hats, or whatever. This is not the case today however ----- times change.
This is old world traditional thinking.
It is like saying, we are here to discuss the ying, but the
yang is not going to be part of the theory.
> > > The relational model cannot possibly have anything to say
> > > about the *implementation* of applications based on it.
> >
> > This statement is the common response by RM supporters.
> > Date says the same thing. You're just quoting chapter and verse.
>
> The relational model is *intentionally* silent about implementation.
> Are you arguing that we should dictate the method of implementation
> for DBMS vendors? What would be gained?
I understand its *intentional* silence.
> > The relational model of the data has alot to say about ongoing
> > change management of database systems after implementation
> > because the data schema in most organisations change in the
> > course of time.
> >
> > Every change management exercise can be viewed as a mini-
> > pre-implementation exercise and in this, even by your own
> > definitions, the RM is a useful tool to map and consider these
> > changes to the data existent (implemented) structure.
>
> I'm sorry, I can't unravel these paragraphs.
Paraphrase:
Theory does not cease at implementation!
Theory and implementation are inter-related.
> > > We already have it. It's called the relational model.
> >
> > It is a model of data. What needs to be modelled is something
> > slightly in excess of this "data alone", and includes processes
> > and applications, with respect to the organization.
>
> It is a model of data that includes provisions for operators to
> manipulate the data. It is *not* data alone. Data by itself wouldn't
> be very useful would it.
The operator's cannot be modelled?
> > > So I'll ask
> > > you once again, have you read What Not How?
> >
> > Date cannot get things right in his major publication concerning
> > an "introduction to database systems". What should I be looking
> > for in these other works?
>
> So if you wrote a textbook surveying database management systems and
> database theory, you would start with application development? I'm
> glad you're not writing the textbooks.
I would make mention of the theoretical relationships between the RDBMS and the application software environment that is generic.
> > If you cannot tell the difference between data and intelligence,
> > or perceive that they need to modelled in a different manner,
> > then how am I to assess your assessment?
>
> It is you who is claiming that the relational model does not support
> "intelligence", not me. You're assertion that the model is "just
> data" is simply wrong. If you do not understand the fundamental
> definition of the relational model, how am I to assess your critique
> of it? This is why I asked you to define the relational model when we
> first started this little odyssey. I should have pushed you harder to
> provide one.
A provide a definition here:
http://www.mountainman.com.au/software/Theory_of_Organizational_Intelligence.htm
Pete Brown
Falls Creek
Oz
Received on Tue May 25 2004 - 12:42:36 CEST