Re: Date is Incomplete - database application software and database theory

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

First off, I'll assume by your silence here that An Introduction to Database Systems is the only Date you have read. Date is one of the most prolific writers in the industry today, with literally hundreds of publications. You read one book and decided he doesn't address application development adequately? Wow.

Second, Database systems and applications development are still very much two, if not more, separate environments today, and the situation is only getting worse. Yes, we can write application logic server-side using stored procedures, but the logical models presented within the systems in which these procedures are written are inadequate for enforcing even the simplest of integrity constraints required by today's applications. As such, the integrity constraint enforcement is moved into a more general language that can handle the enforcement, albeit procedurally. If we had a language in the database management system that was capable of enforcing the integrity constraints (ideally declaratively) then we could automate the application development side of things. Until the DBMSs support such a language, the application logic will have to be external to them.

> Every single database system that I am aware of, correctly me
> if I am mistaken, requires not only the RDBMS software layer
> but also an applications layer (given that the OS layer exists).

Of course they require an applications layer, the question is, to what extent can that layer be automated? The answer is, almost completely, and the completely keeps getting more complete. By that I mean that a platform that enabled automated application development would always encounter scenarios that cannot be automated within the framework, but if the framework is built on a solid foundation, and is properly design with extensibility in mind, the framework could always be adapted to handle new scenarios. In this way, the platform would continue to evolve and become better and better at automating application development.

> I would have expected some more theory on this from Date,
> but it is reduced to one diagram. Here see, the apps environment
> is outside the box of database systems ....

In the one book you've read.

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

It's fundamental thinking, which you have to get right before you can go on to discuss things that are based on the fundamentals.

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

I don't think you do, or you wouldn't be disuputing it.

> Theory does not cease at implementation!
> Theory and implementation are inter-related.

No one is claiming that it does.

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

Are you asking me this? I don't understand. The operators can be modeled. They are called operators, and they are part of the model.

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

The 'application software environment that is generic' is not part of the fundamental theory of database management. That is not to say that it is not discussed in the literature. Again, you need to read more. What I'm telling you is that you're not coming up with anything new here. Research has been concerned with this problem as long as applications have been around. You should read what other people have done in this area before coming up with your own solution.

> A provide a definition here:
> http://www.mountainman.com.au/software/Theory_of_Organizational_Intelligence.htm

You quote Date, and yet fail to recognize that it encompasses the concept of an operator, even though the definition you quote makes explicit reference to operators. (BTW Stored Procedure = A special case of an *operator*) Received on Tue May 25 2004 - 18:36:06 CEST