Using these data, state assumptions about functional dependencies among the colu
ID: 3885466 • Letter: U
Question
Using these data, state assumptions about functional dependencies among the columns of data.
Given your assumptions in part A, comment on the appropriateness of the following designs:
PROPERTY (PropertyName, PropertyType, Street, City, Zip, ServiceDate, Description, Amount)
PROPERTY (PropertyName, PropertyType, Street, City, Zip, ServiceDate, Description, Amount)
PROPERTY (PropertyName, PropertyType, Street, City, Zip, ServiceDate, Description, Amount)
PROPERTY (PropertyID, PropertyName, PropertyType, Street, City, Zip, ServiceDate, Description, Amount)
PROPERTY (PropertyID, PropertyName, PropertyType, Street, City, Zip, ServiceDate, Description, Amount)
PROPERTY (PropertyID, PropertyName, PropertyType, Street, City, Zip, ServiceDate )
and:
SERVICE (ServiceDate, Description, Amount)
PROPERTY (PropertyID, PropertyName, PropertyType, Street, City, Zip, ServiceDate)
and:
SERVICE (ServiceID, ServiceDate , Description, Amount)
PROPERTY (PropertyID, PropertyName, PropertyType, Street, City, Zip, ServiceDate )
and:
SERVICE (ServiceID, ServiceDate, Description, Amount, PropertyID )
PROPERTY (PropertyID, PropertyName, PropertyType, Street, City, Zip)
and:
SERVICE (ServiceID, ServiceDate, Description, Amount, PropertyID )
Explanation / Answer
1.
PROPERTY (PropertyName, PropertyType, Street, City, Zip, ServiceDate, Description, Amount)
zip --> city
pin and city can be in different table (applicable for all table)
2.
PROPERTY (PropertyID, PropertyName, PropertyType, Street, City, Zip, ServiceDate, Description, Amount)
propertyID --> PropertyName, PropertyType, Street, Zip
zip --> city
propertyID, ServiceDate --> Description, Amount
Introduction of PropertyID makes more sense (primary key)
3.
PROPERTY (PropertyID, PropertyName, PropertyType, Street, City, Zip, ServiceDate )
and:
SERVICE (ServiceDate, Description, Amount)
propertyID --> PropertyName, PropertyType, Street, Zip
zip --> city
propertyID, ServiceDate --> Description, Amount
Service introduced, but no primary key for SERVICE table
4.
PROPERTY (PropertyID, PropertyName, PropertyType, Street, City, Zip, ServiceDate)
and:
SERVICE (ServiceID, ServiceDate , Description, Amount)
PropertyID --> PropertyName, PropertyType, Street, Zip
zip --> city
propertyID, ServiceDate --> Description, Amount
ServiceID --> ServiceDate, Description, Amount
Primary key in SERVICE table introduced, but Proverty(Service Date) is invalid since SERVICE(SERVICEDATE) is not primary key
5
PROPERTY (PropertyID, PropertyName, PropertyType, Street, City, Zip, ServiceDate )
and:
SERVICE (ServiceID, ServiceDate, Description, Amount, PropertyID )
PropertyID --> PropertyName, PropertyType, Street, Zip
zip --> city
propertyID, ServiceDate --> Description, Amount
ServiceID --> ServiceDate, Description, Amount
Primary key in SERVICE table introduced, but Proverty(Service Date) is invalid since SERVICE(SERVICEDATE) is not primary key, but lossless join due to presence of primary key od Property table in Service table
For any help or doubt, commnet below!
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.