Model creation

Model in ObjectGears can be understood as a separate application. Relation between classes is solved by means of references and inheritance.

Hereinafter you can find model aspects of model creation from the perspective of relations between classes that represent fundamental data framework of the model/application. Description of other ObjectGears features (Master-Detail relace, Pravidla, Skripty, Workflow etc.) can be found in other chapters. Security aspects of creation a new model/application or functionality are described here.

Reference to another class can have cardinality of 0 or 1 record (de facto column that is a foreign key in the entity-relationship model) or 0 to N records (association class analogy). The classes can be also linked up by means of another class (real association class, possibly with another columns describing relation that that the class mediates).

However, it is difficult to implement subcategories by means of foreign keys. Subcategories are situations when objects have a number of common properties which can be grouped in a special class and then specific properties according to the type (category) of the object. An example are means of transport, that can be divided to cars, airplanes, ships, that have their own property sets. Subcategories are implemented in ObjectGears by means of inheritance. All the objects, no matter if cars, airplanes or ships have several attributes defined in the common parent class – class Means of transport. Other attributes are specific for the given type and are stated in particular classes Cars, Ships, Airplanes inheriting from the class Means of transport.

An advantage of using subcategories is also the fact that we can refer in other clasess both to one particular type (cars, ships, airplanes) and to all of them at the same time (means of transport). In the first case we are selecting in the referring column either from cars or from ships or from airplanes. In the latter case we are selecting from the list of all means of transport irrespective of its type.

Inheritance and a common parent class will be also used if we do not know all the possible relations between objects or the relations are varied and komplex. Definition of dependencies between classes is then solved on the common parent class level. An example is IT configuration database containing particular components hardware, servers, applications and their components, databases, documentation etc. It is possible to create an entity-relationship models of various complexity for these classes. However, in order to capture all the possible relations (any class with another class), we will introduce selfreference on class Configuration item, that is a common parent class to all other classes.

 

Entity-relationship model – foreign keys are used to capture relations.

Subcategories implementation – classes do not have defined relations between themselves, but they inherit properties from its parent class (Configuration item), to which relations are defined by selfreference. (There is Configuration item in the example, as it is described by the ITIL framework.)

 

Parent class can also have its parent class. In our example it is convenient to group classes describing Microsoft Active directory (users, computers, groups) under a common parent class – class MS Active Directory Objects. This class will be a child class of the class Configuration item. The advantage of this design is that we can refer in the column Members of the class MS AD Groups to all the objects that can be members of MS AD group.

Both shown approaches to capture relations between classes (references to classes by means of columns of the reference type and inheritance from the class that refers to itself) can be combined.

This design enables to explicitly define all the frequent relations in a well structured way (references between classes) and at the same time have the possibility to capture rare or not anticipated relation by common class selfreference as it is specified in the ITIL framework.

Above mentioned examples enable to achieve high data integrity in ObjectGears and capture also relations, that may not be planned at the creation of classic stitic entity-relationship model at the time of its design. If we do not want in some cases to create model with many classes and use class inheritance, but on the contrary to take advantage of storing data in a single class we may use property multiple columns, that is defined in the class detail.