Which scenario most commonly leads to incorrect totals after joining tables?

• A. Joining on a one-to-one relationship without restrictions
• B. Filtering on a non-join field
• C. Joining on a one-to-many relationship without restricting the many side
• D. Using an inner join with accurately defined keys

Answer: (C)

When joining a table that has a one-to-many relationship with another, every row on the “one” side will be paired with all matching rows on the “many” side. If you don’t restrict the many side or don’t aggregate appropriately, those single rows from the one side get replicated as many times as there are matching many-side rows. That replication inflates totals because you’re effectively counting the same one-side value multiple times.

For example, if you have a customers table (one side) and an orders table (many side), joining them without growing the result set to a single total per customer means summing values across the joined rows can double-count each customer’s value according to how many orders they have. To get correct totals, you’d typically aggregate the many-side values first (sum orders per customer) or sum after grouping by the one-side key, or join to a pre-aggregated table.

The other scenarios don’t inherently cause this kind of duplication: a true one-to-one join doesn’t multiply rows; filtering on a non-join field changes which rows are included but isn’t about row duplication; an inner join with correctly defined keys produces precise results. The duplication issue uniquely arises from a one-to-many join without restricting the many side.