Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)
Method for definition of data model
1. What is a data model?
A data model is formal documentation for data management. It is a guide to the implementation and use of resources, entities, and data. It is interesting to define for several reasons:
- The possibility to anticipate resource problems before they occur;
- An additional guarantee of the quality, security, and accessibility of data;
- Better allocation of resources;
- Reinforcing the communication, relationship, and collaboration between the functions, logical components and subsystems.
The figure below presents a global ontology for the data model. It puts in parallel concepts defined by ARCH and concepts of Capella.
2. Conceptual data model
2.1. General Approach
The conceptual data model expresses an overview without going into detail. It is therefore completely independent of technologies, systems, and software.
It is used as a starting point for discussion between the project stakeholders. The important categories of data classification are selected and the relationships between them are described. These classes should be based on concrete cases. Everyone should be able to understand the established conceptual model. Technical details are reserved for the following two types of models.
This phase mainly concerns the operational concept architect, the lead system architect, and the system architect.
2.2. Data Object Class
It is a classifier used for understanding the foundations of how the railway environment works. These classes are defined as expressions that have relationships with each other and provide a unique meaning. These expressions are used to explain domain-specific concepts and their relations.
Note: these classes have no attributes or roles but only associations with other classes in the conceptual data model.
2.3. Term
Terms are defined as classes that do not have relationships with each other and provide a unique meaning within the project. It is not used directly in the MBSE approach but ensures a common understanding of the vocabulary used. This may include specific vocabulary for certain stakeholders, specific standards and nomenclatures related to the approaches used, common abbreviations, etc.
3. Logical data model
3.1. General Approach
The logical data model defines more detailed specifications and properties. This data model focuses on the structure of the required data and how it can be represented in a real database. A conceptual model can result in several logical data models. The logical data model defines the information content carried by interactions between operational activities or by functional exchanges between functions.
Lead system architects continue to lead the process in this phase but are beginning to involve domain expert architects to specify the classes, their relationships, and their properties.
3.2. Data objects
3.2.1. Data Object Class
Already defined in the conceptual data model, the data object class is a classifier: it helps to create a classification of objects thanks to the features that characterise the structure and behaviour of those objects. On the logical data model, a class has properties: roles and attributes.
- Attribute: held directly by the class.
- Role: derived from the navigability of an association link between classes.
Note: most of the time role's name is the name of the pointed class. Find more information here: Data modelling with capella (what is possible)#Property
3.2.2. Other classifiers: simple type and structured type
There is two other classifiers for the logical data model: simple type and structured type.
Note: instances of a data type (simple or structured) are identified only by their value, which means that data types with the same value are considered to be equal instances.
3.2.2.1. Simple data type
The purpose is to identify type with simple data (without properties)
As presented in ontology below, there exist several simple data types (boolean, enumeration, etc.).
Some of them have constraints:
- Numeric: for the operational level, the system level, and the logical level, it does not make sense to distinguish numeric attributes into integer, long, unsigned float, etc. These distinctions are part of the solution, not the external requirements. An exception can be made to model non-payload data on external interfaces, the numeric sub-types may be used. Within the physical level, we can start to define the interfaces between subsystems, then detailed numeric types can be used.
Physical quantity: developed with units, these data types are always defined and edited on the operational level only (to ensure that they can be reused at all levels and that there is only one location for these standard definitions).
3.2.2.2. Structured data type
The purpose is to identify types with complex data because they can have properties and can be used as a type of property in another structured type.
In Capella, they are considered primitive classes, which means that these classes will have no identity in the context of the system and cannot be the source or target of association links. Two instances of this class with the same property values cannot be distinguished (e.g. a date does not have any intrinsic identity).
The difference between a structured type and a data object class is that a structured type has no roles (i.e there are no association links between structured types).
3.3. Exchange items
Exchange items are coherent groupings of elements from the data model that are exchanged simultaneously in a given context. Data are exchanged between functions thanks to functional exchanges. This element helps to structure exchanges in order to organise exchanged data and carry a requested communication principle. Consequently, each functional exchange should allocate at least one exchange item.
The exchange mechanisms can be of 3 kinds (see the definition of each of them here: Data modelling with capella (what is possible)#Exchangeitems):
Exchange mechanism | Cases |
---|---|
FLOW | It should be used to exchange items by default because data information between two functions is permanently present at each Capella layer (Operational, System, Logical, Physical). See ARCH.M.010 Method for definition of functionality chapter Technical note on definition of functions |
EVENT | If the interface is constrained by an external standard and if the functional exchange is between an actor function and a system function. It is considered asynchronous, similar to a signal event in SysML. Note: may is defined in ARCADIA a bit different but we decided to use it as mentioned above |
UNSET | When the information content is unknown or unclear. Add a text description on the exchange item, to act as a placeholder/STUB until the information content is resolved. |
The information content of the exchange item should be defined as far as possible using an appropriate combination of data objects (simple types or structured types) thanks to exchange item elements.
3.3.1.1. Exchange Item Elements
Exchange items are structured through exchange item elements in the same way as classes are structured in properties: they define the types of data by referencing a data model element (class or structured/simple types). Each exchange item has one or several exchange item elements as presented in the picture below:
See more information on exchange item elements here: Data modelling with capella (what is possible)#Exchangeitemelements.
4. Physical data model
4.1.1. General approach
Finally, the specifications can be encoded in physical data models. These describe the individual database tables, columns, and component types to specify the interfaces between subsystems. This physical data model also takes into account the performance, access, and use of resources by the subsystems and actors. Here, the technologies to be used have all been selected. The data modelling reaches its highest level of granularity so that we can use it as part of the interface specification.
The responsible for the interface specifications including the physical data modelling is the interfacing subsystem architect.
→ TBD RCAMT-693 - Getting issue details... STATUS