Account
Skip to main content

Business Rules

Business rules in BimlFlex can be modeled as metadata. A modeled table describes how a view is built from other objects, one rule per output column. BimlFlex generates the view SQL from the model, lineage reads the model column by column, and you edit the model one rule at a time with undo.

What a modeled table is​

Without a model, business logic in BimlFlex lives in per-column expressions (a SQL expression and a dataflow expression per column, with a derived flag and a solve order) and in the SQL override fields on the object (Source Create SQL, Create SQL, Override SQL and the From, Join, Where, Select By, Group By and Order By fragments of the load query).

A modeled table adds one kind of metadata. Its inputs are one or more existing objects at any layer, each with an alias. The inputs are combined with joins, filters and grouping. Each output column carries one rule, and a rule is one of seven kinds: pass through, rename, cast, derived expression, aggregate, lookup or constant.

The same model serves source to staging, raw vault to business vault, and warehouse to mart.

The generated SQL is always visible​

BimlFlex generates the view SQL from the model for each SQL dialect. The generated SQL is shown on every modeled table, always, as one statement.

The generator renders three SQL families: the SQL Server family, which covers Microsoft SQL Server, Azure SQL Database, Azure Synapse, Fabric Warehouse and the other platforms that deploy a T-SQL view, Snowflake, and Spark SQL on Databricks. A Spark SQL view deploys the way the framework deploys its Databricks objects, with the catalog name as a session variable on every object name. A modeled table on a Fabric Lakehouse connection reports a dialect the generator does not support, because no Fabric Lakehouse view deploy exists.

BimlFlex writes the generated SQL into Source Create SQL, the field where a hand-written view's SQL goes, exactly as the Dimensional Accelerator writes its published views. The build, the accelerators and every other consumer read it as they read a hand-written view. The fields are described in the SQL overrides section of the Object editor.

BimlFlex records whether a modeled table's SQL is still the unaltered generated default, and the editor shows it as Generated or Hand-edited.

Three ways to reach the bare metal​

You can always reach the bare metal, and all three ways stay inside the model:

  • A SQL fragment on a rule. Any column, join or filter can carry a SQL fragment you write, with its inputs named by alias. BimlFlex parses the fragment for the columns it names and marks it hand-written in lineage. The fragment is resolved before the statement is written, so the SQL you read is the SQL that deploys.
  • A trailing SQL step. A SELECT over the generated view, applied as the last step of the construction and bound to the view's columns by name, never by position. Its output is parsed back so lineage continues, and every rule it supersedes is flagged.
  • A fork. The whole generated SQL taken as a hand-edited view, seeded from the last generate and yours from then on. The rules stay beside it with their last SQL, with a diff and a return to rules.

Nothing is locked, nothing is wiped when the SQL is generated again, and nothing is read only.

Lineage reads the model​

In the model-wide lineage, a modeled table's output column has one rule edge for each source column its rule reads. The edge is labeled with the rule kind, followed by hand-written when the rule's SQL is written by hand, and carries an fx mark only when the rule carries an expression. The edge's tooltip reads the kind, the hand-written mark and the expression, and the text trace shows the same kind and hand-written chips. The per-object lineage reads the same records beside the authored mappings, with the modeled table's inputs as its parents.

BimlFlex parses every hand-written fragment, trailing step and fork once, when the object is saved, and stores the resolved column references on the rule. A parse miss is stored on the exact rule it belongs to. Lineage reads the stored references and never parses SQL itself.

An existing hand-written view keeps its SQL byte for byte. Where the parser reads its column references, the view gains column lineage marked hand-written. Where it does not, the view stays exactly as it is. A rules coverage chip on the model-wide lineage's toolbar counts the hand-written views, the views parsed with column lineage and the views carrying misses, and opens a report with one row per view, and a miss is reported, never raised as an error. See Data Lineage.

Reusable rules​

A rule library holds named rules for reuse. A library rule carries placeholders and a matching condition on data type, and you apply it across many columns.

When a library rule changes, the change propagates to the columns it is attached to, and a report names every column it could not update. Any column can detach from its library rule and keep an expression of its own.

Proposing rules with AI (Preview)​

Two AI verbs work on the model. Propose a rule set drafts a modeled table from imported metadata, and Critique this rule set proposes changes to an existing one.

A proposal is one table shape with the column rules grouped under it. You accept or skip each rule, one at a time, and Accept all reviewed accepts the group. A deterministic generator writes the code from the accepted rules, so no model-written SQL reaches the build unaccepted. A fragment the AI proposes is flagged as AI-proposed and parsed at save like any hand-written fragment.

The verbs carry the Preview label, are off in the no-AI configuration and sit behind the per-customer consent. The rules layer itself has no AI dependency.

Where the records live​

The records of a modeled table live in the database store and the file store alike, as children of the View object: a header record for the table and a rule record for each output column. In the file store they are readable text inside the View object's document, identified by name, so they diff and merge in Git. See File-Mode Metadata.

The BimlFlex Metadata MCP Server reads the same records, proposes changes to them through its guarded write path, and renders the same SQL for a file-mode store. See Metadata MCP Server.

Licensing​

Generating, applying and previewing the SQL of a modeled table need a license that covers the capability. Without it, the editor shows the unlicensed state the way build and preview do. The records and the generated SQL already written stay readable.

What does not change​

The SQL override fields keep their meaning for every object. A modeled table writes its generated SQL into Source Create SQL, and a fork is a state of the modeled table, never a use of another override field.

An object without a rules model builds from its SQL override fields alone, and every field keeps its meaning for it. To work with the rules of a modeled table, see the Rules Editor.