ER Diagrams and Schema Design
Visualizing and Structuring Your Database

Introduction

Every successful database starts with a smart plan. Think of it like designing the blueprint of a school building — classrooms, staff rooms, corridors — everything must connect sensibly. In the world of data, that blueprint is called an ER Diagram (Entity Relationship Diagram), and its translation into tables is known as schema design.

What is an ER Diagram?

An ER Diagram is a visual representation of entities (real-world objects like Student or Teacher), their attributes (like name, marks), and the relationships between them. It helps you understand how your data fits together — before you start coding tables.

Core ER Diagram Elements

• Entity: Object or concept (e.g., Student)
• Attribute: Property of the entity (e.g., name, roll_no)
• Primary Key: Uniquely identifies each entity (e.g., roll_no)
• Relationship: Association between entities (e.g., "enrolls in" between Student and Course)

Example: School Database

Let’s design a simple school system with the following:

• Student (roll_no, name, class)
• Subject (subject_code, name)
• Marks (roll_no, subject_code, marks)

ER Diagram (conceptually):

- Student --enrolled_in-- Subject - Marks is a relationship table that connects them and stores additional data (marks).

Step-by-Step Schema Design

1. Student Table

CREATE TABLE students (
  roll_no INT PRIMARY KEY,
  name VARCHAR(50),
  class VARCHAR(10)
);

2. Subject Table

CREATE TABLE subjects (
  subject_code VARCHAR(10) PRIMARY KEY,
  name VARCHAR(50)
);

3. Marks Table (Many-to-Many relationship)

CREATE TABLE marks (
  roll_no INT,
  subject_code VARCHAR(10),
  marks INT,
  PRIMARY KEY (roll_no, subject_code),
  FOREIGN KEY (roll_no) REFERENCES students(roll_no),
  FOREIGN KEY (subject_code) REFERENCES subjects(subject_code)
);

Entity-Relationship Mapping Summary

Entity	Mapped Table	Relationship
Student	students	1-to-many with marks
Subject	subjects	1-to-many with marks
Marks	marks	Associative entity between student & subject

Normalization Review

• All tables are in 1NF – atomic values only
• 2NF – no partial dependencies in composite keys
• 3NF – no transitive dependencies

Common Design Mistakes to Avoid

• Storing multiple subjects in one field (violates 1NF)
• Repeating student name in the marks table (redundancy)
• Missing foreign key constraints (data inconsistency)

Real-World School Extensions

You can expand this design by adding:

• Teachers table (with subject_code as FK)
• Attendance table (roll_no, date, status)
• Exams table (term_name, date_range)

Visual Tools for ER Diagrams

• dbdiagram.io
• DrawSQL
• MySQL Workbench (visual design + schema generation)

Summary

ER Diagrams are the heart of any well-designed database. They help you visualize the structure before you write a single line of SQL. Combined with normalization, they prevent confusion, enforce clarity, and pave the way for future scaling. Whether it's a small school app or a large university portal — solid design begins with a great schema.

What’s Next?

Coming up: SQL Best Practices — real-world habits and tips to write cleaner, safer, and more efficient SQL code.