Question:
How do I represent weak entity sets in the network and/or hierarchical models?
Answer:
Actually, you don't.
These models, being ``object oriented,'' have a built-in assumption that each
logical record (instance of an LRT) has an object ID.
In reality, the object ID is the location of the record in virtual memory,
just as for a struct in C or an object in C++.
Thus, there is no requirement that records in these ``historical'' models
have a key.
Question: Do we need a seperate engine entity set in part a since there is not any key information given for engines? Answer: No -- you can safely do this problem without using an engine entity set. You can assume that the types of engines can just be plugged appropriately into your automobile entity sets (of course, you have to do this in the correct manner...)
Question: Are car models unique? Could there be two cars with both the same model and manufacturer? Answer: Several manufacturers may offer cars with the same model designation. For instance, a "GL" model is offered by Ford, Volvo, Mercury, and probably a number of other manufacturers. However, it is fair to assume that one manufacturer would not have two different models with the same name. You may also assume that there are no two manufacturers with the same name.
Question: But what if the same model is offered with both a 4-cylinder and a 6-cylinder engine? Answer: Let's assume that models have unique numbers of cylinders, unique capacities (if they are an SUV) etc. That makes life simpler than trying to develop a key that will work for all combinations of engine type, SUV/not, etc.
Question:
My relation schemas for the E/R and O-O approaches are the same.
Is this situation possible?
Answer:
It can occur.
However, note that it is just the schemas that are the same, not the intension
of the relations or the data.
It has been suggested that we should have added another attribute like
price to the automobiles entity set, thus making the distinction
clearer.
Feel free to do that if you like, but either way, be careful and make sure
that you don't eliminate a relation just because its schema looks like that
of some other relation.
Note: do not assume from our publication of this question that we believe
the two schemas should be the same in all respects.