HW1 Solutions Page

Return to homework page.

11.14 One distinction between inheritance in EER and OO is that in the former we do not have any methods associated with an object just attributes. Thus, issues such as polymorphic functions do not appear in EER model. Because of this in EER there is no binding issue of types at run-time that one might have with inheritance in the OO-model. Further there is no real notion of multiple inheritances in EER. The closest concept is a union type but this forces one to only one of the subtypes attributes for each object. In EER we have Entities and Relationships and inheritance only pertain to the former; whereas, in OO any class is potentially subclassable. (This is a little misleading because in ODMG the concept of a relationship is somehow embedded into class definitions.) On the other hand, although one could probably fake it by suitably dividing extents there is nothing that directly corresponds to the EER concepts of union type or disjoint specialization in the OO model.

11.15 Answers will differ for this question. What I was expecting was a reasonable effort to come up with an operation or two for each entity type. We are following the prototype format of Chapter 11, although it is fine to give C-like or ODMG like prototypes from Ch12. Below are some examples:

Person
findAddress() : Address; (* note here we are assuming we have
                                  defined Name and Address types as tuples
                                  of their components *)
Faculty
promote(rank : integer) : boolean;
calcSalary() : float;
findGrants() : set(Grant);

Student
getCurrent_Sections(): set(Current_Section);
getTranscript() : string;

Grad_Student
findAdvisor() : string;
findCommittee() : set(Faculty);
addCommittee(f : Faculty) : boolean;

Grant
addSupport(i : Intructor_Researcher) : boolean;

Instructor_Researcher
getSection(year : integer, qtr : integer) : set(Section);
addSection(s :Section) : boolean;

Current_Section
getRoster() : set(Student);
addStudent(s: Student) :boolean;

Section
getInstructor() : Instructor_Researcher;

Course
addSection(s : section) : boolean;
 
Department
findChair() : Faculty;
addFaculty(f : Faculty) : boolean;

College
addDepartment(d :Department) : boolean;

Pet DB problem

The requirements people come up with will vary. Here are some I considered:

Need to keep track of which pet supplies we have.
Want to break supplies into easily understood categories so
people can find them easily.
Need to know how to get more of a given supply if there is demand.
Need to know where we are storing a given supply.
Need to know who has placed order, how they want it delivered, and how
long since they ordered.

The ER diagrams people come up will be different from mine below. However, I expect any reasonable modelling of the problem to have at least four entities or so. Once you have the ER diagram, the mapping to tables is fixed by the Procedure 9.1.1 in the book.

Each key in the above tables fixes that row. Beyond this, considering the meaning of the above tables, we can see the following functional dependencies, multivalued dependencies and join dependencies:

In Supplier:
Phone --> Location 

In Pet Supplies:
Type --> Category  Ex: If know is Dog Food then know is Pet Food.
ItemName --> Type  Ex: If know Purina Dog Chow then know is Dog Food. 
 
In Order:

CardNo --> CID 

There did not seem to be any additional multivalued or join dependencies.

Given these dependencies, let's see which normal forms our tables satisfy. As there are no additional FDs, MVDs, or JDs beside on WAREHOUSE, SUPPLIES, PHONE, and CUSTOMER besides those derivable from key constraints we know these tables satisfy all the normal forms. This leaves us to consider the remaining three tables. Since first normal says we can't have multivalued attributes (which we don't) each table will be in 1st normal form.

PETSUPPLY and SUPPLIER are in 2NF because they only have one obvious key and their key has only one attribute. So all the nonprime attributes will be fully functionally dependent on this key. The non-prime attribute in ORDER is DeliveryType (CardNo ID Time is a candidate key). We cannot determine it from part of either of the two candidate keys so ORDER is in 2NF.

For 3NF we need that whenever X-->A, either (a) X is a superkey of R or (b) A is prime (part of a candidate key). This is not the case for Phone in Phone --> Location or Type in Type-->Category. Thus, neither SUPPLIER or PETSUPPLY will be in 3NF. As 3NF is weaker than BCNF, 4NF, 5NF they won't be in these latter forms either. As CID is part of a candidate key on the other hand, (b) above applies to CardNo --> CID, so ORDER will be in 3NF.

BCNF is 3NF where we eliminate clause (b). As CardNo is not a superkey for ORDER, ORDER will not be in BCNF. Hence, it won't be in 4NF ot 5NF either.

My Pet.mdb file.

Return to homework page.