Theory
Designing where the data lives
Almost every project stores data, students, events, orders, records, and how you organise that data hugely affects whether the project works well. Get it right, and everything is consistent and easy to query; get it wrong, and you fight duplication and inconsistency forever.
Database design is planning this structure, and the classic tool is the entity-relationship (ER) diagram, which you learned in DBMS. This lesson applies it to your project: identifying the entities, their attributes, and the relationships between them, to produce a clean data blueprint before you create a single table.
Theory
Entities, attributes, relationships
An ER diagram models your data with three ingredients.
Entities are the things you store data about, the nouns of your system: Student, Event, Registration. Each becomes (roughly) a table.
Attributes are the properties of an entity: a Student has a name, email, and id; an Event has a title, date, and venue. Each entity needs a primary key, a unique identifier (like a student id).
Relationships connect entities: a Student registers for an Event. Relationships have cardinality, one-to-one, one-to-many, or many-to-many, describing how many of one relate to how many of the other (a student can register for many events; an event has many registrations).
Draw these from your requirements, and you have your data structure mapped out.
Formula
Normalise to avoid duplication
A key goal of good database design is to reduce redundancy, avoid storing the same data in multiple places. This is what normalisation (from DBMS) achieves: organising data so each fact lives in one place.
Why it matters: if a student's email is duplicated across many rows and they change it, you must update every copy, and if you miss one, the data becomes inconsistent (which is now correct?). By storing each piece of data once and linking with relationships (keys), you keep it consistent and easy to maintain. So design your entities and relationships to hold each fact once. A clean, normalised design prevents a whole class of bugs before you write any code.
Quiz
In an ER diagram for your project, what does an 'entity' represent?
- The colour scheme of the user interface
- A thing you store data about (like Student, Event, or Registration), with attributes and a primary key
- The speed of the database
- A single function in the code
Show the answer
A thing you store data about (like Student, Event, or Registration), with attributes and a primary key
In an ER diagram, an entity represents a thing you store data about, such as Student, Event, or Registration, and it has attributes (its properties, like name and email) and a primary key (a unique identifier). Option A, the UI colour scheme, is a design/UX matter, not a data entity. Option C, database speed, is a performance (non-functional) concern, not what an entity is. Option D, a single function, is code logic, not a data entity. Entities are the 'things' (nouns) your system stores information about; attributes describe them, and relationships connect them, together forming your data blueprint.
Think first
Why design the database with an ER diagram before creating any tables?
You could just create tables as you go. Why model the data with an ER diagram first? Then tap.
Show the answer
Because the database is the FOUNDATION your whole application is built on, and mistakes in its structure are extremely costly to fix later, so modelling it carefully with an ER diagram first, before creating tables and writing code against them, prevents deep, painful problems. Think about how central the data structure is: almost every part of your application reads from and writes to the database, so once you have created tables and built code, forms, queries, and features, that depend on their structure, changing that structure means changing everything connected to it. If you created tables ad hoc as you coded and later discovered the design was flawed, missing a needed entity, tangled relationships, data duplicated everywhere, you would face a massive, error-prone reworking of both the database AND all the code that uses it, often late in the project when you can least afford it. An ER diagram lets you think through the data design UP FRONT, on paper (or a diagram tool), where changes are free: you can see all the entities and relationships at once, spot missing or wrong connections, decide primary keys, and normalise to remove duplication, all before committing anything to code. This produces a clean, consistent structure that supports your requirements and avoids the redundancy that causes inconsistency bugs. It also gives the team a shared, clear picture of the data (essential when several people build different parts), and it becomes documentation for your report and presentation. The ER diagram is, in effect, the blueprint of your data, and just as you would not pour a building's foundation without a plan, you should not create your database without designing it, because everything else rests on it. Model the data first, get the foundation right, and the rest of the project stands on solid ground. Design the data before you build on it.
Summary
Key takeaways
- Database design plans how your project stores data; the entity-relationship (ER) diagram is the tool for it (from DBMS).
- Entities are the things you store data about (Student, Event, Registration), each with a primary key.
- Attributes are an entity's properties (a Student has name, email, id).
- Relationships connect entities (a Student registers for an Event) with cardinality (one-to-one, one-to-many, many-to-many).
- Normalise the design to reduce redundancy, storing each fact once, so data stays consistent and maintainable.
- Design the ER model from your requirements before creating tables, because the database is the foundation everything rests on.
- Memory hook: entities (things), attributes (properties), relationships (links); model with an ER diagram, normalise, then build.