🤝Relationships

In Euno, the data model is made up of resources, each identified with a Universal Resource Identifier. Between these resources there are relationships.

These relationships form the foundation of Euno’s graph-based understanding of the data stack. There are five primary types of relationships:

1. Dependency

A dependency relationship exists when one resource relies on another. For example, a database view created by joining three tables will have three dependency relationships pointing from the view to each table.

If resource A depends on resource B, A is said to be downstream of B, and B is upstream of A.

A single resource may have zero, one, or many dependencies—technically a many-to-many relationship.

Examples of using upstream and downstream queries:

• To find the upstream of a resource: has upstream(uri="<resource-uri>")

• To find the downstream of a resource: has downstream(uri="<resource-uri>")

Column-Level Dependencies

Euno also supports fine-grained, column-level dependency tracking using the attributes upstream_fields and downstream_fields. These relationships capture dependencies between individual fields (such as columns, measures, or dimensions), or between fields and visualizations (such as Tableau views or Looker Looks).

For instance:

• A column in a table used in a Tableau view would create a dependency from the view to the column.

• A measure in a Looker Look based on multiple columns would be downstream of those columns.

Examples of using upstream_fields and downstream_fields:

• To find the visualizations in Tableau that use a specific field: type="tableau_view" and has upstream_fields(uri="<resource-uri>")

• To find all the fields used in a Tableau view: type="tableau_field" and has downstream_fields(uri="<resource-uri>")

Note: If a resource has both column-level lineage and regular lineage, and you want to return all relevant resources, you need to include both types of queries. For example: has downstream_fields(uri="<resource-uri>") or has downstream(uri="<resource-uri>")

2. Containment

A resource can be contained within another resource. For example, a column is contained in a table, and a table is contained in a schema.

When two resources, A and B, have a containment relationship such that A contains B, we say that A is the parent of B, and B is a child of A.

A resource can have zero, one, or many children, and zero or one parent. In technical terms, this is an optional many-to-one relationship.

Examples using the containment relationship:

• To find all the resources inside a workbook: has parent(type="tableau_workbook" and uri="<resource-uri>")

• To return all the fields in a table: has parent(type="table" and uri="<resource-uri>")

3. Defined-by

The defined by relationship links a resource to the entity that defines it. It is used when one resource determines the structure or existence of another.

For example, a Snowflake table created via a dbt model will have a defined by relationship pointing from the table to the dbt model. Conversely, the dbt model is considered the definer of the table.

It is possible for a resource to have multiple definers.

Example:

• To find the dbt resource that defines a specific table in the warehouse: type~"dbt" and has defined(type="table" and uri="<resource-uri>") or type~"dbt" and is definer of(type="table" and uri="<resource-uri>")

• To find the table that is defined by a dbt model: type="table" and has definer(type~"dbt" and uri="<resource-uri>") or type="table" and is defined by(type~"dbt" and uri="<resource-uri>")

This relationship helps trace logical definitions across tools, and surfaces authoritative sources within your data stack.

4. Usage

A usage relationship exists when a user interacts with or uses a resource. This relationship tracks which users are accessing which resources, providing insights into resource utilization and user behavior.

If resource A (a user) uses resource B, A is said to be a user of B, and B is used by A.

A resource can be used by zero, one, or many users—technically a many-to-many relationship.

Examples of using user and used queries:

• To find all users of a specific resource: type="user_account" AND is user of(type='tableau_dashboard' AND uri="<resource-uri>")

• To find all resources used by a specific user: type="tableau_view" AND is used by(name="[email protected]")

Timeframe specification: For usage relationships, you can limit results to a specific time period by adding -Xd parameters (where X is the number of days).

5. Membership

A membership relationship exists when a user or group is a member of another group or workspace. This relationship tracks organizational structure, access control, and group hierarchies.

If resource A (a user or group) is a member of resource B (a group or workspace), A is said to be a member of B, and B has A as a member.

A group or workspace can have zero, one, or many members—technically a many-to-many relationship. Groups can also be members of other groups, creating nested group hierarchies.

Examples of using member and group queries:

• To find all members of a specific group: has group(uri="<group-uri>")

• To find all groups that a user is a member of: has member(uri="<user-uri>")

• To find all members of a PowerBI workspace: has group(uri="<workspace-uri>")

Resource Types:

• user_account (or user): Represents an individual user in the system. Users can be members of groups and workspaces.

• user_group: Represents a security group or organizational group. Groups can contain users and other groups as members.

• powerbi_workspace: PowerBI workspaces can have users and groups as members, with role information (e.g., Admin, Member, Contributor).

Role Information:

When querying membership relationships with extended_relationships=true, the API returns role information for workspace memberships. For example, a user might be an "Admin" or "Member" of a PowerBI workspace.

Summary of Resources and Possible Relationships

Lineage Relationships (is upstream of)

Source Resource	Relationship	Target Resource
dbt_seed, dbt_source, dbt_model, dbt_snapshot	is upstream of	dbt_model, dbt_snapshot
dbt_model	is upstream of	dbt_semantic_model
dbt_measure	is upstream of	dbt_metric
dbt_metric	is upstream of	table, dbt_metric, looker_view
table	is upstream of	table, tableau_published_datasource, tableau_embedded_datasource, tableau_custom_sql, looker_view, powerbi_table, snowflake_semantic_view
tableau_custom_sql	is upstream of	tableau_embedded_datasource, tableau_published_datasource
tableau_published_datasource	is upstream of	tableau_embedded_datasource
tableau_embedded_datasource	is upstream of	tableau_view
tableau_view	is upstream of	tableau_dashboard
looker_view	is upstream of	looker_view, looker_explore
looker_explore	is upstream of	looker_view, looker_explore, looker_look, looker_tile, looker_dashboard
looker_tile	is upstream of	looker_dashboard
looker_look	is upstream of	looker_dashboard
table	is upstream of	hex_project
table	is upstream of	powerbi_dataflow
powerbi_dataflow	is upstream of	powerbi_table
table	is upstream of	powerbi_table
powerbi_table	is upstream of	powerbi_report, powerbi_tile
powerbi_tile	is upstream of	powerbi_report
sigma_workbook	is upstream of	table
hex_semantic_model	is upstream of	dbt_semantic_model
hex_dimension	is upstream of	dbt_dimension
hex_measure	is upstream of	dbt_metric

Column-Level Lineage Relationships (is upstream_fields of)

Source Field	Relationship	Target Field
column	is upstream_fields of	column, tableau_field, hex_project, powerbi_column, powerbi_measure, snowflake_dimension, snowflake_metric
tableau_field	is upstream_fields of	tableau_field, tableau_view
powerbi_column	is upstream_fields of	powerbi_measure, powerbi_column, powerbi_tile
powerbi_measure	is upstream_fields of	powerbi_tile
hex_dimension	is upstream_fields of	dbt_dimension
hex_measure	is upstream_fields of	dbt_metric

Hierarchical Relationships (has parent)

Child Resource	Relationship	Parent Resource
column	has parent	table, dbt_source, dbt_model, dbt_snapshot
table	has parent	database_schema
database_schema	has parent	database
dbt_dimension, dbt_measure, dbt_metric	has parent	dbt_model
dbt_seed, dbt_source, dbt_model, dbt_snapshot	has parent	dbt_project
tableau_published_datasource, tableau_workbook	has parent	tableau_project
tableau_embedded_datasource, tableau_dashboard, tableau_view	has parent	tableau_workbook
tableau_custom_sql	has parent	tableau_embedded_datasource, tableau_published_datasource
tableau_field	has parent	tableau_embedded_datasource, tableau_published_datasource, tableau_custom_sql, tableau_view
looker_dimension, looker_measure	has parent	looker_view, looker_explore, looker_look, looker_tile
looker_dashboard, looker_look	has parent	looker_folder
looker_tile	has parent	looker_dashboard
matillion_pipeline	has parent	matillion_project
powerbi_report, powerbi_dashboard, powerbi_semantic_model, powerbi_dataflow, powerbi_app	has parent	powerbi_workspace
powerbi_table	has parent	powerbi_semantic_model
powerbi_column, powerbi_measure	has parent	powerbi_table
powerbi_page	has parent	powerbi_report
powerbi_tile	has parent	powerbi_page, powerbi_dashboard, powerbi_app
powerbi_dashboard, powerbi_report	has parent	powerbi_app
sigma_workspace, sigma_folder, sigma_data_model	has parent	sigma_account
sigma_folder	has parent	sigma_folder, sigma_workspace
sigma_workbook	has parent	sigma_folder, sigma_workspace
hex_project, hex_semantic_project	has parent	hex_workspace
hex_semantic_model	has parent	hex_semantic_project
hex_dimension, hex_measure	has parent	hex_semantic_model
snowflake_dimension, snowflake_metric	has parent	snowflake_semantic_view

Definition Relationship (has definer)

Source Field	Relationship	Target Field
table	has definer	dbt_seed, dbt_source, dbt_model, dbt_snapshot, fivetran_connector, matillion_pipeline

Membership Relationships (has member / has group)

Source Resource	Relationship	Target Resource
user_account, user_group	has member	user_group, powerbi_workspace
user_group, powerbi_workspace	has group	user_account, user_group

Note:

• Groups can be members of other groups, creating nested hierarchies

• PowerBI workspaces can have both users and groups as members

• Membership relationships may include role information (e.g., Admin, Member) for workspace memberships

Manually adding upstream dependencies in dbt

In addition to standard dbt-inferred relationships, Euno also supports custom dependency declarations via metadata annotations in dbt . Specifically, column-level meta fields in your .yml files can define additional upstream dependencies using the key:

euno.ai/additional_upstream_dependencies

This allows you to declare column-level relationships that are not inferable from SQL lineage. For example, create an upstream relationship from a column to a dbt metric.

Accepted formats

Both of the following are valid, add them to column definition in a .yml file:

meta:
  euno.ai/additional_upstream_depedencies:
    - metric.<metric_name>
    - model.<model_name>

meta:
  euno.ai/additional_upstream_depedencies: [metric.<metric_name>, model.<model_name>]

Supported reference types

Each value in the list should be a string referring to a valid dbt object. The following formats are supported:

Object Type	Format Example
dbt model/seed/source/snapshot	model.<dbt_project_name>.<model_name> or full unique ID
Metric (short form)	metric.<metric_name>
Metric (full unique_id)	metric.<dbt_project_name>.<metric_name>

These references will be parsed and added as additional table_dependencies in the Euno knowledge graph.