Legal information

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

  Draft

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

1- Each system architect per area of expertise shall elaborate their data object classes with identification of potential shared concepts with other area(s) of expertise    


2- For each shared concept, discussion has to be made with the system architect of the other area of expertise. (Note: a data object class can also be shared with more than 2 areas of expertise). If there are different definitions for that shared concept, then record them through rationale or comments in your modelling support. 

The rationales would help the Operational Concept Architect to understand the decision of having different definition and to avoid further discussion with those system architects


3- After discussion with the other area of expertise, a consolidation has to be done between the 2 ontologies of data object classes. This is a process that has to be done incrementally with the other areas of expertise (green, pink and yellow on the example)


4- Consolidation/review of all ontologies on a single project done by the Operational Concept Architect and the Cross cutting engineer to improve data object class definition. 

The shared concept can be grouped and definition could be refined. (See also chapter 1)


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