Metamodel - Entities and relationships

The metamodel configuration in Anjana Data allows adapting and extending the entity and relationship structure beyond the native metamodel. Through the Configuration Panel, the administrator can define new entity subtypes (for example, BUSINESS TERM, AI SYSTEM, AI MODEL) and relationship subtypes (for example, TRAINED_WITH, GOVERNS, USED_BY) that represent the reality of the organization.

The image below shows an example of an extended metamodel, in which native entities and relationships are combined with custom ones, reflecting the complexity of data assets and their links within the organization:

These entity and relationship subtypes form the basis for:

• Consistently documenting the different data assets.

• Establishing dependency, hierarchy, and governance relationships between them.

• Integrating governance processes with configurable workflows for the creation, modification, transfer, deprecation, and validation of these assets.

Table Object Sub-types from the Configuration Panel (Administrator view)

The Object Sub-types table is the central point where the metamodel's entities and relationships are configured. Each registered object subtype is characterized by the following fields:

Structure of the Object Sub-types table

Each entity or relationship to be governed is characterized by the following fields:

• id: unique identifier of the object subtype.

  • It is automatically assigned from the Configuration Panel, based on database sequences.

• name: name of the object subtype.

  • This value must be unique within the module and cannot be repeated among existing entities or relationships.

• module: module to which the object belongs.

  • "BG" → Business Glossary

  • "DC" → Data Catalog

• typeObject: indicates whether the subtype corresponds to an entity or a relationship.

  • "ENTITY" → Metamodel entity (example: DATASET, REPORT, DOCUMENT).

  • "RELATIONSHIP" → Relationship between entities (example: TRAINED_WITH, USED_BY, GOVERNS).

• activate_workflow: name of the identifier of the activation workflow for non-native entities or relationships.

• create_workflow: name of the identifier of the creation workflow.

• deactivate_workflow: name of the identifier of the deactivation workflow for non-native entities or relationships.

• modify_workflow: name of the identifier of the edit or modification workflow.

• transfer_workflow: name of the identifier of the workflow that manages the transfer (change of organizational unit) of entities.

• deprecate_workflow: name of the identifier of the deprecation workflow for native entities of the Data Catalog.

• wf_role_dependent: flag that defines whether there are role-differentiated workflows for the same action.

  • When this flag is enabled, for each of the actions configured in the previous fields (create_workflow, modify_workflow, transfer_workflow, deprecate_workflow, etc.) it is necessary to define a role-specific workflow that has permissions to trigger that action.

  • The identifier of each role-based workflow is built from the base workflow identifier, concatenated with the role name in the Roles table using the format:

    <id_workflow_base>_-<role_name>
    

  • Example: if the identifier of the base creation workflow is CREATE_DATASET and the role's name is DataSteward, the identifier will be CREATE_DATASET_-DataSteward.

• parental: applies only if it is a relationship.

  • If the value is true, the relationship is considered parental (parent-child) and will be represented vertically (top-bottom) in the lineage.

  • If false, the relationship is considered input-output, represented horizontally (left-right).

Creating an entity in the Object Sub-types table

Creating a new entity in the metamodel involves registering a new record with type ENTITY in the Object Sub-types table.

To add a new entity:

1. Click the New button in the top-right corner. This will open a wizard with the fields defined in the Object Sub-types table structure section.

2. Fill in the corresponding fields:

   • name: name of the entity (example: AI_MODEL).

   • module: module in which it will be used (example: DC).

   • object_type: select ENTITY.

   • Define the names of the identifiers of the workflows associated with the actions:

     • create_workflow : Identifier of the creation workflow (example: WF_AI).

     • modify_workflow : Identifier of the modification workflow (example: WF_AI).

     • activate_workflow : Identifier of the activation workflow, does not apply to native entities (example: WF_AI).

     • activate_workflow : Identifier of the activation workflow, does not apply to native entities (example: WF_AI).

     • deactivate_workflow : Identifier of the deactivation workflow, does not apply to native entities (example: WF_AI).

     • transfer_workflow : Identifier of the organizational unit change workflow (example: WF_AI).

     • deprecate_workflow : Identifier of the deprecation workflow, does not apply to non-native entities ( example: left empty since it is a non-native entity )

   • wf_role_dependent : check only if you want to configure different workflows for each of the previous workflows.

3. Click Save to save the entity or Cancel to discard it.

Creating a relationship in the Object Sub-types table

Creating a new relationship in the metamodel involves registering a new record with type RELATIONSHIP in the Object Sub-types table.

To add a new relationship:

1. Click the New button in the top-right corner. This will open a wizard with the fields defined in the Object Sub-types table structure section.

2. Fill in the corresponding fields:

   • name: name of the relationship (example: COMPOSED_OF).

   • module: module in which it will be used (example: DC).

   • object_type: select RELATIONSHIP.

   • Define the names of the identifiers of the workflows associated with the actions:

     • create_workflow: Identifier of the creation workflow (example: WF_AI).

     • modify_workflow: Identifier of the modification workflow (example: WF_AI).

     • activate_workflow: Identifier of the activation workflow, does not apply to native relationships (example: WF_AI).

     • deactivate_workflow: Identifier of the deactivation workflow, does not apply to native relationships (example: WF_AI).

     • transfer_workflow: Identifier of the organizational unit change workflow (example: WF_AI).

     • deprecate_workflow: Identifier of the deprecation workflow, does not apply to non-native relationships (left empty in that case).

   • wfRoleDependent: check only if you want to configure different workflows for each of the previous workflows based on the user's role (left unchecked in this example).

   • parental: check if the relationship should be represented in the lineage as a parental relationship (parent-child, vertical). Leave unchecked if the relationship is of the input-output type (horizontal). (Left unchecked in this example)

3. Click Save to save the relationship or Cancel to discard it.

Modifying an entity or relationship in the Object Sub-types table

Modifying an object subtype (whether an entity or a relationship) is managed directly from the Object Sub-types table in the Configuration Panel.

When editing a subtype, it is important to keep in mind the following considerations:

• Fields that can be modified:

  • The workflow identifiers (create_workflow, modify_workflow, transfer_workflow, deprecate_workflow, etc.).

  • The parental and wf_role_dependent flags, which can be enabled or disabled at any time depending on lineage visualization needs or the management of role-differentiated workflows.

• Fields that cannot be modified once there are governed objects in the Data Portal associated with that subtype:

  • typeObject (ENTITY or RELATIONSHIP).

  • name of the subtype.

Configuring object subtypes via direct database access (Developer view)

The database (DB) table that contains the parameterization of the metamodel's entities and relationships (anjana.object_subtype) has this structure:

Below is an example script for configuring the AI_MODEL entity:

INSERT INTO anjana.object_subtype
(id_object_subtype, activate_workflow, create_workflow, deactivate_workflow, deprecate_workflow, modify_workflow, "module", "name", object_type, transfer_workflow, wf_role_dependent, is_parental)
VALUES(32, 'WF_AI', 'WF_AI', 'WF_AI', 'WF_AI', 'WF_AI', 'DC', 'AI_MODEL', 'ENTITY', 'WF_AI', false, false);

Below is an example script for configuring the COMPOSED_OF relationship:

INSERT INTO anjana.object_subtype
(id_object_subtype, module, name, object_type, create_workflow, modify_workflow, activate_workflow, deactivate_workflow, wf_role_dependent, is_parental)
VALUES
(102, 'DC', 'COMPOSED_OF', 'RELATIONSHIP', 'WF_AI', 'WF_AI', 'WF_AI', 'WF_AI', false, false);