Meta object model for relational data storage

• General Information
  • Overview
  • What is Marauroa?
  • Features
  • Glossary
  • Differences
  • History
  • New in Marauroa 3.8
  • New in Marauroa 3.9
• Using Marauroa
  • Building
  • Initial Steps
  • Tutorial
  • Core API
  • Adventure Games Concepts
  • Database Access
  • server.ini
  • Testserver
• Internals
  • Network Design
  • Role Playing Design
  • Database Design
  • Database Access
  • Eclipse
  • Roadmap
  • JUnit

This article describes a future concept. It may still have some open issues and it was not decided, yet, whether to implement it in this way.

Object Model of Marauroa

Marauroa supports definition of classes and attributes at runtime. The type information is stored in instances of RPClass. Instantiated Objects are RPObjects which must obey the rules defined in their associated RPClass. Associations are defined in RPClass as well and the links on the instance layer are represented by RPSlot instances.

The basic Meta Model

This chapter will describe a generic meta model for object orientated systems. The following class diagrams are designed with mapping to database tables in mind. Therefore the direction of the association arrows may appear strange on a first glance.

Model Layer

Let's start with thinking about the model layer. It consists of classes with their attributes and associations. In addition to that the classes form a hierarchy of specializations.

In Marauroa "associations" are named "slots". They don't have a target type.

Instance Layer

Based on the model layer instances can be created:

On the instance layer the actual life data is managed. Every object on the instance layer has a type on the model layer. So for example every object is an instance of exactly one class. Just as the model layers classes have attributes, objects have values. Those values are instances of the appropriate attribute. This means that there is a consistency condition: A value may only belong to an object which is an instance of a class (or subclass) to which the attribute belongs. The same is true for links on the other side of the diagram. They are instances of association with the same set of consistency conditions.

Differences to Marauroa: In Marauroa associations (slots) don't have a target type. So that condition is not required. But the slots are ordered lists, so an additional attribute in link for the sort oder is required.

Converting the Meta Model into a database structure

TODO: ...

Performance optimization for inheritance

TODO: reflexive and transitive

Version support for the model layer

TODO: ...

Revision support for the instance layer

TODO: ...

TODO

TODO: ...

CREATE TABLE class (id SERIAL, name VARCHAR);

CREATE TABLE inheritance (id SERIAL, sub_class_id INTEGER, super_class_id INTEGER);

CREATE TABKE attribute_type (id SERIAL, name VARCHAR, class_id INTEGER, type CHAR(1));

CREATE TABKE association_type (id SERIAL, name VARCHAR, class_id INTEGER, class_id INTEGER);

CREATE TABLE object (id SERIAL, class_id INTEGER);

CREATE TABLE value_char (id SERIAL, attribute_type_id INTEGER, object_id INTEGER, value VARCHAR);

CREATE TABLE value_int (id SERIAL, attribute_type_id INTEGER, object_id INTEGER, value INTEGER);

CREATE TABLE value_blob (id SERIAL, attribute_type_id INTEGER, object_id INTEGER, value BLOB);

CREATE TABLE link (id SERIAL, association_type_id INTEGER, object_id INTEGER, target_object_id INTEGER);

There is a type layer at the top, consisting of classes (e.g. Player), attributes (e. g. ATK) and associations (e. g. bank_slot). The Inheritance is the reference to the super object (Player, RPEntity)

The second block is the instance layer. It consists of objects (4711 of type Player), values (43 for atk) and links (items in the bank_slot). Of cause there are some consistency conditions required. For example value.object.class <= value.attribute.class.

This basic model can than be easily extended. For example in our case we want a sort order in links table. And because some databases are very slow at deleting rows, or just in case we may want a revision safe system there is an easy way to achieve that: Add a new table activity which basically has a timestamp. All the table on the instance layer get two additional columns: created_activity_id and deleted_activity_id. This is a lit bit redundant but required for performance reasons. Together with a second trick, the whole system is much faster as one would guess: This trick is to have two special activities: "beginning of time" (lowest possible date) and "end of time" (highest possible date). This allows to greatly simplify the queries, because deleted_activity now always has a valid value. Life objects are simply deleted at the end of time. {{#breadcrumbs: Marauroa | Internals | Roadmap | Meta object model }}