Database Fundamentals & ER Model
Introduction to DBMS, ER diagrams, relational model, and schema design
Database Fundamentals & ER Model
Databases are organized collections of data that allow efficient storage, retrieval, and management of information. This module covers foundational concepts essential for CUET PG and data engineering roles.
What You'll Learn
| # | Topic | Skill |
|---|---|---|
| 1 | Database Concepts | DBMS vs File System, data independence |
| 2 | ER Model | Entities, attributes, relationships |
| 3 | EER Model | Generalization, specialization, aggregation |
| 4 | Relational Model | Tables, keys, constraints |
| 5 | Schema Design | ER to Relational mapping |
1. Introduction to Databases
What is a Database? A database is an organized collection of structured data stored electronically. A Database Management System (DBMS) is software that manages this data.
DBMS vs File System:
| Aspect | File System | DBMS |
|---|---|---|
| Data Redundancy | High | Minimal (controlled) |
| Data Integrity | Manual enforcement | Automatic constraints |
| Concurrency | No support | Built-in support |
| Security | OS-level | Fine-grained access control |
| Data Independence | None | Logical & Physical |
| Recovery | Manual backups | Automatic crash recovery |
Three-Schema Architecture:
External Level (View Schema)
↓ Logical Data Independence
Conceptual Level (Logical Schema)
↓ Physical Data Independence
Internal Level (Physical Schema)
- External Schema: User views, customized for different users
- Conceptual Schema: Logical structure of entire database
- Internal Schema: Physical storage structure
Data Independence:
- Logical: Changes to conceptual schema don't affect external views
- Physical: Changes to physical storage don't affect logical schema
2. Entity-Relationship (ER) Model
ER Model is a high-level conceptual data model used to describe the database structure graphically.
Core Components:
┌─────────────────────────────────────────────────┐
│ ER DIAGRAM SYMBOLS │
├─────────────────────────────────────────────────┤
│ ┌───────┐ │
│ │ │ Rectangle = Entity │
│ └───────┘ │
│ │
│ ○ Ellipse = Attribute │
│ │
│ ◇ Diamond = Relationship │
│ │
│ ___ Underline = Primary Key │
│ │
│ (-) Dashed Ellipse = Derived Attribute │
│ │
│ { } Double Ellipse = Multivalued Attr │
└─────────────────────────────────────────────────┘
Attribute Types:
| Type | Description | Example |
|---|---|---|
| Simple | Atomic, cannot be divided | First Name |
| Composite | Can be divided | Full Name (First + Last) |
| Single-valued | One value per entity | Date of Birth |
| Multi-valued | Multiple values | Phone Numbers |
| Derived | Calculated from other attributes | Age (from DOB) |
| Key | Uniquely identifies entity | Employee ID |
Example: University Database ER
# Entity: STUDENT
# Attributes: student_id (PK), name, email, dob, age (derived)
# Entity: COURSE
# Attributes: course_id (PK), course_name, credits
# Relationship: ENROLLS
# Student <--(enrolls)--> Course
# Cardinality: Many-to-Many (M:N)
# A student can enroll in many courses
# A course can have many students
# Relationship Attributes:
# enrollment_date, grade
Relationship Types:
1:1 (One-to-One)
┌───────┐ ┌───────┐
│ Person │──────│ Passport│
└───────┘ └───────┘
One person has exactly one passport
1:N (One-to-Many)
┌───────┐ ┌───────┐
│ Dept │──────<│ Employee│
└───────┘ └───────┘
One department has many employees
M:N (Many-to-Many)
┌───────┐>─────<┌───────┐
│Student│ │ Course │
└───────┘ └───────┘
Many students enroll in many courses
Participation Constraints:
- Total (Mandatory): Every entity must participate (double line)
- Partial (Optional): Participation is optional (single line)
3. Enhanced ER (EER) Model
Generalization: Bottom-up approach - combine similar entities into a higher-level entity.
┌─────────┐
│ VEHICLE │ ← Generalized Entity
└────┬────┘
│
┌────────┼────────┐
↓ ↓ ↓
┌─────┐ ┌─────┐ ┌─────┐
│ Car │ │ Truck│ │ Bike │
└─────┘ └─────┘ └─────┘
Specialization: Top-down approach - create specialized sub-entities from general entity.
┌──────────┐
│ EMPLOYEE │ ← Superclass
└────┬─────┘
│ is-a
┌────────┼────────┐
↓ ↓ ↓
┌───────┐ ┌───────┐ ┌───────┐
│ Manager│ │Engineer│ │ Intern │
└───────┘ └───────┘ └───────┘
↑ Subclasses
Aggregation: Treating a relationship as a higher-level entity.
# Example: Project Management
# Relationship "Works_On" between Employee and Project
# This relationship itself participates in "Manages" relationship
# Employee ---(works_on)--- Project
# |
# | (aggregation)
# ↓
# [Monitors]
# ↑
# Manager
4. Relational Model
Core Concepts:
| Term | Definition |
|---|---|
| Relation | A table with rows and columns |
| Tuple | A row (record) in a table |
| Attribute | A column (field) in a table |
| Domain | Set of allowed values for an attribute |
| Degree | Number of attributes (columns) |
| Cardinality | Number of tuples (rows) |
| Schema | Structure definition (column names & types) |
| Instance | Actual data at a given time |
Keys in Relational Model:
-- STUDENT Table Example
CREATE TABLE Student (
student_id INT PRIMARY KEY, -- Primary Key
email VARCHAR(100) UNIQUE, -- Candidate Key
name VARCHAR(50) NOT NULL,
dept_id INT,
FOREIGN KEY (dept_id) REFERENCES Department(dept_id)
);
-- Key Types:
-- Super Key: Any set of attributes that uniquely identifies tuples
-- {student_id}, {student_id, name}, {email}, {email, name}
-- Candidate Key: Minimal super key (no redundant attributes)
-- {student_id}, {email}
-- Primary Key: Chosen candidate key for identification
-- student_id
-- Foreign Key: References primary key of another table
-- dept_id references Department(dept_id)
-- Alternate Key: Candidate keys not chosen as primary key
-- email
Integrity Constraints:
| Constraint | Description |
|---|---|
| Domain | Values must be from attribute's domain |
| Key | Primary key must be unique and NOT NULL |
| Entity Integrity | No part of primary key can be NULL |
| Referential Integrity | Foreign key must reference valid primary key or be NULL |
5. ER to Relational Mapping
Step-by-Step Mapping Algorithm:
# Step 1: Map Regular Entities
# Each entity → Table
# Simple attributes → Columns
# Composite attributes → Component attributes as columns
# Multivalued attributes → Separate table with FK
# Step 2: Map Weak Entities
# Include partial key + owner's PK as composite primary key
# Step 3: Map Binary 1:1 Relationships
# Add FK to either side (preferably total participation side)
# Or create separate relationship table
# Step 4: Map Binary 1:N Relationships
# Add FK to "many" side (N-side entity)
# Relationship attributes go with FK
# Step 5: Map Binary M:N Relationships
# Create new relationship table
# Include PKs of both entities as composite PK
# Add relationship attributes to this table
# Step 6: Map Multivalued Attributes
# Separate table with attribute + foreign key to owner
# EXAMPLE:
# Student (M) --- enrolls --- (N) Course
# Creates: Enrollment(student_id, course_id, grade, date)
Mapping Example:
-- Original ER: Student --enrolls-- Course (M:N)
-- Resulting Tables:
CREATE TABLE Student (
student_id INT PRIMARY KEY,
name VARCHAR(50),
email VARCHAR(100)
);
CREATE TABLE Course (
course_id INT PRIMARY KEY,
course_name VARCHAR(100),
credits INT
);
-- Relationship becomes a table
CREATE TABLE Enrollment (
student_id INT,
course_id INT,
enrollment_date DATE,
grade CHAR(1),
PRIMARY KEY (student_id, course_id),
FOREIGN KEY (student_id) REFERENCES Student(student_id),
FOREIGN KEY (course_id) REFERENCES Course(course_id)
);
TL;DR - Quick Reference
| Concept | Key Point |
|---|---|
| DBMS Advantage | Data independence, integrity, concurrency, security |
| Three Schema | External (views) → Conceptual (logical) → Internal (physical) |
| ER Entity | Rectangle, has attributes |
| ER Relationship | Diamond, connects entities with cardinality |
| EER Generalization | Combine similar entities (bottom-up) |
| EER Specialization | Create sub-entities (top-down) |
| Candidate Key | Minimal set of attributes uniquely identifying tuples |
| Referential Integrity | FK must match valid PK or be NULL |
| 1:N Mapping | FK goes to N-side entity |
| M:N Mapping | Create separate relationship table |
Resources
- Database System Concepts - Silberschatz - Standard textbook
- ER Diagram Tutorial - Visual guide
- GATE DBMS Notes - Practice problems
Test your understanding
Practice Quiz
10 questions · 90s per question
Each question has a 90-second time limit. Unanswered questions will be auto-submitted when time runs out.