Database Models: Relational, Network, Hierarchical, Object-Oriented

A database model defines the logical structure of a database and determines how data can be stored, organized, and manipulated.

Evolution of Database Models:

1. Hierarchical Model (1960s-1970s)

• Tree-like structure
• Parent-child relationships
• One-to-many (1:N) only

2. Network Model (1970s)

• Graph-based structure
• Many-to-many (M:N) supported
• More flexible than hierarchical

3. Relational Model (1970-present)

• Table-based structure
• Dominant model today
• Flexible and powerful

4. Object-Oriented Model (1980s-present)

• Objects with properties and methods
• Inheritance and encapsulation
• Complex data types

EXAMPLE 1: HIERARCHICAL DATABASE

Limitation: If John double-majors in CS and Math, must duplicate record or use complex workarounds.

EXAMPLE 2: NETWORK DATABASE

Network allows M:N relationships directly but requires pointer navigation.

EXAMPLE 3: RELATIONAL DATABASE

University Schema (Tables):

STUDENTS Table:

StudentID | Name        | Major    | Email
----------|-------------|----------|------------------
101       | John Doe    | CS       | john@uni.edu
102       | Jane Smith  | Math     | jane@uni.edu
103       | Bob Johnson | CS       | bob@uni.edu

COURSES Table:

CourseID | CourseName           | Credits | Department
---------|---------------------|---------|------------
CS101    | Intro to Programming | 3       | CS
CS202    | Database Systems     | 4       | CS
MATH101  | Calculus I          | 4       | Math

ENROLLMENT Table (Junction):

StudentID | CourseID | Semester | Grade
----------|----------|----------|------
101       | CS101    | Fall2024 | A
101       | CS202    | Fall2024 | B+
102       | MATH101  | Fall2024 | A
103       | CS101    | Fall2024 | B

SQL Query Examples:

-- Find all students enrolled in Database Systems
SELECT S.Name, S.Email
FROM STUDENTS S
JOIN ENROLLMENT E ON S.StudentID = E.StudentID
JOIN COURSES C ON E.CourseID = C.CourseID
WHERE C.CourseName = 'Database Systems';

-- Count enrollments per course
SELECT C.CourseName, COUNT(E.StudentID) as Enrollment_Count
FROM COURSES C
LEFT JOIN ENROLLMENT E ON C.CourseID = E.CourseID
GROUP BY C.CourseName;

EXAMPLE 4: OBJECT-ORIENTED DATABASE (db4o - Java)

// Define classes
class Student {
    int studentID;
    String name;
    String email;
    List<Course> courses;
    
    void enroll(Course c) {
        courses.add(c);
    }
}

class Course {
    String courseID;
    String courseName;
    int credits;
    List<Student> students;
}

// Store objects directly
Student john = new Student(101, "John Doe", "john@uni.edu");
Course cs101 = new Course("CS101", "Intro to Programming", 3);
john.enroll(cs101);

db.store(john); // Stores entire object graph

// Query objects
List<Student> csStudents = db.query(new Predicate<Student>() {
    public boolean match(Student s) {
        for (Course c : s.courses) {
            if (c.courseID.equals("CS101")) return true;
        }
        return false;
    }
});

EXAMPLE 5: REAL-WORLD APPLICATIONS

Hierarchical:

• File systems (directory structure)
• Organization charts
• XML documents

Network:

• Telecommunications networks
• Transportation systems
• Legacy mainframe applications

Relational:

• Banking systems
• E-commerce platforms
• Enterprise applications
• Web applications

Object-Oriented:

• CAD/CAM systems
• Multimedia databases
• Scientific applications
• Real-time systems

PRACTICAL CONSIDERATIONS:

1. Choosing the Right Model:

Use Relational When:

• ACID transactions required
• Complex queries needed
• Data highly structured
• Standard SQL queries
• Example: Banking, E-commerce

Use Object-Oriented When:

• Complex nested objects
• Tight OOP integration
• Multimedia content
• Example: CAD, Gaming, Simulations

Use Hierarchical/Network When:

• Legacy system maintenance
• Specific performance requirements
• Predefined access patterns

2. Migration Strategies:

-- Hierarchical to Relational
-- From tree:
Company -> Department -> Employee

-- To tables:
CREATE TABLE Company (
    CompanyID INT PRIMARY KEY,
    Name VARCHAR(100)
);

CREATE TABLE Department (
    DeptID INT PRIMARY KEY,
    DeptName VARCHAR(100),
    CompanyID INT,
    FOREIGN KEY (CompanyID) REFERENCES Company(CompanyID)
);

CREATE TABLE Employee (
    EmpID INT PRIMARY KEY,
    Name VARCHAR(100),
    DeptID INT,
    FOREIGN KEY (DeptID) REFERENCES Department(DeptID)
);

3. Hybrid Approaches (Object-Relational):

-- PostgreSQL: User-defined types
CREATE TYPE Address AS (
    street VARCHAR(100),
    city VARCHAR(50),
    zip VARCHAR(10)
);

CREATE TABLE Employee (
    EmpID INT PRIMARY KEY,
    Name VARCHAR(100),
    HomeAddress Address,  -- Complex type
    WorkAddress Address
);

-- Insert
INSERT INTO Employee VALUES (
    1,
    'John Doe',
    ROW('123 Main St', 'NYC', '10001'),
    ROW('456 Corp Ave', 'NYC', '10002')
);

-- Query
SELECT Name, (HomeAddress).city FROM Employee;

4. Modern Trends:

• Polyglot Persistence: Use multiple database types

  • Relational for transactions
  • Document for flexible data
  • Graph for relationships
  • Key-value for caching

• NoSQL Movement: Beyond relational

  • Document (MongoDB)
  • Key-Value (Redis)
  • Column-family (Cassandra)
  • Graph (Neo4j)

5. Performance Comparison: