Journal of Accounting and Computers Issue XIII Article 5
Page 1 of 13
Using an Active Database System to Simplify the Pension
Accounting Process: A Tutorial
David H. Olsen
Dean L. Sproveri
David H. Olsen is from the Department of Business Information Systems; Utah State University; Logan,
Utah.
Dean L. Sproveri is from the College of Business Administration; University of Akron, Akron,Ohio.
ABSTRACT Using advanced database techniques in the accounting profession is
becoming more commonplace. For this reason, accountants are better served if they have a
substantial database background. One area of database research and practice that is
becoming increasingly popular is active databases. This paper presents a tutorial that
integrates standard database concepts with active database concepts in the context of a
pension accounting system for the advanced accounting information systems course.
Those interested in studying the tutorial described in this paper will have an excellent
database background from which they can draw throughout their accounting careers. This
tutorial will help develop skills in pension accounting, relational database implementation,
E/R modeling, programming, and active databases. A solid understanding of intermediate
accounting and applications-oriented information systems concepts are necessary for this
tutorial.
z
z
z
z
z
z
Introduction
Prior Research
Foundations of Active Databases
Active Database Implementation
Conclusion
References
Introduction
Accounting systems have been implemented using conventional database technology for at least the past
20 years. In recent years, advanced database technologies, such as active databases, have become more
popular for many businesses and have improved quality for them, particularly in manufacturing.
Because of the increased use of advanced database techniques, accountants will be well-served if
database training is integral to their education. Moreover, accountants that include advanced database
training as a part of their education will enhance their market viability.
http://www.swlearning.com/accounting/jac13/jac13_article5.html
7/30/2005
Journal of Accounting and Computers Issue XIII Article 5
Page 2 of 13
In this paper, we describe a tutorial that integrates conventional and active database techniques to
produce a pension accounting system. This tutorial includes an E/R model, the business rules, and
formal rule statements for an active database. Those who thoroughly understand this tutorial have a
framework for building a more comprehensive, fully integrated pension accounting system. In addition,
those who complete tutorials like the one in this paper are better able to solve accounting problems using
information systems techniques.
The paper continues with Section II providing a review of relevant database, active database, and
accounting expert systems research. Section III provides a foundation of salient active database
concepts. Section IV includes an example of an active database implementation that illustrates how to
use active database concepts in a pension accounting system. Section IV also discusses the educational
benefits of this tutorial. Section V concludes with a discussion concerning future research in this area.
Prior Research
The areas of study for this tutorial are conventional databases, active databases, expert systems,
accounting information systems, and accounting education.
Conventional Databases
Conventional database management systems (DBMS) used in business and accounting for the past 15
years are largely passive, functioning as data repositories with appropriate tools for querying and
building large-scale applications. Table 1 provides a summary of some salient conventional database
concepts. Although passive database technology is currently used for many accounting applications, its
efficiency and reliability leave a great deal to be desired. For example, almost no intelligence regarding
the data is built into the core database itself. Indeed, with the exception of entity and referential integrity,
a conventional DBMS functions solely as an efficient storage and retrieval system.
Active Databases
Active databases are very useful for accounting systems because of the inferential power associated with
event-condition-action (ECA) rules, otherwise known as production rules [Widom and Ceri, 1996]
though only limited work has been done in the accounting area [Olsen, 1996]. ECA rules have the
ability to provide intelligence to an otherwise passive database. These ECA rules [Dayal, Hanson, and
Widom, 1995] have their origin in the fields of artificial intelligence and expert systems rule languages
such as OPS5 [Brownston et al., 1985]. ECA rules are defined to be an event that triggers a rule and
checks a condition. If the condition is satisfied, the active database executes an action.
Table 2 lists the prominent active database concepts including ECA rules. Dayal et al. [Dayal, Hanson,
and Widom, 1995] and Widom [1994] list a number of useful tasks that can be accomplished through
the use of ECA rules:
1.
2.
3.
4.
5.
6.
Enforce integrity constraints for specific applications.
Implement triggers based on the conditions.
Maintain derived data.
Enforce access constraints.
Implement version control policies.
Gather statistics for query optimization or database reorganization.
In contrast to a passive database system, an active database monitors pre-specified situations and, when
http://www.swlearning.com/accounting/jac13/jac13_article5.html
7/30/2005
Journal of Accounting and Computers Issue XIII Article 5
Page 3 of 13
the given conditions are met, triggers an appropriate response [Brownston et al., 1985]. For example,
when sales are made on account, it is axiomatic that some will become bad debts. It is also a wellestablished fact that, as accounts move farther beyond their due date, the probability of collection
declines progressively. Typically, an accounts receivable aging list is prepared at specified intervals
after which a person in accounting reviews the list to identify specific receivables that are still unpaid
after some arbitrary period, often 60 days. These overdue accounts then receive attention, generally a
letter from Credit and Collections.
Alternatively, generalized rules can be implemented in an active database system that creates a
collection risk report whenever a receivable hits the 60-day mark. The sequence of rules could send Email to the Credit and Collections Manager, generate correspondence to the delinquent customer, and
start a review of the customer's credit history. A questionable credit history could execute yet another
series of actions.
To summarize, an active database makes use of prespecified rules that are "triggered" on a given event
and the related conditions. Thus, rules can be used to automate certain tasks and also to augment the
manual completion of other tasks.
Expert Systems
ECA rules in active databases are related to condition-action rules in expert systems. OPS5 and Prolog
[Brownston et al., 1985] are examples of languages that incorporate production rules and have been used
in several prototype expert systems.
Expert systems are designed to serve different functions. By definition, experts make the best decisions
of anyone in a given domain. It follows that expert systems can make no better decisions than the
humans whose knowledge is drawn from, in order to create the system. One expert system function,
then, is to act as a decision aid for experts to relieve them of time-consuming tasks and to help them
make consistently acceptable decisions through all areas of a domain.
A second function of expert systems is to facilitate novices in performing tasks that are usually reserved
for persons with more expertise. This purpose might be called "pushing down" the workload by using
expert systems to augment the skill levels of staff persons.
In developing the tutorial discussed in this paper, the four standard components of an expert system
were used [O'Leary and Lin, 1989]:
1.
2.
3.
4.
Database
Knowledge base
Inference engine
User interface
A database is a collection of files that contains information about the topic at hand. For example, a
database in the collections environment would contain data about a specific customer, a description of
how it is structured, and the techniques to use it.
A knowledge base contains information about the relationships among various types of data contained in
the database.
An inference engine is the underlying software that allows several hundred rules to be traversed and
checked simultaneously. The logic can be described using the following progression. The user answers
http://www.swlearning.com/accounting/jac13/jac13_article5.html
7/30/2005
Journal of Accounting and Computers Issue XIII Article 5
Page 4 of 13
the first question posed by the expert system. If it is affirmative, we say the rule "fired," which means it
executed. A rule that is answered negatively does not fire and thus does not trigger other rules. A "fired"
rule may trigger a second rule, which may also "fire." Indeed, many rules may "fire" under certain
conditions, which lead other rules to "fire." Many expert systems have built-in features that guard
against rules infinitely firing one another.
The user interface is simply what the user sees and the methods that must be used to interact with the
system. Older systems had a command line user interface, while newer systems often have a graphical
user interface.
A number of expert systems prototypes and production systems have been created in the last twelve
years. Table 3 is a review of several accounting expert systems research projects that have been
conducted in areas such as auditing, tax, management accounting, and internal controls. More recent
work in the accounting expert systems area seems to have focused more on neural networks and fuzzy
reasoning. Nonetheless, other studies have also included a review of accounting expert systems [Foltin,
1994, 1996].
Expert systems lack the necessary features for large-scale systems though newer research has
concentrated on better integration between expert systems and database systems. Nonetheless, expert
systems have either been prototypes or they have been "front ends" for database systems. DBMSs have
the capability that is needed for large-scale production systems but have traditionally lacked automated
features for rule creation that is common in expert systems. This "marriage" of expert systems and
database features into an active database holds great promise for more reliable, accurate accounting
systems that can be produced at a lower cost. If future systems migrate towards active databases,
accountants who receive substantial active database training should be well-prepared for the advanced
information systems they encounter.
Foundations of Active Databases
Active database systems should provide the same set of tools as conventional database systems
including tools for query management, report creation, input forms creation, transaction management,
etc. Additionally, performance should not suffer because a database is active. The active database should
appear to users to be the same as a traditional database. Using ECA rules that are triggered under
specified conditions is the main difference between an active database and a conventional database.
Active database application rules can be classified as internal, extended, or external [Widom and Ceri,
1996]. In this paper, most of the examples use external active database rules. These rules often take the
place of rules specified in application programs.
1. Internal--Active rules are used as a substitute for special purpose programming. Examples include
integrity constraint management and views support. Referential and entity integrity are examples
of internal active database rules.
2. Extended--Active rules are used for novel database applications such as version management and
workflow management systems.
3. External--Active rules generate automatic behavior in a specific system. Active rules are created
for a specific purpose such as manufacturing, financial, and power plant management.
http://www.swlearning.com/accounting/jac13/jac13_article5.html
7/30/2005
Journal of Accounting and Computers Issue XIII Article 5
Page 5 of 13
Traditionally, ECA rules have been implemented in one of two ways. Each of the two approaches has
serious drawbacks for both the programmer and the user. In one approach, ECA rules are created for a
given expert system. Unfortunately, many expert systems are prototypes that may demonstrate the
usefulness of production rules, but often lack the database features commonly needed for large-scale
applications. Without the ability to efficiently access and manage large quantities of data, expert systems
are confined to small prototypes.
Expert system rules are rarely implemented in a manner that makes them consistently reusable by other
applications. Rather, rules are generally implemented specifically for each application and must be
recreated for new applications, even when the new rule is nearly identical. This lack of rule reusability
coupled with a lack of database features has hindered the adoption of expert systems for large-scale
applications.
A second approach to implementing production rules is to specify the rules in the application by using
the DBMS programming language. This approach creates a more active system, but problems still exist.
One problem is that there is no standardized tool-set in the DBMS programming language to create these
rules. Thus, rules are created using whatever methodology the individual programmer desires. Rules are
not standardized and, therefore, often cannot be reused. Rule nonreusability is disadvantageous for two
reasons. First, rule creation is a time-consuming and tedious process because rule structures must be
developed each time a rule is created. The second disadvantage relates to correctness. Creating a rule
and determining that it is functioning correctly is time-consuming and sometimes prone to error.
Consistency and correctness can be enhanced be reusing rules that are known to produce correct results.
Organizations frequently have rule systems that are associated with a database. For example, an
accounting system usually has rules in place that govern accounting for defective products. These rules
may include determining estimates for a batch of defective products, identifying the cause of defects,
and notifying the appropriate management of possible causes.
The defective product rules are associated with the defective product policy, are specified by managerial
accountants, and are reviewed by the internal audit function. These rules may be found in a variety of
forms in a business. First, rules may be unwritten and passed on to employees on an informal basis. One
problem with this approach is that there is no way to guarantee that facts in the database reflect the
unwritten rules. For example, an unwritten rule may be that defective products in a certain product line
are accounted for by assuming that .01 are defective. The database may not, however, reflect any
defective product allowances. There is no guarantee that the rule has been followed. Additionally, rules
may be written in some type of policy manual. The same problem occurs, though, because there is no
guarantee that the rule has been followed.
Rules can also reside in application programs that access the database. This is probably the most
common placement of rules. There is still no guarantee, however, that the rules and the data are
consistent. Databases may be updated by transactions that are independent of the application program.
This means that the database could be changed to be inconsistent with the rules without the specified
application being invoked. A second problem with including rules in an application is that they are
difficult to change. It is difficult to bring the database into conformity with the new rules because a
single rule may have to be created or updated in numerous places. Any application where a new rule can
be invoked cannot guarantee the correct application of that rule if users can bypass the application. As a
result, including rules in an application program or an expert system shell is cumbersome and subject to
erroneous results.
Rules can also reside in the DBMS itself. In this case, the DBMS can guarantee that the rules and the
data are consistent because a single rule is specified as opposed to rules in each application. Moreover,
http://www.swlearning.com/accounting/jac13/jac13_article5.html
7/30/2005
Journal of Accounting and Computers Issue XIII Article 5
Page 6 of 13
performance is often increased as a result of this integrated approach. Substantial research activity has
occurred over the past decade by the database community in integrating rules and data. This research has
been used in some commercial systems. For example, POSTGRES, Oracle, and Sybase have rule
systems integrated into their database engines. However, rule programming is a task that should be
assigned to the database administrator as a part of the schema design phase. This keeps rule creation
under centralized control and ensures a higher level of rule correctness.
Figure 1 shows the interaction between the individual modules and the DBMS in a conventional
database where the rules are contained in each module. Many modules are listed but a subset is probably
appropriate for a given organization. For example, all rules associated with the accounts receivable
function are located in the accounts receivable module. The design and the data for the entire database
are a part of the DBMS, and each module and its associated rules are independent. In contrast, Figure 2
shows the active database interaction where the rules are a part of the DBMS. The database design, data,
and rules are integrated into the DBMS. The advantage of including rules in the DBMS include:
1.
2.
3.
4.
5.
Work reduction in the rule creation process
The elimination of consistency and accuracy problems
Reduced complexity for maintenance purposes
Reusability of rules
The ability to use specialized tools for rule creation
In Figure 1, we show that the rules are contained in each module of a conventional database, but there is
often little uniformity both in regard to how the rules are specified and what rules are specified. Rules or
constraints are often created in the specific style of a programmer. If multiple programmers are assigned
to the different modules, multiple styles of the rule implementation are likely to result. These
heterogeneous rule implementations lead to increased development and maintenance costs. In contrast,
in an active database system, there is one specified way to create rules or triggers because rules are a
part of the DBMS tool-set.
Work is reduced in the rule creation process in an active database because fewer rules are generally
created. This occurs because the rule duplication common in passive databases is eliminated in active
databases. For example, in Figure 1 notice that rules are developed separately in both the sales and
inventory modules. A rule might exist in the inventory module that ensures that a sale cannot be made
unless sufficient inventory exists to cover the sale. The rule would not execute unless the inventory
module were accessed. To be robust, the same rule would need to exist in the sales module; a sale
cannot be made unless sufficient inventory exists to cover the sale. Only if the rule existed in both
modules could we guarantee its execution under all conditions. Thus, duplicating the rule creation
process would involve unnecessary effort.
Ensuring that rules are functioning correctly is more difficult in systems with multiple modules where
rules are duplicated because each rule must be tested for correctness. In contrast, if one rule is created
and proved correct at the DBMS level, the process for that rule is completed. Maintenance is also
reduced if there are fewer rules because updates or changes have to be made to only one rule instead of
many.
Two additional advantages of active databases include the reusability of rules and specialized tools for
rule creation. First, a number of commercial databases, such as Sybase and Oracle, include triggers that
aid in rule creation. These specialized mechanisms aid the process of rule creation. Rules created in
Sybase are reusable for related situations. For example, a rule may state that "a receivable cannot be
eliminated unless inventory is returned or cash is received." The syntax for that rule can be reused and
modified slightly for a similar rule that states "a payable cannot be eliminated unless the inventory is
http://www.swlearning.com/accounting/jac13/jac13_article5.html
7/30/2005
Journal of Accounting and Computers Issue XIII Article 5
Page 7 of 13
returned or cash is disbursed." Though the rules are semantically different, the structures are very similar
and are in fact reusable. Rule reusability is very attractive because of reduced time for creation and
maintenance.
Active Database Implementation
In this section, a pension accounting system provides the structure for an active database application.
This structure is designed to be used by several different companies in the administration of their
pension plans. Since defined-benefit plans have traditionally been the most common and are more
difficult to understand than defined contribution plans, they will be used in this tutorial. While this
example is not designed for a specific company, a sample company is used throughout our presentation
to illustrate the functions of such a system.
During the conceptual design phase of database creation, considerable effort is devoted to identifying
the business rules that must be followed in order to guarantee correctness in a database. This activity
could be as simple as setting limits on field values or so complex that defining the knowledge itself is a
key activity. A problem with current DBMSs is that few support the implementation of these business
rules in the logical and physical design of the database except for the very simple restrictions involving
key and referential integrity constraints. The remaining constraints are left to the application designers
so that integrity of the system becomes more a matter of the software developer's discipline than an
inherent property of the system. Active databases are being developed so that integrity issues become a
part of the system.
The first step in developing this system was building an entity relationship (ER) model [Chen, 1976] in
an iterative process typical of systems design. By making several modifications until the model best
represented the structure of a typical pension system, a logical ER model was developed. For each entity
in the model, attributes were specified to capture the necessary data that will be required for the system
to effectively operate. After the ER model was complete, normalized tables were specified.
The next step in the systems development process included deriving business rules for the system. Since
the formally stated concept of business rules used in information systems applications is fairly new, a
standard format has not been established for their presentation. Barbara Von Halle [1994] stated this best
when she said, "The best preparation is developing a formal business rule strategy that will meet your
organization's objective."
The business rules for this proposed system are listed in Table 4. We group the business rules according
to the entity to which they relate. It is important to note that some business rules relate to multiple
entities. For each entity, then, the business rules are categorized by each of the four types listed in Von
Halle: definition, fact, constraint, or derivation rule [1994].
Entity Relationship Model
The ER model shown in Figure 3 logically depicts the entities and their relationships. The normalized
tables listed in Figure 4 were derived from the ER model. In the ER model, two related entities are
shown with the appropriate degree of the relationship between them. Degree is represented by either a I
or an M. The entity relationship model also documents the cardinality of relationships. Cardinality is
represented by two characters; each is either a I, an M, or an N placed inside parentheses next to its
respective entity.
http://www.swlearning.com/accounting/jac13/jac13_article5.html
7/30/2005
Journal of Accounting and Computers Issue XIII Article 5
Page 8 of 13
The first entity in the model is the funding pattern. A funding pattern is used by the system to calculate
the amount that the company will contribute each year to the pension trust. The assistance of the
actuarial profession is essential in the computation of the employer's contribution. Actuaries use criteria,
such as employee turnover, mortality rates, length of employee service, compensation levels, and
interest earnings on the pension trust, to determine the contribution. Between one and many funding
patterns may be used to calculate an employer's contribution. However, an employer contribution may
be computed by one and only one funding pattern.
Another entity is the employer contribution. This entity allows the system to record the amount of each
contribution by the check number. After it has been prepared, the employer contribution is sent to one
pension trust fund. A pension trust fund receives many employer contributions.
The pension trust entity is maintained separately from the company, usually by a private pension
administration firm. This fund contains all of the assets of the pension system. The pension trust must be
divided between employer and employee contributions. This topic will be discussed in detail later in our
analysis. In order to maintain the assets of the company's pension, the trust entity must maintain the
balance of the contributions, the interest earned on those contributions, and the losses and gains
associated with the portfolio investments of that fund. When it comes time for an employee to receive
benefits, the pension trust must utilize one of four possible pension benefit formulas.
For our company, there will be four formulas established to calculate benefit payments, which will be
paid to many different employees. An employee may receive a minimum of zero benefit payments. The
maximum would be an indeterminate number. Each formula will be based on the employee's level in the
organizational hierarchy. The four levels are: executive, middle management, supervisor, and staff.
The employee entity includes three generalized sets of tables. First, a salaried table will record a listing
of all currently-employed salaried employees and the necessary corresponding employment data.
Second, an hourly table will record a listing of all currently-employed hourly employees and the
necessary corresponding employment data. Third, when an employee retires, he/she will be moved from
the respective salaried or hourly table to the retired table. It is important to note that a retiree may or
may not be vested in the company pension plan. Therefore, all names listed within the retired table may
not be receiving payments from the pension fund.
Each employee has the option, but not an obligation, to contribute additional amounts from his/her
paycheck toward retirement. The employee contribution entity was then created to record the amount of
each contribution made by an employee. An employee contribution is sent to the pension trust to
accumulate interest and is subject to the gains and losses of the pension portfolio.
Since both the employee and the employer are contributing to the pension fund, it is essential to divide
the pension trust entity by employee and employer. Each employee's accumulated contributions over the
years of his/her employment belong to the individual employee only, so they must be recorded
separately in the pension trust fund. According to the accounting rules for defined-benefit plans, the
annual contributions made by the company are not designated for each employee but, rather, for the
benefit of all future beneficiaries. Thus, we have the reason for splitting the pension trust table.
Business Rules
The business rules are grouped by the entity to which they relate. Obviously, there will be some
overlapping between entities. Rules that pertain to two entities will be listed for each entity and marked
with a capital letter. Rules that pertain to greater than two entities will also be listed for each entity, but
will be marked with a double capital letter. For each entity, then, the business rules will be divided by
http://www.swlearning.com/accounting/jac13/jac13_article5.html
7/30/2005
Journal of Accounting and Computers Issue XIII Article 5
Page 9 of 13
each of the four types: definition, fact, constraint, or derivation rule. Table 4 includes a list of business
rules for this system.
The formal system that corresponds to the business rules was generated in a more quasi-formal language
that is similar to some active databases. These system rules are listed in Table 5 and are given as an
example of rule creation from a list of business rules.
Educational Benefits
Several types of knowledge or skills must be used or developed to successfully complete this tutorial. In
Figure 5, the seven important components that interact with a successful implementation of this tutorial
are shown. Those components are:
1.
2.
3.
4.
5.
6.
7.
E/R modeling skills
Passive database knowledge
Active database knowledge
Relational database normalization skills
Pension skills
Programming skills
Relational database implementation skills
This paper has focused mainly on the first five components. The two that have not been covered are the
programming and the relational database implementation skills. If the analysis and design are completed
as was shown earlier in the paper, the next phase would include an implementation. An implementation
is preferable to just an analysis and design because the skills gained from an implementation are
invaluable in practice. However, if this tutorial were used only to teach analysis and design, it would
still be very valuable because the analysis and design phase is often the most difficult one, and there are
very few tutorials that include active database techniques.
Conclusion
Using active database techniques in accounting applications has several inherent advantages over
passive database techniques. Accountants with a background in conventional and active database
techniques will be better equipped to function with these newer systems.
The tutorial in this paper describes a detailed, comprehensive, active database tutorial in the pension
accounting area. Learning to build an active database in the context of a pension accounting system is
beneficial in three ways:
1. It reinforces conventional and active database concepts by necessitating a comprehensive design
and implementation.
2. It reinforces the concepts in the complex area of pension accounting.
3. A certain synergy is created as the database development reinforces pension accounting
principles, and the implementation of pension accounting principles sharpens skills in database
development.
Active database systems can also be appropriately applied to several different areas within the field of
http://www.swlearning.com/accounting/jac13/jac13_article5.html
7/30/2005
Journal of Accounting and Computers Issue XIII Article 5
Page 10 of 13
accounting. Audit, expense management, and taxation represent just a few of the possible active
database accounting application areas. Active databases have positive implications for auditors who seek
higher levels of assurance for data integrity because written rules may be specified and guaranteed to be
implemented. It also eliminates data updates without each applicable rule being examined. For example,
when a cash disbursement amount is recorded in the cash disbursements journal, the same amount will
be transferred to the check register and ultimately to the check itself. The rule triggering that initiates the
transfer of the disbursement amount from the cash disbursements journal to the check register, and also
from the check register to the check, ensures that the disbursement amount recorded initially is indeed
the amount that the payee receives. Thus, the auditor's test of internal controls can demonstrate a greater
assurance of accuracy by using an active database.
Another advantage of active databases is that large-scale systems can be developed using ECA rules
because of the data management features that are common in many DBMSs. These features were
missing in prototype expert systems.
Yet another advantage of active database techniques is that once the rules are specified and found to be
correct, they are reusable. This not only saves tremendous amounts of money in development time, but it
also enhances the integrity of the system. In considering the increasingly important area of expense
management in this age of corporate restructuring, lower systems development time is highly desirable.
Although systems development is a value-added activity, reductions in development time, which do not
cause a deleterious effect on the value of the activity, lead to reduced costs without compromising
quality.
Finally, active database techniques have the ability to simplify very complex problems. This is of great
importance to the tax application in accounting. Active databases could conceivably handle complex tax
rules more efficiently than the passive database.
References
Abiteboul, S., R. Hull, and V. Vianu, Foundations of Databases,
(Reading, MA: Addison-Wesley, 1995).
Brownston, L., R. Farrell, E. Kant, and N. Martin, Programming Expert Systems
in OPS5: An Introduction to Rule-Based Programming, (Reading, MA:
Addison-Wesley, 1985).
Cannan, S.J., and G.A.M. Otten, SQL--The Standard Handbook (London:
McGraw-Hill, 1992).
Chen, P.P., "The Entity-Relationship Model: Toward a Unified View of Data,"
ACM Transactions on Database Systems. Volume 1, Number 1 (January
1976): 936.
Dayal, U., E. Hanson, and J. Widom, Active Database Systems. In Modern
http://www.swlearning.com/accounting/jac13/jac13_article5.html
7/30/2005
Journal of Accounting and Computers Issue XIII Article 5
Page 11 of 13
Database Systems, edited by Won Kim, Addison Wesley Publishing Co.
(New York: ACM Press, 1995) 434456.
Dayal, U., and J. Widom, Active Database Systems. In ACM SIGMOD
International Conference on Management of Data (tutorial), San Diego,
CA (June 1992).
Dillard, J. and J. Mutchler, "Expertise in Assessing Solvency Problems,"
Expert Systems (August 1987): 170178.
Dungan, C. and Chandler, J., "AUDITOR: A Microcomputer-Based Expert
System to Support Auditors in the Field," Expert Systems (October 1985):
210221.
Edwards, A., and N.A.D. Connell, Expert Systems in Accounting (Englewood
Cliffs, NJ: Prentice Hall, 1990).
Foltin, C., "Beyond Expert Systems: Neural Networks in Accounting," National
Public Accountant (June 1996): 2630.
----- "Accounting Expert Systems," CPA Journal (November 1994): 4653.
Gray, J., and A. Reuter, "Transaction Processing: Concepts and Techniques" (San
Mateo, CA: Morgan Kauffman Publishers, 1993).
Hansen, J. and W. Messier, "A Knowledge-Based, Expert System for Auditing
Advanced Computer Systems," European Journal of Operational
Research (September 1986a): 371379.
Kelly, K., G. Ribar, and J. Willingham, "Interim Report on the Development of
an Expert System for Auditor's Loan Loss Evaluation," Auditing
Symposium VIII (University of Kansas, 1986).
Lomet, D., and B. Salzberg, "Transaction Time Databases," in Temporal
Databases: Theory, Design, and Implementation edited by Tansel, A., et al.
(New York: The Benjamin/Cummings Publishing Company, Inc. 1993).
Melton, J., and A.R. Simon, Understanding the New SQL: A Complete Guide
(San Francisco: Morgan Kaufmann, 1993).
http://www.swlearning.com/accounting/jac13/jac13_article5.html
7/30/2005
Journal of Accounting and Computers Issue XIII Article 5
Page 12 of 13
Meservy, R., A. Bailey Jr., and P. Johnson, "Internal Control Evaluation: A
Computational Model of the Review Process," Auditing: A Journal of
Practice and Theory (Fall 1986): 4474.
Messier, W. and J. Hansen, "Expert Systems in Auditing: The State of the Art,"
Auditing: A Journal of Practice and Theory (Fall 1987): 94105.
Michaelson, R., "An Expert System for Federal Tax Planning," Expert Systems,
Vol.1, No. 2 (1984): 149167.
----- "An Expert System for Selecting Tax Shelters," Journal of the American
Taxation Association (Fall 1987): 3547.
----- "Development of an Expert Computer System to Assist in the
Classification of Estate Tax Returns," Accounting Horizons (December
1988): 6370.
Newell, A., and H.A. Simon, Human Problem Solving, (Englewood Cliffs, NJ:
Prentice-Hall, 1972).
Olsen, D., and D.L. Sproveri, "An Active Database Approach for Supporting
Accounting Information Systems," American Accounting Association
National Conference (August 1996): 23.
O'Leary, D., and T. Lin, "Expert Systems in Accounting in a Personal Computer
Environment," Georgia Journal of Accounting (Spring 1986): 107117.
----- "An Expert System for Cash Flow Analysis." In Artificial Intelligence in
Accounting and Auditing, edited by M. Vasarhelyi, (New York: Markus
Weiner Publishing, Inc. 1989).
Shpilberg, D., and L. Graham, "Developing ExperTAXsm: An Expert System for
Corporate Tax Accrual and Planning," Auditing: A Journal of Practice and
Theory (Fall 1986): 7594.
Shpilberg, D., L. Graham, and H. Shatz, "ExperTAXsm: An Expert System for
Corporate TaxPlanning," Expert Systems (July 1986): 136151.
http://www.swlearning.com/accounting/jac13/jac13_article5.html
7/30/2005
Journal of Accounting and Computers Issue XIII Article 5
Page 13 of 13
Steinbart, P., "Materiality: A Case Study Using Expert System," The Accounting
Review (January 1987): 97116.
Stonebraker, M., "The Integration of Rule Systems and Database Systems." IEEE
Transactions on Knowledge and Data Engineering, 4 (1992): 415423.
Von Halle, B., Lessons to Learn from Tee-Ball. In Database Programming &
Design (December 1994).
Widom, J., Research Issues in Active Database Systems: Report from the Closing
Panel at Ride-Ads '94, in ACM SIGMOD Record, 23(3) (September
1994): 4143.
Widom, J., and B. Ceri, "Introduction to Active Database Systems," in Widom, J.,
Ceri, B., eds., Active Database Systems: Triggers and Rules For Advanced
Database Processing, (San Francisco: Morgan Kaufmann Publishers, Inc.,
1996).
Widom, J, and S. Ceri, eds., Active Database Systems: Triggers and Rules for
Advanced Database Processing, (San Francisco: Morgan Kaufmann
Publishers, Inc., 1996).
Widom, J. and S. Chakravarthy, eds., Fourth International Workshop on Research
Issues in Data Engineering: Active Database Systems, (Houston, Texas,
1994, IEEE Computer Society Press, Los Alamitos, CA).
Widom, J., R.J. Cochrane, and B.G. Lindsay, "Implementing Set-Oriented
Production Rules as an Extension to Starburst. In Proceedings of the
Seventeenth International Conference on Very Large Data Bases,
Barcelona, Spain (September 1991): 275285.
Widom, J., and S.J. Finkelstein, "Set-Oriented Production Rules in Relational
Database Systems. In Proceedings of the ACM SIGMOD International
Conference on Management of Data, Atlantic City, NJ (May 1990):
259270.
Copyright © 1998 South-Western College Publishing. All Rights Reserved.
webmaster@swlearning.com
http://www.swlearning.com/accounting/jac13/jac13_article5.html
7/30/2005