Information Systems System Analysis 421 Class Seven

1
Information Systems System Analysis 421Class
Seven
2
Learning Objectives

• Define key data modeling terms
• Entity type
• Attribute
• Multivalued attribute
• Relationship
• Degree
• Cardinality
• Business Rule
• Associative entity
• Trigger
• Supertype
• Subtype

10.2
3
Learning Objectives

• Learn to draw Entity-Relationship (E-R) Diagrams
  Review the role of conceptual data modeling in
  overall design and analysis of an information
  system
• Distinguish between unary, binary, and ternary
  relationships, and give an example of each
• Define four basic types of business rules in an
  E-R diagram
• Explain the role of CASE technology in the
  analysis and documentation of data required in an
  information system
• Relate data modeling to process and logic
  modeling as different views describing an
  information system

10.3
4
System Analysis
5
System Modeling

• One way to structure unstructured problems is to
  draw a model
• A model is a representation of reality - picture
  worth a thousand words
• Built to understand the existing system as a way
  to document business requirements
• Data modeling is a technique for defining
  business requirements
• Data is viewed as a resource to be shared by as
  many processes as possible, data must be
  organized in a way that is flexible and adaptable
  to unanticipated business requirements

6
System modeling

• Physical model shows not only what a system does
  but how the system is physically and technically
  implemented - depicts technical design
• Logical models depict business requirements
  illustrates the essence of the system
• Move biases that are the results of the way the
  current system is implemented
• Reduce the risk of missing requirements
• Allow us to communicate with end users
• Help analysts and users understand business
  terminology and rules

7
Data Modeling

• Data modeling is done during the project
  definition stage and refined in physical design
• Data model help the analyst identify business
  vocabulary and uncover business requirements
• Built more quickly
• Can be fit on several sheets of paper
• Looking ahead -
• logical models will be transformed into a
  physical model called database schema
• Also be analyzed for adaptability and flexibility
  through a process called normalization

8
Conceptual Data Modeling

• Representation of organizational data
• Purpose is to show rules about the meaning and
  interrelationships among data
• Entity-Relationship (E-R) diagrams are commonly
  used to show how data are organized
• Main goal of conceptual data modeling is to
  create accurate E-R diagrams
• Methods such as interviewing, questionnaires and
  JAD are used to collect information
• Consistency must be maintained between process
  flow, decision logic and data modeling
  descriptions

10.8
9
Process of Conceptual Data Modeling

• First step is to develop a data model for the
  system being replaced
• Next, a new conceptual data model is built that
  includes all the requirements of the new system
• In the design stage, the conceptual data model is
  translated into a physical design
• Project repository links all design and data
  modeling steps performed during SDLC

10.9
10
Deliverables and Outcome

• Primary deliverable is the entity-relationship
  diagram
• There may be as many as 4 E-R diagrams produced
  and analyzed during conceptual data modeling
• Covers just data needed in the projects
  application
• E-R diagram for system being replaced
• An E-R diagram for the whole database from which
  the new applications data are extracted
• An E-R diagram for the whole database from which
  data for the application system being replaced is
  drawn

10.10
11
Figure 10-3Sample conceptual data model diagram
10.11
12
Deliverables and Outcome

• Second deliverable is a set of entries about data
  objects to be stored in repository or project
  dictionary
• Repository links data, process and logic models
  of an information system
• Data elements that are included in the DFD must
  appear in the data model and visa versa
• Each data store in a process model must relate to
  business objects represented in the data model

10.12
13
Gathering Information for Conceptual Data Modeling

• Two perspectives
• Top-down
• Data model is derived from an intimate
  understanding of the business
• Bottom-up
• Data model is derived by reviewing specifications
  and business documents

10.13
14
Introduction to Entity-Relationship (E-R) Modeling

• Notation uses three main constructs
• Data entities
• Relationships
• Attributes
• Entity-Relationship (E-R) Diagram
• A detailed, logical representation of the
  entities, associations and data elements for an
  organization or business

10.14
15
Entity-Relationship (E-R) ModelingKey Terms

• Entity
• A person, place, object, event or concept in the
  user environment about which the organization
  wishes to maintain data
• Represented by a rectangle in E-R diagrams
• Entity Type
• A collection of entities that share common
  properties or characteristics
• Attribute
• A named property or characteristic of an entity
  that is of interest to an organization

10.15
16
Entity-Relationship (E-R) ModelingKey Terms

• Candidate keys and identifiers
• Each entity type must have an attribute or set of
  attributes that distinguishes one instance from
  other instances of the same type
• Candidate key
• Attribute (or combination of attributes) that
  uniquely identifies each instance of an entity
  type

10.16
17
Entity-Relationship (E-R) ModelingKey Terms

• Identifier
• A candidate key that has been selected as the
  unique identifying characteristic for an entity
  type
• Selection rules for an identifier
• Choose a candidate key that will not change its
  value
• Choose a candidate key that will never be null
• Avoid using intelligent keys
• Consider substituting single value surrogate keys
  for large composite keys

10.17
18
Entity-Relationship (E-R) ModelingKey Terms

• Multivalued Attribute
• An attribute that may take on more than one value
  for each entity instance
• Represented on E-R Diagram in two ways
• double-lined ellipse
• weak entity
• Relationship
• An association between the instances of one or
  more entity types that is of interest to the
  organization
• Association indicates that an event has occurred
  or that there is a natural link between entity
  types
• Relationships are always labeled with verb
  phrases

10.18
19
Conceptual Data Modeling

• Goal
• Capture as much of the meaning of the data as
  possible
• Result
• A better design that is easier to maintain

10.19
20
Degree of Relationship

• Degree
• Number of entity types that participate in a
  relationship
• Three cases
• Unary
• A relationship between two instances of one
  entity type
• Binary
• A relationship between the instances of two
  entity types
• Ternary
• A simultaneous relationship among the instances
  of three entity types
• Not the same as three binary relationships

10.20
21
Figure 10-6Example relationships of different
degrees
10.21
22
Cardinality

• The number of instances of entity B that can be
  associated with each instance of entity A
• Minimum Cardinality
• The minimum number of instances of entity B that
  may be associated with each instance of entity A
• Maximum Cardinality
• The maximum number of instances of entity B that
  may be associated with each instance of entity A

10.22
23
ERD Sample
24
Entity

• All systems contain data
• Data describes things
• A thing that can be uniquely identified -- a noun
• person
• object (e.g., machine, tool, equipment, document)
• concept
• An entity is a class of persons, place, objects,
  events or concepts about which we need to capture
  and store data
• An entity instance - is a single occurrence of an
  entity

25
Entity Type
26
Entity Instance
27
Entity Symbol
Entity Symbol
What are some groupings of data? What are some
entity instance?
28
Entity Rules

• Some Rules of Thumb
• Each entity is going to end up being represented
  by at least one table. Therefore, something which
  does not involve at least two data elements to
  describe it is probably not an entity.
• Entities will become data stores on the Data Flow
  Diagram.
• If each data store does not represent at least
  one entity, it may not be necessary to the
  system.
• If you cannot imagine the entity you propose as
  being the name of a data store on a system DFD,
  it is probably not worth defining as one.

29
Entity Review

• Review
• they are primary things about which an
  organization records data
• they have unique names that are nouns
• they have primary keys that are unique
• they have attributes
• they have at least one relationship
• they can be fundamental or attributive entities.

30
ERD Concepts - Attributes

• The piece of data that we want to store about
  each element within a given entity
• An attribute is a descriptive property or
  character of an entity
• A compound attribute is one that actually consist
  of more primitive attributes
• Name gt Last, First, middle

31
Entity Attributes
Street
Last_name
City
Persons
State
First_name
Zip
32
Compound Attributes
Last_name
Persons
Address
First_name
33
Properties Attributes

• The value of each attribute are defined in terms
  of three properties type, domain and default
• Type - the class of data
• Domain - potential values
• Default - what is recorded if nothing is
  specified

34
Keys

• Primary
• Alternate
• Foreign

35
Properties Attributes

• Identification - an entity has many occurrences,
  could run into the millions, there is a need to
  uniquely identify each instance based on the data
  value of one or more attributes
• Every entity must have an identifier or key which
  assumes an unique value - primary
• Sometimes you will have more than one key -
  concatenated keys
• Any field that is not a primary key is a
  candidate for alternate/foreign keys

36
Entity Keys

• Primary Key
• unique
• never changes
• never is null
• sometimes is compound
• Alternate Key
• for searching
• sometimes compound

37
Foreign Key

• Use Foreign key as pointer to establish this
  relationship.

38
Guidelines for Naming Attributes

• Compound names
• name should reflect the meaning of the entity and
  attribute
• name must be unique to the whole context
• good to make the name hierarchical (almost like
  an object environment.) consider using the
  entity name, then underscore, then attribute name
  when needed for clarity

Salesman_Name_First Salesman_Name_Last Customer_Na
me_First Customer_Name_Last
Salesmen
Customers
39
Guidelines for Naming Attributes

• Abbreviations
• allow for more descriptive names
• Blanks
• avoid blanks as many languages do not permit them
  in variable names

40
Attribute Types and Width

• Defines physical structure of the attribute
• Character
• Numeric
• Money
• Date
• BLOB
• Phone number
• Zipcode
• Width defines the size of the type
• Zipcode might have width of 9

41
Guidelines for Naming Attributes

• Consistency
• Best to use the same name in ERD, DFD, database,
  actual code
• Length
• Depends upon limits of the tools in use. Dont
  violate the limit of a tool if you are in a
  separate stage of SDLC if you can help it
• Capitalization
• Use unless implementation language discourages
  it. It is clearer to read

42
ERD Concepts - Relationships

• Entities and attributes do not exist in isolation
• A relationship is a natural business association
  that exist between one or more entities.
• A connecting line between two entities represents
  a relationship
• A verb phase describes the relationship
• Directional
• Event
• Something happens
• Linkage

43
Entity Relationship Diagrams
44
ERD Concepts - Relationships
45
Is related to
Relationship
46
Relationships
Student SSN Name Last First
Middle Address Town State Sex Disability Birth
date Overall GPA
Class SSN Course No. Time YR/QTR Grade Credit
has taken
47
Relationship Degree

• The degree of a relationship is the number of
  entities that participate in the relationship
• The number of entities involved
• Unary - relate back to itself
• This is called a recursive relationship
  (sometimes called a unary relationship degree
  1).
• Binary- two entity
• Ternary - relationship exist between more than
  two entities

48
Unuary Relationship

• Organization Hierarchy
• SSN Name Report to
• 123 Joe Smith 456
• 245 Kraft Cheese 456
• 456 Top Dog

49
Binary Relationships
Student SSN Name Last First
Middle Address Town State Sex Disability Birth
date Overall GPA
Class SSN Course No. Time YR/QTR Grade Credit
has taken
50
Ternary Relationships

• Relationships can also exist between more than
  two different entities.
• These are sometimes called N-ary relationships.
• A relationship existing among three entities is
  called a 3-ary or ternary relationship.
• An N-ary relationship maybe associated with an
  associative entity.
• An associative entity is an entity that inherits
  its primary key from more than one other entity
  (parents). Each part of that concatenated key
  points to one and only one instance of each of
  the connecting entities.

51
Ternary Relationships
Teacher SSN Name Last First
Middle Address Town State Sex Disability Birth
date
Class Course No. Time YR/QTR Grade Credit
is assign
meets in
Classroom SSN CourseNo. Facility Room Night
52
Ternary Relationships
53
ERD Cardinality

• The minimum and maximum number of occurrences of
  one entity for a single instance
• zero
• one
• many
• specific number
• 11, 1M, MN

54
ERD Relationships
Unary 1 to 1 1 to many
is married to
Person
Employee
Manages
55
ERD Relationships
Binary 1 to 1 1 to many many to
many
Parking Place
is assigned
Employee
Product Line
Product
contains
Registers for
Course
Student
56
ERD Relationships Symbols
57
ERD Cardinality
Prepared by Kevin C. Dittman for Systems Analysis
Design Methods 4ed by J. L. Whitten L. D.
Bentley
58
Relationships
59
Relationships
B
A is related to one and only one B A is related
to zero or one B A is related to one or more
B A is related to zero, one or more B A is
related to more than one B
A
A
B
A
B
B
A
A
B
60
Relationships
Places
Order
Customer
Is-Placed-by
Claims is-claimed-by
Dependent
Employee
Teaches is-taught-by
Class
Instructor
61
Problem
62
Naming and Defining Relationships

• Relationship name is a verb phrase
• Avoid vague names
• Guidelines for defining relationships
• Definition explains what action is being taken
  and why it is important
• Give examples to clarify the action
• Optional participation should be explained
• Explain reasons for any explicit maximum
  cardinality

10.62
63
Naming and Defining Relationships

• Guidelines for defining relationships
• Explain any restrictions on participation in the
  relationship
• Explain extent of the history that is kept in the
  relationship
• Explain whether an entity instance involved in a
  relationship instance can transfer participation
  to another relationship instance

10.63
64
Associative Entity

• An entity type that associates the instances of
  one or more entity types and contains attributes
  that are peculiar to the relationship between
  those entity instances

10.64
65
Domains

• The set of all data types and ranges of values
  that an attribute can assume
• Several advantages
• Verify that the values for an attribute are valid
• Ensure that various data manipulation operations
  are logical
• Help conserve effort in describing attribute
  characteristics

10.65
66
Triggering Operations

• An assertion or rule that governs the validity of
  data manipulation operations such as insert,
  update and delete
• Includes the following components
• User rule
• Statement of the business rule to be enforced by
  the trigger
• Event
• Data manipulation operation that initiates the
  operation
• Entity Name
• Name of entity being accessed or modified
• Condition
• Condition that causes the operation to be
  triggered
• Action
• Action taken when the operation is triggered

10.66
67
Triggering Operations

• Responsibility for data integrity lies within
  scope of database management system, not
  individual applications

10.67
68
The Role of CASE in Conceptual Data

• CASE tools provide two important functions
• Maintain E-R diagrams as a visual depiction of
  structured data requirements
• Link objects on E-R diagrams to corresponding
  descriptions in a repository

10.68
69
Summary

• Process of conceptual data modeling
• Deliverables
• Gathering information
• Entity-Relationship Modeling
• Entities
• Attributes
• Candidate keys and identifiers
• Multivalued attributes
• Degree of relationship

10.69
70
Summary

• Cardinality
• Naming and defining relationships
• Associative entities
• Domains
• Triggering Operations
• Role of CASE

10.70
71
How do you build an ERD for your project?

• Here is a cookbook approach

72
How to Construct a Data Model

• Identify data entities
• What are the entities of interest around which
  data must be stored?
• Model the world be more rather than less
  comprehensive
• Pay attention to key words
• True entities have many instances dozens,
  hundreds or more!
• Entities should be named with a singular noun
  when possible
• Define each entity in business terms
• Sometimes the start of a business glossary
• Show slide 43

73
How to Construct a Data Model

• Data entry forms (paper and screen)
• Reports (paper and screen)
• Existing Databases
• DFDs (if completed. Each data flow must be an
  attribute of some entity. Data stores may be
  associated with entities.)
• Interviews

74
How to Construct a Data Model

• Derive a high level, first cut data model
• Sometimes referred to as a context data model
• What are the techniques?
• look at forms, look at existing database, do
  interviews, do a JAD-like session
• Define relationships between entities, form
  simple business sentences

75
Data Model
76
How to Construct a Data Model

• Identify likely attributes of those entities
• What are the keys? (Primary, Alternate, Foreign)
• How should you name them?
• Determine what type each is
• Determine constraints (cardinalities) of
  attributes
• Determine relationships among entities
• How are they related? Optional or mandatory?
• Fundamental, attributive, and associative
  entities
• What are the cardinalities of the relationships?
• Identify remaining attributes

77
How to Construct a Data Model

• Other key questions to ask
• What people, places, and things are used in the
  business? How many of each are there? How do
  you differentiate them? Entities and attributes
  
• What unique characteristics distinguish one
  object from another? Attributes and primary key
• What characteristics describe each object?
  Attributes and secondary keys

78
How to Construct a Data Model

• How do you use the data? What is the source of
  the data? Who controls it?
• Over what time periods are you interested in this
  data? If it changes over time, do you need to
  know that? Cardinality and time issues
• Are all instances of each object the same?
  Supertypes and subtypes
• What kinds of transactions do you keep track of?
  Relationships
• Are transactions always handled the same way, or
  are there sometimes exceptions? Can only some of
  the attributes of an object change? Cardinality
• Can the associations or relationships among
  objects change over time?

79
Class Problem

• Given the following data attributes and entities,
  indicate which attributes could be identifiers
  for each of the entities. You may have to combine
  attributes or even add some attributes that are
  not listed. Map all of the attributes to their
  appropriate entity. Remember, each attribute
  should describe one and only one entity. Draw a
  rough draft entity relationship diagram.

80
Class Problem
Green Acres Real Estate System Entities Seller
House Closing Buyer Offer Showing Listing
Property Room Attributes Seller name Square
foot size Seller address House style Closing
location Listing price Number of
bathrooms Garage size Showing date Garage
location Buyer name Basement size House heating
method Offer amount Listing date Property
description Offer date Room type Property
size Showing time Room size Elementary school
zone Buyer phone number Closing date Sales terms
81
Answers
82
Answers