Skip to main content

Every table on one page, every column with its roles

A table's semantic layer used to be spread over four tabs — Keys, Dimensions, Measures, Metrics — that each listed the same columns from a different angle. The Tables section of a connection now opens on a table tree, and each table is a page with one list of its columns and what each of them means.

The table tree​

Open a connection in Settings → Admin → Data and pick Tables: the rail becomes the connection's tables, grouped by schema or dataset with the primary one first. Each entry shows at a glance whether dbt governs it, how many issues it has, whether it is a Virtual flatten model, and a blue dot while it carries unsaved edits. Search the tree to jump to a table.

The column list​

A table page starts with its identity — name, display name and description edited right there, and where its definitions come from — then lists every column with:

  • Type — the warehouse's own type, not a normalized one.
  • Role — primary key, foreign key and the table it points at, dimension (with its geography, or for a time column its primary-axis status and grains), and how many measures aggregate it. Hidden columns read as Hidden.
  • Display name & description — what users see in field pickers.
  • Source — Generated, Edited, Custom or dbt.

Fields computed rather than read from a column — expression dimensions, count-of-records and expression measures — sit under Derived at the bottom. Filter with All · Keys · Dimensions · Measures · Derived · Hidden, or search.

Editing still happens in the Keys, Dimensions, Measures and Metrics tabs beside Columns; the column list follows your edits live, before you save. A column-by-column inspector is next.

📖 Semantic layer overview · Keys and joins · Dimensions and measures