61FIT3REQ – Software Requirements Analysis

Lecture 7

System Data Requirements (a)

Faculty of Information Technology

Hanoi University
Recall: 3 Perspectives of Requirements
 Conceptual Data Modeling
• Conceptual data modeling: a detailed model
that captures the overall structure of data in
an organization
– Entities, attributes, and relationships extracted
from analyzing captured requirements
• No assumptions about underlying technology
– Independent of any DBMS or implementation
• Description of what would be in the data
stores of the DFDs
 Conceptual Data Modeling
• Conceptual data modeling is typically done in
parallel with other requirements analysis and
specification activities.
– E.g. Process modeling, use case modeling...
• In the design stage: a conceptual data model
is translated into a physical design.
• Conceptual data modeling is also useful for
project planning.
Data modeling and the SDLC
 Outcome and deliverables
• Entity-relationship (E-R) diagram or UML class
diagram
– Entities (or classes) – categories of data
– Relationships (or associations) – connections
between entities
• Data elements included in the data flow diagram
(DFD) must appear in the data model and vice versa.
• Each data store in a process model must relate to
business objects represented in the data model.
Conceptual data model example
Conceptual Data Modeling Approaches
• Two perspectives on data modeling:
– Top-down approach: a data model is derived from
understanding the business.
– Bottom-up approach: a data model is derived by
reviewing specifications and business documents.
 Gathering Information
• Requirements determination questions for
data modeling:
– What are subjects/objects of the business?
• Data entities and descriptions
– What unique characteristics distinguish between
subjects/objects of the same type?
• Primary keys
 Gathering Information
• What characteristics describe each
subject/object?
– Attributes and secondary keys
• How do you use the data? Who knows the
meaning of the data?
– Security controls and user access privileges
• Over what period of time are you interested in
the data?
– Cardinality and time dimensions
 Gathering Information
• Are all instances of each object the same?
– Supertypes, subtypes, and aggregations
• What events occur that imply associations
between objects?
– Relationships and cardinalities
• Are there special circumstances that affect the
way events are handled?
– Integrity rules, minimum and maximum
cardinalities, time dimensions
Entity-Relationship (E-R) Modeling
• Entity-Relationship data model (E-R model): a
detailed, logical representation of the entities,
associations and data elements for an
organization or business area
• Entity-relationship diagram (E-R diagram): a
graphical representation of an E-R model
Entity-Relationship (E-R) Modeling
• The E-R model is expressed in terms of:
– Data entities in the business environment
– Relationships or associations among those entities
– Attributes or properties of both the entities and
their relationships
Entity-Relationship (E-R) Modeling
• Entity: a person, place, object, event or concept
in the user environment about which data is to be
maintained
– An entity should be about something that is being
represented by the system.
• Entity type: collection of entities that share
common properties or characteristics
• Entity instance: single occurrence of an entity
type
(*) The terms Entity and Entity Type are often used interchangeably
Basic E-R notations
 Defining Entity Types
• An entity type definition:
– Includes a statement of what the unique
characteristic(s) is (are) for each instance.
– Makes clear what entity instances are included
and not included in the entity type.
– Often includes a description of when an instance
of the entity type is created or deleted.
 Naming Entity Types
• An entity type name should be:
– A singular noun.
– Descriptive and specific to the organization.
– Concise.
• Event entity type should be named for the
result of the event, not the activity or process
of the event.
 Attributes
• Attribute: a named property or characteristic of
an entity that is of interest to the organization
– e.g. Vehicle_ID
• An attribute name is a noun and should be
unique.
• To make an attribute name unique and for clarity,
each attribute name should follow a standard
format.
• Similar attributes of different entity types should
use similar but distinguishing names.
 Candidate Keys and Identifiers
• Candidate key: an attribute (or combination
of attributes) that uniquely identifies each
instance of an entity type
• 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.
– Whose values are derived from some data.
• Consider replacing composite keys with
single-valued keys.
 Other attribute types
• Multivalued attribute: an attribute that may
take on more than one value for each entity
instance
• Repeating group: a set of two or more
multivalued attributes that are logically
related
Multivalued attributes
and repeating groups
 Other attribute types
• Required attribute: an attribute that must
have a value for every entity instance
• Optional attribute: an attribute that may not
have a value for every entity instance
• Composite attribute: an attribute that has
meaningful component parts
• Derived attribute: an attribute whose value
can be computed from related attribute values
 Relationships
• Relationship: an association between the
instances of one or more entity types that is of
interest to the organization
• Degree: the number of entity types that
participate in a relationship
 Relationships
• Unary relationship: a relationship between the
instances of one entity type
– Also called a recursive relationship
• Binary relationship: a relationship between
instances of two entity types
– Most common type of relationship encountered in
data modeling
• Ternary relationship: a simultaneous relationship
among instances of three entity types
Examples of relationships
of different degrees
 Cardinalities
• Cardinality: the number of instances of entity
B that can (or must) 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
 Cardinalities
• Mandatory vs. Optional Cardinalities
– Specifies whether an instance must exist or can be
absent in the relationship

Mandatory cardinalities

Optional cardinalities
One mandatory, one optional
 Associative Entities
• 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
– Sometimes called a gerund
• The data modeler chooses to model the
relationship as an entity type.
Associative Entities
EXTENDED E-R DIAGRAM
 Supertypes and subtypes
• Subtype: a subgrouping of the entities in an
entity type
– Is meaningful to the organization
– Shares common attributes or relationships distinct
from other subgroupings
• Supertype: a generic entity type that has a
relationship with one or more subtypes
Supertype/subtype relationships in a hospital
 Supertypes and subtypes
• Total specialization specifies that each entity
instance of the supertype must be a member
of some subtype in the relationship.
– Represented by double lines.
• Partial specialization specifies that an entity
instance of the supertype does not have to
belong to any subtype, and may or may not be
an instance of one of the subtypes.
– Represented by single lines.
 Supertypes and subtypes
• Disjoint rule specifies that if an entity instance
of the supertype is a member of one subtype,
it cannot simultaneously be a member of any
other subtype.
– Represented with “d”.
• Overlap rule specifies that an entity instance
can simultaneously be a member of two (or
more) subtypes.
– Represented with “o”.
 Example of
supertype/subtype hierarchy