Flat-File vs. Database Management Systems
Flat-File vs. Database Management Systems
DATABASE MANAGEMENT SYSTEMS Figure 9-2(a) presents a simple overview of the database approach with the
same users and data requirements. The most obvious change from the flat-
Overview of the Flat-File versus Database Approach file model is the pooling of data into a common database that is shared by
Many so-called legacy systems are characterized by the flat-file approach all the users.
to data management. In this environment, users own their data files.
Exclusive ownership of data is a natural consequence of two problems
associated with the legacy-system era. The first problem is a business
culture that erects barriers between organizational units that inhibit
entity-wide integration of data. The second problem stems from
limitations in flat-file management technology, which require data files to
be structured to the unique needs of the primary user.
As information needs arise, users send formal requests for computer Accountants and auditors work extensively with databases as part of their
applications to the systems professionals (programmers) of the day-to-day activities. Whether preparing financial statements, tagging data
organization. The requests are handled through formal systems attributes for XBRL reporting, or extracting financial data from tables during
development procedures, which produce the programmed applications. By the conduct of audit tests, accountants and auditors need to understand
keeping access authority separate from systems development (application how the data are structured. The purpose of this section, therefore, is to
programming), the organization is better able to control and protect the explain the basics of data modeling, which will serve to guide the
database. Intentional and unintentional attempts at unauthorized access accountant when performing database- related tasks. Toward this end, the
are more likely to be discovered when these two groups work subsections that follow introduce relational concepts, database
independently. terminology, and database design techniques. The final subsection employs
the top-down approach to develop a data model from scratch.
Entity, Relation, Occurrence, and Attributes ANOMALIES, STRUCTURAL DEPENDENCIES, AND DATA
An entity is anything about which the organization wishes to capture data. NORMALIZATION
Entities may be physical, such as inventories, customers, and employees. This section deals with why database tables need to be normalized. In other
They may also be conceptual, such as accounts receivable and accounts words, why is it necessary for the organization’s database to form an
payable. Database developers identify entities and prepare a model of elaborate network of normalized tables linked together? Why, instead, can
them. The graphical technique used to depict the model is called an entity we not simply consolidate the views of one user (or several) into a single
relationship (ER) diagram. Each entity that is represented in an ER diagram common table from which all data needs may be met?
corresponds to a table in the physical database. This is a high-level
perspective of the overall schema, which presents only the key entities and Database Anomalies
their relationships; it does not show the data types and keys contained
The answer to the questions asked in previous section is that
within the entities. The term relation describes how data in one entity are
related to data in another entity.
improperly normalized tables can cause DBMS processing
As a matter of convention, entities are named in the singular noun form, problems that restrict, or even deny, users’ access to the
such as Customer rather than Customers. The term occurrence (or instance) information they need. Such tables exhibit negative operational
is used to describe the number of items associated with an entity. symptoms called anomalies. Specifically, these are the update
Attributes are the data elements that define an entity. anomaly, the insertion anomaly, and the deletion anomaly.
Associations and Cardinality UPDATE ANOMALY. The update anomaly is the result of data
The term association describes the nature of the functional connection redundancy in an unnormalized table.
between two entities in a relation. This association is represented in an ER
diagram by a verb label on the connecting line such as ships, requests, and
INSERTION ANOMALY. To demonstrate the effects of the
receives. Cardinality is the degree of association between two entities.
Simply stated, cardinality describes the number of possible occurrences in
insertion anomaly, assume that a new vendor has entered
one table that is associated with a single occurrence in a related table. the marketplace. The organization does not yet purchase
Four basic forms of cardinality are possible: zero or one (0,1), one and only from the vendor but may wish to do so in the future. In the
one (1,1), zero or many (0,M), and one or many (1,M). These are combined meantime, the organization wants to add the vendor to the
to describe the cardinality between entities in a relation. database.
The Physical Database Tables DELETION ANOMALY. The deletion anomaly involves the
The data model is the blueprint for the physical database tables that unintentional deletion of data from a table.
constitute the database. The tables are constructed based on the entity
specifications in the model. The attributes form columns with the attribute The presence of the deletion anomaly is less conspicuous but potentially
name at the top of each column. Occurrences form rows that cut across the more serious than the update and insertion anomalies. A flawed database
columns and at their intersection is an attribute value that pertains to the design that prevents the insertion of records or requires the user to perform
occurrence. The term tuple is the formal name for a row in the table, Codd excessive updates attracts attention quickly. The deletion anomaly,
gave a precise definition when he first introduced this term. Accordingly, however, may go undetected, leaving the user unaware of the loss of
properly designed tables possess the following four characteristics: important data until it is too late. This can result in the unintentional loss
1. The value of at least one attribute in each tuple must be unique. of critical accounting records and the destruction of audit trails. Proper
This attribute is the primary key. The values of the other table design, therefore, is not just an operational efficiency issue; it carries
(nonkey) attributes in the row need not be unique. internal control significance that accountants need to recognize.
2. All attribute values in any column must be of the same class.
3. Each column in a given table must be uniquely named. However,
Normalizing Tables in a Relational Database
different tables may contain columns with the same name.
The database anomalies described earlier in the text are symptoms of
4. Tables must conform to the rules of normalization. This means structural problems within tables called dependencies. Specifically, these
they must be free from structural dependencies, including
are known as repeating groups, partial dependencies, and transitive
repeating groups, partial dependencies, and transitive
dependencies. The normalization process involves identifying and
dependencies.
removing structural dependencies from the table(s) being modeled such
that the resulting 3NF table designs will meet two conditions:
Linkages between Relational Tables 1. All nonkey (data) attributes in the table are dependent on (defined by)
Logically related tables need to be physically connected to achieve the the primary key.
associations described in the data model. This is accomplished by using 2. All nonkey attributes are independent of the other nonkey attributes.
foreign keys. The foreign keys are embedded in the related table but not
always. The degree of cardinality between the related tables determines In other words, a 3NF table is one in which the primary key of a table wholly
the method used for assigning foreign keys. With foreign keys in place, a and uniquely defines each attribute in the table. Furthermore, none of the
computer program can be written to navigate among the tables of the table attributes is defined by an attribute other than the primary key.
database and provide users with the data they need to support their day-
to-day tasks and decision-making responsibilities. REPRESENT THE VIEW AS A SINGLE TABLE. The next step is to
represent the view as a single table that contains all of the view
User Views attributes.
A user view was defined earlier as the set of data that a particular user
sees. Examples of user views are computer screens for entering or viewing REMOVE REPEATING GROUP DATA. The first step in correcting
data, management reports, or source documents such as an invoice and a structural dependencies is to determine if the table under review
purchase order. Views may be digital or hard copy, but in all cases, they contains repeating groups. Repeating group data occur when
derive from underlying database tables. Simple views may be constructed multiple values for a particular attribute exist in a specific tuple.
from a single table, while more complex views may require several tables.
The task of identifying all views and translating them into normalized tables
REMOVE TRANSITIVE DEPENDENCIES. The final step in resolving
is an important responsibility of database designers as it has internal control
implications. The issues and techniques related to this task are examined structural dependencies is to remove transitive dependencies. A
next. transitive dependency occurs in a table where nonkey attributes
are dependent on another nonkey attribute and independent of
the table’s primary key.
REMOVE PARTIAL DEPENDENCIES. Next we check to see if the 2. NORMALIZE DATA MODEL AND ADD PRIMARY KEYS. Figure 9-
resulting tables contain partial dependencies. A partial 27 presents a normalized data model. The following section
dependency occurs when one or more nonkey attributes are describes the normalization procedures that produced this model:
dependent on (defined by) only part of the primary key, rather than 1. Repeating Group Data in Status Report Entity. The nonkey attributes of
the whole key. This can occur only in tables that have composite Supplier Number, Supplier Name, Supplier Address, and Supplier Tel
Number are repeating group data in the Status Report. These data were
(two or more attributes) primary keys.
removed and placed in a new table called Supplier and assigned a primary
key of Supplier number. The remaining entity, which now contains only
LINKING THE NORMALIZED TABLES. At this point, the original inventory attributes was renamed Inventory.
single-table structure has been reduced to the four normalized but 2. Repeating Group Data in Purchase Order Entity. The attributes of Part
independent tables. The tables contain the sample data used in the Number, Description, Order Quantity, and Unit Cost are repeating group
original single- table structure. Data redundancy in the original data. To resolve this, these attributes data were removed to a new entity
single-table structure has been eliminated from the more efficient called PO Item Detail, which was assigned a primary key that is a composite
structure. To work together in the physical database, however, the of Part Number and PO Number.
3. Partial Dependency in PO Item Detail Entity. An analysis of the PO Item
tables in this data model need to be linked via foreign keys. This
Detail entity reveals that its composite primary key uniquely defines only
requires first determining the cardinality between the tables and Order Quantity. The attributes of Description and Unit Cost are partially
then assigning foreign keys. dependent on Part Number and therefore removed from the table leaving
Order Quantity as the only nonkey attribute. Unit Cost was added to the
Accountants and Data Modeling Inventory entity. Description was already a listed attribute of the Inventory
Although most accountants will not be directly responsible for normalizing entity.
an organization’s databases, they should have an understanding of the 4. Transitive Dependency in Purchase Order Entity. The attributes of
process and be able to determine whether financial data are normalized Supplier Name, Supplier Address, and Supplier Tel Number are transitive
properly to avoid anomalies. For example, the update anomaly can dependencies, which are defined by Supplier Number. These attributes
generate conflicting and/or obsolete database values in accounts, the were therefore removed from the Purchase Order entity.
insertion anomaly can result in unrecorded transactions and incomplete 5. Repeating Group Data in Receiving Report Entity. The attributes Part
audit trails, and the deletion anomaly can cause the loss of accounting Number, Quantity Received, and Condition Code are repeating groups in
records and the destruction of audit trails. Also, the conduct of many the Receiving Report entity and were removed to a new entity called Rec
financial audit procedures involves accessing data stored in normalized base Report Item Detail. A composite key composed of Part number and Rec Rept
tables. An organization’s financial database may consist of thousands of Number was assigned.
normalized tables and navigating such a network requires an understanding 6. Transitive Dependency in Receiving Report Entity. The attributes
of data structures. Supplier Name, Supplier Address, and Supplier Tel Number are defined by
Supplier Number and not defined by the primary key PO Number. They are
Top-Down Approach to Designing Relational Databases Supplier entity attributes and therefore removed from the Purchase Order
This section examines the steps involved in creating a relational entity.
database using a top-down approach. Keep in mind that database
design is an element of a much larger systems development 3. DETERMINE CARDINALITIES AND ADD FOREIGN KEYS. The next
process that involves extensive analysis of user needs. The focus step in view modeling is to determine the cardinality between
will be on the following phases of database design, which are entities and link the entities with foreign keys. Recall that
known collectively as view modeling: cardinalities represent business rules. Sometimes, the rules are
1. Identify the views to be modeled. obvious and are the same for all organizations. For example, the
2. Normalize the data model and add primary keys. normal cardinality between a Customer entity and a Sales Order
3. Determine cardinalities and add foreign keys. entity is 1:M. This signifies that one customer may place many
4. Construct the physical database. orders during a sales period. The cardinality would never be 1:1.
This would mean that the organization restricts each customer to a
5. Prepare the physical user views.
single sale, which is illogical. Sometimes, the cardinality between
entities is not apparent because different rules may apply in
1. IDENTIFY THE VIEWS TO BE MODELED. View modeling begins by
different organizations. If the database is to function properly, its
identifying the relevant views of the business function in question.
designers need to understand the organization’s business rules as
This involves user interviews, and other techniques, to determine
well as the specific needs of individual users.
what users do and what information they need to support their
tasks. To demonstrate view identification, we will analyze the
The view modeling process described previously in the chapter
following key features of a simplified purchasing function:
1. The purchasing agent reviews the inventory status report for items that involved only one business function— the purchases system—and
need to be reordered. the example entities that resulted constitute only a small portion
2. The agent selects a supplier and prepares a digital purchase order from of that system. A modern company would employ thousands of
his terminal. views. Combining the data needs of all users into a single entity-
3. The agent prints a copy of the purchase order and sends it to the supplier. wide schema is called view integration. This involves the
4. The supplier ships the inventory to the company. Upon its arrival, the consolidation of the attributes from all user views into a common
receiving clerk inspects the inventory and prepares the digital receiving set of normalized entities that meet the following conditions:
report. The computer system automatically updates the inventory records.
1. An entity must consist of two or more occurrences.
2. No two entities may have the same primary key. The exceptions to this
This description identifies three views: (1) Inventory Status Report, (2) are entities with composite keys that comprise the primary keys of other
Purchase Order, and (3) Receiving Report. The primary key should logically entities.
define the nonkey attributes and uniquely identify each occurrence in the 3. No nonkey attribute may be associated with more than one entity. For
entity. Sometimes this is accomplished by using a simple sequential code example, if Customer Address is an attribute of the Customer entity, it
such as an invoice number, check number, and purchase order number. cannot also be an attribute of another entity. All views that use Customer
Sequential codes, however, are not always appropriate keys. Block codes, Address will retrieve it from the Customer entity.
group codes, alphabetic codes, and mnemonic codes can also be assigned
as primary keys.
that are free of the update, insert, and deletion anomalies and sufficiently
4. CONSTRUCT THE PHYSICAL DATABASE. Figure 9-28 illustrates rich to serve the needs of all users.
the 3NF table structures for the physical database. The dotted lines Databases in a Distributed Environment
represent the primary and foreign keys linking the tables. The next Chapter 1 introduced the concept of distributed data processing
step is to create the physical tables and populate them with data. (DDP) as an alternative to the centralized approach. Most modern
This is an involved step that must be carefully planned and organizations use some form of distributed processing and
executed, and may take many months in a large installation. networking to process their transactions. Some companies process
Programs will need to be written to transfer organization data all of their transactions in this way. An important consideration in
currently stored in flat files or legacy databases to the new planning a distributed system is the location of the organization’s
relational tables. Data currently stored on paper documents will be database. In addressing this issue, the planner has two basic
entered into database tables manually. Once this is done, the options: databases can be centralized, or they can be distributed.
physical user views can be produced. Distributed databases fall into two categories: partitioned and
replicated.
5. PREPARE THE PHYSICAL USER VIEWS. The normalized tables
should be rich enough to support the views of all users of the CENTRALIZED DATABASES. Under the centralized database
system being modeled. The fields in the user view are cross- approach, remote users send requests via terminals for data
referenced via circled numbers to the attributes in the supporting to the central site, which processes the requests and
tables. Keep in mind that these tables may also provide data for transmits the data back to the user. The central site performs
many other views not shown here, such as the receiving report, the functions of a file manager that services the data needs of
purchase requisition listing, inventory status report, and vendor the remote users. Earlier in the chapter, three primary
purchases activity report. Database developers use SQL to identify advantages of the database approach were presented: the
which tables to use and which attributes to select to create the reduction of data storage costs, the elimination of multiple
user view. SQL commands needed to produce the inventory status update procedures, and the establishment of data currency
report (i.e., the firm’s data files reflect accurately the effects of its
The SELECT command identifies all of the attributes to be transactions). Achieving data currency is critical to database
contained in the view. integrity and reliability. However, in the DDP environment,
The FROM command identifies the tables used in creating the this can be a challenging task.
view.
The WHERE command specifies how rows in the Inventory, Data Currency in a DDP Environment
During data processing, account balances pass through a state of temporary
Part-Supplier, and Supplier tables are to be matched to create
inconsistency in which their values are incorrectly stated. This occurs during
the view. the execution of any accounting transaction.
Multiple expressions may be linked with the AND, OR, and
NOT operators. Only records whose quantities on hand have Database Lockout
fallen to or below their reorder points will be selected for the To achieve data currency, simultaneous access to individual data elements
view and the user will not see the many thousands of other by multiple sites needs to be prevented. The solution to this problem is to
inventory items that have adequate quantities available. use a database lockout, which is a software control (usually a function of
the DBMS) that prevents multiple simultaneous accesses to data.
These SQL commands will be saved in a user program called a query. To
view the Inventory Status Report, the purchasing agent executes the query DISTRIBUTED DATABASES. Distributed databases can be
program. Each time this is done, the query builds a new view with current distributed using either the partitioned or replicated
data from the Inventory and Vendor tables. By providing the user with his technique.
or her personal query, rather than permitting access to the underlying base
tables, the user is limited only to authorized data. A report program is used
Partitioned Databases
to make the view visually attractive and easy to read. Column headings can
The partitioned database approach splits the central database into
be added to produce a hard-copy or computer screen report. The report
segments or partitions that are distributed to their primary users. The
program will suppress unnecessary data from the view, such as duplicated
advantages of this approach are:
fields and the key values in the Inventory/Vendor link table. These keys are
Storing data at local sites increases users’ control.
necessary to build the view, but are not needed in the actual report.
Permitting local access to data and reducing the volume of data
that must be transmitted between sites improve transaction
COMMERCIAL DATABASE SYSTEM processing response time.
Modeling the data needs of thousands of user views is a daunting Partitioned databases can reduce the potential for disaster. By
undertaking when creating an entity-wide database from scratch. having data located at several sites, the loss of a single site
To facilitate this task, modern commercial database systems come cannot terminate all data processing by the organization.
equipped with a core schema, normalized tables, and templates
for thousands of views. Commercial systems are designed to The partitioned approach works best for organizations that require
comply with proven industry best practices and to satisfy the minimal data sharing among users at remote sites. To the extent that
remote users share data, the problems associated with the centralized
most common needs of different client organizations.
approach still apply. The primary user must now manage requests for data
from other sites. Selecting the optimum host location for the partitions will
Working from a commercial database package, developers can thus focus
minimize data access problems. This requires an in-depth analysis of end-
on configuring predefined views to accommodate specific user needs within
user data needs.
their organizations rather than starting from scratch.
Database vendors cannot, however, anticipate the information needs of all
users in advance. Therefore, new entities and new attributes may need to THE DEADLOCK PHENOMENON. In a distributed environment, it is
be added to the core schema. Although configuring the core database in possible that multiple sites will lock out each other, thus preventing
this fashion is far more efficient than working from scratch, the objective is each from processing its transactions. A deadlock occurs here
the same. The database designer must produce a set of integrated tables because there is mutual exclusion to data, and the transactions
are in a wait state until the locks are removed. This can result in to use the same data and do not conflict. However, multiple sales order
transactions being incompletely processed and corruption of the transactions involving both read and write operations will potentially
database. A deadlock is a permanent condition that must be conflict.
The second part of the control process is to time stamp each transaction. A
resolved by special software that analyzes each deadlock condition
system-wide clock is used to keep all sites, some of which may be in
to determine the best solution. Because of the implications for different time zones, on the same logical time. Each time stamp is made
transaction processing, accountants should be aware of the issues unique by incorporating the site’s identification number. When
pertaining to deadlock resolutions. transactions are received at each site, they are examined first for potential
conflicts. If conflicts exist, the transactions are entered into a serialization
DEADLOCK RESOLUTION. Resolving a deadlock usually involves schedule. An algorithm is used to schedule updates to the database based
sacrificing one or more transactions. These must be terminated to on the transaction time stamp and class. This method permits multiple
complete the processing of the other transactions in the deadlock. inter- leaved transactions to be processed at each site as if they were serial
events.
The preempted transactions must then be reinitiated. In
preempting transactions, the deadlock resolution software
Distributed Databases and the Accountant
attempts to minimize the total cost of breaking the deadlock.
The decision to distribute databases is one that should be entered
Although not an easy task to automate, some of the factors that
into thoughtfully. There are many issues and trade-offs to consider.
influence this decision are as follows:
1. The resources currently invested in the transaction. This may be
Some of the most basic questions to be addressed are as follows:
measured by the number of updates that the transaction has already Should the organization’s data be centralized or distributed?
performed and that must be repeated if the transaction is terminated. If data distribution is desirable, should the databases be
2. The transaction’s stage of completion. In general, deadlock resolution replicated or partitioned?
software will avoid terminating transactions that are close to completion. If replicated, should the databases be totally replicated or
3. The number of deadlocks associated with the transaction. Because partially replicated?
terminating the transaction breaks all deadlock involvement, the software
If the database is to be partitioned, how should the data
should attempt to terminate transactions that are part of more than one
deadlock. segments be allocated among the sites?
Replicated Databases The choices involved in each of these questions impact the
In some organizations, the entire database is replicated at each site. organization’s ability to maintain database integrity. The
Replicated databases are effective in companies in which there preservation of audit trails and the accuracy of accounting records
exists a high degree of data sharing but no primary user. Because are key concerns. Clearly, these are decisions that the modern
common data are replicated at each site, the data traffic between accountant should understand and influence intelligently.
sites is reduced considerably.
Concurrency Control
Database concurrency is the presence of complete and accurate
data at all remote sites. System designers need to employ methods
to ensure that transactions processed at each site are accurately
reflected in the databases at all other sites. This task, while
problematic, has implications for accounting records and is a
matter of concern for accountants. A commonly used method for
concurrency control is to serialize transactions. This involves
labeling each transaction by two criteria.