Cerebrum Wiki & Documentation Rss Feed

UPDATED WIKI: Home

shuklin — Sun, 18 May 2008 20:52:56 GMT

Idea

The Object-oriented network knowledge base Cerebrum (OONKB) has the following features:

It saves the current state of the graph of objects or the neural network in the OONKB between user sessions, including the current topology of objects so that it does not require the creation of objects again at the next run.

It restricts the amount of memory used by the graph of objects or the neural network with larger quantities of class instances. The most frequently used objects are left in the RAM, the others are moved to the physical storage area and are loaded into the RAM upon demand. It unloads the rarely used objects when other objects are loaded to the RAM. The memory amount restriction allows not using the paging file so that it significantly increases the modeling performance of networks with larger quantities of class instances.

The primary goal of this research is to create a virtual machine supporting free topology object-oriented network with up 2 billons of object instances within one physical storage area. This possibility is provided with implementation of the network object-oriented knowledge database. So that only a few class instances are in the RAM and the most objects are frozen in the file system.

I am currently looking for your help and participation. Please suggest features and report bugs by creating issues in the Issue Tracker. You can ask any question in the forum or email to shuklin@bk.ru .

UPDATED WIKI: Home

shuklin — Sun, 18 May 2008 20:47:43 GMT

Background

The Object-oriented network knowledge base Cerebrum (OONKB) has the following features:

It saves the current state of the graph of objects or the neural network in the OONKB between user sessions, including the current topology of objects so that it does not require the creation of objects again at the next run.

It restricts the amount of memory used by the graph of objects or the neural network with larger quantities of class instances. The most frequently used objects are left in the RAM, the others are moved to the physical storage area and are loaded into the RAM upon demand. It unloads the rarely used objects when other objects are loaded to the RAM. The memory amount restriction allows not using the paging file so that it significantly increases the modeling performance of networks with larger quantities of class instances.

The primary goal of this research is to create a virtual machine supporting free topology object-oriented network with up 2 billons of object instances within one physical storage area. This possibility is provided with implementation of the network object-oriented knowledge database. So that only a few class instances are in the RAM and the most objects are frozen in the file system.

I am currently looking for your help and participation. Please suggest features and report bugs by creating issues in the Issue Tracker. You can ask any question in the forum or email to shuklin@bk.ru .

UPDATED WIKI: Idea

shuklin — Sun, 18 May 2008 20:46:29 GMT

Shuklin D.E.

An object-oriented network DBMS from relational DBMS point of view

Naive ORDBMS

Lets examine the implementation of an abstract object-oriented DBMS. Lets take the relational DBMS as starting point. Rows in OODB tables will be an object instances. All table’s rows will be instances of a class, which are corresponding to the table. Classes will be defined by table headings. In this case table column will conform to the field of the class. The value of the row field will conform to the value of the instance field. This first iteration of the ODBMS development allows us to work with DBMS in terms of classes, instances and values of instance fields. This OO system is still missing methods, virtual methods overriding, inheritance and encapsulation. Neverless, it is obvious, that no RDBMS values at that ORDBMS interpretation were lost.

Object - relational DBMS

Lets move further. By analogy with OOP it is possible to implement single inheritance. The table, which has inherited base table, also inherits columns of that base table or, what is equivalently, inherits class fields. Base table should contain all class instances (= rows) from all derived tables, which were inherited from this base table. Some methods can be associated to the row (= instance). An interface of the class, which was determined in the basic table, is inherited by derived tables. Each row method should implicitly receive one row as hidden parameter (= this). These row methods can be regarded as class (= table) methods. These methods will be executed on data stored in the row of table (= class instance or this). Identifiers of all virtual methods of single class can be stored in some table known as vtbl. Lets add hidden field (= column) with identifier of vtbl to each data table. The vtbl identifier stored in hidden field in each row allows to implementing overriding of virtual methods. The call of virtual method of some row will be implemented as searching of the virtual methods table by the vtbl identifier stored in this row and then searching and calling the implementation of the method by its name in the virtual methods table. The availability of vtbl allows to invocate overridden methods, defined in the derived tables by rows contained in the base table. So, in the developed abstract DBMS support of inheritance and polymorphism concepts are presented. Also it is obvious that the addition of such capacity uphold all present RDBMS capacities.

The encapsulation is implemented in the developed DBMS by VIEWs using. VIEW allows protect some table fields from direct access, providing the access to fields interface. Due to the availability of vtbl identifier in each row the VIEW also provides access to methods interface.

As is easy to see, such implementation of OOP concepts in the RDBMS is not new. PostgreeSQL is an example of already existing implementation.

Let’s go on. Each row of the table is physically located in the storage at some unique address. Even if it was not yet implemented in the RDBMS used as prototype, it is technically possible to provide invariability of this address during all row lifetime. The analogue of this address can be bookmarks, used in the modern RDBMS for rows addressing. The availability of unique and invariant row logical address allows us to implement the concept of pointers to the rows. Previously it was developed concepts of inheritance, polymorphism and encapsulation. They are converting developed abstract ODDBMS to valuable OO programming system.

Note, that the concept of references to the rows is also not new and was embodied long ago in such famous RDBMS, as Oracle.

Neverless, it is obvious, that no RDBMS values at that ORDBMS interpretation were lost too. As before, developed abstract ORDBMS includes RDBMS as special case.

Network OODBMS

Let continue the building. The table of ORDBMS is a bookmarks collection which refers to some rows. So many tables can contain reference to one row and the same instance of row can be contained by several tables. The row instance will be contained by the table, which corresponds to the row class. And the same row instance will be contained by the all base tables (= classes). Interface, which was implemented by the row (= columns + methods), corresponds to the class from which this instance was inherited. It is significant that this interface is not equivalent to interfaces of base tables. It is wider than base table’s interfaces. However, this interface is compatible with interfaces of tables, which are containing this row. That is how we are getting to the concepts of interface, abstract classes and multiple inheritance of interfaces.

This is very important step, because now the possibility of the belonging of some row to some table is determined by compatibility of this row interface with interface fixed for some table. This gives a possibility to make next step – to consider tables to be not just physical storage for rows, but a collection of instances of some classes, which interfaces were compatible with interfaces determined for this collections. Lets draw your attention to potential independence of the interface, determined for the table from the interface, fixed for the row. Notwithstanding the fact that developed system in some special case can operate just as RDBMS, tables in the developed DBMS are not relations in classical meaning. Rows of these tables (= collections) are not a subset of Cartesian product of interface declaration to possible domain of the interface. Yes, collections at the developed system can be interpreted as a subset of Cartesian product of interface declaration to possible domain of the interface. This makes RDBMS to be special case of developed one. But, the polymorphism of instances (= rows), which provides the access to their internal structures through public interfaces caused in this DBMS interfaces sharing (= columns and/or methods) to many tables (= collections). These tables can’t be considered as relations because the changes of row fields provided through one table caused changes in all other tables.

Lets examine data interfaces more elaborately. Interface implemented by the row consists of the definition of signatures of methods, which are applicable to this row, and also of the definition of fields (= columns) which were inherited by this row from base tables. The possibility of the table inheritance causes the possibility of simultaneous ownership of the same columns (= fields) by different tables. As result, row (= object) instance has values for columns, which were described in all inherited interfaces. However, only that subset of values can be available through some table, which is an intersection of variety of all columns, which were inherited by row and the variety of all columns, fixed as the interface for the collection (= table). What is the row in this case? The row is the subset of Cartesian product of all possible columns by all possible values of these columns. Here interesting and unexpected result is obtained. Though the developed abstract ORDBMS included RDBMS as special case, the row is a relation instead of table.

Summary

During development no RDBMS capacities from the developed abstract DBMS were removed, but new capacities was only added to it. Developed ORDBMS includes RDBMS as special case. Rows are instances inheriting many columns, published only some columns through tables interface. Both rows and columns can be simultaneously placed into several different tables. Tables are collections of instances and are not classical relations. We could say that instances of classes (= rows) are nodes, fields of these instances are attributes of nodes. Fields of reference type holds pointers to other nodes. Nodes themselves can have millions of attributes, publishing only some attributes through interfaces of collections. Attributes can have both scalar values and references to other nodes, thus forming the net. So relational DBMS is just a special case of network DBMS.

UPDATED WIKI: Home

shuklin — Thu, 08 Mar 2007 10:36:06 GMT

UPDATED WIKI: Home

shuklin — Thu, 08 Mar 2007 09:59:21 GMT

Idea

The Object-oriented network knowledge base Cerebrum (OONKB) has the following features:

It saves the current state of the graph of objects or the neural network in the OONKB between user sessions, including the current topology of objects so that it does not require the creation of objects again at the next run.

It restricts the amount of memory used by the graph of objects or the neural network with larger quantities of class instances. The most frequently used objects are left in the RAM, the others are moved to the physical storage area and are loaded into the RAM upon demand. It unloads the rarely used objects when other objects are loaded to the RAM. The memory amount restriction allows not using the paging file so that it significantly increases the modeling performance of networks with larger quantities of class instances.

The primary goal of this research is to create a virtual machine supporting free topology object-oriented network with up 2 billons of object instances within one physical storage area. This possibility is provided with implementation of the network object-oriented knowledge database. So that only a few class instances are in the RAM and the most objects are frozen in the file system.

I am currently looking for your help and participation. Please suggest features and report bugs by creating issues in the Issue Tracker. You can ask any question in the forum or email to shuklin@bk.ru .

UPDATED WIKI: Idea

shuklin — Thu, 08 Mar 2007 09:58:37 GMT

Shuklin D.E.

An object-oriented network DBMS from relational DBMS point of view

Naive ORDBMS

Lets examine the implementation of an abstract object-oriented DBMS. Lets take the relational DBMS as starting point. Rows in OODB tables will be an object instances. All table’s rows will be instances of a class, which are corresponding to the table. Classes will be defined by table headings. In this case table column will conform to the field of the class. The value of the row field will conform to the value of the instance field. This first iteration of the ODBMS development allows us to work with DBMS in terms of classes, instances and values of instance fields. This OO system is still missing methods, virtual methods overriding, inheritance and encapsulation. Neverless, it is obvious, that no RDBMS values at that ORDBMS interpretation were lost.

Object - relational DBMS

Lets move further. By analogy with OOP it is possible to implement single inheritance. The table, which has inherited base table, also inherits columns of that base table or, what is equivalently, inherits class fields. Base table should contain all class instances (= rows) from all derived tables, which were inherited from this base table. Some methods can be associated to the row (= instance). An interface of the class, which was determined in the basic table, is inherited by derived tables. Each row method should implicitly receive one row as hidden parameter (= this). These row methods can be regarded as class (= table) methods. These methods will be executed on data stored in the row of table (= class instance or this). Identifiers of all virtual methods of single class can be stored in some table known as vtbl. Lets add hidden field (= column) with identifier of vtbl to each data table. The vtbl identifier stored in hidden field in each row allows to implementing overriding of virtual methods. The call of virtual method of some row will be implemented as searching of the virtual methods table by the vtbl identifier stored in this row and then searching and calling the implementation of the method by its name in the virtual methods table. The availability of vtbl allows to invocate overridden methods, defined in the derived tables by rows contained in the base table. So, in the developed abstract DBMS support of inheritance and polymorphism concepts are presented. Also it is obvious that the addition of such capacity uphold all present RDBMS capacities.

The encapsulation is implemented in the developed DBMS by VIEWs using. VIEW allows protect some table fields from direct access, providing the access to fields interface. Due to the availability of vtbl identifier in each row the VIEW also provides access to methods interface.

As is easy to see, such implementation of OOP concepts in the RDBMS is not new. PostgreeSQL is an example of already existing implementation.

Let’s go on. Each row of the table is physically located in the storage at some unique address. Even if it was not yet implemented in the RDBMS used as prototype, it is technically possible to provide invariability of this address during all row lifetime. The analogue of this address can be bookmarks, used in the modern RDBMS for rows addressing. The availability of unique and invariant row logical address allows us to implement the concept of pointers to the rows. Previously it was developed concepts of inheritance, polymorphism and encapsulation. They are converting developed abstract ODDBMS to valuable OO programming system.

Note, that the concept of references to the rows is also not new and was embodied long ago in such famous RDBMS, as Oracle.

Neverless, it is obvious, that no RDBMS values at that ORDBMS interpretation were lost too. As before, developed abstract ORDBMS includes RDBMS as special case.

Network OODBMS

Let continue the building. The table of ORDBMS is a bookmarks collection which refers to some rows. So many tables can contain reference to one row and the same instance of row can be contained by several tables. The row instance will be contained by the table, which corresponds to the row class. And the same row instance will be contained by the all base tables (= classes). Interface, which was implemented by the row (= columns + methods), corresponds to the class from which this instance was inherited. It is significant that this interface is not equivalent to interfaces of base tables. It is wider than base table’s interfaces. However, this interface is compatible with interfaces of tables, which are containing this row. That is how we are getting to the concepts of interface, abstract classes and multiple inheritance of interfaces.

This is very important step, because now the possibility of the belonging of some row to some table is determined by compatibility of this row interface with interface fixed for some table. This gives a possibility to make next step – to consider tables to be not just physical storage for rows, but a collection of instances of some classes, which interfaces were compatible with interfaces determined for this collections. Lets draw your attention to potential independence of the interface, determined for the table from the interface, fixed for the row. Notwithstanding the fact that developed system in some special case can operate just as RDBMS, tables in the developed DBMS are not relations in classical meaning. Rows of these tables (= collections) are not a subset of Cartesian product of interface declaration to possible domain of the interface. Yes, collections at the developed system can be interpreted as a subset of Cartesian product of interface declaration to possible domain of the interface. This makes RDBMS to be special case of developed one. But, the polymorphism of instances (= rows), which provides the access to their internal structures through public interfaces caused in this DBMS interfaces sharing (= columns and/or methods) to many tables (= collections). These tables can’t be considered as relations because the changes of row fields provided through one table caused changes in all other tables.

Lets examine data interfaces more elaborately. Interface implemented by the row consists of the definition of signatures of methods, which are applicable to this row, and also of the definition of fields (= columns) which were inherited by this row from base tables. The possibility of the table inheritance causes the possibility of simultaneous ownership of the same columns (= fields) by different tables. As result, row (= object) instance has values for columns, which were described in all inherited interfaces. However, only that subset of values can be available through some table, which is an intersection of variety of all columns, which were inherited by row and the variety of all columns, fixed as the interface for the collection (= table). What is the row in this case? The row is the subset of Cartesian product of all possible columns by all possible values of these columns. Here interesting and unexpected result is obtained. Though the developed abstract ORDBMS included RDBMS as special case, the row is a relation instead of table.

Resume

During development no RDBMS capacities from the developed abstract DBMS were removed, but new capacities was only added to it. Developed ORDBMS includes RDBMS as special case. Rows are instances inheriting many columns, published only some columns through tables interface. Both rows and columns can be simultaneously placed into several different tables. Tables are collections of instances and are not classical relations. We could say that instances of classes (= rows) are nodes, fields of these instances are attributes of nodes. Fields of reference type holds pointers to other nodes. Nodes themselves can have millions of attributes, publishing only some attributes through interfaces of collections. Attributes can have both scalar values and references to other nodes, thus forming the net. So relational DBMS is just a special case of network DBMS.

UPDATED WIKI: Home

shuklin — Wed, 31 Jan 2007 13:15:55 GMT

The Object-oriented network knowledge base Cerebrum (OONKB) has the following features:

It saves the current state of the graph of objects or the neural network in the OONKB between user sessions, including the current topology of objects so that it does not require the creation of objects again at the next run.

It restricts the amount of memory used by the graph of objects or the neural network with larger quantities of class instances. The most frequently used objects are left in the RAM, the others are moved to the physical storage area and are loaded into the RAM upon demand. It unloads the rarely used objects when other objects are loaded to the RAM. The memory amount restriction allows not using the paging file so that it significantly increases the modeling performance of networks with larger quantities of class instances.

The primary goal of this research is to create a virtual machine supporting free topology object-oriented network with up 2 billons of object instances within one physical storage area. This possibility is provided with implementation of the network object-oriented knowledge database. So that only a few class instances are in the RAM and the most objects are frozen in the file system.

I am currently looking for your help and participation. Please suggest features and report bugs by creating issues in the Issue Tracker. You can ask any question in the forum or email to shuklin@bk.ru .

UPDATED WIKI: Home

shuklin — Wed, 31 Jan 2007 13:15:33 GMT

UPDATED WIKI: Home

shuklin — Wed, 31 Jan 2007 13:12:04 GMT

UPDATED WIKI: Home

shuklin — Tue, 24 Oct 2006 13:22:52 GMT

The Object-oriented network knowledge base Cerebrum (OONKB) has the following features:

It saves the current state of the graph of objects or the neural network in the OONKB between user sessions, including the current topology of objects so that it does not require the creation of objects again at the next run.

It restricts the amount of memory used by the graph of objects or the neural network with larger quantities of class instances. The most frequently used objects are left in the RAM, the others are moved to the physical storage area and are loaded into the RAM upon demand. It unloads the rarely used objects when other objects are loaded to the RAM. The memory amount restriction allows not using the paging file so that it significantly increases the modeling performance of networks with larger quantities of class instances.

The primary goal of this research is to create a virtual machine supporting free topology object-oriented network with up 2 billons of object instances within one physical storage area. This possibility is provided with implementation of the network object-oriented knowledge database. So that only a few class instances are in the RAM and the most objects are frozen in the file system.

UPDATED WIKI: Home

shuklin — Tue, 24 Oct 2006 11:43:38 GMT

The Object-oriented network knowledge base Cerebrum (OONKB) has the following features:

---

Project Home Page
This is your project's Wiki-based home page. The content of this page is completely editable by any project developer. Before you get too far along with your project, we encourage you to take some time to update this page with useful information regarding your project.
To edit this page, just click the Edit link below.
A "Quick Wiki Markup Guide" can be found on the right side of the Edit page for help with formatting the Wiki text. For a more detailed explanation of the Wiki markup, see the Wiki Markup Guide.

How to use this page
The Project home page is the place that team members and visitors will go to find out about your project. Here are some ideas about what to put on this page:

News
Frequently Asked Questions (FAQ)
Project information (the text from your project description, for example)
Project documentation
Development methodologies
Release process
Current issues

What is a Wiki page?
If you are active on the Internet, chances are you've visited a Wiki page--perhaps even edited one. Simply put, a Wiki is a collection of Web pages that can be edited by anybody with sufficient permission to do so. Wiki pages are easy to edit using a set of simple markup tags that allow you to format text, add images, and create links. A Quick Wiki Markup Guide appears to the right of the Edit page as a reference.

UPDATED WIKI: Home

shuklin — Fri, 20 Oct 2006 17:28:45 GMT

The Object-oriented network knowledge base Cerebrum (OONKB) has the following features:

I will upload sources from http://www.shuklin.com/ai/ht/en/cerebrum/ as soon as i understand how Team Server works.

- I need to understand how to upload VS2003 files without conversion to VS2005
- I need separate kernel and desktop components from client-server and ASP.NET 2.0 components.

How to use this page
The Project home page is the place that team members and visitors will go to find out about your project. Here are some ideas about what to put on this page:

News
Frequently Asked Questions (FAQ)
Project information (the text from your project description, for example)
Project documentation
Development methodologies
Release process
Current issues

UPDATED WIKI: Home

shuklin — Fri, 20 Oct 2006 17:25:36 GMT

The Object-oriented network knowledge base Cerebrum (OONKB) has the following features:

Considering the case when applying the relational data model of neural network modeling could require the query executions with larger quantities of joins and further representation of the table structures on the object network, the usage of relational database systems to solve this kind of problems is not applicable. In certain cases applying the OODB might be more reasonable in comparison with the rational data model. This happens because the model of the real world is represented as relations between real world entities. In the case of implementation of information systems, those which are complex business cases oriented, frequent hardships arise through the support of the relational model changes describing the relations between business objects.

I will upload sources from http://www.shuklin.com/ai/ht/en/cerebrum/ as soon as i understand how Team Server works.

- I need to understand how to upload VS2003 files without conversion to VS2005
- I need separate kernel and desktop components from client-server and ASP.NET 2.0 components.

How to use this page
The Project home page is the place that team members and visitors will go to find out about your project. Here are some ideas about what to put on this page:

News
Frequently Asked Questions (FAQ)
Project information (the text from your project description, for example)
Project documentation
Development methodologies
Release process
Current issues

UPDATED WIKI: Home

shuklin — Fri, 20 Oct 2006 17:24:54 GMT

The Object-oriented network knowledge base Cerebrum (OONKB) has the following features:

_I will upload sources from http://www.shuklin.com/ai/ht/en/cerebrum/ as soon as i understand how Team Server works.

- I need to understand how to upload VS2003 files without conversion to VS2005
- I need separate kernel and desktop components from client-server and ASP.NET 2.0 components._

How to use this page
The Project home page is the place that team members and visitors will go to find out about your project. Here are some ideas about what to put on this page:

News
Frequently Asked Questions (FAQ)
Project information (the text from your project description, for example)
Project documentation
Development methodologies
Release process
Current issues

UPDATED WIKI: Home

shuklin — Fri, 20 Oct 2006 17:23:07 GMT

The Object-oriented network knowledge base Cerebrum (OONKB) has the following features:

I will upload sources from http://www.shuklin.com/ai/ht/en/cerebrum/ as soon as i understand how Team Server works.

How to use this page
The Project home page is the place that team members and visitors will go to find out about your project. Here are some ideas about what to put on this page:

News
Frequently Asked Questions (FAQ)
Project information (the text from your project description, for example)
Project documentation
Development methodologies
Release process
Current issues

UPDATED WIKI: Home

shuklin — Fri, 20 Oct 2006 17:08:40 GMT

The Object-oriented network knowledge base (OONKB) Cerebrum has the following features:

I will upload sources from http://www.shuklin.com/ai/ht/en/cerebrum/ as soon as i understand how Team Server works.

How to use this page
The Project home page is the place that team members and visitors will go to find out about your project. Here are some ideas about what to put on this page:

News
Frequently Asked Questions (FAQ)
Project information (the text from your project description, for example)
Project documentation
Development methodologies
Release process
Current issues