Relationships
The Relationships tab shows the connections between tables that Lakehousecat uses to build joins — in the semantic layer, in generated SQL, and in the Datasource Map. Most relationships are detected automatically during semantic extraction, but you can also curate them by hand: correct a wrong connection, add one the automatic process missed, or lock one you've verified.
Available to Builder and Administrator roles. End Users cannot access this tab.
What a Relationship Is
A relationship connects a column in one table to a column in another — the same thing a foreign key represents in a relational database, whether or not the source database actually declares it as one. Lakehousecat detects relationships two ways:
- From the source schema — actual foreign keys declared in the connected database.
- Statistically — during semantic extraction, by analyzing value overlap and naming patterns between columns across tables.
Both kinds appear in the list, alongside any relationship you add manually.
Managing Relationships
Adding a Relationship
- Click Add Relationship.
- Select the two tables and the column in each that connects them.
- Set a strength — how confidently this relationship should be treated as a real connection.
- Save.
A manually added relationship is treated the same as a real foreign key — it can be used to build joins in generated SQL and in the semantic model. If it connects the wrong columns, it can produce misleading results, the same way linking unrelated data sources into one Custom Model can. There is no confirmation step for this — as a Builder or Administrator, you're trusted to know the relationship you're describing is correct.
Editing a Relationship
You can change a relationship's strength after creating it. The two tables and columns it connects cannot be edited — they are the relationship's identity. To connect different columns, delete the relationship and add a new one.
Removing or Deactivating
- Manually added relationships can be deleted outright.
- Automatically detected relationships are deactivated rather than deleted — this prevents the next semantic extraction from silently recreating them. Deactivated relationships stay visible in the list and can be reactivated at any time.
The delete confirmation text differs depending on which kind you're removing, so it's always clear whether the action is reversible.
Confirming
An automatically detected relationship that you have checked can be confirmed: click Confirm on its row. The relationship becomes Manual, so later semantic extractions can no longer change or discard it, and Lakehousecat marks the connecting column as a foreign key that you curated. Which side holds the foreign key is derived from the data; if the data cannot tell, the relationship is confirmed without a foreign key.
Views inherit the foreign key only after the next semantic update and model update — Lakehousecat reminds you of this after confirming. There is no way to un-confirm; to withdraw a confirmed relationship, delete it.
Locking
Locking freezes an automatically detected relationship's strength so future semantic extractions can't overwrite it — use this once you've reviewed and confirmed one is correct.
Manually added relationships have no lock option: automatic extraction can never modify or remove them in the first place, so a lock would have no effect. The list marks them instead with a Manual badge.
State Badges
| Badge | Meaning |
|---|---|
| Manual | Added by a Builder or Administrator — protected from automatic changes |
| Foreign Key | Declared by the source database's schema |
| Locked | An automatically detected relationship whose strength is frozen |
| Inactive | Deactivated — excluded from joins, SQL generation, and the map until reactivated |
| Missing | The table or column it points to no longer exists (see below) |
When a Table or Column Disappears
If a manually curated relationship points at a table or column that's no longer part of the schema — for example after a filter change or a source-side rename — the next semantic extraction flags it Missing rather than deleting it. A missing relationship is excluded from joins, SQL generation, and the map, but stays visible with an option to fix or remove it.
If the table or column comes back (the rename is reverted, or the filter is widened again), the next semantic extraction clears the flag automatically and the relationship becomes active again without any action on your part. A transient schema change never permanently discards curation work.
Relationships and the Datasource Map
Adding, editing, or deactivating a relationship marks the Datasource Map as outdated — it does not rebuild automatically on every change. Open the Map tab and use Refresh to rebuild it against the current set of relationships.
Best Practices
- Review automatically detected relationships after the first semantic extraction and deactivate any that connect the wrong tables.
- Add relationships the automatic process didn't find, especially ones that depend on business knowledge not visible in the schema itself (naming conventions, undeclared foreign keys, cross-domain links).
- Lock relationships you've verified so they survive future re-extractions unchanged.
- After curating relationships, refresh the Datasource Map to confirm the change looks the way you expect before relying on it for chart generation.