Meta object model for relational data storage: Difference between revisions
Jump to navigation
Jump to search
Content deleted Content added
imported>Hendrik Brummermann |
imported>Hendrik Brummermann No edit summary |
||
| (66 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{Navigation for Marauroa Top|Internals}} |
|||
{{Inprogress}} |
|||
{{Navigation for Marauroa Developers}} |
|||
{{Future Concept}} |
|||
== Object Model of Marauroa == |
== Object Model of Marauroa == |
||
| Line 7: | Line 12: | ||
== The basic Meta Model == |
== The basic Meta Model == |
||
This chapter will describe a generic meta model for object orientated systems. |
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 === |
=== Model Layer === |
||
| Line 13: | Line 18: | ||
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. |
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. |
||
[[Image:Model_layer.png]] |
|||
TODO: insert picture here. |
|||
In Marauroa "associations" are named "slots". They don't have a target type. |
In Marauroa "associations" are named "slots". They don't have a target type. |
||
| Line 21: | Line 26: | ||
Based on the model layer instances can be created: |
Based on the model layer instances can be created: |
||
[[Image:Instance_layer.png]] |
|||
TODO: insert picture here. |
|||
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. |
|||
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. |
|||
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 == |
== Converting the Meta Model into a database structure == |
||
TODO: ... |
|||
A simple way to store generic object data in a relational database would be a meta model like the following. While it is nice nobody stepped up yet to implement it, which would be quite a bit of work with little gain. |
|||
== 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 class (id SERIAL, name VARCHAR); |
||
| Line 57: | Line 81: | ||
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. |
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. |
||
[[Category:Marauroa]] |
|||
{{#breadcrumbs: [[Marauroa]] | [[Navigation for Marauroa Developers|Internals]] | [[Marauroa Roadmap|Roadmap]] | [[Meta object model for relational data storage|Meta object model]] }} |
|||