Managing Information Technology

Chapter 8 • Basic Systems Concepts and Tools 347

Accounts Payable Project Data Dictionary Entry for PO Number

Label

Alternate Names

Definition

Example

Field Name

Input Format

Output Format

Edit Rules

Additional Notes

Storage Type

Default Value

Required

PO Number

Purchase Order Number. PO Number. PO#

Unique identifier for an individual purchase order: alpha character designates

the division. The five digit number is assigned in sequential order at the time

of creation.

C07321

PO_Num

A##### (single alpha followed by five integers, no spaces or symbols allowed)

Same as input format

No values below 1000 allowed in numeric portion: currently using A–E as

division code indicators.

At conversion to the former system in 1991, numbers below 1000 were

discontinued. Each division writes about 700–1,000 purchase orders per year.

PO Numbers cannot be re-used.

Alphanumeric, no decimals

None

Each purchase order must have one PO Number.

Prepared by: JDAustin Date: 8/27/11 Version No.: 1

FIGURE 8.14 Data Dictionary Sample Entry

Includes

Purchase Order

PO_No

PO_Date

Vendor_ID

Vendor Invoice

Vendor_Invoice_No

Vendor_ID

Invoice_Date

Invoice_Amount

FIGURE 8.15 Entity-Relationship Diagram for Invoice and PO

model(defined and illustrated in Chapter 4) is created by
logically defining the necessary and sufficient relation-
ships among system data. A data model, as was discussed
in Chapter 4, consists of data entities (i.e., people, places,
things, concepts) and their associated data elements (char-
acteristics), relationships between the data entities, and
instances of the entities and relationships. A data model
documents the same data that are in the data stores from
the DFDs but focuses on greater details and the relation-
ships between data, rather than on data usage. There is not
necessarily a one-to-one mapping of data stores to entities
on a data model, because of the different perspectives
DFDs and data models have on data.
As mentioned in Chapter 4, the most common nota-
tion for a data model is an entity-relationship diagram,
also known as the E-R diagram or ERD. Figure 8.15 shows
that the data entity “Vendor Invoice” is related to the data
entity “Purchase Order” by the relation type “Includes.”
Furthermore, the notation next to the data entities shows
that a many-to-one relationship has been defined. This
means that one invoice can refer to only one purchase
order but that a purchase order number may have many
invoices associated with it. The attributes of each data
entity are shown inside the rectangles (only a sample of
attributes are included); that attribute which is unique to

each instance of the entity is underlined (e.g., PO_No for

Purchase Order), and any attribute whose value must be

present for each instance of the entity is in bold (e.g., any

purchase order must have a date).

The E-R diagram in Figure 8.15 thus reflects an

existing business rule:

Vendor invoices cannot include items from

more than one purchase order.

The motivation for such a business rule could lie in

difficulties related to manual paper processing. However,

IT can be used to break this rule by eliminating the

problems of manually reconciling invoices to multiple

purchase orders. If this decision rule is changed, the E-R

diagram would be changed to reflect a new many-to-many

relationship desired in the Logical To-Be system.