Chapter Seven

Structuring System Data

Requirements: Data Modeling
Introduction
Data-flow diagrams show how, where, and when data are used or changed in an information
system. Data modeling show the definition, structure, and relationships within the data.
Conceptual Data Modeling
A conceptual data model is a representation of organizational data. The purpose of a conceptual
data model is to show as many rules about the meaning and interrelationships among data as
possible, independent of any database management system or other implementation
considerations.
Entity-relationship (E-R) data models are commonly used diagrams that show how data are
organized in an information system. The main goal of conceptual data modeling is to create
accurate E-R diagrams. You develop (or use from prior systems development) a conceptual data
model for the current system and build a conceptual data model that supports the scope and
requirements for the proposed or enhanced system.
The work of all team members is coordinated and shared through the project dictionary or
repository. This repository and associated diagrams may be maintained by a CASE tool or a
specialized tool such as Microsoft’s Visio. Whether automated or manual, the process flow,
decision logic, and data-model descriptions of a system must be consistent and complete,
because each describes different but complementary views of the same information system. For
example, the names of data stores on primitive-level DFDs often correspond to the names of data
entities in entity-relationship diagrams, and the data elements in data flows on DFDs must be
attributes of entities and relationships in entity-relationship diagrams.
The Process of Conceptual Data Modeling
You typically begin conceptual data modeling by developing a data model for the system being
replaced, if a system exists. An E-R data model evolves from project identification and selection
through analysis as it becomes more specific and is validated by more detailed analysis of system
needs. In the design phase, the final E-R model developed in analysis is matched with designs for
systems inputs and outputs and is translated into a format that enables physical data storage
decisions. During physical design, specific data storage architectures are selected, and then, in
implementation, files and databases are defined as the system is coded. Through the use of the
project repository, a field in a physical data record can, for example, be traced back to the
conceptual data attribute that represents it on an E-R diagram. Thus, the data modeling and
design steps in each of the SDLC phases are linked through the project repository.
Deliverables and Outcomes
The primary deliverable from the conceptual data-modeling step within the analysis phase is an
entity-relationship (E-R) diagram. Second deliverable is a set of entries about data objects to be

1
stored in repository or project dictionary. Repository links data, process, and logic models of
an IS. Data elements included in the DFD must appear in the data model and vice versa.
Gathering Information for Conceptual Data Modeling
You typically do data modeling from a combination of perspectives. The first perspective is
called the top-down approach. It derives the data model from an intimate understanding of the
nature of the business, rather than from any specific information requirements in computer
displays, reports, or business forms.
Alternatively, you can gather the information for data modeling by reviewing specific business
documents—computer displays, reports, and business forms—handled within the system. This
second perspective of gaining an understanding of data is often called a bottom-up approach.
Table: Questions to Ask to Develop Accurate and Complete Data Models

Introduction to Entity-Relationship Modeling

The basic entity-relationship modeling notation uses three main constructs: data entities,
relationships, and their associated attributes. An entity-relationship diagram (or E-R diagram)
is a detailed, logical, and graphical representation of the data for an organization or business
area. The E-R diagram is a model of entities in the business environment, the relationships or
associations among those entities, and the attributes or properties of both the entities and their
relationships. A rectangle is used to represent an entity, and lines are used to represent the

2
relationship between two or more entities. The notation for E-R diagrams appears in the below
figure.

Figure: Entity-relationship diagram notations: basic symbols, relationship degree, and

relationship cardinality.
Entities
An entity is a person, place, object, event, or concept in the user environment about which the
organization wishes to maintain data. An entity has its own identity, which distinguishes it from
every other entity. Some examples of entities follow:
 Person: EMPLOYEE, STUDENT, PATIENT
 Place: STATE, REGION, COUNTRY, BRANCH
 Object: MACHINE, BUILDING, AUTOMOBILE, PRODUCT
 Event: SALE, REGISTRATION, RENEWAL
 Concept: ACCOUNT, COURSE, WORK CENTER
You need to recognize an important distinction between entity types and entity instances. An
entity type is a collection of entities that share common properties or characteristics. Each entity
type in an E-R model is given a name. Because the name represents a set of entities, it is

3
singular. Also, because an entity is an object, An object represents a person, place, event, or
transaction that is significant to the
Information system. An object has certain attributes, which are characteristics that describe the
object.
For example, if you own a car, it has attributes such as make, model, and color. We use a simple
noun to name an entity type. We use capital letters in naming an entity type, and in an E-R
diagram, the name is placed inside a rectangle representing the entity, for example:

An entity instance (or instance) is a single occurrence of an entity type. An entity type is
described just once in a data model, whereas many instances of that entity type may be
represented by data stored in the database. For example, most organizations have one
EMPLOYEE entity type, but hundreds (or even thousands) of instances of this entity type may
be stored in the database.
Attributes
Each entity type has a set of attributes associated with it. An attribute is a property or
characteristic of an entity that is of interest to the organization (relationships may also have
attributes). Following are some typical entity types and associated attributes:
 STUDENT: Student_ID, Student_Name, Address, Phone_Number, Major
 AUTOMOBILE: Vehicle_ID, Color, Weight, Horsepower
 EMPLOYEE: Employee_ID, Employee_Name, Address, Skill

We use nouns with an initial capital letter followed by lowercase letters in naming an attribute.
In E-R diagrams, we represent an attribute by placing its name inside the rectangle that
represents the associated entity. In many E-R drawing tools, such as Microsoft Visio, attributes
are listed within the entity rectangle under the entity name.
Candidate Keys and Identifiers
Every entity type must have an attribute or set of attributes that distinguishes one instance from
other instances of the same type. A candidate key is an attribute (or combination of attributes)
that uniquely identifies each instance of an entity type. A candidate key for a STUDENT entity
type might be Student_ID. Sometimes more than one attribute is required to identify a unique
entity.
Some entities may have more than one candidate key. One candidate key for EMPLOYEE is
Employee_ID; a second is the combination of Employee_Name and Address (assuming that no
two employees with the same name live at the same address). If more than one candidate key is
involved, the designer must choose one of the candidate keys as the identifier.
An identifier is a candidate key that has been selected to be used as the unique characteristic for
an entity type. Identifiers should be selected carefully because they are critical for the integrity of
data.
You should apply the following identifier selection rules:

4
1. Choose a candidate key that will not change its value over the life
of each instance of the entity type. For example, the combination of
Employee_Name and Address would probably be a poor choice as a primary key for
EMPLOYEE because the values of Employee_Name and Address could easily change during an
employee’s term of employment.
2. Choose a candidate key such that for each instance of the entity, the Attribute is guaranteed to
have valid values and not be null. To ensure Valid values, you may have to include special
controls in data entry And maintenance routines to eliminate the possibility of errors. If the
candidate key is combination of two or more attributes, make sure that all parts of the key have
valid values.
3. Avoid the use of so-called intelligent keys, whose structure indicates Classifications, locations,
and other entity properties. For example, the first two digits of a key for a PART entity may
indicate the warehouse Location. Such codes are often modified as conditions change, which
Renders the primary key values invalid.
4. Consider substituting single-attribute surrogate keys for large composite keys. For example, an
attribute called Game_ID could be used for the Entity GAME instead of the combination of
Home Team and Visiting Team.
For each entity, the name of the identifier is underlined on an E-R diagram. The following
diagram shows the representation for a STUDENT entity type using E-R notation:

Multivalued Attributes
A multivalued attribute may take on more than one value for each entity instance. Suppose that,
Skill is one of the attributes of EMPLOYEE. If each employee can have more than one Skill,
then it is a multivalued attribute. During conceptual design, two common special symbols or
notations are used to highlight multivalued attributes. The first is to use curly brackets around the
name of the multivalued attribute, so that the EMPLOYEE entity with its attributes is
diagrammed as follows:

5
the primary key is listed immediately below the entity
name with the notation PK, and the primary key is underlined. All required attributes
(that is, an instance of STUDENT must have values for Student_ID and
Name) are in bold.
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
 Relationships are the glue that hold together the various components of an E-Rmodel.
A relationship is an association between the instances of one or more entity types that are of
interest to the organization. An association usually means that an event has occurred or that some
natural linkage exists between entity instances. For this reason, relationships are labeled with
verb phrases. For example, a training department in a company is interested in tracking which
training courses each of its employees has completed. This information leads to a relationship
(called Completes) between the EMPLOYEE and COURSE entity types that we diagram as
follows:

As indicated by the lines, this relationship is considered a many-to-many relationship: Each

employee may complete more than one course, and each course may be completed by more than
one employee. More significantly, we can use the Completes relationship to determine the
specific courses that a given employee has completed. Conversely, we can determine the identity
of each employee who has completed a particular course.
Degree of a Relationship
The degree of a relationship is the number of entity types that participate in that relationship.
Thus, the relationship Completes, illustrated previously, is of degree two because it involves two

6
entity types: EMPLOYEE and COURSE (as you can see from the above figure). The three most
common relationships in E-R diagrams are:
 Unary (degree one)
 Binary (degree two) and
 Ternary (degree three)
Higher-degree relationships are possible, but they are rarely encountered in practice.
Unary Relationship
Also called a recursive relationship, a unary relationship is a relationship between the instances
of one entity type. Two examples are shown in Figure below. In the first example, Is_married_to
is shown as a one-to-one relationship between instances of the PERSON entity type. That is,
each person may be currently married to one other person. In the second example, Manages is
shown as a one-to-many relationship between instances of the EMPLOYEE entity type. Using
this relationship, we could identify (for example) the employees who report to a particular
manager or, reading the Manages relationship in the opposite direction, who the manager is for a
given employee.

Binary Relationship
A binary relationship is a relationship between instances of two entity types and is the most
common type of relationship encountered in data modeling. Figure 7-6 shows three examples.
The first (one to-one) indicates that an employee is assigned one parking place, and each parking
place is assigned to one employee. The second (one-to-many) indicates that a product line may
contain several products, and each product belongs to only one product line. The third (many to-

7
many) shows that a student may register for more than one course and that each course may have
many student registrants.
Ternary Relationship
A ternary relationship is a simultaneous relationship among instances of three entity types. In
the example shown in Figure 7-6, the relationship Supplies tracks the quantity of a given part
that is shipped by a particular vendor to a selected warehouse. Each entity may be a one or a
many participant in a ternary relationship (in Figure 7-6, all three entities are many
participants).Note that a ternary relationship is not the same as three binary relationships.
For example, Unit_Cost is an attribute of the Supplies relationship in Figure 7-6. Unit_Cost
cannot be properly associated with any of the three possible binary relationships among the three
entity types (such as that between PART and VENDOR) because Unit_Cost is the cost of a
particular PART shipped from a particular VENDOR to a particular WAREHOUSE.
Cardinalities in Relationships
Suppose that two entity types, A and B, are connected by a relationship. The cardinality of a
relationship is the number of instances of entity B that can (or must) be associated with each
instance of entity A. For example, consider the following relationship for DVDs and movies:

Clearly, a video store may stock more than one DVD of a given movie. In the terminology we
have used so far, this example is intuitively a “many” relationship. Yet, it is also true that the
store may not have a single DVD of a particular movie in stock. We need a more precise notation
to indicate the range of cardinalities for a relationship.
Minimum and Maximum Cardinalities
The minimum cardinality of a relationship is the minimum number of instances of entity B that
may be associated with each instance of entity A. In the preceding example, the minimum
number of DVDs available for a movie is zero, in which case we say that DVD is an optional
participant in the Is_stocked_as relationship. When the minimum cardinality of a relationship is
one, then we say entity B is a mandatory participant in the relationship. The maximum
cardinality is the maximum number of instances. For our example, this maximum is “many” (an
unspecified number greater than one). Using the notation from the above figure, we diagram this
relationship as follows:

The zero through the line near the DVD entity means a minimum cardinality of zero, whereas the
crow’s-foot notation means a “many” maximum cardinality. It is possible for the maximum
cardinality to be a fixed number, not an arbitrary “many” values. For example, see the Supplies
relationship in Figure 7-3A, Which indicates that each item involves at most four suppliers