OBJECTIVE: INTRODUCTION: PROCEDURE: Get some practice with different uses of junction tables. As we know, a one-to-many

[answerhappygod]

Objective Introduction Procedure Get Some Practice With Different Uses Of Junction Tables As We Know A One To Many 1 (73.23 KiB) Viewed 35 times

OBJECTIVE: INTRODUCTION: PROCEDURE: Get some practice with different uses of junction tables. As we know, a one-to-many relationship can sometimes have more to it than just an association. There might be attributes or other associations that only apply to the child in the context of that association. Just how to model that in UML and then implement the association in the relation scheme is often a matter of judgement. You have the following business rules: 1. An engine can exist outside of a car. Presume that the engine has some sort of an ID stamped into the block that is independent of the VIN of a vehicle. 2. We will keep track of the total displacement of the engine, the number of miles on it, and the year when it was manufactured. 3. An engine can also be installed in a car. 4. If an engine is installed in a car, we will keep track of the VIN of the car, the date and time when the installation occurred, and who the mechanic was who performed the installation. 5. On the other hand, if an engine is not installed in a car, we will not capture a VIN, date, and time of installation, nor mechanic. Either all three of those associations are populated for the engine, or none of themis. 6. Use a lookup table for the mechanic. Model this in UML, and then create a relation scheme for it. Indicate on the relation scheme diagram how you are implementing each of the above business rules. Remember, this is an exercise in using junction tables.