Two Table DI Sets: Link Tables Through a Common Key

DILR

Some DI sets give you one table and ask a handful of questions. Others give you two tables and expect you to use both at once. The second kind feels harder than it is, because the work is not in either table alone. It is in the join, the moment you carry a number from one table into the other.

That join is where marks are lost. A unit is mismatched, a row is misread, or a figure from the wrong year is multiplied by a rate from the right one. This guide gives you a four step method for linking tables through a shared key, with a worked example whose numbers you can verify line by line.

Why Two Table Sets Feel Harder

With one table, every figure sits in one place and the questions point at rows and columns. With two tables, you must decide how they connect. The connection is rarely stated outright. You infer it from the headings, and if you infer it wrongly, every later answer is wrong in a consistent and confusing way.

The tables are also usually in different units or on different bases. One may give quantities in thousands, and the other prices in rupees per unit. One may list products and the other regions. Without a deliberate check, you will multiply thousands by rupees and quote an answer a thousand times too small or large, without noticing.

The cure is to slow down for thirty seconds at the start, and to treat the setup as a small task in itself. A set with two tables might carry five or six questions. A clean combined table built once will answer most of them quickly, and the thirty seconds pay for themselves many times over.

The Key Bridge: Four Steps

The Key Bridge is a short routine for any set with more than one table. It moves from understanding the structure to building a working table, and only then to answering.

The first step sounds trivial, but keys can be disguised. The same entity may be spelled differently, or abbreviated in one table. Sometimes the key is not a name but a year, or a category such as a product tier. Whatever it is, write it at the top of your rough sheet, so you always know what joins to what.

A Worked Example: Sales and Unit Economics

Here is a set written for practice. The first table gives units sold, in thousands, in three cities: Pune 40, Nagpur 25 and Indore 35. The second table gives, for the same cities, the selling price per unit and the cost per unit in rupees: Pune 300 and 210, Nagpur 280 and 200, and Indore 320 and 250.

The key is the city. The units are thousands in one table and rupees per unit in the other, so any product of the two is in thousands of rupees. Now build the combined table. Revenue is units times price. Pune is 40 times 300, which is 12,000. Nagpur is 25 times 280, which is 7,000. Indore is 35 times 320, which is 11,200. Total revenue is 30,200 thousand rupees.

Profit per unit is price minus cost. That is 90 in Pune, 80 in Nagpur and 70 in Indore. Multiplying by units gives profit: 3,600 for Pune, 2,000 for Nagpur and 2,450 for Indore. The total is 8,050 thousand rupees. Margin on revenue is profit divided by revenue, which is 30 percent for Pune, about 28.6 percent for Nagpur and about 21.9 percent for Indore.

City	Units (000)	Revenue (Rs 000)	Profit (Rs 000)	Margin
Pune	40	12,000	3,600	30.0%
Nagpur	25	7,000	2,000	28.6%
Indore	35	11,200	2,450	21.9%
Total	100	30,200	8,050	26.7%

Once this table exists, the questions are lookups. Which city earned the highest profit? Pune, with 3,600. Which has the lowest margin? Indore. What is the total profit across all three cities? 8,050. Each answer takes a second, and none required returning to the original tables.

The Weighted Average Trap

A very common question asks for the overall margin, or overall growth, across all rows. The tempting move is to average the row percentages. In our example, the simple average of 30, 28.6 and 21.9 is about 26.8 percent. The correct overall margin is total profit over total revenue, which is 8,050 divided by 30,200, or about 26.7 percent.

The two numbers are close here, which makes the error easy to miss. They differ because the cities have different revenues. Pune and Indore carry more weight than Nagpur, and a simple average gives each city equal weight. In another set the gap could be large enough to change the answer option.

The rule is to weight by the base. For a margin on revenue, the base is revenue. For a growth rate, the base is the earlier year's value. For a ratio of two totals, compute the totals first and then divide. Never average percentages across rows unless the bases are equal.

This trap appears in many DI sets, and it is the same logic that underlies questions on growth and CAGR. Our guide on percentage change and CAGR traps in CAT DI covers more of these base errors.

When the Key Is Not Obvious

Real sets are not always as tidy as our example. Keys can be disguised, partial or many-to-one. Handling these cases is a matter of care, not new technique.

If the key is spelled differently across tables, such as a full name in one and a code in the other, list the pairs at the top before doing anything else. If one table has rows that the other lacks, mark them, and decide whether the question needs them. A question about total revenue across all cities needs every city, so a missing row may mean the data is incomplete or that the question is about a subset.

If the key is many-to-one, such as products belonging to categories, you will need to add the product figures within each category before joining. Do that aggregation first, and write the category totals down, so that the join is a simple one-to-one step. Doing both at once is a classic source of errors.

Sometimes the key is time, as when one table gives sales by year and the other gives prices by year. Check that the years line up, including whether one table uses calendar years and the other financial years. A mismatch of one year looks small and changes every answer. Our guide on filling the blanks in tables with missing data shows how to use totals to catch such inconsistencies.

Checking Your Combined Table

A combined table is only useful if it is correct, and a few quick checks will tell you. First, does the total of each column match what you get from the original tables? In our example, the total units, 100 thousand, should match the sum of the first table. Second, do the figures pass a sanity check, such as profit being smaller than revenue in every row?

Third, test one row end to end. Pick a city and recompute its revenue and profit from the raw figures, ignoring your table. If it matches, your method is sound. If it does not, you have found a setup error early, before it spreads. This one-row check takes under ten seconds and is well worth it.

Finally, consider whether the combined table could answer a question you have not yet read. If the set includes a what-if, such as a rise in units in one city, the table lets you adjust a single row. If Nagpur's units rise by 20 percent, from 25 to 30, its profit becomes 30 times 80, which is 2,400, an increase of 400. You did not need to rebuild anything. Our guide on reading combo charts in CAT DI covers a related skill, combining several displays.

Turning the Bridge into a Habit

You will not build a combined table in the exam unless you have done it many times. Take your two-table sets and redo them using the Key Bridge, even those you solved correctly. Time each step, and notice where you hesitate. Most hesitation is at the unit check, which is the step people skip.

Keep a log of your errors by type: key mismatch, unit mismatch, simple average instead of weighted, or arithmetic slip. After a few sets, the log shows which error is yours. Then add a specific check to your routine. If you are prone to unit slips, write the unit in every header. If you favour simple averages, say weighted aloud whenever you see an overall percentage.

If you would like the practice spread evenly over the weeks, a CAT study planner can slot short DI sessions into your calendar, and you can talk to a CAT mentor if you want an experienced reviewer to watch your setup.