There are two kinds of ways to query a relational database to retrieve information. The first one is to expose database (SQL) scripting interface to the user. The user has complete access to all objects and operations allowed by the database. This kind of user interfaces are usually reserved for the database administrators who have thorough understanding of SQL scripting language and the structure of the corresponding database. The results usually have very poor display qualities. It is not suitable to be used inside a product that is designed for more ordinary users who has limited knowledge about database and corresponding low level data structure of a system. It also open the system widely to a variety of security attacks, information leaks, etc..
The second one is to encapsulate all query and other actions into a predefined set of fixed methods to be invoked by the user interface. It is easier for a user to use and, if designed properly, is much more secure, but it is very limited in functionality since all operations are predefined by the producer. To develop a sufficiently good user interface that covers even a small portion of possible operations on the database requires exponentially increasing amount of efforts, especially when the number of the tables inside the database is large. The results are still none-extensible and limited systems that were fixed from the very beginning no matter how much resources the producer has and how hard it tries. Most data applications today on the market are produced in this way supported by economically reasonable resources. Going further, the producer must justify not only the development costs but also maintenance costs and even possibility due to increased complexity of the system.
The second approaches are becoming more and more heavily rely upon some form of object-relational mapping (ORM) techniques, especially when developing applications that are sufficiently complex. Most of the more successful programming languages used to build user interface applications are object oriented (OO) ones. One of the important successes of some of the OO languages is the possibility for a developer to adopt polymorphism to represent related types or concepts that are not only be concrete but also abstract so that a set of more abstract interfaces for them can be declared. The simplicity in coding style and extensibility, the degree of code reuse and ease of project maintenance can be increased significantly in this kind of practices that are designed properly. Data inside a relational database are organized differently. ORM happens on many levels in an application system. Here we are interested on the data level. If one make the following map for comparison purposes, namely,
A table schema in RDB world maps to a type in OO world;
A table row in RDB world maps to an object in OO world;
A row field in RDB world maps to a property of an object in OO world.
One can see that there is no concept of polymorphism in the RDB world. Instead of inheritance, RDB developer can use composition to reach similar goals, which can be less elegant than the OO approach.
Let’s focus on the design of a hypothetical inclusive animal database on earth. The reasoning, like “a cat is an animal” so that “any action that can be performed on an animal can also be tried to be performed on a cat, pending approval from the owner or the cat or a cat rights organization or whatever, the result will depend on the cat-ness of the said animal”, cannot be represented in RDB system well. Queries like “select (d as cat).* from [the animal set] where d is cat AND (d as cat).Whiskers<2 …”, where “whisker” is a property that belongs only to the cat family, has no support to be executed. each concrete member of the animal family has to have a separated table pre-defined and they can’t be mixed or inherited. given the diversity of the animal family, the animal database can become very had to maintain and expensive to develop, if possible at all. the abstract source, “[the animal set]”, makes it simple and extensible later as the database grows, provided that the underlying database can be implemented.
The reader may think that is what an object oriented database OODB can do! Depending on a user’s needs, this maybe is true. What we are after is in some critical details. The concept of OODB is of course not new; there are already many implementations. One of the qualities that differentiate them is how easy the database can be queried. Second, the design of OODB data structure, due to its heavy bound to OO languages, intends to be more of hierarchical rather than relational. Data in RDB can be mapped to graphs in the OO world, which is not use explicitly by many developers in the OO world. This state of affair is manifested in the fact that even some serialization libraries build into language framework cannot preserve a data object graph without polymorphism faithfully, reflecting the lack of care about relational aspects of the things in the object world. Including polymorphism, almost none of them can do it naturally yet. The more relational they can represent, the more they reflect the fact that many data in the real world cannot be fitted into hierarchic structure naturally. That is one of the reasons why relational databases went into relational direction and became so spectacularly successful at low data layer in the past. The SQL language combined with the relational data structure is also one of the most successful data systems that most of these existing OODB can’t match yet. It would be ideal to develop a data system that is hybrid of relational and hierarchic and implement an extension of the SQL language (at least partially) to allow detailed queries mentioned above, to be executed dynamically in response to a client (or user)’s runtime input. Namely it has to be relational (in addition to its natural quality of been hierarchical) and scriptable to end users. This is one of the problems we have successfully addressed in our technology. It will be detailed below.