Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)
Best practices to maintain a consistent data model
RCAMT-656
-
01_2022_3 Update method page for abstract concepts to better understand generic data concepts definition
Finished
1. Consolidation of data model
Info
The data model is defined on this Method for definition of data model, here we focus on the changes/updates of the data content
At each Capella layer (operational, system, etc.) there are consolidation and optimisation of the concepts created and this includes the optimisation of the data model elements as well. The goal of these actions is to add elements to viewpoints already created in previous process steps (or create new viewpoints) in order to ensure a full-scope content.
Consolidation should aim to achieve:
- efficient model of data objetc classes;
- elimination of duplicates;
- realisation of multiple needs with reused items, where appropriate;
- elimination of gaps in definitions and coverage.
2. Data package organisation
The picture below represents the structure in the Capella model. At each layer, we found a folder for each specific type of data element.
2.1.1. Current proposal
2.1.2. Alternative proposal
3. Conceptual data model changes
3.1.1. Data object classes draft
Data object classes can be work in progress or out of the current scope, which means that they will be updated and taken under consideration in later iterations. They are called data object classes draft.
3.1.2. Modification of the conceptual data model
These concepts may be updated, and/or new concepts might be identified during the definition of the system architecture. In such a case, the person responsible for the data object classes (e.g. operational concept architect) must be involved in the change process.
Check if a data object class which you would like to create already exist, if so please involve all persons of interest in your discussion.
After the relationships of the data object class are defined, please share the results with the group.
Data object classes must be aligned with any international collaborations. Therefore, this task may be done jointly with other railway organisations if it makes sense to do the work once jointly and then adopt the outcome for ourselves.
3.1.2.1. Way of working to manage redundancy
Advices
- 2 representatives, system architect/system engineer or system architect/subsystem architect, of each area of expertise is enough for discussion
- Meeting of 2h is where you have the best results
4. Logical data model changes
4.1.1. Modification of the logical data model
Through the methodology and processes put in place for the other concepts of the project, new functional exchanges will appear (or be refined from other exchanges) in the different layers of the model (system analysis, logical architecture, etc.). The data that flows along these exchanges must be defined. Data modeling elements can be reused from a higher layer to a lower layer. In other words: if a functional exchange in the system layer needs to use a data element already created in the operational layer, it can and should do so.
It is not allowed to have identical data model elements on multiple levels, so before creating a new one check all instances for existing reusable data model elements (data objects and exchange items).
Exception
When working together in a cooperation project in which there is no operational level model content. In the model where there is model content at the operational level it is allowed that there is identical data at the operational level and system level. But the realisation relationship must then be set correctly.
For example, RCA does not have an operational level, while the DBS project does. In such a case, it is permissible for RCA to utilise operational-level data from DBS on its system level, since in this case the data are not being duplicated. However, in the case that the two projects are merged in the future, realisation relationships will have to be created between the previously-created data on operational level (DBS) and the newly-merged data on system level (RCA). It must also be ensured that the names of the data elements are provided postfixes corresponding to their levels.
If it is necessary to create a new data model element then link it via a realisation link to the corresponding parent element at the higher level. The diagram below shows the realisation links possible between the layers of the model.
- Note 1: new data model elements should be modeled at the level where they are first needed.
- Note 2: due to the feature-based approach it is theoretically possible that data objects might be created on a lower layer first,e.g. when the feature 1 work group reached the logical layer. Later, when the feature 2 work group starts to work on the system layer, the need for the same data object might be identified. If so the data object should be moved from the logical level to the system level.
.
If a new element is created due to a purely architectural decision then the description of the data element should include a rationale or a reference to where it is documented. This is likely to happen frequently at the system level, wherever decisions on system boundaries mean that the interface between the system and actors is now clearly defined in terms of information flows across the boundary.
4.1.2. Useful aspects for consolidation
During this activity, existing viewpoints shall be reviewed and updated where required with focus on the following aspects:
Re-usability and consistency
Are all common data objects been re-used as appropriate or are there potentially two or more specific data objects defined, which are very similar in scope? In this case it should be considered to create a common data object.
- Completeness
Are all exchange items actually linked to a data items?
Are all exchange items allocated to functional exchanges?
- Readability
Do the instances of data object provide good readability to convey the full definition of the respective data?
Is there also an overview of all data available as working diagram available? This helps to ensure re-usability, consistency and completeness
5. Physical data model changes
TBD
RCAMT-693
-
Follow up ticket for physical data modelling method/rules
BACKLOG