System analysis and design
| COMMONWEALTH OF AUSTRALIA Copyright Regulation 1969 WARNING This material has been copied and communicated to you by or on behalf of Curtin University of Technology pursuant to Part VB of the Copyright Act 1968 (the Act) The material in this communication may be subject to copyright under the Act. Any further copying or communication of this material by you may be the subject of copyright protection under the Act. Do not remove this notice |
Chapter 4
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved.
2
2
Domain Modeling
Systems Analysis and Design in a Changing World 7th Ed
Satzinger, Jackson & Burd
Chapter 4
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved.
3
Chapter 4 Outline
“Things” in the Problem Domain
The Entity-Relationship Diagram
4
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved.
4
Learning Objectives
Explain how the concept of “things” in the problem domain also define requirements
Read and interpret an entity-relationship diagram
Identify and analyze data entities needed in the system
Create an entity-relationship diagram
Student Learning Outcome
Use appropriate techniques and tools to construct models for existing and new systems.
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved.
5
Overview
Chapter 3 provided an overview of identifying use cases to define functional requirements
This chapter focuses on another key concept for defining information/data requirements which is the concept of data entities.
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved.
6
Systems Analysis and Design in a Changing World, 6th Edition
7
Requirements Models in this unit
Model covered in this lecture
Models covered in previous lecture
Themes for Information-Elicitation Questions and their associated models
Systems Analysis and Design in a Changing World, 7th Edition
8
ERD
Use Case Models
8
The first questions that new systems analysts ask are, “What kind of information do I need to collect?” and “What is a requirement?” Basically, you want to obtain information that will enable you to build the logical model of the new business system (see Chapters 5 and 6 for information about modeling). As shown in Figure 4-6, the following three major themes should guide you as you pursue your investigation:
What Are the Business Processes?
In the first question—What do you do?—the focus is on understanding the business functions. In most cases, the users will provide answers in terms of the current system. As an analyst, you must carefully discern which of those functions are fundamental business functions, which will remain, and which may possibly be eliminated with an improved system.
How is the Business Process Performed?
The second question—How can it be done?—moves the discussion from the current system to the new system. The focus is on how the new system should support the function rather than on how it is performed under the existing system. Thus, the first two questions go hand-in-hand to discover the need and begin the definition of the system requirements in terms of the new system.
What Information is Required?
The final question—What information is needed?—defines specific information that the new system must provide. The answers to the second and third questions form the basis for the definition of the system requirements.
If you focus your investigation around these three themes, you will be able to ask intelligent, meaningful questions in your investigation. Later, as you learn about models, you will be able to formulate additional meaningful detailed questions to ask.
Systems Analysis and Design in a Changing World, 7th Edition
9
Entity-Relationship Diagram (ERD)
An ERD
is one model that represents data of interest to the system
basically shows the same information as a domain model Class Diagram (a UML model)
is used widely in database design
has no standard notation
crows feet notation is used in this text
consists of:
entities
relationships (associations) and
attributes
Systems Analysis and Design in a Changing World
10
Example of an ERD for a Customer Account System
Entity
Attribute
Relationship
Entities
11
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved.
1. Entity
“Thing” of interest that the system needs to store information about.
For example, a Student Management System needs to store data about a thing (entity) called student.
Represented by a rectangle in an ERD.
The name given to an entity MUST be SINGULAR and must be a NOUN e.g.
12
STUDENT
12
Entity Set & Entity Instance
An entity instance is each unique identifiable “thing” within an entity set.
For example, the STUDENT entity set below contains 2 unique identifiable student entity instances.
STUDENT entity set (with 2 instances)
Student ID Surname Firstname DOB Phone
123456789 Bloggs Joe 16/06/1981 93321245
123456790 Smith Jim 17/07/1975 94567556
STUDENT
ENTITY
StudentID
Surname
Firstname
DOB
Phone
Identifying Entities of interest to a system
Consider the following scenario for a bank’s account transaction processing system:
Kevin, a customer goes into the bank and makes a deposit. The bank teller at the counter records details of Kevin’s deposit.
What are the entities (things) of interest to the bank’s account transaction processing system in the scenario above? Which entities would the system need to keep information about?
Relationships
15
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved.
2. Relationship
Relationship - naturally occurring association between entities
Represented by a
line connecting the entities participating in the relationship and
a verb describing the relationship
CUSTOMER
ORDER
places
ITEM
contains
Read them separately each way e.g. the relationships between Customer and Order are:
Customer “places” Order (left to right) and
Order “is placed by” Customer (right to left).
17
Explaining relationships (associations) using entity instances
Order instance
Customer instance
Item instances
Representing business rules (cardinality)
We need to represent business rules i.e. the number of associations between entity instances participating in a relationship in an ERD
This is referred to as the cardinality of the relationship.
For example, what do you think are the business rules for the 2 relationships shown in the ERD below?
CUSTOMER
ORDER
places
ITEM
contains
Systems Analysis and Design in a Changing World, 7th Edition
19
Representing business rules (cont’d)
During elicitation of requirements, the following 3 business rules were expressed by the user with regard to customers placing orders for items.
Fig 4-5
1.
2.
3.
Systems Analysis and Design in a Changing World, 7th Edition
20
Representing business rules (cont’d)
The notation (crows feet) used to represent the cardinality of
relationships is shown below:
Representing business rules (cont’d)
The cardinality of the relationships have been added to the ERD based on the business rules expressed by the user
CUSTOMER
ORDER
places
ITEM
contains
What do you think should be the business rule and cardinality for this end of the relationship?
Business
Rule 2
Business
Rule 1
Business
Rule 3
Systems Analysis and Design in a Changing World, 7th Edition
22
Business Rule 1:
A customer places zero or many orders
Explaining cardinality using Customer, Order and Item (Product) instances
Business Rule 4:
An order contains one or more items
Customer places many orders
Customer places zero orders
Customer places one order
STUDENT
UNIT
Determining business rules between entities
enrols
You can determine the business rules between entities by asking 4 questions (in this example let’s examine the relationship Student enrols in Unit):
In how many units can a student enrol? Answer: many
Must a student enrol in a unit? Answer: mandatory
How many student enrolments can a unit have? Answer: many
Must a unit have a student enrolment? Answer: optional
EMPLOYEE
PROJECT
Describe the cardinality of the following
one-to-one relationship:
Example of an ERD with a One-to-One (1:1) Relationship
manages
EMPLOYEE
PROJECT
Describe the cardinality of the following
one-to-many relationship:
Example of an ERD with a One-to-Many (1:M) Relationship
manages
STUDENT
UNIT
Describe the cardinality of the following
many-to-many relationship:
Example of an ERD with a Many-to-Many (M:N) Relationship
enrols in
Example of Multiple Relationships
DEPT
*deptname
deptlocation
EMP
*empno
empfname
emplname
is assigned
is managed by
Describe the cardinality of the following relationships:
Hoffer J. A., George J. F., & Valacich S. Modern Systems Analysis and Design
28
Degree of Relationships (Associations)
Binary
a relationship between entity instances from 2 entity sets e.g. a product line contains many products
Unary Association (recursive)
a relationship between entity instances within the same entity set e.g.
A person is married to another person or an employee manages many employees
Binary relationships are relationships between two different types of things, such as a customer and an order.
Unary (recursive) relationships are relationships between two things of the same type, such as one person being married to another person.
28
Hoffer J. A., George J. F., & Valacich S. Modern Systems Analysis and Design
29
Degree of Relationships (Cont’d)
Ternary Association (three)
a simultaneous relationship among instances from 3 entity sets e.g. vendors ships parts to warehouses
N-ary Association (between n)
Ternary relationships are relationships between three different types of things. (An n-ary relationship means a relationship between n, any number, of different types of things.)
29
Attributes
30
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved.
3. Attribute
A specific piece of information stored about an entity or a relationship
An attribute describes an entity or a relationship
Naming attributes:
must be unique within an entity or a relationship
must be a noun
must be singular
should be meaningful
Important: An entity should only contain attributes that describe that entity i.e. it should not contain attributes that describe other entities.
Attributes
customer_id
first_name
last_name
phone_no
CUSTOMER
Most information systems store and use specific pieces of information about each thing. One piece of information about a thing is called an attribute.
For example, a customer has a name, address, phone number, and so on. Sometimes the identifier or key might be a compound attribute
Systems Analysis and Design in a Changing World, 7th Edition
32
Attributes and Values
Three customer instances
Attributes store data values
Example of an attribute describing a Relationship
Systems Analysis and Design in a Changing World, 7th Edition
33
Figure 4-15
grade
enrols
contains
33
Many-to-many relationships have “crow’s feet” on both ends of the relationship line. Sometimes this means there is more information that needs to be stored about the relationship. For example, a course section enrolls many students, and a student is enrolled in many course sections.
An associative entity called Course enrollment should replace the many-to-many relationship to allow the system to store the grade for each section that is taken by the student. See Figure 5-28 on page 178.
Type of Attribute Classifications
Simple versus Compound (Composite)
e.g. name is a compound attribute made up of simple attributes like first and last (family) name.
Single-valued versus Multi-valued
e.g. sex has a single value i.e. M or F but contact number could have multiple values e.g. home phone number, mobile number etc.
Stored versus Derived Attributes
e.g. Date of birth is a stored attribute while age is a derived attribute
Hoffer J. A., George J. F., & Valacich S. Modern Systems Analysis and Design
5
A compound attribute is an attribute that contains a collection of related attributes. For example, a Customer full name compound attribute might represent a customer’s first, middle, and last names.
Identifier
Every entity set must have an attribute or set of attributes that uniquely identifies each entity instance
e.g. the attribute cust_number uniquely identifies each customer instance for the entity CUSTOMER.
This attribute or set of attributes is called an identifier.
In this text, the characters “PK” is used to denote an identifier (placed in front of the identifier)
Each customer has a specific value for the attribute that is important for the system to remember. An attribute that uniquely identifies a specific thing is called an identifier or key. For example, an identifier for a customer is a customer number, for a vehicle it is a vehicle ID, and for a product it is a product ID. Sometimes these identifiers already exist (social security number, vehicle ID number) but sometimes they need to be created and assigned by the system (invoice number, transaction number).
Not all identifiers are ID numbers. For example, a name of a university could be an identifier.
Systems Analysis and Design in a Changing World, 7th Edition
36
An ERD for a Customer Account System (with attributes)
Identifier (PK)
Guidelines for Choosing an Identifier
Candidate Identifier – any attribute or set of attributes that could be used as an identifier i.e. they satisfy the requirements for being an identifier, e.g. studentid or email address can uniquely a student
When choosing the identifier for an entity, choose one that:
will always have a value
will not change its value over time
will not lose its uniqueness
is short.
Each customer has a specific value for the attribute that is important for the system to remember. An attribute that uniquely identifies a specific thing is called an identifier or key. For example, an identifier for a customer is a customer number, for a vehicle it is a vehicle ID, and for a product it is a product ID. Sometimes these identifiers already exist (social security number, vehicle ID number) but sometimes they need to be created and assigned by the system (invoice number, transaction number).
Not all identifiers are ID numbers. For example, a name of a university could be an identifier.
Developing an ERD
38
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved.
Process for Developing an ERD
Step 1a: Identify entities
Step 1b: Identify attributes for the entities
Some sources of information to identify entities and attributes include:
event tables
trigger for external events – input data (attributes)
response – output data (attributes)
use case descriptions
current reports or forms
information from existing systems and current procedures
Systems Analysis and Design in a Changing World, 7th Edition
39
39
RMO Event Table (trigger and response)
Systems Analysis and Design in a Changing World, 5th Edition
40
40
Systems Analysis and Design in a Changing World, 7th Edition
41
Use Case Description
Entities
Sample Order Form for RMO
Systems Analysis and Design in a Changing World, 7th Edition
42
Payment attributes
Order item attributes
Customer attributes
Shipment attributes
42
Better to have a completed rather than a blank form because:
Can see how form is actually used and understand the data
Can determine type and size of data being recorded
Need to determine which data is not always required
Can see relationships between data on form
Process for Developing an ERD (cont’d)
Step 2a: Identify relationships between the entities e.g.
Customer makes an Order
Order contains Items
Step 2b Identify cardinalities (business rules) of the relationships e.g.
Customer must make one or more Orders
Order must contain one or more items
Step 3: Identify any attributes for the relationships
Note: The process is an iterative and incremental process e.g. after step 3, one might identify attributes that describe entities that were not identified in step 1. One would then go back to step 1 and start again.
Systems Analysis and Design in a Changing World, 7th Edition
43
43
ERD Exercise
Every school in a university has a large number of units in its courses. After a student is admitted into a course, the student enrols in one or more units in a semester. A student might not be enrolled in any units in a particular semester (e.g. having a holiday, leave of absence or suspended).
ENROLMENT REPORT
Student ID: 143589 Name: John Smith
School Name: Management
Course Code: BOC Course Name: Bachelor of Commerce
Year Admitted: 2014
Year: 2014 Semester: 1
Unit ID Unit Name
11739 Development Methods
310410 Systems Analysis 251
44
Step 1a – Identify entities
Every school in a university has a large number of units in its courses. After a student is admitted into a course, the student enrols in one or more units in a semester. A student might not be enrolled in any units in a particular semester (e.g. having a holiday, leave of absence or suspended).
ENROLMENT REPORT
Student ID: 143589 Name: John Smith
School Name: Management
Course Code: BOC Course Name: Bachelor of Commerce
Year Admitted: 2014
Year: 2014 Semester: 1
Unit ID Unit Name
11739 Development Methods
310410 Systems Analysis 251
45
Step 1a – Identify entities (cont’d)
46
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved.
SCHOOL
COURSE
STUDENT
UNIT
Step 1b – Identify attributes for entities
Every school in a university has a large number of units in its courses. After a student is admitted into a course, the student enrols in one or more units in a semester. A student might not be enrolled in any units in a particular semester (e.g. having a holiday, leave of absence or suspended).
ENROLMENT REPORT
Student ID: 143589 Name: John Smith
School Name: Management
Course Code: BOC Course Name: Bachelor of Commerce
Year Admitted: 2014
Year: 2014 Semester: 1
Unit ID Unit Name
11739 Development Methods
310410 Systems Analysis 251
47
Step 1b – Identify attributes for entities (cont’d)
48
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved.
SCHOOL
SchoolCode (I)
SchoolName
COURSE
CourseCode (I)
CourseName
STUDENT
StudentNo (I)
StudentlName
UNIT
UnitID (I)
UnitName
Step 2a – Identify relationships
Every school in a university has a large number of units in its courses. After a student is admitted into a course, the student enrols in one or more units in a semester. A student might not be enrolled in any units in a particular semester (e.g. having a holiday, leave of absence or suspended).
ENROLMENT REPORT
Student ID: 143589 Name: John Smith
School: Management
Course Code: BOC Course Name: Bachelor of Commerce
Year Admitted: 2014
Year: 2014 Semester: 1
Unit ID Unit Name
11739 Development Methods
310410 Systems Analysis 251
49
Step 2a: Identify relationships (cont’d)
50
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved.
SCHOOL
SchoolCode (I)
SchoolName
COURSE
CourseCode (I)
CourseName
STUDENT
StudentNo (I)
StudentlName
UNIT
UnitID (I)
UnitName
admits
enrols
offers
consists
Step 2b – Identify cardinalities
Every school in a university has a large number of units in its courses. After a student is admitted into a course, the student enrols in one or more units in a semester. A student might not be enrolled in any units in a particular semester (e.g. having a holiday, leave of absence or suspended).
ENROLMENT REPORT
Student ID: 143589 Name: John Smith
School: Management
Course Code: BOC Course Name: Bachelor of Commerce
Year Admitted: 2014
Year: 2014 Semester: 1
Unit ID Unit Name
11739 Development Methods
310410 Systems Analysis 251
51
52
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved.
SCHOOL
SchoolCode (I)
SchoolName
COURSE
CourseCode (I)
CourseName
STUDENT
StudentNo (I)
StudentlName
UNIT
UnitID (I)
UnitName
admits
enrols
offers
consists
Step 2b – Identify cardinalities (cont’d)
Step 3 - Identify attributes for relationships
Every school in a university has a large number of units in its courses. After a student is admitted into a course, the student enrols in one or more units in a semester. A student might not be enrolled in any units in a particular semester (e.g. having a holiday, leave of absence or suspended).
ENROLMENT REPORT
Student ID: 143589 Name: John Smith
School: Management
Course Code: BOC Course Name: Bachelor of Commerce
Year Admitted: 2014
Year: 2014 Semester: 1
Unit ID Unit Name
11739 Development Methods
310410 Systems Analysis 251
53
Step 3 - Identify attributes for relationships (cont’d)
54
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved.
SCHOOL
SchoolCode (I)
SchoolName
COURSE
CourseCode (I)
CourseName
STUDENT
StudentNo (I)
StudentlName
UNIT
UnitID (I)
UnitName
Year
Semester
Year
Admitted
admits
enrols
offers
consists
ERD
55
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved.
SCHOOL
SchoolCode (I)
SchoolName
COURSE
CourseCode (I)
CourseName
STUDENT
StudentNo (I)
StudentlName
UNIT
UnitID (I)
UnitName
Year
Semester
Year
admits
enrols
offers
contains
Supertypes and Subtypes
56
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved.
More Complex Concepts
Generalisation: The concept that some entities are subtypes of other, more general entities i.e. supertypes.
A supertype is a generic entity type that is subdivided into subtypes
e.g. the “Motor Vehicle” in the next slide is considered a supertype that is subdivided into 3 subtypes (Truck, Car and Tractor).
Systems Analysis and Design in a Changing World, 7th Edition
57
57
Systems Analysis and Design in a Changing World, 7th Edition
58
More Complex Concepts (cont’d)
More Complex Concepts (cont’d)
A subtype shares common attributes or relationships with other subtypes but also has its own distinct attributes
For example, an organisation has 3 types (subtypes) of employees: 1. Casual Employees: EmpNo, Name and Hourly Rate 2. Salaried Employees EmpNo, Name and Annual Salary 3. Contract Consultants: EmpNo, Name, Contract No and Daily Rate
The employee subtypes above
Share common attributes i.e. EmpNo and Name and
Have their own distinct attributes (in italics).
Systems Analysis and Design in a Changing World, 7th Edition
59
59
The scenario in the previous slide can be modelled using 3 approaches:
Approach 1: Define one entity EMPLOYEE that stores all the attributes
Approach 2: Define 3 separate entities: CASUAL EMP, SALARIED EMP and CONSULTANT
Approach 3: Define a supertype EMPLOYEE (that stores the common attributes) with subtypes CASUAL EMP, SALARIED EMP and CONSULTANT which store the attributes unique to that subtype.
Modelling supertype and subtypes
EMPLOYEE
EmpNo
Name
Hourly rate
Annual Salary
ContractNo
DailyRate
Approach 1
Define one entity EMPLOYEE that stores the attributes for all types of employees
Approach 1 (cont’d)
| EmpNo | Name | Hourly rate | Annual Salary | ContractNo | DailyRate |
| 01 | Smith | 70 | |||
| 02 | Jones | 80000 | |||
| 03 | Tan | 0897889 | 900 |
62
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved.
Note: There will no values (nulls) stored in the attributes Hourly Rate, Annual Salary, ContractNo and DailyRate, as these are unique attributes that will only have values depending on the type of employee i.e. casual, salaried or contract.
CASUAL_EMP
EmpNo
Name
Hourly rate
SALARIED_EMP
EmpNo
Name
Annual Salary
CONSULTANT
EmpNo
Name
ContractNo
DailyRate
Approach 2
Note: This approach is not making use of the common attributes (EmpNo and Name) for each of the entities.
Define 3 separate entities: CASUAL EMP, SALARIED EMP and CONSULTANT
EMPLOYEE
EmpNo
Name
CASUAL
EMP
Hourly rate
SALARIED
EMP
Annual Salary
CONSULTANT
Contract
DailyRate
Approach 3 – Using super and subtypes
Note:
This approach makes use of the common attributes (EmpNo and Name) applicable to all types of employees (which was the issue in approach 2)
All attributes of the supertype become attributes of its subtypes i.e. the subtypes CASUAL EMP, SALARIED EMP and CONSULTANT inherit the attributes EmpNo and Name from the supertype EMPLOYEE.
This approach also avoids the situation of no values (nulls) being stored in the attributes Hourly Rate, Annual Salary, ContractNo and DailyRate (which was the issue in approach 1).
Systems Analysis and Design in a Changing World, 7th Edition
65
Summary
This chapter focuses on modelling data requirements as a part of systems analysis
“Things” are identified and modelled, called data entities
Data entities have attributes and associations
Associations are naturally occurring relationships among entities, and have minimum and maximum cardinality
Entity-relationship diagrams (ERDs) show the information about data entities and their associations
References
Hoffer J. A., George J. F., & Valacich S. Modern Systems Analysis and Design, Pearson Prentice Hall.
Systems Analysis and Design in a Changing World, 6th Edition
66
Additional Exercises
Additional exercises on Use Cases can be found in the appropriate chapters in the following textbooks in the library:
1. Bentley, L.D. and Whitten, J. L. (2007). Systems Analysis and Design for the Global Enterprise, 7th Ed., McGraw-Hill/Irwin, McGraw-Hill Companies.
2. Hoffer J. A, Valacich S., George J. F. (2013). Modern Systems Analysis and Design, 7th Ed., Pearson Prentice Hall.
3. Shelly, G.B., Cashman, T.J., & Rosenblatt, H.J. 2012. Systems Analysis and Design, 9th ed., Thomson Course Technology.
4. Kendall, K.E. and Kendall, J.E., (2013), Systems Analysis and Design, 9th ed., Pearson Prentice Hall.
5. Dennis, A., Wixom, B. H. & Roth, R.M. (2014). Systems Analysis and Design, 6th ed., John Wiley & Sons Inc.