Table of Contents

    Relational database concepts

    DATABASE FUNDAMENTALS

    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.

    "The relational model treats data as a collection of relations — simple, mathematical, and powerful enough to model the entire world of information."
    🗂️

    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.

    📌 Popular RDBMS Software:
    • 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

    RELATIONAL HIERARCHY
    DatabaseTableRowColumnValue
    1

    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.

    2

    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.

    3

    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.

    4

    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}.

    5

    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.

    6

    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.

    7

    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."

    8

    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
    101Rumman Ansari25KolkataComputer Science
    102Aditi Sharma22DelhiData Science
    103Rohan Mehta24MumbaiAI & ML
    🧠 Quick Analysis:
    • 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 KeyUniquely identifies rows❌ No❌ No
    Candidate KeyEligible to be Primary Key❌ No❌ No
    Super KeySuperset for uniqueness❌ No❌ No
    Alternate KeyUnused Candidate Keys❌ No❌ No
    Foreign KeyEstablishes relationship✅ Yes✅ Yes
    Composite KeyMulti-column PK❌ No❌ No
    Unique KeyEnsures unique values✅ One NULL❌ No
    Surrogate KeyArtificial 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.

    1

    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.

    2

    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.

    3

    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.

    4

    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:

    1

    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.

    2

    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.

    3

    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.

    4

    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.

    ACID FORMULA
    Atomicity + Consistency + Isolation + Durability
    1

    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.

    2

    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.

    3

    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.

    4

    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
    1NFAtomic values only (no multi-valued columns)Remove repeating groups
    2NF1NF + No partial dependencyRemove partial dependencies
    3NF2NF + No transitive dependencyRemove transitive dependencies
    BCNFStricter version of 3NFHandle anomaly edge cases
    4NFBCNF + No multi-valued dependencyHandle multi-valued data
    5NF4NF + No join dependencyEnsure lossless decomposition

    Relational vs Non-Relational Databases

    Relational (SQL) Non-Relational (NoSQL)
    Structured tables with fixed schemaFlexible schema (documents/key-value)
    Uses SQL for queriesUses custom APIs or query languages
    ACID-compliantBASE model (eventual consistency)
    Vertical scalingHorizontal scaling
    Best for structured dataBest for unstructured / big data
    Example: MySQL, PostgreSQLExample: 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.