Aglet

Triage report totals that may be inflated by join fanout

A report total can increase when one row at the intended grain matches several rows on a joined table. Triage should identify the measure's intended unit, list the relationships in the report path, and compare a small parent-child example before anyone calls the result a duplicate.

Establish what is happening

  1. State the intended grain

    Write what one report row represents and which measure is being summed, averaged, or counted. Capture the grouping fields and a representative identifier so the expected contribution is testable before examining joined detail.

  2. Inspect relationship counts

    For a small sample, count matching rows on each join edge and mark one-to-one, one-to-many, and optional relationships. Compare the base row count with the post-join row count, keeping legitimate line items distinct from repeated parent attributes.

  3. Classify the symptom

    Decide whether the report needs detail-level aggregation, a distinct parent measure, a different join path, or clearer labeling. Record any relationship whose intended cardinality is undocumented instead of assuming the first multiplication is the defect.

What to carry forward

Triage is complete when the intended row grain, join cardinalities, and affected measure are recorded with a concrete example. If the report deliberately counts detail rows, classify repeated parents as expected and focus the case on whether the label explains that meaning.

Technical background: PostgreSQL documentation.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow