Let's first take a look at the history of the development of the database, and hopefully this will give you a clue as to why we decided on the name Quixote.
[Here is a hint: The most important word is missing. Put it on, and use it as an acronym!]
In the age of pre-relational databases, users of hierarchical databases or network databases could not easily determine how they should search for data unless they knew how the data in the database was structured. To solve this problem, Dr.Codd used a table format for the basic data structure and built relational algebra and relational calculus into the design. These algebra and calculus were used to allow exact mathematical relations to be set between items stored in the database. This step was a catalyst in encouraging others to further develop the relational database.
As a result of this wave of research, large improvements were made to the search speed, and a consistent basis for database design made updating workable. As a result the overall reliability of databases increased.
During the 1980's the relational database came into its own and made inroads into the office, due mainly to the fact that the table structure of the data matched the way that information is recorded in an office. At the same time, computers became faster to the point where they could easily handle the algebra and calculus involved in relational database access, and user interfaces for database access improved.
Prolog, which is based on the first-order predicate logic, influenced the development of relational databases because both were developed around the same basic concept. This led people to trying to extend relational logic of relational databases to the first-order predicate logic or looking at the whole database on the basis of logic, not just the query language as in a relational database. This trend in turn led in 1977 to the development of the deductive database as a combination of the relational database and logic programming languages.
Unlike the relational database, the deductive database has built in inference rules. The conventional database is just a flat file which stores data, with the ability to search for a record. However, once inference rules are built in, the deductive database can be used to support problem solving.
In addition the logic of the deductive database system means that it searches only for unique solutions (soundness), and searches until a solution is found (completeness). These characteristics are important because they guarantee the reliability of the database.
The number of application software packages which can handle graphics and image data has been increasing steadily since 1980, but during the 1970's, when the relational database first emerged, there were hardly any. Many people tried to link software to relational databases that had been successful in the business area, but they found that it is difficult to use relational databases for complex data items because they have a relatively low processing efficiency for this kind of data. And the same problem occurred with deductive databases, because the beginning of research in deductive databases was to integrate relational databases and programming logic. So both types of databases reached an impasse on the question of how to handle complex data.
Object-oriented programming tools, from which object-oriented databases developed, are rooted in the search for new software programming development techniques and software maintenance. Let's have a look at the most important concepts of object-oriented databases.
The concept of an object first appeared in the mid-60's, in the simulation programming language Simula '67. The attractiveness of object-oriented programming lies in its ability to use abstract objects to represent actual events. Its strength is that it allows any data types and procedures. This saves users time spent in converting data to fit specific data formats and has increased the number of objects that can be represented on a computer. However, since the programmer can now determine freely procedures, it is now the responsibility of the programmer to determine whether the result of them is the correct one or not.
In the 1970's, the field of artificial intelligence started to use the concept of Frame theory, which incorporated the concept of inheritance. This proved an effective method for sharing and reusing code, as well as for organizing information.
Object oriented programming sprang into the limelight in 1980 when it was used in SmallTalk-80, a programming language developed at Xerox USA's Palo Alto Research Center. Following this, related concepts such as multiple inheritance introduced by Flavors, were developed as object oriented programming gradually adopted basic concepts.
These concepts emerged as the result of research and experience with object oriented programming techniques, and were not uniformly integrated into object-oriented databases. Because of the versatility of its programming techniques, a whole range of object-oriented databases with new functions appeared in the late 1980's.
The deductive database is based on first-order predicate logic, part of formal mathematical logic. This clear logical structure ensures the accuracy of a query result, an important point in database design. It is also upward compatible with conventional relational databases. However predicate representation cannot handle very complex data types. At that time, deductive databases were still under development, and there were as yet none commercially available.
Object-oriented databases allow easy modeling of the target object, and this representation can be further refined by the user. There were many systems in commercial use. However, there was still no formal base for development, and there was no consensus of concept of object-oriented databases. The results of a query and whether a query stops or not are determined by the user's skill in programming. In addition, the object-oriented database is basically not compatible with the relational database.
From the above, it should now be clear that the strengths and weaknesses of the deductive database and the object-oriented database complement each other. This immediately suggests that an appropriate combination of the two types would result in a more powerful database, adopting the strengths and evading the weaknesses of both.
The deductive database has now taken this step forward. As the weaknesses of the deductive database became clearer, people started to integrate the strengths of the object-oriented database to compensate. The term :"Deductive Object-Oriented Database (DOOD)" came into use around 1988, and the first DOOD Conference was held in 1989.
This ends our short tour of the history of the database. Have you guessed yet why we chose the name Quixote for our database language?
Well, the important word that is missing from Quixote is the word "Don," which in normal usage means "to put on." Used as an acronym, DON stands for "Deductive Object-Oriented Nucleus." We developed Quixote using a deductive object-oriented database language, and so the name of the hero in Cervantes' novel seemed just right.
You may well ask why we didn't name it after some other Don. The answer to this lies in the development process for Quixote, during which time its character was formed. Let's look now at that process.
When we started to develop Quixote, because our project was so new, and there was nothing similar to compare it with, we often hesitated in making decisions about how to proceed simply because we wondered whether our ideas were too far out, too idealistic.
But we encouraged each other with the thought that without ideals we cannot develop anything new. Although our project seemed like chasing a dream, we believed that we could make our dream of developing a language called Quixote come true. We hoped that the language would be like Don Quixote himself - aiming for the top, even when that involves risks.
Can you see now why we had to choose the name Quixote?