The semantic layer: understanding a database it has never seen

Demo databases are tidy. Real ones are not. The table that holds revenue might be called tbl_acct_2; the column that means “net amount” might be amt3; a status might be a single flag whose meaning lives only in a developer’s head from six years ago. Point a naive assistant at a schema like that and it will guess — and guess wrong.

Meaning, layered on top

iDBQuery builds a semantic layer over your raw schema: a map from cryptic names to business concepts. It learns that amt3 is net revenue, that a flag of 3 means “refunded”, that two tables that look unrelated actually join on a customer key. That knowledge comes from several sources — what it can infer from the data, what your documentation says, what a glossary defines, and corrections your team makes — and it is merged by provenance, so a human’s definition always outranks a guess.

With that layer in place, “net revenue by region last quarter” resolves to the right tables, the right columns and the right join the first time — even though none of those words appear in the schema.

It gets smarter as you use it

When someone clarifies what a field means or fixes a wrong assumption, the correction is remembered and reused. The semantic layer is not a one-time setup step; it is an asset that compounds, turning a database only one engineer understood into one the whole team can ask questions of.

This is the quiet difference between a toy and a tool. Anyone can answer questions about a clean schema. Answering them against the messy, real, undocumented schema you actually have is the hard part — and the part that matters.