SWIFTTRIPS – TRAVEL MANAGEMENT SYSTEM

A PROJECT REPORT
Submitted by
SHAMBHAVI AKHOURI [RA2311029010014]

PARNIKA SHARMA [RA2311029010054]

Under the Guidance of

Dr. P. Visalakshi

Associate Professor, Department of Networking and Communications

in partial fulfillment of the requirements for the degree of

BACHELOR OF TECHNOLOGY
in
COMPUTER SCIENCE AND ENGINEERING
With Specialisation in Computer Networking

DEPARTMENT OF NETWORKING AND

COMMUNICATIONS
SRM COLLEGE OF ENGINEERING AND
TECHNOLOGY
SRM INSTITUTE OF SCIENCE AND TECHNOLOGY
KATTANKULATHUR– 603203
MAY 2025

1
 SRM INSTITUTE OF SCIENCE AND
TECHNOLOGY
KATTANKULATHUR–603203

BONAFIDE CERTIFICATE

Certified to be the Bonafide work done by Shambhavi Akhouri

(RA2311029010014) & Parnika Sharma (RA2311029010054) of II
year/IV sem B.Tech Degree Course in the Project Course 21CSC205P
Database Management Systems in SRM INSTITUTE OF SCIENCE
AND TECHNOLOGY, Kattankulathur for the academic year 2024-2025.

Faculty Incharge Head of the department

Dr. P. Visalakshi Dr. M. Lakshmi
Associate Professor Professor
Department of Networking and Department of Networking and
Communications Communications
SRMIST -KTR SRMIST -KTR

2
 ABSTRACT

In the era of smart technology and digital convenience, travel planning has evolved
from manual bookings to streamlined, tech-driven platforms that prioritize
personalization, integration, and efficiency. SwiftTrips is a comprehensive travel
management web application developed with a MySQL-backed architecture, aimed at
transforming the way users explore destinations, book accommodations, and manage
their travel itineraries. SwiftTrips provides an intuitive interface where users can
browse destinations, compare transport and hotel options, make secure bookings, and
leave feedback—all within a centralized system. The application ensures data reliability
and operational consistency through a well-structured Entity-Relationship (ER) model
and a fully normalized relational schema. Core features include user authentication,
destination-wise package customization, booking history, secure payment tracking, and
administrative control panels. The platform addresses key challenges in the existing
travel planning ecosystem such as fragmented service access, redundant user input, and
poor post-booking experience. SwiftTrips resolves these with a modular and relational
database-driven backend, ensuring seamless interaction across user roles and travel
entities. This report delves into the complete system architecture, database design, and
implementation strategies, showcasing how SwiftTrips redefines travel planning
through a smart, scalable, and user-centric solution.

3
 Chapter Chapter Name Page No
No

1. Introduction 5

Problem understanding, Identification of Entity and

Relationships, Construction of DB using ER Model
for the project

2. Design of Relational Schemas, Creation of Database 8

Tables for the project.

3. Complex queries based on the concepts of 13

constraints, sets, joins, views, Triggers and Cursors.

4. Analyzing the pitfalls, identifying the dependencies, 17

and applying normalizations

5. Implementation of concurrency control and recovery 23

mechanisms

6. Code for the project 27

7. Result and Discussion (Screenshots of the 32

implementation with front end.

8. NPTEL course registration page and ASSIGNMENT 34

PROOF

9. Chart Work - 1 36

10. Chart Work - 2 37

11. Conclusion 38

4
 1. INTRODUCTION

In today’s fast-paced, tech-enabled world, travel has become more frequent,

spontaneous, and diversified. However, organizing a trip—from researching
destinations to booking transport and accommodation—remains a fragmented and often
stressful experience. SwiftTrips is a centralized travel management web application
powered by a robust MySQL-based backend. Its goal is to simplify and streamline the
travel planning process for users while maintaining a secure and efficient database
system.

The platform features a clean and responsive User Interface where travelers can
explore various destinations, book transport and hotel accommodations, track past trips,
and leave feedback—all from a single portal. Meanwhile, the Admin Panel enables
platform managers to oversee bookings, manage listings, handle payments, and
moderate user interactions, ensuring operational control and platform reliability.

SwiftTrips integrates secure user authentication, normalized database storage, complex

relational queries, and real-time booking feedback loops to ensure a seamless and
scalable user experience. Designed for consistency, reliability, and future extensibility,
the system is modeled using an Entity-Relationship diagram and normalized relational
schema to reduce redundancy and optimize performance.

This report presents the complete development cycle of SwiftTrips—covering problem

analysis, ER design, relational schema, SQL query implementation, normalization
techniques, concurrency control, and backup mechanisms—offering a holistic look at
how SwiftTrips bridges the gap between travelers and travel service providers.

1.1 Problem Identification

Traditional travel planning platforms often suffer from:

 Fragmented systems for transport, hotel, and destination information.

 No unified portal to track all booking details in one place.
 Repetitive data entry for user profiles across different services.
 Lack of feedback integration for continuous service improvement.
 Poor post-booking support and no centralized trip history tracking.

SwiftTrips addresses these challenges by offering:

 A centralized portal for destination, hotel, and transport booking.

 Seamless user onboarding, trip management, and booking summary.
 Secure payment tracking and booking confirmation features.
 A feedback system for improving user satisfaction and service quality.
 Admin-side dashboards for maintaining data consistency and oversight.

The platform ensures smooth travel planning through a modular structure that connects
users, bookings, and destinations with minimal effort and maximum control.
5
1.2 Identification of Entities and Relationships

To accurately model the real-world operations of a travel booking system, SwiftTrips

uses eight core entities, each with specific attributes and relationships:

Entities and Attributes

1. Account
(account_id, username, email, password_hash)
Stores login credentials and access control details for each user.
2. Customer
(customer_id, account_id, name, contact_number)
Contains personal and contact information for customers; linked to their
account.
3. RideBooking
(ride_id, customer_id, pickup_location, drop_location, status)
Manages ride-sharing bookings such as cabs or private vehicles, including
route and booking status.
4. FlightBooking
(flight_id, customer_id, flight_number, departure_date, arrival_date, status)
Handles flight reservations for customers, tracking schedules and booking
status.
5. Payment
(payment_id, customer_id, ride_id, flight_id, amount, payment_date,
payment_mode)
Centralized payment processing entity supporting multi-mode transactions for
both rides and flights.
6. Itinerary
(itinerary_id, customer_id, trip_type, trip_id, details)
Records planned travel packages or custom trip details selected by the
customer.
7. Discount
(discount_id, code, discount_percentage, expiry_date)
Manages promotional offers applied during booking or payment processes.
8. Review
(review_id, customer_id, service_type, service_id, rating, comments,
review_date)
Captures customer feedback for different services (ride or flight), enhancing
service quality.

6
1.3 Relationships Between Entities

Relationship Type Description

Each login account corresponds to one

One Account → One Customer One-to-One
customer profile.

One Customer → Many

One-to-Many A customer can book multiple rides.
RideBookings

One Customer → Many A customer can make multiple flight

One-to-Many
FlightBookings reservations.

All payments are made by registered

One Customer → Many Payments One-to-Many
customers.

A ride booking is linked to one

One RideBooking → One Payment One-to-One
payment entry.

A flight booking is linked to one

One FlightBooking → One Payment One-to-One
payment entry.

Customers can save or create multiple

One Customer → Many Itineraries One-to-Many
trip plans.

A customer may submit multiple

One Customer → Many Reviews One-to-Many
service reviews.

7
1.4 ER Model

2. DESIGN OF RELATIONAL SCHEMAS

The design of the relational schema for SwiftTrips adheres to the principles of
normalization and data integrity, ensuring a robust and scalable travel management
system. Each core entity of the platform—such as users, trips, bookings, and
payments—is modeled using relational tables with appropriate attributes, keys, and
relationships.

Key Design Principles:

 Normalization: Tables are structured to eliminate redundancy and ensure logical

data grouping.

 Referential Integrity: Foreign keys are used to maintain relationships between

related entities and enforce data consistency.

 Scalability: The schema supports future expansion in terms of destinations,

transportation modes, and users.

 Modularity: Entities are cleanly separated to simplify querying and maintenance.

8
The schema includes several primary entities that form the backbone of the SwiftTrips
platform. These entities are linked through their relationships, allowing seamless
interactions between different components of the system.

2.1 Creation of Database Tables for the Project

Table 1: Account

The Account table stores login credentials and basic access-level information for all
users. It ensures that each user has a unique identity on the platform.

Column Name Data Type Description

account_id INT Primary Key

username VARCHAR(50) Unique Username

email VARCHAR(100) Unique Email

password_hash VARCHAR(255) Encrypted password

Table 2: Customer

This table stores detailed user profile information and links each customer to their
corresponding account.

Column Name Data Type Description

customer_id INT Primary Key

Foreign Key →
account_id INT
Account(account_id)

name VARCHAR(100) Full Name

9
 contact_number VARCHAR(20) Customer's contact number

Table 3: RideBooking

Stores details of cab/ride bookings made by users.

Column Name Data Type Description

ride_id INT Primary Key

Foreign Key →
customer_id INT
Customer(customer_id)

pickup_location VARCHAR(255) Pickup address

Table 4: FlightBooking

Contains all data related to flight reservations.

Column Name Data Type Description

flight_id INT Primary Key

Foreign Key →
customer_id INT
Customer(customer_id)

flight_number VARCHAR(20) Airline flight number

departure_date DATE Date of departure

10
Table 5: Payment

Records payment information for rides and flights. A payment may be associated with
either service.

Column Name Data Type Description

payment_id INT Primary Key

Foreign Key →
customer_id INT
Customer(customer_id)

Foreign Key →
ride_id INT (nullable)
RideBooking(ride_id)

Foreign Key →
flight_id INT (nullable)
FlightBooking(flight_id)

Table 6: Itinerary

This table stores trip details including both ride and flight types.

Column Name Data Type Description

itinerary_id INT Primary Key

Foreign Key →
customer_id INT
Customer(customer_id)

trip_type ENUM Type of trip (Ride or Flight)

trip_id INT Associated trip's ID

details TEXT Additional notes or info

11
Table 7: Discount

Stores available promotional discount codes.

Column Name Data Type Description

discount_id INT Primary Key

code VARCHAR(50) Unique Discount Code

discount_percentage DECIMAL(5,2) Discount in %

expiry_date DATE Expiry of the offer

Table 8: Review

Captures feedback from users on both rides and flights.

Column Name Data Type Description

review_id INT Primary Key

Foreign Key →
customer_id INT
Customer(customer_id)

service_type ENUM Either Ride or Flight

service_id INT Associated service ID

rating INT 1 to 5 rating

12
 3. COMPLEX QUERIES BASED ON THE CONCEPTS OF
CONSTRAINTS, SETS, JOINS, VIEWS, TRIGGERS AND
CURSORS

In this section, we explore advanced database operations that ensure the efficiency,
accuracy, and consistency of the SwiftTrips platform. These techniques include
constraints, set operations, joins, views, triggers, and cursors—each playing a critical
role in database management for a travel booking system.

3.1 Constraints

Constraints enforce rules at the table level and ensure data integrity throughout the
database.

Primary Key Constraint

Ensures each record in a table is uniquely identified. Example: account_id in the

Account table.

sql
CopyEdit
ALTER TABLE Account
ADD CONSTRAINT pk_account_id PRIMARY KEY (account_id);

Foreign Key Constraint

Ensures referential integrity between related tables. For example, customer_id in the
RideBooking table references the Customer table.

sql
CopyEdit
ALTER TABLE RideBooking
ADD CONSTRAINT fk_customer_id FOREIGN KEY (customer_id) REFERENCES
Customer(customer_id);

Check Constraint

Restricts values within a column. For example, limiting rating between 1 and 5 in the
Review table.

sql
CopyEdit
ALTER TABLE Review
ADD CONSTRAINT chk_rating CHECK (rating BETWEEN 1 AND 5);

13
3.2 Sets

Set operations allow the comparison and combination of data from multiple queries.

Union

Fetch all bookings made either for rides or flights.

sql
CopyEdit
SELECT customer_id, ride_id AS booking_id FROM RideBooking
UNION
SELECT customer_id, flight_id AS booking_id FROM FlightBooking;

Intersection

Get users who have both ride and flight bookings.

sql
CopyEdit
SELECT customer_id FROM RideBooking
INTERSECT
SELECT customer_id FROM FlightBooking;

Difference

Find users who have booked rides but never booked a flight.

sql
CopyEdit
SELECT customer_id FROM RideBooking
EXCEPT
SELECT customer_id FROM FlightBooking;

3.3 Joins

Joins combine rows from two or more tables based on a common column.

Inner Join

Retrieve the names of customers and their ride destinations.

sql
CopyEdit
SELECT c.name, r.drop_location
FROM Customer c
14
INNER JOIN RideBooking r ON c.customer_id = r.customer_id;

Left Join

Display all customers with ride booking details if available.

sql
CopyEdit
SELECT c.name, r.pickup_location, r.drop_location
FROM Customer c
LEFT JOIN RideBooking r ON c.customer_id = r.customer_id;

Right Join

List all rides, even if some don’t have corresponding customer details (rare but valid in
testing or legacy cases).

sql
CopyEdit
SELECT c.name, r.pickup_location
FROM Customer c
RIGHT JOIN RideBooking r ON c.customer_id = r.customer_id;

3.4 Views

Views simplify complex queries and improve security by showing only specific
columns.

Create View

Create a view for completed flight bookings with customer names.

sql
CopyEdit
CREATE VIEW CompletedFlightBookings AS
SELECT c.name, f.flight_number, f.departure_date
FROM Customer c
JOIN FlightBooking f ON c.customer_id = f.customer_id
WHERE f.status = 'Completed';

Query the View

sql
CopyEdit
SELECT * FROM CompletedFlightBookings;

15
3.5 Triggers

Triggers automate actions in response to specific changes in a table.

Trigger Example

Automatically insert a review when a flight booking is marked as 'Completed'.

sql
CopyEdit
CREATE TRIGGER AutoInsertReview
AFTER UPDATE ON FlightBooking
FOR EACH ROW
BEGIN
IF NEW.status = 'Completed' THEN
INSERT INTO Review (customer_id, service_type, service_id, rating, comments)
VALUES (NEW.customer_id, 'Flight', NEW.flight_id, 5, 'Auto-generated review
for completed flight.');
END IF;
END;

3.6 Cursors

Cursors process each row returned by a query individually—useful for batch updates
or audits.

Cursor Example

Iterate through all in-progress ride bookings and mark them as 'Completed'.

sql
CopyEdit
DECLARE @ride_id INT;
DECLARE ride_cursor CURSOR FOR
SELECT ride_id FROM RideBooking WHERE status = 'Pending';

OPEN ride_cursor;
FETCH NEXT FROM ride_cursor INTO @ride_id;

WHILE @@FETCH_STATUS = 0
BEGIN
UPDATE RideBooking
SET status = 'Completed'
WHERE ride_id = @ride_id;

FETCH NEXT FROM ride_cursor INTO @ride_id;

END;

CLOSE ride_cursor;
16
DEALLOCATE ride_cursor;

4. ANALYZING THE PITFALLS, IDENTIFYING THE

DEPENDENCIES, AND APPLYING NORMALIZATIONS

Table Functional Dependency (FD) Closure

{account_id}+ = {account_id,
account_id → username, email,
Account username, email,
password_hash
password_hash}

{customer_id}+ =
customer_id → account_id, name,
Customer {customer_id, account_id,
contact_number
name, contact_number}

{ride_id}+ = {ride_id,
ride_id → customer_id,
RideBooking customer_id, pickup_location,
pickup_location, drop_location, status
drop_location, status}

{flight_id}+ = {flight_id,
flight_id → customer_id,
customer_id, flight_number,
FlightBooking flight_number, departure_date,
departure_date, arrival_date,
arrival_date, status
status}

{payment_id}+ =
payment_id → customer_id, ride_id, {payment_id, customer_id,
Payment flight_id, amount, payment_date, ride_id, flight_id, amount,
payment_mode payment_date,
payment_mode}

{itinerary_id}+ = {itinerary_id,
itinerary_id → customer_id,
Itinerary customer_id, trip_type, trip_id,
trip_type, trip_id, details
details}

{discount_id}+ = {discount_id,
discount_id → code,
Discount code, discount_percentage,
discount_percentage, expiry_date
expiry_date}

{review_id}+ = {review_id,
review_id → customer_id,
customer_id, service_type,
Review service_type, service_id, rating,
service_id, rating, comments,
comments, review_date
review_date}

17
4.2 PITFALLS :

Table Pitfalls
- Repeated usernames or emails without strong
constraints can cause duplicates. - Passwords
Account must be stored using secure hashing algorithms,
not plaintext. - No role-based access system
included (e.g., Admin, User).
- Redundant data if multiple customers share
similar contact numbers. - Tightly coupled with
Customer
Account, changes to Account can cause
anomalies if not cascaded.
- No driver or vehicle table limits extensibility
for transport tracking. - ENUM values are fixed;
RideBooking
future expansion (e.g., "Ongoing") requires
schema change.
- Repeating flight numbers for different dates
might not be properly handled without
FlightBooking composite uniqueness. - Date constraints are not
enforced (arrival_date should be after
departure_date).
- Either ride_id or flight_id is NULL depending
on context, leading to sparse records. -
Redundant amount storage if recalculated from
Payment
booking tables. - ENUM values like ‘UPI’,
‘Credit Card’ should be normalized into a
separate table.
- trip_id refers to either a RideBooking or
FlightBooking — no foreign key enforcement
Itinerary possible due to polymorphic relationship. -
Details stored in TEXT format reduce querying
flexibility.
- No linkage to specific users or bookings;
Discount cannot track usage history. - Expiry check not
enforced by DB logic.
- No check to restrict one review per customer
per service. - Rating should be bounded (1 to 5),
Review but changes in customer info can affect
traceability. - Polymorphic service_id makes
strict integrity enforcement difficult.

18
4.3 Normalisation :

1NF (First Normal Form)

Rule: Atomic values, no repeating groups. All the tables you provided already satisfy
Example (Not in 1NF):

Decomposed Table (1NF):

2NF (Second Normal Form)

Rule: Be in 1NF and no partial dependency.

Example (Not in 2NF):

Decomposed Tables (2NF):

19
3NF (Third Normal Form)

Rule: A table must be in 2NF and have no transitive dependency (non-key attributes
should not depend on other non-key attributes).

Example: Not in 3NF

3NF Solution (Decomposed)

BCNF (Boyce-Codd Normal Form)

Rule: A stricter version of 3NF where every determinant must be a candidate key.

Example : Not in BCNF

20
BCNF Solution (Decomposed)

4NF (Fourth Normal Form)

Rule: A table must be in BCNF and have no multi-valued dependencies.

Example : Not in 4NF

4NF Solution (Decomposed)

21
5NF (Fifth Normal Form)

Rule: A table must be in 4NF and all join dependencies must be implied by candidate
keys.

Example : Not in 5NF

5NF Solution (Decomposed)

22
 5. IMPLEMENTATION OF CONCURRENCY CONTROL AND
RECOVERY MECHANISMS

5.1 Transaction Management

Definition:

Transaction management ensures that a sequence of operations (such as adding a

course, enrolling a student, and updating inventory) is treated as a single unit. The
transaction guarantees that either all actions within the sequence succeed, or none of
them do, maintaining the integrity of the database. If any part of the transaction fails,
the entire transaction is rolled back, ensuring no partial data updates.

Goal:

The primary goal of transaction management is to maintain data consistency and

integrity. This ensures that the database remains in a valid state and doesn't end up
with incomplete or inconsistent data, even in the event of a failure.

What Is Done Usually:

● Begin Transaction: A transaction starts with START TRANSACTION or
an equivalent.

● Commit or Rollback:

● If all operations are successful, COMMIT is issued to make changes permanent.

● If an error occurs, ROLLBACK undoes all changes, ensuring consistency.

● In systems like SwiftTrips, it is common to ensure that course enrollment and

payment operations happen atomically, meaning either the course is enrolled
and payment processed, or neither happens.

How It Is Done in SwiftTrips:

 While booking a flight, generating itinerary, and recording payment, all operations
should occur within a single transaction.
 If payment fails, all previous actions (like booking) are rolled back, ensuring data
integrity.

23
5.2 Concurrency Control

Definition:

Concurrency control manages simultaneous access to the database by multiple users

or systems. It ensures that transactions executed at the same time do not interfere with
each other, preventing conflicts and ensuring the database stays in a consistent state.

Goal:

The goal of concurrency control is to maintain data consistency and prevent race
conditions, where multiple transactions simultaneously alter the same data. It is
critical in systems where multiple users might attempt to access or modify the same
data at the same time.

What Is Done Usually:

Locking: Locks are applied to specific rows or tables to prevent multiple transactions
from accessing the same data simultaneously.

Isolation Levels: Different isolation levels (e.g., READ COMMITTED,

REPEATABLE READ, SERIALIZABLE) define how visible the changes of one
transaction are to others, ensuring proper isolation of transaction operations.

How It Is Done in SwiftTrips:

 Use row-level locks (e.g., SELECT ... FOR UPDATE) when accessing ride or flight
availability.

 Apply isolation levels (SERIALIZABLE) to ensure transactions are processed one at a

time logically.

 Prevents multiple bookings of the same ride or flight slot.

24
5.3 Recovery Mechanism

Definition:

A recovery mechanism ensures that the system can return to a consistent state after a
failure (e.g., system crash, network failure, or transaction failure). Recovery typically
involves undoing incomplete transactions and redoing committed transactions,
ensuring data durability and consistency.

Goal:

The recovery mechanism's goal is to ensure that the database remains consistent even
after a failure. It helps recover from system crashes or disruptions while guaranteeing
no data is lost and the system returns to a valid state.

What Is Done Usually:

●  Logging: A transaction log records all changes made to the database. This
log is essential to undo or redo changes after a failure.
●  Checkpoints: Periodic checkpoints are created so that recovery can start from
the last successful point, minimizing recovery time.
●  Rollback and Redo: Unfinished transactions are rolled back, and committed
transactions are redone from the logs.

25
How It Is Done in SwiftTrips:

 Use database logs to track each transaction step.

 If a crash occurs (e.g., power failure or system crash), the database:

 Rolls back incomplete bookings,

 Reapplies committed updates if not written to disk,
 Maintains system consistency.

Comprehensive Overview in SwiftTrips:

● Transaction Management: Ensures that operations such as booking a ride or

flight, updating the itinerary, and processing payment are performed atomically.
If any part of the process fails (e.g., payment failure or itinerary mismatch), the
entire transaction is rolled back to maintain data consistency. This guarantees
that users are not charged without a confirmed booking or left with incomplete
trip records.

● Concurrency Control: Locks are applied when accessing critical resources

like rides or flights to prevent multiple users from booking the same seat or ride
simultaneously. Using SELECT ... FOR UPDATE, the system ensures that only
one transaction can modify a particular booking at a time. This prevents race
conditions and ensures that users always see accurate availability and pricing
information.

● Recovery Mechanism: Each failed or incomplete transaction is logged with

error details (e.g., “Ride already booked” or “Payment timeout”). These logs
enable system administrators to review, analyze, and retry failed operations. In
the event of a system crash, SwiftTrips uses recovery tables, rollback, and redo
mechanisms to restore the system to a consistent state, preserving the integrity
of both bookings and payments.

26
By implementing these mechanisms, SwiftTrips ensures High data integrity during
multi-step operations, Robust Concurrency handling during high-traffic scenarios,
and Effective fault recovery to maintain service reliability even in failure conditions.

6. Code for the project

SQL Connection

import mysql.connector

def get_connection():

return mysql.connector.connect(

host="localhost",

user="root",

password="Lovesid@005",

database="db_name"

)
Main.py

import tkinter as tk
from PIL import Image, ImageTk
import accounts_ui
import flight_bookings_ui
import ride_bookings_ui
import hotel_bookings_ui
import review_ui
import payment_ui
import discount_coupons_ui
import itinerary_ui
27
def open_dashboard():
root = tk.Tk()
root.title("Swift Trips - Dashboard")
root.geometry("1280x800")
root.resizable(False, False)

# Background Image
bg_image =
Image.open("/Users/parnikasharma/Desktop/dbm/Image.jpg")
bg_image = bg_image.resize((1280, 800))
bg_photo = ImageTk.PhotoImage(bg_image)
bg_label = tk.Label(root, image=bg_photo)
bg_label.place(x=0, y=0, relwidth=1, relheight=1)

# Dashboard Title
title = tk.Label(
root,
text="Swift Trips Dashboard",
font=("Helvetica", 50, "bold"),
fg="#FFFFFF",
padx=20,
pady=10

28
 )
title.place(relx=0.5, rely=0.05, anchor="n")

# Button Frame (with slight padding and shadow mimic)

btn_frame = tk.Frame(root, bg="#F9E7E7", bd=4,
relief="sunken")
btn_frame.place(relx=0.5, rely=0.52, anchor="center")

# Button styling
BUTTON_BG = "#255957" # Teal
BUTTON_BORDER = "#1A3C40"

def create_button(text, command=None):

return tk.Button(
btn_frame,
text=text,
font=("Helvetica", 12, "bold"),
width=20,
height=2,
bg=BUTTON_BG,
activebackground=BUTTON_BG,
bd=2,
relief="raised",

29
 highlightbackground=BUTTON_BORDER,
highlightthickness=1,
state="normal", # ensures they look active
command=command if command else lambda:
print(f"{text} clicked")
)

# Define buttons and their handlers

buttons = [
("Manage Accounts", accounts_ui.open_window),
("Flight Bookings", flight_bookings_ui.open_window),
("Hotel Bookings",
hotel_bookings_ui.open_hotel_booking_window),
("Itinerary", itinerary_ui.open_itinerary_window),
("Ride Bookings",
ride_bookings_ui.open_ride_booking_window),
("Payments", payment_ui.open_payment_window),
("Reviews", review_ui.open_review_window),
("Discount Coupons",
discount_coupons_ui.open_discount_coupon_window),
]

# Layout buttons in 2 rows

for i, (text, cmd) in enumerate(buttons):

30
 btn = create_button(text, cmd)
btn.grid(row=i//4, column=i%4, padx=20, pady=15)

# Exit Button
exit_btn = tk.Button(
root,
text="Exit",
font=("Helvetica", 12, "bold"),
width=18,
height=2,
bg="#3F292B", # Dark brown
activebackground="#3F292B",
command=root.quit
)
exit_btn.place(relx=0.5, rely=0.92, anchor="center")

root.mainloop()

if _name_ == "_main_":
open_dashboard()

31
7. Results

32
 \

33
8. NPTEL course registration page & ASSIGNMENT PROOF

34
35
9. CHART 1 : [ER MODEL & RELATIONAL MODEL]

36
CHART 2 : [FD & NORMALISATION]

37
 CONCLUSION

The SwiftTrips – Travel Management System has been developed with the objective of
creating a comprehensive and efficient platform that caters to the growing demands of
modern travel services. With features ranging from ride and flight bookings to payment
processing, itinerary management, discount handling, and customer reviews, the system
integrates various travel functionalities into a single database-driven solution.

Throughout the course of this project, we followed a structured approach to database

design and implementation, grounded in the principles of relational database
management systems. Tables were normalized to avoid redundancy and ensure
consistency, with appropriate constraints such as primary keys, foreign keys, and check
conditions maintaining the integrity of the data. Each entity and its relationships were
carefully mapped to reflect real-world scenarios, enabling the system to handle complex
queries and support a wide range of operations.

By applying advanced SQL techniques such as joins, set operations, triggers, views,
and cursors, we demonstrated the ability to go beyond basic CRUD operations and
implement logic that automates key processes—for example, automatically updating
booking statuses or generating virtual views for efficient data retrieval. We also
identified and analyzed common pitfalls in database design, such as update anomalies,
redundant data, and dependency conflicts, and addressed them using normalization up
to the third normal form (3NF).

The system's modular design ensures scalability and flexibility for future
enhancements, such as integrating third-party APIs, adding user authentication layers,
or including multi-modal travel packages. Moreover, the inclusion of real-time payment
tracking, itinerary summaries, and review functionalities adds value from both
customer experience and administrative perspectives.

In conclusion, SwiftTrips not only fulfills its primary function as a travel management
system but also serves as a well-structured case study in database design and
application. This project has allowed us to bridge theoretical knowledge with practical
implementation, demonstrating the importance of well-designed databases in powering
real-world software solutions.

38