Prepare a repeated-key and inflated-total question for a Singapore data workshop

The problem

A Singapore spreadsheet learner merges two tables and sees a total increase even though no new business activity occurred, but cannot explain the repeated rows.

Name what each input row represents

Start with two tiny fictional tables, not a full customer workbook. In the order table, row O01 has an order amount of 30 and row O02 an amount of 40; there is one row per order. In the item table, the rows are O01 with item A, O01 with item B and O02 with item C; there is one row per item in this example. These labels and numbers are invented for explanation. The order identifier repeats in the item table because that table represents a different unit. Put the row meaning beside each table before discussing a tool. “There are duplicates” is incomplete until you can say which records should be unique and which repeated values have a purpose.

Write the intended matching rule before inspecting the result

For this example, suppose you intend to list every item alongside its order amount, matching rows where the order identifiers are equal. State that rule explicitly rather than assuming everyone means the same operation by “merge”. Under that stated rule, O01 matches two item rows and O02 matches one. The expected output therefore has three matched rows, even though the order table has two. If your intended output instead needs one row per order, write that requirement as a separate decision. Ask the facilitator which intermediate result supports it. This guide does not prescribe a SQL join type, spreadsheet function or universal correction; the peer-help question starts with the result you need and the rule you actually used.

Show precisely why the amount looks larger

When the order amount is copied onto each of the three matched item rows in the defined example, the displayed values are 30, 30 and 40. Adding that displayed column gives 100, while adding the two original order amounts gives 70. No new order was added: O01’s amount appears on both of its item rows. Those fixed calculations illustrate a repeated measure at a changed row unit; they are not a diagnosis of your real report. Write both totals, the rows behind them and the decision each total was supposed to support. A facilitator can then discuss whether the amount belongs at order level, item level or another explicitly defined level rather than treating any larger total as proof that every repeated row is redundant.

Count the matching values on both sides

Make a key-count note before selecting a correction. In the fictional inputs, O01 appears once in orders and twice in items; O02 appears once in each. Add a second sample only if it isolates a further question, such as an identifier that repeats unexpectedly in both inputs. Record which repetition is intended and which needs explanation. Data.gov.sg documents public dataset queries and metadata retrieval as practice context, but its API overview does not establish that any field in your chosen dataset is unique. Inspect that dataset’s own description and the rows used in your example. A column name that sounds like an identifier does not by itself establish a matching rule or the correct unit for a report.

• Data.gov.sg API overview ↗ · Source checked 20 October 2026

Keep absent keys as a separate expected-result question

If missing matches are part of the real problem, add a clearly labelled fictional order O03 with no corresponding item row. State what you intend to see: should that order remain visible with an explicit absence, or is this particular result meant to show matched items only? Then record what the actual operation produced. Do not silently convert a missing match into an amount of zero, a cancelled order or proof of bad data. Also distinguish an absent identifier from an empty identifier whose meaning is unresolved. These questions can lead to different implementations. The small example should expose the expected treatment before a peer recommends a query or function whose behaviour might hide the records you need to examine.

Build a peer-help card that someone can reproduce

Keep one card with input rows and row meanings; matching field and rule; expected rows and total; actual rows and total; steps or query used; and the precise unresolved question. For the fixed example, a useful question is: “I want one amount per order, but my item-level output repeats O01’s 30. Which intermediate table should we inspect before summarising?” That is more answerable than asking a stranger to repair an entire dashboard. Use a public or genuinely invented example; any screenshot or input extract must be permitted for this recipient and purpose, beyond simply removing confidential details. Keep the original problem intact while reducing its size. Ask whether the event allows participant examples and whether the facilitator can discuss the relevant tool; neither permission nor individual help follows from a workshop title.

Choose an exercise that exposes the intermediate rows

A session demonstration may show a final chart without explaining the matching result. Look for a beginner query or data-preparation exercise where participants can inspect both inputs, matched rows and the measure being summarised. Ask about assumed skills, supplied tables, setup and the chance to discuss repeated keys. Data.gov.sg’s search-and-filter documentation supports paginated row inspection and query parameters; it is not evidence that a named workshop teaches joins or allows your example. Use the existing first-page retrieval guide if an input is incomplete, and the snapshot guide if input versions changed. Resolving those separate questions avoids blaming the matching rule for a difference that began before the tables were combined.

• Data.gov.sg search and filter within dataset ↗ · Source checked 20 October 2026

Test the explanation before carrying it into the full report

After peer help, apply the proposed interpretation to the same fixed rows and compare it with the expected result you wrote down. Explain which row unit it preserves and what happens to O03 if you included that absent-key case. Retain any unresolved assumptions about key meaning, input completeness or the decision the amount supports. Only then investigate the real workbook through an appropriate authorised process. Do not remove every repeated output row merely because the total becomes smaller. Use Boardzip’s free search for a suitable data session, then verify its actual level, admission and participation conditions. No current workshop place or implemented repair is established here. A reproducible question and an accurately bounded explanation are the intended outcomes.