BAs who understand data think differently. They ask better questions in requirements sessions, spot inconsistencies in stakeholder explanations faster, and write tighter acceptance criteria for data-driven features. You don't need to write code or build dashboards — but you need to read and reason about data with confidence.

Common BA–data intersection points:

• Defining data requirements for new features (fields, format, validation rules)
• Reviewing data models to check that the solution covers all business scenarios
• Questioning metrics in business cases ("where does this number come from?")
• Validating test data against real-world distributions
• Writing acceptance criteria for reports and dashboards

Key concepts to understand:

• Table: A structured collection of records (the "Customers" table has one row per customer)
• Primary key: The unique identifier for each row (CustomerID). Every table has one.
• Foreign key: A reference to a primary key in another table — creates the relationship between tables
• Null / Not Null: Whether a field can be blank. A Not Null constraint is a business rule embedded in the database

BA question when reading a schema: "Are the relationships between tables correct? Can an order exist without a customer?" These are business rules — and schema mismatches are a common source of production defects.

For any story that involves data, add explicit acceptance criteria for:

• Format: "Email addresses must be validated as name@domain.extension"
• Completeness: "All mandatory fields (marked with *) must be completed before submission is enabled"
• Validation: "Dates of birth must be in the past and within 120 years"
• Error handling: "If validation fails, display a specific error message adjacent to the failing field"