100% found this document useful (1 vote)
82 views3 pages

Database - Management - System - Case - Studies Hospital3

The document describes requirements for a database to support a painting hire business. The database needs to store information about customers, paintings, and current painting hires. Customers are categorized by discount level. Paintings can be searched by artist or theme. Paintings have a monthly rental price and owners receive 10% of rentals. Unhired paintings are returned after 6 months but owners can resubmit after 3 months. Required reports include a customer painting history, artist paintings, and returned paintings by artist.

Uploaded by

ceuprit
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
100% found this document useful (1 vote)
82 views3 pages

Database - Management - System - Case - Studies Hospital3

The document describes requirements for a database to support a painting hire business. The database needs to store information about customers, paintings, and current painting hires. Customers are categorized by discount level. Paintings can be searched by artist or theme. Paintings have a monthly rental price and owners receive 10% of rentals. Unhired paintings are returned after 6 months but owners can resubmit after 3 months. Required reports include a customer painting history, artist paintings, and returned paintings by artist.

Uploaded by

ceuprit
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

6.

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 

Remember to identify key attributes and any foreign key attributes.

You might also like