Chapter 5 Part B Consider the following as additional requirements for inventory and extend and modify the E-R data model that you prepared in Part A accordingly. Create appropriate identifiers and attributes for each entity and explain assumptions you make to determine minimum and maximum cardinality (similar to the assumptions listed above). Keep in mind that you will need additional entity(ies) and you may need to move one or more attributes from their current entity to another. Description of additional requirements All Supplies Medical wants to expand its database applications beyond the current recording of sales. The company still wants to maintain data on customer contacts, employees, vendors, sales, and items, but it also wants to modify the way it handles inventory. Currently, each purchase is considered unique, which means that one sale-item consists of only one quantity of an item, and that multiple units of the item in stock must be treated as separate items (records) in the PURCHASE table. The management wants the database modified to include an inventory system that will allow multiple units of an item to be stored under one PurchaseID. The system should allow columns for quantity on hand, quantity on order (ordered from a vendor), and order due date. If the identical item is stocked by multiple vendors, the item should be orderable from any of these vendors. The SALE_ITEM table should then include Quantity and Extended Price columns to allow for sales of multiple units of an item. Hint: This can be done by adding a single new entity and two relationships between the new entity and two existing entities. You may also have to change the type of one of the existing relationships. Chapter 5 Part C Consider the following as additional requirements for more efficient storage of CUSTOMER_CONTACT and EMPLOYEE data and extend and modify the E-R data model that you prepared in Part B accordingly. Create appropriate identifiers and attributes for each entity and explain assumptions you make to determine supertype/subtype entities and relationships between them (similar to the assumptions listed above). Note: For supertype/subtype relationships, you do not have to have the cardinality symbols, having inclusive/exclusive symbols will be sufficient. Also, LucidChart does not have specific symbols for inclusive/exclusive. You can just use some of the generic symbols to create something similar. Description of additional requirements All Supplies Medical wants to simplify the storage of customer and employee data. The company management has noticed that some of the fields in CUSTOMER_CONTACT and EMPLOYEE entities store similar data. Since their policies allow their employees to do a side job as a representative for a customer, under the current system, when an employee buys something for a customer, his or her data has to be reentered into the CUSTOMER_CONTACT table. The managers would like to have the CUSTOMER_CONTACT and EMPLOYEE tables redesigned using subtypes