• What is a process model?
– A formal way of representing how a business system operates.
– Illustrates the activities that are performed and how data moves through the process.
– A process model can be used to document current system or to illustrate new system
• Use Cases and Data Flow Diagrams (DFD) are among many techniques to support Business Process
Modeling

• What’s new in technology?
• A couple of ‘Interesting’ Questions
• Lecture Material
– Data Modeling
– Entity-Relationship Diagrams
– Normalizing Data
• Summary – where we are
• NOTE: No tutorials next week
(midterm)

Project Identification & Selection
Project Initiation & Planning
Analysis
Logical Design
Process Model
Data Structure
Logic Modeling
Physical Design
Implementation
Maintenance

• DFDs and Logic Modeling
– show how, where and when data is used
• Data Modeling
– shows data definition, structure & relationships
• Importance
– crucial information for the design phase
– data is often more complex than processes
– data has reasonably permanent characteristics

• A data model shows the people, places, and things of interest to an organization and the relationships among them.
• The logical data model is an abstraction. Once again, it shows the organization of data without indicating how it is stored, created, or manipulated.

• A physical data model shows how the data will actually be stored in the database.
• Normalization is the process analysts use to check for data redundancy.

• What is it?
– Captures the structure of organizational data
– Is independent of a DBMS or implementation
• When is it used?
– Conceptual Data Modeling is during analysis
– Other data modeling is done throughout SDLC
• What form does it take?
– Entity Relationship Diagrams (ERDs)

Entity-Name
Identifier
Attribute-name
Attribute-name
Attribute-name
Relationship-name

• There are several different notations for ERD’s.
– none are the de facto standard
– we will look at commonalities

• A person, place, object, event or concept that you want to maintain data about
– e.g., Customer, Product, Sale, Course, etc.
• entities are named with a noun
• represented by a rectangle
Place Entity
Name Here

• Top Down Modeling
– Asking Questions
– Determining Business Rules
“What things do we care about, in that we need to store them in our data base to perform business operations?”
• persons
• places
• objects
• events
• concepts

• Bottom-Up Modeling
– looking at forms and reports required in the system
– identifying entities from DFD’s

(aka: distinctions modelers make to keep you confused)
• Entity Type (or class) refers to a collection of entities that share common properties
– e.g. The entity “student” may have two entity types, graduate and undergraduate student
• Entity Instance refers to a single unique object within an entity type
– e.g., Employee is an entity, customer service representative (CSR) is an entity type, and the CSR named ‘Carl’ is an entity instance.

• A named characteristic of an entity that is of interest to the organization or application
– e.g., Customer #, Customer Address, etc.
• Attributes are listed under the entity name
Customer
C_lastname
C_firstname
C_telephone
• attributes are named with nouns

• A key is an attribute that uniquely identifies every instance of an entity type.
• Candidate keys are one or more attributes that uniquely identify every entity instance
• Primary key - the candidate key that is chosen as the unique identifier for every instance of the entity type.
– choose stable, non null, and simple attributes
– primary keys are marked with an asterisk in the diagram

• Title and Copy could uniquely identify a single physical DVD.
• It would probably be better to choose a
Movie_Serial_Number for each specific DVD so we could keep the key to one attribute
(could include mnemonics like the first word and a number: Ted2-01)

• The link that combines entity types.
– More formally, a relationship is an association between instances of one or more entity types
• labeled with verb phases - one or two
• may be represented as a diamond or not shown at all on the diagram to avoid clutter

• Relationships typically represent a
transaction of the organization
Members
1 0
Rent
0
DVDs

• One to One
Employee Assigned
Parking
Space
1
1
• One to Many
Student
1
• Many to Many
Student
Owns
N
Takes
N
N
Textbooks
Classes

Optional:
Members
1 0
Rent
0
DVDs

• Degrees of Relationships
• Cardinality
• Many to many relationships

• The number of instances of entity A that can be associated with instances of entity B
• For example:
Student
1
Owns
N
Textbooks
Cardinalities
Student
N
Takes
N
Classes

One
Many
The crow’s foot indicates many
This line indicates mandatory (at least one must exist)
Example: Patient has Patient History
Patient has
Patient
History

One Many
The “0” indicates the entity may have zero instances. This means the relation is optional
Example: Movie is available on DVD
Movie Stored as
DVD

• Generally implies that there are attributes associated with the relationship
– i.e., attributes that do not belong with one of the entities alone but with the combination
• Many to Many relationships are very difficult to deal with in databases
• A typical approach is to create a 3rd entity when we are faced with a many to many relation
– the primary key for the new entity will be the keys of the entities that it connects

Customer
0
Can be transformed into: books
Flight
Customer
0 Books
Seat
Is on
This transformation makes the relationship easier to handle. In general, we seek to eliminate many to many relationships whenever possible.
Flight

What information does this M-to-M assume is not important to keep track of?

• To minimize redundancy of a data base
• To completely represent the required data in an information system

• A set of rules to determine appropriate behavior for a data base.
• First, fill in the blanks for EVERY record
• Second, remove redundant items (partial dependency)
• Third, eliminate complex relations where two or more relational meanings exist (transitive dependency)

Orders:
Ordered Items:
Item Descriptions:

Orders:
Customers:
City, Province:
Ordered Items:
Item Descriptions:

• We have covered the Systems Analysis part of the course…
– Seek to understand a system, and to start to build a model of that system
– Focus on the Systems Development Life Cycle
• Process, Data, or Object Oriented
• Works with traditional and rapid application development

• We ask questions:
– Feasibility
• Economic
• Technical
• Organizational
• We plan major steps of the project
– Understand current system
– Envision possible improvements
• automation
• process improvement
• process reengineering

• We gather data
– questionnaires
– interviews
– observation
– JAD
• We start to model what we understand to be the processes under study
– Build Use Cases
– draw DFD’s

• We start to distill the required logic of the process
– Logical data flows
– Key processes
– Logic within the processes themselves
• And the data we need to keep within the system
– ERD and logical data modeling