Login required to access the wiki. Please register to create your login credentials We apologize for any inconvenience this may cause, but please note that this step is necessary to protect your privacy and ensure a safer browsing experience. Thank you for your cooperation. Documents available for download: GAMSO , GSBPM , GSIM |
The modelling technique used for the SDMX Information Model (SDMX-IM) is the Unified Modelling Language (UML).The scope of this section is to give some notions of UML to simplify the readbility of the Clickable SDMX diagrams[1].
Only a part of the UML standard is used in the Clickable SDMX diagrams: classes and relations between classes.
Classes and attributes
"A Class classifies a set of objects and specifies the features that characterize the structure and behavior of those objects" [2]. A class is represented by a rectangle
A class is something of interest to the user. The equivalent name in an entity-relationship model (E-R model) is the entity and the attribute. In fact, if the UML is used purely as a means of modelling data, then there is little difference between a class and an entity.
A class is represented by the name, its attributes and operations. In the picture above the name of the class is AnnotableArtefact. Usually in UML these three parts are represented in the rettangle itself in different compartements, in SDMX clickable the attributes are shown in a grid in the detail of class with the cardinality of the attributes and the operations are shown in the graph with cardinality and name.
Abstract Class
An abstract class is drawn because it is a useful way of grouping classes, and avoids drawing a complex diagram with lots of association lines, but where it is not foreseen that the class serves any other purpose (i.e. it is always implemented as one of its sub classes). In the diagram in this document an abstract class is depicted with its name in italics.
Associations
General
In an E-R model these are known as relationships. A UML model can give more meaning to the associations than can be given in an E-R relationship. Furthermore, the UML notation is fixed (i.e. there is no variation in the way associations are drawn). In an E-R diagram, there are many diagramming techniques, and it is the relationship in an E-R diagram that has many forms, depending on the particular E-R notation used.
Simple Association
Here the DataflowDefinition class has an association with the DataStructureDefinition class. The diagram shows that a DataflowDefinition can have an association with only oneDataStructureDefinition (1) and that a DataStructureDefinition can be linked to many DataflowDefinitions (0..*). The association is sometimes named to give more semantics. In UML it is possible to specify a variety of “multiplicity” rules. The most common ones are:
- Zero or one (0..1)
- Zero or many (0..*)
- One or many (1..*)
- Many (*)
- Unspecified (blank)
Aggregation
An association with an aggregation relationship indicates that one class is a subordinate class (or a part) of another class. In an aggregation relationship. There are two types of aggregation, a simple aggregation where the child class instance can outlive its parent class, and a composition aggregation where the child class's instance lifecycle is dependent on the parent class's instance lifecycle. In the simple aggregation it is usual, in the SDMX Information model, for this association to also be a reference to the associated class.
Association Names and Association-end (role) Names
It can be useful to name associations as this gives some more semantic meaning to the model i.e. the purpose of the association. It is possible for two classes to be joined by two (or more) associations, and in this case it is extremely useful to name the purpose of the association. Figure below, shows a simple aggregation between CategoryScheme and Category called /items (this means it is derived from the association between the super classes – in this case between the ItemScheme and the Item, and another between Category called /hierarchy.
Furthermore, it is possible to give role names to the association-ends to give more semantic meaning – such as parent and child in a tree structure association. The role is shown with “+” preceding the role name (e.g. in the diagram above the semantic of the association is that a Item can have zero or one parent Items and zero or many child Item). In this model the preference has been to use role names for associations between concrete classes and association names for associations between abstract classes. The reason for using an association name is often useful to show a physical association between two sub classes that inherit the actual association between the super class from which they inherit. This is possible to show in the UML with association names, but not with role names. This is covered later in “Derived Association”. Note that in general the role name is given at just one end of the association.
Navigability
Associations are, in general, navigable in both directions. For a conceptual data model it is not necessary to give any more semantic than this. However, UML allows a notation to express navigability in one direction only. In this model this “navigability” feature has been used to represent referencing. In other words, the class at the navigable end of the association is referenced from the class at the non-navigable end. This is aligned, in general, with the way this is implemented in the XML schemas.
Here it is possible to navigate from A to B, but there is no implementation support for navigatation from B to A using this association.
Inheritance
Sometimes it is useful to group common attributes and associations together in a super class.This is useful if many classes share the same associations with other classes, and have many (but not necessarily all) attributes in common. Inheritance is shown as a triangle at the super class.
In the picture above, the Dimension is derived from Component. Component is an abstract super classe. The Dimension inherits the attributes and associations of the super classe in the inheritance tree. Note that a super class can be a concrete class (i.e. it exists in its own right as well as in the context of one of its sub classes), or an abstract class.
Derived association
It is often useful in a relationship diagram to show associations between sub classes that are derived from the associations of the super classes from which the sub classes inherit. A derived association is shown by “/” preceding the association name e.g. /name (see picture from Association Names and Association-end (role) Names for /items and /hierarchy associations)
[1] For this section it has been unsed the Appendix of the SDMX_InformationModel.pdf document.