Publisherintermediate

Data Model: SQL, Sub-Queries & Multiple Data Sets

Explain how BI Publisher data models combine multiple queries, parameters, and linked sub-queries into a single structured XML output.

A single report often needs data from more than one query — a header query for invoice-level detail, a linked sub-query for line items, and perhaps a third independent query for a summary chart — and BI Publisher's Data Model editor is built specifically to compose these into one coherent XML tree. Interviewers ask about this to test whether a candidate understands data modeling for documents, which has different constraints than a typical reporting query.

It's like assembling a family tree document: one query fetches each family (the parent group), and for each family, a second query fetches its members (the nested child group) — the final document naturally shows members indented under their own family, not as one flat, unsorted list of names.

Key Concepts

1
The simplest data model is a single SQL query dataset, but the more commonly tested scenario is a master-detail (linked) query: a parent query (e.g., invoice header) and a child query (e.g., invoice lines) linked by a bind parameter — the child query's WHERE clause references a column from the parent (WHERE INVOICE_ID = :INVOICE_ID), and BI Publisher automatically nests the child's XML output inside each parent row's group, which is exactly the G_INVOICE / G_LINE nested structure referenced in template syntax.
single SQL querymaster-detail (linked) queryWHERE INVOICE_ID = :INVOICE_IDG_INVOICEG_LINE
2
Parameters (report-level prompts like a date range or a specific customer ID) flow into the SQL via bind variables, and can be exposed to end users as a parameter form when the report runs, with List of Values (LOV) queries providing dropdown options. Data models also support combining fundamentally different data set types — a SQL query dataset alongside a web service call dataset or an OBIEE subject area (logical SQL) dataset — merged into the same XML output structure, which is powerful for reports that need to blend a transactional source with a governed RPD metric.
ParametersList of Values (LOV)web service call datasetOBIEE subject area (logical SQL) dataset
3
A nuance interviewers like to probe: the overhead of many separate child queries — a master-detail structure that fires one child query execution per parent row (rather than a single set-based query with an appropriate GROUP BY/JOIN) can be extremely slow for large reports, so an experienced developer prefers a well-joined single query with break groups in the template over naive nested sub-queries whenever performance matters.
overhead of many separate child queries