Relations in MMBase

MMBase is an object oriented content management system. I.e. text, images and other content are stored in objects, objects are connected by relations, relations are objects themselves. The most basic relation of these, is the relation that can be used to connect two objects, but does not contain any content itself. This relation which does not contain any additional information is normally called "related". Often it is not enough to make a relation between two objects. For instance, when adding news items to a magazine one also needs a way of telling in which sequence the newsitems should occur. In MMBase one can use the "posrel" relation for this purpose. The "posrel" not only connects two objects, but it also allows you to store an integer value in this relation. To this end you use the "pos" field of the relation. In general, you can create relations with whatever fields you need for your content model. For instance, when connecting employees to departments one can use a relation which contains an extra String field to store information on the function(s) an employee has in his/her department(s).

This document provides information on how to create and use relations. Before you can actually start creating relations between MMBase objects, you must assert that this relation can be understood by MMBase. This means that you must assert the following three things.

The following image provides a graphical representation of these steps. In the sections that follow the details of each step will be described.

This document assumes that you are familiar with the following concepts:

Like normal objects, relations are of a certain type (`are created by a certain builder'). We will have a closer look at two standard object type definitions used for relations: insrel (defined in insrel.xml) and posrel (defined in posrel.xml).

In the previous section we saw what a builder for a relation looks like. You can use these builders to create relations. Every relation instance also has a certain role. The existing roles are defined in the `reldef' table. In this reldef object type you have to set the following fields.

In the previous section we saw how we can define relation roles in MMBase. Principally you could be ready now to create actual relation instances. You could take two object and connect them by a `role'. The role defines also the relation builder, and therefore the extra fields which can be filled in the relation object itself.

But MMBase enforces us to explicitely define what kind of relations are possible. For example you have to explicitely state that relations between news nodes and people nodes with the role `author' are allowed.

This extra requirement makes generic editors a lot simpler, because MMBase can offer only the possibility to relate people to news articles (and what else is defined), and there is no need to add buttons for every permutation of object types and roles, which would make such editors very complex.

The other advantage is that database queries can be optimized using this information about which relations are possible. So, though it could be tempting to allow the relation from any object to any object (because of `inheritance' this is perfectly possible), it would be inadvisable to do so. Generally you should limit yourself to relation types which you are actually going to use. Using `inheritance' in allowed relation definitions is possible, but use it sparingly.

When `following' relations in the front-end, this on default tries to follow them in `both' directions (if both are possible). If the object type on both sides of your allowed relation type is the same, you could therefore consider making the relations unidirectional. Otherwise in the resulting queries lots of `OR' constraints may arise which is generally very bad for performance. The option is to specify the `search direction' on every query you do between to objects of the same type.

For the same reason you should also avoid to allow the same relation in both directions. It's better to allow the `author' relation only from news to people, and not also from people to news.

If you have a look at the typerel objects, which define the allowed relations, in generic editors, you see that you can set the following fields.


The field names for the builders and relations are called snumber, dnumber and rnumber, because the builders are specified by the object numbers from the typedef table and the relations are specified by the object numbers from the reldef table. In generic editors you should however see nice drop down boxes.

This is part of the MMBase documentation.

For questions and remarks about this documentation mail to: