Customers Product Orders Suppliers supplier_id suppliers_name supplier_address Supplier_phone supplies order product ld product_name product price product description order id Customer_id Customer Address customer_id customer name cistomer phone customer Address Brand order_item brand_id product_id order id brand_id product_id Document cord Product cation Failed Peferences Lang Rete Aa- 2! Aat 1 Normal 1 No Spec. Heading1 Heading 2 Title Subtic Paragraph Styles PART-1 1- Expand and enhance above database design to include Supertype and Subtype entities. You have the choice to decide if the Specialization Hierarchy is Disjoint or Overlapping and if the constraints are partial or Complete. Make sure you apply this to no less than 2 Entities. If in your above database design you did not provide any entities that could be extended then make sure you add to your Database design entities that could be categorized 2. Improve your database design by make sure your tables are Normalized. To solve this go through the check list provided in part-2 and make sure you have done all the recommendation given to you. Note: This Check list is recommended for your use anytime you design a database 3- Create at least I recursive relationship Make the new normalized ERD. A summary of changes that you have apply to your design, I" heading Heading 2 Title Sul Paragraph Styles PART-2 1- Business rules: Properly document and verify all business rules with the end users. Ensure that all business rules are written precisely, clearly, and simply. The business rules must help identify entities, attributes, relationships, and constraints. Identify the source of all business rules, and ensure that each business rule is justified, dated, and signed off by an approving authority. 2- Data modeling: Naming conventions: all names should be limited in length (database-dependent size) 3- Entity names: Should be nouns that are familiar to business and should be short and meaningful. Should document abbreviations, synonyms, and aliases for each entity. Should be unique within the model. For composite entities, may include a combination of abbreviated names of the entities linked through the composite entity. 4- Attribute names: Should be unique within the entity. Should use the entity abbreviation as a prefix. Should be descriptive of the characteristic. Should use suffixes such as _ID, NUM, or _CODE for the PK attribute. Should not be a reserved word. Should not contain spaces or special characters such as @...or & 5- Relationship names: Should be active or passive verbs that clearly indicate the nature of the relationship 6- Entities: Each entity should represent a single subject. Each entity should represent a set of distinguishable entity instances. All entities should be in 3NF or higher. Any entities below 3NF should be justified. Granularity of the entity instance should be clearly defined. PK should be clearly defined and support the selected data granularity 7- Attributes: Should be simple and single-valued (atomic data). Should document default values, constraints, synonyms, and aliases. Derived attributes should be clearly identified and include source(s). Should not be redundant unless this is required for transaction accuracy, performance or maintaining a history. Nonkey attributes must be fully dependent on the PK attribute 8- Relationships: Should clearly identify relationship participants. Should clearly define participation, connectivity, and document cardinality 9- ER model Should be validated against expected processes: inserts, updates, and deletions. Should evaluate where, when, and how to maintain a history. Should not contain redundant relationships except as required. Should minimize data redundancy to ensure single-place updates You can take upto 5 hours to complete this. Customers Product Orders Suppliers supplier_id suppliers_name supplier_address Supplier_phone supplies order product ld product_name product price product description order id Customer_id Customer Address customer_id customer name cistomer phone customer Address Brand order_item brand_id product_id order id brand_id product_id Document cord Product cation Failed Peferences Lang Rete Aa- 2! Aat 1 Normal 1 No Spec. Heading1 Heading 2 Title Subtic Paragraph Styles PART-1 1- Expand and enhance above database design to include Supertype and Subtype entities. You have the choice to decide if the Specialization Hierarchy is Disjoint or Overlapping and if the constraints are partial or Complete. Make sure you apply this to no less than 2 Entities. If in your above database design you did not provide any entities that could be extended then make sure you add to your Database design entities that could be categorized 2. Improve your database design by make sure your tables are Normalized. To solve this go through the check list provided in part-2 and make sure you have done all the recommendation given to you. Note: This Check list is recommended for your use anytime you design a database 3- Create at least I recursive relationship Make the new normalized ERD. A summary of changes that you have apply to your design, I" heading Heading 2 Title Sul Paragraph Styles PART-2 1- Business rules: Properly document and verify all business rules with the end users. Ensure that all business rules are written precisely, clearly, and simply. The business rules must help identify entities, attributes, relationships, and constraints. Identify the source of all business rules, and ensure that each business rule is justified, dated, and signed off by an approving authority. 2- Data modeling: Naming conventions: all names should be limited in length (database-dependent size) 3- Entity names: Should be nouns that are familiar to business and should be short and meaningful. Should document abbreviations, synonyms, and aliases for each entity. Should be unique within the model. For composite entities, may include a combination of abbreviated names of the entities linked through the composite entity. 4- Attribute names: Should be unique within the entity. Should use the entity abbreviation as a prefix. Should be descriptive of the characteristic. Should use suffixes such as _ID, NUM, or _CODE for the PK attribute. Should not be a reserved word. Should not contain spaces or special characters such as @...or & 5- Relationship names: Should be active or passive verbs that clearly indicate the nature of the relationship 6- Entities: Each entity should represent a single subject. Each entity should represent a set of distinguishable entity instances. All entities should be in 3NF or higher. Any entities below 3NF should be justified. Granularity of the entity instance should be clearly defined. PK should be clearly defined and support the selected data granularity 7- Attributes: Should be simple and single-valued (atomic data). Should document default values, constraints, synonyms, and aliases. Derived attributes should be clearly identified and include source(s). Should not be redundant unless this is required for transaction accuracy, performance or maintaining a history. Nonkey attributes must be fully dependent on the PK attribute 8- Relationships: Should clearly identify relationship participants. Should clearly define participation, connectivity, and document cardinality 9- ER model Should be validated against expected processes: inserts, updates, and deletions. Should evaluate where, when, and how to maintain a history. Should not contain redundant relationships except as required. Should minimize data redundancy to ensure single-place updates You can take upto 5 hours to complete this