Convert the following unnormalized relation to fourth normal form using the requirements (many sales reps can represent one customer and one sales rep can represent many customers) ### Entity-Relationship Schema ExplanationThis image represents the structure of a basic database table design, detailing the relationships and attributes of a sales representative and their associated customers. Here is the transcription and explanation of each component:#### Table: `Rep`- **Primary Key:** - `RepNum`: The unique identifier for each sales representative. This is underlined to indicate it as the primary key in the database.- **Attributes:** - `LastName`: The last name of the sales representative. - `FirstName`: The first name of the sales representative. - `Street`: The street address where the sales representative is located. - `City`: The city where the sales representative is located. - `State`: The state where the sales representative is located. - `PostalCode`: The postal code of the sales representative's location. - `Commission`: The commission rate or amount that the sales representative earns. - `Rate`: Possibly an additional metric related to commission or performance.#### Nested Substructure: Customer Information- **Attributes Related to Customers:** - `CustomerNum`: A unique identifier for each customer; likely a foreign key relating to the `RepNum`. - `CustomerName`: The full name of the customer. - `Street`: The street address of the customer. - `City`: The city where the customer is located. - `State`: The state where the customer is located. - `PostalCode`: The postal code of the customer's location. - `Balance`: The current balance associated with the customer's account. - `CreditLimit`: The maximum credit limit set for the customer.This schema is hierarchical, showing that each sales representative may be related to multiple customers, indicating a one-to-many relationship. Understanding this structure is essential in designing databases that handle customer-relationship data efficiently.

Answer:) step: 1 of 7 Consider the given table. There exists following functional dependencies in the table: 1) RepNum-> LastName, FirstName, Street, City, State, PostalCode, Commission, Rate 2) CustomerNum-> CustomerName, Street, City, State, PostalCode, Balance, CreditLimit The table is said to be in fourth normal form, if it is in first, second and third normal form and the table must not have any multivalued dependencies. So that the table should be decomposed into various tables and all the tables must be related in right manner. step: 2 of 7 Step 1: The table must not have group of values in any attribute for one value of primary key. So the candidate key must be defined as primary key. The primary key is now the group of the keys: CustomerNum and RepNum. step: 3 of 7 Step 2: The relation which is in first normal form can still have a problem of update anomaly that is there could be repeating values, which waste space and cause problems at the time of updating. • For example: in the above described relation, still the values of the fields CustomerNum, CustomerName, Street, City, State, PostalCode, Balance, CreditLimit could be repeated for more than one group of values of primary (combination) key. • So the relation must have all non-key attributes dependent only on key attribute(s). • Hence, divide a relation into two relations named Customer and Rep to be in second normal form. Following would be the structure: • Rep (RepNum, LastName, FirstName, Street, City, State, PostalCode) • Customer (CustomerNum, CustomerName, Street, City, State, PostalCode, Balance, CreditLimit, RepNum, Commission, Rate) step: 4 of 7 Step 3: The relation which is in second normal form can still have a problem of repetition of values due to combinational primary key. • For example the relation Customer can have many same values of RepNum, Commission, Rate. The tables after decomposition which show the relations as well are shown below: 1) Rep (RepNum, LastName, FirstName, Street, City, State, PostalCode, Commission, Rate) 2) Customer (CustomerNum, CustomerName, Street, City, State, PostalCode, Balance, CreditLimit) Now, there are no functional dependencies that each non-key attribute of the table is dependent on only the key attribute. So each table is in third normal form. step: 5 of 7 Requirements: 1. A sales representative can represent many customers and many sales representative scan represent one customer so if the relation would be designed as follows: 1) Rep (RepNum, LastName, FirstName, Street, City, State, PostalCode, Commission, Rate, CustomerNum) 2) Customer (CustomerNum, CustomerName, Street, City, State, PostalCode, Balance, CreditLimit, RepNum) step: 6 of 7 Step 4: There would be multivalued dependencies because for a CustomerNum, there would be various RepNum and for a RepNum, there would be various CustomerNum. So there must be another relation as shown: • CustomerRep (CustomerNum, RepNum) step: 7 of 7 Step 5: Now the structure of the relations, which is in fourth normal form, would be: • Rep (RepNum, LastName, FirstName, Street, City, State, PostalCode, Commission, Rate, CustomerNum) • Customer (CustomerNum, CustomerName, Street, City, State, PostalCode, Balance, CreditLimit, RepNum) • CustomerRep (CustomerNum, RepNum)