Chapter 6 Elements of Database Systems 1 of 30 ACCO.docx

Chapter 6: Elements of Database Systems
1 of 30
ACCOUNTING INFORMATION SYSTEMS: A DATABASE
APPROACH
by: Uday S. Murthy, Ph.D., ACA and S. Michael Groomer,
Ph.D., CPA, CISA
Elements of Database Systems
Learning Objectives
After studying this chapter you should be able to:
• distinguish between the file-oriented approach and the
database approach
• discuss fundamental relational database concepts such as
composite and foreign
keys
• specify the types of relationships that can be represented in
database systems
• provide a detailed description of the relational database model
• discuss database integrity, emphasizing entity and referential
integrity in

particular
• explain and provide examples of validation rules in relational
database systems
• discuss how views and permissions can be used to restrict
access to sensitive
data in relational database systems
• explain the data dictionary concept
• describe the types of database languages
• construct SQL queries to extract information from relational
database systems
• discuss database backup and recovery methods
• explain concepts such as concurrency control
• explain in general terms concepts such as the object-oriented
approach to
developing database systems
The elements of computer-based information systems were
discussed in Chapter 2. In
this chapter we focus on the elements of database systems. As
discussed in Chapter 1,
the next generation of accounting systems will have an
enterprise-wide orientation and
will most likely be built on a database platform. We will first
differentiate between the
older file-oriented approach and the more recent database
approach. Various data

structure elements specific to database systems will then be
discussed. The major
2 of 30
types of database models will then be reviewed. The remainder
of the chapter will focus
exclusively on the relational database model, which has grown
to become widely
accepted as the platform of choice for robust enterprise
applications.
File-oriented and database approaches contrasted
The early applications of computer technology were in
automating transaction
processing systems. These early applications were developed
using COBOL. Each
transaction processing system was created and treated
independently with its own set
of files and programs. There was virtually no integration across
application areas. Most
business data processing systems developed in the 1970s and
the early 1980s
employed this approach. This approach to TPS is referred to as
the file-oriented
approach. A more modern approach is to develop an integrated
set of application
systems with all data stored in a shared repository, i.e., the
enterprise database. This
approach is referred to as the database approach. It is important

to note that a
significant number of file-oriented systems exist in many
businesses today. Most of
these file-oriented systems are written in COBOL and continue
to receive maintenance.
These systems will be around for some years to come due
primarily to the significant
investment businesses have made in these systems. The term
"legacy systems" is used
to describe these older COBOL systems. Systems administrators
in many organizations
have to grapple with the problems associated with interfacing
these legacy systems with
newer systems that operate in a database or 4GL environment.
Furthermore, many of
these legacy systems had to be overhauled to deal with the Y2K
problem, since their
"date" data structures typically allocated only two digits for the
year. The contrast
between the file-oriented and database approaches is most stark
in the context of
custom-developed accounting information systems. However,
as discussed in Chapter
3, many companies use “off-the-shelf” accounting software
packages such as
Quickbooks Pro, Peachtree, and Great Plains. Lower-end (less
expensive) accounting
packages tend to conform more to the file-oriented approach
while the higher-end (more
expensive) packages tend to conform more to the database
approach. Thus, the
discussion below of the file-oriented and database approaches is
also relevant in the
context of accounting software packages. Both the file-oriented
and the database
approaches will now be described, and the relative advantages

and drawbacks of each
will be discussed.
The file-oriented approach
As indicated above, the file-oriented approach involves creating
a set of files, as
needed, for each transaction processing application such as
sales or purchases. A set
of COBOL programs and data files are created to satisfy the
information needs of each
application. As shown in the figure on the next page, each
application's files and
programs are created and maintained independent of other
applications.
3 of 30
Duplication of files across applications is one consequence of
this independence. For
example, in the above figure, File A is used in application
program 1 and 3. However,
two instances of File A must be created - programs 1 and 3
cannot simply share File A
since there is no way of allowing concurrent access to the same
file in COBOL. Another
important characteristic of the file-oriented approach is that

each COBOL program is
required to define the data structures that will be used in the
program. For example, a
CUSTOMER file might have the following fields: CUSTOMER-
NO, NAME, STREET-
ADDRESS, CITY, STATE, and ZIP. The format of this file,
including the field names and
data types (e.g., text, numeric, date/time) must be explicitly
defined. Such definitions
constitute the "data structure" for a particular file. If you are
familiar with COBOL, you
might recall that every COBOL program has four divisions --
the identification division,
the environment division, the data division, and the procedure
division. The data division
is where the data structures are defined which are then
manipulated in the procedure
division. Thus, in the file-oriented approach, every program
defines all the data
structures it uses.
4 of 30
Drawbacks of the file-oriented approach
The most significant drawback of the file-oriented approach is
data redundancy or
duplication, which is caused by the lack of sharing of data
across applications. For
example, a marketing application would have to create its own
customer file, although a
customer file already exists in the sales application. The

resulting data redundancy or
duplication has many undesirable consequences. Apart from
merely consuming more
storage space, data redundancy can easily lead to data
inconsistencies. Adding new
data, changing existing data, or deleting data has to be repeated
for each instance of
the duplicate files. For example, consider the marketing and
sales application referred
to above. If a customer's address change is recorded in the sales
application but not the
marketing application, the result is inconsistent data across the
two applications with no
indication of which address is the correct address. Thus, data
redundancy can cause
data inconsistencies, which is more problematic than simply the
extra storage space
consumed by duplicate data.
A second drawback of the file-oriented approach is the
proliferation of files resulting
from each application creating its own files as needed, which
leads to data maintenance
becoming significantly more problematic. With several versions
of the same file in
different applications, ensuring consistency of data across all
applications becomes
more difficult as the number of files multiplies. A third
drawback of the file-oriented
approach is the length of time normally required for application
development. Files
needed for a new application must be created from scratch since
sharing of existing
files is not possible.
A fourth and rather significant disadvantage of the file-oriented
approach is the lack of

independence between the data structures and the application
programs that access
those data structures. As indicated earlier, the "data" division in
the COBOL program
defines the data structures of all files used in the program.
These data structures have
to be redefined in every COBOL program that accesses the same
file. Any change in a
data structure of a file has to be painstakingly effected in each
of the several COBOL
programs that access the file. The drawbacks of the file-oriented
approach are
summarized in the table on the next page.
5 of 30
Drawbacks of the File-Oriented Approach
Drawback Explanation
Data redundancy
Duplication of data (files) across applications
poses a data maintenance problem and can
potentially cause problems of data
inconsistencies. Excessive duplication also
results in high data storage costs.
Proliferation of files

The task of maintaining files can become
very complex as the number of applications
multiplies, since each application creates its
own set of files.
Lengthy application
development
Inability to share data in existing files
increases the time required to create new
applications, since all files needed for the
new application must be independently
created.
Lack of data
independence
Data structures and the procedures that
modify the data are both defined within the
same program (in the "Data" and
"Procedure" divisions). Data structures
and/or procedures cannot be independently
modified.
The Database Approach
In contrast to the file-oriented approach, the database approach
centers around creating
an organization wide repository of data that all applications and
all users can share.
Rather than having multiple instances of the same file, each set
of data is uniquely
stored, as shown in the figure that follows. Note that in the
database approach the term

"data set" is used instead of "file." Each application interfaces
with the data it needs by
accessing the appropriate data sets from the organization's
repository or database. The
"sharing" of data in the common repository, stored on disk, is
transparent to the users.
Concurrent access to the same data set is handled by the
database management
system. Note in the following figure (next page) that the DBMS
interfaces with the
operating system. The actual retrieval of the data sets stored on
disks is handled by the
operating system.
6 of 30
A database is an integrated repository of an organization's data
containing a series of
interrelated data sets. The data sets are designed to store data
about entities such as
customers, employees, and vendors, and also events such as
sales, which are really
relationships between entities. Specifically, the "sales" event
represents a relationship
between the "customers" and "finished goods inventory" data
sets (i.e., finished goods
inventory is sold to customers). The repository is integrated in
that there is no
duplication of data sets - every entity and event data set is

stored just once. The data
sets are interrelated in that common attributes exist between
data sets to signify
relationships between entities and events. Coordination among
the data sets involves
ensuring that updates to one data set do not result in data
inconsistencies in related
data sets.
The tasks of creating, updating, and managing data sets are
handled by the database
management system (DBMS). The definition of data sets in
terms of their structure is
done using DBMS facilities. Updates to these data sets are also
performed using
features in the DBMS. In effect, the DBMS serves as the
interface between the
application programs and users requesting access to data sets
and the operating
system which actually retrieves the data from their physical
locations on a magnetic
disk. When there are multiple concurrent requests to access the
same data set, it is the
DBMS that prioritizes and coordinates the requests. Details
regarding this process of
handling multiple simultaneous requests to the same data set, a
process called
concurrency control, will be discussed a little later. The DBMS
also handles a variety of
other functions, most notably backup and security.
Advantages of the Database Approach
In contrast to the file-oriented approach, the database approach
has many advantages.
First, data redundancy is essentially eliminated since every data
set is stored only once

in the repository. Multiple applications requiring access to the
same data set simply
share that data set perhaps even simultaneously as indicated
above. No longer are
duplicate versions of the same data set maintained for different
applications (as was
7 of 30
necessary in the file-oriented approach). This sharing of data is
a key feature of the
database approach. If customer names and addresses are stored
in only one data set,
a change in a particular customer's address would need to be
made just once.
A second advantage of the database approach, related to the
first advantage, is that
data inconsistencies are much less likely to occur. Since
customer ABC's record is
stored just once in the database, there is no possibility of having
different versions of
ABC's name and address in different files.
A third and very significant advantage of the database approach
is data
independence. Recall that in the file-oriented approach data
structures must be defined
in each application program that accesses those data structures.
In a database, data
structures are defined using the DBMS independently of
application programs that
access the data sets. It is not the application programs but the

DBMS that is used to
define data structures. An application program that requires
access to the customer
data set does not have to define the structure of the customer
data set. This
independent definition permits changes to be made in the
structures of data sets without
having to modify each application program that accesses the
affected data sets. Thus, if
the "zip code" field in the customer data set needs to be changed
from a five digit field
to a nine digit field, this change is performed once using the
DBMS. None of the
application programs that access the customer data set need to
be modified.
A fourth advantage of the database approach is that sharing of
data and the data
independence concept permit rapid application development.
New applications using
data that already exists in the database can be very quickly
developed. The time-
consuming steps of defining the data structures and setting up
files are eliminated.
The fifth and final advantage of the database approach is that
the important functions of
backup, control, and security are centralized. Virtually all
DBMS come with backup
facilities to periodically backup the entire database. Corrupted
data sets can be easily
restored from the backup. Facilities also exist within the DBMS
software to specify
access restrictions for either the entire repository, specific data
sets, or specific data
items within each data set. Controls over what kind of data can

be entered into each
data set can also be specified at the level of the data set. These
controls, called integrity
constraints or validation rules, will be discussed later in the
chapter. In contrast to the
database approach, the file-oriented approach required backup,
control, and security to
be performed and specified on an application-by-application
basis.
The advantages of the database approach are summarized in the
following table on the
next page.
8 of 30
Advantages of the Database Approach
Advantage Explanation
Data redundancy virtually
eliminated
Each data set is stored just once
in the repository, thereby reducing
data storage costs.
No data inconsistencies
Since each data item is stored

only once, there cannot be
multiple versions of that data item.
Data independence
Data structures are defined
separately from the application
programs. Changes can be made
to data structures without having
to modify application programs.
Rapid application development
Ability to share data shortens the
time required to create new
applications.
Centralized backup, control, and
security
Backup, control, and security
tasks are all handled centrally by
the database management
system.
Drawbacks of the database approach
In comparison to the advantages just cited, the database
approach has a few
drawbacks. First, within the organization, performing tasks
beyond the most basic
database activities can be extremely complex. Although DBMS
software is becoming
increasingly user friendly, most complex tasks such as
administering the database
require considerable expertise. A second drawback of the

database approach is that
DBMS include a number of fairly complex features for
controlling the integrity of data
entered into tables. Mastering the intricacies of table integrity
features can be quite a
daunting task. However, given their role as control and security
consultants within the
organization, auditors (internal and external) must familiarize
themselves with the
DBMS features that allow control and security to be specified.
From an auditor's
perspective, the complexity of DBMS might pose significant
problems in addressing
audit concerns of control, security, and integrity of data. Third,
data stored within the
database can most easily be accessed using DBMS specific
features and utilities, such
as the DBMS query language and built-in reports. Thus, for the
purposes of the annual
financial statement audit, the auditor must become adept at
creating and running
database queries to ensure that there are no material errors in
the financial statements.
A fourth and final drawback of the database approach pertains
to the centralization of
control and security. Although centralization was listed as an
advantage, it can also be a
weakness since intruders need only penetrate the DBMS shield
to have access to all of
9 of 30

the organization's data. Access and control restrictions specified
on data sets are done
using DBMS features; those same features can be used to "turn
off" the access and
control restrictions unless adequate safeguards exist. Thus, for
the DBMS control and
security features to be reliable, there should be strong control
procedures over access
to the database (control procedures are discussed in detail in
chapter 10). The
disadvantages of the database approach are summarized in the
following table. The
advantages of the database approach outweigh the few
drawbacks. With the falling cost
of hardware and software, most organizations should be able to
justify the investment
associated with the database approach.
Disadvantages of the Database Approach
Disadvantage Explanation
Complexity of
DBMS
administration
The administration of large scale database
systems requires significant resources and
expertise
Data integrity
using complex
DBMS features
Configuring the database to insure data integrity
requires considerable expertise and intricate

knowledge of DBMS features. Accountants and
auditors must familiarize themselves with control
and security concerns for DBMS and how these
can be implemented in database environments
Data accessible
only through
DBMS
Accountants and auditors must be competent in
using the DBMS to access data for the purpose of
generating useful information and fulfilling audit
objectives
Centralized
backup, control,
and security
Backup, control and security are typically
centralized, potentially making the organization
vulnerable to a hacker who can break through the
central security shield
Fundamental database concepts
Having contrasted the file-oriented and database approaches, let
us examine some
fundamental concepts in the database approach. The data set
concept discussed
earlier is a crucial building block of database models and
database systems. A data set
is created for every entity and every event of interest that needs
to be represented in
the database. A primary key is a unique identifier of a record in
a file. Similarly, in a
database, every data set must have a unique identifier of records

within the data set.
This unique identifier is referred to as the primary key of the
data set. When multiple
fields are required to uniquely identify a data set, the result is
referred to as a composite
key or a concatenated key. Every field in a data set other than
the primary key is
referred to as a non-key attribute. Some of the non-key
attributes may be used to sort
the file (or data set) to facilitate answering user queries.
10 of 30
As discussed earlier, a unique aspect of the database approach is
the interrelationships
between data sets. These interrelationships are defined in
different ways depending on
the type of database model (to be discussed in the next section).
In terms of our
discussion of keys, it is relevant to discuss the concept of a
foreign key. A foreign key
is a field in a data set that is the primary key in a related data
set, referred to as the
"master" data set. There are two variants of the "foreign key"
concept -- a foreign key
can either be part of a composite primary key or simply a non-
key attribute in a data
set. That is, when a data set has a composite primary key (more
than one field making
up the primary key), then each individual element of that
composite key will usually be
the primary key in another related data set. Alternatively, a

foreign key can simply be a
non-key attribute in a data set which happens to be a primary
key in a related data set.
It is important to identify foreign keys in a database because it
is these keys that enable
linking of data sets that are related to one another. The concept
of foreign keys will be
explained later in this chapter using an example. The various
key types are summarized
in the following table.
Keys in Database Environments
Key Explanation
Primary key Unique identifier of records in a data set.
Composite (concatenated) key Two or more fields taken
together serve as the primary key in the data set.
Non-key attribute Any field that is not a primary key attribute.
Foreign key
Two variants: (1) an element of a composite
key in a data set which is the primary key in a
related data set, (2) a non-key attribute in a
data set which is the primary key in a related
data set.
Relationships between entities and events, both of which are
represented in the
database by means of data sets, can be of three types, referred
to as the relationship
cardinality. One-to-one (1:1), one-to-many (1:M), and many-to-
many (M:M)

relationships are the three relationship types; the shorthand for
depicting each
relationship type is shown in parentheses. Consider the
relationship between the
"department" and "manager" entities. A 1:1 relationship
between departments and
managers implies that each department can have one and only
one manager and each
manager can manage one and only one department. Now
consider the relationship
between the "salespersons" and "customers" entities. A 1:M
relationship between
salespersons and customers means that each salesperson can
have many customers
but every customer is assigned to exactly one salesperson. Note
that a 1:M relationship
can be interpreted as a M:1 relationship when read from the
opposite direction. Thus,
the relationship from customers to salespersons is a M:1
relationship (many customers
have one salesperson). A M:M relationship between
salespersons and customers
11 of 30
indicates that each salesperson can have many customers and
each customer can
work with many salespersons.
As another example of the various relationship cardinalities,
consider the relationship
between students and tutors. A 1:1 relationship indicates that

each student is assigned
exactly one tutor and each tutor is assigned exactly one student.
A 1:M relationship
from tutors to students indicates that each tutor has many
students but every student is
assigned exactly one tutor. Thus, this relationship would be
read as a M:1 relationship
from students to tutors. A M:M relationship between tutors and
students indicates that
each student can have many tutors and each tutor can have many
students. Note that
the "M" side of a relationship, that is the "many" side, can be
interpreted as "one or
more." The various relationship types are summarized in the
table below.
Relationship Types
Relationship Explanation
1:1 One-to-one (e.g., one professor in one office)
1:M One-to-many (e.g., one advisor has many students)
M:M Many-to-many (e.g., a class has many students, and a
student can be in many classes)
Overview of database models
Given the understanding of fundamental database concepts
discussed above, we now
turn to a description of the dominant database model today, i.e.,
the relational model.
Two older database models are the hierarchical and the network
model -- these models
were popular in the 1970s but have since been displaced by the

relational model. The
hierarchical and network models are rarely found in practice
and are therefore not
discussed in this chapter. An emerging model is the object-
oriented database model
which we shall briefly explore when we consider emerging
concepts in the database
arena.
Relational Model Overview
The relational model, first proposed by E.F. Codd, uses the
concept of a "relation" to
store data. A relation is simply a two-dimensional table with
rows and columns. The
rows, also referred to as "tuples," are the records in the data set
and the columns are
the fields. The term "table" and "relation" are synonymous and
are used
interchangeably. Henceforth, we shall use the term "table"
rather than "relation" and
"row" rather than "tuple." A "customer" data set would be
implemented as a two-
dimensional table with the columns containing the various
attributes of customers (e.g.,
name, address, phone number, etc.) and the rows containing the
records (i.e.,
customers). The concept of a table is thus intuitively appealing
and easy to understand.
http://en.wikipedia.org/wiki/Edgar_F._Codd

12 of 30
In the relational model, then, a series of tables are constructed
for storing data relevant
to the situation. A relational model for a sales order and
collection system is shown in
the figure below. Note that one table is used to represent each
entity and each event.
The resulting tables are SALES-REGIONS, CUSTOMERS,
SALES-ORDERS, ITEMS-
ORDERED, COLLECTIONS, ORDERS-COLLECTIONS, and
ITEMS. The arrows in the
figure are drawn to point out the links between tables (i.e., the
common fields between
tables). The single and double headed arrows signify "1" and
"M" relationships as
before. The convention we will use to indicate the primary key
in a table is by
underlining it. Obviously, there will be two (or more) fields
underlined in the case of a
composite primary key.
Recall that we introduced the concept of a "foreign key" earlier
in the chapter. Let us
revisit that concept in the context of the relational model. To
repeat, a foreign key is
either a non-key attribute in a table that is a primary key in a
related table or an element
of a composite key in a table that is a primary key in a related
table. The "related table"
is in effect the "master" table for that key field. In the above set
of tables, the

CUSTOMER-NO and REGION-NO fields in the SALES-
ORDERS table represent one
variant of the foreign key concept -- they are non-key attributes
in the SALES-ORDERS
table, but each of them are primary keys in a related table.
CUSTOMER-NO is the
primary key in the CUSTOMERS table, and REGION-NO is the
primary key in the
SALES-REGIONS table. "CUSTOMERS" is considered to be
the "master" table for the
13 of 30
CUSTOMER-NO primary key, and "SALES-REGIONS" is
considered to be the "master"
table for the REGION-NO field.
Now let us turn to the second variant of foreign keys -- those
that are elements of
composite primary keys. Note that the ORDERS-
COLLECTIONS table has a
composite key of RECEIPT-NO and ORDER-NO (i.e.,
RECEIPT-NO and ORDER-NO
taken together uniquely determine the rows in the ORDERS-
COLLECTIONS table). Per
the definition of a foreign key, both RECEIPT-NO and ORDER-
NO are each considered
to be foreign keys in the ORDERS-COLLECTIONS table since
each of them is a
primary key in a related "master" table (RECEIPT-NO is the
primary key in
COLLECTIONS and ORDER-NO is the primary key in SALES-

ORDERS). Similarly,
ORDER-NO and ITEM-NO are foreign keys in the ITEMS-
ORDERED table (the
"master" table for items is the ITEMS table). The relevance of
the distinction between
these two variants of foreign keys will become apparent a little
later in the chapter when
we discuss the concepts of entity integrity and referential
integrity. The convention we
will use to indicate foreign keys in the relational model is with
an asterisk (*) at the end
of the foreign key field.
In the relational model, M:M relationships are represented using
composite key tables.
Thus, the M:M relationship between SALES-ORDERS and
COLLECTIONS is
implemented by creating a new ORDER-COLLECTIONS table,
which has a composite
key comprising the primary keys of the SALES-ORDERS and
COLLECTIONS tables,
i.e., the two tables involved in the M:M relationship. That is,
the ORDER-
COLLECTIONS table has a composite primary key of
RECEIPT-NO, ORDER-NO, with
RECEIPT-NO being the primary key of the COLLECTIONS
table and ORDER-NO being
the primary key of the SALES-ORDERS table. Similarly, the
M:M relationship between
SALES-ORDES and ITEMS is implemented by means of the
ITEMS-ORDERED table
which also has a composite key, formed by taking the primary
key of SALES-ORDERS
and the primary key of ITEMS (i.e., ORDER-NO, ITEM-NO).
The ITEMS-ORDERED
and ORDER-COLLECTION composite key tables above both

had non-key attributes.
However, it is possible for a composite key table to have no
non-key attributes at all. In
that case, the composite key table is referred to as an all key
relation (i.e., a table
where all fields comprise the primary key).
It is important to note that relationships between tables are
represented implicitly using
foreign keys. By contrast, the older hierarchical and network
models represented
relationships explicitly using physical pointers. The process of
designing a relational
model, in terms of the number and structure of tables and the
keys linking tables, will be
discussed in the next chapter. Suffice to say for now that the
process of designing a
relational database model is non-trivial.
The simplicity and ease of use of the relational model, and
hence its superiority over the
hierarchical and network models, is evident in many ways.
First, the use of foreign keys
results in the representation of all relationships implicitly and
not explicitly (as was the
case in the hierarchical and network models). Thus, any two
tables can be related as
long as they have a common field. Thus, query processing in the
relational model is far
simpler since users do not have be cognizant of the physical
pointers between data
sets. In terms of the types of relationships that can be
represented in the relational

14 of 30
model, 1:1, 1:M and M:M relationships can all be represented.
The way in which each of
the relationship types is represented will be discussed in the
next chapter.
Relational database management systems (RDBMS) are
available for enterprise
oriented operating systems such as Unix. Linux, and Windows
2012 Server as well as
personal computer oriented operating systems such as Windows
and Macintosh OS-X.
Oracle 12c, IBM Informix 12.1, Microsoft SQL Server, IBM
DB2, and Sybase are some
of the popular enterprise RDBMS that run on “industrial-
strength” servers. For individual
users running Windows, some of the popular RDBMS packages
are Microsoft Access
and dBase.
The Relational Model Explored
Although there have been recent advances in database
technology focused on the
object-oriented model, which we will briefly explore towards
the end of this chapter, the
vast majority of database oriented business information systems
are built using the
relational model platform. Some years ago, RDBMS were hailed
for their simplicity and
ease of use but assailed for their poor performance relative to
DBMS built on the then
prevailing models – the hierarchical and network models (which
are now defunct).

However, in recent years, the performance of RDBMS has
improved considerably as a
result of which RDBMS have gained widespread acceptance in
the marketplace. Even
personal computer based RDBMS such as Microsoft Access are
proving to be powerful
enough for creating complex and robust database applications to
meet the information
needs of a variety of businesses.
We will first examine the rules to which tables must conform.
RDBMS vary in terms of
their compliance with these rules. In addition to these basic
rules, we will also focus on
various RDBMS features that have implications for control and
security of the database.
As accountants, you are likely to be called upon to work with
and give advice on the
control and security aspect of database systems. Integrity
constraints, validation rules,
permissions, views, and the data dictionary are some of the
features of RDBMS that are
relevant from a control and security standpoint.
Rules for tables
Tables in a relational database must conform to a number of
rules. Each table in the
database must have a unique name; no two tables can have the
same name. Duplicate
columns and rows are not permitted within a table; no two
columns can have the same
name in a table, and no two rows can have the same value in
every column. The
sequence of rows and columns is immaterial. However, the
convention is to list the
primary key field(s) at the left and the non-key fields on the
right. Rows in tables are

usually ordered in ascending or descending order of the primary
key, although this
ordering is not essential. Tables can easily be sorted on fields
other than the primary
key.
Every table must have a designated primary key - a unique
identifier of every row in the
table. The primary key could either be one field only, or more
than one field taken
together. As discussed earlier, when multiple fields make up the
primary key, the result
is referred to as a composite key or a concatenated key. Note
that a table could have
more than one unique identifier, but only one must be chosen as
the primary key. For
http://www.oracle.com/database/index.html
http://www.informix.com/informix/products/ids/
http://www.microsoft.com/sql
http://www.ibm.com/db2
http://www.sybase.com/products/databaseservers/
http://office.microsoft.com/en-us/FX010857911033.aspx
http://www.dbase.com/
15 of 30
example, a student table could store both the social security
number (SSN) and a
university assigned student ID (SID) number. The student table
would thus have two
unique identifiers (SSN and SID), but only one can be
designated as the primary key.
Relationships between tables are represented using common

fields between them. As
discussed earlier, these common fields are foreign keys. Recall
that a foreign key is
either an individual element of a composite primary key or a
non-key attribute in one
table that is the primary key in another table. As discussed
above, the "CUSTOMER-
NO" field in the sales orders table in the relational model is
also the primary key in the
customers table and is thus a foreign key in the sales orders
table. The rules for tables
are summarized below.
• Table names must be unique in the database.
• Every table must have a primary key.
• Duplicate rows and duplicate columns are not allowed.
• The order of rows and columns is immaterial.
Entity and referential integrity
Tables must conform to a number of integrity constraints. Two
key constraints are
entity integrity and referential integrity. Entity integrity means
that the primary key
field (or fields in case of a composite key) in a table cannot be
null and must be unique.
This integrity constraint applies to every table in the database.
What entity integrity
simply means is that the primary key field must have a value --
it cannot be left blank.
Furthermore, the value of every primary key in a table must be
unique -- no two rows in
the table can have the same primary key value. Most RDBMS
are equipped with

features that automatically enforce entity integrity. Thus, the
RDBMS will signal an error
if the user attempts to insert a new row without specifying a
value for the primary key
field, or if the value specified is a duplicate value.
Referential integrity means that foreign keys must either be null
or match an existing
value in the "master" table for the foreign key. It is important to
note that foreign keys
can only be null when they are non-key attributes. It is
perfectly legal for a non-key
attribute to be null. However, a foreign key can never be null
when it is an element of a
composite key, because a null value in an element of a
composite key would violate
entity integrity.
Referential integrity is best explained in the context of an
example. Consider the
relational model in the figure presented earlier in the chapter.
The CUSTOMER-NO field
in the SALES-ORDERS table is a foreign key (because it is a
non-key attribute in the
SALES-ORDERS table and a primary key in the CUSTOMERS
table). What referential
integrity requires is that every value of CUSTOMER-NO in the
SALES-ORDERS table
must exist in the CUSTOMERS table. In other words, there
cannot be a customer
number in the SALES-ORDERS table that does not exist in the
CUSTOMERS table.
Simply put, you cannot have a sales order on a non-existing
customer. The
CUSTOMERS table is considered the "master" table for the
CUSTOMER-NO foreign
key. That is, every new customer number must first appear in

the CUSTOMERS table
16 of 30
before it can appear anywhere else in the database (i.e., in other
tables). Note however
that referential integrity allows a foreign key field to be left
blank when it is a non-key
attribute. For example, a null value in the CUSTOMER-NO
foreign key field in the
SALES-ORDERS table might signify a cash sale (in which case
it may not be necessary
to keep track of the customer number). Referential integrity also
applies to the REGION-
NO field in the SALES-ORDERS table (every REGION-NO in
SALES-ORDERS must
exist in the SALES-REGIONS table). Thus, referential integrity
dictates that all foreign
key fields must have a corresponding value in the "master" table
for the foreign key
field.
Entity integrity and referential integrity are essential to ensure
an error free database.
Entity integrity prevents tables from having duplicate or
missing primary keys which
would prevent rows from being located and queries from being
answered. The main
purpose of referential integrity is to ensure the validity of
foreign keys. As discussed
earlier, foreign keys are how links between tables are
implemented. If referential

integrity is not enforced, then relationships between tables may
be corrupted because of
invalid foreign key values.
Data validation rules
In addition to entity and referential integrity, a number of data
validation rules can be
prescribed for each table in the database. The purpose of these
validation rules is to
prevent erroneous data from being entered into the table. Note
the emphasis on the
word "prevent" -- these rules are aimed at prevention rather than
detection of errors.
Thus, validation rules in database systems present an
opportunity for accountants and
auditors to propose a wide range of controls that can be built
into the systems to
prevent errors from creeping into the database. Let us first
discuss examples of data
validation rules and then how they work to prevent errors.
Validation rules can be established for individual fields within a
table to restrict the data
that can be entered into the field. Rules that refer to more than
one field in a table can
also be defined either directly at the field level or in some
database systems at the
overall table level. Data validation rules at the field level can be
specified to ensure that
the value entered in the field is in a range of acceptable values.
Minimum values,
maximum values and both minimum and maximum values for
data can be specified. For
an example, an "hours worked" field can have a minimum value
(1), a maximum value
(40), or both a minimum and a maximum value (>=1 AND <=
40). If the user attempts to

enter a value of 50, the system will reject the input and display
an error message.
Another type of validation rule allows valid values for a field to
be specified such that
data input is accepted only if it matches one of the acceptable
values. A "shipping code"
field may be designed to accept only one of the following
values: 'S' for in-state, 'O' for
out of state but within the U.S., and 'I' for international. If the
user attempts to enter a
value other than S, O, or I, an message will be displayed and the
erroneous data will not
be accepted. Rules can also be specified to ensure that the
correct number of digits
have been entered into a field. For example, a "zip code" field
can be designed to
accept exactly five digits, or exactly nine digits in the format
99999-9999.
Rules can also be specified to ensure valid relationships
between fields. Take for
example a "sales order" table with the fields "order date" and
"ship date." A rule can be
17 of 30
specified to ensure that the ship date is always on or after the
order date. While some
database systems allow such rules to be specified in either of
the two fields, other
systems refer to such multi-field validation rules as "record
validation rules" (or "table

level validation rules"). Validation rules in RDBMS are
summarized in the following
table.
Validation Rules
Range test Greater than a minimum and/or less than a maximum
value?
Validity test One of the acceptable values for this field?
Length test Correct number of digits entered?
Valid combinations
test
Correct mathematical or logical relationship
between fields in a table?
Restricting access to tables
In addition to such validation rules that are defined for each
table, access restrictions
can be defined at the database level for controlling access to
sensitive data such as
tables containing employee salary data. Most RDBMS provide
the ability to designate
authorized and unauthorized users for tables. Certain tables can
be made accessible to
all users except those listed, or only to the listed users.
Unauthorized users receive
error messages when they attempt to access a table which they
have not been
authorized to access.
Another method of restricting access to sensitive data is to
create a view. A view is a
virtual table. A view appears to the user as a table but is
actually a version of an existing

table with some of the table's data hidden from view (hence the
term "view"). For
example, a view can be constructed of the "employee" table that
hides the "salary" and
"home phone number" fields. The rest of the data in the
employee table such as the
name, office phone number, email address, etc. would appear in
the view. All users can
be given permission to access this view, but only a few
individuals would be granted
access to the actual employee table. Apart from hiding certain
columns, rows that
contain sensitive data can also be hidden. For example,
information pertaining to high
level executives can be omitted from the view by excluding all
rows in the "employee"
table where the "rank" field is higher than 8 (assuming that all
top executives have
values greater than 8 in the "rank" field). Hiding of rows and
columns can be combined
in the same view. To summarize, access to sensitive data can be
restricted by (1)
specifying which users can access the sensitive table by setting
"permissions" and (2)
creating views in which sensitive fields are hidden and
permitting access only to the
view.
Data Dictionary
In an RDBMS, the data dictionary contains a variety of
information about the contents
of the database. In a sense, the data dictionary contains data
about data, or "meta

18 of 30
data." Note that the data dictionary is not a single table in the
database but a collection
of hidden “system” tables. The information stored in these
hidden system tables
comprising the data dictionary is useful both from the
standpoint of application
development and database maintenance and also from a control
and security
standpoint. Some examples of the kind of data contained within
the data dictionary are
the names of all tables, the columns (attributes) contained in
each table along with their
data formats, and the privileges held by each user authorized to
access the database.
By querying the data dictionary, users can locate all tables in
which a particular attribute
exists. Note that access to the data dictionary should be
restricted to select systems
designers and auditors who would find the need to refer to the
data dictionary for a
variety of reasons. For example, an auditor interested in
determining which users are
authorized to read the "customers" table could find that
information by examining the
data dictionary. Or if the auditor would like to know how many
tables contain the
"employee salary" field, the answer can be obtained from the
data dictionary.
Languages for RDBMS
There are three categories of RDBMS languages: one for

defining the relational
database schema, one that is used to access database tables from
within conventional
application programs, and one that can be used by end users to
perform ad hoc queries
of the database. The data definition language (DDL) is used to
program the database
schema. The design and setup of the database is typically
performed by the database
administrator (DBA) who is the individual having overall
control over the database.
Using the DDL, the DBA can create tables, define authorized
users of each table and
specify validation rules for individual tables.
The language that is used within conventional application
programs like COBOL, or
more recently C and Visual Basic, is called the data
manipulation language (DML).
These DML statements are embedded within third generation
languages such as
COBOL or C, or even fourth generation languages. The purpose
of the DML statements
is to allow the programs to access tables in a database whenever
required. The need
for a separate DML embedded within conventional programs is
fast diminishing as most
RDBMS today have powerful programming components built
into them. For example,
Microsoft Access provides the ability to develop powerful
applications using Visual
Basic for Applications (VBA) which is available within Access.
The third category of DBMS languages is the data query
language (DQL). The DQL is
used by end users to perform ad hoc queries on the database.
The DQL should ideally

be easy to use so that end users without extensive programming
experience can
execute simple statements to satisfy relatively straightforward
information needs. There
are two broad categories of DQL - GUI oriented querying
referred to as Query By
Example (QBE), and command line oriented querying. The most
popular command line
DQL is Structured Query Language (SQL - pronounced
"sequel"). SQL will be
discussed in greater detail in the next section.
In GUI oriented querying, QBE, the user is presented with a
shell of the table or tables
containing the data that would answer the user's query. In the
appropriate field, the user
simply provides an example of the data he/she is looking for
(hence the term "query by
19 of 30
example"). In effect, the user specifies select conditions for
fields and can also indicate
which fields the result should be sorted on. For example, if the
user wants all sales
orders where the amount exceeded $1,000, he/she would first
invoke the QBE module
to view a "skeleton" of the orders table. Then, the user would
tab over to the "amount"
field, type in >1000, and execute the query. The skeleton table
would then show the
rows that met the condition specified by the user (or a message

if no rows were found to
satisfy the condition). As is possible in the "view" concept
discussed earlier, the user
can hide certain fields from the answer. The following figure
shows QBE in action, to
show orders exceeding $1,000, using the default query design
view in Microsoft Access.
In addition to QBE and SQL, two other RDBMS tools are
noteworthy. Most RDBMS
include a report writer which can be used to create custom
reports formatted to the
user's specifications. The user simply indicates which table or
view to use as the input
and can determine the precise nature of the report. The fields to
total, at what points to
provide subtotals, the header and footer for each page, and the
end of report summary
information are some examples of the report characteristics that
the user can control.
The second useful RDBMS tool is the forms editor which can be
used to create custom
data input forms. Rather than using the table itself to enter data,
users (especially
novice users) can be provided with easy to use forms that
simplify the process of
entering and retrieving data. Forms can be designed to supply
default values for fields
and for specifying custom formats to facilitate data entry. Other
than simply for data
input, forms also represent the user-interface component of
powerful custom
applications that can be developed using the RDBMS'
programming tools. Program
code modules can be associated with buttons on forms such that

a whole series of
actions are automatically executed when the user clicks on a
button after entering data
into form fields. This use of forms will be discussed in the next
chapter. Shown below is
an example of a Microsoft Access form, used to add, update,
and delete information
about customers.
20 of 30
Structured Query Language -- SQL
As indicated above, a very popular database language for data
definition, manipulation,
and query is Structured Query Language (SQL). In the context
of the three types of
database languages discussed earlier (i.e., DDL, DML, and
DQL), SQL includes
statements for all three purposes. The set of "create" commands
within SQL are used to
define tables, i.e., as a DDL. SQL statements can be embedded
into conventional
programming languages (i.e., used as a DML). Finally, and in
its most common use,
SQL can be used as a DQL by end users seeking answers to ad
hoc queries.
There are four primary operations that can be performed on
tables using SQL -- the
SELECT operation (to select rows from one or more tables), the
INSERT operation (to

insert rows into a table), the UPDATE operation (to modify one
or more rows in a table),
and the DELETE operation (to delete one or more rows from a
table). The most
commonly used SQL operation to answer ad hoc queries is the
SELECT operation.
The SELECT operation can simultaneously (1) create a
horizontal subset of a table, i.e.,
selecting all rows from a table that meet a certain condition, (2)
link tables using the
common field between them, and (3) create a vertical subset of
a table or tables, i.e.,
displaying only certain fields in tables.
The general syntax of the SELECT operation is as follows:
SELECT <table_name1>.<field_name1>,
<table_name1>.<field_name2>,
<table_name2>.<field_name2>
FROM <table_name1>, <table_name2>...
WHERE <table_name1>.<common_field1> =
<table_name2>.<common_field1> ....
AND <condition> [INTO <result table>]
The "INTO" syntax in square brackets is optional -- it results in
the creation of a new
table to store the query results. The <condition> portion of the
SQL statement (i.e., the
WHERE clause) is specified using a field from a table listed in
the FROM part of the
statement (e.g., CUSTOMERS.BALANCE > 5000). Note that
the WHERE condition

21 of 30
clause is used to specify both the joins necessary to obtain the
query result and the
criterion or criteria to be applied. The order of joins and
criteria specifications is not
material. Tables needed for joins and for criteria specifications
should be listed in the
FROM portion of the SQL statement. Note that the above
syntax is not universal across
all RDBMS -- slight variations from one RDBMS to the next
will exist. Let us now look at
some examples of SQL in action.
Consider the following four tables in a sales database
information system (the primary
key in each table is in underlined, and foreign keys are
identified with an asterisk at the
end of the field):
CUSTOMERS (CUSTOMERNO, NAME, ADDRESS, PHONE,
BALANCE,
CREDIT_LIMIT)
SALES (INVOICENO, DATE, CUSTOMERNO*,
SALESPERSON, TOTAL)
ITEMS (ITEMNO, DESCRIPTION, QTY_ON_HAND,
COST_PRICE)
ITEMS_SOLD (INVOICENO*, ITEMNO*, QTY_SOLD,
SELLING_PRICE)
Let us assume that the sales manager has the following queries:
(1) which customers, if

any, have exceeded their credit limit? (2) what are the names
and phone numbers of
customers who have been sold merchandise by John Doe? (3)
what are the names and
current balances of customers who have been sold item number
1250? The SQL
queries to answer each of these queries follow:
Query no. 1:
SELECT * FROM CUSTOMERS
WHERE CREDIT_LIMIT < BALANCE;
(Note: the * means all fields)
Query no. 2:
SELECT CUSTOMERS.NAME, CUSTOMERS.PHONE
FROM CUSTOMERS, SALES
WHERE CUSTOMERS.CUSTOMERNO =
SALES.CUSTOMERNO AND
SALES.SALESPERSON = "John Doe";
Query no. 3
SELECT CUSTOMERS.NAME, CUSTOMERS.BALANCE
FROM CUSTOMERS, SALES, ITEMS_SOLD
WHERE CUSTOMERS.CUSTOMERNO =
SALES.CUSTOMERNO
AND SALES.INVOICENO = ITEMS_SOLD.INVOICENO
AND ITEMS_SOLD.ITEMNO = 1250;
The statements shown above use the syntax <table-name.field-
name> to jointly refer to
both a field and the table in which the field appears. Joins are
performed by indicating
which fields in the two tables should equal one another (i.e.,
which fields are common
between the two tables). In query number 3 above, the WHERE
clause specifies (1) the
two joins needed—between CUSTOMERS and SALES using

CUSTOMERNO and
between SALES and ITEMS_SOLD using INVOICENO and (2)
the criterion involving
22 of 30
the ITEMNO field in the ITEMS_SOLD table. The
CUSTOMERS, SALES, and
ITEMS_SOLD tables must all be specified in the FROM portion
of the query.
While the exact form of SQL syntax can vary from one RDBMS
to the next, the general
format should be similar to that shown above. The various
DBMS languages/tools are
summarized in the following table.
DBMS Languages
Language/tool Explanation
DDL - Data Definition Language
Used to create tables, set
permissions on tables, define
validation rules in tables, and
perform other functions such as
backup.
DML - Data Manipulation
Language

Embedded into application
programs written in a third or
fourth generation language. The
DML statements allow the
program to interface with the
database.
DQL - Data Query Language
General term for user-oriented
interfaces to the database to
enable end users to obtain
answers to ad hoc questions.
SQL - Structured Query Language
A widely accepted standard
relational database query
language. Command line interface
using four main operators --
SELECT, INSERT, UPDATE, and
DELETE.
QBE - Query By Example
Graphical interface for querying.
User is presented with a shell of a
table to be queried in which the
user can enter an example of what
he/she is looking for as a means
of querying the table.
Report Writer
Allows custom reports to be
generated from tables in a very

user-friendly intuitive manner.
Forms Editor
Permit the creation of user-friendly
interfaces to tables. Forms can be
made to appear like the
documents and paper forms that
are familiar to the user.
23 of 30
DBMS backup and control features
In order to protect the organization from accidental or
intentional corruption of the
database, periodic backups should be performed. The most basic
form of backup is the
static backup. This backup procedure first involves closing all
programs and shutting
down the database. Next, the entire database is backed up,
either to a separate disk or
to tape. During the backup procedure all users are "locked out"
of the database (i.e.,
prevented from accessing the database). The reason that this
backup method is
referred to as a "static" method is because table structures and
values are saved at a
particular point in time. If the database crashes, it can only be
recovered to the state at
which it was last backed up. In other words, transactions that
occurred since the last
backup are lost. Most personal computer RDBMS offer only

static database backup.
A superior backup method is called dynamic backup. Often
available only on
mainframe RDBMS, this method involves periodic static backup
combined with logging
of each individual transaction to a backup magnetic disk in
addition to the primary
magnetic disk. In effect, every transaction is recorded twice --
once on the primary
database disk and once on a backup disk. In the event of a
hardware or software failure
which results in corruption of the database, the static backup is
retrieved and the new
transactions from the backup disk are "applied" to the backed up
version of the
database. This process results in recovery of the database to the
status at the point of
failure. In effect, the database is reconstructed as if the crash
had never occurred. One
popular dynamic backup method is the redundant array of
inexpensive (or
independent) disks (RAID). As the name suggests, RAID uses
an array of magnetic
disks for recording transactions. The RAID controller
determines which disks each
transaction will be written on - as indicated earlier, each
transaction will be written on
more than one disk. If a disk fails, the RAID controller can still
retrieve all the
transactions because every single data item on the failed disk
would have been written
on some other disk in the array. Especially with the cost of
magnetic disks declining
rapidly, RAID systems have become more affordable than ever
before. This web site at
the Advanced Computer & Network Corporation provides an

excellent description of the
different levels of RAID, from level 0, to level 53, to level 0+1.
When multiple users can access a database via a network, a
critical concern is control
over concurrent or simultaneous updates. If two users are
allowed to update a table at
the same time, the database may be left with inconsistent values
after the two users
perform their respective updates. For example, assume that 100
units of a finished
goods inventory item are in stock. Next assume that two sales
clerks each process a
sales transaction for 80 units at exactly the same time (both
would be permitted to do
so, since the system would display available inventory of 100 to
both users). At the
conclusion of both transactions, the inventory item would have
a balance of -60! To
prevent such an occurrence, all RDBMS have some form of
concurrency control. The
most rudimentary form of concurrency control is called a "lock
out." When one user
accesses a table with the intention of updating it, all other users
are simply "locked out"
from the table. The other users receive a message indicating that
the table is currently
unavailable. However, this is an extreme form of concurrency
control. Users who only
intend to read data in the table should be permitted to do so. A
less stringent form of
concurrency control is the "write lock" in which users who only
intend to read data from
http://www.acnc.com/raid.html

24 of 30
the table are granted access but users who intend to update
values in the table are
denied access. Remember that in a multi-user DBMS
environment, it is essential to
allow simultaneous access to tables unless corruption of the
data might result (as in the
case of simultaneous updates).
Emerging database systems concepts
We conclude this chapter with a brief discussion of an emerging
concept relating to
database systems. Object-oriented (OO) approaches to modeling
and implementing
database systems are becoming increasingly popular. This
approach employs object-
oriented modeling (OOM) techniques to model the domain of
interest and then
implements the resulting model using an object-oriented
database management system
(OODBMS). The object-oriented approach focuses on the
objects of interest in the
domain. Customers, vendors, employees, sales orders, and
receipts are all viewed as
objects that have certain attributes. OOM involves identifying
the objects of interest,
their attributes, and relationships between objects.
A critical feature unique to the OO approach is that an "object"
package includes both
the attributes of the object and the methods or procedures that
pertain to that object.

The methods might dictate how the object's attributes are
modified in response to
different events, or how the object causes changes in the
attributes of other objects.
Thus, a key difference between the database models described
earlier and the OO
approach is that OO models combine data (attributes) and
procedures (methods) in one
package, i.e., the "object." This feature of OO models is
referred to as encapsulation -
attributes and methods are represented together in one capsule.
Another powerful
feature of OO models is inheritance. OO models depict the real
world as a hierarchy of
object classes, with lower level classes inheriting attributes and
methods from higher
level classes. Thus, lower level object classes do not need to
redefine attributes and
methods that are common to the higher level object classes in
the class hierarchy.
An OO model contains all details needed for implementation
and object-oriented DBMS
are powerful enough to represent all the information contained
in the model. However,
most organizations that have made heavy investments in
RDBMS see little need to
migrate to OO environments. While OO modeling methods are
available, there is no
consensus regarding the "best" method to use. Finally, although
OODBMS are
beginning to become commercially available, they have not
gained much acceptance in
the marketplace probably due to their relatively high cost and
poor performance in
comparison to RDBMS. Gemstone, Jade, ObjectDB, and

Objectivity are some
examples of OODBMS.
Summary
The chapter began by contrasting the older file-oriented
approach with the database
approach. Drawbacks of the file-oriented approach and
advantages and limitations of
the database approach were discussed. Key database concepts
such as primary,
concatenated, and foreign keys were described. The various
types of relationships such
as 1:1, 1:M, and M:M relationships were then explained. The
relational model was then
explored in detail. Rules for relations, entity and referential
integrity, and validation
rules for relational database systems were explained. The
process of restricting access
25 of 30
to data in a relational database was then discussed. The data
dictionary concept was
then explained. The three major database languages - the data
definition language, the
data manipulation language, and the data query language - were
described in terms of
their functions. SQL, a popular relational database query
language, was discussed in
some detail along with examples. Finally, backup and control
procedures for relational

database systems were discussed. These include static backup,
dynamic backup,
RAID, and concurrency control. The chapter concluded by
discussing the emerging
concept of object-oriented modeling and implementation of
database systems.
Key Terms
Composite key
Concatenated key
Concurrency control
Data definition language
Data dictionary
Data independence
Data manipulation language
Data query language
Database approach
Dynamic backup
Encapsulation
Entity integrity
File-oriented approach
Foreign key
Forms editor
Inheritance
Object-oriented
Redundant array of inexpensive disks
Referential integrity
Relationship cardinality
Report writer
Static backup
Structured query language (SQL)

26 of 30
Key Web Sites
PC based DBMS
• Microsoft Access – Microsoft's popular RDBMS for the
personal computer
• dBase - one of the earliest (and still around) RDBMS for the
personal computer
• Base – the database software that is part of the Apache
OpenOffice suite
Server based DBMS
• IBM DB2 – IBM’s relational DBMS for the enterprise
• Microsoft SQL Server – the latest version is SQL Server 2005
• IBM Informix 12.1 – Informix Dynamic Server – an enterprise
strength relational
database
• Oracle 12c – the latest version of Oracle's database, the
industry leader in
RDBMS technology.
• Sybase - A cross-platform RDBMS
• mySQL – An open source (i.e., “free”) multi-platform RDBMS
Other sites

• A home page dedicated to information about the SQL standard
• An interactive online SQL tutorial
• The W3Schools.com site for SQL – a good place to learn SQL
• Network World article on RAID
• Explanation of the different levels of RAID
• A site with links to various object-oriented database systems
http://www.openoffice.org/product/base.html
http://www.openoffice.org/
http://www.ibm.com/db2
http://www.microsoft.com/sql/default.asp
http://www.informix.com/informix/products/ids/
http://www.oracle.com/database/index.html
http://www.sybase.com/products/databaseservers/
http://www.mysql.com/
http://www.jcc.com/sql.htm
http://www.sqlcourse.com/
http://www.w3schools.com/sql/default.asp
http://www.networkworld.com/community/node/20354
http://www.service-architecture.com/products/object-
oriented_databases.html

27 of 30
Discussion Questions
1. Briefly describe the file-oriented approach to data
processing.
2. Provide an overview level description of the database
approach to data
processing.
3. Distinguish between the file-oriented and database
approaches in terms of their
relative advantages and disadvantages.
4. What do you understand by the term "legacy systems."
5. Explain the concept of data independence.
6. Giving examples, explain the concept of foreign keys.
7. Indicate the key features of the object-oriented model.
8. How are many-to-many relationships represented in the
relational model?
Explain in the context of the following scenario: an employee
can be working on
many projects, and a project can have many employees working
on it.
9. What are the rules to which tables must conform in the
relational model?
10. Giving examples, explain the concepts of entity and
referential integrity.
11. What are data validation rules? Why are validation rules in

database
environments superior to application controls in a file-oriented
environment?
12. Explain the methods by which access to sensitive data in a
relational database
can be restricted.
13. Explain the concept of the "data dictionary." Why do
auditors find the data
dictionary useful?
14. What are the three broad categories of database languages?
Briefly indicate the
function of each language type.
15. Describe the four major SQL operators.
16. Distinguish between static and dynamic database backup.
Explain the function of
RAID.
17. Giving examples, explain the concept of concurrency
control in database
environments.
28 of 30
Problems and Exercises
1. Aggies-R-Us would like your assistance in developing a

logical database model for
their purchasing application. Based on discussions with key
managers at Aggies-R-Us,
you determine the following information: (1) a vendor can
supply many parts and a
particular part can by supplied by many vendors, and (2) each
part can be stored in
many warehouses and each warehouse can store many parts.
Required: Draw a relational model to reflect the relationships
between vendors, parts,
and warehouses. List the tables in your model and draw
appropriate links between the
tables (use single-headed and double-headed arrows to indicate
the relationship
cardinality). You may make reasonable assumptions regarding
the fields to be
represented in each table; be sure to indicate the primary key in
each table.
2. Answer the questions that follow with reference to the
following tables in a relational
database. The assumptions pertaining to the tables are (1) an
employee can work on
many projects, (2) a project can have many employees working
on it, and (3) the
"hours-worked" field is used to keep track of the number of
hours worked by each
employee on each project.
EMPLOYEES (EMPLOYEE-NO, NAME, PHONE-NO, OFFICE)
CUSTOMERS (CUSTOMER-NO, NAME, ADDRESS,
BALANCE)
PROJECTS (PROJECT-NO, DATE, CUSTOMER-NO,
BILLING-AMOUNT)

HOURS (EMPLOYEE-NO, PROJECT-NO, HOURS-WORKED)
Required:
a) Identify the primary key in each table.
b) Identify foreign keys, if any.
database. The assumptions pertaining to the tables are (1) an
instructor can be
teaching many courses, (2) a student can be taking many
classes, (3) there can be only
one instructor teaching a particular course, and (4) each class
can have many students
enrolled in it.
INSTRUCTORS (INSTRUCTOR-NO, NAME, PHONE-NO,
OFFICE)
STUDENTS (STUDENT-NO, NAME, ADDRESS, PHONE,
YEAR-JOINED,
GRADUATION-YEAR, COLLEGE)
COURSES (COURSE-NO, DESCRIPTION, CREDIT-HOURS,
INSTRUCTOR-NO)
ENROLLMENTS (COURSE-NO, STUDENT-NO, STATUS)
Required:
a) Identify the primary key in each table.

29 of 30
b) Identify foreign keys, if any.
4. Consider a scenario in which work orders require many parts
and the same part
could be used on different work orders. Construct tables to
show how this relationship
would be implemented in the relational model. You may make
any reasonable
assumptions regarding fields to be represented for work orders
and parts.
database. The assumptions pertaining to these three tables are
(1) a customer can
have many invoices, (2) an invoice can have many items, and
(3) the STR field
indicates the state sales tax rate for each customer's state.
CUSTOMERS
CUSTOMER# NAME ADDRESS1 ADDRESS2
STATE
STR BALANCE
456 ABC Corp. 111 Any St. Houston TX 6.25 34560.65
457 DEF Corp. 22 Anywhere Dr. New York NY 6.50 2145.90
458 GHI Corp. 5 Someplace Ct. Miami FL 6.45 45670.75
459 JKL Corp. 56 Some Dr. Bryan TX 6.25 21009.50
460 MNO Corp. 7 Noplace Cir. San Diego CA 5.50 4561.00
INVOICES
INVOICE# DATE CUSTOMER# AMOUNT

1001 11-1-95 456 450.75
1002 11-2-95 457 560.25
11-2-95 460 300.10
1003 11-2-95 459 890.25
1004 11-3-95 450 425.50
INVOICE-ITEMS
INVOICE# ITEM# DESC PRICE QTY
1001 121 Widget 2.25 45
1001 540 Bolt 0.40 25
1002 211 Gear 3.70 10
1003 121 Widget 2.25 15
1003 121 Widget 2.25 10
1006 348 Nut 0.25 5
Required:
a) List all violations of entity integrity in the above tables.
b) List all violations of referential integrity in the above tables.
30 of 30
6. Consider the following tables in a relational database.
Provide the appropriate
"SELECT" SQL statement necessary to answer the queries that
follow. Primary keys
are underlined and foreign key fields have an asterisk at the end
of the field.
CUSTOMERS (CUSTNO, CNAME, CADDRESS, BALANCE)
SALESPERSONS (SPNO, SNAME, DATE_EMPLOYED,

SALARY)
SALES (INVOICENO, DATE, CUSTNO*, SPNO*)
Required:
a) List the salesperson name and salary for all sales to
customers whose balance is
greater than $20,000.
b) List the names and addresses of all customers who have been
sold merchandise
by salespersons employed before 1/1/96.
7. Consider the following tables in a relational database which
are in third normal form.
Provide the appropriate "SELECT" SQL statement necessary to
answer the queries that
follow. Primary keys are underlined and foreign key fields have
an asterisk at the end of
the field.
CUSTOMERS (CUSTOMERNO, NAME, ADDRESS, REGION,
BALANCE)
INVOICES (INVOICENO, DATE, CUSTOMERNO*,
SALESPERSON, AMOUNT)
ITEMS-SOLD (INVOICENO*, ITEMNO*, QUANTITY_SOLD,
SELLING_PRICE)
INVENTORY (ITEMNO, DESCRIPTION,
QUANTITY_ON_HAND)
Required:
a) List the invoice number, item number, item description and
selling price on all
invoices by salesperson "John Doe."

b) List the customer names, invoice numbers, and invoice dates
for all invoices
where the quantity sold exceeded 100.
8. Visit Web sites describing personal computer relational
database products such as
Microsoft Access, dBase, and OpenOffice Base. Develop
criteria that you feel are
important in evaluating the products, and rate each product in
terms of the criteria you
develop. Summarize your findings regarding the product you
feel best meets the criteria
you develop.
Last Updated: August 19, 2013
Copyright © 1996-2013 CyberText Publishing, Inc. All Rights
Reserved
http://www.openoffice.org/product/base.htmlFile-oriented and
database approaches contrastedThe file-oriented
approachDrawbacks of the file-oriented approachThe Database
ApproachAdvantages of the Database ApproachDrawbacks of
the database approachFundamental database conceptsOverview
of database modelsRelational Model OverviewThe Relational
Model ExploredRules for tablesEntity and referential
integrityData validation rulesRestricting access to tablesData
DictionaryLanguages for RDBMSStructured Query Language --
SQLQuery no. 1:Query no. 2:Query no. 3DBMS backup and
control featuresEmerging database systems
conceptsSummaryKey TermsKey Web SitesPC based
DBMSServer based DBMSDiscussion QuestionsProblems and

Exercises
Liberty University
[email protected]
University
Faculty Publications and Presentations
Department for Counselor Education and Family
Studies
2009
Rethinking Integration: A Prodding Case in Brazil
Fernando L. Garzon
Liberty University, [email protected]
Follow this and additional works at:
http://digitalcommons.liberty.edu/ccfs_fac_pubs
This Article is brought to you for free and open access by the
Department for Counselor Education and Family Studies at
[email protected]
University. It has been accepted for inclusion in Faculty
Publications and Presentations by an authorized administrator of
[email protected]
University. For more information, please contact
[email protected]
Recommended Citation
Garzon, Fernando L., "Rethinking Integration: A Prodding Case
in Brazil" (2009). Faculty Publications and Presentations. 47.
http://digitalcommons.liberty.edu/ccfs_fac_pubs/47
http://digitalcommons.liberty.edu?utm_source=digitalcommons.
liberty.edu%2Fccfs_fac_pubs%2F47&utm_medium=PDF&utm_

campaign=PDFCoverPages
http://digitalcommons.liberty.edu/ccfs_fac_pubs?utm_source=di
gitalcommons.liberty.edu%2Fccfs_fac_pubs%2F47&utm_mediu
m=PDF&utm_campaign=PDFCoverPages
http://digitalcommons.liberty.edu/ccfs?utm_source=digitalcomm
ons.liberty.edu%2Fccfs_fac_pubs%2F47&utm_medium=PDF&u
tm_campaign=PDFCoverPages
http://digitalcommons.liberty.edu/ccfs?utm_source=digitalcomm
ons.liberty.edu%2Fccfs_fac_pubs%2F47&utm_medium=PDF&u
tm_campaign=PDFCoverPages
http://digitalcommons.liberty.edu/ccfs_fac_pubs?utm_source=di
gitalcommons.liberty.edu%2Fccfs_fac_pubs%2F47&utm_mediu
m=PDF&utm_campaign=PDFCoverPages
http://digitalcommons.liberty.edu/ccfs_fac_pubs/47?utm_source
=digitalcommons.liberty.edu%2Fccfs_fac_pubs%2F47&utm_me
dium=PDF&utm_campaign=PDFCoverPages
mailto:[email protected]
Journal of Psychology and Christianity
2009, Vol. 28, No. 1, 78-83
Copyright 2009 Christian Association for Psychological Studies
ISSN 0733-4273

78
ship counseling” appointments were available to
those needing more intensive ministry (Anderson,
2003). These appointments generally lasted 4-8
hours and utilized Anderson’s structured Steps to
Freedom in Christ approach (Steps or Steps to
Freedom) found in the above works. The Steps
have some features similar to the historical prayer
of examen (cf., Foster, 1992, pp. 27-36). They
involve confession, renunciation, prayers of
repentance, and the utilization of sacred text pas-
sages from the Bible to affirm God’s forgiveness
and love. Further description will be found in
Lucia’s intervention details below. Of course,
Lucia is a pseudonym, and the identifying demo-
graphic information has been altered to protect
her confidentiality.
The Client
Lucia was a 32-year-old married enculturated
Brazilian woman with 2 male children (7 and 9
years old). Since she did not speak English, a
translator with a bicultural Brazilian/United States
background assisted her treatment. As is common
in developing countries, the translator had little
formal psychological training. I spent about 45
minutes orienting him to the psychological inter-
view process to make the session more produc-
tive. Clearly, much more training time and a
female translator would have been optimal; how-
ever, Lucia’s crisis condition precluded postpon-
ing the session for further preparation.
Lucia described Major Depression and panic

attack symptoms. These lasted over the last 2
years, worsening during the last 6 months to the
point of mood congruent auditory hallucinations.
The voices focused on condemnatory and worth-
lessness themes and she described them as now
occurring constantly. It should be noted that the
translation process may have impacted the accu-
rate assessment of the extent of these auditory
hallucinations. However, Lucia displayed no
looseness of associations, disorganized speech or
bizarre behaviors suggestive of Schizophrenia.
Agoraphobic symptoms also had emerged in the
last six months.
Lucia’s history provided clinical clues to her
condition. She was raised and currently lives in
the same small subtropical town as her relatives,
about 10 hours from Sao Paulo. Her parents were
Rethinking Integration:
A Prodding Case in Brazil
Fernando Garzon
Liberty University
I like integration—as long as I can apply the
concept clinically on my own terms. These
include having resources available that modern
science affords: Psychiatric consultations, medical
evaluations, and quality inpatient services. Such
go hand-in-hand with my Christian cognitive
behavioral integration approach. I see all of these
together as gifts from God to help people. Multi-
cultural cases, however, can challenge my typical
integration approaches and standard clinical prac-
tices. This especially occurs when I am outside
my familiar U.S. practice setting, as was the case

with Lucia, a 32-year-old woman I met while
attending a week-long emotional healing confer-
ence in Sao Paulo, Brazil, conducted by Neil
Anderson (Freedom in Christ Ministries). Dr.
Anderson gave me permission to accompany him
on this trip in order to participate in the confer-
ence and make qualitative research observations.
Before introducing Lucia, it’s appropriate to
take a look first at the conference itself. Briefly,
Dr. Anderson’s conference revolved around two
of his written works, Victory Over the Darkness
(1990a, revised 2000a) and The Bondage Breaker
(1990b, revised 2000b). These works focus on
God’s acceptance and the role of the world,
flesh, and the devil (I Jn 2:16; Gal. 5:19-21; Eph.
6:12) in cultivating secular values instead of
Christian values. Anderson espouses the develop-
ment of a positive self-identity through under-
standing Christ’s love for us, and encourages the
utilization of sacred text passages to cognitively
restructure maladaptive self-perceptions. Teach-
ing sessions and worship sessions alternated
throughout the conference. Participants included
three hundred ministers and their spouses, pri-
marily indigenous to Brazil. Individual “disciple-
CASE STUDIES
Liberty University does not officially endorse Freedom
in Christ Ministries. Rather, it supports the theological
and scientific examination of this and other Christian
approaches. Correspondence regarding this article
should be addressed to Fernando Garzon, PsyD., Cen-
ter for Counseling and Family Studies, Liberty Univer-
sity, 1971 University Blvd., Lynchburgh, VA 24502;

[email protected]
still alive and married, and she described their
socio-economic status as poor to lower middle
class. While she was growing up, she perceived
her father as harsh and critical but non-abusive,
and her mother as consoling.
Over the last two years, Lucia felt increasingly
neglected by her husband. She reported him
spending less time with her and felt he was more
focused on his small but growing lumber business
than on the family. Arguments erupted. No reso-
lutions ensued. Lucia’s hopelessness grew.
From the beginning of their marriage, the cou-
ple had been actively involved in a small conser-
vative evangelical church. Lucia became a born
again Christian when she was a teenager, and met
her husband in church. During the first eight
years, Lucia believed her marriage was fine. The
last two years of fighting though have taken their
toll. To cope, Lucia spent time with her cousins,
read her Bible, and attended more to her chil-
dren. Yet the arguments and her husband’s with-
drawal continued. She wondered what was
happening. As is common in her culture, she
began questioning whether someone had put a
curse on her. Lucia believed a neighbor with
whom she had been having several disputes may
have been responsible. In my assessment of this
belief, the boundary between cultural conceptual-
ization and delusional thinking became clearer as
she acknowledged that someone else could have

put a curse on her or her dilemma could have
been coming from another source.
Not knowing how to utilize her Christian faith
to address this fear of a curse, Lucia decided to
visit a Macumba practitioner six months prior to
the conference. Macumba practitioners in Brazil
are similar to black magic witch doctors in other
cultures. While Lucia’s decision may seem sur-
prising to many western Christians, syncretistic
coping patterns occur in many cultures when
the formalized religious system (such as Roman
Catholicism or Evangelical Christianity, for
example) does not appear to have a remedy for
a culturally defined problem (Hiebert, Shaw, &
Tienou, 1999).
In a midnight ceremony, the Macumba practi-
tioner spread fecal material over Lucia’s body,
placed her in a partially dug grave, and poured a
solution on her that had been made from native
Brazilian plants. After an incantation, he lifted her
out of the grave and told her the curse would be
completely broken off if she returned for the sec-
ond part of the ceremony the next week and
gave him the equivalent of $500.
The ceremony itself greatly frightened Lucia.
Her anxiety and panic attacks increased. Indeed,
she began feeling very guilty for pursuing black
magic as a potential solution to her dilemma. She
reported that shortly after the ceremony she
began experiencing the condemnatory auditory
hallucinations.
Case Conceptualization

I attempted to understand Lucia’s symptoms
from a cognitive biopsychosocial perspective. For
example, her distal and current stressors likely
triggered a previously dormant biological vulnera-
bility to panic attacks and depression. Regarding
social context, her on-going marital distress led to
internalized anger and depressogenic cognitions
around themes of rejection and worthlessness.
Lucia’s unsuccessful attempt to cope with her situ-
ation by utilizing her Christian faith produced fur-
ther depressive cognitions about herself, the
future, and her world. Finally, her latest coping
attempt, seeing a Macumba practitioner, exposed
her to spiritual deception and produced great
guilt and anxiety. The experience may have left
her vulnerable to the condemnatory auditory hal-
lucinations she now experienced. She not only
feels disconnected from her husband, but now
faces a spiritual crisis as well.
Lucia noted many questions from the crisis: Has
God rejected me for seeking a black magic reso-
lution to my problems? Am I going to live under a
curse the remainder of my life? Does my faith
[evangelical Christianity] contain any interventions
that may be of help to resolve my spiritual and
marital crisis?
Treatment Justification
Lucia’s crisis also contained questions for me:
Am I culturally competent for this case? How do
I handle the lack of access to psychiatrists, psy-
chotropic medications, and quality inpatient
facilities as potential resources for Lucia? Normal-

ly, these are critical components I consider in
developing treatment plans for psychotic symp-
toms such as auditory hallucinations. Are my
typical Christian cognitive behavioral strategies
adequate for her case? Clearly, my normal inte-
gration methods needed examination in this very
different cultural context.
One aspect of the context was the seminar set-
ting itself. Lucia came to the conference expect-
ing to receive individual ministry consistent with
Neil Anderson’s approach rather than western
CASE STUDIES 79
psychotherapy or psychiatric medications. Would
I be imposing my cultural values on her if I sim-
ply shelved Anderson’s approach?
Further, I recognized some overlap between
Anderson’s principles of ministry and my typical
Christian cognitive approach. The Steps would
encourage restructuring of some of Lucia’s
depressive cognitions (for example, cognitions
about God rejecting her and a hopeless future)
and would also invite her to recognize her anger
at her husband. With her permission, I decided to
administer portions of the Steps to Freedom as a
starting point and carefully assess the outcome. As
intonated in the above, had I additional clinical
resources, the treatment plan likely would have
been quite different.
Interventions

Treatment occurred in one intensive 7-hour
session. An informal intake, portions of the Steps
to Freedom, and a marital consultation com-
prised the interventions. In the Steps to Free-
dom, I focused on the portions most pertinent to
Lucia’s situation. These included step 1 (renunci-
ation of occult involvement), step 3 (forgive-
ness), and part of step 6 (the section on wrong
sexual use of the body). Breaks were taken
approximately every hour.
In step one, Lucia made a detailed list of all
the folk religion and occult practices in which
she had previously participated. She endorsed
several other folk religion rituals from earlier
years of her life. After making this list, Lucia
asked God’s forgiveness for these activities and
renounced each one individually. She appeared
to experience a great sense of relief from her
guilt following the activity.
Step three (forgiveness) followed. Lucia asked
the Lord to bring to her mind everyone against
whom she was holding an offense. In accordance
with the step, rather than saying a blanket prayer
to release these wounds, Lucia described the
offenses in detail and how they made her feel
about herself. Injuries with her parents, other rela-
tives, and her husband came to mind. Much affect
was displayed as she released these to God. Lucia
also confessed anger at God over some of the
things that had happened to her and, later, anger
at herself over some of her choices. She was able
to reconcile with God and to forgive herself.
Some unanticipated history also emerged. In

another coping attempt, Lucia confessed to having
a brief extra-marital affair.
Given the affair, the step which focuses on
sexual sin areas (step six) followed naturally.
Lucia confessed the wrong usage of her body,
asked the Lord to cleanse her of any harmful
effects from this experience, and rededicated her
body as God’s holy temple. As the prayer ended
the last portion of the Steps intervention for
Lucia, she expressed a sense of God’s forgive-
ness and restoration.
I debriefed with Lucia about her experience.
She felt a great sense of emotional relief, recon-
nection with God, and renewed hope. She also
reported the auditory hallucinations had
stopped. While it was unclear at which point in
the ministry session this occurred, I chose to
focus on continuing her brief treatment rather
than lose time in such an assessment. Lucia con-
sented to meet with her spouse.
In the meeting, her husband, a tall medium
stature bearded man, appeared open. Through
the translator, we discussed “time with family”
as a significant issue and did some problem-
solving. I suggested marital counseling might
also be helpful; however, this was done very
delicately. I framed the counseling more as
“consultations” to help Lucia than therapy ses-
sions (something that would be very threatening
to the typical enculturated Brazilian male). Nei-
ther of them knew of any potential resources in
their area. No mention was made to the hus-
band of the marital affair, given the lack of treat-

ment time to process this issue. We all agreed to
look for marital counseling resources during the
remainder of the conference.
Two days later, I briefly saw Lucia again.
Her af fect was noticeably brighter, she
appeared relaxed, and the circles underneath
her eyes were gone. She smiled often, and
reported sleeping well the last two nights. No
panic attacks or auditory hallucinations had
recurred. Her husband likewise noted great
improvement. Though encouraged by these
reports, the lack of marital and individual fol-
low-up continued to concern me. I eventually
met a Christian psychologist as well as a pas-
tor of a local Christian emotional healing min-
istry at the conference. They both introduced
themselves to Lucia and agreed to continue
working with her. They gave her their contact
information. Five days after our intensive treat-
ment appointment, I met again with Lucia and
her husband and they continued to report no
return of symptoms.
80 CASE STUDIES
Discussion
Many issues worthy of debate emerge from
Lucia’s case. Theologians, culturally competent
therapists, and medical researchers all would
examine this case report with enriching critique
and commentary. Accordingly, I will attempt to
pose the primary questions that might emerge

from such an interdisciplinary roundtable discus-
sion while acknowledging that I am not necessari-
ly an expert in all the issues raised.
Questions Theologians Might Have
I imagine the theologians sitting at the table
would be focused on Lucia’s faith status and the
role of the demonic in her life. Specifically, was
Lucia truly a Christian before she went through
the Steps to Freedom? This question matters
because she may have been experiencing signifi-
cant demonic oppression. Her syncretistic practice
of seeking out a Macumba practitioner, along with
her resentment towards her husband, may have
exposed her to this vulnerability (Bufford, 1988).
Some theologians at the table would argue that
Lucia’s behavior demonstrates she did not have
saving faith prior to the Steps. They would assert
that a Christian cannot have a demon, and that
Lucia only became a true Christian when she
repented of her folk religion practices. Others
would object, saying she was indeed a Christian
and exposed herself to demonic oppr ession
through her sinful behavior but not possession.
Oppression implies influence but not the com-
plete control intonated in possession. The debate
will be noted here but certainly not resolved.
See Dickason (1987) for examples of the argu-
ments and Boyd (1997) for more in-depth theo-
logical context.
Some liberal theologians at the table hearing
this exchange might become squeamish. They
have relegated demons to a past that they

believe now has been “demythologized” a la
Bultmann (1952). The facts of this case would
create significant cognitive dissonance for them.
Indeed, I imagine them listening intently to the
questions medical researchers would have later.
Questions Culturally Competent Therapists
Might Have
Psychologists and counselors are both now eth-
ically mandated to practice religiously and cultur-
ally sensitive treatment as a component of
diversity (APA Ethical Standard 1.08 and ACA
standard A.2.c). At the table they would be con-
sidering whether this was done for Lucia. Her
case illustrates the challenges of developing truly
sensitive approaches, especially in circumstances
where the client’s worldview may vary widely
from the practicing clinician’s. In the discussion,
the difference between Lucia’s Brazilian cultural
norms and western psychological norms I had
been trained in would carefully be explored.
From Lucia’s perspective, demons, black magic,
and curses were real problems to be dealt with
versus being interpreted as abnormal delusional
fantasies to be analyzed or medicated. The
prayers of confession and renunciation in Step 1
seemed to resolve her concerns rapidly in these
matters in a way in which other interventions I
normally use may not have. Perhaps Anderson’s
intervention style was more consistent with the
cultural norms and expectations that Lucia had for
what might be a reasonable treatment to resolve
such issues, and this facilitated the outcome.

The therapists might also explore the forgive-
ness step further. It appeared equally important in
helping Lucia. She was able to release her anger
at her parents and her husband for offenses
against her, while also forgiving herself and rec-
onciling with God. The intervention’s utilization
of sacred text passages to affirm God’s forgive-
ness and build a positive identity fit with Lucia’s
religious expectations that Christianity would have
resources to help her combat her depressogenic
cognitions. My therapist friends also would point
out that part of the forgiveness intervention’s suc-
cess related to Lucia’s personal characteristics. She
was able to process painful negative affect fully.
Other clients may have been more defended
against such emotions. The therapists would
agree with me that Lucia’s lack of features com-
monly found in Schizophrenia and severe disso-
ciative disorders also helped the outcome.
At some point, the theologians would inter-
rupt our discourse and maintain the important
role of the Holy Spirit in Lucia’s outcome. We
would concur, and clarify that our observations
do not denigrate the role of the Holy Spirit in
the outcome; rather, the observations merely
help us understand some of the mechanisms
God may have used without implying they were
exhaustive.
The therapists and theologians might continue
their discussion examining the step dealing with
sexual sin. It contained something I had never
seen in integration therapies. Most Christian clini-
cians would endeavor to address Lucia’s guilt
over the marital affair, but the petition for spiritual

restoration of the body was a novel approach to
CASE STUDIES 81
me. Lucia showed great relief from guilt when this
step was completed. The therapists might reason
that the intervention was religiously and culturally
congruent with Lucia’s background, which aided
the response, while the theologians would
explore with us the hermeneutical interpretation
of New Testament passages that Anderson uses as
a rationale for this strategy.
Finally, the therapists might ask me if Lucia
portrayed any characteristics consistent with a
client who might have reported a resolution to
her symptoms simply to please the treating clini-
cian. Lucia’s more relaxed physical appearance
following the intervention, the absence of dark
circles under her eyes later in the week, and her
husband’s report of improvement later in the
week would appear to support a true symptom
remission.
Questions Medical Researchers Might Have
The medical researchers at the table would
focus on the case study design. Was the design
sound? Is a 1-week outcome analysis sufficient?
Lucia’s case did not have pre and post outcomes
measures, a recommended 6-month follow-up
testing, and no control group cases for compari-
son. Certainly, the doctors would insist, her case
is not something scientifically sound enough to

build a theory.
I would readily agree with the researchers on
these points. Indeed, this was a naturalistic setting
and the case study itself was serendipitous. One
week’s worth of qualitative follow-up is not suffi-
cient to insure there would not have been a
relapse. Indeed, Anderson himself warns that one
must not consider the Steps a final treatment but
rather that each person should seek sufficient
spiritual and emotional support to maintain their
freedom (Anderson & Miller, 1999; Anderson,
2003). He recommends attending a healthy
church, continuing to grow through fellowship
and Bible study, support groups, and Christian
counseling as needed (Anderson, Zuehlke, &
Zuehlke, 2000). He likely would agree that marital
counseling as a follow-up is important in main-
taining Lucia’s outcome. If Lucia’s husband
returns to his behavioral pattern and she does not
have such supports, she could relapse.
Even with these caveats, the observed 1-week
outcome of the case went heavily against my own
empirically-based theoretical predictions. For at
least 7 days, the auditory hallucinations stopped,
Lucia slept well, and she had renewed hope in
her marriage.
The researchers’ next question would focus on
the interpretation of this outcome. Could Lucia’s
improvement be accounted for by placebo
effects? Perhaps. Yet, what have we actually said
in simply labeling a process “placebo” without
understanding its underlying mechanism? If
Lucia’s faith and expectancy alone were power-

Chapter 6 Elements of Database Systems 1 of 30 ACCO.docx

Chapter 6 Elements of Database Systems 1 of 30 ACCO.docx

Recommended

Recommended

More Related Content

Similar to Chapter 6 Elements of Database Systems 1 of 30 ACCO.docx

Similar to Chapter 6 Elements of Database Systems 1 of 30 ACCO.docx (20)

More from robertad6

More from robertad6 (20)

Recently uploaded

Recently uploaded (20)

Chapter 6 Elements of Database Systems 1 of 30 ACCO.docx