Database (CS432)

Group 10
FreshWash : Laundry Management System
Module 2 Report
Objective : In this Module 2, we need to design UML diagrams and transition them into ER
diagrams to create a structured database schema. This process ensures a well- organized
visualization of the database entities and their relationships, aligning with the database schema
from Module 1.

Task 1
Our task is to design a UML class diagram; however, we have also designed a series of other diagrams. These
include a Use Case Diagram, Activity Diagram, Sequence Diagram, and Deployment Diagram. This is because
each of these diagrams presents different views and a full picture of the system, each with a specific role in
the system's design and implementation phases.
The Use Case Diagram helps identify the interactions between actors and the system's functional
requirements. Thus, it may help us identify the entities of the database as well as the classes for the UML
class diagram.
Activity Diagram visualizes the workflow or internal processes. This will help us identify some of the total
and partial participation between entities and relationships.
The Sequence Diagram shows the sequence of interactions between objects, aiding in understanding the
system's dynamic behaviour. Making this diagram will help us identify some attributes of relationship tables.
For instance, we found that we need an attribute “payment_date” in the “do_payment” relationship date to
justify the sequence between “order confirmed” and “process order”. We will discuss about this in detail in
the later section of this report.
The Deployment Diagram illustrates how the system components are physically deployed on hardware,
providing insights into the system's architecture. This diagram will help us to do the module 4 task for this
course.
And lastly, the Class Diagram is essential because it provides a detailed static view of the system's structure,
showing the classes (entities) involved, their attributes, methods, and the relationships between them. Also,
association between classes will tell us about the total and partial participation between entities and
relationships. Furthermore, it will help us in doing the Module 3 tasks.

The Use Case Diagram (UCD):

Use Case Diagrams are visual tools in Unified Modeling Language (UML). These visual tools are
diagrams that represent the different external actors and their interactions with a system's functionalities
(for example, user, role, or system). These diagrams represent use cases (specific actions or services the
system provides) in the form of ovals, and actors are stick figures with lines from which they are defined or
identified as being active. Relationships are indicated by the "<<include>>" and "<<extend>>" notations to
show how use cases are related to each other. For instance, within a laundry system, a "Customer" actor
interacts with use cases like "Place Order" and "File Complaint," while a "Staff" actor would manage the use
case "Update Order Status" instead. Use-case diagramming focuses on what the system does to the view of
users rather than technical details for concepts.
Use Case Diagrams serve to align stakeholder communication, shape system boundaries, and then
refine requirements. They act as the link for a technical team and non-technical team in order to arrive at a
common understanding of scope and function to be satisfied. During early development phases, these
provide a means to gaps (e.g., missing "Refund Order" use case) and redundancy identification, alongside a
guide to feature importance. It also includes reducing risk of misinterpretation regarding user goals to what
system function should perform and that alignment guarantees on what business really needs from the end
product.

Explanation of the above UCD:

Actors:

• Customers: User who will use the laundry services.

• Delivery Partner: Person responsibly for picking up and delivering the laundry.
• Manager: Person will look over the employee and also oversees operations such as order tracking,
payment tracking, and resolving complaints.
• Employee: Person responsible for handling and processing laundry orders and also resolves
complaints. He is the person who will actually wash the clothes. There may be a situation where
his/her involvement is needed to solve a particular complaint.
• Database System: This is the place where all the order details will be stored for future. It will get the
details from use cases such as update order status, track payments, track orders & handles/process
orders.
Use Cases and Their Descriptions:
Customer Use Cases:

• Register & Login: Customers must register and log in before accessing services.
• Place Orders: Customers can place laundry orders.
• Make Payments: Customers pay for their laundry services.
• File Complaints: Customers can file complaints about service issues like lost clothes, damaged
clothes, etc.
• Track Orders: Customers can check their order status.
Delivery Partner Use Cases:

• Pick Up Orders: Collects laundry from customers.

• Deliver Orders: Returns cleaned laundry to customers.
• Update Order Status: Delivery partner can modify status about orders like “picked up”, “in-transit”,
etc.
Manager Use Cases:

• Update Order Status: Keeps track of order progress.

• Track Payments: Monitors transactions related to payments.
• Resolve Complaints: Handles customer complaints.
Employee Use Cases:

• Handles/Process Orders: Employees process laundry orders, wash clothes, etc

• Resolve Complaints: Employees assist in resolving customer complaints when needed.
• Update Order Status: Employee can modify status about orders like “washed”, “clothes ironed”, etc.
Database System Use Case:

• Track Orders: The database automatically records and updates order tracking information.
• Handles/Process Orders: Database stores information regarding the employee working on a
particular order.
• Update Order Status: Database automatically records and updates the modified order related
information from the service provider side.
• Track Payments: Database stores payment details like transaction id and date, etc.

Relationships:

• Includes (<<include>>) Relationship: The Register use case is included in Login, because it is a
mandatory process to be done by the user before using the laundry system.
• Extends (<<extend>>) Relationship: File Complaints extends Place Orders because a customer can
file complaint if he/she wants, regarding an order. It is not mandatory!
Benefits of UCD in Creating ER and Class Diagrams
1. Defines Classes and their responsibilities in the Class Diagram.
• Each use case tells us about the functional components which requires classes and methods
in an Object-Oriented Model.

• For example:
1. Customer Class would be one of the core classes in a class diagram with attributes
such as “Name, Email, Age, etc” and methods such as “register(), login(),etc” .
2. Order Class would contain attributes like “Order ID, Status, etc” and methods like
“updateStatus(), trackOrder()”.
3. Manager Class will have methods like “resolveComplaints(), trackPayments()” .

2. Helps Identify Entities for ER Diagram

• As discussed above, it will assist in creating a class diagram, which will ultimately help us
identify the entities.
• The actors and use cases help define key entities such as Customers, Orders, Payments,
Employees, Complaints, and Database System.
Inshort, the Use Case Diagram will serve as a blue print to create class diagram and ER diagram.
The Activity Diagram:
Explanation of the above Activity diagram:
Actors:
1. Customer: Places order, makes payments, and files complaints if necessary.
2. Staff: Handles orders, resolves complaints, and updates order statuses.
Workflow Steps:
1. Order Placement Process:

• The process begins when a customer places an order.

• A decision node checks if the order is placed:
➔ If NO, the process terminates
➔ If YES, the customer proceeds to add items to the order.
2. Payment Process:

• The customer proceeds to make payment.

• A decision node checks if the payment is completed:
➔ If NO, the process terminates.
➔ If YES, the order is sent to the staff for handling.
3. Order Processing:

• The staff handles the order after payment is confirmed.

4. Complaint Filing Process:

• A decision node checks if the customer wants to file a complaint:

➔ If NO, the process moves to closing the order.
➔ If YES, the complaint is filed and forwarded to the staff.
5. Complaint Resolution Process:

• The staff resolves complaints and updates the order status.

• After resolution, the order is closed, marking the end of the process.

Benefits of Activity Diagram in Creating ER and Class Diagrams

1. Identifying Entities for ER Diagram:

• Relationships in the decision nodes guide in defining entity associations and constraints.
2. Understanding Total and Partial Participation:

• Decision nodes (where branches divide) represent participation constraints in the ER diagram:
• Above the decision point (e.g., "Order Placed" ), Customers can exist without placing orders,
i.e., it has two options either enter the order branch or go to Final activity node. Thus, it
represents partial participation (not all instances participate).
• Below the decision point (e.g., "Handling Orders" or "Updating Status") represents total
participation (all instances must participate in the process then and only then it will enter in
that particular branch).
The Class Diagram:-

Class diagrams are structural diagrams in the UML representing a system's static structure in terms of its
classes, attributes and relationships between classes. Class diagrams view some schemas of software
systems, representing classes in boxes with three compartments: class name, attributes (variables), and
methods (functions). Relationships exist between classes and are depicted using notations of either arrows
or lines, corresponding to inheritance (generalization), associations, aggregation, composition, and
dependencies. Class diagrams give a clear view of the hierarchical arrangement of the components of the
system, together with encapsulation, inheritance, and polymorphism - the basic principles of OOP.

The class diagrams further define, describe, and analyze the structural aspects of a software system during
its software development lifecycle. They provide a concrete means for the developers to plan the interactions
between objects, validating data models, and maintaining consistency across teams. These diagrams aid in
identifying redundancies or useful code reuse by outlining relationships and dependencies and ensuring that
it complies with the business requirements. They also serve as a visual aid for all stakeholders - developers
writing the code and project managers monitoring the timelines - thus completing the divide between
technical and non-technical communication.
Note: Class diagram basically represents our development code(OOP), improving our database quality.
Core Business Entities:
Customer
At the heart of the system is the Customer class, representing individuals who use the laundry service. Each
customer has personal attributes like name, contact information (email, phone), and verification status.
Customers can place orders, view their order history, and file complaints when necessary. The customer's
relationship with the system begins here, forming the foundation for all subsequent business processes.
Order
The Order class encapsulates a complete laundry transaction from creation to delivery. Orders have a defined
lifecycle tracked through status updates (Pending, Processing, QualityCheck, Completed) and contain
essential timing information like pickup and delivery dates. Orders can generate invoices and estimate
completion times, providing customers with transparency throughout the process.
Item
The Item class represents individual garments within an order. Items are categorized by garment type (Shirt,
Pant, Dress, Bedding) and include details about fabric type and specific cleaning instructions. Each item has
associated pricing information and service charging methods, ensuring accurate billing for different types of
laundry items.
Payment
The Payment class handles all financial transactions in the system. It supports various payment modes
(Credit, UPI, Cash, Debit) and tracks payment status. Methods for processing payments, verifying
transactions, and generating receipts ensure smooth financial operations, while refund capabilities handle
exceptions.

Staff Hierarchy:
Staff (Base Class)
The Staff class serves as the parent class in an inheritance hierarchy, containing common attributes for all
employees like ID, name, contact information, and scheduling data. Staff members are responsible for
handling orders, resolving complaints, and updating order statuses throughout the fulfillment process.
Operator
The Operator subclass represents staff members who handle day-to-day laundry processing. Operators work
at specific workstations during assigned shifts, processing orders and escalating complaints when necessary.
They form the operational core of the laundry service.
Manager
The Manager subclass represents supervisory staff with special privileges. They have different access profiles
(FINANCIAL, OPERATIONAL, STRATEGIC) and can generate reports, approve refunds, and handle escalated
complaints. Managers supervise other staff members, creating an organizational hierarchy within the system.
Deliverer
The Deliverer subclass represents staff members who handle the final step in the order process. They
manage delivery zones and vehicles, update delivery statuses, and check availability for optimized delivery
scheduling. Their role ensures orders reach customers efficiently.
Support Processes:
Complaint
The Complaint class manages customer grievances within the system. Complaints are categorized by type
(Quality, Timing, Loss) and track resolution status. The system supports escalation processes, evidence
attachment, compensation calculation, and formal resolution documentation, ensuring customer satisfaction
even when problems occur.

Benefits of Class Diagram in Creating ER Diagram

1. Inheritance & Specialization
• Clarifies Hierarchies: Models, avoiding ER’s table structure.
• Guides Implementation Strategies: Informs decisions like single-table vs. joined-table designs.
2. Advanced Relationship Semantics
• Composition/Aggregation:
• Composition (represented as ◆→) → translates to ER CASCADE DELETE constraints.
• Aggregation (represented as ◇→) → translates to ER nullable foreign keys.
• Qualified Associations: Refines ER cardinality (e.g., Customer *→ Order, one to many).
3. Implementation-Ready Constraints
• Multiplicity Rules: Translates UML 1..5 to ER cardinality constraints (e.g., CHECK greater than 1, less
than 5).
4. Transition to Physical Data Models
• Optimizes Performance:
• Frequent joins → should Denormalized tables.
5. Error Prevention
• Polymorphism Support: Class hierarchies prevent ER data redundancy (e.g.,
shared Employee attributes).
• Constraint Validation: UML type-checking (e.g., String(50) for names) → ER VARCHAR(50) with NOT
NULL.
Modelling Steps:
1. Identify Classes
2. Define Attributes/Methods
3. Establish Relationships
4. Apply UML Notation
5. Iterate & Refine
The Sequence Diagram:-

Sequence diagrams, behavioural model of Unified Modelling Language (UML), characterize an essential
means for visualizing the interactions between various system components or objects at a given moment in
time. That is to map the paths of vertical lifelines with horizontal arrows that show communications, including
message passing, method calls and events. Sequence diagrams are best for dealing with time-sensitive
scenarios, like API communications, distributed system communications, or user-driven workflows, using
UML-approved standardized notations for consistency for all teams.

The sequence diagram is one way to design, analyze, and document the dynamic behaviour of a system
during the software developmental process. Engineers make use of sequence diagrams in the following
activities:
1. Validating Use Case Scenarios: High-level requirements (e.g., "process payment") into precise object
interactions; check that all components can be properly coordinated.
2. Debugging Complex Workflows: Use the message sequences to visualize the flow of communication,
to find race conditions in multi-threaded systems, or determine missing error-handling logic.
3. Distributing Cross Team Communication: Visual contract between developers, testers, and naked
stakeholders that reflect actual technical implementation against expected business requirements.
Brief Description:
Actors
• Customer
• Primary user who initiates the order process
• Interacts with the system to place orders and make payments
• Receives order updates and notifications
• Can file complaints when issues arise
• Staff
• Processes assigned laundry orders
• Marks orders as completed after processing
• Handles customer complaints
• Investigates issues and implements resolutions

System Components
• Laundry System
• Central controller coordinating all interactions
• Manages communications between users and data objects
• Processes customer requests and staff actions
• Serves as middleware between frontend and backend services
• Order
• Represents the transaction record
• Created when customer initiates new order
• Maintains order status throughout the process
• Connects customer requests to internal processing
• Item
• Represents laundry articles within an order
• Stores details about garments (likely type, quantity, etc.)
• Confirms item specifications before processing
• Linked to specific orders
• Payment
• Handles financial transactions
• Processes payment confirmations
 • Verifies transaction success
• Ensures proper billing before order processing
• Complaint
• Records customer issues
• Stores investigation details
• Tracks resolution progress
• Documents the entire complaint lifecycle

Key Interactions
• Order Flow
• Customer → System: Places new order
• System → Order: Creates new order record
• System → Item: Adds selected items
• Item → System: Confirms item details
• System → Customer: Shows order summary
• Customer → System: Confirms payment
• System → Payment: Processes transaction
• Payment → System: Confirms transaction success
• System → Staff: Assigns order for processing
• Staff → System: Marks order as completed
• System → Customer: Notifies order processed
• Complaint Flow
• Customer → System: Files complaint
• System → Complaint: Creates complaint record
• System → Staff: Assigns complaint for resolution
• Staff → Complaint: Investigates issue
• Staff → System: Resolves complaint
• System → Customer: Sends resolution details
Benefits of Sequence Diagram in Creating ER Diagram
Sequence diagrams (dynamic behavioral models) help refine ER diagrams (static data models) by
revealing interactions and data flows that inform entity relationships and constraints. Here's how:
1. Identify Core Entities
• Extract ER entities from message sequences (e.g., Customer, Order, Payment).
2. Define Relationships
• Map message interactions to ER relationships:
• Customer → Order (places) = 1:N relationship.
• Order → Payment (processes) = 1:1 relationship.
3. Infer Attributes
• Message parameters → ER attributes:
• createOrder(orderID: string, date: Date) → ER: Order entity with orderID (primary
key), orderDate.
• processPayment(amount: float) → ER: Payment entity with amount (decimal).
4. Determine Multiplicity
• Loop/alt fragments → Cardinality rules:
• A loop adding multiple items → ER: Order (1) → Item (1..*).
• Conditional payment failure → ER: Payment entity with status enum(Failure).
5. Add Constraints
• Message order → Database triggers/foreign keys:
• Payment must follow Order in sequence → ER: Order.orderID as foreign key in Payment.
• deleteCustomer() cascading to orders → ER: ON DELETE CASCADE.

Modelling Steps:
1. Define Scenario
2. Identify Actors/Objects
3. Create Lifelines
4. Add Messages
5. Add Activations
6. Include Fragments
7. Validate Flow
8. Refine
The Deployment Diagram:-

Deployment diagrams in the Unified Modelling Language (UML) are structural diagrams which show the
architecture of hardware in a software system. Such diagrams show how software components are relevant
to hardware structure. These diagrams can show how nodes, a part of a system - such as components,
databases, and files - are distributed across some type of physical or virtual nodes like servers, devices, or
cloud-systems. A node can either be counted as hardware, like servers and user devices, or software
environments, like containers or virtual machines. Connections between nodes represent network lines.
Hence, this shows that this diagram shows an instance of a web application deployed to a cloud server node,
which communicates with a database on the same node via queries; while client devices interact through
HTTP requests.
Deployment diagrams are used to ensure stakeholders about the software design as well as the hardware
architecture involved in the system. Engineers depend on them to optimize the allocation of resources,
whereas developers rely on them for configuration validation. Deployment diagrams model the relevant
relationships between hardware and software components, thereby minimizing risks associated with
deployments or upgrades as well as with recovery scenarios. The result is a sound design in logical
formulation and reliance on physical execution.
Note: This Diagram will help us in preparation for deployment (Task 4) and modelling ER diagram in regards
to that.
Brief Description of diagram components:
Client Device
• Houses the Web Browser used by customers to access the service
• Initiates HTTP Requests to the cloud server for laundry services
• Receives Notifications from the system about order status and updates
• Represents the primary user touchpoint for the laundry management system1
Cloud Server
• Acts as the centralized hosting environment containing multiple components
• Provides infrastructure for the entire application ecosystem
• Processes requests and coordinates communication between all system parts1
Application Server
• Contains the FreshWash Web Application (core business logic)
• Processes client requests and generates appropriate responses
• Handles Queries to the database for data retrieval and storage
• Manages Access Control for administrative functions
• Initiates Payment Requests to external payment processors1
Database Server
• Houses the FreshWash Database storing all system information
• Maintains records of customers, orders, payments, and inventory
• Responds to queries from the application server
• Provides persistent data storage for the entire system1
Admin Device
• Provides access to the Admin Panel for staff and management
• Sends HTTP Requests for administrative functions
• Receives Access Grants from the application server
• Enables system management, reporting, and oversight functions1
Payment Gateway
• Contains the Payment Processor for handling financial transactions
• Receives Payment Requests from the application server
• Returns Confirmation of successful or failed transactions
• Provides secure interface for monetary operations1
Communication Flows
 • Client-to-Server: HTTP requests for service and data retrieval
• Server-to-Client: Notifications about order status and updates
• Application-to-Database: Queries for data operations
• Application-to-Admin: Access control and management functions
• Application-to-Payment: Financial transaction processing

Benefits of Deployment Diagram in Creating ER Diagram

Deployment diagrams help in formulation Entity-Relationship (ER) diagrams by providing insights into
the hardware infrastructure and data distribution requirements of a system. While ER diagrams focus on
logical data relationships, deployment diagrams reveal how data components (e.g., databases, file storage)
are physically distributed across nodes (servers, cloud, or devices). This physical mapping directly informs ER
design decisions such as:
• Data Partitioning: If a deployment diagram shows databases distributed across regions, the ER
diagram may require geographic attributes or replication relationships.
• Node-Specific Requirements: A deployment diagram with IoT devices collecting sensor data would
prompt ER entities.
Modelling Steps:
1. Define System Scope
2. Identify Physical Nodes
3. Create Node Relationships
4. Validate

Now, we have looked at all the UML diagrams, not let’s look at the final ER diagram.
The ER Diagram:

Explanation of the above ER diagram:

After we identified the Entities using the Class Diagram, we first drew the entities for the ER diagram.
Entities: All entities are represented in rectangle shape. Also weak relationship is represented by double
concentric rectangle shape.
1. Customers(Strong Entity): This table contains the details about customers who are going to use the
laundry services. It has attributes like “customer_id” which is also a primary key(used underline to
represent it), customer_name, customer_image, Age, customer_phone, customer_email and
customer_address. Here customer

2. Orders(Strong Entity): This table contains the details about the orders a customer placed. Here, order
means ‘BUCKET OF CLOTHES’ for which the customers want to avail the laundry services. It contains
attributes such as order_id, order_status, Total_Amount, Pickup_Date and Delivery_Date. In this
table “order_id” is the primary key(used underline to represent it).

3. Items(Weak Entity): This table contains the details of individual clothes. Its primary key is derived
from “Orders” entity. Its primary key is (order_id,item_sequence). Thus, it is a weak entity. Its other
attributes are item_type, item_details and price. You may notice the attribute “price” is represented
in a dotted line ellipse, because it is a derived attribute. We have derived it using the “item_type”
attribute, i.e., the price of clothes is already defined. For example, if a user selects T-shirt in items(user
wants to avail laundry service for that particular item), for T-shirt price will be defined as 10 or say x
Rupees. Thus, it will be automatically fetched and it becomes a derived attribute.

4. Staff: This table contains the details about the staff members working in this laundry service. Each
staff has an Id and it is a primary key for this table(staff_id). Other attributes are staff_name,
staff_image, staff_age, staff_positon, staff_phone, staff_email and hire_date.

5. Complaints: This table contains the details about the complaint a customer makes for a laundry
service. Each complaint has its own id which is also the primary key of this table(complaint_id). Other
attributes are complaint_type(damaged clothes, missing clothes,etc), complaint_details and
complaint_status.

6. Payments: This table contains the details about the payment a customer does for a laundry service.
It has attribute payment_id which is also the primary key of this table. Other attributes are
payment_mode and Amount.
After we identified the relationships and their attributes using the Class Diagram, Activity Diagram &
Sequence diagram, we drew the relationships for the ER diagram.
Relationships: All relationships are represented in Diamond shape. Total participation is represented by
double lines and partial participation is represented by single line. Also, weak relationship is represented
by double concentric diamond shape.
1. Customer Places Orders (1:N):
Relationship Name: places
Entities Involved: Customers & Orders
Cardinality: One-to-Many (1:N)

Explanation:
• Each Customer can place multiple Orders, but each Order is placed by only one Customer.
• Example: A customer named John can place multiple orders, such as an order for laundry
service on Monday and another on Friday. However, each order belongs to only one customer.

Participation:
• Customers (Total Participation) → A customer must place at least one order.
• Orders (Partial Participation) → An order cannot exist without being placed by a customer.

2. Orders Consist of Items (M:N)

Relationship Name: Consists
Relationship Type: Weak
Entities Involved: Orders & Items
Cardinality: Many-to-Many (M:N)

Explanation:
• Each Order can contain multiple Items, and each Item can be part of multiple Orders. Also, it
is a weak relationship because item cannot exist without being ordered by a Customer and
Item itself is a Weak Entity.
• Example: An order might include a "shirt wash" and a "jeans dry-cleaning," and these items
might appear in other orders of other customers as well.

Participation:
• Orders (Total Participation) → Every order must consist of at least one item.
• Items (Partial Participation) → Some items may not yet be ordered.

3. Staff Handles Orders (M:N)

Relationship Name: handles
Entities Involved: Staff & Orders
Cardinality: Many-to-Many (M:N)

Explanation:
• Multiple Staff members can handle multiple Orders, and each Order can be handled by
multiple Staff.
• Example: A laundry order might be processed by one staff member for washing and another
for ironing. Similarly, a staff member can handle multiple orders at once.
 Participation:
• Orders (Total Participation) → Every order must be handled by at least one staff member.
• Staff (Partial Participation) → Some staff may not currently be assigned to handle any order.

4. Supervisor-Supervisee Relationship in Staff (1:N)

Relationship Name: supervises
Entities Involved: Staff & Staff
Cardinality: One-to-Many (1:N)

Explanation:
• Each Supervisor manages multiple Staff, but each Staff member has only one Supervisor.
• Example: A senior laundry manager may supervise multiple workers, but each worker reports
to only one supervisor.

Participation:
• Supervisor (Partial Participation) → Some staff may not be supervisors.
• Supervisee (Total Participation) → Every worker must have a supervisor.

5. Complaints Filed by Customers (N:1)

Relationship Name: files
Entities Involved: Customers & Complaints
Cardinality: One-to-Many (1:N)

Explanation:
• A Customer can file multiple Complaints, but each Complaint is associated with only one
Customer.
• Example: If a customer receives a damaged item, they may file a complaint. The same
customer might file another complaint for a delay in order delivery. However, a complaint
cannot belong to multiple customers.

Participation:
• Customers (Partial Participation) → Not all customers file complaints.
• Complaints (Total Participation) → Every complaint must be associated with a customer.

6. Complaints Resolved by Staff (M:N)

Relationship Name: resolves
Entities Involved: Staff & Complaints
Cardinality: Many-to-Many (M:N)

Explanation:
• Multiple Staff members can handle multiple Complaints, and a Complaint can be resolved by
multiple Staff.
• Example: A billing issue might be resolved by a manager, while a laundry damage complaint
might be handled by a senior laundry worker.

Participation:
• Staff (Partial Participation) → Some staff may not handle complaints.
 • Complaints (Total Participation) → Every complaint must be assigned to at least one staff
member for resolution.

7. Customers Make Payments (1:N)

Relationship Name: do_payment
Entities Involved: Customers & Payments
Cardinality: One-to-Many (1:N)

Explanation:
• A Customer can make multiple Payments, but each Payment is linked to only one Customer.
• Example: A customer may make one payment for an order today and another payment next
week for a new order.

Participation:
o Customers (Partial Participation) → Some customers may not have made a payment yet.
o Payments (Total Participation) → Every payment must be associated with a customer.
We have explained how the ER diagram was created using all the UML diagrams and justified our all steps!
Contributions Below!
Contribution of Members of Group 10:

Nishit Prajapati – 24120036

For Module 2,

• Creation of Activity Diagram, Sequence Diagram, ER Diagram and related report work

For Module 1,

• Generation of INSERT queries

• Testing INSERT queries
• Creation of Entity Tables

Mitansh Patel – 24120033

For Module 2,

• Creation of Class Diagram, Deployment Diagram and related report work

For Module 1,

• Visual Representation of general idea

• Validating Constraints
• Generation of CREATE queries
• Creation of Relationship Tables

Chinteshwar Dhakate – 24120024

For Module 2,

• Creation of Use Case Diagram

For Module 1,

• No contribution

-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-Reports ends here-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-