PROJECT1.1 Implementing Database Design Implementing Database Design 1.2 INSTRUCTOR NOTES The following are the inputs for the faculty for project allocation and evaluation: The project should be allocated to individual students by the end of the Retrieving and Maintaining Data submodule. The student can start the project earliest after the Experiment session of Managing Databases is over. During allocation, explain the students the scope of the project by referring to the topic Project Activities and Project Timelines. Ask the students to refer to the sample case study and its solution given in the sample project documentation. Ask the students to refer to the topic Project Standards and Guidelines before starting the project documentation. Before project evaluation day, ask the students to verify their projects according to the standards and guidelines given in the topic Project Standards and Guidelines. Evaluate the students according to the guidelines given in the topic Project Evaluation Guidelines. 1.3 Implementing Database Design CASE STUDY 1: SHOP HERE Background Shop Here is a leading departmental store in New York. The store is known for quality products, affordable price range, timely services, and home delivery facility. The store has customers from all sections of the society and procures goods from various countries. Existing System Shop Here maintains an optimum inventory of various categories of items. The details of the various categories are stored in the Categories file. This file contains data about the item category numbers and the corresponding categories. The details of the items are stored in a file named Items. The Items file contains records such as item number, item description, item category number, serial number of the item, unit price of each item, and reorder level of each item. The store has several regular suppliers for the various items. The suppliers are spread over various geographical locations. A detailed record is maintained for each supplier. The supplier record consists of supplier code, supplier’s name, address, phone number, country of origin, and shipment mode number and shipment mode for outstation suppliers. All records are maintained in the Suppliers file. Whenever the employee of a store places a purchase order, a purchase order form needs to be filled out. The format of a purchase order form is as follows: PURCHASE ORDER FORM Purchase Order ID: Employee ID: Shipment Date: Shipment Method ID: Supplier ID: Order Date: Quantity: Freight Charge: A complete transaction takes place when the purchase is made and the payment is done. Envisioned System Shop Here requires a computerized system that provides an effective method of storing transaction details. The inventory-in-charge, Chris Symonds, realizes that with growth in business, it becomes difficult to manually maintain the inventory. Shop Here Implementing Database Design 1.4 also wants to include the information about employees who place purchase orders with the suppliers. Therefore, the management of the store has decided to computerize the inventory management of the store. To fulfill this need, the store management has contacted RedSky IT Systems to develop the computerized system. Don Allen, a project manager of RedSky IT Systems, has been deputed to manage the assignment. Don and his project team have: 1. Identified the various entities involved. 2. Identified the attributes of the various entities. The attributes should completely define the entities. 3. Drawn an E/R diagram to demonstrate the relationship between the various entities. 4. Mapped the E/R diagram to tables. 5. Normalized the tables to 3 NF. The normalized tables should have: a. Table names b. Field names, datatypes, and size of fields c. Primary and foreign key identification and integrity 6. Drawn a diagram to show the relationships between various tables. The final relationship diagram created by the project team is as follows: 1.5 Implementing Database Design Relationship Diagram For the Shop Here Database Management System Implementing Database Design 1.6 INSTRUCTOR NOTES The various steps involved in creation of the relationship diagram are as follows: Identifying Entities The entities for the Shop Here database management system are: 1. Employees 2. Items 3. Purchase Orders 4. Suppliers 5. Categories Identifying Attributes The attributes of the entities listed above are as follows: 1. Employees: Employee ID, First Name, Last Name, Title, Phone 2. Items: Item ID, Item Name, Item Description, Category ID, Unit Price, Reorder Level, Quantity On Hand 3. Purchase Orders: Purchase Order ID, Supplier ID, Employee ID, Order Date, Shipping Date, Shipping Method, Freight Charge 4. Suppliers: Supplier ID, First Name, Last Name, Address, City, State, Zip, Country, Phone 5. Categories: Category ID, Category Description 1.7 Implementing Database Design Drawing the E-R Diagram EMPLOYEES 1 PLACE m PURCHASE ORDERS m m FOR m ITEMS m MADE FROM HAS 1 SUPPLIERS 1 CATEGORIES Normalizing tables The tables that will be created in the database are as follows: Employees Employee ID First Name Last Name Items Item ID Purchase Orders Purchase Order ID Supplier ID Employee ID Item Name Item Description Category ID Unit Price Reorder Level Title Phone Order Date Shipping Date Shipping Method ID Shipping Method Quantity On Hand (QOH) Freight Charge Implementing Database Design 1.8 Suppliers Categories Inventory Transactions Transaction ID Purchase Order ID Supplier ID First Name Category ID Category Description Last Name Address Item ID Transaction Description Transaction Date Quantity Ordered Quantity Received Total Amount City State Country Zip Phone Normalizing tables to 1NF The tables are already in 1NF. Normalizing tables to 2NF All the attributes of the tables are dependant on the whole key and not just part of the key. Hence, the tables are in 2NF. Normalizing tables to 3NF In the Purchase Orders table, the attribute Shipping Method depends on Shipping Method ID and not on the Purchase Order ID. Therefore, for the tables to be in 3 NF, we need to create another table, Shipment Methods. 1.9 Implementing Database Design Employees Employee ID First Name Last Name Title Phone Items Item ID Purchase Orders Purchase Order ID Item Name Item Description Category ID Unit Price Reorder Level Quantity On Hand (QOH) Supplier ID Employee ID Order Date Shipping Date Shipping Method ID Freight Charge Suppliers Categories Inventory Transactions Transaction ID Purchase Order ID Supplier ID First Name Category ID Category Description Last Name Address Item ID Transaction Description Transaction Date Quantity Ordered Quantity Received Total Amount City State Country Zip Phone Implementing Database Design 1.10 Shipment Methods Shipment Method ID Shipment Method Description To create a computerized transaction system for Shop Here using SQL Server 2000, the project team needs to perform the following tasks: 1. Create a database, ShopHere. 2. Create the tables as per the relationship diagram ensuring minimum disk space utilization. 3. The validations to be performed on the tables are as follows: Table: Items a. b. c. d. e. f. g. Item ID must be unique. Item ID must be auto generated. Item name should not be left blank. Item description should not be left blank. The record should not be inserted or modified if QOH is 0. Unit Price should be greater than 0. ROQ should be greater than 0. Table: Categories a. Category ID must be unique. b. Category ID must be auto generated. c. Category description should not be left blank. Table: ShippingMethods a. Shipping Method ID must be unique. b. Shipping Method ID must be auto generated. c. Method description should not be left blank. Table: Suppliers a. b. c. d. Supplier ID must be unique. Supplier ID must be auto generated. First Name, Last Name, City, and Phone should not be left blank. The Phone number must be in the following format: ‘[0-9][0-9][0-9][0-9]-[0-9][0-9][0-9]-[0-9][0-9][0-9]’ Example: 4356-555-555 1.11 Implementing Database Design Table: Employees a. b. c. d. e. Employee ID must be unique. Employee ID must be auto generated. Employee First Name, Last Name, Phone should not be left blank. The Phone number must be in the following format: ‘[0-9][0-9][0-9][0-9]-[0-9][0-9][0-9]-[0-9][0-9][0-9]’ The Title value must be any one of the following: ‘Trainee’, ’Floor Manager’, ’Senior Manager’, ’Floor In Charge’ , ‘Executive’, ‘Senior Executive’. Table: PurchaseOrders a. Purchase Order ID must be unique. b. The purchase order id must be in the following format: P[0-9][0-9][0-9] Example: P001 c. The Order date should not be greater than the current date. d. The Shipment date should not be less than the order date. e. If the order date is not entered, the current date should be taken as the default date. f. The Freight Charge should be greater than 0. Table: InventoryTransactions a. b. c. d. e. f. Transaction ID should uniquely identify each record in the table. Transaction ID should be auto generated. The Transaction date should not be greater than the current date. The Transaction date should be the current date if not entered. The Transaction date should be greater than the order date. Quantity Ordered, Quantity Received, and Unit Price should be greater than 0. g. The Quantity Received cannot be greater than the quantity ordered. h. Total Amount should be automatically calculated using the formula ((Quantity Received*Unit Price of Item) + Freight Charge) and be stored in the Total Amount field. i. j. k. The Shipment date should be updated to two days after the transaction date after the transaction is successfully completed. The Quantity received should be added to the QOH in the Items table. When a record is inserted into the table, the QOH in the Items table should be updated automatically. 4. Create appropriate relationships between the tables. 5. The Transaction details need to be stored in a text file on a day-to-day basis. Make use of the required tools to perform the data transfer. Implementing Database Design 1.12 6. You need to ensure that a supplier record is deleted from the Suppliers table only after all the records from the dependant tables are deleted. 7. The users of the database need to perform the following queries frequently: a. Extracting the transaction details for all the purchase orders in the current month. b. Extracting the details of all purchase orders handled by a particular employee. c. Extracting the details of all the orders placed more than two years back. d. Displaying the details for all the employees based on the title of the employees. Based on the above queries, create the appropriate indexes to speed up the execution of queries and joins. 8. The entire database should be created using SQL scripts. This will help to ensure that the database and its objects can be recreated in minimum possible time in event of a database crash. 1.13 Implementing Database Design CASE STUDY 2: SHOWMAN HOUSE Background Showman House is a large event management company of New York. The company organizes various types of events throughout the year. The events types include fashion shows, celebrity shows, chat shows, musical extravaganza, exhibitions, fairs, and charity shows. Existing System Showman House organizes events of different types. The details of the various event types are stored in the Event Types file. This file contains data about the event type codes and the corresponding event types. Any attendee who wishes to organize an event needs to provide details about the nature of the event he wants to organize. Along with providing event details, he also makes the payment for the event. The payment for an event is made in instalments, according to the fee plan, which is stored in the Fee Schedules file. The Fee Schedules file maintains details such as fee schedule id, event id, fee description, and fee amount. An attendee needs to pay all the instalments of the payment, on or before the start date of the event. All details related to an event such as event code, event name, event type code, location of the event, start date, end date, event description, number of people, and the staffing required for the event are stored in the Events file. The payment details that include payment amount, payment date, payment method id, and payment method description are also stored in the Events file. The details of an attendee such as attendee id, attendee name, and address are stored in the Attendees file. Any event at Showman House is managed by an employee. The employee details such as employee id, first name, last name, title, and phone are stored in the Employees file. Envisioned System The management of Showman House realize that it is difficult to maintain so much data manually. Therefore, they have decided to computerize the entire system of event management. Blue Moon Computers have been assigned the task to computerize the system. The project team of Blue Moon have: 1. Identified the various entities involved. 2. Identified the attributes of the various entities. The attributes should completely define the entities. 3. Drawn an E/R diagram to demonstrate the relationship between the various entities. Implementing Database Design 1.14 4. Mapped the E/R diagram to tables. 5. Normalized the tables to 3 NF. The normalized tables should have: a. Table names b. Field names, datatypes, and size of fields c. Primary and foreign key identification and integrity 6. Drawn a diagram to show the relationships between various tables. The final relationship diagram created by the project team is as follows: Relationship Diagram for the Showman House Database Management System 1.15 Implementing Database Design INSTRUCTOR NOTES The various steps involved in creation of the relationship diagram are as follows: Identifying Entities The entities for the Showman House database management system are: 1. Attendees 2. Events 3. Fee Schedules 4. Employees 5. Event Types Identifying Attributes The attributes of the entities listed above are as follows: 1. Attendees: Attendee ID, First Name, Last Name, Address, City, State, Zip, Country, Phone 2. Events: Event ID, Event Name, Event Type ID, Event Description, Location, Start Date, End Date, Staffing Required, Employee ID, Attendee ID, No Of People, Payment Date, Payment Amount, Payment Method ID, Payment Method, Credit Card No, Card Holder Name, Expiry Date, Fee Schedule ID 3. Fee Schedules: Fee Schedule ID, Event ID, Fee Description, Fee 4. Employees: Employee ID, First Name, Last Name, Title, Phone 5. Event Types: Event Type ID, Event Type Description Implementing Database Design 1.16 Drawing the E-R Diagram HAS 1 EVENT TYPES ATTENDEES 1 m PAY FOR m EVENTS 1 1 HAS 1 FEE SCHEDULES MANAGED BY 1 EMPLOYEES Normalizing Tables The tables that will be created in the database are as follows: 1.17 Implementing Database Design Attendees Attendee ID First Name Last Name Address City State Country Zip Phone Events Event ID Event Name Event Description Event Type ID Location Start Date End Date Staffing Required Employee ID Attendee ID No Of People Payment Date Payment Amount Payment Method ID Payment Method Credit Card No Card Holder Name Expiry Date Fee Schedule ID Fee Schedules Purchase Order ID Supplier ID Employee ID Order Date Implementing Database Design 1.18 Employees Employee ID First Name Last Name Address City State Country Zip Phone Event Types Event Type ID Event Type Description Normalizing tables to 1NF These tables are already in 1NF. Normalizing tables to 2NF For 2 NF, the tables Attendees, Employees, Event Types, and Fee Schedules will not change as they are already in 2 NF. In the Events table, Event ID, Attendee ID, and Fee Schedule ID comprise the composite key. The attributes Payment Date, Payment Amount, and Payment Method ID, Payment Method, Credit Card No, Card Holder Name, and Expiry Date depend only on Event ID and Fee Schedule ID and not the Attendee ID. Therefore, we need to create another table, Payments. Now, the tables are as follows: 1.19 Implementing Database Design Attendees Attendee ID First Name Last Name Address City State Country Zip Phone Events Event ID Event Name Event Description Event Type ID Location Start Date End Date Staffing Required Employee ID Attendee ID No Of People Fee Schedules Fee Schedule ID Event ID Fee Description Fee Implementing Database Design 1.20 Employees Employee ID First Name Last Name Address City State Country Zip Phone Event Types Event Type ID Event Type Description Payments Payment ID Payment Date Payment Amount Payment Method ID Payment Method Credit Card No Card Holder Name Expiry Date Fee Schedule ID Event ID Normalizing tables to 3NF In the Payments table, the attribute Payment Method depends on Payment Method ID and not on the Payment ID. Therefore, for the tables to be in 3 NF, we need to create another table, Payment Methods. 1.21 Implementing Database Design Attendees Attendee ID First Name Last Name Address City State Country Zip Phone Events Event ID Event Name Event Description Event Type ID Location Start Date End Date Staffing Required Employee ID Attendee ID No Of People Fee Schedules Fee Schedule ID Event ID Fee Description Fee Implementing Database Design 1.22 Employees Employee ID First Name Last Name Address City State Country Zip Phone Event Types Event Type ID Event Type Description Payments Payment ID Payment Date Payment Amount Payment Method ID Payment Method Credit Card No Card Holder Name Expiry Date Fee Schedule ID Event ID Payment Methods Payment Method ID Payment Method Description To create the computerized event management system for Showman House, the project team at Blue Moon Computers needs to perform the following tasks: 1. Create a database, ShowmanHouse. 2. Create the table designs as per the relationship diagram ensuring minimum disk space utilization. 3. The validations to be performed on the tables are as follows: Table: Employees a. Employee ID should be unique. b. The FirstName, LastName, City, and Phone should not be left blank. 1.23 Implementing Database Design c. The Title of the employees should be any one of the following: ‘Executive’, ’Senior Executive’, ‘Management Trainee’, ‘Event Manager’, ‘Senior Event Manager’. d. The Phone number should be in the following format: ‘[0-9][0-9]-[0-9][0-9][0-9]-[0-9][0-9][0-9]’ Example: 11-111-111 Table: Events a. Event ID should be unique. b. Event ID should be auto generated. c. Event Name, Start Date, End Date, Location, NoOfPeople, and StaffingRequired should not be left blank. d. NoOfPeople and StaffingRequired should be greater than 0. e. The Start Date should be less than the End Date. f. The Start Date and End Date should be greater than the current date. Table: Payments a. Payment ID must be unique. b. Payment ID should be in the following format: ‘PA[0-9][0-9][0-9][0-9]’ Example: PA0001 c. Payment Date should be less than or equal to the start date of the event. d. Payment Date cannot be less than the current date. e. If the payment method is ‘Credit Card’, then it needs to be ensured that the credit card details are entered for a new record being inserted into the table. If the payment is not being done using a credit card, it must be ensured that the credit card details are blank. f. The Expiry date for the credit card should be greater than the current date. g. The Payment Amount must be compared with the fee given in the Fee Schedule table for a given fee schedule ID and event ID. If the two values match, the transaction is successful, else it needs to be rejected. h. The Payment Amount must be greater than 0. Table: Attendees a. Attendee ID must be unique. b. Attendee ID must be auto generated. c. FirstName, LastName, Address, City, State, Phone should not be left blank. d. The Phone should be in the following format: ‘[0-9][0-9]-[0-9][0-9][0-9]-[0-9][0-9][0-9]’ Example: 21-123-122 Table: FeeSchedules a. Fee Schedule ID must be unique. Implementing Database Design 1.24 b. Fee Schedule ID must be auto generated. c. Fee Schedule Description should not be left blank. d. Fee Amount should be greater than 0. Table: EventTypes a. Event Type ID must be unique. b. Event Type ID must be auto generated. c. Description should not be left blank. 4. Create appropriate relationships between the tables. 5. You need to ensure that an event record is deleted from the Events table only after all the records from the dependant tables are deleted. 6. The details of all the employees who have managed an event in the current month need to be stored in a text file. This information will be displayed on the organization’s website. Make use of the required tools to perform the data transfer. 7. The users of the database need to perform the following queries frequently: a. Extracting the attendee details for an event organized on a particular date. b. Displaying the fee schedule details for all events organized by the organization. c. Extracting event details for all the events where the payment is pending. d. Displaying the details of all the events where the staffing required is greater than 25. Based on the above queries, create the appropriate indexes to speed up the execution of queries and joins. 8. The entire database should be created using SQL scripts. This will help to ensure that the database and its objects can be recreated in minimum possible time in event of a database crash. 1.25 Implementing Database Design CASE STUDY 3: NEW PROJECT LTD Background New Project Ltd is a company that provides staff on contract for various project assignments. The company is known for providing qualified and skilled staff that can fulfill the project requirements efficiently. New Project employs professionals from various fields that match the requirement of clients. Existing System New Project has a system of time cards. Time cards are issued to its employees for working at the client site until the completion of the project. The employees use their time cards for all work processes and expenses during the contract period. The time card data enables New Project to prepare the final billing that needs to be submitted to the clients for release of payment in lieu of work. When a work agreement is signed, a project form needs to be filled out. The format of this form is as follows: PROJECT FORM CLIENT SECTION Client code: Address: Contact Person: PROJECT SECTION Project code: Project Description: Start Date: EMPLOYEE SECTION Employee code: Address: Work Phone: Employee Name: Country: Billing Rate: Project Name: Estimate Bill: End Date: Company Name: Country: Phone: Implementing Database Design 1.26 The client details are stored in the Clients file, the project details are stored in the Projects file, and the employee details are stored in the Employees file. The next form that needs to be filled out is the Time Card Details form. The format of the form is as follows: TIME CARD DETAILS Time Card code: EXPENSES DETAILS Time Card Expense code: Expense code ID: Expense Date: WORK DETAILS Work code ID: Work Description: Project code: BILL SECTION Billed Hours: Billing Rate: Work code: Work date: Expense Description: Expense code: Expense amount: Employee code: All employees fill the time card details on a daily basis. These details include Time Card ID, Employee ID, Date Issued, Date Worked, Project ID, Work Description, Billable Hours, and Work Code ID. The staffing-in-charge of New Project stores these details in the Time Cards file. The work code Id defines the category of the task performed by the employee in the project. The details related to the work codes are stored in the Work Codes file which includes details such as work code id and work code description. During the project life cycle, employees might also incur expenses due to conveyance, food etc. The details of the expenses incurred by an employee in a project are stored in the Time Card Expenses file. These details include time card expense id, time card id, expense date, expense amount, expense description, project id, expense code id, and expense code. After every project, the company calculates its payment due from the client and raises an invoice. On realization of the payment, all related data is stored in the Payments file. This file contains data about payment code, payment mode ID, payment mode name, corresponding project code, payment amount, payment date, and credit card details if the client pays through credit card. Credit card details consist of card number, cardholder’s name, and expiry date of the credit card. 1.27 Implementing Database Design Envisioned System The management decided that manually maintaining such records was a cumbersome process. It also gave rise to data redundancy and record duplication. Therefore, to streamline the entire process, the best solution was to create databases and convert the manual process to computerized process. An in-house development team has been created to work on the project of computerizing the staffing process of New Project Ltd. The development team has: 1. Identified the various entities involved. 2. Identified the attributes of the various entities. The attributes should completely define the entities. 3. Drawn an E/R diagram to demonstrate the relationship between the various entities. 4. Mapped the E/R diagram to tables. 5. Normalized the tables to 3 NF. The normalized tables should have: a. Table names b. Field names, datatypes, and size of fields c. Primary and foreign key identification and integrity 6. Drawn a diagram to show the relationships between various tables. The final relationship diagram created by the project team is as follows: Implementing Database Design 1.28 Relationship Diagram for the New Project Database Management System INSTRUCTOR NOTES The various steps involved in creation of the relationship diagram are as follows: Identifying Entities The entities for the New Project database management system are: 1. Employees 2. Projects 3. Clients 1.29 Implementing Database Design 4. Time Cards 5. Work Codes 6. Time Card Expenses 7. Payments Identifying Attributes The attributes of the entities listed above are as follows: 1. Employees: Employee ID, First Name, Last Name, Title, Phone, Billing Rate 2. Projects: Project ID, Project Name, Project Description, Client ID, Billing Estimate, Employee ID, Start Date, End Date 3. Clients: Client ID, Company Name, Address, City, State, Zip, Country, Contact Person, Phone 4. Time Cards: Time Card ID, Employee ID, Date Issued, Date Worked, Project ID, Work Description, Billable Hours, Work Code ID 5. Work Codes: Work Code ID, Work Code Description 6. Expenses: Time Card Expense ID, Time Card ID, Expense Date, Project ID, Expense Description, Expense Amount, Expense Code ID, Expense Code 7. Payments: Payment ID, Project ID, Payment Amount, Payment Date, Credit Card No, Card Holder Name, Expiry Date, Payment Method ID, Payment Method Implementing Database Design 1.30 Drawing the E-R Diagram EMPLOYEES 1 PAYMENTS 1 WORKS ON m FILLS MADE FOR 1 TIME CARDS 1 m RECORDED IN EXPENSES m m 1 PROJECTS 1 m GIVES 1 CLIENTS FOR Normalizing tables The tables that will be created in the database are as follows: Employees Employee ID First Name Last Name Title Phone Billing Rate Projects Project ID Project Name Project Description Client ID Billing Estimate Start Date End Date Employee ID Clients Client ID Company Name Address City State Country Zip Contact Person Phone 1.31 Implementing Database Design Time Cards Time Card ID Work Codes Work Code ID Time Card Expenses Time Card Expense ID Time Card ID Expense Date Expense Amount Expense Code ID Expense Code Project ID Expense Description Employee ID Date Issued Date Worked Project ID Work Description Billable Hours Work Code ID Total Cost Work Code Description Payments Payment ID Payment Date Payment Amount Project ID Credit Card No Card Holder Name Expiry Date Payment Method ID Payment Method Normalizing tables to 1NF The tables are already in 1NF. Implementing Database Design 1.32 Normalizing tables to 2NF For 2 NF, the tables Employees, Clients, Projects, Work Codes, Expenses, and Payments will not change as they are already in 2 NF. In the Time Cards table, Time Card ID, Employee ID, and Project ID comprise a composite key. The Date Worked, Billable Hours, Work Description, Work Code ID depend only on Project ID and Time Card ID and not the Employee ID. Therefore, we need to create another table, Time Card Hours. Now, the tables are as follows: Employees Employee ID First Name Last Name Title Phone Billing Rate Projects Project ID Project Name Project Description Client ID Billing Estimate Start Date End Date Employee ID Clients Client ID Company Name Address City State Country Zip Contact Person Phone Time Cards Time Card ID Employee ID Date Issued Work Codes Work Code ID Work Code Description Time Card Expenses Time Card Expense ID Time Card ID Expense Date Expense Amount Expense Code ID Expense Code Project ID Expense Description 1.33 Implementing Database Design Payments Payment ID Payment Date Payment Amount Project ID Credit Card No Card Holder Name Expiry Date Payment Method ID Payment Method Time Card Hours Time Card Detail ID Time Card ID Project ID Date Worked Work Description Work Code ID Billable Hours Total Cost Normalizing tables to 3NF In the Payments table, the attribute Payment Method depends on Payment Method ID and not on the Payment ID. Similarly, in the Time Card Expenses table, the attribute Expense Code depends on the Expense Code ID and not on the Time Card Expense ID. Therefore, for the tables to be in 3 NF, we need to create two more tables, Payment Methods and Expense Codes. Implementing Database Design 1.34 Employees Employee ID First Name Last Name Title Phone Billing Rate Projects Project ID Project Name Project Description Client ID Billing Estimate Start Date End Date Employee ID Clients Client ID Company Name Address City State Country Zip Contact Person Phone Time Cards Time Card ID Employee ID Date Issued Work Codes Work Code ID Work Code Description Time Card Expenses Time Card Expense ID Time Card ID Expense Date Expense Amount Expense Code ID Expense Code Project ID Expense Description Payments Payment ID Time Card Hours Time Card Detail ID 1.35 Implementing Database Design Payments Payment Date Payment Amount Project ID Credit Card No Card Holder Name Expiry Date Payment Method ID Payment Method Time Card Hours Time Card ID Project ID Date Worked Work Description Work Code ID Billable Hours Total Cost Payment Methods Payment Method ID Payment Method Description Expense Codes Expense Code ID Expense Code Description To create the computerized time card management system for New Project Ltd., the development team needs to perform the following tasks: 1. Create a database, TimeCard. 2. Create the table designs as per the relationship diagram ensuring minimum disk space utilization. 3. The validations to be performed on the tables are as follows: Table: Clients a. Client-ID must be auto generated. b. Client-ID must be unique. c. CompanyName, Contact Person, Address, City, and Phone should be mandatory. d. The phone number must be in the following format, (000)-(000)-(0000). Table: Employees a. Employee ID must be auto generated. b. Employee ID must be unique. Implementing Database Design 1.36 c. Title must be any one of the following, ‘Trainee’, ‘Team Member’, ‘Team Leader’, ‘Project Manager’, ‘Senior Project Manager’. d. Billing Rate should be greater than 0. e. First Name and Phone should not be left blank. f. The phone number must be in the following format, (000)-(000)-(0000). Table: Projects a. b. c. d. e. Project ID should be unique. Project ID should be in the format ‘P[0-9][0-9][0-9]’. Project Name, Start Date, and End Date should not be left blank. The Billing Estimate should be greater than 1000. The start date should be less than the end date. Table: PaymentMethods a. The Payment Method ID should be in the format ,’PM [0-9][0-9][0-9]’ b. The Payment Description cannot be blank. c. The Payment Method Id should be unique. Table: Payments a. b. c. d. e. The Payment Id should be auto generated. The payment id should be unique. The payment amount should be greater than 0. The payment date should be greater than the end date of the project. If the payment method is not ‘Credit Card’, the credit card details should be null. f. If the payment method is ‘Credit Card’, the Expiry date of the card should be greater than the payment date. g. If the payment method is ‘Credit Card’, ensure that the credit card details are not blank. Table: WorkCodes a. The Work Code Id should be auto generated and unique. b. The Description cannot be left blank. Table: ExpenseCodes a. The Expense Code ID should be auto generated and unique. b. The Description should not be blank. Table: TimeCards a. The Time Card ID should be unique. b. The Time Card ID should be auto generated. c. The Date of issue of the time card should be greater than the current date and the project start date to which the employee is assigned. Table: TimeCardHours a. The Date worked should be greater than the project start date. b. The Date worked cannot be left blank. c. The Time card detail id should be unique and auto generated. 1.37 Implementing Database Design d. The Total Cost should be automatically calculated using the formula (Billable Hours * Billing Rate for the employee to whom the time card is issued.) e. Billable hours should be greater than 0. Table: TimeCardExpenses a. b. c. d. The The The The Time Card Expense Id should be auto generated and unique. Expense date should be less than the project end date. Expense amount should be greater than 0. Expense date cannot be left blank. 4. Create appropriate relationships between the tables. 5. The payment details of each client need to be documented and saved in a text file. 6. The users of the database need to perform the following queries frequently: a. Extracting the time card details for a employee based on employee names. b. Extracting the expense details for all employees with time card ids in a given range. c. Displaying the name of an employee with the list of all projects that he is working on. d. Extracting a list of all projects that need to be completed in the current month. Based on the above queries, create the appropriate indexes to speed up the execution of queries and joins. 7. You need to create a report displaying the projects and the details of the employee assigned to a project in the following format: Project ID: ………… Project Name: ………… Employee Name: ………… Employee Title: ………… 8. The entire database should be created using SQL scripts. This will help to ensure that the database and its objects can be recreated in minimum possible time in event of a database crash. Implementing Database Design 1.38 PROJECT EXECUTION This book contains three case studies. These case studies will be allocated to individual students. Phases in Project Execution The project will be carried out in the following phases: System Analysis: System analysis refers to an in-depth study of the existing system to depict the functionality of the system. The analysis phase is the most crucial phase in a project because it helps developers to identify the processes in the system and functioning of each process. The project teams will analyze their respective case studies before moving on to the development phase. Development: This phase involves developing the project based on the specifications. Testing and debugging: This phase involves testing the project before submitting it to the coordinator. Documentation: Documentation is one of the most important aspects of computer programming. The project documentation should be submitted to the coordinator in the formats given in this book before the project walkthrough. The blank report following the case studies is to be filled up, detached from the book, and submitted on the given date. Project Evaluation Guidelines The project is to be evaluated based on the following parameters: Quality: Conformance to requirements of the case study – 20 marks The solution maps to the requirements specified along with the case study Timeliness - 20 marks Timely completion of the project Quality of documentation - 40 marks Completion of all formats Adherence to standards and processes Query handling during project walkthrough - 20 marks 1.39 Implementing Database Design Project Standards and Guidelines The following standards and guidelines should be followed while creating the project. Following these standards and guidelines is one of the evaluation criteria for the project: A consistent naming convention should be used for all database objects. Fields in a table should not have a “.” character. Project Activities The students will get 16 hours to complete the project. The activities to be performed during this period are: a. b. c. d. Analyze the case study to identify the system processes. Create the design of the database objects. Test the tables with three or four records. Debug the tables, stored procedures, triggers, and transactions in case of any errors. e. Document the project by using the formats given in the later section. f. Submit the documentation to the faculty. g. After submitting the documentation, the student will present the project to the faculty. The faculty will assign marks to the student based on the evaluation criterions specified in this section. Project Timelines The students should follow the given timelines to complete the project on time: Session # 1 2 Task to be Performed Analyze the case study and create the table design with appropriate fields and their datatypes. Create and execute the database creation script. Refer to the sample script ‘CreatePayJunctionDB.sql’ for help. Create the tables by applying the appropriate constraints. 3 4 5 Create the table creation scripts. Create the script which is used to enter sample records into the database. According to the validations, create the appropriate Implementing Database Design 1.40 Session # Task to be Performed stored procedures, triggers, and transactions. 6 7 8 Test the stored procedures, triggers, and transactions as per the requirements of the project. Create the appropriate indexes for the tables as per the queries defined in the requirements. Perform final validations and document the project. 1.41 Implementing Database Design SAMPLE CASE STUDY 4: PAY JUNCTION Background Pay Junction is a company that performs order processing and manages payment realizations for other organizations. Existing System Pay junction maintains separate files for storing customer details and order details. The Customer Details file consists of records such as customer code, customer name, company name, address, country, phone number, and billing address. When an order is processed, various parameters that affect the order are filled in a form and then analyzed. The format of the Order Processing form is shown below: ORDER PROCESSING Order code: Customer code: Employee Code: Product Name: Discount: SHIPMENT DETAILS Shipment Name: Shipping Country: Shipping Date: Shipping Method: Tax: Total Amount: The data related to the order and shipment is transferred from the Order Processing form to the Orders file. The data related to the products ordered is stored in the Products file. Shipping Address: Contact Phone: Shipping Method ID: Freight Charges: Order Details Code: Order Date: Product code: Quantity: Implementing Database Design 1.42 The payments for orders are accepted through cash or credit card. When the customer makes the payment, the Payments file is updated with the data about payment code, order code, payment amount, payment date, payment mode ID, payment mode, and credit card details if the customer pays through a credit card. The credit card details consist of card number, cardholder’s name, and card expiry date. Envisioned System Pay Junction has decided to stop manual data storage and start computerized database management and order processing. It would also enable the company to have quicker communication with the clients. A small group of database designers have been deployed by Pay Junction to develop a computerized system of order processing and database management. Pay Junction also wants to include the information about an employee who processes an order. This information will include the employee code, name, title, and phone number. The development team has: 1. Identified the various entities involved. 2. Identified the attributes of the various entities. The attributes should completely define the entities. 3. Drawn an E/R diagram to demonstrate the relationship between the various entities. 4. Mapped the E/R diagram to tables. 5. Normalized the tables to 3 NF. The normalized tables should have: a. Table names b. Field names, datatypes, and size of fields c. Primary and foreign key identification and integrity 6. Drawn a diagram to show the relationships between various tables. The final relationship diagram created by the project team is as follows: 1.43 Implementing Database Design Relationship Diagram for the Pay Junction Database Management System To create the computerized system, the team needs to perform the following tasks: 1. Create a database, PayJunction. 2. Create the table designs as per the relationship diagram ensuring minimum disk space utilization. 3. The validations to be performed on the tables are as follows: Table: Customers a. Cust_Id must be unique. b. Cust_Id must be auto generated. c. The FirstName, LastName, Address, City, State, and Phone should not be left blank. d. The phone number should be entered in the format, 0000-000-000. Table: Employees a. Emp_Id must be unique. Implementing Database Design 1.44 b. Auto generation on the Emp_Id column. c. The phone number should be in the format, 0000-000-000. d. The Title must be in the list, ‘Executive’, ’Senior Executive’, ‘Manager’, ’Chairman’. e. The FirstName and LastName fields should not be left blank. Table: Products a. b. c. d. Product_Id must be unique. The product id must be of the format, ‘P[0-9][0-9][0-9]’ The Unit Price should be greater than 0. The Product name, description and price should not be left blank. Table: PaymentMethods a. PaymentMethod_Id must be unique. b. The payment method id must be of the format, ‘PM[0-9][0-9][0-9]’ c. The description should not be left blank. Table: ShipmentMethods a. ShipmentMethod_Id must be unique. b. The shipment method id must be of the format, ‘SH[0-9][0-9][0-9]’ c. The description should not be left blank. Table: Orders a. Order_Id must be unique. b. The order id must be of the format, ‘O[0-9][0-9][0-9]’ c. The shipment name, shipment address, shipment city, shipment state, shipment phone, shipment country, shipment date, freight charge, and tax should not be left blank. d. The shipment phone should be in the format, ‘[0-9][0-9][0-9][0-9]-[09][0-9][0-9]-[0-9][0-9][0-9]’ e. The Order date should not greater than the current date. f. If the order date is not entered, the current date should be taken as the default order date. g. Freight charge must be greater than 0. h. Tax should be greater than 0. i. When an insertion is made into the Orders table, an insertion should be made into the OrderDetails table. The insertion should take place only after all the values in the Orders table have been validated. j. The Shipment Date cannot be greater than the order date. Table: OrderDetails a. b. c. d. e. OrderDetail_Id must be unique. Auto generation of OrderDetail_Id. The quantity and discount should not be left blank. The Total cost should be calculated automatically and added to the total cost field. The Quantity should be greater than 0. 1.45 Implementing Database Design Table: Payments a. b. c. d. Payment_Id must be unique. Auto generation of Payment_Id. The payment amount should be greater than 0. The payment amount should be equal to the sum of the total costs for a given order id in the OrderDetails table. If the amounts do not match, the transaction should be rejected and a user-friendly message should be displayed to the user. e. The shipment date should be updated to two days after the payment date if the transaction is successful. f. The payment date should be greater than the order date. g. The Credit card number must be in the following format, ‘[0-9][0-9][0-9][0-9][0-9][0-9][0-9]-[0-9][0-9][0-9]’. h. The payment amount and payment date fields should not be left blank. i. If the payment method is ‘Credit Card’, ensure that the credit card details are not blank. j. If the payment method is not ‘Credit Card’, ensure that the credit card details are blank. k. The Expiry date for the credit card should be greater than the current date. 4. Create appropriate relationships between the tables. 5. A yearly sales report needs to be sent to each customer displaying their order details in the current year. Make use of the required tools to perform the data transfer. 6. The order details for a given customer id need to be stored in a text file. Make use of the required tools to perform the data transfer. 7. The users of the database need to perform the following queries frequently: a. Extracting order details of the orders placed on a particular date along with the product details. b. Extracting for all orders whose payments are pending. c. Displaying the customer details for all customers living in a particular city. d. Displaying the customer details for all customers with a given first name and last name. 8. The entire database should be created using SQL scripts. This will help to ensure that the database and its objects can be recreated in minimum possible time in event of a database crash. Implementing Database Design 1.46 SOLUTION TO CASE STUDY 4 – PAY JUNCTION To create the PayJunction database and its objects, you need to make use of the SQL Scripts provided in the TIRM CD. 1. CreatePayJunctionDatabase.sql: The script contains the code for creating a database. It removes the database if it already exists in SQL Server. 2. CreatePayJunctionObjects.sql: The script contains the statements required to create the tables of the database. It also contains statements used to insert sample records into the tables. 3. CreatePayJunctionConstraints.sql: The script contains the SQL statements used for creation of constraints, rules, and defaults as per the validations required. 4. CreatePayJunctionProcedures.sql: The script contains the batch statements that create the generic procedures and triggers in the database. 5. CreatePayJunctionIndexes.sql: The script contains the SQL statements used to create indexes to speed up the execution of the frequently used queries. 6. CreatePayJunctionForBCPandDTS.sql: The script contains the SQL queries used to retrieve the data to be transferred to external applications using BCP and DTS. 7. ErrorDetectionForProceduresandTriggers.sql: The script contains statements which test the database objects for validity. 1.47 Implementing Database Design SAMPLE PROJECT DOCUMENTATION: PAY JUNCTION PROJECT ON Pay Junction Database Management System Developed by Name: Debbie Howe Reg. No.: 4701-10-258 Implementing Database Design 1.48 Pay Junction Database Management System (Project Title) Batch Code Start Date End Date Name of the Coordinator Name of Developer Date of Submission : B010101 : June 1, 2003 : June 10, 2003 : Alex Norton : Debbie Howe : June 11, 2003 1.49 Implementing Database Design CERTIFICATE This is to certify that this report titled Pay Junction Database Management System embodies the original work done by Debbie Howe in partial fulfillment of their course requirement at NIIT. Coordinator: Alex Norton Implementing Database Design 1.50 ACKNOWLEDGEMENT We have benefited a lot from the feedback and suggestions given to us by Mr. Alex Norton and other faculty members. 1.51 Implementing Database Design SYSTEM ANALYSIS System Summary: Pay Junction is a consultancy firm that manages order processing and payment realizations for any organization. The company has decided to stop manual data entry. Instead, it has decided to make use of a computerized database management for processing orders and payment realizations. This would enable the company to have quicker communication with the clients. Implementing Database Design 1.52 DATABASE DESIGN Database Name: PayJunction Number of tables: 8 Table Names: 1. Customers 2. Employees 3. Products 4. PaymentMethods 5. ShipmentMethods 6. Orders 7. OrderDetails 8. Payments 1.53 Implementing Database Design SCHEMATIC DIAGRAM OF DATABASE Database Name: PayJunction Schematic diagram of the database depicting the primary and foreign key relationships. Implementing Database Design 1.54 TABLE DESIGN Database Name: PayJunction Customers Field Name Cust_Id First Name Last Name Address City State Zip Country Phone Data type int varchar varchar varchar varchar varchar char varchar char Width Description Customer Number 30 30 50 30 30 10 20 20 Customer First Name Customer Last Name Customer Address Customer City Customer State Zip Code Customer Country Phone Number 1.55 Implementing Database Design Employees Field Name Emp_Id First Name Last Name Title Phone Data type Width Description int varchar varchar varchar char 30 30 30 20 Employee Number Employee First Name Employee Last Name Employee Designation Phone Number PaymentMethods Field Name PaymentMethod_Id PaymentMethodDesc Data type char varchar Width 5 30 Description Payment Method Number Payment Method Description Implementing Database Design 1.56 ShipmentMethods Field Name ShipmentMethod_Id Data type char Width 5 Description Shipment Method Number Shipment Method Description ShipmentMethodDesc varchar 30 Products Field Name Product_Id Prod_Name Prod_Desc UnitPrice Data type char varchar varchar money Width 4 30 50 Description Product Number Name of the product Description of product Cost of the product 1.57 Implementing Database Design OrderDetails Field Name OrderDetail_Id Order_Id Product_Id Quantity Discount Data type int char char int smallint Width Description Order Detail Number 4 4 Order Number Product Number Quantity of the product bought Discount on the payment amount (Quantity * Unit Price) + Tax * (Quantity * Unit Price) + Freight Charge – Discount * (Quantity * Unit Price) TotalCost money Implementing Database Design 1.58 Payments Field Name Payment_Id Order_Id Payment Amount Data type int char money 4 Width Description Payment Number Order Number Amount paid for the order Date of payment 5 Payment Method Number Credit Card Number Credit card holder’s name Expiry Date of the credit card Payment Date PaymentMethod_Id datetime char CreditCardNo char 20 CardHolderName varchar 30 ExpiryDate datetime 1.59 Implementing Database Design Orders Field Name Order_Id Cust_Id Emp_Id ShipmentMethod_Id OrderDate Data type char int int char datetime Width 4 Description Order Number Customer Number Employee Number 5 Shipment Method Number Date when the order was placed ShipName varchar 30 Name of the parcel to be shipped Place for shipment Shipment City Shipment State Shipment Country Shipment Phone Date of the shipment Shipping charges Tax applied on the payment ShipAddress ShipCity ShipState ShipCountry ShipPhone ShipDate Freight Charge Tax varchar varchar varchar varchar char datetime money smallint 30 30 30 20 20 Implementing Database Design 1.60 VALIDATIONS PERFORMED Customers Validation Required Method Used For Validation Cust_Id must be unique. Cust_Id must be auto generated. Primary key constraint Stored Procedure and batch programming NOT NULL clause in the CREATE TABLE statement CHECK constraint The FirstName, LastName, Address, City, State, and Phone should not be left blank. The phone number should be entered in the format, 0000-000000. Employees Validation Required Method Used For Validation Emp_Id must be unique. Auto generation on the Emp_Id column. The phone number should be in the format, 0000-000-000. The Title must be in the list, ‘Executive’, ’Senior Executive’, ‘Manager’, ’Chairman’. The FirstName, LastName, Title, and Phone fields should not be left blank. Primary key constraint Stored Procedure and batch programming CHECK constraint CHECK constraint NOT NULL clause in the CREATE TABLE statement 1.61 Implementing Database Design Products Validation Required Method Used For Validation Product_Id must be unique. The product id must be of the format, ‘P[0-9][0-9][0-9]’ The Unit Price should be greater than 0. The Product name, description and price should not be left blank. Primary Key constraint CHECK constraint Rule NOT NULL clause in the CREATE TABLE statement PaymentMethods Validation Required Method Used For Validation PaymentMethod_Id must be unique. The payment method id must be of the format, ‘PM[0-9][0-9][0-9]’ The description should not be left blank. Primary Key constraint Rule NOT NULL clause in the CREATE TABLE statement Implementing Database Design 1.62 ShipmentMethods Validation Required Method Used For Validation ShipmentMethod_Id must be unique. The shipment method id must be of the format, ‘SH[0-9][0-9][09]’ The description should not be left blank. Primary Key constraint Rule NOT NULL clause in the CREATE TABLE statement Orders Validation Required Method Used For Validation Order_Id must be unique. The order id must be of the format, ‘O[0-9][0-9][0-9]’ The shipment name, shipment address, shipment city, shipment state, shipment phone, shipment country, shipment date, freight charge, and tax should not be left blank. The shipment phone should be in the format, ‘[0-9][0-9][0-9][0-9][0-9][0-9][0-9]-[0-9][0-9][0-9]’ The Order date should not be greater than the current date. If the order date is not entered, the current date should be taken as the default order date. Freight charge must be greater than 0. Primary Key constraint CHECK constraint NOT NULL clause in the CREATE TABLE statement Rule Trigger Default CHECK constraint 1.63 Implementing Database Design Validation Required Method Used For Validation Tax should be greater than 0. When an insertion is made into the Orders table, an insertion should be made into the OrderDetails table. The insertion should take place only after all the values in the Orders table have been validated. The Shipment Date cannot be greater than the order date. CHECK constraint Stored Procedure and batch programming Trigger OrderDetails Validation Required Method Used For Validation OrderDetail_Id must be unique. Auto generation of OrderDetail_Id. Primary Key constraint Stored Procedure and batch programming NOT NULL clause in the CREATE TABLE statement Trigger The quantity and discount should not be left blank. The Total cost should be calculated automatically and added to the total cost field. The Quantity should be greater than 0. Rule Implementing Database Design 1.64 Payments Validation Required Method Used For Validation Payment_Id must be unique. Auto generation of Payment_Id. The payment amount should be greater than 0. The payment amount should be equal to the sum of the total costs for a given order id in the OrderDetails table. If the amounts do not match, the transaction should be rejected and a user-friendly message should be displayed to the user. The shipment date should be updated to two days after the payment date if the transaction is successful. The payment date should be greater than the order date. The Credit card number must be in the following format, ‘[0-9][0-9][0-9]-[09][0-9][0-9][0-9]-[0-9][0-9][0-9]’. The payment amount and payment date fields should not be left blank. If the payment method is ‘Credit Card’, ensure that the credit card details are not blank. Primary Key constraint Stored Procedure and batch programming CHECK constraint Triggers, Aggregate Functions, and Joins Trigger and Update statement Trigger and batch programming CHECK constraint NOT NULL clause in the CREATE TABLE statement Trigger If the payment method is not ‘Credit Card’, ensure that the credit card details are blank. The Expiry date for the credit card should be greater than the current date. Trigger Trigger 1.65 Implementing Database Design REPORTS OUTLINE Report Name Report Type Description Tables/Queries Used OrderDetails, Orders, and Customers Customer Report Text File This report displays the order details such as the Order Detail Id, Order Id, Product Name, Unit Price, Freight Charge, Tax, Discount, Total Cost, and Quantity for a given customer id. This report displays the Order_Id and the cumulative cost for the order for the customer in the current year. Yearly Sales Report Excel Sheet OrderDetails, Orders, and Customers Implementing Database Design 1.66 CONFIGURATION Hardware: PC compatible with a Intel Pentium-III processor, 128-MB RAM, and 20GB of Hard disk Operating system: Windows 2003 Server Software: Microsoft SQL Server 2000 Enterprise Edition PROJECT FILE DETAILS S.No 1 File Name PayJunction.mdf PayJunction_log.ldf Remarks SQL Server database that contains tables, procedures, triggers, constraints, and queries. 1.67 Implementing Database Design BLANK DOCUMENTATION FORMATS PROJECT ON Developed by Name: Reg. No.: Implementing Database Design 1.68 (Project Title) Batch Code Start Date End Date Name of the Coordinator Name of Developer Date of Submission : : : : : : 1.69 Implementing Database Design CERTIFICATE This is to certify that this report titled __________ embodies the original work done by ___________ in partial fulfillment of their course requirement at NIIT. Coordinator: Implementing Database Design 1.70 ACKNOWLEDGEMENT 1.71 Implementing Database Design SYSTEM ANALYSIS System Summary: Implementing Database Design 1.72 DATABASE DESIGN Database Name: No of Tables: Name of Tables: 1.73 Implementing Database Design SCHEMATIC DIAGRAM OF DATABASE Database Name: Schematic diagram for the database depicting the primary and foreign key relationships. Implementing Database Design 1.74 TABLE DESIGN Database Name: Table Name: 1.75 Implementing Database Design VALIDATIONS PERFORMED Implementing Database Design 1.76 REPORTS OUTLINE Report Name Report Type Description Tables/Queries Used 1.77 Implementing Database Design CONFIGURATION Hardware: Operating System: Software: PROJECT FILE DETAILS S.No File Name Remarks Implementing Database Design 1.78