Data lineage in Anjana Data can be visualized from different perspectives (business, technical, audit, consumption, etc.) thanks to the definition of visualization layers.
Layers allow pre-filtering the types of entities and relationships displayed in the lineage graph according to the chosen layer, so that each user can focus on the most relevant elements for their use case.
Additionally, a layer can be configured as default, so that it is the first one displayed when accessing the lineage.
Layer Table in the Configuration Panel (Administrator view)
Lineage layer management is performed from the Configuration Panel in the Layer table.
Structure of the Layer table
Each registered layer is characterized by the following fields:
-
Id: unique identifier of the menu entry. Assigned automatically from the Configuration Panel. -
Name: visible name of the layer in the Data Portal.-
In the case of multi-language configuration (internationalization), the
Namevalue itself must be used as a translation key in thetranslationstable, creating one record per language. -
No two layers can share the same name.
-
-
isDefault: indicates whether the layer is the default one (isDefault= true). There may be no layer marked as default, in which case the base layer containing all objects will be displayed.
Notes:
-
The lineage always includes a base layer that contains all metamodel objects without aggregation relationships. This layer does not require configuration in the
Layertable. -
It is not mandatory for a layer to be marked as default in this table. In its absence, Anjana Data displays the base layer by default.
-
Only one layer can be marked as default.
-
The configuration in this table does not affect governed objects or their existence in the Data Portal. It only conditions the visualization in the lineage graph.
Creating a Layer in the Layer table
Creating a new layer involves adding a record to the Layer table with the layer name and, optionally, marking it as the default.
To create a layer from the Configuration Panel:
-
Click the New button in the upper-right corner.
-
Fill in the fields:
-
Name: enter the name of the layer (e.g.: Consumption layer). -
isDefault: check if you want the layer to be the default one (e.g.: in this case it is not desired to mark it as the default layer, as another one already serves that purpose).
-
-
Click Save to save the layer or Cancel to discard.
Note: After creating a layer, it is necessary to run the Clear cache action from the Configuration Panel (Actions > Clear cache) for the changes to be applied and visible in the Data Portal.
Modifying a Layer in the Layer table
Modifying an existing layer must be done with caution. These changes do not affect governed objects in the Data Portal, as they only impact how the lineage is visualized:
-
Name: can be freely modified. If internationalization is used, it will be necessary to review the associated translations in thetranslationstable. -
isDefault: can be enabled or disabled as needed.
Note: After modification, it is necessary to run the Clear cache action from the Configuration Panel (Actions > Clear cache) for the changes to be applied and visible in the Data Portal.
Configuring Layers via direct database access (Developer view)
Lineage layers are stored in the anjana.layer table.
|
Column |
Data type |
Constraints / Notes |
|---|---|---|
|
id |
int4 |
PRIMARY KEY. Unique identifier of the layer, managed by sequence. |
|
layer_name |
varchar(255) |
NOT NULL. Name of the layer. Must be unique ( |
|
is_default |
bool |
Default value = false. Indicates whether the layer is the default one. Only one layer should be marked as true. |
Below is an example script to configure a lineage layer:
INSERT INTO anjana.layer
(id, layer_name, is_default)
VALUES(2, 'Capa de consumo', false);
Important:
-
Once the insert has been executed, run the sequence update for the table. (From the Configuration Panel under
Actions > Reset DQ sequences, you can update the sequences of all tables, including this one). -
The full responsibility for the configuration logic lies with the developer executing the SQL queries directly on the tables. It is recommended to carefully review the Table Structure section.