Best Practices for Making Legacy Data Semantic and AI-Ready

Overview

Foreign keys are useful evidence because they reveal where one table, record, or object depends on another. However, many legacy systems have weak, undocumented, partial, or application-enforced relationships that do not appear as formal database constraints.

Relationship discovery should therefore inspect more than foreign keys. Candidate relationships can be discovered from join tables, shared codes, API contracts, event logs, lineage, application configuration, reports, dashboards, workflow definitions, business rules, data steward knowledge, and AI-assisted inference.

The important distinction is that discovery does not equal approval. A discovered relationship is only a candidate until the Ontology defines what it means, which predicate describes it, which direction matters, and whether it belongs in the governed Semantic Layer.

Figure: Relationship Discovery Sources shows that semantic relationships can be discovered from many technical and business evidence sources, not just foreign keys, and converted into governed Subject–Predicate–Object relationships.

Technical clue: ORDER.CUSTOMER_ID -\> CUSTOMER.CUSTOMER_ID

Candidate relationship: Order relates to Customer

Approved semantic relationship: Order was placed by Customer

Inverse relationship: Customer placed Order

Examples

The following illustrate this step in practice.

Example 1: A team discovers that an application uses a database by combining connection strings, configuration files, query logs, and a database administrator’s confirmation.

Example 2: A customer-to-product relationship is inferred from shared identifiers in orders, billing records, and support tickets, then validated by a business steward before publication.

Best Practice

Use foreign keys, join tables, and existing join logic as evidence for candidate Semantic Relationships, but do not treat them as complete semantic meaning.

Benefit(s)

This preserves the value of legacy relational design while preventing AI from inferring business meaning from technical joins alone. The enterprise gains a practical starting point for relationship discovery without confusing connectivity with semantics.

Best Practice

Inspect non-foreign-key sources such as APIs, event logs, lineage, reports, dashboards, workflow definitions, application configuration, shared codes, business rules, and steward knowledge to identify additional relationship candidates.

Benefit(s)

This captures relationships that legacy databases often hide or enforce outside the schema. AI receives a richer map of real business connections instead of a narrow map of formal database constraints.

Best Practice

Require every approved Semantic Relationship to have a descriptive predicate, direction, source evidence, approval status, and relationship governance owner.

Benefit(s)

This turns relationship discovery into governed meaning. AI can traverse approved relationships with clearer context, and stewards can audit where the relationship came from and why it is valid.

Best Practice

Use AI to assist relationship discovery, but require Ontology-based review before inferred relationships are accepted.

Benefit(s)

AI can accelerate discovery by finding repeated patterns, hidden joins, naming similarities, and likely predicates. Governance prevents inferred relationships from becoming authoritative merely because a model suggested them.