Technical Design Document

B9IS100_2324_TMD3
CA1
Part A Documentation and Design

GROUP MEMBERS

ASKANI GAUTHAM - 20025842

VISHWANATHA REDDY REDDY – 20036059

SRAVANI AGATAMUDI - 20030994

Contents
...............................................................................................................................................................0
1. Business Case.................................................................................................................................2
a. Scope........................................................................................................................................2
b. Requirements Identified...........................................................................................................3
2. Business Rules...............................................................................................................................4
3. ERD and Schema............................................................................................................................6
Relationship...........................................................................................................................................6
4. Individual Contribution..................................................................................................................7
References.............................................................................................................................................9

1
1. Business Case
For this project, our team has chosen Scenario 3: Travel Agent

a. Scope
 Customers: Maintaining the detailed information about the customers including
their contact details like name, email which should be unique as it should not
registered with our business already, phone number, age, nationality, marital status,
date of birth as well as food allergies which contains detailed information about all
foods and allergies customer is currently facing, also stores the detailed information
about their health condition as a past history and present history.

 Bookings: In this entity, we are managing whole customer bookings for various
elements such as their flights, hotels, trips, visa, travel insurance, specials requests as
well as transportation mode and their whole trip journey from start till end.

 Destinations: We are managing current and past travel destinations with their
associated details such as which country they have travelled, which language they
prefer and includes destination name and last updated date and our status attribute
will inform about the destinations whether it was previous or currently active.

 Day or Multi Day Trips: We are recording and managing sub destinations or trips that
can be booked as part of a travel package as also it includes name, description of
trips, type, duration of trip, as well as max trip per booking which is very essential
part of the business core.

 Airlines: Managing data around active airlines which includes customer preferences,
airlines specific rules such as luggage rules, seat booking rules, boarding rules with
active status columns which tell if specific airline is activated or not.

 Hotels: Managing hotel data around available hotels, including customer preferences
with their special requests, room preferences etc.

 Special Requests: Recording special customer requests and accommodations, such as

dietary restrictions based on food allergies, health conditions and disability needs.

 Packages: Managing all standard and customized holiday packages with validity date
check.

 Travel Insurance: Recording and managing travel insurance details and maintaining
the integrations with insurance suppliers and all policy details.

 Transportation Modes: Tracking different transportation options like cars, trains,

rental cars etc with proper supplier details and pricing details.

2
 Visa Requirements: Maintaining data on visa requirements and, also automates the
renewal process which is the business requirement with its cost and processing time
details.

 Payments: Recoding all payment details, handling multiple payment types, and
managing payment schedules.

 Customer Feedback and complaints: Collecting and storing all customer feedback,
suggestions, ratings, and complaints for their post travel.

b. Requirements Identified

The following are the requirements identified for this project:

o Client Management:
 Maintaining comprehensive customer details which includes contact
information is with their nationality, health conditions and
preferences.
 We need to ensure customer provide a unique email and contact
phone number.
 Customer must be more than 18+ to register with the travel agent.

o Booking Management:
 Recoding and managing all elements of customer bookings ensuring
each booking has unique ID.
 Booking can be updated automatically based on any changes made
and if exceptions present.

o Health Conditions Constraints:

 Recoding health conditions and allergies which can directly impact on
the travel options present to customer.
 Generate daily lists of customers with specific health conditions and
allergies.

o Special Requests and Accommodations:

 Recoding and managing special client requests and accommodations
for each customer.
 Linking these requests to bookings and need to ensure that they are
communicated to third parties involved with travel agents.

o Travel Packages:
 Managing standard holiday packages and custom packages for
customer based on their criteria.

3
  Tracking of the availability, and valid dates of these packages.

o Payment and Financial Tracking:

 Recording and maintaining all payment details including type, amount,
and schedule of their payments.
 Automates the system to reduce the balance owned per booking as
whenever the payment received.

o Client Feedback and Complaints:

 Collecting and storing feedbacks and complaints from clients after
each booking and post travels so to improve the whole system.
 Enabling the detailed tracking of feedback types like star ratings,
written feedback, and suggestions.

2. Business Rules

 Business Rule 1: This implies that there exists minimum age requirement for booking
since they included age limits for simplifying searching.

a) Rule: This should be done with an understanding that customer must be over the
age 18 years to get a booking. To be certain with this, we will to subtract from the
customer’s date of birth (DOB) to the current date and ensure it is greater than
18. This will be done by creating a new checksum constraint with the name of
minimum_age_checker on the customer table.

 Business Rule 2: This validation has to do with the day and time that the booking was
made.

a) Rule: According to the previously established recommendations all the bookings

should be made at least 48 hours prior the actual departure to make the
necessary corrections, if needed. To implement this constraint, we will generate a
trigger that checks if the booking date exceeds 48 hours before departure; if not,
there will be an error message stating that bookings must be done three days
before the intended date of the trip.

4
 Business Rule 3: Number of Trips Allowed by Years for Both Long- and Short-Term
Bookings

a) Rule: As one of the rules of house sharing, the number of trips is as limited as the
number of actual days of the booking period. When it comes to bookings in
between 10 and 14 days, then an individual can book a maximum of two journeys
only. For bookings that will be done 15-28 days prior dates, the systems will allow
for a maximum of three trips to be booked. For the continuous bookings that
exceed 28 days, there is no limitation when it comes to the number of trips in the
same booking. This will be enforced by creating a new column in the table for
booking which is ‘duration’ and imposing a check constraint on the same.

 Business Rule 4: Commencement of Automatic Visa Renewal Process

a) Rule: An effective system should be one that shows alerts and prompts the visa
renewal procedure say, a month before the validity of the visa. A trigger will be
created for follow up for visa expiry dates for the concerned visas and the status
shall be updated. In the case where the model has a renewal date in the future
and the model renewal status is not complete, then the model status is set to
‘Pending renewal’, in order to begin the renewal process.

5
3. ERD and Schema

Relationship
 Customer and Booking:

a. Customer can have zero or multiple (o<) bookings but each booking is linked to one
customer so this relationship is called one to many where customer side we have
one or many and booking side we have exactly one. ( || )

 Trip and Destination:

a. Destination can have zero or multiple (o<) trips which can be day or many days but
each trip linked to one destination ( || ) so the relationship is called one to many
where destination has one or many side and trip has only one side.

 Booking and Airline:

a. Airline can have zero or multiple bookings (o<) but each airline linked to single
booking so the relationship is called many to one where airline has many sides and
booking has only one side (exactly one) (||)

 Booking and Hotel:

a. Each booking can be associated with specific hotel but hotel can be linked to zero or
many (o<) bookings meaning relationship would be many to one where booking side
has many and hotel side contains exactly one. ( || )

 Booking and Special Request:

a. Each booking can have zero or multiple (o<) special requests but each request is
linked to a single booking meaning relationship is called one to many where booking
side has one or many and special request side has exactly one. ( || )

6
 Booking and Package:
a. Each booking can include a specific package but each package is linked to one or
many bookings (|<) meaning relationship is called many to one where booking side
has many and package side has exactly one. ( || )

 Booking and Travel Insurance:

a. Each booking can include a travel insurance policy but travel insurance policy can be
linked with zero or many (o<) bookings so the relationship is called many to one
where booking side has many sides and travel insurance has exactly one. ( || )

 Booking and Transportation Mode:

a. Each booking can include a specific transportation mode like car, bus, airplane, train
etc. but a transportation mode can be linked to one or many bookings (|<) so, the
relationship is called many to one where booking side has many and transportation
mode has exactly one. ( || )

 Booking and Visa:

a. Each booking can have multiple (|<) visas linked but each visa can be linked to a
single booking ( || ) so relationship called one to many where booking side has one
or many and visa side has only one.

 Booking and Payment:

a. Each booking can have one or multiple (|<) payments but each payment can be
linked with single booking so the relationship is called one to many where booking
has one or many and payment side has only one like exactly one. ( || )

 Booking and Feedback:

a. Each booking can have zero or multiple (o<) feedbacks but each feedback can be
linked with single booking so the relationship is called one to many where booking
has one or many and feedback side has only one like exactly one. ( || )

4. Individual Contribution
Askani Gautham: 20025842

I took on the responsibility of designing the Entity-Relationship Diagram (ERD) using

draw.io. My first task was to identify the essential entities required for the business
implementation and understand how the flow works within the travel agent system. To do
this, I made a rough draft to get a brief idea of the scenario, working closely with my
teammates for initial feedback and ideas.

I decided to focus on the Client, Booking, Trip, and Destination entities, which are crucial
for the business implementation. These entities are fundamental as they directly interact
with each other and form the core of our travel booking system. Additionally, I designed the
Feedback entity to ensure we capture customer feedback effectively.

7
After identifying the key entities, I analyzed the scenario details to determine the necessary
attributes for each entity. For example, the Client entity includes attributes like name,
email, phone number, age, nationality, marital status, date of birth, food allergies, and
health conditions. The Booking entity captures details about flights, hotels, trips, visas,
insurance, transportation, and special requests.

Once the attributes were defined, I started creating the ERD, making sure to illustrate all
relationships between entities clearly. I used crow's foot notation to represent the
relationships and worked with my teammates to ensure accuracy. I stylized the ERD using
appropriate colors and fonts to make it visually appealing and easy to understand.

I also took care of the modifications based on team feedback, ensuring that the diagram
was comprehensive and reflected all necessary business rules. For instance, I included a
one-to-many relationship between Clients and Bookings, indicating that a client can have
multiple bookings, but each booking is linked to one client.

Overall, my contribution ensured that the ERD provided a clear and structured
representation of the database schema, serving as a solid foundation for the system's
implementation.

Vishwanatha Reddy Reddy : 20036059

I was responsible for designing the Hotel, Payment, Package, and Special Request entities. I
carefully discussed these entities with my teammates to ensure that they support the main
Booking entity effectively.

For the Hotel entity, I defined attributes such as hotel name, location, room preferences,
and special requests from customers. I also established the relationship between Booking
and Hotel, where each booking can be associated with a specific hotel, but a hotel can be
linked to zero or many bookings. This relationship is many-to-one, with many bookings
associated with one hotel.

The Payment entity included attributes like payment ID, type, amount, date, and booking ID
to link each payment to a specific booking. I ensured that the system could handle multiple
payment types and schedules, automating the balance updates per booking.

For the Package entity, I defined attributes to manage standard and custom holiday
packages, including package name, description, validity dates, and associated booking IDs.
This helps in tracking the availability and customization of holiday packages based on
customer preferences.

The Special Request entity captured unique customer requirements, such as dietary
restrictions and disability needs. Each special request is linked to a booking, ensuring that
all customer needs are communicated to relevant parties.

Additionally, I worked on normalizing the database to the Third Normal Form (3NF). This
involved analyzing the relationships between entities and ensuring that each attribute
depended only on the primary key, reducing redundancy and improving data integrity.

My contributions ensured that the database schema was well-structured and normalized,
supporting efficient data management and retrieval.

8
 Sravani Agatamudi : 20030994

I was responsible for designing the Airline, Travel Insurance, Visa, and Transportation Mode
entities. I began by reading the scenario document thoroughly to understand the
requirements and ensure that these entities captured all necessary details for the travel
booking system.

For the Airline entity, I included attributes such as airline name, luggage rules, seat booking
rules, boarding rules, and active status. This entity helps manage customer preferences and
specific airline policies, ensuring smooth flight bookings.

The Travel Insurance entity captured details about insurance policies, including policy
number, provider, coverage details, and validity dates. This is crucial for managing travel
insurance integrations and ensuring that customers are adequately covered.

For the Visa entity, I defined attributes like visa type, country, cost, processing time, and
expiry date. This entity automates the visa renewal process, ensuring that customers
receive timely alerts for visa renewals.

The Transportation Mode entity included attributes for different transportation options,
such as mode type (car, train, rental car), supplier details, and pricing. This helps in
managing various transportation options available to customers during their travel.

I also took on the task of documentation, ensuring that our project document was
comprehensive, well-organized, and adhered to the required standards. I included detailed
descriptions of each entity, their attributes, and relationships, making the document easy
to follow and understand.

Furthermore, I worked on the crow's foot notation for the ERD diagram, ensuring that all
relationships between entities were clearly represented. This visual representation helped
in understanding the database structure and its implementation.

Through my contributions, I ensured that our system was well-documented, and the
additional entities were thoroughly defined, supporting a comprehensive and user-friendly
travel booking system.

References
Curry, C. (2019) Database design all-in-one tutorial series (8 hours!), YouTube. Available at:
https://www.youtube.com/watch?
v=h0j0QN2b57M&list=PL_c9BZzLwBRK0Pc28IdvPQizD2mJlgoID (Accessed: 07 June 2024).

Schools, W. (no date) Entity Relationship Model, Entity relationship(er) model. Available at:
https://www.w3schools.in/dbms/er-model?utm_content=cmp-true (Accessed: 04 June
2024).