0% found this document useful (0 votes)
76 views3 pages

Week 3 Assignment 4 - Vacation Rentals

The document outlines a database design for a vacation rental organization, detailing an EER diagram that includes properties, renters, and rental agreements. It provides a relational schema, functional dependencies, and ensures that all relations are in third normal form. Additionally, it suggests an integrity constraint to prevent double bookings of properties during overlapping rental periods.

Uploaded by

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

Week 3 Assignment 4 - Vacation Rentals

The document outlines a database design for a vacation rental organization, detailing an EER diagram that includes properties, renters, and rental agreements. It provides a relational schema, functional dependencies, and ensures that all relations are in third normal form. Additionally, it suggests an integrity constraint to prevent double bookings of properties during overlapping rental periods.

Uploaded by

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

Gerard Ryan - Week 3 Assignment 4 - Vacation Rentals

Use your textbook and a database design tool to complete the following
questions. Figure 4-35 shows an EER diagram for Vacation Property Rentals.
This organization rents preferred properties in several states. As shown in the
figure, there are two basic types of properties: beach properties and
mountain properties.

a. Transform the EER diagram to a set of relations and develop a


relational schema.

a. PROPERTY T (Supertype)
a. PropertyID (Primary Key)
b. StreetAddress
c. City
d. State
e. Zip
f. NbrRooms
g. BaseRate
h. PropertyType
b. BEACH PROPERTY T (Subtype)
a. PropertyID
b. BlocksToBeach
c. MOUNTAIN PROPERTY T (Subtype)
a. PropertyID
b. Activity
d. RENTER T
a. RenterID (Primary Key)
b. FirstName
c. MiddleInitial
d. LastName
e. Address
f. Phone
g. Email
e. RENTAL AGREEMENT T
a. AgreementID (Primary Key)
b. BeginDate
c. EndDate
d. RentalAmount
e. RenterID
f. PropertyID
Relational Schema:
PROPERTY T (PropertyID, StreetAddress, City, State, Zip, NbrRooms,
BaseRate, PropertyType)
BEACH PROPERTY T (PropertyID, BlocksToBeach)
FOREIGN KEY (PropertyID) REFERENCES PROPERTY T(PropertyID)
MOUNTAIN PROPERTY T (PropertyID)
FOREIGN KEY (PropertyID) REFERENCES PROPERTY T(PropertyID)
MOUNTAIN PROPERTY ACTIVITY T (PropertyID, Activity)
FOREIGN KEY (PropertyID) REFERENCES MOUNTAIN PROPERTY T(PropertyID)
RENTER T (RenterID, FirstName, MiddleInitial, LastName, Address, Phone,
Email)
RENTAL AGREEMENT T (AgreementID, BeginDate, EndDate, RentalAmount,
RenterID, PropertyID)
FOREIGN KEY (RenterID) REFERENCES RENTER T(RenterID)
FOREIGN KEY (PropertyID) REFERENCES PROPERTY T(PropertyID)

b. Diagram the functional dependencies and determine the normal form


for each relation.

a. PROPERTY T

a. PropertyID → StreetAddress, City, State, Zip, NbrRooms, BaseRate,


PropertyType
b. Primary Key (PropertyID) determines all other attributes.

b. BEACH PROPERTY T

a. PropertyID > BlocksToBeach

b. Primary Key (PropertyID)

c. MOUNTAIN PROPERTY T:
a. PropertyID is the sole attribute and primary key.
d. MOUNTAIN PROPERTY ACTIVITY T
a. PropertyID, Activity
e. RENTER T
a. RenterID > FirstName, MiddleInitial, LastName, Address, Phone, Email
b. Primary Key (RenterID)
f. RENTAL AGREEMENT T
a. AgreementID > BeginDate, EndDate, RentalAmount, RenterID,
PropertyID
b. RenterID > FirstName, MiddleInitial, LastName (from RENTER T via
foreign key)
c. PropertyID > StreetAddress, City, State, Zip, NbrRooms, BaseRate,
PropertyType (from PROPERTY T via foreign key)
d. Primary Key (AgreementID)

c. Convert all relations to third normal form, if necessary, and draw a


revised relational schema.
PROPERTY T (PropertyID, StreetAddress, City, State, Zip, NbrRooms,
BaseRate, PropertyType)
BEACH PROPERTY T (PropertyID, BlocksToBeach)
FOREIGN KEY (PropertyID) REFERENCES PROPERTY T(PropertyID)
MOUNTAIN PROPERTY T (PropertyID)
FOREIGN KEY (PropertyID) REFERENCES PROPERTY T(PropertyID)
MOUNTAIN PROPERTY ACTIVITY T (PropertyID, Activity)
FOREIGN KEY (PropertyID) REFERENCES MOUNTAIN PROPERTY T(PropertyID)
RENTER T (RenterID, FirstName, MiddleInitial, LastName, Address, Phone,
Email)
RENTAL AGREEMENT T (AgreementID, BeginDate, EndDate, RentalAmount,
RenterID, PropertyID)
FOREIGN KEY (RenterID) REFERENCES RENTER T(RenterID)
FOREIGN KEY (PropertyID) REFERENCES PROPERTY T(PropertyID)

d. Suggest an integrity constraint that would ensure that no property is


rented twice during the same time interval.

a. An integrity constraint that would ensure that no property is


rented twice during the same time interval is to have a rule that
disallows overlapping rental periods when we add a new rental
agreement. The routine would query the renal agreement table
for existing agreements on the same PropertyID that have an
extended period with the new agreement.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy