Home > Metamodelling Concepts > Entity Class and Attribute Class
Classes are the key concept in object-oriented modelling. Naturally OOMEGA supports classes, inheritance and polymorphism. In addition there are some special features which need to be explained, namely:
- Entity Class and Attribute Class
- Abstract Class and Definite Class
- Strong Entity Class and Weak Entity Class
- Mapped Attribute Class
Entity Class and Attribute Class
A class is either an entity class or an attribute class. In terms of JDO, entity classes are first class objects and attribute classes are second class objects. In relational terms (and in the broadest sense) an entity class corresponds to a relational table and an attribute class defines the type of a table column.
The instance of an entity class is called entity object or brief entity. Analogous the instance of an attribute class is called attribute object. The characteristics of entity and attribute classes are as follows:
| Entity Classes | Attribute Classes |
|---|---|
| Extents of entity classes are well known and subject to database queries. | Extents of attribute classes are not known and of no interest. |
| Entities are interconnected with other entities in an object graph. | Attribute objects always reside within entities, but they may also contain other attribute objects. They form a hierarchical tree of information. |
| Uni- and bidirectional associations between entity objects are supported. | Attribute relationships are always unidirectional. However, an attribute object may also have an unidirectional association to another entity object. |
| Entities are treated as atomical units in client/server communication and the locking system. | Attribute objects are treated as part of entities. They are not autonomous. |
| Entities must be deleted explicitely. They may be deleted automatically according to a well-defined cascading delete mechanism. | Attribute objects are always deleted implicitely whenever they are unaccessible from the spanning entity. |
Abstract Class and Definite Class
Abstract classes define a model constraint: a data container must not contain any instances of an abstract class. Be aware that the class extent of an abstract class typically contains instances of concrete subclasses.
Definite classes define a contract for the modeller: all subclasses must not add any fields and are in turn definite. A field is an attribute or a (navigable) association. In contrary to the Java keyword final it is allowed to add or overload methods in subclasses of a definite class.
The bottom line of the "definite class" concept is that the whole class extent is made up of objects with exactly the same data structure although it might also contain instances of subclasses. Theoretically you could typecast between the whole class hierarchy starting from the root definite class. In practice this is not possible, because Java does not support this concept. Nevertheless you are able to speed up the serialisation and deserialisation process by providing this information to your metamodels.
Strong Entity Class and Weak Entity Class
Strong entity classes and weak entity classes are related to an object-oriented cascading delete concept. First of all you must know that whenever you delete an entity all the links to and from other entities are deleted automatically. This is the default behaviour of a data container and guarantees referential integrity. In relational terms this approach is named "on delete set null".
- Instances of strong entity classes are called strong entities. They can exist on their own and won't be deleted automatically.
- Instances of weak entity classes are called weak entities. They always have to have a link to exactly one composite object (cp. composition). If there's no such link set they will be deleted automatically by the data container.
Mapped Attribute Class
Attribute classes describe the underlying data structure unambiguously and are among other things crucial for the canonical encoding with the "Structured Data Format" (SDF) or "Structured Data Markup Language" (SDML). On the other hand it is a desirable feature to map an attribute class to the corresponding language specific type. This is very important to ensure a comfortable data handling in the context of a specific programming language, e.g. Java.
Consider for example the attribute class org.oomega.base.String. The string operations, heavily embedded in the programming language Java, do not know anything about OOMEGA's String. Fortunately they don't have to, because we mapped this type to java.lang.String thanks to the mapping facility. Thus the application programming interface never confronts the programmer with the OOMEGA-specific type. You just get and deliver ordinary strings perfectly known by your programming environment.
You'll find a lot of attribute classes in the org.oomega.base package which are mapped to their pendants in Java.
In SDL classes are represented by files with the suffix .model. They must be part of metapackage folders.
+ OOMEGA Core.metamodel
+ org
+ oomega
+ base
+ meta
AbstractSyntax.model
AttributeClass.model
...
+ persistence
+ query
+ syntax
The content of model class files is nearly identical to what you already know from Java. Additionally there are some class-level
annotations available.
- abstract - an abstract class
- @entity - a strong entity class
- @entity(weak = true) - a weak entity class
- @mapped (java="") - a mapped class
- @definite - a definite class
- @attribute - an attribute class
Here are two examples:
- org.oomega.base.String - a definite and mapped attribute class
package org.oomega.base; @mapped (java="java.lang.String") @definite @attribute (cid=27) class String { ... }
- org.oomega.meta.DataClass - an abstract and weak entity class
package org.oomega.meta; abstract @entity(weak = true, cid = 102) class DataClass { ... }
Next chapter: Attribute