Exercise 2: Employee ID vs. Country as Lookup Keys — Possible Solution ==================================================================== CLARIFYING THE DIRECTION OF EACH FUNCTION ------------------------------ Both mappings are most naturally read as functions FROM each user TO one of their own attributes: User -> Employee ID, and User -> Country. Every user has exactly one employee ID and exactly one country of residence, so both are genuinely well-defined functions per this chapter's own definition. The question of "looking up the user from the output alone" is then about reversing the function - given just an ID or just a country, can you reliably work backward to the one specific user it came from? (a) USER -> EMPLOYEE ID: INJECTIVE ------------------------------ Employee IDs are unique by design - no two different users are ever assigned the same ID. This is exactly injectivity: different inputs (different users) always produce different outputs (different IDs). PRACTICAL CONSEQUENCE: reliable lookup. Given an ID (the output), there is exactly one user it could have come from, because injectivity guarantees no two users could have produced that same ID. Looking up "the" user from an employee ID alone is always reliable. (b) USER -> COUNTRY: NOT INJECTIVE ------------------------------ Many different users can share the same country of residence - there is nothing preventing two, ten, or a thousand users from all living in the same country. This directly violates injectivity: different inputs (different users) can easily produce the identical output (the same country). PRACTICAL CONSEQUENCE: unreliable lookup. Given a country (the output) alone, there could be many users who produced that exact output - there's no way to determine which specific one you actually meant. Looking up "the" user from a country alone is fundamentally ambiguous, not just occasionally inconvenient - it's a structural property of the mapping itself, true regardless of how the lookup is implemented. WHY THE DISTINCTION MATTERS BEYOND THIS ONE EXAMPLE ------------------------------ This is exactly why a unique employee ID (or any injective attribute) makes a reliable database primary key or lookup key, while a non-injective attribute like country does not - the mathematical property of injectivity is what a "unique key" actually formalizes. WHY THIS WORKS AS AN ANSWER ------------------------------ It states the interpretation of each mapping's direction explicitly to remove ambiguity, checks injectivity for each based on real-world facts about IDs and countries, and explains the concrete practical consequence (reliable vs. ambiguous lookup) that follows directly from each result.