Database - Management - System - Case - Studies Hospital3
Database - Management - System - Case - Studies Hospital3
The in‐between stoppage stations and their bookings are not considered.
Description of Tables and Procedures
Tables and procedures that will be created are as follows:
1. TrainList: This table consists of details about all the available trains. The information
stored in this table includes train number, train name, source, destination, fair for AC
ticket, fair for general ticket, and weekdays on which train is available.
Constraint: The train number is unique.
2. Train_Status: This table consists of details about the dates on which ticket can be
booked for a train and the status of the availability of tickets. The information stored in
this table includes train number, train date, total number of AC seats, total number of
general seats, number of AC seats booked, and number of general seats booked.
Constraint: Train number should exist in TrainList table.
3. Passenger: This table consists of details about the booked tickets. The information
stored in this table includes ticket ID, train number, date for which ticket is booked,
name, age, sex and address of the passenger, status of reservation (either confirmed or
waiting), and category for which ticket is booked.
Constraint: Ticket ID is unique and the train number should exist in TrainList table.
4. Booking: In this procedure, the train number, train date, and category is read from the
passenger. On the basis of the values provided by the passenger, corresponding record
is retrieved from the Train_Status table. If the desired category is AC, then total number
of AC seats and number of booked AC seats are compared in order to find whether
ticket can be booked or not. Similarly, it can be checked for the general category. If
ticket can be booked, then passenger details are read and stored in the Passenger table.
5. Cancel: In this procedure, ticket ID is read from the passenger and corresponding record is
searched in the Passenger table. If the record exists, it is deleted from the table. After
deleting the record (if it is confirmed), first record with waiting status for the same train and
same category are searched from the Passenger table and its status is changed to confirm.
E‐R diagram
Case Study 3
Painting Hire Business
System Description:
A local businesswoman has decided to start her own Internet business, called Masterpieces Ltd,
hiring paintings to private individuals and commercial companies.
Because of your reputation as a database designer she has called upon your services to design
and implement a database to support her new business. At the initial planning meeting, to
discuss the design, the following user requirements were requested.
The system must be able to manage the details of customers, paintings and those paintings
currently on hire to customers. Customers are categorized as B (bronze), S (silver), G (gold) or P
(platinum). These categories entitle a customer to a discount of 0%, 5%, 10% or 15%
respectively.
Customers often request paintings by a particular artist or theme (eg animal, landscape,
seascape, naval, still‐life, etc). Over time a customer may hire the same painting more than
once.
Each painting is allocated a customer monthly rental price defined by the owner. The owner of
the painting is then paid 10% of that customer rental price. Any paintings that are not hired
within six months are returned to the owner. However, after three months, an owner may
resubmit a returned painting.
Each painting can only have one artist associated with it.
Several reports are required from the system. Three main ones are:
1. For each customer, a report showing an overview of all the paintings they have hired or
are currently hiring
2. For each artist, a report of all paintings submitted for hire
3. For each artist, a returns report for those paintings not hired over the past six months