8.4 Data Matching Across Multiple Tables

Why This Module Matters

The most realistic cross-referencing items do not ask you to search a single list — they hand you two or three separate tables (a name table, a phone table, a plate table, a radio-unit roster) that share no single master database, and ask you to trace one piece of information across all of them to answer a question. This is a direct simulation of real dispatch work: Computer-Aided Dispatch (CAD) systems, Department of Motor Vehicles (DMV) records, warrant files, and radio rosters are typically separate systems that do not share a common backend, so a working dispatcher constantly and manually reconciles them by matching a shared field — a plate, a name, or a call sign — from one table into another.

These items are usually the most time-consuming on the cross-referencing module because they require holding one confirmed fact from the first table in memory (or writing it down) while scanning a second table for the matching field, and sometimes a third table for the final answer. Rushing this process by skimming instead of tracing the exact shared field is the single largest source of wrong answers on this item type.

Core Technique: Anchor on the Rarest Shared Field

When two or more tables need to be joined, the fastest and most accurate approach is to identify which field is most specific — least likely to repeat — and anchor your search there first:

1. Identify the shared field. Find the one column or piece of data that appears in both tables in the same form: a plate number, a call sign, a case number.
2. Anchor on the rarer identifier. If one table is organized by name and has several similar names, and the other table is organized by a unique plate or ID number, look up by the plate or ID first — it has far fewer chances of a false match than a common name does.
3. Carry only the confirmed value forward. Once you have found the correct row in the first table, hold only the exact matching field — not the whole row, and not an approximation of it — into your search of the second table.
4. Watch for one-to-many and many-to-one relationships. A single officer can be assigned two call signs across a shift change, or two different call signs can map to the same officer — this is a deliberate distractor pattern, not an error in the table.

Worked Example Table

Consider a NAME table and a PHONE table used together:

NAME table

PHONE table

Question logic: which name is associated with the phone number 555-118-7734? The PHONE table ties that phone number to plate KTR-402. Scanning the NAME table for KTR-402 — not the similar-looking KTR-204 — shows that the second Delgado row, not Owens, is the correct match. Notice the trap: Owens also carries a plate that begins with the same "KTR-4" pattern, and there are two Delgado rows in the table, so the only safe method is matching the full plate string exactly, not the surname or the first few characters of the plate.

A Second Pattern: Chained (Indirect) Matches

Some items require two hops instead of one — a roster table links a call sign to an officer's name, and a separate status table links that same call sign to a current activity, so you must chain through the shared call-sign field to answer a question about the officer named in the first table. The technique is identical to a single-hop match: find the confirmed value in the first table, then use only that exact value — not an approximation — to search the second table. Skipping straight to an assumed answer without tracing both hops is the most common way these items are missed.

Common Traps in Multi-Table Matching

Takeaways Recap

Multi-table items reward tracing one exact value through every required hop, in order, rather than pattern-matching an answer that merely looks plausible from a quick glance across all the tables at once.