DW Generator

Purpose#

The DW Generator inspects source tables you select, classifies each one as a fact, dimension, bridge, or junk table, and emits warehouse DDL for the target engine you choose. It is a design aid: it produces SQL for you to review and run yourself. It does not create anything in your warehouse, and it does not move data.

Note. Abrq DIP ships no AI model and sends nothing to a vendor service. The generator works entirely from schema introspection. If you configure your own AI provider (see AI model providers), the generator can additionally use it to suggest a restructure — that call goes to the endpoint you configured, under your credentials.

Prerequisites#

The three-step wizard#

Open DW Generator AI in the left navigation (/dw-model).

Step 1 — Target#

Choose the source connector, the target database name, and the target engine.

Note. The target-engine list is wider than the set of engines Abrq DIP can load data into. Generating DDL for Snowflake or SQL Server is supported here because the output is SQL you run yourself.

Step 2 — Select source tables#

The generator pulls the table list from the source connector. Select the tables to model.

• At least one table is required: selecting none fails with no tables selected — pick at least one source table on step 2.
• The ceiling is 100 tables per model. Beyond that you get too many tables selected (N). Limit is 100; split into multiple DW models if you need more. The cap exists so an accidental "select all" cannot hold the source connection open for minutes.

Step 3 — Generate and review#

The generator introspects each selected table, classifies it, and emits DDL. Every table lands in one of four buckets:

You get a roll-up (for example "5 facts, 12 dimensions") plus the per-table detail, and you can override any individual classification before the DDL is finalised — the generator's guess is a starting point, not a verdict.

Review the emitted DDL and run it against your warehouse yourself. Abrq DIP never executes it.

Optional: AI-assisted restructure#

If an AI provider is configured, you can ask it to propose a different model — typically merging or splitting tables and re-classifying them. The proposal comes back as classification overrides, which flow through the same review step above.

Operational notes:

• The request goes to your configured provider endpoint with your credentials. No Abrq-hosted inference exists.
• ABRQ_AI_REQUEST_TIMEOUT_SECONDS (default 120) is the only AI-related environment variable — raise it if you run a slow on-premises model. See Environment variables.
• Outbound requests are subject to the egress rules in Transport and egress: a provider on a private address is blocked unless you allow-list its host.

Failure modes#