On this page
The core idea
Begin with the business concepts and their lifecycles. A learner, course and enrollment are different things even if an early spreadsheet stores them in one row. Separating identity from participation helps avoid duplicated facts and ambiguous updates. The right structure depends on actual read and write patterns, not a desire to normalize every possible detail.
A practical approach
Step 1
List the main entities and give each a stable identifier. Write which facts belong to each entity and which belong to a relationship.
Step 2
Describe the essential questions in plain language, such as ‘which active enrollments belong to this learner?’.
Step 3
Add constraints that express real rules, then review how edits, deletion and historical records should behave.
Worked example
A learner’s email belongs to the learner record, while enrollment date and completion status belong to the learner-course relationship. Storing all of these only on the course row makes multiple learners and repeated enrollments difficult to represent cleanly.
A mistake to avoid
Designing tables directly from a single screen can bake presentation choices into the data model. Screens change; the underlying identity and relationship rules usually need more stability.
Try it yourself
Model a small workshop system with learners, sessions and registrations. Write five queries it must answer and check whether each fact has one clear owner.
Your implementation checklist
- Entities have stable identifiers.
- Relationships carry their own facts.
- Important queries are written down.
- Constraints reflect actual business rules.
Share or cite this guide
Innovate with Ajay Editorial (2026-10-04). Start a Database Schema with the Questions It Must Answer. https://innovatewithajay.com/blogs/start-a-database-schema-with-questions