Explore Employee and Session Audit Tables Before Analysis

# Explore Employee and Session Audit Tables Before Analysis You are given an `employee` table with `org`, `country`, `employeeid`, and `name`, and an `audit_events` table with `session_id`, `user_id`, `event_timestamp`, and `session_name`. Before calculating session metrics by organization, explain how you would explore these tables and establish a trustworthy analytical dataset. Discuss duplicates, missing values, timestamp coverage, organizational and country categories, and the meaning of sessions. Explain how each check can change your analysis. The relationship between `employeeid` and `user_id` and the exact session-duration definition must be confirmed rather than assumed. You may describe checks conceptually; no particular query output is required. ### What a Strong Answer Covers - The grain and candidate keys of both tables, including legitimate repeated session events. - Missing-value, duplicate, timestamp-range, and category checks tied to the session analysis. - Validation of the proposed employee-to-audit join and its cardinality. - Clarification of session boundaries, duration, organization history, and incomplete observation windows. - Concrete decisions about invalid records without silently dropping or multiplying observations. ```hint Inspect the join before the average If one employee identifier matches several employee rows, each session may be replicated before any metric is calculated. ``` ### Follow-up Questions - Why is a repeated session_id not necessarily a duplicate audit row? - How could an employee moving organizations change historical session metrics? - What would you need to know before interpreting a one-event session's duration?