Metadata import with interface tables

The SQL crawling strategy supports an interface tables pattern: you map rows from source tables or views to Blindata resources by writing SELECT queries whose column aliases match the expected schema. Unlike the JDBC driver strategy—which reads standard JDBC metadata—the SQL strategy lets you source metadata from any queryable structure: operational schemas, staging tables, lineage repositories, BI tool databases, or custom views built for governance.

Instead of inserting rows into fixed staging tables in a repository, you point each extraction query at the tables that already hold (or can expose) the metadata, and the agent uploads the result set on each run.

Note

Interface tables apply to the SQL strategy only. For JDBC-native catalog extraction, see Import Metadata with SQL or JDBC .

When to use interface tables

Use SQL crawling when you need to:

  • Document a system without a native connector — custom applications, APIs materialized as tables, file catalogs, or legacy platforms
  • Automate metadata loading — generate or refresh metadata from scripts, ETL jobs, or CI/CD pipelines on a schedule
  • Combine metadata from multiple tools — merge catalog, lineage, and glossary mappings into one Blindata system
  • Import external lineage — load dataflows that involve objects outside standard catalog views
  • Enrich catalog assets — attach custom properties or semantic links already maintained upstream

For systems with a standard INFORMATION_SCHEMA (or equivalent), default SQL queries often work out of the box. Interface tables become essential when metadata lives elsewhere.

How it works

  1. Prepare the source — ensure metadata is available in queryable tables or views (your own interface schema, a vendor repository, or catalog views).
  2. Configure extraction queries — on the system CRAWLING tab, create a job with strategy SQL and write one query per resource type you want to import. Each query’s result columns must use the aliases documented for that type.
  3. Run or schedule the job — the agent executes the queries against the target connection and uploads the results to Blindata. Use TEST to verify row counts before the first full import.

On each run, objects are matched by their natural keys (for example, schema + name for physical entities, scope + name for dataflows). Rows that cannot be reconciled with existing catalog assets are discarded. If Automatic cleanup is enabled, resources not updated within the configured window can be removed (optionally scoped to a specific dataflows scope).

For the UI walkthrough of the crawling tab, see Automated Metadata Crawling .

Query types

Each optional query on a SQL crawling job maps to a class of Blindata resources:

Extraction query Blindata resources imported
Tables Query Physical entities (tables, views, reports, files, etc.)
Columns Query Physical fields
Physical Constraints Query Primary keys, foreign keys, unique constraints, indexes
Tables / Columns Additional Properties Query Custom key/value metadata on entities and fields
Routines Query Stored procedures and functions
Data Flows Query Dataflows (system, entity, or field level)
Physical entities / fields semantic links query Links from catalog assets to business glossary concepts and attributes

Column aliases, mandatory fields, database-specific examples, and reconciliation rules for each query type are documented in Import Metadata with SQL or JDBC .

Updated on 13 Jul 2026