Relational database concepts
Relational Database Concepts
The Core Foundation Behind Every Modern Data-Driven Application
What is a Relational Database?
A Relational Database is a type of database that stores and organizes data in the form of tables (relations) consisting of rows and columns. Each table represents a real-world entity, and tables are connected to each other through relationships defined by keys.
The concept of the Relational Model was introduced by Dr. Edgar F. Codd in 1970 in his famous research paper "A Relational Model of Data for Large Shared Data Banks." This revolutionary idea became the foundation of every modern RDBMS like MySQL, PostgreSQL, Oracle, SQL Server, and SQLite.
Easy Analogy
Imagine an Excel workbook. Each sheet is a table, each row is a record, each column is an attribute, and you can link sheets using common IDs. That's exactly how a relational database works — but with massive power, structure, and integrity.
What is an RDBMS?
An RDBMS (Relational Database Management System) is software that manages relational databases. It allows users to create, read, update, and delete data using SQL (Structured Query Language) while maintaining data integrity, security, and relationships.
- MySQL — Open-source, widely used in web applications
- PostgreSQL — Advanced open-source RDBMS
- Oracle Database — Enterprise-grade, used by large corporations
- Microsoft SQL Server — Popular in Windows-based enterprises
- SQLite — Lightweight, embedded database
- MariaDB — MySQL fork, fully open-source
Core Concepts of Relational Database
Relation (Table)
A two-dimensional structure made up of rows and columns.
In relational terminology, a table is called a Relation. It represents an entity such as Students, Employees, or Products. Every relation has a unique name within the database.
Tuple (Row / Record)
A single record in a table representing one instance of an entity.
Each row in a table is called a Tuple. For example, one row in a Students table represents the complete data of one specific student.
Attribute (Column / Field)
A specific property or characteristic of an entity.
Each column in a table is called an Attribute. For example, in a Students table, attributes might include name, age, city, and course.
Domain
The set of valid values an attribute can hold.
For example, the domain of an "age" column is positive integers (typically 0–120), and the domain of "gender" might be {Male, Female, Other}.
Degree
The total number of attributes (columns) in a relation.
If a Students table has 5 columns (id, name, age, city, course), then the degree of the relation = 5.
Cardinality
The total number of tuples (rows) in a relation.
If a Students table has 100 records, then the cardinality of the relation = 100. Cardinality changes as data is inserted or deleted.
Schema
The logical blueprint or structural design of the database.
The schema defines the structure — tables, attributes, data types, constraints, and relationships. It's the database's "skeleton."
Instance
The actual data stored in the database at a given moment.
The instance is dynamic — it changes whenever data is inserted, updated, or deleted. The schema stays the same; the instance evolves.
Visualizing a Relation (Table)
Here's a simple Students relation that explains all the terminology together:
| student_id | name | age | city | course |
|---|---|---|---|---|
| 101 | Rumman Ansari | 25 | Kolkata | Computer Science |
| 102 | Aditi Sharma | 22 | Delhi | Data Science |
| 103 | Rohan Mehta | 24 | Mumbai | AI & ML |
- Relation: Students
- Attributes: student_id, name, age, city, course
- Degree: 5 (number of columns)
- Cardinality: 3 (number of rows)
- Tuple Example: (101, Rumman Ansari, 25, Kolkata, Computer Science)
- Domain of "age": Positive integers
Keys in Relational Databases
Keys are the most important concept in relational databases. They uniquely identify records and establish relationships between tables.
1. Primary Key
A column (or combination of columns) that uniquely identifies each row. It cannot be NULL and cannot have duplicates.
CREATE TABLE Students (
student_id INT PRIMARY KEY,
name VARCHAR(100),
age INT
);
2. Candidate Key
A column or set of columns that could qualify as a primary key. Every primary key is a candidate key, but not every candidate key becomes the primary key.
Example: In a Students table, both student_id and email can uniquely identify a student — both are candidate keys.
3. Super Key
A superset of attributes that can uniquely identify a row. Every candidate key is a super key, but not every super key is a candidate key.
Example: {student_id}, {student_id, name}, {student_id, email} — all are super keys.
4. Alternate Key
All candidate keys that are NOT chosen as the primary key are called Alternate Keys.
5. Foreign Key
A column in one table that refers to the primary key of another table. It maintains referential integrity and creates relationships between tables.
CREATE TABLE Enrollments (
enroll_id INT PRIMARY KEY,
student_id INT,
course_id INT,
FOREIGN KEY (student_id) REFERENCES Students(student_id)
);
6. Composite Key
A primary key made up of two or more columns combined to uniquely identify a row.
CREATE TABLE CourseEnrollment (
student_id INT,
course_id INT,
enroll_date DATE,
PRIMARY KEY (student_id, course_id)
);
7. Unique Key
Ensures that all values in a column are unique, but unlike primary key, it can accept one NULL value.
8. Surrogate Key
An artificially generated key (like AUTO_INCREMENT ID) that has no business meaning. It's used purely for unique identification.
All Keys at a Glance
| Key Type | Purpose | NULL Allowed? | Duplicates Allowed? |
|---|---|---|---|
| Primary Key | Uniquely identifies rows | ❌ No | ❌ No |
| Candidate Key | Eligible to be Primary Key | ❌ No | ❌ No |
| Super Key | Superset for uniqueness | ❌ No | ❌ No |
| Alternate Key | Unused Candidate Keys | ❌ No | ❌ No |
| Foreign Key | Establishes relationship | ✅ Yes | ✅ Yes |
| Composite Key | Multi-column PK | ❌ No | ❌ No |
| Unique Key | Ensures unique values | ✅ One NULL | ❌ No |
| Surrogate Key | Artificial unique ID | ❌ No | ❌ No |
Integrity Constraints
Constraints are the rules enforced on data columns to maintain the accuracy, validity, and reliability of data in the database.
Domain Integrity
Ensures values fall within the defined data type and range.
For example, an "age" column should only contain positive integers, not text or negative values.
Entity Integrity
Every table must have a primary key, and it cannot be NULL.
This ensures that every row is uniquely identifiable in the table.
Referential Integrity
A foreign key must match a primary key value in the referenced table (or be NULL).
This maintains consistency between related tables and prevents orphan records.
Key Integrity
All primary key and unique key constraints must be maintained.
Ensures uniqueness and prevents duplicate values in key columns.
Common SQL Constraints
CREATE TABLE Employee (
emp_id INT PRIMARY KEY AUTO_INCREMENT, -- Primary Key
name VARCHAR(100) NOT NULL, -- NOT NULL Constraint
email VARCHAR(100) UNIQUE, -- Unique Constraint
age INT CHECK (age >= 18), -- Check Constraint
department VARCHAR(50) DEFAULT 'General', -- Default Constraint
manager_id INT,
FOREIGN KEY (manager_id) REFERENCES Employee(emp_id) -- Foreign Key
);
Types of Relationships
Tables in a relational database are connected through different types of relationships:
One-to-One (1:1)
One row in Table A relates to exactly one row in Table B.
Example: One Person has one Passport. One row in the Person table relates to exactly one row in the Passport table.
One-to-Many (1:N)
One row in Table A relates to many rows in Table B.
Example: One Department has many Employees. This is the most common type of relationship in relational databases.
Many-to-One (N:1)
Many rows in Table A relate to one row in Table B.
Example: Many Students belong to one Class. It's simply the reverse of One-to-Many.
Many-to-Many (M:N)
Many rows in Table A relate to many rows in Table B.
Example: Students enroll in many Courses, and each Course has many Students. This is implemented using a junction table.
Example: Many-to-Many Relationship
CREATE TABLE Students (
student_id INT PRIMARY KEY,
name VARCHAR(100)
);
CREATE TABLE Courses (
course_id INT PRIMARY KEY,
course_name VARCHAR(100)
);
-- Junction Table linking Students and Courses
CREATE TABLE StudentCourses (
student_id INT,
course_id INT,
enroll_date DATE,
PRIMARY KEY (student_id, course_id),
FOREIGN KEY (student_id) REFERENCES Students(student_id),
FOREIGN KEY (course_id) REFERENCES Courses(course_id)
);
ACID Properties
Every reliable relational database follows the ACID properties to ensure data integrity and consistency during transactions.
Atomicity
"All or Nothing" — either all operations succeed, or none do.
If any step in a transaction fails, the entire transaction is rolled back. For example, in a money transfer, if debit succeeds but credit fails, the debit is reversed.
Consistency
The database remains in a valid state before and after the transaction.
All defined rules, constraints, and triggers are honored, preserving data integrity throughout every transaction.
Isolation
Concurrent transactions don't interfere with each other.
Each transaction executes as if it were the only one running, even when many are happening simultaneously.
Durability
Once a transaction is committed, it stays permanently — even after a system crash.
Changes are saved to non-volatile memory, ensuring data survives power failures or hardware crashes.
Normalization (Brief Overview)
Normalization is the process of organizing data in a database to eliminate redundancy and ensure data integrity. It involves dividing large tables into smaller related tables and defining relationships between them.
| Normal Form | Rule | Purpose |
|---|---|---|
| 1NF | Atomic values only (no multi-valued columns) | Remove repeating groups |
| 2NF | 1NF + No partial dependency | Remove partial dependencies |
| 3NF | 2NF + No transitive dependency | Remove transitive dependencies |
| BCNF | Stricter version of 3NF | Handle anomaly edge cases |
| 4NF | BCNF + No multi-valued dependency | Handle multi-valued data |
| 5NF | 4NF + No join dependency | Ensure lossless decomposition |
Relational vs Non-Relational Databases
| Relational (SQL) | Non-Relational (NoSQL) |
|---|---|
| Structured tables with fixed schema | Flexible schema (documents/key-value) |
| Uses SQL for queries | Uses custom APIs or query languages |
| ACID-compliant | BASE model (eventual consistency) |
| Vertical scaling | Horizontal scaling |
| Best for structured data | Best for unstructured / big data |
| Example: MySQL, PostgreSQL | Example: MongoDB, Cassandra |
Advantages vs Limitations
✅ Advantages
- Strong data integrity & consistency
- Powerful SQL query support
- Mature, well-tested technology
- Excellent for structured data
- ACID-compliant transactions
- Easy to understand and visualize
- Standardized across all RDBMS
⚠️ Limitations
- Rigid schema — difficult to change
- Not ideal for unstructured data
- Horizontal scaling is challenging
- Complex joins can slow performance
- Storage overhead due to normalization
- Not ideal for hierarchical or graph data
Real-World Use Cases
🌍 Where Relational Databases Are Used
- Banking & Finance: Transaction records, account management
- E-commerce: Product catalogs, orders, payments
- ERP Systems: Inventory, HR, payroll, accounting
- CRM Platforms: Customer data, interactions, sales records
- Education: Student information systems, exam records
- Healthcare: Patient records, prescriptions, billing
- Government: Citizen records, taxation, voter databases
- Web Applications: User management, authentication, blogs
Relational Database Best Practices
💡 Pro Tips for Database Design
- Always define a Primary Key for every table
- Use Foreign Keys to maintain referential integrity
- Normalize tables up to 3NF for most use cases
- Choose appropriate data types for each column
- Apply constraints (NOT NULL, UNIQUE, CHECK) to enforce rules
- Use indexes on frequently queried columns
- Follow a consistent naming convention (snake_case)
- Document your schema and relationships with ER diagrams
- Always use transactions for critical multi-step operations
- Regularly backup and monitor performance
Think of a Relational Database as a Government Office
Every table is a department, every row is a citizen file, every column is a personal detail, and every foreign key is a reference number that links one department's file to another.
🎯 Key Takeaway
The Relational Database Model is the backbone of structured data management — combining mathematical elegance with real-world practicality. Mastering its concepts means mastering the logic behind every modern data system.