Shuklin D.E.

About the perspectives of object-oriented data and knowledge bases into artificial intelligence systems.

I think the practice of exploitations of relation control systems for control databases discovered considerable limitations into a relation model of data presentation. Nowadays necessity has shown up to refuse the relation mode and to pay attention to the undeservedly forgotten network or object-oriented models of data representing. In the nearest future that will allow us to achieve a noticeable success in artificial intelligence using for resolving actual problems of nowadays business.

AI – an artificial intelligence,

DB – a database;

KB – a knowledge base;

RDB – a relation (table) database;

ODB – an object database;

RMD – a relation model of data representing;

OMD – an object model of data representing;

DBMS – a database management system;

KBMS – a knowledge base management system;

RDBMS – a relation database management system;

OONKB – a network object-oriented knowledge database.

As is well known, nowadays data management systems built on the relative data model obtained wide prevalence. Most of soft developers and system analyst have a strong prejudice the relative model won and force other models of data presentation out of the market once and for all. I consider this situation is temporary and in the nearest future we all will be witnesses of this prejudice breaking. Databases management systems on their own are not of a great value for users. Even data saved into bases is not of a great value of itself. The main value is the complete applications that allow users to model some aspects of their activities and business using computer engineering. Business processes that exist nowadays are characterized by high complexity. The tendency of business processes complication, caused by development of integration and globalization processes can be watched. Accordingly, the requirements to a model of a business process data representing are getting stronger.

In spite of a relative model of data presentation has merits it also has several demerits[1]. In case the model of the object area is normalized, the database is a set of joined tables. Besides to the trivial necessity of the implementing a big number of joins on a set of tables; that structure considerably complicates a database support. In case the business changes it’s necessary to develop a new variant of a normalized database and to throw away all developers’ work that were done for creating of the previous database and applications worked with the previous DB version. Developing of the relative structure of tables intended for changes of a business model during the application execution doesn’t resolve the problem also.

In this case developers of relative databases use 3 approaches.

1. DB dynamical modification of the structure using the application is done.

This approach saves DB structure normalization. And it has these shortcomings:

A. If a structure of DB changes, the structure of data that were input to the DB during the previous exploitation phase changes also. In some cases legislation or business processes need saving historical data unmodified.

B. Lack of inheritance in the classic RMD doesn’t offer to model a conception inheritance from a business model in a usual way.

C. Most of the present-day RDBMS don’t offer modification of the DB structure inside one transaction. Transactions are closed during tables’ structure modifications. In case there was a mistaken structure modification, the changes can’t be restored.

2. The structure is turned on 90 degrees. This approach allows to get rid of the previous approach shortcomings. For the conception clearness all the objects saved in the DB are to be placed into the several tables only. Often there are two tables, the table of the objects and the table of the objects’ attributes values. That leads to the Cartesian multiplication of the objects quantity by their attributes quantity and considerable increase number of lines in the tables. This approach also leads to increasing of the number of ties. Taking into consideration increased number of lines and index growing, this approach leads to the catastrophic fall of the DB productivity. Additional shortcomings of this approach are:

- loss of the information about the object attributes type can take place; that can lead to loss of data in the DB;

- difficulties of realization attributes that save collections of joins to another objects located into DB (into the previous approach that is resolved by using joins “one to one” or “one to many”, that are modeled into separate tables).

3. Tables of templates are used.

In this case template tables are created into the DB, they have a set of buttons “in reserve” that are not compared to the business objects attributes. Several columns of the same type are created into every template table, for example int1, int2, int3, …, int99, float1, float2, float3, … , float99, varchar1, varchar2, varchar3, … varchar99, … A business project model is also created into the DB; it describes a column where each attribute of the object is located. In this case the same template table column contains values of quite different attributes of the different types objects. In comparison with described above approaches, this one ease the situation, but it has considerable shortcomings also. A developer needs to foresee all attributes types of modeled objects and to create a quantity of each potentially useful type column that would be enough for the further using “in reserve”. Besides the obvious limitations for quantity of attributes of one type for each object, the given approach requires dynamic SQL query building and implementation. That leads to additional expenses for realization and execution of a dynamic queries builder in accordance to a data model. That brings down the productivity and reliability of this decision.

So the sad situation that occurs in using a relative data management system area continues to become more complicated. We all can watch that because of despair RDBMS producers extend their products functionality by adding possibilities of objects processing (Oracle, Informix, …) and resources that allows XML processing, realization of application business logic on the DBMS side using procedural languages tools (Oracle, Microsoft, …). Per se this situation shows a relative data model fails to be a universal tool for nowadays business processes modeling.

Owners of existing relation data management systems who has invested lots of millions in the products development, marketing managers whose main aim is the product advertisement on the market and unsophisticated users try to make us sure the evolution way of the RMD development will help to save investments and resolve all the problems described above. Is it so?

For answering this question let's divert our attention from the data management system and let's view business process modeling as a main problem that is resolved using DBMS. Obviously the aim of our society industrialization is to replace the humans' work with the machines' one. Informatization of the society leads to replacing humans' intelligence with machine's one. Business processes automation brought to the absolute expects complete human estrangement from resolving routine intelligence problems. As a result a conclusion can be done that a business processes modeling system brought up to the absolute, has to have an artificial intelligence. Introduction of the system has to leave only creative problems for a human and completely automates routine operations for a modern enterprise managing. System like that has to have knowledge and skills comparable to a business analyst of a middle range. That means the knowledge base managing system (exactly knowledge base, not a data base) has to provide presentation and processing of a business process model that can be matched by its difficulty to a business process model that is used by a human consciousness. Systems that don't meet this requirement first or last will turn out to be out-of-date and they will be replaced with the systems that have artificial intelligence. Of course, that isn't the prospect for the very close future. But business already challenges developers setting the problems that need artificial intelligence tools using. The absence of the AI systems in wide use wasn't caused by absence of the problems that need models based on AI for resolving. Problems of business automation were not set yesterday or the day before yesterday, they were set during the epoch when the first abacus and arithmometers appeared. The current level of information development is defined by the current level of achievements in sphere of business data and business knowledge modeling and processing. Our users don't get the thing they need, but the thing we are able to develop using popular development tools.

As we can see from the done above RMD analysis, the RMD is not the summit of desires. The RDMS producers understand the established situation themselves and being affected by the public pressure they evolve slowly to the "post-relation models of data representing". The RDBMS producers and groups of scientists budgeted by them are anxious for multi million investments saving first of all. Most part of developers tries to save evolution way of DBMS developing. That’s why in the researches dedicated to "post-related models", there is no word about artificial intelligence as a tool for business processes modeling. On the given analysis it gets obviously that in the further prospect all attempts to reanimate RMD will surely fail. During the attempts of resolving nowadays business problems the undoubtedly dead-end way of developing was chosen; that is the way to develop RMD somewhere to the future. The business challenge can be accepted just using the proved method "from general to the particular”.  In spite of making improvement spontaneously and laying one modification on another one under circumstances pressing, the problem should be viewed top-down to define the way of development since the current state of DBMS/KBMS until AI systems. In this case not the RMD could turn out to be the start point, starting with one the modern industry “sacred Grail” - the artificial intelligence can be reached with the less aggregate expenses.

Industry and customers need knowledge management systems. Professionals working in the AI area know many knowledge representing models which have not less but even more flexibility and universality in comparison to RMD. Quite widespread and well known models of knowledge representing are hierarchical semantic networks, active semantic networks, semantic networks of frames, hidden Markov models, ... Last time neuron networks are at the period of the second birth.

History of neuron networks developing deserves paying attention. The science development in this direction was hampered during decades after critical publications advertised neurocomputing as a deadlock branch of the scientific and technical progress. Later on authors admitted they were categorical superfluously, but the time was missed. Fortunately, science is more democratic society in comparison with software industry. The author’s point of view doesn’t influence average scientists as much as corporations influence an average developer. Nowadays researches of artificial networks are recommenced and we get to know about progress in this sphere not just from the scientific publications but from mass media also. But in the sphere of data management systems a relation model keeps its “stable” and monopolistic positions. The same way as with artificial neuron networks, data models competed with RMD were declared to be a deadlock way and researches in areas of network and object oriented data management systems were considerably hampered. RDBMS won market of the commercial DMS. At first euphoria caused by these DMS was quite well-grounded. Financial operations take a noticeable business part. Financial data in its natural form is presented as different tables. That is why the relative model turned out to be just at the right time here and it occupied a sector of financial applications. At this moment this sector is substantially mastered and automated. RDBMS masters adjacent areas gradually. Not automated business spheres are characterized by a model of data representing which form is far from the tabular one. As a result there’s a noticeable deceleration of RMD spreading. Now RDB developers have to spread RMD using tools for complicated data structures keeping and processing.

Business requires automation not just a financial but any activity. For any business model creating an artificial intelligence and knowledge database management system is required. That’s why in the further prospect all attempts of RMD improvement in any event are to fail or to be finished with AI creating. Two ways are possible here. The evolutional one is in case if on the way of casual errors and under pressure of current business problems that haven’t been automated yet, the RMD is fluently transformed into the AI knowledge representing model. And the revolution one, that is in case if developers clearly realize the put by aim and begin the knowledge base management creating using all the best that was stored up for the years of researches in artificial intelligence sphere. For any of two variants, there won’t be any place for the current RMD state or current attempts for its reanimation. Data representing model suitable for using into AI systems will be quite different from RMD. Spending a lot of resources on the RMD evolution is too expensive outlay in the situation like that. Especially in case if the success will take place, just memories about RMD are left. I propose to decline the evolution approach. During the next generation DBMS/KBMS development the DBMS should be considered an equal model between the equal ones. The development of the next generation model of data and knowledge representing should be done headed not for millions of dollars spent on development of the current products but for effectiveness of using the solutions into perspective AI systems. That will allow going towards the defined aim of absolute business processes automation by the shortest route, but not under pressure of casual fluctuation caused by the next RMD limit during a business process modeling.

What is data representing model known nowadays, that reflects more appropriately the model of the world and reality into which all we are living? I think that is a network object-oriented model of data and knowledge representing. Nowadays successes into the sphere of the object-oriented methods of software development confirm this idea.

Shortcomings of the object databases are considered to be difficulties of object representations realization, difficulties of unplanned queries realization and necessity of the iteration in collections of objects during the objects search by values of the objects’ attributes. If we compare a clear RMD and a clear OMD we can accept the representations into RMD can be considered to be as relations but consideration of OMD objects representations as objects is more difficult. In practice ersatz key are inserted for meeting the requirement “there is no essence without identifier”. In this case RDB assumes representation realization difficulties equivalent to the ODB ones. For example, a lot of limits present for the updatable views realization are evidence of that. Therefore, in practice and from the representations realization point of view ODB and RDB can be considered to be practically equal in rights. Difficulties of realization of the unplanned queries to the objects base are invented. Unplanned queries to objects tree can be realized on the base of OQL or XPath languages, for example. For the optimization of the objects search using the objects’ attributes values in ODB, like into RDB indexes creating and using is possible. So, from the point of view of the considered capabilities OMD doesn’t yield to RMD.

I consider the most perspective direction that can lead to AI creation is neuron networks that have capabilities for self-modulation and introspection. Semantic neuron networks developed by the author have such capabilities [2]. As can be concluded taking into consideration the analysis that has been done above, the perspective way for realization of the neuron network model is using network object-oriented knowledge base management systems. I consider the neuron network model should be realized as an application implemented in context of a network object-oriented database management system. A knowledge management multiplier has to be realized into context of a self-modification neuron network. At present RDB technology influence ODB developers too much. Existing ODB realization were done taking into consideration compatibility with RDB. That fact considerably influenced models of existing ODB realizations and from my point of view it influenced them not in a good way. During the process of realization of a knowledge database management system we need to provide for any possibilities of modeling the neuron networks that have free topology and universal model of a separate neuron behaviour. I think the functionality of an object KB managing system has to be enough for semantic neuron network modeling. In this connection I decided to develop my own research model of a network object-oriented knowledge database, it is Cerebrum [3], its model of objects representation is oriented on further use into the semantic network.

The developed system has the capabilities:

• It saves the current state of object graphs or neuron network into OONKB between the séances of working with a user. A current topology an object network is saved also. During the second launching of the application there won’t be any need for the object network creating.

• In case there’re a big number of objects instances, there is a capability to limit the memory volume used by a graph or a neuron network. The most frequently used objects stays into the main memory; other ones are replaced to files depository and are loaded to main memory if needed. While is downloaded to a main memory an instance forces out another objects that are used rarely. The memory volume limitation allows to get rid of using an operational system filling file, that will noticeably increase productivity of networks with a big number of objects instances (in case the total size of all the objects instances is bigger than the size of current free memory in the system).

• In case the total size of all the objects instances is less than the size of current free memory in the system all network is into main memory and no productivity losses caused by serialization-deserialization appear.

OONKB using doesn’t put on any limitations for used business logic of an object or mathematic model of a neuron that can be realized as methods of objects that are into OONKB.

An object-oriented model of data representation that is used in Cerebrum, is free of shortages described above. A capability of complicated structured objects modeling allows combining several object instances into one that is called a component. In contrast to RMD such component can be saved into database as a single whole. That increases effectiveness of the system work noticeably. But that isn’t the main thing. As a component is an aggregation of several objects instances, into the object model it’s possible to change an internal structure of a component dynamically without affecting structure of another objects of the same type that are saved into the DB. An object model allows realizing classes’ inheritance and interfaces multiple inheritance. In contrast to the first approach viewed above, ODB allows to change internal structure of a separate component without affecting other components that are in the DB. It resolves a problem of representation and processing of objects versions. Presence of the developed information about types allows applying to an internal structure of such component the same way as to separate table fields like in case with RMD. In contrast to the second approach ODB saves capability to work with the internal structure of a component and allows to get rid of indexes sizes increasing and necessity of using joins during access to a component attributes. Problems of attributes type loss and difficulties during objects collections realization disappear also. An object model is free of limitations for a number of attributes of one type that is in the third approach. Additional merits of an object model of data representing is capability to interpret any item represented into DB as an object. That allows saving as an object attributes not simple values only, but also components with complicated internal structure.

Theoretic researches results and practical experiments results allow realizing network object-oriented knowledge management system successfully already these days. A system like this will turned up to be useful not for resolving the perspective problems only, but also for nowadays business problems, that are traditionally resolved using RDBMS. I consider that taking into account a necessity of changing to systems that are based on AI, it is required to refuse the dogma about superiority of a relative data model and to concentrate main efforts on alternative models researches and developing. I hope a network object-oriented knowledge database Cerebrum will allow to define the way of further development of data and knowledge management systems and will bring near creating of industrial machines with artificial intelligence.

1. (C) 2003, 2004 Baroudi Bloor International, Inc. / The Failure of Relational Database, The Rise of Object Technology and the Need for the Hybrid Database / Internet publication:  http://www.intersystems.com/cache/technology/whitepapers/baroudi_bloor.pdf

2. Shuklin D.E. / The further development of semantic neural network models. / In Artificial Intelligence, Donetsk, "Nauka i obrazovanie" Institute of Artificial Intelligence, Ukraine, 2004, No 3. pp. 598-606

3. Shuklin D.E. / Cerebrum : A object-oriented network knowledge base management system / Internet publication: URL: http://www.shuklin.com/ai/ht/en/cerebrum