Chapter 8 • Basic Systems Concepts and Tools 349alternative will lead to one approach selected as the chosen
strategy for designing and developing the physical system.
Making the Logical To-Be model “physical”
requires additional analysis and a host of decisions.
Techniques for physical design include those that represent
how processes and data stores will be partitioned, how
program control will be handled, and how the database
will be organized. We will illustrate in this section several
techniques that facilitate the communications between
system users and developers, which are used to help ensure
that system requirements are properly met. There are a
host of techniques used to communicate between various
systems developers (e.g., a program structure chart to
communicate the design of a computer program between
system architects and programmers), which are documented
in other sources (e.g., see Hoffer et al., 2010).
Data design issues must also be resolved for a
specific database and application architecture. Because
database structures embody business rules, getting system
requirements right is at the heart of database design. Thus,
there are often check points when system users and
developers review database designs. The number, content,
and relationship of data tables and their data elements
must be defined consistent with business rules. For
example, a closer look at the accounts payable system
reveals that purchase orders, receipts, and invoices may
contain several similar data elements. An Item Master
table is created into which data about all invoiced items
must be entered. Figure 8.17 shows the Item Master table
and its relationship to other tables in the accounts payable
database. In each table, there is a data attribute which
uniquely identifies each instance of that data; for example,
ItemNumber is the identifier for the Item Master table (so
it is in boldface and underlined). Attributes that must have
a value for each row in a table are in boldface; for
example, each Item Master must have an ItemName and
an ItemDescription. Notation on the relationship lines
between tables indicate how many rows of one table may
relate to rows in another table. For example, there may be
many Invoice Detail rows for each row in the Item Master
table, and an Invoice Detail row must have an associated
Item Master row (this makes sense; why have an Invoice
Detail entry that isn’t for some item). Invoice Detail also
includes the ItemNumber attribute, which is the way an
Invoice Detail row implements the relationship to its
associated Item Master row. The names on the relation-
ship lines help people to read the diagram; for example, a
Check Register entry Pays for an Invoice, and each
Invoice is paid by some Check Register entry. All of this
notation shows important business rules that the database
and information system must enforce.
Our final example for the Physical To-Be model is
layouts for system interfaces with end users. The most
common interfaces are online screen layouts and reportFIGURE 8.17 Entity-Relationship Diagram for Accounts Payable Database
CHECK REGISTERVENDORCheckNumberVendorlD PONumber
PODateInvoiceNumberVendorNameVendorAddress
VendorCity
VendorPostalCode
VendorStateOrProvince
VendorCountry
VendorPhoneNumber
VendorFaxNumber
VendorEMailContactName
ContactTitlePays for / Is paid by
+Is generated by / GeneratesHas detail of / Is detail forHas detail of / Is detail forIs bill for / Is billed onIs ordered on / Is order forIs receipt for / Is receivedRequiredByDate
PromisedByDateCharges / Owed toCheckDate
PaidAmount
AccountNumberInvoiceNumberReceiptNumberVendorID
PayablesStatus
InvoiceDate
ShipDate
ShippedTo
ShippedVia
ShippingCost
PONumberPONumber
ReceivedDate
ReceivedBy
AcceptanceRECEIPTPURCHASE ORDERInvoiceDetailID
InvoiceNumber
ItemNumber
Quantity
PricePerUnit
PaymentTerms
DiscountINVOICE DETAILItemNumber
ItemName
ItemDescription
CategoryIDITEM MASTERPODetailID
ItemNumber
Quantity
DiscountUnitPrice
SalesPrice
SalesTax
PONumberPO DETAILINVOICE/PAYABLE++