Field Lineage

Field lineage helps answer where a column comes from, where it is used, and what a change might affect. DBX combines database metadata with local query history and labels evidence strength instead of treating every matching name as a confirmed dependency.

Open Lineage

Open field lineage from a column node, table structure, or related context menu. The active column becomes the target, and results list related tables, columns, views, or historical SQL.

Relationship Sources and Confidence

Source	Default confidence	Meaning
Foreign key	Certain	The database declares a constraint between the current and target columns
View definition	Likely or possible	Confidence is higher when view source references both the target table and column
Query history	Likely or possible	Historical SQL is stronger evidence when both table and column are present
Same-name column	Possible	Name-based inference only and requires business confirmation

The UI distinguishes Certain, Likely, and Possible. Filter lower-confidence results to focus on foreign keys and explicit source references first.

Search and Filters

Search tables, columns, views, or SQL fragments
Filter by confidence
See displayed and total relationship counts
Copy table or column names
Open target table data or structure
Reveal the related object in the tree

Lineage loads foreign keys, view source, and related metadata according to database capability. Initial analysis can take time in large schemas.

Query History as Evidence

DBX uses executed queries as supporting evidence, including:

Fields that appear together in a JOIN
Target columns referenced in WHERE, SELECT, or expressions
Historical repair or reporting SQL that uses a matching field

History only represents SQL executed or saved in DBX. It does not cover all application code, ETL, BI, or other clients.

Query history can contain sensitive table names, predicates, and literals. Review privacy before demonstrating lineage, exporting logs, or sharing screenshots.

View and Source Analysis

View relationships use definitions returned by the database. Confidence can be lower with:

Dynamic SQL or generated procedure text
Ambiguous tables or columns without explicit schema
SELECT *, complex subqueries, or vendor extensions
Databases that do not return complete view source

Open a view result and inspect source in Object Browser for manual confirmation.

Workflows

Before Changing a Column

Review confirmed foreign-key relationships
Inspect likely views and historical SQL
Validate possible same-name relationships with business context
Continue searching application repositories, ETL, and BI assets
Use Schema Diff to review target-environment changes

Understanding an Unfamiliar Database

Start with primary keys, business identifiers, user IDs, or time columns and follow related tables and views. Column comments and object source are usually stronger evidence than name matching alone.

Support and Boundaries

Lineage requires foreign keys, view source, or parseable query history, so coverage varies by database
Without declared foreign keys, DBX can only provide view, history, and same-name clues
Results are not a strongly consistent data-governance graph and do not include every application, message flow, ETL, or BI system
Deleting history or clearing local data reduces the query-history source
Use the Database Support matrix for current engine coverage

Important schema changes still need database constraints, source review, application-code search, and business-owner confirmation. Lineage narrows the investigation; it does not replace impact analysis.