SADM 7/Ed ESSS CASE STUDY - Milestone 4: Solution Page: 4-1

SADM 7/ed – ESSS CASE STUDY - Milestone 4: Solution Page: 4-1

MILESTONE 4 – DATA MODELING

 Activity 1 – Entity/Definition Matrix he entities in the following matrix were identified by analyzing the forms provided in Milestone 4. This list and the following diagrams are based on the author’s assumptions and Tinterpretations. If you, the instructor, choose to do your own solution, it may be different, depending on your interpretation of the forms provided. In most activities explanations for why things were done as they were have been provided to aid in your understanding of the solution.

Prepared by Gary B. Randolph for Systems Analysis & Design Methods 7ed by J. L. Whitten, L. D. Bentley, & K.C. Dittman Copyright Irwin/McGraw-Hill 2007 SADM 7/ed – ESSS CASE STUDY - Milestone 4: Solution Page: 4-2

Students should be able to identify at least the major entities listed below. Whether or not they identify the optional entities will depend on how they interpret the user requirements and on their experience level with database normalization. The following completed matrix is one possible solution.

Entity/Definition Matrix

ENTITY BUSINESS DEFINITION Major Entities Employee Any individual who is currently on active payroll or is a recipient of any company benefits. MiscDeduction A payroll deduction that can be specified by employees. UnitedWayContribution An order submitted by employees to have a charitable contribution deducted from their payroll. EmergencyContact Any individual who is specified by the employee as the person(s) to contact in case of an emergency. Optional Entities Department An organizational unit within the company to categorize employees. Site A geographic location where the company has a vested interest and conducts business in some fashion. Building A facility that exists on a site. MailStop A location within a building where all intra-company and external mail is delivered and picked up. Room A unique location area within a building. More than one employee may be located in a room. SalaryEmployee An employee paid by salary. HourlyEmployee An employee paid by hourly wages. ContractEmployee A temporary employee.

 Activity 2 – Context Data Model his model should be constructed based on the entities identified in Activity 1. All of the cardinalities of the major entities can be determined from the interview or the forms. The Tstudent may need to make assumptions on the cardinalities of the optional entities or other entities the student may include.

The following diagram is based on the following assumptions and/or business rules:  The Employee, SalaryEmployee, HourlyEmployee, and ContractEmployee entities compose a generalization hierarchy. Students may identify it here or only in the fully attributed data model. There are several clues in the interview to establish its existence.  Each Employee works in a Department and a Department employs one or more Employees.  Every Employee has zero or more EmergencyContacts.  Site, Building, Room, and MailStop could be setup just as attributes in the Employee entity. However, by making them separate entities we can assure that spelling is consistent for all records and provide the user interface with dropdown controls to lookup the values. The interview contains clues that this is the preferred method.  An Employee will make zero or more UnitedWayContributions (zero or one each year).  An Employee will specify one or more MiscDeductions. Every hourly and salary employee must specify MiscDeductions at least once when they first hire in, and they can change them at any time. But contract employees do not have MiscDeduction records.

 Activity 3 – Key-Based Data Model his model is constructed by adding the primary keys to the model in Activity 2. The primary keys are based on how the user uniquely identifies each entity. Make sure students specify Tprimary keys that uniquely identify the entities as well as use proper names for the keys. The following diagram illustrates one possible solution.

 This diagram was created in Microsoft Visio. Primary keys are shown at the top of the list of attributes and marked with PK. Foreign keys are marked with FK and a number.  The Employee, SalaryEmployee, HourlyEmployee, and ContractEmployee entities generalization hierarchy entities must all have the same primary key. All the forms use and employee ID.  Because the same employee directory shows two buildings with the same room numbers, Room must use RoomNum and RoomBldgID as the primary key.  Similarly, two or more buildings could feasibly have the same mail stop IDs. So MailStop must use MailStop and MailStopBldgID as a primary key.  The EmergencyContact entity has a concatenated primary key. A case could be made for building an auto-sequencing ContactID. However, since this entity is not a parent to any other entities, there is no compelling need for a non-concatenated primary key. The simplicity of using a naturally-occurring primary key is appealing. ContactEmpID must be included in the primary key in case multiple employees want to use the same emergency contact.  UnitedWayContribution requires a concatenated primary key because an employee will have a separate contribution record for each year.  MiscDeduction requires a concatenated primary key because an employee could have multiple records over time.

 Activity 4 – Fully Attributed Data Model his model should be constructed by adding non-key attributes to the entities in Activity 3. Since students’ models are not necessarily normalized, attributes could be placed in various Tentities. But make sure each non-key attribute exists in only one entity. Students may also include other attributes based on their interpretations of the users’ needs.

The diagram below includes foreign keys, assuming implementation in a relational database. Subject to interpretation, this diagram is in third normal form, which is the bulk of the assignment for Milestone 5. If you will be doing Milestone 5 as a separate assignment, you may want to withhold this solution. An attractive alternative is to have students analyze and critique each other’s Fully Attributed Data Models in small groups to refine the normalization. Another alternative is to start with this data model for Milestone 5 but add additional requirements, such as the Milestone 4 Advanced Option and require that students revise the data model accordingly.

 This diagram was created in Microsoft Visio. Primary keys are shown at the top of the list of attributes and marked with PK. Foreign keys are marked with FK and a number.  The Employee entity includes EmpMiddlename, EmpNickname, and EmpHireDate, which were mentioned in the interview though not on the forms.  The EmpSup attribute in Employee is actually a foreign key to the EmpID of other records in Employee. This self-join is fairly advanced for students to detect and setup unless they have prior database design experience or were drilled on this kind of relationship. It is, however, the best and easiest way to implement employees and supervisors in a database.  The entities that have concatenated primary keys and are also parent entities (MailStop and Room) must contribute both primary keys to child entities (Room and Employee) as foreign keys.  In MiscDeduction, beginning data designers will be tempted to have fields for each of the various kinds of deductions. That is ultimately a bad idea because deductions will surely change over time. With a little thinking, attributes such as these can be devised that will work for essentially any kind of deduction.

 Advanced Option – Revised Attributed Data Model If the system must also track out-of-pocket medical expenses, you would most likely add an entity called MedicalExpenses. It would have attributes for date, employee, doctor, and description. It would have a relationship to Employee, such that one employee could have many expenses. It would not need a relationship to MiscDeduction.

Instructor Notes:

Prepared by Gary B. Randolph for Systems Analysis & Design Methods 7ed by J. L. Whitten, L. D. Bentley, & K.C. Dittman Copyright Irwin/McGraw-Hill 2007