Create an EER diagram using MySQL Workbench (Crow's Foot Notation) to support the described business scenario and its operations. After, translate the diagram into a DB schema consisting of tables and provide screenshots

If you feel that some information, you need when modeling relationships or sub-types, is missing in a question specs, then make reasonable assumptions and state them clearly at the beginning of your answer to the question. If you fell that a question contains contradictory requirements, describe what the contradiction is, and make a reasonable assumption to resolve it (and, of course, describe the contradiction and the assumption (that will resolve the contradiction) at the beginning of vour answer As Workbench does not have notations for composite and multi-valued attributes, note such attributes when describing entities (see below). Furthermore, as Workbench does not provide notation to represent sub-types, you should represent a sub-type in your Workbench ER diagram as an entity with a 1:1 relationship to its super-type. The sub-type entity will have the primary key being the foreign key. For instance, if A is the super-type and B is a sub-type of A, then there is 1:1 relationship between A and B, where one of A and B will have a mandatory membership while the other may be an optional membership #1 List your assumptions and clearly state your assumptions that you made (in addition to the question specs for the question), such as any assumption that you make to determine whether a membership in a relationship is optional or mandatory o As an example, if two entities, EMPLOYEE and DEPARTMENT, have a one-to-many relationship Works-for (from DEPARTMENT to EMPLOYEE) and the question is silent on whether any instance EMPLOYEE must belong to an instance of DEPARTMENT in the relationship Works-for, then you make and describe/state your assumption and state why you made it, such as o Assumption: Every employee must work for a department o Reason: It is needed to determine whether the membership of an EMPLOYEE instance is mandatory or optional in the relationship Works-for between EMPLOYEE and DEPARTMENT entities. Another example is if you have a super-type and its sub-types, such as the super-type EMPLOYEE and sub- types (of EMPLOYEE) being PILOT and ACCOUNTANT. If the question is silent on whether or not each employee must be either a pilot or an accountant, or might not be neither of the two, then you need to make an assumption about it and also state it. Also, if the question does not state whether an employee can be both a pilot and an accountant, then again, you need to make an assumption about it and state that it is to determine whether sub-types are disjoint or not. o #2 Show a screenshot of your diagram o When showing a screenshot of your EER diagram (created using Workbench) in your answer, your entities should not show attributes, but rather should appear as shown here for an entity called book: book To not-show attributes of an entity in a diagram, click on the little triangle at the top right corner of the entity-rectangle " o Show your whole EER diagram. If the screenshot does not show sufficient details (e.g., the crow's feet are not clear enough to show optional/mandatory memberships), then you need to also show its sub-parts as screenshots so that such details are recognizable by the marker o List entities and for each entity also list its attributes. Names of attributes for primary keys should be such that they end with the last two digits of you student ID. For each attribute identify whether it has unigque values, must not have NULL values, " is multi-valued, is composite, in which case list the attributes components. o List super-types and their corresponding sub-types. For any super-type and of its sub-types, you need to state whether sub-types are disjoint or optional and also whether a super-type instance must be or does not have to be any of its sub-types. o List relationships and for each one whether it is 1:1, 1:N, or N:M, and memberships (mandatory or optional). Use the following table to show these properties. You need not show sample data stored in rows/tuples of tables/relation Relationship (El:E2) El Membership E2 Membership Relationship Name Entity E1 Name Entity E2 Name Type N N:M Mand Opt Mand Opt ChairsDep EMP DEP #3 Translate the EER diagram intoa DB scheme consisting of a set of relations/tables and show the list of relations. For each relation, show its list of attribute names. For each o Ifit is a part of the table's primary key, add "PK" in parentheses after its name. o Ifit is a part of a foreign key, add "FK" in parentheses after its name. o If it has unique values, add "UQ" in parentheses after its name. If its value cannot be NULL, add o If its value cannot be NULL, add "NN" in parentheses after its name. after its name. If an attribute (could be a composite one) is a primary key, it is assumed that no NULL values may appear in it and that the values are unique (i.e., you need not put UQ or NN for primary key attributes) Question Specifications: A scenic tours company, referred to as the company, provides guided tours and has the following operations and data requirements that were gathered from the company's employees: For each tour, the tour name, length of time in hours), and fee charged are needed. Information about guides includes an employee ID, name, and the date of hire. Guides take tests to be qualified to lead specific tours. It is important to know which guides are qualified to lead which tours and the date that they completed the qualification test for each tour (they are qualified to lead). A guide may be qualified to lead many different tours. A tour can have many different qualified guides. New guides may or may not be qualified to lead many tours, just as a tour may or may not require a qualified guide. Every tour must be designed to visit three locations or more locations. For cach location, the name, type, and official description are kept. Some popular locations are visited by more than one tour. The order in which a tour visits cach location should be tracked as well When a tour is actually given, that is referred to as an "outing." The company schedules outings well in advance so they can be advertised, so that customers may sign up in advance and employees can understand their upcoming work schedules. A tour can have many scheduled outings. New tours can be added. Once a tour is created and information about is recorded, locations visited and the order in which they are visited are not changed. Each outing is for a single tour and is scheduled to occur at a particular date and time. All outings must be associated with a tour. All tours are guided tours, so a guide must be assigned to each outing. Each outing has exactly one guide. Newly hired guides may not have ever been scheduled to lead any outings. Tourists, referred to as "clients" or "customers, pay to join a scheduled outing. For cach client, the name, telephone number are recorded (ame includes the first name, initials, and the last name). Furthermore, email addresses for a customer are also recorded. Clients may sign up to join many different outings, and cach outing can have many clients. Information is kept only on clients who have signed up for at least one outing