Advantages :

• Data is structured

• Conceptual and simple

• security through access control

• data integrity

• predicted performance

Disadvantages:

● Only limited to one to many relationships

● difficult to modify or edit

● data redundancy

● complex implementation

Network model

Advantages:

□ support many to many relationships

□ reduced to data redundancy

□ efficienct data access

Disadvantages:

▪︎ complex

▪︎ not user friendly

Relational model

Advantages:

¤ flexible

¤ data integrity

¤ no data redundancy

Disadvantages:

◇ too rigid

◇ too expensive for large scale

◇ hard to for super fast needs

Advantages:

Easy to understand (simple parent-child structure)

Fast for 1-to-many data access

Good data integrity and security

Disadvantages:

Rigid structure (hard to modify)

Only supports 1-to-many relationships

Data can be duplicated

Complex to implement with pointers

Network Model

Advantages:

Supports many-to-many relationships

Reduces data duplication

Fast access through multiple paths

Disadvantages:

Hard to design and manage

Needs technical knowledge (no standard query language like SQL)

Less user-friendly

Relational Model

Advantages:

Very flexible and widely used

Supports complex queries and all relationship types

Prevents data duplication (using normalization)

Ensures data integrity with keys

Disadvantages:

Can be hard to change structure

Expensive for large systems

Not ideal for real-time or unpredictable data

Hierarchical Data Model

Advantages:

-Simple and easy to understand.

-Fast access for large volumes of data with a clear parent-child relationship.

-Data integrity is maintained through parent-child structure.

-Good for applications with fixed, predictable relationships.

Disadvantages:

-Rigid structure — difficult to reorganize or modify.

-Redundancy if child records need multiple parents.

-Complex to manage if hierarchy changes.

-Poor support for many-to-many relationships.

Network Data Model

Advantages:

-Supports complex relationships (many-to-many).

-More flexible than hierarchical model.

-Faster data access for some use cases.

-Reduces redundancy through shared relationships.

Disadvantages:

-Complex structure and difficult to design/manage.

-Difficult for users to understand and navigate.

-Requires knowledge of physical links (pointers).

-Poor portability and low independence from system.

Relational Data Model

Advantages:

-Easy to understand and use (tables and SQL).

-Highly flexible — supports ad-hoc queries.

-Strong theoretical foundation (based on set theory).

-High data independence and good scalability.

-Easy to maintain and modify.

Disadvantages:

-Slower for complex, large-volume operations.

-Requires more memory and processing.

-Joins can be performance-intensive.

-May not model hierarchical or network relationships as naturally.

Hierarchical Model

Advantages:

Easy to understand (simple parent-child structure)

Fast for 1-to-many data access

Good data integrity and security

Disadvantages:

Rigid structure (hard to modify)

Only supports 1-to-many relationships

Data can be duplicated

Complex to implement with pointers

Network Model

Advantages:

Supports many-to-many relationships

Reduces data duplication

Fast access through multiple paths

Disadvantages:

Hard to design and manage

Needs technical knowledge (no standard query language like SQL)

Less user-friendly

Relational Model

Advantages:

Very flexible and widely used

Supports complex queries and all relationship types

Prevents data duplication (using normalization)

Ensures data integrity with keys

Disadvantages:

Can be hard to change structure

Expensive for l

arge systems

Not ideal for real-time or unpredictable data

Advantages:

Easy to understand.

Fast for simple, one-to-many data.

Disadvantages:

Hard to change structure.

Can’t handle many-to-many relationships.

Data might get repeated.

2. Network Model

Advantages:

Can handle complex, many-to-many relationships

Less repeated data.

Fast for complicated queries.

Disadvantages:

Hard to design and manage.

Needs skilled programmers.

No standard way to ask questions (no SQL).

3. Relational Model

Advantages:

Very flexible and powerful.

Easy to organize and search data.

No repeated data.

Disadvantages:

Can be expensive for big systems.

Not good for messy or unpredictable data.

Harder to change structure once set up.

Advantages

1. Easy to understand with clear parent-child relationships

2. Data Integrity

Disadvantages

1. Only supports one-to-many relationships

2. Data Redundancy

2. Network Model

Advantages

1. Reduced Data Redundancy

2. Supports complex many-to-many relationships

Disadvantages

1. No standard query language

2. Managing pointer structures can be challenging

3. Relational Model

Advantages

1. No data redundancy

2. Data integrity

Disadvantages

1. Changingthe structure can be complicated.

2. Relational database systems can be expensive

Scenario 1: Employee Management System

Most Suitable Data Model: Hierarchical Model

Justification:

The structure described is strictly top-down, where each employee reports to one manager, who reports to a department head, who then reports to the CEO. 

Scenario 2: School Enrollment System

Most Suitable Data Model: Relational Model

Justification:

Students can enroll in multiple courses, and each course can have many students (many-to-many relationship). This complex relationship is best handled using the Relational Model.

Scenario 3: Government Document System

Most Suitable Data Model: Hierarchical Model

Justification:

The description shows a strict hierarchy: ministries > departments > units. Each unit belongs to only one department and each department to one ministry. This fixed hierarchy is best modeled with the Hierarchical Model, reflecting the one-to-many relationships in a tree-like structure.

Scenario 4: Library System

Most Suitable Data Model: Relational Model

Justification:

A book can have multiple authors and an author can write multiple books (many-to-many relationship). This type of relationship is best modeled using the Relational Model, which allows tables to relate through foreign keys and handle interconnected entities flexibly.

Scenario 5: Telecom Billing System

Most Suitable Data Model: Network Model

Justification:

There are complex connections-customers with multiple connection types, shared connections among customers (like family plans), and cross-references. The Network Model is ideal here as it supports many-to-many relationships with flexible linkages among entities.

Scenario 6: Online Shopping Platform

Most Suitable Data Model: Relational Model

Justification:

Customers place many orders, and each order contains many products. One product can also appear in many orders. These many-to-many relationships are best handled using the Relational Model, with separate tables for customers, orders, products, and linking tables like order_details.

Advantages:

Simple structure (like a tree).

Fast access for 1-to-many data.

Good data integrity and security.

Disadvantages:

Rigid structure, hard to modify.

Only supports 1-to-many relationships.

Redundant data and complex implementation.

🟩 Network Model

Advantages:

Supports many-to-many relationships.

Reduces data duplication.

Faster for complex queries.

Disadvantages:

Hard to design and manage.

No standard query language (like SQL).

Not user-friendly.

🟥 Relational Model

Advantages:

Very flexible (1-to-1, 1-to-many, many-to-many).

Uses SQL, easy to use.

No data redundancy; strong data integrity.

Disadvantages:

Can be rigid for changes.

Expensive for large systems.

Not ideal for real-time or messy data.

• Easy to visualize how data is stored which helps developers quickly understand how system is organized

• Can avoid records with missing references which increases data reliability and consistency

• Can handle one-to-many relationships efficiently compared to other model

Disadvantages of Hierarchical Model

• Any changes in structure require redesigning the entire database

• Some data might be duplicated if it is needed in multiple branches

• Must clearly define the full hierarchy in advance cause it’s difficult to modify once defined

Advantages of Network Model

• Since records can be connected in multiple ways, it’s more realistic and flexible

• Can avoid duplicating the same data cause multiple parent records can point to the same child record

• Queries that involve mutation relationship can be processed faster

Disadvantages of Hierarchical Model

• Having multiple connections makes the structure harder to visualize and understand

• Ordinary users can’t easily access or retrieve data since the model is complex

• Too many pointers make it hard to build the model

Advantages of Relational Model

• Allows for powerful and flexible queries using SQL

• Prevent invalid and duplicate entries and make sure all data is accurately linked

• Breaks data to multiple related tables to avoid repeating the same data

Disadvantages of Relational Model

• Not flexible and limiting for unstructured and varied data

• Less suitable for applications that require fast performance at a very large scale

• High-end relational database systems can be very expensive

Justification: The employee reporting structure follows a clear top-down hierarchy, which is perfectly represented by the parent-child relationships of the hierarchical model.

2. Network Model

Justification: The many-to-many relationship between students and courses requires the flexible connections that the network model provides.

3. Hierarchical Model

Justification: The fixed organizational structure of ministries, departments and units naturally fits the tree-like hierarchy of this model.

4. Network Model

Justification: The complex interconnections between books and multiple authors are best handled by the network model's ability to manage many-to-many relationships.

5. Network Model

Justification: Shared telecom connections between customers need the network model's capability to link multiple parents to single records.

6. Relational Model

Justification: The online shopping system's multiple related tables are ideally organized using the relational model's table structure with keys.

🟦 Best Model: Hierarchical Model

The structure is strictly top-down (CEO → Department Head → Manager → Employee).

Each employee has only one manager → fits a parent-child (1-to-many) model.

Scenario 2: School Enrollment System

🟩 Best Model: Network Model

Students can enroll in multiple courses, and courses can have many students.

This many-to-many relationship is ideal for the flexible links in a network model.

Scenario 3: Government Document System

🟦 Best Model: Hierarchical Model

Fixed hierarchy: Ministry → Department → Unit.

Each unit belongs to one department, matching a tree-like structure.

Scenario 4: Library System

🟩 Best Model: Network Model

Books can have multiple authors, and authors can write multiple books.

Many-to-many relationships → perfect for network model's flexibility.

Scenario 5: Telecom Billing System

🟩 Best Model: Network Model

Customers and connections can be shared and linked in complex ways.

Cross-references and many-to-many relationships are better managed in a network model.

Scenario 6: Online Shopping Platform

🟥 Best Model: Relational Model

Customers → Orders → Products with many-to-many and 1-to-many relations.

Easily modeled using tables and foreign keys (standard in relational databases).

Adventage:

Easy to see the data flow

Parent-child links are maintained

Fast access for structured data

Access control through levels

Same speed for hierarchical data access.

Disadvantage:

Need to redesign the whole structure.

Only supports one-to-many.

Same data might be repeated in different parts

Need careful planning before building

Network Model

Adventage:

Can handle many-to-many relationships

Shared records reduce repeated data

Faster than hierarchical model for complex data access.

Disadvantage:

Complex structure, needs planning

Requires programmers to manage and access data

Changes in one part may affect others, not modular.

Relational model

Adventage:

Supports many-to-many relationships using extra tables.

Foreign keys keep relationships accurate and valid.

Uses nomination to avoid repeating the same data.

Disadvantage:

Changing structure ,like adding columns is hard.

Some systems are costly for businesses.

May not scale well for very high speed needs.

Advantages

Data Integrity-

Automatic maintenance of parent-child links

Prevents orphaned records

security-Built-in access control through hierarchy

Predictable Performance-

Consistent speed for hierarchical data access

Disadvantages

Structural Rigidity

*Difficult to modify existing structure

*Adding new relationships requires redesign

Data Redundancy

Same data may be duplicated in multiple branches.

Network Model

course and student relationship

Advantages

Relationship Flexibility-Supports many to many relationships

Reduced data redundancy-shared records eliminate duplication

Efficient data access-Direct access to records via multiple paths

Disadvantages

complexity-difficult to design and implement

lack of user-friendliness

no standard query language

Relational Model

Advantages

flexibility-supports complex queries

handle many to many relations

no data redundancy-normalization minimizes duplication

Disadvantages

Too rigid-changing the structure

expensive for big system-some data base cost a lot of money for businesses

hard to scale for super fast needs-not ideal for apps needing ideal updates.

The structure is top-down (employee → manager → department head → CEO)

2. Relational

Students and courses have a many-to-many relationship

3.Hierarchical

There is a fixed hierarchy (ministry → department → unit), with each level belonging to only one parent.

4.Relational

Books and authors have a many-to-many relationship

5. Network

Justification:

Customers and connections have complex, cross-linked relation

6. Relational

Customers, orders, and products are all related in many-to-many ways

Hierarchical model

Here data is sorted in levels specifically in top down levels where order is given from top positions to lower positions

Scenario 2

Relational model

Each student can register for many courses and many course can have many students creating a many to many relationship. Here each student has a multiple parents courses.

Scenario 3

Hierarchical model

This system has a fixed hierarchy from top to bottom. One goverment has many ministries and each ministry has multiple departments and each of them has several units which depicts a rigid hierarchy.

Scenario 4

Network model

Each book has multiple authors and each author can write multiple books creating a many to many relationship. Network model is ideal for this.

Scenario 5

Network model

Connections are shared between customers and some customers have multiple connections creating complex many to many relationships with cross references

Scenario 6

Relational model

One customer can make many orders and one item can be ordered by many customers. This has both one to many and many to many relationships. So relational model is better for this.

1. Easy to Understand

Shows clear parent-child relationships.

Easy to see the structure of the database.

2. Keeps Data Accurate

Parent-child links are updated automatically.

Prevents records from being left without a parent (no "orphan" data).

3. Fast and Efficient

Very quick for finding data in a tree-like structure.

Works best for one-to-many relationships (like one parent with many children).

4. Secure

Data access can be controlled using the hierarchy (who can see what).

5. Predictable Speed

Performance stays fast and steady when using a hierarchical structure.

Disadvantages of Hierarchical Model

1. Hard to Change

Changing the structure is difficult.

Adding new relationships means redesigning the database.

2. Limited Flexibility

Only supports one-to-many relationships.

Can’t directly handle many-to-many relationship.

3. Data Repeats

The same data might be copied in different branches, causing duplication.

4. Complicated Setup

Needs careful planning of the hierarchy.

Using pointers (links between data) can get confusing.

Advantages of Network Model

1. Flexible Relationships

Supports complex many-to-many relationships.

More flexible than the hierarchical model.

2. Less Repeated Data

Shared records reduce data duplication.

3. Fast Data Access

Records can be reached from different paths.

Faster than hierarchical model for complex queries.

Disadvantages of Network Model

1. Complicated Design

Hard to design and build.

Requires understanding of pointers (links between records).

2. Not User-Friendly

No standard query language like SQL.

Users need a programmer’s help to access data.

Advantages of Relational Model

1. Flexible Queries

Can answer complex questions (e.g., “Find all students enrolled in Math and Science”).

Supports many-to-many relationships using junction tables.

2. Strong Data Accuracy (Data Integrity)

Primary Keys prevent duplicate records.

Foreign Keys make sure relationships between tables are valid.

3. No Data Redundancy

Normalization reduces data duplication.

Example: Student details are stored once and linked elsewhere when needed.

Disadvantages of Relational Model

1. Hard to Change Structure

Adding new columns or changing design can be difficult.

2. Not Great for Messy Data

Doesn’t work well with unpredictable or unstructured data (like social media posts).

3. Can Be Expensive

Some systems (like Oracle) are costly f

or big businesses.

4. Not for Real-Time Needs

May not be fast enough for apps needing instant updates (like stock trading apps).

We should use hierarchical Model because this system is parent- children kind of organization and concerned with one to many relation.

2.School Enrollment System

We should use network model for this case because many different courses are related to many students and also many students can apply many courses. This one is concerned with many to many relation.

3. Government Document System

We should use hierarchical model for this one because although there are several units, they are under only one respective department and it is like parent to children relationship.

4. Library System

This one should use network model because many-to-many relationship between books and authors (a book can have many authors, and an author can write many books).

Network models support complex interconnections and allow shared access through pointers.

5. Telecom Billing System

We should use network model in this case because it's sharing multiple types of network between many different customer and it is likely many to many relationship.

6. Online Shopping Platform

This one, we should use relational database and because The platform involves many-to-many relationships managed via junction tables.

Relational models handle this structure well using foreign keys and are great for complex queries, data ac

curacy, and scalability.

The employee reporting structure follows a top-down hierarchy, which is represented by the parent-child relationships of the hierarchical model.

2. Network Model

The many to many relationship between students and courses requires the flexible connections that the network model provides.

3. Hierarchical Model

The fixed organizational structure of ministries, departments and units naturally fits the tree-like hierarchy of this model.

4. Network Model

The complex interconnections between books and multiple authors are best handled by the network model to manage many-to-many relationships.

5. Network Model

Shared telecom connections between customers need the network model's capability to link multiple parents to single records.

6. Relational Model

The online shopping system's multiple related tables are organized using the relational model's table structure with keys.

1. Easy to Understand - simplicity

• Simple parent-child structure

• Easy to see the data flow

2. Data Integrity

• Parent-child links are maintained (automatic maintenance)

• No missing or broken records

3. High Efficiency

• Fast access for structured data

• Works well for one-to-many relationships

4. Built-in Security

• Access control through levels (e.g., top to bottom)

5. Consistent Performance

• Same speed for similar queries

Disadvantage of Hierarchical Model

1. Rigid Structure

• Difficult to reorganize or add new relationships

• Not flexible for complex data

2. Limited relationships

• only supports one to many relationships

Advantages of Network Model

1. Flexible Relationships

• Can have many-to-many relationships.

• More flexible than hierarchical model.

2. Less Data Duplication

• Shared records reduce repeated data.

3. Fast Data Access

• Can reach data through multiple paths.

• Faster than hierarchical model for complex queries.

Disadvantages of Network Model

1. Hard to Design

• Complex structure, needs planning.

• Must understand how pointers work.

2. Not User-Friendly

• No easy language like SQL.

• Requires programmers to manage

Advantages of Relational Model

1. Flexibility

• Can run complex queries easily.

• Supports many-to-many relationships using extra tables.

2. Data Integrity

• Primary keys prevent duplicate data.

• Foreign keys keep relationships accurate and valid.

3. No Data Redundancy

• Uses normalization to avoid repeating the same data

Disadvantages of Relational Model

1. Too Rigid

• Changing structure is hard.

• Not suitable for unstructured data

2. Expensive for Big Systems

• Some systems are costly for businesses.

3. Not Good for Real-Time Apps

• Slow for apps that need instant updates

• May not scale well for very high-speed needs

The structure is like a family tree. Each employee has one boss, and the flow goes from top to bottom.

2. Relational Model

A student can join many classes, and each class has many students. This is a many-to-many relationship. The relational model uses tables and makes it easy to link and manage both sides.

3. Hierarchical Model

The structure is fixed and clear Units. Each level belongs to one higher level.

4. Network model

Many to many relationships with authors and books

And it consists of many connected parent child relationships

5. Network model

Many to many relationships it is complex and flexible

And multiple connections within the model.

6. Relational Model

Customers place many orders, and each order includes many products.

Products can also appear in many different orders.

Tree like structure with one to many relationships as the hierarchical model and single parent rule like each employee reports to one manager, top to down structure

2. Relational model

Many to many relationships as relational model, and the structure consists of tables (enrollment table )

3. Hierarchical model

Single parent rule each unit belongs to one person

Tree structure

4. Network model

Many to many relationships with authors and books

And it consists of many connected parent child relationships

5. Network model

Many to many relationships it is complex and flexible

And multiple connections within the model6. Relational model

Many to many relationships and it is managed using the tables

Advantages:

* Simple and easy to use when the data has a clear parent-child relationship.

* Data retrieval is fast and predictable due to the tree-like structure.

* Enhances data integrity with defined parent-child relationships.

Disadvantages:

* Rigid structure: difficult to make changes to the hierarchy.

* Redundancy: data repetition is possible if children need to associate with multiple parents.

* Complex to manage many-to-many relationships.

2. Network Model

Advantages:

* Supports many-to-many relationships.

* Flexible and more efficient than the hierarchical model for complex relationships.

* Faster access to data through multiple paths.

Disadvantages:

* Complex structure, harder to design and maintain.

* Requires skilled programmers to manage the pointers and links.

* Changes in structure require significant restructuring.

3. Relational Model

Advantages:

* Easy to use and understand (uses tables).

* High flexibility in querying data using SQL.

* No need to know the physical data structure.

Disadvantages:

* Slower performance with large databases compared to hierarchical or network models.

* More processing power is needed due to complex joins.

* Poor representation of real-world relationships in some cases.

Advantages:

1.Conceptual Simplicity

Easy to understand parent-child relationships and clear database structure visualization.

2.Data Integrity

Automatic maintenance of parent-child links and prevents orphaned records

3.Efficiency

Fast access for hierarchical queries and excellent performance for 1-to-many relationships

4. Security

Built-in access control through hierarchy

5. Predictable Performance

Consistent speed for hierarchical data access

Disadvantages:

1.Structural Rigidity

Difficult to modify existing structure and adding new relationships requires redesign

2.Limited Relationships

Only supports 1-to-many relationships and cannot directly represent many-to-many

relationships

3. Data Redundancy

The same data may be duplicated in multiple

branches

4. Complex Implementation

It requires careful planning of hierarchy and pointers can become complex

Network model

Advantages:

1.Relationship Flexibility

Supports complex many - to - many

relationships and more versatile than hierarchical model

2.R reduced Data Redundancy

Share records eliminate duplication

3.Efficient Data Access

Direct access record via multiple paths and faster than hierarchical for complex queries

Disadvantages:

1.Complexity

Difficult to design and implement and requires understanding of pointer structure

2.Lack of User - Friendliness

No standard query language ( unlike SQL ) and programmers needed for data access

Relational model

Advantages:

1.Flexibility

Supports complex queries ( e . g . , " Find all

students enrolled in Math and Science " ) .

Handle many - t o - many relationship via Junction tables .

2.Data Integrity

Primary Keys prevent duplicate recordsand foreign keys ensure validation relationship.

3.No Data Redundancy

Normalization minimize duplication

( e . g . ,store students details once, referenced elsewhere ) .

Disadvantages:

1.Too Rigid

Changing the structure ( e . g . , adding a

new column ) can be complicated .

Not good for messy / unpredictable data

( e . g . , social media post ) .

2.Expensive for Big Systems

Some databases ( like Oracle ) cost a lot

of money for businesses .

3.Hard to scale for Super Fast Ne

eds

Not ideal for apps needing instant updates ( e . g . , stock trading systems )

The most suitable model is the Hierarchical Model.

Since each employee reports to single manager, manager to department heads, and to the CEO, the structure is hierarchical. It maintains clear levels, one to many relationships, and vertical dependencies across the organization.

Scenario 2: School Enrollment System

The most suitable model is the Relational Model.

The system follows a many-to-many data model, which is best handled by a relational model in databases. The mutual, flexible, shared relationships between entities make it unsuitable for a hierarchical model, which only supports one-to-many.

Scenario 3:

The most suitable model is the Hierarchical Model.

The structure described is clearly a hierarchical data model because it follows a strict, one-to-many, top-down relationship without overlap or cross-connection.

Scenario 4:

The most suitable model is the Relational Model.

The system fits a many-to-many relational data model because books and authors are linked in both directions, and the relationship is flexible and shared.

Scenario 5:

The most suitable model is the Network Model.

The system follows a network model because it handles many-to-many relationships through interconnected data, cross-references, and shared ownership between entities

Scenario 6:

The most suitable model is the Relational Model.

The system uses a relational model because it efficiently handles multiple interconnected entities and supports many-to-many relationships using linking tables.

1. Hierarchical because the structure is top-down (employee → manager → department head → CEO)// parent child relationship

2. Relational because the students and courses have a many-to-many relationship

3.Hierarchical because it has a fixed hierarchy (ministry → department → unit), with each level belonging to only one parent.

4.Relational because the books and authors have a many-to-many relationship

5. Network because the customers and connections have complex, cross-linked relation

6. Relational because the customers, orders, and products are all related in

many-to-many ways

The most suitable model is the Hierarchical Model.

Since each employee reports to single manager, manager to department heads, and to the CEO, the structure is hierarchical. It maintains clear levels, one to many relationships, and vertical dependencies across the organization.

Scenario 2: School Enrollment System

The most suitable model is the Relational Model.

The system follows a many-to-many data model, which is best handled by a relational model in databases. The mutual, flexible, shared relationships between entities make it unsuitable for a hierarchical model, which only supports one-to-many.

Scenario 3:

The most suitable model is the Hierarchical Model.

The structure described is clearly a hierarchical data model because it follows a strict, one-to-many, top-down relationship without overlap or cross-connection.

Scenario 4:

The most suitable model is the Relational Model.

The system fits a many-to-many relational data model because books and authors are linked in both directions, and the relationship is flexible and shared.

Scenario 5:

The most suitable model is the Network Model.

The system follows a network model because it handles many-to-many relationships through interconnected data, cross-references, and shared ownership between entities

Scenario 6:

The most suitable model is the Relational Model.

The system uses a relational model because it efficiently handles multiple interconnected entities and supports many-to-many relationships using linking tables.

• Easy to visualize how data is stored which helps developers quickly understand how system is organized

• Can avoid records with missing references which increases data reliability and consistency

• Can handle one-to-many relationships efficiently compared to other model

Disadvantages of Hierarchical Model

• Any changes in structure require redesigning the entire database

• Some data might be duplicated if it is needed in multiple branches

• Must clearly define the full hierarchy in advance cause it’s difficult to modify once defined

Advantages of Network Model

• Since records can be connected in multiple ways, it’s more realistic and flexible

• Can avoid duplicating the same data cause multiple parent records can point to the same child record

• Queries that involve mutation relationship can be processed faster

Disadvantages of Hierarchical Model

• Having multiple connections makes the structure harder to visualize and understand

• Ordinary users can’t easily access or retrieve data since the model is complex

• Too many pointers make it hard to build the model

Advantages of Relational Model

• Allows for powerful and flexible queries using SQL

• Prevent invalid and duplicate entries and make sure all data is accurately linked

• Breaks data to multiple related tables to avoid repeating the same data

Disadvantages of Relational Model

• Not flexible and limiting for unstructured and varied data

• Less suitable for applications that require fast performance at a very large scale

• High-end relational database systems can be very expensive

Advantage: Simple structure and easy to access if data has a clear parent-child relationship.

Disadvantage: difficult to make changes

Cannot manage many-to-many relationships.

2. Network Data Model

Advantage: Supports complex many-to-many relationships with faster access.

Disadvantage: Complex structure and hard to maintain or understand.

3. Relational Data Model

Advantage: Flexible, easy to use

No data redundancy with primary key ( no duplication)

Disadvantage: Cannot make changes easily to data tables

Costly for big database system

Advantage

1. Easy to understand

2. Automatic maintenance

Disadvantages

1. Difficult to modify

2. Only support one to many relationships

   
   

Network

Advantage

1. Support complex many to many relationships

2. Can eliminate duplication

Disadvantages

1. Difficult to design

2. No standard query language

Relational model

Advantages

1. Flexible

2. Primary key prevent duplication

Disadvantages

1. Too rigid

2. Expesive for big systems

Advantages -

Conceptual and simple

Data integrity

Efficiency

Predictable performance

Disadvantages -

Data redundancy

Complex implementation

Network model

Advantages-

Flexible relationships

Reduced data redundancy

Efficient data access

Disadvantages -

Complex

Lack of user friendliness

Relational model

Advantages:

Flexible

Data integrity

No data redundancy

Disadvantages -

Complicated and rigid

Expensive for large scale

Hard to scale for super fast needs

(Advantages)

• Clear database structure

• Fast access

(Disadvantages)

• Difficult to modify

• Only support 1-to-many

Network model

(Advantages)

• More versatile

• Direct access to records

(Disadvantages)

• Difficult to design

• No standard query language

Relational models

(Advantages)

• No data redundancy

(Disadvantages)

• Too rigid

• High cost

1.Hierarchical Model

Advantages:

• Fast access: Data retrieval is quick if the structure is followed (like parent → child).

• Easy to understand: Works like a family tree – clear parent-child relationships.

  Disadvantages:

• Rigid structure: You must follow the set path (top to bottom), not flexible.

• No many-to-many: Cannot represent complex relationships easily.

Justification:

Best for simple and fixed structures like organizational charts or file systems.

2.Network Model

Advantages:

• Flexible connections: Allows many-to-many relationships.

• Faster navigation: Good for complex data relationships.

Disadvantages:

• Hard to design and use: Complex pointers make it difficult to understand.

• Changes are hard: Modifying the structure is time-consuming.

Justification:

Suitable when multiple links between records are needed, like airline routes.

3.Relational Model

Advantages:

• Simple and flexible: Uses tables; easy to understand and use.

• Powerful query language: SQL makes searching and updating easy.

Disadvantages:

• Slower for large data: Not as fast as others for huge, complex data.

• Requires more storage: Tables may repeat data (redundancy).

Justification:

Most widely used today – ideal for general-purpose applications like banking or e-commerce.

Advantages:

1.Organized structure

2.Easy to understand

Disadvantages

1.Repetition

2.One-way link

2. Network Model

Advantages

1.More flexible

2.Faster searching

Disadvantages:

1.Complex structure

2.Difficult to manage

3. Relational Model

Advantages:

1.Simple tables

2.Easy to use

Disadvantages:

1.Slower for big data

2.expensive

Advantages

- Easy to understand the data structure and relationships

- Clear database structure visualization

- Ensure security through access control based on hierarchy

Disadvantages

- Adding new relationships requires redesign

- Requires careful planning of hierarchy

- Only support one to many relationships

Network Model

Advantages

- Support many to many relationships

- Reduce data duplication

- Efficient data access

Disadvantages

- Difficult to design and implement

- Not user friendly

Relational Model

Advantages

- Handles many to many relationships

- Primary keys prevent data duplication

- Foreign keys ensure valid relationship

Disadvantages

- Too complicated to change the structure

- Expensive for large model

- Less suitable for applications that require fast performance at a very large scale

hierarchical, because every employee report to only a single manager. the system required every employee to report to one person above them so a hierarchical model fit the most.

scenario 2

relational, because each student can have many courses and courses can have many students, a relational model is suitable for this multiple relationship.

scenario 3

hierarchical, because the structure is fixed so it is already organized like a tree, for example; units are under departments, departments are under ministries, therefore hierarchical model fits the best.

scenario 4

network, because books can have multiple authors and authors can write many books. since they're linked to each others, a network model fits this scenario.

scenario 5

network, because customers and their connections are all linked in different ways like a shared plan. a network model helps show all of the connections clearly.

scenario 6

relational, because all of the customers, orders and products all are connected. since each order may include many products, everything is connected in different ways, therefore a relational model works the best.

Advantages

1. Simple and Easy to Understand :

The structure is like a tree (parent-child), making it easy to follow, especially for beginners.

2. Data Integrity and Security :

The parent-child relationship enforces clear links between data, reducing redundancy and ensuring consistency.

3. Efficient for Certain Queries :

It performs well for operations that follow the hierarchy

Disadvantages

1. Lack of Flexibility :

Each child can have only one parent, making it hard to model complex many-to-many relationships.

2. Difficult to Modify Structure :

Any change in the hierarchy (like adding a new relationship) may require redesigning the entire model.

3. Data Redundancy :

Since each parent-child path is fixed, similar data might need to be repeated in different branches.

Network Model

Advantages

1. Supports Many-to-Many Relationships :

Unlike the hierarchical model, a child can have multiple parents, which makes the structure more flexible.

2. Faster Data Access :

Data can be accessed quickly through multiple paths.

3. More Efficient Use of Storage :

Reduces data redundancy by allowing shared relationships between records.

Disadvantages

1. Complex Structure :

The multiple relationships and links can make the model difficult to design, understand, and manage.

2. Difficult to Modify :

Making changes to the database structure (like adding new relationships) is complicated and may affect many parts of the system.

Relational Model

Advantages

1. Flexibility in Queries :

Powerful query languages like SQL allow easy data retrieval, filtering, and manipulation.

2. Data Accuracy and Integrity :

The use of keys and constraints helps maintain accurate, consistent, and reliable data.

Disadvantages

1. Complex Joins Can Impact Performance :

When queries involve many tables with joins, it can slow down performance and make the system harder to optimize.

2. High Hardware and Software Requirements

Relational databases may require more memory, processing power, and advanced software to manage efficiently.

Advantages:

1.Conceptual Simplicity:

-Easy to understand parent-child relationships

-Clear database structure visualization.

2.Data Integrity:

-Automatic maintenance of parent-child links

-Prevents orphaned records.

Disadvantages of hierarchical model:

1.Structural Rigidity:

-Difficult to modify existing structure

-Adding new relationships requires redesign.

2.Limited Relationships:

-Only supports 1-to-many relationships

-Cannot directly represent many-to-many

relationships.

Network model advantages:

1. Relationship flexibility:

-Supports complex many to many relationships

-more versatile than hierarchical model

2. Reduced data redundancy:

-Shared records eliminate duplication

Disadvantages of network model:

1.Complexity:

-Difficult to design and implement

-Requires understanding of pointer structures

2.Lack of user-friendliness:

-No standard query language (unlike SQL)

-Programmers needed for data access

Advantages of relational model:

1. Flexibility:

-Supports complex queries (e.g., "Find all students enrolled in Math and Science").

-Handles many-to-many relationships via junction tables.

2. Data Integrity:

-Primary keys prevent duplicate records.

-Foreign keys ensure valid relationships.

Disadvantages of relational model:

1.Expensive for Big Systems:

-Some databases (like Oracle) cost a lot of money for businesses.

2. Hard to Scale for Super Fast Needs:

-Not ideal for apps needing instant updates (e.g., stock trading systems).

Advantages:

1. Simplicity- easy to understand relation between parent-child and clear database

2. Data Integrity- automatically maintains parent-child link and prevents old incorrect record

   
   

   Disadvantages:

   1. Structural Movements- difficult to modify and when add new relation need to redesign whole structure

   2. Data redundancy- same data can be duplicated in multiple childs

   Network model

   Advantages:

   1. Reduced data redundancy- when sharing records it eliminates duplication

   2. Efficient access- direct access to data using multiple routes and faster than H.model

   Disadvantages:

   1. Complex- Hard to design and deploy and need to understand pointer bodies

   2. Non user-friendliness- No standard query language like SQL and need programmers for accessing data

   Relational Model

   Advantages:

   1. Flexibility- support complex requests and handles many to many function by junction tables

   2. Data integrity- primary key prevents duplication of records and foreign key ensures validity

   Disadvantages:

   1. Expensive for huge systems- some are costly for businesses

   2. Rigidity- changing like when adding new columns is difficult and not preferred for unpredictable data

Scenario 1: Employee Management System

Best Model: Hierarchical Model

Justification:

It follows a strict top-down structure (Employee → Manager → Dept Head → CEO). Each employee reports to one manager only — a clear parent-child relationship.

Scenario 2: School Enrollment System

Best Model: Relational Model

Justification:

A student can enroll in many courses, and each course has many students (many-to-many). Tables with foreign keys make this easy in the relational model.

Scenario 3: Government Document System

Best Model: Hierarchical Model

Justification:

The structure is fixed and top-down: Ministry → Department → Unit. Each unit belongs to one department, like a tree structure.

Scenario 4: Library System

Best Model: Network Model

Justification:

Books ↔ Authors have many-to-many relationships. A book can have many authors, and authors can write many books — best handled by a flexible network model.

Scenario 5: Telecom Billing System

Best Model: Network Model

Justification:

Customers can have many connections, and some connections are shared — complex relationships with cross-links, which are well supported in network models.

Scenario 6: Online Shopping Platform

Best Model: Relational Model

Justification:

Customers → Orders → Products involve many-to-many relationships (e.g., products in many orders), best handled with relational tables using primary and foreign keys.

Hierarchical Model

Advantages :

• Data is structured

• Conceptual and simple

• security through access control

• data integrity

• predicted performance

Disadvantages:

● Only limited to one to many relationships

● difficult to modify or edit

● data redundancy

● complex implementation

Network model

Advantages:

•support many to many relationships

• reduced to data redundancy

•efficienct data access

Disadvantages:

•complex

•not user friendly

Relational model

Advantages:

•flexible

• data integrity

•no data redundancy

Disadvantages:

• too rigid

• too expensive for large scale

• hard for super fast needs

Advantages:

Conceptual Simplicity

---- Easy to understand parent-child relationships

Data Integrity

----Automatic maintenance of parent-child links

Efficiency

----Fast access for hierarchical queries

Disadvantages:

1.Structural Rigidity

----Difficult to modify existing structure

2.Limited Relationships

----Only supports 1-to-many relationships

3. Data Redundancy

----Same data may be duplicated in multiple branches

Network model

Advantages:

Relationship Flexibility

-----Supports complex many-to-many relationships

More versatile than hierarchical model

Reduced Data Redundancy

-----Shared records eliminate duplication

Efficient Data Access

----Direct access to records via multiple paths

Faster than hierarchical for complex queries

Disadvantages:

Complexity

---Difficult to design and implement

Requires understanding of pointer structures

Lack of User-Friendliness

----No standard query language (unlike SQL)

Programmers needed for data access

Relational Model:

Advantages:

Flexibility

----Supports complex like hoe to handles many-to-many relationships via junction tables.

Data Integrity

-----Primary Keys prevent duplicate records.

Foreign Keys ensure valid relationships.

No Data Redundancy

----Normalization minimizes duplication (e.g., store student details once, reference elsewhere).

Disadvantages:

Too Rigid

-----Changing the structure

Hard to Scale for Super Fast Needs

-----Not ideal for apps needing instant updates

Model: Hierarchical

Reason: it follows a top-down and tree-like structure with one-to-one reporting.

Scenario 2: School Enrollment System

Model: Relational

Reason: it has Many-to-many relationship between students and courses can be handled with relational tables.

Scenario 3: Government Document System

Model: Hierarchical

Reason: it is fixed, one-way relationships between ministry and department unit that match a tree structure.

Scenario 4: Library System

Model: Relational

Reason: Books and authors have many-to-many relationships, which can be handled by relational databases .

Scenario 5: Telecom Billing System

Model: Network

Reason: there are many shared connections between multiple customers.

Scenario 6: Online Shopping Platform

Model: Relational

Reason: Customers, orders, and products are linked with many-to-many relationships.

●Easy to understand

● Fast access for 1 - to many data

● Security through access control

Disadvantages

●Only support to 1 to many relationship

● Data can be duplicated

●Difficult to edit

Network model Advantage

■support to many relationship

■Efficient Data access

■Fast Data access through multiple paths

Disadvantages

■hard to design and manage

■ less user friendly

■ complex

Relational model Advantage

♡ very flexible

♡ prevent Data duplication

♡ supports complex queries

Disadvantages

♡ can be hard to change structure

♡expensive for big system

♡ unpredictable data

Advantage

1. Easy to understand (simple parent - child structure)

2. Fast access for large volume for data

Good data integrity and security

Disadvantage

1. Rigid structure

2. Only supports 1 to many relationships

3. Data can be duplicated

Complex to implement with pointers

Network Model

Advantage

1. Support many to many relationships

2. Reduce data duplication

3.Fast access through multiple paths

Disadvantage

1. Less user friendly

2. Hard to design and manage

Needs skilled programmers

Relational model

Advantage

1. No data redundancy

2. Very flexible

3. Data integrity

Disadvantage

1. Complicated and rigid

2. Expensive for large scale

3. Hard to scale for super fast needs

Advantages

1.Easy to understand the relationships between the parent- child

2.Clear structure

3.keeps data connected correctly

Disadvantages

1.hard to change the structure

2.only one to many relationship

3.pointers can be become complex

Network model

Advantages

1.support complex many to many relationship

2.more flexible than hierarchical

Disadvantages

1.difficult to design and implement

2.programmers needed for data access

Relational model

Advantages

1.support many to many relationship via junction tables

2.prevent duplicate records and

3.can do very complex searches easily

Disadvantages

1.hard to change the structure

2.some data base systems can be expensive

3.not suitable for real time updates

Data Model: Hierarchical

Justification:

This system follows a top-down structure, like a family tree.

Each employee reports to one manager, and each manager reports up the chain, forming a strict hierarchy.

Scenario 2:

Data Model: Relational

Justification:

There is a many-to-many relationship:

A student can enroll in many courses.

A course can have many students.

The relational model handles this well.

Scenario 3:

Data Model: Hierarchical

Justification:

The structure is strict and fixed:

Ministries contain departments

Departments contain units

Each unit belongs to only one department, making a clear hierarchy.

Scenario 4:

Data Model: Relational

Justification:

There is a many-to-many relationship:

A book can have multiple authors

An author can write multiple books

This structure is ideal for the relational model.

Scenario 5:

Data Model: Network

Justification:

The system involves complex interconnections:

Customers may share connections

Data involves cross-references and interlinked records

The network model is designed for such complicated relationships.

Scenario 6:

Data Model: Relational

Justification:

Multiple many-to-many relationships exist:

A customer can place many orders

An order can include many products

A product can appear in many orders

The relational model efficiently manages this kind of data.

This system has a top-down structure, where each employee reports to a single manager, and managers report upward. It is similar to the parent- child like structure

Scenario 2: Relational model

Students can enroll in multiple courses, and each course can have many students. This is relevant to the relational model which uses many-to-many relationship

Scenario 3: Hierarchical model

The model includes one-to-one and one-to-many relationships from ministries to departments to units. Because hierarchy is fixed and defined, hierarchical model is the most suitable.

Scenario 4: Relational model

Books can have multiple authors, and authors can write multiple books. This many-to-many relationship can be managed using relational model.

Scenario 5: Network model

Customers and connections are interconnected, with shared data. This type of relationships refers to a network model that supports many-to-many connections with cross-references.

Scenario 6: Relational model

The platform handles multiple orders, products, and customers with many-to-many relationships. A relational model efficiently handles such cases.

Justification

Follows a top-down structure

Each level reports to only one above—strict one-to-many relationships.

Scenario 2 : Relational Model

Justification:

Many-to-many relationship between Students and Courses.

Efficient with relational tables

Scenario 3 : Hierarchical Model

Justification:

Fixed hierarchy

Each child (unit) has only one parent

Clearly structured one-to-many levels.

Scenario 4 : Relational Model

Justification:

Many-to-many relationship between Books and Authors.

multiple authors to books and vice versa.

Scenario 5 : Network Model

Justification:

Complex relationships: connections shared among customers.

Requires many-to-many relationships

Best handled by network model with flexible pointers

Scenario 6 : Relational Model

Justification:

Many-to-many: Customers ↔ Orders ↔ Products.

Handled efficiently with foreign keys and linking tables.

- Advantages

* Conceptual Simplicity

* Data Integrity

* Efficiency

* Security

- Disadvantages

* Structural Rigidity

* Limited Relationships

* Data Redundancy

* Complex Implementation

### Network Model

- Advantages

* Relationship Flexibility

* Reduced Data Redundancy

* Efficient Data Access

- Disadvantages

* Complexity

* Lack of User-Friendliness

### Relational Model

- Advantages

* Flexibility

* Data Integrity

* No Data Redundancy

* Ease of Management

- Disadvantages

* Structural Rigidity for Changes

* Expensive for Big Systems

* Hard to Scale for Super Fast Needs

Reason:

The structure is top-down like a tree.

Each employee has only one manager.

Each manager reports to one department head.

It fits the parent-child relationship, which is how the hierarchical model works.

2. Relational Model

A student can join many courses.

A course can have many students.

This is a many-to-many relationship.

The relational model handles this easily using tables and join tables (like a student-course table).

3.Hierarchical Model

Reason:

The structure is fixed and top-down (Ministry → Department → Unit).

Each unit belongs to one department, and each department to one ministry.

Follows a tree like, parent-child structure perfect for a hierarchical model.

4. Relational Model

Reason:

Books can have many authors and authors can write many books.

This is a many-to-many relationship, which the relational model handles well using join tables.

5. Network Model

Reason:

Connections can be shared by multiple customers.

There are multiple links and cross references between data.

The network model supports many to

many relationships and complex linkages.

6. Relational Model

Reason:

One customer can place many orders.

Each order can include many products.

This system involves multiple entities with clear relationships, best handled by the relational model using tables and foreign key

• Data Model: Hierarchical

• Justification: Follows a top-down, one-to-many relationship (tree structure) with each employee reporting to one manager.

Scenario 2: School Enrollment System

• Data Model: Relational

• Justification: Many-to-many relationship between students and courses is best handled using relational tables with join.

  
  

Scenario 3: Government Document System

Data Model: Hierarchical

Justification: Follows a strict, fixed parent-child hierarchy (Ministry → Department → Unit), with one-to-many relationships and no cross-linking.

Scenario 4: Library System

Data Model: Relational

Justification: Many-to-many relationship between books and authors, best managed using relational tables with junction tables (e.g., book-author link).

Scenario 5: Telecom Billing System

Data Model: Network

Justification: Complex many-to-many relationships with shared connections and cross-references among customers and services suit the flexible link structure of the network model.

Scenario 6: Online Shopping Platform

Data Model: Relational

Justification: Many-to-many relationships between orders and products, and one-to-many between customers and orders, are efficiently handled using relational databases.

Justification:

This system follows a strict top down structure. Each employee has only one parent (manager). So thats a hierarchical database, where relationships are one to one or one to many in a tree like structure.

Scenario 2

Justification:

The relationship is many to many, which is best handled using junction tables in relational databases. flexible queries, such as which students are in a course, or which courses a student is taking.

Scenario 3

Database Model: Hierarchical

Justification:

This is a fixed system where each level depends on the one above it, like a family tree. That’s why the hierarchical model is the best fit.

Scenario 4

Database Model: Relational

Justification:

The many to many relationship between books and authors is best modeled in a relational database using a linking table . This supports flexible queries.

Scenario 5

Database Model: Network

Justification:

Since many things are linked to each other in different ways, the network model is good because it allows one item to connect to many others easily.

Scenario 6

Database Model: Relational

Justification:

This involves one to many (customer and order )and many to many (orders ↔ products). A relational model handles this efficiently using foreign keys and link tables (like Order_Products).

The most suitable data model is Hierarchical. This is because the structure is shaped like a tree, simple and good for fixed relationships. It is also very efficient. But it can also have data redundancy and has a rigid structure which could make modify it a bit harder

Scenario 2:

The most suitable data model is Relational model. This is because the model organizes data into tables and can make relationships between tables which allows for more flexibility. But it can be too rigid as it can be complicated to change the structure and expensive for big structures.

Scenario 3:

The most suitable data model is hierarchical. This is because the relationships is 1-to-many and is very simple to understand the parent-child relationship. It also has great data integrity. But it has complex implementation because of careful planning of hierachy and limited relationships as it only supports 1-to-many.

Scenario 4:

The most suitable data model is Relational model. This is because the system can have 1-to-1, 1-to-many or many-to-many relationship. It is also easy to manage and supports complex queries. But it can be hard for to scale for super fast needs as it is not ideal for needing instant updates and can be quite expensive to aquire a database.

Scenario 5:

The most suitable data model is network model. This is because the model supports many-to-many relationships and is very efficient at that type of relationships. It supports complex many-to-many relationships and reduce data redundancy. But it can be difficult to design and implement and is also lacks user-friendliness.

Scenario 6:

The most suitable data model is Relational model. This is because the platform needs different tables to be able to link data better and allows for different kinds of relationship the platform needs. It has no data redundancy as minimizes duplication and also mantains data integrity. But it can be hard to change the structure and hard to scale with super fast needs that the platform needs to provide.

Hierarchical Model. It is because it used top down structure where each level is dependent on the one above it

Scenario 2: School Enrollment System

Network Model. It is because student can enroll to multiple courses is the characteristic of network model

Scenario 3: Government Document System

Hierarchical Model. It is because each units only belong to one department.

Scenario 4: Library System

Relational Model. It is because it supports 1 - many relationships.

Scenario 5: Telecom Billing System

Relational Model. It is because it has many-to-many relationships.

Scenario 6: Online Shopping Platform

Relational Model. It is because it keeps record of custormers and uses 1 to many relationships also many-to-many relationships.

advatages:

• simple and easy to understand because the structure looks like a tree.

• fast access since the path to the data is already set.

disadvantages:

• doesnt work well for a complex relationships.

• it is quite hard to change the structure.

network model

advantages:

• can supports complex connections, like multiple relationships.

• more flexible than hierarchical model.

disadvantages:

• not common since it is lack of user.

• the structure is complicated to design.

relational model

advantages:

• very flexible, can change and update data easily.

• can handle complicated relationships.

disadvantages:

• it would be difficult to change the structure.

• some databases required a lot of money to create the big system for businesses.

-it has tree like structure where each manager, employees and department head has one parent

-one to many relationships because one manager can supervise multiple employees

2. Network model

-it has many to many relationships because a student can enroll in multiple courses and a course can have multiple student

3. Hierachical

-because each unit belongs to one department and each department belongs to only one minister.

-it has top down structure

4. Relational

-many to many relationships

-relational data is effective in handling many to many relationships because it is easily modelled using tables

5. Network model

-it has many to many relationships

-customer may have multiple connections

6. Relational

-it keeps customers records

-has one to many relationships

Most suitable data model : Hierarchical Model

Justification : This is hierarchical model because the management system is like a family tree starting from the CEO at the top and flows downards through department heads, managers and employees which is showing top-down chain of command.

Scenario 2 : School Enrollment System

Most suitable data model : Relational Model

Justification: This is relational model because it allows many-to-many relationships where each student can join many courses, and each courses can have many students.

Scenario 3: Government Document System

Most suitable data model : Hierarchical Model

Justification: This is hierarchical model because it has a clear top-down structure and each unit belongs to only one department.

Scenario 4: Library System

Most suitable data model : Relational Model

Justification: This is relational model because it supports many-to-many relationships where books can have multiple authors and authors can write multiple books.

Scenario 5: Telecom Billing System

Most suitable data model : Network Model

Justification : This is network model because it allows complex and shared relationships where customers can have multiple connections and connections can be shared among customers.

Scenario 6: Online Shopping Platform

Most suitable data model : Relational Model

Justification : This is relational model because it uses tables to store data like customers, orders and products with relationships between them.

Hierarchical model

The company structure is top-down (employee --- manager --- department head --- CEO)

Scenario 2

Relational model

School Enrollment System have a many-to-many relationship

Scenario 3

Hierarchical

Government Document System (ministry --- department -- unit), with each level only one parent the hierarchy is fixed.

Scenario 4

Relational

Library System have many-to-many relationship.

Scenario 5

Network

Telecom Billing System have complex, cross-linked relation.

Scenario 6

Relational

Online Shopping Platform have many-to-many ways relationship.

* Most Suitable Data Model: Hierarchical Model.

* Justification: The Hierarchical Model organizes data in a tree structure where data is sorted in levels, similar to a family tree or folder system. Crucially, in this model, each child has only one parent. This perfectly matches the "top-down structure" described, where an employee has one manager, and a manager has one department head. The hierarchical model is known for its conceptual simplicity and efficiency for one-to-many relationships, which are characteristics of this employee reporting structure.

# School Enrollment System

* Most Suitable Data Model: Relational Model.

* Justification: The scenario explicitly describes a many-to-many relationship between students and courses. The Relational Model is highly flexible and "handles many-to-many relationships via junction tables". It supports "all types" of relationships, including many-to-many, and is described as the most used today, being "easy to manage" and "very flexible". While the Network Model also supports many-to-many relationships, the Relational Model's overall flexibility and widespread use make it the preferred choice for a system that requires handling such mutual and flexible relationships effectively.

# Government Document System

* Most Suitable Data Model: Hierarchical Model.

* Justification: This system presents a clear and fixed hierarchical structure where each unit belongs strictly to one department, and departments belong to ministries. The Hierarchical Model is specifically designed for such one-to-many relationships where "each child has only one parent". It effectively represents data organized in a "tree structure" and is good for simple, fixed relationships like the one described.

# Library System

* Most Suitable Data Model: Network Model.

* Justification: This scenario describes a classic many-to-many relationship between books and authors, where both entities are "interconnected and share relationships". The Network Model is an "extension of hierarchical model" that "uses a graph structure with many-to-many relationships". Notably, the sources explicitly mention that the Network Model is "Used in telecom, library systems", making it a direct fit for this scenario due to its capability to handle complex and flexible interconnections.

# Telecom Billing System

* Most Suitable Data Model: Network Model.

* Justification: This system involves complex many-to-many relationships where connections can be shared among different customers and data is linked via "cross-references and linkages". The Network Model is particularly well-suited for such scenarios as it supports "complex many-to-many relationships" and allows for shared records, eliminating duplication. The sources directly state that the Network Model is "Used in telecom" systems, emphasizing its applicability for managing such intricate connection types.

# Online Shopping Platform

* Most Suitable Data Model: Relational Model.

* Justification: This scenario requires handling various types of relationships: a customer placing "several orders" (one-to-many), and "one product can appear in many different orders" while "each order may include many products" (many-to-many). The Relational Model is the most used today and is highly flexible, supporting "all types" of relationships (1-1, 1-many, many-many). It effectively "handles many-to-many relationships via junction tables", which would be essential for linking products to orders. Its overall ease of management and flexibility make it ideal for a comprehensive and dynamic online shopping platform.

advantages

1. easy to understand with parent-child relationships

2. data integrity automatically maintained by the parent-child relationships

disadvantages

1. data redundancy -some data may be duplicated in multiple folders

2. structural rigidity -hard to modify existing structure because of the old version

network model

advantages

1. support complex (many-to-many) relationships

2. reduce data duplication

disadvantages

1. not user friendly

2. hard to design and implement. require understanding of the structure

relational model

advantages

1. flexible (handle many-to-many) relationships

2. minimize data duplication

disadvantages

1. hard to change the structure

2. expensive means cost a lot of money for business

Hierarchical Model. It is because data structure for this company is top down type and it is organised according to levels which depends on previous levels.

Scenario 2:

Network Model. It is because students in the school can enroll multiple courses and each course can have many students where this explains many to many function. This is also because the student (child data) have multiple courses (parent data).

Scenario 3:

Hierarchical Model. It is because this government system is organised in a top down manner where the child data becomes more when going down the structure but each child data (department units) only report to one parent data (one ministry).

Scenario 4:

Relational Model. It is because one book have multiple authors and each of them can contribute to multiple books where this explains many to many functions. The books table can link to authors table to visualize the relationship.

Scenario 5:

Network Model. It is because customers has multiple types of connections and those connections each have different benefits which links one another. The company use cross-preference to connect all data because it is a many to many function. These data have multiple parent data.

Scenario 6:

Relational Model. It is because this company keeps records of customers. One customer can place many order and one order may have many products. Here we have 1-1 function and many to many function too. So this model can make data more easy to manage.

Most suitable data model : Hierarchical Model

Justification

Because every employee has to report a single manager: one to many relationships, and the structure is top-down structure.

Scenario 2: School Enrollment System

Most suitable data model : Relational Model

Justification

Because students and courses have a many-to-many relationship. The relational model can handle this easily using tables and a join table (like "enrollments") to connect them.

Scenario 3: Government Document System

Most suitable data model : Hierarchical Model

Justification

Because it follows a fixed top-down structure — units under departments, departments under ministries. And if has fixed hierarchy.

Scenario 4: Library System

Most suitable data model : Relational Model

Justification

Because books and authors have a many-to-many relationship. The relational model uses tables to manage this kind of flexible connection easily. Also data can be validated via foreign keys and data redundancy can be prevented via primary keys.

Scenario 5: Telecom Billing System

Most suitable data model: Network Model

Justification

Because customers and connections have many-to-many relationships, and the system needs cross-references and flexible links. The network model is good at handling complex, interconnected data like this.

Scenario 6: Online Shopping Platform

Most suitable data model: Relational Model

Justification

Because customers, orders, and products have many-to-many (Orders and Products) and one-to-many (One Customer and Many Orders) relationships. The relational model uses tables to manage this clearly and efficiently.

Hierarchical model

Justification- each employee reports to one manager and the structure goes step by step

Scenario 2

Relational model

Justification- the relationship is many to many. Students can join many courses and courses have many students

Scenario 3

Hierarchical model

Justification - there is a fixed hierarchy from ministry one to many relationship and no cross linking

Scenario 4

Relational model

Justification-The many to many relationship between books and authors is best modeled in a relational database using a linking table . This supports flexible queries.

Scenario 5

Network model

Justification- Since many things are linked to each other in different ways, the network model is good because it allows one item to connect to many others easily.

Scenario 6

Relational model

Justification-This involves one to many (customer and order )and many to many (orders ↔ products). A relational model handles this efficiently using foreign keys and link tables (like Order_Products).

Database Model: Hierarchical

Justification:

This system follows a strict top down structure. Each employee has only one parent (manager). So thats a hierarchical database, where relationships are one to one or one to many in a tree like structure.

Scenario 2

Justification:

The relationship is many to many, which is best handled using junction tables in relational databases. flexible queries, such as which students are in a course, or which courses a student is taking.

Scenario 3

Database Model: Hierarchical

Justification:

This is a fixed system where each level depends on the one above it, like a family tree. That’s why the hierarchical model is the best fit.

Scenario 4

Database Model: Relational

Justification:

The many to many relationship between books and authors is best modeled in a relational database using a linking table . This supports flexible queries.

Scenario 5

Database Model: Network

Justification:

Since many things are linked to each other in different ways, the network model is good because it allows one item to connect to many others easily.

Scenario 6

Database Model: Relational

Justification:

This involves one to many (customer and order )and many to many (orders ↔ products). A relational model handles this efficiently using foreign keys and link tables (like Order_Products).

Hierarchical Model

Advantages :

• Data is structured

• Conceptual and simple

• security through access control

• data integrity

• predicted performance

Disadvantages:

● Only limited to one to many relationships

● difficult to modify or edit

● data redundancy

● complex implementation

Network model

Advantages:

•support many to many relationships

• reduced to data redundancy

•efficienct data access

Disadvantages:

•complex

•not user friendly

Relational model

Advantages:

•flexible

• data integrity

•no data redundancy

Disadvantages:

• too rigid

• too expensive for large scale

• hard for super fast needs

In-class task:

EPrints is an open-source digital repository platform commonly used by universities and research institutions to manage and preserve academic content. It serves as a centralized system for storing, organizing, and sharing scholarly materials such as theses, dissertations, research papers, articles, and conference proceedings. Designed to support the principles of open access, EPrints enables users, such as students, lecturers, and librarians to upload documents, add metadata, and make them discoverable through search and browse features. The system includes user roles for submission, moderation, and administration, allowing for a controlled workflow that ensures content quality and access rights. EPrints also supports metadata standards like Dublin Core and offers integration with institutional authentication systems and academic search engines, making it a valuable tool for increasing the visibility and accessibility of an institution’s academic output.

Phase 1: Problem Definition

- Need: Centralized repository for academic documents (theses, papers).

- Flexibility: Support future expansions (new metadata, document types).

- Cost: Open-source (EPrints) reduces licensing costs.

- Risks/Benefits: Data migration vs. improved research visibility.

- Feasibility: Confirmed by existing EPrints implementations.

Phase 2: Existing System Analysis

- Study manual submission & approval workflows.

- Interview students, faculty, librarians, IT staff.

- Identify gaps in current systems.

- Output: Requirements document (user roles, metadata standards, workflows).

Phase 3: Preliminary Design

- Conceptual Schema (View-Integration Approach):

- Entities: Users, Documents, Metadata, Reviews, Collections.

- - Relationships: Users submit Documents, Documents have Metadata, Reviews approve/reject.

- Performance: Fast search (<2s), handle peak submissions.

Phase 4: System Requirements

- DBMS: PostgreSQL (open-source, full-text search, security).

- Hardware: Scalable storage, backup solutions.

Phase 5: Final Design

- Tables: Users, Documents, Metadata, Reviews.

- Storage: Filesystem for docs, database for metadata.

- Security: Role-based access (LDAP integration).

-Backup: Daily incremental, disaster recovery plan.

Phase 6: Implementation & Testing

- Build database, integrate authentication.

- Testing: Unit (upload), Integration (workflow), Performance (load).

- Documentation: Admin guides, user manuals.

Phase 7: Operation & Tuning

- Pilot rollout, user training.

- Optimize queries, adjust indexes.

- - Monitor usage, apply updates.

Advantages:

Structured, reliable design.

Maintains data integrity.

User-centered workflows.

Limitations:

Complex relationships.

Requires training.

Initial setup effort.

Final Output: A well-structured, scalable EPrints database following the 7-phase design cycle.

1.

Database design is the process of planning and organizing how data will be stored, managed, and used in a database system. It ensures that the structure of the database reflects the actual, real-world information needs of an organization. A good design allows data to be updated easily and accurately as changes happen.

It is important because it helps create a reliable and efficient system. With proper design, the database performs better, reduces errors, and supports clear data organization. It also allows users and developers to understand how data flows, making the system easier to use, maintain, and expand over time.

2. Database Design Cycle – 7 Phases

Phase 1: Definition of the Problem

In this phase, the need for a new database system is identified. The designer determines the system's purpose, estimates cost, analyzes risks and benefits, checks project flexibility, and conducts a feasibility study to find the best possible solution.

Phase 2: Analyses of Existing System and Procedures

This phase involves studying how the current system works. It includes interviewing users, reviewing procedures, understanding data flow, identifying current issues, and preparing the initial proposal and requirement specifications for the new system.

Phase 3: Preliminary Design

At this stage, the conceptual schema is created using either centralized schema design or the view-integration approach. The system’s overall structure is planned, conflicts (such as naming or data types) are resolved, and performance requirements are considered.

Phase 4: Computing System Requirements

In this phase, the designer selects the appropriate DBMS software and hardware. Factors like cost, features, existing systems, availability, and system flexibility are considered to meet the actual database requirements.

Phase 5: Final Design

Here, the logical structure of the database is completed. It includes finalizing table structures, defining storage details, setting access and security controls, designing user interfaces, and planning backup and recovery procedures.

Phase 6: Implementation and Testing

The system is built and tested. The database is implemented based on the final design. Functional and performance testing is done, and documentation is prepared to support users and future maintenance.

Phase 7: Operation and Tuning

This final phase involves daily use of the system. It includes installation, onsite testing, performance tuning, and user training. The database is monitored and adjusted as needed to ensure s

mooth and efficient operation.

• reduces data redundancy, prevents errors, and makes it easier to retrieve and update information

• improves system performance by optimizing how queries are executed and how data is stored

• provides a strong foundation for building reliable and scalable database systems that can grow and adapt to future needs

Database design is the process of organizing data so that it can be stored, managed, and used effectively.

To create an effective database system, we

follow a step-by-step process called the

database design cycle. Each step in the cycle focuses on a specific task in the design process as below: Move to the next step once the current step is completed. Go back to a previous step if changes or corrections are needed.

2.

Phase 1: Definition of the Problem

Identify the need for a system to manage and share academic documents.

Phase 2: Analysis of Existing System and Procedure

Understand how EPrints works and find areas to improve (e.g., metadata, logging).

Phase 3: Preliminary Design

Identify key entities (User, Document, Author, Metadata, etc.) and their relationships.

Phase 4: Computing System Requirements

Define software, storage, security, and performance needs.

Phase 5: Final Design

Build normalized tables and relationships for the database.

Phase 6: Implementation and Testing

Create database, run tests, and ensure features like upload and review work.

Phase 7: Operation and Tuning

Maintain, monitor, and optimize the system regularly.

2. Phase 1: Definition of the Problem

   Identify the need for a database. Consider flexibility, estimate cost, analyze risks and benefits, and check if the project is feasible.

   Phase 2: Analysis of Existing System

   Study the current system, gather user feedback through interviews, analyze how data flows, and list system problems. Prepare initial requirements for the new system.

   Phase 3: Preliminary Design

   Create a conceptual design (schema) of the database. Use centralized or view-integration approach to combine user needs. Resolve any naming or data type conflicts.

   Phase 4: Computing System Requirements

   Choose the right DBMS software and hardware based on cost, features, availability, and flexibility. Make sure it meets system and performance needs.

   Phase 5: Final Design

   Convert the logical design into a working plan. Finalize tables, storage structure, user interfaces, access controls, and set up backup and recovery plans.

   Phase 6: Implementation and Testing

   Build the system based on the final design. Test all features to ensure data accuracy, system performance, and user experience. Prepare system documentation.

   Phase 7: Operation and Tuning

   Install the system for real use. Perform testing in the live environment, fine-tune performance, and train users to operate and manage the system efficiently.

Database design is the process of planning how data is stored, organized, and managed in a database. It helps make sure the data is accurate, easy to access, and safe.

Importance:

1. Keeps data accurate and organized

2. Speeds up data search and updates

3. Prevents data mistakes and duplication

4. Makes it easy to grow or change the system

5. Protects data with proper security rules

2.

Database Design Cycle – 7 Phases (Based on Image)

1. Phase 1: Definition of the Problem

Identify the main issue or need. Understand what the database should solve or support.

2. Phase 2: Analyses of Existing System and Procedure

Study the current system, how data is handled, and what improvements are needed.

3. Phase 3: Preliminary Design

Create an early model of the system. Plan the basic structure and flow of data.

4. Phase 4: Computing System Requirements

Decide what hardware, software, and network resources are needed to run the database system.

5. Phase 5: Final Design

Complete the detailed design, including data structures, tables, relationships, and rules.

6. Phase 6: Implementation and Testing

Build the database and test it to make sure it works correctly and meets the user needs.

7. Phase 7: Operation and Tuning

Run the system and make improvements over time for better performance and efficiency.

Database design is the process of organizing data to be stored, managed, and used effectively.

Importance:

It ensures accurate reflection of real-world data.

It supports easy updating and expansion.

It enhances data integrity and efficiency.

It minimizes data redundancy and inconsistency.

2. Draw the Database Design Cycle showing all 7 phases.Include short notes for each phase.

(1) Problem Definition → Identify the actual need, estimate cost, consider risks, and conduct feasibility study.

(2) Analyse Existing System → Study the current system through interviews and process reviews.

(3) Preliminary Design → Develop conceptual schema; design applications and performance needs.

(4) Computing System Requirements → Choose suitable DBMS and hardware based on cost, features, and availability.

(5) Final Design → Finalize table structures, user views, storage details, and security plans.

(6) Implementation & Testing → Build the system, test it, and prepare documentation.

(7) Operation & Tuning → Install, tune performance, and provide training for day-to-day operation.

its important because a good designed system can help it run faster and more smoothly. it also make sure that the data is correct and wont be repeated more than one time.

Importance:

- Ensures data is stored logically, reducing redundancy and inconsistency. 

- Improves performance by optimizing data retrieval and storage. 

- Enhances data integrity by enforcing rules (e.g., primary keys, foreign keys). 

- Makes the database scalable and easier to maintain.

2.Varchar

3.Integer

4.Date

5.Varcgar

6.Integer

7.Char

8.Integer

2. Char

3. Number

4. Date

5. Varchar

6. Number

7. Boolean

8. Float

2. varchar

3. Number

4. Date

5. varchar

6. Number

7. Char

8. Number

2. var char

3. number

4. date

5. var char

6. number

7. char

8. number

2. CHAR

3. NUMBER

4. DATE

5. VARCHAR

6. NUMBER

7. VARCHAR / CHAR

8. FLOAT

1. varchar

2. varchar

3. Number

4.Date

5. varchar

6. Number

7. Char

8. Number

2. Char

3. Number

4. Date

5. Varchar

6. Number

7. Boolean

8. Float

2.Varchar

3.Int

4.Date

5.Varchar

6.Int

7.Char

Number

2. CHAR

3. NUMBER

4. DATE

5. VARCHAR

6. NUMBER

7. BOOLEAN

8. FLOAT

2. CHAR

3. NUMBER

4. DATE

5. VARCHAR

6. NUMBER

7. BOOLEAN

8. FLOAT

Varchar

Number

Date

Varchar

Varchar

Char or Varchar

Number

2. FullName - Siti Aisyah - VARCHAR

3. Age - 20 - NUMBER

4. DateOfBirth - 2005-08-21 - DATE

5. Email - aisyah@gmail.com - VARCHAR

6. PhoneNumber - 0123456789 - VARCHAR

7. IsActiveStudent - Yes or No - BOOLEAN

8. GPA - 3.75 -

DECIMAL

2. Char

3. Number

4. Date

5. Varchar

6. Number

7. Boolean

8. Float

2. Char

3. Number

4. Date

5. Varchar

6. Number

7. Char

8. Number

Char

Number

Date

Varchar

Number

Char

Number

2.char

3.number

4.date

5.varchar

6.number

7.char

8.number

2.Varchar2-because it long

3.Number

4.Date

5.Varchar2-it has symbol

6.Varchar2-long number

7.Varchar2/ char - because it can be long and short

8. Number

2. Varchar

3. Int

4. Date

5. Varchar

6. Int

7. Boolean

8. Float

2.Char

3.Number

4.Date

5.Varchar

6.Number

7.Char

8.Number

2. Varchar

3. Int

4. Date

5. Varchar

6. Int

7. Boolean

8. Float

2. Query Compiler
The query compiler converts the SQL query into an intermediate representation. During this stage, it also verifies that the query’s syntax and meaning are correct.

3. Query Plan
A query plan outlines the sequence of operations the system will perform to retrieve the requested data, based on the intermediate form of the query.

4. Query Optimizer
The optimizer evaluates various possible execution methods for a query and selects the most efficient approach. It determines the sequence of operations, the indexes to apply, and the join methods to use.

5. Catalog Manager
The catalog manager oversees the system catalog, which contains metadata describing the database’s structure, indexes, constraints, and more. It supplies the optimizer with essential information about tables, indexes, and statistical data.

6. System Catalog
This is the repository of a database’s metadata, containing details such as table designs, index configurations, and storage specifications.

7. Query Execution Plan
The finalized and optimized plan that the database engine will execute to process the query.

8. Command Processor
Executes the query by taking the final plan and working with the data manager to access or update the data.

9. Data Manager
Responsible for reading data from and writing data to the database’s physical storage.

10. Database
The physical location where all actual data is stored.

11. Query Result
The final output, consisting of the retrieved and processed data, presented to the user in the desired format.

2. Query Compiler – Translates the SQL request into a form the system can work with, and checks that it’s written correctly and makes sense.

3. Query Plan – A list of steps the system will follow to get the data, based on the translated query.

4. Query Optimizer – Looks at different ways to run the query and picks the fastest method, deciding things like order of steps, which indexes to use, and how to join tables.

5. Catalog Manager – Manages information about the database’s structure, indexes, and rules, and gives the optimizer details it needs.

6. System Catalog – The stored “map” of the database, including table layouts, indexes, and storage details.

7. Query Execution Plan – The final, improved version of the plan, ready to be run.

8. Command Processor – Takes the execution plan and works with the data manager to get or change the data.

9. Data Manager – Handles the actual reading and writing of data in storage.

10. Database – Where the real data is physically stored.

11. Query Result – The finished data is given back to the user in the format they asked for.

This is the starting point where the system receives the user’s request (often written in SQL). At this stage, the system just knows what you want, not how to get it.

2. Query Compiler

The query compiler translates the user’s SQL query into an internal form that the database can understand.

It performs:

Parsing – checks syntax and meaning.

Translation – converts it into a lower-level representation.

Validation – ensures the tables and columns exist.

3. Query Plan

Here, the system creates a recipe of steps needed to get the data.

It describes what operations should be done but not necessarily in the most efficient way yet.

4. Query Optimizer

This is like a smart planner that finds the fastest and cheapest way to execute the query.

It considers,

Index usage

Join orders

Access paths

It may consult the System Catalog to get information like table sizes, indexes, and data statistics.

5. Catalog Manager

This manages the System Catalog, which stores metadata about the database

It provides the optimizer with information needed for efficient planning.

6. Query Execution Plan

After optimization, the system produces a detailed step-by-step guide for actually running the query.

This is the final, most efficient plan.

7. Command Processor

The command processor takes the execution plan and turns it into actual low-level operations that the Data Manager can run.

8. Data Manager

This component directly interacts with the physical database storage.

It reads and writes data blocks, handles transactions, and ensures data integrity.

9. Database

The actual storage where all your data lives tables, indexes.

10. Query Result

After the data manager fetches the required data and the command processor processes it, the final results are sent back to the user.

1. Query Processing – This is the overall job of handling a user’s request (like an SQL query) from start to finish.

2. Query Compiler – Reads the SQL query, checks for errors in grammar (syntax) and meaning (semantics), then changes it into an easier-to-handle form for the system.

3. Query Plan – A draft set of steps that shows how the database could get the required data.

4. Query Optimizer – Looks at all possible ways to run the query and picks the fastest and most efficient method, deciding on things like join order and which indexes to use.

5. Catalog Manager – Handles the database’s “dictionary” (metadata) containing details about tables, indexes, and constraints, and gives this info to the optimizer.

6. System Catalog – The storage space for metadata — information about how the database is structured and stored.

7. Query Execution Plan – The final, optimized set of instructions ready to be run by the database engine.

8. Command Processor – Takes the execution plan and works with the Data Manager to actually get or change the data.

9. Data Manager – Controls the real reading from and writing to the database storage.

10. Database – The physical place where all actual data is kept.

11. Query Result – The final data output that is sent back to the user in the format they requested.

2. Query Optimizer - Finds the most efficient way to execute the query by considering different plans.

3. Catalog Manager - Maintains metadata about the database structure (tables, columns, indexes).

4. Command Processor - Coordinates the execution of the query by interacting with other components.

5. Query Execution Plan - The step-by-step instructions for how to retrieve the data.

2. Query Compilation is receiving the query and checks if it's valid, making sure the syntax is correct and the request makes sense.

3.  Query Plan creates a plan, which is a set of steps for getting the requested data.

4. Query Optimization  looks at all the possible ways to run the query and chooses the most efficient one.

5. Query Execution Plan is when Final, optimized plan is then ready to be executed by the database.

6.  Command Processing is a command processor that takes this plan and works with the data manager to actually retrieve or change the data in the database's physical storage.

7. Data Manager is Fetching data.

8. Query Result is processed data is returned to the user in the format they asked for.

● handling user's activity by database system

2. Query compiler

● translate high level query language to intermediate form and check for syntax and semantics for validation

3. Query plan

● set of steps used by system to get the data

4. Query optimizer

● looks for most efficienct way to execute the query

5. Catalog manager

● manage system catalog and provide needed details to optimizer

6. System catalog

● metadata storage of database like table structures, indexes definitions and storage details

7. Query execution plan

● ready to run, finally optimised plan

8. Command processor

● takes the execution plan and coordinate with data manager

9. Data manager

● handles actual data access

10. Database

● physical storage where data is actually stored

11. Query result

● processed and retrieved data is returned to user in requested format

2. Query Compiler – Converts the SQL query into an intermediate form and checks if it’s correct.

3. Query Plan – The list of steps the system will follow to get the data.

4. Query Optimizer – Chooses the fastest and most efficient way to run the query.

5. Catalog Manager – Manages information about the database’s structure and provides it to the optimizer.

6. System Catalog – The storage of database details like table structures, indexes, and storage info.

7. Query Execution Plan – The final optimized plan ready to be executed.

8. Command Processor – Executes the plan and works with the data manager.

9. Data Manager – Handles the actual reading and writing of data from storage.

10. Database – The physical storage where the data is kept.

11. Query Result – The final data returned to the user.

1. Query Processing – This is the whole process where the database handles a user’s request (often written in SQL).

2. Query Compiler – Translates the SQL request into a form the system can work with, and checks that it’s written correctly and makes sense.

3. Query Plan – A list of steps the system will follow to get the data, based on the translated query.

4. Query Optimizer – Looks at different ways to run the query and picks the fastest method, deciding things like order of steps, which indexes to use, and how to join tables.

5. Catalog Manager – Manages information about the database’s structure, indexes, and rules, and gives the optimizer details it needs.

6. System Catalog – The stored “map” of the database, including table layouts, indexes, and storage details.

7. Query Execution Plan – The final, improved version of the plan, ready to be run.

8. Command Processor – Takes the execution plan and works with the data manager to get or change the data.

9. Data Manager – Handles the actual reading and writing of data in storage.

10. Database – Where the real data is physically stored.

11. Query Result – The finished data is given back to the user in the format they asked for.

The overall activity where a user’s query is handled by the database system

2. Query Compiler

The query compiler makes translations of the high-level SQL query into an intermediate form. It checks syntax and semantics to ensure for the validation.

3. Query Plan

A query plan is a set of steps that used by the system to get the data. It is generated from the intermediate form of the query.

4. Query Optimizer

The optimizer looks at different possible ways to execute the query and chooses the most efficient one. It decides the order of operations, indexes to use, and join strategies.

5. Catalog Manager

The catalog manager manages the system catalog. It provides the optimizer with needed details about tables, indexes, and statistics.

6. System Catalog

A database’s metadata storage contains information like table structures, index definitions and storage details.

7. Query Execution Plan

The final optimized version of the plan, ready to be run by the database engine.

8. Command Processor

Takes the execution plan and coordinates with the data manager to retrieve or modify the data.

9. Data Manager

Handles actual data access fetching from and writing to the database storage.

10.Database

The physical storage where the actual data is kept.

11. Query Result

The processed and retrieved data is returned to the user in the requested format.

This is the starting point where the system receives the user’s request (often written in SQL). At this stage, the system just knows what you want, not how to get it.

2. Query Compiler

The query compiler translates the user’s SQL query into an internal form that the database can understand.

It performs:

Parsing – checks syntax and meaning.

Translation – converts it into a lower-level representation.

Validation – ensures the tables and columns exist.

3. Query Plan

Here, the system creates a recipe of steps needed to get the data.

It describes what operations should be done but not necessarily in the most efficient way yet.

4. Query Optimizer

This is like a smart planner that finds the fastest and cheapest way to execute the query.

It considers,

Index usage

Join orders

Access paths

It may consult the System Catalog to get information like table sizes, indexes, and data statistics.

5. Catalog Manager

This manages the System Catalog, which stores metadata about the database

It provides the optimizer with information needed for efficient planning.

6. Query Execution Plan

After optimization, the system produces a detailed step-by-step guide for actually running the query.

This is the final, most efficient plan.

7. Command Processor

The command processor takes the execution plan and turns it into actual low-level operations that the Data Manager can run.

8. Data Manager

This component directly interacts with the physical database storage.

It reads and writes data blocks, handles transactions, and ensures data integrity.

9. Database

The actual storage where all your data lives tables, indexes.

10. Query Result

After the data manager fetches the required data and the command processor processes it, the final results are sent back to the user.

This is where the process starts.

The user’s SQL query (e.g., SELECT * FROM Students) is taken in for processing

2. Query Compiler

Translates the SQL query into an internal form that the database can understand better.

Checks the query syntax and semantics (making sure it’s valid and makes sense).

3. Query Plan

A raw plan showing possible steps to retrieve the requested data.

It’s like a “first draft” of how the database might execute the query.

4. Query Optimizer

Improves the raw query plan to make it faster and use fewer resources.

Chooses the most efficient way to access tables, indexes, and data.

5. Catalog Manager

Works with the System Catalog (metadata database that stores information about tables, columns, indexes, permissions, etc.).

Provides necessary information for optimization and execution planning.

6. Query Execution Plan

The final, optimized set of steps for executing the query.

Passed to the execution system.

7. Command Processor

Receives the execution plan and translates it into actual database commands.

Sends instructions to the Data Manager.

8. Data Manager

Directly interacts with the physical database storage.

Retrieves or updates the data based on the commands.

9. Database

The actual storage where all data resides (tables).

10. Query Result

The final output returned to the user after the query is executed.

This is the whole process where the database takes a user’s SQL request, works on it, and gives back the results.

2. Query Compiler

This part of the system changes the SQL query into another form that the database can understand better. It also checks for mistakes in the query’s structure and meaning.

3. Query Plan

This is like a step-by-step guide the database follows to find the requested data. It’s created from the processed version of the query.

4. Query Optimizer

Looks at different ways to run the query and picks the fastest one.

Decides the order of steps, which indexes to use, and how to join tables.

5. Catalog Manager

Manages the database’s “catalog” (metadata) that stores details about tables, indexes, and rules.

Gives the optimizer the needed information to make decisions.

6. System Catalog

A storage area for metadata (info about the database structure, indexes, and storage details).

7. Query Execution Plan

The final, improved plan for running the query — ready for the database to execute.

8. Command Processor

Takes the execution plan and works with the data manager to get or change the data.

9. Data Manager

Handles the actual fetching and storing of data in the database.

10. Database

The place where all the real data is physically stored.

11. Query Result

The processed data is sent back to the user in the format they requested.

1. Query Processing is the entire process the database system goes through to handle and respond to a user's SQL query.

2. Query Compiler translates the SQL query into a form the system can work with. It also checks the query for any syntax or logical errors.

3. Query Plan is a set of steps the database will follow to get the requested data. This is created from the translated version of the original query.

4. Query Optimizer looks at different ways to run the query and picks the most efficient method. It decides things like the order of operations, which indexes to use, and how to handle joins.

5. Catalog Manager manages the metadata like information about tables, indexes, and constraints. It provides this information to the optimizer.

6. System Catalog is where all the database's metadata is stored, such as table structures, indexes, and storage details.

7. Query Execution Plan is the final version of the plan chosen by the optimizer. It's ready to be executed by the system.

8. Command Processor takes the execution plan and works with the data manager to actually retrieve or modify the data.

9. Data Manager handles direct access to the stored data, reading from and writing to the database.

10. Database is the actual place where the data is stored physically.

11. Query Result is the final output and the data that's been fetched or modified, and returned to the user in a usable format.

    
    

The process a database follows to handle a user’s SQL request from start to finish.

2. Query Compiler

Changes the SQL command into a form the database understands and checks if it’s correct.

3. Query Plan

A list of steps the database will follow to get the answer.

4. Query Optimizer

Finds the fastest and most efficient way to run the query.

5. Catalog Manager

Provides the optimizer with details about tables, indexes, and rules.

6. System Catalog

Stores the database’s structure and design details.

7. Query Execution Plan

The final plan chosen to run the query.

8. Command Processor

Runs the plan and works with the data manager.

9. Data Manager

Gets the data from storage or saves it there.

10. Database

The place where all actual data is stored.

11. Query Result

The final answer shown to the user.

This is the overall activity where a user’s query usually in SQL is handled by the database system

02. Query compiler

It translates your high level sql query into an internal format so that the database understands.

03. Query plan

A detailed map or like you can say a set of steps on how the database will answer the query.

04.Query optimizer

Improves the query plan to make it run faster and use fewer resources.

05.Catalog manager

Looks into the database’s System Catalog to check information about tables, indexes and sizes, etc.

06.System Catalog

Stores data about the data base table structures, column types and the user permissions.

07.Query execution plan

It’s the final optimized instructions ready to run.

08.Command processor

Executes the plan and coordinates with the data manager.

09.Data Manager

It handles reading and writing actual data in the database storage.

10.Database

The physical storage where all data is kept.

11.Query result

It is the output you get after all steps are done.

This is the starting point where the system receives the user’s request (often written in SQL). At this stage, the system just knows what you want, not how to get it.

2. Query Compiler

The query compiler translates the user’s SQL query into an internal form that the database can understand.

It performs:

Parsing – checks syntax and meaning.

Translation – converts it into a lower-level representation.

Validation – ensures the tables and columns exist.

3. Query Plan

Here, the system creates a recipe of steps needed to get the data.

It describes what operations should be done but not necessarily in the most efficient way yet.

4. Query Optimizer

This is like a smart planner that finds the fastest and cheapest way to execute the query.

It considers,

Index usage

Join orders

Access paths

It may consult the System Catalog to get information like table sizes, indexes, and data statistics.

5. Catalog Manager

This manages the System Catalog, which stores metadata about the database

It provides the optimizer with information needed for efficient planning.

6. Query Execution Plan

After optimization, the system produces a detailed step-by-step guide for actually running the query.

This is the final, most efficient plan.

7. Command Processor

The command processor takes the execution plan and turns it into actual low-level operations that the Data Manager can run.

8. Data Manager

This component directly interacts with the physical database storage.

It reads and writes data blocks, handles transactions, and ensures data integrity.

9. Database

The actual storage where all your data lives tables, indexes.

10. Query Result

After the data manager fetches the required data and the command processor processes it, the final results are sent back to the user.

2. Query Compiler ---– Changes question into database language.

3. Query Plan ---– Makes steps to get the answer.

4. Query Optimizer ---– Finds the quickest way.

5. Catalog Manager –--- Gives info about tables and data.

6. Query Execution Plan --– Final plan to run.

7. Command Processor ---– Sends instructions to get data.

8. Data Manager ---– Brings the data from storage.

9. Query Result –--- Shows the answer.

2.Query Compiler- Translates a SQL query or user command into a format the database system can understand.

3. Query Plan-A step-by-step strategy created by the system to fetch the requested data efficiently.

4. Query Optimize- Analyzes different ways to execute a query and selects the fastest and most efficient method.

5.Catalog Manager- Keeps track of database metadata .

6.Query Result-The final data returned to the user after processing the query.

7.Command Processo

Executes database commands .

8. Query Execution Plan- The finalized version of the query plan that the database actually follows to retrieve data.

9.System Catalog that stores metadata

10.Data Manager-Handles the actual storage, retrieval, and updating of data in the database.

11. Database-The physical storage where all structured data is kept

2. Query Compiler: This part translates the query written by the user into a form that the database system can understand and work with, usually an internal representation.

3. Query Plan: After compilation, the system creates a plan showing how to execute the query efficiently. It’s like a roadmap of steps to get the data.

4. Query Optimizer: This component reviews the query plan and tries to improve it by finding the most efficient way to execute the query, saving time and resources.

5. System Catalog / Catalog Manager: This is like a database directory that holds metadata about the data — what tables exist, their structure, indexes, etc. The optimizer and others refer to this to make decisions.

6. Query Execution Plan: This is the final, optimized set of instructions that tells the system exactly how to retrieve the data.

7. Command Processor: This executes the instructions from the query execution plan and manages communication between different components.

8. Data Manager: Responsible for accessing the actual stored data in the database.

9. Query Result: The final data output produced after the query has been processed and executed.

Query Compiler converts a high-level query (e.g., SQL) into an internal form the database can understand.

Query Plan is a sequence of operations that outlines how the query will be executed.

Query Optimizer selects the most efficient execution strategy by comparing alternative plans.

Catalog Manager controls access to metadata about database objects and their properties.

System Catalog is the repository storing metadata such as table definitions, indexes, constraints, and statistics.

Query Execution Plan is the finalized, optimized set of operations to be performed on the database.

Command Processor executes non-query commands like schema modifications or security changes.

Data Manager handles the physical reading, writing, and buffering of stored data.

Database is the structured, persistent storage of data.

Query Result is the final output returned to the user after query execution.

2. The query compiler changes the SQL query into an intermediate form and checks its validity.

3. A query plan is the step-by-step method the system uses to retrieve the data.

4. The query optimizer picks the most efficient way to run the query by deciding operation order, indexes, and join methods.

5. The catalog manager handles database metadata and gives the optimizer details about tables, indexes, and statistics.

6. The system catalog stores metadata such as table structures, index definitions, and storage details.

7. A query execution plan is the final optimized plan ready for the database to run.

8. The command processor runs the execution plan and works with the data manager to get or change data.

9. The data manager reads from and writes data to the database storage.

10. The database is the physical storage holding all actual data.

11. The query result is the final data returned to the user in the desired format.

1. Query Processing -The overall work the database does to understand and answer the question given

2.Query Compiler -Changes your SQL query into a form the computer understands and checks if there are any mistakes

3.Query Plan -A detailed set of steps on how to find the data you asked for

4.Query Optimizer -Looks at different ways to run the query and picks the fastest and most efficient method

5.Catalog Manager -Manages the information about the database’s structure and shares it with the optimizer when needed

6.System Catalog -A special storage that contains details about all tables, columns, indexes, and other database objects

7.Query Execution Plan-The final version of the plan after optimization, ready to be carried out

8.Command Processor -Sends instructions from the execution plan to the Data Manager

9.Data Manager -Handles the actual reading or updating of data in the database storage

10.Database -Where all the real data is kept

11.Query Result -The final answer that is sent back to the user

This refers to the complete process by which a database system handles a user’s query written in SQL.

2. Query Compiler

The query compiler converts the SQL query into an executable form representation. During this stage, it also verifies that the query’s syntax and meaning are correct.

3. Query Plan
A query plan outlines the sequence of operations the system will perform to retrieve the requested data, based on the intermediate form of the query.

4. Query Optimizer

The optimizer evaluates various possible execution methods for a query and selects the most efficient approach. It determines the sequence of operations, the indexes to apply, and the join methods to use.

5. Catalog Manager
The catalog manager oversees the system catalog, which contains metadata describing the database’s structure, indexes, constraints, and more. It supplies the optimizer with essential information about tables, indexes, and statistical data.

6. System Catalog

This is the repository of a database’s metadata, containing details such as table designs, index configurations, and storage specifications.

7. Query Execution
The finalized and optimized plan that the database engine will execute to process the query.

8. Command Processor

Executes the query by taking the final plan and working with the data manager to access or update the data.

9. Data Manager
Responsible for reading data from and writing data to the database’s physical storage.

10. Database 

The physical location where all data is stored.

In this process, user's query is handled by the database manager usually in SQL.

2. Query Complier:

This is the process where the query complier translates high level SQL query into an intermediate form.

It checks syntax and semantics to ensure that the query is valid.

3. Query Plan:

It's a set of steps the system will use to get the data from the intermediate query form.

4. Query Optimizer:

Query Optimizer looks at different ways to execute the query and chooses the most efficient way. It decides the order of operations, which indexes to use and join strategies.

5. Catalog Manager:

The Catalog Manager manages the system catalog, such as metadata about database structure.

6. System catalog:

System catalog is a database's metadata storage which contains information about indexes, tables, and statistics.

7. Query execution plan:

This is the final optimized stage which is ready to be used by the database engine.

8. Command Processor:

Command Processor takes the execution plan and coordinates with the data manager to retrieve and modify data

9. Data manager:

It handles actual data access fetching from and writing to the database storage.

10. Database:

The physical storage where the actual data is stored.

11. Query Result:

This is the processed and retrieved data which is returned to the user in the way the user requests.

• is the overall activity that user’s query handled by database system.

• usually in SQL

2.Query compiler

• compiler that translating high level SQL query into an intermediate form.

3.Query Plan

• to get the data the system will use a set of steps from a query plan. it is generated from the mid form of query.

4.Query Optimizer

• the query optimizer check different ways to run your query and pick the fastest one. it figures out which steps to do first, which indexes to use.

5.Catalog Manager

• managing the system catalog such as metadata about database structure, indexes and constraints.

• optimizer need a details about table,indexes and statistics

6.System Catalog

• it’s a database metadata storage that contains information

7.Query execution plan

• final optimized version

• ready to be run

8.Command processor

• take execution plan

• coordinate with data manager

9.Data manager

• this part gets the data from storage or saves new data into it.

10.Database

• the place where all the data is physically stored.

11.Query result

• the final data you asked for, sent back to you in the format you wanted.

1. Query Processing – This is the starting point where the database receives a user’s query.

2. Query Compiler – This part translates the user’s SQL query into an internal format that the database system can understand. It also checks if the query syntax is correct.

3. Query Plan – Here, the database creates a step-by-step outline (plan) of how to get the requested data. This is like a blueprint for execution.

4. Query Optimizer – The optimizer looks at the query plan and finds the most efficient way to run it, such as choosing the fastest search method or reducing unnecessary steps.

5. Catalog Manager – This component manages the system catalog, which stores information about the structure of the database (tables, columns, indexes, etc.). The optimizer often uses this data to make better decisions.

6. Query Execution Plan – After optimization, a final plan is prepared, detailing exactly how the database will retrieve and process the data.

7. Command Processor – This takes the execution plan and actually carries out the commands, interacting with the data manager.

8. Data Manager – This is the part that directly handles reading and writing data in the physical database storage.

9. Database – The actual storage where all data is kept.

10. Query Result – The final output that is sent back to the user after all steps are completed.

2. Query Compiler – Turns SQL into an intermediate form and checks it.

3. Query Plan – Steps to follow to get the data.

4. Query Optimizer – Picks the fastest, most efficient way to run it.

5. Catalog Manager – Manages database structure info for the optimizer.

6. System Catalog – Stores details like tables, indexes, and storage.

7. Query Execution Plan – Final optimized plan ready to run.

8. Command Processor – Runs the plan and works with the data manager.

9. Data Manager – Handles reading and writing data from storage.

10. Database – Physical place where data is stored.

11. Query Result – The fin

al data sent back to the user.

2) query compiler = this compiler is used to translate high level SQL into intermediate form

3) query plan = is a step that the system will be using toget the data and its generated from an intermediate form of the query.

4) query optimizer = search for alternatives way to execute

The query and choose the most suitable one.

5)catalog manager= it manages the system catalog for example

metadata ant database structure indexs , constrain and etc it will also provide the optimezer along with detail that is needed., about the table, indexes and

statistic

6) system catalog= its a database metadata storage that contain information such as table structure, index definition and storage detail

7) query execution plan = it is a final optimized version of the plan and ready to be run by the database engine.

8) commad processor = it will take the execution plan and coordinate with the data manager to retrieve or modify the data

9) data managers = they will handle actual data access fetching

From and writing to the database storage.

10) database = is a physical storage where the actual data is kept

11) query result = is the processed and retrieved data is returned to the user in the requested format

database system handle all activities involving user's query.

2.query compiler

translate high level SQL into a format database can understand easily.

3.query plan

a step-by-step list before actually running the query.

4.query optimizer

to find the quickest way most efficient way to follow the steps.

5.catalog manager

manages system catalog involving database structure, indexes, constraints, etc.

6.system catalog

database's metadata storage that contains information like table structures, index definitions and storage details.

7.query execution plan

finalised plan that is ready to be run by database engine.

8.command processor

coordinates with data manager to retrieve data from the execution plan.

9.data manager

actually fetches and stores data in the database.

10.database

physical storage where real data is stored.

11.query result

finalized answer.

 The Overall Activity.

It starts when you send the SQL statement and ends when you get back the answer.

At this point, the system only has raw text nothing has been checked or executed yet.

2.Query Compiler

-acts like a translator.
-It takes your SQL query and converts it into an intermediate form that the database can work with internally.
-It checks:
Syntax = Is your SQL written correctly?
Semantics = Do the tables, columns, and operations you mention actually exist and make sense?
-If something is wrong, you get an error message here before anything else happens.

3.Query Plan

-Once the query is valid, the system creates a query plan or a step-by-step roadmap of how it could get the data.
-This is not yet the final optimized plan; it’s more like the first draft.

4. Query Optimizer

-The optimizer looks for the fastest and most resource-efficient way to execute the query.
-It considers:
=The order to process different parts of the query

=Which indexes to use
=Which join methods are best

-The optimizer is critical because the difference between a good and bad plan can mean seconds vs. hours in execution time.

5. Catalog Manager

This part keeps track of metadata //information about the database.
It tells the optimizer details like:

=How big each table is

=What indexes exist

=What constraints apply

-Without this info, the optimizer would be guessing.

6. System Catalog

The actual storage of metadata (also called the data dictionary).

Contains things like: Table structures, Index definitions, Column data types and Storage details

7. Query Execution Plan

After optimization, the final execution plan is produced.

This is the ready-to-run version of the plan the database will follow.

8. Command Processor

-This component takes the execution plan and works with the data manager to carry it out.

-Think of it as the coordinator that says:
Alright, step 1: do this rows. Step 2: join with that table. Step 3: filter results.

9. Data Manager

The data manager is the one that actually goes to storage and:

Fetches the data, Writes any changes back, It deals with low-level data access.

10. Database (Physical Storage)

-This is where the actual data lives =on disk or in memory.

-Could be in tables, indexes, and files.

11. Query Result

After the data is processed according to your SQL instructions, the results are sent back to you.

The output can be: A table of rows (for SELECT), A success message (for INSERT, UPDATE, DELETE)

This is the starting point, where the database system receives the query (often written in SQL) from the user

2. Query Compiler

The compiler checks if the query is written correctly (syntax check) and translates it into an internal form that the database can work with.

3. Query Plan

This is show the way of how the database could run the query, detailing the steps and methods to retrieve the needed data.

4. Query Optimizer

The optimizer looks at different possible query plans and chooses the most efficient one, using information from the System Catalog (which stores metadata about the database’s structure, indexes, and statistics).

5. Query Execution Plan

This is the final, optimized plan that the database will actually run to get the results.

6. Command Processor

This component interprets the execution plan and passes instructions to the Data Manager to fetch or update the data.

7. Data Manager

The data manager controls access to the physical database, ensuring the correct records are read or modified.

8. Database

This is where the actual data lives, stored on disk or other storage systems.

9. Query Result

After execution, the processed data is returned to the user in the required format.

Database system control overall activity that involve user query for execution.

- Query Compiler: Transforms the query compiler into a middle form

- Query Plan: A detailed strategy for executing the query for generate from intermidate form of query.

- Query Optimizer: Analyzes different execution strategies to find the most efficient plan.

- Catalog Manager: Manages metadata about the database structure, which is used during optimization and execution.

- System Catalog: Stores metadata about the database, such as table structures and indexes

- Query Execution Plan: The optimized plan is executed to retrieve the desired data.

- Command Processor: Processes the commands from the query execution plan.

- Data Manager: Handles the actual retrieval and manipulation of data from the database.

- Database: The organized collection of data stored and managed by the system.

- Query Result: The final output of the query for the requested information to the user.

1. Query processing: The overall process of how the database system manage the query.

2. Query Compiler: Ensures the accuracy of the query by checking the syntax and semantics. It translates the intermediate form from high-level SQL query.

3. Query Plan: Step-by-step the system use to get the data. It is comes from the intermediate form of the query.

4. Query Optimizer: It find the other way to execute the query and choose the most effective one. It decides the the arrangement of operations, indexes to use, and join strategies.

5. Catalog Manager: managing the system catalog which is consist of Database structure, indexes, constraints and etc. Provides the optimizer with needed details of the table, indexes, and statistics.

6. System Catalog: Database’s metadata storage contains information like table structures, index definitions, and storage details.

7. Query Execution Plan: It is the confirm version of the plan and ready to be run.

8. Command Processor: Takes the plan and align with the data manager to retrieve or modify the data.

9. Data Manager: Handles data access and write it to the database storage. Database Control System is the component of a DBMS that acts as a bridge between the data stored in the database and the queries received from users or applications.

10. Database: The place where the data is stored.

11. Query Result: The processed data is returned to the user.

the database process the user's query and come out with the results

Query Compiler

Check and translate the high-level SQL and ensure the validity of the query

Query Plan

Step by step plan in the system, translated into the valid query by the system to get the proper results from user's input

Query Optimizer

Execute and choose the most efficient query

Catalog Manager

Managing the track of all about of the data

Library of the data ( metadata )

System Catalog

Database that contains information of the metadata

Query Execution Plan

Final optimized version which is ready to be run

Command Processer

Read and check if it's valid and send to the part to modify the data

Data Manager

Handles the real data

Opens, read, fetching and storing the data

Database

Keeps and store the data

Query Result

Processed and sent in formatted data structure

Instructions for Students:

• You are simulating a bank transfer between two accounts.

• Follow these steps carefully and decide whether the transaction should COMMIT or ROLLBACK.

Question:

• Should this transaction be committed or rolled back?

• Explain why based on the ACID properties.

Step 2 is failed so the transaction is not accurate to continue. Therefore it should rollback

In Acid properties

Atomicity- either all parts or non of the parts of transaction should happen.

As here step 2 is failed, whole transaction should be aborted

_{Because Step 2 failed, committing would violate Atomicity and Consistency money would disappear from the system. Rolling back ensures both accounts return to their original state, preserving database integrity.}

because the transfer from A has been deducted while it hasn’t been received for B because there’s a failure it cannot me a commit so it’s a rollback

and when it comes to the acid properties it’s atomicity. it means if step 2 fails step one must be rollback

=Rolled back

2.Explain why based on the ACID properties.

Atomicity = transaction must be all or nothing 

In this case the step 1 is succeeded but step 2 failed so the entire transaction must be rolled

Since money was deducted from Account A but not added to Account B, the database became inconsistent.

Rolling back undoes the partial change and restores consistency.

This preserves the ACID properties of transactions.

According to the ACID properties:

-Atomicity – All steps must succeed or none at all. Here, deduction from Account A succeeded but credit to Account B failed, so rollback is required.

-Consistency – The database must remain valid. If committed, RM300 would be lost, making the system inconsistent. Rolling back restores the original state.

-Isolation – Transactions must not interfere. Rolling back prevents other transactions from seeing this incomplete transfer.

-Durability – Only successful transactions are permanent. Since this one failed midway, it cannot be committed.

Explanation based on ACID:

1. Atomicity (All or nothing):

Since Step 2 failed, the transaction is incomplete.

To follow atomicity, we must undo Step 1 (put RM300 back in Account A).

2. Consistency:

If we commit now, Account A loses RM300 but Account B doesn’t get it.

That breaks consistency.

3. Isolation:

Isolation ensures no other transaction sees the “half-done” transfer.

4. Durability:

Durability ensures only successful, committed transactions are saved.

Therefore, this transaction should be ROLLED BACK because it did not complete successfully. According to ACID rules, either both accounts must be update

d or none at all.

• Based on the ACID properties, this step is called as Atomicity. Atomicity means a transaction is all or nothing. For example, if step 2 fails, step 1 must rollback.

Reason (ACID):

Atomicity: All steps must succeed or none. Since Step 2 failed, the whole transaction fails.

Consistency: Money cannot disappear. If we commit, RM300 is lost.

Isolation & Durability: Other users must not see incomplete results, and only successful transactions should be saved.

Therefore, we must rollback to keep the accounts correct.

From Atomicity of ACID properties, transaction is only single unit and if one operation is failed, none of them would've completed. In this, database returns to original due to failure at second step.

Atomicity: These requires transaction 'all or nothing'. Since step 2 failed, the entire transaction must be rolled back to make sure that there is no partial changes saved. Therefore, to enforce this property, the entire transaction must be rolled back, to undo the deduction from account A. Ensure 'all or nothing'.

Explanation using ACID properties:

Atomicity

A transaction is all or nothing. Since Step 2 failed, Step 1 (deduction) must also be undone. Otherwise, Account A will lose RM300 without Account B receiving it.

Therefore, rollback is required.

Consistency: Without rollback, total funds drop by RM300 (A lost money, B didn’t gain) It violates balance invariants.

Isolation: Until success, no other transaction should see a partial transfer. Rolling back prevents exposure of the half-done state.

Durability: Because we don’t commit, none of the partial changes become permanent.

Reason :

Atomicity (All or Nothing): Step 2 failed, so we must cancel Step 1 also.

Consistency: If we only deduct from A and not add to B, money will disappear. That is not correct.

Isolation: Others should not see half-done work.

Durability: If we commit now, the wrong result will be saved forever.

b) This leads to atomicy which means that a transaction is all or nothing. For example, if step 2 fails, step 1 must rollback.

Reason (using ACID):

Atomicity (All or Nothing): Step 2 failed, so we must cancel Step 1 also.

Consistency: If we only deduct from A and not add to B, money will disappear. That is not correct.

Isolation: Others should not see half-done work.

Durability: If we commit now, the wrong result will be saved forever.

The transaction should be rollback because it failed at stage 2

Question2

1. Atomicity -All steps must succeed or none at all. Since step 2 failed, we must cancel everything.

2. Consistency -The money must not disappear.

3. Isolation -Other transactions must not see half-done transfers. Rolling back hides the failure.

4. Durability -Only successful transactions should be saved permanently. Failed ones must not.

Why?

1. Atomicity

A transaction must complete fully or not at all.Here, only Step 1 worked but Step 2 failed - violates Atomicity.Therefore, rollback is needed to undo the deduction from Account A.

2. Consistency

The total money before and after must remain the same.If only Account A lost money and Account B didn’t receive it, consistency is broken.

3. Isolation

Other transactions should not see incomplete updates.If committed, other users might see Account A with less money while Account B didn’t gain — incorrect.

4. Durability

Only successful transactions should be saved permanently.Since this one failed halfway, it must not be saved.

1. Atomicity

Atomicity means all steps of a transaction must succeed, or none at all.

Here, Step 1 succeeded, but Step 2 failed.

Since not all operations succeeded, the entire transaction must be undone (rollback) to maintain consistency.

2. Consistency

The database should remain in a valid state before and after the transaction.

If we commit now, RM300 would be missing (deducted from A but never added to B), which breaks consistency.

Rolling back restores the database to its original state (no money lost).

3. Isolation

Isolation ensures transactions don’t interfere with each other.

If this transaction is rolled back, it will be as if it never happened, preventing inconsistencies from leaking into other transactions.

4. Durability

Once a transaction is committed, changes must be permanent.

Since this transaction is invalid (partial failure), it cannot be committed. Only after a successful completion of all steps would durability apply.

2.According to the ACID properties:

Atomicity requires that all steps of the transaction succeed or none at all. Since Step 2 failed, the whole transaction must be undone.

Consistency ensures money is not lost or created incorrectly. If we commit, Account A would lose RM300 while Account B receives nothing, which is inconsistent.

Isolation prevents partial updates from being visible to others, so rollback maintains correctness.

Durability means only successful transactions are saved permanently. Since this transaction failed, it cannot be saved.

Explanation:

· Atomicity requires that a transaction must be "all or nothing" - either all operations complete successfully, or none do.

· In this case:

· Step 1 (Deduct RM300 from Account A) succeeded

· Step 2 (Add RM300 to Account B) failed

· Since one part of the transaction succeeded while the other failed, the transaction is incomplete and inconsistent.

1. Atomicity – A transaction must succeed fully or not at all. Since Step 2 failed, the whole transaction must be undone.

2. Consistency – If committed, RM300 would disappear (deducted from A but not added to B). Rolling back keeps the accounts correct.

3. Isolation – Rolling back ensures no incorrect changes affect other transactions.

4. Durability – Only successful transactions are saved permanently. This one failed, so it cannot be committed.

Atomicity – A transaction must succeed fully or not at all. Since Step 2 failed, the whole transaction must be undone.

Consistency – If committed, RM300 would disappear (deducted from A but not added to B). Rolling back keeps the accounts correct.

Isolation – Rolling back ensures no incorrect changes affect other transactions.

Durability – Only successful transactions are saved permanently. This one failed, so it cannot be committed.

- ISOLATION: other transactions should not see the part

- DURABILITY: only applies after a successful commit

2.

1. Atomicity – A transaction must be all or nothing. Since Step 2 failed, the whole transaction cannot be considered complete. Rolling back ensures Account A gets back the deducted RM300.

2. Consistency – The database must remain in a valid state. If we commit after deducting from A but failing to add to B, money will "disappear," violating consistency.

3. Isolation – Other transactions should not see partial updates. If not rolled back, other users may see Account A reduced while Account B doesn’t get the money.

4. Durability – Only successfully completed (committed) transactions are saved permanently. Since this transaction failed, it must not be saved.

Atomicity

A transaction is all or nothing.

Since Step 2 failed, Step 1 must also be undone. Otherwise, Account A will lose

RM300 without Account