🧠 Chapter 2: Data Model (Part 1)

🌟 What is a Data Model?

A data model is a simple, visual representation of how real-world data is
structured and related inside a database.
Think of it like a blueprint — it shows how data is stored, connected, and used
without dealing with the actual database code.
 Purpose: To simplify complex real-world data structures.
 Main function: Acts as a communication tool between:
o Database designers

o Application developers

o End users

💡 A good database design always starts with a clear and accurate data model.

👥 Different Views of Data

Different users in a company see data in different ways:
 A manager might care about employee performance.
 A salesperson might care about customer orders.
 A developer might focus on how data is stored.
➡️The data model helps organize and represent all these perspectives in a
consistent way.

🔗 Types of Relationships in Data Models

Relationships show how entities are connected.

Relationship
Description Example
Type

One-to-Many One entity is related to

One department has many employees.
(1:M) many others.

Many-to- Many entities relate to Students can take many courses, and
Many (M:N) many others. each course has many students.

One-to-One One entity relates to

Each person has one passport.
(1:1) only one other.

🧩 Basic Building Blocks of Data Models

Term Description Example

Anything you collect and store data Student, Product,

Entity
about. Employee

A property or characteristic of an Student Name, Product

Attribute
entity. Price

Relations A link or association between Students enroll in

hip entities. Courses

🧾 Business Rules
Business rules are clear, written descriptions of how an organization
operates.
They define policies, procedures, and principles that affect database design.
Examples:
 Each student must have a unique student ID.
 An employee can belong to only one department.
 Orders must have at least one item.
Characteristics of Good Business Rules:
 Must be written clearly.
 Must be updated regularly.
 Should be easy to understand and accessible to everyone.
 May come from external sources like government policies.
Why They Matter:
Business rules help ensure:
 Data accuracy and consistency.
 A shared understanding between users and designers.
 Correct relationship rules and data constraints.

🧍‍♀️Who Defines Business Rules?

Business rules are usually gathered from:
 Company managers
 Policy makers
 Department heads
 End users (via interviews)
  Documents, manuals, and procedures

🧰 Importance of Business Rules

Business rules:
1. Help create an accurate data model.
2. Standardize how data is viewed across the organization.
3. Improve communication between users and database designers.
4. Help designers understand business processes.
5. Define relationship rules and constraints in the model.

📚 Reference
Coronel, Morris & Rob, Database Systems – Design, Implementation, and
Management (9th Edition)

Hierarchical Model, based on your notes from Chapter 2 (Part 2):

🌳 Hierarchical Data Model

🔹 1. Definition
The hierarchical model organizes data into a tree-like structure, where each
record (called a segment) has a parent-child relationship.
 Parent: A higher-level record.
 Child: A lower-level record that depends on a parent.
 Hierarchy: Each child can have only one parent, but a parent can have
many children.
🧩 Example (real-world):
Company
├── Department
│ ├── Employee
│ ├── Employee
│ └── Employee
└── Department
├── Employee
├── Employee
Each Company can have many Departments,
each Department can have many Employees,
but each Employee belongs to only one Department.

🔹 2. Structure
The model is built on segments connected through pointers or links, forming
a tree.
 The root is the top-level parent (e.g., “Company”).
 Each child record can itself be a parent to other records.
 The path from root to leaf defines a unique hierarchical path.
📘 Key Terms:

Term Meaning

Root Segment The topmost record (e.g., Company)

Parent Segment A record that has one or more child segments

Child Segment A record that belongs to one parent

Sequence of segments from the root to a specific

Hierarchical Path
child

Preorder Traversal Method for reading all segments starting from the
(Hierarchic Sequence) left-most parent down through its children

🔹 3. Example in Data Context

Company_ Company_Na
ID me

C01 TechVision

Department Department_Na Company_

_ID me ID

D01 HR C01

D02 IT C01

Employee_ Employee_Na Department

ID me _ID

E01 Alice D01

E02 Bob D02

E03 Carol D02

💡 Notice how each table follows a one-to-many relationship:

  One Company → Many Departments
 One Department → Many Employees

🔹 4. Characteristics
✅ Main Features:
 Data is represented as records (segments) connected by links
(pointers).
 One-to-Many (1:M) relationships are the foundation.
 Relationships are predetermined — structure is fixed.
 Access to data follows a specific path from parent to child.
 Data retrieval is fast and efficient when the structure is known.

🔹 5. Advantages

Advantage Explanation

The tree structure is easy to visualize and

Conceptual simplicity
understand.

Each child has only one parent → reduces data

Data integrity
inconsistency.

Access can be controlled at different hierarchy

Data security
levels.

Efficiency Very fast when handling large, predictable data.

Data independence Some level of separation between data and

(limited) applications.

🔹 6. Disadvantages

Disadvantage Explanation

Complex Modifying the structure requires major

implementation reprogramming.

Difficult to manage Adding or deleting relationships is not flexible.

No structural Changing data structure affects all applications

independence using it.

Complicated for Navigating through multiple paths and levels is

programmers hard.

Lacks ad hoc query Cannot easily search data outside the

Disadvantage Explanation

capability predefined paths.

Suitable only for fixed, predictable

Limited flexibility
relationships.

🔹 7. Example Visualization
Here’s a simplified hierarchical tree showing how the relationships work:
UNIVERSITY
├── FACULTY OF SCIENCE
│ ├── Department of Biology
│ │ ├── Lecturer: Dr. A
│ │ ├── Lecturer: Dr. B
│ │
│ └── Department of Chemistry
│ ├── Lecturer: Dr. C
│ └── Lecturer: Dr. D
│
└── FACULTY OF ENGINEERING
├── Department of Mechanical Eng.
│ ├── Lecturer: Dr. E
│ └── Lecturer: Dr. F
└── Department of Electrical Eng.
├── Lecturer: Dr. G
└── Lecturer: Dr. H
This shows 1:M relationships at each level — one Faculty has many
Departments, one Department has many Lecturers.

🔹 8. Summary Table

Aspect Hierarchical Model

Structure Tree-like (Parent–Child)

Relationship
One-to-Many (1:M)
Type

Example Use Organization chart, product categories

Aspect Hierarchical Model

Data Access
Predetermined (top-down)
Path

Query
Low (no ad hoc queries)
Flexibility

Applications with fixed, predictable data

Best For
structure

1960s (IBM Information Management

Introduced In
System – IMS)

🌐 Network Data Model

🔹 1. Definition
The Network Model represents data using records (like entities) that are
connected by relationships called sets.
Unlike the tree structure of the Hierarchical Model,
the Network Model forms a graph structure — allowing multiple paths and
more flexible relationships.
📘 Introduced by: Charles Bachman (1969)
📘 Standardized by: CODASYL (Conference on Data Systems Languages)

🔹 2. Core Concept
Each relationship in a Network Model is called a Set, which defines how records
are connected.
📎 A Set has two parts:

Hierarchical
Part Meaning
Equivalent

Owner Record The “one” side of a

Parent
Type relationship

Member Record The “many” side of a

Child
Type relationship

Each owner can have many members,

but each member can belong to multiple owners — ✅ this allows a child to
have multiple parents.
🔹 3. Structure Visualization
Let’s use a simple example:
👉 An Employee can work on many Projects, and each Project can have many
Employees.
📄 In Hierarchical Model
Department
├── Project
│ └── Employee
❌ Employee belongs to one Project only.
📄 In Network Model
[Project A]
/ \
[Employee1] [Employee2]
\ /
[Project B]
✅ Here:
 Employee 1 works on Project A and B.
 Project A has Employee 1 and Employee 2.
 This many-to-many (M:N) relationship is possible.

🔹 4. Example (CODASYL-style Set)

Let’s represent the above with sets:

Set Owner Member

Name Record Record

Works_O
PROJECT EMPLOYEE
n

So:
 Each Project (owner) can have many Employees (members).
 Each Employee can belong to multiple Projects (via the set).

🔹 5. Key Characteristics

Feature Description

Structure Graph-like (records connected by sets)

Feature Description

Relationship
One-to-Many (1:M) and Many-to-Many (M:N)
Types

Data
Records connected via pointers
Representation

Access Path Predefined by the database designer

Data Manipulation Language (DML) under CODASYL

Language
standard

🔹 6. Advantages
✅ More Flexible Relationships
 Supports M:N (many-to-many) and 1:M (one-to-many) directly.
 A child can have multiple parents — perfect for complex data.
✅ Data Integrity
 Uses owner-member sets to maintain consistent relationships.
✅ Efficiency
 Fast data access using direct pointers (no searching through tables).
✅ Data Independence
 Some flexibility when modifying structure without rewriting everything.
✅ Standards Support
 Early DBMS standards (CODASYL) improved system compatibility.

🔹 7. Disadvantages
❌ System Complexity
 Much more difficult to design, maintain, and program than hierarchical or
relational models.
❌ Navigation Required
 To retrieve data, programmers must navigate pointer paths manually.
❌ Limited Structural Independence
 Still tied to the physical data structure — changes may affect applications.
❌ Learning Curve
 Requires specialized knowledge of sets, pointers, and paths.
🔹 8. Comparison: Hierarchical vs. Network Model

Hierarchical
Feature Network Model
Model

Structure Tree Graph

One-to-Many (1:M) and Many-to-

Relationships One-to-Many (1:M)
Many (M:N)

Child with Multiple

❌ Not allowed ✅ Allowed
Parents

Flexibility Low High

Single path (top-

Data Access Multiple paths
down)

Ease of Design Simple Complex

Simple, fixed
Best Use Complex, interconnected data
structures

🔹 9. Real-World Analogy
Imagine a university system:
 Students can take many Courses.
 Each Course can have many Students.
✅ This is Network Model — both sides can have many connections.
If it were Hierarchical, a student could only take one course — unrealistic!

🔹 10. Summary

Concept Description

Purpose To represent complex relationships efficiently

Structure Graph with records and sets

Key
Owner–Member (supports M:N)
Relationship

Advantage Greater flexibility, better performance

Disadvantage Complex management and navigation

Early database systems (e.g., IDMS, Integrated

Historical Use
Data Store)
📈 Entity–Relationship (ER) Model
🔹 1. Definition
The Entity–Relationship Model (ER Model) is a graphical approach to data
modeling that shows:
 The entities (things we store data about),
 Their attributes (properties or details), and
 The relationships between them.
🧠 Developed by: Peter Chen in 1976
🎯 Purpose: To visually represent data structure before converting it into a
database.

🔹 2. Why It’s Important

 It helps database designers and users visualize data easily.
 It acts as a blueprint for designing a Relational Database.
 It is independent of any specific software or hardware — purely
conceptual.

🔹 3. Key Components of the ER Model

Componen
Description Example
t

A real-world object or concept about which Student, Course,

Entity
data is stored. Employee

StudentName,
Attribute A property or characteristic of an entity.
StudentID, Email

Relations An association between two or more

Student enrolls in Course
hip entities.

 🔹 4. Types of Entities

Type Description Example

Exists independently. Has a

Strong Entity Employee, Department
primary key.

Depends on another entity for

Weak Entity OrderItem depends on Order
identification.
Type Description Example

Associative Used to represent a many-to- Enrollment between Student

Entity many relationship. & Course

🔹 5. Attributes
Attributes describe characteristics of entities.

Attribute
Description Example
Type

Simple Cannot be divided further. Name, Age

Can be divided into smaller FullName → FirstName,

Composite
parts. LastName

Calculated from other

Derived Age (from DateOfBirth)
attributes.

Multivalue PhoneNumber (work, home,

Can have multiple values.
d mobile)

🔹 6. Relationships
Relationships define how entities are connected.

Type Description Example

One-to-One One entity relates to one

Each person has one passport.
(1:1) other entity.

One-to-Many One entity relates to

One teacher teaches many students.
(1:M) many others.

Many-to- Many entities relate to Students take many courses, each

Many (M:N) many others. course has many students.

🔹 7. Cardinality (Connectivity)
Cardinality defines the number of instances that can participate in a
relationship.

Symb Meani
ol ng

1 One

M or N Many

Example:
STUDENT (1,M) — ENROLLS — (1,M) COURSE
→ One student can enroll in many courses,
and one course can have many students.

🔹 8. Entity Relationship Diagram (ERD)

The ERD is the visual representation of the ER model.

Symbol Meaning

🟦
Entity
Rectangle

🔶 Diamond Relationship

🟠 Oval Attribute

Relationship line (connects entities and

───
relationships)

🧩 Example:
[STUDENT]──<ENROLLS>──[COURSE]

STUDENT:
- StudentID
- StudentName
- Email

COURSE:
- CourseID
- CourseName
- CreditHours

🔹 9. Example in Context
Scenario:
A university wants to keep track of students and the courses they take.

Entity Attributes Relationships

Stude StudentID, Name,

Enrolls in Course
nt Email

Cours CourseID, Title, Has many

e Credits Students
🧭 Relationship:
Each Student can enroll in many Courses, and each Course can have many
Students → M:N relationship.
This can be broken down by creating a new Associative Entity called
ENROLLMENT.

🔹 10. Advantages
✅ Easy to Understand
 Simple visual representation — ideal for communication between users
and designers.
✅ Conceptual Simplicity
 Clearly shows how data entities are connected.
✅ Useful for Relational Databases
 Maps directly to relational tables (entities become tables, attributes
become columns).
✅ Improves Communication
 Everyone (technical or non-technical) can understand the data structure.

🔹 11. Disadvantages
❌ Limited Constraint Representation
 Doesn’t show complex rules (like “a student can enroll in only 5 courses”).
❌ Limited Relationship Representation
 Not great at showing relationships with detailed semantics.
❌ No Data Manipulation Language
 Only a design tool — you can’t use it to query or manipulate data directly.
❌ Information Loss
 Some details about system behavior might not appear in the ER diagram.

🔹 12. Summary Table

Aspect ER Model

Developed by Peter Chen (1976)

Aspect ER Model

Graphical (entities, attributes,

Structure
relationships)

Representation Entity Relationship Diagram (ERD)

Relationships
1:1, 1:M, M:N
Supported

Database design and conceptual

Best For
modeling

Main Advantage Visual clarity and simplicity

Main Limitation No direct data manipulation

🧠 Quick Recap
 The ER Model is conceptual → used for database design, not storage.
 It uses entities, attributes, and relationships to model data.
 It’s the foundation for the Relational Model used in modern databases.

🧩 Object-Oriented Data Model (OODM)

🔹 1. Definition
The Object-Oriented Data Model (OODM) represents both data and the
operations (behavior) that can be performed on that data — inside a single
structure called an object.
💬 In other words:
The OODM combines data (what it is) and methods (what it can do) into
one package.
📘 Developed from: the Semantic Data Model (SDM) by Hammer & McLeod
(1981)
📘 Foundation for: Object-Oriented Database Management System (OODBMS)

🔹 2. Why It Was Developed

Earlier models (hierarchical, network, relational) could store data well,
but they couldn’t handle complex data relationships or real-world objects
(like images, videos, or documents).
The Object-Oriented Model was designed to:
 Represent real-world entities more naturally.
  Combine data + behavior in one model.
 Improve data reusability, extensibility, and semantic richness
(meaningful connections).

🔹 3. Core Concepts

Concept Description Example

Basic building block — A Student object stores data

Object represents a real-world entity (name, ID) and methods (enroll(),
with data and behavior. payFees())

Describe properties or
Attributes Name, Age, Course
characteristics of the object.

Define actions or behaviors enroll(), dropCourse(),

Methods
associated with the object. displayInfo()

A template or blueprint for “Student” is a class → each

Class
creating objects. student is an object

Class Classes are organized from “Person” → “Student” →

Hierarchy general → specific. “GraduateStudent”

Child class inherits attributes Student inherits from Person

Inheritance
and methods of parent class. (name, address)

Data and behavior are bundled

Encapsulati User can call enroll() but not
together and hidden from
on directly change private attributes
outside access.

Different classes can use the

Polymorphis printDetails() works differently for
same method name with
m Student and Teacher
different behaviors.

🔹 4. Object Example
🎓 Example: Student Object
Class: Student
Attributes:
- studentID
- name
- courseList
Methods:
- enroll(course)
- drop(course)
 - displayInfo()
Each Student object:
 Has data (ID, name, courses)
 Has behavior (functions it can perform)
 Can interact with other objects (e.g., Course, Department)

🔹 5. Structure Visualization
Here’s how the Object-Oriented model organizes data:
┌─────────────┐
│ PERSON │
│-------------│
│ Name │
│ Address │
│-------------│
│ displayInfo() │
└──────┬──────┘
│
┌─────────┴─────────┐
│ │
┌──────────────┐ ┌──────────────┐
│ STUDENT │ │ TEACHER │
│--------------│ │--------------│
│ studentID │ │ teacherID │
│ courseList │ │ department │
│--------------│ │--------------│
│ enroll() │ │ teach() │
│ drop() │ │ grade() │
└──────────────┘ └──────────────┘
✅ Inheritance:
 Student and Teacher inherit attributes from Person (Name, Address).
 Each class adds its own unique properties and behaviors.
🔹 6. Advantages

Advantage Description

🧠 Semantic Models real-world entities more naturally (includes both

richness data and behavior).

🧩 Encapsulation Keeps data secure and organized with access controls.

♻️Reusability Classes and objects can be reused across applications.

Reduces redundancy by sharing common attributes and

🌲 Inheritance
methods.

🧮 Data integrity Each object controls access to its data → fewer data errors.

Multimedia
Can handle complex data like images, videos, sounds.
support

🔹 7. Disadvantages

Disadvantage Description

⚙️Complex More difficult to design and maintain than relational

implementation databases.

🧭 Slow standards
OODBMS standards are not as mature as SQL.
development

Requires programmers familiar with object-oriented

🧑‍💻 Steep learning curve
concepts.

High system overhead Extra processing needed for object management.

Not widely used in commercial systems — relational

📉 Limited adoption
databases still dominate.

🔹 8. Comparison with Relational Model

Feature Relational Model Object-Oriented Model

Structure Tables (rows & columns) Objects (data + methods)

Data Complex, semantic (real-

Simple, tabular
Representation world)

Relationships Based on foreign keys Based on object references

Behavior Supported within each

Not supported
(Methods) object

High (via classes and

Reusability Limited
inheritance)
Feature Relational Model Object-Oriented Model

Business/transactional Multimedia, scientific, AI

Best For
systems systems

🔹 9. Real-World Examples
The OODM is used in systems where data is complex, interrelated, and
behavior-driven, such as:
 🎮 Game development (characters, environments, objects)
 Engineering/CAD systems
 🧬 Bioinformatics and scientific research
 🎬 Multimedia databases (images, audio, video)
 🤖 Artificial Intelligence & simulation models

🔹 10. Summary Table

Aspect Object-Oriented Data Model

Developed by Hammer & McLeod (1981, Semantic Data Model)

Core Element Object (data + methods)

Organizational Unit Class

Relationship
Class hierarchy and object references
Representation

Main Feature Combines data and behavior

Best Use Complex, real-world applications

Object, class, inheritance, encapsulation,

Key Concepts
polymorphism

Main Advantage Real-world modeling accuracy

Main Disadvantage Complexity and limited commercial use

💡 Quick Recap
 An object = data + operations.
 OODM focuses on semantic richness and real-world modeling.
 It’s great for systems that go beyond simple data — like interactive,
multimedia, or simulation systems.
  Basis for modern OOP languages (C++, Java, Python) and object-
relational databases.

🧠 Chapter 2: Data Model (Part 3)

(Levels of Data Abstraction & Modern Database Characteristics)

🌐 1. Characteristics of “Internet Age” Databases

Modern databases (especially those used on the Internet) must be:
✅ Flexible – easily adaptable to new needs.
✅ Efficient – quick data access even with large data volumes.
✅ Secure – protect data from unauthorized access.
✅ User-friendly – simple and intuitive for users and developers.
✅ Support complex data types – like images, audio, video, documents.
✅ Integrate multiple data sources – can connect with different systems (e.g.,
APIs, cloud, external databases).
💡 Goal: Seamless, secure, and efficient access for users and applications across
the web.

🧰 2. Features of Successful Modern Databases

To support these needs, a modern database should have:

Feature Description

Conceptual
Easy to design and understand.
Simplicity

Includes software tools for modeling, implementation, and

Rich Design Tools
testing.

GUI (Graphical Makes database administration easier — e.g., drag-and-

User Interface) drop table design, visual query builders.

🧭 3. Classifying Data Models by Level of Abstraction

Data models are classified by how detailed or abstract they are.
The goal is to move from a broad idea to specific details during database
design.
The three main levels were standardized by:
📘 ANSI/SPARC (American National Standards Institute / Standards
Planning and Requirements Committee)

🔺 Levels of Data Abstraction

Level Description Dependency Represented By

DBMS-dependent,
External Describes how end users ER Diagrams, user
hardware-
Level view the data. views
independent

Describes the overall Independent of both Entity

Conceptual
logical structure of the software & Relationship (ER)
Level
entire database. hardware Model

Software-
Describes how the database
Internal dependent, Tables, indexes,
is logically implemented
Level hardware- storage structure
inside the DBMS.
independent

Describes how data is Software and Disk files, data

Physical
physically stored on hardware blocks, storage
Level
hardware. dependent paths

🪜 4. The Three Main Levels in Detail

🧍‍♀️1. External Level

Also called: User view or subschema.
 Focuses on how specific users or departments see the data they need.
 Each user has a personalized view — only relevant data is shown.
 Useful for security (users only see what they are allowed to).
 ER diagrams are used to represent each view.
✅ Advantages:
 Easier application development (each department gets only what it
needs).
 Improves database security — users cannot access unrelated data.
 Simplifies user interaction and feedback for database design.
Example:
 A Sales Department sees only Customer and Order data.
 The HR Department sees Employee and Payroll data.

🧩 2. Conceptual Level
Also called: Logical Level.
 Represents a global view of the entire database for the whole
organization.
  Integrates all user (external) views into one unified model.
 Shows entities, relationships, and constraints, but not
implementation details.
 Acts as a bridge between the external and internal models.
✅ Advantages:
 Hardware and software independent → changes in system do not
affect conceptual design.
 Provides a clear, high-level understanding of how all data is related.
 Based on the Entity Relationship (ER) Model — the most widely used
conceptual tool.
💡 Think of this as your “master plan” for the entire database.

⚙️3. Internal Level

Also called: Implementation Level.
 Shows how data is structured and stored logically in the DBMS.
 Defines storage methods, indexing, and data access paths.
 Must match the conceptual design but adapt to the DBMS’s
capabilities.
 Software dependent, but hardware independent.
✅ Examples:
 Defining tables, data types, and relationships in SQL.
 How indexes and constraints are implemented in the DBMS.

💾 4. Physical Level (Lowest Level of Abstraction)

 Deals with actual data storage — how data is saved on physical media
(disks, SSDs, tapes).
 Requires knowledge of both hardware and software.
 Includes file organization, storage allocation, compression, and retrieval
mechanisms.
✅ Example:
How MySQL or Oracle physically stores table data on disk (data blocks, pages,
files).

🧭 5. Relationship Between the Levels

[External Level]
 ↓
[Conceptual Level]
↓
[Internal Level]
↓
[Physical Level]
Each level adds more detail, moving from abstract ideas → actual
implementation.

⚖️6. Summary Table

Level Description Dependency Purpose

User’s view of DBMS Dependent, Customize user access,

External
data Hardware Independent ensure security

Conceptu Global logical Unified data design for

Independent of both
al view entire organization

Defines storage
Logical Software Dependent,
Internal structures & access
implementation Hardware Independent
methods

Actual storage Software & Hardware Determines how data is

Physical
details Dependent physically stored

🧠 7. Key Takeaways
 Database design moves from high-level abstraction to detailed
implementation.
 The Entity Relationship (ER) Model is the most popular conceptual
model.
 A well-designed conceptual model ensures:
o Consistency across departments

o Data integrity and security

o Easier maintenance and scalability

💬 “A good DBMS can’t fix a bad database design — design comes first!”