Problem
A database is only useful when its structure reflects the business accurately. Poor entity boundaries, duplicated data or weak integrity rules create reporting and operational problems later.
Selected database coursework demonstrating how I turn business rules into entities, relationships, integrity constraints and queryable SQL structures.
University work · Public summary, assessed artefacts not reproducedVisual concepts covering data modelling, business rules and checking relationships. Illustrative examples, not a reproduction of assessed work.
Illustrative project visuals are available with JavaScript enabled. The case study below remains fully accessible.
A database is only useful when its structure reflects the business accurately. Poor entity boundaries, duplicated data or weak integrity rules create reporting and operational problems later.
I worked through conceptual modelling, normalisation, relational design and SQL implementation with an emphasis on connecting database decisions to the business use case.
Identify entities, keys, relationships and cardinality from business requirements before writing queries.
Use normalisation and relational constraints to reduce duplication and keep stored data consistent.
Write SQL that retrieves and combines data in forms that support operational questions and reporting.
This work supports my analyst profile because it helps me discuss data structures with technical teams while still reasoning from business entities, rules and reporting needs.