Cascading Key

BJECTIVE: Get some firsthand experience with the implications of a chain of relationships. INTRODUCTION: Jo Anne's Fabrics and Crafts has stores all across the country. Each store has a name that is unique within that store's district. Each district has a name that is unique within that district's region. Each region has a name that is unique within that region's state. Assume for this exercise that Jo Anne's only operates within the United States. Each store has a store manager. Each district has a district manager, and so on up the line. A given manager manages one and only one store, district, region, and state. Each manager is an employee of Jo Anne's. Each employee in Jo Anne's has a surrogate key: Employeeld. Their Employee ID uniquely identifies them across all of Jo Anne's. PROCEDURE: For each state, we want to know the manager in charge of that state. For each region, we want to know the manager. Similarly for the district and the individual store. For each store, we want to know the city within the state where the store is located. One city could have more than one Jo Anne's stores in it. A given store can come in "large" or "small" format and we want to know that as well. Create a UML class model of the above information. Then create the corresponding relation scheme diagram. There are two basic ways to go about the key structure of this model: one using a surrogate key in each case, and the other that uses no surrogate keys. In one of your relation scheme diagrams, the only surrogate will be Employeeld. In the other relation scheme diagram, create a surrogate key for Region and District. See what each approach does to the primary key of Store. WHAT TO TURN IN: The UML class model for each approach to the key structure in either a dia or draw.io model. The relation scheme diagram for each approach to the key structure in either in a .dia or draw.io model. A short Word document describing the benefits and liabilities of each approach to the key structure. BJECTIVE: Get some firsthand experience with the implications of a chain of relationships. INTRODUCTION: Jo Anne's Fabrics and Crafts has stores all across the country. Each store has a name that is unique within that store's district. Each district has a name that is unique within that district's region. Each region has a name that is unique within that region's state. Assume for this exercise that Jo Anne's only operates within the United States. Each store has a store manager. Each district has a district manager, and so on up the line. A given manager manages one and only one store, district, region, and state. Each manager is an employee of Jo Anne's. Each employee in Jo Anne's has a surrogate key: Employeeld. Their Employee ID uniquely identifies them across all of Jo Anne's. PROCEDURE: For each state, we want to know the manager in charge of that state. For each region, we want to know the manager. Similarly for the district and the individual store. For each store, we want to know the city within the state where the store is located. One city could have more than one Jo Anne's stores in it. A given store can come in "large" or "small" format and we want to know that as well. Create a UML class model of the above information. Then create the corresponding relation scheme diagram. There are two basic ways to go about the key structure of this model: one using a surrogate key in each case, and the other that uses no surrogate keys. In one of your relation scheme diagrams, the only surrogate will be Employeeld. In the other relation scheme diagram, create a surrogate key for Region and District. See what each approach does to the primary key of Store. WHAT TO TURN IN: The UML class model for each approach to the key structure in either a dia or draw.io model. The relation scheme diagram for each approach to the key structure in either in a .dia or draw.io model. A short Word document describing the benefits and liabilities of each approach to the key structure