EA Toolsets project : OsMmRelations

HomePage :: PageIndex :: Guest Logon
[ OsEATools | MetaModel | Overview | Base-principles and requirements | Model-objects | Entities | Relations | Models | Categories ]


Metamodel: Relations


A relation represents a perceived relationship between any two entities.

A relation-type is a template (‘class’) for a specific type of relation.

(Relations are always binary, between two entities. An apparent n-ary relation is logically a cluster of relations of the same type of which one end of each relation connects in the same way to the same entity.)

A relation is always descriptive. It may optionally also imply semantics of relationship, to be verified within a model-type and model-instance.

Each end of the relation identifies the entity-type(s) to which it may connect, by specifying the matching ‘linkable’ connection-interface. Since these connection-interfaces may occur at any level in the entity-type stack, a relation may be linked to any entity-type which includes the respective connection anywhere in its stack – hence a relation does not need to be defined on a per-entity-type level, thus minimising the number of relations that need to be defined on adding a new entity-type to the metamodel repository.

A relation-type may also specify that it may not be connected to a given connection-type. (To support modal-logics, it should also be possible to allow or prevent connection based on property-values within the entity-type or its instances: this principle should be included within the metamodel design, but may be left for implementation at a later stage.)

A relation-type is constructed as a stack of subclasses, equivalent to the subclass stack for entity-types. A relation-type may therefore be configured to connect with any combination of the presence and/or absence (and/or, at a later stage, computed modal-logic) of connections within the entity-type stack.

As for entity-types, each member of the relation-type subclass-stack may carry any number of its own properties and/or display-methods. Likewise an instance of a relation may be reconverted back to a relation-type.

In certain cases, a relation-type may connect to instances of another relation-type rather than to an entity-type. (This is required for some model-types such as Object Role Modeling [ORM].) To support this, a relation-type may optionally expose its own ‘linkable’ connection-interface property, exactly as for entity-types.


[ OsEATools | MetaModel | Overview | Base-principles and requirements | Model-objects | Entities | Relations | Models | Categories ]
Comments [Hide comments/form]
I don’t like the description of “binary, between two entities”. The way that I visualise this is that any object can have a (complex-type) property, which may include a reference to another object.

For some references, a reciprocal reference may also exist in the target object, but this is not essential.

For example:

<google> (links to) <my company website>
but
<my company website> does not (link to) <google>

Is this a binary relation?
-- MikeT? (2009-05-15 01:26:27)
for MikeT?:

Agreed: by 'binary' here I mean that a relation connects only two entities: in other words, if you want to connect multiple entities to a single 'parent' entity - such as in UML-style aggregation or composition - you need a separate relation-object for each link.

The point about 'binary' was solely about what a relation connects: the semantics of the connection are determined by what exists at each end, and the properties of the relation. To use your example of directionality ("google links to my website, but my website does not link to google"), it's a property of a relation, not the relation-object itself: the relation itself is binary in that it connects just two entities, but the semantics of the relation are not 'binary', because the link being described goes only one way.

Again, this seems to be a slight confusion about the metamodel layer - which has no real concept of real-world semantics - versus the model layer - where the semantics obviously are the whole point of the model. What I'm describing here is the (meta)metamodel, not the model.
-- TomG (2009-05-17 22:55:51)