Coit11237 assignment 2 specifications
Download as DOCX, PDF1 like398 views
The document outlines the specifications for assignment 2 of the course COIT11237, which is due by Friday of week 10 and carries a weight of 30%. The assignment consists of three parts: creating an entity-relationship diagram (ERD), designing tables for a software product storage, and transforming the ER model into a relational database design. Students are expected to adhere to certain standards and document their assumptions, with assessment criteria detailed for each part.
Coit11237 assignment 2 specifications
- 1. COIT11237 – Assignment 2 Specifications Page: 1 of 4. Assessment details for ALL students Assessment item 2—Assignment 2 Due date: Friday of Week 10 (Midnight AEST time) ASSESSMENT Weighting: 30% Length: Typically 10-20 hours 2 Objectives This assessment item relates to all course learning outcomes in the course profile. Introduction This is a highly industry relevant assignment. It consists of multiple parts: • Part A — Entity-Relationship Diagram (ERD) (40 marks) • Part B — Table design (30 marks) • Part C — Data Model Transformation (30 marks) Students are expected to complete all parts. Part A — Entity-Relationship Diagram (ERD) (40 marks) Draw an Entity-Relationship Diagram (ERD) for the data storage requirements of a business described in the case study below. Notes: • It is recommended that you follow the modelling standard used in the text book and lecture slides. • Use only attributes that uniquely identify instances of an entity that are mentioned inside the case study. Any other attributes that also could uniquely identify entity instances beyond the case study should not be introduced. • Some information in the case study is ambiguous, vague, and/or missing. This is intentional to encourage students to think, explore, and search for answers. There are two options: 1. Seek clarification about the case study by posting a message on the course forums for this assignment (after searching thoroughly, you notice the same topic / question has not already been discussed). In an appendix named ‘Assumptions and Clarifications’, clearly document any clarification received in your assignment submission. This appendix will be marked regarded as a 10-mark task in Part A as ‘Assumptions/ clarifications support all details provided in the ERD’. 2. Make reasonable assumptions about missing or ambiguous information in the case study which are useful information that support the way you draw and present your developed
- 2. COIT11237 – Assignment 2 Specifications Page: 2 of 4. ERD. Your assumptions and clarifications need to adequately support why all details in the ERD are provided as such. However, marks may be lost for unreasonable assumptions. For example, the follow are unreasonable assumptions: • ‘I assume that each invoice must be paid, so created a payment entity for this assignment’ (when the last line in the case study clearly states that payments are outside the scope) and • ‘I could not find MS Visio in any CQU lab or any similar software, so hand drew my ERD for submission’. The Case Study A local IT retailer “IT solutions” in Melbourne offer both IT products (desktop PCs, tablet PCs and individual components) and services to its customers. Due to new advances in technology and increased use of mobile devices, IT solutions has seen significant growth in IT product sales and demand for their services. In order to meet the growing needs and to record product and service related transactions, they hired a consultant to design a database to store all of the required data about their customers, offerings, products, services and billing. The consultant has been provided with data storage requirements which are described below. An offering can be a product or a service. When customers visits their store, IT solutions assigns a unique customer ID to each customer and records their title, first name, last name, address (number, street, city, postcode), both home phone and mobile phone numbers and their email address. If the customer wishes to purchase any of the offerings, then offeringID, description and type (product or service) are recorded. Purchase date is also recorded every time an offering is purchased. If the product is purchased then product name, price, and the product release date are noted. If the offering is a service then Name of the Employee responsible for that service, service conditions, service type are recorded. It is important to note that a service can be either repair or maintenance. For repair cost will be recorded, if its maintenance, hourly rate will be noted. Although it is not a common occurrence, sometimes stocked products may require repair. If this service is purchased by the customer, then a final Invoice will be prepared at the end of each service and given to the customer for payment. Invoice includes details relating to service date, due date and the amount due. Employee (except employee name) and Payments are outside the scope for this case study. How You Are Marked for the Entity-Relationship Diagram (ERD) You need to ensure you pay attention to the following aspects when developing your ERD: • Correct entities are identified (5 marks) • Correct appropriate use of unique identifiers (5 marks) • Appropriate attributes and attribute types for each entity (5 marks) • Appropriate use of symbols (5 marks) • Correct relationships and cardinalities (min/ max cardinalities) (10 marks) • Assumptions/ clarifications support all details provided in the ERD (10 marks)
- 3. COIT11237 – Assignment 2 Specifications Page: 3 of 4. Part B — Table design (30 marks) “IT solutions” created a table to store details of different software products. Primary key for this table is a composite key made with Organisation and Software_name. Unfortunately, some anomalies arose while using this design. Below is a small sample of some of this data: Software_details Organisation Country_of_origin Software_name Software_type Version Microsoft USA Office Office application 2013 Microsoft USA Windows Operating System XP Apple USA Mac Operating System 7.6 Oracle USA Oracle Database 11.0 Infosys Technologies Ltd. India BANCS 2000 Banking product 1.0 Ramco Systems India Marshal ERP 1.0 Tata Consultancy Services India EX Financial accounting 1.0 Eastern Software Systems India MakEss ERP 1.0 Arrow Australia Tencia Accounting 1.0 Pan Software Australia Riskware Risk management 1.0 Questions Support your answers to questions below with any assumptions that help to clarify your understanding of data in the Software_details table. 1. Identify one anomaly that might arise from using the above table. (6 marks) 2. Identify all functional dependencies in the above mentioned table. (7 marks) 3. Explain why this table does not satisfy BCNF. (7 marks) 4. Convert this table into a set of BCNF tables that can hold the sample data shown in the above table. (10 marks) Note: Document the tables in your design using the notation below. Customer(CID, Name, Street, Suburb, State, PostCode, DiscountPercent, Email) SalesOrder(SOID, CID, Number, FullPrice, Discount, FinalPrice, TotalPaid, Status) foreign key (CID) references Customer(CID)
- 4. COIT11237 – Assignment 2 Specifications Page: 4 of 4. Part C — Data Model Transformation (30 marks) Implement the ER model you developed in Part A as a relational database design. 1. Transform your ER model into a relational database design. (10 marks) Note: Document the tables in your design using the notation shown in the example below. Customer(CID, Name, Street, Suburb, State, PostCode, DiscountPercent, Email) SalesOrder(SOID, CID, Number, FullPrice, Discount, FinalPrice, TotalPaid, Status) foreign key (CID) references Customer(CID) 2. Implement sufficient tables to support the requirements below. You do not need to implement (create) the entire database. You just need to implement enough of the database to demonstrate (and document) the following: (20 marks) A. use of data types: provide examples of four different data types used in your design B. primary key constraints: provide two examples C. foreign key constraints: provide two examples D. a unique constraint: provide one example E. a cascading delete:provide one example F. column constraints (a constraint that affects only one column): provide two examples G. a table constraint (a constraint that affects more than one column): provide one example H. default values: provide two examples I. validation rule with a corresponding validation text: provide one each as two examples J. input mask: provide one example k. required: provide one example L. format: provide one example Note: Each item has its mark as bolded and underlined above. You need to include a brief documentation (in a word document) that highlights where the above items are demonstrated in your database, e.g. where the primary key constraints are. Marks will be lost if your documentation is missing, unclear or not concise. How and what to submit You must make an electronic submission using submission link on the course web site. Your submission must consist of a single ZIP file which contains your assignment work in two files, as follows: 1. A Microsoft Word document containing: • Your Entity Relationship Diagram (ERD) for Part A • Your reasonable assumptions/points of clarification for Part A (if you have any) • Your answers to questions in Part B • Documentation for Part C. 2. Microsoft Access file containing: The tables and features you have implemented to support the requirements for Part C. Marking, modelsolutions, and deadlines • Marked assignments and marking feedback are made available to students approximately 2 weeks after the due date or 2 weeks after submission, whichever is later. Any Assignment 2 submitted 2 weeks after the due date will NOT be accepted or marked.