DBMS Notes
A data model is a collection of conceptual tools for describing data, data relationships, data semantics, and consistency constraints. It provides an...
What is a Data Model?
A data model is a collection of conceptual tools for describing data, data relationships, data semantics, and consistency constraints. It provides an organized framework for thinking about and representing the structure of a database. Just as an architect uses blueprints to describe a building before construction begins, a database designer uses data models to describe the database before implementation.
A good data model answers three fundamental questions: What data do we store? How are different pieces of data related? What rules must the data satisfy?
1. Hierarchical Model
Data is organized in a tree structure with a single root and parent-child relationships. Each parent can have many children, but each child has exactly one parent.
| │ ├── Student | Alice (CS) |
| │ ├── Student | Bob (CS) |
| │ └── Course | DBMS |
| │ ├── Student | David (Math) |
| │ └── Course | Linear Algebra |
| └── Student | Frank (Physics) |
Data access: Navigation follows the tree — to find Alice, you traverse University → CS Dept → Alice. There is no way to jump directly; you always start from the root and navigate down.
Advantages:
- Simple and fast for one-to-many (1:N) relationships
- Efficient when access patterns follow the hierarchy (e.g., "all students in CS")
- Low storage overhead
Disadvantages:
- Cannot naturally represent many-to-many (M:N) relationships
- Data redundancy: if Alice takes courses in two departments, her record is duplicated
- Rigid structure: reorganizing the tree requires rewriting applications
Historical Example: IBM IMS (Information Management System), used since the 1960s for banking and airline systems.
2. Network Model
An extension of the hierarchical model that allows many-to-many relationships. Data is organized as a directed graph where records (nodes) connect through links (edges called "sets").
| Student | Courses |
|---|---|
| Alice | CS101, MATH201, PHY301 |
| Bob | CS101, MATH201 |
| Carol | PHY301 |
Students can enroll in many courses, and each course can have many students.
Advantages:
- Supports M:N relationships naturally
- More flexible than hierarchical model
- Reduced redundancy compared to hierarchical
Disadvantages:
- Complex navigation: programmers must know the physical structure and follow pointers
- Difficult to reorganize: changing the graph structure breaks applications
- No declarative query language — all access is procedural
Historical Example: CODASYL (Conference on Data Systems Languages) databases like IDMS.
3. Relational Model
Proposed by E.F. Codd in 1970, the relational model represents data as a collection of tables (relations). Each table has rows (tuples) and columns (attributes). Relationships between tables are expressed through shared attribute values (foreign keys), not physical pointers.
-- Student table
+-----+-------+------+
| SID | Name | Dept |
+-----+-------+------+
| 101 | Alice | CS |
| 102 | Bob | Math |
+-----+-------+------+
-- Enrollment table (M:N relationship via junction table)
+-----+--------+-------+
| SID | CrsID | Grade |
+-----+--------+-------+
| 101 | CS101 | A |
| 101 | MATH201| B+ |
| 102 | CS101 | A- |
+-----+--------+-------+Key Properties:
- Data is accessed using a declarative language (SQL) — you specify *what* you want, not *how* to navigate
- Physical storage is independent of logical structure
- Mathematical foundation (set theory, predicate logic) enables formal optimization
Advantages:
- Simple, intuitive table structure
- Data independence (physical reorganization does not affect queries)
- Powerful query language (SQL)
- Strong theoretical foundation
- Supports integrity constraints declaratively
Disadvantages:
- Performance overhead for complex joins on very large datasets
- Not ideal for hierarchical or graph-shaped data
- Object-relational impedance mismatch with OOP languages
Examples: Oracle, MySQL, PostgreSQL, SQL Server, SQLite.
4. Entity-Relationship (ER) Model
The ER model is a conceptual data model used during the design phase. It represents real-world scenarios as entities (things), attributes (properties), and relationships (associations).
The ER model is not used for implementation directly — it is converted (mapped) into a relational schema.
5. Object-Oriented Model
Combines database capabilities with object-oriented programming concepts:
- Objects have state (attributes) and behavior (methods)
- Classes define object templates
- Inheritance allows subclasses to extend superclasses
- Object identity — each object has a unique OID independent of its attribute values
| Class | Person |
| attributes | name, address |
| methods | getName(), setAddress() |
| Class | Student extends Person |
| attributes | GPA, enrollmentYear |
| methods | calculateCGPA() |
Use cases: CAD/CAM systems, multimedia databases, scientific data. Examples: ObjectDB, db4o.
6. Object-Relational Model
A hybrid that extends the relational model with object-oriented features: user-defined types, inheritance, methods, and nested tables — while keeping SQL as the query language.
-- User-defined type in PostgreSQL
CREATE TYPE address_type AS (
street VARCHAR(100),
city VARCHAR(50),
zip CHAR(6)
);
CREATE TABLE Employee (
emp_id INT PRIMARY KEY,
name VARCHAR(100),
home_address address_type -- nested composite type
);Examples: PostgreSQL (supports custom types, inheritance), Oracle (object types).
Comparison of Data Models
| Feature | Hierarchical | Network | Relational | Object-Oriented |
|---|---|---|---|---|
| Structure | Tree | Graph | Tables | Objects/Classes |
| Relationships | 1:N only | M:N | M:N via FK | References/OID |
| Query language | Procedural | Procedural | Declarative (SQL) | OQL |
| Data independence | Low | Low | High | Medium |
| Flexibility | Rigid | Moderate | High | High |
| Theoretical basis | None formal | CODASYL spec | Set theory | OOP theory |
| Current usage | Legacy systems | Rare | Dominant | Niche |
Choosing the Right Model
In modern practice, the relational model dominates for transactional systems (OLTP). However, the choice depends on the application:
- Relational: Business applications, ERP, banking, e-commerce
- Document/NoSQL: Content management, real-time analytics, flexible schemas
- Graph: Social networks, recommendation engines, fraud detection
- Object-oriented: Engineering/CAD, genomics, multimedia
Understanding all models gives you the vocabulary to evaluate database systems and pick the right tool for each problem.
Continue the lesson path