Tabular Representation

The tabular view of the semantic model consists of dimensions, simple measures, custom measures, and join relationships.

Dimensions

Dimensions are descriptive attributes of your database that define how columns should be interpreted by Tursio when generating SQL queries from natural language. Setting up dimensions correctly improves the accuracy of query interpretation and ensures meaningful results.

Viewing Dimensions

Users can view the inferred dimensions by choosing a Query Table from the dropdown, as shown in the screenshot below:

Once selected, users can see the list of dimensions in that Query Table along with various attributes (display name, data type, value type, and ontology). For example, an Orders table could have aliases like Purchases or Transactions.

Adding Aliases

Users can add up to 2 aliases for each Query Table. Aliases help the AI understand user queries that reference the table with different terms.

Editing Dimensions

For each dimension, users can configure:

• Display Name: A human-friendly name (e.g., Customer Name instead of cust_nm).
• Alias: Comma-separated alternate names (e.g., buyer, client, shopper).
• Value Type: Defines how the column behaves in queries:
  • Continuous: Numeric values used for aggregations (e.g., Age, Salary).
  • Description: Textual values used for filtering and display (e.g., Name, City).
  • Identifier: Unique values that identify entities (e.g., Employee ID, Order ID).
• Ontology: Adds domain-specific context:
  • ICD Code: For medical classification codes.
  • Uncountable Identifier: Identifiers that should not be aggregated.
  • None: Default, when no special ontology applies.

Best Practices

• Always provide aliases for commonly used synonyms to improve AI interpretation.
• Assign value types carefully — incorrect types may confuse query generation.
• Use ontology only where domain-specific meaning is required.

Simple Measures

Simple measures are numerical columns that support aggregations. These measures allow the system to perform calculations such as sum, average, minimum, and maximum.

Auto-Generated Simple Measures

During training, all columns identified as measure columns in the Query Table are collected as simple measures. These can be further aggregated in queries.

Users can edit simple measures but cannot delete them from the Semantic page. To remove a simple measure, edit the Query Table to unmark the column as a measure — it will then be automatically removed.

Viewing Simple Measures

Users can choose a Query Table to view all simple measures, including the inferred aspect (cost, percent, units, or unknown), currency if applicable (USD, GBP, EUR, INR, etc.), precision, disabled aggregations, alternate names, and aliases.

Editing Simple Measures

Users can edit existing measures to refine their settings or delete irrelevant ones. For each measure, the following can be configured:

• Aspect: Defines the semantic meaning of the measure.
  • UNKNOWN: Default; allows only precision.
  • UNIT: Represents raw values; does not support precision or currency.
  • PERCENT: Requires precision (e.g., 2 decimal places for percentages).
  • COST: Requires currency type (e.g., USD, EUR, INR) and precision.
• Disabled Aggregations:
  • Choose which aggregation functions (SUM, AVG, MIN, MAX, COUNT) are disabled.
  • At least one aggregation must remain enabled.
• Alternate:
  • A unique display name for the measure, distinct from the column name.
• Alias:
  • Comma-separated synonyms for the measure column.

Best Practices

• Use the COST aspect only for financial data where currency is relevant.
• Do not disable all aggregations for a measure — at least one must remain.
• Ensure alternate names are unique across measures for clarity.

Note

Changes to simple measures take effect only after re-training. Re-train the database to apply updates and improve query accuracy.

Custom Measures

Custom measures are derived metrics computed on the fly that do not exist as columns in the database. These measures are created using expressions and provide flexibility for business-specific calculations.

Auto-Generated Custom Measures

During training, all columns detected as ID columns are automatically added as custom measures with the expression: COUNT(DISTINCT <Column_Name>).

Auto-generated measures cannot be deleted from the Semantic page. However, users can set their ontology to non-countable identifier or change their value type to Continuous/Description on the Dimensions page. Re-training will then remove them from custom measures.

Create Custom Measures

Click Add Measure to define a new custom measure. In addition to the fields provided for simple measures, users also need to specify the SQL expression in the dialect of their backend database.

Import from Power BI

If you already use Power BI and have created measures in your reports, you can bring those measures into Tursio without rebuilding them manually.

Step 1: Export from Power BI using DAX Studio

• Open your Power BI report.
• Launch DAX Studio and connect it to the report.
• Click Export Metrics.
• Save the exported file with the .vpax extension.

Step 2: Upload the VPAX File

• Navigate to the Custom Measures page.
• Click the Upload VPAX File icon.
• Select the .vpax file from your system.
• Click Upload.

After saving, Tursio automatically extracts the DAX measures and converts them into custom measures. The imported measures are then added to the relevant query tables.

Step 3: Review Import Status

If some measures could not be imported, you will see how many were skipped along with the option to download a CSV showing the reason for each skipped item. This allows you to review and correct any issues.

Limitations:

• Table Not Found — Measures are skipped if their Power BI table name does not match any table in your Tursio data model.
• Column Not Found — Measures referencing columns that do not exist in the corresponding Tursio table cannot be translated and will be skipped.
• Multi-Table References — Measures that reference multiple tables will be skipped.

After Import:

Run training to make these measures available for querying. After training completes, the measures are incorporated into the semantic layer and can be queried.

Recommendations:

• Review skipped measures to ensure important logic is not missed.
• Re-upload the VPAX file whenever your Power BI measures change.

Edit Custom Measures

Once added, users can modify existing custom measures or remove them if no longer needed. The following fields can be edited:

• Measure Name:
  • A unique name that can be directly queried.
• Aspect:
  • Same as simple measures (UNKNOWN, UNIT, PERCENT, COST).
• Expression:
  • SQL-style expression or formula used to compute the measure.
  • Example: (Revenue - Cost) / Revenue for Profit Margin.
• Alias:
  • Comma-separated alternate names for referencing the measure.

Best Practices

• Always give clear and descriptive names to custom measures for easy discovery.
• Keep expressions optimized — complex nested expressions may slow down query execution.
• Ensure no duplicate measure names exist across simple and custom measures.

Note

Changes to custom measures take effect only after re-training. Re-train the database to apply updates and improve query accuracy.

Join Relationships

Join relationships define how tables are linked together for querying — specifically, how data flows between fact tables and related dimension or lookup tables.

Auto-Generated Join Relationships

As part of training, Tursio automatically infers possible joins from your database schema. These inferred joins are displayed in the Join Relationships tab for review.

Each join includes:

• Fact Table — The main table containing measurable events (e.g., LINEITEM, ORDERS).
• Join Table — The related table being connected (e.g., CUSTOMER, SUPPLIER).
• Primary Key — The unique identifier column in the join table.
• Foreign Key — The corresponding column in the fact table.
• Join Type — The type of join used (commonly LEFT JOIN).
• Status — The current state of the join:
  • Accepted: Join will be used during querying.
  • Rejected: Join will be ignored.
  • Pending: Join is stored for future reference but not used.

Managing Joins

• Accept or Reject: Review inferred joins and mark them as Accepted or Rejected.
• Keep as Pending: If unsure, leave the join in Pending for later review.
• Add New Joins: Create custom joins by specifying the fact table, join table, primary key, foreign key, and join type.
• Edit Existing Joins: Modify inferred joins if the default relationship does not match your data model.

Why Joins Matter

Accepted joins are directly used by the system when building queries. By curating these relationships, you ensure:

• Queries run with the correct table relationships.
• Consistent results across measures and dimensions.
• Flexibility to override or refine automatically detected joins.

Note

Changes to join relationships take effect only after re-training. Re-train the database to apply updates and improve query accuracy.